Subject: [nemo] draft-charbon-nemo-multihoming-evaluation-00.txt

From: Julien Charbon <[email-masked]>
Date: Tue, 1 Jul 2003 22:27:50 +0900

Hello all,

 We have written an Internet-Draft on the evaluation of Multi-homing
support by NEMO Basic solution. You can check this draft at this URL:

[http://www.sfc.wide.ad.jp/~julien/papers/draft-charbon-nemo-multihoming-evaluation-00.txt]

 The Cut-off Internet Draft for initial document (-00) submission is
over for the 57th IETF Meeting [23th of June]. But we want to open it
up for comments to facilitate further discussions.

                                           Thanks.

                                  -- Julien Charbon & Chan-Wah Ng

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 03 Jul 2003 15:31:50 +0200

Julien Charbon wrote:
> support by NEMO Basic solution.

Thanks for the draft, useful analysis.  Good to see that most
multi-homing aspects can be featured by base spec.

I have some remarks from the start.  The document defines "Policy" and
"Load Sharing" in a very loose way (at least when compared to the
specific specification of e.g. deriving a Home Address from the MNP).
So maybe a more concrete definition of Load Sharing is needed.

> Load-sharing: This is achieved when the traffic load is distributed 
> among different connections between the mobile network and the 
> Internet.

YEs, this is possible with the current base spec, I think.

> As long as the protocol uses all active connections simultaneously, 
> Load-sharing will have been deemed achieved.

What is "simultaneously" more exactly?  In the setting I use, both
access systems are up and active simultaneously.  If I switch the MR
very quickly between one access system to another then I can give the
impression of simultaneous connections.  Would this qualify as
"simultaneous"?

And I will not ask what is the "Policy" problem more exactly :-)

> 2.3 Solution behavior
> 
> o Against Load-Sharing:
> 
> 1.  Doesn't specify the simultaneous use of several bi-directional 
> tunnels but doesn't prevent it.

Ok.

> 2.  Doesn't specify the binding of multiple CoAs against the same MNP
>  but doesn't prevent it.

Ok.

> 3.  Doesn't provides a method to identify each CoA but doesn't 
> prevent it:

Ok.

> Here an explanation of one of possibility of this management:
> 
> As long as there is no specific field for a CoA ID, the solution have
>  to use a field present in current Prefix-BU definition.

Probably yes, in case that explicit, or explicit combined modes are
used.  And implicit mode?

> The only common field is each type of Prefix-BU - Implicit, Explicit 
> and Explicit combined - is the Home Address Option in the Destination
> Option Header [Section 6.3 Home Address Option] [13].

Yes, exactly, only the Home Address is common.

> Thus a NEMO implementation can create a Home Address for each egress 
> interface.  And when a CoA on an egress interface change, use in 
> Prefix-BU the corresponding Home Address in the Home Address Option. 
> An example to make clear this behavior:
> 
> HA Routing Table & Binding Cache before:
> 
> 
> +===============+=================+=========================+ | Home 
> Address  | Care-of Address | MN Prefix/Prefix Length | 
> +===============+=================+=========================+ | HoA-1
>  |  CoA-1          | MNP-1/Length-1          | |  HoA-2 |  CoA-2 | 
> MNP-1/Length-1          | 
> +===============+=================+=========================+

I think the base spec tries to say that the prefix is neither in the
RT nor in the BC, but in the Prefix Table.  No?

> Here HoA-x is the Home Address corresponding to the egress interface 
> x on which is assigned CoA-x.  Now the HA receives a Prefix-BU 
> because CoA-1 has changed to CoA-New.
> 
> The Prefix-BU:
> 
> 
> +===============+=================+=========================+ | Home 
> Address  | Care-of Address | MN Prefix/Prefix Length | 
> +===============+=================+=========================+ | HoA-1
>  |  CoA-New        | MNP-1/Length-1          | 
> +===============+=================+=========================+

Yes, if Prefix-BU (explicit or explicit-combined modes).  No, if
implicit mode; in implicit mode there is neither prefix nor prefix len
in the BU.

