Lwapp Mailing List: RE: Another Way to Think about CAPWAP

[Sadot, Emek (Emek) (esadot]

Title: RE: [Lwapp] Another Way to Think about CAPWAP

That's precisely against the light and centralizing-functionality concepts.

Simply put, instead of “only” encapsulating 802.11 frames and send them over to the AC the AP shall inspect frames and performs lookup tables. The AP becomes non-light in terms of Cpu-duties and memory space.

Centralizing functionality is also spoiled - the AC will need to download the entire rules list to all APs. Update rules would become an issue as well, since distribution is needed now.

Furthermore, complexity is added to the user notification scheme. CAPWAP protocol will need to support AP to AC notification of such “rejecting due to policy X” event.

And last, saving “unnecessary packets, conserves bandwidth and CPU cycles” is still to be proven, since distribution of policy rules to APs and AP to AC notification demands the same resources.

Emek

(BTW, allow traffic from a particular MAC address at the AP is especially odd since STA’s association and authentication are, in any case, subject to the AC approval).

-----Original Message-----
From: Pat R. Calhoun [mailto:pcalhoun [at] airespace.com]
Sent: Tuesday, 18 November, 2003 5:01 PM
To: Sadot, Emek (Emek); James Kempf; Paulo Francisco; Jim Murphy; Branislav Meandzija; LWAPP
Subject: RE: [Lwapp] Another Way to Think about CAPWAP

Well, for instance, if you look at the LWAPP draft, you can tell the AP to only allow 802.1x packets for a given mobile station. This minimizes unnecessary packets to the AC, conserves bandwidth not to mention CPU cycles in the AC.

PatC

-----Original Message-----
From: Sadot, Emek (Emek) [mailto:esadot [at] avaya.com]
Sent: Tue 11/18/2003 6:58 AM
To: Pat R. Calhoun; James Kempf; Paulo Francisco; Jim Murphy; Branislav Meandzija; LWAPP
Subject: RE: [Lwapp] Another Way to Think about CAPWAP

What is the rational behind pushing policies to the AP? Doesn't centralizing functionality at the AR level is one of the AR/AP architecture motivations? Besides doesn't it contradict the "L" concept?

Emek

-----Original Message-----
From: lwapp-admin [at] frascone.com [mailto:lwapp-admin [at] frascone.com]On Behalf Of Pat R. Calhoun
Sent: Tuesday, 18 November, 2003 1:42 AM
To: James Kempf; Paulo Francisco; Jim Murphy; Branislav Meandzija; LWAPP
Subject: RE: [Lwapp] Another Way to Think about CAPWAP




>LWAPP also consists of an in-band configuration protocol to the AP -
allowing
>a state machine to use the same control mechanism from the AC to the AP.

Is this to keep the state machine synchronized between the two sides? Or is
there some other reason for it?

<PRC> Multiple reasons. One is to push down policies (allow traffic for a particular
MAC address), while others are for configuration reasons (change channel to x on radio y).

PatC