Re: [Tsvwg] multiaddressing

On Mon, Nov 15, 2004 at 01:40:47PM -0500, Wesley Eddy wrote:
> In draft-crocker-mast-analysis-01 (now expired), the concept of
> "multiaddressing" for solving multihoming and mobility problems is
> explained.
> 
> The HIP groups and multi6 are focusing on multiaddressing solutions
> built for "simple" transports that can only bind to a single address
> with no means to update or extend that binding when it might be required
> by mobility or multihoming.  Adding a wedge-layer to map dynamic locators
> to fixed identifiers fixes these problems and allows the transport to go
> untouched and remain simple.
> 

I previously brought up the idea that a multiaddressing wedge should at
least pass a bit up to the transport to notify it of mobility events.

Another consideration, in comparison to systems where the transport does
all the book-keeping of addresses and handles mobility and multihoming
on its own, is that the transport<->wedge interface will likely not be
rich enough for the transport to do the sorts of things that SCTP is
capable of, like retransmiting on alternate paths, load balancing
between interfaces, etc.  I'm not sure that the wedge interface could be
made rich enough to support those types of transport decisions without
completely negating the benefit of its simplicity, and certainly we
don't want the wedge to be doing those types of things silently itself
without the transport's consent.

It looks like this issue is another point in favor of transport-based
mobility/multihoming schemes.  I'm still in favor of passing the
book-keeping off to a common wedge somehow, but it looks like there's
still quite a bit of utility in having the transport be able to query
and richly interact with that wedge, rather than have it just
transparently "make things work".

-Wes