Subject: [arch-d] Mobility and multi-homing: Summary and going forward

From: Pekka Nikander <[email-masked]>
Date: Thu, 10 Nov 2005 09:26:55 -0800

This is my biased summary of the Mobility and Multi-homing discussion  
so far, with some suggestions of moving forward in the end.

It looks like that this particular threat diverged quite fast from  
its original topic, to other useful -- but different -- topics.   I  
am ignoring the other topics here.

I was able to find five distinct subtopics that seemed to be relevant:

   1. Noel stated that if the architecture isn't rich enough,
      we end up with feature-cancer.  Jari stated that mobility
      does not involve just a single solution but a set of separable
      pieces.

   2. From an architectural point of view, it is clear that supporting
      mobility and multi-homing must take place above the traditional
      "deliver packet from this interface to that interface" IP service.
      Noel stated that the best suggestion so far has been the NSRG
      concept of designing a new name space, somewhere above the
      traditional IP service.

   3. According to Noel, in a perfect world, a shim approach might
      be better, but given the current state, bundling with new
      transports may be easier.

   4. There are different operational environments, and we need to
      pay attention to deployment in these different environments.

   5. The topic can be expanded to consider also other aspects of
      mobility and multi-homing, such as service mobility within a
      server farm, or denial-of-service protection.

In the following, I ignore topics #4 and #5, not because they are not  
important but because I consider #4 orthogonal to the other  
discussion and #5 as a pure research issue for the time being, with  
little direct engineering consequences.  However, I do think that as  
time passes more generic concepts (like service mobility) will become  
more important and we need to keep them in mind in this discussion.

The problem: Lack of richness in the architecture, or missing name  
spaces
======================================================================== 
=

Noel noted that when the underlying architecture isn't rich enough,  
in namespaces, mechanisms, etc, the approaches to add functionality  
that would require them will not be nice (ugly "bags on the side").   
In my opinion, another way of stating the same (in this particular  
case) is that if we are missing a layer of indirection, any attempt  
to add the functionality without adding a name space will end up  
using one of the existing name spaces for multiple semantically  
different purposes, make the solutions, in some sense, ugly.

There are a number of questions that need to be answered in order to  
understand what kind of name space should be added to the  
architecture.  Hence, my conclusion here is that we should focus a  
little bit more on understanding what are the right questions.  At  
the IAB list, some people recently asked whether we have a good set  
of mobility requirements, and the answer is apparently "no".

Related to this, Jari made the comment that to him it seems more  
important to break down the problem into separable pieces.  While I  
sympathetic and certainly can see how certain pieces of the problem  
(like attachment detection or path exploration) can and should be  
seen as separate issues, I am not sure if the core problem (need for  
a new layer of indirection) can be split into subpieces.

The solution and its nature: a new name space, shim or not
==========================================================

It seems to be clear that mobility and multi-homing support has to  
happen above the "deliver a packet from this interface to that  
interface" layer, or what has traditionally been considered as the  
core of the IP.  At this point we need to be careful, as today's IP  
has package that is not really that much interface-to-interface in  
nature any more; IPsec is a prime example, in my opinion.

Noel stated his opinion that the NSRG concept of designing a new  
namespace, and deploying it one application and/or transport layer at  
a time, was the best one.  Personally, I am a little worried about  
this approach, as it seems to require changing all transports and  
applications.   Noel continued to state that in a perfect world he  
would he'd go for a shim, but in real world he'd be more inclined to  
bundle it with transports.

I have a different opinion here.  I see two concrete possibilities of  
going forward in a shim-like way.  One is HIP, perhaps first  
deploying HIP with IP addresses as ULIDs just in order to make early  
deployment easier, and then later on proceeding to use HITs as  
ULIDs.  The danger of such two-step approach is, of course, that we  
may fail to do the second step, and that would be bad.

The other alternative transition mechanism would be to start using  
CGA, or something like CGA, to associate a public key or other  
similar identifiers with ULID IPv6 addresses.  From a semantic point  
of view the ULID would stand as a proxy for the public key, the  
public key (or other identifier) being the real end-point  
identifier.  Under this layer we could then run shim6 with mobility  
extensions, HIP, or some hybrid of them.

In any case, the goal of any transition mechanism like this would be  
to gradually move into an architecture that does have a new name  
space and a new layer of indirection.

--Pekka Nikander

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

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 14 Nov 2005 23:17:00 -0500

> >> So if we are to speak of needing a new layer above IP but before
> >> transport processing then that will be a new virtual layer.
> >> 
> >> Also realize that what we do not want to do is create a 
> bottlneck making
> >> the middle virtual layers fat and slow either.
> 
>     In the spirit of modularity, you could implement the shim 
> in one of the
>     following OS process models (ignore kernel versus user 
> space for now):
> 
>     (1) As a library called from the TCP/UDP process in both 
> ingress and egress
>         directions.

I think work will need to be done closer to IP thus just tcp/udp library
will choke the transport for threading (trying to ignore kernel vs user
space).

> 
>     (2) As a library called from the IP process in both 
> ingress and egress
>        directions.

As much as I don't like the steve deering mid-life-bulge of the hour
glass model I think this is most optimal.  We could just write it in
assembly instruction and go back to a real programming language :--).
But open to more of this kind of good talk.

> 
>     (3) As a separte process where on egress from TCP/UDP and 
> ingress from IP,
>         would use an IPC mechanism. As well as the separate 
> shim process being
>         an egress to both TCP/UDP and IP (for each packet direction).

Ouch agree with Dino below.

> 
>     (4) A library which is shared by both the TCP/UDP and IP 
> processes.

This will create major lock contention and/or additional data structures
thus adding more space for a virtual layer and cannot see the time
advantage for execution except in the most optimal case after set up.

> 
>     It would be real nice if (3) could be avoided. And would 
> be nice if
>     the shim6 working group would decide if this is a 
> transport function or
>     an network layer function so (4) could be avoided.

I agree this is work to be hard core nailed down in shim6 and with other
comments above.

> 
>     So what do people think, can this be implemented as (1) or (2)?

Today I like 2.

/jim
> Dino

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 14 Nov 2005 23:41:59 -0500

Correction below.  I don't want to contribute to the mid-life-bulge of
the hour glass. I actually believe totally in Steve's explanation of the
hour glass model and affect.  But I see no choice today.
sorry,
/jim 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bound, Jim
> Sent: Monday, November 14, 2005 11:17 PM
> To: Dino Farinacci
> Cc: [email-masked]; [email-masked]
> Subject: RE: [arch-d] Mobility and multi-homing: Summary and 
> going forward
> 
>