Subject: RE: [Capwap] Taxonomy Recommendations

From: "Sadot, Emek (Emek)" <[email-masked]>
Date: Tue, 21 Jun 2005 02:42:57 -0400

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

---

From: "Pat Calhoun" <[email-masked]>
Date: Tue, 21 Jun 2005 07:33:40 -0700

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
> 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 
> 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.
> 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.
> (apologize, it turn out the answer is a bit too long that I 
> expected) 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.
>

---

From: "James Kempf" <[email-masked]>
Date: Tue, 21 Jun 2005 09:34:16 -0700

Emek,

jak>> Is this a realistic deployment scenerio? I don't know what the RTT
packet latency is between NYC and London, but from San Jose, we typically
get somewhere around 100-130 ms to Europe. I'm not sure that this would be
acceptable even for control traffic. I think that any deployment which would
experience delay/latency/jitter for application traffic might also have
problems for control traffic too.

jak>> Yes, that seems to be a realistic reason. It is also a reason for
thinking about mechanisms for failover of the WTC to another AC in the
control protocol. In some cases, it might be acceptable to have tunnel
failover slightly delayed; in others, possibly not.

...

jak>> I'm not so sure. There have been some arguments advanced why putting
the distribution function at the AC would be desirable. You list them below.

jak>> So it seems you are proposing to separate the control and data plane,
and then some way in the control protocol to negotiate how the data plane is
handled? Is that correct?

            jak