idnits 2.17.1 draft-ietf-capwap-protocol-binding-ieee80211-11.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 3488. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3499. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3506. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3512. 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 (October 14, 2008) is 5673 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 3364, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2598 (Obsoleted by RFC 3246) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.802-11.2007' == Outdated reference: A later version (-15) exists of draft-ietf-capwap-protocol-specification-13 -- 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: April 17, 2009 Research In Motion 6 D. Stanley, Editor 7 Aruba Networks 8 October 14, 2008 10 CAPWAP Protocol Binding for IEEE 802.11 11 draft-ietf-capwap-protocol-binding-ieee80211-11 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 April 17, 2009. 38 Abstract 40 Wireless LAN product architectures have evolved from single 41 autonomous access points to systems consisting of a centralized 42 Access Controller (AC) and Wireless Termination Points (WTPs). The 43 general goal of centralized control architectures is to move access 44 control, including user authentication and authorization, mobility 45 management and radio management from the single access point to a 46 centralized controller. 48 This specification defines the Control And Provisioning of Wireless 49 Access Points (CAPWAP) Protocol Binding Specification for use with 50 the IEEE 802.11 Wireless Local Area Network protocol. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 1.2. Conventions used in this document . . . . . . . . . . . . 6 57 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 58 2. IEEE 802.11 Binding . . . . . . . . . . . . . . . . . . . . . 8 59 2.1. CAPWAP Wireless Binding Identifier . . . . . . . . . . . 8 60 2.2. Split MAC and Local MAC Functionality . . . . . . . . . . 8 61 2.2.1. Split MAC . . . . . . . . . . . . . . . . . . . . . . 8 62 2.2.2. Local MAC . . . . . . . . . . . . . . . . . . . . . . 13 63 2.3. Roaming Behavior . . . . . . . . . . . . . . . . . . . . 16 64 2.4. Group Key Refresh . . . . . . . . . . . . . . . . . . . . 17 65 2.5. BSSID to WLAN ID Mapping . . . . . . . . . . . . . . . . 18 66 2.6. CAPWAP Data Channel QoS Behavior . . . . . . . . . . . . 19 67 2.6.1. IEEE 802.11 Data Frames . . . . . . . . . . . . . . . 19 68 2.6.2. IEEE 802.11 MAC Management Messages . . . . . . . . . 22 69 2.7. Run State Operation . . . . . . . . . . . . . . . . . . . 22 70 3. IEEE 802.11 Specific CAPWAP Control Messages . . . . . . . . . 23 71 3.1. IEEE 802.11 WLAN Configuration Request . . . . . . . . . 23 72 3.2. IEEE 802.11 WLAN Configuration Response . . . . . . . . . 24 73 4. CAPWAP Data Message Bindings . . . . . . . . . . . . . . . . . 25 74 5. CAPWAP Control Message bindings . . . . . . . . . . . . . . . 27 75 5.1. Discovery Request Message . . . . . . . . . . . . . . . . 27 76 5.2. Discovery Response Message . . . . . . . . . . . . . . . 27 77 5.3. Primary Discovery Request Message . . . . . . . . . . . . 27 78 5.4. Primary Discovery Response Message . . . . . . . . . . . 27 79 5.5. Join Request Message . . . . . . . . . . . . . . . . . . 27 80 5.6. Join Response Message . . . . . . . . . . . . . . . . . . 28 81 5.7. Configuration Status Request Message . . . . . . . . . . 28 82 5.8. Configuration Status Response Message . . . . . . . . . . 28 83 5.9. Configuration Update Request Message . . . . . . . . . . 29 84 5.10. Station Configuration Request . . . . . . . . . . . . . . 30 85 5.11. Change State Event Request . . . . . . . . . . . . . . . 30 86 5.12. WTP Event Request . . . . . . . . . . . . . . . . . . . . 30 87 6. IEEE 802.11 Message Element Definitions . . . . . . . . . . . 31 88 6.1. IEEE 802.11 Add WLAN . . . . . . . . . . . . . . . . . . 31 89 6.2. IEEE 802.11 Antenna . . . . . . . . . . . . . . . . . . . 37 90 6.3. IEEE 802.11 Assigned WTP BSSID . . . . . . . . . . . . . 38 91 6.4. IEEE 802.11 Delete WLAN . . . . . . . . . . . . . . . . . 39 92 6.5. IEEE 802.11 Direct Sequence Control . . . . . . . . . . . 39 93 6.6. IEEE 802.11 Information Element . . . . . . . . . . . . . 41 94 6.7. IEEE 802.11 MAC Operation . . . . . . . . . . . . . . . . 41 95 6.8. IEEE 802.11 MIC Countermeasures . . . . . . . . . . . . . 43 96 6.9. IEEE 802.11 Multi-Domain Capability . . . . . . . . . . . 44 97 6.10. IEEE 802.11 OFDM Control . . . . . . . . . . . . . . . . 45 98 6.11. IEEE 802.11 Rate Set . . . . . . . . . . . . . . . . . . 46 99 6.12. IEEE 802.11 RSNA Error Report From Station . . . . . . . 47 100 6.13. IEEE 802.11 Station . . . . . . . . . . . . . . . . . . . 49 101 6.14. IEEE 802.11 Station QoS Profile . . . . . . . . . . . . . 50 102 6.15. IEEE 802.11 Station Session Key . . . . . . . . . . . . . 51 103 6.16. IEEE 802.11 Statistics . . . . . . . . . . . . . . . . . 53 104 6.17. IEEE 802.11 Supported Rates . . . . . . . . . . . . . . . 57 105 6.18. IEEE 802.11 Tx Power . . . . . . . . . . . . . . . . . . 57 106 6.19. IEEE 802.11 Tx Power Level . . . . . . . . . . . . . . . 58 107 6.20. IEEE 802.11 Update Station QoS . . . . . . . . . . . . . 59 108 6.21. IEEE 802.11 Update WLAN . . . . . . . . . . . . . . . . . 60 109 6.22. IEEE 802.11 WTP Quality of Service . . . . . . . . . . . 64 110 6.23. IEEE 802.11 WTP Radio Configuration . . . . . . . . . . . 66 111 6.24. IEEE 802.11 WTP Radio Fail Alarm Indication . . . . . . . 68 112 6.25. IEEE 802.11 WTP Radio Information . . . . . . . . . . . . 69 113 7. IEEE 802.11 Binding WTP Saved Variables . . . . . . . . . . . 71 114 7.1. IEEE80211AntennaInfo . . . . . . . . . . . . . . . . . . 71 115 7.2. IEEE80211DSControl . . . . . . . . . . . . . . . . . . . 71 116 7.3. IEEE80211MACOperation . . . . . . . . . . . . . . . . . . 71 117 7.4. IEEE80211OFDMControl . . . . . . . . . . . . . . . . . . 71 118 7.5. IEEE80211Rateset . . . . . . . . . . . . . . . . . . . . 71 119 7.6. IEEE80211TxPower . . . . . . . . . . . . . . . . . . . . 71 120 7.7. IEEE80211QoS . . . . . . . . . . . . . . . . . . . . . . 71 121 7.8. IEEE80211RadioConfig . . . . . . . . . . . . . . . . . . 71 122 8. Technology Specific Message Element Values . . . . . . . . . . 72 123 8.1. WTP Descriptor Message Element, Encryption 124 Capabilities Field: . . . . . . . . . . . . . . . . . . . 72 125 9. Security Considerations . . . . . . . . . . . . . . . . . . . 73 126 9.1. IEEE 802.11 Security . . . . . . . . . . . . . . . . . . 73 127 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 75 128 10.1. CAPWAP Wireless Binding Identifier . . . . . . . . . . . 75 129 10.2. CAPWAP IEEE 802.11 Message Types . . . . . . . . . . . . 75 130 10.3. CAPWAP Message Element Type . . . . . . . . . . . . . . . 75 131 10.4. IEEE 802.11 Key Status . . . . . . . . . . . . . . . . . 75 132 10.5. IEEE 802.11 QoS . . . . . . . . . . . . . . . . . . . . . 76 133 10.6. IEEE 802.11 Auth Type . . . . . . . . . . . . . . . . . . 76 134 10.7. IEEE 802.11 Antenna Combiner . . . . . . . . . . . . . . 76 135 10.8. IEEE 802.11 Antenna Selection . . . . . . . . . . . . . . 76 136 10.9. IEEE 802.11 Session Key Flags . . . . . . . . . . . . . . 77 137 10.10. IEEE 802.11 Tagging Policy . . . . . . . . . . . . . . . 77 138 10.11. IEEE 802.11 WTP Radio Fail . . . . . . . . . . . . . . . 77 139 10.12. IEEE 802.11 WTP Radio Type . . . . . . . . . . . . . . . 77 140 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 79 141 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 80 142 12.1. Normative References . . . . . . . . . . . . . . . . . . 80 143 12.2. Informational References . . . . . . . . . . . . . . . . 81 144 Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 82 145 Intellectual Property and Copyright Statements . . . . . . . . . . 83 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. This figure represents 346 a case where encryption services are provided by the AC. 348 Client WTP AC 350 Beacon 351 <----------------------------- 352 Probe Request 353 ----------------------------( - )-------------------------> 354 Probe Response 355 <----------------------------- 356 802.11 AUTH/Association 357 <---------------------------------------------------------> 358 Station Configuration Request 359 [Add Station (Station MAC 360 Address), IEEE 802.11 Add 361 Station (WLAN ID), IEEE 362 802.11 Session Key(Flag=A)] 363 <--------------------------> 364 802.1X Authentication & 802.11 Key Exchange 365 <---------------------------------------------------------> 366 Station Configuration Request 367 [Add Station(Station MAC 368 Address), IEEE 802.11 Add 369 Station (WLAN ID), IEEE 802.11 370 Station Session Key(Flag=C)] 371 <--------------------------> 372 802.11 Action Frames 373 <---------------------------------------------------------> 374 802.11 DATA (1) 375 <---------------------------( - )-------------------------> 377 Figure 2: Split MAC Message Flow 379 Figure 2 provides an illustration of the division of labor in a Split 380 MAC architecture. In this example, a WLAN has been created that is 381 configured for IEEE 802.11, using 802.1X based end user 382 authentication and AES-CCMP link layer encryption (Counter mode with 383 Cipher-block chaining Message authentication code Protocol, see 384 [FIPS.197.2001]). The following process occurs: 386 o The WTP generates the IEEE 802.11 Beacon frames, using information 387 provided to it through the IEEE 802.11 Add WLAN (see Section 6.1) 388 message element, including the RSNIE, which indicates support of 389 802.1X and AES-CCMP. 391 o The WTP processes the Probe Request frame and responds with a 392 corresponding Probe Response frame. The Probe Request frame is 393 then forwarded to the AC for optional processing. 395 o The WTP forwards the IEEEE 802.11 Authentication and Association 396 frames to the AC, which is responsible for responding to the 397 client. 399 o Once the association is complete, the AC transmits a Station 400 Configuration Request message, which includes an Add Station 401 message element, to the WTP (see Section 4.6.8 in 402 [I-D.ietf-capwap-protocol-specification]). In the above example, 403 the WLAN was configured for IEEE 802.1X, and therefore the IEEE 404 802.11 Station Session Key is included with the flag field's 'A' 405 bit set. 407 o If the WTP is providing encryption/decryption services, once the 408 client has completed the IEEE 802.11 key exchange, the AC 409 transmits another Station Configuration Request message, which 410 includes: 412 - An Add Station message element. 414 - An IEEE 802.11 Add Station message element, which includes the 415 WLAN Identifier the station has associated with. 417 - An IEEE 802.11 Station Session Key message element, which 418 includes the pairwise encryption key. 420 - An IEEE 802.11 Information Element message element which 421 includes the obust Security Network Information Element (RSNIE) 422 to the WTP, stating the security policy to enforce for the 423 client (in this case AES-CCMP). 425 o If the WTP is providing encryption/decryption services, once the 426 client has completed the IEEE 802.11 key exchange, the AC 427 transmits another Station Configuration Request message, which 428 includes: 430 - An Add Station message element. 432 - An IEEE 802.11 Add Station message element, which includes the 433 WLAN Identifier the station has associated with. 435 - An IEEE 802.11 Station Session Key message element, which 436 includes the pairwise encryption key. 438 - An IEEE 802.11 Information Element message element which 439 includes the Robust Security Network Information Element 440 (RSNIE) to the WTP, stating the security policy to enforce for 441 the client (in this case AES-CCMP). 443 o If the AC is providing encryption/decryption services, once the 444 client has completed the IEEE 802.11 key exchange, the AC 445 transmits another Station Configuration Request message, which 446 includes: 448 - An Add Station message element. 450 - An IEEE 802.11 Add Station message element, which includes the 451 WLAN Identifier the station has associated with. 453 - An IEEE 802.11 Station Session Key message element with the 454 flag fields' 'C' bit enabled (indicating that the AC will 455 provide crypto services). 457 o The WTP forwards any IEEE 802.11 Management Action frames received 458 to the AC. 460 o All IEEE 802.11 station data frames are tunneled between the WTP 461 and the AC. 463 Note that during the EAPOL-Key exchange between the Station and the 464 AC, the Receive Sequence Counter (RSC) field for the GTK needs to be 465 included in the frame. The value of zero (0) is used by the AC 466 during this exchange. Additional details are available in 467 Section 9.1. 469 The WTP SHALL include the IEEE 802.11 MAC header contents in all 470 frames transmitted to the AC. 472 When 802.11 encryption/decryption is performed at the WTP, the WTP 473 MUST decrypt the uplink frames, MUST set the Protected Frame field to 474 0, and MUST make the frame format consistent with that of an 475 unprotected 802.11 frame prior to transmitting the frames to the AC. 476 The fields added to an 802.11 protected frame (i.e., Initialization 477 Vector/Extended Initialization Vector (IV/EIV), Message Integrity 478 Code (MIC), and Integrity Check Value (ICV)) MUST be stripped off 479 prior to transmission from the WTP to AC. For downlink frames, the 480 Protected Frame field MUST be set to 0 by the AC as the frame being 481 sent is unencrypted. The WTP MUST apply the required protection 482 policy for the WLAN, and set the Protected Frame field on 483 transmission over the air. The Protected Frame field always needs to 484 accurately indicate the status of the 802.11 frame that is carrying 485 it. 487 When 802.11 encryption/decryption is performed at the AC, the WTP 488 SHALL NOT decrypt the uplink frames prior to transmitting the frames 489 to the AC. The AC and WTP SHALL populate the IEEE 802.11 MAC header 490 fields as described in Figure 3. 492 MAC header field Location 493 Frame Control: 494 Version AC 495 ToDS AC 496 FromDS AC 497 Type AC 498 SubType AC 499 MoreFrag WTP/AC 500 Retry WTP 501 Pwr Mgmt - 502 MoreData WTP 503 Protected WTP/AC 504 Order AC 505 Duration: WTP 506 Address 1: AC 507 Address 2: AC 508 Address 3: AC 509 Sequence Ctrl: WTP 510 Address 4: AC 511 QoS Control: AC 512 Frame Body: AC 513 FCS: WTP 515 Figure 3: Population of the IEEE 802.11 MAC header Fields for 516 Downlink Frames 518 When 802.11 encryption/decryption is performed at the AC, the 519 MoreFrag bit is populated at the AC. The Pwr Mgmt bit is not 520 applicable to downlink frames, and is set to 0. Note that the Frame 521 Check Sequence (FCS) field is not included in 802.11 frames exchanged 522 between the WTP and the AC. Upon sending data frames to the AC, the 523 WTP is responsible for validating, and stripping the FCS field. Upon 524 receiving data frames from the AC, the WTP is responsible for adding 525 the FCS field, and populating the field as described in 526 [IEEE.802-11.2007]. 528 Note that when the WTP tunnels data packets to the AC (and vice 529 versa), the CAPWAP protocol does not guarantee in-order delivery. 530 When the protocol being transported over IEEE 802.11 is IP, out of 531 order delivery is not an issue as IP has no such requirements. 532 However, implementors need to be aware of this protocol 533 characteristic before deciding to use CAPWAP. 535 2.2.2. Local MAC 537 This section shows the division of labor between the WTP and the AC 538 in a Local MAC architecture. Figure 4 shows the separation of 539 functionality among CAPWAP components. 541 Function Location 542 Distribution Service WTP/AC 543 Integration Service WTP 544 Beacon Generation WTP 545 Probe Response Generation WTP 546 Power Mgmt/Packet Buffering WTP 547 Fragmentation/Defragmentation WTP 548 Assoc/Disassoc/Reassoc WTP/AC 550 IEEE 802.11 QOS 551 Classifying WTP 552 Scheduling WTP 553 Queuing WTP 555 IEEE 802.11 RSN 556 IEEE 802.1X/EAP AC 557 RSNA Key Management AC 558 IEEE 802.11 Encryption/Decryption WTP 560 Figure 4: Mapping of 802.11 Functions for Local AP Architecture 562 In the Local MAC mode, the integration service exists on the WTP, 563 while the distribution service MAY reside on either the WTP or the 564 AC. When it resides on the AC, station generated frames are not 565 forwarded to the AC in their native format, but encapsulated as 802.3 566 frames. 568 While the MAC is terminated on the WTP, it is necessary for the AC to 569 be aware of mobility events within the WTPs. Thus the WTP MUST 570 forward the IEEE 802.11 Association Request frames to the AC. The AC 571 MAY reply with a failed Association Response frame if it deems it 572 necessary, and upon receipt of a failed Association Response frame 573 from the AC, the WTP MUST send a Disassociation frame to the station. 575 The IEEE 802.1X [IEEE.802-1X.2004], EAP and IEEE RSNA Key Management 576 [IEEE.802-11.2007] functions reside in the AC. Therefore, the WTP 577 MUST forward all IEEE 802.1X, EAP and RSNA Key Management frames to 578 the AC and forward the corresponding responses to the station. This 579 implies that the AAA client also resides on the AC. 581 Note that in the following figure, the use of '( - )' indicates that 582 processing of the frames is done on the WTP. 584 Client WTP AC 586 Beacon 587 <----------------------------- 588 Probe 589 <----------------------------> 590 802.11 AUTH 591 <----------------------------- 592 802.11 Association 593 <---------------------------( - )-------------------------> 594 Station Configuration Request 595 [Add Station (Station MAC 596 Address), IEEE 802.11 Add 597 Station (WLAN ID), IEEE 598 802.11 Session Key(Flag=A)] 599 <--------------------------> 600 802.1X Authentication & 802.11 Key Exchange 601 <---------------------------------------------------------> 602 Station Configuration Request 603 [Add Station(Station MAC 604 Address), IEEE 802.11 Add 605 Station (WLAN ID), IEEE 802.11 606 Station session Key (Key=x), 607 IEEE 802.11 Information 608 Element(RSNIE(Pairwise 609 Cipher=CCMP))] 610 <--------------------------> 611 802.11 Action Frames 612 <---------------------------------------------------------> 613 802.11 DATA 614 <-----------------------------> 616 Figure 5: Local MAC Message Flow 618 Figure 5 provides an illustration of the division of labor in a Local 619 MAC architecture. In this example, a WLAN that is configured for 620 IEEE 802.11 has been created using AES-CCMP for privacy. The 621 following process occurs: 623 o The WTP generates the IEEE 802.11 Beacon frames, using information 624 provided to it through the Add WLAN (see Section 6.1) message 625 element. 627 o The WTP processes a Probe Request frame and responds with a 628 corresponding Probe Response frame. 630 o The WTP forwards the IEEE 802.11 Authentication and Association 631 frames to the AC. 633 o Once the association is complete, the AC transmits a Station 634 Configuration Request message, which includes the Add Station 635 message element, to the WTP (see Section 4.6.8 in 636 [I-D.ietf-capwap-protocol-specification]). In the above example, 637 the WLAN was configured for IEEE 802.1X, and therefore the IEEE 638 802.11 Station Session Key is included with the flag field's 'A' 639 bit set. 641 o The WTP forwards all IEEE 802.1X and IEEE 802.11 key exchange 642 messages to the AC for processing. 644 o The AC transmits another Station Configuration Request message, 645 which includes: 647 - An Add Station message element, which MAY include a Virtual LAN 648 (VLAN) [IEEE.802-1Q.2005] name, which when present is used by 649 the WTP to identify the VLAN on which the user's data frames 650 are to be bridged. 652 - An IEEE 802.11 Add Station message element, which includes the 653 WLAN Identifier the station has associated with 655 - An IEEE 802.11 Station Session Key message element, which 656 includes the pairwise encryption key. 658 - An IEEE 802.11 Information Element message element which 659 includes the RSNIE to the WTP, stating the security policy to 660 enforce for the client (in this case AES-CCMP). 662 o The WTP forwards any IEEE 802.11 Management Action frames received 663 to the AC. 665 o The WTP MAY locally bridge client data frames (and provide the 666 necessary encryption and decryption services). The WTP MAY also 667 tunnel client data frames to the AC, using 802.3 frame tunnel mode 668 or 802.11 frame tunnel mode. 670 2.3. Roaming Behavior 672 This section expands upon the examples provided in the previous 673 section, and describes how the CAPWAP control protocol is used to 674 provide secure roaming. 676 Once a client has successfully associated with the network in a 677 secure fashion, it is likely to attempt to roam to another WTP. 679 Figure 6 shows an example of a currently associated station moving 680 from its "Old WTP" to a "New WTP". The figure is valid for multiple 681 different security policies, including IEEE 802.1X and Wireless 682 Protected Access (WPA) or Wireless Protected Access 2 (WPA2) [WPA]. 683 In the event that key caching was employed, the 802.1X Authentication 684 step would be eliminated. Note that the example represents one where 685 crypto services are provided by the WTP, so in a case where the AC 686 provided this function the last Station Configuration Request would 687 be different. 689 Client Old WTP New WTP AC 691 Association Request/Response 692 <--------------------------------------( - )--------------> 693 Station Configuration Request 694 [Add Station (Station MAC 695 Address), IEEE 802.11 Add 696 Station (WLAN ID), IEEE 697 802.11 Session Key(Flag=A)] 698 <----------------> 699 802.1X Authentication (if no key cache entry exists) 700 <--------------------------------------( - )--------------> 701 802.11 4-way Key Exchange 702 <--------------------------------------( - )--------------> 703 Station Configuration Request 704 [Delete Station] 705 <----------------------------------> 706 Station Configuration Request 707 [Add Station(Station MAC 708 Address), IEEE 802.11 Add 709 Station (WLAN ID), IEEE 802.11 710 Station session Key (Key=x), 711 IEEE 802.11 Information 712 Element(RSNIE(Pairwise 713 Cipher=CCMP))] 714 <----------------> 716 Figure 6: Client Roaming Example 718 2.4. Group Key Refresh 720 Periodically, the Group Key (GTK)for the BSS needs to be updated. 721 The AC uses an EAPOL-Key frame to update the group key for each STA 722 in the BSS. While the AC is updating the GTK, each L2 broadcast 723 frame transmitted to the BSS needs to be duplicated and transmitted 724 using both the current GTK and the new GTK. Once the GTK update 725 process has completed, broadcast frames transmitted to the BSS will 726 be encrypted using the new GTK. 728 In the case of Split MAC, the AC needs to duplicate all broadcast 729 packets and update the key index so that the packet is transmitted 730 using both the current and new GTK to ensure that all STA's in the 731 BSS receive the broadcast frames. In the case of local MAC, the WTP 732 needs to duplicate and transmit broadcast frames using the 733 appropriate index to ensure that all STA's in the BSS continue to 734 receive broadcast frames. 736 The Group Key update procedure is shown in the following figure. The 737 AC will signal the update to the GTK using an IEEE 802.11 738 Configuration Request message, including an IEEE 802.11 Update WLAN 739 message element with the new GTK, its index, the TSC for the Group 740 Key and the Key Status set to 3 (begin GTK update). The AC will then 741 begin updating the GTK for each STA. During this time, the AC (for 742 Split MAC) or WTP (for Local MAC) MUST duplicate broadcast packets 743 and transmit them encrypted with both the current and new GTK. When 744 the AC has completed the GTK update to all STA's in the BSS, the AC 745 MUST transmit an IEEE 802.11 Configuration Request message including 746 an IEEE 802.11 Update WLAN message element containing the new GTK, 747 its index, and the Key Status set to 4 (GTK update complete). 749 Client WTP AC 751 IEEE 802.11 WLAN Configuration Request [Update 752 WLAN (GTK, GTK Index, GTK Start, 753 Group TSC) ] 754 <-------------------------------------------- 755 802.1X EAPoL (GTK Message 1) 756 <-------------( - )------------------------------------------- 757 802.1X EAPoL (GTK Message 2) 758 -------------( - )-------------------------------------------> 759 IEEE 802.11 WLAN Configuration Request [ Update 760 WLAN (GTK Index, GTK Complete) ] 761 <-------------------------------------------- 763 Figure 7: Group Key Update Procedure 765 2.5. BSSID to WLAN ID Mapping 767 The CAPWAP protocol binding enables the WTP to assign BSSIDs upon 768 creation of a WLAN (see Section 6.1). While manufacturers are free 769 to assign BSSIDs using any arbitrary mechanism, it is advised that 770 where possible the BSSIDs are assigned as a contiguous block. 772 When assigned as a block, implementations can still assign any of the 773 available BSSIDs to any WLAN. One possible method is for the WTP to 774 assign the address using the following algorithm: base BSSID address 775 + WLAN ID. 777 The WTP communicates the maximum number of BSSIDs that it supports 778 during configuration via the IEEE 802.11 WTP WLAN Radio Configuration 779 message element (see Section 6.23). 781 2.6. CAPWAP Data Channel QoS Behavior 783 The CAPWAP IEEE 802.11 binding specification provides procedures to 784 allow for the WTP to enforce Quality of Service on IEEE 802.11 Data 785 Frames and MAC Management messages. 787 2.6.1. IEEE 802.11 Data Frames 789 When the WLAN is created on the WTP, a default Quality of Service 790 policy is established through the IEEE 802.11 WTP Quality of Service 791 message element (see Section 6.22). This default policy will cause 792 the WTP to use the default QoS values for any station associated with 793 the WLAN in question. The AC MAY also override the policy for a 794 given station, by sending the IEEE 802.11 Update Station QoS message 795 element (see Section 6.20), known as a station specific QoS policy. 797 Beyond the default, and per station QoS policy, the IEEE 802.11 798 protocol also allows a station to request special QoS treatment for a 799 specific flow through the TSPEC information elements found in the 800 IEEE 802.11-2007's QoS Action Frame. Alternatively, stations MAY 801 also use the WiFi Alliance's WMM specification instead to request QoS 802 treatment for a flow (see [WMM]). This requires the WTP to observe 803 the Status Code in the IEEE 802.11-2007 and WMM QoS Action ADDTS 804 responses from the AC, and provide the services requested in the 805 TSPEC information element. Similarly, the WTP MUST observe the 806 Reason Code information element in the IEEE 802.11-2007 and WMM QoS 807 Action DELTS responses from the AC by removing the policy associated 808 with the TSPEC. 810 The IEEE 802.11 WTP Quality of Service message element's Tagging 811 Policy field indicates how the packets are to be tagged, known as the 812 Tagging Policy. There are five bits defined, two of which are used 813 to indicate the type of QoS to be used by the WTP. The first is the 814 'P' bit which is set to inform the WTP it is to use the 802.1p QoS 815 mechanism. When set, the 'Q' bit is used to inform the WTP which 816 802.1p priority values it is to use. 818 The 'D' bit is set to inform the WTP it is to use the DSCP QoS 819 mechanism. When set, the 'I' and 'O' bits are used to inform the WTP 820 which values it is to use in the inner header, in the station's 821 original packet, or the outer header, the latter of which is only 822 valid when tunneling is enabled. 824 When an IEEE 802.11 Update Station QoS message element is received, 825 while the specific 802.1p priority or DSCP values may change for a 826 given station, known as the station specific policy, the original 827 Tagging Policy (the use of the five bits) remains the same. 829 The use of the DSCP and 802.1p QoS mechanisms are not mutually 830 exclusive. An AC MAY request that a WTP use none, one or both types 831 of QoS mechanisms at the same time. 833 2.6.1.1. 802.1p Support 835 The IEEE 802.11 WTP Quality of Service and IEEE 802.11 Update Station 836 QoS message elements include the "802.1p Tag" field, which is the 837 802.1p priority value. This value is used by the WTP by adding an 838 802.1Q header (see [IEEE.802-1Q.2005]) with the priority field set 839 according to the policy provided. Note this tagging is only valid 840 for interfaces that support 802.1p. The actual treatment does not 841 change for either Split or Local MAC modes, or when tunneling is 842 used. The only exception is when tunneling is used, the 802.1Q 843 header is added to the outer packet (tunneled) header. The IEEE 844 802.11 standard does not permit the station's packet to include an 845 802.1Q header. Instead, the QoS mechanisms defined in the IEEE 846 802.11 standard are used by stations to mark a packet's priority. 847 When the 'P' bit is set in the Tagging Policy, the 'Q' bit has the 848 following behavior: 850 Q=1: The WTP marks the priority field in the 802.1Q header to 851 either the default, or the station specific 802.1p policy. 853 Q=0: The WTP marks the priority field in the 802.1Q header to the 854 value found in User Priority field of the QoS Control field of the 855 IEEE 802.11 header. If the QoS Control field is not present in 856 the IEEE 802.11 header, then the behavior described under 'Q=1' is 857 used. 859 2.6.1.2. DSCP Support 861 The IEEE 802.11 WTP Quality of Service and IEEE 802.11 Update Station 862 QoS message elements also provide a "DSCP Tag", which is used by the 863 WTP when the 'D' bit is set to mark the DSCP field of both the IPv4 864 and IPv6 headers (see [RFC2474]). When DSCP is used, the WTP marks 865 the inner packet (the original packet received by the station) when 866 the 'I' bit is set. Similarly, the WTP marks the outer packet 867 (tunnel header's DSCP field) when the 'O' bit is set. 869 When the 'D' bit is set, the treatment of the packet differs based 870 whether the WTP is tunneling the station's packets to the AC. 871 Tunneling does not occur in a Local MAC mode when the AC has 872 communicated that tunneling is not required, as part of the IEEE 873 802.11 Add WLAN message element Section 6.1. In the case where 874 tunneling is not used, the 'I' and 'O' bits have the following 875 behavior: 877 O=1: This option is invalid when tunneling is not enabled for 878 station data frames. 880 O=0: This option is invalid when tunneling is not enabled for 881 station data frames. 883 I=1: The WTP sets the DSCP field in the station's packet to either 884 the default policy, or the station specific policy if one exists. 886 I=0: The WTP MUST NOT modify the DSCP field in the station's 887 packet. 889 For Split MAC mode, or Local MAC with tunneling enabled, the WTP 890 needs to contend with both the inner packet (the station's original 891 packet), as well as the tunnel header (added by the WTP). In this 892 mode of operation, the bits are treated as follows: 894 O=1: The WTP sets the DSCP field in the tunnel header to either the 895 default policy, or the station specific policy if one exists. 897 O=0: The WTP sets the DSCP field in the tunnel header to the value 898 found in the inner packet's DSCP field. If encryption services 899 are provided by the AC (see Section 6.15), the packet is 900 encrypted, therefore the WTP cannot access the inner DSCP field, 901 in which case it uses the behavior described when the 'O' bit is 902 set. This occurs also if the inner packet is not IPv4 or IPv6, 903 and thus does not have a DSCP field. 905 I=1: The WTP sets the DSCP field in the station's packet to either 906 the default policy, or the station specific policy if one exists. 907 If encryption services are provided by the AC (see Section 6.15), 908 the packet is encrypted, therefore the WTP cannot access the inner 909 DSCP field, in which case it uses the behavior described when the 910 'I' bit is not set. This occurs also if the inner packet is not 911 IPv4 or IPv6, and thus does not have a DSCP field. 913 I=0: The WTP MUST NOT modify the DSCP field in the station's 914 packet. 916 The CAPWAP protocol supports the Explicit Congestion Notification 917 (ECN) bits [RFC3168]. Additional details on ECN support can be found 918 [I-D.ietf-capwap-protocol-specification]. 920 2.6.2. IEEE 802.11 MAC Management Messages 922 It is recommended that IEEE 802.11 MAC Management frames be sent by 923 both the AC and the WTP with appropriate Quality of Service values, 924 listed below, to ensure that congestion in the network minimizes 925 occurrences of packet loss. Note that the QoS Mechanism specified in 926 Tagging Policy is used as specified by the AC in the IEEE 802.11 WTP 927 Quality of Service message element (see Section 6.22). However, the 928 station specific policy is not used for IEEE 802.11 MAC Management 929 frames. 931 802.1p: The precedence value of 7 (decimal) SHOULD be used for all 932 IEEE 802.11 MAC management frames, except for Probe Requests which 933 SHOULD use 4. 935 DSCP: All IEEE 802.11 MAC management frames SHOULD use the CS6 per- 936 hop behavior (see [RFC2474]), while IEEE 802.11 Probe Requests 937 should use the Low Drop Assured Forwarding per-hop behavior (see 938 [RFC2598]). 940 2.7. Run State Operation 942 The Run state is the normal state of operation for the CAPWAP 943 protocol in both the WTP and the AC. 945 When the WTP receives a WLAN Configuration Request message (see 946 Section 3.1), it MUST respond with a WLAN Configuration Response 947 message (see Section 3.2) and it remains in the Run state. 949 When the AC sends a WLAN Configuration Request message (see 950 Section 3.1) or receives the corresponding WLAN Configuration 951 Response message (see Section 3.2) from the WTP, it remains in the 952 Run state. 954 3. IEEE 802.11 Specific CAPWAP Control Messages 956 This section defines CAPWAP Control Messages that are specific to the 957 IEEE 802.11 binding. Two messages are defined, IEEE 802.11 WLAN 958 Configuration Request and IEEE 802.11 WLAN Configuration Response. 959 See Section 4.5 in [I-D.ietf-capwap-protocol-specification] for 960 CAPWAP Control message definitions and the derivation of the Message 961 Type value from the IANA Enterprise number. 963 The valid message types for IEEE 802.11 specific control messages are 964 listed below. The IANA Enterprise number used with these messages is 965 13277. 967 CAPWAP Control Message Message Type 968 Value 970 IEEE 802.11 WLAN Configuration Request 3398913 971 IEEE 802.11 WLAN Configuration Response 3398914 973 3.1. IEEE 802.11 WLAN Configuration Request 975 The IEEE 802.11 WLAN Configuration Request is sent by the AC to the 976 WTP in order to change services provided by the WTP. This control 977 message is used to either create, update or delete a WLAN on the WTP. 979 The IEEE 802.11 WLAN Configuration Request is sent as a result of 980 either some manual administrative process (e.g., deleting a WLAN), or 981 automatically to create a WLAN on a WTP. When sent automatically to 982 create a WLAN, this control message is sent after the CAPWAP 983 Configuration Update Response message (see Section 8.5 in 984 [I-D.ietf-capwap-protocol-specification]) has been received by the 985 AC. 987 Upon receiving this control message, the WTP will modify the 988 necessary services, and transmit an IEEE 802.11 WLAN Configuration 989 Response. 991 A WTP MAY provide service for more than one WLAN, therefore every 992 WLAN is identified through a numerical index. For instance, a WTP 993 that is capable of supporting up to 16 Service Set Identifiers 994 (SSIDs), could accept up to 16 IEEE 802.11 WLAN Configuration Request 995 messages that include the Add WLAN message element. 997 Since the index is the primary identifier for a WLAN, an AC MAY 998 attempt to ensure that the same WLAN is identified through the same 999 index number on all of its WTPs. An AC that does not follow this 1000 approach MUST find some other means of maintaining a WLAN-Identifier- 1001 to-SSID mapping table. 1003 The following message elements MAY be included in the IEEE 802.11 1004 WLAN Configuration Request message. Only one message element MUST be 1005 present. 1007 o IEEE 802.11 Add WLAN, see Section 6.1 1009 o IEEE 802.11 Delete WLAN, see Section 6.4 1011 o IEEE 802.11 Update WLAN, see Section 6.21 1013 The following message element MAY be present. 1015 o IEEE 802.11 Information Element, see Section 6.6 1017 o Vendor Specific Payload, see 1018 [I-D.ietf-capwap-protocol-specification] 1020 3.2. IEEE 802.11 WLAN Configuration Response 1022 The IEEE 802.11 WLAN Configuration Response message is sent by the 1023 WTP to the AC. It is used to acknowledge receipt of an IEEE 802.11 1024 WLAN Configuration Request message, and to indicate that the 1025 requested configuration was successfully applied, or that an error 1026 related to the processing of the IEEE 802.11 WLAN Configuration 1027 Request message occurred on the WTP. 1029 The following message element MUST be included in the IEEE 802.11 1030 WLAN Configuration Response message. 1032 o Result Code, see Section 4.6.34 in 1033 [I-D.ietf-capwap-protocol-specification] 1035 The following message element MAY be included in the IEEE 802.11 WLAN 1036 Configuration Response message. 1038 o IEEE 802.11 Assigned WTP BSSID, see Section 6.3 1040 o Vendor Specific Payload, see 1041 [I-D.ietf-capwap-protocol-specification] 1043 4. CAPWAP Data Message Bindings 1045 This section describes the CAPWAP Data Message bindings to support 1046 transport of IEEE 802.11 frames. 1048 Payload encapsulation: The CAPWAP protocol defines the CAPWAP data 1049 message, which is used to encapsulate a wireless payload. For 1050 IEEE 802.11, the IEEE 802.11 header and payload are encapsulated 1051 (excluding the IEEE 802.11 FCS checksum). The IEEE 802.11 FCS 1052 checksum is handled by the WTP. This allows the WTP to validate 1053 an IEEE 802.11 frame prior to sending it to the AC. Similarly, 1054 when an AC wishes to transmit a frame to a station, the WTP 1055 computes and adds the FCS checksum. 1057 Optional Wireless Specific Information: This optional CAPWAP header 1058 field (see Section 4.3 in 1059 [I-D.ietf-capwap-protocol-specification]) is only used with CAPWAP 1060 data messages, and it serves two purposes, depending upon the 1061 direction of the message. For messages from the WTP to the AC, 1062 the field uses the format described in the "IEEE 802.11 Frame 1063 Info" field (see below). However, for messages sent by the AC to 1064 the WTP, the format used is described in the "Destination WLANs" 1065 field (also defined below). 1067 Note that in both cases, the two optional headers fit in the 1068 "Data" field of the Wireless Specific Information header. 1070 IEEE 802.11 Frame Info: When an IEEE 802.11 frame is received from a 1071 station over the air, it is encapsulated and this field is used to 1072 include radio and PHY specific information associated with the 1073 frame. 1075 The IEEE 802.11 Frame Info field has the following format: 1077 0 1 2 3 1078 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 1079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1080 | RSSI | SNR | Data Rate | 1081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 RSSI: RSSI is a signed, 8-bit value. It is the received signal 1084 strength indication, in dBm. 1086 SNR: SNR is a signed, 8-bit value. It is the signal to noise 1087 ratio of the received IEEE 802.11 frame, in dB. 1089 Data Rate: The data rate field is a 16 bit unsigned value. The 1090 data rate field is a 16 bit unsigned value expressing the data 1091 rate of the packets received by the WTP in units of 0.1 Mbps. 1092 For instance, a packet received at 5.5Mbps would be set to 55, 1093 while 11Mbps would be set to 110. 1095 Destination WLANs The Destination WLANs field is used to specify the 1096 target WLANs for a given frame, and is only used with broadcast 1097 and multicast frames. This field allows the AC to transmit a 1098 single broadcast or multicast frame to the WTP, and allows the WTP 1099 to perform the necessary frame replication. The field uses the 1100 following format: 1102 0 1 2 3 1103 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 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1105 | WLAN ID bitmap | Reserved | 1106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1108 WLAN ID bitmap: This bit field indicates the WLAN ID (see 1109 Section 6.1) on which the WTP will transmit the included frame. 1110 For instance, if a multicast packet is to be transmitted on 1111 WLANs 1 and 3, the bits for WLAN 1 and 3 of this field would be 1112 enabled. WLAN 1 is represented by bit 15 in the figure above, 1113 or the least significant bit, while WLAN 16 would be 1114 represented by bit zero (0), or the most significant bit, in 1115 the figure. This field is to be set to all zeroes for unicast 1116 packets and is unused if the WTP is not providing IEEE 802.11 1117 encryption. 1119 Reserved: All implementations complying with this protocol MUST 1120 set to zero any bits that are reserved in the version of the 1121 protocol supported by that implementation. Receivers MUST 1122 ignore all bits not defined for the version of the protocol 1123 they support. 1125 5. CAPWAP Control Message bindings 1127 This section describes the IEEE 802.11 specific message elements 1128 included in CAPWAP Control Messages. 1130 5.1. Discovery Request Message 1132 The following IEEE 802.11 specific message element MUST be included 1133 in the CAPWAP Discovery Request Message. 1135 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 1136 802.11 WTP Radio Information message element MUST be present for 1137 every radio in the WTP. 1139 5.2. Discovery Response Message 1141 The following IEEE 802.11 specific message element MUST be included 1142 in the CAPWAP Discovery Response Message. 1144 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 1145 802.11 WTP Radio Information message element MUST be present for 1146 every radio in the WTP. 1148 5.3. Primary Discovery Request Message 1150 The following IEEE 802.11 specific message element MUST be included 1151 in the CAPWAP Primary Discovery Request Message. 1153 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 1154 802.11 WTP Radio Information message element MUST be present for 1155 every radio in the WTP. 1157 5.4. Primary Discovery Response Message 1159 The following IEEE 802.11 specific message element MUST be included 1160 in the CAPWAP Primary Discovery Response Message. 1162 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 1163 802.11 WTP Radio Information message element MUST be present for 1164 every radio in the WTP. 1166 5.5. Join Request Message 1168 The following IEEE 802.11 specific message element MUST be included 1169 in the CAPWAP Join Request Message. 1171 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 1172 802.11 WTP Radio Information message element MUST be present for 1173 every radio in the WTP. 1175 5.6. Join Response Message 1177 The following IEEE 802.11 specific message element MUST be included 1178 in the CAPWAP Join Response Message. 1180 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 1181 802.11 WTP Radio Information message element MUST be present for 1182 every radio in the WTP. 1184 5.7. Configuration Status Request Message 1186 The following IEEE 802.11 specific message elements MAY be included 1187 in the CAPWAP Configuration Status Request Message. More than one of 1188 each message element listed MAY be included. 1190 o IEEE 802.11 Antenna, see Section 6.2 1192 o IEEE 802.11 Direct Sequence Control, see Section 6.5 1194 o IEEE 802.11 MAC Operation, see Section 6.7 1196 o IEEE 802.11 Multi Domain Capability, see Section 6.9 1198 o IEEE 802.11 OFDM Control, see Section 6.10 1200 o IEEE 802.11 Supported Rates, see Section 6.17 1202 o IEEE 802.11 Tx Power, see Section 6.18 1204 o IEEE 802.11 TX Power Level, see Section 6.19 1206 o IEEE 802.11 WTP Radio Configuration, see Section 6.23 1208 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 1209 802.11 WTP Radio Information message element MUST be present for 1210 every radio in the WTP. 1212 5.8. Configuration Status Response Message 1214 The following IEEE 802.11 specific message elements MAY be included 1215 in the CAPWAP Configuration Status Response Message. More than one 1216 of each message element listed MAY be included. 1218 o IEEE 802.11 Antenna, see Section 6.2 1219 o IEEE 802.11 Direct Sequence Control, see Section 6.5 1221 o IEEE 802.11 MAC Operation, see Section 6.7 1223 o IEEE 802.11 Multi Domain Capability, see Section 6.9 1225 o IEEE 802.11 OFDM Control, see Section 6.10 1227 o IEEE 802.11 Rate Set, see Section 6.11 1229 o IEEE 802.11 Supported Rates, see Section 6.17 1231 o IEEE 802.11 Tx Power, see Section 6.18 1233 o IEEE 802.11 WTP Quality of Service, see Section 6.22 1235 o IEEE 802.11 WTP Radio Configuration, see Section 6.23 1237 5.9. Configuration Update Request Message 1239 The following IEEE 802.11 specific message elements MAY be included 1240 in the CAPWAP Configuration Update Request Message. More than one of 1241 each message element listed MAY be included. 1243 o IEEE 802.11 Antenna, see Section 6.2 1245 o IEEE 802.11 Direct Sequence Control, see Section 6.5 1247 o IEEE 802.11 MAC Operation, see Section 6.7 1249 o IEEE 802.11 Multi Domain Capability, see Section 6.9 1251 o IEEE 802.11 OFDM Control, see Section 6.10 1253 o IEEE 802.11 Rate Set, see Section 6.11 1255 o IEEE 802.11 RSNA Error Report From Station, see Section 6.12 1257 o IEEE 802.11 Tx Power, see Section 6.18 1259 o IEEE 802.11 WTP Quality of Service, see Section 6.22 1261 o IEEE 802.11 WTP Radio Configuration, see Section 6.23 1263 5.10. Station Configuration Request 1265 The following IEEE 802.11 specific message elements MAY included in 1266 the CAPWAP Station Configuration Request message. More than one of 1267 each message element listed MAY be included. 1269 o IEEE 802.11 Station, see Section 6.13 1271 o IEEE 802.11 Station Session Key, see Section 6.15 1273 o IEEE 802.11 Station QoS Profile, see Section 6.14 1275 o IEEE 802.11 Update Station Qos, see Section 6.20 1277 5.11. Change State Event Request 1279 The following IEEE 802.11 specific message elements MAY included in 1280 the CAPWAP Station Configuration Request message. 1282 o IEEE 802.11 WTP Radio Fail Alarm Indication, see Section 6.24 1284 5.12. WTP Event Request 1286 The following IEEE 802.11 specific message elements MAY be included 1287 in the CAPWAP WTP Event Request message. More than one of each 1288 message element listed MAY be included. 1290 o IEEE 802.11 MIC Countermeasures, see Section 6.8 1292 o IEEE 802.11 RSNA Error Report From Station, see Section 6.12 1294 o IEEE 802.11 Statistics, see Section 6.16 1296 6. IEEE 802.11 Message Element Definitions 1298 The following IEEE 802.11 specific message elements are defined in 1299 this section. 1301 IEEE 802.11 Message Element Type Value 1303 IEEE 802.11 Add WLAN 1024 1304 IEEE 802.11 Antenna 1025 1305 IEEE 802.11 Assigned WTP BSSID 1026 1306 IEEE 802.11 Delete WLAN 1027 1307 IEEE 802.11 Direct Sequence Control 1028 1308 IEEE 802.11 Information Element 1029 1309 IEEE 802.11 MAC Operation 1030 1310 IEEE 802.11 MIC Countermeasures 1031 1311 IEEE 802.11 Multi-Domain Capability 1032 1312 IEEE 802.11 OFDM Control 1033 1313 IEEE 802.11 Rate Set 1034 1314 IEEE 802.11 RSNA Error Report From Station 1035 1315 IEEE 802.11 Station 1036 1316 IEEE 802.11 Station QoS Profile 1037 1317 IEEE 802.11 Station Session Key 1038 1318 IEEE 802.11 Statistics 1039 1319 IEEE 802.11 Supported Rates 1040 1320 IEEE 802.11 Tx Power 1041 1321 IEEE 802.11 Tx Power Level 1042 1322 IEEE 802.11 Update Station QoS 1043 1323 IEEE 802.11 Update WLAN 1044 1324 IEEE 802.11 WTP Quality of Service 1045 1325 IEEE 802.11 WTP Radio Configuration 1046 1326 IEEE 802.11 WTP Radio Fail Alarm Indication 1047 1327 IEEE 802.11 WTP Radio Information 1048 1329 Figure 8: IEEE 802.11 Binding Message Elements 1331 6.1. IEEE 802.11 Add WLAN 1333 The IEEE 802.11 Add WLAN message element is used by the AC to define 1334 a WLAN on the WTP. The inclusion of this message element MUST also 1335 include IEEE 802.11 Information Element message elements, containing 1336 the following IEEE 802.11 IEs: 1338 Power Constraint information element 1339 EDCA Parameter Set information element 1341 QoS Capability information element 1343 WPA information element [WPA] 1345 RSN information element 1347 WMM information element [WMM] 1349 These IEEE 802.11 information elements are stored by the WTP and 1350 included in any Probe Responses and Beacons generated, as specified 1351 in the IEEE 802.11 standard [IEEE.802-11.2007]. If present, the RSN 1352 information element is sent with the IEEE 802.11 Add WLAN message 1353 element to instruct the WTP on the usage of the Key field. 1355 If cryptographic services are provided at the WTP, the WTP MUST 1356 observe the algorithm dictated in the Group Cipher Suite field of the 1357 RSN information element sent by the AC. The RSN Information Element 1358 is used to communicate any supported algorithm, including WEP, TKIP 1359 and AES-CCMP. In the case of static WEP keys, the RSN Information 1360 Element is still used to indicate the cryptographic algorithm even 1361 though no key exchange occurred. 1363 An AC MAY include additional information elements as desired. The 1364 message element uses the following format: 1366 0 1 2 3 1367 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 1368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1369 | Radio ID | WLAN ID | Capability | 1370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1371 | Key Index | Key Status | Key Length | 1372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1373 | Key... | 1374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1375 | Group TSC | 1376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1377 | Group TSC | QoS | Auth Type | 1378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1379 | MAC Mode | Tunnel Mode | Suppress SSID | SSID ... 1380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1382 Type: 1024 for IEEE 802.11 Add WLAN 1383 Length: >= 20 1385 Radio ID: An 8-bit value representing the radio, whose value is 1386 between one (1) and 31. 1388 WLAN ID: An 8-bit value specifying the WLAN Identifier. The value 1389 MUST be between one (1) and 16. 1391 Capability: A 16-bit value containing the capability information 1392 field to be advertised by the WTP in the Probe Request and Beacon 1393 frames. Each bit of the Capability field represents a different 1394 WTP capability, which are described in detail in 1395 [IEEE.802-11.2007]. The format of the field is: 1397 0 1 1398 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1400 |E|I|C|F|P|S|B|A|M|Q|T|D|V|O|K|L| 1401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1403 E (ESS): The AC MUST set the Extended Service Set (ESS) subfield 1404 to 1. 1406 I (IBSS): The AC MUST set the Independent Basic Service Set 1407 (IBSS) subfield to 0. 1409 C (CF-Pollable): The AC sets the Contention Free Pollable (CF- 1410 Pollable) subfield based on the table found in 1411 [IEEE.802-11.2007]. 1413 F (CF-Poll Request): The AC sets the CF-Poll Request subfield 1414 based on the table found in [IEEE.802-11.2007]. 1416 P (Privacy): The AC sets the Privacy subfield based on the 1417 confidentiality requirements of the WLAN, as defined in 1418 [IEEE.802-11.2007]. 1420 S (Short Preamble): The AC sets the Short Preamble subfield 1421 based on whether the use of short preambles are permitted on 1422 the WLAN, as defined in [IEEE.802-11.2007]. 1424 B (PBCC): The AC sets the Packet Binary Convolutional Code 1425 (PBCC) modulation option subfield based on whether the use of 1426 PBCC is permitted on the WLAN, as defined in 1427 [IEEE.802-11.2007]. 1429 A (Channel Agility): The AC sets the Channel Agility subfield 1430 based on whether the WTP is capable of supporting the High Rate 1431 Direct Sequence Spread Spectrum (HR/DSSS), as defined in 1432 [IEEE.802-11.2007]. 1434 M (Spectrum Management): The AC sets the Spectrum Management 1435 subfield according to the value of the 1436 dot11SpectrumManagementRequired MIB variable, as defined in 1437 [IEEE.802-11.2007]. 1439 Q (QOS): The AC sets the Quality of Service (QOS) subfield based 1440 on the table found in [IEEE.802-11.2007]. 1442 T (Short Slot Time): The AC sets the Short Slot Timesubfield 1443 according to the value of the WTP's currently used slot time 1444 value, as defined in [IEEE.802-11.2007]. 1446 D (APSD): The AC sets the APSD subfield according to the value 1447 of the dot11APSDOptionImplemented Management Information Base 1448 (MIB) variable, as defined in [IEEE.802-11.2007]. 1450 V (Reserved): The AC sets the Reserved subfield to zero, as 1451 defined in [IEEE.802-11.2007]. 1453 O (DSSS-OFDM): The AC sets the DSSS-OFDM subfield to indicate 1454 the use of Direct Sequence Spread Spectrum with Orthogonal 1455 Frequency Division Multiplexing (DSSS-OFDM), as defined in 1456 [IEEE.802-11.2007]. 1458 K (Delayed Block ACK): The AC sets the Delayed Block ACK 1459 subfield according to the value of the 1460 dot11DelayedBlockAckOptionImplemented MIB variable, as defined 1461 in [IEEE.802-11.2007]. 1463 L (Immediate Block ACK): The AC sets the Delayed Block ACK 1464 subfield according to the value of the 1465 dot11ImmediateBlockAckOptionImplemented MIB variable, as 1466 defined in [IEEE.802-11.2007]. 1468 Key-Index: The Key Index associated with the key. 1470 Key Status: A 1 byte value that specifies the state and usage of 1471 the key that has been included. Note this field is ignored if the 1472 Key Length field is set to zero (0). The following values 1473 describe the key usage and its status: 1475 0 - A value of zero, with the inclusion of the RSN Information 1476 Element means that the WLAN uses per-station encryption keys, 1477 and therefore the key in the 'Key' field is only used for 1478 multicast traffic. 1480 1 - When set to one, the WLAN employs a shared Wired Equivalent 1481 Privacy (WEP) key, also known as a static WEP key, and uses the 1482 encryption key for both unicast and multicast traffic for all 1483 stations. 1485 2 - The value of 2 indicates that the AC will begin rekeying the 1486 GTK with the STA's in the BSS. It is only valid when IEEE 1487 802.11 is enabled as the security policy for the BSS. 1489 3 - The value of 3 indicates that the AC has completed rekeying 1490 the GTK and broadcast packets no longer need to be duplicated 1491 and transmitted with both GTK's. 1493 Key Length: A 16-bit value representing the length of the Key 1494 field. 1496 Key: A Session Key, whose length is known via the key length field, 1497 used to provide data privacy. For encryption schemes that employ 1498 a separate encryption key for unicast and multicast traffic, the 1499 key included here only applies to multicast frames, and the cipher 1500 suite is specified in an accompanied RSN Information Element. In 1501 these scenarios, the key and cipher information is communicated 1502 via the Add Station message element, see Section 4.6.8 in 1503 [I-D.ietf-capwap-protocol-specification] and the IEEE 802.11 1504 Station Session Key message element, see Section 6.15. When used 1505 with WEP, the key field includes the broadcast key. When used 1506 with CCMP, the Key field includes the 128-bit Group Temporal Key. 1507 When used with TKIP, the Key field includes the 256-bit Group 1508 Temporal Key (which consists of a 128-bit key used as input for 1509 TKIP key mixing, and two 64-bit keys used for Michael). 1511 Group TSC A 48-bit value containing the Transmit Sequence Counter 1512 for the updated group key. The WTP will set the TSC for 1513 broadcast/multicast frames to this value for the updated group 1514 key. 1516 QOS: An 8-bit value specifying the default QOS policy for the WTP 1517 to apply to network traffic received for a non-WMM enabled STA. 1519 The following enumerated values are supported: 1521 0 - Best Effort 1523 1 - Video 1525 2 - Voice 1527 3 - Background 1529 Auth Type: An 8-bit value specifying the supported authentication 1530 type. 1532 The following enumerated values are supported: 1534 0 - Open System 1536 1 - WEP Shared Key 1538 MAC Mode: This field specifies whether the WTP should support the 1539 WLAN in Local or Split MAC modes. Note that the AC MUST NOT 1540 request a mode of operation that was not advertised by the WTP 1541 during the discovery process (see Section 4.6.43 in 1542 [I-D.ietf-capwap-protocol-specification]). The following 1543 enumerated values are supported: 1545 0 - Local-MAC: Service for the WLAN is to be provided in Local 1546 MAC mode. 1548 1 - Split-MAC: Service for the WLAN is to be provided in Split 1549 MAC mode. 1551 Tunnel Mode: This field specifies the frame tunneling type to be 1552 used for 802.11 data frames from all stations associated with the 1553 WLAN. The AC MUST NOT request a mode of operation that was not 1554 advertised by the WTP during the discovery process (see Section 1555 4.6.42 in [I-D.ietf-capwap-protocol-specification]). All IEEE 1556 802.11 management frames MUST be tunneled using 802.11 Tunnel 1557 mode. The following enumerated values are supported: 1559 0 - Local Bridging: All user traffic is to be locally bridged. 1561 1 - 802.3 Tunnel: All user traffic is to be tunneled to the AC 1562 in 802.3 format (see Section 4.4.2 in 1563 [I-D.ietf-capwap-protocol-specification]). Note that this 1564 option MUST NOT be selected with Split-MAC mode. 1566 2 - 802.11 Tunnel: All user traffic is to be tunneled to the AC 1567 in 802.11 format. 1569 Supress SSID: A boolean indicating whether the SSID is to be 1570 advertised by the WTP. A value of zero suppresses the SSID in the 1571 802.11 Beacon and Probe Response frames, while a value of one will 1572 cause the WTP to populate the field. 1574 SSID: The SSID attribute is the service set identifier that will be 1575 advertised by the WTP for this WLAN. The SSID field contains any 1576 ASCII character and MUST NOT exceed 32 octets in length, as 1577 defined in [IEEE.802-11.2007]. 1579 6.2. IEEE 802.11 Antenna 1581 The IEEE 802.11 Antenna message element is communicated by the WTP to 1582 the AC to provide information on the antennas available. The AC MAY 1583 use this element to reconfigure the WTP's antennas. The message 1584 element contains the following fields: 1586 0 1 2 3 1587 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 1588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1589 | Radio ID | Diversity | Combiner | Antenna Cnt | 1590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1591 | Antenna Selection... 1592 +-+-+-+-+-+-+-+-+ 1594 Type: 1025 for IEEE 802.11 Antenna 1596 Length: >= 5 1598 Radio ID: An 8-bit value representing the radio to configure, whose 1599 value is between one (1) and 31. 1601 Diversity: An 8-bit value specifying whether the antenna is to 1602 provide receive diversity. The value of this field is the same as 1603 the IEEE 802.11 dot11DiversitySelectionRx MIB element, see 1604 [IEEE.802-11.2007]. The following enumerated values are 1605 supported: 1607 0 - Disabled 1609 1 - Enabled (may only be true if the antenna can be used as a 1610 receive antenna) 1612 Combiner: An 8-bit value specifying the combiner selection. The 1613 following enumerated values are supported: 1615 1 - Sectorized (Left) 1617 2 - Sectorized (Right) 1619 3 - Omni 1621 4 - Multiple Input/Multiple Output (MIMO) 1623 Antenna Count: An 8-bit value specifying the number of Antenna 1624 Selection fields. This value SHOULD be the same as the one found 1625 in the IEEE 802.11 dot11CurrentTxAntenna MIB element (see 1626 [IEEE.802-11.2007]). 1628 Antenna Selection: One 8-bit antenna configuration value per 1629 antenna in the WTP, containing up to 255 antennas. The following 1630 enumerated values are supported: 1632 1 - Internal Antenna 1634 2 - External Antenna 1636 6.3. IEEE 802.11 Assigned WTP BSSID 1638 The IEEE 802.11 Assigned WTP BSSID is only included by the WTP when 1639 the IEEE 802.11 WLAN Configuration Request included the IEEE 802.11 1640 Add WLAN message element. The BSSID value field of this message 1641 element contains the BSSID that has been assigned by the WTP, 1642 enabling the WTP to perform its own BSSID assignment. 1644 The WTP is free to assign the BSSIDs the way it sees fit, but it is 1645 highly recommended that the WTP assign the BSSID using the following 1646 algorithm: BSSID = {base BSSID} + WLAN ID. 1648 0 1 2 3 1649 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 1650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1651 | Radio ID | WLAN ID | BSSID 1652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1653 | BSSID | 1654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1656 Type: 1026 for IEEE 802.11 Assigned WTP BSSID 1658 Length: 8 1660 Radio ID: An 8-bit value representing the radio, whose value is 1661 between one (1) and 31. 1663 WLAN ID: An 8-bit value specifying the WLAN Identifier. The value 1664 MUST be between one (1) and 16. 1666 BSSID: The BSSID assigned by the WTP for the WLAN created as a 1667 result of receiving an IEEE 802.11 Add WLAN. 1669 6.4. IEEE 802.11 Delete WLAN 1671 The IEEE 802.11 Delete WLAN message element is used to inform the WTP 1672 that a previously created WLAN is to be deleted, and contains the 1673 following fields: 1675 0 1 1676 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1678 | Radio ID | WLAN ID | 1679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1681 Type: 1027 for IEEE 802.11 Delete WLAN 1683 Length: 2 1685 Radio ID: An 8-bit value representing the radio, whose value is 1686 between one (1) and 31. 1688 WLAN ID: An 8-bit value specifying the WLAN Identifier. The value 1689 MUST be between one (1) and 16. 1691 6.5. IEEE 802.11 Direct Sequence Control 1693 The IEEE 802.11 Direct Sequence Control message element is a bi- 1694 directional element. When sent by the WTP, it contains the current 1695 state. When sent by the AC, the WTP MUST adhere to the values 1696 provided. This element is only used for IEEE 802.11b radios. The 1697 message element has the following fields. 1699 0 1 2 3 1700 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 1701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1702 | Radio ID | Reserved | Current Chan | Current CCA | 1703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1704 | Energy Detect Threshold | 1705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1707 Type: 1028 for IEEE 802.11 Direct Sequence Control 1709 Length: 8 1711 Radio ID: An 8-bit value representing the radio to configure, whose 1712 value is between one (1) and 31. 1714 Reserved: All implementations complying with this protocol MUST set 1715 to zero any bits that are reserved in the version of the protocol 1716 supported by that implementation. Receivers MUST ignore all bits 1717 not defined for the version of the protocol they support. 1719 Current Channel: This attribute contains the current operating 1720 frequency channel of the Direct Sequence Spread Spectrum (DSSS) 1721 PHY. This value comes from the IEEE 802.11 dot11CurrentChannel 1722 MIB element (see [IEEE.802-11.2007]). 1724 Current CCA: The current Clear Channel Assessment (CCA) method in 1725 operation, whose value can be found in the IEEE 802.11 1726 dot11CCAModeSupported MIB element (see [IEEE.802-11.2007]). Valid 1727 values are: 1729 1 - energy detect only (edonly) 1731 2 - carrier sense only (csonly) 1733 4 - carrier sense and energy detect (edandcs) 1735 8 - carrier sense with timer (cswithtimer) 1737 16 - high rate carrier sense and energy detect (hrcsanded) 1739 Energy Detect Threshold: The current Energy Detect Threshold being 1740 used by the DSSS PHY. The value can be found in the IEEE 802.11 1741 dot11EDThreshold MIB element (see [IEEE.802-11.2007]). 1743 6.6. IEEE 802.11 Information Element 1745 The IEEE 802.11 Information Element is used to communicate any IE 1746 defined in the IEEE 802.11 protocol. The data field contains the raw 1747 IE as it would be included within an IEEE 802.11 MAC management 1748 message. 1750 0 1 2 3 1751 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 1752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1753 | Radio ID | WLAN ID |B|P| Reserved |Info Element... 1754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1756 Type: 1029 for IEEE 802.11 Information Element 1758 Length: >= 4 1760 Radio ID: An 8-bit value representing the radio, whose value is 1761 between one (1) and 31. 1763 WLAN ID: An 8-bit value specifying the WLAN Identifier. The value 1764 MUST be between one (1) and 16. 1766 B: When set, the WTP is to include the information element in IEEE 1767 802.11 Beacons associated with the WLAN. 1769 P: When set, the WTP is to include the information element in Probe 1770 Responses associated with the WLAN. 1772 Reserved: All implementations complying with this protocol MUST set 1773 to zero any bits that are reserved in the version of the protocol 1774 supported by that implementation. Receivers MUST ignore all bits 1775 not defined for the version of the protocol they support. 1777 Info Element: The IEEE 802.11 Information Element, which includes 1778 the type, length and value field. 1780 6.7. IEEE 802.11 MAC Operation 1782 The IEEE 802.11 MAC Operation message element is sent by the AC to 1783 set the IEEE 802.11 MAC parameters on the WTP, and contains the 1784 following fields. 1786 0 1 2 3 1787 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 1788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1789 | Radio ID | Reserved | RTS Threshold | 1790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1791 | Short Retry | Long Retry | Fragmentation Threshold | 1792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1793 | Tx MSDU Lifetime | 1794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1795 | Rx MSDU Lifetime | 1796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1798 Type: 1030 for IEEE 802.11 MAC Operation 1800 Length: 16 1802 Radio ID: An 8-bit value representing the radio to configure, whose 1803 value is between one (1) and 31. 1805 Reserved: All implementations complying with this protocol MUST set 1806 to zero any bits that are reserved in the version of the protocol 1807 supported by that implementation. Receivers MUST ignore all bits 1808 not defined for the version of the protocol they support. 1810 RTS Threshold: This attribute indicates the number of octets in an 1811 MAC Protocol Data Unit (MPDU), below which an Request To Send/ 1812 Clear To Send (RTS/CTS) handshake MUST NOT be performed. An RTS/ 1813 CTS handshake MUST be performed at the beginning of any frame 1814 exchange sequence where the MPDU is of type Data or Management, 1815 the MPDU has an individual address in the Address1 field, and the 1816 length of the MPDU is greater than this threshold. Setting this 1817 attribute to be larger than the maximum MSDU size MUST have the 1818 effect of turning off the RTS/CTS handshake for frames of Data or 1819 Management type transmitted by this STA. Setting this attribute 1820 to zero MUST have the effect of turning on the RTS/CTS handshake 1821 for all frames of Data or Management type transmitted by this STA. 1822 The default value of this attribute MUST be 2347. The value of 1823 this field comes from the IEEE 802.11 dot11RTSThreshold MIB 1824 element, (see [IEEE.802-11.2007]). 1826 Short Retry: This attribute indicates the maximum number of 1827 transmission attempts of a frame, the length of which is less than 1828 or equal to RTSThreshold, that MUST be made before a failure 1829 condition is indicated. The default value of this attribute MUST 1830 be 7. The value of this field comes from the IEEE 802.11 1831 dot11ShortRetryLimit MIB element, (see [IEEE.802-11.2007]). 1833 Long Retry: This attribute indicates the maximum number of 1834 transmission attempts of a frame, the length of which is greater 1835 than dot11RTSThreshold, that MUST be made before a failure 1836 condition is indicated. The default value of this attribute MUST 1837 be 4. The value of this field comes from the IEEE 802.11 1838 dot11LongRetryLimit MIB element, (see [IEEE.802-11.2007]). 1840 Fragmentation Threshold: This attribute specifies the current 1841 maximum size, in octets, of the MPDU that MAY be delivered to the 1842 PHY. A MAC Service Data Unit (MSDU) MUST be broken into fragments 1843 if its size exceeds the value of this attribute after adding MAC 1844 headers and trailers. An MSDU or MAC Management Protocol Data 1845 Unit (MMPDU) MUST be fragmented when the resulting frame has an 1846 individual address in the Address1 field, and the length of the 1847 frame is larger than this threshold. The default value for this 1848 attribute MUST be the lesser of 2346 or the aMPDUMaxLength of the 1849 attached PHY and MUST never exceed the lesser of 2346 or the 1850 aMPDUMaxLength of the attached PHY. The value of this attribute 1851 MUST never be less than 256. The value of this field comes from 1852 the IEEE 802.11 dot11FragmentationThreshold MIB element, (see 1853 [IEEE.802-11.2007]). 1855 Tx MSDU Lifetime: This attribute specifies the elapsed time in TU, 1856 after the initial transmission of an MSDU, after which further 1857 attempts to transmit the MSDU MUST be terminated. The default 1858 value of this attribute MUST be 512. The value of this field 1859 comes from the IEEE 802.11 dot11MaxTransmitMSDULifetime MIB 1860 element, (see [IEEE.802-11.2007]). 1862 Rx MSDU Lifetime: This attribute specifies the elapsed time in TU, 1863 after the initial reception of a fragmented MMPDU or MSDU, after 1864 which further attempts to reassemble the MMPDU or MSDU MUST be 1865 terminated. The default value MUST be 512. The value of this 1866 field comes from the IEEE 802.11 dot11MaxReceiveLifetime MIB 1867 element, (see [IEEE.802-11.2007]). 1869 6.8. IEEE 802.11 MIC Countermeasures 1871 The IEEE 802.11 MIC Countermeasures message element is sent by the 1872 WTP to the AC to indicate the occurrence of a MIC failure. For more 1873 information on MIC failure events, see the 1874 dot11RSNATKIPCounterMeasuresInvoked MIB element definition in 1875 [IEEE.802-11.2007]. 1877 0 1 2 3 1878 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 1879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1880 | Radio ID | WLAN ID | MAC Address | 1881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1882 | MAC Address | 1883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1885 Type: 1031 for IEEE 802.11 MIC Countermeasures 1887 Length: 8 1889 Radio ID: The Radio Identifier, whose value is between one (1) and 1890 31, typically refers to some interface index on the WTP. 1892 WLAN ID: This 8-bit unsigned integer includes the WLAN Identifier, 1893 on which the MIC failure occurred. The value MUST be between one 1894 (1) and 16. 1896 MAC Address: The MAC Address of the station that caused the MIC 1897 failure. 1899 6.9. IEEE 802.11 Multi-Domain Capability 1901 The IEEE 802.11 Multi-Domain Capability message element is used by 1902 the AC to inform the WTP of regulatory limits. The AC will transmit 1903 one message element per frequency band to indicate the regulatory 1904 constraints in that domain. The message element contains the 1905 following fields. 1907 0 1 2 3 1908 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 1909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1910 | Radio ID | Reserved | First Channel # | 1911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1912 | Number of Channels | Max Tx Power Level | 1913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1915 Type: 1032 for IEEE 802.11 Multi-Domain Capability 1917 Length: 8 1919 Radio ID: An 8-bit value representing the radio to configure, whose 1920 value is between one (1) and 31. 1922 Reserved: All implementations complying with this protocol MUST set 1923 to zero any bits that are reserved in the version of the protocol 1924 supported by that implementation. Receivers MUST ignore all bits 1925 not defined for the version of the protocol they support. 1927 First Channnel #: This attribute indicates the value of the lowest 1928 channel number in the sub-band for the associated domain country 1929 string. The value of this field comes from the IEEE 802.11 1930 dot11FirstChannelNumber MIB element (see [IEEE.802-11.2007]). 1932 Number of Channels: This attribute indicates the value of the total 1933 number of channels allowed in the sub-band for the associated 1934 domain country string (see Section 6.23). The value of this field 1935 comes from the IEEE 802.11 dot11NumberofChannels MIB element (see 1936 [IEEE.802-11.2007]). 1938 Max Tx Power Level: This attribute indicates the maximum transmit 1939 power, in dBm, allowed in the sub-band for the associated domain 1940 country string (see Section 6.23). The value of this field comes 1941 from the IEEE 802.11 dot11MaximumTransmitPowerLevel MIB element 1942 (see [IEEE.802-11.2007]). 1944 6.10. IEEE 802.11 OFDM Control 1946 The IEEE 802.11 Orthogonal Frequency Division Multiplexing (OFDM) 1947 Control message element is a bi-directional element. When sent by 1948 the WTP, it contains the current state. When sent by the AC, the WTP 1949 MUST adhere to the received values. This message element is only 1950 used for 802.11a radios and contains the following fields: 1952 0 1 2 3 1953 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 1954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1955 | Radio ID | Reserved | Current Chan | Band Support | 1956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1957 | TI Threshold | 1958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1960 Type: 1033 for IEEE 802.11 OFDM Control 1962 Length: 8 1964 Radio ID: An 8-bit value representing the radio to configure, whose 1965 value is between one (1) and 31. 1967 Reserved: All implementations complying with this protocol MUST set 1968 to zero any bits that are reserved in the version of the protocol 1969 supported by that implementation. Receivers MUST ignore all bits 1970 not defined for the version of the protocol they support. 1972 Current Channel: This attribute contains the current operating 1973 frequency channel of the OFDM PHY. The value of this field comes 1974 from the IEEE 802.11 dot11CurrentFrequency MIB element (see 1975 [IEEE.802-11.2007]). 1977 Band Supported: The capability of the OFDM PHY implementation to 1978 operate in the three U-NII bands. The value of this field comes 1979 from the IEEE 802.11 dot11FrequencyBandsSupported MIB element (see 1980 [IEEE.802-11.2007]), coded as a bit field, whose values are: 1982 Bit 0 - capable of operating in the 5.15-5.25 GHz band 1984 Bit 1 - capable of operating in the 5.25-5.35 GHz band 1986 Bit 2 - capable of operating in the 5.725-5.825 GHz band 1988 Bit 3 - capable of operating in the 5.47-5.725 GHz band 1990 Bit 4 - capable of operating in the lower Japanese 5.25 GHz band 1992 Bit 5 - capable of operating in the 5.03-5.091 GHz band 1994 Bit 6 - capable of operating in the 4.94-4.99 GHz band 1996 For example, for an implementation capable of operating in the 1997 5.15-5.35 GHz bands this attribute would take the value 3. 1999 TI Threshold: The Threshold being used to detect a busy medium 2000 (frequency). CCA MUST report a busy medium upon detecting the 2001 RSSI above this threshold. The value of this field comes from the 2002 IEEE 802.11 dot11TIThreshold MIB element (see [IEEE.802-11.2007]). 2004 6.11. IEEE 802.11 Rate Set 2006 The rate set message element value is sent by the AC and contains the 2007 supported operational rates. It contains the following fields. 2009 0 1 2 3 2010 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 2011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2012 | Radio ID | Rate Set... 2013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2015 Type: 1034 for IEEE 802.11 Rate Set 2017 Length: >= 3 2019 Radio ID: An 8-bit value representing the radio to configure, whose 2020 value is between one (1) and 31. 2022 Rate Set: The AC generates the Rate Set that the WTP is to include 2023 in its Beacon and Probe messages. The length of this field is 2024 between 2 and 8 bytes. The value of this field comes from the 2025 IEEE 802.11 dot11OperationalRateSet MIB element (see 2026 [IEEE.802-11.2007]). 2028 6.12. IEEE 802.11 RSNA Error Report From Station 2030 The IEEE 802.11 RSN Error Report From Station message element is used 2031 by a WTP to send RSN error reports to the AC. The WTP does not need 2032 to transmit any reports that do not include any failures. The fields 2033 from this message element come from the IEEE 802.11 2034 Dot11RSNAStatsEntry table, see [IEEE.802-11.2007]. 2036 0 1 2 3 2037 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 2038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2039 | Client MAC Address | 2040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2041 | Client MAC Address | BSSID | 2042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2043 | BSSID | 2044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2045 | Radio ID | WLAN ID | Reserved | 2046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2047 | TKIP ICV Errors | 2048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2049 | TKIP Local MIC Failures | 2050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2051 | TKIP Remote MIC Failures | 2052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2053 | CCMP Replays | 2054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2055 | CCMP Decrypt Errors | 2056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2057 | TKIP Replays | 2058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2060 Type: 1035 for IEEE 802.11 RSNA Error Report From Station 2062 Length: 40 2064 Client MAC Address: The Client MAC Address of the station. 2066 BSSID: The BSSID on which the failures are being reported on. 2068 Radio ID: The Radio Identifier, whose value is between one (1) and 2069 31, typically refers to some interface index on the WTP 2071 WLAN ID: The WLAN ID on which the RSNA failures are being reported. 2072 The value MUST be between one (1) and 16. 2074 Reserved: All implementations complying with this protocol MUST set 2075 to zero any bits that are reserved in the version of the protocol 2076 supported by that implementation. Receivers MUST ignore all bits 2077 not defined for the version of the protocol they support. 2079 TKIP ICV Errors: A 32-bit value representing the number of Temporal 2080 Key Integrity Protocol (TKIP) (as defined in [IEEE.802-11.2007]) 2081 ICV errors encountered when decrypting packets from the station. 2082 The value of this field comes from the IEEE 802.11 2083 dot11RSNAStatsTKIPICVErrors MIB element (see [IEEE.802-11.2007]). 2085 TKIP Local MIC Failures: A 32-bit value representing the number of 2086 MIC failures encountered when checking the integrity of packets 2087 received from the station. The value of this field comes from the 2088 IEEE 802.11 dot11RSNAStatsTKIPLocalMICFailures MIB element (see 2089 [IEEE.802-11.2007]). 2091 TKIP Remote MIC Failures: A 32-bit value representing the number of 2092 MIC failures reported by the station encountered (possibly via the 2093 EAPOL-Key frame). The value of this field comes from the IEEE 2094 802.11 dot11RSNAStatsTKIPRemoteMICFailures MIB element (see 2095 [IEEE.802-11.2007]). 2097 CCMP Replays: A 32-bit value representing the number of CCMP MPDUs 2098 discarded by the replay detection mechanism. The value of this 2099 field comes from the IEEE 802.11 dot11RSNACCMPReplays MIB element 2100 (see [IEEE.802-11.2007]). 2102 CCMP Decrypt Errors: A 32-bit value representing the number of CCMP 2103 MDPUs discarded by the decryption algorithm. The value of this 2104 field comes from the IEEE 802.11 dot11RSNACCMPDecryptErrors MIB 2105 element (see [IEEE.802-11.2007]). 2107 TKIP Replays: A 32-bit value representing the number of TKIP 2108 Replays detected in frames received from the station. The value 2109 of this field comes from the IEEE 802.11 dot11RSNAStatsTKIPReplays 2110 MIB element (see [IEEE.802-11.2007]). 2112 6.13. IEEE 802.11 Station 2114 The IEEE 802.11 Station message element accompanies the Add Station 2115 message element, and is used to deliver IEEE 802.11 station policy 2116 from the AC to the WTP. 2118 The latest IEEE 802.11 Station message element overrides any 2119 previously received message elements. 2121 If the QoS field is set, the WTP MUST observe and provide policing of 2122 the 802.11e priority tag to ensure that it does not exceed the value 2123 provided by the AC. 2125 0 1 2 3 2126 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 2127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2128 | Radio ID | Association ID | Flags | 2129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2130 | MAC Address | 2131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2132 | MAC Address | Capabilities | 2133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2134 | WLAN ID |Supported Rates| 2135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2137 Type: 1036 for IEEE 802.11 Station 2139 Length: >= 14 2141 Radio ID: An 8-bit value representing the radio, whose value is 2142 between one (1) and 31. 2144 Association ID: A 16-bit value specifying the IEEE 802.11 2145 Association Identifier 2147 Flags: All implementations complying with this protocol MUST set to 2148 zero any bits that are reserved in the version of the protocol 2149 supported by that implementation. Receivers MUST ignore all bits 2150 not defined for the version of the protocol they support. 2152 MAC Address: The station's MAC Address 2154 Capabilities: A 16-bit field containing the IEEE 802.11 2155 Capabilities Information Field to use with the station. 2157 WLAN ID: An 8-bit value specifying the WLAN Identifier. The value 2158 MUST be between one (1) and 16. 2160 Supported Rates: The variable length field containing the supported 2161 rates to be used with the station, as found in the IEEE 802.11 2162 dot11OperationalRateSet MIB element (see [IEEE.802-11.2007]). 2163 This field MUST NOT exceed 126 octets and specifies the set of 2164 data rates at which the station may transmit data, where each 2165 octet represents a data rate. 2167 6.14. IEEE 802.11 Station QoS Profile 2169 The IEEE 802.11 Station QoS Profile message element contains the 2170 maximum IEEE 802.11e priority tag that may be used by the station. 2171 Any packet received that exceeds the value encoded in this message 2172 element MUST be tagged using the maximum value permitted by to the 2173 user. The priority tag MUST be between zero (0) and seven (7). This 2174 message element MUST NOT be present without the IEEE 802.11 Station 2175 (see Section 6.13) message element. 2177 0 1 2 3 2178 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 2179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2180 | MAC Address | 2181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2182 | MAC Address | Reserved |8021p| 2183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2185 Type: 1037 for IEEE 802.11 Station QOS Profile 2187 Length: 8 2189 MAC Address: The station's MAC Address 2191 Reserved: All implementations complying with this protocol MUST set 2192 to zero any bits that are reserved in the version of the protocol 2193 supported by that implementation. Receivers MUST ignore all bits 2194 not defined for the version of the protocol they support. 2196 8021p: The maximum 802.1p priority value that the WTP will allow in 2197 the Traffic Identifier (TID) field in the extended 802.11e QOS 2198 Data header. 2200 6.15. IEEE 802.11 Station Session Key 2202 The IEEE 802.11 Station Session Key message element is sent when the 2203 AC determines that encryption of a station must be performed in the 2204 WTP. This message element MUST NOT be present without the IEEE 2205 802.11 Station (see Section 6.13) message element, and MUST NOT be 2206 sent if the WTP had not specifically advertised support for the 2207 requested encryption scheme, through the WTP Descriptor Message 2208 Element's Encryption Capabilities Field (see Section 8.1). 2210 When the Key field is non-zero in length, the RSN information element 2211 MUST be sent along with the IEEE 802.11 Station Session Key in order 2212 to instruct the WTP on the usage of the Key field. The WTP MUST 2213 observe the AKM field of the RSN information element in order to 2214 identify the authentication protocol to be enforced with the station. 2216 If cryptographic services are provided at the WTP, the WTP MUST 2217 observe the algorithm dictated in the Pairwise Cipher Suite field of 2218 the RSN information element sent by the AC. The RSN Information 2219 Element included here is the one sent by the AC in the third message 2220 of the 4-Way Key Handshake, which specifies which cipher is to be 2221 applied to provide encryption and decryption services with the 2222 station. The RSN Information Element is used to communicate any 2223 supported algorithm, including WEP, TKIP and AES-CCMP. In the case 2224 of static WEP keys, the RSN Information Element is still used to 2225 indicate the cryptographic algorithm even though no key exchange 2226 occurred. 2228 If the IEEE 802.11 Station Session Key message element's AKM-Only bit 2229 is set, the WTP MUST drop all IEEE 802.11 packets that are not part 2230 of the Authentication and Key Management (AKM), such as EAP. Note 2231 that AKM-Only is MAY be set while an encryption key is in force, 2232 requiring that the AKM packets be encrypted. Once the station has 2233 successfully completed authentication via the AKM, the AC MUST send a 2234 new Add Station message element to remove the AKM-Only restriction, 2235 and optionally push the session key down to the WTP. 2237 0 1 2 3 2238 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 2239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2240 | MAC Address | 2241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2242 | MAC Address |A|C| Flags | 2243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2244 | Pairwise TSC | 2245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2246 | Pairwise TSC | Pairwise RSC | 2247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2248 | Pairwise RSC | 2249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2250 | Key... 2251 +-+-+-+-+-+-+-+- 2253 Type: 1038 for IEEE 802.11 Station Session Key 2255 Length: >= 25 2257 MAC Address: The station's MAC Address 2259 Flags: All implementations complying with this protocol MUST set to 2260 zero any bits that are reserved in the version of the protocol 2261 supported by that implementation. Receivers MUST ignore all bits 2262 not defined for the version of the protocol they support. The 2263 following bits are defined: 2265 A: The one bit AKM-Only field is set by the AC to inform the WTP 2266 that is MUST NOT accept any 802.11 data frames, other than AKM 2267 frames. This is the equivalent of the WTP's IEEE 802.1X port 2268 for the station to be in the closed state. When set, the WTP 2269 MUST drop any non-IEEE 802.1X packets it receives from the 2270 station. 2272 C: The one bit field is set by the AC to inform the WTP that 2273 encryption services will be provided by the AC. When set, the 2274 WTP SHOULD police frames received from stations to ensure that 2275 are properly encrypted as specified in the RSN Information 2276 Element, but does not need to take specific cryptographic 2277 action on the frame. Similarly, for transmitted frames, the 2278 WTP only needs to forward already encrypted frames. Since 2279 packets received by the WTP will be encrypted, the WTP cannot 2280 modify the contents of the packets, including modifying the 2281 DSCP markings of the encapsulated packet. In this case, this 2282 function would be the responsibility of the AC. 2284 Pairwise TSC: The 6 byte Transmit Sequence Counter (TSC) field to 2285 use for unicast packets transmitted to the station. 2287 Pairwise RSC: The 6 byte Receive Sequence Counter (RSC) to use for 2288 unicast packets received from the station. 2290 Key: The pairwise key the WTP is to use when encrypting traffic to/ 2291 from the station. The format of the keys differ based on the 2292 crypto algorithm used. For unicast WEP keys, the Key field 2293 consists of the actual unicast encryption key (note, this is used 2294 when WEP is used in conjunction with 802.1X, and therefore a 2295 unicast encryption key exists). When used with CCMP, the Key 2296 field includes the 128-bit Temporal Key. When used with TKIP, the 2297 Key field includes the 256-bit Temporal Key (which consists of a 2298 128-bit key used as input for TKIP key mixing, and two 64-bit keys 2299 used for Michael). 2301 6.16. IEEE 802.11 Statistics 2303 The IEEE 802.11 Statistics message element is sent by the WTP to 2304 transmit its current statistics, and contains the following fields. 2305 All of the fields in this message element are set to zero upon WTP 2306 initialization. The fields will roll over when they reach their 2307 maximum value of 4294967295. Due to the nature of each counter 2308 representing different data points, the roll over event will vary 2309 greatly across each field. Applications or human operators using 2310 these counters need to be aware about the minimal possible times 2311 between rollover events in order to make sure that no consecutive 2312 rollover events are missed. 2314 0 1 2 3 2315 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 2316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2317 | Radio ID | Reserved | 2318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2319 | Tx Fragment Count | 2320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2321 | Multicast Tx Count | 2322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2323 | Failed Count | 2324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2325 | Retry Count | 2326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2327 | Multiple Retry Count | 2328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2329 | Frame Duplicate Count | 2330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2331 | RTS Success Count | 2332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2333 | RTS Failure Count | 2334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2335 | ACK Failure Count | 2336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2337 | Rx Fragment Count | 2338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2339 | Multicast RX Count | 2340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2341 | FCS Error Count | 2342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2343 | Tx Frame Count | 2344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2345 | Decryption Errors | 2346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2347 | Discarded QoS Fragment Count | 2348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2349 | Associated Station Count | 2350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2351 | QoS CF Polls Received Count | 2352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2353 | QoS CF Polls Unused Count | 2354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2355 | QoS CF Polls Unusable Count | 2356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2358 Type: 1039 for IEEE 802.11 Statistics 2360 Length: 80 2362 Radio ID: An 8-bit value representing the radio, whose value is 2363 between one (1) and 31. 2365 Reserved: All implementations complying with this protocol MUST set 2366 to zero any bits that are reserved in the version of the protocol 2367 supported by that implementation. Receivers MUST ignore all bits 2368 not defined for the version of the protocol they support. 2370 Tx Fragment Count: A 32-bit value representing the number of 2371 fragmented frames transmitted. The value of this field comes from 2372 the IEEE 802.11 dot11TransmittedFragmentCount MIB element (see 2373 [IEEE.802-11.2007]). 2375 Multicast Tx Count: A 32-bit value representing the number of 2376 multicast frames transmitted. The value of this field comes from 2377 the IEEE 802.11 dot11MulticastTransmittedFrameCount MIB element 2378 (see [IEEE.802-11.2007]). 2380 Failed Count: A 32-bit value representing the transmit excessive 2381 retries. The value of this field comes from the IEEE 802.11 2382 dot11FailedCount MIB element (see [IEEE.802-11.2007]). 2384 Retry Count: A 32-bit value representing the number of transmit 2385 retries. The value of this field comes from the IEEE 802.11 2386 dot11RetryCount MIB element (see [IEEE.802-11.2007]). 2388 Multiple Retry Count: A 32-bit value representing the number of 2389 transmits that required more than one retry. The value of this 2390 field comes from the IEEE 802.11 dot11MultipleRetryCount MIB 2391 element (see [IEEE.802-11.2007]). 2393 Frame Duplicate Count: A 32-bit value representing the duplicate 2394 frames received. The value of this field comes from the IEEE 2395 802.11 dot11FrameDuplicateCount MIB element (see 2396 [IEEE.802-11.2007]). 2398 RTS Success Count: A 32-bit value representing the number of 2399 successfully transmitted Ready To Send (RTS). The value of this 2400 field comes from the IEEE 802.11 dot11RTSSuccessCount MIB element 2401 (see [IEEE.802-11.2007]). 2403 RTS Failure Count: A 32-bit value representing the failed 2404 transmitted RTS. The value of this field comes from the IEEE 2405 802.11 dot11RTSFailureCount MIB element (see [IEEE.802-11.2007]). 2407 ACK Failure Count: A 32-bit value representing the number of failed 2408 acknowledgements. The value of this field comes from the IEEE 2409 802.11 dot11ACKFailureCount MIB element (see [IEEE.802-11.2007]). 2411 Rx Fragment Count: A 32-bit value representing the number of 2412 fragmented frames received. The value of this field comes from 2413 the IEEE 802.11 dot11ReceivedFragmentCount MIB element (see 2414 [IEEE.802-11.2007]). 2416 Multicast RX Count: A 32-bit value representing the number of 2417 multicast frames received. The value of this field comes from the 2418 IEEE 802.11 dot11MulticastReceivedFrameCount MIB element (see 2419 [IEEE.802-11.2007]). 2421 FCS Error Count: A 32-bit value representing the number of FCS 2422 failures. The value of this field comes from the IEEE 802.11 2423 dot11FCSErrorCount MIB element (see [IEEE.802-11.2007]). 2425 Decryption Errors: A 32-bit value representing the number of 2426 Decryption errors that occurred on the WTP. Note that this field 2427 is only valid in cases where the WTP provides encryption/ 2428 decryption services. The value of this field comes from the IEEE 2429 802.11 dot11WEPUndecryptableCount MIB element (see 2430 [IEEE.802-11.2007]). 2432 Discarded QoS Fragment Count: A 32-bit value representing the 2433 number of discarded QoS fragments received. The value of this 2434 field comes from the IEEE 802.11 dot11QoSDiscardedFragmentCount 2435 MIB element (see [IEEE.802-11.2007]). 2437 Associated Station Count: A 32-bit value representing the number of 2438 number of associated stations. The value of this field comes from 2439 the IEEE 802.11 dot11AssociatedStationCount MIB element (see 2440 [IEEE.802-11.2007]). 2442 QoS CF Polls Received Count: A 32-bit value representing the number 2443 of (+)CF-Polls received. The value of this field comes from the 2444 IEEE 802.11 dot11QosCFPollsReceivedCount MIB element (see 2445 [IEEE.802-11.2007]). 2447 QoS CF Polls Unused Count: A 32-bit value representing the number 2448 of (+)CF-Polls that have been received, but not used. The value 2449 of this field comes from the IEEE 802.11 2450 dot11QosCFPollsUnusedCount MIB element (see [IEEE.802-11.2007]). 2452 QoS CF Polls Unusable Count: A 32-bit value representing the number 2453 of (+)CF-Polls that have been received, but could not be used due 2454 to the Transmission Opportunity (TXOP) size being smaller than the 2455 time that is required for one frame exchange sequence. The value 2456 of this field comes from the IEEE 802.11 2457 dot11QosCFPollsUnusableCount MIB element (see [IEEE.802-11.2007]). 2459 6.17. IEEE 802.11 Supported Rates 2461 The IEEE 802.11 Supported Rates message element is sent by the WTP to 2462 indicate the rates that it supports, and contains the following 2463 fields. 2465 0 1 2 3 2466 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 2467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2468 | Radio ID | Supported Rates... 2469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2471 Type: 1040 for IEEE 802.11 Supported Rates 2473 Length: >= 3 2475 Radio ID: An 8-bit value representing the radio, whose value is 2476 between one (1) and 31. 2478 Supported Rates: The WTP includes the Supported Rates that its 2479 hardware supports. The format is identical to the Rate Set 2480 message element and is between 2 and 8 bytes in length. 2482 6.18. IEEE 802.11 Tx Power 2484 The IEEE 802.11 Tx Power message element value is bi-directional. 2485 When sent by the WTP, it contains the current power level of the 2486 radio in question. When sent by the AC, it contains the power level 2487 the WTP MUST adhere to. 2489 0 1 2 3 2490 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 2491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2492 | Radio ID | Reserved | Current Tx Power | 2493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2495 Type: 1041 for IEEE 802.11 Tx Power 2496 Length: 4 2498 Radio ID: An 8-bit value representing the radio to configure, whose 2499 value is between one (1) and 31. 2501 Reserved: All implementations complying with this protocol MUST set 2502 to zero any bits that are reserved in the version of the protocol 2503 supported by that implementation. Receivers MUST ignore all bits 2504 not defined for the version of the protocol they support. 2506 Current Tx Power: This attribute contains the current transmit 2507 output power in mW, as described in the dot11CurrentTxPowerLevel 2508 MIB variable, see [IEEE.802-11.2007]. 2510 6.19. IEEE 802.11 Tx Power Level 2512 The IEEE 802.11 Tx Power Level message element is sent by the WTP and 2513 contains the different power levels supported. The values found in 2514 this message element are found in the IEEE 802.11 2515 Dot11PhyTxPowerEntry MIB table, see [IEEE.802-11.2007]. 2517 The value field contains the following: 2519 0 1 2 3 2520 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 2521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2522 | Radio ID | Num Levels | Power Level [n] | 2523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2525 Type: 1042 for IEEE 802.11 Tx Power Level 2527 Length: >= 4 2529 Radio ID: An 8-bit value representing the radio to configure, whose 2530 value is between one (1) and 31. 2532 Num Levels: The number of power level attributes. The value of 2533 this field comes from the IEEE 802.11 2534 dot11NumberSupportedPowerLevels MIB element (see 2535 [IEEE.802-11.2007]). 2537 Power Level: Each power level fields contains a supported power 2538 level, in mW. The value of this field comes from the 2539 corresponding IEEE 802.11 dot11TxPowerLevel[n] MIB element, see 2540 [IEEE.802-11.2007]. 2542 6.20. IEEE 802.11 Update Station QoS 2544 The IEEE 802.11 Update Station QoS message element is used to change 2545 the Quality of Service policy on the WTP for a given station. The 2546 QoS tags included in this message element are to be applied to 2547 packets received at the WTP from the station indicated through the 2548 MAC Address field. This message element overrides the default values 2549 provided through the IEEE 802.11 WTP Quality of Service message 2550 element (see Section 6.22). Any tagging performed by the WTP MUST be 2551 directly applied to the packets receive from the station, as well as 2552 the CAPWAP tunnel, if the packets are tunneled to the AC. See 2553 Section 2.6 for more information. 2555 0 1 2 3 2556 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 2557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2558 | Radio ID | MAC Address | 2559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2560 | MAC Address | QoS Sub-Element... | 2561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2563 Type: 1043 for IEEE 802.11 Update Station QoS 2565 Length: 8 2567 Radio ID: The Radio Identifier, whose value is between one (1) and 2568 31, typically refers to some interface index on the WTP 2570 MAC Address: The station's MAC Address. 2572 QoS Sub-Element: The IEEE 802.11 WTP Quality of Service message 2573 element contains four QoS sub-elements, one for every QoS profile. 2574 The order of the QoS profiles are Voice, Video, Best Effort and 2575 Background. 2577 0 1 2578 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2580 | Reserved|8021p|RSV| DSCP Tag | 2581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2583 Reserved: All implementations complying with this protocol MUST 2584 set to zero any bits that are reserved in the version of the 2585 protocol supported by that implementation. Receivers MUST 2586 ignore all bits not defined for the version of the protocol 2587 they support. 2589 8021p: The three bit 802.1p priority value to use if packets are 2590 to be IEEE 802.1p tagged. This field is used only if the 'P' 2591 bit in the WTP Quality of Service message element was set; 2592 otherwise, its contents MUST be ignored. 2594 RSV: All implementations complying with this protocol MUST set 2595 to zero any bits that are reserved in the version of the 2596 protocol supported by that implementation. Receivers MUST 2597 ignore all bits not defined for the version of the protocol 2598 they support. 2600 DSCP Tag: The 6 bit DSCP label to use if packets are eligible to 2601 be DSCP tagged, specifically an IPv4 or IPv6 packet (see 2602 [RFC2474]). This field is used only if the 'D' bit in the WTP 2603 Quality of Service message element was set; otherwise, its 2604 contents MUST be ignored. 2606 6.21. IEEE 802.11 Update WLAN 2608 The IEEE 802.11 Update WLAN message element is used by the AC to 2609 define a wireless LAN on the WTP. The inclusion of this message 2610 element MUST also include the IEEE 802.11 Information Element message 2611 element, containing the following 802.11 IEs: 2613 Power Constraint information element 2615 WPA information element [WPA] 2617 RSN information element 2619 EDCA Parameter Set information element 2621 QoS Capability information element 2623 WMM information element [WMM] 2625 These IEEE 802.11 information elements are stored by the WTP and 2626 included in any Probe Responses and Beacons generated, as specified 2627 in the IEEE 802.11 standard [IEEE.802-11.2007]. 2629 If cryptographic services are provided at the WTP, the WTP MUST 2630 observe the algorithm dictated in the Group Cipher Suite field of the 2631 RSN information element sent by the AC. The RSN Information Element 2632 is used to communicate any supported algorithm, including WEP, TKIP 2633 and AES-CCMP. In the case of static WEP keys, the RSN Information 2634 Element is still used to indicate the cryptographic algorithm even 2635 though no key exchange occurred. 2637 The message element uses the following format: 2639 0 1 2 3 2640 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 2641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2642 | Radio ID | WLAN ID | Capability | 2643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2644 | Key Index | Key Status | Key Length | 2645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2646 | Key... | 2647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2649 Type: 1044 for IEEE 802.11 Update WLAN 2651 Length: >= 8 2653 Radio ID: An 8-bit value representing the radio, whose value is 2654 between one (1) and 31. 2656 WLAN ID: An 8-bit value specifying the WLAN Identifier. The value 2657 MUST be between one (1) and 16. 2659 Capability: A 16-bit value containing the capability information 2660 field to be advertised by the WTP in the Probe Request and Beacon 2661 frames. Each bit of the Capability field represents a different 2662 WTP capability, which are described in detail in 2663 [IEEE.802-11.2007]. The format of the field is: 2665 0 1 2666 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2668 |E|I|C|F|P|S|B|A|M|Q|T|D|V|O|K|L| 2669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2671 E (ESS): The AC MUST set the Extended Service Set (ESS) subfield 2672 to 1. 2674 I (IBSS): The AC MUST set the Independent Basic Service Set 2675 (IBSS) subfield to 0. 2677 C (CF-Pollable): The AC sets the Contention Free Pollable (CF- 2678 Pollable) subfield based on the table found in 2679 [IEEE.802-11.2007]. 2681 F (CF-Poll Request): The AC sets the CF-Poll Request subfield 2682 based on the table found in [IEEE.802-11.2007]. 2684 P (Privacy): The AC sets the Privacy subfield based on the 2685 confidentiality requirements of the WLAN, as defined in 2686 [IEEE.802-11.2007]. 2688 S (Short Preamble): The AC sets the Short Preamble subfield 2689 based on whether the use of short preambles are permitted on 2690 the WLAN, as defined in [IEEE.802-11.2007]. 2692 B (PBCC): The AC sets the Packet Binary Convolutional Code 2693 (PBCC) modulation option subfield based on whether the use of 2694 PBCC is permitted on the WLAN, as defined in 2695 [IEEE.802-11.2007]. 2697 A (Channel Agility): The AC sets the Channel Agility subfield 2698 based on whether the WTP is capable of supporting the High Rate 2699 Direct Sequence Spread Spectrum (HR/DSSS), as defined in 2700 [IEEE.802-11.2007]. 2702 M (Spectrum Management): The AC sets the Spectrum Management 2703 subfield according to the value of the 2704 dot11SpectrumManagementRequired MIB variable, as defined in 2705 [IEEE.802-11.2007]. 2707 Q (QOS): The AC sets the Quality of Service (QOS) subfield based 2708 on the table found in [IEEE.802-11.2007]. 2710 T (Short Slot Time): The AC sets the Short Slot Timesubfield 2711 according to the value of the WTP's currently used slot time 2712 value, as defined in [IEEE.802-11.2007]. 2714 D (APSD): The AC sets the APSD subfield according to the value 2715 of the dot11APSDOptionImplemented Management Information Base 2716 (MIB) variable, as defined in [IEEE.802-11.2007]. 2718 V (Reserved): The AC sets the Reserved subfield to zero, as 2719 defined in [IEEE.802-11.2007]. 2721 O (DSSS-OFDM): The AC sets the DSSS-OFDM subfield to indicate 2722 the use of Direct Sequence Spread Spectrum with Orthogonal 2723 Frequency Division Multiplexing (DSSS-OFDM), as defined in 2724 [IEEE.802-11.2007]. 2726 K (Delayed Block ACK): The AC sets the Delayed Block ACK 2727 subfield according to the value of the 2728 dot11DelayedBlockAckOptionImplemented MIB variable, as defined 2729 in [IEEE.802-11.2007]. 2731 L (Immediate Block ACK): The AC sets the Delayed Block ACK 2732 subfield according to the value of the 2733 dot11ImmediateBlockAckOptionImplemented MIB variable, as 2734 defined in [IEEE.802-11.2007]. 2736 Key-Index: The Key Index associated with the key. 2738 Key Status: A 1 byte value that specifies the state and usage of 2739 the key that has been included. The following values describe the 2740 key usage and its status: 2742 0 - A value of zero, with the inclusion of the RSN Information 2743 Element means that the WLAN uses per-station encryption keys, 2744 and therefore the key in the 'Key' field is only used for 2745 multicast traffic. 2747 1 - When set to one, the WLAN employs a shared WEP key, also 2748 known as a static WEP key, and uses the encryption key for both 2749 unicast and multicast traffic for all stations. 2751 2 - The value of 2 indicates that the AC will begin rekeying the 2752 GTK with the STA's in the BSS. It is only valid when IEEE 2753 802.11 is enabled as the security policy for the BSS. 2755 3 - The value of 3 indicates that the AC has completed rekeying 2756 the GTK and broadcast packets no longer need to be duplicated 2757 and transmitted with both GTK's. 2759 Key Length: A 16-bit value representing the length of the Key 2760 field. 2762 Key: A Session Key, whose length is known via the key length field, 2763 used to provide data privacy. For static WEP keys, which is true 2764 when the 'Key Status' bit is set to one, this key is used for both 2765 unicast and multicast traffic. For encryption schemes that employ 2766 a separate encryption key for unicast and multicast traffic, the 2767 key included here only applies to multicast data, and the cipher 2768 suite is specified in an accompanied RSN Information Element. In 2769 these scenarios, the key, and cipher information, is communicated 2770 via the Add Station message element, see Section 4.6.8 in 2771 [I-D.ietf-capwap-protocol-specification]. When used with WEP, the 2772 key field includes the broadcast key. When used with CCMP, the 2773 Key field includes the 128-bit Group Temporal Key. When used with 2774 TKIP, the Key field includes the 256-bit Group Temporal Key (which 2775 consists of a 128-bit key used as input for TKIP key mixing, and 2776 two 64-bit keys used for Michael). 2778 6.22. IEEE 802.11 WTP Quality of Service 2780 The IEEE 802.11 WTP Quality of Service message element value is sent 2781 by the AC to the WTP to communicate quality of service configuration 2782 information. The QoS tag included in this message element are the 2783 default QoS values to be applied to packets received by the WTP from 2784 stations on a particular radio. Any tagging performed by the WTP 2785 MUST be directly applied to the packets receive from the station, as 2786 well as the CAPWAP tunnel, if the packets are tunneled to the AC. 2787 See Section 2.6 for more information. 2789 0 1 2 3 2790 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 2791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2792 | Radio ID |Tagging Policy | QoS Sub-Element ... 2793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2795 Type: 1045 for IEEE 802.11 WTP Quality of Service 2797 Length: 34 2799 Radio ID: The Radio Identifier, whose value is between one (1) and 2800 31, typically refers to some interface index on the WTP 2802 Tagging Policy: A bit field indicating how the WTP is to mark 2803 packets for QoS purposes. The required WTP behavior is defined in 2804 Section 2.6.1. The field has the following format: 2806 0 1 2 3 4 5 6 7 2807 +-+-+-+-+-+-+-+-+ 2808 |Rsvd |P|Q|D|O|I| 2809 +-+-+-+-+-+-+-+-+ 2811 Rsvd: A set of reserved bits for future use. All implementations 2812 complying with this protocol MUST set to zero any bits that are 2813 reserved in the version of the protocol supported by that 2814 implementation. Receivers MUST ignore all bits not defined for 2815 the version of the protocol they support. 2817 P: When set, the WTP is to employ the 802.1p QoS mechanism (see 2818 Section 2.6.1.1), and the WTP is to use the 'Q' bit. 2820 Q: When the 'P' bit is set, the 'Q' bit is used by the AC to 2821 communicate to the WTP how 802.1p QoS is to be enforced. 2822 Details on the behavior of the 'Q' bit is specified in 2823 Section 2.6.1.1. 2825 D: When set, the WTP is to employ the DSCP QoS mechanism (see 2826 Section 2.6.1.2), and the WTP is to use the 'O' and 'I' bits. 2828 O: When the 'D' bit is set, the 'O' bit is used by the AC to 2829 communicate to the WTP how DSCP QoS is to be enforced on the 2830 outer (tunneled) header. Details on the behavior of the 'O' 2831 bit is specified in Section 2.6.1.2. 2833 I: When the 'D' bit is set, the 'I' bit is used by the AC to 2834 communicate to the WTP how DSCP QoS is to be enforced on the 2835 station's packet (inner) header. Details on the behavior of 2836 the 'I' bit is specified in Section 2.6.1.2. 2838 QoS Sub-Element: The IEEE 802.11 WTP Quality of Service message 2839 element contains four QoS sub-elements, one for every QoS profile. 2840 The order of the QoS profiles are Voice, Video, Best Effort and 2841 Background. 2843 0 1 2 3 2844 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 2845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2846 | Queue Depth | CWMin | CWMax | 2847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2848 | CWMax | AIFS | Reserved|8021p|RSV| DSCP Tag | 2849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2851 Queue Depth: The number of packets that can be on the specific 2852 QoS transmit queue at any given time. 2854 CWMin: The Contention Window minimum (CWmin) value for the QoS 2855 transmit queue. The value of this field comes from the IEEE 2856 802.11 dot11EDCATableCWMin MIB element (see 2857 [IEEE.802-11.2007]). 2859 CWMax: The Contention Window maximum (CWmax) value for the QoS 2860 transmit queue. The value of this field comes from the IEEE 2861 802.11 dot11EDCATableCWMax MIB element (see 2862 [IEEE.802-11.2007]). 2864 AIFS: The Arbitration Inter Frame Spacing (AIFS) to use for the 2865 QoS transmit queue. The value of this field comes from the 2866 IEEE 802.11 dot11EDCATableAIFSN MIB element (see 2867 [IEEE.802-11.2007]). 2869 Reserved: All implementations complying with this protocol MUST 2870 set to zero any bits that are reserved in the version of the 2871 protocol supported by that implementation. Receivers MUST 2872 ignore all bits not defined for the version of the protocol 2873 they support. 2875 8021p: The three bit 802.1p priority value to use if packets are 2876 to be IEEE 802.1p tagged. This field is used only if the 'P' 2877 bit is set; otherwise, its contents MUST be ignored. 2879 RSV: All implementations complying with this protocol MUST set 2880 to zero any bits that are reserved in the version of the 2881 protocol supported by that implementation. Receivers MUST 2882 ignore all bits not defined for the version of the protocol 2883 they support. 2885 DSCP Tag: The 6 bit DSCP label to use if packets are eligible to 2886 be DSCP tagged, specifically an IPv4 or IPv6 packet (see 2887 [RFC2474]). This field is used only if the 'D' bit is set; 2888 otherwise, its contents MUST be ignored. 2890 6.23. IEEE 802.11 WTP Radio Configuration 2892 The IEEE 802.11 WTP WLAN Radio Configuration message element is used 2893 by the AC to configure a Radio on the WTP, and by the WTP to deliver 2894 its radio configuration to the AC. The message element value 2895 contains the following fields: 2897 0 1 2 3 2898 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 2899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2900 | Radio ID |Short Preamble| Num of BSSIDs | DTIM Period | 2901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2902 | BSSID | 2903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2904 | BSSID | Beacon Period | 2905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2906 | Country String | 2907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2909 Type: 1046 for IEEE 802.11 WTP WLAN Radio Configuration 2911 Length: 16 2912 Radio ID: An 8-bit value representing the radio to configure, whose 2913 value is between one (1) and 31. 2915 Short Preamble: An 8-bit value indicating whether short preamble is 2916 supported. The following enumerated values are currently 2917 supported: 2919 0 - Short preamble not supported. 2921 1 - Short preamble is supported. 2923 BSSID: The WLAN Radio's base MAC Address. 2925 Number of BSSIDs: This attribute contains the maximum number of 2926 BSSIDs supported by the WTP. This value restricts the number of 2927 logical networks supported by the WTP, and is between 1 and 16. 2929 DTIM Period: This attribute specifies the number of beacon 2930 intervals that elapse between transmission of Beacons frames 2931 containing a Traffic Indication Map (TIM) element whose Delivery 2932 Traffic Indication Message (DTIM) Count field is 0. This value is 2933 transmitted in the DTIM Period field of Beacon frames. The value 2934 of this field comes from the IEEE 802.11 dot11DTIMPeriod MIB 2935 element (see [IEEE.802-11.2007]). 2937 Beacon Period: This attribute specifies the number of Time Unit 2938 (TU) that a station uses for scheduling Beacon transmissions. 2939 This value is transmitted in Beacon and Probe Response frames. 2940 The value of this field comes from the IEEE 802.11 2941 dot11BeaconPeriod MIB element (see [IEEE.802-11.2007]). 2943 Country String: This attribute identifies the country in which the 2944 station is operating. The value of this field comes from the IEEE 2945 802.11 dot11CountryString MIB element (see [IEEE.802-11.2007]). 2946 Some regulatory domains do not allow WTPs to have user 2947 configurable country string, and require that it be a fixed value 2948 during the manufacturing process. Therefore, WTP vendors that 2949 wish to allow for the configuration of this field will need to 2950 validate this behavior during its radio certification process. 2951 Other WTP vendors may simply wish to treat this WTP configuration 2952 parameter as read-only. The country strings can be found in 2953 [ISO.3166-1]. 2955 The WTP and AC MAY ignore the value of this field, depending upon 2956 regulatory requirements, for example to avoid classification as a 2957 Software Defined Radio. When this field is used, the first two 2958 octets of this string is the two character country string as 2959 described in document [ISO.3166-1], and the third octet MUST 2960 either be a space, 'O', 'I' or X' as defined below. When the 2961 value of the third octet is 255 (HEX 0xff), the country string 2962 field is not used, and MUST be ignored. The following are the 2963 possible values for the third octet: 2965 1. an ASCII space character, if the regulations under which the 2966 station is operating encompass all environments in the country, 2968 2. an ASCII 'O' character, if the regulations under which the 2969 station is operating are for an outdoor environment only, or 2971 3. an ASCII 'I' character, if the regulations under which the 2972 station is operating are for an indoor environment only. 2974 4. an ASCII 'X' character, if the station is operating under a 2975 non-country entity. The first two octets of the non-country 2976 entity shall be two ASCII 'XX' characters. 2978 3. a HEX 0xff character means that the country string field is 2979 not used and MUST be ignored. 2981 Note that the last byte of the Country String MUST be set to NULL. 2983 6.24. IEEE 802.11 WTP Radio Fail Alarm Indication 2985 The IEEE 802.11 WTP Radio Fail Alarm Indication message element is 2986 sent by the WTP to the AC when it detects a radio failure. 2988 0 1 2 3 2989 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 2990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2991 | Radio ID | Type | Status | Pad | 2992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2994 Type: 1047 for IEEE 802.11 WTP Radio Fail Alarm Indication 2996 Length: 4 2998 Radio ID: The Radio Identifier, whose value is between one (1) and 2999 31, typically refers to some interface index on the WTP 3001 Type: The type of radio failure detected. The following enumerated 3002 values are supported: 3004 1 - Receiver 3005 2 - Transmitter 3007 Status: An 8-bit boolean indicating whether the radio failure is 3008 being reported or cleared. A value of zero is used to clear the 3009 event, while a value of one is used to report the event. 3011 Pad: All implementations complying with version zero of this 3012 protocol MUST set these bits to zero. Receivers MUST ignore all 3013 bits not defined for the version of the protocol they support. 3015 6.25. IEEE 802.11 WTP Radio Information 3017 The IEEE 802.11 WTP Radio Information message element is used to 3018 communicate the radio information for each IEEE 802.11 radio in the 3019 WTP. The Discovery Request message, Primary Discovery Request 3020 message and Join Request message MUST include one such message 3021 element per radio in the WTP. The Radio-Type field is used by the AC 3022 in order to determine which IEEE 802.11 technology specific binding 3023 is to be used with the WTP. 3025 The message element contains two fields, as shown below. 3027 0 1 2 3 3028 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 3029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3030 | Radio ID | Radio Type | 3031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3032 | Radio Type | 3033 +-+-+-+-+-+-+-+-+ 3035 Type: 1048 for IEEE 802.11 WTP Radio Information 3037 Length: 5 3039 Radio ID: The Radio Identifier, whose value is between one (1) and 3040 31, which typically refers to an interface index on the WTP 3042 Radio Type: The type of radio present. Note this is a bit field 3043 which is used to specify support for more than a single type of 3044 PHY/MAC. The field has the following format: 3046 0 1 2 3 4 5 6 7 3047 +-+-+-+-+-+-+-+-+ 3048 |Reservd|N|G|A|B| 3049 +-+-+-+-+-+-+-+-+ 3051 Reservd: A set of reserved bits for future use. All 3052 implementations complying with this protocol MUST set to zero 3053 any bits that are reserved in the version of the protocol 3054 supported by that implementation. Receivers MUST ignore all 3055 bits not defined for the version of the protocol they support. 3057 N: An IEEE 802.11n radio. 3059 G: An IEEE 802.11g radio. 3061 A: An IEEE 802.11a radio. 3063 B: An IEEE 802.11b radio. 3065 7. IEEE 802.11 Binding WTP Saved Variables 3067 This section contains the IEEE 802.11 binding specific variables that 3068 SHOULD be saved in non-volatile memory on the WTP. 3070 7.1. IEEE80211AntennaInfo 3072 The WTP per radio antenna configuration, defined in Section 6.2. 3074 7.2. IEEE80211DSControl 3076 The WTP per radio Direct Sequence Control configuration, defined in 3077 Section 6.5. 3079 7.3. IEEE80211MACOperation 3081 The WTP per radio MAC Operation configuration, defined in 3082 Section 6.7. 3084 7.4. IEEE80211OFDMControl 3086 The WTP per radio OFDM MAC Operation configuration, defined in 3087 Section 6.10. 3089 7.5. IEEE80211Rateset 3091 The WTP per radio Basic Rate Set configuration, defined in 3092 Section 6.11. 3094 7.6. IEEE80211TxPower 3096 The WTP per radio Transmit Power configuration, defined in 3097 Section 6.18. 3099 7.7. IEEE80211QoS 3101 The WTP per radio Quality of Service configuration, defined in 3102 Section 6.22. 3104 7.8. IEEE80211RadioConfig 3106 The WTP per radio Radio Configuration, defined in Section 6.23. 3108 8. Technology Specific Message Element Values 3110 This section lists IEEE 802.11 specific values for the generic CAPWAP 3111 message elements which include fields whose values are technology 3112 specific. 3114 8.1. WTP Descriptor Message Element, Encryption Capabilities Field: 3116 This specification defines two new bits for the WTP Descriptor's 3117 Encryption Capabilities field, as defined in 3118 [I-D.ietf-capwap-protocol-specification]. Note that only the bits 3119 defined in this specification are described below. The format of the 3120 Encryption Capabilities Field is: 3122 1 3123 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3125 | |A|T| | 3126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3128 A: WTP supports AES-CCMP, as defined in [IEEE.802-11.2007]. 3130 T: WTP supports TKIP and Michael, as defined in [IEEE.802-11.2007] 3131 and [WPA], respectively. 3133 9. Security Considerations 3135 This section describes security considerations for using IEEE 802.11 3136 with the CAPWAP protocol. A complete threat analysis of the CAPWAP 3137 protocol can also be found in [I-D.ietf-capwap-threat-analysis] 3139 9.1. IEEE 802.11 Security 3141 When used with an IEEE 802.11 infrastructure with WEP encryption, the 3142 CAPWAP protocol does not add any new vulnerabilities. Derived 3143 session keys between the STA and WTP can be compromised, resulting in 3144 many well-documented attacks. Implementers SHOULD discourage the use 3145 of WEP and encourage use of technically sound cryptographic solutions 3146 such as those in an IEEE 802.11 RSN. 3148 STA authentication is performed using IEEE 802.lX, and consequently 3149 EAP. Implementers SHOULD use EAP methods meeting the requirements 3150 specified [RFC4017]. 3152 When used with IEEE 802.11 RSN security, the CAPWAP protocol may 3153 introduce new vulnerabilities, depending on whether the link security 3154 (packet encryption and integrity verification) is provided by the WTP 3155 or the AC. When the link security function is provided by the AC, no 3156 new security concerns are introduced. 3158 However, when the WTP provides link security, a new vulnerability 3159 will exist when the following conditions are true: 3161 o The client is not the first to associate to the WTP/ESSID (i.e. 3162 other clients are associated), and a GTK already exists 3164 o traffic has been broadcast under the existing GTK 3166 Under these circumstances, the receive sequence counter (KeyRSC) 3167 associated with the GTK is non-zero, but because the AC anchors the 3168 4-way handshake with the client, the exact value of the KeyRSC is not 3169 known when the AC constructs the message containing the GTK. The 3170 client will update its Key RSC value to the current valid KeyRSC upon 3171 receipt of a valid multicast/broadcast message, but prior to this, 3172 previous multicast/broadcast traffic which was secured with the 3173 existing GTK may be replayed, and the client will accept this traffic 3174 as valid. 3176 Typically, busy networks will produce numerous multicast or broadcast 3177 frames per second, so the window of opportunity with respect to such 3178 replay is expected to be very small. In most conditions, it is 3179 expected that replayed frames could be detected (and logged) by the 3180 WTP. 3182 The only way to completely close this window is to provide the exact 3183 KeyRSC value in message 3 of the 4-way handshake; any other approach 3184 simply narrows the window to varying degrees. Given the low relative 3185 threat level this presents, the additional complexity introduced by 3186 providing the exact KeyRSC value is not warranted. That is, this 3187 specification provides for a calculated risk in this regard. 3189 The AC SHOULD use an RSC of 0 when computing message-3 of the 4-way 3190 802.11i handshake, unless the AC has knowledge of a more optimal RSC 3191 value to use. Mechanisms for determining a more optimal RSC value 3192 are outside the scope of this specification. 3194 10. IANA Considerations 3196 This section details the actions to be taken by IANA during the 3197 publication of the specification. There are numerous registries that 3198 need to be created, and the contents, document action (see [RFC5226], 3199 and registry format are all included below. Note that in cases where 3200 bit fields are referred to, the bit numbering is left to right, where 3201 the leftmost bit is labelled as bit zero (0). 3203 10.1. CAPWAP Wireless Binding Identifier 3205 This specification requires a value assigned from the Wireless 3206 Binding Identifier namespace, defined in 3207 [I-D.ietf-capwap-protocol-specification]. The value assigned is to 3208 be added to Section 2.1. The value of one (1)is highly recommended, 3209 as it is used in implementations. 3211 10.2. CAPWAP IEEE 802.11 Message Types 3213 This document creates a new sub-registry to the existing CAPWAP 3214 Message Type registry, which is defined in 3215 [I-D.ietf-capwap-protocol-specification]. 3217 IANA will create and maintain the CAPWAP IEEE 802.11 Message Types 3218 sub-registry for all message types whose Enterprise Number is set to 3219 13277. The namespace is 32 bits (0-4294967295), where the values 3220 3398911 and 3398912 are reserved and must not be assigned. The 3221 values 3398913 and 3398914 are allocated in this specification, and 3222 can be found in Section 3. Any new assignments of a CAPWAP IEEE 3223 802.11 Message Type, whose Enterprise Number is set to 13277) 3224 requires a Expert Review. The format of the registry to be 3225 maintained by IANA has the following format: 3227 CAPWAP IEEE 802.11 Message Type Reference 3228 Control Message Value 3230 10.3. CAPWAP Message Element Type 3232 This specification defines new values to be registered to the 3233 existing CAPWAP Message Element Type registry, defined in 3234 [I-D.ietf-capwap-protocol-specification]. The values used in this 3235 document, 1024 through 1048, as listed in Figure 8 are recommended as 3236 implementations already exist that make use of these values. 3238 10.4. IEEE 802.11 Key Status 3240 The Key Status field in the IEEE 802.11 Add WLAN message element (see 3241 Section 6.1) and IEEE 802.11 Update WLAN message element (see 3242 Section 6.21) is used to provide information about the status of the 3243 keying exchange. This document defines four values, and the 3244 remaining values are controlled and maintained by IANA and requires a 3245 Expert Review. 3247 10.5. IEEE 802.11 QoS 3249 The QoS field in the IEEE 802.11 Add WLAN message element (see 3250 Section 6.1) is used to configure a QoS policy for the WLAN. The 3251 namespace is 8 bits (0-255), where the values zero (0) through four 3252 (4) are allocated in this specification, and can be found in 3253 Section 6.1. This namespace is managed by IANA and assignments 3254 require a Expert Review. IANA will create the IEEE 802.11 QoS 3255 registry, whose format is: 3257 IEEE 802.11 QoS Type Value Reference 3259 10.6. IEEE 802.11 Auth Type 3261 The Auth Type field in the IEEE 802.11 Add WLAN message element (see 3262 Section 6.1) is 8 bits and is used to configure the IEEE 802.11 3263 authentication policy for the WLAN. The namespace is 8 bits (0-255), 3264 where the values zero (0) and one (1) are allocated in this 3265 specification, and can be found in Section 6.1. This namespace is 3266 managed by IANA and assignments require a Expert Review. IANA will 3267 create the IEEE 802.11 Auth Type registry, whose format is: 3269 IEEE 802.11 Auth Type Type Value Reference 3271 10.7. IEEE 802.11 Antenna Combiner 3273 The Combiner field in the IEEE 802.11 Antenna message element (see 3274 Section 6.2) is used to provide information about the WTP's antennas. 3275 The namespace is 8 bits (0-255), where the values zero (0) and one 3276 (1) are allocated in this specification, and can be found in 3277 Section 6.2. This namespace is managed by IANA and assignments 3278 require a Expert Review. IANA will create the IEEE 802.11 Antenna 3279 Combiner registry, whose format is: 3281 IEEE 802.11 Antenna Combiner Type Value Reference 3283 10.8. IEEE 802.11 Antenna Selection 3285 The Antenna Selection field in the IEEE 802.11 Antenna message 3286 element (see Section 6.2) is used to provide information about the 3287 WTP's antennas. The namespace is 8 bits (0-255), where the values 3288 zero (0) is reserved and used and the values one (1) through four (4) 3289 are allocated in this specification, and can be found in Section 6.2. 3291 This namespace is managed by IANA and assignments require a Expert 3292 Review. IANA will create the IEEE 802.11 Antenna Selection registry, 3293 whose format is: 3295 IEEE 802.11 Antenna Selection Type Value Reference 3297 10.9. IEEE 802.11 Session Key Flags 3299 The Flags field in the IEEE 802.11 Station Session Key message 3300 element (see Section 6.15) is 16 bits and is used to configure the 3301 session key association with the mobile device. This specification 3302 defines bits zero (0) and one (1), while bits two (2) through sixteen 3303 are reserved. The reserved bits are managed by IANA and whose 3304 assignment requires a Expert Review. IANA will create the IEEE 3305 802.11 Session Key Flags registry, whose format is: 3307 IEEE 802.11 Station Session Key Bit Position Reference 3309 10.10. IEEE 802.11 Tagging Policy 3311 The Tagging Policy field in the IEEE 802.11 WTP Quality of Service 3312 message element (see Section 6.22) is 8 bits and is used to specify 3313 how the CAPWAP Data Channel packets are to be tagged. This 3314 specification defines bits five (5) through seven (7). The remaining 3315 bits are managed by IANA and whose assignment requires a Expert 3316 Review. IANA will create the IEEE 802.11 Tagging Policy registry, 3317 whose format is: 3319 IEEE 802.11 Tagging Policy Bit Position Reference 3321 10.11. IEEE 802.11 WTP Radio Fail 3323 The Type field in the IEEE 802.11 WTP Radio Fail Alarm Indication 3324 message element (see Section 6.24) is used to provide information on 3325 why a WTP's radio has failed. The namespace is 8 bits (0-255), where 3326 the values zero (0) is reserved and unused, while the values one (1) 3327 and two (2) are allocated in this specification, and can be found in 3328 Section 6.24. This namespace is managed by IANA and assignments 3329 require a Expert Review. IANA will create the IEEE 802.11 WTP Radio 3330 Fail registry, whose format is: 3332 IEEE 802.11 WTP Radio Fail Type Value Reference 3334 10.12. IEEE 802.11 WTP Radio Type 3336 The Radio Type field in the IEEE 802.11 WTP Radio Information message 3337 element (see Section 6.25) is 8 bits and is used to provide 3338 information about the WTP's radio type. This specification defines 3339 bits five (5) through seven (7). The remaining bits are managed by 3340 IANA and whose assignment requires a Expert Review. IANA will create 3341 the IEEE 802.11 WTP Radio Type registry, whose format is: 3343 IEEE 802.11 WTP Radio Type Bit Position Reference 3345 11. Acknowledgments 3347 The following individuals are acknowledged for their contributions to 3348 this binding specification: Puneet Agarwal, Charles Clancy, Pasi 3349 Eronen, Saravanan Govindan, Scott Kelly, Peter Nilsson, Bob O'Hara, 3350 David Perkins, Margaret Wasserman and Yong Zhang. 3352 12. References 3354 12.1. Normative References 3356 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3357 Requirement Levels", BCP 14, RFC 2119, March 1997. 3359 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 3360 "Definition of the Differentiated Services Field (DS 3361 Field) in the IPv4 and IPv6 Headers", RFC 2474, 3362 December 1998. 3364 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 3365 "Assured Forwarding PHB Group", RFC 2597, June 1999. 3367 [RFC2598] Jacobson, V., Nichols, K., and K. Poduri, "An Expedited 3368 Forwarding PHB", RFC 2598, June 1999. 3370 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 3371 of Explicit Congestion Notification (ECN) to IP", 3372 RFC 3168, September 2001. 3374 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 3375 Levkowetz, "Extensible Authentication Protocol (EAP)", 3376 RFC 3748, June 2004. 3378 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3379 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 3380 May 2008. 3382 [FIPS.197.2001] 3383 National Institute of Standards and Technology, "Advanced 3384 Encryption Standard (AES)", FIPS PUB 197, November 2001, < 3385 http://csrc.nist.gov/publications/fips/fips197/ 3386 fips-197.pdf>. 3388 [ISO.3166-1] 3389 ISO Standard, "International Organization for 3390 Standardization, Codes for the representation of names of 3391 countries and their subdivisions - Part 1: Country codes", 3392 ISO Standard 3166-1:1997, 1997. 3394 [IEEE.802-11.2007] 3395 "Information technology - Telecommunications and 3396 information exchange between systems - Local and 3397 metropolitan area networks - Specific requirements - Part 3398 11: Wireless LAN Medium Access Control (MAC) and Physical 3399 Layer (PHY) specifications", IEEE Standard 802.11, 2007, < 3400 http://standards.ieee.org/getieee802/download/ 3401 802.11-2007.pdf>. 3403 [I-D.ietf-capwap-protocol-specification] 3404 Montemurro, M., Stanley, D., and P. Calhoun, "CAPWAP 3405 Protocol Specification", 3406 draft-ietf-capwap-protocol-specification-13 (work in 3407 progress), September 2008. 3409 [IEEE.802-1X.2004] 3410 "Information technology - Telecommunications and 3411 information exchange between systems - Local and 3412 metropolitan area networks - Specific requirements - Port- 3413 Based Network Access Control", IEEE Standard 802.1X, 2004, 3414 . 3417 [IEEE.802-1Q.2005] 3418 "Information technology - Telecommunications and 3419 information exchange between systems - Local and 3420 metropolitan area networks - Specific requirements - 3421 Virtual Bridged Local Area Networks", IEEE Standard 3422 802.1Q, 2005, . 3425 12.2. Informational References 3427 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 3428 Authentication Protocol (EAP) Method Requirements for 3429 Wireless LANs", RFC 4017, March 2005. 3431 [RFC4118] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy 3432 for Control and Provisioning of Wireless Access Points 3433 (CAPWAP)", RFC 4118, June 2005. 3435 [I-D.ietf-capwap-threat-analysis] 3436 Kelly, S. and C. Clancy, "CAPWAP Threat Analysis for IEEE 3437 802.11 Deployments", draft-ietf-capwap-threat-analysis-04 3438 (work in progress), September 2008. 3440 [WPA] "Deploying Wi-Fi Protected Access (WPA) and WPA2 in the 3441 Enterprise", March 2005, . 3443 [WMM] "Support for Multimedia Applications with Quality of 3444 Service in WiFi Networks)", September 2004, . 3447 Editors' Addresses 3449 Pat R. Calhoun 3450 Cisco Systems, Inc. 3451 170 West Tasman Drive 3452 San Jose, CA 95134 3454 Phone: +1 408-902-3240 3455 Email: pcalhoun@cisco.com 3457 Michael P. Montemurro 3458 Research In Motion 3459 5090 Commerce Blvd 3460 Mississauga, ON L4W 5M4 3461 Canada 3463 Phone: +1 905-629-4746 x4999 3464 Email: mmontemurro@rim.com 3466 Dorothy Stanley 3467 Aruba Networks 3468 1322 Crossman Ave 3469 Sunnyvale, CA 94089 3471 Phone: +1 630-363-1389 3472 Email: dstanley@arubanetworks.com 3474 Full Copyright Statement 3476 Copyright (C) The IETF Trust (2008). 3478 This document is subject to the rights, licenses and restrictions 3479 contained in BCP 78, and except as set forth therein, the authors 3480 retain all their rights. 3482 This document and the information contained herein are provided on an 3483 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3484 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 3485 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 3486 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3487 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3488 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3490 Intellectual Property 3492 The IETF takes no position regarding the validity or scope of any 3493 Intellectual Property Rights or other rights that might be claimed to 3494 pertain to the implementation or use of the technology described in 3495 this document or the extent to which any license under such rights 3496 might or might not be available; nor does it represent that it has 3497 made any independent effort to identify any such rights. Information 3498 on the procedures with respect to rights in RFC documents can be 3499 found in BCP 78 and BCP 79. 3501 Copies of IPR disclosures made to the IETF Secretariat and any 3502 assurances of licenses to be made available, or the result of an 3503 attempt made to obtain a general license or permission for the use of 3504 such proprietary rights by implementers or users of this 3505 specification can be obtained from the IETF on-line IPR repository at 3506 http://www.ietf.org/ipr. 3508 The IETF invites any interested party to bring to its attention any 3509 copyrights, patents or patent applications, or other proprietary 3510 rights that may cover technology that may be required to implement 3511 this standard. Please address the information to the IETF at 3512 ietf-ipr@ietf.org.