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

Re: shim-aware transports



I'd suggest that an API model may assist in the thinking here, particularly as I
suspect that there may also be some 'horizontal' signalling that may also
be required here when the SHIM layer wants to signal its remote
counterpart.


However if an implementation chooses to implement the API via
direct access to data structures in the stack then that's not
inconsistent with this API design approach.

  Geoff





At 01:30 AM 20/08/2005, Brian E Carpenter wrote:
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