Re: Shared Locator Address Pool (SLAP) protocol proposal

[Brian E Carpenter <brc@zurich.ibm.com>]

Spencer, I think the point here is that there will be state
to maintain, and each user of that state will need to access a
common STorage Information bloCK, i.e. the SLAP STICK.

The kind of shim that NOID suggests could also be a user
and maintainer of the slapstick.

I'd encourage people to think about this as a potential
architectural component, in the spirit of the final part of
the discussion last week.

  Brian

Spencer Dawkins wrote:
> 
> Dave,
> 
> If this proposal can be made to work, that would be lovely. The part
> that scares me is having a number of different entities maintaining
> this pool (if we had TCP, SCTP, RTP/RTCP, and DCCP on one node, that's
> not a small amount of software) - just figuring out why something was
> added or deleted seems daunting.
> 
> But I'll let others chime in here, one way or the other.
> 
> Spencer
> 
> ----- Original Message -----
> From: "Dave Crocker" <dhc@dcrocker.net>
> To: <multi6@ops.ietf.org>
> Sent: Saturday, November 15, 2003 10:45 AM
> Subject: Shared Locator Address Pool (SLAP) protocol proposal
> 
> > 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>
> >
> >