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

From: "Scott G. Kelly" <[email-masked]>
Date: Thu, 28 Sep 2006 10:44:09 -0700 (GMT-07:00)

I was going to just leave this, but there are some things that might best be called misconceptions in Margaret's summary below. I had an offline exchange with Margaret about this, and I have no doubt that this just didn't come out quite the way she meant it, so please don't view this as offensive. 

I am quite tired of arguing on this topic, but since the associated email archive essentially represents a record of our deliberations, I think for whatever it's worth, it's important that it accurately reflect what's gone on here.  So, I've inlined some clarifications below:

Margaret Wasserman wrote:
>
> 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.

This is one of the mischaracterizations I see. The issues have nothing to do with how many processors there are - they have to do with separation of control and data planes, and with the switching facility used to distribute packets between these two planes. This is a critical distinction. 

> 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.

Based on the clarification above, it should be clear that this is also a mischaracterization. Either approach will work in either of the architectures, and in particular, in either of the architectures _as they are deployed today_. The real problem appears to be that one vendor has made a conscious choice to limit the control/data switching facility to 5-tuple-based solutions. Here's the picture Pat used to explain this:

   +-----------------------------------------------+ 
   | +---------+       +--------+       +--------+ |
   | |         |       |        |       |        | |
   | | Control |       | Data 1 |       | Data 2 | |
   | |         |       |        |       |        | |
   | +---------+       +--------+       +--------+ |
   |      ^                ^              AC       |
   +------|----------------|-----------------------+
          |                |

     +----|----------------|---------------------+
     |    \                |        Ethernet     |
     |     ----------------+         Switch      |
     +---------------------|---------------------+
                           |
                      +---------+
                      |         |
                      |   WTP   |
                      |         |
                      +---------+

I can't say I've cracked open WLAN controllers from every vendor in the market, but I've seen the insides of at least 5, and all of them had either NPU(s) or NPU-like capabilities. The picture above represents an implementation decision that is not constrained by currently deployed wlan technology. That's a really important point.

> 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.

This also seems mischaracterized, because in all currently defined split-MAC modes, a data channel must be established in order to handle 802.11 management and authentication frames (even when you're doing local bridging of the data). 
 
> 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

I think the working group has a right to know that when we took this offline and attempted to bring in experts, it came out that there really were *no* QoS or routing issues, and that all along, this had been about integrating airespace wlan controllers with catalyst switching gear. We wasted weeks chasing red herrings and misdirection. Gotta wonder what that was about.

In any event, Margaret is right: the working group needs to speak up so we can close this and move on. I'm done arguing about this, and life will go on one way or another regardless of what we choose. But at least, we should all be clear on what's happened here, and go into this eyes wide open.

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: Margaret Wasserman <[email-masked]>
Date: Thu, 28 Sep 2006 15:24:13 -0400

Hi Scott,

I'd just like to state, for clarity, that the message you are  
responding to came from all three of the CAPWAP chairs.  Although I  
drafted and sent the message, it did reflect input from Mani and  
Dorothy.

This response is just from me, and the opinions expressed are mine.   
The other chairs may not agree.

On Sep 28, 2006, at 1:44 PM, Scott G. Kelly wrote:
> This is one of the mischaracterizations I see. The issues have  
> nothing to do with how many processors there are - they have to do  
> with separation of control and data planes, and with the switching  
> facility used to distribute packets between these two planes. This  
> is a critical distinction.

I agree with you comment, and your private note on this subject was  
very helpful to advance my thinking on this matter. However, I do not  
think that your correction fundamentally changes the situation.  It  
would have been better if we had characterized these systems based on  
how received packets are handled, rather than based on the number of  
processors in the system, but that doesn't change the fact that there  
are two type of systems:

(1) Those where the packet is initially received by a component (such  
as a NPU or a CPU) that can distinguish between control and data  
traffic by looking at the CAPWAP headers.  There may be additional  
processors on this type of systems, so using the phrase "single- 
processor" to describe these systems was not correct.

AND

(2) Those where the packet is initially received by switching  
hardware that can only efficiently distinguish between control and  
data traffic using a five-tuple that includes the UDP ports.

There are both high- and low-performance systems that correspond to  
each architecture.

> Based on the clarification above, it should be clear that this is  
> also a mischaracterization. Either approach will work in either of  
> the architectures, and in particular, in either of the  
> architectures _as they are deployed today_. The real problem  
> appears to be that one vendor has made a conscious choice to limit  
> the control/data switching facility to 5-tuple-based solutions.

I am personally aware of switching equipment from more than one  
vendor that is restricted to using a five-tuple for switching  
incoming traffic.  I am not currently aware of whether these systems  
are sold as WLAN switches, but I believe that many of them could be  
software upgraded to serve in that role.  Given the widespread  
deployment of switches that employ this architecture, I believe that  
it is desirable to make sure that CAPWAP can be added, as a software  
upgrade, to systems of this type.

I could express some opinions about which architecture is better, but  
my opinion on that subject is immaterial.  Both systems are widely  
deployed, and I think that we are likely to see wider deployment of  
CAPWAP if it can work well on both architectures.

> This also seems mischaracterized, because in all currently defined  
> split-MAC modes, a data channel must be established in order to  
> handle 802.11 management and authentication frames (even when  
> you're doing local bridging of the data).

Perhaps Mani could respond to this point, as he was the originator of  
this text.

> In any event, Margaret is right: the working group needs to speak  
> up so we can close this and move on. I'm done arguing about this,  
> and life will go on one way or another regardless of what we  
> choose. But at least, we should all be clear on what's happened  
> here, and go into this eyes wide open.

Thanks for your comments, and for your continuing efforts to keep  
this work moving forward.

Margaret