[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Transport level multihoming
- To: RJ Atkinson <rja@inet.org>
- Subject: Re: Transport level multihoming
- From: Greg Maxwell <gmaxwell@martin.fl.us>
- Date: Tue, 3 Apr 2001 12:30:18 -0400 (EDT)
- cc: multi6@ops.ietf.org
- Delivery-date: Tue, 03 Apr 2001 09:33:36 -0700
- Envelope-to: multi6-data@psg.com
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.