Subject: split AC-WTP tunneling (was RE:[Capwap] a necessary and sufficient capwap base protocol)

From: "Scott G. Kelly" <[email-masked]>
Date: Wed, 29 Mar 2006 14:30:11 -0500 (EST)

A few days ago I suggested that we should not be considering split tunneling in the base draft. Below is a quote, including Pat's response. I followed up previously, but I want to spend a bit more energy on this:

>> - split tunneling, where data channel terminates on a different 
>> endpoint than the control channel; this has definite security 
>> implications, and probably requires a secure inter-AC protocol, in 
>> addition to its own state machine loop(s). It's a corner case that 
>> many won't care about.
>
>Same as previous comment. This is mandatory for large scale deployments 
>and the protocol supports it already.

I've included a diagram in a text file attachment (sorry, but my webmail interface mangles ascii drawings). In the diagram, I've include a NAT cloud for good measure, but what I really want to draw attention to first is the inter-ac communication this requires.

The proposal is to allow the AC with which the control channel is established to tell the WTP to terminate its data channel on a different AC. I think this is a rather curious construct, since control channel overhead is relatively light, and it seems like the whole session could be pushed to AC-2 just as easily (isn't this sort of like load balancing?), but apparently some folks really want this functionality.

I've proposed not supporting this in the base spec, deferring it until later (assuming it turns out to be useful, of which I remain unconvinced). One reason is that it requires a back-end inter-AC protocol, and this MUST be secured - this is currently out of scope, and bringing it into scope for the base protocol will just about guarantee that we won't have interoperable implementations before *next* year at this time.

A secondary issue pertains to the complexity this introduces into the state machines in both ACs and the WTP. AC-1 must make sure that AC-2 can "handle" the WTP before telling the WTP to use AC-2. What if AC-2 can't take the load? And what about race conditions - what if WTP sends data before AC-2 is ready, or after AC-1 told AC-2 to tear down the session? And if there's a NAT, what if one channel is lost but the other one is still there? Or AC-2 turns out to be unreachable for some reason? Or AC-2 can't reach WTP?

This is just stream-of-consiousness rambling after 30 seconds of thinking about it - I'm sure there's plenty more complexity where that came from. This looks like a minority solution that will take lots of time plus a charter change to address. I suggest we defer this.

To be very clear, the fact that something is not in the base spec does not mean a vendor is not free to differentiate by adding the feature using VSA's or some such approach.

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: "David T. Perkins" <[email-masked]>
Date: Wed, 29 Mar 2006 11:49:45 -0800 (PST)

HI,

I haven't seen any vendors that support the architecture
as shown on your diagram. That is,
  a) having the control channel going to one AC
  b) having the tunneled data channel going directly
     to another AC

I have seen a product that supports multi-ACs where 
the data tunnel from a WTP is further tunneled from
the AC where the control channel is terminated to
another AC that supports the VLAN where the data
is needed to be delivered.

On first look at what you have described, my reaction is
that this seems to add more cost than the cost
savings by tunneling the data directly to another AC
instead of having the data tunneled between the ACs.

> To be very clear, the fact that something is not in the base spec does not mean a vendor is not free to differentiate by adding the feature using VSA's or some such approach.
Regards,
/david t. perkins