Subject: Re: [Capwap] New mux header for CAPWAP

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 9 Jun 2006 06:47:53 -0700

Thanks for the clarification, Scott. That is helpful. Let me ask a
separate
question. The protocol currently allows the CAPWAP control and data
flows
to be sent to separate devices. While I admit that the protocol isn't
complete
in this area, and is probably something that would need to be worked out
in
a future version of the CAPWAP protocol.

However, the MUX implies (at least to me) that the destination of both
the
control and the data plane MUST terminate on the same device. This is
particularly
troubling as 802.11N is coming our next year, and if one believes that
APs 
will be able to deliver up to 400Mbps, then scaling will quickly become
a
problem.

As service providers and large enterprises deploy this technology, the
expectations
of a high AP count supported on an AC (with minimal oversubscription)
will become expected, but I feel we are creating a protocol that forces
vendors
to make changes to the protocol that pushes it in way that it isn't
compatible with
the specification in order to deal with the market expectations.

I think this expands on the scaling issues raised by Rohit.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: Scott G. Kelly [mailto:[email-masked]] 
> Sent: Thursday, June 08, 2006 3:33 PM
> To: Rohit Suri (rsuri); Charles Clancy; [email-masked]
> Cc: [email-masked]
> Subject: Re: [Capwap] New mux header for CAPWAP
> 
> Hi Rohit!
> 
> >I have been reading through the conversations on this and I 
> think there 
> >is a bigger issue that has not been considered. Not allowing 
> separation 
> >of data and control plane by using easy to recognize method 
> such as UDP 
> >ports would restrict system scaling. Consider for the moment 
> the fact 
> >that because we are bundling the channels into a single 
> crypto stream, 
> >it will become impossible to separate the control and data planes.
> 
> I think you may have misunderstood: the data and control 
> channels will not be bundled into a single crypto stream (not 
> ever, in my view). Even if someone implements data channel 
> encryption, it will almost certainly have to be independent 
> of control channel encryption in all cases. My gut feeling is 
> that there would be serious operational issues otherwise in 
> terms of anti-replay and other channel interactions. I 
> suppose it's possible that there is *some* scenario where you 
> could combine the two - but I don't currentlly believe this 
> could be done in general for capwap.  
> 
> > I understand that this is not currently in the protocol, 
> the reality 
> >is that creating such a restriction today will dictate 
> future systems. 
> >The side effect I believe is being lost is that an AC can only be as 
> >fast as a single DTLS crypto accelerator. As faster 802.11 
> technologies 
> >come around, such as 802.11n, there will be a need for bigger and 
> >faster systems. In order to solve this, we will in the 
> future have to 
> >remove the MUX and allow for the separation.
> 
> Like I said, the channels won't be bundled together. Also, 
> this and previous posts make me think there's a fundamental 
> misunderstanding about DTLS.  This is really important to 
> understand: DTLS does not care what sort of transport is 
> underneath. It is oblivious to whether it runs over UDP, GRE, 
> TCP, SMTP (yes, you could even send dtls records in emails), 
> or CAPWAP... whatever. It is completely transport-agnostic.
> 
> That means you could multiplex virtually any number of DTLS 
> sessions over the same transport session (e.g. using the same 
> UDP port), and then demultiplex them at the receiving side.  
> This is true whether your transport is UDP or even ethernet, 
> for that matter.  
> 
> Any DTLS crypto accelerator will have to be able to handle 
> mutliple simultaneous DTLS sessions (just like SSL/TLS 
> accelerators).  Some will be capable of doing their own 
> session lookup based on the record header, but even for the 
> cheapest ones (which ostensibly would not be used in high end 
> systems),  it is a simple matter for the receiving AC to 
> distribute independent dtls streams to parallel crypto 
> accelerators, and contrary to what we've heard on this list,  
> software, fpga's, and network processors are all well-suited 
> to and commonly used for such tasks. Also, FPGAs and network 
> processors which can be used for this purpose are commonly 
> included in ACs available on the market today.
> 
> >I think system scaling is much bigger issue than NAT, which can be 
> >addressed by adding an keepalive mechanism in the data plane. We can 
> >also do this only when we detect a NAT is in play (look at outer IP 
> >address vs. a message element in the protocol). So we can 
> have our cake 
> >and eat it too.
> >
> >Therefore, I personally feel very uncomfortable crippling future 
> >products to up front protocol development time.
> 
> I don't know. I get the impression that what we are actually 
> being asked is to cripple the protocol in order to match up 
> with past products (i.e. those legacy switching products that 
> can only classify based on ports). I must admit, I'm kind of 
> surprised by such arguments, given the rich classification 
> capabilities described by NBAR. 
> 
> Anyway, I don't think there really are scaling issues, unless 
> we are constrained to combining AC functionality with legacy 
> switching gear. Otherwise, there is nothing to prevent us 
> from building systems which meet our needs as throughput 
> climbs. And as someone else pointed out in a related 
> discussion, "the purpose of capwap is not to make <ACs> 
> cheaper" - I substituted ACs for APs, but I don't think 
> anything is lost in translation. 
> 
> Scott
> 
> _________________________________________________________________
> 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: Scott G Kelly <[email-masked]>
Date: Fri, 09 Jun 2006 07:18:00 -0700

Hi Pat,

> will be able to deliver up to 400Mbps, then scaling will quickly become

I don't see how this is implied. Assuming you had the backend signalling 
in place, I think the two cases are equivalent. Am I missing something?

Scott

---

From: "David T. Perkins" <[email-masked]>
Date: Fri, 9 Jun 2006 08:44:12 -0700 (PDT)

HI,

On the below.....

First, I believe the packet diagrams show quite clearly that
a packet header is needed to distingush between a protected
and unprotected payload. This is independent from the 
transport address used on data vs control traffic.

Secondly, I sent out email sometime back that compared
a localMAC to a splitMAC (where the splitMAC uses a
different transport for control and data). I think
this was not understood. The issue is that when you
put in the instrumentation for the user traffic
(with the plan of making the attributes available
via an SNMP agent on the AC), where do you put
the instrumentation. If the instrumentation is
NOT on the AC, then you have to provide a
mechanism for the values generated by the 
instrumentation to be transported to the AC. The CAPWAP
protocol supports transportation of values
from WTPs to ACs. However, it doesn't currently
have a mechanism to transport the values
for the termination of a arbitary transport
endpoint of a "data tunnel". Thus, to support
both localMAC and splitMAC(where the the
data tunnel is terminated at a transport
different than the control transport),
we need to define additional message elements
transport the values from instrumentation
in WTPs. 

> CTO, Wireless Networking Business Unit

Regards,
/david t. perkins