[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: shim-aware transports
At 11:05 PM 19/08/2005, Erik Nordmark wrote:
Geoff Huston wrote:
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.)
This notion of forking makes sense, but it isn't clear to me whether it is
a local notion at the sending side, with the ULP at each end being able to
make independent decisions (perhaps using some ULP signaling), or whether
it is a shim-coordinated decision.
I am not sure whether peer-to-peer coordination is a strict requirement or
my comment about a richer vertical and horizontal signalling API that at
a signalling placeholder there in any case.
I think we can define it to be a local thing at the sending side, where a
ULP can signal that a given class of packets between a ULP pair (or even
at the granularity of each packet) use a different locator pair than the
default. The receiver will happily accept such packets, because the
locator pair is in the negotiated set of locators for the ULP pair context.
Exactly my thought as well! The other end may see the use of multiple
in the incoming stream and will correctly map these to the same ULID
and then demux
them to the active transport entities as normal.
Do you think we'd loose something important if there isn't shim signaling
to have the two ends agree to switch the locator pair for both directions?
I think we should allow for the possibility for one shim entity to signal
to the remote shim
entity to attempt a switch to a specific locator set for a specific
"state", forking its state
as necessary, but its a weakly formed thought at this stage!