RE: Requirements [was Re: Transport level multihoming]

[Coene Lode <Lode.Coene@siemens.atea.be>]

Yes, I know. I am getting annoying:-)

> -----Original Message-----
> From: xxvaf [mailto:xxvaf@mfnx.net]
> Sent: dinsdag 3 april 2001 21:54
> To: multi6@ops.ietf.org
> Subject: Re: Requirements [was Re: Transport level multihoming]
> 
> 
> > > >A more basic question - are we able to *require* changes in the
> > > >host IPv6 stack in support of multihoming?
> > > 
> > >         If not, then we close the door on a large class
> > > of potential solutions.  In particular, the TCP/UDP
> > > Protocol Control Blocks currently bind the IP addresses
> > > on both sides tightly into each session.  The sort of approach
> > > that GSE outlined would want to bind the PCBs to some
> > > identifier that was not the IP address used for packet
> > > forwarding.
> > 
> > That's fair comment, but remember that we have legacy IPv6 
> stacks already.
> > We certainly can't assume that host IPv6 stacks will all 
> get upgraded
> > rapidly to cover such changes - i.e. hosts must not lose 
> connectivity if 
> > they are not upgraded for multihoming, even if they don't 
> get full benefit
> > >From the multihoming.
> 
> IMHO, the number of such "legacy ipv6 stacks" is 
> insignificant compared to
> the opportunity to do multihoming right. Especially if, as 
> some now believe,
> getting this right means the difference between allowing the 
> routing system
> to scale or watching it stop working during the next year or 
> two. One would
> also imagine that the users of the legacy systems are also 
> (very) early
> adopters who must know that early implementations are subject 
> to change.
> 
> As I believe Noel once said, there is at most one chance to 
> make substantial
> change to the Internet network and transport protocols. One 
> would hope that
> the changes to be made will provide more benefit than just 
> expanding the
> locator field from 32 to 128 bits.
> 
> My brief persual of SCTP suggests that it could have some promise. Two
> questions for someone with more knowledge of its details:
> 
>     - Has any work been done to port existing protocols and 
> applications
>       (HTTP, SMTP, FTP, TELNET, SSH, etc.) to SCTP? If not, 
> how difficult
>       would it be to provide a TCP-compatible API? What, if 
> any, approach
>       might be taken for UDP-based applications, such as DNS?

I cannot talk for the TCP based API. The SCTP socket draft should give soem
clues about that. I can only talk as a UDP style user: I supply the IP
addresses at association setup and after association setup, I can send
messages to SCTP(using the association ID) till I or the remote side decides
to breakdown the assocation. SCTP can also shower me with messages coming
from the remote end during the association lifetime. That's the basic
operation: some nifty things are taken care for me by SCTP: MTU path
discovery( I don't have to do that myself), if my side or the remote sides
sents a lot of traffic, then congestion control kicks in, it protects
against certain DOS attacks(not all of them, but it's a start) and others.

> 
>     - My reading of SCTP suggests that it only supports 
> multiple address
>       negotiation at session establishment. This would seem to make it
>       difficult for it to deal with address renumbering 
> events, which is
>       kind of unfortunate. Has any thought been given to this?

Well, a draft on adding and/or removing IP addresses in a SCTP association
is now in the works . see:
http://search.ietf.org/internet-drafts/draft-ietf-sigtran-addip-sctp-01.txt

> 
> Geoff's presentation indicates that multi-homing and 
> consequent traffic
> engineering tricks (i.e. selective leaking of more-specifics) 
> represents the
> biggest growth problem facing the routing system today. If 
> multhoming at 
> the transport layer can be made to work well, it would seem 
> to hold some
> potential as a solution. Can transport-layer multihoming 
> solve all of the
> requirements so far listed in the multi6 draft? I dunno - an 
> analsys of
> that might be interesting...
> 
> 	--Vince
> 

yours sincerly,
Lode

Siemens Atea ICN D CS D
Software Development 
Atealaan 34     
B-2200    Herentals    Belgium         
Tel +32-14-25-2081   /  Fax +32-14-25-3212
E-mail:   lode.coene@siemens.atea.be