Shared Locator Address Pool (SLAP) protocol proposal

[Dave Crocker <dhc@dcrocker.net>]

Folks,

A fundamental advantage that transport-based locator-pool schemes
(SCTP, DCCP, TCP-MH) have over wedge-layer approaches (HIP, LIN6,
MAST, MIP) is that they can multiplex the control exchange in with
data traffic, potentially saving on number of packets. Wedge-layer
approaches are forced to have an explicit, separate exchange. MAST
makes this asynchronous from the data exchange that uses the locator
pool; this avoid startup delay. However the basic cost of the exchange
remains. If a host must do this exchange with every other host it
talks to, the aggregate overhead is high.

Deferring use of the mechanism, as Pekka S. described, is one way to
reduce such traffic.

Wouldn't it be nice if it were possible to have the "enhanced"
transport services share their lower-cost largesse with the
wedge-layer schemes?

So, here's the thought:

1. An endpoint runs Locator Pools (LP) as a resource shared among different
consumer services at the endpoint -- eg, a wedge layer service and an enhanced
transport service -- potentially with multiple maintainers. (Yes, the latter
raises a concern about synchronization, but let's ignore that minor detail,
for now.) LPs might vary in their granularity.  Bigger grains makes it
more likely that the pool will be shared.  A pool that is the finest
grain (Connection) can't be shared, of course.

2. A common Shared Locator Address Pool (SLAP) protocol is used by the
different maintenance services, over different communication channels
(eg, multiplexed on the transport channel, versus over an independent
control channel). The maintenance services also might use different
"configurations", such as peer-to-peer exchange, versus third-party
agent mediation.

3. Enhanced transport services access the pool directly. Legacy
transport services access the pool via the much-vaunted IP wedge layer
service. If an enhanced transport is one of the participants, then
there really is no need for a wedge-layer service to conduct an
exchange. This saves packets.

The obvious direction this idea leads is towards an effort to produce
a common protocol.  Clearly it should include the locator
"characterization" attribute-signalling capability that Erik suggested.

Anyone from the various camps interested in discussing such an effort?

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>