idnits 2.17.1 draft-ietf-capwap-protocol-binding-ieee80211-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 3502. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3513. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3520. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3526. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 31, 2008) is 5649 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2597' is defined on line 3378, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2598 (Obsoleted by RFC 3246) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.802-11.2007' == Outdated reference: A later version (-15) exists of draft-ietf-capwap-protocol-specification-14 -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.802-1X.2004' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.802-1Q.2005' Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Calhoun, Editor 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track M. Montemurro, Editor 5 Expires: May 4, 2009 Research In Motion 6 D. Stanley, Editor 7 Aruba Networks 8 October 31, 2008 10 CAPWAP Protocol Binding for IEEE 802.11 11 draft-ietf-capwap-protocol-binding-ieee80211-12 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on May 4, 2009. 38 Abstract 40 Wireless LAN product architectures have evolved from single 41 autonomous access points to systems consisting of a centralized 42 Access Controller (AC) and Wireless Termination Points (WTPs). The 43 general goal of centralized control architectures is to move access 44 control, including user authentication and authorization, mobility 45 management and radio management from the single access point to a 46 centralized controller. 48 This specification defines the Control And Provisioning of Wireless 49 Access Points (CAPWAP) Protocol Binding Specification for use with 50 the IEEE 802.11 Wireless Local Area Network protocol. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 1.2. Conventions used in this document . . . . . . . . . . . . 6 57 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 58 2. IEEE 802.11 Binding . . . . . . . . . . . . . . . . . . . . . 8 59 2.1. CAPWAP Wireless Binding Identifier . . . . . . . . . . . 8 60 2.2. Split MAC and Local MAC Functionality . . . . . . . . . . 8 61 2.2.1. Split MAC . . . . . . . . . . . . . . . . . . . . . . 8 62 2.2.2. Local MAC . . . . . . . . . . . . . . . . . . . . . . 13 63 2.3. Roaming Behavior . . . . . . . . . . . . . . . . . . . . 16 64 2.4. Group Key Refresh . . . . . . . . . . . . . . . . . . . . 17 65 2.5. BSSID to WLAN ID Mapping . . . . . . . . . . . . . . . . 18 66 2.6. CAPWAP Data Channel QoS Behavior . . . . . . . . . . . . 19 67 2.6.1. IEEE 802.11 Data Frames . . . . . . . . . . . . . . . 19 68 2.6.2. IEEE 802.11 MAC Management Messages . . . . . . . . . 22 69 2.7. Run State Operation . . . . . . . . . . . . . . . . . . . 22 70 3. IEEE 802.11 Specific CAPWAP Control Messages . . . . . . . . . 23 71 3.1. IEEE 802.11 WLAN Configuration Request . . . . . . . . . 23 72 3.2. IEEE 802.11 WLAN Configuration Response . . . . . . . . . 24 73 4. CAPWAP Data Message Bindings . . . . . . . . . . . . . . . . . 25 74 5. CAPWAP Control Message bindings . . . . . . . . . . . . . . . 27 75 5.1. Discovery Request Message . . . . . . . . . . . . . . . . 27 76 5.2. Discovery Response Message . . . . . . . . . . . . . . . 27 77 5.3. Primary Discovery Request Message . . . . . . . . . . . . 27 78 5.4. Primary Discovery Response Message . . . . . . . . . . . 27 79 5.5. Join Request Message . . . . . . . . . . . . . . . . . . 27 80 5.6. Join Response Message . . . . . . . . . . . . . . . . . . 28 81 5.7. Configuration Status Request Message . . . . . . . . . . 28 82 5.8. Configuration Status Response Message . . . . . . . . . . 28 83 5.9. Configuration Update Request Message . . . . . . . . . . 29 84 5.10. Station Configuration Request . . . . . . . . . . . . . . 30 85 5.11. Change State Event Request . . . . . . . . . . . . . . . 30 86 5.12. WTP Event Request . . . . . . . . . . . . . . . . . . . . 30 87 6. IEEE 802.11 Message Element Definitions . . . . . . . . . . . 31 88 6.1. IEEE 802.11 Add WLAN . . . . . . . . . . . . . . . . . . 31 89 6.2. IEEE 802.11 Antenna . . . . . . . . . . . . . . . . . . . 37 90 6.3. IEEE 802.11 Assigned WTP BSSID . . . . . . . . . . . . . 38 91 6.4. IEEE 802.11 Delete WLAN . . . . . . . . . . . . . . . . . 39 92 6.5. IEEE 802.11 Direct Sequence Control . . . . . . . . . . . 39 93 6.6. IEEE 802.11 Information Element . . . . . . . . . . . . . 41 94 6.7. IEEE 802.11 MAC Operation . . . . . . . . . . . . . . . . 41 95 6.8. IEEE 802.11 MIC Countermeasures . . . . . . . . . . . . . 43 96 6.9. IEEE 802.11 Multi-Domain Capability . . . . . . . . . . . 44 97 6.10. IEEE 802.11 OFDM Control . . . . . . . . . . . . . . . . 45 98 6.11. IEEE 802.11 Rate Set . . . . . . . . . . . . . . . . . . 46 99 6.12. IEEE 802.11 RSNA Error Report From Station . . . . . . . 47 100 6.13. IEEE 802.11 Station . . . . . . . . . . . . . . . . . . . 49 101 6.14. IEEE 802.11 Station QoS Profile . . . . . . . . . . . . . 50 102 6.15. IEEE 802.11 Station Session Key . . . . . . . . . . . . . 51 103 6.16. IEEE 802.11 Statistics . . . . . . . . . . . . . . . . . 53 104 6.17. IEEE 802.11 Supported Rates . . . . . . . . . . . . . . . 57 105 6.18. IEEE 802.11 Tx Power . . . . . . . . . . . . . . . . . . 57 106 6.19. IEEE 802.11 Tx Power Level . . . . . . . . . . . . . . . 58 107 6.20. IEEE 802.11 Update Station QoS . . . . . . . . . . . . . 59 108 6.21. IEEE 802.11 Update WLAN . . . . . . . . . . . . . . . . . 60 109 6.22. IEEE 802.11 WTP Quality of Service . . . . . . . . . . . 64 110 6.23. IEEE 802.11 WTP Radio Configuration . . . . . . . . . . . 66 111 6.24. IEEE 802.11 WTP Radio Fail Alarm Indication . . . . . . . 68 112 6.25. IEEE 802.11 WTP Radio Information . . . . . . . . . . . . 69 113 7. IEEE 802.11 Binding WTP Saved Variables . . . . . . . . . . . 71 114 7.1. IEEE80211AntennaInfo . . . . . . . . . . . . . . . . . . 71 115 7.2. IEEE80211DSControl . . . . . . . . . . . . . . . . . . . 71 116 7.3. IEEE80211MACOperation . . . . . . . . . . . . . . . . . . 71 117 7.4. IEEE80211OFDMControl . . . . . . . . . . . . . . . . . . 71 118 7.5. IEEE80211Rateset . . . . . . . . . . . . . . . . . . . . 71 119 7.6. IEEE80211TxPower . . . . . . . . . . . . . . . . . . . . 71 120 7.7. IEEE80211QoS . . . . . . . . . . . . . . . . . . . . . . 71 121 7.8. IEEE80211RadioConfig . . . . . . . . . . . . . . . . . . 71 122 8. Technology Specific Message Element Values . . . . . . . . . . 72 123 8.1. WTP Descriptor Message Element, Encryption 124 Capabilities Field: . . . . . . . . . . . . . . . . . . . 72 125 9. Security Considerations . . . . . . . . . . . . . . . . . . . 73 126 9.1. IEEE 802.11 Security . . . . . . . . . . . . . . . . . . 73 127 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 75 128 10.1. CAPWAP Wireless Binding Identifier . . . . . . . . . . . 75 129 10.2. CAPWAP IEEE 802.11 Message Types . . . . . . . . . . . . 75 130 10.3. CAPWAP Message Element Type . . . . . . . . . . . . . . . 75 131 10.4. IEEE 802.11 Key Status . . . . . . . . . . . . . . . . . 75 132 10.5. IEEE 802.11 QoS . . . . . . . . . . . . . . . . . . . . . 76 133 10.6. IEEE 802.11 Auth Type . . . . . . . . . . . . . . . . . . 76 134 10.7. IEEE 802.11 Antenna Combiner . . . . . . . . . . . . . . 76 135 10.8. IEEE 802.11 Antenna Selection . . . . . . . . . . . . . . 76 136 10.9. IEEE 802.11 Session Key Flags . . . . . . . . . . . . . . 77 137 10.10. IEEE 802.11 Tagging Policy . . . . . . . . . . . . . . . 77 138 10.11. IEEE 802.11 WTP Radio Fail . . . . . . . . . . . . . . . 77 139 10.12. IEEE 802.11 WTP Radio Type . . . . . . . . . . . . . . . 77 140 10.13. WTP Encryption Capabilities . . . . . . . . . . . . . . . 78 141 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 79 142 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 80 143 12.1. Normative References . . . . . . . . . . . . . . . . . . 80 144 12.2. Informational References . . . . . . . . . . . . . . . . 81 145 Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 82 146 Intellectual Property and Copyright Statements . . . . . . . . . . 83 148 1. Introduction 150 The CAPWAP protocol [I-D.ietf-capwap-protocol-specification] defines 151 an extensible protocol to allow an Access Controller to manage 152 wireless agnostic Wireless Termination Points. The CAPWAP protocol 153 itself does not include any specific wireless technologies, but 154 instead relies on binding specification to extend the technology to a 155 particular wireless technology. 157 This specification defines the Control And Provisioning of Wireless 158 Access Points (CAPWAP) Protocol Binding Specification for use with 159 the IEEE 802.11 Wireless Local Area Network protocol. Use of CAPWAP 160 control message fields, new control messages and message elements are 161 defined. The minimum required definitions for a binding-specific 162 Statistics message element, Station message element, and WTP Radio 163 Information message element are included. 165 Note that this binding only supports the IEEE 802.11-2007 166 specification. Of note, this binding does not support the ad-hoc 167 network mode defined in the IEEE 802.11-2007 standard. This 168 specification also does not cover the use of data frames with the 169 four-address format, commonly referred to as Wireless Bridges, whose 170 use is not specified in the IEEE 802.11-2007 standard. New protocol 171 specifications published outside of this document (e.g., IEEE 172 802.11n, IEEE 802.11r) are therefore not supported through this 173 binding, and must be addressed either through a separate CAPWAP 174 binding, or an update to this binding. 176 In order to address immediate market needs for standards still being 177 developed by the IEEE 802.11 standards body, the WiFi Alliance 178 created interim pseudo-standards specifications. Two such 179 specifications are widely used in the industry, namely the WiFi 180 Protect Access [WPA] and the WiFi MultiMedia [WMM] specifications. 181 Given their widespread adoption, this CAPWAP binding requires the use 182 of these two specifications. 184 1.1. Goals 186 The goals of this CAPWAP protocol binding are to make the 187 capabilities of the CAPWAP protocol available for use in conjunction 188 with IEEE 802.11 wireless networks. The capabilities to be made 189 available can be summarized as: 191 1. To centralize the authentication and policy enforcement functions 192 for an IEEE 802.11 wireless network. The AC may also provide 193 centralized bridging, forwarding, and encryption of user traffic. 194 Centralization of these functions will enable reduced cost and 195 higher efficiency by applying the capabilities of network 196 processing silicon to the wireless network, as in wired LANs. 198 2. To enable shifting of the higher level protocol processing from 199 the WTP. This leaves the time-critical applications of wireless 200 control and access in the WTP, making efficient use of the 201 computing power available in WTPs which are subject to severe cost 202 pressure. 204 The CAPWAP protocol binding extensions defined herein apply solely to 205 the interface between the WTP and the AC. Inter-AC and station-to-AC 206 communication are strictly outside the scope of this document. 208 1.2. Conventions used in this document 210 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 211 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 212 document are to be interpreted as described in RFC 2119 [RFC2119]. 214 1.3. Terminology 216 This section contains definitions for terms used frequently 217 throughout this document. However, many additional definitions can 218 be found in [IEEE.802-11.2007]. 220 Access Controller (AC): The network entity that provides WTP access 221 to the network infrastructure in the data plane, control plane, 222 management plane, or a combination therein. 224 Basic Service Set (BSS): A set of stations controlled by a single 225 coordination function. 227 Distribution: The service that, by using association information, 228 delivers medium access control (MAC) service data units (MSDUs) 229 within the distribution system (DS). 231 Distribution System Service (DSS): The set of services provided by 232 the distribution system (DS) that enable the medium access control 233 (MAC) layer to transport MAC service data units (MSDUs) between 234 stations that are not in direct communication with each other over a 235 single instance of the wireless medium (WM). These services include 236 the transport of MSDUs between the access points (APs) of basic 237 service sets (BSSs) within an extended service set (ESS), transport 238 of MSDUs between portals and BSSs within an ESS, and transport of 239 MSDUs between stations in the same BSS in cases where the MSDU has a 240 multicast or broadcast destination address, or where the destination 241 is an individual address, but the station sending the MSDU chooses to 242 involve the DSS. DSSs are provided between pairs of IEEE 802.11 243 MACs. 245 Integration: The service that enables delivery of medium access 246 control (MAC) service data units (MSDUs) between the distribution 247 system (DS) and an existing, non-IEEE 802.11 local area network (via 248 a portal). 250 Station (STA): A device that contains an IEEE 802.11 conformant 251 medium access control (MAC) and physical layer (PHY) interface to the 252 wireless medium (WM). 254 Portal: The logical point at which medium access control (MAC) 255 service data units (MSDUs) from a non-IEEE 802.11 local area network 256 (LAN) enter the distribution system (DS) of an extended service set 257 (ESS). 259 WLAN: In this document, WLAN refers to a logical component 260 instantiated on a WTP device. A single physical WTP may operate a 261 number of WLANs. Each Basic Service Set Identifier (BSSID) and its 262 constituent wireless terminal radios is denoted as a distinct WLAN on 263 a physical WTP. 265 Wireless Termination Point (WTP): The physical or network entity that 266 contains an IEEE 802.11 RF antenna and wireless PHY to transmit and 267 receive station traffic for wireless access networks. 269 2. IEEE 802.11 Binding 271 This section describes use of the CAPWAP protocol with the IEEE 272 802.11 Wireless Local Area Network protocol, including Local and 273 Split MAC operation, Group Key Refresh, Basic Service Set 274 Identification (BSSID) to WLAN Mapping, IEEE 802.11 MAC management 275 frame Quality of Service tagging and Run State operation. 277 2.1. CAPWAP Wireless Binding Identifier 279 The CAPWAP Header, defined in section 4.3 of 280 [I-D.ietf-capwap-protocol-specification] requires that all CAPWAP 281 binding specifications have a Wireless Binding Identifier (WBID) 282 assigned. This document, which defines the IEEE 802.11 binding, uses 283 the the value one (1). 285 2.2. Split MAC and Local MAC Functionality 287 The CAPWAP protocol, when used with IEEE 802.11 devices, requires 288 specific behavior from the WTP and the AC to support the required 289 IEEE 802.11 protocol functions. 291 For both the Split and Local MAC approaches, the CAPWAP functions, as 292 defined in the taxonomy specification [RFC4118], reside in the AC. 294 To provide system component interoperability, the WTP and AC MUST 295 support 802.11 encryption/decryption at the WTP. The WTP and AC MAY 296 support 802.11 encryption/decryption at the AC. 298 2.2.1. Split MAC 300 This section shows the division of labor between the WTP and the AC 301 in a Split MAC architecture. Figure 1 shows the separation of 302 functionality between CAPWAP components. 304 Function Location 305 Distribution Service AC 306 Integration Service AC 307 Beacon Generation WTP 308 Probe Response Generation WTP 309 Power Mgmt/Packet Buffering WTP 310 Fragmentation/Defragmentation WTP/AC 311 Assoc/Disassoc/Reassoc AC 313 IEEE 802.11 QOS 314 Classifying AC 315 Scheduling WTP/AC 316 Queuing WTP 318 IEEE 802.11 RSN 319 IEEE 802.1X/EAP AC 320 RSNA Key Management AC 321 IEEE 802.11 Encryption/Decryption WTP/AC 323 Figure 1: Mapping of 802.11 Functions for Split MAC Architecture 325 In a Split MAC Architecture, the Distribution and Integration 326 services reside on the AC, and therefore all user data is tunneled 327 between the WTP and the AC. As noted above, all real-time IEEE 328 802.11 services, including the Beacon and Probe Response frames, are 329 handled on the WTP. 331 All remaining IEEE 802.11 MAC management frames are supported on the 332 AC, including the Association Request frame which allows the AC to be 333 involved in the access policy enforcement portion of the IEEE 802.11 334 protocol. The IEEE 802.1X [IEEE.802-1X.2004], Extensible 335 Authentication Protocol (EAP) [RFC3748] and IEEE Robust Security 336 Network Association (RSNA) Key Management [IEEE.802-11.2007] 337 functions are also located on the AC. This implies that the AAA 338 client also resides on the AC. 340 While the admission control component of IEEE 802.11 resides on the 341 AC, the real time scheduling and queuing functions are on the WTP. 342 Note that this does not prevent the AC from providing additional 343 policy and scheduling functionality. 345 Note that in the following figure, the use of '( - )' indicates that 346 processing of the frames is done on the WTP. This figure represents 347 a case where encryption services are provided by the AC. 349 Client WTP AC 351 Beacon 352 <----------------------------- 353 Probe Request 354 ----------------------------( - )-------------------------> 355 Probe Response 356 <----------------------------- 357 802.11 AUTH/Association 358 <---------------------------------------------------------> 359 Station Configuration Request 360 [Add Station (Station MAC 361 Address), IEEE 802.11 Add 362 Station (WLAN ID), IEEE 363 802.11 Session Key(Flag=A)] 364 <--------------------------> 365 802.1X Authentication & 802.11 Key Exchange 366 <---------------------------------------------------------> 367 Station Configuration Request 368 [Add Station(Station MAC 369 Address), IEEE 802.11 Add 370 Station (WLAN ID), IEEE 802.11 371 Station Session Key(Flag=C)] 372 <--------------------------> 373 802.11 Action Frames 374 <---------------------------------------------------------> 375 802.11 DATA (1) 376 <---------------------------( - )-------------------------> 378 Figure 2: Split MAC Message Flow 380 Figure 2 provides an illustration of the division of labor in a Split 381 MAC architecture. In this example, a WLAN has been created that is 382 configured for IEEE 802.11, using 802.1X based end user 383 authentication and AES-CCMP link layer encryption (Counter mode with 384 Cipher-block chaining Message authentication code Protocol, see 385 [FIPS.197.2001]). The following process occurs: 387 o The WTP generates the IEEE 802.11 Beacon frames, using information 388 provided to it through the IEEE 802.11 Add WLAN (see Section 6.1) 389 message element, including the RSNIE, which indicates support of 390 802.1X and AES-CCMP. 392 o The WTP processes the Probe Request frame and responds with a 393 corresponding Probe Response frame. The Probe Request frame is 394 then forwarded to the AC for optional processing. 396 o The WTP forwards the IEEEE 802.11 Authentication and Association 397 frames to the AC, which is responsible for responding to the 398 client. 400 o Once the association is complete, the AC transmits a Station 401 Configuration Request message, which includes an Add Station 402 message element, to the WTP (see Section 4.6.8 in 403 [I-D.ietf-capwap-protocol-specification]). In the above example, 404 the WLAN was configured for IEEE 802.1X, and therefore the IEEE 405 802.11 Station Session Key is included with the flag field's 'A' 406 bit set. 408 o If the WTP is providing encryption/decryption services, once the 409 client has completed the IEEE 802.11 key exchange, the AC 410 transmits another Station Configuration Request message, which 411 includes: 413 - An Add Station message element. 415 - An IEEE 802.11 Add Station message element, which includes the 416 WLAN Identifier the station has associated with. 418 - An IEEE 802.11 Station Session Key message element, which 419 includes the pairwise encryption key. 421 - An IEEE 802.11 Information Element message element which 422 includes the obust Security Network Information Element (RSNIE) 423 to the WTP, stating the security policy to enforce for the 424 client (in this case AES-CCMP). 426 o If the WTP is providing encryption/decryption services, once the 427 client has completed the IEEE 802.11 key exchange, the AC 428 transmits another Station Configuration Request message, which 429 includes: 431 - An Add Station message element. 433 - An IEEE 802.11 Add Station message element, which includes the 434 WLAN Identifier the station has associated with. 436 - An IEEE 802.11 Station Session Key message element, which 437 includes the pairwise encryption key. 439 - An IEEE 802.11 Information Element message element which 440 includes the Robust Security Network Information Element 441 (RSNIE) to the WTP, stating the security policy to enforce for 442 the client (in this case AES-CCMP). 444 o If the AC is providing encryption/decryption services, once the 445 client has completed the IEEE 802.11 key exchange, the AC 446 transmits another Station Configuration Request message, which 447 includes: 449 - An Add Station message element. 451 - An IEEE 802.11 Add Station message element, which includes the 452 WLAN Identifier the station has associated with. 454 - An IEEE 802.11 Station Session Key message element with the 455 flag fields' 'C' bit enabled (indicating that the AC will 456 provide crypto services). 458 o The WTP forwards any IEEE 802.11 Management Action frames received 459 to the AC. 461 o All IEEE 802.11 station data frames are tunneled between the WTP 462 and the AC. 464 Note that during the EAPOL-Key exchange between the Station and the 465 AC, the Receive Sequence Counter (RSC) field for the GTK needs to be 466 included in the frame. The value of zero (0) is used by the AC 467 during this exchange. Additional details are available in 468 Section 9.1. 470 The WTP SHALL include the IEEE 802.11 MAC header contents in all 471 frames transmitted to the AC. 473 When 802.11 encryption/decryption is performed at the WTP, the WTP 474 MUST decrypt the uplink frames, MUST set the Protected Frame field to 475 0, and MUST make the frame format consistent with that of an 476 unprotected 802.11 frame prior to transmitting the frames to the AC. 477 The fields added to an 802.11 protected frame (i.e., Initialization 478 Vector/Extended Initialization Vector (IV/EIV), Message Integrity 479 Code (MIC), and Integrity Check Value (ICV)) MUST be stripped off 480 prior to transmission from the WTP to AC. For downlink frames, the 481 Protected Frame field MUST be set to 0 by the AC as the frame being 482 sent is unencrypted. The WTP MUST apply the required protection 483 policy for the WLAN, and set the Protected Frame field on 484 transmission over the air. The Protected Frame field always needs to 485 accurately indicate the status of the 802.11 frame that is carrying 486 it. 488 When 802.11 encryption/decryption is performed at the AC, the WTP 489 SHALL NOT decrypt the uplink frames prior to transmitting the frames 490 to the AC. The AC and WTP SHALL populate the IEEE 802.11 MAC header 491 fields as described in Figure 3. 493 MAC header field Location 494 Frame Control: 495 Version AC 496 ToDS AC 497 FromDS AC 498 Type AC 499 SubType AC 500 MoreFrag WTP/AC 501 Retry WTP 502 Pwr Mgmt - 503 MoreData WTP 504 Protected WTP/AC 505 Order AC 506 Duration: WTP 507 Address 1: AC 508 Address 2: AC 509 Address 3: AC 510 Sequence Ctrl: WTP 511 Address 4: AC 512 QoS Control: AC 513 Frame Body: AC 514 FCS: WTP 516 Figure 3: Population of the IEEE 802.11 MAC header Fields for 517 Downlink Frames 519 When 802.11 encryption/decryption is performed at the AC, the 520 MoreFrag bit is populated at the AC. The Pwr Mgmt bit is not 521 applicable to downlink frames, and is set to 0. Note that the Frame 522 Check Sequence (FCS) field is not included in 802.11 frames exchanged 523 between the WTP and the AC. Upon sending data frames to the AC, the 524 WTP is responsible for validating, and stripping the FCS field. Upon 525 receiving data frames from the AC, the WTP is responsible for adding 526 the FCS field, and populating the field as described in 527 [IEEE.802-11.2007]. 529 Note that when the WTP tunnels data packets to the AC (and vice 530 versa), the CAPWAP protocol does not guarantee in-order delivery. 531 When the protocol being transported over IEEE 802.11 is IP, out of 532 order delivery is not an issue as IP has no such requirements. 533 However, implementors need to be aware of this protocol 534 characteristic before deciding to use CAPWAP. 536 2.2.2. Local MAC 538 This section shows the division of labor between the WTP and the AC 539 in a Local MAC architecture. Figure 4 shows the separation of 540 functionality among CAPWAP components. 542 Function Location 543 Distribution Service WTP/AC 544 Integration Service WTP 545 Beacon Generation WTP 546 Probe Response Generation WTP 547 Power Mgmt/Packet Buffering WTP 548 Fragmentation/Defragmentation WTP 549 Assoc/Disassoc/Reassoc WTP/AC 551 IEEE 802.11 QOS 552 Classifying WTP 553 Scheduling WTP 554 Queuing WTP 556 IEEE 802.11 RSN 557 IEEE 802.1X/EAP AC 558 RSNA Key Management AC 559 IEEE 802.11 Encryption/Decryption WTP 561 Figure 4: Mapping of 802.11 Functions for Local AP Architecture 563 In the Local MAC mode, the integration service exists on the WTP, 564 while the distribution service MAY reside on either the WTP or the 565 AC. When it resides on the AC, station generated frames are not 566 forwarded to the AC in their native format, but encapsulated as 802.3 567 frames. 569 While the MAC is terminated on the WTP, it is necessary for the AC to 570 be aware of mobility events within the WTPs. Thus the WTP MUST 571 forward the IEEE 802.11 Association Request frames to the AC. The AC 572 MAY reply with a failed Association Response frame if it deems it 573 necessary, and upon receipt of a failed Association Response frame 574 from the AC, the WTP MUST send a Disassociation frame to the station. 576 The IEEE 802.1X [IEEE.802-1X.2004], EAP and IEEE RSNA Key Management 577 [IEEE.802-11.2007] functions reside in the AC. Therefore, the WTP 578 MUST forward all IEEE 802.1X, EAP and RSNA Key Management frames to 579 the AC and forward the corresponding responses to the station. This 580 implies that the AAA client also resides on the AC. 582 Note that in the following figure, the use of '( - )' indicates that 583 processing of the frames is done on the WTP. 585 Client WTP AC 587 Beacon 588 <----------------------------- 589 Probe 590 <----------------------------> 591 802.11 AUTH 592 <----------------------------- 593 802.11 Association 594 <---------------------------( - )-------------------------> 595 Station Configuration Request 596 [Add Station (Station MAC 597 Address), IEEE 802.11 Add 598 Station (WLAN ID), IEEE 599 802.11 Session Key(Flag=A)] 600 <--------------------------> 601 802.1X Authentication & 802.11 Key Exchange 602 <---------------------------------------------------------> 603 Station Configuration Request 604 [Add Station(Station MAC 605 Address), IEEE 802.11 Add 606 Station (WLAN ID), IEEE 802.11 607 Station session Key (Key=x), 608 IEEE 802.11 Information 609 Element(RSNIE(Pairwise 610 Cipher=CCMP))] 611 <--------------------------> 612 802.11 Action Frames 613 <---------------------------------------------------------> 614 802.11 DATA 615 <-----------------------------> 617 Figure 5: Local MAC Message Flow 619 Figure 5 provides an illustration of the division of labor in a Local 620 MAC architecture. In this example, a WLAN that is configured for 621 IEEE 802.11 has been created using AES-CCMP for privacy. The 622 following process occurs: 624 o The WTP generates the IEEE 802.11 Beacon frames, using information 625 provided to it through the Add WLAN (see Section 6.1) message 626 element. 628 o The WTP processes a Probe Request frame and responds with a 629 corresponding Probe Response frame. 631 o The WTP forwards the IEEE 802.11 Authentication and Association 632 frames to the AC. 634 o Once the association is complete, the AC transmits a Station 635 Configuration Request message, which includes the Add Station 636 message element, to the WTP (see Section 4.6.8 in 637 [I-D.ietf-capwap-protocol-specification]). In the above example, 638 the WLAN was configured for IEEE 802.1X, and therefore the IEEE 639 802.11 Station Session Key is included with the flag field's 'A' 640 bit set. 642 o The WTP forwards all IEEE 802.1X and IEEE 802.11 key exchange 643 messages to the AC for processing. 645 o The AC transmits another Station Configuration Request message, 646 which includes: 648 - An Add Station message element, which MAY include a Virtual LAN 649 (VLAN) [IEEE.802-1Q.2005] name, which when present is used by 650 the WTP to identify the VLAN on which the user's data frames 651 are to be bridged. 653 - An IEEE 802.11 Add Station message element, which includes the 654 WLAN Identifier the station has associated with 656 - An IEEE 802.11 Station Session Key message element, which 657 includes the pairwise encryption key. 659 - An IEEE 802.11 Information Element message element which 660 includes the RSNIE to the WTP, stating the security policy to 661 enforce for the client (in this case AES-CCMP). 663 o The WTP forwards any IEEE 802.11 Management Action frames received 664 to the AC. 666 o The WTP MAY locally bridge client data frames (and provide the 667 necessary encryption and decryption services). The WTP MAY also 668 tunnel client data frames to the AC, using 802.3 frame tunnel mode 669 or 802.11 frame tunnel mode. 671 2.3. Roaming Behavior 673 This section expands upon the examples provided in the previous 674 section, and describes how the CAPWAP control protocol is used to 675 provide secure roaming. 677 Once a client has successfully associated with the network in a 678 secure fashion, it is likely to attempt to roam to another WTP. 680 Figure 6 shows an example of a currently associated station moving 681 from its "Old WTP" to a "New WTP". The figure is valid for multiple 682 different security policies, including IEEE 802.1X and Wireless 683 Protected Access (WPA) or Wireless Protected Access 2 (WPA2) [WPA]. 684 In the event that key caching was employed, the 802.1X Authentication 685 step would be eliminated. Note that the example represents one where 686 crypto services are provided by the WTP, so in a case where the AC 687 provided this function the last Station Configuration Request would 688 be different. 690 Client Old WTP New WTP AC 692 Association Request/Response 693 <--------------------------------------( - )--------------> 694 Station Configuration Request 695 [Add Station (Station MAC 696 Address), IEEE 802.11 Add 697 Station (WLAN ID), IEEE 698 802.11 Session Key(Flag=A)] 699 <----------------> 700 802.1X Authentication (if no key cache entry exists) 701 <--------------------------------------( - )--------------> 702 802.11 4-way Key Exchange 703 <--------------------------------------( - )--------------> 704 Station Configuration Request 705 [Delete Station] 706 <----------------------------------> 707 Station Configuration Request 708 [Add Station(Station MAC 709 Address), IEEE 802.11 Add 710 Station (WLAN ID), IEEE 802.11 711 Station session Key (Key=x), 712 IEEE 802.11 Information 713 Element(RSNIE(Pairwise 714 Cipher=CCMP))] 715 <----------------> 717 Figure 6: Client Roaming Example 719 2.4. Group Key Refresh 721 Periodically, the Group Key (GTK)for the BSS needs to be updated. 722 The AC uses an EAPOL-Key frame to update the group key for each STA 723 in the BSS. While the AC is updating the GTK, each L2 broadcast 724 frame transmitted to the BSS needs to be duplicated and transmitted 725 using both the current GTK and the new GTK. Once the GTK update 726 process has completed, broadcast frames transmitted to the BSS will 727 be encrypted using the new GTK. 729 In the case of Split MAC, the AC needs to duplicate all broadcast 730 packets and update the key index so that the packet is transmitted 731 using both the current and new GTK to ensure that all STA's in the 732 BSS receive the broadcast frames. In the case of local MAC, the WTP 733 needs to duplicate and transmit broadcast frames using the 734 appropriate index to ensure that all STA's in the BSS continue to 735 receive broadcast frames. 737 The Group Key update procedure is shown in the following figure. The 738 AC will signal the update to the GTK using an IEEE 802.11 739 Configuration Request message, including an IEEE 802.11 Update WLAN 740 message element with the new GTK, its index, the TSC for the Group 741 Key and the Key Status set to 3 (begin GTK update). The AC will then 742 begin updating the GTK for each STA. During this time, the AC (for 743 Split MAC) or WTP (for Local MAC) MUST duplicate broadcast packets 744 and transmit them encrypted with both the current and new GTK. When 745 the AC has completed the GTK update to all STA's in the BSS, the AC 746 MUST transmit an IEEE 802.11 Configuration Request message including 747 an IEEE 802.11 Update WLAN message element containing the new GTK, 748 its index, and the Key Status set to 4 (GTK update complete). 750 Client WTP AC 752 IEEE 802.11 WLAN Configuration Request [Update 753 WLAN (GTK, GTK Index, GTK Start, 754 Group TSC) ] 755 <-------------------------------------------- 756 802.1X EAPoL (GTK Message 1) 757 <-------------( - )------------------------------------------- 758 802.1X EAPoL (GTK Message 2) 759 -------------( - )-------------------------------------------> 760 IEEE 802.11 WLAN Configuration Request [ Update 761 WLAN (GTK Index, GTK Complete) ] 762 <-------------------------------------------- 764 Figure 7: Group Key Update Procedure 766 2.5. BSSID to WLAN ID Mapping 768 The CAPWAP protocol binding enables the WTP to assign BSSIDs upon 769 creation of a WLAN (see Section 6.1). While manufacturers are free 770 to assign BSSIDs using any arbitrary mechanism, it is advised that 771 where possible the BSSIDs are assigned as a contiguous block. 773 When assigned as a block, implementations can still assign any of the 774 available BSSIDs to any WLAN. One possible method is for the WTP to 775 assign the address using the following algorithm: base BSSID address 776 + WLAN ID. 778 The WTP communicates the maximum number of BSSIDs that it supports 779 during configuration via the IEEE 802.11 WTP WLAN Radio Configuration 780 message element (see Section 6.23). 782 2.6. CAPWAP Data Channel QoS Behavior 784 The CAPWAP IEEE 802.11 binding specification provides procedures to 785 allow for the WTP to enforce Quality of Service on IEEE 802.11 Data 786 Frames and MAC Management messages. 788 2.6.1. IEEE 802.11 Data Frames 790 When the WLAN is created on the WTP, a default Quality of Service 791 policy is established through the IEEE 802.11 WTP Quality of Service 792 message element (see Section 6.22). This default policy will cause 793 the WTP to use the default QoS values for any station associated with 794 the WLAN in question. The AC MAY also override the policy for a 795 given station, by sending the IEEE 802.11 Update Station QoS message 796 element (see Section 6.20), known as a station specific QoS policy. 798 Beyond the default, and per station QoS policy, the IEEE 802.11 799 protocol also allows a station to request special QoS treatment for a 800 specific flow through the TSPEC information elements found in the 801 IEEE 802.11-2007's QoS Action Frame. Alternatively, stations MAY 802 also use the WiFi Alliance's WMM specification instead to request QoS 803 treatment for a flow (see [WMM]). This requires the WTP to observe 804 the Status Code in the IEEE 802.11-2007 and WMM QoS Action ADDTS 805 responses from the AC, and provide the services requested in the 806 TSPEC information element. Similarly, the WTP MUST observe the 807 Reason Code information element in the IEEE 802.11-2007 and WMM QoS 808 Action DELTS responses from the AC by removing the policy associated 809 with the TSPEC. 811 The IEEE 802.11 WTP Quality of Service message element's Tagging 812 Policy field indicates how the packets are to be tagged, known as the 813 Tagging Policy. There are five bits defined, two of which are used 814 to indicate the type of QoS to be used by the WTP. The first is the 815 'P' bit which is set to inform the WTP it is to use the 802.1p QoS 816 mechanism. When set, the 'Q' bit is used to inform the WTP which 817 802.1p priority values it is to use. 819 The 'D' bit is set to inform the WTP it is to use the DSCP QoS 820 mechanism. When set, the 'I' and 'O' bits are used to inform the WTP 821 which values it is to use in the inner header, in the station's 822 original packet, or the outer header, the latter of which is only 823 valid when tunneling is enabled. 825 When an IEEE 802.11 Update Station QoS message element is received, 826 while the specific 802.1p priority or DSCP values may change for a 827 given station, known as the station specific policy, the original 828 Tagging Policy (the use of the five bits) remains the same. 830 The use of the DSCP and 802.1p QoS mechanisms are not mutually 831 exclusive. An AC MAY request that a WTP use none, one or both types 832 of QoS mechanisms at the same time. 834 2.6.1.1. 802.1p Support 836 The IEEE 802.11 WTP Quality of Service and IEEE 802.11 Update Station 837 QoS message elements include the "802.1p Tag" field, which is the 838 802.1p priority value. This value is used by the WTP by adding an 839 802.1Q header (see [IEEE.802-1Q.2005]) with the priority field set 840 according to the policy provided. Note this tagging is only valid 841 for interfaces that support 802.1p. The actual treatment does not 842 change for either Split or Local MAC modes, or when tunneling is 843 used. The only exception is when tunneling is used, the 802.1Q 844 header is added to the outer packet (tunneled) header. The IEEE 845 802.11 standard does not permit the station's packet to include an 846 802.1Q header. Instead, the QoS mechanisms defined in the IEEE 847 802.11 standard are used by stations to mark a packet's priority. 848 When the 'P' bit is set in the Tagging Policy, the 'Q' bit has the 849 following behavior: 851 Q=1: The WTP marks the priority field in the 802.1Q header to 852 either the default, or the station specific 802.1p policy. 854 Q=0: The WTP marks the priority field in the 802.1Q header to the 855 value found in User Priority field of the QoS Control field of the 856 IEEE 802.11 header. If the QoS Control field is not present in 857 the IEEE 802.11 header, then the behavior described under 'Q=1' is 858 used. 860 2.6.1.2. DSCP Support 862 The IEEE 802.11 WTP Quality of Service and IEEE 802.11 Update Station 863 QoS message elements also provide a "DSCP Tag", which is used by the 864 WTP when the 'D' bit is set to mark the DSCP field of both the IPv4 865 and IPv6 headers (see [RFC2474]). When DSCP is used, the WTP marks 866 the inner packet (the original packet received by the station) when 867 the 'I' bit is set. Similarly, the WTP marks the outer packet 868 (tunnel header's DSCP field) when the 'O' bit is set. 870 When the 'D' bit is set, the treatment of the packet differs based 871 whether the WTP is tunneling the station's packets to the AC. 872 Tunneling does not occur in a Local MAC mode when the AC has 873 communicated that tunneling is not required, as part of the IEEE 874 802.11 Add WLAN message element Section 6.1. In the case where 875 tunneling is not used, the 'I' and 'O' bits have the following 876 behavior: 878 O=1: This option is invalid when tunneling is not enabled for 879 station data frames. 881 O=0: This option is invalid when tunneling is not enabled for 882 station data frames. 884 I=1: The WTP sets the DSCP field in the station's packet to either 885 the default policy, or the station specific policy if one exists. 887 I=0: The WTP MUST NOT modify the DSCP field in the station's 888 packet. 890 For Split MAC mode, or Local MAC with tunneling enabled, the WTP 891 needs to contend with both the inner packet (the station's original 892 packet), as well as the tunnel header (added by the WTP). In this 893 mode of operation, the bits are treated as follows: 895 O=1: The WTP sets the DSCP field in the tunnel header to either the 896 default policy, or the station specific policy if one exists. 898 O=0: The WTP sets the DSCP field in the tunnel header to the value 899 found in the inner packet's DSCP field. If encryption services 900 are provided by the AC (see Section 6.15), the packet is 901 encrypted, therefore the WTP cannot access the inner DSCP field, 902 in which case it uses the behavior described when the 'O' bit is 903 set. This occurs also if the inner packet is not IPv4 or IPv6, 904 and thus does not have a DSCP field. 906 I=1: The WTP sets the DSCP field in the station's packet to either 907 the default policy, or the station specific policy if one exists. 908 If encryption services are provided by the AC (see Section 6.15), 909 the packet is encrypted, therefore the WTP cannot access the inner 910 DSCP field, in which case it uses the behavior described when the 911 'I' bit is not set. This occurs also if the inner packet is not 912 IPv4 or IPv6, and thus does not have a DSCP field. 914 I=0: The WTP MUST NOT modify the DSCP field in the station's 915 packet. 917 The CAPWAP protocol supports the Explicit Congestion Notification 918 (ECN) bits [RFC3168]. Additional details on ECN support can be found 919 [I-D.ietf-capwap-protocol-specification]. 921 2.6.2. IEEE 802.11 MAC Management Messages 923 It is recommended that IEEE 802.11 MAC Management frames be sent by 924 both the AC and the WTP with appropriate Quality of Service values, 925 listed below, to ensure that congestion in the network minimizes 926 occurrences of packet loss. Note that the QoS Mechanism specified in 927 Tagging Policy is used as specified by the AC in the IEEE 802.11 WTP 928 Quality of Service message element (see Section 6.22). However, the 929 station specific policy is not used for IEEE 802.11 MAC Management 930 frames. 932 802.1p: The precedence value of 7 (decimal) SHOULD be used for all 933 IEEE 802.11 MAC management frames, except for Probe Requests which 934 SHOULD use 4. 936 DSCP: All IEEE 802.11 MAC management frames SHOULD use the CS6 per- 937 hop behavior (see [RFC2474]), while IEEE 802.11 Probe Requests 938 should use the Low Drop Assured Forwarding per-hop behavior (see 939 [RFC2598]). 941 2.7. Run State Operation 943 The Run state is the normal state of operation for the CAPWAP 944 protocol in both the WTP and the AC. 946 When the WTP receives a WLAN Configuration Request message (see 947 Section 3.1), it MUST respond with a WLAN Configuration Response 948 message (see Section 3.2) and it remains in the Run state. 950 When the AC sends a WLAN Configuration Request message (see 951 Section 3.1) or receives the corresponding WLAN Configuration 952 Response message (see Section 3.2) from the WTP, it remains in the 953 Run state. 955 3. IEEE 802.11 Specific CAPWAP Control Messages 957 This section defines CAPWAP Control Messages that are specific to the 958 IEEE 802.11 binding. Two messages are defined, IEEE 802.11 WLAN 959 Configuration Request and IEEE 802.11 WLAN Configuration Response. 960 See Section 4.5 in [I-D.ietf-capwap-protocol-specification] for 961 CAPWAP Control message definitions and the derivation of the Message 962 Type value from the IANA Enterprise number. 964 The valid message types for IEEE 802.11 specific control messages are 965 listed below. The IANA Enterprise number used with these messages is 966 13277. 968 CAPWAP Control Message Message Type 969 Value 971 IEEE 802.11 WLAN Configuration Request 3398913 972 IEEE 802.11 WLAN Configuration Response 3398914 974 3.1. IEEE 802.11 WLAN Configuration Request 976 The IEEE 802.11 WLAN Configuration Request is sent by the AC to the 977 WTP in order to change services provided by the WTP. This control 978 message is used to either create, update or delete a WLAN on the WTP. 980 The IEEE 802.11 WLAN Configuration Request is sent as a result of 981 either some manual administrative process (e.g., deleting a WLAN), or 982 automatically to create a WLAN on a WTP. When sent automatically to 983 create a WLAN, this control message is sent after the CAPWAP 984 Configuration Update Response message (see Section 8.5 in 985 [I-D.ietf-capwap-protocol-specification]) has been received by the 986 AC. 988 Upon receiving this control message, the WTP will modify the 989 necessary services, and transmit an IEEE 802.11 WLAN Configuration 990 Response. 992 A WTP MAY provide service for more than one WLAN, therefore every 993 WLAN is identified through a numerical index. For instance, a WTP 994 that is capable of supporting up to 16 Service Set Identifiers 995 (SSIDs), could accept up to 16 IEEE 802.11 WLAN Configuration Request 996 messages that include the Add WLAN message element. 998 Since the index is the primary identifier for a WLAN, an AC MAY 999 attempt to ensure that the same WLAN is identified through the same 1000 index number on all of its WTPs. An AC that does not follow this 1001 approach MUST find some other means of maintaining a WLAN-Identifier- 1002 to-SSID mapping table. 1004 The following message elements MAY be included in the IEEE 802.11 1005 WLAN Configuration Request message. Only one message element MUST be 1006 present. 1008 o IEEE 802.11 Add WLAN, see Section 6.1 1010 o IEEE 802.11 Delete WLAN, see Section 6.4 1012 o IEEE 802.11 Update WLAN, see Section 6.21 1014 The following message element MAY be present. 1016 o IEEE 802.11 Information Element, see Section 6.6 1018 o Vendor Specific Payload, see 1019 [I-D.ietf-capwap-protocol-specification] 1021 3.2. IEEE 802.11 WLAN Configuration Response 1023 The IEEE 802.11 WLAN Configuration Response message is sent by the 1024 WTP to the AC. It is used to acknowledge receipt of an IEEE 802.11 1025 WLAN Configuration Request message, and to indicate that the 1026 requested configuration was successfully applied, or that an error 1027 related to the processing of the IEEE 802.11 WLAN Configuration 1028 Request message occurred on the WTP. 1030 The following message element MUST be included in the IEEE 802.11 1031 WLAN Configuration Response message. 1033 o Result Code, see Section 4.6.34 in 1034 [I-D.ietf-capwap-protocol-specification] 1036 The following message element MAY be included in the IEEE 802.11 WLAN 1037 Configuration Response message. 1039 o IEEE 802.11 Assigned WTP BSSID, see Section 6.3 1041 o Vendor Specific Payload, see 1042 [I-D.ietf-capwap-protocol-specification] 1044 4. CAPWAP Data Message Bindings 1046 This section describes the CAPWAP Data Message bindings to support 1047 transport of IEEE 802.11 frames. 1049 Payload encapsulation: The CAPWAP protocol defines the CAPWAP data 1050 message, which is used to encapsulate a wireless payload. For 1051 IEEE 802.11, the IEEE 802.11 header and payload are encapsulated 1052 (excluding the IEEE 802.11 FCS checksum). The IEEE 802.11 FCS 1053 checksum is handled by the WTP. This allows the WTP to validate 1054 an IEEE 802.11 frame prior to sending it to the AC. Similarly, 1055 when an AC wishes to transmit a frame to a station, the WTP 1056 computes and adds the FCS checksum. 1058 Optional Wireless Specific Information: This optional CAPWAP header 1059 field (see Section 4.3 in 1060 [I-D.ietf-capwap-protocol-specification]) is only used with CAPWAP 1061 data messages, and it serves two purposes, depending upon the 1062 direction of the message. For messages from the WTP to the AC, 1063 the field uses the format described in the "IEEE 802.11 Frame 1064 Info" field (see below). However, for messages sent by the AC to 1065 the WTP, the format used is described in the "Destination WLANs" 1066 field (also defined below). 1068 Note that in both cases, the two optional headers fit in the 1069 "Data" field of the Wireless Specific Information header. 1071 IEEE 802.11 Frame Info: When an IEEE 802.11 frame is received from a 1072 station over the air, it is encapsulated and this field is used to 1073 include radio and PHY specific information associated with the 1074 frame. 1076 The IEEE 802.11 Frame Info field has the following format: 1078 0 1 2 3 1079 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 1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 | RSSI | SNR | Data Rate | 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1084 RSSI: RSSI is a signed, 8-bit value. It is the received signal 1085 strength indication, in dBm. 1087 SNR: SNR is a signed, 8-bit value. It is the signal to noise 1088 ratio of the received IEEE 802.11 frame, in dB. 1090 Data Rate: The data rate field is a 16 bit unsigned value. The 1091 data rate field is a 16 bit unsigned value expressing the data 1092 rate of the packets received by the WTP in units of 0.1 Mbps. 1093 For instance, a packet received at 5.5Mbps would be set to 55, 1094 while 11Mbps would be set to 110. 1096 Destination WLANs The Destination WLANs field is used to specify the 1097 target WLANs for a given frame, and is only used with broadcast 1098 and multicast frames. This field allows the AC to transmit a 1099 single broadcast or multicast frame to the WTP, and allows the WTP 1100 to perform the necessary frame replication. The field uses the 1101 following format: 1103 0 1 2 3 1104 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 1105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1106 | WLAN ID bitmap | Reserved | 1107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1109 WLAN ID bitmap: This bit field indicates the WLAN ID (see 1110 Section 6.1) on which the WTP will transmit the included frame. 1111 For instance, if a multicast packet is to be transmitted on 1112 WLANs 1 and 3, the bits for WLAN 1 and 3 of this field would be 1113 enabled. WLAN 1 is represented by bit 15 in the figure above, 1114 or the least significant bit, while WLAN 16 would be 1115 represented by bit zero (0), or the most significant bit, in 1116 the figure. This field is to be set to all zeroes for unicast 1117 packets and is unused if the WTP is not providing IEEE 802.11 1118 encryption. 1120 Reserved: All implementations complying with this protocol MUST 1121 set to zero any bits that are reserved in the version of the 1122 protocol supported by that implementation. Receivers MUST 1123 ignore all bits not defined for the version of the protocol 1124 they support. 1126 5. CAPWAP Control Message bindings 1128 This section describes the IEEE 802.11 specific message elements 1129 included in CAPWAP Control Messages. 1131 5.1. Discovery Request Message 1133 The following IEEE 802.11 specific message element MUST be included 1134 in the CAPWAP Discovery Request Message. 1136 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 1137 802.11 WTP Radio Information message element MUST be present for 1138 every radio in the WTP. 1140 5.2. Discovery Response Message 1142 The following IEEE 802.11 specific message element MUST be included 1143 in the CAPWAP Discovery Response Message. 1145 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 1146 802.11 WTP Radio Information message element MUST be present for 1147 every radio in the WTP. 1149 5.3. Primary Discovery Request Message 1151 The following IEEE 802.11 specific message element MUST be included 1152 in the CAPWAP Primary Discovery Request Message. 1154 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 1155 802.11 WTP Radio Information message element MUST be present for 1156 every radio in the WTP. 1158 5.4. Primary Discovery Response Message 1160 The following IEEE 802.11 specific message element MUST be included 1161 in the CAPWAP Primary Discovery Response Message. 1163 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 1164 802.11 WTP Radio Information message element MUST be present for 1165 every radio in the WTP. 1167 5.5. Join Request Message 1169 The following IEEE 802.11 specific message element MUST be included 1170 in the CAPWAP Join Request Message. 1172 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 1173 802.11 WTP Radio Information message element MUST be present for 1174 every radio in the WTP. 1176 5.6. Join Response Message 1178 The following IEEE 802.11 specific message element MUST be included 1179 in the CAPWAP Join Response Message. 1181 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 1182 802.11 WTP Radio Information message element MUST be present for 1183 every radio in the WTP. 1185 5.7. Configuration Status Request Message 1187 The following IEEE 802.11 specific message elements MAY be included 1188 in the CAPWAP Configuration Status Request Message. More than one of 1189 each message element listed MAY be included. 1191 o IEEE 802.11 Antenna, see Section 6.2 1193 o IEEE 802.11 Direct Sequence Control, see Section 6.5 1195 o IEEE 802.11 MAC Operation, see Section 6.7 1197 o IEEE 802.11 Multi Domain Capability, see Section 6.9 1199 o IEEE 802.11 OFDM Control, see Section 6.10 1201 o IEEE 802.11 Supported Rates, see Section 6.17 1203 o IEEE 802.11 Tx Power, see Section 6.18 1205 o IEEE 802.11 TX Power Level, see Section 6.19 1207 o IEEE 802.11 WTP Radio Configuration, see Section 6.23 1209 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 1210 802.11 WTP Radio Information message element MUST be present for 1211 every radio in the WTP. 1213 5.8. Configuration Status Response Message 1215 The following IEEE 802.11 specific message elements MAY be included 1216 in the CAPWAP Configuration Status Response Message. More than one 1217 of each message element listed MAY be included. 1219 o IEEE 802.11 Antenna, see Section 6.2 1220 o IEEE 802.11 Direct Sequence Control, see Section 6.5 1222 o IEEE 802.11 MAC Operation, see Section 6.7 1224 o IEEE 802.11 Multi Domain Capability, see Section 6.9 1226 o IEEE 802.11 OFDM Control, see Section 6.10 1228 o IEEE 802.11 Rate Set, see Section 6.11 1230 o IEEE 802.11 Supported Rates, see Section 6.17 1232 o IEEE 802.11 Tx Power, see Section 6.18 1234 o IEEE 802.11 WTP Quality of Service, see Section 6.22 1236 o IEEE 802.11 WTP Radio Configuration, see Section 6.23 1238 5.9. Configuration Update Request Message 1240 The following IEEE 802.11 specific message elements MAY be included 1241 in the CAPWAP Configuration Update Request Message. More than one of 1242 each message element listed MAY be included. 1244 o IEEE 802.11 Antenna, see Section 6.2 1246 o IEEE 802.11 Direct Sequence Control, see Section 6.5 1248 o IEEE 802.11 MAC Operation, see Section 6.7 1250 o IEEE 802.11 Multi Domain Capability, see Section 6.9 1252 o IEEE 802.11 OFDM Control, see Section 6.10 1254 o IEEE 802.11 Rate Set, see Section 6.11 1256 o IEEE 802.11 RSNA Error Report From Station, see Section 6.12 1258 o IEEE 802.11 Tx Power, see Section 6.18 1260 o IEEE 802.11 WTP Quality of Service, see Section 6.22 1262 o IEEE 802.11 WTP Radio Configuration, see Section 6.23 1264 5.10. Station Configuration Request 1266 The following IEEE 802.11 specific message elements MAY included in 1267 the CAPWAP Station Configuration Request message. More than one of 1268 each message element listed MAY be included. 1270 o IEEE 802.11 Station, see Section 6.13 1272 o IEEE 802.11 Station Session Key, see Section 6.15 1274 o IEEE 802.11 Station QoS Profile, see Section 6.14 1276 o IEEE 802.11 Update Station Qos, see Section 6.20 1278 5.11. Change State Event Request 1280 The following IEEE 802.11 specific message elements MAY included in 1281 the CAPWAP Station Configuration Request message. 1283 o IEEE 802.11 WTP Radio Fail Alarm Indication, see Section 6.24 1285 5.12. WTP Event Request 1287 The following IEEE 802.11 specific message elements MAY be included 1288 in the CAPWAP WTP Event Request message. More than one of each 1289 message element listed MAY be included. 1291 o IEEE 802.11 MIC Countermeasures, see Section 6.8 1293 o IEEE 802.11 RSNA Error Report From Station, see Section 6.12 1295 o IEEE 802.11 Statistics, see Section 6.16 1297 6. IEEE 802.11 Message Element Definitions 1299 The following IEEE 802.11 specific message elements are defined in 1300 this section. 1302 IEEE 802.11 Message Element Type Value 1304 IEEE 802.11 Add WLAN 1024 1305 IEEE 802.11 Antenna 1025 1306 IEEE 802.11 Assigned WTP BSSID 1026 1307 IEEE 802.11 Delete WLAN 1027 1308 IEEE 802.11 Direct Sequence Control 1028 1309 IEEE 802.11 Information Element 1029 1310 IEEE 802.11 MAC Operation 1030 1311 IEEE 802.11 MIC Countermeasures 1031 1312 IEEE 802.11 Multi-Domain Capability 1032 1313 IEEE 802.11 OFDM Control 1033 1314 IEEE 802.11 Rate Set 1034 1315 IEEE 802.11 RSNA Error Report From Station 1035 1316 IEEE 802.11 Station 1036 1317 IEEE 802.11 Station QoS Profile 1037 1318 IEEE 802.11 Station Session Key 1038 1319 IEEE 802.11 Statistics 1039 1320 IEEE 802.11 Supported Rates 1040 1321 IEEE 802.11 Tx Power 1041 1322 IEEE 802.11 Tx Power Level 1042 1323 IEEE 802.11 Update Station QoS 1043 1324 IEEE 802.11 Update WLAN 1044 1325 IEEE 802.11 WTP Quality of Service 1045 1326 IEEE 802.11 WTP Radio Configuration 1046 1327 IEEE 802.11 WTP Radio Fail Alarm Indication 1047 1328 IEEE 802.11 WTP Radio Information 1048 1330 Figure 8: IEEE 802.11 Binding Message Elements 1332 6.1. IEEE 802.11 Add WLAN 1334 The IEEE 802.11 Add WLAN message element is used by the AC to define 1335 a WLAN on the WTP. The inclusion of this message element MUST also 1336 include IEEE 802.11 Information Element message elements, containing 1337 the following IEEE 802.11 IEs: 1339 Power Constraint information element 1340 EDCA Parameter Set information element 1342 QoS Capability information element 1344 WPA information element [WPA] 1346 RSN information element 1348 WMM information element [WMM] 1350 These IEEE 802.11 information elements are stored by the WTP and 1351 included in any Probe Responses and Beacons generated, as specified 1352 in the IEEE 802.11 standard [IEEE.802-11.2007]. If present, the RSN 1353 information element is sent with the IEEE 802.11 Add WLAN message 1354 element to instruct the WTP on the usage of the Key field. 1356 If cryptographic services are provided at the WTP, the WTP MUST 1357 observe the algorithm dictated in the Group Cipher Suite field of the 1358 RSN information element sent by the AC. The RSN Information Element 1359 is used to communicate any supported algorithm, including WEP, TKIP 1360 and AES-CCMP. In the case of static WEP keys, the RSN Information 1361 Element is still used to indicate the cryptographic algorithm even 1362 though no key exchange occurred. 1364 An AC MAY include additional information elements as desired. The 1365 message element uses the following format: 1367 0 1 2 3 1368 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 1369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1370 | Radio ID | WLAN ID | Capability | 1371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1372 | Key Index | Key Status | Key Length | 1373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1374 | Key... | 1375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1376 | Group TSC | 1377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1378 | Group TSC | QoS | Auth Type | 1379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1380 | MAC Mode | Tunnel Mode | Suppress SSID | SSID ... 1381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1383 Type: 1024 for IEEE 802.11 Add WLAN 1384 Length: >= 20 1386 Radio ID: An 8-bit value representing the radio, whose value is 1387 between one (1) and 31. 1389 WLAN ID: An 8-bit value specifying the WLAN Identifier. The value 1390 MUST be between one (1) and 16. 1392 Capability: A 16-bit value containing the capability information 1393 field to be advertised by the WTP in the Probe Request and Beacon 1394 frames. Each bit of the Capability field represents a different 1395 WTP capability, which are described in detail in 1396 [IEEE.802-11.2007]. The format of the field is: 1398 0 1 1399 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1401 |E|I|C|F|P|S|B|A|M|Q|T|D|V|O|K|L| 1402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1404 E (ESS): The AC MUST set the Extended Service Set (ESS) subfield 1405 to 1. 1407 I (IBSS): The AC MUST set the Independent Basic Service Set 1408 (IBSS) subfield to 0. 1410 C (CF-Pollable): The AC sets the Contention Free Pollable (CF- 1411 Pollable) subfield based on the table found in 1412 [IEEE.802-11.2007]. 1414 F (CF-Poll Request): The AC sets the CF-Poll Request subfield 1415 based on the table found in [IEEE.802-11.2007]. 1417 P (Privacy): The AC sets the Privacy subfield based on the 1418 confidentiality requirements of the WLAN, as defined in 1419 [IEEE.802-11.2007]. 1421 S (Short Preamble): The AC sets the Short Preamble subfield 1422 based on whether the use of short preambles are permitted on 1423 the WLAN, as defined in [IEEE.802-11.2007]. 1425 B (PBCC): The AC sets the Packet Binary Convolutional Code 1426 (PBCC) modulation option subfield based on whether the use of 1427 PBCC is permitted on the WLAN, as defined in 1428 [IEEE.802-11.2007]. 1430 A (Channel Agility): The AC sets the Channel Agility subfield 1431 based on whether the WTP is capable of supporting the High Rate 1432 Direct Sequence Spread Spectrum (HR/DSSS), as defined in 1433 [IEEE.802-11.2007]. 1435 M (Spectrum Management): The AC sets the Spectrum Management 1436 subfield according to the value of the 1437 dot11SpectrumManagementRequired MIB variable, as defined in 1438 [IEEE.802-11.2007]. 1440 Q (QOS): The AC sets the Quality of Service (QOS) subfield based 1441 on the table found in [IEEE.802-11.2007]. 1443 T (Short Slot Time): The AC sets the Short Slot Timesubfield 1444 according to the value of the WTP's currently used slot time 1445 value, as defined in [IEEE.802-11.2007]. 1447 D (APSD): The AC sets the APSD subfield according to the value 1448 of the dot11APSDOptionImplemented Management Information Base 1449 (MIB) variable, as defined in [IEEE.802-11.2007]. 1451 V (Reserved): The AC sets the Reserved subfield to zero, as 1452 defined in [IEEE.802-11.2007]. 1454 O (DSSS-OFDM): The AC sets the DSSS-OFDM subfield to indicate 1455 the use of Direct Sequence Spread Spectrum with Orthogonal 1456 Frequency Division Multiplexing (DSSS-OFDM), as defined in 1457 [IEEE.802-11.2007]. 1459 K (Delayed Block ACK): The AC sets the Delayed Block ACK 1460 subfield according to the value of the 1461 dot11DelayedBlockAckOptionImplemented MIB variable, as defined 1462 in [IEEE.802-11.2007]. 1464 L (Immediate Block ACK): The AC sets the Delayed Block ACK 1465 subfield according to the value of the 1466 dot11ImmediateBlockAckOptionImplemented MIB variable, as 1467 defined in [IEEE.802-11.2007]. 1469 Key-Index: The Key Index associated with the key. 1471 Key Status: A 1 byte value that specifies the state and usage of 1472 the key that has been included. Note this field is ignored if the 1473 Key Length field is set to zero (0). The following values 1474 describe the key usage and its status: 1476 0 - A value of zero, with the inclusion of the RSN Information 1477 Element means that the WLAN uses per-station encryption keys, 1478 and therefore the key in the 'Key' field is only used for 1479 multicast traffic. 1481 1 - When set to one, the WLAN employs a shared Wired Equivalent 1482 Privacy (WEP) key, also known as a static WEP key, and uses the 1483 encryption key for both unicast and multicast traffic for all 1484 stations. 1486 2 - The value of 2 indicates that the AC will begin rekeying the 1487 GTK with the STA's in the BSS. It is only valid when IEEE 1488 802.11 is enabled as the security policy for the BSS. 1490 3 - The value of 3 indicates that the AC has completed rekeying 1491 the GTK and broadcast packets no longer need to be duplicated 1492 and transmitted with both GTK's. 1494 Key Length: A 16-bit value representing the length of the Key 1495 field. 1497 Key: A Session Key, whose length is known via the key length field, 1498 used to provide data privacy. For encryption schemes that employ 1499 a separate encryption key for unicast and multicast traffic, the 1500 key included here only applies to multicast frames, and the cipher 1501 suite is specified in an accompanied RSN Information Element. In 1502 these scenarios, the key and cipher information is communicated 1503 via the Add Station message element, see Section 4.6.8 in 1504 [I-D.ietf-capwap-protocol-specification] and the IEEE 802.11 1505 Station Session Key message element, see Section 6.15. When used 1506 with WEP, the key field includes the broadcast key. When used 1507 with CCMP, the Key field includes the 128-bit Group Temporal Key. 1508 When used with TKIP, the Key field includes the 256-bit Group 1509 Temporal Key (which consists of a 128-bit key used as input for 1510 TKIP key mixing, and two 64-bit keys used for Michael). 1512 Group TSC A 48-bit value containing the Transmit Sequence Counter 1513 for the updated group key. The WTP will set the TSC for 1514 broadcast/multicast frames to this value for the updated group 1515 key. 1517 QOS: An 8-bit value specifying the default QOS policy for the WTP 1518 to apply to network traffic received for a non-WMM enabled STA. 1520 The following enumerated values are supported: 1522 0 - Best Effort 1524 1 - Video 1526 2 - Voice 1528 3 - Background 1530 Auth Type: An 8-bit value specifying the supported authentication 1531 type. 1533 The following enumerated values are supported: 1535 0 - Open System 1537 1 - WEP Shared Key 1539 MAC Mode: This field specifies whether the WTP should support the 1540 WLAN in Local or Split MAC modes. Note that the AC MUST NOT 1541 request a mode of operation that was not advertised by the WTP 1542 during the discovery process (see Section 4.6.43 in 1543 [I-D.ietf-capwap-protocol-specification]). The following 1544 enumerated values are supported: 1546 0 - Local-MAC: Service for the WLAN is to be provided in Local 1547 MAC mode. 1549 1 - Split-MAC: Service for the WLAN is to be provided in Split 1550 MAC mode. 1552 Tunnel Mode: This field specifies the frame tunneling type to be 1553 used for 802.11 data frames from all stations associated with the 1554 WLAN. The AC MUST NOT request a mode of operation that was not 1555 advertised by the WTP during the discovery process (see Section 1556 4.6.42 in [I-D.ietf-capwap-protocol-specification]). All IEEE 1557 802.11 management frames MUST be tunneled using 802.11 Tunnel 1558 mode. The following enumerated values are supported: 1560 0 - Local Bridging: All user traffic is to be locally bridged. 1562 1 - 802.3 Tunnel: All user traffic is to be tunneled to the AC 1563 in 802.3 format (see Section 4.4.2 in 1564 [I-D.ietf-capwap-protocol-specification]). Note that this 1565 option MUST NOT be selected with Split-MAC mode. 1567 2 - 802.11 Tunnel: All user traffic is to be tunneled to the AC 1568 in 802.11 format. 1570 Supress SSID: A boolean indicating whether the SSID is to be 1571 advertised by the WTP. A value of zero suppresses the SSID in the 1572 802.11 Beacon and Probe Response frames, while a value of one will 1573 cause the WTP to populate the field. 1575 SSID: The SSID attribute is the service set identifier that will be 1576 advertised by the WTP for this WLAN. The SSID field contains any 1577 ASCII character and MUST NOT exceed 32 octets in length, as 1578 defined in [IEEE.802-11.2007]. 1580 6.2. IEEE 802.11 Antenna 1582 The IEEE 802.11 Antenna message element is communicated by the WTP to 1583 the AC to provide information on the antennas available. The AC MAY 1584 use this element to reconfigure the WTP's antennas. The message 1585 element contains the following fields: 1587 0 1 2 3 1588 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 1589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1590 | Radio ID | Diversity | Combiner | Antenna Cnt | 1591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1592 | Antenna Selection... 1593 +-+-+-+-+-+-+-+-+ 1595 Type: 1025 for IEEE 802.11 Antenna 1597 Length: >= 5 1599 Radio ID: An 8-bit value representing the radio to configure, whose 1600 value is between one (1) and 31. 1602 Diversity: An 8-bit value specifying whether the antenna is to 1603 provide receive diversity. The value of this field is the same as 1604 the IEEE 802.11 dot11DiversitySelectionRx MIB element, see 1605 [IEEE.802-11.2007]. The following enumerated values are 1606 supported: 1608 0 - Disabled 1610 1 - Enabled (may only be true if the antenna can be used as a 1611 receive antenna) 1613 Combiner: An 8-bit value specifying the combiner selection. The 1614 following enumerated values are supported: 1616 1 - Sectorized (Left) 1618 2 - Sectorized (Right) 1620 3 - Omni 1622 4 - Multiple Input/Multiple Output (MIMO) 1624 Antenna Count: An 8-bit value specifying the number of Antenna 1625 Selection fields. This value SHOULD be the same as the one found 1626 in the IEEE 802.11 dot11CurrentTxAntenna MIB element (see 1627 [IEEE.802-11.2007]). 1629 Antenna Selection: One 8-bit antenna configuration value per 1630 antenna in the WTP, containing up to 255 antennas. The following 1631 enumerated values are supported: 1633 1 - Internal Antenna 1635 2 - External Antenna 1637 6.3. IEEE 802.11 Assigned WTP BSSID 1639 The IEEE 802.11 Assigned WTP BSSID is only included by the WTP when 1640 the IEEE 802.11 WLAN Configuration Request included the IEEE 802.11 1641 Add WLAN message element. The BSSID value field of this message 1642 element contains the BSSID that has been assigned by the WTP, 1643 enabling the WTP to perform its own BSSID assignment. 1645 The WTP is free to assign the BSSIDs the way it sees fit, but it is 1646 highly recommended that the WTP assign the BSSID using the following 1647 algorithm: BSSID = {base BSSID} + WLAN ID. 1649 0 1 2 3 1650 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 1651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1652 | Radio ID | WLAN ID | BSSID 1653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1654 | BSSID | 1655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1657 Type: 1026 for IEEE 802.11 Assigned WTP BSSID 1659 Length: 8 1661 Radio ID: An 8-bit value representing the radio, whose value is 1662 between one (1) and 31. 1664 WLAN ID: An 8-bit value specifying the WLAN Identifier. The value 1665 MUST be between one (1) and 16. 1667 BSSID: The BSSID assigned by the WTP for the WLAN created as a 1668 result of receiving an IEEE 802.11 Add WLAN. 1670 6.4. IEEE 802.11 Delete WLAN 1672 The IEEE 802.11 Delete WLAN message element is used to inform the WTP 1673 that a previously created WLAN is to be deleted, and contains the 1674 following fields: 1676 0 1 1677 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1679 | Radio ID | WLAN ID | 1680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1682 Type: 1027 for IEEE 802.11 Delete WLAN 1684 Length: 2 1686 Radio ID: An 8-bit value representing the radio, whose value is 1687 between one (1) and 31. 1689 WLAN ID: An 8-bit value specifying the WLAN Identifier. The value 1690 MUST be between one (1) and 16. 1692 6.5. IEEE 802.11 Direct Sequence Control 1694 The IEEE 802.11 Direct Sequence Control message element is a bi- 1695 directional element. When sent by the WTP, it contains the current 1696 state. When sent by the AC, the WTP MUST adhere to the values 1697 provided. This element is only used for IEEE 802.11b radios. The 1698 message element has the following fields. 1700 0 1 2 3 1701 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 1702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1703 | Radio ID | Reserved | Current Chan | Current CCA | 1704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1705 | Energy Detect Threshold | 1706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1708 Type: 1028 for IEEE 802.11 Direct Sequence Control 1710 Length: 8 1712 Radio ID: An 8-bit value representing the radio to configure, whose 1713 value is between one (1) and 31. 1715 Reserved: All implementations complying with this protocol MUST set 1716 to zero any bits that are reserved in the version of the protocol 1717 supported by that implementation. Receivers MUST ignore all bits 1718 not defined for the version of the protocol they support. 1720 Current Channel: This attribute contains the current operating 1721 frequency channel of the Direct Sequence Spread Spectrum (DSSS) 1722 PHY. This value comes from the IEEE 802.11 dot11CurrentChannel 1723 MIB element (see [IEEE.802-11.2007]). 1725 Current CCA: The current Clear Channel Assessment (CCA) method in 1726 operation, whose value can be found in the IEEE 802.11 1727 dot11CCAModeSupported MIB element (see [IEEE.802-11.2007]). Valid 1728 values are: 1730 1 - energy detect only (edonly) 1732 2 - carrier sense only (csonly) 1734 4 - carrier sense and energy detect (edandcs) 1736 8 - carrier sense with timer (cswithtimer) 1738 16 - high rate carrier sense and energy detect (hrcsanded) 1740 Energy Detect Threshold: The current Energy Detect Threshold being 1741 used by the DSSS PHY. The value can be found in the IEEE 802.11 1742 dot11EDThreshold MIB element (see [IEEE.802-11.2007]). 1744 6.6. IEEE 802.11 Information Element 1746 The IEEE 802.11 Information Element is used to communicate any IE 1747 defined in the IEEE 802.11 protocol. The data field contains the raw 1748 IE as it would be included within an IEEE 802.11 MAC management 1749 message. 1751 0 1 2 3 1752 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 1753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1754 | Radio ID | WLAN ID |B|P| Reserved |Info Element... 1755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1757 Type: 1029 for IEEE 802.11 Information Element 1759 Length: >= 4 1761 Radio ID: An 8-bit value representing the radio, whose value is 1762 between one (1) and 31. 1764 WLAN ID: An 8-bit value specifying the WLAN Identifier. The value 1765 MUST be between one (1) and 16. 1767 B: When set, the WTP is to include the information element in IEEE 1768 802.11 Beacons associated with the WLAN. 1770 P: When set, the WTP is to include the information element in Probe 1771 Responses associated with the WLAN. 1773 Reserved: All implementations complying with this protocol MUST set 1774 to zero any bits that are reserved in the version of the protocol 1775 supported by that implementation. Receivers MUST ignore all bits 1776 not defined for the version of the protocol they support. 1778 Info Element: The IEEE 802.11 Information Element, which includes 1779 the type, length and value field. 1781 6.7. IEEE 802.11 MAC Operation 1783 The IEEE 802.11 MAC Operation message element is sent by the AC to 1784 set the IEEE 802.11 MAC parameters on the WTP, and contains the 1785 following fields. 1787 0 1 2 3 1788 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 1789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1790 | Radio ID | Reserved | RTS Threshold | 1791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1792 | Short Retry | Long Retry | Fragmentation Threshold | 1793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1794 | Tx MSDU Lifetime | 1795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1796 | Rx MSDU Lifetime | 1797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1799 Type: 1030 for IEEE 802.11 MAC Operation 1801 Length: 16 1803 Radio ID: An 8-bit value representing the radio to configure, whose 1804 value is between one (1) and 31. 1806 Reserved: All implementations complying with this protocol MUST set 1807 to zero any bits that are reserved in the version of the protocol 1808 supported by that implementation. Receivers MUST ignore all bits 1809 not defined for the version of the protocol they support. 1811 RTS Threshold: This attribute indicates the number of octets in an 1812 MAC Protocol Data Unit (MPDU), below which an Request To Send/ 1813 Clear To Send (RTS/CTS) handshake MUST NOT be performed. An RTS/ 1814 CTS handshake MUST be performed at the beginning of any frame 1815 exchange sequence where the MPDU is of type Data or Management, 1816 the MPDU has an individual address in the Address1 field, and the 1817 length of the MPDU is greater than this threshold. Setting this 1818 attribute to be larger than the maximum MSDU size MUST have the 1819 effect of turning off the RTS/CTS handshake for frames of Data or 1820 Management type transmitted by this STA. Setting this attribute 1821 to zero MUST have the effect of turning on the RTS/CTS handshake 1822 for all frames of Data or Management type transmitted by this STA. 1823 The default value of this attribute MUST be 2347. The value of 1824 this field comes from the IEEE 802.11 dot11RTSThreshold MIB 1825 element, (see [IEEE.802-11.2007]). 1827 Short Retry: This attribute indicates the maximum number of 1828 transmission attempts of a frame, the length of which is less than 1829 or equal to RTSThreshold, that MUST be made before a failure 1830 condition is indicated. The default value of this attribute MUST 1831 be 7. The value of this field comes from the IEEE 802.11 1832 dot11ShortRetryLimit MIB element, (see [IEEE.802-11.2007]). 1834 Long Retry: This attribute indicates the maximum number of 1835 transmission attempts of a frame, the length of which is greater 1836 than dot11RTSThreshold, that MUST be made before a failure 1837 condition is indicated. The default value of this attribute MUST 1838 be 4. The value of this field comes from the IEEE 802.11 1839 dot11LongRetryLimit MIB element, (see [IEEE.802-11.2007]). 1841 Fragmentation Threshold: This attribute specifies the current 1842 maximum size, in octets, of the MPDU that MAY be delivered to the 1843 PHY. A MAC Service Data Unit (MSDU) MUST be broken into fragments 1844 if its size exceeds the value of this attribute after adding MAC 1845 headers and trailers. An MSDU or MAC Management Protocol Data 1846 Unit (MMPDU) MUST be fragmented when the resulting frame has an 1847 individual address in the Address1 field, and the length of the 1848 frame is larger than this threshold. The default value for this 1849 attribute MUST be the lesser of 2346 or the aMPDUMaxLength of the 1850 attached PHY and MUST never exceed the lesser of 2346 or the 1851 aMPDUMaxLength of the attached PHY. The value of this attribute 1852 MUST never be less than 256. The value of this field comes from 1853 the IEEE 802.11 dot11FragmentationThreshold MIB element, (see 1854 [IEEE.802-11.2007]). 1856 Tx MSDU Lifetime: This attribute specifies the elapsed time in TU, 1857 after the initial transmission of an MSDU, after which further 1858 attempts to transmit the MSDU MUST be terminated. The default 1859 value of this attribute MUST be 512. The value of this field 1860 comes from the IEEE 802.11 dot11MaxTransmitMSDULifetime MIB 1861 element, (see [IEEE.802-11.2007]). 1863 Rx MSDU Lifetime: This attribute specifies the elapsed time in TU, 1864 after the initial reception of a fragmented MMPDU or MSDU, after 1865 which further attempts to reassemble the MMPDU or MSDU MUST be 1866 terminated. The default value MUST be 512. The value of this 1867 field comes from the IEEE 802.11 dot11MaxReceiveLifetime MIB 1868 element, (see [IEEE.802-11.2007]). 1870 6.8. IEEE 802.11 MIC Countermeasures 1872 The IEEE 802.11 MIC Countermeasures message element is sent by the 1873 WTP to the AC to indicate the occurrence of a MIC failure. For more 1874 information on MIC failure events, see the 1875 dot11RSNATKIPCounterMeasuresInvoked MIB element definition in 1876 [IEEE.802-11.2007]. 1878 0 1 2 3 1879 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 1880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1881 | Radio ID | WLAN ID | MAC Address | 1882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1883 | MAC Address | 1884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1886 Type: 1031 for IEEE 802.11 MIC Countermeasures 1888 Length: 8 1890 Radio ID: The Radio Identifier, whose value is between one (1) and 1891 31, typically refers to some interface index on the WTP. 1893 WLAN ID: This 8-bit unsigned integer includes the WLAN Identifier, 1894 on which the MIC failure occurred. The value MUST be between one 1895 (1) and 16. 1897 MAC Address: The MAC Address of the station that caused the MIC 1898 failure. 1900 6.9. IEEE 802.11 Multi-Domain Capability 1902 The IEEE 802.11 Multi-Domain Capability message element is used by 1903 the AC to inform the WTP of regulatory limits. The AC will transmit 1904 one message element per frequency band to indicate the regulatory 1905 constraints in that domain. The message element contains the 1906 following fields. 1908 0 1 2 3 1909 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 1910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1911 | Radio ID | Reserved | First Channel # | 1912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1913 | Number of Channels | Max Tx Power Level | 1914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1916 Type: 1032 for IEEE 802.11 Multi-Domain Capability 1918 Length: 8 1920 Radio ID: An 8-bit value representing the radio to configure, whose 1921 value is between one (1) and 31. 1923 Reserved: All implementations complying with this protocol MUST set 1924 to zero any bits that are reserved in the version of the protocol 1925 supported by that implementation. Receivers MUST ignore all bits 1926 not defined for the version of the protocol they support. 1928 First Channnel #: This attribute indicates the value of the lowest 1929 channel number in the sub-band for the associated domain country 1930 string. The value of this field comes from the IEEE 802.11 1931 dot11FirstChannelNumber MIB element (see [IEEE.802-11.2007]). 1933 Number of Channels: This attribute indicates the value of the total 1934 number of channels allowed in the sub-band for the associated 1935 domain country string (see Section 6.23). The value of this field 1936 comes from the IEEE 802.11 dot11NumberofChannels MIB element (see 1937 [IEEE.802-11.2007]). 1939 Max Tx Power Level: This attribute indicates the maximum transmit 1940 power, in dBm, allowed in the sub-band for the associated domain 1941 country string (see Section 6.23). The value of this field comes 1942 from the IEEE 802.11 dot11MaximumTransmitPowerLevel MIB element 1943 (see [IEEE.802-11.2007]). 1945 6.10. IEEE 802.11 OFDM Control 1947 The IEEE 802.11 Orthogonal Frequency Division Multiplexing (OFDM) 1948 Control message element is a bi-directional element. When sent by 1949 the WTP, it contains the current state. When sent by the AC, the WTP 1950 MUST adhere to the received values. This message element is only 1951 used for 802.11a radios and contains the following fields: 1953 0 1 2 3 1954 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 1955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1956 | Radio ID | Reserved | Current Chan | Band Support | 1957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1958 | TI Threshold | 1959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1961 Type: 1033 for IEEE 802.11 OFDM Control 1963 Length: 8 1965 Radio ID: An 8-bit value representing the radio to configure, whose 1966 value is between one (1) and 31. 1968 Reserved: All implementations complying with this protocol MUST set 1969 to zero any bits that are reserved in the version of the protocol 1970 supported by that implementation. Receivers MUST ignore all bits 1971 not defined for the version of the protocol they support. 1973 Current Channel: This attribute contains the current operating 1974 frequency channel of the OFDM PHY. The value of this field comes 1975 from the IEEE 802.11 dot11CurrentFrequency MIB element (see 1976 [IEEE.802-11.2007]). 1978 Band Supported: The capability of the OFDM PHY implementation to 1979 operate in the three U-NII bands. The value of this field comes 1980 from the IEEE 802.11 dot11FrequencyBandsSupported MIB element (see 1981 [IEEE.802-11.2007]), coded as a bit field, whose values are: 1983 Bit 0 - capable of operating in the 5.15-5.25 GHz band 1985 Bit 1 - capable of operating in the 5.25-5.35 GHz band 1987 Bit 2 - capable of operating in the 5.725-5.825 GHz band 1989 Bit 3 - capable of operating in the 5.47-5.725 GHz band 1991 Bit 4 - capable of operating in the lower Japanese 5.25 GHz band 1993 Bit 5 - capable of operating in the 5.03-5.091 GHz band 1995 Bit 6 - capable of operating in the 4.94-4.99 GHz band 1997 For example, for an implementation capable of operating in the 1998 5.15-5.35 GHz bands this attribute would take the value 3. 2000 TI Threshold: The Threshold being used to detect a busy medium 2001 (frequency). CCA MUST report a busy medium upon detecting the 2002 RSSI above this threshold. The value of this field comes from the 2003 IEEE 802.11 dot11TIThreshold MIB element (see [IEEE.802-11.2007]). 2005 6.11. IEEE 802.11 Rate Set 2007 The rate set message element value is sent by the AC and contains the 2008 supported operational rates. It contains the following fields. 2010 0 1 2 3 2011 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 2012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2013 | Radio ID | Rate Set... 2014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2016 Type: 1034 for IEEE 802.11 Rate Set 2018 Length: >= 3 2020 Radio ID: An 8-bit value representing the radio to configure, whose 2021 value is between one (1) and 31. 2023 Rate Set: The AC generates the Rate Set that the WTP is to include 2024 in its Beacon and Probe messages. The length of this field is 2025 between 2 and 8 bytes. The value of this field comes from the 2026 IEEE 802.11 dot11OperationalRateSet MIB element (see 2027 [IEEE.802-11.2007]). 2029 6.12. IEEE 802.11 RSNA Error Report From Station 2031 The IEEE 802.11 RSN Error Report From Station message element is used 2032 by a WTP to send RSN error reports to the AC. The WTP does not need 2033 to transmit any reports that do not include any failures. The fields 2034 from this message element come from the IEEE 802.11 2035 Dot11RSNAStatsEntry table, see [IEEE.802-11.2007]. 2037 0 1 2 3 2038 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 2039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2040 | Client MAC Address | 2041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2042 | Client MAC Address | BSSID | 2043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2044 | BSSID | 2045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2046 | Radio ID | WLAN ID | Reserved | 2047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2048 | TKIP ICV Errors | 2049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2050 | TKIP Local MIC Failures | 2051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2052 | TKIP Remote MIC Failures | 2053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2054 | CCMP Replays | 2055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2056 | CCMP Decrypt Errors | 2057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2058 | TKIP Replays | 2059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2061 Type: 1035 for IEEE 802.11 RSNA Error Report From Station 2063 Length: 40 2065 Client MAC Address: The Client MAC Address of the station. 2067 BSSID: The BSSID on which the failures are being reported on. 2069 Radio ID: The Radio Identifier, whose value is between one (1) and 2070 31, typically refers to some interface index on the WTP 2072 WLAN ID: The WLAN ID on which the RSNA failures are being reported. 2073 The value MUST be between one (1) and 16. 2075 Reserved: All implementations complying with this protocol MUST set 2076 to zero any bits that are reserved in the version of the protocol 2077 supported by that implementation. Receivers MUST ignore all bits 2078 not defined for the version of the protocol they support. 2080 TKIP ICV Errors: A 32-bit value representing the number of Temporal 2081 Key Integrity Protocol (TKIP) (as defined in [IEEE.802-11.2007]) 2082 ICV errors encountered when decrypting packets from the station. 2083 The value of this field comes from the IEEE 802.11 2084 dot11RSNAStatsTKIPICVErrors MIB element (see [IEEE.802-11.2007]). 2086 TKIP Local MIC Failures: A 32-bit value representing the number of 2087 MIC failures encountered when checking the integrity of packets 2088 received from the station. The value of this field comes from the 2089 IEEE 802.11 dot11RSNAStatsTKIPLocalMICFailures MIB element (see 2090 [IEEE.802-11.2007]). 2092 TKIP Remote MIC Failures: A 32-bit value representing the number of 2093 MIC failures reported by the station encountered (possibly via the 2094 EAPOL-Key frame). The value of this field comes from the IEEE 2095 802.11 dot11RSNAStatsTKIPRemoteMICFailures MIB element (see 2096 [IEEE.802-11.2007]). 2098 CCMP Replays: A 32-bit value representing the number of CCMP MPDUs 2099 discarded by the replay detection mechanism. The value of this 2100 field comes from the IEEE 802.11 dot11RSNACCMPReplays MIB element 2101 (see [IEEE.802-11.2007]). 2103 CCMP Decrypt Errors: A 32-bit value representing the number of CCMP 2104 MDPUs discarded by the decryption algorithm. The value of this 2105 field comes from the IEEE 802.11 dot11RSNACCMPDecryptErrors MIB 2106 element (see [IEEE.802-11.2007]). 2108 TKIP Replays: A 32-bit value representing the number of TKIP 2109 Replays detected in frames received from the station. The value 2110 of this field comes from the IEEE 802.11 dot11RSNAStatsTKIPReplays 2111 MIB element (see [IEEE.802-11.2007]). 2113 6.13. IEEE 802.11 Station 2115 The IEEE 802.11 Station message element accompanies the Add Station 2116 message element, and is used to deliver IEEE 802.11 station policy 2117 from the AC to the WTP. 2119 The latest IEEE 802.11 Station message element overrides any 2120 previously received message elements. 2122 If the QoS field is set, the WTP MUST observe and provide policing of 2123 the 802.11e priority tag to ensure that it does not exceed the value 2124 provided by the AC. 2126 0 1 2 3 2127 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 2128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2129 | Radio ID | Association ID | Flags | 2130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2131 | MAC Address | 2132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2133 | MAC Address | Capabilities | 2134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2135 | WLAN ID |Supported Rates| 2136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2138 Type: 1036 for IEEE 802.11 Station 2140 Length: >= 14 2142 Radio ID: An 8-bit value representing the radio, whose value is 2143 between one (1) and 31. 2145 Association ID: A 16-bit value specifying the IEEE 802.11 2146 Association Identifier 2148 Flags: All implementations complying with this protocol MUST set to 2149 zero any bits that are reserved in the version of the protocol 2150 supported by that implementation. Receivers MUST ignore all bits 2151 not defined for the version of the protocol they support. 2153 MAC Address: The station's MAC Address 2155 Capabilities: A 16-bit field containing the IEEE 802.11 2156 Capabilities Information Field to use with the station. 2158 WLAN ID: An 8-bit value specifying the WLAN Identifier. The value 2159 MUST be between one (1) and 16. 2161 Supported Rates: The variable length field containing the supported 2162 rates to be used with the station, as found in the IEEE 802.11 2163 dot11OperationalRateSet MIB element (see [IEEE.802-11.2007]). 2164 This field MUST NOT exceed 126 octets and specifies the set of 2165 data rates at which the station may transmit data, where each 2166 octet represents a data rate. 2168 6.14. IEEE 802.11 Station QoS Profile 2170 The IEEE 802.11 Station QoS Profile message element contains the 2171 maximum IEEE 802.11e priority tag that may be used by the station. 2172 Any packet received that exceeds the value encoded in this message 2173 element MUST be tagged using the maximum value permitted by to the 2174 user. The priority tag MUST be between zero (0) and seven (7). This 2175 message element MUST NOT be present without the IEEE 802.11 Station 2176 (see Section 6.13) message element. 2178 0 1 2 3 2179 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 2180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2181 | MAC Address | 2182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2183 | MAC Address | Reserved |8021p| 2184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2186 Type: 1037 for IEEE 802.11 Station QOS Profile 2188 Length: 8 2190 MAC Address: The station's MAC Address 2192 Reserved: All implementations complying with this protocol MUST set 2193 to zero any bits that are reserved in the version of the protocol 2194 supported by that implementation. Receivers MUST ignore all bits 2195 not defined for the version of the protocol they support. 2197 8021p: The maximum 802.1p priority value that the WTP will allow in 2198 the Traffic Identifier (TID) field in the extended 802.11e QOS 2199 Data header. 2201 6.15. IEEE 802.11 Station Session Key 2203 The IEEE 802.11 Station Session Key message element is sent when the 2204 AC by the AC to provision encryption keys, or to configure an access 2205 policy, on the WTP. This message element MUST NOT be present without 2206 the IEEE 802.11 Station (see Section 6.13) message element, and MUST 2207 NOT be sent if the WTP had not specifically advertised support for 2208 the requested encryption scheme, through the WTP Descriptor Message 2209 Element's Encryption Capabilities Field (see Section 8.1). 2211 When the Key field is non-zero in length, the RSN information element 2212 MUST be sent along with the IEEE 802.11 Station Session Key in order 2213 to instruct the WTP on the usage of the Key field. The WTP MUST 2214 observe the AKM field of the RSN information element in order to 2215 identify the authentication protocol to be enforced with the station. 2217 If cryptographic services are provided at the WTP, the WTP MUST 2218 observe the algorithm dictated in the Pairwise Cipher Suite field of 2219 the RSN information element sent by the AC. The RSN Information 2220 Element included here is the one sent by the AC in the third message 2221 of the 4-Way Key Handshake, which specifies which cipher is to be 2222 applied to provide encryption and decryption services with the 2223 station. The RSN Information Element is used to communicate any 2224 supported algorithm, including WEP, TKIP and AES-CCMP. In the case 2225 of static WEP keys, the RSN Information Element is still used to 2226 indicate the cryptographic algorithm even though no key exchange 2227 occurred. 2229 If the IEEE 802.11 Station Session Key message element's AKM-Only bit 2230 is set, the WTP MUST drop all IEEE 802.11 packets that are not part 2231 of the Authentication and Key Management (AKM), such as EAP. Note 2232 that AKM-Only is MAY be set while an encryption key is in force, 2233 requiring that the AKM packets be encrypted. Once the station has 2234 successfully completed authentication via the AKM, the AC MUST send a 2235 new Add Station message element to remove the AKM-Only restriction, 2236 and optionally push the session key down to the WTP. 2238 0 1 2 3 2239 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 2240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2241 | MAC Address | 2242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2243 | MAC Address |A|C| Flags | 2244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2245 | Pairwise TSC | 2246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2247 | Pairwise TSC | Pairwise RSC | 2248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2249 | Pairwise RSC | 2250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2251 | Key... 2252 +-+-+-+-+-+-+-+- 2254 Type: 1038 for IEEE 802.11 Station Session Key 2256 Length: >= 25 2258 MAC Address: The station's MAC Address 2260 Flags: All implementations complying with this protocol MUST set to 2261 zero any bits that are reserved in the version of the protocol 2262 supported by that implementation. Receivers MUST ignore all bits 2263 not defined for the version of the protocol they support. The 2264 following bits are defined: 2266 A: The one bit AKM-Only field is set by the AC to inform the WTP 2267 that is MUST NOT accept any 802.11 data frames, other than AKM 2268 frames. This is the equivalent of the WTP's IEEE 802.1X port 2269 for the station to be in the closed state. When set, the WTP 2270 MUST drop any non-IEEE 802.1X packets it receives from the 2271 station. 2273 C: The one bit field is set by the AC to inform the WTP that 2274 encryption services will be provided by the AC. When set, the 2275 WTP SHOULD police frames received from stations to ensure that 2276 are properly encrypted as specified in the RSN Information 2277 Element, but does not need to take specific cryptographic 2278 action on the frame. Similarly, for transmitted frames, the 2279 WTP only needs to forward already encrypted frames. Since 2280 packets received by the WTP will be encrypted, the WTP cannot 2281 modify the contents of the packets, including modifying the 2282 DSCP markings of the encapsulated packet. In this case, this 2283 function would be the responsibility of the AC. 2285 Pairwise TSC: The 6 byte Transmit Sequence Counter (TSC) field to 2286 use for unicast packets transmitted to the station. 2288 Pairwise RSC: The 6 byte Receive Sequence Counter (RSC) to use for 2289 unicast packets received from the station. 2291 Key: The pairwise key the WTP is to use when encrypting traffic to/ 2292 from the station. The format of the keys differ based on the 2293 crypto algorithm used. For unicast WEP keys, the Key field 2294 consists of the actual unicast encryption key (note, this is used 2295 when WEP is used in conjunction with 802.1X, and therefore a 2296 unicast encryption key exists). When used with CCMP, the Key 2297 field includes the 128-bit Temporal Key. When used with TKIP, the 2298 Key field includes the 256-bit Temporal Key (which consists of a 2299 128-bit key used as input for TKIP key mixing, and two 64-bit keys 2300 used for Michael). 2302 6.16. IEEE 802.11 Statistics 2304 The IEEE 802.11 Statistics message element is sent by the WTP to 2305 transmit its current statistics, and contains the following fields. 2306 All of the fields in this message element are set to zero upon WTP 2307 initialization. The fields will roll over when they reach their 2308 maximum value of 4294967295. Due to the nature of each counter 2309 representing different data points, the roll over event will vary 2310 greatly across each field. Applications or human operators using 2311 these counters need to be aware about the minimal possible times 2312 between rollover events in order to make sure that no consecutive 2313 rollover events are missed. 2315 0 1 2 3 2316 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 2317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2318 | Radio ID | Reserved | 2319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2320 | Tx Fragment Count | 2321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2322 | Multicast Tx Count | 2323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2324 | Failed Count | 2325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2326 | Retry Count | 2327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2328 | Multiple Retry Count | 2329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2330 | Frame Duplicate Count | 2331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2332 | RTS Success Count | 2333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2334 | RTS Failure Count | 2335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2336 | ACK Failure Count | 2337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2338 | Rx Fragment Count | 2339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2340 | Multicast RX Count | 2341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2342 | FCS Error Count | 2343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2344 | Tx Frame Count | 2345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2346 | Decryption Errors | 2347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2348 | Discarded QoS Fragment Count | 2349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2350 | Associated Station Count | 2351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2352 | QoS CF Polls Received Count | 2353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2354 | QoS CF Polls Unused Count | 2355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2356 | QoS CF Polls Unusable Count | 2357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2359 Type: 1039 for IEEE 802.11 Statistics 2361 Length: 80 2363 Radio ID: An 8-bit value representing the radio, whose value is 2364 between one (1) and 31. 2366 Reserved: All implementations complying with this protocol MUST set 2367 to zero any bits that are reserved in the version of the protocol 2368 supported by that implementation. Receivers MUST ignore all bits 2369 not defined for the version of the protocol they support. 2371 Tx Fragment Count: A 32-bit value representing the number of 2372 fragmented frames transmitted. The value of this field comes from 2373 the IEEE 802.11 dot11TransmittedFragmentCount MIB element (see 2374 [IEEE.802-11.2007]). 2376 Multicast Tx Count: A 32-bit value representing the number of 2377 multicast frames transmitted. The value of this field comes from 2378 the IEEE 802.11 dot11MulticastTransmittedFrameCount MIB element 2379 (see [IEEE.802-11.2007]). 2381 Failed Count: A 32-bit value representing the transmit excessive 2382 retries. The value of this field comes from the IEEE 802.11 2383 dot11FailedCount MIB element (see [IEEE.802-11.2007]). 2385 Retry Count: A 32-bit value representing the number of transmit 2386 retries. The value of this field comes from the IEEE 802.11 2387 dot11RetryCount MIB element (see [IEEE.802-11.2007]). 2389 Multiple Retry Count: A 32-bit value representing the number of 2390 transmits that required more than one retry. The value of this 2391 field comes from the IEEE 802.11 dot11MultipleRetryCount MIB 2392 element (see [IEEE.802-11.2007]). 2394 Frame Duplicate Count: A 32-bit value representing the duplicate 2395 frames received. The value of this field comes from the IEEE 2396 802.11 dot11FrameDuplicateCount MIB element (see 2397 [IEEE.802-11.2007]). 2399 RTS Success Count: A 32-bit value representing the number of 2400 successfully transmitted Ready To Send (RTS). The value of this 2401 field comes from the IEEE 802.11 dot11RTSSuccessCount MIB element 2402 (see [IEEE.802-11.2007]). 2404 RTS Failure Count: A 32-bit value representing the failed 2405 transmitted RTS. The value of this field comes from the IEEE 2406 802.11 dot11RTSFailureCount MIB element (see [IEEE.802-11.2007]). 2408 ACK Failure Count: A 32-bit value representing the number of failed 2409 acknowledgements. The value of this field comes from the IEEE 2410 802.11 dot11ACKFailureCount MIB element (see [IEEE.802-11.2007]). 2412 Rx Fragment Count: A 32-bit value representing the number of 2413 fragmented frames received. The value of this field comes from 2414 the IEEE 802.11 dot11ReceivedFragmentCount MIB element (see 2415 [IEEE.802-11.2007]). 2417 Multicast RX Count: A 32-bit value representing the number of 2418 multicast frames received. The value of this field comes from the 2419 IEEE 802.11 dot11MulticastReceivedFrameCount MIB element (see 2420 [IEEE.802-11.2007]). 2422 FCS Error Count: A 32-bit value representing the number of FCS 2423 failures. The value of this field comes from the IEEE 802.11 2424 dot11FCSErrorCount MIB element (see [IEEE.802-11.2007]). 2426 Decryption Errors: A 32-bit value representing the number of 2427 Decryption errors that occurred on the WTP. Note that this field 2428 is only valid in cases where the WTP provides encryption/ 2429 decryption services. The value of this field comes from the IEEE 2430 802.11 dot11WEPUndecryptableCount MIB element (see 2431 [IEEE.802-11.2007]). 2433 Discarded QoS Fragment Count: A 32-bit value representing the 2434 number of discarded QoS fragments received. The value of this 2435 field comes from the IEEE 802.11 dot11QoSDiscardedFragmentCount 2436 MIB element (see [IEEE.802-11.2007]). 2438 Associated Station Count: A 32-bit value representing the number of 2439 number of associated stations. The value of this field comes from 2440 the IEEE 802.11 dot11AssociatedStationCount MIB element (see 2441 [IEEE.802-11.2007]). 2443 QoS CF Polls Received Count: A 32-bit value representing the number 2444 of (+)CF-Polls received. The value of this field comes from the 2445 IEEE 802.11 dot11QosCFPollsReceivedCount MIB element (see 2446 [IEEE.802-11.2007]). 2448 QoS CF Polls Unused Count: A 32-bit value representing the number 2449 of (+)CF-Polls that have been received, but not used. The value 2450 of this field comes from the IEEE 802.11 2451 dot11QosCFPollsUnusedCount MIB element (see [IEEE.802-11.2007]). 2453 QoS CF Polls Unusable Count: A 32-bit value representing the number 2454 of (+)CF-Polls that have been received, but could not be used due 2455 to the Transmission Opportunity (TXOP) size being smaller than the 2456 time that is required for one frame exchange sequence. The value 2457 of this field comes from the IEEE 802.11 2458 dot11QosCFPollsUnusableCount MIB element (see [IEEE.802-11.2007]). 2460 6.17. IEEE 802.11 Supported Rates 2462 The IEEE 802.11 Supported Rates message element is sent by the WTP to 2463 indicate the rates that it supports, and contains the following 2464 fields. 2466 0 1 2 3 2467 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 2468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2469 | Radio ID | Supported Rates... 2470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2472 Type: 1040 for IEEE 802.11 Supported Rates 2474 Length: >= 3 2476 Radio ID: An 8-bit value representing the radio, whose value is 2477 between one (1) and 31. 2479 Supported Rates: The WTP includes the Supported Rates that its 2480 hardware supports. The format is identical to the Rate Set 2481 message element and is between 2 and 8 bytes in length. 2483 6.18. IEEE 802.11 Tx Power 2485 The IEEE 802.11 Tx Power message element value is bi-directional. 2486 When sent by the WTP, it contains the current power level of the 2487 radio in question. When sent by the AC, it contains the power level 2488 the WTP MUST adhere to. 2490 0 1 2 3 2491 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 2492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2493 | Radio ID | Reserved | Current Tx Power | 2494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2496 Type: 1041 for IEEE 802.11 Tx Power 2497 Length: 4 2499 Radio ID: An 8-bit value representing the radio to configure, whose 2500 value is between one (1) and 31. 2502 Reserved: All implementations complying with this protocol MUST set 2503 to zero any bits that are reserved in the version of the protocol 2504 supported by that implementation. Receivers MUST ignore all bits 2505 not defined for the version of the protocol they support. 2507 Current Tx Power: This attribute contains the current transmit 2508 output power in mW, as described in the dot11CurrentTxPowerLevel 2509 MIB variable, see [IEEE.802-11.2007]. 2511 6.19. IEEE 802.11 Tx Power Level 2513 The IEEE 802.11 Tx Power Level message element is sent by the WTP and 2514 contains the different power levels supported. The values found in 2515 this message element are found in the IEEE 802.11 2516 Dot11PhyTxPowerEntry MIB table, see [IEEE.802-11.2007]. 2518 The value field contains the following: 2520 0 1 2 3 2521 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 2522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2523 | Radio ID | Num Levels | Power Level [n] | 2524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2526 Type: 1042 for IEEE 802.11 Tx Power Level 2528 Length: >= 4 2530 Radio ID: An 8-bit value representing the radio to configure, whose 2531 value is between one (1) and 31. 2533 Num Levels: The number of power level attributes. The value of 2534 this field comes from the IEEE 802.11 2535 dot11NumberSupportedPowerLevels MIB element (see 2536 [IEEE.802-11.2007]). 2538 Power Level: Each power level fields contains a supported power 2539 level, in mW. The value of this field comes from the 2540 corresponding IEEE 802.11 dot11TxPowerLevel[n] MIB element, see 2541 [IEEE.802-11.2007]. 2543 6.20. IEEE 802.11 Update Station QoS 2545 The IEEE 802.11 Update Station QoS message element is used to change 2546 the Quality of Service policy on the WTP for a given station. The 2547 QoS tags included in this message element are to be applied to 2548 packets received at the WTP from the station indicated through the 2549 MAC Address field. This message element overrides the default values 2550 provided through the IEEE 802.11 WTP Quality of Service message 2551 element (see Section 6.22). Any tagging performed by the WTP MUST be 2552 directly applied to the packets receive from the station, as well as 2553 the CAPWAP tunnel, if the packets are tunneled to the AC. See 2554 Section 2.6 for more information. 2556 0 1 2 3 2557 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 2558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2559 | Radio ID | MAC Address | 2560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2561 | MAC Address | QoS Sub-Element... | 2562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2564 Type: 1043 for IEEE 802.11 Update Station QoS 2566 Length: 8 2568 Radio ID: The Radio Identifier, whose value is between one (1) and 2569 31, typically refers to some interface index on the WTP 2571 MAC Address: The station's MAC Address. 2573 QoS Sub-Element: The IEEE 802.11 WTP Quality of Service message 2574 element contains four QoS sub-elements, one for every QoS profile. 2575 The order of the QoS profiles are Voice, Video, Best Effort and 2576 Background. 2578 0 1 2579 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2581 | Reserved|8021p|RSV| DSCP Tag | 2582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2584 Reserved: All implementations complying with this protocol MUST 2585 set to zero any bits that are reserved in the version of the 2586 protocol supported by that implementation. Receivers MUST 2587 ignore all bits not defined for the version of the protocol 2588 they support. 2590 8021p: The three bit 802.1p priority value to use if packets are 2591 to be IEEE 802.1p tagged. This field is used only if the 'P' 2592 bit in the WTP Quality of Service message element was set; 2593 otherwise, its contents MUST be ignored. 2595 RSV: All implementations complying with this protocol MUST set 2596 to zero any bits that are reserved in the version of the 2597 protocol supported by that implementation. Receivers MUST 2598 ignore all bits not defined for the version of the protocol 2599 they support. 2601 DSCP Tag: The 6 bit DSCP label to use if packets are eligible to 2602 be DSCP tagged, specifically an IPv4 or IPv6 packet (see 2603 [RFC2474]). This field is used only if the 'D' bit in the WTP 2604 Quality of Service message element was set; otherwise, its 2605 contents MUST be ignored. 2607 6.21. IEEE 802.11 Update WLAN 2609 The IEEE 802.11 Update WLAN message element is used by the AC to 2610 define a wireless LAN on the WTP. The inclusion of this message 2611 element MUST also include the IEEE 802.11 Information Element message 2612 element, containing the following 802.11 IEs: 2614 Power Constraint information element 2616 WPA information element [WPA] 2618 RSN information element 2620 EDCA Parameter Set information element 2622 QoS Capability information element 2624 WMM information element [WMM] 2626 These IEEE 802.11 information elements are stored by the WTP and 2627 included in any Probe Responses and Beacons generated, as specified 2628 in the IEEE 802.11 standard [IEEE.802-11.2007]. 2630 If cryptographic services are provided at the WTP, the WTP MUST 2631 observe the algorithm dictated in the Group Cipher Suite field of the 2632 RSN information element sent by the AC. The RSN Information Element 2633 is used to communicate any supported algorithm, including WEP, TKIP 2634 and AES-CCMP. In the case of static WEP keys, the RSN Information 2635 Element is still used to indicate the cryptographic algorithm even 2636 though no key exchange occurred. 2638 The message element uses the following format: 2640 0 1 2 3 2641 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 2642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2643 | Radio ID | WLAN ID | Capability | 2644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2645 | Key Index | Key Status | Key Length | 2646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2647 | Key... | 2648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2650 Type: 1044 for IEEE 802.11 Update WLAN 2652 Length: >= 8 2654 Radio ID: An 8-bit value representing the radio, whose value is 2655 between one (1) and 31. 2657 WLAN ID: An 8-bit value specifying the WLAN Identifier. The value 2658 MUST be between one (1) and 16. 2660 Capability: A 16-bit value containing the capability information 2661 field to be advertised by the WTP in the Probe Request and Beacon 2662 frames. Each bit of the Capability field represents a different 2663 WTP capability, which are described in detail in 2664 [IEEE.802-11.2007]. The format of the field is: 2666 0 1 2667 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2669 |E|I|C|F|P|S|B|A|M|Q|T|D|V|O|K|L| 2670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2672 E (ESS): The AC MUST set the Extended Service Set (ESS) subfield 2673 to 1. 2675 I (IBSS): The AC MUST set the Independent Basic Service Set 2676 (IBSS) subfield to 0. 2678 C (CF-Pollable): The AC sets the Contention Free Pollable (CF- 2679 Pollable) subfield based on the table found in 2680 [IEEE.802-11.2007]. 2682 F (CF-Poll Request): The AC sets the CF-Poll Request subfield 2683 based on the table found in [IEEE.802-11.2007]. 2685 P (Privacy): The AC sets the Privacy subfield based on the 2686 confidentiality requirements of the WLAN, as defined in 2687 [IEEE.802-11.2007]. 2689 S (Short Preamble): The AC sets the Short Preamble subfield 2690 based on whether the use of short preambles are permitted on 2691 the WLAN, as defined in [IEEE.802-11.2007]. 2693 B (PBCC): The AC sets the Packet Binary Convolutional Code 2694 (PBCC) modulation option subfield based on whether the use of 2695 PBCC is permitted on the WLAN, as defined in 2696 [IEEE.802-11.2007]. 2698 A (Channel Agility): The AC sets the Channel Agility subfield 2699 based on whether the WTP is capable of supporting the High Rate 2700 Direct Sequence Spread Spectrum (HR/DSSS), as defined in 2701 [IEEE.802-11.2007]. 2703 M (Spectrum Management): The AC sets the Spectrum Management 2704 subfield according to the value of the 2705 dot11SpectrumManagementRequired MIB variable, as defined in 2706 [IEEE.802-11.2007]. 2708 Q (QOS): The AC sets the Quality of Service (QOS) subfield based 2709 on the table found in [IEEE.802-11.2007]. 2711 T (Short Slot Time): The AC sets the Short Slot Timesubfield 2712 according to the value of the WTP's currently used slot time 2713 value, as defined in [IEEE.802-11.2007]. 2715 D (APSD): The AC sets the APSD subfield according to the value 2716 of the dot11APSDOptionImplemented Management Information Base 2717 (MIB) variable, as defined in [IEEE.802-11.2007]. 2719 V (Reserved): The AC sets the Reserved subfield to zero, as 2720 defined in [IEEE.802-11.2007]. 2722 O (DSSS-OFDM): The AC sets the DSSS-OFDM subfield to indicate 2723 the use of Direct Sequence Spread Spectrum with Orthogonal 2724 Frequency Division Multiplexing (DSSS-OFDM), as defined in 2725 [IEEE.802-11.2007]. 2727 K (Delayed Block ACK): The AC sets the Delayed Block ACK 2728 subfield according to the value of the 2729 dot11DelayedBlockAckOptionImplemented MIB variable, as defined 2730 in [IEEE.802-11.2007]. 2732 L (Immediate Block ACK): The AC sets the Delayed Block ACK 2733 subfield according to the value of the 2734 dot11ImmediateBlockAckOptionImplemented MIB variable, as 2735 defined in [IEEE.802-11.2007]. 2737 Key-Index: The Key Index associated with the key. 2739 Key Status: A 1 byte value that specifies the state and usage of 2740 the key that has been included. The following values describe the 2741 key usage and its status: 2743 0 - A value of zero, with the inclusion of the RSN Information 2744 Element means that the WLAN uses per-station encryption keys, 2745 and therefore the key in the 'Key' field is only used for 2746 multicast traffic. 2748 1 - When set to one, the WLAN employs a shared WEP key, also 2749 known as a static WEP key, and uses the encryption key for both 2750 unicast and multicast traffic for all stations. 2752 2 - The value of 2 indicates that the AC will begin rekeying the 2753 GTK with the STA's in the BSS. It is only valid when IEEE 2754 802.11 is enabled as the security policy for the BSS. 2756 3 - The value of 3 indicates that the AC has completed rekeying 2757 the GTK and broadcast packets no longer need to be duplicated 2758 and transmitted with both GTK's. 2760 Key Length: A 16-bit value representing the length of the Key 2761 field. 2763 Key: A Session Key, whose length is known via the key length field, 2764 used to provide data privacy. For static WEP keys, which is true 2765 when the 'Key Status' bit is set to one, this key is used for both 2766 unicast and multicast traffic. For encryption schemes that employ 2767 a separate encryption key for unicast and multicast traffic, the 2768 key included here only applies to multicast data, and the cipher 2769 suite is specified in an accompanied RSN Information Element. In 2770 these scenarios, the key, and cipher information, is communicated 2771 via the Add Station message element, see Section 4.6.8 in 2772 [I-D.ietf-capwap-protocol-specification]. When used with WEP, the 2773 key field includes the broadcast key. When used with CCMP, the 2774 Key field includes the 128-bit Group Temporal Key. When used with 2775 TKIP, the Key field includes the 256-bit Group Temporal Key (which 2776 consists of a 128-bit key used as input for TKIP key mixing, and 2777 two 64-bit keys used for Michael). 2779 6.22. IEEE 802.11 WTP Quality of Service 2781 The IEEE 802.11 WTP Quality of Service message element value is sent 2782 by the AC to the WTP to communicate quality of service configuration 2783 information. The QoS tag included in this message element are the 2784 default QoS values to be applied to packets received by the WTP from 2785 stations on a particular radio. Any tagging performed by the WTP 2786 MUST be directly applied to the packets receive from the station, as 2787 well as the CAPWAP tunnel, if the packets are tunneled to the AC. 2788 See Section 2.6 for more information. 2790 0 1 2 3 2791 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 2792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2793 | Radio ID |Tagging Policy | QoS Sub-Element ... 2794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2796 Type: 1045 for IEEE 802.11 WTP Quality of Service 2798 Length: 34 2800 Radio ID: The Radio Identifier, whose value is between one (1) and 2801 31, typically refers to some interface index on the WTP 2803 Tagging Policy: A bit field indicating how the WTP is to mark 2804 packets for QoS purposes. The required WTP behavior is defined in 2805 Section 2.6.1. The field has the following format: 2807 0 1 2 3 4 5 6 7 2808 +-+-+-+-+-+-+-+-+ 2809 |Rsvd |P|Q|D|O|I| 2810 +-+-+-+-+-+-+-+-+ 2812 Rsvd: A set of reserved bits for future use. All implementations 2813 complying with this protocol MUST set to zero any bits that are 2814 reserved in the version of the protocol supported by that 2815 implementation. Receivers MUST ignore all bits not defined for 2816 the version of the protocol they support. 2818 P: When set, the WTP is to employ the 802.1p QoS mechanism (see 2819 Section 2.6.1.1), and the WTP is to use the 'Q' bit. 2821 Q: When the 'P' bit is set, the 'Q' bit is used by the AC to 2822 communicate to the WTP how 802.1p QoS is to be enforced. 2823 Details on the behavior of the 'Q' bit is specified in 2824 Section 2.6.1.1. 2826 D: When set, the WTP is to employ the DSCP QoS mechanism (see 2827 Section 2.6.1.2), and the WTP is to use the 'O' and 'I' bits. 2829 O: When the 'D' bit is set, the 'O' bit is used by the AC to 2830 communicate to the WTP how DSCP QoS is to be enforced on the 2831 outer (tunneled) header. Details on the behavior of the 'O' 2832 bit is specified in Section 2.6.1.2. 2834 I: When the 'D' bit is set, the 'I' bit is used by the AC to 2835 communicate to the WTP how DSCP QoS is to be enforced on the 2836 station's packet (inner) header. Details on the behavior of 2837 the 'I' bit is specified in Section 2.6.1.2. 2839 QoS Sub-Element: The IEEE 802.11 WTP Quality of Service message 2840 element contains four QoS sub-elements, one for every QoS profile. 2841 The order of the QoS profiles are Voice, Video, Best Effort and 2842 Background. 2844 0 1 2 3 2845 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 2846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2847 | Queue Depth | CWMin | CWMax | 2848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2849 | CWMax | AIFS | Reserved|8021p|RSV| DSCP Tag | 2850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2852 Queue Depth: The number of packets that can be on the specific 2853 QoS transmit queue at any given time. 2855 CWMin: The Contention Window minimum (CWmin) value for the QoS 2856 transmit queue. The value of this field comes from the IEEE 2857 802.11 dot11EDCATableCWMin MIB element (see 2858 [IEEE.802-11.2007]). 2860 CWMax: The Contention Window maximum (CWmax) value for the QoS 2861 transmit queue. The value of this field comes from the IEEE 2862 802.11 dot11EDCATableCWMax MIB element (see 2863 [IEEE.802-11.2007]). 2865 AIFS: The Arbitration Inter Frame Spacing (AIFS) to use for the 2866 QoS transmit queue. The value of this field comes from the 2867 IEEE 802.11 dot11EDCATableAIFSN MIB element (see 2868 [IEEE.802-11.2007]). 2870 Reserved: All implementations complying with this protocol MUST 2871 set to zero any bits that are reserved in the version of the 2872 protocol supported by that implementation. Receivers MUST 2873 ignore all bits not defined for the version of the protocol 2874 they support. 2876 8021p: The three bit 802.1p priority value to use if packets are 2877 to be IEEE 802.1p tagged. This field is used only if the 'P' 2878 bit is set; otherwise, its contents MUST be ignored. 2880 RSV: All implementations complying with this protocol MUST set 2881 to zero any bits that are reserved in the version of the 2882 protocol supported by that implementation. Receivers MUST 2883 ignore all bits not defined for the version of the protocol 2884 they support. 2886 DSCP Tag: The 6 bit DSCP label to use if packets are eligible to 2887 be DSCP tagged, specifically an IPv4 or IPv6 packet (see 2888 [RFC2474]). This field is used only if the 'D' bit is set; 2889 otherwise, its contents MUST be ignored. 2891 6.23. IEEE 802.11 WTP Radio Configuration 2893 The IEEE 802.11 WTP WLAN Radio Configuration message element is used 2894 by the AC to configure a Radio on the WTP, and by the WTP to deliver 2895 its radio configuration to the AC. The message element value 2896 contains the following fields: 2898 0 1 2 3 2899 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 2900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2901 | Radio ID |Short Preamble| Num of BSSIDs | DTIM Period | 2902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2903 | BSSID | 2904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2905 | BSSID | Beacon Period | 2906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2907 | Country String | 2908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2910 Type: 1046 for IEEE 802.11 WTP WLAN Radio Configuration 2912 Length: 16 2913 Radio ID: An 8-bit value representing the radio to configure, whose 2914 value is between one (1) and 31. 2916 Short Preamble: An 8-bit value indicating whether short preamble is 2917 supported. The following enumerated values are currently 2918 supported: 2920 0 - Short preamble not supported. 2922 1 - Short preamble is supported. 2924 BSSID: The WLAN Radio's base MAC Address. 2926 Number of BSSIDs: This attribute contains the maximum number of 2927 BSSIDs supported by the WTP. This value restricts the number of 2928 logical networks supported by the WTP, and is between 1 and 16. 2930 DTIM Period: This attribute specifies the number of beacon 2931 intervals that elapse between transmission of Beacons frames 2932 containing a Traffic Indication Map (TIM) element whose Delivery 2933 Traffic Indication Message (DTIM) Count field is 0. This value is 2934 transmitted in the DTIM Period field of Beacon frames. The value 2935 of this field comes from the IEEE 802.11 dot11DTIMPeriod MIB 2936 element (see [IEEE.802-11.2007]). 2938 Beacon Period: This attribute specifies the number of Time Unit 2939 (TU) that a station uses for scheduling Beacon transmissions. 2940 This value is transmitted in Beacon and Probe Response frames. 2941 The value of this field comes from the IEEE 802.11 2942 dot11BeaconPeriod MIB element (see [IEEE.802-11.2007]). 2944 Country String: This attribute identifies the country in which the 2945 station is operating. The value of this field comes from the IEEE 2946 802.11 dot11CountryString MIB element (see [IEEE.802-11.2007]). 2947 Some regulatory domains do not allow WTPs to have user 2948 configurable country string, and require that it be a fixed value 2949 during the manufacturing process. Therefore, WTP vendors that 2950 wish to allow for the configuration of this field will need to 2951 validate this behavior during its radio certification process. 2952 Other WTP vendors may simply wish to treat this WTP configuration 2953 parameter as read-only. The country strings can be found in 2954 [ISO.3166-1]. 2956 The WTP and AC MAY ignore the value of this field, depending upon 2957 regulatory requirements, for example to avoid classification as a 2958 Software Defined Radio. When this field is used, the first two 2959 octets of this string is the two character country string as 2960 described in document [ISO.3166-1], and the third octet MUST 2961 either be a space, 'O', 'I' or X' as defined below. When the 2962 value of the third octet is 255 (HEX 0xff), the country string 2963 field is not used, and MUST be ignored. The following are the 2964 possible values for the third octet: 2966 1. an ASCII space character, if the regulations under which the 2967 station is operating encompass all environments in the country, 2969 2. an ASCII 'O' character, if the regulations under which the 2970 station is operating are for an outdoor environment only, or 2972 3. an ASCII 'I' character, if the regulations under which the 2973 station is operating are for an indoor environment only. 2975 4. an ASCII 'X' character, if the station is operating under a 2976 non-country entity. The first two octets of the non-country 2977 entity shall be two ASCII 'XX' characters. 2979 3. a HEX 0xff character means that the country string field is 2980 not used and MUST be ignored. 2982 Note that the last byte of the Country String MUST be set to NULL. 2984 6.24. IEEE 802.11 WTP Radio Fail Alarm Indication 2986 The IEEE 802.11 WTP Radio Fail Alarm Indication message element is 2987 sent by the WTP to the AC when it detects a radio failure. 2989 0 1 2 3 2990 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 2991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2992 | Radio ID | Type | Status | Pad | 2993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2995 Type: 1047 for IEEE 802.11 WTP Radio Fail Alarm Indication 2997 Length: 4 2999 Radio ID: The Radio Identifier, whose value is between one (1) and 3000 31, typically refers to some interface index on the WTP 3002 Type: The type of radio failure detected. The following enumerated 3003 values are supported: 3005 1 - Receiver 3006 2 - Transmitter 3008 Status: An 8-bit boolean indicating whether the radio failure is 3009 being reported or cleared. A value of zero is used to clear the 3010 event, while a value of one is used to report the event. 3012 Pad: All implementations complying with version zero of this 3013 protocol MUST set these bits to zero. Receivers MUST ignore all 3014 bits not defined for the version of the protocol they support. 3016 6.25. IEEE 802.11 WTP Radio Information 3018 The IEEE 802.11 WTP Radio Information message element is used to 3019 communicate the radio information for each IEEE 802.11 radio in the 3020 WTP. The Discovery Request message, Primary Discovery Request 3021 message and Join Request message MUST include one such message 3022 element per radio in the WTP. The Radio-Type field is used by the AC 3023 in order to determine which IEEE 802.11 technology specific binding 3024 is to be used with the WTP. 3026 The message element contains two fields, as shown below. 3028 0 1 2 3 3029 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 3030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3031 | Radio ID | Radio Type | 3032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3033 | Radio Type | 3034 +-+-+-+-+-+-+-+-+ 3036 Type: 1048 for IEEE 802.11 WTP Radio Information 3038 Length: 5 3040 Radio ID: The Radio Identifier, whose value is between one (1) and 3041 31, which typically refers to an interface index on the WTP 3043 Radio Type: The type of radio present. Note this is a bit field 3044 which is used to specify support for more than a single type of 3045 PHY/MAC. The field has the following format: 3047 0 1 2 3 4 5 6 7 3048 +-+-+-+-+-+-+-+-+ 3049 |Reservd|N|G|A|B| 3050 +-+-+-+-+-+-+-+-+ 3052 Reservd: A set of reserved bits for future use. All 3053 implementations complying with this protocol MUST set to zero 3054 any bits that are reserved in the version of the protocol 3055 supported by that implementation. Receivers MUST ignore all 3056 bits not defined for the version of the protocol they support. 3058 N: An IEEE 802.11n radio. 3060 G: An IEEE 802.11g radio. 3062 A: An IEEE 802.11a radio. 3064 B: An IEEE 802.11b radio. 3066 7. IEEE 802.11 Binding WTP Saved Variables 3068 This section contains the IEEE 802.11 binding specific variables that 3069 SHOULD be saved in non-volatile memory on the WTP. 3071 7.1. IEEE80211AntennaInfo 3073 The WTP per radio antenna configuration, defined in Section 6.2. 3075 7.2. IEEE80211DSControl 3077 The WTP per radio Direct Sequence Control configuration, defined in 3078 Section 6.5. 3080 7.3. IEEE80211MACOperation 3082 The WTP per radio MAC Operation configuration, defined in 3083 Section 6.7. 3085 7.4. IEEE80211OFDMControl 3087 The WTP per radio OFDM MAC Operation configuration, defined in 3088 Section 6.10. 3090 7.5. IEEE80211Rateset 3092 The WTP per radio Basic Rate Set configuration, defined in 3093 Section 6.11. 3095 7.6. IEEE80211TxPower 3097 The WTP per radio Transmit Power configuration, defined in 3098 Section 6.18. 3100 7.7. IEEE80211QoS 3102 The WTP per radio Quality of Service configuration, defined in 3103 Section 6.22. 3105 7.8. IEEE80211RadioConfig 3107 The WTP per radio Radio Configuration, defined in Section 6.23. 3109 8. Technology Specific Message Element Values 3111 This section lists IEEE 802.11 specific values for the generic CAPWAP 3112 message elements which include fields whose values are technology 3113 specific. 3115 8.1. WTP Descriptor Message Element, Encryption Capabilities Field: 3117 This specification defines two new bits for the WTP Descriptor's 3118 Encryption Capabilities field, as defined in 3119 [I-D.ietf-capwap-protocol-specification]. Note that only the bits 3120 defined in this specification are described below. WEP is not 3121 explicitely advertised as a WTP capability since all WTPs are 3122 expected to support the encryption cipher. The format of the 3123 Encryption Capabilities Field is: 3125 1 3126 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3128 | |A|T| | 3129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3131 A: WTP supports AES-CCMP, as defined in [IEEE.802-11.2007]. 3133 T: WTP supports TKIP and Michael, as defined in [IEEE.802-11.2007] 3134 and [WPA], respectively. 3136 9. Security Considerations 3138 This section describes security considerations for using IEEE 802.11 3139 with the CAPWAP protocol. A complete threat analysis of the CAPWAP 3140 protocol can also be found in [I-D.ietf-capwap-threat-analysis] 3142 9.1. IEEE 802.11 Security 3144 When used with an IEEE 802.11 infrastructure with WEP encryption, the 3145 CAPWAP protocol does not add any new vulnerabilities. Derived 3146 session keys between the STA and WTP can be compromised, resulting in 3147 many well-documented attacks. Implementers SHOULD discourage the use 3148 of WEP and encourage use of technically sound cryptographic solutions 3149 such as those in an IEEE 802.11 RSN. 3151 STA authentication is performed using IEEE 802.lX, and consequently 3152 EAP. Implementers SHOULD use EAP methods meeting the requirements 3153 specified [RFC4017]. 3155 When used with IEEE 802.11 RSN security, the CAPWAP protocol may 3156 introduce new vulnerabilities, depending on whether the link security 3157 (packet encryption and integrity verification) is provided by the WTP 3158 or the AC. When the link security function is provided by the AC, no 3159 new security concerns are introduced. 3161 However, when the WTP provides link security, a new vulnerability 3162 will exist when the following conditions are true: 3164 o The client is not the first to associate to the WTP/ESSID (i.e. 3165 other clients are associated), and a GTK already exists 3167 o traffic has been broadcast under the existing GTK 3169 Under these circumstances, the receive sequence counter (KeyRSC) 3170 associated with the GTK is non-zero, but because the AC anchors the 3171 4-way handshake with the client, the exact value of the KeyRSC is not 3172 known when the AC constructs the message containing the GTK. The 3173 client will update its Key RSC value to the current valid KeyRSC upon 3174 receipt of a valid multicast/broadcast message, but prior to this, 3175 previous multicast/broadcast traffic which was secured with the 3176 existing GTK may be replayed, and the client will accept this traffic 3177 as valid. 3179 Typically, busy networks will produce numerous multicast or broadcast 3180 frames per second, so the window of opportunity with respect to such 3181 replay is expected to be very small. In most conditions, it is 3182 expected that replayed frames could be detected (and logged) by the 3183 WTP. 3185 The only way to completely close this window is to provide the exact 3186 KeyRSC value in message 3 of the 4-way handshake; any other approach 3187 simply narrows the window to varying degrees. Given the low relative 3188 threat level this presents, the additional complexity introduced by 3189 providing the exact KeyRSC value is not warranted. That is, this 3190 specification provides for a calculated risk in this regard. 3192 The AC SHOULD use an RSC of 0 when computing message-3 of the 4-way 3193 802.11i handshake, unless the AC has knowledge of a more optimal RSC 3194 value to use. Mechanisms for determining a more optimal RSC value 3195 are outside the scope of this specification. 3197 10. IANA Considerations 3199 This section details the actions to be taken by IANA during the 3200 publication of the specification. There are numerous registries that 3201 need to be created, and the contents, document action (see [RFC5226], 3202 and registry format are all included below. Note that in cases where 3203 bit fields are referred to, the bit numbering is left to right, where 3204 the leftmost bit is labelled as bit zero (0). 3206 10.1. CAPWAP Wireless Binding Identifier 3208 This specification requires a value assigned from the Wireless 3209 Binding Identifier namespace, defined in 3210 [I-D.ietf-capwap-protocol-specification]. The value assigned is to 3211 be added to Section 2.1. The value of one (1)is highly recommended, 3212 as it is used in implementations. 3214 10.2. CAPWAP IEEE 802.11 Message Types 3216 This document creates a new sub-registry to the existing CAPWAP 3217 Message Type registry, which is defined in 3218 [I-D.ietf-capwap-protocol-specification]. 3220 IANA will create and maintain the CAPWAP IEEE 802.11 Message Types 3221 sub-registry for all message types whose Enterprise Number is set to 3222 13277. The namespace is 8 bits (3398912-3399167), where the value 3223 3398912 is reserved and must not be assigned. The values 3398913 and 3224 3398914 are allocated in this specification, and can be found in 3225 Section 3. Any new assignments of a CAPWAP IEEE 802.11 Message Type, 3226 whose Enterprise Number is set to 13277) requires a Expert Review. 3227 The format of the registry to be maintained by IANA has the following 3228 format: 3230 CAPWAP IEEE 802.11 Message Type Reference 3231 Control Message Value 3233 10.3. CAPWAP Message Element Type 3235 This specification defines new values to be registered to the 3236 existing CAPWAP Message Element Type registry, defined in 3237 [I-D.ietf-capwap-protocol-specification]. The values used in this 3238 document, 1024 through 1048, as listed in Figure 8 are recommended as 3239 implementations already exist that make use of these values. 3241 10.4. IEEE 802.11 Key Status 3243 The Key Status field in the IEEE 802.11 Add WLAN message element (see 3244 Section 6.1) and IEEE 802.11 Update WLAN message element (see 3245 Section 6.21) is used to provide information about the status of the 3246 keying exchange. This document defines four values, and the 3247 remaining values are controlled and maintained by IANA and requires a 3248 Expert Review. 3250 10.5. IEEE 802.11 QoS 3252 The QoS field in the IEEE 802.11 Add WLAN message element (see 3253 Section 6.1) is used to configure a QoS policy for the WLAN. The 3254 namespace is 8 bits (0-255), where the values zero (0) through three 3255 (3) are allocated in this specification, and can be found in 3256 Section 6.1. This namespace is managed by IANA and assignments 3257 require a Expert Review. IANA will create the IEEE 802.11 QoS 3258 registry, whose format is: 3260 IEEE 802.11 QoS Type Value Reference 3262 10.6. IEEE 802.11 Auth Type 3264 The Auth Type field in the IEEE 802.11 Add WLAN message element (see 3265 Section 6.1) is 8 bits and is used to configure the IEEE 802.11 3266 authentication policy for the WLAN. The namespace is 8 bits (0-255), 3267 where the values zero (0) and one (1) are allocated in this 3268 specification, and can be found in Section 6.1. This namespace is 3269 managed by IANA and assignments require a Expert Review. IANA will 3270 create the IEEE 802.11 Auth Type registry, whose format is: 3272 IEEE 802.11 Auth Type Type Value Reference 3274 10.7. IEEE 802.11 Antenna Combiner 3276 The Combiner field in the IEEE 802.11 Antenna message element (see 3277 Section 6.2) is used to provide information about the WTP's antennas. 3278 The namespace is 8 bits (0-255), where the values zero (0) and four 3279 (4) are allocated in this specification, and can be found in 3280 Section 6.2. This namespace is managed by IANA and assignments 3281 require a Expert Review. IANA will create the IEEE 802.11 Antenna 3282 Combiner registry, whose format is: 3284 IEEE 802.11 Antenna Combiner Type Value Reference 3286 10.8. IEEE 802.11 Antenna Selection 3288 The Antenna Selection field in the IEEE 802.11 Antenna message 3289 element (see Section 6.2) is used to provide information about the 3290 WTP's antennas. The namespace is 8 bits (0-255), where the values 3291 zero (0) is reserved and used and the values one (1) through two (2) 3292 are allocated in this specification, and can be found in Section 6.2. 3294 This namespace is managed by IANA and assignments require a Expert 3295 Review. IANA will create the IEEE 802.11 Antenna Selection registry, 3296 whose format is: 3298 IEEE 802.11 Antenna Selection Type Value Reference 3300 10.9. IEEE 802.11 Session Key Flags 3302 The Flags field in the IEEE 802.11 Station Session Key message 3303 element (see Section 6.15) is 16 bits and is used to configure the 3304 session key association with the mobile device. This specification 3305 defines bits zero (0) and one (1), while bits two (2) through fifteen 3306 are reserved. The reserved bits are managed by IANA and whose 3307 assignment requires a Expert Review. IANA will create the IEEE 3308 802.11 Session Key Flags registry, whose format is: 3310 IEEE 802.11 Station Session Key Bit Position Reference 3312 10.10. IEEE 802.11 Tagging Policy 3314 The Tagging Policy field in the IEEE 802.11 WTP Quality of Service 3315 message element (see Section 6.22) is 8 bits and is used to specify 3316 how the CAPWAP Data Channel packets are to be tagged. This 3317 specification defines bits three (3) through seven (7). The 3318 remaining bits are managed by IANA and whose assignment requires a 3319 Expert Review. IANA will create the IEEE 802.11 Tagging Policy 3320 registry, whose format is: 3322 IEEE 802.11 Tagging Policy Bit Position Reference 3324 10.11. IEEE 802.11 WTP Radio Fail 3326 The Type field in the IEEE 802.11 WTP Radio Fail Alarm Indication 3327 message element (see Section 6.24) is used to provide information on 3328 why a WTP's radio has failed. The namespace is 8 bits (0-255), where 3329 the values zero (0) is reserved and unused, while the values one (1) 3330 and two (2) are allocated in this specification, and can be found in 3331 Section 6.24. This namespace is managed by IANA and assignments 3332 require a Expert Review. IANA will create the IEEE 802.11 WTP Radio 3333 Fail registry, whose format is: 3335 IEEE 802.11 WTP Radio Fail Type Value Reference 3337 10.12. IEEE 802.11 WTP Radio Type 3339 The Radio Type field in the IEEE 802.11 WTP Radio Information message 3340 element (see Section 6.25) is 8 bits and is used to provide 3341 information about the WTP's radio type. This specification defines 3342 bits four (4) through seven (7). The remaining bits are managed by 3343 IANA and whose assignment requires a Expert Review. IANA will create 3344 the IEEE 802.11 WTP Radio Type registry, whose format is: 3346 IEEE 802.11 WTP Radio Type Bit Position Reference 3348 10.13. WTP Encryption Capabilities 3350 The WTP Encryption Capabilities field in the WTP Descriptor message 3351 element (see Section 8.1) is 16 bits and is used by the WTP to 3352 indicate its IEEE 802.11 encryption capabilities. This specification 3353 defines bits 12 and 13. The reserved bits are managed by IANA and 3354 whose assignment requires a Expert Review. IANA will create the IEEE 3355 802.11 Encryption Capabilities registry, whose format is: 3357 IEEE 802.11 Encryption Capabilities Bit Position Reference 3359 11. Acknowledgments 3361 The following individuals are acknowledged for their contributions to 3362 this binding specification: Puneet Agarwal, Charles Clancy, Pasi 3363 Eronen, Saravanan Govindan, Scott Kelly, Peter Nilsson, Bob O'Hara, 3364 David Perkins, Margaret Wasserman and Yong Zhang. 3366 12. References 3368 12.1. Normative References 3370 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3371 Requirement Levels", BCP 14, RFC 2119, March 1997. 3373 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 3374 "Definition of the Differentiated Services Field (DS 3375 Field) in the IPv4 and IPv6 Headers", RFC 2474, 3376 December 1998. 3378 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 3379 "Assured Forwarding PHB Group", RFC 2597, June 1999. 3381 [RFC2598] Jacobson, V., Nichols, K., and K. Poduri, "An Expedited 3382 Forwarding PHB", RFC 2598, June 1999. 3384 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 3385 of Explicit Congestion Notification (ECN) to IP", 3386 RFC 3168, September 2001. 3388 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 3389 Levkowetz, "Extensible Authentication Protocol (EAP)", 3390 RFC 3748, June 2004. 3392 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3393 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 3394 May 2008. 3396 [FIPS.197.2001] 3397 National Institute of Standards and Technology, "Advanced 3398 Encryption Standard (AES)", FIPS PUB 197, November 2001, < 3399 http://csrc.nist.gov/publications/fips/fips197/ 3400 fips-197.pdf>. 3402 [ISO.3166-1] 3403 ISO Standard, "International Organization for 3404 Standardization, Codes for the representation of names of 3405 countries and their subdivisions - Part 1: Country codes", 3406 ISO Standard 3166-1:1997, 1997. 3408 [IEEE.802-11.2007] 3409 "Information technology - Telecommunications and 3410 information exchange between systems - Local and 3411 metropolitan area networks - Specific requirements - Part 3412 11: Wireless LAN Medium Access Control (MAC) and Physical 3413 Layer (PHY) specifications", IEEE Standard 802.11, 2007, < 3414 http://standards.ieee.org/getieee802/download/ 3415 802.11-2007.pdf>. 3417 [I-D.ietf-capwap-protocol-specification] 3418 Montemurro, M., Stanley, D., and P. Calhoun, "CAPWAP 3419 Protocol Specification", 3420 draft-ietf-capwap-protocol-specification-14 (work in 3421 progress), October 2008. 3423 [IEEE.802-1X.2004] 3424 "Information technology - Telecommunications and 3425 information exchange between systems - Local and 3426 metropolitan area networks - Specific requirements - Port- 3427 Based Network Access Control", IEEE Standard 802.1X, 2004, 3428 . 3431 [IEEE.802-1Q.2005] 3432 "Information technology - Telecommunications and 3433 information exchange between systems - Local and 3434 metropolitan area networks - Specific requirements - 3435 Virtual Bridged Local Area Networks", IEEE Standard 3436 802.1Q, 2005, . 3439 12.2. Informational References 3441 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 3442 Authentication Protocol (EAP) Method Requirements for 3443 Wireless LANs", RFC 4017, March 2005. 3445 [RFC4118] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy 3446 for Control and Provisioning of Wireless Access Points 3447 (CAPWAP)", RFC 4118, June 2005. 3449 [I-D.ietf-capwap-threat-analysis] 3450 Kelly, S. and C. Clancy, "CAPWAP Threat Analysis for IEEE 3451 802.11 Deployments", draft-ietf-capwap-threat-analysis-04 3452 (work in progress), September 2008. 3454 [WPA] "Deploying Wi-Fi Protected Access (WPA) and WPA2 in the 3455 Enterprise", March 2005, . 3457 [WMM] "Support for Multimedia Applications with Quality of 3458 Service in WiFi Networks)", September 2004, . 3461 Editors' Addresses 3463 Pat R. Calhoun 3464 Cisco Systems, Inc. 3465 170 West Tasman Drive 3466 San Jose, CA 95134 3468 Phone: +1 408-902-3240 3469 Email: pcalhoun@cisco.com 3471 Michael P. Montemurro 3472 Research In Motion 3473 5090 Commerce Blvd 3474 Mississauga, ON L4W 5M4 3475 Canada 3477 Phone: +1 905-629-4746 x4999 3478 Email: mmontemurro@rim.com 3480 Dorothy Stanley 3481 Aruba Networks 3482 1322 Crossman Ave 3483 Sunnyvale, CA 94089 3485 Phone: +1 630-363-1389 3486 Email: dstanley@arubanetworks.com 3488 Full Copyright Statement 3490 Copyright (C) The IETF Trust (2008). 3492 This document is subject to the rights, licenses and restrictions 3493 contained in BCP 78, and except as set forth therein, the authors 3494 retain all their rights. 3496 This document and the information contained herein are provided on an 3497 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3498 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 3499 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 3500 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3501 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3502 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3504 Intellectual Property 3506 The IETF takes no position regarding the validity or scope of any 3507 Intellectual Property Rights or other rights that might be claimed to 3508 pertain to the implementation or use of the technology described in 3509 this document or the extent to which any license under such rights 3510 might or might not be available; nor does it represent that it has 3511 made any independent effort to identify any such rights. Information 3512 on the procedures with respect to rights in RFC documents can be 3513 found in BCP 78 and BCP 79. 3515 Copies of IPR disclosures made to the IETF Secretariat and any 3516 assurances of licenses to be made available, or the result of an 3517 attempt made to obtain a general license or permission for the use of 3518 such proprietary rights by implementers or users of this 3519 specification can be obtained from the IETF on-line IPR repository at 3520 http://www.ietf.org/ipr. 3522 The IETF invites any interested party to bring to its attention any 3523 copyrights, patents or patent applications, or other proprietary 3524 rights that may cover technology that may be required to implement 3525 this standard. Please address the information to the IETF at 3526 ietf-ipr@ietf.org.