Subject: RE: [nemo] Multiple Egress vs multihoming

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 19 May 2003 14:14:01 +0100

Hi again Chan Wah and Julien:

I'm back from vacations :)

I looked again at the w you introduced. Now I'm a bit confused. My
initial statement on April 24th was x is for multiple parallel careOfs
and y is for multiple egress routers. It seems my x is your w=0 and my y
is your w=1. I subdivided x in 2 cases, and y too. Note that I insisted
in saying that whether a MR has one or more egress interface should not
be important in the protocol and that we should make the assumption that
there are multiple interfaces, as we are talking about Mobile Routers.

In other words it seems to me that the w is not too useful... For me,
the problems are still the 4 I listed before. If I'm missing something,
sorry about that :)

Let me describe further the problems I see, x cases, Tarzan and JetSet
and y cases, Shinkansen and doublebed: 

Tarzan: One MR building and registering (to same HA) several CareOf in
order to maintain connectivity while moving is a MH(x=0)

The Tarzan problem is the introduction of multiple CareOfs registered in
parallel. This breaks the MIP paradigm. Whether they are on a single or
multiple interfaces of the MR may not ne important, but I expect that
they'll be on different access routers. Anyway, this introduces the load
balancing / high availability problem in both directions. I understand
that FMIP has already studied this some. Maybe we can start from there.

JetSet: one MR that registers its prefix to Paris and New York at the
same time in order to optimize routing is a MH(x=1)

The JetSet is the case where the multiple CareOfs are not registered to
the same HA. The HAs may be far away from each other. The JetSet problem
is the collaboration of the HAs in order to accept multiple
registrations, and the selection by the MR of the best via-HA to the
correspondent. Correlated problem is to get the packets onto the active
tuunels on the HA side. This is the problem for which I pointed out that
a dynamic routing over the MRHA is needed, including for me whatever
causes the MNP prefix to be injected in the Home AS routing protocol
while the MR is registered.

Shinkansen: A train with one prefix, one careof per MR and 2 MRs, which
is a MH(y=0).

Shinkansen is about the high availability of a prefix being registered
by 2 different MRs. The problem is to make that transparent to the MNNs,
so that if the MRHA tunnel of one MR fails, the MNNs traffic move to the
other MR. Note that if we have both routers registering the same prefix
at the same time, this is an x case too. But the second MR can be in hot
standby, in which case this is not a x case.

