-----Original Message-----
From: owner-shim6@psg.com [mailto:owner-shim6@psg.com] On
Behalf Of Thierry Ernst
Sent: Wednesday, March 16, 2005 11:46 PM
To: shim6@psg.com
Subject: Re: how mobile do we want to be
I will take it further. Margaret is correct and I will be stronger
and replace the word tangential with orthogonal. Mobility and
Multihoming are completely two separate technology efforts and
functions related to building a multihome archictecture, a network
operations model for an enterprise, or a shim solution within an IP
stack.
The motiviations behind mobility and multihoming are distinct
(i.e. the
intention is orthogonal) but the solutions MAY be similar / could
apply to one another / could be the same (i.e. the result may not be
orthogonal).
Another example is Mobile IPv6 et al (multiple working groups
on mobility) is completely orthogonal to MANETs problem of
routing or
autoconfiguratin on the link.
In my opinion I have seen some views expressed to try to integrate
Mobility issues-problems-opportunities into the work of multihoming
I'm not sure it's the intention. I would better take this as
a "concern"
(deploying an architectural change which doesn't solve the mobility
problem is at best a loss of opportunity and at worse a lack of
planning) . I personaly have no intention to integrate mobility issues
or problems into the Shim6 WG as long as the output are **experimental
RFCs**. However, it may be useful if a twin IRTF is set up to
investigate the relation between mobility and multihoming using a shim
(or compatible with a shim) so that, in the end, we can output - in a
few years and in other WGs - RFCs in the standard track category which
bring an answer to both mobility and multihoming.
and I believe to circumvent the IETF direction in the respective
mobility WGs, as end-run as opposed to going to those IETF WGs and
defending their need technically with that IETF center of expertise.
The existing mobiliy WGs are not chartered to discuss this.
Thierry.
/jim
-----Original Message-----
From: owner-shim6@psg.com [mailto:owner-shim6@psg.com] On
Behalf Of Thierry Ernst
Sent: Wednesday, March 16, 2005 10:35 PM
To: shim6@psg.com
Subject: Re: how mobile do we want to be
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.