You forgot to provide an Email Address. This email address is already registered. Please login. You have exceeded the maximum character limit.
|Published (Last):||2 April 2015|
|PDF File Size:||14.19 Mb|
|ePub File Size:||13.41 Mb|
|Price:||Free* [*Free Regsitration Required]|
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. Current vendor solutions and interoperability is also covered, and the current state and trends in the enterprise WLAN market are discussed.
An overview of the architecture and protocols use in access point AP to controller communication in enterprise grade wireless networks. 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. 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. 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. 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.
The challenges facing wireless networks with regard to standardized management and provisioning are difficult. However, some have been met with criticism. In 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. 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 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.
Not all access points are alike, as they fall into 3 categories. The AP's 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.
These 3 MAC layer concepts will be discussed in greater detail in [Section 2. Local MAC refers to the location of the 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. 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. 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 AP would only implement the This reduces complexity of the AP. 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.
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. Non-realtime capabilities are authentication procedures, fragmenting and defragmenting frames, and more. Fit APs are a combination of the Thin and Thick metaphors. Fit APs still rely on the controller for configuration and some frame processing.
It is important to realize that the definition of what a controller is is not clearly defined. 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. CAPWAP only seeks to relay what a device is and is not capable of, in order to classify and provision the device into operation.
It was initially designed by Airespace, which was later bought out by Cisco in 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. However, the header does not warrant any particular attention, and as such, will not be covered by this paper.
A full specification is preserved in [RFC]. LWAPP defines certain operation modes for compliant hardware. The controller has a fixed set of 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.
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 wireless key exchange is handled in a fully encrypted fashion, by utilizing preshared keys PSKs , or a security certificate model. 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.
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.
CAPWAP (Control and Provisioning of Wireless Access Points)
Current Status and Overview of the CAPWAP Protocol