Subject: [Capwap] The Mux header flux

From: "Mani, Mahalingam (Mani)" <[email-masked]>
Date: Sat, 24 Jun 2006 18:42:50 -0600

All,

Attached is a summary of the discussions that have been in progress so
far on the proposal to use a mux-header for multiplexing control and
data flows.

Apologies for late summary. The attached also includes a proposed set of
questions for consulting other SME (subject-matter-experts) as suggested
by ADs.

Some of them could be framed better; some more could be framed.

In the final analysis, we are positioned best to determine the best way
to go based on inputs that may need clarifying not only from SMEs but
also the current practices in the industry (enterprises, provider
environments of various hues). We may not be able to get them all; if we
do get a large subset that is goodness.

Else, it is inevitable that additional field deployment experiences of
the CAPWAP standard alone can help us refine it (a -bis, perhaps).

Preamble:

More than a year ago, around when the WG was being rechartered to work
on the protocol; it was suggested to treat the data-path independent of
control path and leave it out of the CAPWAP protocol definition itself.
However, architectural taxonomy indicated trends that found usefulness
of split-MAC with tunneled forwarding of data to a centralized AC
already having found some acceptance in many deployments also merited
inclusion. Hence we are ending up classifying three modes - two in
split-MAC and one in local-MAC. The Split-MAC treatment of data-traffic
has led to questions about its protection, encapsulation and
multiplexing with control stream.

Since then there has been a lot that happened including succeeding in
getting a -00 version of the WG CAPWAP draft protocol out for review and
a -01 following it.

A member of the WG, Scott Kelly, has proposed use of mux header citing
several reasons.

It also appears that - given the nature and intensity of discussions; as
well as the stated/claimed deployment practices in enterprise and
provider environments to enforce local policies - it becomes imperative
to validate them over a broader network equipment vendor and customer
space.

It also becomes apparent that a best-practices (applicability) document
may be useful to guide operators (enterprise and provider) with best
choices for given topologies.

While the presented approach of tables may not be the best way to
summarize - this is captured in chronological order showing the
progression of topics; it is interesting what has caused what looks to
be a simple issue to resolve technically to take this magnitude of
debate.

We would like not to linger long on debating the questions; simply send
in your additions/changes and we (chairs) will recompile them once
(hopefully to general agreement) and send it on to the ADs.

Regards,

-mani

PS:

The technical merits of the reasons have been debated. Also in question
is the concern about compatibility with existing implementations and
behaviors on intermediate switches and routers processing along the way
leading to performance inefficiencies. The discussions are not citing
any correctness issues, however, mux-header or not. We will try to
summarize them all and see why we gauge consensus in favor of
mux-header. For those more used to other SDOs: That does not mean the
perceived consensus cannot be opposed (as it happens ever so many times
in other SDOs based on respective process mechanisms and influences of
varied hues) or argued against/for - on technical merits and pitfalls.

It is customary, both thinly contended to closely contended issues
(technical and otherwise) there is a need to call for consensus by
stating a conclusion and calling the question. This may happen at many
layers - not always requiring the chairs to intervene - as happens with
many cases in the issue-tracker. However, in the event of strong dissent
the chairs are required to/called upon to assess, gauge, state and
validate "rough" consensus. This is what is happening. Now that

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: "David T. Perkins" <[email-masked]>
Date: Sun, 25 Jun 2006 22:38:08 -0700 (PDT)

HI,

Wow, you sure did a lot on the summary.
However, I still fundamentally disagree with an assumption,
which is you don't need a capwap header that comes
at the beginning of the UDP data that indicates if you have
protected or unprotected content that follows.

Also, there is an assumption that the QoS marking on all
data stream are the same, and all control stream are the
same. That is, for some wireless devices, their data
may be VoIP, or some other real time media, and others
may be plain old data. This is one data stream between
a WTP and AC. How is the STA traffic defferentiated?
For control traffic, there are different types. I would
hope that traffic to "add a station" would have a
higher priority over a periodic statistics report.

Also, one of the things that is different about LWAPP
than most (maybe all, but I really can't out one) of
the other submissions is that the 802.11 control frames
are sent in the data stream. In the other submissions,
the control frames were encapsulated and sent in
the control stream. If I've correctly interpreted
LWAPP (and which was carried over into CAPWAP),
this seems problematic in several ways. First,
it creates problems with QoS marking. Secondly,
if this is the mechanism used for localMAC, it
seems a little strange. (Let' talk about the
other issues at another time.)

So, in summary, I believe the following:
 1) CAPWAP packets must always have a header
     that indicates if protected or unprotected
     content follows
 2) The QoS for CAPWAP control and data streams
     should not be the same for all packets in
     the stream.

Thus, I believe that the questions to the IETF subject
matter experts should be:
 1) what is the best way to indicate if the content
    of a CAPWAP packet is protected or unprotected?
    And does 32-bit alignment matter or not?
 2) what mechanism is the best way to provide
    the QoS values of protected content so that
    intermediate systems can use it to remark
    the QoS values is CAPWAP packets?

I believe that you may run into problems because:
1) no one used used DTLS before to do what is
   desired in CAPWAP
2) the TCP assumptions are not the same as when
   running on UDP
3) the TCP programing patterns for writing servers
   will not work for UDP servers.

Oh I wish that CAPWAP had had an interim meeting.

Oh I wish there was some working open source code.

Oh I wish that DTLS in openSSL was bug free and
conformed to the defining RFCs (4346 & 4347).

Best regards,
/david t. perkins