idnits 2.17.1 draft-ietf-capwap-protocol-binding-ieee80211-09.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 3373. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3384. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3391. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3397. 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 : ---------------------------------------------------------------------------- No issues found here. 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 (September 19, 2008) is 5698 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 3257, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 2598 (Obsoleted by RFC 3246) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.802-11.2007' == Outdated reference: A later version (-15) exists of draft-ietf-capwap-protocol-specification-12 -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.802-1X.2004' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.802-1Q.2005' Summary: 3 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: March 23, 2009 Research In Motion 6 D. Stanley, Editor 7 Aruba Networks 8 September 19, 2008 10 CAPWAP Protocol Binding for IEEE 802.11 11 draft-ietf-capwap-protocol-binding-ieee80211-09 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 March 23, 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 . . . . . . . . . . . . . . . . . . . . 15 64 2.4. Group Key Refresh . . . . . . . . . . . . . . . . . . . . 16 65 2.5. BSSID to WLAN ID Mapping . . . . . . . . . . . . . . . . 17 66 2.6. CAPWAP Data Channel QoS Behavior . . . . . . . . . . . . 17 67 2.6.1. IEEE 802.11 Data Frames . . . . . . . . . . . . . . . 17 68 2.6.2. IEEE 802.11 MAC Management Messages . . . . . . . . . 20 69 2.7. Run State Operation . . . . . . . . . . . . . . . . . . . 21 70 3. IEEE 802.11 Specific CAPWAP Control Messages . . . . . . . . . 22 71 3.1. IEEE 802.11 WLAN Configuration Request . . . . . . . . . 22 72 3.2. IEEE 802.11 WLAN Configuration Response . . . . . . . . . 23 73 4. CAPWAP Data Message Bindings . . . . . . . . . . . . . . . . . 24 74 5. CAPWAP Control Message bindings . . . . . . . . . . . . . . . 26 75 5.1. Discovery Request Message . . . . . . . . . . . . . . . . 26 76 5.2. Discovery Response Message . . . . . . . . . . . . . . . 26 77 5.3. Primary Discovery Request Message . . . . . . . . . . . . 26 78 5.4. Primary Discovery Response Message . . . . . . . . . . . 26 79 5.5. Join Request Message . . . . . . . . . . . . . . . . . . 26 80 5.6. Join Response Message . . . . . . . . . . . . . . . . . . 27 81 5.7. Configuration Status Message . . . . . . . . . . . . . . 27 82 5.8. Configuration Status Response Message . . . . . . . . . . 27 83 5.9. Configuration Update Request Message . . . . . . . . . . 28 84 5.10. Station Configuration Request . . . . . . . . . . . . . . 29 85 5.11. Change State Event Request . . . . . . . . . . . . . . . 29 86 5.12. WTP Event Request . . . . . . . . . . . . . . . . . . . . 29 87 6. IEEE 802.11 Message Element Definitions . . . . . . . . . . . 30 88 6.1. IEEE 802.11 Add WLAN . . . . . . . . . . . . . . . . . . 30 89 6.2. IEEE 802.11 Antenna . . . . . . . . . . . . . . . . . . . 36 90 6.3. IEEE 802.11 Assigned WTP BSSID . . . . . . . . . . . . . 37 91 6.4. IEEE 802.11 Delete WLAN . . . . . . . . . . . . . . . . . 38 92 6.5. IEEE 802.11 Direct Sequence Control . . . . . . . . . . . 38 93 6.6. IEEE 802.11 Information Element . . . . . . . . . . . . . 39 94 6.7. IEEE 802.11 MAC Operation . . . . . . . . . . . . . . . . 40 95 6.8. IEEE 802.11 MIC Countermeasures . . . . . . . . . . . . . 42 96 6.9. IEEE 802.11 Multi-Domain Capability . . . . . . . . . . . 43 97 6.10. IEEE 802.11 OFDM Control . . . . . . . . . . . . . . . . 44 98 6.11. IEEE 802.11 Rate Set . . . . . . . . . . . . . . . . . . 45 99 6.12. IEEE 802.11 RSNA Error Report From Station . . . . . . . 45 100 6.13. IEEE 802.11 Station . . . . . . . . . . . . . . . . . . . 47 101 6.14. IEEE 802.11 Station QoS Profile . . . . . . . . . . . . . 48 102 6.15. IEEE 802.11 Station Session Key . . . . . . . . . . . . . 49 103 6.16. IEEE 802.11 Statistics . . . . . . . . . . . . . . . . . 51 104 6.17. IEEE 802.11 Supported Rates . . . . . . . . . . . . . . . 55 105 6.18. IEEE 802.11 Tx Power . . . . . . . . . . . . . . . . . . 55 106 6.19. IEEE 802.11 Tx Power Level . . . . . . . . . . . . . . . 56 107 6.20. IEEE 802.11 Update Station QoS . . . . . . . . . . . . . 56 108 6.21. IEEE 802.11 Update WLAN . . . . . . . . . . . . . . . . . 58 109 6.22. IEEE 802.11 WTP Quality of Service . . . . . . . . . . . 61 110 6.23. IEEE 802.11 WTP Radio Configuration . . . . . . . . . . . 64 111 6.24. IEEE 802.11 WTP Radio Fail Alarm Indication . . . . . . . 66 112 6.25. IEEE 802.11 WTP Radio Information . . . . . . . . . . . . 66 113 7. IEEE 802.11 Binding WTP Saved Variables . . . . . . . . . . . 68 114 7.1. IEEE80211AntennaInfo . . . . . . . . . . . . . . . . . . 68 115 7.2. IEEE80211DSControl . . . . . . . . . . . . . . . . . . . 68 116 7.3. IEEE80211MACOperation . . . . . . . . . . . . . . . . . . 68 117 7.4. IEEE80211OFDMControl . . . . . . . . . . . . . . . . . . 68 118 7.5. IEEE80211Rateset . . . . . . . . . . . . . . . . . . . . 68 119 7.6. IEEE80211TxPower . . . . . . . . . . . . . . . . . . . . 68 120 7.7. IEEE80211QoS . . . . . . . . . . . . . . . . . . . . . . 68 121 7.8. IEEE80211RadioConfig . . . . . . . . . . . . . . . . . . 68 122 8. Technology Specific Message Element Values . . . . . . . . . . 69 123 8.1. WTP Descriptor Message Element, Encryption 124 Capabilities Field: . . . . . . . . . . . . . . . . . . . 69 125 9. Security Considerations . . . . . . . . . . . . . . . . . . . 70 126 9.1. IEEE 802.11 Security . . . . . . . . . . . . . . . . . . 70 127 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72 128 10.1. CAPWAP Wireless Binding Identifier . . . . . . . . . . . 72 129 10.2. CAPWAP IEEE 802.11 Message Types . . . . . . . . . . . . 72 130 10.3. CAPWAP Message Element Type . . . . . . . . . . . . . . . 72 131 10.4. IEEE 802.11 Key Status . . . . . . . . . . . . . . . . . 72 132 10.5. IEEE 802.11 QoS . . . . . . . . . . . . . . . . . . . . . 73 133 10.6. IEEE 802.11 Auth Type . . . . . . . . . . . . . . . . . . 73 134 10.7. IEEE 802.11 Antenna Combiner . . . . . . . . . . . . . . 73 135 10.8. IEEE 802.11 Antenna Selection . . . . . . . . . . . . . . 73 136 10.9. IEEE 802.11 Session Key Flags . . . . . . . . . . . . . . 74 137 10.10. IEEE 802.11 Tagging Policy . . . . . . . . . . . . . . . 74 138 10.11. IEEE 802.11 WTP Radio Fail . . . . . . . . . . . . . . . 74 139 10.12. IEEE 802.11 WTP Radio Type . . . . . . . . . . . . . . . 74 140 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 76 141 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 77 142 12.1. Normative References . . . . . . . . . . . . . . . . . . 77 143 12.2. Informational References . . . . . . . . . . . . . . . . 78 144 Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 79 145 Intellectual Property and Copyright Statements . . . . . . . . . . 80 147 1. Introduction 149 The CAPWAP protocol [I-D.ietf-capwap-protocol-specification] defines 150 an extensible protocol to allow an Access Controller to manage 151 wireless agnostic Wireless Termination Points. The CAPWAP protocol 152 itself does not include any specific wireless technologies, but 153 instead relies on binding specification to extend the technology to a 154 particular wireless technology. 156 This specification defines the Control And Provisioning of Wireless 157 Access Points (CAPWAP) Protocol Binding Specification for use with 158 the IEEE 802.11 Wireless Local Area Network protocol. Use of CAPWAP 159 control message fields, new control messages and message elements are 160 defined. The minimum required definitions for a binding-specific 161 Statistics message element, Station message element, and WTP Radio 162 Information message element are included. 164 Note that this binding only supports the IEEE 802.11-2007 165 specification. Of note, this binding does not support the ad-hoc 166 network mode defined in the IEEE 802.11-2007 standard. This 167 specification also does not cover the use of data frames with the 168 four-address format, commonly referred to as Wireless Bridges, whose 169 use is not specified in the IEEE 802.11-2007 standard. New protocol 170 specifications published outside of this document (e.g., IEEE 171 802.11n, IEEE 802.11r) are therefore not supported through this 172 binding, and must be addressed either through a separate CAPWAP 173 binding, or an update to this binding. 175 In order to address immediate market needs for standards still being 176 developed by the IEEE 802.11 standards body, the WiFi Alliance 177 created interim pseudo-standards specifications. Two such 178 specifications are widely used in the industry, namely the WiFi 179 Protect Access [WPA] and the WiFi MultiMedia [WMM] specifications. 180 Given their widespread adoption, this CAPWAP binding requires the use 181 of these two specifications. 183 1.1. Goals 185 The goals of this CAPWAP protocol binding are to make the 186 capabilities of the CAPWAP protocol available for use in conjunction 187 with IEEE 802.11 wireless networks. The capabilities to be made 188 available can be summarized as: 190 1. To centralize the authentication and policy enforcement functions 191 for an IEEE 802.11 wireless network. The AC may also provide 192 centralized bridging, forwarding, and encryption of user traffic. 193 Centralization of these functions will enable reduced cost and 194 higher efficiency by applying the capabilities of network 195 processing silicon to the wireless network, as in wired LANs. 197 2. To enable shifting of the higher level protocol processing from 198 the WTP. This leaves the time-critical applications of wireless 199 control and access in the WTP, making efficient use of the 200 computing power available in WTPs which are subject to severe cost 201 pressure. 203 The CAPWAP protocol binding extensions defined herein apply solely to 204 the interface between the WTP and the AC. Inter-AC and station-to-AC 205 communication are strictly outside the scope of this document. 207 1.2. Conventions used in this document 209 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 210 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 211 document are to be interpreted as described in RFC 2119 [RFC2119]. 213 1.3. Terminology 215 This section contains definitions for terms used frequently 216 throughout this document. However, many additional definitions can 217 be found in [IEEE.802-11.2007]. 219 Access Controller (AC): The network entity that provides WTP access 220 to the network infrastructure in the data plane, control plane, 221 management plane, or a combination therein. 223 Basic Service Set (BSS): A set of stations controlled by a single 224 coordination function. 226 Distribution: The service that, by using association information, 227 delivers medium access control (MAC) service data units (MSDUs) 228 within the distribution system (DS). 230 Distribution System Service (DSS): The set of services provided by 231 the distribution system (DS) that enable the medium access control 232 (MAC) layer to transport MAC service data units (MSDUs) between 233 stations that are not in direct communication with each other over a 234 single instance of the wireless medium (WM). These services include 235 the transport of MSDUs between the access points (APs) of basic 236 service sets (BSSs) within an extended service set (ESS), transport 237 of MSDUs between portals and BSSs within an ESS, and transport of 238 MSDUs between stations in the same BSS in cases where the MSDU has a 239 multicast or broadcast destination address, or where the destination 240 is an individual address, but the station sending the MSDU chooses to 241 involve the DSS. DSSs are provided between pairs of IEEE 802.11 242 MACs. 244 Integration: The service that enables delivery of medium access 245 control (MAC) service data units (MSDUs) between the distribution 246 system (DS) and an existing, non-IEEE 802.11 local area network (via 247 a portal). 249 Station (STA): A device that contains an IEEE 802.11 conformant 250 medium access control (MAC) and physical layer (PHY) interface to the 251 wireless medium (WM). 253 Portal: The logical point at which medium access control (MAC) 254 service data units (MSDUs) from a non-IEEE 802.11 local area network 255 (LAN) enter the distribution system (DS) of an extended service set 256 (ESS). 258 WLAN: In this document, WLAN refers to a logical component 259 instantiated on a WTP device. A single physical WTP may operate a 260 number of WLANs. Each Basic Service Set Identifier (BSSID) and its 261 constituent wireless terminal radios is denoted as a distinct WLAN on 262 a physical WTP. 264 Wireless Termination Point (WTP): The physical or network entity that 265 contains an IEEE 802.11 RF antenna and wireless PHY to transmit and 266 receive station traffic for wireless access networks. 268 2. IEEE 802.11 Binding 270 This section describes use of the CAPWAP protocol with the IEEE 271 802.11 Wireless Local Area Network protocol, including Local and 272 Split MAC operation, Group Key Refresh, Basic Service Set 273 Identification (BSSID) to WLAN Mapping, IEEE 802.11 MAC management 274 frame Quality of Service tagging and Run State operation. 276 2.1. CAPWAP Wireless Binding Identifier 278 The CAPWAP Header, defined in section 4.3 of 279 [I-D.ietf-capwap-protocol-specification] requires that all CAPWAP 280 binding specifications have a Wireless Binding Identifier (WBID) 281 assigned. This document, which defines the IEEE 802.11 binding, uses 282 the the value one (1). 284 2.2. Split MAC and Local MAC Functionality 286 The CAPWAP protocol, when used with IEEE 802.11 devices, requires 287 specific behavior from the WTP and the AC to support the required 288 IEEE 802.11 protocol functions. 290 For both the Split and Local MAC approaches, the CAPWAP functions, as 291 defined in the taxonomy specification [RFC4118], reside in the AC. 293 To provide system component interoperability, the WTP and AC MUST 294 support 802.11 encryption/decryption at the WTP. The WTP and AC MAY 295 support 802.11 encryption/decryption at the AC. 297 2.2.1. Split MAC 299 This section shows the division of labor between the WTP and the AC 300 in a Split MAC architecture. Figure 1 shows the separation of 301 functionality between CAPWAP components. 303 Function Location 304 Distribution Service AC 305 Integration Service AC 306 Beacon Generation WTP 307 Probe Response Generation WTP 308 Power Mgmt/Packet Buffering WTP 309 Fragmentation/Defragmentation WTP/AC 310 Assoc/Disassoc/Reassoc AC 312 IEEE 802.11 QOS 313 Classifying AC 314 Scheduling WTP/AC 315 Queuing WTP 317 IEEE 802.11 RSN 318 IEEE 802.1X/EAP AC 319 RSNA Key Management AC 320 IEEE 802.11 Encryption/Decryption WTP/AC 322 Figure 1: Mapping of 802.11 Functions for Split MAC Architecture 324 In a Split MAC Architecture, the Distribution and Integration 325 services reside on the AC, and therefore all user data is tunneled 326 between the WTP and the AC. As noted above, all real-time IEEE 327 802.11 services, including the Beacon and Probe Response frames, are 328 handled on the WTP. 330 All remaining IEEE 802.11 MAC management frames are supported on the 331 AC, including the Association Request frame which allows the AC to be 332 involved in the access policy enforcement portion of the IEEE 802.11 333 protocol. The IEEE 802.1X [IEEE.802-1X.2004], Extensible 334 Authentication Protocol (EAP) [RFC3748] and IEEE Robust Security 335 Network Association (RSNA) Key Management [IEEE.802-11.2007] 336 functions are also located on the AC. This implies that the AAA 337 client also resides on the AC. 339 While the admission control component of IEEE 802.11 resides on the 340 AC, the real time scheduling and queuing functions are on the WTP. 341 Note that this does not prevent the AC from providing additional 342 policy and scheduling functionality. 344 Note that in the following figure, the use of '( - )' indicates that 345 processing of the frames is done on the WTP. 347 Client WTP AC 349 Beacon 350 <----------------------------- 351 Probe Request 352 ----------------------------( - )-------------------------> 353 Probe Response 354 <----------------------------- 355 802.11 AUTH/Association 356 <---------------------------------------------------------> 357 Station Configuration Request 358 [Add Station (Station Message 359 Elements)] 360 <--------------------------> 361 802.1X Authentication & 802.11 Key Exchange 362 <---------------------------------------------------------> 363 Station Configuration Request 364 [Add Station (AES-CCMP, 365 PTK=x)] 366 <--------------------------> 367 802.11 Action Frames 368 <---------------------------------------------------------> 369 802.11 DATA (1) 370 <---------------------------( - )-------------------------> 372 Figure 2: Split MAC Message Flow 374 Figure 2 provides an illustration of the division of labor in a Split 375 MAC architecture. In this example, a WLAN has been created that is 376 configured for IEEE 802.11, using 802.1X based end user 377 authentication and AES-CCMP link layer encryption (Counter mode with 378 Cipher-block chaining Message authentication code Protocol, see 379 [FIPS.197.2001]). The following process occurs: 381 o The WTP generates the IEEE 802.11 Beacon frames, using information 382 provided to it through the IEEE 802.11 Add WLAN (see Section 6.1) 383 message element, including the RSNIE, which indicates support of 384 802.1X and AES-CCMP. 386 o The WTP processes the Probe Request frame and responds with a 387 corresponding Probe Response frame. The Probe Request frame is 388 then forwarded to the AC for optional processing. 390 o The WTP forwards the IEEEE 802.11 Authentication and Association 391 frames to the AC, which is responsible for responding to the 392 client. 394 o Once the association is complete, the AC transmits a Station 395 Configuration Request message, which includes an Add Station 396 message element, to the WTP (see Section 4.6.8 in 397 [I-D.ietf-capwap-protocol-specification]). In the above example, 398 the WLAN was configured for IEEE 802.1X. 400 o If the WTP is providing encryption/decryption services, once the 401 client has completed the IEEE 802.11 key exchange, the AC 402 transmits another Station Configuration Request message which 403 includes an Add Station message element, an IEEE 802.11 Station 404 message element, an IEEE 802.11 Station Session Key message 405 element and an IEEE 802.11 Information Element message element 406 which includes the Robust Security Network Information Element 407 (RSNIE) to the WTP, delivering the security policy to enforce for 408 the station (in this case AES-CCMP), and the encryption key to 409 use. If encryption/decryption is handled in the AC, the IEEE 410 802.11 Information message element with an RSNIE would not be 411 included. 413 o The WTP forwards any IEEE 802.11 Management Action frames received 414 to the AC. 416 o All IEEE 802.11 station data frames are tunneled between the WTP 417 and the AC. 419 Note that during the EAPOL-Key exchange between the Station and the 420 AC, the Receive Sequence Counter (RSC) field for the GTK needs to be 421 included in the frame. The value of zero (0) is used by the AC 422 during this exchange. Additional details are available in 423 Section 9.1. 425 The WTP SHALL include the IEEE 802.11 MAC header contents in all 426 frames transmitted to the AC. 428 When 802.11 encryption/decryption is performed at the WTP, the WTP 429 MUST decrypt the uplink frames, MUST set the Protected Frame field to 430 0, and MUST make the frame format consistent with that of an 431 unprotected 802.11 frame prior to transmitting the frames to the AC. 432 The fields added to an 802.11 protected frame (i.e., Initialization 433 Vector/Extended Initialization Vector (IV/EIV), Message Integrity 434 Code (MIC), and Integrity Check Value (ICV)) MUST be stripped off 435 prior to transmission from the WTP to AC. For downlink frames, the 436 Protected Frame field MUST be set to 0 by the AC as the frame being 437 sent is unencrypted. The WTP MUST apply the required protection 438 policy for the WLAN, and set the Protected Frame field on 439 transmission over the air. The Protected Frame field always needs to 440 accurately indicate the status of the 802.11 frame that is carrying 441 it. 443 When 802.11 encryption/decryption is performed at the AC, the WTP 444 SHALL NOT decrypt the uplink frames prior to transmitting the frames 445 to the AC. The AC and WTP SHALL populate the IEEE 802.11 MAC header 446 fields as described in Figure 3. 448 MAC header field Location 449 Frame Control: 450 Version AC 451 ToDS AC 452 FromDS AC 453 Type AC 454 SubType AC 455 MoreFrag WTP/AC 456 Retry WTP 457 Pwr Mgmt - 458 MoreData WTP 459 Protected WTP/AC 460 Order AC 461 Duration: WTP 462 Address 1: AC 463 Address 2: AC 464 Address 3: AC 465 Sequence Ctrl: WTP 466 Address 4: AC 467 QoS Control: AC 468 Frame Body: AC 469 FCS: WTP 471 Figure 3: Population of the IEEE 802.11 MAC header Fields for 472 Downlink Frames 474 When 802.11 encryption/decryption is performed at the AC, the 475 MoreFrag bit is populated at the AC. The Pwr Mgmt bit is not 476 applicable to downlink frames, and is set to 0. Note that the Frame 477 Check Sequence (FCS) field is not included in 802.11 frames exchanged 478 between the WTP and the AC. Upon sending data frames to the AC, the 479 WTP is responsible for validating, and stripping the FCS field. Upon 480 receiving data frames from the AC, the WTP is responsible for adding 481 the FCS field, and populating the field as described in 482 [IEEE.802-11.2007]. 484 Note that when the WTP tunnels data packets to the AC (and vice 485 versa), the CAPWAP protocol does not guarantee in-order delivery. 486 When the protocol being transported over IEEE 802.11 is IP, out of 487 order delivery is not an issue as IP has no such requirements. 488 However, implementors need to be aware of this protocol 489 characteristic before deciding to use CAPWAP. 491 2.2.2. Local MAC 493 This section shows the division of labor between the WTP and the AC 494 in a Local MAC architecture. Figure 4 shows the separation of 495 functionality among CAPWAP components. 497 Function Location 498 Distribution Service WTP/AC 499 Integration Service WTP 500 Beacon Generation WTP 501 Probe Response Generation WTP 502 Power Mgmt/Packet Buffering WTP 503 Fragmentation/Defragmentation WTP 504 Assoc/Disassoc/Reassoc WTP/AC 506 IEEE 802.11 QOS 507 Classifying WTP 508 Scheduling WTP 509 Queuing WTP 511 IEEE 802.11 RSN 512 IEEE 802.1X/EAP AC 513 RSNA Key Management AC 514 IEEE 802.11 Encryption/Decryption WTP 516 Figure 4: Mapping of 802.11 Functions for Local AP Architecture 518 In the Local MAC mode, the integration service exists on the WTP, 519 while the distribution service MAY reside on either the WTP or the 520 AC. When it resides on the AC, station generated frames are not 521 forwarded to the AC in their native format, but encapsulated as 802.3 522 frames. 524 While the MAC is terminated on the WTP, it is necessary for the AC to 525 be aware of mobility events within the WTPs. Thus the WTP MUST 526 forward the IEEE 802.11 Association Request frames to the AC. The AC 527 MAY reply with a failed Association Response frame if it deems it 528 necessary, and upon receipt of a failed Association Response frame 529 from the AC, the WTP MUST send a Disassociation frame to the station. 531 The IEEE 802.1X [IEEE.802-1X.2004], EAP and IEEE RSNA Key Management 532 [IEEE.802-11.2007] functions reside in the AC. Therefore, the WTP 533 MUST forward all IEEE 802.1X, EAP and RSNA Key Management frames to 534 the AC and forward the corresponding responses to the station. This 535 implies that the AAA client also resides on the AC. 537 Note that in the following figure, the use of '( - )' indicates that 538 processing of the frames is done on the WTP. 540 Client WTP AC 542 Beacon 543 <----------------------------- 544 Probe 545 <----------------------------> 546 802.11 AUTH 547 <----------------------------- 548 802.11 Association 549 <---------------------------( - )-------------------------> 550 Station Configuration Request[ 551 Add Station (Station Message 552 Elements)] 553 <--------------------------> 554 802.1X Authentication & 802.11 Key Exchange 555 <---------------------------------------------------------> 556 802.11 Action Frames 557 <---------------------------------------------------------> 558 Station Configuration Request[ 559 Add Station (AES-CCMP, 560 PTK=x)] 561 <--------------------------> 562 802.11 DATA 563 <-----------------------------> 565 Figure 5: Local MAC Message Flow 567 Figure 5 provides an illustration of the division of labor in a Local 568 MAC architecture. In this example, a WLAN that is configured for 569 IEEE 802.11 has been created using AES-CCMP for privacy. The 570 following process occurs: 572 o The WTP generates the IEEE 802.11 Beacon frames, using information 573 provided to it through the Add WLAN (see Section 6.1) message 574 element. 576 o The WTP processes a Probe Request frame and responds with a 577 corresponding Probe Response frame. 579 o The WTP forwards the IEEE 802.11 Authentication and Association 580 frames to the AC. 582 o Once the association is complete, the AC transmits a Station 583 Configuration Request message, which includes the Add Station 584 message element, to the WTP (see Section 4.6.8 in 585 [I-D.ietf-capwap-protocol-specification]). In the above example, 586 the WLAN is configured for IEEE 802.1X, and therefore the '802.1X 587 only' policy bit is enabled. 589 o The WTP forwards all IEEE 802.1X and IEEE 802.11 key exchange 590 messages to the AC for processing. 592 o The AC transmits another Station Configuration Request message 593 including an Add Station message element, an IEEE 802.11 Station 594 message element, an IEEE 802.11 Station Session Key message 595 element and an IEEE 802.11 Information Element message element 596 which includes the RSNIE to the WTP, stating the security policy 597 to enforce for the client (in this case AES-CCMP), as well as the 598 encryption key to use. The Add Station message element MAY 599 include a Virtual LAN (VLAN) [IEEE.802-1Q.2005] name , which when 600 present is used by the WTP to identify the VLAN on which the 601 user's data frames are to be bridged. 603 o The WTP forwards any IEEE 802.11 Management Action frames received 604 to the AC. 606 o The WTP MAY locally bridge client data frames (and provide the 607 necessary encryption and decryption services). The WTP MAY also 608 tunnel client data frames to the AC, using 802.3 frame tunnel mode 609 or 802.11 frame tunnel mode. 611 2.3. Roaming Behavior 613 This section expands upon the examples provided in the previous 614 section, and describes how the CAPWAP control protocol is used to 615 provide secure roaming. 617 Once a client has successfully associated with the network in a 618 secure fashion, it is likely to attempt to roam to another WTP. 619 Figure 6 shows an example of a currently associated station moving 620 from its "Old WTP" to a "New WTP". The figure is valid for multiple 621 different security policies, including IEEE 802.1X and Wireless 622 Protected Access (WPA) or Wireless Protected Access 2 (WPA2) [WPA], 623 both with key caching (where the IEEE 802.1x exchange would be 624 bypassed) and without. 626 Client Old WTP New WTP AC 628 Association Request/Response 629 <--------------------------------------( - )--------------> 630 Station Configuration Request[ 631 Add Station (Station Message 632 Elements)] 633 <----------------> 634 802.1X Authentication (if no key cache entry exists) 635 <--------------------------------------( - )--------------> 636 802.11 4-way Key Exchange 637 <--------------------------------------( - )--------------> 638 Station Configuration Request 639 [Delete Station] 640 <----------------------------------> 641 Station Configuration Request 642 [Add Station (AES-CCMP, 643 PTK=x)] 644 <----------------> 646 Figure 6: Client Roaming Example 648 2.4. Group Key Refresh 650 Periodically, the Group Key (GTK)for the BSS needs to be updated. 651 The AC uses an EAPOL-Key frame to update the group key for each STA 652 in the BSS. While the AC is updating the GTK, each L2 broadcast 653 frame transmitted to the BSS needs to be duplicated and transmitted 654 using both the current GTK and the new GTK. Once the GTK update 655 process has completed, broadcast frames transmitted to the BSS will 656 be encrypted using the new GTK. 658 In the case of Split MAC, the AC needs to duplicate all broadcast 659 packets and update the key index so that the packet is transmitted 660 using both the current and new GTK to ensure that all STA's in the 661 BSS receive the broadcast frames. In the case of local MAC, the WTP 662 needs to duplicate and transmit broadcast frames using the 663 appropriate index to ensure that all STA's in the BSS continue to 664 receive broadcast frames. 666 The Group Key update procedure is shown in the following figure. The 667 AC will signal the update to the GTK using an IEEE 802.11 668 Configuration Request message, including an IEEE 802.11 Update WLAN 669 message element with the new GTK, its index, the TSC for the Group 670 Key and the Key Status set to 3 (begin GTK update). The AC will then 671 begin updating the GTK for each STA. During this time, the AC (for 672 Split MAC) or WTP (for Local MAC) MUST duplicate broadcast packets 673 and transmit them encrypted with both the current and new GTK. When 674 the AC has completed the GTK update to all STA's in the BSS, the AC 675 MUST transmit an IEEE 802.11 Configuration Request message including 676 an IEEE 802.11 Update WLAN message element containing the new GTK, 677 its index, and the Key Status set to 4 (GTK update complete). 679 Client WTP AC 681 IEEE 802.11 WLAN Configuration Request [Update 682 WLAN (GTK, GTK Index, GTK Start, 683 Group TSC) ] 684 <-------------------------------------------- 685 802.1X EAPoL (GTK Message 1) 686 <-------------( - )------------------------------------------- 687 802.1X EAPoL (GTK Message 2) 688 -------------( - )-------------------------------------------> 689 IEEE 802.11 WLAN Configuration Request [ Update 690 WLAN (GTK Index, GTK Complete) ] 691 <-------------------------------------------- 693 Figure 7: Group Key Update Procedure 695 2.5. BSSID to WLAN ID Mapping 697 The CAPWAP protocol binding enables the WTP to assign BSSIDs upon 698 creation of a WLAN (see Section 6.1). While manufacturers are free 699 to assign BSSIDs using any arbitrary mechanism, it is advised that 700 where possible the BSSIDs are assigned as a contiguous block. 702 When assigned as a block, implementations can still assign any of the 703 available BSSIDs to any WLAN. One possible method is for the WTP to 704 assign the address using the following algorithm: base BSSID address 705 + WLAN ID. 707 The WTP communicates the maximum number of BSSIDs that it supports 708 during configuration via the IEEE 802.11 WTP WLAN Radio Configuration 709 message element (see Section 6.23). 711 2.6. CAPWAP Data Channel QoS Behavior 713 The CAPWAP IEEE 802.11 binding specification provides procedures to 714 allow for the WTP to enforce Quality of Service on IEEE 802.11 Data 715 Frames and MAC Management messages. 717 2.6.1. IEEE 802.11 Data Frames 719 When the WLAN is created on the WTP, a default Quality of Service 720 policy is established through the IEEE 802.11 WTP Quality of Service 721 message element (see Section 6.22). This default policy will cause 722 the WTP to use the default QoS values for any station associated with 723 the WLAN in question. The AC MAY also override the policy for a 724 given station, by sending the IEEE 802.11 Update Station QoS message 725 element (see Section 6.20), known as a station specific QoS policy. 727 Beyond the default, and per station QoS policy, the IEEE 802.11 728 protocol also allows a station to request special QoS treatment for a 729 specific flow through the TSPEC information elements found in the 730 IEEE 802.11-2007's QoS Action Frame. Alternatively, stations MAY 731 also use the WiFi Alliance's WMM specification instead to request QoS 732 treatment for a flow (see [WMM]). This requires the WTP to observe 733 the Status Code in the IEEE 802.11-2007 and WMM QoS Action ADDTS 734 responses from the AC, and provide the services requested in the 735 TSPEC information element. Similarly, the WTP MUST observe the 736 Reason Code information element in the IEEE 802.11-2007 and WMM QoS 737 Action DELTS responses from the AC by removing the policy associated 738 with the TSPEC. 740 The IEEE 802.11 WTP Quality of Service message element's Tagging 741 Policy field indicates how the packets are to be tagged, known as the 742 Tagging Policy. There are five bits defined, two of which are used 743 to indicate the type of QoS to be used by the WTP. The first is the 744 'P' bit which is set to inform the WTP it is to use the 802.1p QoS 745 mechanism. When set, the 'Q' bit is used to inform the WTP which 746 802.1p priority values it is to use. 748 The 'D' bit is set to inform the WTP it is to use the DSCP QoS 749 mechanism. When set, the 'I' and 'O' bits are used to inform the WTP 750 which values it is to use in the inner header, in the station's 751 original packet, or the outer header, the latter of which is only 752 valid when tunneling is enabled. 754 When an IEEE 802.11 Update Station QoS message element is received, 755 while the specific 802.1p priority or DSCP values may change for a 756 given station, known as the station specific policy, the original 757 Tagging Policy (the use of the five bits) remains the same. 759 The use of the DSCP and 802.1p QoS mechanisms are not mutually 760 exclusive. An AC MAY request that a WTP use none, one or both types 761 of QoS mechanisms at the same time. 763 2.6.1.1. 802.1p Support 765 The IEEE 802.11 WTP Quality of Service and IEEE 802.11 Update Station 766 QoS message elements include the "802.1p Tag" field, which is the 767 802.1p priority value. This value is used by the WTP by adding an 768 802.1Q header (see [IEEE.802-1Q.2005]) with the priority field set 769 according to the policy provided. Note this tagging is only valid 770 for interfaces that support 802.1p. The actual treatment does not 771 change for either Split or Local MAC modes, or when tunneling is 772 used. The only exception is when tunneling is used, the 802.1Q 773 header is added to the outer packet (tunneled) header. The IEEE 774 802.11 standard does not permit the station's packet to include an 775 802.1Q header. Instead, the QoS mechanisms defined in the IEEE 776 802.11 standard are used by stations to mark a packet's priority. 777 When the 'P' bit is set in the Tagging Policy, the 'Q' bit has the 778 following behavior: 780 Q=1: The WTP marks the priority field in the 802.1Q header to 781 either the default, or the station specific 802.1p policy. 783 Q=0: The WTP marks the priority field in the 802.1Q header to the 784 value found in User Priority field of the QoS Control field of the 785 IEEE 802.11 header. If the QoS Control field is not present in 786 the IEEE 802.11 header, then the behavior described under 'Q=1' is 787 used. 789 2.6.1.2. DSCP Support 791 The IEEE 802.11 WTP Quality of Service and IEEE 802.11 Update Station 792 QoS message elements also provide a "DSCP Tag", which is used by the 793 WTP when the 'D' bit is set to mark the DSCP field of both the IPv4 794 and IPv6 headers (see [RFC2474]). When DSCP is used, the WTP marks 795 the inner packet (the original packet received by the station) when 796 the 'I' bit is set. Similarly, the WTP marks the outer packet 797 (tunnel header's DSCP field) when the 'O' bit is set. 799 When the 'D' bit is set, the treatment of the packet differs based 800 whether the WTP is tunneling the station's packets to the AC. 801 Tunneling does not occur in a Local MAC mode when the AC has 802 communicated that tunneling is not required, as part of the IEEE 803 802.11 Add WLAN message element Section 6.1. In the case where 804 tunneling is not used, the 'I' and 'O' bits have the following 805 behavior: 807 O=1: This option is invalid when tunneling is not enabled for 808 station data frames. 810 O=0: This option is invalid when tunneling is not enabled for 811 station data frames. 813 I=1: The WTP sets the DSCP field in the station's packet to either 814 the default policy, or the station specific policy if one exists. 816 I=0: The WTP MUST NOT modify the DSCP field in the station's 817 packet. 819 For Split MAC mode, or Local MAC with tunneling enabled, the WTP 820 needs to contend with both the inner packet (the station's original 821 packet), as well as the tunnel header (added by the WTP). In this 822 mode of operation, the bits are treated as follows: 824 O=1: The WTP sets the DSCP field in the tunnel header to either the 825 default policy, or the station specific policy if one exists. 827 O=0: The WTP sets the DSCP field in the tunnel header to the value 828 found in the inner packet's DSCP field. If encryption services 829 are provided by the AC (see Section 6.15), the packet is 830 encrypted, therefore the WTP cannot access the inner DSCP field, 831 in which case it uses the behavior described when the 'O' bit is 832 set. This occurs also if the inner packet is not IPv4 or IPv6, 833 and thus does not have a DSCP field. 835 I=1: The WTP sets the DSCP field in the station's packet to either 836 the default policy, or the station specific policy if one exists. 837 If encryption services are provided by the AC (see Section 6.15), 838 the packet is encrypted, therefore the WTP cannot access the inner 839 DSCP field, in which case it uses the behavior described when the 840 'I' bit is not set. This occurs also if the inner packet is not 841 IPv4 or IPv6, and thus does not have a DSCP field. 843 I=0: The WTP MUST NOT modify the DSCP field in the station's 844 packet. 846 The IP header also includes the Explicit Congestion Notification 847 (ECN) bits [RFC3168]. When packets received from stations are 848 encapsulated by the WTP, the ECN bits are set to zero (0) in the 849 outer header. The WTP does not modify the ECN bits in the original 850 station's packet header. This mode of operation is detailed as the 851 "limited functionality option" in [RFC3168]. 853 2.6.2. IEEE 802.11 MAC Management Messages 855 It is recommended that IEEE 802.11 MAC Management frames be sent by 856 both the AC and the WTP with appropriate Quality of Service values, 857 listed below, to ensure that congestion in the network minimizes 858 occurrences of packet loss. Note that the QoS Mechanism specified in 859 Tagging Policy is used as specified by the AC in the IEEE 802.11 WTP 860 Quality of Service message element (see Section 6.22). However, the 861 station specific policy is not used for IEEE 802.11 MAC Management 862 frames. 864 802.1p: The precedence value of 7 (decimal) SHOULD be used for all 865 IEEE 802.11 MAC management frames, except for Probe Requests which 866 SHOULD use 4. 868 DSCP: All IEEE 802.11 MAC management frames SHOULD use the 869 Expedited Forwarding per-hop behavior (see [RFC2598]), while IEEE 870 802.11 Probe Requests should use the Low Drop Assured Forwarding 871 per-hop behavior (see [RFC2598]). 873 2.7. Run State Operation 875 The Run state is the normal state of operation for the CAPWAP 876 protocol in both the WTP and the AC. 878 When the WTP receives a WLAN Configuration Request message (see 879 Section 3.1), it MUST respond with a WLAN Configuration Response 880 message (see Section 3.2) and it remains in the Run state. 882 When the AC sends a WLAN Configuration Request message (see 883 Section 3.1) or receives the corresponding WLAN Configuration 884 Response message (see Section 3.2) from the WTP, it remains in the 885 Run state. 887 3. IEEE 802.11 Specific CAPWAP Control Messages 889 This section defines CAPWAP Control Messages that are specific to the 890 IEEE 802.11 binding. Two messages are defined, IEEE 802.11 WLAN 891 Configuration Request and IEEE 802.11 WLAN Configuration Response. 892 See Section 4.5 in [I-D.ietf-capwap-protocol-specification] for 893 CAPWAP Control message definitions and the derivation of the Message 894 Type value from the IANA Enterprise number. 896 The valid message types for IEEE 802.11 specific control messages are 897 listed below. The IANA Enterprise number used with these messages is 898 13277. 900 CAPWAP Control Message Message Type 901 Value 903 IEEE 802.11 WLAN Configuration Request 3398913 904 IEEE 802.11 WLAN Configuration Response 3398914 906 3.1. IEEE 802.11 WLAN Configuration Request 908 The IEEE 802.11 WLAN Configuration Request is sent by the AC to the 909 WTP in order to change services provided by the WTP. This control 910 message is used to either create, update or delete a WLAN on the WTP. 912 The IEEE 802.11 WLAN Configuration Request is sent as a result of 913 either some manual administrative process (e.g., deleting a WLAN), or 914 automatically to create a WLAN on a WTP. When sent automatically to 915 create a WLAN, this control message is sent after the CAPWAP 916 Configuration Update Response message (see Section 8.5 in 917 [I-D.ietf-capwap-protocol-specification]) has been received by the 918 AC. 920 Upon receiving this control message, the WTP will modify the 921 necessary services, and transmit an IEEE 802.11 WLAN Configuration 922 Response. 924 A WTP MAY provide service for more than one WLAN, therefore every 925 WLAN is identified through a numerical index. For instance, a WTP 926 that is capable of supporting up to 16 Service Set Identifiers 927 (SSIDs), could accept up to 16 IEEE 802.11 WLAN Configuration Request 928 messages that include the Add WLAN message element. 930 Since the index is the primary identifier for a WLAN, an AC MAY 931 attempt to ensure that the same WLAN is identified through the same 932 index number on all of its WTPs. An AC that does not follow this 933 approach MUST find some other means of maintaining a WLAN-Identifier- 934 to-SSID mapping table. 936 The following message elements MAY be included in the IEEE 802.11 937 WLAN Configuration Request message. Only one message element MUST be 938 present. 940 o IEEE 802.11 Add WLAN, see Section 6.1 942 o IEEE 802.11 Delete WLAN, see Section 6.4 944 o IEEE 802.11 Update WLAN, see Section 6.21 946 The following message element MAY be present. 948 o IEEE 802.11 Information Element, see Section 6.6 950 o Vendor Specific Payload, see 951 [I-D.ietf-capwap-protocol-specification] 953 3.2. IEEE 802.11 WLAN Configuration Response 955 The IEEE 802.11 WLAN Configuration Response message is sent by the 956 WTP to the AC. It is used to acknowledge receipt of an IEEE 802.11 957 WLAN Configuration Request message, and to indicate that the 958 requested configuration was successfully applied, or that an error 959 related to the processing of the IEEE 802.11 WLAN Configuration 960 Request message occurred on the WTP. 962 The following message element MUST be included in the IEEE 802.11 963 WLAN Configuration Response message. 965 o Result Code, see Section 4.6.34 in 966 [I-D.ietf-capwap-protocol-specification] 968 The following message element MAY be included in the IEEE 802.11 WLAN 969 Configuration Response message. 971 o IEEE 802.11 Assigned WTP BSSID, see Section 6.3 973 o Vendor Specific Payload, see 974 [I-D.ietf-capwap-protocol-specification] 976 4. CAPWAP Data Message Bindings 978 This section describes the CAPWAP Data Message bindings to support 979 transport of IEEE 802.11 frames. 981 Payload encapsulation: The CAPWAP protocol defines the CAPWAP data 982 message, which is used to encapsulate a wireless payload. For 983 IEEE 802.11, the IEEE 802.11 header and payload are encapsulated 984 (excluding the IEEE 802.11 FCS checksum). The IEEE 802.11 FCS 985 checksum is handled by the WTP. This allows the WTP to validate 986 an IEEE 802.11 frame prior to sending it to the AC. Similarly, 987 when an AC wishes to transmit a frame to a station, the WTP 988 computes and adds the FCS checksum. 990 Optional Wireless Specific Information: This optional CAPWAP header 991 field (see Section 4.3 in 992 [I-D.ietf-capwap-protocol-specification]) is only used with CAPWAP 993 data messages, and it serves two purposes, depending upon the 994 direction of the message. For messages from the WTP to the AC, 995 the field uses the format described in the "IEEE 802.11 Frame 996 Info" field (see below). However, for messages sent by the AC to 997 the WTP, the format used is described in the "Destination WLANs" 998 field (also defined below). 1000 Note that in both cases, the two optional headers fit in the 1001 "Data" field of the Wireless Specific Information header. 1003 IEEE 802.11 Frame Info: When an IEEE 802.11 frame is received from a 1004 station over the air, it is encapsulated and this field is used to 1005 include radio and PHY specific information associated with the 1006 frame. 1008 The IEEE 802.11 Frame Info field has the following format: 1010 0 1 2 3 1011 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 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 | RSSI | SNR | Data Rate | 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1016 RSSI: RSSI is a signed, 8-bit value. It is the received signal 1017 strength indication, in dBm. 1019 SNR: SNR is a signed, 8-bit value. It is the signal to noise 1020 ratio of the received IEEE 802.11 frame, in dB. 1022 Data Rate: The data rate field is a 16 bit unsigned value. The 1023 data rate field is a 16 bit unsigned value expressing the data 1024 rate of the packets received by the WTP in units of 0.1 Mbps. 1025 For instance, a packet received at 5.5Mbps would be set to 55, 1026 while 11Mbps would be set to 110. 1028 Destination WLANs The Destination WLANs field is used to specify the 1029 target WLANs for a given frame, and is only used with broadcast 1030 and multicast frames. This field allows the AC to transmit a 1031 single broadcast or multicast frame to the WTP, and allows the WTP 1032 to perform the necessary frame replication. The field uses the 1033 following format: 1035 0 1 2 3 1036 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 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1038 | WLAN ID bitmap | Reserved | 1039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1041 WLAN ID bitmap: This bit field indicates the WLAN ID (see 1042 Section 6.1) on which the WTP will transmit the included frame. 1043 For instance, if a multicast packet is to be transmitted on 1044 WLANs 1 and 3, the bits for WLAN 1 and 3 of this field would be 1045 enabled. WLAN 1 is represented by bit 15 in the figure above, 1046 or the least significant bit, while WLAN 16 would be 1047 represented by bit zero (0), or the most significant bit, in 1048 the figure. This field is to be set to all zeroes for unicast 1049 packets and is unused if the WTP is not providing IEEE 802.11 1050 encryption. 1052 Reserved: All implementations complying with this protocol MUST 1053 set to zero any bits that are reserved in the version of the 1054 protocol supported by that implementation. Receivers MUST 1055 ignore all bits not defined for the version of the protocol 1056 they support. 1058 5. CAPWAP Control Message bindings 1060 This section describes the IEEE 802.11 specific message elements 1061 included in CAPWAP Control Messages. 1063 5.1. Discovery Request Message 1065 The following IEEE 802.11 specific message element MUST be included 1066 in the CAPWAP Discovery Request Message. 1068 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 1069 802.11 WTP Radio Information message element MUST be present for 1070 every radio in the WTP. 1072 5.2. Discovery Response Message 1074 The following IEEE 802.11 specific message element MUST be included 1075 in the CAPWAP Discovery Response Message. 1077 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 1078 802.11 WTP Radio Information message element MUST be present for 1079 every radio in the WTP. 1081 5.3. Primary Discovery Request Message 1083 The following IEEE 802.11 specific message element MUST be included 1084 in the CAPWAP Primary Discovery Request Message. 1086 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 1087 802.11 WTP Radio Information message element MUST be present for 1088 every radio in the WTP. 1090 5.4. Primary Discovery Response Message 1092 The following IEEE 802.11 specific message element MUST be included 1093 in the CAPWAP Primary Discovery Response Message. 1095 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 1096 802.11 WTP Radio Information message element MUST be present for 1097 every radio in the WTP. 1099 5.5. Join Request Message 1101 The following IEEE 802.11 specific message element MUST be included 1102 in the CAPWAP Join Request Message. 1104 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 1105 802.11 WTP Radio Information message element MUST be present for 1106 every radio in the WTP. 1108 5.6. Join Response Message 1110 The following IEEE 802.11 specific message element MUST be included 1111 in the CAPWAP Join Response Message. 1113 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 1114 802.11 WTP Radio Information message element MUST be present for 1115 every radio in the WTP. 1117 5.7. Configuration Status Message 1119 The following IEEE 802.11 specific message elements MAY be included 1120 in the CAPWAP Configuration Status Message. More than one of each 1121 message element listed MAY be included. 1123 o IEEE 802.11 Antenna, see Section 6.2 1125 o IEEE 802.11 Direct Sequence Control, see Section 6.5 1127 o IEEE 802.11 MAC Operation, see Section 6.7 1129 o IEEE 802.11 Multi Domain Capability, see Section 6.9 1131 o IEEE 802.11 OFDM Control, see Section 6.10 1133 o IEEE 802.11 Supported Rates, see Section 6.17 1135 o IEEE 802.11 Tx Power, see Section 6.18 1137 o IEEE 802.11 TX Power Level, see Section 6.19 1139 o IEEE 802.11 WTP Radio Configuration, see Section 6.23 1141 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 1142 802.11 WTP Radio Information message element MUST be present for 1143 every radio in the WTP. 1145 5.8. Configuration Status Response Message 1147 The following IEEE 802.11 specific message elements MAY be included 1148 in the CAPWAP Configuration Status Response Message. More than one 1149 of each message element listed MAY be included. 1151 o IEEE 802.11 Antenna, see Section 6.2 1152 o IEEE 802.11 Direct Sequence Control, see Section 6.5 1154 o IEEE 802.11 MAC Operation, see Section 6.7 1156 o IEEE 802.11 Multi Domain Capability, see Section 6.9 1158 o IEEE 802.11 OFDM Control, see Section 6.10 1160 o IEEE 802.11 Rate Set, see Section 6.11 1162 o IEEE 802.11 Supported Rates, see Section 6.17 1164 o IEEE 802.11 Tx Power, see Section 6.18 1166 o IEEE 802.11 WTP Quality of Service, see Section 6.22 1168 o IEEE 802.11 WTP Radio Configuration, see Section 6.23 1170 5.9. Configuration Update Request Message 1172 The following IEEE 802.11 specific message elements MAY be included 1173 in the CAPWAP Configuration Update Request Message. More than one of 1174 each message element listed MAY be included. 1176 o IEEE 802.11 Antenna, see Section 6.2 1178 o IEEE 802.11 Direct Sequence Control, see Section 6.5 1180 o IEEE 802.11 MAC Operation, see Section 6.7 1182 o IEEE 802.11 Multi Domain Capability, see Section 6.9 1184 o IEEE 802.11 OFDM Control, see Section 6.10 1186 o IEEE 802.11 Rate Set, see Section 6.11 1188 o IEEE 802.11 RSNA Error Report From Station, see Section 6.12 1190 o IEEE 802.11 Tx Power, see Section 6.18 1192 o IEEE 802.11 WTP Quality of Service, see Section 6.22 1194 o IEEE 802.11 WTP Radio Configuration, see Section 6.23 1196 5.10. Station Configuration Request 1198 The following IEEE 802.11 specific message elements MAY included in 1199 the CAPWAP Station Configuration Request message. More than one of 1200 each message element listed MAY be included. 1202 o IEEE 802.11 Station, see Section 6.13 1204 o IEEE 802.11 Station Session Key, see Section 6.15 1206 o IEEE 802.11 Station QoS Profile, see Section 6.14 1208 o IEEE 802.11 Update Station Qos, see Section 6.20 1210 5.11. Change State Event Request 1212 The following IEEE 802.11 specific message elements MAY included in 1213 the CAPWAP Station Configuration Request message. 1215 o IEEE 802.11 WTP Radio Fail Alarm Indication, see Section 6.24 1217 5.12. WTP Event Request 1219 The following IEEE 802.11 specific message elements MAY be included 1220 in the CAPWAP WTP Event Request message. More than one of each 1221 message element listed MAY be included. 1223 o IEEE 802.11 MIC Countermeasures, see Section 6.8 1225 o IEEE 802.11 RSNA Error Report From Station, see Section 6.12 1227 o IEEE 802.11 Statistics, see Section 6.16 1229 6. IEEE 802.11 Message Element Definitions 1231 The following IEEE 802.11 specific message elements are defined in 1232 this section. 1234 IEEE 802.11 Message Element Type Value 1236 IEEE 802.11 Add WLAN 1024 1237 IEEE 802.11 Antenna 1025 1238 IEEE 802.11 Assigned WTP BSSID 1026 1239 IEEE 802.11 Delete WLAN 1027 1240 IEEE 802.11 Direct Sequence Control 1028 1241 IEEE 802.11 Information Element 1029 1242 IEEE 802.11 MAC Operation 1030 1243 IEEE 802.11 MIC Countermeasures 1031 1244 IEEE 802.11 Multi-Domain Capability 1032 1245 IEEE 802.11 OFDM Control 1033 1246 IEEE 802.11 Rate Set 1034 1247 IEEE 802.11 RSNA Error Report From Station 1035 1248 IEEE 802.11 Station 1036 1249 IEEE 802.11 Station QoS Profile 1037 1250 IEEE 802.11 Station Session Key 1038 1251 IEEE 802.11 Statistics 1039 1252 IEEE 802.11 Supported Rates 1040 1253 IEEE 802.11 Tx Power 1041 1254 IEEE 802.11 Tx Power Level 1042 1255 IEEE 802.11 Update Station QoS 1043 1256 IEEE 802.11 Update WLAN 1044 1257 IEEE 802.11 WTP Quality of Service 1045 1258 IEEE 802.11 WTP Radio Configuration 1046 1259 IEEE 802.11 WTP Radio Fail Alarm Indication 1047 1260 IEEE 802.11 WTP Radio Information 1048 1262 Figure 8: IEEE 802.11 Binding Message Elements 1264 6.1. IEEE 802.11 Add WLAN 1266 The IEEE 802.11 Add WLAN message element is used by the AC to define 1267 a WLAN on the WTP. The inclusion of this message element MUST also 1268 include IEEE 802.11 Information Element message elements, containing 1269 the following IEEE 802.11 IEs: 1271 Power Constraint information element 1272 EDCA Parameter Set information element 1274 QoS Capability information element 1276 WPA information element [WPA] 1278 RSN information element 1280 WMM information element [WMM] 1282 These IEEE 802.11 information elements are stored by the WTP and 1283 included in any Probe Responses and Beacons generated, as specified 1284 in the IEEE 802.11 standard [IEEE.802-11.2007]. If present, the RSN 1285 information element is sent with the IEEE 802.11 Add WLAN message 1286 element to instruct the WTP on the usage of the Key field. 1288 If cryptographic services are provided at the WTP, the WTP MUST 1289 observe the algorithm dictated in the Group Cipher Suite field of the 1290 RSN information element sent by the AC. The RSN Information Element 1291 is used to communicate any supported algorithm, including WEP, TKIP 1292 and AES-CCMP. In the case of static WEP keys, the RSN Information 1293 Element is still used to indicate the cryptographic algorithm even 1294 though no key exchange occurred. 1296 An AC MAY include additional information elements as desired. The 1297 message element uses the following format: 1299 0 1 2 3 1300 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 1301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1302 | Radio ID | WLAN ID | Capability | 1303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1304 | Key Index | Key Status | Key Length | 1305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1306 | Key... | 1307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1308 | Group TSC | 1309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1310 | Group TSC | QoS | Auth Type | 1311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1312 | MAC Mode | Tunnel Mode | Suppress SSID | SSID ... 1313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1315 Type: 1024 for IEEE 802.11 Add WLAN 1316 Length: >= 20 1318 Radio ID: An 8-bit value representing the radio. 1320 WLAN ID: An 8-bit value specifying the WLAN Identifier. The value 1321 MUST be between one (1) and 16. 1323 Capability: A 16-bit value containing the capability information 1324 field to be advertised by the WTP in the Probe Request and Beacon 1325 frames. Each bit of the Capability field represents a different 1326 WTP capability, which are described in detail in 1327 [IEEE.802-11.2007]. The format of the field is: 1329 0 1 1330 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1332 |E|I|C|F|P|S|B|A|M|Q|T|D|V|O|K|L| 1333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1335 E (ESS): The AC MUST set the Extended Service Set (ESS) subfield 1336 to 1. 1338 I (IBSS): The AC MUST set the Independent Basic Service Set 1339 (IBSS) subfield to 0. 1341 C (CF-Pollable): The AC sets the Contention Free Pollable (CF- 1342 Pollable) subfield based on the table found in 1343 [IEEE.802-11.2007]. 1345 F (CF-Poll Request): The AC sets the CF-Poll Request subfield 1346 based on the table found in [IEEE.802-11.2007]. 1348 P (Privacy): The AC sets the Privacy subfield based on the 1349 confidentiality requirements of the WLAN, as defined in 1350 [IEEE.802-11.2007]. 1352 S (Short Preamble): The AC sets the Short Preamble subfield 1353 based on whether the use of short preambles are permitted on 1354 the WLAN, as defined in [IEEE.802-11.2007]. 1356 B (PBCC): The AC sets the Packet Binary Convolutional Code 1357 (PBCC) modulation option subfield based on whether the use of 1358 PBCC is permitted on the WLAN, as defined in 1359 [IEEE.802-11.2007]. 1361 A (Channel Agility): The AC sets the Channel Agility subfield 1362 based on whether the WTP is capable of supporting the High Rate 1363 Direct Sequence Spread Spectrum (HR/DSSS), as defined in 1364 [IEEE.802-11.2007]. 1366 M (Spectrum Management): The AC sets the Spectrum Management 1367 subfield according to the value of the 1368 dot11SpectrumManagementRequired MIB variable, as defined in 1369 [IEEE.802-11.2007]. 1371 Q (QOS): The AC sets the Quality of Service (QOS) subfield based 1372 on the table found in [IEEE.802-11.2007]. 1374 T (Short Slot Time): The AC sets the Short Slot Timesubfield 1375 according to the value of the WTP's currently used slot time 1376 value, as defined in [IEEE.802-11.2007]. 1378 D (APSD): The AC sets the APSD subfield according to the value 1379 of the dot11APSDOptionImplemented Management Information Base 1380 (MIB) variable, as defined in [IEEE.802-11.2007]. 1382 V (Reserved): The AC sets the Reserved subfield to zero, as 1383 defined in [IEEE.802-11.2007]. 1385 O (DSSS-OFDM): The AC sets the DSSS-OFDM subfield to indicate 1386 the use of Direct Sequence Spread Spectrum with Orthogonal 1387 Frequency Division Multiplexing (DSSS-OFDM), as defined in 1388 [IEEE.802-11.2007]. 1390 K (Delayed Block ACK): The AC sets the Delayed Block ACK 1391 subfield according to the value of the 1392 dot11DelayedBlockAckOptionImplemented MIB variable, as defined 1393 in [IEEE.802-11.2007]. 1395 L (Immediate Block ACK): The AC sets the Delayed Block ACK 1396 subfield according to the value of the 1397 dot11ImmediateBlockAckOptionImplemented MIB variable, as 1398 defined in [IEEE.802-11.2007]. 1400 Key-Index: The Key Index associated with the key. 1402 Key Status: A 1 byte value that specifies the state and usage of 1403 the key that has been included. Note this field is ignored if the 1404 Key Length field is set to zero (0). The following values 1405 describe the key usage and its status: 1407 0 - A value of zero, with the inclusion of the RSN Information 1408 Element means that the WLAN uses per-station encryption keys, 1409 and therefore the key in the 'Key' field is only used for 1410 multicast traffic. 1412 1 - When set to one, the WLAN employs a shared Wired Equivalent 1413 Privacy (WEP) key, also known as a static WEP key, and uses the 1414 encryption key for both unicast and multicast traffic for all 1415 stations. 1417 2 - The value of 2 indicates that the AC will begin rekeying the 1418 GTK with the STA's in the BSS. It is only valid when IEEE 1419 802.11 is enabled as the security policy for the BSS. 1421 3 - The value of 3 indicates that the AC has completed rekeying 1422 the GTK and broadcast packets no longer need to be duplicated 1423 and transmitted with both GTK's. 1425 Key Length: A 16-bit value representing the length of the Key 1426 field. 1428 Key: A Session Key, whose length is known via the key length field, 1429 used to provide data privacy. For encryption schemes that employ 1430 a separate encryption key for unicast and multicast traffic, the 1431 key included here only applies to multicast frames, and the cipher 1432 suite is specified in an accompanied RSN Information Element. In 1433 these scenarios, the key and cipher information is communicated 1434 via the Add Station message element, see Section 4.6.8 in 1435 [I-D.ietf-capwap-protocol-specification] and the IEEE 802.11 1436 Station Session Key message element, see Section 6.15. 1438 Group TSC A 48-bit value containing the Transmit Sequence Counter 1439 for the updated group key. The WTP will set the TSC for 1440 broadcast/multicast frames to this value for the updated group 1441 key. 1443 QOS: An 8-bit value specifying the default QOS policy for the WTP 1444 to apply to network traffic received for a non-WMM enabled STA. 1446 The following enumerated values are supported: 1448 0 - Best Effort 1450 1 - Video 1451 2 - Voice 1453 3 - Background 1455 Auth Type: An 8-bit value specifying the supported authentication 1456 type. 1458 The following enumerated values are supported: 1460 0 - Open System 1462 1 - WEP Shared Key 1464 MAC Mode: This field specifies whether the WTP should support the 1465 WLAN in Local or Split MAC modes. Note that the AC MUST NOT 1466 request a mode of operation that was not advertised by the WTP 1467 during the discovery process (see Section 4.6.43 in 1468 [I-D.ietf-capwap-protocol-specification]). The following 1469 enumerated values are supported: 1471 0 - Local-MAC: Service for the WLAN is to be provided in Local 1472 MAC mode. 1474 1 - Split-MAC: Service for the WLAN is to be provided in Split 1475 MAC mode. 1477 Tunnel Mode: This field specifies the frame tunneling type to be 1478 used for 802.11 data frames from all stations associated with the 1479 WLAN. The AC MUST NOT request a mode of operation that was not 1480 advertised by the WTP during the discovery process (see Section 1481 4.6.42 in [I-D.ietf-capwap-protocol-specification]). All IEEE 1482 802.11 management frames MUST be tunneled using 802.11 Tunnel 1483 mode. The following enumerated values are supported: 1485 0 - Local Bridging: All user traffic is to be locally bridged. 1487 1 - 802.3 Tunnel: All user traffic is to be tunneled to the AC 1488 in 802.3 format (see Section 4.4.2 in 1489 [I-D.ietf-capwap-protocol-specification]). Note that this 1490 option MUST NOT be selected with Split-MAC mode. 1492 2 - 802.11 Tunnel: All user traffic is to be tunneled to the AC 1493 in 802.11 format. 1495 Supress SSID: A boolean indicating whether the SSID is to be 1496 advertised by the WTP. A value of zero suppresses the SSID in the 1497 802.11 Beacon and Probe Response frames, while a value of one will 1498 cause the WTP to populate the field. 1500 SSID: The SSID attribute is the service set identifier that will be 1501 advertised by the WTP for this WLAN. The SSID field contains any 1502 ASCII character and MUST NOT exceed 32 octets in length, as 1503 defined in [IEEE.802-11.2007]. 1505 6.2. IEEE 802.11 Antenna 1507 The IEEE 802.11 Antenna message element is communicated by the WTP to 1508 the AC to provide information on the antennas available. The AC MAY 1509 use this element to reconfigure the WTP's antennas. The message 1510 element contains the following fields: 1512 0 1 2 3 1513 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 1514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1515 | Radio ID | Diversity | Combiner | Antenna Cnt | 1516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1517 | Antenna Selection... 1518 +-+-+-+-+-+-+-+-+ 1520 Type: 1025 for IEEE 802.11 Antenna 1522 Length: >= 5 1524 Radio ID: An 8-bit value representing the radio to configure. 1526 Diversity: An 8-bit value specifying whether the antenna is to 1527 provide receive diversity. The value of this field is the same as 1528 the IEEE 802.11 dot11DiversitySelectionRx MIB element, see 1529 [IEEE.802-11.2007]. The following enumerated values are 1530 supported: 1532 0 - Disabled 1534 1 - Enabled (may only be true if the antenna can be used as a 1535 receive antenna) 1537 Combiner: An 8-bit value specifying the combiner selection. The 1538 following enumerated values are supported: 1540 1 - Sectorized (Left) 1542 2 - Sectorized (Right) 1544 3 - Omni 1546 4 - Multiple Input/Multiple Output (MIMO) 1548 Antenna Count: An 8-bit value specifying the number of Antenna 1549 Selection fields. This value SHOULD be the same as the one found 1550 in the IEEE 802.11 dot11CurrentTxAntenna MIB element (see 1551 [IEEE.802-11.2007]). 1553 Antenna Selection: One 8-bit antenna configuration value per 1554 antenna in the WTP, containing up to 255 antennas. The following 1555 enumerated values are supported: 1557 1 - Internal Antenna 1559 2 - External Antenna 1561 6.3. IEEE 802.11 Assigned WTP BSSID 1563 The IEEE 802.11 Assigned WTP BSSID is only included by the WTP when 1564 the IEEE 802.11 WLAN Configuration Request included the IEEE 802.11 1565 Add WLAN message element. The BSSID value field of this message 1566 element contains the BSSID that has been assigned by the WTP, 1567 enabling the WTP to perform its own BSSID assignment. 1569 The WTP is free to assign the BSSIDs the way it sees fit, but it is 1570 highly recommended that the WTP assign the BSSID using the following 1571 algorithm: BSSID = {base BSSID} + WLAN ID. 1573 0 1 2 3 1574 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 1575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1576 | Radio ID | WLAN ID | BSSID 1577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1578 | BSSID | 1579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1581 Type: 1026 for IEEE 802.11 Assigned WTP BSSID 1583 Length: 8 1584 Radio ID: An 8-bit value representing the radio. 1586 WLAN ID: An 8-bit value specifying the WLAN Identifier. The value 1587 MUST be between one (1) and 16. 1589 BSSID: The BSSID assigned by the WTP for the WLAN created as a 1590 result of receiving an IEEE 802.11 Add WLAN. 1592 6.4. IEEE 802.11 Delete WLAN 1594 The IEEE 802.11 Delete WLAN message element is used to inform the WTP 1595 that a previously created WLAN is to be deleted, and contains the 1596 following fields: 1598 0 1 1599 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1601 | Radio ID | WLAN ID | 1602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1604 Type: 1027 for IEEE 802.11 Delete WLAN 1606 Length: 2 1608 Radio ID: An 8-bit value representing the radio 1610 WLAN ID: An 8-bit value specifying the WLAN Identifier. The value 1611 MUST be between one (1) and 16. 1613 6.5. IEEE 802.11 Direct Sequence Control 1615 The IEEE 802.11 Direct Sequence Control message element is a bi- 1616 directional element. When sent by the WTP, it contains the current 1617 state. When sent by the AC, the WTP MUST adhere to the values 1618 provided. This element is only used for IEEE 802.11b radios. The 1619 message element has the following fields. 1621 0 1 2 3 1622 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 1623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1624 | Radio ID | Reserved | Current Chan | Current CCA | 1625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1626 | Energy Detect Threshold | 1627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1629 Type: 1028 for IEEE 802.11 Direct Sequence Control 1631 Length: 8 1633 Radio ID: An 8-bit value representing the radio to configure. 1635 Reserved: All implementations complying with this protocol MUST set 1636 to zero any bits that are reserved in the version of the protocol 1637 supported by that implementation. Receivers MUST ignore all bits 1638 not defined for the version of the protocol they support. 1640 Current Channel: This attribute contains the current operating 1641 frequency channel of the Direct Sequence Spread Spectrum (DSSS) 1642 PHY. This value comes from the IEEE 802.11 dot11CurrentChannel 1643 MIB element (see [IEEE.802-11.2007]). 1645 Current CCA: The current Clear Channel Assessment (CCA) method in 1646 operation, whose value can be found in the IEEE 802.11 1647 dot11CCAModeSupported MIB element (see [IEEE.802-11.2007]). Valid 1648 values are: 1650 1 - energy detect only (edonly) 1652 2 - carrier sense only (csonly) 1654 4 - carrier sense and energy detect (edandcs) 1656 8 - carrier sense with timer (cswithtimer) 1658 16 - high rate carrier sense and energy detect (hrcsanded) 1660 Energy Detect Threshold: The current Energy Detect Threshold being 1661 used by the DSSS PHY. The value can be found in the IEEE 802.11 1662 dot11EDThreshold MIB element (see [IEEE.802-11.2007]). 1664 6.6. IEEE 802.11 Information Element 1666 The IEEE 802.11 Information Element is used to communicate any IE 1667 defined in the IEEE 802.11 protocol. The data field contains the raw 1668 IE as it would be included within an IEEE 802.11 MAC management 1669 message. 1671 0 1 2 3 1672 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 1673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1674 | Radio ID | WLAN ID |B|P| Reserved |Info Element... 1675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1677 Type: 1029 for IEEE 802.11 Information Element 1679 Length: >= 4 1681 Radio ID: An 8-bit value representing the radio. 1683 WLAN ID: An 8-bit value specifying the WLAN Identifier. The value 1684 MUST be between one (1) and 16. 1686 B: When set, the WTP is to include the information element in IEEE 1687 802.11 Beacons associated with the WLAN. 1689 P: When set, the WTP is to include the information element in Probe 1690 Responses associated with the WLAN. 1692 Reserved: All implementations complying with this protocol MUST set 1693 to zero any bits that are reserved in the version of the protocol 1694 supported by that implementation. Receivers MUST ignore all bits 1695 not defined for the version of the protocol they support. 1697 Info Element: The IEEE 802.11 Information Element, which includes 1698 the type, length and value field. 1700 6.7. IEEE 802.11 MAC Operation 1702 The IEEE 802.11 MAC Operation message element is sent by the AC to 1703 set the IEEE 802.11 MAC parameters on the WTP, and contains the 1704 following fields. 1706 0 1 2 3 1707 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 1708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1709 | Radio ID | Reserved | RTS Threshold | 1710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1711 | Short Retry | Long Retry | Fragmentation Threshold | 1712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1713 | Tx MSDU Lifetime | 1714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1715 | Rx MSDU Lifetime | 1716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1718 Type: 1030 for IEEE 802.11 MAC Operation 1720 Length: 16 1721 Radio ID: An 8-bit value representing the radio to configure. 1723 Reserved: All implementations complying with this protocol MUST set 1724 to zero any bits that are reserved in the version of the protocol 1725 supported by that implementation. Receivers MUST ignore all bits 1726 not defined for the version of the protocol they support. 1728 RTS Threshold: This attribute indicates the number of octets in an 1729 MAC Protocol Data Unit (MPDU), below which an Request To Send/ 1730 Clear To Send (RTS/CTS) handshake MUST NOT be performed. An RTS/ 1731 CTS handshake MUST be performed at the beginning of any frame 1732 exchange sequence where the MPDU is of type Data or Management, 1733 the MPDU has an individual address in the Address1 field, and the 1734 length of the MPDU is greater than this threshold. Setting this 1735 attribute to be larger than the maximum MSDU size MUST have the 1736 effect of turning off the RTS/CTS handshake for frames of Data or 1737 Management type transmitted by this STA. Setting this attribute 1738 to zero MUST have the effect of turning on the RTS/CTS handshake 1739 for all frames of Data or Management type transmitted by this STA. 1740 The default value of this attribute MUST be 2347. The value of 1741 this field comes from the IEEE 802.11 dot11RTSThreshold MIB 1742 element, (see [IEEE.802-11.2007]). 1744 Short Retry: This attribute indicates the maximum number of 1745 transmission attempts of a frame, the length of which is less than 1746 or equal to RTSThreshold, that MUST be made before a failure 1747 condition is indicated. The default value of this attribute MUST 1748 be 7. The value of this field comes from the IEEE 802.11 1749 dot11ShortRetryLimit MIB element, (see [IEEE.802-11.2007]). 1751 Long Retry: This attribute indicates the maximum number of 1752 transmission attempts of a frame, the length of which is greater 1753 than dot11RTSThreshold, that MUST be made before a failure 1754 condition is indicated. The default value of this attribute MUST 1755 be 4. The value of this field comes from the IEEE 802.11 1756 dot11LongRetryLimit MIB element, (see [IEEE.802-11.2007]). 1758 Fragmentation Threshold: This attribute specifies the current 1759 maximum size, in octets, of the MPDU that MAY be delivered to the 1760 PHY. A MAC Service Data Unit (MSDU) MUST be broken into fragments 1761 if its size exceeds the value of this attribute after adding MAC 1762 headers and trailers. An MSDU or MAC Management Protocol Data 1763 Unit (MMPDU) MUST be fragmented when the resulting frame has an 1764 individual address in the Address1 field, and the length of the 1765 frame is larger than this threshold. The default value for this 1766 attribute MUST be the lesser of 2346 or the aMPDUMaxLength of the 1767 attached PHY and MUST never exceed the lesser of 2346 or the 1768 aMPDUMaxLength of the attached PHY. The value of this attribute 1769 MUST never be less than 256. The value of this field comes from 1770 the IEEE 802.11 dot11FragmentationThreshold MIB element, (see 1771 [IEEE.802-11.2007]). 1773 Tx MSDU Lifetime: This attribute specifies the elapsed time in TU, 1774 after the initial transmission of an MSDU, after which further 1775 attempts to transmit the MSDU MUST be terminated. The default 1776 value of this attribute MUST be 512. The value of this field 1777 comes from the IEEE 802.11 dot11MaxTransmitMSDULifetime MIB 1778 element, (see [IEEE.802-11.2007]). 1780 Rx MSDU Lifetime: This attribute specifies the elapsed time in TU, 1781 after the initial reception of a fragmented MMPDU or MSDU, after 1782 which further attempts to reassemble the MMPDU or MSDU MUST be 1783 terminated. The default value MUST be 512. The value of this 1784 field comes from the IEEE 802.11 dot11MaxReceiveLifetime MIB 1785 element, (see [IEEE.802-11.2007]). 1787 6.8. IEEE 802.11 MIC Countermeasures 1789 The IEEE 802.11 MIC Countermeasures message element is sent by the 1790 WTP to the AC to indicate the occurrence of a MIC failure. For more 1791 information on MIC failure events, see the 1792 dot11RSNATKIPCounterMeasuresInvoked MIB element definition in 1793 [IEEE.802-11.2007]. 1795 0 1 2 3 1796 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 1797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1798 | Radio ID | WLAN ID | MAC Address | 1799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1800 | MAC Address | 1801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1803 Type: 1031 for IEEE 802.11 MIC Countermeasures 1805 Length: 8 1807 Radio ID: The Radio Identifier, typically refers to some interface 1808 index on the WTP. 1810 WLAN ID: This 8-bit unsigned integer includes the WLAN Identifier, 1811 on which the MIC failure occurred. The value MUST be between one 1812 (1) and 16. 1814 MAC Address: The MAC Address of the station that caused the MIC 1815 failure. 1817 6.9. IEEE 802.11 Multi-Domain Capability 1819 The IEEE 802.11 Multi-Domain Capability message element is used by 1820 the AC to inform the WTP of regulatory limits. The AC will transmit 1821 one message element per frequency band to indicate the regulatory 1822 constraints in that domain. The message element contains the 1823 following fields. 1825 0 1 2 3 1826 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 1827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1828 | Radio ID | Reserved | First Channel # | 1829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1830 | Number of Channels | Max Tx Power Level | 1831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1833 Type: 1032 for IEEE 802.11 Multi-Domain Capability 1835 Length: 8 1837 Radio ID: An 8-bit value representing the radio to configure. 1839 Reserved: All implementations complying with this protocol MUST set 1840 to zero any bits that are reserved in the version of the protocol 1841 supported by that implementation. Receivers MUST ignore all bits 1842 not defined for the version of the protocol they support. 1844 First Channnel #: This attribute indicates the value of the lowest 1845 channel number in the sub-band for the associated domain country 1846 string. The value of this field comes from the IEEE 802.11 1847 dot11FirstChannelNumber MIB element (see [IEEE.802-11.2007]). 1849 Number of Channels: This attribute indicates the value of the total 1850 number of channels allowed in the sub-band for the associated 1851 domain country string (see Section 6.23). The value of this field 1852 comes from the IEEE 802.11 dot11NumberofChannels MIB element (see 1853 [IEEE.802-11.2007]). 1855 Max Tx Power Level: This attribute indicates the maximum transmit 1856 power, in dBm, allowed in the sub-band for the associated domain 1857 country string (see Section 6.23). The value of this field comes 1858 from the IEEE 802.11 dot11MaximumTransmitPowerLevel MIB element 1859 (see [IEEE.802-11.2007]). 1861 6.10. IEEE 802.11 OFDM Control 1863 The IEEE 802.11 Orthogonal Frequency Division Multiplexing (OFDM) 1864 Control message element is a bi-directional element. When sent by 1865 the WTP, it contains the current state. When sent by the AC, the WTP 1866 MUST adhere to the received values. This message element is only 1867 used for 802.11a radios and contains the following fields: 1869 0 1 2 3 1870 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 1871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1872 | Radio ID | Reserved | Current Chan | Band Support | 1873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1874 | TI Threshold | 1875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1877 Type: 1033 for IEEE 802.11 OFDM Control 1879 Length: 8 1881 Radio ID: An 8-bit value representing the radio to configure. 1883 Reserved: All implementations complying with this protocol MUST set 1884 to zero any bits that are reserved in the version of the protocol 1885 supported by that implementation. Receivers MUST ignore all bits 1886 not defined for the version of the protocol they support. 1888 Current Channel: This attribute contains the current operating 1889 frequency channel of the OFDM PHY. The value of this field comes 1890 from the IEEE 802.11 dot11CurrentFrequency MIB element (see 1891 [IEEE.802-11.2007]). 1893 Band Supported: The capability of the OFDM PHY implementation to 1894 operate in the three U-NII bands. The value of this field comes 1895 from the IEEE 802.11 dot11FrequencyBandsSupported MIB element (see 1896 [IEEE.802-11.2007]), coded as a bit field, whose values are: 1898 Bit 0 - capable of operating in the 5.15-5.25 GHz band 1900 Bit 1 - capable of operating in the 5.25-5.35 GHz band 1902 Bit 2 - capable of operating in the 5.725-5.825 GHz band 1904 Bit 3 - capable of operating in the 5.47-5.725 GHz band 1905 Bit 4 - capable of operating in the lower Japanese 5.25 GHz band 1907 Bit 5 - capable of operating in the 5.03-5.091 GHz band 1909 Bit 6 - capable of operating in the 4.94-4.99 GHz band 1911 For example, for an implementation capable of operating in the 1912 5.15-5.35 GHz bands this attribute would take the value 3. 1914 TI Threshold: The Threshold being used to detect a busy medium 1915 (frequency). CCA MUST report a busy medium upon detecting the 1916 RSSI above this threshold. The value of this field comes from the 1917 IEEE 802.11 dot11TIThreshold MIB element (see [IEEE.802-11.2007]). 1919 6.11. IEEE 802.11 Rate Set 1921 The rate set message element value is sent by the AC and contains the 1922 supported operational rates. It contains the following fields. 1924 0 1 2 3 1925 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 1926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1927 | Radio ID | Rate Set... 1928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1930 Type: 1034 for IEEE 802.11 Rate Set 1932 Length: >= 3 1934 Radio ID: An 8-bit value representing the radio to configure. 1936 Rate Set: The AC generates the Rate Set that the WTP is to include 1937 in its Beacon and Probe messages. The length of this field is 1938 between 2 and 8 bytes. The value of this field comes from the 1939 IEEE 802.11 dot11OperationalRateSet MIB element (see 1940 [IEEE.802-11.2007]). 1942 6.12. IEEE 802.11 RSNA Error Report From Station 1944 The IEEE 802.11 RSN Error Report From Station message element is used 1945 by a WTP to send RSN error reports to the AC. The WTP does not need 1946 to transmit any reports that do not include any failures. The fields 1947 from this message element come from the IEEE 802.11 1948 Dot11RSNAStatsEntry table, see [IEEE.802-11.2007]. 1950 0 1 2 3 1951 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 1952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1953 | Client MAC Address | 1954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1955 | Client MAC Address | BSSID | 1956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1957 | BSSID | 1958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1959 | Radio ID | WLAN ID | Reserved | 1960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1961 | TKIP ICV Errors | 1962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1963 | TKIP Local MIC Failures | 1964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1965 | TKIP Remote MIC Failures | 1966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1967 | CCMP Replays | 1968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1969 | CCMP Decrypt Errors | 1970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1971 | TKIP Replays | 1972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1974 Type: 1035 for IEEE 802.11 RSNA Error Report From Station 1976 Length: 40 1978 Client MAC Address: The Client MAC Address of the station. 1980 BSSID: The BSSID on which the failures are being reported on. 1982 Radio ID: The Radio Identifier, typically refers to some interface 1983 index on the WTP 1985 WLAN ID: The WLAN ID on which the RSNA failures are being reported. 1986 The value MUST be between one (1) and 16. 1988 Reserved: All implementations complying with this protocol MUST set 1989 to zero any bits that are reserved in the version of the protocol 1990 supported by that implementation. Receivers MUST ignore all bits 1991 not defined for the version of the protocol they support. 1993 TKIP ICV Errors: A 32-bit value representing the number of Temporal 1994 Key Integrity Protocol (TKIP) (as defined in [IEEE.802-11.2007]) 1995 ICV errors encountered when decrypting packets from the station. 1996 The value of this field comes from the IEEE 802.11 1997 dot11RSNAStatsTKIPICVErrors MIB element (see [IEEE.802-11.2007]). 1999 TKIP Local MIC Failures: A 32-bit value representing the number of 2000 MIC failures encountered when checking the integrity of packets 2001 received from the station. The value of this field comes from the 2002 IEEE 802.11 dot11RSNAStatsTKIPLocalMICFailures MIB element (see 2003 [IEEE.802-11.2007]). 2005 TKIP Remote MIC Failures: A 32-bit value representing the number of 2006 MIC failures reported by the station encountered (possibly via the 2007 EAPOL-Key frame). The value of this field comes from the IEEE 2008 802.11 dot11RSNAStatsTKIPRemoteMICFailures MIB element (see 2009 [IEEE.802-11.2007]). 2011 CCMP Replays: A 32-bit value representing the number of CCMP MPDUs 2012 discarded by the replay detection mechanism. The value of this 2013 field comes from the IEEE 802.11 dot11RSNACCMPReplays MIB element 2014 (see [IEEE.802-11.2007]). 2016 CCMP Decrypt Errors: A 32-bit value representing the number of CCMP 2017 MDPUs discarded by the decryption algorithm. The value of this 2018 field comes from the IEEE 802.11 dot11RSNACCMPDecryptErrors MIB 2019 element (see [IEEE.802-11.2007]). 2021 TKIP Replays: A 32-bit value representing the number of TKIP 2022 Replays detected in frames received from the station. The value 2023 of this field comes from the IEEE 802.11 dot11RSNAStatsTKIPReplays 2024 MIB element (see [IEEE.802-11.2007]). 2026 6.13. IEEE 802.11 Station 2028 The IEEE 802.11 Station message element accompanies the Add Station 2029 message element, and is used to deliver IEEE 802.11 station policy 2030 from the AC to the WTP. 2032 The latest IEEE 802.11 Station message element overrides any 2033 previously received message elements. 2035 If the QoS field is set, the WTP MUST observe and provide policing of 2036 the 802.11e priority tag to ensure that it does not exceed the value 2037 provided by the AC. 2039 0 1 2 3 2040 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 2041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2042 | Radio ID | Association ID | Flags | 2043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2044 | MAC Address | 2045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2046 | MAC Address | Capabilities | 2047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2048 | WLAN ID |Supported Rates| 2049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2051 Type: 1036 for IEEE 802.11 Station 2053 Length: >= 14 2055 Radio ID: An 8-bit value representing the radio 2057 Association ID: A 16-bit value specifying the IEEE 802.11 2058 Association Identifier 2060 Flags: All implementations complying with this protocol MUST set to 2061 zero any bits that are reserved in the version of the protocol 2062 supported by that implementation. Receivers MUST ignore all bits 2063 not defined for the version of the protocol they support. 2065 MAC Address: The station's MAC Address 2067 Capabilities: A 16-bit field containing the IEEE 802.11 2068 Capabilities Information Field to use with the station. 2070 WLAN ID: An 8-bit value specifying the WLAN Identifier. The value 2071 MUST be between one (1) and 16. 2073 Supported Rates: The variable length field containing the supported 2074 rates to be used with the station, as found in the IEEE 802.11 2075 dot11OperationalRateSet MIB element (see [IEEE.802-11.2007]). 2076 This field MUST NOT exceed 126 octets and specifies the set of 2077 data rates at which the station may transmit data, where each 2078 octet represents a data rate. 2080 6.14. IEEE 802.11 Station QoS Profile 2082 The IEEE 802.11 Station QoS Profile message element contains the 2083 maximum IEEE 802.11e priority tag that may be used by the station. 2084 Any packet received that exceeds the value encoded in this message 2085 element MUST be tagged using the maximum value permitted by to the 2086 user. The priority tag MUST be between zero (0) and seven (7). This 2087 message element MUST NOT be present without the IEEE 802.11 Station 2088 (see Section 6.13) message element. 2090 0 1 2 3 2091 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 2092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2093 | MAC Address | 2094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2095 | MAC Address | 802.1p Priority Tag | 2096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2098 Type: 1037 for IEEE 802.11 Station QOS Profile 2100 Length: 8 2102 MAC Address: The station's MAC Address 2104 802.1p Priority Tag: The maximum 802.1p priority value that the WTP 2105 will allow in the Traffic Identifier (TID) field in the extended 2106 802.11e QOS Data header. Only the three least significant bits of 2107 this field are valid, while the remaining bits MUST be set to zero 2108 (0). 2110 6.15. IEEE 802.11 Station Session Key 2112 The IEEE 802.11 Station Session Key message element is sent when the 2113 AC determines that encryption of a station must be performed in the 2114 WTP. This message element MUST NOT be present without the IEEE 2115 802.11 Station (see Section 6.13) message element, and MUST NOT be 2116 sent if the WTP had not specifically advertised support for the 2117 requested encryption scheme, through the WTP Descriptor Message 2118 Element's Encryption Capabilities Field (see Section 8.1). 2120 The RSN information element MUST sent along with the IEEE 802.11 2121 Station Session Key in order to instruct the WTP on the usage of the 2122 Key field. The WTP MUST observe the AKM field of the RSN information 2123 element in order to identify the authentication protocol to be 2124 enforced with the station. 2126 If cryptographic services are provided at the WTP, the WTP MUST 2127 observe the algorithm dictated in the Pairwise Cipher Suite field of 2128 the RSN information element sent by the AC. The RSN Information 2129 Element included here is the one sent by the AC in the third message 2130 of the 4-Way Key Handshake, which specifies which cipher is to be 2131 applied to provide encryption and decryption services with the 2132 station. The RSN Information Element is used to communicate any 2133 supported algorithm, including WEP, TKIP and AES-CCMP. In the case 2134 of static WEP keys, the RSN Information Element is still used to 2135 indicate the cryptographic algorithm even though no key exchange 2136 occurred. 2138 If the IEEE 802.11 Station Session Key message element's AKM-Only bit 2139 is set, the WTP MUST drop all IEEE 802.11 packets that are not part 2140 of the Authentication and Key Management (AKM), such as EAP. Note 2141 that AKM-Only is MAY be set while an encryption key is in force, 2142 requiring that the AKM packets be encrypted. Once the station has 2143 successfully completed authentication via the AKM, the AC MUST send a 2144 new Add Station message element to remove the AKM-Only restriction, 2145 and optionally push the session key down to the WTP. 2147 0 1 2 3 2148 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 2149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2150 | MAC Address | 2151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2152 | MAC Address |A|C| Flags | 2153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2154 | Pairwise TSC | 2155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2156 | Pairwise TSC | Pairwise RSC | 2157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2158 | Pairwise RSC | 2159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2160 | Key... 2161 +-+-+-+-+-+-+-+- 2163 Type: 1038 for IEEE 802.11 Station Session Key 2165 Length: >= 25 2167 MAC Address: The station's MAC Address 2169 Flags: All implementations complying with this protocol MUST set to 2170 zero any bits that are reserved in the version of the protocol 2171 supported by that implementation. Receivers MUST ignore all bits 2172 not defined for the version of the protocol they support. The 2173 following bits are defined: 2175 A: The one bit AKM-Only field is set by the AC to inform the WTP 2176 that is MUST NOT accept any 802.11 data frames, other than AKM 2177 frames. This is the equivalent of the WTP's IEEE 802.1X port 2178 for the station to be in the closed state. When set, the WTP 2179 MUST drop any non-IEEE 802.1X packets it receives from the 2180 station. 2182 C: The one bit field is set by the AC to inform the WTP that 2183 encryption services will be provided by the AC. When set, the 2184 WTP SHOULD police frames received from stations to ensure that 2185 are properly encrypted as specified in the RSN Information 2186 Element, but does not need to take specific cryptographic 2187 action on the frame. Similarly, for transmitted frames, the 2188 WTP only needs to forward already encrypted frames. Since 2189 packets received by the WTP will be encrypted, the WTP cannot 2190 modify the contents of the packets, including modifying the 2191 DSCP markings of the encapsulated packet. In this case, this 2192 function would be the responsibility of the AC. 2194 Pairwise TSC: The 6 byte Transmit Sequence Counter (TSC) field to 2195 use for unicast packets transmitted to the station. 2197 Pairwise RSC: The 6 byte Receive Sequence Counter (RSC) to use for 2198 unicast packets received from the station. 2200 Key: The key the WTP is to use when encrypting traffic to/from the 2201 station. For dynamically created keys, such as those used with 2202 WPA and RSN, this is commonly known as a Pairwise Transient Key 2203 (PTK). For static keys, such as those used in WEP, the Key field 2204 contains the actual encryption key. 2206 6.16. IEEE 802.11 Statistics 2208 The IEEE 802.11 Statistics message element is sent by the WTP to 2209 transmit its current statistics, and contains the following fields. 2210 All of the fields in this message element are set to zero upon WTP 2211 initialization. The fields will roll over when they reach their 2212 maximum value of 4294967295. Due to the nature of each counter 2213 representing different data points, the roll over event will vary 2214 greatly across each field. Applications or human operators using 2215 these counters need to be aware about the minimal possible times 2216 between rollover events in order to make sure that no consecutive 2217 rollover events are missed. 2219 0 1 2 3 2220 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 2221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2222 | Radio ID | Reserved | 2223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2224 | Tx Fragment Count | 2225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2226 | Multicast Tx Count | 2227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2228 | Failed Count | 2229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2230 | Retry Count | 2231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2232 | Multiple Retry Count | 2233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2234 | Frame Duplicate Count | 2235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2236 | RTS Success Count | 2237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2238 | RTS Failure Count | 2239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2240 | ACK Failure Count | 2241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2242 | Rx Fragment Count | 2243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2244 | Multicast RX Count | 2245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2246 | FCS Error Count | 2247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2248 | Tx Frame Count | 2249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2250 | Decryption Errors | 2251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2252 | Discarded QoS Fragment Count | 2253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2254 | Associated Station Count | 2255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2256 | QoS CF Polls Received Count | 2257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2258 | QoS CF Polls Unused Count | 2259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2260 | QoS CF Polls Unusable Count | 2261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2263 Type: 1039 for IEEE 802.11 Statistics 2265 Length: 80 2267 Radio ID: An 8-bit value representing the radio. 2269 Reserved: All implementations complying with this protocol MUST set 2270 to zero any bits that are reserved in the version of the protocol 2271 supported by that implementation. Receivers MUST ignore all bits 2272 not defined for the version of the protocol they support. 2274 Tx Fragment Count: A 32-bit value representing the number of 2275 fragmented frames transmitted. The value of this field comes from 2276 the IEEE 802.11 dot11TransmittedFragmentCount MIB element (see 2277 [IEEE.802-11.2007]). 2279 Multicast Tx Count: A 32-bit value representing the number of 2280 multicast frames transmitted. The value of this field comes from 2281 the IEEE 802.11 dot11MulticastTransmittedFrameCount MIB element 2282 (see [IEEE.802-11.2007]). 2284 Failed Count: A 32-bit value representing the transmit excessive 2285 retries. The value of this field comes from the IEEE 802.11 2286 dot11FailedCount MIB element (see [IEEE.802-11.2007]). 2288 Retry Count: A 32-bit value representing the number of transmit 2289 retries. The value of this field comes from the IEEE 802.11 2290 dot11RetryCount MIB element (see [IEEE.802-11.2007]). 2292 Multiple Retry Count: A 32-bit value representing the number of 2293 transmits that required more than one retry. The value of this 2294 field comes from the IEEE 802.11 dot11MultipleRetryCount MIB 2295 element (see [IEEE.802-11.2007]). 2297 Frame Duplicate Count: A 32-bit value representing the duplicate 2298 frames received. The value of this field comes from the IEEE 2299 802.11 dot11FrameDuplicateCount MIB element (see 2300 [IEEE.802-11.2007]). 2302 RTS Success Count: A 32-bit value representing the number of 2303 successfully transmitted Ready To Send (RTS). The value of this 2304 field comes from the IEEE 802.11 dot11RTSSuccessCount MIB element 2305 (see [IEEE.802-11.2007]). 2307 RTS Failure Count: A 32-bit value representing the failed 2308 transmitted RTS. The value of this field comes from the IEEE 2309 802.11 dot11RTSFailureCount MIB element (see [IEEE.802-11.2007]). 2311 ACK Failure Count: A 32-bit value representing the number of failed 2312 acknowledgements. The value of this field comes from the IEEE 2313 802.11 dot11ACKFailureCount MIB element (see [IEEE.802-11.2007]). 2315 Rx Fragment Count: A 32-bit value representing the number of 2316 fragmented frames received. The value of this field comes from 2317 the IEEE 802.11 dot11ReceivedFragmentCount MIB element (see 2318 [IEEE.802-11.2007]). 2320 Multicast RX Count: A 32-bit value representing the number of 2321 multicast frames received. The value of this field comes from the 2322 IEEE 802.11 dot11MulticastReceivedFrameCount MIB element (see 2323 [IEEE.802-11.2007]). 2325 FCS Error Count: A 32-bit value representing the number of FCS 2326 failures. The value of this field comes from the IEEE 802.11 2327 dot11FCSErrorCount MIB element (see [IEEE.802-11.2007]). 2329 Decryption Errors: A 32-bit value representing the number of 2330 Decryption errors that occurred on the WTP. Note that this field 2331 is only valid in cases where the WTP provides encryption/ 2332 decryption services. The value of this field comes from the IEEE 2333 802.11 dot11WEPUndecryptableCount MIB element (see 2334 [IEEE.802-11.2007]). 2336 Discarded QoS Fragment Count: A 32-bit value representing the 2337 number of discarded QoS fragments received. The value of this 2338 field comes from the IEEE 802.11 dot11QoSDiscardedFragmentCount 2339 MIB element (see [IEEE.802-11.2007]). 2341 Associated Station Count: A 32-bit value representing the number of 2342 number of associated stations. The value of this field comes from 2343 the IEEE 802.11 dot11AssociatedStationCount MIB element (see 2344 [IEEE.802-11.2007]). 2346 QoS CF Polls Received Count: A 32-bit value representing the number 2347 of (+)CF-Polls received. The value of this field comes from the 2348 IEEE 802.11 dot11QosCFPollsReceivedCount MIB element (see 2349 [IEEE.802-11.2007]). 2351 QoS CF Polls Unused Count: A 32-bit value representing the number 2352 of (+)CF-Polls that have been received, but not used. The value 2353 of this field comes from the IEEE 802.11 2354 dot11QosCFPollsUnusedCount MIB element (see [IEEE.802-11.2007]). 2356 QoS CF Polls Unusable Count: A 32-bit value representing the number 2357 of (+)CF-Polls that have been received, but could not be used due 2358 to the Transmission Opportunity (TXOP) size being smaller than the 2359 time that is required for one frame exchange sequence. The value 2360 of this field comes from the IEEE 802.11 2361 dot11QosCFPollsUnusableCount MIB element (see [IEEE.802-11.2007]). 2363 6.17. IEEE 802.11 Supported Rates 2365 The IEEE 802.11 Supported Rates message element is sent by the WTP to 2366 indicate the rates that it supports, and contains the following 2367 fields. 2369 0 1 2 3 2370 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 2371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2372 | Radio ID | Supported Rates... 2373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2375 Type: 1040 for IEEE 802.11 Supported Rates 2377 Length: >= 3 2379 Radio ID: An 8-bit value representing the radio. 2381 Supported Rates: The WTP includes the Supported Rates that its 2382 hardware supports. The format is identical to the Rate Set 2383 message element and is between 2 and 8 bytes in length. 2385 6.18. IEEE 802.11 Tx Power 2387 The IEEE 802.11 Tx Power message element value is bi-directional. 2388 When sent by the WTP, it contains the current power level of the 2389 radio in question. When sent by the AC, it contains the power level 2390 the WTP MUST adhere to. 2392 0 1 2 3 2393 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 2394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2395 | Radio ID | Reserved | Current Tx Power | 2396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2398 Type: 1041 for IEEE 802.11 Tx Power 2400 Length: 4 2401 Radio ID: An 8-bit value representing the radio to configure. 2403 Reserved: All implementations complying with this protocol MUST set 2404 to zero any bits that are reserved in the version of the protocol 2405 supported by that implementation. Receivers MUST ignore all bits 2406 not defined for the version of the protocol they support. 2408 Current Tx Power: This attribute contains the current transmit 2409 output power in mW, as described in the dot11CurrentTxPowerLevel 2410 MIB variable, see [IEEE.802-11.2007]. 2412 6.19. IEEE 802.11 Tx Power Level 2414 The IEEE 802.11 Tx Power Level message element is sent by the WTP and 2415 contains the different power levels supported. The values found in 2416 this message element are found in the IEEE 802.11 2417 Dot11PhyTxPowerEntry MIB table, see [IEEE.802-11.2007]. 2419 The value field contains the following: 2421 0 1 2 3 2422 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 2423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2424 | Radio ID | Num Levels | Power Level [n] | 2425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2427 Type: 1042 for IEEE 802.11 Tx Power Level 2429 Length: >= 4 2431 Radio ID: An 8-bit value representing the radio to configure. 2433 Num Levels: The number of power level attributes. The value of 2434 this field comes from the IEEE 802.11 2435 dot11NumberSupportedPowerLevels MIB element (see 2436 [IEEE.802-11.2007]). 2438 Power Level: Each power level fields contains a supported power 2439 level, in mW. The value of this field comes from the 2440 corresponding IEEE 802.11 dot11TxPowerLevel[n] MIB element, see 2441 [IEEE.802-11.2007]. 2443 6.20. IEEE 802.11 Update Station QoS 2445 The IEEE 802.11 Update Station QoS message element is used to change 2446 the Quality of Service policy on the WTP for a given station. The 2447 QoS tags included in this message element are to be applied to 2448 packets received at the WTP from the station indicated through the 2449 MAC Address field. This message element overrides the default values 2450 provided through the IEEE 802.11 WTP Quality of Service message 2451 element (see Section 6.22). Any tagging performed by the WTP MUST be 2452 directly applied to the packets receive from the station, as well as 2453 the CAPWAP tunnel, if the packets are tunneled to the AC. See 2454 Section 2.6 for more information. 2456 0 1 2 3 2457 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 2458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2459 | Radio ID | MAC Address | 2460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2461 | MAC Address | QoS Sub-Element... | 2462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2464 Type: 1043 for IEEE 802.11 Update Station QoS 2466 Length: 8 2468 Radio ID: The Radio Identifier, typically refers to some interface 2469 index on the WTP 2471 MAC Address: The station's MAC Address. 2473 QoS Sub-Element: The IEEE 802.11 WTP Quality of Service message 2474 element contains four QoS sub-elements, one for every QoS profile. 2475 The order of the QoS profiles are Voice, Video, Best Effort and 2476 Background. 2478 0 1 2479 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2481 | Reserved|8021p|RSV| DSCP Tag | 2482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2484 Reserved: All implementations complying with this protocol MUST 2485 set to zero any bits that are reserved in the version of the 2486 protocol supported by that implementation. Receivers MUST 2487 ignore all bits not defined for the version of the protocol 2488 they support. 2490 8021p: The three bit 802.1p priority value to use if packets are 2491 to be IEEE 802.1p tagged. This field is used only if the 'P' 2492 bit in the WTP Quality of Service message element was set; 2493 otherwise, its contents MUST be ignored. 2495 RSV: All implementations complying with this protocol MUST set 2496 to zero any bits that are reserved in the version of the 2497 protocol supported by that implementation. Receivers MUST 2498 ignore all bits not defined for the version of the protocol 2499 they support. 2501 DSCP Tag: The 6 bit DSCP label to use if packets are eligible to 2502 be DSCP tagged, specifically an IPv4 or IPv6 packet (see 2503 [RFC2474]). This field is used only if the 'D' bit in the WTP 2504 Quality of Service message element was set; otherwise, its 2505 contents MUST be ignored. 2507 6.21. IEEE 802.11 Update WLAN 2509 The IEEE 802.11 Update WLAN message element is used by the AC to 2510 define a wireless LAN on the WTP. The inclusion of this message 2511 element MUST also include the IEEE 802.11 Information Element message 2512 element, containing the following 802.11 IEs: 2514 Power Constraint information element 2516 WPA information element [WPA] 2518 RSN information element 2520 EDCA Parameter Set information element 2522 QoS Capability information element 2524 WMM information element [WMM] 2526 These IEEE 802.11 information elements are stored by the WTP and 2527 included in any Probe Responses and Beacons generated, as specified 2528 in the IEEE 802.11 standard [IEEE.802-11.2007]. 2530 If cryptographic services are provided at the WTP, the WTP MUST 2531 observe the algorithm dictated in the Group Cipher Suite field of the 2532 RSN information element sent by the AC. The RSN Information Element 2533 is used to communicate any supported algorithm, including WEP, TKIP 2534 and AES-CCMP. In the case of static WEP keys, the RSN Information 2535 Element is still used to indicate the cryptographic algorithm even 2536 though no key exchange occurred. 2538 The message element uses the following format: 2540 0 1 2 3 2541 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 2542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2543 | Radio ID | WLAN ID | Capability | 2544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2545 | Key Index | Key Status | Key Length | 2546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2547 | Key... | 2548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2550 Type: 1044 for IEEE 802.11 Update WLAN 2552 Length: >= 8 2554 Radio ID: An 8-bit value representing the radio. 2556 WLAN ID: An 8-bit value specifying the WLAN Identifier. The value 2557 MUST be between one (1) and 16. 2559 Capability: A 16-bit value containing the capability information 2560 field to be advertised by the WTP in the Probe Request and Beacon 2561 frames. Each bit of the Capability field represents a different 2562 WTP capability, which are described in detail in 2563 [IEEE.802-11.2007]. The format of the field is: 2565 0 1 2566 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2568 |E|I|C|F|P|S|B|A|M|Q|T|D|V|O|K|L| 2569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2571 E (ESS): The AC MUST set the Extended Service Set (ESS) subfield 2572 to 1. 2574 I (IBSS): The AC MUST set the Independent Basic Service Set 2575 (IBSS) subfield to 0. 2577 C (CF-Pollable): The AC sets the Contention Free Pollable (CF- 2578 Pollable) subfield based on the table found in 2579 [IEEE.802-11.2007]. 2581 F (CF-Poll Request): The AC sets the CF-Poll Request subfield 2582 based on the table found in [IEEE.802-11.2007]. 2584 P (Privacy): The AC sets the Privacy subfield based on the 2585 confidentiality requirements of the WLAN, as defined in 2586 [IEEE.802-11.2007]. 2588 S (Short Preamble): The AC sets the Short Preamble subfield 2589 based on whether the use of short preambles are permitted on 2590 the WLAN, as defined in [IEEE.802-11.2007]. 2592 B (PBCC): The AC sets the Packet Binary Convolutional Code 2593 (PBCC) modulation option subfield based on whether the use of 2594 PBCC is permitted on the WLAN, as defined in 2595 [IEEE.802-11.2007]. 2597 A (Channel Agility): The AC sets the Channel Agility subfield 2598 based on whether the WTP is capable of supporting the High Rate 2599 Direct Sequence Spread Spectrum (HR/DSSS), as defined in 2600 [IEEE.802-11.2007]. 2602 M (Spectrum Management): The AC sets the Spectrum Management 2603 subfield according to the value of the 2604 dot11SpectrumManagementRequired MIB variable, as defined in 2605 [IEEE.802-11.2007]. 2607 Q (QOS): The AC sets the Quality of Service (QOS) subfield based 2608 on the table found in [IEEE.802-11.2007]. 2610 T (Short Slot Time): The AC sets the Short Slot Timesubfield 2611 according to the value of the WTP's currently used slot time 2612 value, as defined in [IEEE.802-11.2007]. 2614 D (APSD): The AC sets the APSD subfield according to the value 2615 of the dot11APSDOptionImplemented Management Information Base 2616 (MIB) variable, as defined in [IEEE.802-11.2007]. 2618 V (Reserved): The AC sets the Reserved subfield to zero, as 2619 defined in [IEEE.802-11.2007]. 2621 O (DSSS-OFDM): The AC sets the DSSS-OFDM subfield to indicate 2622 the use of Direct Sequence Spread Spectrum with Orthogonal 2623 Frequency Division Multiplexing (DSSS-OFDM), as defined in 2624 [IEEE.802-11.2007]. 2626 K (Delayed Block ACK): The AC sets the Delayed Block ACK 2627 subfield according to the value of the 2628 dot11DelayedBlockAckOptionImplemented MIB variable, as defined 2629 in [IEEE.802-11.2007]. 2631 L (Immediate Block ACK): The AC sets the Delayed Block ACK 2632 subfield according to the value of the 2633 dot11ImmediateBlockAckOptionImplemented MIB variable, as 2634 defined in [IEEE.802-11.2007]. 2636 Key-Index: The Key Index associated with the key. 2638 Key Status: A 1 byte value that specifies the state and usage of 2639 the key that has been included. The following values describe the 2640 key usage and its status: 2642 0 - A value of zero, with the inclusion of the RSN Information 2643 Element means that the WLAN uses per-station encryption keys, 2644 and therefore the key in the 'Key' field is only used for 2645 multicast traffic. 2647 1 - When set to one, the WLAN employs a shared WEP key, also 2648 known as a static WEP key, and uses the encryption key for both 2649 unicast and multicast traffic for all stations. 2651 2 - The value of 2 indicates that the AC will begin rekeying the 2652 GTK with the STA's in the BSS. It is only valid when IEEE 2653 802.11 is enabled as the security policy for the BSS. 2655 3 - The value of 3 indicates that the AC has completed rekeying 2656 the GTK and broadcast packets no longer need to be duplicated 2657 and transmitted with both GTK's. 2659 Key Length: A 16-bit value representing the length of the Key 2660 field. 2662 Key: A Session Key, whose length is known via the key length field, 2663 used to provide data privacy. For static WEP keys, which is true 2664 when the 'Key Status' bit is set to one, this key is used for both 2665 unicast and multicast traffic. For encryption schemes that employ 2666 a separate encryption key for unicast and multicast traffic, the 2667 key included here only applies to multicast data, and the cipher 2668 suite is specified in an accompanied RSN Information Element. In 2669 these scenarios, the key, and cipher information, is communicated 2670 via the Add Station message element, see Section 4.6.8 in 2671 [I-D.ietf-capwap-protocol-specification]. 2673 6.22. IEEE 802.11 WTP Quality of Service 2675 The IEEE 802.11 WTP Quality of Service message element value is sent 2676 by the AC to the WTP to communicate quality of service configuration 2677 information. The QoS tag included in this message element are the 2678 default QoS values to be applied to packets received by the WTP from 2679 stations on a particular radio. Any tagging performed by the WTP 2680 MUST be directly applied to the packets receive from the station, as 2681 well as the CAPWAP tunnel, if the packets are tunneled to the AC. 2682 See Section 2.6 for more information. 2684 0 1 2 3 2685 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 2686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2687 | Radio ID |Tagging Policy | QoS Sub-Element ... 2688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2690 Type: 1045 for IEEE 802.11 WTP Quality of Service 2692 Length: 34 2694 Radio ID: The Radio Identifier, typically refers to some interface 2695 index on the WTP 2697 Tagging Policy: A bit field indicating how the WTP is to mark 2698 packets for QoS purposes. The required WTP behavior is defined in 2699 Section 2.6.1. The field has the following format: 2701 0 1 2 3 4 5 6 7 2702 +-+-+-+-+-+-+-+-+ 2703 |Rsvd |P|Q|D|O|I| 2704 +-+-+-+-+-+-+-+-+ 2706 Rsvd: A set of reserved bits for future use. All implementations 2707 complying with this protocol MUST set to zero any bits that are 2708 reserved in the version of the protocol supported by that 2709 implementation. Receivers MUST ignore all bits not defined for 2710 the version of the protocol they support. 2712 P: When set, the WTP is to employ the 802.1p QoS mechanism (see 2713 Section 2.6.1.1), and the WTP is to use the 'Q' bit. 2715 Q: When the 'P' bit is set, the 'Q' bit is used by the AC to 2716 communicate to the WTP how 802.1p QoS is to be enforced. 2717 Details on the behavior of the 'Q' bit is specified in 2718 Section 2.6.1.1. 2720 D: When set, the WTP is to employ the DSCP QoS mechanism (see 2721 Section 2.6.1.2), and the WTP is to use the 'O' and 'I' bits. 2723 O: When the 'D' bit is set, the 'O' bit is used by the AC to 2724 communicate to the WTP how DSCP QoS is to be enforced on the 2725 outer (tunneled) header. Details on the behavior of the 'O' 2726 bit is specified in Section 2.6.1.2. 2728 I: When the 'D' bit is set, the 'I' bit is used by the AC to 2729 communicate to the WTP how DSCP QoS is to be enforced on the 2730 station's packet (inner) header. Details on the behavior of 2731 the 'I' bit is specified in Section 2.6.1.2. 2733 QoS Sub-Element: The IEEE 802.11 WTP Quality of Service message 2734 element contains four QoS sub-elements, one for every QoS profile. 2735 The order of the QoS profiles are Voice, Video, Best Effort and 2736 Background. 2738 0 1 2 3 2739 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 2740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2741 | Queue Depth | CWMin | CWMax | 2742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2743 | CWMax | AIFS | Reserved|8021p|RSV| DSCP Tag | 2744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2746 Queue Depth: The number of packets that can be on the specific 2747 QoS transmit queue at any given time. 2749 CWMin: The Contention Window minimum (CWmin) value for the QoS 2750 transmit queue. The value of this field comes from the IEEE 2751 802.11 dot11EDCATableCWMin MIB element (see 2752 [IEEE.802-11.2007]). 2754 CWMax: The Contention Window maximum (CWmax) value for the QoS 2755 transmit queue. The value of this field comes from the IEEE 2756 802.11 dot11EDCATableCWMax MIB element (see 2757 [IEEE.802-11.2007]). 2759 AIFS: The Arbitration Inter Frame Spacing (AIFS) to use for the 2760 QoS transmit queue. The value of this field comes from the 2761 IEEE 802.11 dot11EDCATableAIFSN MIB element (see 2762 [IEEE.802-11.2007]). 2764 Reserved: All implementations complying with this protocol MUST 2765 set to zero any bits that are reserved in the version of the 2766 protocol supported by that implementation. Receivers MUST 2767 ignore all bits not defined for the version of the protocol 2768 they support. 2770 8021p: The three bit 802.1p priority value to use if packets are 2771 to be IEEE 802.1p tagged. This field is used only if the 'P' 2772 bit is set; otherwise, its contents MUST be ignored. 2774 RSV: All implementations complying with this protocol MUST set 2775 to zero any bits that are reserved in the version of the 2776 protocol supported by that implementation. Receivers MUST 2777 ignore all bits not defined for the version of the protocol 2778 they support. 2780 DSCP Tag: The 6 bit DSCP label to use if packets are eligible to 2781 be DSCP tagged, specifically an IPv4 or IPv6 packet (see 2782 [RFC2474]). This field is used only if the 'D' bit is set; 2783 otherwise, its contents MUST be ignored. 2785 6.23. IEEE 802.11 WTP Radio Configuration 2787 The IEEE 802.11 WTP WLAN Radio Configuration message element is used 2788 by the AC to configure a Radio on the WTP, and by the WTP to deliver 2789 its radio configuration to the AC. The message element value 2790 contains the following fields: 2792 0 1 2 3 2793 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 2794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2795 | Radio ID |Short Preamble| Num of BSSIDs | DTIM Period | 2796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2797 | BSSID | 2798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2799 | BSSID | Beacon Period | 2800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2801 | Country String | 2802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2804 Type: 1046 for IEEE 802.11 WTP WLAN Radio Configuration 2806 Length: 16 2808 Radio ID: An 8-bit value representing the radio to configure. 2810 Short Preamble: An 8-bit value indicating whether short preamble is 2811 supported. The following enumerated values are currently 2812 supported: 2814 0 - Short preamble not supported. 2816 1 - Short preamble is supported. 2818 BSSID: The WLAN Radio's base MAC Address. 2820 Number of BSSIDs: This attribute contains the maximum number of 2821 BSSIDs supported by the WTP. This value restricts the number of 2822 logical networks supported by the WTP, and is between 1 and 16. 2824 DTIM Period: This attribute specifies the number of beacon 2825 intervals that elapse between transmission of Beacons frames 2826 containing a Traffic Indication Map (TIM) element whose Delivery 2827 Traffic Indication Message (DTIM) Count field is 0. This value is 2828 transmitted in the DTIM Period field of Beacon frames. The value 2829 of this field comes from the IEEE 802.11 dot11DTIMPeriod MIB 2830 element (see [IEEE.802-11.2007]). 2832 Beacon Period: This attribute specifies the number of Time Unit 2833 (TU) that a station uses for scheduling Beacon transmissions. 2834 This value is transmitted in Beacon and Probe Response frames. 2835 The value of this field comes from the IEEE 802.11 2836 dot11BeaconPeriod MIB element (see [IEEE.802-11.2007]). 2838 Country String: This attribute identifies the country in which the 2839 station is operating. The value of this field comes from the IEEE 2840 802.11 dot11CountryString MIB element (see [IEEE.802-11.2007]). 2841 Some regulatory domains do not allow WTPs to have user 2842 configurable country string, and require that it be a fixed value 2843 during the manufacturing process. Therefore, WTP vendors that 2844 wish to allow for the configuration of this field will need to 2845 validate this behavior during its radio certification process. 2846 Other WTP vendors may simply wish to treat this WTP configuration 2847 parameter as read-only. The country strings can be found in 2848 [ISO.3166-1]. 2850 The WTP and AC MAY ignore the value of this field, depending upon 2851 regulatory requirements, for example to avoid classification as a 2852 Software Defined Radio. When this field is used, the first two 2853 octets of this string is the two character country string as 2854 described in document [ISO.3166-1], and the third octet MUST have 2855 the value 1, 2 or 3 as defined below. When the value of the third 2856 octet is 255, the country string field is not used, and MUST be 2857 ignored. 2859 1. an ASCII space character, if the regulations under which the 2860 station is operating encompass all environments in the country, 2862 2. an ASCII 'O' character, if the regulations under which the 2863 station is operating are for an outdoor environment only, or 2865 3. an ASCII 'I' character, if the regulations under which the 2866 station is operating are for an indoor environment only. 2868 4. an ASCII 'X' character, if the station is operating under a 2869 non-country entity. The first two octets of the non-country 2870 entity shall be two ASCII 'XX' characters. 2872 Note that the last byte of the Country String MUST be set to NULL. 2874 6.24. IEEE 802.11 WTP Radio Fail Alarm Indication 2876 The IEEE 802.11 WTP Radio Fail Alarm Indication message element is 2877 sent by the WTP to the AC when it detects a radio failure. 2879 0 1 2 3 2880 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 2881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2882 | Radio ID | Type | Status | Pad | 2883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2885 Type: 1047 for IEEE 802.11 WTP Radio Fail Alarm Indication 2887 Length: 4 2889 Radio ID: The Radio Identifier, typically refers to some interface 2890 index on the WTP 2892 Type: The type of radio failure detected. The following enumerated 2893 values are supported: 2895 1 - Receiver 2897 2 - Transmitter 2899 Status: An 8-bit boolean indicating whether the radio failure is 2900 being reported or cleared. A value of zero is used to clear the 2901 event, while a value of one is used to report the event. 2903 Pad: All implementations complying with version zero of this 2904 protocol MUST set these bits to zero. Receivers MUST ignore all 2905 bits not defined for the version of the protocol they support. 2907 6.25. IEEE 802.11 WTP Radio Information 2909 The IEEE 802.11 WTP Radio Information message element is used to 2910 communicate the radio information for each IEEE 802.11 radio in the 2911 WTP. The Discovery Request message, Primary Discovery Request 2912 message and Join Request message MUST include one such message 2913 element per radio in the WTP. The Radio-Type field is used by the AC 2914 in order to determine which IEEE 802.11 technology specific binding 2915 is to be used with the WTP. 2917 The message element contains two fields, as shown below. 2919 0 1 2 3 2920 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 2921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2922 | Radio ID | Radio Type | 2923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2924 | Radio Type | 2925 +-+-+-+-+-+-+-+-+ 2927 Type: 1048 for IEEE 802.11 WTP Radio Information 2929 Length: 5 2931 Radio ID: The Radio Identifier, which typically refers to an 2932 interface index on the WTP 2934 Radio Type: The type of radio present. Note this is a bit field 2935 which is used to specify support for more than a single type of 2936 PHY/MAC. The field has the following format: 2938 0 1 2 3 4 5 6 7 2939 +-+-+-+-+-+-+-+-+ 2940 |Reservd|N|G|A|B| 2941 +-+-+-+-+-+-+-+-+ 2943 Reservd: A set of reserved bits for future use. All 2944 implementations complying with this protocol MUST set to zero 2945 any bits that are reserved in the version of the protocol 2946 supported by that implementation. Receivers MUST ignore all 2947 bits not defined for the version of the protocol they support. 2949 N: An IEEE 802.11n radioP. 2951 G: An IEEE 802.11g radio. 2953 A: An IEEE 802.11a radio. 2955 B: An IEEE 802.11b radio. 2957 7. IEEE 802.11 Binding WTP Saved Variables 2959 This section contains the IEEE 802.11 binding specific variables that 2960 SHOULD be saved in non-volatile memory on the WTP. 2962 7.1. IEEE80211AntennaInfo 2964 The WTP per radio antenna configuration, defined in Section 6.2. 2966 7.2. IEEE80211DSControl 2968 The WTP per radio Direct Sequence Control configuration, defined in 2969 Section 6.5. 2971 7.3. IEEE80211MACOperation 2973 The WTP per radio MAC Operation configuration, defined in 2974 Section 6.7. 2976 7.4. IEEE80211OFDMControl 2978 The WTP per radio OFDM MAC Operation configuration, defined in 2979 Section 6.10. 2981 7.5. IEEE80211Rateset 2983 The WTP per radio Basic Rate Set configuration, defined in 2984 Section 6.11. 2986 7.6. IEEE80211TxPower 2988 The WTP per radio Transmit Power configuration, defined in 2989 Section 6.18. 2991 7.7. IEEE80211QoS 2993 The WTP per radio Quality of Service configuration, defined in 2994 Section 6.22. 2996 7.8. IEEE80211RadioConfig 2998 The WTP per radio Radio Configuration, defined in Section 6.23. 3000 8. Technology Specific Message Element Values 3002 This section lists IEEE 802.11 specific values for the generic CAPWAP 3003 message elements which include fields whose values are technology 3004 specific. 3006 8.1. WTP Descriptor Message Element, Encryption Capabilities Field: 3008 This specification defines two new bits for the WTP Descriptor's 3009 Encryption Capabilities field, as defined in 3010 [I-D.ietf-capwap-protocol-specification]. Note that only the bits 3011 defined in this specification are described below. The format of the 3012 Encryption Capabilities Field is: 3014 0 1 2 3 4 5 6 7 3015 +-+-+-+-+-+-+-+-+ 3016 | |A|T| | 3017 +-+-+-+-+-+-+-+-+ 3019 A: WTP supports AES-CCMP, as defined in [IEEE.802-11.2007]. 3021 T: WTP supports TKIP and Michael, as defined in [IEEE.802-11.2007] 3022 and [WPA], respectively. 3024 9. Security Considerations 3026 This section describes security considerations for using IEEE 802.11 3027 with the CAPWAP protocol. 3029 9.1. IEEE 802.11 Security 3031 When used with an IEEE 802.11 infrastructure with WEP encryption, the 3032 CAPWAP protocol does not add any new vulnerabilities. Derived 3033 session keys between the STA and WTP can be compromised, resulting in 3034 many well-documented attacks. Implementers SHOULD discourage the use 3035 of WEP and encourage use of technically sound cryptographic solutions 3036 such as those in an IEEE 802.11 RSN. 3038 STA authentication is performed using IEEE 802.lX, and consequently 3039 EAP. Implementers SHOULD use EAP methods meeting the requirements 3040 specified [RFC4017]. 3042 When used with IEEE 802.11 RSN security, the CAPWAP protocol may 3043 introduce new vulnerabilities, depending on whether the link security 3044 (packet encryption and integrity verification) is provided by the WTP 3045 or the AC. When the link security function is provided by the AC, no 3046 new security concerns are introduced. 3048 However, when the WTP provides link security, a new vulnerability 3049 will exist when the following conditions are true: 3051 o The client is not the first to associate to the WTP/ESSID (i.e. 3052 other clients are associated), and a GTK already exists 3054 o traffic has been broadcast under the existing GTK 3056 Under these circumstances, the receive sequence counter (KeyRSC) 3057 associated with the GTK is non-zero, but because the AC anchors the 3058 4-way handshake with the client, the exact value of the KeyRSC is not 3059 known when the AC constructs the message containing the GTK. The 3060 client will update its Key RSC value to the current valid KeyRSC upon 3061 receipt of a valid multicast/broadcast message, but prior to this, 3062 previous multicast/broadcast traffic which was secured with the 3063 existing GTK may be replayed, and the client will accept this traffic 3064 as valid. 3066 Typically, busy networks will produce numerous multicast or broadcast 3067 frames per second, so the window of opportunity with respect to such 3068 replay is expected to be very small. In most conditions, it is 3069 expected that replayed frames could be detected (and logged) by the 3070 WTP. 3072 The only way to completely close this window is to provide the exact 3073 KeyRSC value in message 3 of the 4-way handshake; any other approach 3074 simply narrows the window to varying degrees. Given the low relative 3075 threat level this presents, the additional complexity introduced by 3076 providing the exact KeyRSC value is not warranted. That is, this 3077 specification provides for a calculated risk in this regard. 3079 The AC SHOULD use an RSC of 0 when computing message-3 of the 4-way 3080 802.11i handshake, unless the AC has knowledge of a more optimal RSC 3081 value to use. Mechanisms for determining a more optimal RSC value 3082 are outside the scope of this specification. 3084 10. IANA Considerations 3086 This section details the actions to be taken by IANA during the 3087 publication of the specification. There are numerous registries that 3088 need to be created, and the contents, document action (see [RFC5226], 3089 and registry format are all included below. Note that in cases where 3090 bit fields are referred to, the bit numbering is left to right, where 3091 the leftmost bit is labelled as bit zero (0). 3093 10.1. CAPWAP Wireless Binding Identifier 3095 This specification requires a value assigned from the Wireless 3096 Binding Identifier namespace, defined in 3097 [I-D.ietf-capwap-protocol-specification]. The value assigned is to 3098 be added to Section 2.1. The value of one (1)is highly recommended, 3099 as it is used in implementations. 3101 10.2. CAPWAP IEEE 802.11 Message Types 3103 This document creates a new sub-registry to the existing CAPWAP 3104 Message Type registry, which is defined in 3105 [I-D.ietf-capwap-protocol-specification]. 3107 IANA will create and maintain the CAPWAP IEEE 802.11 Message Types 3108 sub-registry for all message types whose Enterprise Number is set to 3109 13277. The namespace is 32 bits (0-4294967295), where the values 3110 3398911 and 3398912 are reserved and must not be assigned. The 3111 values 3398913 and 3398914 are allocated in this specification, and 3112 can be found in Section 3. Any new assignments of a CAPWAP IEEE 3113 802.11 Message Type, whose Enterprise Number is set to 13277) 3114 requires a Expert Review. The format of the registry to be 3115 maintained by IANA has the following format: 3117 CAPWAP IEEE 802.11 Message Type Reference 3118 Control Message Value 3120 10.3. CAPWAP Message Element Type 3122 This specification defines new values to be registered to the 3123 existing CAPWAP Message Element Type registry, defined in 3124 [I-D.ietf-capwap-protocol-specification]. The values used in this 3125 document, 1024 through 1048, as listed in Figure 8 are recommended as 3126 implementations already exist that make use of these values. 3128 10.4. IEEE 802.11 Key Status 3130 The Key Status field in the IEEE 802.11 Add WLAN message element (see 3131 Section 6.1) and IEEE 802.11 Update WLAN message element (see 3132 Section 6.21) is used to provide information about the status of the 3133 keying exchange. This document defines four values, and the 3134 remaining values are controlled and maintained by IANA and requires a 3135 Expert Review. 3137 10.5. IEEE 802.11 QoS 3139 The QoS field in the IEEE 802.11 Add WLAN message element (see 3140 Section 6.1) is used to configure a QoS policy for the WLAN. The 3141 namespace is 8 bits (0-255), where the values zero (0) through four 3142 (4) are allocated in this specification, and can be found in 3143 Section 6.1. This namespace is managed by IANA and assignments 3144 require a Expert Review. IANA will create the IEEE 802.11 QoS 3145 registry, whose format is: 3147 IEEE 802.11 QoS Type Value Reference 3149 10.6. IEEE 802.11 Auth Type 3151 The Auth Type field in the IEEE 802.11 Add WLAN message element (see 3152 Section 6.1) is 8 bits and is used to configure the IEEE 802.11 3153 authentication policy for the WLAN. The namespace is 8 bits (0-255), 3154 where the values zero (0) and one (1) are allocated in this 3155 specification, and can be found in Section 6.1. This namespace is 3156 managed by IANA and assignments require a Expert Review. IANA will 3157 create the IEEE 802.11 Auth Type registry, whose format is: 3159 IEEE 802.11 Auth Type Type Value Reference 3161 10.7. IEEE 802.11 Antenna Combiner 3163 The Combiner field in the IEEE 802.11 Antenna message element (see 3164 Section 6.2) is used to provide information about the WTP's antennas. 3165 The namespace is 8 bits (0-255), where the values zero (0) and one 3166 (1) are allocated in this specification, and can be found in 3167 Section 6.2. This namespace is managed by IANA and assignments 3168 require a Expert Review. IANA will create the IEEE 802.11 Antenna 3169 Combiner registry, whose format is: 3171 IEEE 802.11 Antenna Combiner Type Value Reference 3173 10.8. IEEE 802.11 Antenna Selection 3175 The Antenna Selection field in the IEEE 802.11 Antenna message 3176 element (see Section 6.2) is used to provide information about the 3177 WTP's antennas. The namespace is 8 bits (0-255), where the values 3178 zero (0) is reserved and used and the values one (1) through four (4) 3179 are allocated in this specification, and can be found in Section 6.2. 3181 This namespace is managed by IANA and assignments require a Expert 3182 Review. IANA will create the IEEE 802.11 Antenna Selection registry, 3183 whose format is: 3185 IEEE 802.11 Antenna Selection Type Value Reference 3187 10.9. IEEE 802.11 Session Key Flags 3189 The Flags field in the IEEE 802.11 Station Session Key message 3190 element (see Section 6.15) is 16 bits and is used to configure the 3191 session key association with the mobile device. This specification 3192 defines bits zero (0) and one (1), while bits two (2) through sixteen 3193 are reserved. The reserved bits are managed by IANA and whose 3194 assignment requires a Expert Review. IANA will create the IEEE 3195 802.11 Session Key Flags registry, whose format is: 3197 IEEE 802.11 Station Session Key Bit Position Reference 3199 10.10. IEEE 802.11 Tagging Policy 3201 The Tagging Policy field in the IEEE 802.11 WTP Quality of Service 3202 message element (see Section 6.22) is 8 bits and is used to specify 3203 how the CAPWAP Data Channel packets are to be tagged. This 3204 specification defines bits five (5) through seven (7). The remaining 3205 bits are managed by IANA and whose assignment requires a Expert 3206 Review. IANA will create the IEEE 802.11 Tagging Policy registry, 3207 whose format is: 3209 IEEE 802.11 Tagging Policy Bit Position Reference 3211 10.11. IEEE 802.11 WTP Radio Fail 3213 The Type field in the IEEE 802.11 WTP Radio Fail Alarm Indication 3214 message element (see Section 6.24) is used to provide information on 3215 why a WTP's radio has failed. The namespace is 8 bits (0-255), where 3216 the values zero (0) is reserved and unused, while the values one (1) 3217 and two (2) are allocated in this specification, and can be found in 3218 Section 6.24. This namespace is managed by IANA and assignments 3219 require a Expert Review. IANA will create the IEEE 802.11 WTP Radio 3220 Fail registry, whose format is: 3222 IEEE 802.11 WTP Radio Fail Type Value Reference 3224 10.12. IEEE 802.11 WTP Radio Type 3226 The Radio Type field in the IEEE 802.11 WTP Radio Information message 3227 element (see Section 6.25) is 8 bits and is used to provide 3228 information about the WTP's radio type. This specification defines 3229 bits five (5) through seven (7). The remaining bits are managed by 3230 IANA and whose assignment requires a Expert Review. IANA will create 3231 the IEEE 802.11 WTP Radio Type registry, whose format is: 3233 IEEE 802.11 WTP Radio Type Bit Position Reference 3235 11. Acknowledgments 3237 The following individuals are acknowledged for their contributions to 3238 this binding specification: Puneet Agarwal, Charles Clancy, Pasi 3239 Eronen, Saravanan Govindan, Scott Kelly, Peter Nilsson, Bob O'Hara, 3240 David Perkins, Margaret Wasserman and Yong Zhang. 3242 12. References 3244 12.1. Normative References 3246 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3247 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 3248 May 2008. 3250 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3251 Requirement Levels", BCP 14, RFC 2119, March 1997. 3253 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 3254 Levkowetz, "Extensible Authentication Protocol (EAP)", 3255 RFC 3748, June 2004. 3257 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 3258 "Assured Forwarding PHB Group", RFC 2597, June 1999. 3260 [RFC2598] Jacobson, V., Nichols, K., and K. Poduri, "An Expedited 3261 Forwarding PHB", RFC 2598, June 1999. 3263 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 3264 "Definition of the Differentiated Services Field (DS 3265 Field) in the IPv4 and IPv6 Headers", RFC 2474, 3266 December 1998. 3268 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 3269 of Explicit Congestion Notification (ECN) to IP", 3270 RFC 3168, September 2001. 3272 [FIPS.197.2001] 3273 National Institute of Standards and Technology, "Advanced 3274 Encryption Standard (AES)", FIPS PUB 197, November 2001, < 3275 http://csrc.nist.gov/publications/fips/fips197/ 3276 fips-197.pdf>. 3278 [ISO.3166-1] 3279 ISO Standard, "International Organization for 3280 Standardization, Codes for the representation of names of 3281 countries and their subdivisions - Part 1: Country codes", 3282 ISO Standard 3166-1:1997, 1997. 3284 [IEEE.802-11.2007] 3285 "Information technology - Telecommunications and 3286 information exchange between systems - Local and 3287 metropolitan area networks - Specific requirements - Part 3288 11: Wireless LAN Medium Access Control (MAC) and Physical 3289 Layer (PHY) specifications", IEEE Standard 802.11, 2007, < 3290 http://standards.ieee.org/getieee802/download/ 3291 802.11-2007.pdf>. 3293 [I-D.ietf-capwap-protocol-specification] 3294 Montemurro, M., Stanley, D., and P. Calhoun, "CAPWAP 3295 Protocol Specification", 3296 draft-ietf-capwap-protocol-specification-12 (work in 3297 progress), September 2008. 3299 [IEEE.802-1X.2004] 3300 "Information technology - Telecommunications and 3301 information exchange between systems - Local and 3302 metropolitan area networks - Specific requirements - Port- 3303 Based Network Access Control", IEEE Standard 802.1X, 2004, 3304 . 3307 [IEEE.802-1Q.2005] 3308 "Information technology - Telecommunications and 3309 information exchange between systems - Local and 3310 metropolitan area networks - Specific requirements - 3311 Virtual Bridged Local Area Networks", IEEE Standard 3312 802.1Q, 2005, . 3315 12.2. Informational References 3317 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 3318 Authentication Protocol (EAP) Method Requirements for 3319 Wireless LANs", RFC 4017, March 2005. 3321 [RFC4118] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy 3322 for Control and Provisioning of Wireless Access Points 3323 (CAPWAP)", RFC 4118, June 2005. 3325 [WPA] "Deploying Wi-Fi Protected Access (WPA) and WPA2 in the 3326 Enterprise", March 2005, . 3328 [WMM] "Support for Multimedia Applications with Quality of 3329 Service in WiFi Networks)", September 2004, . 3332 Editors' Addresses 3334 Pat R. Calhoun 3335 Cisco Systems, Inc. 3336 170 West Tasman Drive 3337 San Jose, CA 95134 3339 Phone: +1 408-902-3240 3340 Email: pcalhoun@cisco.com 3342 Michael P. Montemurro 3343 Research In Motion 3344 5090 Commerce Blvd 3345 Mississauga, ON L4W 5M4 3346 Canada 3348 Phone: +1 905-629-4746 x4999 3349 Email: mmontemurro@rim.com 3351 Dorothy Stanley 3352 Aruba Networks 3353 1322 Crossman Ave 3354 Sunnyvale, CA 94089 3356 Phone: +1 630-363-1389 3357 Email: dstanley@arubanetworks.com 3359 Full Copyright Statement 3361 Copyright (C) The IETF Trust (2008). 3363 This document is subject to the rights, licenses and restrictions 3364 contained in BCP 78, and except as set forth therein, the authors 3365 retain all their rights. 3367 This document and the information contained herein are provided on an 3368 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3369 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 3370 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 3371 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3372 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3373 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3375 Intellectual Property 3377 The IETF takes no position regarding the validity or scope of any 3378 Intellectual Property Rights or other rights that might be claimed to 3379 pertain to the implementation or use of the technology described in 3380 this document or the extent to which any license under such rights 3381 might or might not be available; nor does it represent that it has 3382 made any independent effort to identify any such rights. Information 3383 on the procedures with respect to rights in RFC documents can be 3384 found in BCP 78 and BCP 79. 3386 Copies of IPR disclosures made to the IETF Secretariat and any 3387 assurances of licenses to be made available, or the result of an 3388 attempt made to obtain a general license or permission for the use of 3389 such proprietary rights by implementers or users of this 3390 specification can be obtained from the IETF on-line IPR repository at 3391 http://www.ietf.org/ipr. 3393 The IETF invites any interested party to bring to its attention any 3394 copyrights, patents or patent applications, or other proprietary 3395 rights that may cover technology that may be required to implement 3396 this standard. Please address the information to the IETF at 3397 ietf-ipr@ietf.org.