Subject: Experts Request for CAPWAP

From: Bill Fenner <[email-masked]>
Date: Thu, 6 Jul 2006 17:11:27 -0400

The CAPWAP WG needs some advice.  It's trying to decide between
two options:

- Using seperate UDP ports for control traffic vs. encapsulated data
- Using a single UDP port and a small multiplexing header

It turns out there are *all sorts* of sub issues involved, so it's
not really "pick one".  One of the questions that they're interested
in having answered is QoS classification: is it reasonable to expect
that if you want to give traffic different queueing behavior, that
you can just set a DSCP and be done, or should you be programming
classifiers (and obviously classifiers can classify on UDP ports
but not all classifiers will be able to look at the 4th byte of the
UDP payload (e.g.)).

I'm forwarding a message from Dan Romascanu, the ops area AD 
responsible for CAPWAP, asking for help.  I'd like to ask the
routing directorate this:

- If someone has been following the CAPWAP work, and has a
sense of what the underlying issues are here, summarize for
the group.
- Is there someone interested in looking into this and
helping to inform the group?

In the "routing protocols" sense, this isn't a routing area issue
at all; things like packet classification etc. have usually been
Internet area issues, but Dan asked us for help so I wanted to
see if the expertise was around.

[You can find the PDF file that was attached to Dan's email
at http://rtg.ietf.org/~fenner/tmp/muxflux.pdf - I didn't want
to clog up inboxes with it.]

Thanks,
  Bill

----- Begin forwarded message:

From: "Romascanu, Dan (Dan)" <[email-masked]>
Subject: Experts Request for CAPWAP
Date: Thu, Jul 6 14:52:41 
To: "Mark Townsley (townsley)" <[email-masked]>, "Jari Arkko" <[email-masked]>, "Ross Callon" <[email-masked]>, "Bill
    Fenner" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Hi,

Following the 7/6 telechat, here is the request to provide assistance to
the CAPWAP WG in order to overcome their deadlock concerning the
multiplexing of control and data frames in the capwap specification. It
would be very useful if the Internet Area and Routing Area can delegate
one expert each to advice CAPWAP starting with the Montreal meeting. 

The document in discussion is
draft-ietf-capwap-protocol-specification-02. However, there is no need
for a full review of this document but for guidance on the specific
question of distinguishing control and data frames in CAPWAP. 

The choices that were discussed were the usage of separate UDP ports or
a separate header in the protocol. 

Initially, after the initial CAPWAP protocol selection it was suggested
to treat the data-path independent of control path and leave it out of
the CAPWAP protocol definition itself. This is similar to solutions used
by protocols like SIP and FTP and allows for simpler classification in
intermediate routers for security and QoS purposes. 

The second solution came later proposing use of mux header citing like
in L2TP citing several reasons related to less complexity in handling
and correlating data for NAT Translation, simpler firewall rules,
simpler channel binding between discover, control and data. 

Also note that the configurations supported by CAPWAP lead to the need
of supporting split-MAC with tunneled forwarding of data to a
centralized AC. The Split-MAC treatment of data-traffic has led to
questions about its protection, encapsulation and multiplexing with
control stream.

The CAPWAP WG need a recommendation for a better choice between the two
solutions that will take into consideration:
- the necessity of distinguishing between the data channel (non-DTLS,
may be DTLS protected) and the DTLS-encapsulated control channel
- need for classification and inspection for QoS marking
- cost of deployment over existing routing and bridging infrastructure,
including modifications in the software stacks of existing routing and
reprogramming of firewall devices
- need to conserve QoS on WTP-AC links - not clear if is split MAC
viable solution for both cases

Details of the discussion and references are being detailed in the mail
prepared by the WG chairs and distributed to the whole IESG and in the
attached file. 

Thanks and Regards,

Dan

[Attachment: muxflux.pdf, application/octet-stream]

----- End forwarded message:
----- Begin forwarded message:

Subject: Re: Experts Request for CAPWAP
Date: Thu, Jul 6 15:46:44 
To: [email-masked]
Cc: [email-masked] [email-masked] [email-masked] [email-masked]

I've downloaded the capwap wg archives and subscribed the archiver to
the mailing list; I find the lurker interface to be much better than
pipermail for searching for old threads.

http://rtg.ietf.org/lurker/list/capwap.en.html

The threads that the muxflux pdf point to are:

http://rtg.ietf.org/lurker/thread/20060322.165321.958ab973.en.html [NAT-T]
http://rtg.ietf.org/lurker/thread/20060505.114306.e2000749.en.html [To mux or not to mux?]
http://rtg.ietf.org/lurker/thread/20060515.220123.2f03f052.en.html [Mux redux]
http://rtg.ietf.org/lurker/thread/20060518.162324.bfbf5559.en.html [Cost-benefit analysis: mux vs multiport]
http://rtg.ietf.org/lurker/thread/20060608.234230.a3fbc258.en.html [New mux header for CAPWAP]
http://rtg.ietf.org/lurker/thread/20060609.221348.af6a6381.en.html [Capwap transport analysis: QoS vs multiport]
http://rtg.ietf.org/lurker/thread/20060614.002724.56bc9b85.en.html [Reasonably bounding our QoS ambitions for our base protocol]

There's a *lot* of discussion there, and I haven't been able to
really understand how the PDF file distills it too much.

  Bill

----- End forwarded message: