What's behind the CAPWAP flap?

With wireless vendors arguing over an access point protocol, here's a look at what the proposals actually say

By
Louise McKeag, Techworld
| Apr 13, 2004

Share

TwitterFacebookLinkedInGoogle Plus

If you take a chunk of the intelligence out of your Access Points (APs) and put it into a central management system—be it a set of WLAN switches, routers or dedicated controllers—in theory it should make your WLAN easier to manage, cheaper to build (see Access Points - beyond the thin/fat spat), and potentially give you the capability to mix and match cheap APs from different vendors.

But only if the communication between the APs and the controllers follows some sort of standard. Otherwise you’re well and truly tied in to one manufacturer.

LWAPPIt looked as if the interoperability issue was well on the way to being sorted. An IETF draft for the Light Weight Access Point Protocol (LWAPP) had been proposed by authors from Airespace, DoCoMo and Legra and several vendors were in favour, and starting to implement it. However it expired in December last year without a Working Group being formed to take it any further.

LWAPP was designed to remove the requirement for intelligent APs. Instead they could be thinned down to become just a remote RF extension to a controlling WLAN switch or router (called an Access Router — AR — in LWAPP terminology), although some manufacturers such as Trapeze Networks are in favour of a not-so-thin AP with a modicum of intelligence incorporated. According to the LWAPP specification, APs can be connected to an AR over either Layer 2 or Layer 3. They will pass the 802.11 frames received from end clients straight to the AR for all processing and forwarding out onto the wired LAN.

On power up, an AP sends a Discovery Request out over the wired network. The ARs reply, and the AP associates (joins) with an AR, which will now update its firmware if required, send all configuration information to it and provision it ready to go.

The Discovery Requests are broadcast packets — if the AR is separated from the AP via a routed interface, the LWAPP protocol can be run over UDP — presumably UDP broadcasting forwarding will have to be turned on in the router, although it was suggested in the specification that static AR IP addresses could be used, or DHCP or DNS, but this was regarded as outside the scope of the LWAPP specification, so never clearly defined.

CAPWAPRather than adopt LWAPP as it stood, however, the IETF has decided to form a Working Group to look at the overall management of APs. The Control and Provisioning of Wireless Access Points Working Group, including representation from Trapeze, Airespace, and Chantry among others, is currently working on an architecture specification for CAPWAP, which should be done by summer, but there is currently no timeline for defining the actual specification itself.

In the meantime, since they need something, manufacturers are continuing to use the LWAPP draft as best they can, assuming that at least some of its workings will be incorporated into CAPWAP, but according to Trapeze, every vendor has its own version, and they’re all slightly proprietary. Which means, unless individual switch and AP manufacturers form a private arrangement (such as Airespace and D-Link), no interoperability.

There’s also an issue in that it appears that CAPWAP doesn’t cater for multiple ARs (they’re ACs — access controllers in CAPWAP speak), which is something that will either need rectifying during its writing, or vendors will have to go their own way. It looks to be a couple of years before any standards-based products can be expected, so in the meantime you’ll need to start asking your suppliers whose version of LWAPP their kit works with if you want to be able to (eventually) choose your APs.

CAPWAP or CLAPTRAP? Let us know in our forums if you think this is a standard that will ever be any real use in actual IT environments.