Overview of CAPWAP (Cisco Wireless LAN Controllers)

Control and Provisioning of Wireless Access Points (CAPWAP) is a standard and interoperable protocol that enables a Wireless LAN Controller (WLC) to manage access points (AP) or wireless termination points (WTP). CAPWAP is based on the Lightweight Access Point Protocol (LWAPP). This topic describes the changes in controller and AP software to enable CAPWAP support and to enable an upgrade from LWAPP to CAPWAP. The topic covers a good amount of the protocol, but for those who want to get a deeper understanding, refer to the CAPWAP RFCs. Figure 4-1 gives a brief overview of the different RFCs the CAPWAP protocol involves:

■ RFC 4564 defines the objectives for the CAPWAP protocol.

■ RFC 5418 covers the threat analysis for IEEE 802.11 deployments.

■ RFC 5415 defines the actual CAPWAP protocol specifications.

The CAPWAP protocol does not include specific wireless technologies; instead, it relies on a binding specification to extend the technology to a particular wireless technology. Those binding specifications for the IEEE 802.11 wireless protocol are defined in RFC 5416.

Last but not least, Datagram Transport Layer Security (DTLS), defined in RFC 4347, is used as a tightly integrated, secure wrapper for the CAPWAP protocol, whereas DTLS relies on Transport Layer Security (TLS) 1.1 (RFC 4346).

Reading the RFCs also places you in a position to better digest the material covered in this topic.

Figure 4-1 Important Wireless RFCs and Relationships

CAPWAP support starts in controller Version 5.2. The upgrade transition from LWAPP to CAPWAP is typically transparent to the end user. The process by which an AP discovers a controller, validates firmware, and downloads firmware and configurations does not change. The only exception is in the scenario in which a customer has an LWAPP Layer 2 deployment. CAPWAP does not support Layer 2; this should be a null issue because the customer base using Layer 2 LWAPP deployments is minimal or nonexistent at this point. One of the reasons for such little support is that the deployment is restricted to a Layer 2 boundary. Another reason is that during the transition period when Cisco started supporting LWAPP conversions of autonomous APs, one of the requirements for a WLC to communicate with a converted AP was that the WLC must perform all communications in LWAPP Layer 3 mode.

Note Layer 2 LWAPP has no AP-Manager interface, and the APs do not utilize IP addresses.

Differences from LWAPP

The discovery process changes from LWAPP to CAPWAP are transparent to most users; however, they are indeed different. One of the main differences is the use of DTLS.

As you see from Figure 4-2, the overall deployments are identical between LWAPP and CAPWAP. The only difference is the protocol being used between the AP and the controller. DTLS is used as a tightly integrated secure wrapper for a CAPWAP packet.

Figure 4-2 LWAPP and CAPWAP Comparison

Table 4-1 outlines the primary differences between CAPWAP and LWAPP.

Table 4-1 LWAPP and CAPWAP Comparison

Because of the similarities, deployments can contain mixtures of CAPWAP and LWAPP software-based controllers. This is not a recommended scenario for a few different reasons the first being if an AP were to move from one controller utilizing LWAPP to another utilizing CAPWAP. In that case, the AP would take longer to join because the code versions would obviously be different. Each time the AP would have to download firmware when moving from one controller to the next with different code versions. When an LWAPP AP discovers a CAPWAP controller, the AP is automatically converted to CAPWAP and vice versa when an AP discovers an LWAPP controller. Overall convergence for the APs to come online will take longer in this scenario. This would be a similar scenario to two controllers running different versions of code. The CAPWAP-enabled software, Version 5.2, will allow APs to join a controller running CAPWAP or LWAPP. However, another disadvantage is that only controllers supporting CAPWAP will be present in the same mobility group. For this reason, mobility is limited to the protocol being used—CAPWAP only or LWAPP only. The exception is 6.0 MR1 code, which will support mobility for 4.2 MR3 code. Otherwise, there will be no support for a combination of both LWAPP and CAPWAP controllers in the same mobility group.

You might encounter a deployment scenario as in Figure 4-3, where you have a mixed deployment. This might happen when you are upgrading to a CAPWAP-supported version, for example. In this scenario, you must ask how much LWAPP support is on a CAPWAP version of code. It is assumed that at any point in time the AP will run only CAPWAP or LWAPP. If it is running an image before CAPWAP support, it will be able to discover controllers using LWAPP only.

Figure 4-3 LWAPP and CAPWAP Mixed Deployment

If it is running an image with CAPWAP support, it will be able to discover controllers using CAPWAP or LWAPP. However, LWAPP support is limited—in the sense that LWAPP will be supported only until the AP is able to download an image from an LWAPP controller—for downgrades. At the controllers, LWAPP support in a CAPWAP-enabled image is available to the extent of allowing the existing LWAPP APs to communicate with the controller using LWAPP and being able to download a CAPWAP image. An AP running a CAPWAP-supported image behind Network Address Translation (NAT) will work as it does today with LWAPP. There will be no support for an LWAPP data path in a controller or an AP that is running a CAPWAP-supported image.