RE: shim-aware transports

[<john.loughney@nokia.com>]

Geoff,

>Brian noted that  making the shim  work with unmodified IP and 
>unmodified upper layers needs to get shipped first, and thats 
>a good priority.
>
>Brian also noted that this implies a two-way API between the 
>shim and the ULP, in which the necessary events are 
>transmitted up or down.
>
>So I'd like to float the concept of a placeholder about the 
>interaction with transport that hopefully will allow the 
>priority work to proceed while still keeping enough 
>flexibility around to allow transport sessions to be able to 
>be more explicit about what they want from the shim layer, but 
>to define this interaction at a later stage in the WG's life.

I agree, and I think that this will buy us something - it will
hopefully give us a more light-weight mechanism without 
overloading of a lot of functionality (i.e. - state) inside
of the sim layer.

>It seems to me that the basic mechanics of this can be 
>satisfied by defining a rich enough signalling interface 
>between the shim layer and the upper level sessions - perhaps 
>allowing for the inclusion of the relevant locator set, and 
>allowing attributes to be placed on individual locators as 
>well as on the complete set in either direction. In other 
>words this allows an upper level to be more specific about 
>locator preference either by attribute or by explicit choice 
>by passing a rich information bundle to the ULP via this 
>signalling interface.

Agreed.

>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.)
>
>If you allow vertical (and peer-to-err horizontal) locator 
>attribute signalling, and also dynamic shim state forking you 
>can then say  that the mechanisms for the ULP to signal quite 
>explicit hints to the shim layer as to when and what locator 
>to use, and for the shim to respond with a forked state as 
>required and signal this to the peer remote shim entity is 
>within the capability of the protocol. How the fields are 
>defined and used are up to a later incarnation of the or 
>another WG, that will define the attributes and  their semantics.
>
>Does this help?

I think that this might be a useful way to procede.

John