Capwap Mailing List: Re: mux redux

[Chris Stradtman (capwap]

I have been asked by some folks to expoudn on this a little.
So here it goes.

-I work for a service provider that does temporary small and large scale
hospitality networks.  Think of what the NOC volunteers do for the IETF
meetings but often on a much larger scale.  We deal with hotels,
convention centers, arenas, and some outdoor venues

from an service provider point of view I can think of 2 off the top of
my head.

1. A service provider may not choose to trustingly pass through the QOS
markings and may wish to rewrite the QOS markings
based on other policies internal to the service provider.

-We make it a standard practice to prioritize our management traffic
over the customer transit data.  Most of the time it doesn't really
affect anything, but with the advent of a new Windows virus or worm the
ability to get into our devices to help mitigate or control the spread
is worth it's weight in gold.  (Because of the tradeshow floor nature we
have VERY little control over what the users bring onto the tradeshow
floor until after it's there)


2. The service provider may wish to send the data and control channels
down different physical paths based on economic factors.

-we usually have several paths into and out of a facility.  Some of them
may have significantly different costs and/or path characteristics.
Likewise above in the case of a outbreak problem at a remote center we
may send all of the management data down a slower less congested backup
link so we  can work on controlling the virus/worm and taking the load
off of fully congested primary transit link.

If the streams are muxed then the service provider need to have
equipment in the middle that understands the capwap protocol out of the
gate (although some gear can use explicit bitstrings and offsets into
the packet).  This is unlikely to happen and in my opinion would slow
down the adoption and implementation of the protocol in the "real world".

-Indeed some of our gear does have the capability to do the bitstring
offset matching for policy but far from all of our gear does.  So for
adoption for us we would probably have to wait until 1) we upgrade all
of our core switches to do the bitstring matching. 2) all of our core
switches get code updates to understand the CAPWAP mux header.

-I wouldn't have any problems with doing the bitstring matching, but I'm
not sure some of our level 1 NOC folks we be able to do it correctly.

I've also read mention of the concept of separating the data and control
by putting it on two different VLANs.  In may ways that would be even
easier for us implement/manage.  We already use that approach with our
fat/thick AP installations to accomplish the division.

Anyway, that's my two cents.  :-)

Chris Stradtman