Network Working Group P. Calhoun, Editor Internet-Draft Cisco Systems, Inc. Expires: December 13, 2007 M. Montemurro, Editor Research In Motion D. Stanley, Editor Aruba Networks June 11, 2007 CAPWAP Protocol Binding for IEEE 802.11 draft-ietf-capwap-protocol-binding-ieee80211-04 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 13, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Calhoun, Editor, et al. Expires December 13, 2007 [Page 1]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 Abstract Wireless LAN product architectures have evolved from single autonomous access points to systems consisting of a centralized Access Controller (AC) and Wireless Termination Points (WTPs). The general goal of centralized control architectures is to move access control, including user authentication and authorization, mobility management and radio management from the single access point to a centralized controller. This specification defines the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Binding Specification for use with the IEEE 802.11 Wireless Local Area Network protocol. The CAPWAP Protocol Specification is defined separately [3]. Calhoun, Editor, et al. Expires December 13, 2007 [Page 2]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 1. Introduction This specification defines the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Binding Specification for use with the IEEE 802.11 Wireless Local Area Network protocol. Use of CAPWAP control message fields, new control messages and message elements are defined. The minimum required definitions for a binding-specific Statistics message element, Station message element, and WTP Radio Information message element are included. 1.1. Goals The goals for this CAPWAP protocol binding are listed below: 1. To centralize the authentication and policy enforcement functions for an IEEE 802.11 wireless network. The AC may also provide centralized bridging, forwarding, and encryption of user traffic. Centralization of these functions will enable reduced cost and higher efficiency by applying the capabilities of network processing silicon to the wireless network, as in wired LANs. 2. To enable shifting of the higher level protocol processing from the WTP. This leaves the time-critical applications of wireless control and access in the WTP, making efficient use of the computing power available in WTPs which are subject to severe cost pressure. The CAPWAP protocol binding extensions defined herein apply solely to the interface between the WTP and the AC. Inter-AC and station-to-AC communication are strictly outside the scope of this document. 1.2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. 1.3. Terminology Access Controller (AC): The network entity that provides WTP access to the network infrastructure in the data plane, control plane, management plane, or a combination therein. Basic Service Set (BSS): A set of stations controlled by a single coordination function. Distribution: The service that, by using association information, delivers medium access control (MAC) service data units (MSDUs) Calhoun, Editor, et al. Expires December 13, 2007 [Page 3]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 within the distribution system (DS). Distribution System Service (DSS): The set of services provided by the distribution system (DS) that enable the medium access control (MAC) layer to transport MAC service data units (MSDUs) between stations that are not in direct communication with each other over a single instance of the wireless medium (WM). These services include the transport of MSDUs between the access points (APs) of basic service sets (BSSs) within an extended service set (ESS), transport of MSDUs between portals and BSSs within an ESS, and transport of MSDUs between stations in the same BSS in cases where the MSDU has a multicast or broadcast destination address, or where the destination is an individual address, but the station sending the MSDU chooses to involve the DSS. DSSs are provided between pairs of IEEE 802.11 MACs. Integration: The service that enables delivery of medium access control (MAC) service data units (MSDUs) between the distribution system (DS) and an existing, non-IEEE 802.11 local area network (via a portal). Station (STA): A device that contains an IEEE 802.11 conformant medium access control (MAC) and physical layer (PHY) interface to the wireless medium (WM). Portal: The logical point at which medium access control (MAC) service data units (MSDUs) from a non-IEEE 802.11 local area network (LAN) enter the distribution system (DS) of an extended service set (ESS). WLAN: In this document, WLAN refers to a logical component instantiated on a WTP device. A single physical WTP may operate a number of WLANs. Each Basic Service Set Identifier (BSSID) and its constituent wireless terminal radios is denoted as a distinct WLAN on a physical WTP. Wireless Termination Point (WTP): The physical or network entity that contains an IEEE 802.11 RF antenna and wireless PHY to transmit and receive station traffic for wireless access networks. Calhoun, Editor, et al. Expires December 13, 2007 [Page 4]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 2. IEEE 802.11 Binding This section describes use of the CAPWAP protocol with the IEEE 802.11 Wireless Local Area Network protocol, including Local and Split MAC operation, Group Key Refresh, BSSID to WLAN Mapping, IEEE 802.11 MAC management frame Quality of Service tagging and Run State operation. 2.1. Split MAC and Local MAC Functionality The CAPWAP protocol, when used with IEEE 802.11 devices, requires specific behavior from the WTP and the AC to support the required IEEE 802.11 protocol functions. For both the Split and Local MAC approaches, the CAPWAP functions, as defined in the taxonomy specification [6], reside in the AC. To provide system component interoperability, the WTP and AC MUST support 802.11 encryption/decryption at the WTP. The WTP and AC MAY support 802.11 encryption/decryption at the AC. 2.1.1. Split MAC This section shows the division of labor between the WTP and the AC in a Split MAC architecture. Figure 1 shows the separation of functionality between CAPWAP components. Function Location Distribution Service AC Integration Service AC Beacon Generation WTP Probe Response Generation WTP Power Mgmt/Packet Buffering WTP Fragmentation/Defragmentation WTP/AC Assoc/Disassoc/Reassoc AC IEEE 802.11 QOS Classifying AC Scheduling WTP/AC Queuing WTP IEEE 802.11 RSN IEEE 802.1X/EAP AC RSNA Key Management AC IEEE 802.11 Encryption/Decryption WTP/AC Figure 1: Mapping of 802.11 Functions for Split MAC Architecture Calhoun, Editor, et al. Expires December 13, 2007 [Page 5]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 In a Split MAC Architecture,the Distribution and Integration services reside on the AC, and therefore all user data is tunneled between the WTP and the AC. As noted above, all real-time IEEE 802.11 services, including the Beacon and Probe Response frames, are handled on the WTP. All remaining IEEE 802.11 MAC management frames are supported on the AC, including the Association Request frame which allows the AC to be involved in the access policy enforcement portion of the IEEE 802.11 protocol. The IEEE 802.1X and IEEE 802.11 key management function are also located on the AC. This implies that the AAA client also resides on the AC. While the admission control component of IEEE 802.11 resides on the AC, the real time scheduling and queuing functions are on the WTP. Note that this does not prevent the AC from providing additional policy and scheduling functionality. Note that in the following figure, the use of '( - )' indicates that processing of the frames is done on the WTP. Client WTP AC Beacon <----------------------------- Probe Request ----------------------------( - )-------------------------> Probe Response <----------------------------- 802.11 AUTH/Association <---------------------------------------------------------> Station Configuration Request [Add Station (Station Message Elements)] <--------------------------> 802.1X Authentication & 802.11 Key Exchange <---------------------------------------------------------> Station Configuration Request [Add Station (AES-CCMP, PTK=x)] <--------------------------> 802.11 Action Frames <---------------------------------------------------------> 802.11 DATA (1) <---------------------------( - )-------------------------> Figure 2: Split MAC Message Flow Calhoun, Editor, et al. Expires December 13, 2007 [Page 6]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 Figure 2 provides an illustration of the division of labor in a Split MAC architecture. In this example, a WLAN has been created that is configured for IEEE 802.11, using 802.1X based end user authentication and AES-CCMP link layer encryption. The following process occurs: o The WTP generates the IEEE 802.11 Beacon frames, using information provided to it through the IEEE 802.11 Add WLAN (see Section 6.1) message element, including the RSNIE, which indicates support of 802.1X and AES-CCMP. o The WTP processes the Probe Request frame and responds with a corresponding Probe Response frame. The Probe Request frame is then forwarded to the AC for optional processing. o The WTP forwards the IEEEE 802.11 Authentication and Association frames to the AC, which is responsible for responding to the client. o Once the association is complete, the AC transmits a Station Configuration Request message, which includes an Add Station message element, to the WTP (see Section 4.5.8 in [3]). In the above example, the WLAN was configured for IEEE 802.1X. o If the WTP is providing encryption/decryption services, once the client has completed the IEEE 802.11 key exchange, the AC transmits another Station Configuration Request message which includes an Add Station message element, an IEEE 802.11 Station message element, an IEEE 802.11 Station Session Key message element and an IEEE 802.11 Information Element message element which includes the RSNIE to the WTP, delivering the security policy to enforce for the station (in this case AES-CCMP), and the encryption key to use. If encryption/decryption is handled in the AC, the IEEE 802.11 Information message element with an RSNIE would not be included. o The WTP forwards any IEEE 802.11 Management Action frames received to the AC. o All IEEE 802.11 station data frames are tunneled between the WTP and the AC. The WTP SHALL include the IEEE 802.11 MAC header contents in all frames transmitted to the AC. When 802.11 encryption/decryption is performed at the WTP, the WTP MUST decrypt the uplink frames, MUST set the Protected Frame field to 0, and MUST make the frame format consistent with that of an Calhoun, Editor, et al. Expires December 13, 2007 [Page 7]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 unprotected 802.11 frame prior to transmitting the frames to the AC. The fields added to an 802.11 protected frame, i.e., IV/EIV, MIC,and ICV , MUST be stripped off prior to transmission from the WTP to AC. For downlink frames, the Protected Frame field MUST be set to 0 by the AC as the frame being sent is unencrypted. The WTP MUST apply the required protection policy for the WLAN, and set the Protected Frame field on transmission over the air. The Protected Frame field always needs to accurately indicate the status of the 802.11 frame that is carrying it. When 802.11 encryption/decryption is performed at the AC,the WTP SHALL NOT decrypt the uplink frames prior to transmitting the frames to the AC. The AC and WTP SHALL populate the IEEE 802.11 MAC header fields as described in Figure 3. MAC header field Location Frame Control: Version AC ToDS AC FromDS AC Type AC SubType AC MoreFrag WTP/AC Retry WTP Pwr Mgmt - MoreData WTP Protected WTP/AC Order AC Duration: WTP Address 1: AC Address 2: AC Address 3: AC Sequence Ctrl: WTP Address 4: AC QoS Control: AC Frame Body: AC FCS: WTP Figure 3: Population of the IEEE 802.11 MAC header Fields for Downlink Frames When 802.11 encryption/decryption is performed at the AC, the MoreFrag bit is populated at the AC. The Pwr Mgmt bit is not applicable to downlink frames, and is set to 0. Note that the FCS field is not included in 802.11 frames exchanged between the WTP and the AC. Upon sending data frames to the AC, the WTP is responsible for validating, and stripping the FCS field. Upon receiving data frames from the AC, the WTP is responsible for adding the FCS field, Calhoun, Editor, et al. Expires December 13, 2007 [Page 8]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 and populating the field as described in [2]. 2.1.2. Local MAC This section shows the division of labor between the WTP and the AC in a Local MAC architecture. Figure 4 shows the separation of functionality among CAPWAP components. Function Location Distribution Service WTP/AC Integration Service WTP Beacon Generation WTP Probe Response Generation WTP Power Mgmt/Packet Buffering WTP Fragmentation/Defragmentation WTP Assoc/Disassoc/Reassoc WTP/AC IEEE 802.11 QOS Classifying WTP Scheduling WTP Queuing WTP IEEE 802.11 RSN IEEE 802.1X/EAP AC RSNA Key Management AC IEEE 802.11 Encryption/Decryption WTP Figure 4: Mapping of 802.11 Functions for Local AP Architecture In the Local MAC mode, the integration service exists on the WTP, while the distribution service MAY reside on either the WTP or the AC. When it resides on the AC, station generated frames are not forwarded to the AC in their native format, but encapsulated as 802.3 frames. While the MAC is terminated on the WTP, it is necessary for the AC to be aware of mobility events within the WTPs. Thus the WTP MUST forward the IEEE 802.11 Association Request frames to the AC. The AC MAY reply with a failed Association Response frame if it deems it necessary, and upon receipt of a failed Association Response frame from the AC, the WTP MUST send a Disassociation frame to the station. The IEEE 802.1X and RSNA Key Management functions reside in the AC. Therefore, the WTP MUST forward all IEEE 802.1X/RSNA Key Management frames to the AC and forward the corresponding responses to the station. This implies that the AAA client also resides on the AC. Note that in the following figure, the use of '( - )' indicates that Calhoun, Editor, et al. Expires December 13, 2007 [Page 9]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 processing of the frames is done on the WTP. Client WTP AC Beacon <----------------------------- Probe <----------------------------> 802.11 AUTH <----------------------------- 802.11 Association <---------------------------( - )-------------------------> Station Configuration Request[ Add Station (Station Message Elements)] <--------------------------> 802.1X Authentication & 802.11 Key Exchange <---------------------------------------------------------> 802.11 Action Frames <---------------------------------------------------------> Station Configuration Request[ Add Station (AES-CCMP, PTK=x)] <--------------------------> 802.11 DATA <-----------------------------> Figure 5: Local MAC Message Flow Figure 5 provides an illustration of the division of labor in a Local MAC architecture. In this example, a WLAN that is configured for IEEE 802.11 has been created using AES-CCMP for privacy. The following process occurs: o The WTP generates the IEEE 802.11 Beacon frames, using information provided to it through the Add WLAN (see Section 6.1) message element. o The WTP processes a Probe Request frame and responds with a corresponding Probe Response frame. o The WTP forwards the IEEE 802.11 Authentication and Association frames to the AC. o Once the association is complete, the AC transmits a Station Configuration Request message, which includes the Add Station message element, to the WTP (see Section 10.1 in [3]). In the above example, the WLAN is configured for IEEE 802.1X, and Calhoun, Editor, et al. Expires December 13, 2007 [Page 10]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 therefore the '802.1X only' policy bit is enabled. o The WTP forwards all IEEE 802.1X and IEEE 802.11 key exchange messages to the AC for processing. o The AC transmits another Station Configuration Request message including an Add Station message element, an IEEE 802.11 Station message element, an IEEE 802.11 Station Session Key message element and an IEEE 802.11 Information Element message element which includes the RSNIE to the WTP, stating the security policy to enforce for the client (in this case AES-CCMP), as well as the encryption key to use. The Add Station message element MAY include a VLAN name, which when present is used by the WTP to identify the VLAN on which the user's data frames are to be bridged. o The WTP forwards any IEEE 802.11 Management Action frames received to the AC. o The WTP MAY locally bridge client data frames (and provide the necessary encryption and decryption services). The WTP MAY also tunnel client data frames to the AC, using 802.3 frame tunnel mode or 802.11 frame tunnel mode. 2.2. Roaming Behavior This section expands upon the examples provided in the previous section, and describes how the CAPWAP control protocol is used to provide secure roaming. Once a client has successfully associated with the network in a secure fashion, it is likely to attempt to roam to another WTP. Figure 6 shows an example of a currently associated station moving from its "Old WTP" to a "New WTP". The figure is valid for multiple different security policies, including IEEE 802.1X and WPA or WPA2, both with key caching (where the IEEE 802.1x exchange would be bypassed) and without. Calhoun, Editor, et al. Expires December 13, 2007 [Page 11]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 Client Old WTP New WTP AC Association Request/Response <--------------------------------------( - )--------------> Station Configuration Request[ Add Station (Station Message Elements)] <----------------> 802.1X Authentication (if no key cache entry exists) <--------------------------------------( - )--------------> 802.11 4-way Key Exchange <--------------------------------------( - )--------------> Station Configuration Request [Delete Station] <----------------------------------> Station Configuration Request [Add Station (AES-CCMP, PTK=x)] <----------------> Figure 6: Client Roaming Example 2.3. Group Key Refresh Periodically, the Group Key (GTK)for the BSS needs to be updated. The AC uses an EAPOL-Key frame to update the group key for each STA in the BSS. While the AC is updating the GTK, each L2 broadcast frame transmitted to the BSS needs to be duplicated and transmitted using both the current GTK and the new GTK. Once the GTK update process has completed, broadcast frames transmitted to the BSS will be encrypted using the new GTK. In the case of Split MAC, the AC needs to duplicate all broadcast packets and update the key index so that the packet is transmitted using both the current and new GTK to ensure that all STA's in the BSS receive the broadcast frames. In the case of local MAC, the WTP needs to duplicate and transmit broadcast frames using the appropriate index to ensure that all STA's in the BSS continue to receive broadcast frames. The Group Key update procedure is shown in the following figure. The AC will signal the update to the GTK using an IEEE 802.11 Configuration Request message, including an IEEE 802.11 Update WLAN message element with the new GTK, its index, the TSC for the Group Key and the Key Status set to 3 (begin GTK update). The AC will then begin updating the GTK for each STA. During this time, the AC (for Split MAC) or WTP (for Local MAC) MUST duplicate broadcast packets and transmit them encrypted with both the current and new GTK. When Calhoun, Editor, et al. Expires December 13, 2007 [Page 12]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 the AC has completed the GTK update to all STA's in the BSS, the AC MUST transmit an IEEE 802.11 Configuration Request message including an IEEE 802.11 Update WLAN message element containing the new GTK, its index, and the Key Status set to 4 (GTK update complete). Client WTP AC IEEE 802.11 WLAN Configuration Request [Update WLAN (GTK, GTK Index, GTK Start, Group TSC) ] <-------------------------------------------- 802.1X EAPoL (GTK Message 1) <-------------( - )------------------------------------------- 802.1X EAPoL (GTK Message 2) -------------( - )-------------------------------------------> IEEE 802.11 WLAN Configuration Request [ Update WLAN (GTK Index, GTK Complete) ] <-------------------------------------------- Figure 7: Group Key Update Procedure 2.4. BSSID to WLAN ID Mapping The CAPWAP protocol binding enables the WTP to assign BSSIDs upon creation of a WLAN (see Section 6.1). While manufacturers are free to assign BSSIDs using any arbitrary mechanism, it is advised that where possible the BSSIDs are assigned as a contiguous block. When assigned as a block, implementations can still assign any of the available BSSIDs to any WLAN. One possible method is for the WTP to assign the address using the following algorithm: base BSSID address + WLAN ID. The WTP communicates the maximum number of BSSIDs that it supports during configuration via the IEEE 802.11 WTP WLAN Radio Configuration message element (see Section 6.23). 2.5. Quality of Service for IEEE 802.11 MAC Management Messages It is recommended that IEEE 802.11 MAC Management frames be sent by both the AC and the WTP with appropriate Quality of Service values, listed below, to ensure that congestion in the network minimizes occurrences of packet loss. 802.1P: The precedence value of 7 SHOULD be used for all IEEE 802.11 MAC management frames, except for Probe Requests which SHOULD use 4. Calhoun, Editor, et al. Expires December 13, 2007 [Page 13]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 DSCP: The DSCP tag value of 46 SHOULD be used for all IEEE 802.11 MAC management frames, except for Probe Requests which SHOULD use 34. 2.6. Run State Operation The Run state is the normal state of operation for the CAPWAP protocol in both the WTP and the AC. When the WTP receives a WLAN Configuration Request message (see Section 3.1), it MUST respond with a WLAN Configuration Response message (see Section 3.2) and it remains in the Run state. When the AC sends a WLAN Configuration Request message (see Section 3.1) or receives the corresponding WLAN Configuration Response message (see Section 3.2) from the WTP, it remains in the Run state. Calhoun, Editor, et al. Expires December 13, 2007 [Page 14]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 3. IEEE 802.11 Specific CAPWAP Control Messages This section defines CAPWAP Control Messages that are specific to the IEEE 802.11 binding. Two messages are defined, IEEE 802.11 WLAN Configuration Request and IEEE 802.11 WLAN Configuration Response. See Section 4.4 in [3] for CAPWAP Control message definitions and the derivation of the Message Type value from the IANA Enterprise number. The valid message types for IEEE 802.11 specific control messages are listed below. The IANA Enterprise number used with these messages is 13277. CAPWAP Control Message Message Type Value IEEE 802.11 WLAN Configuration Request 3398912 IEEE 802.11 WLAN Configuration Response 3398913 3.1. IEEE 802.11 WLAN Configuration Request The IEEE 802.11 WLAN Configuration Request is sent by the AC to the WTP in order to change services provided by the WTP. This control message is used to either create, update or delete a WLAN on the WTP. The IEEE 802.11 WLAN Configuration Request is sent as a result of either some manual admistrative process (e.g., deleting a WLAN), or automatically to create a WLAN on a WTP. When sent automatically to create a WLAN, this control message is sent after the CAPWAP Configuration Update Request message (see Section 8.5 in [3]) has been received by the WTP. Upon receiving this control message, the WTP will modify the necessary services, and transmit an IEEE 802.11 WLAN Configuration Response. A WTP MAY provide service for more than one WLAN, therefore every WLAN is identified through a numerical index. For instance, a WTP that is capable of supporting up to 16 SSIDs, could accept up to 16 IEEE 802.11 WLAN Configuration Request messages that include the Add WLAN message element. Since the index is the primary identifier for a WLAN, an AC MAY attempt to ensure that the same WLAN is identified through the same index number on all of its WTPs. An AC that does not follow this approach MUST find some other means of maintaining a WLAN-Identifier- to-SSID mapping table. The following message elements MAY be included in the IEEE 802.11 Calhoun, Editor, et al. Expires December 13, 2007 [Page 15]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 WLAN Configuration Request message. Only one message element MUST be present. o IEEE 802.11 Add WLAN, see Section 6.1 o IEEE 802.11 Delete WLAN, see Section 6.4 o IEEE 802.11 Update WLAN, see Section 6.21 The following message element MAY be present. o IEEE 802.11 Information Element, see Section 6.6 3.2. IEEE 802.11 WLAN Configuration Response The IEEE 802.11 WLAN Configuration Response message is sent by the WTP to the AC. It is used to acknowledge receipt of an IEEE 802.11 WLAN Configuration Request message, and to indicate that the requested configuration was successfully applied, or that an error related to the processing of the IEEE 802.11 WLAN Configuration Request message occurred on the WTP. The following message element MAY be included in the IEEE 802.11 WLAN Configuration Response message. o IEEE 802.11 Assigned WTP BSSID, see Section 6.3 The following message element MUST be included in the IEEE 802.11 WLAN Configuration Response message. o Result Code, see Section 4.5.31 in [3] Calhoun, Editor, et al. Expires December 13, 2007 [Page 16]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 4. CAPWAP Data Message Bindings This section describes the CAPWAP Data Message bindings to support transport of IEEE 802.11 frames. Payload encapsulation: The CAPWAP protocol defines the CAPWAP data message, which is used to encapsulate a wireless payload. For IEEE 802.11, the IEEE 802.11 header and payload are encapsulated (excluding the IEEE 802.11 FCS checksum). The IEEE 802.11 FCS checksum is handled by the WTP. This allows the WTP to validate an IEEE 802.11 frame prior to sending it to the AC. Similarly, when an AC wishes to transmit a frame to a station, the WTP computes and adds the FCS checksum. Optional Wireless Specific Information: The optional CAPWAP header field (see Section 4.2 in [3]) is only used with CAPWAP data messages, and it serves two purposes, depending upon the direction of the message. For messages from the WTP to the AC, the field uses the format described in the "IEEE 802.11 Frame Info" field (see below). However, for messages sent by the AC to the WTP, the format used is described in the "Destination WLANs" field (also defined below). IEEE 802.11 Frame Info: When an IEEE 802.11 frame is received from a station over the air, it is encapsulated and this field is used to include radio and PHY specific information associated with the frame. The IEEE 802.11 Frame Info field has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RSSI | SNR | Data Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RSSI: RSSI is a signed, 8-bit value. It is the received signal strength indication, in dBm. SNR: SNR is a signed, 8-bit value. It is the signal to noise ratio of the received IEEE 802.11 frame, in dB. Data Rate: The data rate field is a 16 bit unsigned value. The contents of the field is set to 10 times the data rate in Mbps of the packet received by the WTP. For instance, a packet received at 5.5Mbps would be set to 55, while 11Mbps would be set to 110. Calhoun, Editor, et al. Expires December 13, 2007 [Page 17]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 Destination WLANs The Destination WLANs field is used to specify the target WLANs for a given frame, and is only used with broadcast and multicast frames. This field allows the AC to transmit a single broadcast or multicast frame to the WTP, and allows the WTP to perform the necessary frame replication. The field uses the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WLAN ID bitmap | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ WLAN ID bitmap: This bit field indicates the WLAN ID (see Section 6.1) on which the WTP will transmit the included frame. For instance, if a multicast packet is to be transmitted on WLANs 1 and 3, bits 1 and 3 of this field would be enabled. This field is to be set to zero for unicast packets and is unused if the WTP is not providing IEEE 802.11 encryption. Reserved: All implementations complying with this protocol MUST set to zero any bits that are reserved in the version of the protocol supported by that implementation. Receivers MUST ignore all bits not defined for the version of the protocol they support. Calhoun, Editor, et al. Expires December 13, 2007 [Page 18]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 5. CAPWAP Control Message bindings This section describes the IEEE 802.11 specific message elements included in CAPWAP Control Messages. 5.1. Discovery Request Message The following IEEE 802.11 specific message element MUST be included in the CAPWAP Discovery Request Message. o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 802.11 WTP Radio Information message element MUST be present for every radio in the WTP. 5.2. Discovery Response Message The following IEEE 802.11 specific message element MUST be included in the CAPWAP Discovery Response Message. o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 802.11 WTP Radio Information message element MUST be present for every radio in the WTP. 5.3. Primary Discovery Request Message The following IEEE 802.11 specific message element MUST be included in the CAPWAP Primary Discovery Request Message. o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 802.11 WTP Radio Information message element MUST be present for every radio in the WTP. 5.4. Primary Discovery Response Message The following IEEE 802.11 specific message element MUST be included in the CAPWAP Primary Discovery Response Message. o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 802.11 WTP Radio Information message element MUST be present for every radio in the WTP. 5.5. Join Request Message The following IEEE 802.11 specific message element MUST be included in the CAPWAP Join Request Message. o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 802.11 WTP Radio Information message element MUST be present for Calhoun, Editor, et al. Expires December 13, 2007 [Page 19]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 every radio in the WTP. 5.6. Join Response Message The following IEEE 802.11 specific message element MUST be included in the CAPWAP Join Response Message. o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 802.11 WTP Radio Information message element MUST be present for every radio in the WTP. 5.7. Configuration Status Message The following IEEE 802.11 specific message elements MAY be included in the CAPWAP Configuration Status Message. More than one of each message element listed MAY be included. o IEEE 802.11 Antenna, see Section 6.2 o IEEE 802.11 Direct Sequence Control, see Section 6.5 o IEEE 802.11 MAC Operation, see Section 6.7 o IEEE 802.11 Multi Domain Capability, see Section 6.9 o IEEE 802.11 OFDM Control, see Section 6.10 o IEEE 802.11 Supported Rates, see Section 6.17 o IEEE 802.11 Tx Power, see Section 6.18 o IEEE 802.11 TX Power Level, see Section 6.19 o IEEE 802.11 WTP Radio Configuration, see Section 6.23 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 802.11 WTP Radio Information message element MUST be present for every radio in the WTP. 5.8. Configuration Status Response Message The following IEEE 802.11 specific message elements MAY be included in the CAPWAP Configuration Status Response Message. More than one of each message element listed MAY be included. o IEEE 802.11 Antenna, see Section 6.2 Calhoun, Editor, et al. Expires December 13, 2007 [Page 20]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 o IEEE 802.11 Direct Sequence Control, see Section 6.5 o IEEE 802.11 MAC Operation, see Section 6.7 o IEEE 802.11 Multi Domain Capability, see Section 6.9 o IEEE 802.11 OFDM Control, see Section 6.10 o IEEE 802.11 Rate Set, see Section 6.11 o IEEE 802.11 Supported Rates, see Section 6.17 o IEEE 802.11 Tx Power, see Section 6.18 o IEEE 802.11 WTP Quality of Service, see Section 6.22 o IEEE 802.11 WTP Radio Configuration, see Section 6.23 5.9. Configuration Update Request Message The following IEEE 802.11 specific message elements MAY be included in the CAPWAP Configuration Update Request Message. More than one of each message element listed MAY be included. o IEEE 802.11 Antenna, see Section 6.2 o IEEE 802.11 Direct Sequence Control, see Section 6.5 o IEEE 802.11 MAC Operation, see Section 6.7 o IEEE 802.11 Multi Domain Capability, see Section 6.9 o IEEE 802.11 OFDM Control, see Section 6.10 o IEEE 802.11 Rate Set, see Section 6.11 o IEEE 802.11 RSNA Error Report From Station, see Section 6.12 o IEEE 802.11 Tx Power, see Section 6.18 o IEEE 802.11 WTP Quality of Service, see Section 6.22 o IEEE 802.11 WTP Radio Configuration, see Section 6.23 Calhoun, Editor, et al. Expires December 13, 2007 [Page 21]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 5.10. Station Configuration Request The following IEEE 802.11 specific message elements MAY included in the CAPWAP Station Configuration Request message. More than one of each message element listed MAY be included. o IEEE 802.11 Station, see Section 6.13 o IEEE 802.11 Station Session Key, see Section 6.15 o Station QoS Profile, see Section 6.14 5.11. Change State Event Request The following IEEE 802.11 specific message elements MAY included in the CAPWAP Station Configuration Request message. o IEEE 802.11 WTP Radio Fail Alarm Indication, see Section 6.24 5.12. WTP Event Request The following IEEE 802.11 specific message elements MAY be included in the CAPWAP WTP Event Request message.More than one of each message element listed MAY be included. o IEEE 802.11 MIC Countermeasures, see Section 6.8 o IEEE 802.11 RSNA Error Report From Station, see Section 6.12 o IEEE 802.11 Statistics, see Section 6.16 Calhoun, Editor, et al. Expires December 13, 2007 [Page 22]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 6. IEEE 802.11 Message Element Definitions The following IEEE 802.11 specific message elements are defined in this section. IEEE 802.11 Message Element Type Value IEEE 802.11 Add WLAN 1024 IEEE 802.11 Antenna 1025 IEEE 802.11 Assigned WTP BSSID 1026 IEEE 802.11 Delete WLAN 1027 IEEE 802.11 Direct Sequence Control 1028 IEEE 802.11 Information Element 1029 IEEE 802.11 MAC Operation 1030 IEEE 802.11 MIC Countermeasures 1031 IEEE 802.11 Multi-Domain Capability 1032 IEEE 802.11 OFDM Control 1033 IEEE 802.11 Rate Set 1034 IEEE 802.11 RSNA Error Report From Station 1035 IEEE 802.11 Station 1036 IEEE 802.11 Station QoS Profile 1037 IEEE 802.11 Station Session Key 1038 IEEE 802.11 Statistics 1039 IEEE 802.11 Supported Rates 1040 IEEE 802.11 Tx Power 1041 IEEE 802.11 Tx Power Level 1042 IEEE 802.11 Update Station QoS 1043 IEEE 802.11 Update WLAN 1044 IEEE 802.11 WTP Quality of Service 1045 IEEE 802.11 WTP Radio Configuration 1046 IEEE 802.11 WTP Radio Fail Alarm Indication 1047 IEEE 802.11 WTP Radio Information 1048 6.1. IEEE 802.11 Add WLAN The IEEE 802.11 Add WLAN message element is used by the AC to define a WLAN on the WTP. The inclusion of this message element MUST also include IEEE 802.11 Information Element message elements, containing the following IEEE 802.11 IEs: Power Capability information element Calhoun, Editor, et al. Expires December 13, 2007 [Page 23]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 WPA information element RSN information element EDCA Parameter Set information element QoS Capability information element WMM information element If present, the RSN information element is sent with the IEEE 802.11 Add WLAN message element to instruct the WTP on the usage of the Key field. An AC MAY include additional information elements as desired. The message element uses the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio ID | WLAN ID | Capabilities | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Index | Key Status | Key Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group TSC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group TSC | QoS | Auth Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Mode | Tunnel Mode | Suppress SSID | SSID ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 1024 for IEEE 802.11 Add WLAN Length: >= 49 Radio ID: An 8-bit value representing the radio. WLAN ID: An 8-bit value specifying the WLAN Identifier. Capability: A 16-bit value containing the capabilities information field to be advertised by the WTP in the Probe Request and Beacon frames. Calhoun, Editor, et al. Expires December 13, 2007 [Page 24]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 Key-Index: The Key Index associated with the key. Key Status: A 1 byte value that specifies the state and usage of the key that has been included. The following values describe the key usage and its status: 0 - A value of zero, with the inclusion of the RSN Information Element means that the WLAN uses per-station encryption keys, and therefore the key in the 'Key' field is only used for multicast traffic. 1 - When set to one, the WLAN employs a shared WEP key, also known as a static WEP key, and uses the encryption key for both unicast and multicast traffic for all stations. 2 - The value of 2 indicates that the AC will begin rekeying the GTK with the STA's in the BSS. It is only valid when IEEE 802.11 is enabled as the security policy for the BSS. 3 - The value of 3 indicates that the AC has completed rekeying the GTK and broadcast packets no longer need to be duplicated and transmitted with both GTK's. Key Length: A 16-bit value representing the length of the Key field. Key: A 32 byte Session Key to use to provide data privacy. For encryption schemes that employ a separate encryption key for unicast and multicast traffic, the key included here only applies to multicast frames, and the cipher suite is specified in an accompanied RSN Information Element. In these scenarios, the key and cipher information is communicated via the Add Station message element, see Section 4.5.8 in [3] and the IEEE 802.11 Station Session Key message element, see Section 6.15. Group TSC A 48-bit value containing the Transmit Sequence Counter for the updated group key. The WTP will set the TSC for broadcast/multicast frames to this value for the updated group key. QOS: An 8-bit value specifying the default QOS policy for the WTP to apply to network traffic received for a non-WMM enabled STA. The following values are supported: Calhoun, Editor, et al. Expires December 13, 2007 [Page 25]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 0 - Best Effort 1 - Video 2 - Voice 3 - Background Auth Type: An 8-bit value specifying the supported authentication type. The following values are supported: 0 - Open System 1 - WEP Shared Key MAC Mode: This field specifies whether the WTP should support the WLAN in Local or Split MAC modes. Note that the AC MUST NOT request a mode of operation that was not advertised by the WTP during the discovery process (see Section 4.4.42 in [3]). The following values are supported: 0 - Local-MAC: Service for the WLAN is to be provided in Local MAC mode. 1 - Split-MAC: Service for the WLAN is to be provided in Split MAC mode. Tunnel Mode: This field specifies the frame tunneling type to be used for 802.11 data frames from all stations associated with the WLAN. The AC MUST NOT request a mode of operation that was not advertised by the WTP during the discovery process (see Section 4.4.40 in [3]). IEEE 802.11 managment frames SHALL be tunneled using 802.11 Tunnel mode. The following values are supported: 0 - Local Bridging: All user traffic is to be locally bridged. 1 - 802.3 Tunnel: All user traffic is to be tunneled to the AC in 802.3 format (see Section 4.2 in [3]). 2 - 802.11 Tunnel: All user traffic is to be tunneled to the AC in 802.11 format. Calhoun, Editor, et al. Expires December 13, 2007 [Page 26]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 Supress SSID: A boolean indicating whether the SSID is to be advertised by the WTP. A value of zero supresses the SSID in the 802.11 Beacon and Probe Response frames, while a value of one will cause the WTP to populate the field. SSID: The SSID attribute is the service set identifier that will be advertised by the WTP for this WLAN. 6.2. IEEE 802.11 Antenna The IEEE 802.11 Antenna message element is communicated by the WTP to the AC to provide information on the antennas available. The AC MAY use this element to reconfigure the WTP's antennas. The message element contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio ID | Diversity | Combiner | Antenna Cnt | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Antenna Selection [0..N] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 1025 for IEEE 802.11 Antenna Length: >= 5 Radio ID: An 8-bit value representing the radio to configure. Diversity: An 8-bit value specifying whether the antenna is to provide receive diversity. The value of this field is the same as the IEEE 802.11 dot11DiversitySelectionRx MIB element, see [2]. The following values are supported: 0 - Disabled 1 - Enabled (may only be true if the antenna can be used as a receive antenna) Combiner: An 8-bit value specifying the combiner selection. The following values are supported: 1 - Sectorized (Left) 2 - Sectorized (Right) Calhoun, Editor, et al. Expires December 13, 2007 [Page 27]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 3 - Omni 4 - MIMO Antenna Count: An 8-bit value specifying the number of Antenna Selection fields. This value SHOULD be the same as the one found in the IEEE 802.11 dot11CurrentTxAntenna MIB element (see [2]). Antenna Selection: One 8-bit antenna configuration value per antenna in the WTP. The following values are supported: 1 - Internal Antenna 2 - External Antenna 6.3. IEEE 802.11 Assigned WTP BSSID The IEEE 802.11 Assigned WTP BSSID is only included by the WTP when the IEEE 802.11 WLAN Configuration Request included the IEEE 802.11 Add WLAN message element. The BSSID value field of this message element contains the BSSID that has been assigned by the WTP, enabling the WTP to perform its own BSSID assignment. The WTP is free to assign the BSSIDs the way it sees fit, but it is highly recommended that the WTP assign the BSSID using the following algorithm: BSSID = {base BSSID} + WLAN ID. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio ID | WLAN ID | BSSID +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BSSID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 1026 for IEEE 802.11 Assigned WTP BSSID Length: 6 Radio ID: An 8-bit value representing the radio. WLAN ID: An 8-bit value specifying the WLAN Identifier. BSSID: The BSSID assigned by the WTP for the WLAN created as a result of receiving an IEEE 802.11 Add WLAN. Calhoun, Editor, et al. Expires December 13, 2007 [Page 28]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 6.4. IEEE 802.11 Delete WLAN The IEEE 802.11 Delete WLAN message element is used to inform the WTP that a previously created WLAN is to be deleted, and contains the following fields: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio ID | WLAN ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 1027 for IEEE 802.11 Delete WLAN Length: 3 Radio ID: An 8-bit value representing the radio WLAN ID: An 8-bit value specifying the WLAN Identifier 6.5. IEEE 802.11 Direct Sequence Control The IEEE 802.11 Direct Sequence Control message element is a bi- directional element. When sent by the WTP, it contains the current state. When sent by the AC, the WTP MUST adhere to the values provided. This element is only used for IEEE 802.11b radios. The message element has the following fields. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio ID | Reserved | Current Chan | Current CCA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Energy Detect Threshold | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 1028 for IEEE 802.11 Direct Sequence Control Length: 8 Radio ID: An 8-bit value representing the radio to configure. Reserved: All implementations complying with this protocol MUST set to zero any bits that are reserved in the version of the protocol supported by that implementation. Receivers MUST ignore all bits not defined for the version of the protocol they support. Calhoun, Editor, et al. Expires December 13, 2007 [Page 29]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 Current Channel: This attribute contains the current operating frequency channel of the DSSS PHY. This value comes from the IEEE 802.11 dot11CurrentChannel MIB element (see [2]). Current CCA: The current CCA method in operation, whose value can be found in the IEEE 802.11 dot11CCAModeSupported MIB element (see [2]). Valid values are: 1 - energy detect only (edonly) 2 - carrier sense only (csonly) 4 - carrier sense and energy detect (edandcs) 8 - carrier sense with timer (cswithtimer) 16 - high rate carrier sense and energy detect (hrcsanded) Energy Detect Threshold: The current Energy Detect Threshold being used by the DSSS PHY. The value can be found in the IEEE 802.11 dot11EDThreshold MIB element (see [2]). 6.6. IEEE 802.11 Information Element The IEEE 802.11 Information Element is used to communicate any IE defined in the IEEE 802.11 protocol. The data field contains the raw IE as it would be included within an IEEE 802.11 MAC management message. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio ID | WLAN ID |B|P| Flags |Info Element... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 1029 for IEEE 802.11 Information Element Length: >= 2 Radio ID: An 8-bit value representing the radio. WLAN ID: An 8-bit value specifying the WLAN Identifier. B: When set, the WTP is to include the information element in IEEE 802.11 Beacons associated with the WLAN. Calhoun, Editor, et al. Expires December 13, 2007 [Page 30]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 P: When set, the WTP is to include the information element in Probe Responses associated with the WLAN. Flags: All implementations complying with this protocol MUST set to zero any bits that are reserved in the version of the protocol supported by that implementation. Receivers MUST ignore all bits not defined for the version of the protocol they support. Info Element: The IEEE 802.11 Information Element, which includes the type, length and value field. 6.7. IEEE 802.11 MAC Operation The IEEE 802.11 MAC Operation message element is sent by the AC to set the IEEE 802.11 MAC parameters on the WTP, and contains the following fields. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio ID | Reserved | RTS Threshold | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Short Retry | Long Retry | Fragmentation Threshold | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tx MSDU Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rx MSDU Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 1030 for IEEE 802.11 MAC Operation Length: 16 Radio ID: An 8-bit value representing the radio to configure. Reserved: All implementations complying with this protocol MUST set to zero any bits that are reserved in the version of the protocol supported by that implementation. Receivers MUST ignore all bits not defined for the version of the protocol they support. RTS Threshold: This attribute indicates the number of octets in an MPDU, below which an RTS/CTS handshake MUST NOT be performed. An RTS/CTS handshake MUST be performed at the beginning of any frame exchange sequence where the MPDU is of type Data or Management, the MPDU has an individual address in the Address1 field, and the length of the MPDU is greater than this threshold. Setting this attribute to be larger than the maximum MSDU size MUST have the effect of turning off the RTS/CTS handshake for frames of Data or Calhoun, Editor, et al. Expires December 13, 2007 [Page 31]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 Management type transmitted by this STA. Setting this attribute to zero MUST have the effect of turning on the RTS/CTS handshake for all frames of Data or Management type transmitted by this STA. The default value of this attribute MUST be 2347. The value of this field comes from the IEEE 802.11 dot11RTSThreshold MIB element, (see [2]). Short Retry: This attribute indicates the maximum number of transmission attempts of a frame, the length of which is less than or equal to RTSThreshold, that MUST be made before a failure condition is indicated. The default value of this attribute MUST be 7. The value of this field comes from the IEEE 802.11 dot11ShortRetryLimit MIB element, (see [2]). Long Retry: This attribute indicates the maximum number of transmission attempts of a frame, the length of which is greater than dot11RTSThreshold, that MUST be made before a failure condition is indicated. The default value of this attribute MUST be 4. The value of this field comes from the IEEE 802.11 dot11LongRetryLimit MIB element, (see [2]). Fragmentation Threshold: This attribute specifies the current maximum size, in octets, of the MPDU that MAY be delivered to the PHY. An MSDU MUST be broken into fragments if its size exceeds the value of this attribute after adding MAC headers and trailers. An MSDU or MMPDU MUST be fragmented when the resulting frame has an individual address in the Address1 field, and the length of the frame is larger than this threshold. The default value for this attribute MUST be the lesser of 2346 or the aMPDUMaxLength of the attached PHY and MUST never exceed the lesser of 2346 or the aMPDUMaxLength of the attached PHY. The value of this attribute MUST never be less than 256. The value of this field comes from the IEEE 802.11 dot11FragmentationThreshold MIB element, (see [2]). Tx MSDU Lifetime: This attribute speficies the elapsed time in TU, after the initial transmission of an MSDU, after which further attempts to transmit the MSDU MUST be terminated. The default value of this attribute MUST be 512. The value of this field comes from the IEEE 802.11 dot11MaxTransmitMSDULifetime MIB element, (see [2]). Rx MSDU Lifetime: This attribute specifies the elapsed time in TU, after the initial reception of a fragmented MMPDU or MSDU, after which further attempts to reassemble the MMPDU or MSDU MUST be terminated. The default value MUST be 512. The value of this field comes from the IEEE 802.11 dot11MaxReceiveLifetime MIB element, (see [2]). Calhoun, Editor, et al. Expires December 13, 2007 [Page 32]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 6.8. IEEE 802.11 MIC Countermeasures The IEEE 802.11 MIC Countermeasures message element is sent by the WTP to the AC to indicate the occurrence of a MIC failure. For more information on MIC failure events, see the dot11RSNATKIPCounterMeasuresInvoked MIB element definition in [2]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio ID | WLAN ID | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 1031 for IEEE 802.11 MIC Countermeasures Length: 8 Radio ID: The Radio Identifier, typically refers to some interface index on the WTP. WLAN ID: This 8-bit unsigned integer includes the WLAN Identifier, on which the MIC failure occurred. MAC Address: The MAC Address of the station that caused the MIC failure. 6.9. IEEE 802.11 Multi-Domain Capability The IEEE 802.11 Multi-Domain Capability message element is used by the AC to inform the WTP of regulatory limits. The AC will transmit one message element per frequency band to indicate the regulatory constraints in that domain. The message element contains the following fields. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio ID | Reserved | First Channel # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Channels | Max Tx Power Level | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Calhoun, Editor, et al. Expires December 13, 2007 [Page 33]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 Type: 1032 for IEEE 802.11 Multi-Domain Capability Length: 8 Radio ID: An 8-bit value representing the radio to configure. Reserved: All implementations complying with this protocol MUST set to zero any bits that are reserved in the version of the protocol supported by that implementation. Receivers MUST ignore all bits not defined for the version of the protocol they support. First Channnel #: This attribute indicates the value of the lowest channel number in the subband for the associated domain country string. The value of this field comes from the IEEE 802.11 dot11FirstChannelNumber MIB element (see [2]). Number of Channels: This attribute indicates the value of the total number of channels allowed in the subband for the associated domain country string. The value of this field comes from the IEEE 802.11 dot11NumberofChannels MIB element (see [2]). Max Tx Power Level: This attribute indicates the maximum transmit power, in dBm, allowed in the subband for the associated domain country string. The value of this field comes from the IEEE 802.11 dot11MaximumTransmitPowerLevel MIB element (see [2]). 6.10. IEEE 802.11 OFDM Control The IEEE 802.11 OFDM Control message element is a bi-directional element. When sent by the WTP, it contains the current state. When sent by the AC, the WTP MUST adhere to the received values. This message element is only used for 802.11a radios and contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio ID | Reserved | Current Chan | Band Support | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TI Threshold | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 1033 for IEEE 802.11 OFDM Control Length: 8 Calhoun, Editor, et al. Expires December 13, 2007 [Page 34]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 Radio ID: An 8-bit value representing the radio to configure. Reserved: All implementations complying with this protocol MUST set to zero any bits that are reserved in the version of the protocol supported by that implementation. Receivers MUST ignore all bits not defined for the version of the protocol they support. Current Channel: This attribute contains the current operating frequency channel of the OFDM PHY. The value of this field comes from the IEEE 802.11 dot11CurrentFrequency MIB element (see [2]). Band Supported: The capability of the OFDM PHY implementation to operate in the three U-NII bands. The value of this field comes from the IEEE 802.11 dot11FrequencyBandsSupported MIB element (see [2]), coded as an integer value of a three bit field as follows: Bit 0 - capable of operating in the lower (5.15-5.25 GHz) U-NII band Bit 1 - capable of operating in the middle (5.25-5.35 GHz) U-NII band Bit 2 - capable of operating in the upper (5.725-5.825 GHz) U-NII band For example, for an implementation capable of operating in the lower and mid bands this attribute would take the value 3. TI Threshold: The Threshold being used to detect a busy medium (frequency). CCA MUST report a busy medium upon detecting the RSSI above this threshold. The value of this field comes from the IEEE 802.11 dot11TIThreshold MIB element (see [2]). 6.11. IEEE 802.11 Rate Set The rate set message element value is sent by the AC and contains the supported operational rates. It contains the following fields. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio ID | Rate Set... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Calhoun, Editor, et al. Expires December 13, 2007 [Page 35]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 Type: 1034 for IEEE 802.11 Rate Set Length: >= 3 Radio ID: An 8-bit value representing the radio to configure. Rate Set: The AC generates the Rate Set that the WTP is to include in its Beacon and Probe messages. The length of this field is between 2 and 8 bytes. The value of this field comes from the IEEE 802.11 dot11OperationalRateSet MIB element (see [2]). 6.12. IEEE 802.11 RSNA Error Report From Station The IEEE 802.11 RSN Error Report From Station message element is used by a WTP to send RSN error reports to the AC. The WTP does not need to transmit any reports that do not include any failures. The fields from this message element come from the IEEE 802.11 Dot11RSNAStatsEntry table, see [2]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Client MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Client MAC Address | BSSID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BSSID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio ID | WLAN ID | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TKIP ICV Errors | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TKIP Local MIC Failures | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TKIP Remote MIC Failures | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CCMP Replays | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CCMP Decrypt Errors | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TKIP Replays | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Calhoun, Editor, et al. Expires December 13, 2007 [Page 36]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 Type: 1035 for IEEE 802.11 RSNA Error Report From Station Length: 14 Client MAC Address: The Client MAC Address of the station. BSSID: The BSSID on which the failures are being reported on. Radio ID: The Radio Identifier, typically refers to some interface index on the WTP WLAN ID: The WLAN ID on which the RSNA failures are being reported. Reserved: All implementations complying with this protocol MUST set to zero any bits that are reserved in the version of the protocol supported by that implementation. Receivers MUST ignore all bits not defined for the version of the protocol they support. TKIP ICV Errors: A 32-bit value representing the number of TKIP ICV errors encountered when decrypting packets from the station. The value of this field comes from the IEEE 802.11 dot11RSNAStatsTKIPICVErrors MIB element (see [2]). TKIP Local MIC Failures: A 32-bit value representing the number of MIC failures encountered when checking the integrity of packets received from the station. The value of this field comes from the IEEE 802.11 dot11RSNAStatsTKIPLocalMICFailures MIB element (see [2]). TKIP Remote MIC Failures: A 32-bit value representing the number of MIC failures reported by the station encountered (possibly via the EAPOL-Key frame). The value of this field comes from the IEEE 802.11 dot11RSNAStatsTKIPRemoteMICFailures MIB element (see [2]). CCMP Replays: A 32-bit value representing the number of CCMP MPDUs discarded by the replay detection mechanism. The value of this field comes from the IEEE 802.11 dot11RSNACCMPReplays MIB element (see [2]). CCMP Decrypt Errors: A 32-bit value representing the number of CCMP MDPUs discarded by the decryption algorithm. The value of this field comes from the IEEE 802.11 dot11RSNACCMPDecryptErrors MIB element (see [2]). TKIP Replays: A 32-bit value representing the number of TKIP Replays detected in frames received from the station. The value of this field comes from the IEEE 802.11 dot11RSNAStatsTKIPReplays MIB element (see [2]). Calhoun, Editor, et al. Expires December 13, 2007 [Page 37]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 6.13. IEEE 802.11 Station The IEEE 802.11 Station message element accompanies the Add Station message element, and is used to deliver IEEE 802.11 station policy from the AC to the WTP. The latest IEEE 802.11 Station message element overrides any previously received message elements. If the QoS field is set, the WTP MUST observe and provide policing of the 802.11e priority tag to ensure that it does not exceed the value provided by the AC. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio ID | Association ID | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address | Capabilities | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WLAN ID |Supported Rates| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 1036 for IEEE 802.11 Station Length: >= 8 Radio ID: An 8-bit value representing the radio Association ID: A 16-bit value specifying the IEEE 802.11 Association Identifier Flags: All implementations complying with this protocol MUST set to zero any bits that are reserved in the version of the protocol supported by that implementation. Receivers MUST ignore all bits not defined for the version of the protocol they support. MAC Address: The station's MAC Address Capabilities: A 16-bit field containing the IEEE 802.11 Capabilities Information Field to use with the station. WLAN ID: An 8-bit value specifying the WLAN Identifier Calhoun, Editor, et al. Expires December 13, 2007 [Page 38]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 Supported Rates: The variable length field containing the supported rates to be used with the station, as found in the IEEE 802.11 dot11OperationalRateSet MIB element (see [2]). 6.14. IEEE 802.11 Station QoS Profile The IEEE 802.11 Station QoS Profile message element contains the maximum IEEE 802.11e priority tag that may be used by the station. Any packet received that exceeds the value encoded in this message element MUST either be dropped or tagged using the maximum value permitted by to the user. The priority tag MUST be between zero (0) and seven (7). This message element MUST NOT be present without the IEEE 802.11 Station (see Section 6.13) message element 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address | 802.1P Precedence Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 1037 for IEEE 802.11 Station QOS Profile Length: 8 MAC Address: The station's MAC Address 802.1P Precedence Tag: The maximum 802.1P precedence value that the WTP will allow in the TID field in the extended 802.11e QOS Data header. 6.15. IEEE 802.11 Station Session Key The IEEE 802.11 Station Session Key message element is sent when the AC determines that encryption of a station must be performed in the WTP. This message element MUST NOT be present without the IEEE 802.11 Station (see Section 6.13) message element, and MUST NOT be sent if the WTP had not specifically advertised support for the requested encryption scheme. The RSN information element MUST sent along with the IEEE 802.11 Station Session Key in order to instruct the WTP on the usage of the Key field. The AKM field of the RSM information element is used by the WTP to identify the authentication protocol. If the IEEE 802.11 Station Session Key message element's AKM-Only bit is set, the WTP MUST drop all IEEE 802.11 packets that are not part Calhoun, Editor, et al. Expires December 13, 2007 [Page 39]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 of the AKM (e.g., EAP). Note that AKM-Only is MAY be set while an encryption key is in force, requiring that the AKM packets be encrypted. Once the station has successfully completed authentication via the AKM, the AC MUST send a new Add Station message element to remove the AKM-Only restriction, and optionally push the session key down to the WTP. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address |A|C| Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pairwise TSC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pairwise TSC | Pairwise RSC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pairwise RSC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key... +-+-+-+-+-+-+-+- Type: 1038 for IEEE 802.11 Station Session Key Length: >= 25 MAC Address: The station's MAC Address Flags: All implementations complying with this protocol MUST set to zero any bits that are reserved in the version of the protocol supported by that implementation. Receivers MUST ignore all bits not defined for the version of the protocol they support. The following bits are defined: A: The one bit AKM-Only field is set by the AC to inform the WTP that is MUST NOT accept any 802.11 data frames, other than AKM frames. This is the equivalent of the WTP's IEEE 802.1X port for the station to be in the closed state. When set, the WTP MUST drop any non-IEEE 802.1X packets it receives from the station. C: The one bit field is set by the AC to inform the WTP that encryption services will be provided by the AC. When set, the WTP SHOULD police frames received from stations to ensure that are properly encrypted as specified in the RSN Information Element, but does not need to take specific cryptographic action on the frame. Similarly, for transmitted frames, the Calhoun, Editor, et al. Expires December 13, 2007 [Page 40]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 WTP only needs to forward already encrypted frames. Pairwise TSC: The 6 byte Transmit Sequence Counter (TSC) field to use for unicast packets transmitted to the station. Pairwise RSC: The 6 byte Receive Sequence Counter (RSC) to use for unicast packets received from the station. Key: The key the WTP is to use when encrypting traffic to/from the station. For dynamically created keys, this is commonly known as a Pairwise Transient Key (PTK). 6.16. IEEE 802.11 Statistics The IEEE 802.11 Statistics message element is sent by the WTP to transmit its current statistics, and contains the following fields. Calhoun, Editor, et al. Expires December 13, 2007 [Page 41]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio ID | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tx Fragment Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Tx Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Failed Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Retry Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multiple Retry Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frame Duplicate Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTS Success Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTS Failure Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACK Failure Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rx Fragment Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast RX Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FCS Error Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tx Frame Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Decryption Errors | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Discarded QoS Fragment Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Associated Station Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QoS CF Polls Received Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QoS CF Polls Unused Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QoS CF Polls Unusable Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Calhoun, Editor, et al. Expires December 13, 2007 [Page 42]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 Type: 1039 for IEEE 802.11 Statistics Length: 60 Radio ID: An 8-bit value representing the radio. Reserved: All implementations complying with this protocol MUST set to zero any bits that are reserved in the version of the protocol supported by that implementation. Receivers MUST ignore all bits not defined for the version of the protocol they support. Tx Fragment Count: A 32-bit value representing the number of fragmented frames transmitted. The value of this field comes from the IEEE 802.11 dot11TransmittedFragmentCount MIB element (see [2]). Multicast Tx Count: A 32-bit value representing the number of multicast frames transmitted. The value of this field comes from the IEEE 802.11 dot11MulticastTransmittedFrameCount MIB element (see [2]). Failed Count: A 32-bit value representing the transmit excessive retries. The value of this field comes from the IEEE 802.11 dot11FailedCount MIB element (see [2]). Retry Count: A 32-bit value representing the number of transmit retries. The value of this field comes from the IEEE 802.11 dot11RetryCount MIB element (see [2]). Multiple Retry Count: A 32-bit value representing the number of transmits that required more than one retry. The value of this field comes from the IEEE 802.11 dot11MultipleRetryCount MIB element (see [2]). Frame Duplicate Count: A 32-bit value representing the duplicate frames received. The value of this field comes from the IEEE 802.11 dot11FrameDuplicateCount MIB element (see [2]). RTS Success Count: A 32-bit value representing the number of successfully transmitted Ready To Send (RTS). The value of this field comes from the IEEE 802.11 dot11RTSSuccessCount MIB element (see [2]). RTS Failure Count: A 32-bit value representing the failed transmitted RTS. The value of this field comes from the IEEE 802.11 dot11RTSFailureCount MIB element (see [2]). Calhoun, Editor, et al. Expires December 13, 2007 [Page 43]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 ACK Failure Count: A 32-bit value representing the number of failed acknowledgements. The value of this field comes from the IEEE 802.11 dot11ACKFailureCount MIB element (see [2]). Rx Fragment Count: A 32-bit value representing the number of fragmented frames received. The value of this field comes from the IEEE 802.11 dot11ReceivedFragmentCount MIB element (see [2]). Multicast RX Count: A 32-bit value representing the number of multicast frames received. The value of this field comes from the IEEE 802.11 dot11MulticastReceivedFrameCount MIB element (see [2]). FCS Error Count: A 32-bit value representing the number of FCS failures. The value of this field comes from the IEEE 802.11 dot11FCSErrorCount MIB element (see [2]). Decryption Errors: A 32-bit value representing the number of Decryption errors that occurred on the WTP. Note that this field is only valid in cases where the WTP provides encryption/ decryption services. The value of this field comes from the IEEE 802.11 dot11WEPUndecryptableCount MIB element (see [2]). Discarded QoS Fragment Count: A 32-bit value representing the number of discarded QoS fragments received. The value of this field comes from the IEEE 802.11 dot11QoSDiscardedFragmentCount MIB element (see [2]). Associated Station Count: A 32-bit value representing the number of number of associated stations. The value of this field comes from the IEEE 802.11 dot11AssociatedStationCount MIB element (see [2]). QoS CF Polls Received Count: A 32-bit value representing the number of (+)CF-Polls received. The value of this field comes from the IEEE 802.11 dot11QosCFPollsReceivedCount MIB element (see [2]). QoS CF Polls Unused Count: A 32-bit value representing the number of (+)CF-Polls that have been received, but not used. The value of this field comes from the IEEE 802.11 dot11QosCFPollsUnusedCount MIB element (see [2]). QoS CF Polls Unusable Count: A 32-bit value representing the number of (+)CF-Polls that have been received, but could not be used due to the TXOP size being smaller than the timethat is required for one frame exchange sequence. The value of this field comes from the IEEE 802.11 dot11QosCFPollsUnusableCount MIB element (see [2]). Calhoun, Editor, et al. Expires December 13, 2007 [Page 44]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 6.17. IEEE 802.11 Supported Rates The IEEE 802.11 Supported Rates message element is sent by the WTP to indicate the rates that it supports, and contains the following fields. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio ID | Supported Rates... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 1040 for IEEE 802.11 Supported Rates Length: >= 3 Radio ID: An 8-bit value representing the radio. Supported Rates: The WTP includes the Supported Rates that its hardware supports. The format is identical to the Rate Set message element and is between 2 and 8 bytes in length. 6.18. IEEE 802.11 Tx Power The IEEE 802.11 Tx Power message element value is bi-directional. When sent by the WTP, it contains the current power level of the radio in question. When sent by the AC, it contains the power level the WTP MUST adhere to. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio ID | Reserved | Current Tx Power | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 1041 for IEEE 802.11 Tx Power Length: 4 Radio ID: An 8-bit value representing the radio to configure. Reserved: All implementations complying with this protocol MUST set to zero any bits that are reserved in the version of the protocol supported by that implementation. Receivers MUST ignore all bits not defined for the version of the protocol they support. Calhoun, Editor, et al. Expires December 13, 2007 [Page 45]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 Current Tx Power: This attribute contains the current transmit output power in mW, as described in the dot11CurrentTxPowerLevel MIB variable, see [2]. 6.19. IEEE 802.11 Tx Power Level The IEEE 802.11 Tx Power Level message element is sent by the WTP and contains the different power levels supported. The values found in this message element are found in the IEEE 802.11 Dot11PhyTxPowerEntry MIB table, see [2]. The value field contains the following: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio ID | Num Levels | Power Level [n] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 1042 for IEEE 802.11 Tx Power Level Length: >= 4 Radio ID: An 8-bit value representing the radio to configure. Num Levels: The number of power level attributes. The value of this field comes from the IEEE 802.11 dot11NumberSupportedPowerLevels MIB element (see [2]). Power Level: Each power level fields contains a supported power level, in mW. The value of this field comes from the corresponding IEEE 802.11 dot11TxPowerLevel[n] MIB element, see [2]. 6.20. IEEE 802.11 Update Station QoS The IEEE 802.11 Update Station QoS message element is used to change the Quality of Service policy on the WTP for a given station. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio ID | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address | DSCP Tag | 802.1P Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Calhoun, Editor, et al. Expires December 13, 2007 [Page 46]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 Type: 1043 for IEEE 802.11 Update Station QoS Length: 8 Radio ID: The Radio Identifier, typically refers to some interface index on the WTP MAC Address: The station's MAC Address. DSCP Tag: The DSCP label to use if packets are to be DSCP tagged. 802.1P Tag: The 802.1P precedence value to use if packets are to be IEEE 802.1P tagged. 6.21. IEEE 802.11 Update WLAN The IEEE 802.11 Update WLAN message element is used by the AC to define a wireless LAN on the WTP. The inclusion of this message element MUST also include the IEEE 802.11 Information Element message element, containing the following 802.11 IEs: Power Capability information element WPA information element RSN information element EDCA Parameter Set information element QoS Capability information element WMM information element The message element uses the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio ID | WLAN ID | Capability | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Index | Key Status | Key Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Calhoun, Editor, et al. Expires December 13, 2007 [Page 47]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 Type: 1044 for IEEE 802.11 Update WLAN Length: 43 Radio ID: An 8-bit value representing the radio. WLAN ID: An 8-bit value specifying the WLAN Identifier. Capability: A 16-bit value containing the capabilities information field to be advertised by the WTP within the Probe and Beacon messages. Key-Index: The Key Index associated with the key. Key Status: A 1 byte value that specifies the state and usage of the key that has been included. The following values describe the key usage and its status: 0 - A value of zero, with the inclusion of the RSN Information Element means that the WLAN uses per-station encryption keys, and therefore the key in the 'Key' field is only used for multicast traffic. 1 - When set to one, the WLAN employs a shared WEP key, also known as a static WEP key, and uses the encryption key for both unicast and multicast traffic for all stations. 2 - The value of 2 indicates that the AC will begin rekeying the GTK with the STA's in the BSS. It is only valid when IEEE 802.11 is enabled as the security policy for the BSS. 3 - The value of 3 indicates that the AC has completed rekeying the GTK and broadcast packets no longer need to be duplicated and transmitted with both GTK's. Key Length: A 16-bit value representing the length of the Key field. Key: A 32 byte Session Key to use to provide data privacy. For static WEP keys, which is true when the 'Key Status' bit is set to one, this key is used for both unicast and multicast traffic. For encryption schemes that employ a separate encryption key for unicast and multicast traffic, the key included hereonly applies to multicast data, and the cipher suite is specified in an accompanied RSN Information Element. In these scenarios, the key, and cipher information, is communicated via the Add Station message element, see Section 4.5.8 in [3]. Calhoun, Editor, et al. Expires December 13, 2007 [Page 48]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 6.22. IEEE 802.11 WTP Quality of Service The IEEE 802.11 WTP Quality of Service message element value is sent by the AC to the WTP to communicate quality of service configuration information. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio ID | Tag Packets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 1045 for IEEE 802.11 WTP Quality of Service Length: >= 2 Radio ID: The Radio Identifier, typically refers to some interface index on the WTP Tag Packets: A value indicating whether CAPWAP packets should be tagged for QoS purposes. The following values are currently supported: 0 - Untagged 1 - 802.1P 2 - DSCP Immediately following the above header is the following data structure. This data structure will be repeated five times; once for every QoS profile. The order of the QoS profiles are Voice, Video, Best Effort and Background. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Queue Depth | CWMin | CWMax | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CWMax | AIFS | Dot1P Tag | DSCP Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Queue Depth: The number of packets that can be on the specific QoS transmit queue at any given time. Calhoun, Editor, et al. Expires December 13, 2007 [Page 49]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 CWMin: The Contention Window minimum value for the QoS transmit queue. The value of this field comes from the IEEE 802.11 dot11EDCATableCWMin MIB element (see [2]). CWMax: The Contention Window maximum value for the QoS transmit queue. The value of this field comes from the IEEE 802.11 dot11EDCATableCWMax MIB element (see [2]). AIFS: The Arbitration Inter Frame Spacing to use for the QoS transmit queue. The value of this field comes from the IEEE 802.11 dot11EDCATableAIFSN MIB element (see [2]). Dot1P Tag: The 802.1P precedence value to use if packets are to be 802.1P tagged. DSCP Tag: The DSCP label to use if packets are to be DSCP tagged. 6.23. IEEE 802.11 WTP Radio Configuration The IEEE 802.11 WTP WLAN Radio Configuration message element is used by the AC to configure a Radio on the WTP, and by the WTP to deliver its radio configuration to the AC. The message element value contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio ID |Short Preamble| Num of BSSIDs | DTIM Period | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BSSID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BSSID | Beacon Period | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Country Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 1046 for IEEE 802.11 WTP WLAN Radio Configuration Length: 16 Radio ID: An 8-bit value representing the radio to configure. Short Preamble: An 8-bit value indicating whether short preamble is supported. The following values are currently supported: Calhoun, Editor, et al. Expires December 13, 2007 [Page 50]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 0 - Short preamble not supported. 1 - Short preamble is supported. BSSID: The WLAN Radio's base MAC Address. Number of BSSIDs: This attribute contains the maximum number of BSSIDs supported by the WTP. This value restricts the number of logical networks supported by the WTP, and is between 1 and 16. DTIM Period: This attribute specifies the number of beacon intervals that elapse between transmission of Beacons frames containing a TIM element whose DTIM Count field is 0. This value is transmitted in the DTIM Period field of Beacon frames. The value of this field comes from the IEEE 802.11 dot11DTIMPeriod MIB element (see [2]). Beacon Period: This attribute specifies the number of TU that a station uses for scheduling Beacon transmissions. This value is transmitted in Beacon and Probe Response frames. The value of this field comes from the IEEE 802.11 dot11BeaconPeriod MIB element (see [2]). Country Code: This attribute identifies the country in which the station is operating. The value of this field comes from the IEEE 802.11 dot11CountryString MIB element (see [2]). Special attention is required with use of this field, as implementations which take action based on this field could violate regulatory requirements. Some regulatory bodies do permit configuration of the country code under certain restrictions, such as the FCC, when WTPs are certified as Software Defined Radios. The WTP and AC MAY ignore the value of this field, depending upon regulatory requirements, for example to avoid classification as a Software Defined Radio. When this field is used, the first two octets of this string is the two character country code as described in document ISO/IEC 3166- 1, and the third octet MUST have the value 1, 2 or 3 as defined below. When the value of the third octet is 255, the country code field is not used, and MUST be ignored. 1 an ASCII space character, if the regulations under which the station is operating encompass all environments in the country, 2 an ASCII 'O' character, if the regulations under which the station is operating are for an outdoor environment only, or Calhoun, Editor, et al. Expires December 13, 2007 [Page 51]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 3 an ASCII 'I' character, if the regulations under which the station is operating are for an indoor environment only 255 Country Code field is not used; ignore the field. 6.24. IEEE 802.11 WTP Radio Fail Alarm Indication The IEEE 802.11 WTP Radio Fail Alarm Indication message element is sent by the WTP to the AC when it detects a radio failure. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio ID | Type | Status | Pad | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 1047 for IEEE 802.11 WTP Radio Fail Alarm Indication Length: 4 Radio ID: The Radio Identifier, typically refers to some interface index on the WTP Type: The type of radio failure detected. The following values are supported: 1 - Receiver 2 - Transmitter Status: An 8-bit boolean indicating whether the radio failure is being reported or cleared. A value of zero is used to clear the event, while a value of one is used to report the event. Pad: All implementations complying with version zero of this protocol MUST set these bits to zero. Receivers MUST ignore all bits not defined for the version of the protocol they support. 6.25. IEEE 802.11 WTP Radio Information The IEEE 802.11 WTP Radio Information message element is used to communicate the radio information for each IEEE 802.11 radio in the WTP. The Discovery Request message, Primary Discovery Request message and Join Request message MUST include one such message element per radio in the WTP. The Radio-Type field is used by the AC in order to determine which IEEE 802.11 technology specific binding is to be used with the WTP. Calhoun, Editor, et al. Expires December 13, 2007 [Page 52]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 The message element contains two fields, as shown below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio ID | Radio Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio Type | +-+-+-+-+-+-+-+-+ Type: 1048 for IEEE 802.11 WTP Radio Information Length: 5 Radio ID: The Radio Identifier, which typically refers to an interface index on the WTP Radio Type: The type of radio present. Note this bitfield can be used to specify support for more than a single type of PHY/MAC. The following values are supported: 1 - 802.11b: An IEEE 802.11b radio. 2 - 802.11a: An IEEE 802.11a radio. 4 - 802.11g: An IEEE 802.11g radio. 8 - 802.11n: An IEEE 802.11n radio. 0xOF - 802.11b, 802.11a, 802.11g and 802.11n: The 4 radio types indicated are supported in the WTP. Calhoun, Editor, et al. Expires December 13, 2007 [Page 53]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 7. IEEE 802.11 Binding WTP Saved Variables This section contains the IEEE 802.11 binding specific variables that SHOULD be saved in non-volatile memory on the WTP. 7.1. IEEE80211AntennaInfo The WTP per radio antenna configuration, defined in Section 6.2. 7.2. IEEE80211DSControl The WTP per radio Direct Sequence Control configuration, defined in Section 6.5. 7.3. IEEE80211MACOperation The WTP per radio MAC Operation configuration, defined in Section 6.7. 7.4. IEEE80211OFDMControl The WTP per radio MAC Operation configuration, defined in Section 6.10. 7.5. IEEE80211Rateset The WTP per radio Basic Rate Set configuration, defined in Section 6.11. 7.6. IEEE80211TxPower The WTP per radio Transmit Power configuration, defined in Section 6.18. 7.7. IEEE80211QoS The WTP per radio Quality of Service configuration, defined in Section 6.22. 7.8. IEEE80211RadioConfig The WTP per radio Radio Configuration, defined in Section 6.23. Calhoun, Editor, et al. Expires December 13, 2007 [Page 54]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 8. Technology Specific Message Element Values This section lists IEEE 802.11 specific values for the generic CAPWAP message elements which include fields whose values are technology specific. IEEE 802.11 uses the following values: 4 - Encrypt AES-CCMP 128: WTP supports AES-CCMP, as defined in [4]. 5 - Encrypt TKIP-MIC: WTP supports TKIP and Michael, as defined in [7]. Calhoun, Editor, et al. Expires December 13, 2007 [Page 55]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 9. Security Considerations This section describes security considerations for using IEEE 802.11 with the CAPWAP protocol. 9.1. IEEE 802.11 Security When used with an IEEE 802.11 infrastructure with WEP encryption, the CAPWAP protocol does not add any new vulnerabilities. Derived session keys between the STA and WTP can be compromised, resulting in many well-documented attacks. Implementors SHOULD discourage the use of WEP and encourage use of technically sound cryptographic solutions such as those in an IEEE 802.11 RSN. STA authentication is performed using IEEE 802.lX, and consequently EAP. Implementors SHOULD use EAP methods meeting the requirements specified [5]. When used with IEEE 802.11 RSN security, the CAPWAP protocol may introduce new vulnerabilities, depending on whether the link security (packet encryption and integrity verification) is provided by the WTP or the AC. When the link security function is provided by the AC, no new security concerns are introduced. However, when the WTP provides link security, a new vulnerability will exist when the following conditions are true: o The client is not the first to associate to the WTP/ESSID (i.e. other clients are associated), and a GTK already exists o traffic has been broadcast under the existing GTK Under these circumstances, the receive sequence counter (KeyRSC) associated with the GTK is non-zero, but because the AC anchors the 4-way handshake with the client, the exact value of the KeyRSC is not known when the AC constructs the message containing the GTK. The client will update its Key RSC value to the current valid KeyRSC upon receipt of a valid multicast/broadcast message, but prior to this, previous multicast/broadcast traffic which was secured with the existing GTK may be replayed, and the client will accept this traffic as valid. Typically, busy networks will produce numerous multicast or broadcast frames per second, so the window of opportunity with respect to such replay is expected to be very small. In most conditions, it is expected that replayed frames could be detected (and logged) by the WTP. Calhoun, Editor, et al. Expires December 13, 2007 [Page 56]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 The only way to completely close this window is to provide the exact KeyRSC value in message 3 of the 4-way handshake; any other approach simply narrows the window to varying degrees. Given the low relative threat level this presents, the additional complexity introduced by providing the exact KeyRSC value is not warranted. That is, this specification provides for a calculated risk in this regard. The AC SHOULD use an RSC of 0 when computing message-3 of the 4-way 802.11i handshake, unless the AC has knowledge of a more optimal RSC value to use. Mechanisms for determining a more optimal RSC value are outside the scope of this specification. Calhoun, Editor, et al. Expires December 13, 2007 [Page 57]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 10. IANA Considerations There are no IANA Considerations. Calhoun, Editor, et al. Expires December 13, 2007 [Page 58]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 11. Acknowledgements The following individuals are acknowledged for their contributions to this binding specification: Puneet Agarwal, Charles Clancy, Saravanan Govindan, Scott Kelly, Peter Nilsson, Bob O'Hara, David Perkins and Margaret Wasserman. Calhoun, Editor, et al. Expires December 13, 2007 [Page 59]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 12. References 12.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications", IEEE Standard 802.11, 1999, <http://standards.ieee.org/getieee802/download/802.11-1999.pdf>. [3] Calhoun, P., Montemurro, M., Stanley, D., "CAPWAP Protocol Specification", draft-ietf-capwap-protocol-specification-07 (work in progress), June 2007. [4] "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications Amendment 6: Medium Access Control (MAC) Security Enhancements", IEEE Standard 802.11i, July 2004, <http://standards.ieee.org/getieee802/download/ 802.11i-2004.pdf>. 12.2. Informational References [5] Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, March 2005. [6] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy for Control and Provisioning of Wireless Access Points (CAPWAP)", RFC 4118, June 2005. [7] "WiFi Protected Access (WPA), WPAfor802.11ver3_073004.pdf", August 2004. Calhoun, Editor, et al. Expires December 13, 2007 [Page 60]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 Editors' Addresses Pat R. Calhoun Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 Phone: +1 408-853-5269 Email: pcalhoun@cisco.com Michael P. Montemurro Research In Motion 5090 Commerce Blvd Mississauga, ON L4W 5M4 Canada Phone: +1 905-629-4746 x4999 Email: mmontemurro@rim.com Dorothy Stanley Aruba Networks 1322 Crossman Ave Sunnyvale, CA 94089 Phone: +1 630-363-1389 Email: dstanley@arubanetworks.com Calhoun, Editor, et al. Expires December 13, 2007 [Page 61]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 June 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Calhoun, Editor, et al. Expires December 13, 2007 [Page 62]