Subject: [Capwap] 2-Port/Mux Issue Discussion

From: Margaret Wasserman <[email-masked]>
Date: Thu, 21 Sep 2006 04:45:21 -0400

Hi All,

As many of you know, we have had a technical issue open in the CAPWAP  
WG for some time that is commonly referred to as the 2-port/mux  
issue.  This issue involves a technical choice between:

- A solution that uses two different well-known UDP ports for  
separate data and control communications (the 2-port solution),

OR

- A solution that uses a single well-known UDP port for all  
communication, with control and data traffic distinguished by a  
CAPWAP header value (the mux solution).

Strong opinions have been expressed on both sides of this issue, and  
the WG has had trouble coming to consensus on a single choice.   
Discussions in this area have included a wide variety of networking  
topics, such as Quality of Service, NAT Traversal and Mobility.

Given the breadth of the technical issues under discussion, our Area  
Director, Dan Romascanu, decided to solicit advice from the IESG to  
help us understand the technical trade-offs, and to help us  
understand which factors it would be reasonable to consider in our  
working group decision -- specifically whether or not it was  
reasonable for us to consider the hardware implications of this  
decision.  The only IESG members who showed up for the discussion  
were Mark Townsley, one of the Internet ADs, and our two OPS ADs, Dan  
and David Kessens.  We didn't receive a definitive answer from the  
IESG, but a clear message was received from Mark Townsley that it is  
reasonable for the group to consider the hardware implications of our  
work -- both compatibility with currently deployed hardware, and the  
hardware architectures we might want to support in the future.

After much discussion with the interested IESG members, the document  
editors, the proponents of both solutions and some people who have  
proposed compromise solutions, the chairs believe that the key  
technical difference between these two proposals is which hardware  
architecture(s) they will support.  There are currently two different  
classes of AC hardware deployed, and variants on both of these  
architectures may be deployed in the future:

- Single-Processor:  In this architecture, the control plane and the  
data plane run on a single processor.  The demultiplexing of control  
and data packets happens on that processor.

- Separate Data & Control Planes:  In this architecture, the data and  
control planes run on separate processors (and possibly on separate  
cards), typically connected via a switching fabric.  This is a common  
hardware architecture for higher-end routing and switching hardware,  
and it relies on a port-based splitting/load-balancing approach to  
separate the control and data traffic.  For CAPWAP to work  
efficiently on these systems, it must be possible to distinguish the  
control and data traffic in the switching hardware, which is  
typically done based on the five-tuple of the send & recv IP  
addresses, the protocol (UDP), and the send & recv port numbers.  The  
switching hardware cannot do the type of deep packet inspection  
required to demultiplex on CAPWAP header fields.

The 2-port approach supports both the "Single-Processor" AC  
architecture and the "Separate Data & Control Planes" AC  
architecture.  Proponents of this solution believe that it is  
important to support the "Separate Data & Control Planes"  
architecture efficiently, both for compatibility with currently  
deployed hardware and to allow this hardware architecture to be used  
for future CAPWAP-enabled products.

The mux approach will only operate efficiently on "Single-Processor"  
systems. as it relies on the ability to demultiplex the control and  
data traffic using CAPWAP header information.  Proponents of this  
solution believe that it will simplify CAPWAP software  
implementation, and that it makes NAT traversal (when the AC and the  
WTPs are on different sides of a NAT) simpler to configure.

This complexity is a consequence of the choice to tunnel all WLAN  
data traffic to the AC.  In split-MAC local-forwarding mode, only the  
control plane traffic would be sent to the AC, and data plane  
forwarding would be handled by the WTPs themselves.

We've heard from a couple of strong voices on this issue. but now  
we'd like to hear from the rest of the WG...

Which hardware architecture(s) does the CAPWAP protocol needs to  
support?

Specifically, do you think that it should be a requirement to   
support efficient operation on currently deployed and future ACs that  
follow the "Separate Control & Data Planes" architecture described  
above?  Or do you think that it would be acceptable to produce a  
somewhat cleaner and simpler protocol that will not work efficiently  
on those ACs?

Please send your response by Thursday, October 5th (two weeks from  
today), so that the chairs can gauge the consensus of the WG in this  
matter.

After we have an understanding of which hardware architecture(s) the  
CAPWAP protocol needs to support, we will make an effort to sort  
through the various proposals and counter-proposals that meet that  
requirement.

Thanks,

The CAPWAP Chairs
Dorothy Gellert, Mahalingam Mani & Margaret Wasserman

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

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

---

From: "James Kempf" <[email-masked]>
Date: Thu, 21 Sep 2006 09:32:33 -0700

Mark's points about better compatibility with high performance hardware of 
the two port solution sound compelling to me, so I support that.

            jak