Re: Transport level multihoming

[Mohan Parthasarathy <Mohan.Parthasarathy@eng.sun.com>]

Sometime back there was some discussion on multi-level multihoming
scenario while GxSE was being discussed i.e what if your upstream
ISP is multi-homed, how does GxSE work in this case ? 

Doesn't similar constraints apply to any transport level solution ?
I am not sure how a transport solution works when one of the
upstream ISP's link fails. Isn't this one of the requirements ?

thanks
-mohan

> Date: Tue, 07 Aug 2001 17:01:51 -0500
> From: Brian E Carpenter <brian@hursley.ibm.com>
> X-Accept-Language: en,fr
> MIME-Version: 1.0
> To: Greg Maxwell <gmaxwell@martin.fl.us>
> CC: Ben Black <ben@layer8.net>, Randy Bush <randy@psg.com>, Peter Tattam 
<peter@jazz-1.trumpet.com.au>, multi6@ops.ietf.org
> Subject: Re: Transport level multihoming
> Content-Transfer-Encoding: 7bit
> 
> Greg Maxwell wrote:
> > 
> > On Tue, 7 Aug 2001, Brian E Carpenter wrote:
> > 
> > [snip]
> > > On the other hand we know that major restructuring of applications isn't 
going
> > > to happen - that's the real world. So if we have to do work in the 
transport
> > > layer, the transport layer is going to have to hide most of it below some
> > > sort of socket API. I can't see any reason in principle why that API
> > > would have to expose a bunch of addresses, even if it turns out that
> > > multi6 requires more than one. A "primary" address per host would be 
enough
> > > to expose to the middleware.
> > 
> > If the primary address is functional at connection setup time, then, yes
> > it could learn the other transports from the remote end. However, what do
> > you do if the primary is down? The only solutions I can think of either
> > require the applications to rotate the address passed to the API, or
> > require the transport to consult DNS (what an ugly kludge and layering
> > violation THAT would be!).
> 
> There is *always* an abstraction layer above which a single handle identifies
> the other party in a session (and probably no handle at all identifies
> "this" end of the session). So whatever layer is the highest layer to
> be aware of N addresses, there is always a layer above that (conceptually
> at least) that has a single handle for that set of N addresses.
> 
> All I am saying is that this abstraction layer may just as well be a socket
> API, and that single handle may just as well be one of the N addresses - and
> if you do it that way, you minimise the impact on existing apps layer logic.
> 
> It's probably sloppy to write as I did of a "primary" address being the
> handle; it's just an arbitrary choice among the N addresses available.
> It's the one that gethostbyname (equivalent) chooses to return to you;
> it might conceal a bunch of others from you below the socket API,
> and use them as needed for multihoming or whatever other cookery it
> needs to do.
> 
>    Brian
>