[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: how mobile do we want to be
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).
"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.
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
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
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
You can also move within a campus/administrative domain with no L3
handoff at all, assuming that there are L2 mechanisms to support this.
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
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.
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.
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.