Re: Transport level multihoming

[Brian E Carpenter <brian@hursley.ibm.com>]

Greg,

Regardless of whether transport level multihoming can be
achieved (which is a long running debate, and I agree
that SCTP makes it a bit more plausible), the operational
requirement for IP level multihoming isn't going to go away
at least for the next 10 or 15 years, so we have to solve it.

   Brian

Greg Maxwell wrote:
> 
> On Tue, 3 Apr 2001, RJ Atkinson wrote:
> 
> >         SCTP is interesting, but not sufficient.  The current
> > multihoming practice works with existing TCP-based and UDP-based
> > applications, without changing them.  Changing the installed
> > base of those applications to use SCTP instead isn't feasible
> > in any sort of interesting timeframe -- if such migration is
> > feasible at all.
> 
> I don't see why not. What percentage of the number of hosts on the
> Internet were added in the last 5 years?  Upgrading a system for SCTP
> support should require less effort then initial install.
> 
> In the context of IPv6, we are already going to have to upgrade our
> end nodes (both OSes and applications).
> 
> Furthermore, self-multihoming transports can run along side legacy
> transports with no additional burden (*unlike* IPv6 where you have to
> conceptually maintain two networks if you need widespread backwards
> compatibility).
> 
> You can create a signifant incentive to move applications to SCTP: Just
> make it the only way to obtain multihoming. Since many users are
> already accustomed to a short upgrade cycle and SCTP requires nothing more
> from the user then a simple end-node software upgrade.
> 
> If the existing protocols are adapted to a self-multihoming transport
> (like SCTP) right away, I believe it would be totally feasable to achieve
> SCTP penetration faster then IPv6 due to a new transport being fire &
> forget.
> 
> >         One might consider the use of techniques such as GSE
> > (or EIDs or Stack Names) to separate the host's identity
> > from its routing goop.  Such an approach would require at least
> > changing the way UDP/TCP checksums are calculated (new
> > pseudo-header) and probably requires enhancements to some
> > directory system (DNS, LDAP, or something else).  Absent an
> > engineering spec for a concrete proposal, this approach is
> > unlikely to go anyplace.
> 
> The host's identity should be totally irrelevent to the network layer,
> just as the name written on an envelope is irrelevent to the post office
> today.
> 
> DNS already provides sufficent facilities to enumerate hosts and provide a
> list of potential network paths.