doubleBed: 2 MRs happening to share the same wireless media for their
mobile prefix (Erik's problem) is a MH(y=1)
Say MR1 has prefix P1 and HA1, and that MR2 has P2 via HA2. doubleBed
problem is basically to allow traffic with a careOf in P2 to flow via
MR1. This requires MR1 to accept P2 in its ingress filtering selection.
This also requires, if MR2 is down, the HA1 sends traffic for P2 over
MRHA1. In other words, MR1 has and advertises P2. Julien's case with an
intermediate router is a good one. For me, this is a case where the MN
is not a stub anymore, and should be ruled out of scope real quick. 

If you see other problems to be solved please update this discussion. I
could also help on the draft if you wish...

Pascal

> -----Original Message-----
> From: Julien Charbon [mailto:[email-masked]] 
> Sent: jeudi 1 mai 2003 11:05
> To: [email-masked]
> Cc: Pascal Thubert (pthubert)
> Subject: Re: [nemo] Multiple Egress vs multihoming
> 
> 
> 
>   Hi Pascal, Hi all,
> 
>   first, excuse me for my second mail [1]. You can put in 
> your trash. I'm so sorry.
> 
> On Fri, 25 Apr 2003 17:00:11 +0100
> "Pascal Thubert (pthubert)" <[email-masked]> wrote:
> 
> > I like your work very much. Very useful and constructive :) 
> I hope we 
> > keep your pictures in the final taxonomy.
> 
>   Thanks you. I will try to continue as well.
> 
> > A general remark, the fact that the multiple careofs are 
> one the same 
> > interface or on different interfaces does not strike me as 
> relevant.  
> > There must be a way for the MR to sort out the available 
> careOfs and 
> > use the best one(s). The interface that provides a careOf 
> is relevant 
> > in that selection. But the protocol to the Home Agent is 
> not impacted, 
> > is it?
> 
>   Well, It depends if you have just one bi-directionnal 
> tunnel between one HA and one MR or several. But the 
> Nemo-Requirement says :
> 
>    R02: The solution MUST set up a bi-directional tunnel between
>         MR and MR's Home Agent.  ^
> 
>    R03: All traffic exchanged between a MNN and a CN in the global
>         Internet MUST transit through the bidirectional tunnel.
>                                       ^^^
> 
>   And so just ONE tunnel. Maybe this case will never be a 
> part of Nemo Basic Support. Conclusion: You are right.
> 
>   But Thierry said me the case with several tunnels is not 
> exclude in Nemo Basic Support, and that could exist a kind of 
> modularity to manage this case.
> 
> > >   So for the Tarzan you can have:
> > >
> > >    - One multi-addressed MR.
> > >
> > >                AR2 [P2]
> > >     _           _   _____
> > >    |_|-|  _  |-|_|-|     |
> > >     _  |-|_|-|  _  |     |-|        _
> > >    |_|-|     |-|_|-|_____| |  _  |-|_|
> > >                            |-|_|-|
> > >                                  |
> > >                AR1 [P1]
> > >
> > >    MNNs   MR        Internet  AR    HA
> > >
> > >
> > >    - One "Multi-egress-interfaced" MR.
> > >                     _____
> > >     _           _  |     |
> > >    |_|-|  _  |-|_|-|     |-|        _
> > >     _  |-|_|=|     |_____| |  _  |-|_|
> > >    |_|-|     |             |-|_|-|
> > >                                  |
> > >
> > >    MNNs   MR   AR  Internet  AR    HA
> > >
> > >
> > >   - Two MR in multi-site case.
> > >
> > >           P
> > >          --->
> > >           _         _____
> > >     _  |-|_|-|  _  |     |
> > >    |_|-|     |-|_|-|     |-|        _
> > >     _  |     |     |_____| |  _  |-|_|
> > >    |_|-|  _  |             |-|_|-|
> > >        |-|_|-|                   |
> > >
> > >          --->
> > >           P
> > >
> > >    MNNs   MR   AR  Internet  AR    HA
> >
> > Yes, they are all Tarzan. The most typical in my mind is: Note that 
> > the [=] sign is extended to mean 'may or may not be the same 
> > interface'
> >
> >                 AR2 [P2]
> >      _           _   _____
> >     |_|-|  _  |-|_|-|     |
> >      _  |-|_|=   _  |     |-|        _
> >     |_|-|     |-|_|-|_____| |  _  |-|_|
> >                             |-|_|-|
> >                                   |
> >                 AR1 [P1]
> >
> >     MNNs   MR        Internet  AR    HA
> >
> 
>   I see. Now this part is clear for me.
> 
> 
>   In the same way and to clean my Shinkansen & DoubleBed graphicals:
> 
>     - In the previous graphicals and in my mind it was:
> 
>         P1
>        --->
> 
>       The Mobile Network Prefix which is in Prefix Binding
>       Update. [Too complex to understand in my graphics]
> 
>     - Now it is:
> 
>         P1
>       <---
> 
>       The Mobile Network Prefix announced in the Mobile Network by the
>       Mobile Router.
> 
>     - The term Egress Router not exist in Nemo-Terminology. Mobile
>       Router is enough:
> 
>         The MR has one or more egress interface(s) and one or more
>         ingress interface(s).
> 
>   And so:
> 
>   o Shinkansen:
> 
>     [Single Mobile Network Prefix announced by Mobile Routers in the
>      Mobile Network]
> 
>    Example with two Egress Routers.
> 
>           P
>         <----
> 
>          MR2
>           _  |
>     _  |-|_|-|  _____
>    |_|-|     |-|     |
>     _  |       |     |-|        _
>    |_|-|  _  |-|_____| |  _  |-|_|
>        |-|_|-|         |-|_|-|
>              |               |
>    MNNs  MR1   Internet  AR    HA
> 
>         <----
>           P
> 
>   o DoubleBed:
> 
>     [Multiple Mobile Network Prefix announced by Mobile Router in
>      the Mobile Network]
> 
>    Example with two Egress Routers.
> 
>           P2
>         <----
> 
>          MR2
>           _  |
>     _  |-|_|-|  _____
>    |_|-|     |-|     |
>     _  |       |     |-|        _
>    |_|-|  _  |-|_____| |  _  |-|_|
>        |-|_|-|         |-|_|-|
>              |               |
>    MNNs  MR1   Internet  AR    HA
> 
>         <----
>           P1
> 
>    Example with one Egress Router. [Rarely used but... It exists]
> 
> 
>           P2        _____
>     _   <---    _  |     |
>    |_|-|  _  |-|_|-|     |
>     _  |-|_|-|     |_____|-|        _
>    |_|-|     |             |  _  |-|_|
>         <---               |-|_|-|
>           P1                     |
> 
> 
>    MNNs  MR    AR  Internet  AR     HA2
> 
>  [This example is maybe not a good one because the MR have two
>   Ingress Addresses and so the Nemo protocol must deal with]  
> [Maybe too particular]
> 
> > >    In all this examples the HA will have two CoAs for the same 
> > > prefix in one HA. According with your definition they are Tarzan 
> > > cases.
> >
> > Shinkansen and doubleBed are Tarzans by definition.
> 
>   Aarrgh ! My comprehension ! Example :
> 
>   [HAx is the Home Agent for the MRx Mobile Router]
> 
>           P              AR    HA1
>         <---
>          MR1              _  |
>           _  |         |-|_|-|  _
>     _  |-|_|-|  _____  |     |-|_|
>    |_|-|     |-|     |-|
>     _  |       |     |
>    |_|-|  _  |-|_____|-|        _
>        |-|_|-|         |  _  |-|_|
>              |         |-|_|-|
>                              |
>    MNNs  MR2   Internet
>         <---
>           P              AR     HA2
> 
> 
>   This case is Shinkansen:
>   [The same Mobile Network Prefix is advertise to the MNNs]
> 
>   But a JetSet case too: [Not a Tarzan case]
>   [Multiple HAs for CoAs of a same Mobile Network Prefix]
> 
>   But it is just a detail.
> 
> > > > Any IPv6 node may build multiple global addresses. Long 
> as we do 
> > > > not register several CareOfs at the same time, it's not a Nemo 
> > > > issue, it's a standard feature.
> > >
> > >  I just add a remark :
> > >
> > >     - Example with one MR multi-addressed.
> > >
> > >                AR2 [P2]
> > >     _           _   _____
> > >    |_|-|  _  |-|_|-|     |
> > >     _  |-|_|-|  _  |     |-|        _
> > >    |_|-|     |-|_|-|_____| |  _  |-|_|
> > >                            |-|_|-|
> > >                                  |
> > >                AR1 [P1]
> > >
> > >    MNNs   MR        Internet  AR    HA
> > >
> > >   P1/P2: Differents IPv6 /64 Prefix.
> > >
> > >   And of course Ingress Filtering is made on AR1 and AR2.
> > >
> > >   So the MR may have this two IPv6 global address :
> > >
> > >    P2:EUI-64-MR and P1:EUI-64-MR
> > >
> > >   If the bi-directional tunnel between the MR and the HA pass 
> > > through AR2 and if AR2 is destroyed by Tarzan anger [the 
> real one] 
> > > and so its reachability to the Internet lost, how the 
> NEMO mechanism 
> > > should deal with this case ?
> > >   So I think Multi-Addressed Multi-Homing is an important case in 
> > > NEMO, not just a standard fearture. [But maybe I'm wrong]. Also 
> > > maybe it will be resolve by the same mechanism in NEMO, 
> so I put it 
> > > with the Multi-Interfaced case.
> >
> > Reread me well: I meant that if you register only one CareOf at a 
> > given point of time, it is a standard MIP flows. If a MIP MN sees 2 
> > ARs on a link, it can build 2 careOfs, but can only bind 
> the primary. 
> > If the primary careOf fails to bind, or times out rebinding, a 
> > standard MIP MN should go try the next available careOf. 
> That process 
> > is not necessarily described in MIPv6, but should it?
> 
>   With this explanation, is clear for me now [again]. And 
> effectively is a standard issue for an Ipv6 Mobile Node. [In 
> my mind it was for all Ipv6 Node].
> 
> > Now, if you have 2 concurent tunnels, it is a whole new 
> problem, to be 
> > designed :) . The HA may try to load balance over the 2 
> tunnels, and 
> > if one dies, we must make sure the HA knows quite fast. For 
> instance 
> > by encapsulating over TCP or SCTP. Anyway, it's one of the good 
> > problems to resolve if we want multiple careOfs.
> 
>   Yes. Now the fact is to know if it is a required feature in 
> Nemo Basic Support or is for Nemo Next Generation.
> 
> <nemo-multi-homing>
> 
>   But I think the management of Multiple CoAs per Network 
> Prefix may provide to Nemo some interesting Multi-Homing 
> benefits like :
> 
>   o Fault-Tolerance/Redundancy.
>   o Load-Sharing.
>   o Policy Management.
> 
>   And it is possible to deploy because [in Nemo Basic 
> Support] all traffic past in tunnel(s) between HA(s) and 
> MR(s) and so the traffic in this tunnel can be policed as you 
> wish. [You don't touch at Correspondant Node Mobile Ipv6 Stack].
> 
>   In Mobile Ipv6 is harder to realize/deploy.
> 
>   But I don't forget the Pandora's box style of Multi-Homing.
> 
> </nemo-multi-homing>
> 
> > Multihoming is not trivial, we'll have to decide whether to 
> amend the 
> > requirements draft for basic about that.
> 
>   So Nemo Basic Support can support only the Redundancy 
> Multi-Homing benefit; or more benefits [Load-Sharing, Policy] 
> and become more complex. [Too complex for a Basic Support ?]
> 
>   Maybe the design team have a begin of answer.
> 
> > > > Comments anyone?
> > >
> > >   I think you have found the good discrimants to classify the 
> > > Multi-Homing in NEMO. So I have just read the Chan Wah Ng's mail 
> > > [2], and just by taking again his classification and ours :
> > >
> > >  And I obtain (w, x, y) :
> > >
> > >   with
> > >
> > >   w: 0: A Mobile Router have more than one Global IPv6 Address.
> > >         OR a Mobile Router have more than one Interface.
> > >      1: There is more then one Egress Mobile Router.
> > >
> > I expect that in any case you imply that multiple CareOfs are 
> > registered in parallel, right?
> 
>   Yes, I think you are right [again]. Now I understand your 
> proposition with "only" four classes of problem.
> 
> > >   x: 0: There is single HA for CoAs of a same Prefix.
> > >      1: There is muliple HA for CoAs of a same Prefix.
> > >
> >
> > I meant mobile prefixes, no the prefix that the careOf is 
> built upon. 
> > I'm sure you mean that too?
> 
>   Yes, I rewrite sharper:
> 
>    x: 0: There is single HA for CoAs of a same Mobile Network Prefix.
>       1: There are muliple HA for CoAs of a same Mobile 
> Network Prefix.
> 
> > >   y: 0: A single Prefix is announced by Egress Router(s).
> > >      1: Muliple Prefix are announced by Egress Router(s).
> >
> > I meant present on INGRESS; see the discussion with Hesham; 
> is this a 
> > typo or is there a misunderstanding between us?
> 
>   Yes, this definition provide misunderstanding, I rewrite :
> 
>   y: 0: A single Mobile Network Prefix is announced by Mobile 
> Router(s).
>      1: Muliple Mobile Network Prefix are announced by Mobile 
> Router(s).
> 
>   or the Chan Wah Ng's one is better [more general]:
> 
>   y: 0: A single prefix is advertise to the MNNs
>      1: More than one prefices is advertised to the MNNs
> 
>   or maybe your definition is more understandable and the good one:
> 
>   y: 0: Same Mobile Network Prefix for Mobile Router of the same link.
>      1: Differents Mobile Network Prefix for Mobile Router of 
> the same link.
> 
>   or I really misunderstand. [It is an another possibility]
> 
>   So an interresting case to clear this point :
> 
>      _     p1 MR1                   AR1   HA1
>     |_|-| <--_     ISP1 ________
>      _  |---|_|--------|        | |        _
>     |_|-|              |        |-|  _  |-|_|
>          \ <--         |        | |-|_|-|
>   Intern  \_ p1        |        |       |
>   Router  |_|          |Internet|
>           /  p2        |        |
>      _   / <--         |        | |        _
>     |_|-|    _         |        |-|  _  |-|_|
>      _  |---|_|--------|________| |-|_|-|
>     |_|-| <--      ISP2         ISP3    |
>            p2 MR2
>    MNN                              AR2   HA2
> 
>   This case is a DoubleBed case because if the ISP1 link fail 
> the problem is:
> 
>   How past the p1 prefix's packets through the MR2_HA2 tunnel 
> then through the AR2 link with the Cerberus Ingress Filtering 
> made by ISP3.
> 
>   [An example of solution is in [2] [Section 3.2.2., Using 
> Alternate Mobile Router]]
> 
>   So my preferred definition is the Chan Wah Ng's one:
> 
>   y: 0: A single prefix is advertise to the MNNs
>      1: More than one prefices is advertised to the MNNs
> 
> > I do agree with your vision. My view is a summarization to focus on 
> > where the problems are in my own view. We may start your standpoint 
> > and see what are the meaningful case between the 8 
> combinations. For 
> > instance (0,0,1) is a trivial extension of (0,0,0).
> 
>   I think you want to write :
> 
>   "For instance (1,0,0) is a trivial extension of (0,0,0)"
> 
> > Like this, we'll find my 4 problems, and other if I missed some? Do 
> > you want to pursue that way?  Pascal
> 
>   So, is it enough ?
> 
>   [Two days of reflection later...]
> 
>    So the main goal of a taxonomy is to define a class of 
> problem, name it, and permit to say after: The solution for 
> the problem <name-of-problem> is ...
> 
>   With this four classes can we say the solution for the 
> Tarzan problem is ... ? Difficult because - for example - 
> this two cases need differents solutions:
> 
>     - One "Multi-egress-interfaced" MR.
> 
>            P         _____
>      _    <--    _  |     |
>     |_|-|  _  |-|_|-|     |-|        _
>      _  |-|_|=|     |_____| |  _  |-|_|
>     |_|-|     |             |-|_|-|
>                                   |
> 
>     MNNs   MR   AR  Internet  AR    HA
> 
> 
>    - Two MR in multi-site case.
> 
>             P
>           <---
>            _         _____
>      _  |-|_|-|  _  |     |
>     |_|-|     |-|_|-|     |-|        _
>      _  |     |     |_____| |  _  |-|_|
>     |_|-|  _  |             |-|_|-|
>         |-|_|-|                   |
> 
>           <---
>             P
> 
>     MNNs   MR   AR  Internet  AR    HA
> 
>   And this two examples are Shinkansen too. So it is why 
> [maybe] an another level [w] would be appreciable. What is 
> your position on this specific example ?
> 
>   Well, I think you provide elsewhere the good taxonomy. 
> Thanks you for your judicious and constructives remarks.
> 
> 
>                                             -- Julien
> 
> 
> [1] http://www.nal.motlabs.com/pipermail/nemo/2003-April/000567.html
> [2] http://www.psl.com.sg/draft-ng-nemo-multihoming-issues-00.txt
>

---

From: Chan-Wah Ng <[email-masked]>
Date: 20 May 2003 16:31:46 +0800

Hello Pascal, and Julien

> I'm back from vacations :)
Welcome back.

> there are multiple interfaces, as we are talking about Mobile Routers.

I agree it is not important how many egress interfaces a mobile router
has.  That's not what 'w' is.  'w' is used to differentiate between
whether there is a single mobile router or multiple mobile routers in
the mobile network.

> the problems are still the 4 I listed before. If I'm missing something,

You may have misunderstood 'w'. See if you still think there is no
difference whether there is a single MR or there is multiple MR.

> order to maintain connectivity while moving is a MH(x=0)

I interpret x=0 as a single HA.  

> same time in order to optimize routing is a MH(x=1)
I interpret x=1 as two or more HA.

> Shinkansen: A train with one prefix, one careof per MR and 2 MRs, which
I interpret y=0 as a single prefix advertised to MNNs.  The way you
define it, it will be a (w=1,x=*,y=0) under Julien and my
classifications.

> mobile prefix (Erik's problem) is a MH(y=1)

I interpret y=1 as a multiple prefix advertised to MNNs. The way you
define it, it will be a (w=1,x=*,y=1) under Julien and my
classifications.

> could also help on the draft if you wish...

We will have agree on each others taxonomy first ...  I admit that our 8
classifications may be a bit overkill, and some of them may turn out to
trivial.  But IMHO, a draft should be there to document such a deduction
of triviality and the draft Julien and I are co-authoring is exactly to
do this.

In trying to merge our classifications, I way I see it is this:

Tarzan is (w=0,x=0,y=*)
JetSet is (w=0,x=1,y=*)
Shinkansen is (w=1,x=*,y=0)
Doublebed is (w=1,x=*,y=1)

By the way, on careful inspection of your definitions, your x and y are
not orthogonal but mutually exclusive, since Tarzan and JetSet specifies
(one MR) and Shinkasen and Doublebed specifies 2 MRs.

/rgds
/cwng

---

From: Julien Charbon <[email-masked]>
Date: Thu, 22 May 2003 20:18:42 +0900

Hi Pascal, Hi all,

On Mon, 19 May 2003 14:14:01 +0100

> I'm back from vacations :)

 I hope you past good vacation, and your are always motivate to
continue the discussion in the multi-homing domain.

> the problems are still the 4 I listed before. If I'm missing something,

 It's nothing, the more there are different points of view the more
the good, or the best solution can be found. And in general this
solution take ideas from all of the other.

> order to maintain connectivity while moving is a MH(x=0)

 Excuse-me that is MH? [Just for my information]

> that FMIP has already studied this some. Maybe we can start from there.

 Let's go for comments:

  The case:

                       _____
       _    p      _  |     |
      |_|-|<-_  |-|_|-|     |-|        _

  I think it a very classic multi-interface problem.

 Solution requirements:

  If you want to use the two interfaces at the same time:

    o Allow several tunnels between a MR and a HA.
    o Allow binding of Multiple CoAs for the same MN-Prefix.
    o Identify the CoAs in the Prefix-BU.
      Explanations for this requirement:

        At a time on the HA you have:

         HA Nemo Binding cache:
            Prefix1/length -> CoA1.
            Prefix1/length -> CoA2.

        And then you receive a Prefix-BU from the same MR:
           Prefix1/length -> CoA3.

         Which CoA has changed the CoA1 or the CoA2 ?

  If you use just one interface a the same time:

    o Nothing, just switch the interface when one goes down.

   But take care in this case the mobile router it's not a
   Multihomed Mobile Router with this behavior according to:

   ,----[ draft-ernst-nemo-terminology-01.txt ]
   | Multihomed Mobile Router
   |
   | A MR is multihomed when it has simultaneously more than one
   |                                ^^^^^^^^^^^^^^
   | active connection to the Internet, that is when it is either:
   |
   | [...]
   |
   `----

   And so remember the R.12 requirements:

   ,----[ draft-ietf-nemo-requirements-01.txt ]
   |    R12: The solution MUST function for multihomed MR [...]
   `----

 Configuration good for:

  o Keep Connectivity Transparently

    Reasons:
     o Don't not change anything for the MNNs.

  o Load-Balancing & Policy

    Outbound traffic:
     o The MR choose between the two CoAs.

    Inbound traffic:
     o The HA choose between the two MR's CoAs.

    So the Prefix-BU should carry some preference for each CoA.

 Clear case for me and you. That's fine.

> while the MR is registered.

 The case:

                                 AR    HA2
                                  _  |
                               |-|_|-|  _
                        _____  |     |-|_|
        _    p      _  |     |-|
       |_|-|<-_  |-|_|-|     |
        _  |-|_|-|     |_____|-|        _
       |_|-|     |             |  _  |-|_|
                               |-|_|-|
                                     |
       MNNs  MR    AR  Internet  AR    HA1

 Solution requirements:

  o Maybe nothing.

 Configuration used for:

  o HA redundancy

  o Kind of Routing Optimization

  o Load-Balancing & Policy

    Outbound traffic:
     o The MR choose between the two HAs. [priority]

    Inbound traffic:
     <maybe-far-away-from-nemo>

      o Prefix-BU should carry some priority in the Prefix-BU for each
        HA, and thus the HAs announce the prefix in IGP with metric
        depending on this priority.

     </maybe-far-away-from-nemo>

> standby, in which case this is not a x case.

 The case:

             MR2

             p
            <-_  |
        _  |-|_|-|  _____
       |_|-|     |-|     |
        _  |       |     |-|        _
            <-   |               |
             p

       MNNs  MR1   Internet  AR    HA

 Solution requirements:

  o Allow binding of Multiple CoAs for the same MN-Prefix.

 Configuration used for:

  o Keep Connectivity Transparently

    Reasons:
     o The Default Router Selection [RFC 2461, Section 6.3.6] ]is
       implemented in all IPv6 Node.  So if a router is crunched by
       godzilla the MNNs take the other transparently.

  o Router redundancy

  o Load-Balancing & Policy

    Outbound traffic:

     <sure-far-away-from-nemo>

     I think a kind of good solution is something like that:

     ,----[ draft-ietf-ipv6-router-selection-02.txt ]
     | IPng Working Group                                               R. Draves
     | Internet Draft                                          Microsoft Research
     | Document: draft-ietf-ipv6-router-selection-02.txt                R. Hinden
     |                                                                      Nokia
     |                                                              June 10, 2002
     |
     |    Default Router Preferences, More-Specific Routes, and Load Sharing
     `----
     [http://ietf.org/internet-drafts/draft-ietf-ipv6-router-selection-02.txt]

     </sure-far-away-from-nemo>

    Inbound traffic:

     o The HA choose between the two MR CoA's.

     So the Prefix-BU should carry some preference for each CoA.

> is not a stub anymore, and should be ruled out of scope real quick.

 The case:

             MR2             AR    HA2

             p2               _  |
            <-_  |         |-|_|-|  _
        _  |-|_|-|  _____  |     |-|_| [Manage p2 only]
       |_|-|     |-|     |-|
        _  |       |     |
       |_|-|  _  |-|_____|-|        _
           |-|_|-|         |  _  |-|_| [Manage p1 only]
            <-   |         |-|_|-|
             p1                  |

       MNNs  MR1   Internet  AR    HA1

 Solution requirements:

  o Manage the Ingress Filtering. [Maybe difficult or too high requirement].

 Configuration imposed by:

  o "2 MRs happening to share the same wireless media for their
    mobile prefix".

 These case is maybe out of scope of Nemo.
[See my write below].

 I prefer this case which is Doublebed too:

             MR2

             p2
            <-_  |
        _  |-|_|-|  _____
       |_|-|     |-|     |
        _  |       |     |-|        _
            <-   |               |
             p1

       MNNs  MR1   Internet  AR    HA

 And in these case:

 Configuration used for:

  o Keep Connectivity Transparently

  o Router redundancy

  o Load-Balancing & Policy

    Outbound traffic:

     I think a kind of good solution is something like
     [draft-ietf-ipv6-router-selection-02.txt] as I write above.

    Inbound traffic:

     o The HA choose between the two MR CoA's.

     So the Prefix-BU should carry some preference for each CoA.

> could also help on the draft if you wish...

 Examples:

                        _____
        _   p1,p2   _  |     |
       |_|-|<-_  |-|_|-|     |-|        _
        _  |-|_|=|     |_____| |  _  |-|_| [Manage p1 & p2]
       |_|-|     |             |-|_|-|
                                     |

 and

             MR2             AR    HA2

             p2               _  |
            <-_  |         |-|_|-|  _
        _  |-|_|-|  _____  |     |-|_| [Manage p2 only]
       |_|-|     |-|     |-|
        _  |       |     |
       |_|-|  _  |-|_____|-|        _
           |-|_|-|         |  _  |-|_| [Manage p1 only]
            <-   |         |-|_|-|
             p1                  |

       MNNs  MR1   Internet  AR    HA1

  Theses cases are Tarzan [Single HA for CoAs of a same Mobile Network
 Prefix], and DoubleBed [Multiple prefixes advertised to the MNNs].

 In the first case:

  All work like for a simple Tarzan case, so you provide "Keep
 Connectivity Transparently" easily. No problem with the doublebed
 style. [No Ingress Filtering Rule to change]

 In the second case:

 [I hope I'll be clear as enough]
 [I know you [Pascal] understand this problem is just a reminder]

  What's wrong with "Keep Connectivity Transparently":

   The MRs announce two different Mobile Network Prefixes. So the
   MNNs have two global source addresses. The MNNs operates a Source
   Address Selection [RFC 3484, section 5]. And:

   Example of lost connection:

    A MNN select for a connection the source address prefixed by
    p1. And after a moment the connection to the HA1 is lost.
    [Godzilla again].

    Thus the connection is lost. [You can't send the p1 prefixed
    packets towards the HA2 because the Ingress Filtering]. But new
    connection are possible using the other source addresses.

  The problem is the same for a fixed network.

 Solutions:

   [Not a real solution]
  o Do not put different HAs who manage different Network Prefixes for a
    same Mobile Network in different domains.

  o [draft-ng-nemo-multihoming-issues-00,
     section 3.2.2. Using Alternate Mobile Router]

  o Modify the Ingress filtering rules.

 Thus maybe [sometime] make difference between one router with
multiple CoAs and multiple mobile router can be useful. But I have
write before you provide a good solution, and these examples are very
specific.

 Maybe another example more simple:

  In this case: [Tarzan]
                        _____
        _    p      _  |     |
       |_|-|<-_  |-|_|-|     |-|        _

    Load-Balancing for Inbound traffic "easy" to manage.

  In this case: [Tarzan too]

             MR2

             p
            <-_  |
        _  |-|_|-|  _____
       |_|-|     |-|     |
        _  |       |     |-|        _
            <-   |               |
             p

       MNNs  MR1   Internet  AR    HA

    Load-Balancing for Inbound traffic "hard" to manage.

 So the difference are maybe not so visible in the solution level, but
much more in the deployment / configuration level.

                     Best regard for the people who read the entire mail.

                                            -- Julien

---

From: William D Ivancic <[email-masked]>
Date: Thu, 22 May 2003 10:49:19 -0400

>        _    p      _  |     |

I think we have a semantics issue here.  Does "simultaneously more than one 
active connection" mean that both are available for use or does that mean 
both are being used - data flowing over both links.   I initially thought 
this meant both are available for use.  However, I my though process was 
biased by the current mobile router implementation I am using.  Regardless, 
I think we need to clarify what is meant by "simultaneous active connection".

Will

---

From: Thierry Ernst <[email-masked]>
Date: Fri, 23 May 2003 15:23:32 +0900

On Thu, 22 May 2003 10:49:19 -0400

> I think we need to clarify what is meant by "simultaneous active connection".

Hi,

Let me explain what I mean.

It doesn't mean the connection is being used, it just means available
from t=0, and thus that both connections can potentially be used at the
same time.

From the conversations I had, I thought this is the meaning behind
"active", so should be clear. If someone has a better word, please let
me know.

[May be I catch your point. If you mean a MN has 2 CoAs with 2 APs, but
only one interface, this is not a multihomed case. Multihoming means you
have more than one access that you can use at the same time].

Thierry

---

From: Ryuji Wakikawa<[email-masked]>
Date: Fri, 23 May 2003 20:04:37 +0900

Hello all,

See my comments below.

>        _    p      _  |     |

This is why I proposed draft-wakikawa-mip6-multiplecoa-00 on MIP.
And the draft can be applied to NEMO case, too.

> > while the MR is registered.

Pascal, question about Jetset.
I want to know whether Jetset case considers to place two HAs (which
serves same mobile network prefix/64(MNP)) in different IGP domains or not. 

If Yes, I think NEMO requires BGP level operations to route packets to
each HA.

For example, HA1 can announce MNP by BGP, but HA2 can not announce
same MNP by BGP. HA2 may allow to advertise MNP by IGP inside the IGP
domain. It is not acceptable to manage unaggregated prefix at BGP
level.

In this example, HA2 is useful only inside its IGP domain.  All packets
to the MNP will be routed to HA1 based on BGP routing.
In this case, HA2 may be treated as Correpondent Router of MR.

Sorry if this question was discussed already in ML.

regards,
ryuji