Subject: [Architecture-discuss] Mobility and multi-homing

From: Leslie Daigle <[email-masked]>
Date: Wed, 26 Oct 2005 17:49:18 -0400

[Tap tap tap -- "is this thing on?" ;-)  I'm forwarding Pekka
Nikander's suggested topic-starters, one at a time, to see if
we can get some "discuss" going, about "architecture".  -- LLD]

[Pekka wrote:]
1. Mobility and multi-homing

The IETF currently hosts a bunch of working groups focusing on  various 
aspects
of mobility and multi homing.  At the Internet Area,  there are five WGs 
and a
couple of almost-WGs charted for standards  track work: MIP4, MIP6, 
NEMO, SHIM6,
MONAMI6, and NETLMM.  In  addition to those, there are experimental 
approaches,
such as HIP,  and optimisations, such as MIPSHOP and MOBOPTS.  Outside 
of the
Internet area, MOBIKE is focusing on mobility and multi-homing for 
IPsec and
SCTP and DCCP folks have had their mobility and multi- homing 
discussions.  The
wider research community is full of various  proposals, including overlay
approaches (such as i3) and underlay  approaches (such as using MPLS 
tunnels to
implement host routes).

Given this multitude of work and even partially overlapping standards  track
solutions, what would be the right way or right ways forward?   Could we 
design
a way towards converging solutions?  How do we ensure  robustness of 
solutions
if we attempt to deploy multiple solutions at  the same time; for 
example, SHIM6
+ Mobile IPv6 + SHIM6?  How do more  unified solutions, like using CGA-based
mobility with SHIM6 contrast  to this?  What about using HIP with 
routable IP
addresses instead of  Host Identity Tags (HITs) as Upper Layer Identifiers?
Going a little  bit furthermore, what are the architectural impacts of doing
mobility  and multi-homing at the IP layer vs. other layers?

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 27 Oct 2005 17:36:22 +0200

[Why forwarding only Pekka's emails?  There are plenty
 discussions happening in the mobility related working groups often
 founded by "don't  do it this way because its not architecturally
 sound", or "this other thing _is_ architecturally sound".

 Following is some doubts I have, and my architecture knowledge is a
 beginner's.]

Leslie Daigle wrote:
> Nikander's suggested topic-starters, one at a time, to see if we can
> get some "discuss" going, about "architecture".  -- LLD]
> 
> [Pekka wrote:] 1. Mobility and multi-homing
> 
> The IETF currently hosts a bunch of working groups focusing on
> various aspects of mobility and multi homing.  At the Internet Area,
> there are five WGs and a couple of almost-WGs charted for standards
> track work: MIP4, MIP6, NEMO, SHIM6, MONAMI6, and NETLMM.

NETLMM and dumb network.

In netlmm there's a proposal to manage host mobility entirely by the
network, in that a small network changes its state dynamically such as
to update paths towards a moving host, which keeps its address stable,
doesn't change it.

Or, the network was supposed to be dumb.

But, architecture is applied differently in different contexts, too.

So, how would an Internet architect critique this aspect?

Alex

---

From: David Barak <[email-masked]>
Date: Fri, 28 Oct 2005 03:54:14 -0700 (PDT)

--- Alexandru Petrescu
> to update paths towards a moving host, which keeps

This has worked moderately well for the GSM/CDMA
types, but the fundamental difficulty with having
hosts update a network (instead of vice-versa) is that
they have to do that whether or not they're mobile. 
With c.phones, it makes sense, because by definition
they're always mobile, but for other types of
less-mobile devices, that may not be the most
efficient use of bandwidth.

> Or, the network was supposed to be dumb.

I've always understood this to mean that the *CORE*
network was dumb - that decisions are made as close to
the host as possible, but not necessarily on the host
itself: routing is a network function which the host
is dimly aware of.  With discussions of Shim6, the
routing intelligence seems to be moving to the host
(eeek!) but there is a significant amount of justified
concern about whether that will work or scale.

David Barak
Need Geek Rock?  Try The Franchise: 
http://www.listentothefranchise.com

		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

---

From: Jari Arkko <[email-masked]>
Date: Fri, 28 Oct 2005 18:22:56 +0300

> we can get some "discuss" going, about "architecture".  -- LLD]

First, I'd like to thank you Leslia and Pekka for setting this
list and discussion up.  I believe this can be very useful.
We do talk too little of the architecture in the IETF.

> 1. Mobility and multi-homing

Actually, I have a bit different view into this than seems
to be the focus of the discussion so far. What I view as
architecture isn't necessarily agreement on a single
solution, nor is it the simplicity of solutions. What seems
more important is that we have broken down the problem
into separable pieces. Solutions for individual pieces
can then proceed in their own pace and style. It seems
evident to me that we have a case of "market will decide"
here for some components, and I think its fine - but don't
take this as opinion that markets work in all cases. Also,
"we have options and we will let the market choose" shouldn't
be the same as "we aren't doing anything to guide the
solutions".

Some examples of the separable pieces include

- Network attachment functions that satisfy
  needs of mobile hosts. There's a lot of ongoing
  work in this space relating to either functional
  or performance improvements, e.g., DNA, optimized
  v6 setups (optimistic DAD), access security for
  roaming (EAP), and so on.

- The actual multiaddressing function, e.g., Mobile
  IPv6 + extensions, HIP + extensions, SHIM+SEND+
  friends, application layer.

- Triggering mechanisms that assist getting
  information about conditions, better attachment
  points, etc.

- Interfaces to transport layer to inform them
  about switching to a new path and/or getting
  information from them about current reachability.

- Local "services", such as ability to offer forwarding
  agents via DHCP, maybe ability to pull old packets
  from previous router, etc.

Re: deploy multiple solutions at  the same time. Here
I think we have a case for some more short term work.
We are starting to have so many extensions to the
"waist" of IP that I'm not fully convinced anyone knows
which order all those processing steps should be taken.

Re: what would be the right way or right ways forward?
Looking at this field, I think we've learned a few lessons
over the years. One of the issues that we need to pay
more attention to include deployment (e.g. ability to
do something without having to (a) set up servers in
the network and (b) set up subscriptions of users for
those servers). Another issue is different environments.
Mechanisms that are more likely to be deployed are
likely to work despite IP versions, NATs, etc.

Re: functions beyond multiaddress suggested by Noel.
I don't think we should work on server pooling; this
seems to work well now. But another issue that may
deserve more attention is denial-of-service protection.

--Jari