> And an example of creation of Home Address according to egress 
> interface can be:
> 
> Egress Interface 1 -> EUI-64-1 -> Home Address for this interface: 
> MNP:EUI-64-1
> 
> Egress Interface 2 -> EUI-64-2 -> Home Address for this interface: 
> MNP:EUI-64-2

Would the scheme work if EUI-64 addresses are not used?  For example,
in many configurations manual addresses are assigned to interfaces
(not with EUI-64).

By your analysis, and for my clarification, is this method somehow
suggesting that the basic solution as is does not support "load
sharing multi-homing" because the Home Address assigned of the egress
interface of the Mobile Router is not derived from MNP?  And following
this reasoning, is the proposed method trying to suggest that, for a
basic solution to support multi-homing load sharing, it must
absolutely necessarily have Home Addresses on the egress interface of
the MR derived from the MNP?

Should I also deduce that, if implicit mode is used, then there is not
even the smallest chance to have multi-homing load sharing?

I hope I didn't interpret the analysis wrong.

> Maybe the solution should specify this behavior because it is very 
> specific to NEMO.
> 
> o Against dynamic Load-sharing and Policy:
> 
> The solution didn't specify anything about a kind of preference/ 
> policy field, but maybe an NEMO implementation can use some part of 
> the reserved field in the MNP Option [Section 4.3. Mobile Network 
> Prefix Option] [1] or in a sub-option.

Sometimes I don't think there's need for more bits in the BU to
specify preferences.  On another hand, if there is indeed a need for
new bits to specify preferences then I think the same need for
preferences related to a CoA are valid for Mobile Hosts too, not only
Mobile Routers, no?  What do you think?

> o Multiple CoAs for the same MNP:
> 
> The proposed solution doesn't have to specify anything one this 
> subject, just to support it.  But a paragraph on this purpose can be 
> helpful for implementation's developers.

Yes, maybe somewhere it should say that it is possible to have several
Care-of Addresses for the same MNP.  But I think it is easily
understandable that this is possible since the tables pictured in the
draft-charbon clearly show some entries in some tables that associate
same MNP to different CoA's.

Alex
GBU

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 03 Jul 2003 15:31:50 +0200

Ok.

Ok.

Ok.

Alex
GBU

---

From: Julien Charbon <[email-masked]>
Date: Mon, 7 Jul 2003 23:03:58 +0900

Bonjour Alexandru, Hello all,

> multi-homing aspects can be featured by base spec.

 Thanks for appreciations, and yes, you work fine to permit the Basic
solution to not prevent Multihoming support; pretty good proposition I
think.

> impression of simultaneous connections.  Would this qualify as

 The "Simultaneous" term goal mark difference with Fault-Tolerance /
Redundancy benefits where just one interface is used at the same time.

 Take some concrete deployment cases to show this difference and
because multihoming in NEMO need several concretes scenarios [1]:

 o You have three interfaces on a MR in a car:

  For Egress Interfaces:

    Type               [Max Bandwidth]

  - One 802.11b Wi-Fi  [11Mb/s]
  - One GPRS           [160Kb/s]

  For Ingress Interface:

  - One 802.11b Wi-Fi  [11Mb/s]

 And you want to keep the connectivity with Internet with the best
interface according to possibilities provided in location where you
are, thus rules should be:

 1. Choose Wi-fi, if not
 2. Choose GPRS, if not
 3. Sorry.

 Thus for keeping connectivity you realize some vertical handover
between Wi-Fi and GPRS, and MIP6 being a solution to solve this
problem, NEMO have to do nothing more than the Basic Solution to
support this case.

   This case is an illustration of Fault-Tolerance benefit.

 o Now take a MR inside the bus Tokio - Kyoto:
 
  For Egress Interface:

  - Three GPRS interfaces. [480Kb/s][Together]
 
  For Ingress Interface:

  - One 802.11b Wi-Fi  [11Mb/s]

 Here the main interest is to provide a "correct" connection to all
people inside bus all the time, and because of this bus run forward
country side, only GPRS is usable during all this trip. Thus you
multiply the GPRS connections to provide a better bandwidth.
 So if you have ten people which use the Internet Connection a the
