Re: shim-aware transports

[Brian E Carpenter <brc@zurich.ibm.com>]

Pekka, since the initial goal is no change to the ULPs,
the state is all going to be in the shim, isn't it?
(Or perhaps better to say, in a data structure initially
maintained exclusively by the shim, but perhaps accessed
by shim6-aware ULPs in a later stage.)

   Brian

Pekka Nikander wrote:
> I am just wondering how much state we want to push to the shim layer  
> versus keep at the     ULPs.  See my other notes about that:
>
> http://psg.com/lists/shim6/msg00663.html
> http://psg.com/lists/shim6/msg00671.html
>
> It looks to me that we may be able to keep the signalling interface  
> pretty simple, without any loss of generality.  But maybe I am  missing 
> something there.
>
> --Pekka Nikander
>
> On Aug 19, 2005, at 1:53, Geoff Huston wrote:
>
> > 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