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

Re: shim-aware transports



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