Re: shim-aware transports

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

Geoff Huston wrote:

> Placing the potential functionality in the hands of the session layer 
> also infers that the shim state may not necessarily be 
> endpoint-to-endpoint, but may operate at a finer level of selection (the 
> 'equivalence" topic I referred to at the WG meeting). It also infers 
> that an individual session may want to trigger a locator change that 
> appears to be an isolated request - in which case there appears to be a 
> logical need for dynamic shim state forking in some form (i.e. a shim 
> state may state in a general host-to-host state, but individual sessions 
> may 'fork' out of this general state by requesting individual locator 
> change trigger settings, for example.)

Geoff,

This notion of forking makes sense, but it isn't clear to me whether it 
is a local notion at the sending side, with the ULP at each end being 
able to make independent decisions (perhaps using some ULP signaling), 
or whether it is a shim-coordinated decision.

I think we can define it to be a local thing at the sending side, where 
a ULP can signal that a given class of packets between a ULP pair (or 
even at the granularity of each packet) use a different locator pair 
than the default. The receiver will happily accept such packets, because 
the locator pair is in the negotiated set of locators for the ULP pair 
context.

Do you think we'd loose something important if there isn't shim 
signaling to have the two ends agree to switch the locator pair for both 
directions?

   Erik