Subject: RE: [Capwap] Taxonomy Recommendations

From: "Sadot, Emek (Emek)" <[email-masked]>
Date: Tue, 28 Jun 2005 02:14:31 -0400

Pat,

We will just have to agree to disagree on whether or not the CAPWAP
protocol should serve as a platform for more-then-just-two distinct
architectures.

I fail to see the NAT problem you described.

Regards,
Emek

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Pat Calhoun
Sent: Tuesday, June 21, 2005 5:34 PM
To: Sadot, Emek (Emek); 'James Kempf'; [email-masked]
Subject: RE: [Capwap] Taxonomy Recommendations

Emek,

I'd like to address the two main points you've made in your e-mail.

1. Keep the data path short. I agree that there are some challenges when
an AC is situated very far from the WTP, and that's the exact reason why
one does need what I call Local AP in the taxonomy recommendations
draft.
However, most "CAPWAP-like" deployments out there really don't fall
under the category you mention - all ACs are located topologically near
the the WTPs, and in such cases having the data path centralized allows
a powerful AC to perform many policy, security and mobility related
functions that would be hard to do on a standalone WTP (but by being
centralized allows for these functions to execute even across mobility
events). Just using one example, what if NAT were to be provided on the
WTP, how could the network converge in understanding what flows are
active, and the related port mapping? Hence my recommendation for Split
and Local AP - where the former tunnels the data to the AC and the
latter does not. The customer can use one or the other, mostly based on
topological requirements.
2. Single point of failure. I've addressed this in prior e-mails, and
the LWAPP protocol addresses this. Further, if a WTP relies on an AC,
you have a point of failure regardless. So this needs to be addressed in
a protocol, and it's not just the data path that's at stake here.

I realize we're not in complete agreement on this topic yet, but I still
do believe that reducing the options is a feature, not a bug. 

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Sadot, Emek (Emek)
> Sent: Monday, June 20, 2005 11:43 PM
> To: James Kempf; Pat Calhoun; [email-masked]
> Subject: RE: [Capwap] Taxonomy Recommendations
> 
> Jak
> 
> The main reason I see to bridge frames at the WTP is to keep session's

> shortest path (diminish delay, latency, jitter, etc., for real-time 
> application such as VoWLAN). For example:
> AC at NYC and WTP located at London; London office has two or three 
> legs to the external world: (a) VPN/FR/Lease line to NYC main office, 
> (b) local PSTN link and (c) local Internet service / exist to local 
> ISP. Wi-Fi voice call from London office better not be traveled via 
> NYC if not absolutely necessary.
> 
> AC as a single point of failure is another point. Sustain existing 
> Wi-Fi sessions while AC experience failure or experience network 
> outage between WTP and AC.
> 
> These are my points, other may have different view which is perfectly 
> fine. Different architectures address different environments and 
> different solutions. Just because a vendor can't figure out how 
> another may solve a perceived problem doesn't mean it can't be done 
> nor is it relevant to CAPWAP.
> 
> I believe the group need to come up with a mechanism / process of how 
> to decide on labor division. Only two distinctive options, Split and 
> Local, is a bit too restricted.
> 
> If I am not mistake there were four objectives which ignite
> CAPWAP: (a) AP is an IP-addressable device requiring management, 
> monitoring, and control (b) Distributing and maintaining a consistent 
> configuration, (c) Difficulty in dealing effectively with the dynamic 
> nature of large WLAN and
> (d) Securing access to the network and preventing installation of 
> unauthorized AP.
> 
> CAPWAP is about Control and Provisioning. It says nothing about the 
> user's data frames path.
> One more point, it's not mandatory that AC will be a dedicated HW 
> appliance. It could be a piece of software runs on any platform.
> Overwhelming the AC with user's data implicitly dictates the former.
> 
> It should be the other way around - one should come with a very good 
> reason to execute bridging at the AC. In my opinion the protocol shell

> facilitate both, letting the operator the freedom to chose.
> To name a few reasons to consider bridging at the AC:
> 1. Statistics: AC can extract raw statistics / info from
> 802.11 frames.
> 2. Apply policy at the AC rather then at the WTP - simpler WTP.
> 3. If AC is a Layer 3 roaming facilitator.
> 4. If AC implements 802.11 encryption / decryption.
> 
> (apologize, it turn out the answer is a bit too long that I
> expected) Emek
> 
> -----Original Message-----
> From: James Kempf [mailto:[email-masked]]
> Sent: Monday, June 20, 2005 8:22 PM
> To: Sadot, Emek (Emek); Pat Calhoun; [email-masked]
> Subject: Re: [Capwap] Taxonomy Recommendations
> 
> Emek,
> 
> Take for example the IS service: where it fits in Slit and Local - WTP

> or AC? I would disagree the authors conclusion (section 5 first 
> bullet) w.r.t. bridging function, and believes we can, and should, 
> allow the operator to chose.
> 
> jak>> OK, so what criteria would cause an operator to choose
> bridging at
> 
> jak>> the
> WTP versus bridging at the AC?
> 
>         jak
> 
> 
> 
> _______________________________________________
> Capwap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/capwap
_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap

_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap

---

From: "Pat Calhoun" <[email-masked]>
Date: Tue, 28 Jun 2005 15:10:56 -0700

One question I do have for you is that if your vision of the CAPWAP protocol
is really a negotiation of various features allowing for any permutation,
then why is our definition binary (meaning split vs. local). In your mind
what consistutes a split vs local architecture, and why do we need two modes
of operation vs one mode that can negotiate a number of configuration
parameters.

WRT the NAT text, I was trying (unsuccessfully) to provide an example where
centralization of services makes sense. The example here was NAT. Imagine if
NAT was implemented on every WTP. As you know, a NAT keeps track of all
flows for an individual user, and when a mobility event occurs, the flow
state would have to be transferred from one WTP to another - a difficult
problem to resolve. Hence such advanced services are natural ones to be
centralized in the AC.

Pat Calhoun

> From: Sadot, Emek (Emek) [mailto:[email-masked]] 
> Sent: Monday, June 27, 2005 11:15 PM
> To: Pat Calhoun; James Kempf; [email-masked]
> We will just have to agree to disagree on whether or not the 
> CAPWAP protocol should serve as a platform for 
> more-then-just-two distinct architectures.
> 
> [mailto:[email-masked]] On Behalf Of Pat Calhoun
> 1. Keep the data path short. I agree that there are some 
> challenges when an AC is situated very far from the WTP, and 
> that's the exact reason why one does need what I call Local 
> AP in the taxonomy recommendations draft.
> However, most "CAPWAP-like" deployments out there really 
> don't fall under the category you mention - all ACs are 
> located topologically near the the WTPs, and in such cases 
> having the data path centralized allows a powerful AC to 
> perform many policy, security and mobility related functions 
> that would be hard to do on a standalone WTP (but by being 
> centralized allows for these functions to execute even across 
> mobility events). Just using one example, what if NAT were to 
> be provided on the WTP, how could the network converge in 
> understanding what flows are active, and the related port 
> mapping? Hence my recommendation for Split and Local AP - 
> where the former tunnels the data to the AC and the latter 
> does not. The customer can use one or the other, mostly based 
> on topological requirements.
> 2. Single point of failure. I've addressed this in prior 
> e-mails, and the LWAPP protocol addresses this. Further, if a 
> WTP relies on an AC, you have a point of failure regardless. 
> So this needs to be addressed in a protocol, and it's not 
> just the data path that's at stake here.
> 
> I realize we're not in complete agreement on this topic yet, 
> but I still do believe that reducing the options is a 
> feature, not a bug. 
> 
> Pat Calhoun