Subject: [Capwap] New mux header for CAPWAP

From: <[email-masked]>
Date: Tue, 6 Jun 2006 18:44:52 -0700

The CAPWAP editors have asked the Chairs to resolve the Mux vs Multiport
issue # 115, in order to progress the specification.  Based on the
discussion that has taken place the chairs are in agreement the
simplest, cleanest solution for this is to add a Mux header.  Barring
any unforseen events, we will instruct the editors resolve in favor of a
new Mux header.

We intend to close this issue by the end of the week, Friday, 6/9.
Please review the issue and send any constructive comments to the list
by Friday. 

Best Regards,
Dorothy

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

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

---

From: Charles Clancy <[email-masked]>
Date: Thu, 08 Jun 2006 15:08:19 -0400

For the record, personally I'm in favor of MUX headers.  While I agree 
that QoS is an issue, I think NAT traversal is a bigger issue.

--
t. charles clancy, ph.d.  |  [email-masked]  |  www.cs.umd.edu/~clancy

[email-masked] wrote:
> ------------------------------------------------------------------------
>

---

From: "Michael Montemurro" <[email-masked]>
Date: Thu, 8 Jun 2006 21:34:39 -0400

First of all, I'd like to comment that one of the CAPWAP editors was not
even consulted on the request to the chairs to resolve this issue. :-(

So basically, the MUX header makes NAT Traversal easier to support. The use
of separate UDP ports for control and data traffic allows for greater
flexibility for deployment and implementation. I think you could probably
argue back and forth on this one, but I don't see one option over the other
presenting a clear advantage.

The only compelling reason I could think of to go with separate UDP ports is
that a network element classifying the packet does not have to read deep
into the packet to distinguish CAPWAP control from data. That might be an
advantage over a MUX if there are no security issues with exposing control
and data UDP ports.

Based on my review of this email thread. I fail to see a clear consensus on
this issue. With that in mind, we really should consider a compromise
scenario which Scott documented as his third option in his email on May
18th. That is, to quote him, "use multiple ports with separate data and
control channels, but when NAT is detected, do what IPsec does, i.e. shift
onto a single UDP channel, bundling control and data together; that is, have
an optional nat-t encapsulation mechanism.".

In that way, everybody is unhappy, but we have consensus on that. :-)

Cheers,
    Mike

---

From: "David T. Perkins" <[email-masked]>
Date: Thu, 8 Jun 2006 22:05:03 -0700 (PDT)

HI,

This is the 3rd or 4th message that has just not read
my message from "Thu, 8 Jun 2006 01:47:21 -0700 (PDT)" with
subject "[Capwap] Proposal for CAPWAP packet format":

In it I showed the packet formats and made the following
observation.

 NOTE: A CAPWAP MUX header is needed whether or not the same or
        different UDP ports are used for CAPWAP control and
        data messages. This is because both CAPWAP data and
        control messages can be unprotected or protected by
        DTLS, and the MUX header is needed to distinguish
        protected from unprotected. Remember that CAPWAP
        "discovery requests" and "discovery responses" are
        unprotected, and that all other CAPWAP control
        message types are protected.

Also note that "deep packet inspection" is not needed.
Whether it's a control or data packet isw simply a matter
of looking at the second octet in the UDP data.

Here is the updated version of what was called "MUX header"
in the email, but is now called "CAPWAP Pkt Header"

  CAPWAP Pkt Header:
                         1
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Version       |    Type       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Version - the version of the CAPWAP protocol (the first is 0)
                DISCUSS: should this be split into major and minor,
                         and if so, what are the implications of
                         an increment of the major or minor part?

      Type - packet type, values are:
                1 - CAPWAP Unprotected Data Packet
                2 - CAPWAP DTLS Protected Data Packet
                3 - CAPWAP Unprotected Control Packet
                4 - CAPWAP DTLS Protected Control Packet
               0,5-15 - reserved

With this as the first two octets, it's pretty easy to
do classification.

So, it looks to me like there is an aweful lot of arguing
over a false assumption. Can we do activities that result
in forward progress? If the WG is not making progress,
I'm sure the ADs will be happy to terminate the WG.

> > that QoS is an issue, I think NAT traversal is a bigger issue.

Regards,
/david t. perkins