Re: Transport level multihoming

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

Greg Maxwell wrote:
> 
> On Wed, 8 Aug 2001, Brian E Carpenter wrote:
> 
> > Daniel,
> >
> > If I could avoid the conclusion that we are forced into transport level
> > gymnastics, I would be delighted. But remember that the scaling arguments
> > are several orders of magnitude worse than in the 802.5 case (potentially
> > many millions of entries in a flat routing table, as opposed to a few thousand
> > for LAN bridging tables.)
> 
> For transport level multi-homing, you'll need a higher level distributed
> database to keep track of all the address->host mappings. Fortunately, we
> already have one designed for just that purpose: DNS.
> 
> Since we don't want to make any application changes (i.e. make it gather
> multiple addresses from DNS and pass them to the socket API), how about
> this:
> 
> We make the existing API a userspace wrapper on an improved API that takes
> multiple addresses. The resolver will return a bogus IP address which is
> specific to that boot-session of the host, the socket API wrapper will
> reconize the bogus address (because they will all be scoped out of a
> special allocated area), and query the resolver again to retrieve all of
> the real addresses then call the real API.
> 
> This would allow us to achieve application compatibility.
> 
> I don't see why anything more is needed. I'll code up an example of this
> implementation for a GNU/Linux system once the SCTP TCP-like api support
> is finished in the Linux kernel SCTP implementation.

Yes, this is one way to do it (almost identical to the "bump in the API"
approach to v4/v6 interworking). I don't see any reason why the IP address
returned by the resolver needs to be bogus; surely it can simply be any one
of the real IP addresses, which might have some advantages.

   Brian