Pekka, we do agree, and I agree with what Dave Meyer wrote too.
Simply put, the shim needs enough state to decide when to switch
locators on behalf of dumb transports, and it needs a way to make that
state accessible to smart transports. What I just realised is the
access for a smart transport could be an API, or it could be
direct access to the data structure maintained by the shim. We can
certainly model it as an API, but direct access might be needed
for performance reasons in an actual implementation.
Brian
Pekka Nikander wrote:
Brian,
I have a feeling we have some sort of a communication problem here but
that we fundamentally agree; this message is an attempt to clarify what
I am trying to say.
I am all for the initial goal of keeping the ULPs unchanged. That's
the whole point. However, when doing so I also think that we
*probably* should adopt the conservative approach adopted by e.g. SCTP,
i.e., to have one preferred locator and to use the rest as equal
backups. Two reasons: keep it simple, and less surprises to the
transport algorithms.
Now, AFAICT, the discussion below cornered around what to do next,
after the initial goal has been reached. What I remember from Paris we
all seem to agree that we need some kind of an interface between the
shim layer and ULP.
My two messages (URLs below) define a strawman for such an interface,
while trying to keep the system at the same time as simple as
possible. I don't see that changing at all the way the shim works with
unmodified ULPs, or what state it maintains.
On the other hand, what I find somewhat worrisome are allusions that we
should make the state at the shim layer more complex as we add
multi-addressing support to ULPs. It looks to me that some folks would
like to do locator-policy decisions at multi-addressing transports, and
then push those policies somehow to the shim, to be executed there. I
find that unnecessarily complex. Why can't the ULP just pick the
locators, if it knows about them; in that case the shim just protects
the transport from using locators that are no longer valid.
So, all I am saying is KISS, and so far the method Christian and I deviced
Going a little bit deeper,
On Aug 19, 2005, at 12:55, Brian E Carpenter wrote:
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