Subject: Re: [nemo] Multiple Egress vs multihoming

From: Julien Charbon <[email-masked]>
Date: Thu, 1 May 2003 18:05:05 +0900

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: Thierry Ernst <[email-masked]>
Date: Thu, 1 May 2003 17:57:37 +0900

Guys, just a clarification note.

> Nemo Basic Support, and that could exist a kind of modularity to

If R02 was saying there MUST be only one tunnel, it would say it
explictly. Probably something like "The solution MUST set up ONE and
ONLY ONE bi-directional tunnel". But we never came to this conclusion.
The requirement is sufficienly loose so that it cannot be exluded nor
enforced.

Thierry

-- 
Thierry Ernst, WIDE at Keio University, Japan