Subject: [Capwap] to mux or not to mux?

From: "Scott G. Kelly" <[email-masked]>
Date: Mon, 1 May 2006 11:38:19 -0700 (GMT-07:00)

Some time ago, I proposed that we use a single port for capwap, and insert a mux header right after the UDP header to differentiate between control and data. While there was some discussion, we did not reach a conclusion.

Here's what it would look like:

+---------+-------------+-------------------------------
| UDP Hdr | MUX Hdr = 1 | DTLS Enc Control Packet ....
+---------+-------------+----------------------

The capwap editors are currently working hard to produce the 01 version of the capwap document, and it would be best for implementers if this question could be decided prior to publication of that document. To facilitate this, I've summarized briefly below.

Using separate ports for control/data has a number of drawbacks:

- if firewalls are between the AC and WTP, multiple rules are required

- we must be able to explicitly bind the data and control channels at the AC in order to ensure proper operation; if they use the same port (and therefore, flow), this is straightforward; if not, we must add protocol elements for detecting and accounting for NATs along the AC-WTP path, and for explicitly (and securely) creating the bindings between the two channels

- there are race conditions that must be dealt with; in particular, it is possible to have the left hand (control channel) not knowing for certain what the right hand (data channel) is doing (and vice versa)

- If there *are* NATs along the path, using two ports will require keepalives on both ports, and error handling for when one channel goes away but the other does not (e.g. if a middlebox deletes the NAT bindings for any reason) 

- there are many more error conditions to manage in the state machine, due to the channel binding and NAT issues

Clearly, using two ports adds *significant* complexity to the implementation, and will likely result in operational problems in some environments.

Using a mux header has one drawback (that I can think of):

- it adds n bytes to the header. I'm tempted to say n will be 4 for 32-bit alignment, but it could also be only 1 or 2 bytes, if bits-on-the-wire overhead is an overriding concern.

Using a mux hader has several advantages:

- we get NAT traversal for free, by simply configuring the echo interval to be smaller than the NAT binding lifetime for the path in question

- we only open one port through intermediate firewalls (and any intermediate NATs)

- the implementation (state machine, error handling) is *much* simpler, and therefore more likely
  to (inter)operate according to spec

We need to decide on this, preferably within the next day or two. Please speak up and make your preferences known.

Thanks,

Scott

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

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

---

From: "T. Charles Clancy" <[email-masked]>
Date: Mon, 1 May 2006 14:47:11 -0400 (EDT)

I think another drawback of the MUX header is that stock DTLS 
implementations will likely already have support for running over plain 
UDP.  Thus any CAPWAP DTLS implementation might be a little less 
out-of-the-box.  Of course, CAPWAP will need to muck with the DTLS state 
machine on a low level anyway, so it's unlikely any implementation would 
work out-of-the-box.

That being said, I'm personally in favor of the MUX header.

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

On Mon, 1 May 2006, Scott G. Kelly wrote:

> Some time ago, I proposed that we use a single port for capwap, and 
> insert a mux header right after the UDP header to differentiate between 
> control and data. While there was some discussion, we did not reach a 
> conclusion.
>
> The capwap editors are currently working hard to produce the 01 version 
> of the capwap document, and it would be best for implementers if this 
> question could be decided prior to publication of that document. To 
> facilitate this, I've summarized briefly below.
>
> - we must be able to explicitly bind the data and control channels at 
> the AC in order to ensure proper operation; if they use the same port 
> (and therefore, flow), this is straightforward; if not, we must add 
> protocol elements for detecting and accounting for NATs along the AC-WTP 
> path, and for explicitly (and securely) creating the bindings between 
> the two channels
>
> - there are race conditions that must be dealt with; in particular, it 
> is possible to have the left hand (control channel) not knowing for 
> certain what the right hand (data channel) is doing (and vice versa)
>
> - If there *are* NATs along the path, using two ports will require 
> keepalives on both ports, and error handling for when one channel goes 
> away but the other does not (e.g. if a middlebox deletes the NAT 
> bindings for any reason)
>
> - there are many more error conditions to manage in the state machine, 
> due to the channel binding and NAT issues
>
> Clearly, using two ports adds *significant* complexity to the 
> implementation, and will likely result in operational problems in some 
> environments.
>
> - it adds n bytes to the header. I'm tempted to say n will be 4 for 
> 32-bit alignment, but it could also be only 1 or 2 bytes, if 
> bits-on-the-wire overhead is an overriding concern.
>
> - we get NAT traversal for free, by simply configuring the echo interval 
> to be smaller than the NAT binding lifetime for the path in question
>
> We need to decide on this, preferably within the next day or two. Please 
> speak up and make your preferences known.
>
> Thanks,
>
> Scott
>

---

From: Puneet <[email-masked]>
Date: Wed, 3 May 2006 09:48:56 -0700

I would vote for having the Mux header instead of using two separate UDP
ports.

Thanks,
Puneet

On 5/1/06, Scott G. Kelly <[email-masked]> wrote:
>
> Some time ago, I proposed that we use a single port for capwap, and insert
> a mux header right after the UDP header to differentiate between control and
> data. While there was some discussion, we did not reach a conclusion.
>
> The capwap editors are currently working hard to produce the 01 version of
> the capwap document, and it would be best for implementers if this question
> could be decided prior to publication of that document. To facilitate this,
> I've summarized briefly below.
>
> - we must be able to explicitly bind the data and control channels at the
> AC in order to ensure proper operation; if they use the same port (and
> therefore, flow), this is straightforward; if not, we must add protocol
> elements for detecting and accounting for NATs along the AC-WTP path, and
> for explicitly (and securely) creating the bindings between the two channels
>
>
> - there are race conditions that must be dealt with; in particular, it is
> possible to have the left hand (control channel) not knowing for certain
> what the right hand (data channel) is doing (and vice versa)
>
> keepalives on both ports, and error handling for when one channel goes away
> but the other does not (e.g. if a middlebox deletes the NAT bindings for
> any reason)
>
> - it adds n bytes to the header. I'm tempted to say n will be 4 for 32-bit
> alignment, but it could also be only 1 or 2 bytes, if bits-on-the-wire
> overhead is an overriding concern.
>