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

[Branislav Meandzija (bran]

> ACs terminate user data streams, possibly applying forwarding 
> policies.
> The AC may act in a VLAN or Vrouter environment. The access (V)LAN
> between the AC and the AP may not be the network that the end user
> (mobile station) actually becomes associated with.
>  
> I think the objective is to keep APs lightweight, burdening 
> evey AP with the
> features listed here or, even more humorously, running these 
> features over
> SNMP is a non-starter.
>  
> [PF>] The only thing being that IEEE does already specify a 
> MIB format for administering an AP. Pretty much any AP 
> implementation does already implement such MIB and most 
> likely will in the future. It would simply suffice to provide 
> a message set for encapsulation of these messages, thus it 
> would maximize leveraging of existing infrastructure. Plus 
> I'm afraid that if CAPWAP proceeds with the specification of 
> its own configuration message set it will be very hard to 
> keep up with future configuration requirements at the AP. 
> While is fairly easy to add an OID to an SNMP infrastructure, 
> from what I see of LWAPP specification the actual message set 
> would have to be extended every time new functionality is 
> required, such as vendor extensions (because you know that in 
> the end each AP vendor will have different features that may 
> require special configuration). 
> 
> Also, we have to re-base our assumptions as to what it means 
> to be 'lightweight' for an AP.  
> Basically the problem is to try to address the deployment of 
> traditional APs which are known as 'fat'. What makes these 
> AP's 'fat' is the amount of features they natively support 
> such as DHCPServer, RadiusClient and some even have full 
> functional routing stacks in them (RIP/OSPF). That all adds 
> up to a complex and expensive AP. 
> Therefore the aim of a 'lightweight' AP is to reduce 
> complexity and cost by removing from the AP as many features 
> as it is possible. This is accomplished by moving these 
> expensive features to a centralized controller. Thus if in 
> the end you end up with an AP on which all you need to deploy 
> is an IP stack, a LWAPP translation app, an SNMP agent and an 
> 802.11 stack, you've already trimmed most of the 'fat'.
> 

I guess that makes a compelling argument to go with SNMP.

Branislav