Re: Transport level multihoming

[Pekka Nikander <pekka.nikander@nomadiclab.com>]

At 14:10 03/04/01, Greg Maxwell wrote:
> >It is totally feasible to implement a self-multihomed-transport-protocol
> >with the exactly the same level of API change as is required for IPv6
> >support.

I agree with Greg.  However, our belief is that end-host multihoming
should not be done at the transport-protocol level, but as a thin
layer between the transport and network levels -- still completely
at the end hosts.  That is what we describe in Homeless Mobile IPv6,
draft-nikander-mobileip-homelessv6-01.txt.  Basically, with regard
to multihoming, our proposal has all the benefits of SCTP with the
additional benefit that it works with TCP and UDP as well.

The current version of the draft still has the defect that is is not fully
backward compatible with the current IPv6 API.  However, if we introduce
"pseudo-identifiers", i.e. some kind of EIDs structurally similar to 
IP addresses, we can provide an API that is fully compatible with the
current IPv6 API.  However, I do not know if that would be the best
approach.

Ran Atkinson wrote:
> It would help the rest of us if there were an Internet-Draft
> describing this that we could study.  You seem to have something
> quite specific in your mind.  Would you mind putting
> one together with your specific proposal ?
> 
> For my own part, some immediate questions that you might want
> to clarify for the I-D would include:
>         - What identifier takes the place of the IP address
>           in this API?

We are still using IP addresses as identifiers, but we allow several
IP addresses to be "bundled together" to represent hosts.  As I noted
above, it would also be relatively easy to provide some kind of pseudo
IP addresses to give "names" for these IP address groups.

>         - How does one modify TCP and UDP to work with the new
>           system ?

In our implementation, we internally use pseudo IP addresses in the PCB.
That pseudo address basically has a pointer to a new data structure, called
host cache, which holds the group of IP addresses the host is known to have.
When sending packets, both TCP and UDP requires a small change so that the
pseudo address is replaced by a real address before the header checksum is 
calculated.  Furthermore, TCP round trip time calculation logic seems to
require heavy modifications (due to the possiblity of simultaneously using
several network paths), but we haven't done that yet.

On the receiving side, no changes are needed at TCP or UDP.  The underlying
modified IP layer locates the correct PCB, and handles the packet and PCB
to the upper layer.  Since the header checksum is calculated over the real
addresses used in the packet, no changes are needed in the header checsum
logic.  (Well, yes, TCP requires changes to the RTT calculation again,
but as I said we haven't had a look at that yet.) 

>         - How does the new API handle UDP traffic to multicast
>           destinations ?

Multicast to multihomed hosts is not handled any different than standard
multicast.  Thus, as far as I can see, no changes are required.  But maybe
I am missing something?

--Pekka Nikander