Re: Transport level multihoming

[Greg Maxwell <gmaxwell@martin.fl.us>]

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.