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