Capwap Mailing List: Re: New mux header for CAPWAP

[Pat Calhoun (pacalhou) (pcalhoun]

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

I am pulling some text from a previous post you had sent, which implies
that both control and data MUST terminate on the same system, which is
the point I tried to make in my scaling argument. I presume your
assessment
that one cannot split them up remains.

> If we go with separate ports, there are a number of unpleasant
consequences:
> - there will certainly be issues with NAT traversal; you now need to
> run keepalives over two channels, and even at that, the behavior will
> not be deterministic; busy NAT devices throw out existing dgram
sessions
> when they need the resources, and this will result in one channel up,
and
> one down; 
Which I claim is really not that hard to provide. We can define a NULL
802.11
packet, for instance - or even something more generic by defining a bit
in the
header. This is really trivial.

> - channel binding is ambiguous; it is not clear what data channel goes
> with what control channel unless we add explicit signalling, and this
> adds considerable complexity to the protocol.
This point you had previously made specifically states that one cannot
separate
both the control and the data channel. 

This said, this is also not not very complex to deal with. A WTP has a
specific
MAC address, called a BSSID, which is present in the CAPWAP header, and
is used
to perform the correlation between the control and data plane.

> - all of the added corner and race conditions and error handling
requirements
> add *significant* complexity to the state machines in both ends of the
> connection. That's bad.
I think it wouldn't hurt to go through the exercise to determine exactly
what this
really means so we can all be on the same page. Right now we have no
concrete
proof this is true.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

 

> -----Original Message-----
> From: Scott G Kelly [mailto:scott [at] hyperthought.com] 
> Sent: Friday, June 09, 2006 7:18 AM
> To: Pat Calhoun (pacalhou)
> Cc: capwap [at] frascone.com; Dorothy.Gellert [at] nokia.com
> Subject: Re: [Capwap] New mux header for CAPWAP
> 
> Hi Pat,
> 
> Pat Calhoun (pacalhou) wrote:
> > 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.
> 
> 
> Scott
> 
> 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
> 
> Archives: http://lists.frascone.com/pipermail/capwap
>