[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: shim-aware transports



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