RE: Transport level multihoming

[Jim.Bound@nokia.com]

Pekka,

I like your draft fyi and know several key users who like it too.  Want to
talk to you off line as lead author of the ipv6  base api and knowing the ip
stack and routing code very well.  Like to get nitty gritty with you on this
one offline as implementor to implementor.  To sort this out.  I also know
sctp very well.  But lets go offline on details and see what we deduce.  

For the list I do agree that we should not prohibit anything that will
resolve multihoming issues but we cannot depend on end systems deploying
sctp for a solution that would not be wise.  The sctp API does not
necessarily break apps but their is a porting cost and the API
implementations for sctp are still being developed and its not clear yet
what all the answers are except for BSD style sockets and when and how to
implement them for sctp.  So we don't want to tie initial solutions to sctp
and what may happen is come up with a set of recommendations that have stage
1, stage 2, etc... where stage 1 solves significant problems.

thanks
/jim

> -----Original Message-----
> From: ext Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]
> Sent: Wednesday,April 04,2001 1:25 AM
> To: Ran Atkinson
> Cc: Greg Maxwell; multi6@ops.ietf.org
> Subject: Re: Transport level multihoming
> 
> 
> 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
> 
>