Re: shim-aware transports

[Geoff Huston <gih@apnic.net>]

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.

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.

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?

  Geoff