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