Re: Thoughts about layering multi-addressing

[Erik Nordmark <erik.nordmark@sun.com>]

Pekka Nikander wrote:

> Hence, my question is if the transport are likely to need anything  else 
> than the following:
>   - both ULIDs and locators in incoming packets
>   - ability to define locators for outgoing packets
>     - what happens if the locators are not available any
>       more?  Host-internal ICMP-like response?
>   - ability to get the full set of locators related
>     to a given ULID
> Anything else?

One additional thing comes to mind. If we are thinking a bit about 
multihomed hosts and not just multihomed sites, it might be that the 
locator pair is really part of an abstraction of the (host visible) 
path; another element of this would be the interface used to send and 
receive packets. Thus carrying <src locator, dst locator, interface id> 
as the annotation might make sense.

When it comes to the available locator pairs (or host-visible path 
abstractions), then I think we'd want the ability for the ULP to request 
notifications not only of the current set, but also of any changes to 
the set. (A locally generated ICMP error might be an implementation of 
this, but I find that missing in its inability to indicate new locators 
to the ULP.)

The thing that is the least clear to me if the role/split between the 
shim and the locator aware transport when it comes to the testing of the 
paths. It might be that the shim has some information about the state of 
the paths (which are known to have recently worked and not), which it 
can share with the ULP. But the ULP might have more data on the paths it 
is currently using (rtt, cwnd) which it may or may not make sense to 
share with other ULPs or instances of the same ULP.
How much do we need in this space? A full fledged mechanisms for sharing 
akin to the congestion manager (what Dave Crocker called CELP)? Or do we 
assume it is a unidirectional mechanism for the shim  to tell the ULP 
the status?

   Erik