Re: Transport level multihoming

[Greg Maxwell <gmaxwell@martin.fl.us>]

On Wed, 4 Apr 2001, Pekka Nikander wrote:

> 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.

I doubt it has all the benifits of SCTP. However it's quite possible that
it has the multihoming benifits without as significant of a change, an
important factor.  

I havn't finishing the homeless mobile IPv6 draft yet.
 
> 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.
k