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

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 31 Mar 2006 08:21:40 -0800

Scott,

I believe that the diagram you had in your e-mail is incorrect. Instead,
I'd like
to propose the following figure:

                                                +-------------------+
                                                |         AC        |
                                                |   +----------+    |
                                     +----------+-->| Control  |    |
+-------+ control   (========)      /           |   +----------+    |
|       |<-------->(          )<---/            |         ^         |
|  WTP  |          (   NAT    )                 |         | binding ctrl
|       |<-------->(          )<---\            |         |  protocol?
+-------+  data     (========)      \           |         v         |
                                     \          |   +----------+    |
                                      +---------+-->|   Data   |+   |
                                                |   +----------+|   |
                                                |    +----------+   |
                                                +-------------------+

I believe that the above scenario is one that CAPWAP must be able to
support
in order to allow to be able to create scalable systems based on the
standard.
In fact, it is a feature that is already part of the specification,
albeit it 
is possible that the NAT feature poses challenges to this scenario.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: Scott G. Kelly [mailto:[email-masked]] 
> Sent: Wednesday, March 29, 2006 11:30 AM
> To: capwap; Pat Calhoun (pacalhou)
> Subject: split AC-WTP tunneling (was RE:[Capwap] a necessary 
> and sufficient capwap base protocol)
> 
> 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: "Scott G. Kelly" <[email-masked]>
Date: Fri, 31 Mar 2006 08:50:23 -0800 (GMT-08:00)

Hi Pat,

>Pat Calhoun wrote:

A few comments: first, incorrect by whose definition? If we allow separate termination points for data channel and control channel, the diagram I submitted is a valid deployment scenario, and you can be sure someone will try it.

Second, I'm not sure I know what your diagram implies - is this supposed to refer to two blades in one chassis? If so, why are two IP addresses required? Such switching could easily be accomplished by looking at the mux header.

Finally, it's not a specification yet, so let's not rush to declare lwapp-03 immutable. The wg never agreed that everything in lwapp-03 must be implemented verbatim, only that lwapp is a good starting point.

Scott

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 31 Mar 2006 13:29:05 -0800

> A few comments: first, incorrect by whose definition? If we 
> allow separate termination points for data channel and 
> control channel, the diagram I submitted is a valid 
> deployment scenario, and you can be sure someone will try it.

By my definition, of course :)

My point is that the scenario you had drawn was inconsistent with 
the scenario that I was thinking.

> 
> Second, I'm not sure I know what your diagram implies - is 
> this supposed to refer to two blades in one chassis? If so, 
> why are two IP addresses required? Such switching could 
> easily be accomplished by looking at the mux header.

Please note the multiple data planes in the picture. That said, it
is possible that the MUX would work, but would be great if you could
provide more concrete details.

> 
> Finally, it's not a specification yet, so let's not rush to 
> declare lwapp-03 immutable. The wg never agreed that 
> everything in lwapp-03 must be implemented verbatim, only 
> that lwapp is a good starting point.

Fair enough. However, I'd prefer that we have widespread agreement prior
to pulling features out of the spec. 

PatC