same time, theoretically, each person can get a 6kB/s connection which
is not so bad.
 Here NEMO have to permit several binding for the same prefix to the
same CoAs. This part is currently OK.

 And now because the bus make a long way, it have to change of GPRS
provider - for example from NTT East to NTT West - to keep
connectivity and thus MR get new CoAs and update its bindings. Here
the NEMO Basic solution have to provide a mechanism to identify each
CoA - as described in the draft-charbon-multihoming-evaluation-00.

   This is an example of Load-sharing because you /use/ simultaneously
   several egress interfaces.

 o Conclusion:
 
 So why there is no formal definition for Load-sharing, because /use/
is not an accurate term. Anyway if I take inspiration from Cisco's
definitions [2][3]:

 Load-sharing: [in NEMO]
 
  Load-sharing is concept that allow some Nodes [MNNs, MRs, HAs -
  depending on the case] to distribute the outgoing and incoming
  traffic among multiple paths.

 But I do'nt know if it is much more sharp.

 And sorry if my remark seems like a teacher ones. :)

[1]

 http://www1.ietf.org/mail-archive/working-groups/nemo/current/msg00154.html
 [The last comment from Vijay]

 And you can find more deployment scenarios in:
 [http://www.ietf.org/internet-drafts/draft-ng-nemo-multihoming-issues-01.txt]
 [Section 3. Deployment Scenarios]

[2] http://www.cisco.com/warp/public/459/40.html#intro
[3] http://www.cisco.com/warp/public/105/46.html#intro

> And I will not ask what is the "Policy" problem more exactly :-)

 Yes, you are right, and here I can bring more precisions:

 o Load-sharing:

   [None accurate definition] ... and mechanisms which make the
  distribution need only informations from the network traffic
  itself. For example:

    o Per-packet distribution.
    o Per-connection distribution.
    o Split TCP and UDP traffic.
    o Load-balancing based network load statistics.

 o Policy:

   [Same as Load-sharing] ... but mechanisms which make the policy
  distribution need informations which are not provided by the network
  traffic itself. Thus theses informations have to be transported by
  NEMO protocol in addition of current protocol information. For
  example, distribution depending on:

    o Cost of connection.
    o Class of user registration.
    o Age of captain.

 IMHO it is the main difference between Load-sharing and Policy benefit.

> > 3.  Doesn't provides a method to identify each CoA but doesn't 

 Fine. ;)

> Probably yes, in case that explicit, or explicit combined modes are

 Well, read far below [A]. But the important point for this mechanism
is the association between HoA and Egress-Interface to update the good
CoA not association between HoA and MNP in Prefix-BU.

> > | Home Address  | Care-of Address | MN Prefix/Prefix Length | 
> > | HoA-1         |  CoA-1          | MNP-1/Length-1          |
> > | HoA-2         |  CoA-2          | MNP-1/Length-1          | 

 Hum, we took this example:

