Re: how mobile do we want to be

[Thierry Ernst <ernst@sfc.wide.ad.jp>]

I'm not sure that Margaret definitions are right. See below.

On Mon, 14 Mar 2005 14:43:31 -0500
Margaret Wasserman <margaret@thingmagic.com> wrote: 
> Personally, I consider the subjects of mobility and renumbering to 
> both be somewhat tangential to the subject of multihoming. 
> Certainly, they are all related in some ways, but they are not the 
> same problem and may not have the same solution.

There are diffrent topics when we do think about the motivations /
needs, but that may be similar when thinking about mobility. Mobility
solutions could serve as a means to renumber/multihome and multihoming
solutions could serve as a means to solve mobility ... So, it's not
orthogonal as it depends from which perspective you look at the picture.

> To my way of thinking, the following definitions apply:
> 
> Mobility:  Changing a node's point of attachment to the Internet 
> without losing L3 sessions. Depending on the mechanism employed, 
> mobility may or may not involve changing the topological location of 
> the node within the Internet (i.e. the IP address prefix of the node).

"IP-layer mobility" means changing the L3 point of attachment and
"mobility support" is the abilitiy to do this without losing the
sessions. Such mobility necessarily means that the topological location
of the node would be changed (if not, I don't understand the scenario),
and, in such a case, that the IP address would be changed (an interface
must obtain an address on the link it is attached to, right ?). However,
depending on the solution to support this, upper layers may not see the
change of IP address (e.g. mobility).

> There are two subtypes of mobility:  mobility within a campus (under 
> a single administrative domain) and mobility across the Internet. 

This is called Macro/Global mobility and Micro/Local mobility (see RFC
3753).

> Mobility within a campus is most often handled by layer 2 protocols, 
> such as dynamic VLANs, that require no change to the node's 
> topological location (IP prefixes or addresses).  Mobility across the 
> Internet does require some change to the topological information, at 
> least at some level, and is handled by MIP (v4 or v6).

You can move into a campus and do a L3 handoff between 2 subnets (i.e.
L3). If the service provider is different, this is "global mobility", if
it's the same provider (2 WLAN, with no L2-bridging) this is "local
mobility".

L3 mobility can be handled my MIP4/6 if it's a host (or using other
proprietary management protocols, e.g. LIN6), or by NEMO Basic Support
if it's a router, or other standardized/not standardized mechanisms.
 
> Renumbering:  Changing a node's topological location within the 
> Internet.  A node that previously had one topological location (IP 
> address prefix) is reconfigured to have a new topological location.

Renumbering to me means adversiting a new prefix, with the result that
the node would have a new IP address. So, I wouldn't say "changing the
topological location" as the word "changing" bring a sense of "proactive
behavior" of the node, whereas it is indeed "reactive behavior".

During the process of renumbering, the nodes may be "multihomed" during
a transient period of time.

> Multihoming:  Allowing a node that has more than one topological 
> location within     the Internet to use its redundant paths for 
> efficient or reliable Internet connectivity. Note that multihoming 
> _does not_ involve changing the node's point(s) of attachment to the 
> Internet and/or changing the node's topological locations within the 
> Internet; the node has more than one topological location on an 
> ongoing basis.

Agree on this.
 
> Now, clearly the above definitions are related, particularly if you 
> view renumbering and mobility as the process of adding a new 
> topological location and removing an old one (perhaps very quickly in 
> some situations).  However, there is a very important difference:
> 
> *** In shim6, two nodes can exchange their full set of topological 
> locations at the beginning of the session and they are not expected 
> to change during the lifetime of the session. ***
> 
> The shim6 mechanism might be a useful tool to soften the blow of 
> renumbering.  A new address prefix (topological location) could be 
> added, and hosts could be multihomed for a while during which 
> longer-lived connections and associations could be migrated to the 
> new topological location (manually, or using some other solution). 
> Then, the old topological information could be deprecated and removed 
> on a schedule that allows the completion of shorter lived 
> connections.  So, shim6 is not a renumbering solution, but it might 
> be usefully applied to the problem of renumbering.
> 
> It is not easy to see how shim6 (as defined) could apply directly to 
> mobility, as described above.  Using shim6 as a mobility mechanism 
> would (at minimum) involve adding new topological information in 
> mid-session and might involve adding new topological information at a 
> time when the node is unreachable using the old topological 
> information.  This creates a universe of protocol issues and security 
> concerns that are not present in the simpler multihoming case, and I 
> would prefer that we don't try to solve this problem right now as 
> part of the shim6 solution.

I agree that it's not straight forward to see shim6 applying for
mobility, but I think that what Avri was trying to say is that it would
be a shame if such an important change wouldn't at the same time bring
an answer to the mobility issue (particularly given the fact that an
important proportion of nodes would be mobile).

So, playing an evil game, mobility-concerned people may wonder what is
the benefit of such an architectural changes if the mobility problem
remain unchanged ? (does it worth the effort ?).

Thierry.


> Personally, I respect all of the work that has gone into the Mobile 
> IP solutions, and I think that we would be underestimating the 
> difficulty and subtlety of that problem space if we assume that it 
> can be solved by a simple variant of the shim6 approach.  I do think 
> it is important for shim6 to co-exist peacefully with MIPv4 and v6, 
> and I think that is sufficient, at least for our first step.