Re: how mobile do we want to be

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

Margaret Wasserman <margaret@thingmagic.com> wrote:
> Hi Thierry,
> 
> At 12:35 PM +0900 3/17/05, Thierry Ernst wrote:
> >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.
> 
> I did not say that the definitions of mobility, renumbering and 
> multihoming are orthogonal (i.e. completely independent).  I said 
> that they are tangential (somewhat related).

Oops, you did, actually. I think I was confused with other mails, I
think someone mentioned "orthogonal". So, yes, then I agree with the
term tangential.

> >"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).
> 
> I am not sure that the world-at-large has accepted your definition of 
> the term "mobility" to apply only to those cases when a node moves 
> from one IP subnet to another.  In a large bridged/VLAN network, a 
> host can move about freely (even between buildings) without changing 
> it's location in the L3 topology, through the use of dynamic VLANs or 
> other L2 mobility solutions.  The node's IP address doesn't change, 
> and no L3 mobility solution is needed to reach it.  In fact, the L3 
> protocols are unaware that the node has moved.

Agree, this is L2 mobility, right ? not IP layer mobility.

The scenario you depicted is exactly the one that applies to our campus
(L2 bridging)  (though we can also do a L3 handoff as each lab has it's
own WLAN in addition to the campus WLAN).

> Another case where mobility is handled at L2 (at least from the 
> perspective of the top-level IP layer) is 3GPP.  The mobility of the 
> node is handled by the 3GPP network, not by an IP-layer mobility 
> solution.

Perfectly agree. I think your initial definition was not clear as you
just mentioned "mobility" whereas you should have said either "IP-layer
mobility" or "link-layer 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).
> 
> Okay.
> 
> >>  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".
> 
> You can also move within a campus/administrative domain with no L3 
> handoff at all, assuming that there are L2 mechanisms to support this.

I think we didn't contradict eachother. It's just the term we use. I
think the simply saying "mobility" is not clear enough, nor saying
"campus mobility" as different people may have a different
interpretation of what that is. 

(I guess the chair may want to shut this discussion as we diverge from
mobility, but we don't threw darts away yet, so it may not be needed
;-)

> >>  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.
> >
> >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).
> 
> I believe that I understand Avri's position.  I just don't happen to 
> agree with it.
> 
> Part of my disagreement lies in the assumption that an important 
> proportion of the nodes will be mobile, where "mobile" is defined as 
> changing their location in the L3 topology while retaining active L4 
> sessions.  While I agree that an important number of nodes will move 
> about (laptops, cell phones, etc.), I do not expect that a 
> particularly large portion of the nodes will be mobile at L3 
> (changing their location in the L3 topology) while expecting (or even 
> wanting) L4 sessions to remain active.

I highly oppose to that statement. To me, either we continue to use the
Internet the way we do know and yes, I can agree with you, or either we
think about the new services, usages, and in this case, I tremendous
proportion of the Internet will be mobile:

- 6 billions people owning IPv6 mobile phones
- 700 millions vehicles with IPv6 embedded network 
- billions and billions of IPv6 walkmans/digital camera/PDAs/etc
- trillions of in-house equipments that people will bring with them when
they go for vacation, shopping, etc

The edge will be mostly mobile because the rationale is that all
electronic devices may be either carried by the people sometimes, or
embedded in moving networks.

I think we would better develop protocols which would allow this.

> We already have solutions for those nodes or networks that do need 
> true mobility, as defined in the previous paragraph: MIP* & NEMO.
> 
> What we don't have is a scalable multi-homing solution.

Right, but with the assumption that most nodes will at the same time be
multihomed AND mobile. It the solutions for multihoming works for
mobility, very fine, we can take a break. 

But having a multihomed solution which doesn't allow mobility is
clearly bad engineering (at best).

On the other side, developping mobility solutions which doesn't allow
multihoming is also bad engineering, and this is why I do work on
enable all kind of multihoming scenarios using NEMO Basic Support and
Mobile IPv6.

> >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 ?).
> 
> The benefit is that it solves the scalable multihoming problem, and 
> some of us consider that an important problem to solve.

I agree it's an important problem to solve, but I do insist that if it
prevent multihomed sites to be mobile, then it's bad engineering.

Thierry