,----[ draft-ietf-nemo-basic-support-00.txt ]
| 6.5. Forwarding Packets
| 
|   [...]
| 
|  1. The Home Agent maintains a route to the Mobile Network Prefix
|     with the next hop set to the Mobile Router's Home Address.  When
|     the Home Agent tries to forward the packet to the next hop, it
|     finds a binding cache entry for the home address.  Then the Home
|     Agent extracts the Mobile Router's Care-of address and tunnels
|     the packet to the Care-of address.
`----

 So above it is a logical view, the exploded corresponding view is:

     Routing Table
   +=========================+===============+
   | MN Prefix/Prefix Length | Next Hop      |
   +=========================+===============+
   | MN-Prefix-1/Length-1    |  HoA-1        |
   | MN-Prefix-1/Length-1    |  HoA-2        |
   +=========================+===============+

     Binding Cache
   +===============+=================+
   | Home Address  | Care-of Address |
   +===============+=================+
   |  HoA-1        |  CoA-1          |
   |  HoA-2        |  CoA-2          |
   +===============+=================+

 But maybe it's too confuse. I will think about this representation.

> > | Home Address  | Care-of Address | MN Prefix/Prefix Length | 
> > | HoA-1         |  CoA-New        | MNP-1/Length-1          | 

 Yes, but read below [A] and think about association between HoA and
Egress-Interface first.

> in many configurations manual addresses are assigned to interfaces

 Yes, that's why is just an example. :)

 Anyway from each kind of link which support all features of Ipv6, we
can create a EUI-64 [3], and if the administrator of this MR want to
support Load-sharing, the fact that he have to configure his MR
specially for this benefit is not so strange. It's the same in many
Load-sharing configurations [4][5]. If you want automatic or
easy-to-install Load-sharing, yes here is a problem but I prefer paid
the administrator more [because I'm administrator too ;)].

[3] http://www.zvon.org/tmRFC/RFC3513/Output/chapter6.html
[4] http://www.cisco.com/warp/public/459/40.html#2
[5] http://www.cisco.com/warp/public/459/40.html#2a

> the MR derived from the MNP?

 Nope: ... Home Addresses of the MR derived from Egress-Interface.
                                                 ^      ^       ^
 Read just below [A].

 And it's just an example because writing:

,----
|  3.  Doesn't provides a method to identify each CoA but doesn't 
|  prevent it:
`----

 is not enough for a validation. The main goal of this example is to
prove this affirmation. But it carry some other problems like:

 o If you had a interface to your MR, you have to declare an
   additional HoA to the administrator of the corresponding HA(s). It
   can be boring. [Thanks to Ryuji for this comment]

 o Break the assumption "One HoA <-> One Mobile Network with One
   Mobile Network" which maybe some people have in mind. But I do'nt
   see all consequences of that.

 But with the current NEMO Basic Solution, it's the only example that
I see.

> even the smallest chance to have multi-homing load sharing?

 [A] I'm not agree with this point because in my understanding in each
mode - Implicit, Explicit, Explicit combined - the association between
HoA and an Egress Interface is keep. Thus the NEMO implementation is
always able to found the CoA to update according to a HoA inside a
Prefix-BU.

 Prof by illustration:

 o Pre-requirement:

  There is a mechanisms which provide this bijective association:

    HoA-x <-> Egress-Interface-x

  For example: [already-know]

   Egress-Interface-x <-> EUI-64-x <-> Home Address associated: 
                                        MNP:EUI-64-x

 Let's start:

 o Routing Table & Binding cache before:

     Routing Table
   +=========================+===============+
   | MN Prefix/Prefix Length | Next Hop      |
   +=========================+===============+
   | MN-Prefix-1/Length-1    |  HoA-1        |
   | MN-Prefix-1/Length-1    |  HoA-2        |
   +=========================+===============+

     Binding Cache
   +===============+=================+
   | Home Address  | Care-of Address |
   +===============+=================+
   |  HoA-1        |  CoA-1          |
   |  HoA-2        |  CoA-2          |
   +===============+=================+

 o Sending Prefix-BU

 Implicit:

     The Prefix-BU:
   +===============+=================+
   | Home Address  | Care-of Address |
   +===============+=================+
   |  HoA-1        |  CoA-New        |
   +===============+=================+

 Explicit:

   +===============+=================+=========================+
   | Home Address  | Care-of Address | MN Prefix/Prefix Length | 
   +===============+=================+=========================+ 
   | HoA-1         |  CoA-New        | MNP-1/Length-1          | 
   +===============+=================+=========================+
  
 Explicit combined:

   +===============+=================+===============+
   | Home Address  | Care-of Address | Prefix Length | 
   +===============+=================+===============+ 
   | HoA-1         |  CoA-New        | Length-1      | 
   +===============+=================+===============+

 o Binding cache after, in any mode:

     Binding Cache
   +===============+=================+
   | Home Address  | Care-of Address |
   +===============+=================+
   |  HoA-1        |  CoA-New        |
   |  HoA-2        |  CoA-2          |
   +===============+=================+

 Thus the good CoA has been updated because identified by appropriate
