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

[Pat R. Calhoun (pcalhoun]

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

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.

<PRC> So just using LWAPP as an *example*, there are very few policies which are intended to guard the AC from unnecessary packets. So before the Add-Mobile message is sent by the AC, the AP will only accept 802.11 mac mgmt packets from the client. Once associated, the AC will send an Add-Mobile to the AP with a specific policy. The policies are very straight forward, allow everything, allow 802.1x, allow nothing. If you believe that inspecting a SNAP protocol id is too heavy weight, then we should discuss this, but personally, I like to conserve my AC as much as I can.


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.

<PRC> well, you are really overloading this. Look at the above process. It's rather simple.

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.

<PRC> Before I reply to this, I will let you reply to the above. Once I understand your position I will respond.