This paper presents an overview of the Control and Provisioning of Wireless Access Points (CAPWAP) working group, and the proposals that have emerged from it. The paper covers the current architecture of enterprise WLAN deployments, as well as proposed protocols that attempt to simplify their management and configuration, and allow inter-vendor compatibility of access points (APs) and controllers. The Lightweight Access Point Protocol (LWAPP), Secure Light Access Point Protocol (SLAPP), and CAPWAP protocols are all discussed and compared. Current vendor solutions and interoperability is also covered, and the current state and trends in the enterprise WLAN market are discussed. Open source solutions such as OpenCAPWAP are also inspected, and compared to vendor solutions currently available.
CAPWAP, Control and Provisioning of Wireless Access Points, SLAPP, Secure Light Access Point Protocol, LWAPP, Lightweight Access Point Protocol, WLAN, Multi-vendor, Split MAC, Local MAC, Remote MAC, OpenCAPWAP, Centralized Management, Wireless, WLAN, AP, Access Point, Wireless Switch, Wireless Router
An overview of the architecture and protocols use in access point (AP) to controller communication in enterprise grade wireless networks.
The term CAPWAP is used for the Control And Provisioning of Wireless Access Points working group. The CAPWAP working group was created in the IETF in order to standardize and define a protocol to ease the implementation of large WLAN deployments that utilize the Controller-AP (Access Point) architecture. The nature of such systems is of such complexity, that vendor implementations can vary widely in their scope and features, leading to incompatibilities between vendors. The significant cost of enterprise level WLAN deployment, coupled with both hardware and software differences on Controllers and Access Points breeds vendor lock-in. Because a vendor change would require the purchase of duplicate Controller and AP hardware, it is often unfeasible for a wireless network to be migrated from one vendor to another. This lack of customer mobility leads to less innovative product offerings from the wireless vendors.
The size of many wireless networks in large companies and universities also introduces many problems of maintaining a consistent configuration across many similar devices, with potentially different hardware capabilities and physical locations. Vendors have provided individual solutions to these issues stated above. However, the implementations are proprietary and have different views on where functionality in the network should be.
The CAPWAP working group seeks to rectify this by specifying a protocol that ensures a common standard for APs and WLAN controllers to communicate with. Thus, the entire process of deploying an AP can be implemented in a vendor neutral format, from finding an initial controller, to deploying firmware updates, to configuration and access point redirection. Ideally controllers of any vendor could provision access points from any other vendor, provided they implement a common CAPWAP protocol. This would allow for more rapid reaction to new innovations in the WLAN sector, as well as improve implementation quality.
This paper is organized as follows: [Section 1] will talk about the goals of the CAPWAP working group. [Section 2] will talk about general architecture of current wireless 802.11 infrastructure, as well as discuss the differences between Split MAC, Local MAC, and Remote MAC layers in APs. [Section 2] will also focus on how so called "Fat APs" are managed and route traffic, as compared to "Thin APs". [Sections 3], [4], and [5] discuss 3 specific protocols that have been proposed, and discusses the differences between them. Next, [Section 6] will look at new trends in the CAPWAP space, and focus specifically on an open source alternative called OpenCAPWAP. Finally, [Section 7] will summarize the key concepts of CAPWAP.
A unified CAPWAP standard aims to be a protocol that could enable centralized wireless hardware utilize a simple, streamlined method of communicating between access points and controllers. As specified by the CAPWAP working group in the IETF (Internet Engineering Task Force), CAPWAP should address 4 main issues. Firstly, it should enable a centralized management solution of the various hardware in a typical WLAN deployment. Second, it should make configuration of multiple hardware types transparent, and ensure configurations are consistent across the network. Third, monitoring the status of both hardware and software configurations is necessary to ensure a properly operating network. And finally, ensuring network security, both from 3rd party hardware, such as rogue access points being connected to the network, as well as preventing the loss of network secrets from the physical theft of access points is also critical. [RFC3990] [Villani] [Jou04]
The challenges facing wireless networks with regard to standardized management and provisioning are difficult. Proposals for a CAPWAP protocol have been submitted to the CAPWAP WG for review. However, some have been met with criticism. 3 specific protocols have surfaced, that have received the most attention and review. The first, LWAPP, or Lightweight Access Point Protocol was proposed, in part supported by Cisco Systems. Next, Aruba Networks and Trapeze proposed a competing protocol named SLAPP, or Secure Light Access Point Protocol, which took a more abstract approach to handling proprietary firmware for vendor's access points. Finally, an updated protocol called CAPWAP, penned by Cisco Systems, Aruba Networks, and Research In Motion, among others, took the place as the front runner of the proposals. [RFC5412] [RFC5413] [RFC5415]
Table of ContentsIn order to understand the CAPWAP, one must first understand the basic controller-AP structure, common to most, if not all enterprise grade wireless network deployments. There are 2 primary components to the wireless network. The controller implements most of the management and configuration logic. The controller acts as a management station, configuration station, and potentially a router. The access point contains the wireless radio(s), and acts as the end point of the network, and communicates directly with user radios. The AP typically contains some amount of logic, however, that amount is governed by the MAC architecture that the AP implements, which will be covered in [Section 2]. A typical diagram of a WLAN network is in [fig1].
In the typical centralized architecture, one or more controllers manage a set number of deployed access points. Access points retrieve their configuration from the controller, and report their status back to the controller for management purposes. With the typical usage case, data from an access point is tunneled back to the controller for processing, and sending onto the back haul network. In this regard, the controller acts in similar fashion to a router, by accepting and processing layer 2 frames, and then switching layer frames on to the access network. [Sridhar06] Controllers may also provide SNMP (Simple Network Management Protocol) data about associated access points, or other types of monitoring information, such as graphs of traffic data, or numbers of associated users. [Cisco69561]
Wireless controllers have some general tasks that they perform. They are responsible for discovering, authenticating, and registration of APs, as well as maintaining a service channel to communicate over. There are 6 main portions of a controller's duties.
AP Discovery allows a controller to take ownership of an AP, or potentially redirect control to another controller. The controller can then authenticate the AP, and negotiate its advertised capabilities, such as being 802.11a, b, g, or n capable, OFDM (Orthogonal Frequency Division Multiplexing) capable, or what encoding the AP is capable of performing, radio transmit and receive power, and more. The controller then authenticates the AP, and begins uploading firmware to the AP. The firmware is used to program radio capabilities on the AP. During this initialization, as well as operation, periodic control messages must be exchanged between the AP and the controller, for management and statistical purposes. The controller opens a channel to the AP, which stays open for the up time of the access point. Finally configuration takes place, and the AP is set into active mode. All of these capabilities fall into the domain of CAPWAP. [RFC4564]
Not all access points are alike, as they fall into 3 categories. "Thick APs", or Local MAC implementations perform all the required data processing and relay locally. "Thin APs", or Remote MAC, speak only a proprietary protocol with the controller. The AP's 802.11 MAC layer exists on the controller, so all frames sent by the AP are processed by the controller, and forwarded on, as if it was a remote MAC layer for the AP. Third, so called "Fit APs" have gained popularity in recent years, as they combine both the intelligence of a Local MAC implementation with the agility of a Remote MAC implementation, by splitting realtime and non-realtime functionality between the controller and AP. [Sridhar06]
These 3 MAC layer concepts will be discussed in greater detail in [Section 2.3] and [Section 2.4].
Local MAC refers to the location of the 802.11 MAC layer on the device. In this case, the whole MAC stack exists on the AP. Fat APs use this type of MAC layer. All beacon generation, RTS, CTS, and ACKs originate from the Local MAC layer. [RFC4118] As seen in [fig2], both the 802.11 MAC and physical layer reside on the AP.
Local MAC has the benefit of being able to perform all of the MAC functions quickly, without having to rely on the controller. However, this power comes at a cost. Fat APs are much more complex, and cost much more per unit than their thinner cousins. Because they are standalone devices, they also cause difficulties when managing a growing network of many devices, as firmware and configuration must be handled on an individual basis for each device.
A Fat AP understands and speaks layer 2 and possible layer 3 protocols, and is addressable on the network. It can perform forwarding between its wireless and wired interfaces, and direct traffic directly onto the network. There is no back haul required for Fat APs, because it can put packets and frames directly on the wire, in contrast to Thin AP implementations. Some Fat APs may handle configuration locally, on a per AP basis. A configuration GUI may be provided over HTTP, as is common with many consumer grade wireless routers, or a command line interface is provided over the SSH or Telnet protocols. Fat APs may implement features such as routing, QoS (Quality of Service), and DHCP configuration for hosts.
A large corporate network with hundreds of APs could use a more centralized solution, which is realized by Thin APs. Thin APs may be found in AP-controller style deployments. The Thin AP speaks only a low level protocol between the controller, and is not accessible via IP. As previously discussed, in the typical AP-controller architecture, access points are not layer 2 or 3 devices. Thin APs have their MAC layers implemented entirely on the controller, and use tunneling to a controller to have all of their frames processed for forwarding onto the back haul network. The controller acts as the AP's remote MAC layer, and handles higher level functions like routing, QoS, and more. The AP would only implement the 802.11 physical layer, and leave the implementation of the MAC layer to the controller. This reduces complexity of the AP. [RFC4188] As seen in [fig3], only the 802.11 physical layer resides on the AP, and the 802.11 MAC layer is on the controller.
The reduction in functionality of the AP with a Remote MAC layer provides many benefits. The cost per unit is much lower than Fat APs, as the only logic necessary for functioning is the radio hardware and a simple wired interface, with memory to store firmware. In some vendor's access points, even wireless encryption is not even performed at the AP. It merely relays the encrypted frames to the controller for processing. Because the AP relies on the controller for its MAC layer, it is sensible to extend this to apply to firmware and configuration as well. [RFC4188] Thin APs lend themselves well to centralized management through controllers. Often refered to as remote antennas, Thin APs lower price allow for a more thorough wireless coverage at a given price point, and are attractive offerings for large deployments.
Split MAC layers address the issue of latency in the Remote MAC system, by defining 2 classes of MAC functions: realtime, and non-realtime. Realtime traffic are beacon generation, RTS, CTS, and ACK messages. Non-realtime capabilities are authentication procedures, fragmenting and defragmenting frames, and more. [Sridhar06] As seen in [fig4], the 802.11 physical layer and realtime MAC layer is on the AP, while the controller handles the non-realtime MAC functions.
Fit APs are a combination of the Thin and Thick metaphors. The Fit AP may implement a Split MAC layer, or a Thin MAC layer. Fit APs still rely on the controller for configuration and some frame processing. However, the AP can now perform some complex tasks, such as tagging frames with certain VLAN (Virtual LAN) IDs, based on the SSID (Service Set Identifier) of the incoming frame. Fit APs may implement either the Remote MAC 802.11 layer, or the new Split MAC. Split MAC divides the functionality of the MAC layer between the AP and the controller. [RFC4188]
It is important to realize that the definition of what a controller is is not clearly defined. The difference between Local, Remote, and Split MAC is also not defined by any standards body. It usually falls to the vendor to create a specific implementation. Many vendors use this to their advantage, and create product differentiation by including features into their wireless products, such as firewall capability in their controller hardware. Allowing, disallowing, or standardizing this is not the goal of the CAPWAP working group, however. CAPWAP only seeks to relay what a device is and is not capable of, in order to classify and provision the device into operation.
Table of ContentsThe LWAPP protocol was the first protocol to be proposed. It was initially designed by Airespace, which was later bought out by Cisco in 2005. LWAPP was introduced in [RFC5412], and defined the process of authenticating an AP with a controller, distributing firmware and configuration, as well as defining the transport header for LWAPP traffic. [RFC5412]
LWAPP defines the state machine that governs both the AP and the controller's communication with each other. [fig5] The basic functionality that is encapsulated within this protocol is as follows.
Discovery - New APs must seek out a controller with which to associate. This is accomplished by the AP broadcasting a Discovery Request. A controller must respond with a Discovery Response. The AP then joins to a controller, and is acknowledged by the controller.
Image Download - The newly joined AP then may request a firmware update, upon seeing the controller advertise a higher version of code. The AP then downloads the firmware, and once completed, enters the Reset state, and then attempts to rejoin a controller.
Configure - An AP with a sufficient version of code may then request to be configured by the controller. The AP sends the controller its current configuration, and the controller responds with an updated configuration. Once the AP has received the configuration, it may enter the Run state.
Run - Both the controller and AP operate in the Run state. The AP forwards packets to the controller, and maintains normal operation. From the Run state, an AP and controller may exchange new key material, by entering the Key Update state. This state updates the encryption keys on both devices, which is used to encrypt all further messages, until a new key is requested.
The standard also defines the layer 2 and 3 headers to encapsulate LWAPP messages. However, the header does not warrant any particular attention, and as such, will not be covered by this paper. Because the protocol can operate over IP networks, the network topology of an LWAPP compliant WLAN is not limited by broadcast domain requirements. [Cisco99947] This is necessary to enable AP Discovery to function outside of a subnet. This overview of LWAPP is by no means comprehensive. A full specification is preserved in [RFC5412].
LWAPP defines certain operation modes for compliant hardware. The controller has a fixed set of 802.11 duties, as does the AP. As part of LWAPP's 802.11 binding, it specifies both Split MAC and Local MAC functionality. The Split MAC implementation in LWAPP is identical to the description given in [Section 2.5]. [RFC4118]
The Local MAC implementation pushes all operation of the MAC layer onto the AP. The only duties that the controller is responsible for under this scheme is wireless key management and authentication proxying. The AP handles the encryption of traffic between itself and its clients, with the controller provided keys.
Communication between a controller and AP must be encrypted, as all data sent to and received by the AP will be tunneled over the local LAN to or from the controller. However, LWAPP only specifies how to encrypt traffic between the controller and AP endpoints. It claims that the physical security of the LAN prevents most attackers from accessing the stream between controller and AP, but does not guarantee against traffic sniffing beyond the scope of LWAPP, and suggests that in the requirement of full end to end encryption, IPsec be used.
The controller and AP will exchange 2 types of messages: control messages, and data messages. The proposal cites the availability of IPsec for general data traffic, and does not provide any mechanism of encrypting data messages between the controller and AP, only control messages, and the key exchange process between both devices. However, some control messages are transmitted unencrypted, such as Discovery Requests and Responses, because of the lack a preexisting association between the 2 devices. The rest of the control sequence, from the Configure state onward, is encrypted with AES-CCM. The wireless key exchange is handled in a fully encrypted fashion, by utilizing preshared keys (PSKs), or a security certificate model. [RFC5412]
The [RFC5412] that defines LWAPP has been marked as "Historic", as it has been superseded by the CAPWAP specification [RFC515] [Section 5]. Vendors such as Trapeze criticized the specification, as it makes assumptions about the topology of the network that the WLAN will be deployed on, as well as assumptions about the complexity and functionality implemented by the AP, by allowing only Local and Split MAC implementations. [Trapeze05] The protocol was originally proposed by Airespace as a vendor neutral alternative to Cisco's wireless offerings. It was seen as overly complex, as well as lacking in security, as portions of the control stream are unencrypted, and the entire data stream between controller and AP are unencrypted. However, Airespace was purchased by Cisco in 2005, and the LWAPP proposal would later become the basis of the CAPWAP standard, as discussed in [Section 5].
Table of ContentsWireless vendors Aruba and Trapeze took a different route than Airespace in designing their protocol, called Secure Light Access Point Protocol, or SLAPP. SLAPP was designed as a simple, extensible protocol that could be extended to other wireless standards, and allow for newer authentication schemes and control protocols to be implemented on top of SLAPP. [Trapeze05] This more abstract approach enables SLAPP to be implemented in standards outside of 802.11, with different topology, hardware, and implementation details. [Judge06] A stated goal in the specification is to allow this technology to be applied to any application requiring a master controller provisioning clients from different vendors. Thus, SLAPP does not seek to implement a control protocol, or manage the configuration of nodes. Rather, it attempts to provide the framework with which devices may request a specific configuration method, which is then layered on top of SLAPP. However, [RFC5413] does give two example protocols: one for controlling wireless APs, and one to manage firmware updates to APs.
SLAPP operates as the framework to make a connection between two devices, and negotiate a protocol. In [fig6], the same SLAPP protocol would be used by an AP to decide how to download updated firmware, as would be used to determine a protocol to communicate with the controller. The state machine in [fig6] show the 4 states attainable during protocol negotiation by a device. [RFC5413]
Discovery - Discovery is the initial broadcast from an AP, informing controllers that they are interested in communicating in a specific protocol. The controller awaits a Discovery Request from an AP. Once received, the controller moves to the Acquiring phase without responding yet.The AP broadcasts a Discovery Request, and upon reception of the response, moves to the Acquiring phase as well.
Acquiring - This state represents both devices connecting to each other, to begin encrypting their communications. The controller processes the Discovery Request, and if valid, responds in the positive, and moves to Securing. Otherwise it moves back to the Discovery state. The AP transitions to the Securing phase when a "client hello" message has been received. This marks the beginning of a DTLS conversation, or Datagram Transport Layer Security [RFC4347]. If a timer expires while the AP is in the Acquiring phase before receiving a "client hello", the AP goes back to Discovery mode.
Securing - This phase establishes an encrypted tunnel, over which a protocol can be agreed upon. The controller transmits a "client end" message, to signify the termination of the DTLS exchange. The controller then moves into the Negotiated Control Protocol state. The AP reciprocates the DTLS connection, and when finished, transmits the "server end" message. When the DTLS exchange is completed, the AP moves to Negotiated Control Protocol.
Negotiated Control Protocol - Here both devices begin communicating in the previously agreed-upon protocol. This protocol can be anything, as long as both sides agreed on it.
As mentioned in [Section 4.1], a DTLS tunnel is created between the controller and AP for encrypting their session. [RFC5413] The connection between the 2 devices is not necessarily a fully encrypted stream, however. The DTLS tunnel allows for different authentication styles, ranging from full stream encryption, to one way encryption, to anonymous authentication. The benefits of this model are such that it does not enforce a specific security model onto the design of the underlying standard, and as mentioned previously, allows the SLAPP standard to be applied to more protocols than just 802.11.
The process of pairing and authentication of the controller and AP is considerably more simple than in LWAPP from [Section 3]. However, this simplicity does not come at the expense of flexibility. The security model in SLAPP allows for a wider range of deployment across different controller-AP configurations. However, the SLAPP protocol is fundamentally different from LWAPP, in that it attempts to solve only a subset of the problems that the CAPWAP specification is meant to address. More specifically, it fails to define key duties mentioned in [Section 2.1], such as number 4, Firmware Distribution, number 5, Management Traffic, and number 6, Configuration. The reasoning behind this incomplete fulfillment of the CAPWAP goals is due to the extensible nature of the SLAPP protocol. Unlike LWAPP, which specified that there must be a configuration exchange as part of the AP association, SLAPP leaves such technicalities to the specific implementation, being able to adapt to future protocol changes.
Critics of SLAPP argue that it is an incomplete specification, as it enforces no minimal compatibility. Vendors do not have a clearly defined set of protocols that must be implemented, in order to be compatible with other vendors. Instead, this protocol leaves the market vulnerable to more proprietary firmware and configuration exchange protocols running on top of SLAPP. For example, vendor X may use SLAPP in its hardware, negotiate proprietary protocols A, B, and C over SLAPP. Vendor Y also uses SLAPP, but cannot interact with vendor X's products, because it implements protocols B, C, and D. By this logic, the SLAPP protocol has done nothing to further the CAPWAP working groups goals of vendor neutrality in the managed WLAN product space.
A different benefit of SLAPP is that it does not enforce a specific 802.11 MAC implementation on the AP. A client AP is free to use Local, Remote, or Split MAC layers, as long as the controller it is associated to supports it. Additionally, because of its generic design, the network location of an AP and controller do not necessarily have to be within the same broadcast domain. Because SLAPP supports both layer 2 and 3, access points may be in completely different routed networks as the controller, or even across the Internet. And finally, in contrast to LWAPP, all traffic over SLAPP is encrypted, not just control channel traffic.
It should be noted that SLAPP has since obsoleted by CAPWAP [RFC5415].
Table of ContentsThe most recent protocol that has come out of the CAPWAP working group is named CAPWAP. It was produced in part by Cisco, Aruba Networks, and Research in Motion. It combines the strengths of SLAPP's generic design and extensibility, while utilizing LWAPP's state machine for managing the connection between AP and controller. The security model is not ported over from LWAPP, as there were many concerns about the validity of the security. An express goal of the CAPWAP protocol is enabling thinner APs, which implement Split MAC, in order to drive innovation in the market by lowering the required computing power in an AP, and thus AP prices. [Cisco69561] Local MAC operation is permitted as well. [RFC5415]
The state machine of CAPWAP is similar to LWAPP's, but with the addition of a full DTLS tunnel establishment, borrowed from SLAPP. The standard provides configuration management and device management, allowing for configurations and firmware to be pushed to APs. Because the overall state design of the CAPWAP protocol is largely the same as the FSM in LWAPP, a detailed diagram is not needed. Consult [RFC5415] for a full overview.
This protocol differentiates between data traffic and control traffic, as LWAPP did. However, only the control messages are transmitted in a DTLS tunnel still. The publishers argue that an unencrypted data channel is not a security threat, because full IPsec is available. More consideration has been placed on ensuring that CAPWAP is secure, by taking advantage of the security offered by requiring full encryption with authentication between the controller and AP. This creates some inconveniences, however, in that both APs and controllers need to be preconfigured in order to associate with each other. Both the AP and controller must be either loaded with PSKs or certificate files to enable encrypted communication. Access Control Lists are also implemented to prevent rogue CAPWAP controllers from hijacking unassociated APs.
LWAPP has been approved by the IETF, but has not seen very widespread deployment. There has been no major consensus between these two technologies, until the CAPWAP protocol was proposed. Now, vendors have begun to slowly migrate towards CAPWAP support. However, the process is slow, as upgrade paths are not necessarily direct and simple.
Aruba was one of the core members of the SLAPP proposal. Although it strongly advocated SLAPP, it currently uses a homegrown system called PAPI. [Aruba09] Aruba states many issues with CAPWAP, namely that of inflexibility. [Aruba09] SLAPP's strong suite was in allowing freedom of control protocol, in the face of new architecture advances. [Judge06] CAPWAP and LWAPP do not take into account new and upcoming standards that could potentially change the problem of CAPWAP. Aruba also claims that as of March 2009, no vendor has implemented CAPWAP per the [RFC5415] specifications, instead claiming that vendors have been using proprietary extensions to complete the specification. [Aruba09]
Aruba plans to roll out support for CAPWAP when the specification has become more standardized, but does not plan to replace its current PAPI technology. [Aruba09] However, Aruba is known for its management hardware, such as AirWave Management System, which can interface with other vendor's APs over various technologies. Examples of support include both Meru and Cisco wireless access points, using SWAN, LWAPP, and CAPWAP protocols.
Trapeze was also involved in penning the SLAPP standard. In a press release in 2005 [Trapeze05], it talked about SLAPP's benefits over implementations such as LWAPP. Quoting increased consumer choice and innovation, However, Trapeze makes no indication of future support of the CAPWAP protocol. [Trapeze05]
Cisco incorporated the LWAPP protocol into its WLAN offerings after purchasing Airespace in 2005, who initially proposed LWAPP. Cisco then pushed CAPWAP, based on LWAPP, and is currently in the process of migrating from LWAPP to CAPWAP in its controller offerings, and as of Cisco's controller software 5.2, CAPWAP has become the only controller-AP communication scheme. This limits interoperability to only vendors who have implemented [RFC5415], which is just Cisco as of the time of this writing. [Cisco69561]
Meru has not been involved in any of the IETF proceedings for the creation of the CAPWAP specification. Currently, their WLAN controllers can only interface with Meru brand access points, utilizing a proprietary protocol. Meru Air Traffic Control software may be used to provision and manage APs, but provides no multi vendor support. However, Aruba hardware may be used to provision and monitor Meru APs via SNMP. Meru has made no plans public for enabling support for a standards compliant method of AP-controller interaction.
Table of ContentsThe creation of a vendor neutral protocol is a potential boon to consumers of enterprise grade managed wireless solutions. However, the capabilities of CAPWAP may only be realized if and when vendors decide to support the protocol. Vendors have expressed doubt about the importance of an overarching standard for AP-controller interaction [Judge06], because of the lack of visibility to the end user. The WLAN market is structured similarly to an oligopoly, because the market is controlled by a very small set of vendors, namely Aruba, Cisco, Meru, and Trapeze. Oligopolies are typically resistant to destabilization of the market, introduced by large paradigm shifts, such as the shift that is promised by CAPWAP.
An open source project named OpenCAPWAP aims at providing an alternative to large vendors. OpenCAPWAP is an open source implementation of the CAPWAP protocol, targeting commodity hardware running Linux. The goal of the project is to provide a free and open source to proprietary controller hardware and software, which can cost in upwards of $20,000. [Ecrater]
OpenCAPWAP is implemented as 2 Linux applications. The first is targeted at server hardware, and handles the operation of the controller. It is a multi-threaded implementation of the CAPWAP state machine specified in [RFC5415]. There are two types of threads that may be instantiated on the controller: Receiver and Session Manager [fig7]. A single Receiver thread receives and processes any requests from APs. The Receiver is then responsible for processing the packets, and either dropping the packets, or moving a good connection into a Session Manager Thread. A Session Manager is instantiated for each open connection to an AP, and engages in communication with the AP with the CAPWAP protocol. [Bernaschi09]
The second program is run on each AP, in order to facilitate communication between the AP and controller. There are 3 types of AP threads, and no more than 3 threads may be active at any one time: Principal, Receiver, and Receiver-From-STA. Please see [fig 8] for a diagram. The Principal thread begins communication with the CAPWAP Discovery Request message. It is responsible for sending CAPWAP messages to the controller. The Principal thread creates a Receiver thread, to handle the responses from the controller. However, the Principal and Receiver thread share sent and received packets with each other. The division between the sending and receiving of CAPWAP messages is that the communication between the AP and controller is not necessarily synchronous, and the controller may send a request while the Principal thread is sending. The final thread that is created in the AP is the Receive-From-STA thread. This thread is used to accept non-realtime requests from the associated client stations, such as any message in Split MAC that may need to be forwarded to the controller in the CAPWAP protocol. The Receiver-From-STA thread can pass along messages through the Principal thread, which are sent back to the controller for processing. [Bernaschi09]
The implementation described in [Bernaschi09] is not ready for currently available APs. The testing was conducted with computers running Linux, with wireless cards as their radio, and wired interfaces as their link to the controller. The authors of OpenCAPWAP note that because the definition of Split MAC is fairly loose, in that the definition of what realtime MAC functionality is changes from vendor to vendor, each AP that supports Split MAC has a different implementation. The lack of a vendor consensus of what functionality should reside in the AP and in the controller for Split MAC is currently preventing the OpenCAPWAP team from supporting a wide range of AP hardware with Split MAC mode currently. [Bernaschi09] However, Local MAC is fully supported, albeit on a desktop Linux platform, and not the embedded platforms common to most vendor's APs. Thus, OpenCAPWAP is only a proof of concept, as they are limited in the hardware that they may support, by a lack of common target hardware, as well as differencing 802.11 MAC implementations.
Table of ContentsIn this survey, a look at different proposed standards for enabling WLAN controllers to support multi-vendor APs, and how to solve the problems introduced by the AP-controller architecture, has been taken. First, an overview of the 4 overarching goals to be addressed by a CAPWAP protocol was given. The protocol must enable centralized management of the components of a WLAN, allow for transparent support of different vendor's hardware, be able to provide monitoring of hardware and software configuration and status, and finally ensure network security. The AP-controller architecture was discussed in detail, and the distinction between Local MAC, Split MAC, and Remote MAC 802.11 MAC layer implementations was given, in order to accurately cover the current and possible divisions of labor between APs and controllers at the MAC layer.
3 protocols were introduced that attempted to solve these issues: LWAPP, SLAPP, and CAPWAP. Two different approaches were taken with LWAPP and SLAPP. LWAPP tried to solve the specific problem of associating APs to controllers, and managing firmware and configuration updates. However, LWAPP introduced many security concerns with its design. SLAPP attempted to solve a more general problem, not limiting itself to 802.11 networks, and not enforcing specific phases of association. Instead, SLAPP proposed a generic protocol for an AP style device to seek out a controller, and establish an encrypted connection, over which a protocol would be agreed upon, and carried out. SLAPP was criticized because it did not solve the specific problem statement laid out by the CAPWAP working group. The CAPWAP protocol was then analyzed, which combined the direct approach of LWAPP, with the powerful and flexible security of SLAPP.
CAPWAP has emerged as the most promising standard, and has obsoleted the previous RFCs that defined LWAPP and SLAPP. The support of the protocol from the 4 major WLAN vendors Aruba Networks, Cisco Systems, Trapeze Networks, and Meru Networks were given brief overviews. The status of interoperability between vendors currently was discussed, as well as the plans of each vendor to support CAPWAP in the future. Finally, the open source OpenCAPWAP proof of concept was discussed, both in its implementation, and current status.
CAPWAP is becoming the defacto standard for enabling operation between different hardware vendors. However, the protocol itself is not finalized, resulting in both hesitation to implement on vendor's parts, and incomplete or incompatible current implementations. Major vendors have also expressed doubt over the demand from customers for interoperable WLAN infrastructure. Some vendors have produced products that allow operation with multiple brands of AP, such as Aruba Network's AirWave being able to provision and control Aruba, Cisco, and Meru access points. However, this compatibility was not the result of CAPWAP, but rather specific licensing deals between each supported company. The only vendor that has produced a CAPWAP implementation thus far is Cisco, but it relies on some proprietary protocols, thus limiting compatibility.
The need for flexible wireless network infrastructure will become more pronounced as WLANs become larger and more widespread. A standard that ensures compatibility between vendors is necessary to prevent vendor lock-in. The migration towards a unified standard will be long, and not necessarily even happen, because each vendor already supports its own proprietary protocols, and sees little motivation to commoditize their AP hardware by introducing CAPWAP across the industry. However, open source solutions such as OpenCAPWAP could provide incentive to vendors to begin deploying an interoperable standard for CAPWAP.
Table of Contents| ACK | Acknowledgment |
| AP | Access Point |
| CAPWAP | Control And Provisioning of Wireless Access Points |
| CTS | Clear to Send |
| DHCP | Dynamic Host Configuration Protocol |
| FSM | Finite State Machine |
| GUI | Graphical User Interface |
| HTTP | Hyper Text Transfer Protocol |
| IETF | Internet Engineering Task Force |
| LWAPP | Lightweight Access Point Protocol |
| MAC | Medium Access Control |
| OFDM | Orthogonal Frequency Division Multiplexing |
| SSID | Service Set Identifier |
| RFC | Request for Comment |
| RTS | Request to Send |
| SLAPP | Secure Light Access Point Protocol |
| SNMP | Simple Network Management Protocol |
| SSH | Secure Shell |
| QoS | Quality of Service |
| VLAN | Virtual Local Area Network |
| WG | Working Group |