HoA.

> I hope I didn't interpret the analysis wrong.

 I hope I answer to your question too.

> Mobile Routers, no?  What do you think?

 Yes, you are right, this proposition is a good one, I will seek for a
kind of Policy Information sub-option in MIP6 WG.

> same MNP to different CoA's.

 Yes this part is clear in the draft, It's my fault I would say:

 o Multiple CoAs for the same MNP & CoA Identification:

  The CoA Identification is a little bit more difficult to understand,
with just the current Basic draft, IMHO.

 And I want to say that this idea to associate Egress Interface with
HoA come firstly from Pascal Thubert. Thus thanks to him for this
interesting idea.

                  Thanks you Alexandru for theses 
                  constructive comments.

                            Best regards.

                                   -- Julien

---

From: Julien Charbon <[email-masked]>
Date: Mon, 7 Jul 2003 23:03:58 +0900

For Egress Interfaces:

    Type               [Max Bandwidth]

  For Ingress Interface:

 1. Choose Wi-fi, if not
 2. Choose GPRS, if not
 3. Sorry.

 
  For Egress Interface:

  For Ingress Interface:

 o Conclusion:

 Load-sharing: [in NEMO]

[1]

 o Load-sharing:

 o Policy:

    o Cost of connection.

 Fine. ;)

     Routing Table

     Binding Cache

,----

 Prof by illustration:

 o Pre-requirement:

 Let's start:

     Routing Table

     Binding Cache

 o Sending Prefix-BU

 Implicit:

     The Prefix-BU:

 Explicit:

 Explicit combined:

     Binding Cache

                            Best regards.

                                   -- Julien

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 11 Jul 2003 14:36:19 -0700

> multiply the GPRS connections to provide a better bandwidth.

I guess I found the example I was looking for in my previous
mail. :) I hadnt read this mail then. sorry.

I have a question here. what do you we need to standardise
here? how the Mobile Router distributes the traffic between
the three egress interface is implementation dependent.
ofcourse you still need the support for registering the same
MNP with multiple CoAs. but there is nothing to standardise
for the load sharing itself. it is internal to the Mobile
Router.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 11 Jul 2003 14:36:19 -0700

Vijay

---

From: Julien Charbon <[email-masked]>
Date: Wed, 16 Jul 2003 15:50:40 +0900

Hi Vijay, Hi all,

On Fri, 11 Jul 2003 14:36:19 -0700

> for the load sharing itself. it is internal to the Mobile

 Yes your right, the algorithm of distribution is implement specific
[currently all solution I have found to support Load-Shring are always
implement specific]. And thus there is nothing to specify in NEMO for
making Load-Sharing itself but:

 o To support it you need CoAs identification:

   [1, Section 2.3 Solution behaviors] or [2]
   
 o and If you want _dynamic_ Load-Sharing:

   You need to put a preference option for each CoA in the BU.
   [If think this point should discuss at Vienna today]

 In conclusion, NEMO think about howto support the Load-Sharing [or
howto don't prevent Load-Sharing] not howto make Load-Sharing. I will
update the drat to be clearer. Thanks.

                                          -- Julien

[1] http://www.sfc.wide.ad.jp/~julien/papers/draft-charbon-nemo-multihoming-evaluation-00.txt
[2] http://www.ietf.org/internet-drafts/draft-wakikawa-mobileip-multiplecoa-01.txt

---

From: Julien Charbon <[email-masked]>
Date: Wed, 16 Jul 2003 15:50:40 +0900

Hi Vijay, Hi all,

   

                                          -- Julien

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 16 Jul 2003 11:22:53 -0700

>    [1, Section 2.3 Solution behaviors] or [2]

I support standardizing draft-wakikawa-mobileip-multiplecoa-01.txt.

>    [If think this point should discuss at Vienna today]

for this how about defining a new mobilily option called
the Care-of Address Preference option?

and I prefer standardizing this option through a separate
specification (not in the NEMO basic support).

> update the drat to be clearer. Thanks.

okay.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 16 Jul 2003 11:22:53 -0700

okay.

Vijay