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

From: "Partha Narasimhan" <[email-masked]>
Date: Thu, 5 Oct 2006 14:26:35 -0700

My two cents below, FWIW.

- Assuming that most currently deployed L2 switches can be upgraded to
support CAPWAP merely with a software upgrade is well beyond the limits
of what I would normally assume in a typical day in my life. 

- In all of the debate, I haven't seen the proponents of the two-port
solution acknowledge significant additional complexity this solution
imposes on the entire protocol. Overall, it increases the
cost/complexity of implementation and/or trouble-shooting over the
single-port mux solution. 

- The single-port mux solution can be made to work on existing gear,
except it may or may not be as efficient as an implementation on some
other gear that is more recent or being designed now. The current
protocol design work should not be influenced by the inefficiencies of
implementing it in gear that was designed well before the need for
CAPWAP crept into people's minds. 

- Choosing a more complicated solution over a simpler one would also
lead to the protocol not getting deployed because of the cost of
implementing it. I am especially concerned whether the WTP vendors can
bear the increased cost of implementation and interoperability testing
and whether this will influence their decisions to drop support for
CAPWAP in their gear. This is the other side of the coin to the argument
that designing the protocol, albeit with a more complex solution, to fit
older implementations would increase the chance of it being widely
deployed. 

Thanks
partha

PS: While debating this issue, we went through what we now know were
detours along non-existent routing and QoS issues. Makes one wonder what
is really behind every long and drawn-out discussion in this WG.

-----Original Message-----
From: Margaret Wasserman [mailto:[email-masked]] 
Sent: Thursday, September 28, 2006 12:24 PM
To: Scott G. Kelly
Cc: capwap
Subject: Re: [Capwap] 2-Port/Mux Issue Discussion

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

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

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

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

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

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

---

From: "Dorothy Stanley" <[email-masked]>
Date: Thu, 5 Oct 2006 15:39:41 -0700

All,

Summary:

In one current (and potentially future) AC product implementation(s),
packets are initially received by component
hardware that can only efficiently distinguish between control and
data traffic using a five-tuple that includes the UDP ports. These
implementations
cannot efficiently distinguish between control and data traffic within a
single port.

In some  5 known current (and potentially future) AC product
implementations, packets are initially received by a component (such
as a NPU or a CPU) that can efficiently distinguish between control and data
traffic by looking at the CAPWAP headers. These implementations can also
distinguish between
control and data traffic using a five-tuple that includes the UDP ports.

Questions:

a)      Should the CAPWAP protocol include support for a single port mode?
Answer: Yes. to enable capable product implementations to take advantage of
the simplicity, reduced
complexity and  NAT traversal benefits of single port mode operation.

b)      Should the CAPWAP protocol include a means to enable its efficient
implementation on UDP-port-only
product implementations?

Answer: Desired, not required as support, though not efficient, of a single
port mode seems to be available..

       It is very disappointing to see the the time and energy of the WG so
wantonly wasted in pursuit of non-existent
issues surrounding this topic.
 Dorothy

---

From: "Chiu, Ran-Fun" <[email-masked]>
Date: Thu, 5 Oct 2006 18:40:43 -0500

Is this the consensus? Or, we are still looking for a consensus? The
current draft has a two-port UDP solution, but does not specify how to
handle Discovery (or, I missed something). Do we need a third port?  We
support the two-port solution if the Discovery issue is resolved. We
also can agree to a one-port solution. The WG has to make a decision.

Ran-Fun Chiu

________________________________

From: Dorothy Stanley [mailto:[email-masked]] 
Sent: Thursday, October 05, 2006 3:40 PM
To: Partha Narasimhan
Cc: Margaret Wasserman; capwap
Subject: Re: [Capwap] 2-Port/Mux Issue Discussion

All,

Summary: 

as a NPU or a CPU) that can efficiently distinguish between control and
data

Questions:

a)       Should the CAPWAP protocol include support for a single port
mode? 

Answer: Yes. to enable capable product implementations to take advantage
of the simplicity, reduced 
complexity and  NAT traversal benefits of single port mode operation.

b)       Should the CAPWAP protocol include a means to enable its
efficient implementation on UDP-port-only
product implementations?

Answer: Desired, not required as support, though not efficient, of a
single port mode seems to be available..

      It is very disappointing to see the the time and energy of the WG
so wantonly wasted in pursuit of non-existent 
issues surrounding this topic.

Dorothy

Thanks
partha

-----Original Message-----
From: Margaret Wasserman [mailto:[email-masked]]
Sent: Thursday, September 28, 2006 12:24 PM
To: Scott G. Kelly
Cc: capwap
Subject: Re: [Capwap] 2-Port/Mux Issue Discussion

Hi Scott,

AND

Margaret