As you learned at the beginning of this topic, 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.
CAPWAP-Data Binding and Payloads
To differentiate which protocol is transported by CAPWAP-Data, the CAPWAP Header requires all CAPWAP binding specifications to have a Wireless Binding Identifier (WBID) assigned. The IEEE 802.11 binding uses the value 1. If CAPWAP-Data encryption is not enabled, you can read this value directly from a sniffer trace. Figure 4-12 highlights the WBID in the packet. After the WBID there is some wireless information that follows and then you see the transported 802.11 frame itself.
Figure 4-12 Wireless Binding Identifier (WBID)
CAPWAP-Control Binding and Payloads
Depending on the control message type, both CAPWAP and LWAPP control messages contain zero or more LWAPP/CAPWAP Protocol message elements. Figure 4-13 (CAPWAP) and Figure 4-14 (LWAPP) show the corresponding control message format. The message elements are highlighted in bold. Message elements are used to carry information needed in control messages.
Figure 4-13 CAPWAP Control Message Format
Figure 4-14 LWAPP Control Message Format
Every message element (carried by CAPWAP or LWAPP Controller messages) is identified by the Type Value field. A message element uses the type, length, value (TLV) format shown in Figure 4-15.
Figure 4-15 TLV Format
Table B-2 details the payloads (every message element) sent in LWAPP control messages and the corresponding ones that will be sent in CAPWAP control messages.
When debugging CAPWAP packets on the controller or capturing CAPWAP packets with the latest CAPWAP dissector, you will find all those elements in the CAPWAP control messages.
LWAPP and CAPWAP Vendor-Specific Payloads
CAPWAP uses almost identical message elements to LWAPP. If no corresponding CAPWAP element exists, such as Radio Resource Management (RRM), the Cisco Unified Wireless Solution transports LWAPP message elements within the CAPWAP vendor-specific elements and maintains all functionality.
The Vendor-Specific Payload message element (Type 37) uses the format shown in Figure 4-16.
Figure 4-16 CAPWAP Vendor-Specific Payload Message Element
Therefore, the complete LWAPP/Cisco vendor-specific message element appears in a trace, as shown in Figure 4-17, using the Cisco OID (Vendor ID) 0×00-40-96-00.
Figure 4-17 Cisco’s/LWAPP-Specific Payload Message Element
Summary
CAPWAP is a standard, interoperable protocol that enables an access controller (AC; WLC) to manage a collection of WTPs; APs). CAPWAP is based on LWAPP, which is the protocol used in the controllers and APs. One essential reason for moving to CAPWAP is to standardize. As a standard, CAPWAP will enable interoperability of Cisco controllers with third-party APs. A second critical reason is because CAPWAP enables management of radio-frequency identification, RFID, readers (and in the future other devices via sensor gateways). To summarize, the following are the major benefits:
■ Support for Path-MTU discovery
■ Fragmentation/reassembly using the CAPWAP protocol
■ Supported legacy as well as next-generation WLC platforms (such as the 5500s)
■ Uses DTLS for Control and Data Channel encryption between AP and WLC
With the introduction of CAPWAP, there are no new command-line interface (CLI) commands other than the debugging ones. The goal here is to help you understand the troubleshooting process utilizing CAPWAP and offer the most versatile, scalable, and powerful product that the market has seen. CAPWAP is simply the next step in making this transition happen.
