idnits 2.17.1 draft-ietf-capwap-protocol-binding-ieee80211-07.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 2846. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2857. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2864. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2870. 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 (July 10, 2008) is 5769 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.802-11.2007' == Outdated reference: A later version (-15) exists of draft-ietf-capwap-protocol-specification-10 -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.802-1X.2004' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.802-1Q.2005' Summary: 1 error (**), 0 flaws (~~), 2 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: January 11, 2009 Research In Motion 6 D. Stanley, Editor 7 Aruba Networks 8 July 10, 2008 10 CAPWAP Protocol Binding for IEEE 802.11 11 draft-ietf-capwap-protocol-binding-ieee80211-07 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 January 11, 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 . . . . . . . . . . . . 5 57 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 58 2. IEEE 802.11 Binding . . . . . . . . . . . . . . . . . . . . . 7 59 2.1. Split MAC and Local MAC Functionality . . . . . . . . . . 7 60 2.1.1. Split MAC . . . . . . . . . . . . . . . . . . . . . . 7 61 2.1.2. Local MAC . . . . . . . . . . . . . . . . . . . . . . 11 62 2.2. Roaming Behavior . . . . . . . . . . . . . . . . . . . . 13 63 2.3. Group Key Refresh . . . . . . . . . . . . . . . . . . . . 14 64 2.4. BSSID to WLAN ID Mapping . . . . . . . . . . . . . . . . 15 65 2.5. Quality of Service for IEEE 802.11 MAC Management 66 Messages . . . . . . . . . . . . . . . . . . . . . . . . 15 67 2.6. Run State Operation . . . . . . . . . . . . . . . . . . . 16 68 3. IEEE 802.11 Specific CAPWAP Control Messages . . . . . . . . . 17 69 3.1. IEEE 802.11 WLAN Configuration Request . . . . . . . . . 17 70 3.2. IEEE 802.11 WLAN Configuration Response . . . . . . . . . 18 71 4. CAPWAP Data Message Bindings . . . . . . . . . . . . . . . . . 19 72 5. CAPWAP Control Message bindings . . . . . . . . . . . . . . . 21 73 5.1. Discovery Request Message . . . . . . . . . . . . . . . . 21 74 5.2. Discovery Response Message . . . . . . . . . . . . . . . 21 75 5.3. Primary Discovery Request Message . . . . . . . . . . . . 21 76 5.4. Primary Discovery Response Message . . . . . . . . . . . 21 77 5.5. Join Request Message . . . . . . . . . . . . . . . . . . 21 78 5.6. Join Response Message . . . . . . . . . . . . . . . . . . 22 79 5.7. Configuration Status Message . . . . . . . . . . . . . . 22 80 5.8. Configuration Status Response Message . . . . . . . . . . 22 81 5.9. Configuration Update Request Message . . . . . . . . . . 23 82 5.10. Station Configuration Request . . . . . . . . . . . . . . 24 83 5.11. Change State Event Request . . . . . . . . . . . . . . . 24 84 5.12. WTP Event Request . . . . . . . . . . . . . . . . . . . . 24 86 6. IEEE 802.11 Message Element Definitions . . . . . . . . . . . 25 87 6.1. IEEE 802.11 Add WLAN . . . . . . . . . . . . . . . . . . 25 88 6.2. IEEE 802.11 Antenna . . . . . . . . . . . . . . . . . . . 30 89 6.3. IEEE 802.11 Assigned WTP BSSID . . . . . . . . . . . . . 32 90 6.4. IEEE 802.11 Delete WLAN . . . . . . . . . . . . . . . . . 32 91 6.5. IEEE 802.11 Direct Sequence Control . . . . . . . . . . . 33 92 6.6. IEEE 802.11 Information Element . . . . . . . . . . . . . 34 93 6.7. IEEE 802.11 MAC Operation . . . . . . . . . . . . . . . . 35 94 6.8. IEEE 802.11 MIC Countermeasures . . . . . . . . . . . . . 36 95 6.9. IEEE 802.11 Multi-Domain Capability . . . . . . . . . . . 37 96 6.10. IEEE 802.11 OFDM Control . . . . . . . . . . . . . . . . 38 97 6.11. IEEE 802.11 Rate Set . . . . . . . . . . . . . . . . . . 39 98 6.12. IEEE 802.11 RSNA Error Report From Station . . . . . . . 40 99 6.13. IEEE 802.11 Station . . . . . . . . . . . . . . . . . . . 42 100 6.14. IEEE 802.11 Station QoS Profile . . . . . . . . . . . . . 43 101 6.15. IEEE 802.11 Station Session Key . . . . . . . . . . . . . 43 102 6.16. IEEE 802.11 Statistics . . . . . . . . . . . . . . . . . 45 103 6.17. IEEE 802.11 Supported Rates . . . . . . . . . . . . . . . 49 104 6.18. IEEE 802.11 Tx Power . . . . . . . . . . . . . . . . . . 49 105 6.19. IEEE 802.11 Tx Power Level . . . . . . . . . . . . . . . 50 106 6.20. IEEE 802.11 Update Station QoS . . . . . . . . . . . . . 50 107 6.21. IEEE 802.11 Update WLAN . . . . . . . . . . . . . . . . . 51 108 6.22. IEEE 802.11 WTP Quality of Service . . . . . . . . . . . 53 109 6.23. IEEE 802.11 WTP Radio Configuration . . . . . . . . . . . 54 110 6.24. IEEE 802.11 WTP Radio Fail Alarm Indication . . . . . . . 56 111 6.25. IEEE 802.11 WTP Radio Information . . . . . . . . . . . . 57 112 7. IEEE 802.11 Binding WTP Saved Variables . . . . . . . . . . . 59 113 7.1. IEEE80211AntennaInfo . . . . . . . . . . . . . . . . . . 59 114 7.2. IEEE80211DSControl . . . . . . . . . . . . . . . . . . . 59 115 7.3. IEEE80211MACOperation . . . . . . . . . . . . . . . . . . 59 116 7.4. IEEE80211OFDMControl . . . . . . . . . . . . . . . . . . 59 117 7.5. IEEE80211Rateset . . . . . . . . . . . . . . . . . . . . 59 118 7.6. IEEE80211TxPower . . . . . . . . . . . . . . . . . . . . 59 119 7.7. IEEE80211QoS . . . . . . . . . . . . . . . . . . . . . . 59 120 7.8. IEEE80211RadioConfig . . . . . . . . . . . . . . . . . . 59 121 8. Technology Specific Message Element Values . . . . . . . . . . 60 122 8.1. WTP Descriptor Message Element, Encryption 123 Capabilities Field: . . . . . . . . . . . . . . . . . . . 60 124 9. Security Considerations . . . . . . . . . . . . . . . . . . . 61 125 9.1. IEEE 802.11 Security . . . . . . . . . . . . . . . . . . 61 126 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 63 127 10.1. CAPWAP Message Types . . . . . . . . . . . . . . . . . . 63 128 10.2. CAPWAP Control Message Type . . . . . . . . . . . . . . . 63 129 10.3. IEEE 802.11 Key Status . . . . . . . . . . . . . . . . . 63 130 10.4. IEEE 802.11 QoS . . . . . . . . . . . . . . . . . . . . . 63 131 10.5. IEEE 802.11 Auth Type . . . . . . . . . . . . . . . . . . 63 132 10.6. IEEE 802.11 Antenna Combiner . . . . . . . . . . . . . . 63 133 10.7. IEEE 802.11 Antenna Selection . . . . . . . . . . . . . . 63 134 10.8. IEEE 802.11 Session Key Flags . . . . . . . . . . . . . . 64 135 10.9. IEEE 802.11 Tag Packets . . . . . . . . . . . . . . . . . 64 136 10.10. IEEE 802.11 WTP Radio Fail . . . . . . . . . . . . . . . 64 137 10.11. IEEE 802.11 WTP Radio Type . . . . . . . . . . . . . . . 64 138 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 65 139 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 66 140 12.1. Normative References . . . . . . . . . . . . . . . . . . 66 141 12.2. Informational References . . . . . . . . . . . . . . . . 67 142 Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 68 143 Intellectual Property and Copyright Statements . . . . . . . . . . 69 145 1. Introduction 147 This specification defines the Control And Provisioning of Wireless 148 Access Points (CAPWAP) Protocol Binding Specification for use with 149 the IEEE 802.11 Wireless Local Area Network protocol. The CAPWAP 150 Protocol Specification is defined separately 151 [I-D.ietf-capwap-protocol-specification]. Use of CAPWAP control 152 message fields, new control messages and message elements are 153 defined. The minimum required definitions for a binding-specific 154 Statistics message element, Station message element, and WTP Radio 155 Information message element are included. 157 1.1. Goals 159 The goals for this CAPWAP protocol binding are listed below: 161 1. To centralize the authentication and policy enforcement functions 162 for an IEEE 802.11 wireless network. The AC may also provide 163 centralized bridging, forwarding, and encryption of user traffic. 164 Centralization of these functions will enable reduced cost and 165 higher efficiency by applying the capabilities of network 166 processing silicon to the wireless network, as in wired LANs. 168 2. To enable shifting of the higher level protocol processing from 169 the WTP. This leaves the time-critical applications of wireless 170 control and access in the WTP, making efficient use of the 171 computing power available in WTPs which are subject to severe cost 172 pressure. 174 The CAPWAP protocol binding extensions defined herein apply solely to 175 the interface between the WTP and the AC. Inter-AC and station-to-AC 176 communication are strictly outside the scope of this document. 178 1.2. Conventions used in this document 180 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 181 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 182 document are to be interpreted as described in RFC 2119 [RFC2119]. 184 1.3. Terminology 186 This section contains definitions for terms used frequently 187 throughout this document. However, many additional definitions can 188 be found in [IEEE.802-11.2007]. 190 Access Controller (AC): The network entity that provides WTP access 191 to the network infrastructure in the data plane, control plane, 192 management plane, or a combination therein. 194 Basic Service Set (BSS): A set of stations controlled by a single 195 coordination function. 197 Distribution: The service that, by using association information, 198 delivers medium access control (MAC) service data units (MSDUs) 199 within the distribution system (DS). 201 Distribution System Service (DSS): The set of services provided by 202 the distribution system (DS) that enable the medium access control 203 (MAC) layer to transport MAC service data units (MSDUs) between 204 stations that are not in direct communication with each other over a 205 single instance of the wireless medium (WM). These services include 206 the transport of MSDUs between the access points (APs) of basic 207 service sets (BSSs) within an extended service set (ESS), transport 208 of MSDUs between portals and BSSs within an ESS, and transport of 209 MSDUs between stations in the same BSS in cases where the MSDU has a 210 multicast or broadcast destination address, or where the destination 211 is an individual address, but the station sending the MSDU chooses to 212 involve the DSS. DSSs are provided between pairs of IEEE 802.11 213 MACs. 215 Integration: The service that enables delivery of medium access 216 control (MAC) service data units (MSDUs) between the distribution 217 system (DS) and an existing, non-IEEE 802.11 local area network (via 218 a portal). 220 Station (STA): A device that contains an IEEE 802.11 conformant 221 medium access control (MAC) and physical layer (PHY) interface to the 222 wireless medium (WM). 224 Portal: The logical point at which medium access control (MAC) 225 service data units (MSDUs) from a non-IEEE 802.11 local area network 226 (LAN) enter the distribution system (DS) of an extended service set 227 (ESS). 229 WLAN: In this document, WLAN refers to a logical component 230 instantiated on a WTP device. A single physical WTP may operate a 231 number of WLANs. Each Basic Service Set Identifier (BSSID) and its 232 constituent wireless terminal radios is denoted as a distinct WLAN on 233 a physical WTP. 235 Wireless Termination Point (WTP): The physical or network entity that 236 contains an IEEE 802.11 RF antenna and wireless PHY to transmit and 237 receive station traffic for wireless access networks. 239 2. IEEE 802.11 Binding 241 This section describes use of the CAPWAP protocol with the IEEE 242 802.11 Wireless Local Area Network protocol, including Local and 243 Split MAC operation, Group Key Refresh, Basic Service Set 244 Identification (BSSID) to WLAN Mapping, IEEE 802.11 MAC management 245 frame Quality of Service tagging and Run State operation. 247 2.1. Split MAC and Local MAC Functionality 249 The CAPWAP protocol, when used with IEEE 802.11 devices, requires 250 specific behavior from the WTP and the AC to support the required 251 IEEE 802.11 protocol functions. 253 For both the Split and Local MAC approaches, the CAPWAP functions, as 254 defined in the taxonomy specification [RFC4118], reside in the AC. 256 To provide system component interoperability, the WTP and AC MUST 257 support 802.11 encryption/decryption at the WTP. The WTP and AC MAY 258 support 802.11 encryption/decryption at the AC. 260 2.1.1. Split MAC 262 This section shows the division of labor between the WTP and the AC 263 in a Split MAC architecture. Figure 1 shows the separation of 264 functionality between CAPWAP components. 266 Function Location 267 Distribution Service AC 268 Integration Service AC 269 Beacon Generation WTP 270 Probe Response Generation WTP 271 Power Mgmt/Packet Buffering WTP 272 Fragmentation/Defragmentation WTP/AC 273 Assoc/Disassoc/Reassoc AC 275 IEEE 802.11 QOS 276 Classifying AC 277 Scheduling WTP/AC 278 Queuing WTP 280 IEEE 802.11 RSN 281 IEEE 802.1X/EAP AC 282 RSNA Key Management AC 283 IEEE 802.11 Encryption/Decryption WTP/AC 285 Figure 1: Mapping of 802.11 Functions for Split MAC Architecture 287 In a Split MAC Architecture, the Distribution and Integration 288 services reside on the AC, and therefore all user data is tunneled 289 between the WTP and the AC. As noted above, all real-time IEEE 290 802.11 services, including the Beacon and Probe Response frames, are 291 handled on the WTP. 293 All remaining IEEE 802.11 MAC management frames are supported on the 294 AC, including the Association Request frame which allows the AC to be 295 involved in the access policy enforcement portion of the IEEE 802.11 296 protocol. The IEEE 802.1X [IEEE.802-1X.2004], Extensible 297 Authentication Protocol (EAP) [RFC3748] and IEEE Robust Security 298 Network Association (RSNA) Key Management [IEEE.802-11.2007] 299 functions are also located on the AC. This implies that the AAA 300 client also resides on the AC. 302 While the admission control component of IEEE 802.11 resides on the 303 AC, the real time scheduling and queuing functions are on the WTP. 304 Note that this does not prevent the AC from providing additional 305 policy and scheduling functionality. 307 Note that in the following figure, the use of '( - )' indicates that 308 processing of the frames is done on the WTP. 310 Client WTP AC 312 Beacon 313 <----------------------------- 314 Probe Request 315 ----------------------------( - )-------------------------> 316 Probe Response 317 <----------------------------- 318 802.11 AUTH/Association 319 <---------------------------------------------------------> 320 Station Configuration Request 321 [Add Station (Station Message 322 Elements)] 323 <--------------------------> 324 802.1X Authentication & 802.11 Key Exchange 325 <---------------------------------------------------------> 326 Station Configuration Request 327 [Add Station (AES-CCMP, 328 PTK=x)] 329 <--------------------------> 330 802.11 Action Frames 331 <---------------------------------------------------------> 332 802.11 DATA (1) 333 <---------------------------( - )-------------------------> 334 Figure 2: Split MAC Message Flow 336 Figure 2 provides an illustration of the division of labor in a Split 337 MAC architecture. In this example, a WLAN has been created that is 338 configured for IEEE 802.11, using 802.1X based end user 339 authentication and AES-CCMP link layer encryption (Counter mode with 340 Cipher-block chaining Message authentication code Protocol, see 341 [FIPS.197.2001]). The following process occurs: 343 o The WTP generates the IEEE 802.11 Beacon frames, using information 344 provided to it through the IEEE 802.11 Add WLAN (see Section 6.1) 345 message element, including the RSNIE, which indicates support of 346 802.1X and AES-CCMP. 348 o The WTP processes the Probe Request frame and responds with a 349 corresponding Probe Response frame. The Probe Request frame is 350 then forwarded to the AC for optional processing. 352 o The WTP forwards the IEEEE 802.11 Authentication and Association 353 frames to the AC, which is responsible for responding to the 354 client. 356 o Once the association is complete, the AC transmits a Station 357 Configuration Request message, which includes an Add Station 358 message element, to the WTP (see Section 4.6.8 in 359 [I-D.ietf-capwap-protocol-specification]). In the above example, 360 the WLAN was configured for IEEE 802.1X. 362 o If the WTP is providing encryption/decryption services, once the 363 client has completed the IEEE 802.11 key exchange, the AC 364 transmits another Station Configuration Request message which 365 includes an Add Station message element, an IEEE 802.11 Station 366 message element, an IEEE 802.11 Station Session Key message 367 element and an IEEE 802.11 Information Element message element 368 which includes the Robust Security Network Information Element 369 (RSNIE) to the WTP, delivering the security policy to enforce for 370 the station (in this case AES-CCMP), and the encryption key to 371 use. If encryption/decryption is handled in the AC, the IEEE 372 802.11 Information message element with an RSNIE would not be 373 included. 375 o The WTP forwards any IEEE 802.11 Management Action frames received 376 to the AC. 378 o All IEEE 802.11 station data frames are tunneled between the WTP 379 and the AC. 381 The WTP SHALL include the IEEE 802.11 MAC header contents in all 382 frames transmitted to the AC. 384 When 802.11 encryption/decryption is performed at the WTP, the WTP 385 MUST decrypt the uplink frames, MUST set the Protected Frame field to 386 0, and MUST make the frame format consistent with that of an 387 unprotected 802.11 frame prior to transmitting the frames to the AC. 388 The fields added to an 802.11 protected frame (i.e., Initialization 389 Vector/Extended Initialization Vector (IV/EIV), Message Integrity 390 Code (MIC), and Integrity Check Value (ICV)) MUST be stripped off 391 prior to transmission from the WTP to AC. For downlink frames, the 392 Protected Frame field MUST be set to 0 by the AC as the frame being 393 sent is unencrypted. The WTP MUST apply the required protection 394 policy for the WLAN, and set the Protected Frame field on 395 transmission over the air. The Protected Frame field always needs to 396 accurately indicate the status of the 802.11 frame that is carrying 397 it. 399 When 802.11 encryption/decryption is performed at the AC, the WTP 400 SHALL NOT decrypt the uplink frames prior to transmitting the frames 401 to the AC. The AC and WTP SHALL populate the IEEE 802.11 MAC header 402 fields as described in Figure 3. 404 MAC header field Location 405 Frame Control: 406 Version AC 407 ToDS AC 408 FromDS AC 409 Type AC 410 SubType AC 411 MoreFrag WTP/AC 412 Retry WTP 413 Pwr Mgmt - 414 MoreData WTP 415 Protected WTP/AC 416 Order AC 417 Duration: WTP 418 Address 1: AC 419 Address 2: AC 420 Address 3: AC 421 Sequence Ctrl: WTP 422 Address 4: AC 423 QoS Control: AC 424 Frame Body: AC 425 FCS: WTP 427 Figure 3: Population of the IEEE 802.11 MAC header Fields for 428 Downlink Frames 430 When 802.11 encryption/decryption is performed at the AC, the 431 MoreFrag bit is populated at the AC. The Pwr Mgmt bit is not 432 applicable to downlink frames, and is set to 0. Note that the Frame 433 Check Sequence (FCS) field is not included in 802.11 frames exchanged 434 between the WTP and the AC. Upon sending data frames to the AC, the 435 WTP is responsible for validating, and stripping the FCS field. Upon 436 receiving data frames from the AC, the WTP is responsible for adding 437 the FCS field, and populating the field as described in 438 [IEEE.802-11.2007]. 440 2.1.2. Local MAC 442 This section shows the division of labor between the WTP and the AC 443 in a Local MAC architecture. Figure 4 shows the separation of 444 functionality among CAPWAP components. 446 Function Location 447 Distribution Service WTP/AC 448 Integration Service WTP 449 Beacon Generation WTP 450 Probe Response Generation WTP 451 Power Mgmt/Packet Buffering WTP 452 Fragmentation/Defragmentation WTP 453 Assoc/Disassoc/Reassoc WTP/AC 455 IEEE 802.11 QOS 456 Classifying WTP 457 Scheduling WTP 458 Queuing WTP 460 IEEE 802.11 RSN 461 IEEE 802.1X/EAP AC 462 RSNA Key Management AC 463 IEEE 802.11 Encryption/Decryption WTP 465 Figure 4: Mapping of 802.11 Functions for Local AP Architecture 467 In the Local MAC mode, the integration service exists on the WTP, 468 while the distribution service MAY reside on either the WTP or the 469 AC. When it resides on the AC, station generated frames are not 470 forwarded to the AC in their native format, but encapsulated as 802.3 471 frames. 473 While the MAC is terminated on the WTP, it is necessary for the AC to 474 be aware of mobility events within the WTPs. Thus the WTP MUST 475 forward the IEEE 802.11 Association Request frames to the AC. The AC 476 MAY reply with a failed Association Response frame if it deems it 477 necessary, and upon receipt of a failed Association Response frame 478 from the AC, the WTP MUST send a Disassociation frame to the station. 480 The IEEE 802.1X [IEEE.802-1X.2004], EAP and IEEE RSNA Key Management 481 [IEEE.802-11.2007] functions reside in the AC. Therefore, the WTP 482 MUST forward all IEEE 802.1X, EAP and RSNA Key Management frames to 483 the AC and forward the corresponding responses to the station. This 484 implies that the AAA client also resides on the AC. 486 Note that in the following figure, the use of '( - )' indicates that 487 processing of the frames is done on the WTP. 489 Client WTP AC 491 Beacon 492 <----------------------------- 493 Probe 494 <----------------------------> 495 802.11 AUTH 496 <----------------------------- 497 802.11 Association 498 <---------------------------( - )-------------------------> 499 Station Configuration Request[ 500 Add Station (Station Message 501 Elements)] 502 <--------------------------> 503 802.1X Authentication & 802.11 Key Exchange 504 <---------------------------------------------------------> 505 802.11 Action Frames 506 <---------------------------------------------------------> 507 Station Configuration Request[ 508 Add Station (AES-CCMP, 509 PTK=x)] 510 <--------------------------> 511 802.11 DATA 512 <-----------------------------> 514 Figure 5: Local MAC Message Flow 516 Figure 5 provides an illustration of the division of labor in a Local 517 MAC architecture. In this example, a WLAN that is configured for 518 IEEE 802.11 has been created using AES-CCMP for privacy. The 519 following process occurs: 521 o The WTP generates the IEEE 802.11 Beacon frames, using information 522 provided to it through the Add WLAN (see Section 6.1) message 523 element. 525 o The WTP processes a Probe Request frame and responds with a 526 corresponding Probe Response frame. 528 o The WTP forwards the IEEE 802.11 Authentication and Association 529 frames to the AC. 531 o Once the association is complete, the AC transmits a Station 532 Configuration Request message, which includes the Add Station 533 message element, to the WTP (see Section 4.6.8 in 534 [I-D.ietf-capwap-protocol-specification]). In the above example, 535 the WLAN is configured for IEEE 802.1X, and therefore the '802.1X 536 only' policy bit is enabled. 538 o The WTP forwards all IEEE 802.1X and IEEE 802.11 key exchange 539 messages to the AC for processing. 541 o The AC transmits another Station Configuration Request message 542 including an Add Station message element, an IEEE 802.11 Station 543 message element, an IEEE 802.11 Station Session Key message 544 element and an IEEE 802.11 Information Element message element 545 which includes the RSNIE to the WTP, stating the security policy 546 to enforce for the client (in this case AES-CCMP), as well as the 547 encryption key to use. The Add Station message element MAY 548 include a Virtual LAN (VLAN) [IEEE.802-1Q.2005] name , which when 549 present is used by the WTP to identify the VLAN on which the 550 user's data frames are to be bridged. 552 o The WTP forwards any IEEE 802.11 Management Action frames received 553 to the AC. 555 o The WTP MAY locally bridge client data frames (and provide the 556 necessary encryption and decryption services). The WTP MAY also 557 tunnel client data frames to the AC, using 802.3 frame tunnel mode 558 or 802.11 frame tunnel mode. 560 2.2. Roaming Behavior 562 This section expands upon the examples provided in the previous 563 section, and describes how the CAPWAP control protocol is used to 564 provide secure roaming. 566 Once a client has successfully associated with the network in a 567 secure fashion, it is likely to attempt to roam to another WTP. 568 Figure 6 shows an example of a currently associated station moving 569 from its "Old WTP" to a "New WTP". The figure is valid for multiple 570 different security policies, including IEEE 802.1X and Wireless 571 Protected Access (WPA) or Wireless Protected Access 2 (WPA2) [WPA], 572 both with key caching (where the IEEE 802.1x exchange would be 573 bypassed) and without. 575 Client Old WTP New WTP AC 577 Association Request/Response 578 <--------------------------------------( - )--------------> 579 Station Configuration Request[ 580 Add Station (Station Message 581 Elements)] 582 <----------------> 583 802.1X Authentication (if no key cache entry exists) 584 <--------------------------------------( - )--------------> 585 802.11 4-way Key Exchange 586 <--------------------------------------( - )--------------> 587 Station Configuration Request 588 [Delete Station] 589 <----------------------------------> 590 Station Configuration Request 591 [Add Station (AES-CCMP, 592 PTK=x)] 593 <----------------> 595 Figure 6: Client Roaming Example 597 2.3. Group Key Refresh 599 Periodically, the Group Key (GTK)for the BSS needs to be updated. 600 The AC uses an EAPOL-Key frame to update the group key for each STA 601 in the BSS. While the AC is updating the GTK, each L2 broadcast 602 frame transmitted to the BSS needs to be duplicated and transmitted 603 using both the current GTK and the new GTK. Once the GTK update 604 process has completed, broadcast frames transmitted to the BSS will 605 be encrypted using the new GTK. 607 In the case of Split MAC, the AC needs to duplicate all broadcast 608 packets and update the key index so that the packet is transmitted 609 using both the current and new GTK to ensure that all STA's in the 610 BSS receive the broadcast frames. In the case of local MAC, the WTP 611 needs to duplicate and transmit broadcast frames using the 612 appropriate index to ensure that all STA's in the BSS continue to 613 receive broadcast frames. 615 The Group Key update procedure is shown in the following figure. The 616 AC will signal the update to the GTK using an IEEE 802.11 617 Configuration Request message, including an IEEE 802.11 Update WLAN 618 message element with the new GTK, its index, the TSC for the Group 619 Key and the Key Status set to 3 (begin GTK update). The AC will then 620 begin updating the GTK for each STA. During this time, the AC (for 621 Split MAC) or WTP (for Local MAC) MUST duplicate broadcast packets 622 and transmit them encrypted with both the current and new GTK. When 623 the AC has completed the GTK update to all STA's in the BSS, the AC 624 MUST transmit an IEEE 802.11 Configuration Request message including 625 an IEEE 802.11 Update WLAN message element containing the new GTK, 626 its index, and the Key Status set to 4 (GTK update complete). 628 Client WTP AC 630 IEEE 802.11 WLAN Configuration Request [Update 631 WLAN (GTK, GTK Index, GTK Start, 632 Group TSC) ] 633 <-------------------------------------------- 634 802.1X EAPoL (GTK Message 1) 635 <-------------( - )------------------------------------------- 636 802.1X EAPoL (GTK Message 2) 637 -------------( - )-------------------------------------------> 638 IEEE 802.11 WLAN Configuration Request [ Update 639 WLAN (GTK Index, GTK Complete) ] 640 <-------------------------------------------- 642 Figure 7: Group Key Update Procedure 644 2.4. BSSID to WLAN ID Mapping 646 The CAPWAP protocol binding enables the WTP to assign BSSIDs upon 647 creation of a WLAN (see Section 6.1). While manufacturers are free 648 to assign BSSIDs using any arbitrary mechanism, it is advised that 649 where possible the BSSIDs are assigned as a contiguous block. 651 When assigned as a block, implementations can still assign any of the 652 available BSSIDs to any WLAN. One possible method is for the WTP to 653 assign the address using the following algorithm: base BSSID address 654 + WLAN ID. 656 The WTP communicates the maximum number of BSSIDs that it supports 657 during configuration via the IEEE 802.11 WTP WLAN Radio Configuration 658 message element (see Section 6.23). 660 2.5. Quality of Service for IEEE 802.11 MAC Management Messages 662 It is recommended that IEEE 802.11 MAC Management frames be sent by 663 both the AC and the WTP with appropriate Quality of Service values, 664 listed below, to ensure that congestion in the network minimizes 665 occurrences of packet loss. 667 802.1p: The precedence value of 7 SHOULD be used for all IEEE 668 802.11 MAC management frames, except for Probe Requests which 669 SHOULD use 4. 671 DSCP: The DSCP tag value of 46 SHOULD be used for all IEEE 802.11 672 MAC management frames, except for Probe Requests which SHOULD use 673 34. 675 2.6. Run State Operation 677 The Run state is the normal state of operation for the CAPWAP 678 protocol in both the WTP and the AC. 680 When the WTP receives a WLAN Configuration Request message (see 681 Section 3.1), it MUST respond with a WLAN Configuration Response 682 message (see Section 3.2) and it remains in the Run state. 684 When the AC sends a WLAN Configuration Request message (see 685 Section 3.1) or receives the corresponding WLAN Configuration 686 Response message (see Section 3.2) from the WTP, it remains in the 687 Run state. 689 3. IEEE 802.11 Specific CAPWAP Control Messages 691 This section defines CAPWAP Control Messages that are specific to the 692 IEEE 802.11 binding. Two messages are defined, IEEE 802.11 WLAN 693 Configuration Request and IEEE 802.11 WLAN Configuration Response. 694 See Section 4.5 in [I-D.ietf-capwap-protocol-specification] for 695 CAPWAP Control message definitions and the derivation of the Message 696 Type value from the IANA Enterprise number. 698 The valid message types for IEEE 802.11 specific control messages are 699 listed below. The IANA Enterprise number used with these messages is 700 13277. 702 CAPWAP Control Message Message Type 703 Value 705 IEEE 802.11 WLAN Configuration Request 3398912 706 IEEE 802.11 WLAN Configuration Response 3398913 708 3.1. IEEE 802.11 WLAN Configuration Request 710 The IEEE 802.11 WLAN Configuration Request is sent by the AC to the 711 WTP in order to change services provided by the WTP. This control 712 message is used to either create, update or delete a WLAN on the WTP. 714 The IEEE 802.11 WLAN Configuration Request is sent as a result of 715 either some manual administrative process (e.g., deleting a WLAN), or 716 automatically to create a WLAN on a WTP. When sent automatically to 717 create a WLAN, this control message is sent after the CAPWAP 718 Configuration Update Request message (see Section 8.4 in 719 [I-D.ietf-capwap-protocol-specification]) has been received by the 720 WTP. 722 Upon receiving this control message, the WTP will modify the 723 necessary services, and transmit an IEEE 802.11 WLAN Configuration 724 Response. 726 A WTP MAY provide service for more than one WLAN, therefore every 727 WLAN is identified through a numerical index. For instance, a WTP 728 that is capable of supporting up to 16 Service Set Identifiers 729 (SSIDs), could accept up to 16 IEEE 802.11 WLAN Configuration Request 730 messages that include the Add WLAN message element. 732 Since the index is the primary identifier for a WLAN, an AC MAY 733 attempt to ensure that the same WLAN is identified through the same 734 index number on all of its WTPs. An AC that does not follow this 735 approach MUST find some other means of maintaining a WLAN-Identifier- 736 to-SSID mapping table. 738 The following message elements MAY be included in the IEEE 802.11 739 WLAN Configuration Request message. Only one message element MUST be 740 present. 742 o IEEE 802.11 Add WLAN, see Section 6.1 744 o IEEE 802.11 Delete WLAN, see Section 6.4 746 o IEEE 802.11 Update WLAN, see Section 6.21 748 The following message element MAY be present. 750 o IEEE 802.11 Information Element, see Section 6.6 752 o Vendor Specific Payload, see 753 [I-D.ietf-capwap-protocol-specification] 755 3.2. IEEE 802.11 WLAN Configuration Response 757 The IEEE 802.11 WLAN Configuration Response message is sent by the 758 WTP to the AC. It is used to acknowledge receipt of an IEEE 802.11 759 WLAN Configuration Request message, and to indicate that the 760 requested configuration was successfully applied, or that an error 761 related to the processing of the IEEE 802.11 WLAN Configuration 762 Request message occurred on the WTP. 764 The following message element MUST be included in the IEEE 802.11 765 WLAN Configuration Response message. 767 o Result Code, see Section 4.6.35 in 768 [I-D.ietf-capwap-protocol-specification] 770 The following message element MAY be included in the IEEE 802.11 WLAN 771 Configuration Response message. 773 o IEEE 802.11 Assigned WTP BSSID, see Section 6.3 775 o Vendor Specific Payload, see 776 [I-D.ietf-capwap-protocol-specification] 778 4. CAPWAP Data Message Bindings 780 This section describes the CAPWAP Data Message bindings to support 781 transport of IEEE 802.11 frames. 783 Payload encapsulation: The CAPWAP protocol defines the CAPWAP data 784 message, which is used to encapsulate a wireless payload. For 785 IEEE 802.11, the IEEE 802.11 header and payload are encapsulated 786 (excluding the IEEE 802.11 FCS checksum). The IEEE 802.11 FCS 787 checksum is handled by the WTP. This allows the WTP to validate 788 an IEEE 802.11 frame prior to sending it to the AC. Similarly, 789 when an AC wishes to transmit a frame to a station, the WTP 790 computes and adds the FCS checksum. 792 Optional Wireless Specific Information: This optional CAPWAP header 793 field (see Section 4.3 in 794 [I-D.ietf-capwap-protocol-specification]) is only used with CAPWAP 795 data messages, and it serves two purposes, depending upon the 796 direction of the message. For messages from the WTP to the AC, 797 the field uses the format described in the "IEEE 802.11 Frame 798 Info" field (see below). However, for messages sent by the AC to 799 the WTP, the format used is described in the "Destination WLANs" 800 field (also defined below). 802 Note that in both cases, the two optional headers fit in the 803 "Data" field of the Wireless Specific Information header. 805 IEEE 802.11 Frame Info: When an IEEE 802.11 frame is received from a 806 station over the air, it is encapsulated and this field is used to 807 include radio and PHY specific information associated with the 808 frame. 810 The IEEE 802.11 Frame Info field has the following format: 812 0 1 2 3 813 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 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | RSSI | SNR | Data Rate | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 RSSI: RSSI is a signed, 8-bit value. It is the received signal 819 strength indication, in dBm. 821 SNR: SNR is a signed, 8-bit value. It is the signal to noise 822 ratio of the received IEEE 802.11 frame, in dB. 824 Data Rate: The data rate field is a 16 bit unsigned value. The 825 data rate field is a 16 bit unsigned value expressing the data 826 rate of the packets received by the WTP in units of 0.1 Mbps. 827 For instance, a packet received at 5.5Mbps would be set to 55, 828 while 11Mbps would be set to 110. 830 Destination WLANs The Destination WLANs field is used to specify the 831 target WLANs for a given frame, and is only used with broadcast 832 and multicast frames. This field allows the AC to transmit a 833 single broadcast or multicast frame to the WTP, and allows the WTP 834 to perform the necessary frame replication. The field uses the 835 following format: 837 0 1 2 3 838 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 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 | WLAN ID bitmap | Reserved | 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 WLAN ID bitmap: This bit field indicates the WLAN ID (see 844 Section 6.1) on which the WTP will transmit the included frame. 845 For instance, if a multicast packet is to be transmitted on 846 WLANs 1 and 3, bits 1 and 3 of this field would be enabled. 847 This field is to be set to all zeroes for unicast packets and 848 is unused if the WTP is not providing IEEE 802.11 encryption. 850 Reserved: All implementations complying with this protocol MUST 851 set to zero any bits that are reserved in the version of the 852 protocol supported by that implementation. Receivers MUST 853 ignore all bits not defined for the version of the protocol 854 they support. 856 5. CAPWAP Control Message bindings 858 This section describes the IEEE 802.11 specific message elements 859 included in CAPWAP Control Messages. 861 5.1. Discovery Request Message 863 The following IEEE 802.11 specific message element MUST be included 864 in the CAPWAP Discovery Request Message. 866 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 867 802.11 WTP Radio Information message element MUST be present for 868 every radio in the WTP. 870 5.2. Discovery Response Message 872 The following IEEE 802.11 specific message element MUST be included 873 in the CAPWAP Discovery Response Message. 875 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 876 802.11 WTP Radio Information message element MUST be present for 877 every radio in the WTP. 879 5.3. Primary Discovery Request Message 881 The following IEEE 802.11 specific message element MUST be included 882 in the CAPWAP Primary Discovery Request Message. 884 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 885 802.11 WTP Radio Information message element MUST be present for 886 every radio in the WTP. 888 5.4. Primary Discovery Response Message 890 The following IEEE 802.11 specific message element MUST be included 891 in the CAPWAP Primary Discovery Response Message. 893 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 894 802.11 WTP Radio Information message element MUST be present for 895 every radio in the WTP. 897 5.5. Join Request Message 899 The following IEEE 802.11 specific message element MUST be included 900 in the CAPWAP Join Request Message. 902 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 903 802.11 WTP Radio Information message element MUST be present for 904 every radio in the WTP. 906 5.6. Join Response Message 908 The following IEEE 802.11 specific message element MUST be included 909 in the CAPWAP Join Response Message. 911 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 912 802.11 WTP Radio Information message element MUST be present for 913 every radio in the WTP. 915 5.7. Configuration Status Message 917 The following IEEE 802.11 specific message elements MAY be included 918 in the CAPWAP Configuration Status Message. More than one of each 919 message element listed MAY be included. 921 o IEEE 802.11 Antenna, see Section 6.2 923 o IEEE 802.11 Direct Sequence Control, see Section 6.5 925 o IEEE 802.11 MAC Operation, see Section 6.7 927 o IEEE 802.11 Multi Domain Capability, see Section 6.9 929 o IEEE 802.11 OFDM Control, see Section 6.10 931 o IEEE 802.11 Supported Rates, see Section 6.17 933 o IEEE 802.11 Tx Power, see Section 6.18 935 o IEEE 802.11 TX Power Level, see Section 6.19 937 o IEEE 802.11 WTP Radio Configuration, see Section 6.23 939 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 940 802.11 WTP Radio Information message element MUST be present for 941 every radio in the WTP. 943 5.8. Configuration Status Response Message 945 The following IEEE 802.11 specific message elements MAY be included 946 in the CAPWAP Configuration Status Response Message. More than one 947 of each message element listed MAY be included. 949 o IEEE 802.11 Antenna, see Section 6.2 950 o IEEE 802.11 Direct Sequence Control, see Section 6.5 952 o IEEE 802.11 MAC Operation, see Section 6.7 954 o IEEE 802.11 Multi Domain Capability, see Section 6.9 956 o IEEE 802.11 OFDM Control, see Section 6.10 958 o IEEE 802.11 Rate Set, see Section 6.11 960 o IEEE 802.11 Supported Rates, see Section 6.17 962 o IEEE 802.11 Tx Power, see Section 6.18 964 o IEEE 802.11 WTP Quality of Service, see Section 6.22 966 o IEEE 802.11 WTP Radio Configuration, see Section 6.23 968 5.9. Configuration Update Request Message 970 The following IEEE 802.11 specific message elements MAY be included 971 in the CAPWAP Configuration Update Request Message. More than one of 972 each message element listed MAY be included. 974 o IEEE 802.11 Antenna, see Section 6.2 976 o IEEE 802.11 Direct Sequence Control, see Section 6.5 978 o IEEE 802.11 MAC Operation, see Section 6.7 980 o IEEE 802.11 Multi Domain Capability, see Section 6.9 982 o IEEE 802.11 OFDM Control, see Section 6.10 984 o IEEE 802.11 Rate Set, see Section 6.11 986 o IEEE 802.11 RSNA Error Report From Station, see Section 6.12 988 o IEEE 802.11 Tx Power, see Section 6.18 990 o IEEE 802.11 WTP Quality of Service, see Section 6.22 992 o IEEE 802.11 WTP Radio Configuration, see Section 6.23 994 5.10. Station Configuration Request 996 The following IEEE 802.11 specific message elements MAY included in 997 the CAPWAP Station Configuration Request message. More than one of 998 each message element listed MAY be included. 1000 o IEEE 802.11 Station, see Section 6.13 1002 o IEEE 802.11 Station Session Key, see Section 6.15 1004 o Station QoS Profile, see Section 6.14 1006 5.11. Change State Event Request 1008 The following IEEE 802.11 specific message elements MAY included in 1009 the CAPWAP Station Configuration Request message. 1011 o IEEE 802.11 WTP Radio Fail Alarm Indication, see Section 6.24 1013 5.12. WTP Event Request 1015 The following IEEE 802.11 specific message elements MAY be included 1016 in the CAPWAP WTP Event Request message. More than one of each 1017 message element listed MAY be included. 1019 o IEEE 802.11 MIC Countermeasures, see Section 6.8 1021 o IEEE 802.11 RSNA Error Report From Station, see Section 6.12 1023 o IEEE 802.11 Statistics, see Section 6.16 1025 6. IEEE 802.11 Message Element Definitions 1027 The following IEEE 802.11 specific message elements are defined in 1028 this section. 1030 IEEE 802.11 Message Element Type Value 1032 IEEE 802.11 Add WLAN 1024 1033 IEEE 802.11 Antenna 1025 1034 IEEE 802.11 Assigned WTP BSSID 1026 1035 IEEE 802.11 Delete WLAN 1027 1036 IEEE 802.11 Direct Sequence Control 1028 1037 IEEE 802.11 Information Element 1029 1038 IEEE 802.11 MAC Operation 1030 1039 IEEE 802.11 MIC Countermeasures 1031 1040 IEEE 802.11 Multi-Domain Capability 1032 1041 IEEE 802.11 OFDM Control 1033 1042 IEEE 802.11 Rate Set 1034 1043 IEEE 802.11 RSNA Error Report From Station 1035 1044 IEEE 802.11 Station 1036 1045 IEEE 802.11 Station QoS Profile 1037 1046 IEEE 802.11 Station Session Key 1038 1047 IEEE 802.11 Statistics 1039 1048 IEEE 802.11 Supported Rates 1040 1049 IEEE 802.11 Tx Power 1041 1050 IEEE 802.11 Tx Power Level 1042 1051 IEEE 802.11 Update Station QoS 1043 1052 IEEE 802.11 Update WLAN 1044 1053 IEEE 802.11 WTP Quality of Service 1045 1054 IEEE 802.11 WTP Radio Configuration 1046 1055 IEEE 802.11 WTP Radio Fail Alarm Indication 1047 1056 IEEE 802.11 WTP Radio Information 1048 1058 Figure 8: IEEE 802.11 Binding Message Elements 1060 6.1. IEEE 802.11 Add WLAN 1062 The IEEE 802.11 Add WLAN message element is used by the AC to define 1063 a WLAN on the WTP. The inclusion of this message element MUST also 1064 include IEEE 802.11 Information Element message elements, containing 1065 the following IEEE 802.11 IEs: 1067 Power Capability information element 1068 WPA information element 1070 RSN information element 1072 EDCA Parameter Set information element 1074 QoS Capability information element 1076 WMM information element 1078 If present, the RSN information element is sent with the IEEE 802.11 1079 Add WLAN message element to instruct the WTP on the usage of the Key 1080 field. 1082 An AC MAY include additional information elements as desired. The 1083 message element uses the following format: 1085 0 1 2 3 1086 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 1087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1088 | Radio ID | WLAN ID | Capability | 1089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1090 | Key Index | Key Status | Key Length | 1091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1092 | Key... | 1093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1094 | Group TSC | 1095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1096 | Group TSC | QoS | Auth Type | 1097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1098 | MAC Mode | Tunnel Mode | Suppress SSID | SSID ... 1099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 Type: 1024 for IEEE 802.11 Add WLAN 1103 Length: >= 52 1105 Radio ID: An 8-bit value representing the radio. 1107 WLAN ID: An 8-bit value specifying the WLAN Identifier. 1109 Capability: A 16-bit value containing the capability information 1110 field to be advertised by the WTP in the Probe Request and Beacon 1111 frames. Each bit of the Capability field represents a different 1112 WTP capability, which are described in detail in 1113 [IEEE.802-11.2007]. The format of the field is: 1115 0 1 1116 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1118 |E|I|C|F|P|S|B|A|M|Q|T|D|V|O|K|L| 1119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1121 E (ESS): The AC MUST set the Extended Service Set (ESS) subfield 1122 to 1. 1124 I (IBSS): The AC MUST set the Independent Basic Service Set 1125 (IBSS) subfield to 0. 1127 C (CF-Pollable): The AC sets the Contention Free Pollable (CF- 1128 Pollable) subfield based on the table found in 1129 [IEEE.802-11.2007]. 1131 F (CF-Poll Request): The AC sets the CF-Poll Request subfield 1132 based on the table found in [IEEE.802-11.2007]. 1134 P (Privacy): The AC sets the Privacy subfield based on the 1135 confidentiality requirements of the WLAN, as defined in 1136 [IEEE.802-11.2007]. 1138 S (Short Preamble): The AC sets the Short Preamble subfield 1139 based on whether the use of short preambles are permitted on 1140 the WLAN, as defined in [IEEE.802-11.2007]. 1142 B (PBCC): The AC sets the Packet Binary Convolutional Code 1143 (PBCC) modulation option subfield based on whether the use of 1144 PBCC is permitted on the WLAN, as defined in 1145 [IEEE.802-11.2007]. 1147 A (Channel Agility): The AC sets the Channel Agility subfield 1148 based on whether the WTP is capable of supporting the High Rate 1149 Direct Sequence Spread Spectrum (HR/DSSS), as defined in 1150 [IEEE.802-11.2007]. 1152 M (Spectrum Management): The AC sets the Spectrum Management 1153 subfield according to the value of the 1154 dot11SpectrumManagementRequired MIB variable, as defined in 1155 [IEEE.802-11.2007]. 1157 Q (QOS): The AC sets the Quality of Service (QOS) subfield based 1158 on the table found in [IEEE.802-11.2007]. 1160 T (Short Slot Time): The AC sets the Short Slot Timesubfield 1161 according to the value of the WTP's currently used slot time 1162 value, as defined in [IEEE.802-11.2007]. 1164 D (APSD): The AC sets the APSD subfield according to the value 1165 of the dot11APSDOptionImplemented Management Information Base 1166 (MIB) variable, as defined in [IEEE.802-11.2007]. 1168 V (Reserved): The AC sets the Reserved subfield to zero, as 1169 defined in [IEEE.802-11.2007]. 1171 O (DSSS-OFDM): The AC sets the DSSS-OFDM subfield to indicate 1172 the use of Direct Sequence Spread Spectrum with Orthogonal 1173 Frequency Division Multiplexing (DSSS-OFDM), as defined in 1174 [IEEE.802-11.2007]. 1176 K (Delayed Block ACK): The AC sets the Delayed Block ACK 1177 subfield according to the value of the 1178 dot11DelayedBlockAckOptionImplemented MIB variable, as defined 1179 in [IEEE.802-11.2007]. 1181 L (Immediate Block ACK): The AC sets the Delayed Block ACK 1182 subfield according to the value of the 1183 dot11ImmediateBlockAckOptionImplemented MIB variable, as 1184 defined in [IEEE.802-11.2007]. 1186 Key-Index: The Key Index associated with the key. 1188 Key Status: A 1 byte value that specifies the state and usage of 1189 the key that has been included. The following values describe the 1190 key usage and its status: 1192 0 - A value of zero, with the inclusion of the RSN Information 1193 Element means that the WLAN uses per-station encryption keys, 1194 and therefore the key in the 'Key' field is only used for 1195 multicast traffic. 1197 1 - When set to one, the WLAN employs a shared Wired Equivalent 1198 Privacy (WEP) key, also known as a static WEP key, and uses the 1199 encryption key for both unicast and multicast traffic for all 1200 stations. 1202 2 - The value of 2 indicates that the AC will begin rekeying the 1203 GTK with the STA's in the BSS. It is only valid when IEEE 1204 802.11 is enabled as the security policy for the BSS. 1206 3 - The value of 3 indicates that the AC has completed rekeying 1207 the GTK and broadcast packets no longer need to be duplicated 1208 and transmitted with both GTK's. 1210 Key Length: A 16-bit value representing the length of the Key 1211 field. 1213 Key: A 32 byte Session Key to use to provide data privacy. For 1214 encryption schemes that employ a separate encryption key for 1215 unicast and multicast traffic, the key included here only applies 1216 to multicast frames, and the cipher suite is specified in an 1217 accompanied RSN Information Element. In these scenarios, the key 1218 and cipher information is communicated via the Add Station message 1219 element, see Section 4.6.8 in 1220 [I-D.ietf-capwap-protocol-specification] and the IEEE 802.11 1221 Station Session Key message element, see Section 6.15. 1223 Group TSC A 48-bit value containing the Transmit Sequence Counter 1224 for the updated group key. The WTP will set the TSC for 1225 broadcast/multicast frames to this value for the updated group 1226 key. 1228 QOS: An 8-bit value specifying the default QOS policy for the WTP 1229 to apply to network traffic received for a non-WMM enabled STA. 1231 The following enumerated values are supported: 1233 0 - Best Effort 1235 1 - Video 1237 2 - Voice 1239 3 - Background 1241 Auth Type: An 8-bit value specifying the supported authentication 1242 type. 1244 The following enumerated values are supported: 1246 0 - Open System 1248 1 - WEP Shared Key 1250 MAC Mode: This field specifies whether the WTP should support the 1251 WLAN in Local or Split MAC modes. Note that the AC MUST NOT 1252 request a mode of operation that was not advertised by the WTP 1253 during the discovery process (see Section 4.6.46 in 1254 [I-D.ietf-capwap-protocol-specification]). The following 1255 enumerated values are supported: 1257 0 - Local-MAC: Service for the WLAN is to be provided in Local 1258 MAC mode. 1260 1 - Split-MAC: Service for the WLAN is to be provided in Split 1261 MAC mode. 1263 Tunnel Mode: This field specifies the frame tunneling type to be 1264 used for 802.11 data frames from all stations associated with the 1265 WLAN. The AC MUST NOT request a mode of operation that was not 1266 advertised by the WTP during the discovery process (see Section 1267 4.6.43 in [I-D.ietf-capwap-protocol-specification]). IEEE 802.11 1268 management frames SHALL be tunneled using 802.11 Tunnel mode. The 1269 following enumerated values are supported: 1271 0 - Local Bridging: All user traffic is to be locally bridged. 1273 1 - 802.3 Tunnel: All user traffic is to be tunneled to the AC 1274 in 802.3 format (see Section 4.3 in 1275 [I-D.ietf-capwap-protocol-specification]). 1277 2 - 802.11 Tunnel: All user traffic is to be tunneled to the AC 1278 in 802.11 format. 1280 Supress SSID: A boolean indicating whether the SSID is to be 1281 advertised by the WTP. A value of zero suppresses the SSID in the 1282 802.11 Beacon and Probe Response frames, while a value of one will 1283 cause the WTP to populate the field. 1285 SSID: The SSID attribute is the service set identifier that will be 1286 advertised by the WTP for this WLAN. The SSID field contains any 1287 ASCII character and MUST NOT exceed 32 octets in length, as 1288 defined in [IEEE.802-11.2007]. 1290 6.2. IEEE 802.11 Antenna 1292 The IEEE 802.11 Antenna message element is communicated by the WTP to 1293 the AC to provide information on the antennas available. The AC MAY 1294 use this element to reconfigure the WTP's antennas. The message 1295 element contains the following fields: 1297 0 1 2 3 1298 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 1299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1300 | Radio ID | Diversity | Combiner | Antenna Cnt | 1301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1302 | Antenna Selection... 1303 +-+-+-+-+-+-+-+-+ 1305 Type: 1025 for IEEE 802.11 Antenna 1307 Length: >= 5 1309 Radio ID: An 8-bit value representing the radio to configure. 1311 Diversity: An 8-bit value specifying whether the antenna is to 1312 provide receive diversity. The value of this field is the same as 1313 the IEEE 802.11 dot11DiversitySelectionRx MIB element, see 1314 [IEEE.802-11.2007]. The following enumerated values are 1315 supported: 1317 0 - Disabled 1319 1 - Enabled (may only be true if the antenna can be used as a 1320 receive antenna) 1322 Combiner: An 8-bit value specifying the combiner selection. The 1323 following values are supported: 1325 1 - Sectorized (Left) 1327 2 - Sectorized (Right) 1329 3 - Omni 1331 4 - Multiple Input/Multiple Output (MIMO) 1333 Antenna Count: An 8-bit value specifying the number of Antenna 1334 Selection fields. This value SHOULD be the same as the one found 1335 in the IEEE 802.11 dot11CurrentTxAntenna MIB element (see 1336 [IEEE.802-11.2007]). 1338 Antenna Selection: One 8-bit antenna configuration value per 1339 antenna in the WTP, containing up to 255 antennas. The following 1340 enumerated values are supported: 1342 1 - Internal Antenna 1344 2 - External Antenna 1346 6.3. IEEE 802.11 Assigned WTP BSSID 1348 The IEEE 802.11 Assigned WTP BSSID is only included by the WTP when 1349 the IEEE 802.11 WLAN Configuration Request included the IEEE 802.11 1350 Add WLAN message element. The BSSID value field of this message 1351 element contains the BSSID that has been assigned by the WTP, 1352 enabling the WTP to perform its own BSSID assignment. 1354 The WTP is free to assign the BSSIDs the way it sees fit, but it is 1355 highly recommended that the WTP assign the BSSID using the following 1356 algorithm: BSSID = {base BSSID} + WLAN ID. 1358 0 1 2 3 1359 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 1360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1361 | Radio ID | WLAN ID | BSSID 1362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1363 | BSSID | 1364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1366 Type: 1026 for IEEE 802.11 Assigned WTP BSSID 1368 Length: 8 1370 Radio ID: An 8-bit value representing the radio. 1372 WLAN ID: An 8-bit value specifying the WLAN Identifier. 1374 BSSID: The BSSID assigned by the WTP for the WLAN created as a 1375 result of receiving an IEEE 802.11 Add WLAN. 1377 6.4. IEEE 802.11 Delete WLAN 1379 The IEEE 802.11 Delete WLAN message element is used to inform the WTP 1380 that a previously created WLAN is to be deleted, and contains the 1381 following fields: 1383 0 1 1384 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1386 | Radio ID | WLAN ID | 1387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1389 Type: 1027 for IEEE 802.11 Delete WLAN 1391 Length: 2 1393 Radio ID: An 8-bit value representing the radio 1395 WLAN ID: An 8-bit value specifying the WLAN Identifier 1397 6.5. IEEE 802.11 Direct Sequence Control 1399 The IEEE 802.11 Direct Sequence Control message element is a bi- 1400 directional element. When sent by the WTP, it contains the current 1401 state. When sent by the AC, the WTP MUST adhere to the values 1402 provided. This element is only used for IEEE 802.11b radios. The 1403 message element has the following fields. 1405 0 1 2 3 1406 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 1407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1408 | Radio ID | Reserved | Current Chan | Current CCA | 1409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1410 | Energy Detect Threshold | 1411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1413 Type: 1028 for IEEE 802.11 Direct Sequence Control 1415 Length: 8 1417 Radio ID: An 8-bit value representing the radio to configure. 1419 Reserved: All implementations complying with this protocol MUST set 1420 to zero any bits that are reserved in the version of the protocol 1421 supported by that implementation. Receivers MUST ignore all bits 1422 not defined for the version of the protocol they support. 1424 Current Channel: This attribute contains the current operating 1425 frequency channel of the Direct Sequence Spread Spectrum (DSSS) 1426 PHY. This value comes from the IEEE 802.11 dot11CurrentChannel 1427 MIB element (see [IEEE.802-11.2007]). 1429 Current CCA: The current Clear Channel Assessment (CCA) method in 1430 operation, whose value can be found in the IEEE 802.11 1431 dot11CCAModeSupported MIB element (see [IEEE.802-11.2007]). Valid 1432 values are: 1434 1 - energy detect only (edonly) 1436 2 - carrier sense only (csonly) 1438 4 - carrier sense and energy detect (edandcs) 1440 8 - carrier sense with timer (cswithtimer) 1442 16 - high rate carrier sense and energy detect (hrcsanded) 1444 Energy Detect Threshold: The current Energy Detect Threshold being 1445 used by the DSSS PHY. The value can be found in the IEEE 802.11 1446 dot11EDThreshold MIB element (see [IEEE.802-11.2007]). 1448 6.6. IEEE 802.11 Information Element 1450 The IEEE 802.11 Information Element is used to communicate any IE 1451 defined in the IEEE 802.11 protocol. The data field contains the raw 1452 IE as it would be included within an IEEE 802.11 MAC management 1453 message. 1455 0 1 2 3 1456 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 1457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1458 | Radio ID | WLAN ID |B|P| Reserved |Info Element... 1459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1461 Type: 1029 for IEEE 802.11 Information Element 1463 Length: >= 4 1465 Radio ID: An 8-bit value representing the radio. 1467 WLAN ID: An 8-bit value specifying the WLAN Identifier. 1469 B: When set, the WTP is to include the information element in IEEE 1470 802.11 Beacons associated with the WLAN. 1472 P: When set, the WTP is to include the information element in Probe 1473 Responses associated with the WLAN. 1475 Reserved: All implementations complying with this protocol MUST set 1476 to zero any bits that are reserved in the version of the protocol 1477 supported by that implementation. Receivers MUST ignore all bits 1478 not defined for the version of the protocol they support. 1480 Info Element: The IEEE 802.11 Information Element, which includes 1481 the type, length and value field. 1483 6.7. IEEE 802.11 MAC Operation 1485 The IEEE 802.11 MAC Operation message element is sent by the AC to 1486 set the IEEE 802.11 MAC parameters on the WTP, and contains the 1487 following fields. 1489 0 1 2 3 1490 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 1491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1492 | Radio ID | Reserved | RTS Threshold | 1493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1494 | Short Retry | Long Retry | Fragmentation Threshold | 1495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1496 | Tx MSDU Lifetime | 1497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1498 | Rx MSDU Lifetime | 1499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1501 Type: 1030 for IEEE 802.11 MAC Operation 1503 Length: 16 1505 Radio ID: An 8-bit value representing the radio to configure. 1507 Reserved: All implementations complying with this protocol MUST set 1508 to zero any bits that are reserved in the version of the protocol 1509 supported by that implementation. Receivers MUST ignore all bits 1510 not defined for the version of the protocol they support. 1512 RTS Threshold: This attribute indicates the number of octets in an 1513 MAC Protocol Data Unit (MPDU), below which an Request To Send/ 1514 Clear To Send (RTS/CTS) handshake MUST NOT be performed. An RTS/ 1515 CTS handshake MUST be performed at the beginning of any frame 1516 exchange sequence where the MPDU is of type Data or Management, 1517 the MPDU has an individual address in the Address1 field, and the 1518 length of the MPDU is greater than this threshold. Setting this 1519 attribute to be larger than the maximum MSDU size MUST have the 1520 effect of turning off the RTS/CTS handshake for frames of Data or 1521 Management type transmitted by this STA. Setting this attribute 1522 to zero MUST have the effect of turning on the RTS/CTS handshake 1523 for all frames of Data or Management type transmitted by this STA. 1524 The default value of this attribute MUST be 2347. The value of 1525 this field comes from the IEEE 802.11 dot11RTSThreshold MIB 1526 element, (see [IEEE.802-11.2007]). 1528 Short Retry: This attribute indicates the maximum number of 1529 transmission attempts of a frame, the length of which is less than 1530 or equal to RTSThreshold, that MUST be made before a failure 1531 condition is indicated. The default value of this attribute MUST 1532 be 7. The value of this field comes from the IEEE 802.11 1533 dot11ShortRetryLimit MIB element, (see [IEEE.802-11.2007]). 1535 Long Retry: This attribute indicates the maximum number of 1536 transmission attempts of a frame, the length of which is greater 1537 than dot11RTSThreshold, that MUST be made before a failure 1538 condition is indicated. The default value of this attribute MUST 1539 be 4. The value of this field comes from the IEEE 802.11 1540 dot11LongRetryLimit MIB element, (see [IEEE.802-11.2007]). 1542 Fragmentation Threshold: This attribute specifies the current 1543 maximum size, in octets, of the MPDU that MAY be delivered to the 1544 PHY. A MAC Service Data Unit (MSDU) MUST be broken into fragments 1545 if its size exceeds the value of this attribute after adding MAC 1546 headers and trailers. An MSDU or MAC Management Protocol Data 1547 Unit (MMPDU) MUST be fragmented when the resulting frame has an 1548 individual address in the Address1 field, and the length of the 1549 frame is larger than this threshold. The default value for this 1550 attribute MUST be the lesser of 2346 or the aMPDUMaxLength of the 1551 attached PHY and MUST never exceed the lesser of 2346 or the 1552 aMPDUMaxLength of the attached PHY. The value of this attribute 1553 MUST never be less than 256. The value of this field comes from 1554 the IEEE 802.11 dot11FragmentationThreshold MIB element, (see 1555 [IEEE.802-11.2007]). 1557 Tx MSDU Lifetime: This attribute specifies the elapsed time in TU, 1558 after the initial transmission of an MSDU, after which further 1559 attempts to transmit the MSDU MUST be terminated. The default 1560 value of this attribute MUST be 512. The value of this field 1561 comes from the IEEE 802.11 dot11MaxTransmitMSDULifetime MIB 1562 element, (see [IEEE.802-11.2007]). 1564 Rx MSDU Lifetime: This attribute specifies the elapsed time in TU, 1565 after the initial reception of a fragmented MMPDU or MSDU, after 1566 which further attempts to reassemble the MMPDU or MSDU MUST be 1567 terminated. The default value MUST be 512. The value of this 1568 field comes from the IEEE 802.11 dot11MaxReceiveLifetime MIB 1569 element, (see [IEEE.802-11.2007]). 1571 6.8. IEEE 802.11 MIC Countermeasures 1573 The IEEE 802.11 MIC Countermeasures message element is sent by the 1574 WTP to the AC to indicate the occurrence of a MIC failure. For more 1575 information on MIC failure events, see the 1576 dot11RSNATKIPCounterMeasuresInvoked MIB element definition in 1577 [IEEE.802-11.2007]. 1579 0 1 2 3 1580 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 1581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1582 | Radio ID | WLAN ID | MAC Address | 1583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1584 | MAC Address | 1585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1587 Type: 1031 for IEEE 802.11 MIC Countermeasures 1589 Length: 8 1591 Radio ID: The Radio Identifier, typically refers to some interface 1592 index on the WTP. 1594 WLAN ID: This 8-bit unsigned integer includes the WLAN Identifier, 1595 on which the MIC failure occurred. 1597 MAC Address: The MAC Address of the station that caused the MIC 1598 failure. 1600 6.9. IEEE 802.11 Multi-Domain Capability 1602 The IEEE 802.11 Multi-Domain Capability message element is used by 1603 the AC to inform the WTP of regulatory limits. The AC will transmit 1604 one message element per frequency band to indicate the regulatory 1605 constraints in that domain. The message element contains the 1606 following fields. 1608 0 1 2 3 1609 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 1610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1611 | Radio ID | Reserved | First Channel # | 1612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1613 | Number of Channels | Max Tx Power Level | 1614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1616 Type: 1032 for IEEE 802.11 Multi-Domain Capability 1618 Length: 8 1620 Radio ID: An 8-bit value representing the radio to configure. 1622 Reserved: All implementations complying with this protocol MUST set 1623 to zero any bits that are reserved in the version of the protocol 1624 supported by that implementation. Receivers MUST ignore all bits 1625 not defined for the version of the protocol they support. 1627 First Channnel #: This attribute indicates the value of the lowest 1628 channel number in the sub-band for the associated domain country 1629 string. The value of this field comes from the IEEE 802.11 1630 dot11FirstChannelNumber MIB element (see [IEEE.802-11.2007]). 1632 Number of Channels: This attribute indicates the value of the total 1633 number of channels allowed in the sub-band for the associated 1634 domain country string. The value of this field comes from the 1635 IEEE 802.11 dot11NumberofChannels MIB element (see 1636 [IEEE.802-11.2007]). 1638 Max Tx Power Level: This attribute indicates the maximum transmit 1639 power, in dBm, allowed in the sub-band for the associated domain 1640 country string. The value of this field comes from the IEEE 1641 802.11 dot11MaximumTransmitPowerLevel MIB element (see 1642 [IEEE.802-11.2007]). 1644 6.10. IEEE 802.11 OFDM Control 1646 The IEEE 802.11 Orthogonal Frequency Division Multiplexing (OFDM) 1647 Control message element is a bi-directional element. When sent by 1648 the WTP, it contains the current state. When sent by the AC, the WTP 1649 MUST adhere to the received values. This message element is only 1650 used for 802.11a radios and contains the following fields: 1652 0 1 2 3 1653 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 1654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1655 | Radio ID | Reserved | Current Chan | Band Support | 1656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1657 | TI Threshold | 1658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1660 Type: 1033 for IEEE 802.11 OFDM Control 1662 Length: 8 1664 Radio ID: An 8-bit value representing the radio to configure. 1666 Reserved: All implementations complying with this protocol MUST set 1667 to zero any bits that are reserved in the version of the protocol 1668 supported by that implementation. Receivers MUST ignore all bits 1669 not defined for the version of the protocol they support. 1671 Current Channel: This attribute contains the current operating 1672 frequency channel of the OFDM PHY. The value of this field comes 1673 from the IEEE 802.11 dot11CurrentFrequency MIB element (see 1674 [IEEE.802-11.2007]). 1676 Band Supported: The capability of the OFDM PHY implementation to 1677 operate in the three U-NII bands. The value of this field comes 1678 from the IEEE 802.11 dot11FrequencyBandsSupported MIB element (see 1679 [IEEE.802-11.2007]), coded as a bit field, whose values are: 1681 Bit 0 - capable of operating in the 5.15-5.25 GHz band 1683 Bit 1 - capable of operating in the 5.25-5.35 GHz band 1685 Bit 2 - capable of operating in the 5.725-5.825 GHz band 1687 Bit 3 - capable of operating in the 5.47-5.725 GHz band 1689 Bit 4 - capable of operating in the lower Japanese 5.25 GHz band 1691 Bit 5 - capable of operating in the 5.03-5.091 GHz band 1693 Bit 6 - capable of operating in the 4.94-4.99 GHz band 1695 For example, for an implementation capable of operating in the 1696 5.15-5.35 GHz bands this attribute would take the value 3. 1698 TI Threshold: The Threshold being used to detect a busy medium 1699 (frequency). CCA MUST report a busy medium upon detecting the 1700 RSSI above this threshold. The value of this field comes from the 1701 IEEE 802.11 dot11TIThreshold MIB element (see [IEEE.802-11.2007]). 1703 6.11. IEEE 802.11 Rate Set 1705 The rate set message element value is sent by the AC and contains the 1706 supported operational rates. It contains the following fields. 1708 0 1 2 3 1709 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 1710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1711 | Radio ID | Rate Set... 1712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1714 Type: 1034 for IEEE 802.11 Rate Set 1715 Length: >= 3 1717 Radio ID: An 8-bit value representing the radio to configure. 1719 Rate Set: The AC generates the Rate Set that the WTP is to include 1720 in its Beacon and Probe messages. The length of this field is 1721 between 2 and 8 bytes. The value of this field comes from the 1722 IEEE 802.11 dot11OperationalRateSet MIB element (see 1723 [IEEE.802-11.2007]). 1725 6.12. IEEE 802.11 RSNA Error Report From Station 1727 The IEEE 802.11 RSN Error Report From Station message element is used 1728 by a WTP to send RSN error reports to the AC. The WTP does not need 1729 to transmit any reports that do not include any failures. The fields 1730 from this message element come from the IEEE 802.11 1731 Dot11RSNAStatsEntry table, see [IEEE.802-11.2007]. 1733 0 1 2 3 1734 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 1735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1736 | Client MAC Address | 1737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1738 | Client MAC Address | BSSID | 1739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1740 | BSSID | 1741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1742 | Radio ID | WLAN ID | Reserved | 1743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1744 | TKIP ICV Errors | 1745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1746 | TKIP Local MIC Failures | 1747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1748 | TKIP Remote MIC Failures | 1749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1750 | CCMP Replays | 1751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1752 | CCMP Decrypt Errors | 1753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1754 | TKIP Replays | 1755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1757 Type: 1035 for IEEE 802.11 RSNA Error Report From Station 1758 Length: 40 1760 Client MAC Address: The Client MAC Address of the station. 1762 BSSID: The BSSID on which the failures are being reported on. 1764 Radio ID: The Radio Identifier, typically refers to some interface 1765 index on the WTP 1767 WLAN ID: The WLAN ID on which the RSNA failures are being reported. 1769 Reserved: All implementations complying with this protocol MUST set 1770 to zero any bits that are reserved in the version of the protocol 1771 supported by that implementation. Receivers MUST ignore all bits 1772 not defined for the version of the protocol they support. 1774 TKIP ICV Errors: A 32-bit value representing the number of Temporal 1775 Key Integrity Protocol (TKIP) (as defined in [IEEE.802-11.2007]) 1776 ICV errors encountered when decrypting packets from the station. 1777 The value of this field comes from the IEEE 802.11 1778 dot11RSNAStatsTKIPICVErrors MIB element (see [IEEE.802-11.2007]). 1780 TKIP Local MIC Failures: A 32-bit value representing the number of 1781 MIC failures encountered when checking the integrity of packets 1782 received from the station. The value of this field comes from the 1783 IEEE 802.11 dot11RSNAStatsTKIPLocalMICFailures MIB element (see 1784 [IEEE.802-11.2007]). 1786 TKIP Remote MIC Failures: A 32-bit value representing the number of 1787 MIC failures reported by the station encountered (possibly via the 1788 EAPOL-Key frame). The value of this field comes from the IEEE 1789 802.11 dot11RSNAStatsTKIPRemoteMICFailures MIB element (see 1790 [IEEE.802-11.2007]). 1792 CCMP Replays: A 32-bit value representing the number of CCMP MPDUs 1793 discarded by the replay detection mechanism. The value of this 1794 field comes from the IEEE 802.11 dot11RSNACCMPReplays MIB element 1795 (see [IEEE.802-11.2007]). 1797 CCMP Decrypt Errors: A 32-bit value representing the number of CCMP 1798 MDPUs discarded by the decryption algorithm. The value of this 1799 field comes from the IEEE 802.11 dot11RSNACCMPDecryptErrors MIB 1800 element (see [IEEE.802-11.2007]). 1802 TKIP Replays: A 32-bit value representing the number of TKIP 1803 Replays detected in frames received from the station. The value 1804 of this field comes from the IEEE 802.11 dot11RSNAStatsTKIPReplays 1805 MIB element (see [IEEE.802-11.2007]). 1807 6.13. IEEE 802.11 Station 1809 The IEEE 802.11 Station message element accompanies the Add Station 1810 message element, and is used to deliver IEEE 802.11 station policy 1811 from the AC to the WTP. 1813 The latest IEEE 802.11 Station message element overrides any 1814 previously received message elements. 1816 If the QoS field is set, the WTP MUST observe and provide policing of 1817 the 802.11e priority tag to ensure that it does not exceed the value 1818 provided by the AC. 1820 0 1 2 3 1821 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 1822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1823 | Radio ID | Association ID | Flags | 1824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1825 | MAC Address | 1826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1827 | MAC Address | Capabilities | 1828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1829 | WLAN ID |Supported Rates| 1830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1832 Type: 1036 for IEEE 802.11 Station 1834 Length: >= 14 1836 Radio ID: An 8-bit value representing the radio 1838 Association ID: A 16-bit value specifying the IEEE 802.11 1839 Association Identifier 1841 Flags: All implementations complying with this protocol MUST set to 1842 zero any bits that are reserved in the version of the protocol 1843 supported by that implementation. Receivers MUST ignore all bits 1844 not defined for the version of the protocol they support. 1846 MAC Address: The station's MAC Address 1848 Capabilities: A 16-bit field containing the IEEE 802.11 1849 Capabilities Information Field to use with the station. 1851 WLAN ID: An 8-bit value specifying the WLAN Identifier 1852 Supported Rates: The variable length field containing the supported 1853 rates to be used with the station, as found in the IEEE 802.11 1854 dot11OperationalRateSet MIB element (see [IEEE.802-11.2007]). 1855 This field MUST NOT exceed 126 octets and specifies the set of 1856 data rates at which the station may transmit data, where each 1857 octet represents a data rate. 1859 6.14. IEEE 802.11 Station QoS Profile 1861 The IEEE 802.11 Station QoS Profile message element contains the 1862 maximum IEEE 802.11e priority tag that may be used by the station. 1863 Any packet received that exceeds the value encoded in this message 1864 element MUST either be dropped or tagged using the maximum value 1865 permitted by to the user. The priority tag MUST be between zero (0) 1866 and seven (7). This message element MUST NOT be present without the 1867 IEEE 802.11 Station (see Section 6.13) message element 1869 0 1 2 3 1870 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1872 | MAC Address | 1873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1874 | MAC Address | 802.1p Priority Tag | 1875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1877 Type: 1037 for IEEE 802.11 Station QOS Profile 1879 Length: 8 1881 MAC Address: The station's MAC Address 1883 802.1p Priority Tag: The maximum 802.1p priority value that the WTP 1884 will allow in the Traffic Identifier (TID) field in the extended 1885 802.11e QOS Data header. Only the three least significant bits of 1886 this field are valid, while the remaining bits MUST be set to zero 1887 (0). 1889 6.15. IEEE 802.11 Station Session Key 1891 The IEEE 802.11 Station Session Key message element is sent when the 1892 AC determines that encryption of a station must be performed in the 1893 WTP. This message element MUST NOT be present without the IEEE 1894 802.11 Station (see Section 6.13) message element, and MUST NOT be 1895 sent if the WTP had not specifically advertised support for the 1896 requested encryption scheme. 1898 The RSN information element MUST sent along with the IEEE 802.11 1899 Station Session Key in order to instruct the WTP on the usage of the 1900 Key field. The AKM field of the RSM information element is used by 1901 the WTP to identify the authentication protocol. 1903 If the IEEE 802.11 Station Session Key message element's AKM-Only bit 1904 is set, the WTP MUST drop all IEEE 802.11 packets that are not part 1905 of the Authentication and Key Management (AKM), such as EAP. Note 1906 that AKM-Only is MAY be set while an encryption key is in force, 1907 requiring that the AKM packets be encrypted. Once the station has 1908 successfully completed authentication via the AKM, the AC MUST send a 1909 new Add Station message element to remove the AKM-Only restriction, 1910 and optionally push the session key down to the WTP. 1912 0 1 2 3 1913 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 1914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1915 | MAC Address | 1916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1917 | MAC Address |A|C| Flags | 1918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1919 | Pairwise TSC | 1920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1921 | Pairwise TSC | Pairwise RSC | 1922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1923 | Pairwise RSC | 1924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1925 | Key... 1926 +-+-+-+-+-+-+-+- 1928 Type: 1038 for IEEE 802.11 Station Session Key 1930 Length: >= 25 1932 MAC Address: The station's MAC Address 1934 Flags: All implementations complying with this protocol MUST set to 1935 zero any bits that are reserved in the version of the protocol 1936 supported by that implementation. Receivers MUST ignore all bits 1937 not defined for the version of the protocol they support. The 1938 following bits are defined: 1940 A: The one bit AKM-Only field is set by the AC to inform the WTP 1941 that is MUST NOT accept any 802.11 data frames, other than AKM 1942 frames. This is the equivalent of the WTP's IEEE 802.1X port 1943 for the station to be in the closed state. When set, the WTP 1944 MUST drop any non-IEEE 802.1X packets it receives from the 1945 station. 1947 C: The one bit field is set by the AC to inform the WTP that 1948 encryption services will be provided by the AC. When set, the 1949 WTP SHOULD police frames received from stations to ensure that 1950 are properly encrypted as specified in the RSN Information 1951 Element, but does not need to take specific cryptographic 1952 action on the frame. Similarly, for transmitted frames, the 1953 WTP only needs to forward already encrypted frames. 1955 Pairwise TSC: The 6 byte Transmit Sequence Counter (TSC) field to 1956 use for unicast packets transmitted to the station. 1958 Pairwise RSC: The 6 byte Receive Sequence Counter (RSC) to use for 1959 unicast packets received from the station. 1961 Key: The key the WTP is to use when encrypting traffic to/from the 1962 station. For dynamically created keys, this is commonly known as 1963 a Pairwise Transient Key (PTK). 1965 6.16. IEEE 802.11 Statistics 1967 The IEEE 802.11 Statistics message element is sent by the WTP to 1968 transmit its current statistics, and contains the following fields. 1969 All of the fields in this message element are set to zero upon WTP 1970 initialization. The fields will roll over when they reach their 1971 maximum value of 65535. Due to the nature of each counter 1972 representing different data points, the roll over event will vary 1973 greatly across each field. Applications or human operators using 1974 these counters need to be aware about the minimal possible times 1975 between rollover events in order to make sure that no consecutive 1976 rollover events are missed. 1978 0 1 2 3 1979 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 1980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1981 | Radio ID | Reserved | 1982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1983 | Tx Fragment Count | 1984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1985 | Multicast Tx Count | 1986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1987 | Failed Count | 1988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1989 | Retry Count | 1990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1991 | Multiple Retry Count | 1992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1993 | Frame Duplicate Count | 1994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1995 | RTS Success Count | 1996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1997 | RTS Failure Count | 1998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1999 | ACK Failure Count | 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2001 | Rx Fragment Count | 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2003 | Multicast RX Count | 2004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2005 | FCS Error Count | 2006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2007 | Tx Frame Count | 2008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2009 | Decryption Errors | 2010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2011 | Discarded QoS Fragment Count | 2012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2013 | Associated Station Count | 2014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2015 | QoS CF Polls Received Count | 2016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2017 | QoS CF Polls Unused Count | 2018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2019 | QoS CF Polls Unusable Count | 2020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2022 Type: 1039 for IEEE 802.11 Statistics 2024 Length: 80 2026 Radio ID: An 8-bit value representing the radio. 2028 Reserved: All implementations complying with this protocol MUST set 2029 to zero any bits that are reserved in the version of the protocol 2030 supported by that implementation. Receivers MUST ignore all bits 2031 not defined for the version of the protocol they support. 2033 Tx Fragment Count: A 32-bit value representing the number of 2034 fragmented frames transmitted. The value of this field comes from 2035 the IEEE 802.11 dot11TransmittedFragmentCount MIB element (see 2036 [IEEE.802-11.2007]). 2038 Multicast Tx Count: A 32-bit value representing the number of 2039 multicast frames transmitted. The value of this field comes from 2040 the IEEE 802.11 dot11MulticastTransmittedFrameCount MIB element 2041 (see [IEEE.802-11.2007]). 2043 Failed Count: A 32-bit value representing the transmit excessive 2044 retries. The value of this field comes from the IEEE 802.11 2045 dot11FailedCount MIB element (see [IEEE.802-11.2007]). 2047 Retry Count: A 32-bit value representing the number of transmit 2048 retries. The value of this field comes from the IEEE 802.11 2049 dot11RetryCount MIB element (see [IEEE.802-11.2007]). 2051 Multiple Retry Count: A 32-bit value representing the number of 2052 transmits that required more than one retry. The value of this 2053 field comes from the IEEE 802.11 dot11MultipleRetryCount MIB 2054 element (see [IEEE.802-11.2007]). 2056 Frame Duplicate Count: A 32-bit value representing the duplicate 2057 frames received. The value of this field comes from the IEEE 2058 802.11 dot11FrameDuplicateCount MIB element (see 2059 [IEEE.802-11.2007]). 2061 RTS Success Count: A 32-bit value representing the number of 2062 successfully transmitted Ready To Send (RTS). The value of this 2063 field comes from the IEEE 802.11 dot11RTSSuccessCount MIB element 2064 (see [IEEE.802-11.2007]). 2066 RTS Failure Count: A 32-bit value representing the failed 2067 transmitted RTS. The value of this field comes from the IEEE 2068 802.11 dot11RTSFailureCount MIB element (see [IEEE.802-11.2007]). 2070 ACK Failure Count: A 32-bit value representing the number of failed 2071 acknowledgements. The value of this field comes from the IEEE 2072 802.11 dot11ACKFailureCount MIB element (see [IEEE.802-11.2007]). 2074 Rx Fragment Count: A 32-bit value representing the number of 2075 fragmented frames received. The value of this field comes from 2076 the IEEE 802.11 dot11ReceivedFragmentCount MIB element (see 2077 [IEEE.802-11.2007]). 2079 Multicast RX Count: A 32-bit value representing the number of 2080 multicast frames received. The value of this field comes from the 2081 IEEE 802.11 dot11MulticastReceivedFrameCount MIB element (see 2082 [IEEE.802-11.2007]). 2084 FCS Error Count: A 32-bit value representing the number of FCS 2085 failures. The value of this field comes from the IEEE 802.11 2086 dot11FCSErrorCount MIB element (see [IEEE.802-11.2007]). 2088 Decryption Errors: A 32-bit value representing the number of 2089 Decryption errors that occurred on the WTP. Note that this field 2090 is only valid in cases where the WTP provides encryption/ 2091 decryption services. The value of this field comes from the IEEE 2092 802.11 dot11WEPUndecryptableCount MIB element (see 2093 [IEEE.802-11.2007]). 2095 Discarded QoS Fragment Count: A 32-bit value representing the 2096 number of discarded QoS fragments received. The value of this 2097 field comes from the IEEE 802.11 dot11QoSDiscardedFragmentCount 2098 MIB element (see [IEEE.802-11.2007]). 2100 Associated Station Count: A 32-bit value representing the number of 2101 number of associated stations. The value of this field comes from 2102 the IEEE 802.11 dot11AssociatedStationCount MIB element (see 2103 [IEEE.802-11.2007]). 2105 QoS CF Polls Received Count: A 32-bit value representing the number 2106 of (+)CF-Polls received. The value of this field comes from the 2107 IEEE 802.11 dot11QosCFPollsReceivedCount MIB element (see 2108 [IEEE.802-11.2007]). 2110 QoS CF Polls Unused Count: A 32-bit value representing the number 2111 of (+)CF-Polls that have been received, but not used. The value 2112 of this field comes from the IEEE 802.11 2113 dot11QosCFPollsUnusedCount MIB element (see [IEEE.802-11.2007]). 2115 QoS CF Polls Unusable Count: A 32-bit value representing the number 2116 of (+)CF-Polls that have been received, but could not be used due 2117 to the Transmission Opportunity (TXOP) size being smaller than the 2118 time that is required for one frame exchange sequence. The value 2119 of this field comes from the IEEE 802.11 2120 dot11QosCFPollsUnusableCount MIB element (see [IEEE.802-11.2007]). 2122 6.17. IEEE 802.11 Supported Rates 2124 The IEEE 802.11 Supported Rates message element is sent by the WTP to 2125 indicate the rates that it supports, and contains the following 2126 fields. 2128 0 1 2 3 2129 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 2130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2131 | Radio ID | Supported Rates... 2132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2134 Type: 1040 for IEEE 802.11 Supported Rates 2136 Length: >= 3 2138 Radio ID: An 8-bit value representing the radio. 2140 Supported Rates: The WTP includes the Supported Rates that its 2141 hardware supports. The format is identical to the Rate Set 2142 message element and is between 2 and 8 bytes in length. 2144 6.18. IEEE 802.11 Tx Power 2146 The IEEE 802.11 Tx Power message element value is bi-directional. 2147 When sent by the WTP, it contains the current power level of the 2148 radio in question. When sent by the AC, it contains the power level 2149 the WTP MUST adhere to. 2151 0 1 2 3 2152 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 2153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2154 | Radio ID | Reserved | Current Tx Power | 2155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2157 Type: 1041 for IEEE 802.11 Tx Power 2159 Length: 4 2160 Radio ID: An 8-bit value representing the radio to configure. 2162 Reserved: All implementations complying with this protocol MUST set 2163 to zero any bits that are reserved in the version of the protocol 2164 supported by that implementation. Receivers MUST ignore all bits 2165 not defined for the version of the protocol they support. 2167 Current Tx Power: This attribute contains the current transmit 2168 output power in mW, as described in the dot11CurrentTxPowerLevel 2169 MIB variable, see [IEEE.802-11.2007]. 2171 6.19. IEEE 802.11 Tx Power Level 2173 The IEEE 802.11 Tx Power Level message element is sent by the WTP and 2174 contains the different power levels supported. The values found in 2175 this message element are found in the IEEE 802.11 2176 Dot11PhyTxPowerEntry MIB table, see [IEEE.802-11.2007]. 2178 The value field contains the following: 2180 0 1 2 3 2181 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 2182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2183 | Radio ID | Num Levels | Power Level [n] | 2184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2186 Type: 1042 for IEEE 802.11 Tx Power Level 2188 Length: >= 4 2190 Radio ID: An 8-bit value representing the radio to configure. 2192 Num Levels: The number of power level attributes. The value of 2193 this field comes from the IEEE 802.11 2194 dot11NumberSupportedPowerLevels MIB element (see 2195 [IEEE.802-11.2007]). 2197 Power Level: Each power level fields contains a supported power 2198 level, in mW. The value of this field comes from the 2199 corresponding IEEE 802.11 dot11TxPowerLevel[n] MIB element, see 2200 [IEEE.802-11.2007]. 2202 6.20. IEEE 802.11 Update Station QoS 2204 The IEEE 802.11 Update Station QoS message element is used to change 2205 the Quality of Service policy on the WTP for a given station. 2207 0 1 2 3 2208 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 2209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2210 | Radio ID | MAC Address | 2211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2212 | MAC Address | DSCP Tag | 802.1p Tag | 2213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2215 Type: 1043 for IEEE 802.11 Update Station QoS 2217 Length: 8 2219 Radio ID: The Radio Identifier, typically refers to some interface 2220 index on the WTP 2222 MAC Address: The station's MAC Address. 2224 DSCP Tag: The DSCP label to use if packets are to be DSCP tagged. 2226 802.1p Tag: The 802.1p priority value to use if packets are to be 2227 IEEE 802.1p tagged. Only the three least significant bits of this 2228 field are valid, while the remaining bits MUST be set to zero (0). 2230 6.21. IEEE 802.11 Update WLAN 2232 The IEEE 802.11 Update WLAN message element is used by the AC to 2233 define a wireless LAN on the WTP. The inclusion of this message 2234 element MUST also include the IEEE 802.11 Information Element message 2235 element, containing the following 802.11 IEs: 2237 Power Capability information element 2239 WPA information element 2241 RSN information element 2243 EDCA Parameter Set information element 2245 QoS Capability information element 2247 WMM information element 2249 The message element uses the following format: 2251 0 1 2 3 2252 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 2253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2254 | Radio ID | WLAN ID | Capability | 2255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2256 | Key Index | Key Status | Key Length | 2257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2258 | Key... | 2259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2261 Type: 1044 for IEEE 802.11 Update WLAN 2263 Length: 40 2265 Radio ID: An 8-bit value representing the radio. 2267 WLAN ID: An 8-bit value specifying the WLAN Identifier. 2269 Capability: A 16-bit value containing the capabilities information 2270 field to be advertised by the WTP within the Probe and Beacon 2271 messages. 2273 Key-Index: The Key Index associated with the key. 2275 Key Status: A 1 byte value that specifies the state and usage of 2276 the key that has been included. The following values describe the 2277 key usage and its status: 2279 0 - A value of zero, with the inclusion of the RSN Information 2280 Element means that the WLAN uses per-station encryption keys, 2281 and therefore the key in the 'Key' field is only used for 2282 multicast traffic. 2284 1 - When set to one, the WLAN employs a shared WEP key, also 2285 known as a static WEP key, and uses the encryption key for both 2286 unicast and multicast traffic for all stations. 2288 2 - The value of 2 indicates that the AC will begin rekeying the 2289 GTK with the STA's in the BSS. It is only valid when IEEE 2290 802.11 is enabled as the security policy for the BSS. 2292 3 - The value of 3 indicates that the AC has completed rekeying 2293 the GTK and broadcast packets no longer need to be duplicated 2294 and transmitted with both GTK's. 2296 Key Length: A 16-bit value representing the length of the Key 2297 field. 2299 Key: A 32 byte Session Key to use to provide data privacy. For 2300 static WEP keys, which is true when the 'Key Status' bit is set to 2301 one, this key is used for both unicast and multicast traffic. For 2302 encryption schemes that employ a separate encryption key for 2303 unicast and multicast traffic, the key included here only applies 2304 to multicast data, and the cipher suite is specified in an 2305 accompanied RSN Information Element. In these scenarios, the key, 2306 and cipher information, is communicated via the Add Station 2307 message element, see Section 4.6.8 in 2308 [I-D.ietf-capwap-protocol-specification]. 2310 6.22. IEEE 802.11 WTP Quality of Service 2312 The IEEE 802.11 WTP Quality of Service message element value is sent 2313 by the AC to the WTP to communicate quality of service configuration 2314 information. 2316 0 1 2317 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2319 | Radio ID | Tag Packets | 2320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2322 Type: 1045 for IEEE 802.11 WTP Quality of Service 2324 Length: 34 2326 Radio ID: The Radio Identifier, typically refers to some interface 2327 index on the WTP 2329 Tag Packets: A bit field indicating whether CAPWAP packets should 2330 be tagged for QoS purposes. The following bit values are 2331 currently supported: 2333 0 - Untagged 2335 1 - 802.1p 2337 2 - DSCP 2339 Immediately following the above header is the following data 2340 structure. This data structure will be repeated four times; once 2341 for every QoS profile. The order of the QoS profiles are Voice, 2342 Video, Best Effort and Background. 2344 0 1 2 3 2345 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 2346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2347 | Queue Depth | CWMin | CWMax | 2348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2349 | CWMax | AIFS | 802.1p Tag | DSCP Tag | 2350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2352 Queue Depth: The number of packets that can be on the specific QoS 2353 transmit queue at any given time. 2355 CWMin: The Contention Window minimum (CWmin) value for the QoS 2356 transmit queue. The value of this field comes from the IEEE 2357 802.11 dot11EDCATableCWMin MIB element (see [IEEE.802-11.2007]). 2359 CWMax: The Contention Window maximum (CWmax) value for the QoS 2360 transmit queue. The value of this field comes from the IEEE 2361 802.11 dot11EDCATableCWMax MIB element (see [IEEE.802-11.2007]). 2363 AIFS: The Arbitration Inter Frame Spacing (AIFS) to use for the QoS 2364 transmit queue. The value of this field comes from the IEEE 2365 802.11 dot11EDCATableAIFSN MIB element (see [IEEE.802-11.2007]). 2367 802.1p Tag: The 802.1p priority value to use if packets are to be 2368 802.1p tagged. Only the three least significant bits of this 2369 field are valid, while the remaining bits MUST be set to zero (0). 2371 DSCP Tag: The DSCP label to use if packets are to be DSCP tagged. 2373 6.23. IEEE 802.11 WTP Radio Configuration 2375 The IEEE 802.11 WTP WLAN Radio Configuration message element is used 2376 by the AC to configure a Radio on the WTP, and by the WTP to deliver 2377 its radio configuration to the AC. The message element value 2378 contains the following fields: 2380 0 1 2 3 2381 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 2382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2383 | Radio ID |Short Preamble| Num of BSSIDs | DTIM Period | 2384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2385 | BSSID | 2386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2387 | BSSID | Beacon Period | 2388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2389 | Country Code | 2390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2392 Type: 1046 for IEEE 802.11 WTP WLAN Radio Configuration 2394 Length: 16 2396 Radio ID: An 8-bit value representing the radio to configure. 2398 Short Preamble: An 8-bit value indicating whether short preamble is 2399 supported. The following enumerated values are currently 2400 supported: 2402 0 - Short preamble not supported. 2404 1 - Short preamble is supported. 2406 BSSID: The WLAN Radio's base MAC Address. 2408 Number of BSSIDs: This attribute contains the maximum number of 2409 BSSIDs supported by the WTP. This value restricts the number of 2410 logical networks supported by the WTP, and is between 1 and 16. 2412 DTIM Period: This attribute specifies the number of beacon 2413 intervals that elapse between transmission of Beacons frames 2414 containing a Traffic Indication Map (TIM) element whose Delivery 2415 Traffic Indication Message (DTIM) Count field is 0. This value is 2416 transmitted in the DTIM Period field of Beacon frames. The value 2417 of this field comes from the IEEE 802.11 dot11DTIMPeriod MIB 2418 element (see [IEEE.802-11.2007]). 2420 Beacon Period: This attribute specifies the number of Time Unit 2421 (TU) that a station uses for scheduling Beacon transmissions. 2422 This value is transmitted in Beacon and Probe Response frames. 2423 The value of this field comes from the IEEE 802.11 2424 dot11BeaconPeriod MIB element (see [IEEE.802-11.2007]). 2426 Country Code: This attribute identifies the country in which the 2427 station is operating. The value of this field comes from the IEEE 2428 802.11 dot11CountryString MIB element (see [IEEE.802-11.2007]). 2429 Some regulatory domains do not allow WTPs to have user 2430 configurable country codes, and require that it be a fixed value 2431 during the manufacturing process. Therefore, WTP vendors that 2432 wish to allow for the configuration of this field will need to 2433 validate this behavior during its radio certification process. 2434 Other WTP vendors may simply wish to treat this WTP configuration 2435 parameter as read-only. The country codes can be found in 2436 [ISO.3166.1984]. 2438 The WTP and AC MAY ignore the value of this field, depending upon 2439 regulatory requirements, for example to avoid classification as a 2440 Software Defined Radio. When this field is used, the first two 2441 octets of this string is the two character country code as 2442 described in document ISO/IEC 3166- 1, and the third octet MUST 2443 have the value 1, 2 or 3 as defined below. When the value of the 2444 third octet is 255, the country code field is not used, and MUST 2445 be ignored. 2447 1 an ASCII space character, if the regulations under which the 2448 station is operating encompass all environments in the country, 2450 2 an ASCII 'O' character, if the regulations under which the 2451 station is operating are for an outdoor environment only, or 2453 3 an ASCII 'I' character, if the regulations under which the 2454 station is operating are for an indoor environment only 2456 255 Country Code field is not used; ignore the field. 2458 6.24. IEEE 802.11 WTP Radio Fail Alarm Indication 2460 The IEEE 802.11 WTP Radio Fail Alarm Indication message element is 2461 sent by the WTP to the AC when it detects a radio failure. 2463 0 1 2 3 2464 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 2465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2466 | Radio ID | Type | Status | Pad | 2467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2469 Type: 1047 for IEEE 802.11 WTP Radio Fail Alarm Indication 2471 Length: 4 2473 Radio ID: The Radio Identifier, typically refers to some interface 2474 index on the WTP 2476 Type: The type of radio failure detected. The following enumerated 2477 values are supported: 2479 1 - Receiver 2481 2 - Transmitter 2483 Status: An 8-bit boolean indicating whether the radio failure is 2484 being reported or cleared. A value of zero is used to clear the 2485 event, while a value of one is used to report the event. 2487 Pad: All implementations complying with version zero of this 2488 protocol MUST set these bits to zero. Receivers MUST ignore all 2489 bits not defined for the version of the protocol they support. 2491 6.25. IEEE 802.11 WTP Radio Information 2493 The IEEE 802.11 WTP Radio Information message element is used to 2494 communicate the radio information for each IEEE 802.11 radio in the 2495 WTP. The Discovery Request message, Primary Discovery Request 2496 message and Join Request message MUST include one such message 2497 element per radio in the WTP. The Radio-Type field is used by the AC 2498 in order to determine which IEEE 802.11 technology specific binding 2499 is to be used with the WTP. 2501 The message element contains two fields, as shown below. 2503 0 1 2 3 2504 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 2505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2506 | Radio ID | Radio Type | 2507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2508 | Radio Type | 2509 +-+-+-+-+-+-+-+-+ 2511 Type: 1048 for IEEE 802.11 WTP Radio Information 2513 Length: 5 2515 Radio ID: The Radio Identifier, which typically refers to an 2516 interface index on the WTP 2518 Radio Type: The type of radio present. Note this is a bit field 2519 which is used to specify support for more than a single type of 2520 PHY/MAC. The following bit values are supported: 2522 1 - 802.11b: An IEEE 802.11b radio. 2524 2 - 802.11a: An IEEE 802.11a radio. 2526 4 - 802.11g: An IEEE 802.11g radio. 2528 8 - 802.11n: An IEEE 802.11n radio. 2530 7. IEEE 802.11 Binding WTP Saved Variables 2532 This section contains the IEEE 802.11 binding specific variables that 2533 SHOULD be saved in non-volatile memory on the WTP. 2535 7.1. IEEE80211AntennaInfo 2537 The WTP per radio antenna configuration, defined in Section 6.2. 2539 7.2. IEEE80211DSControl 2541 The WTP per radio Direct Sequence Control configuration, defined in 2542 Section 6.5. 2544 7.3. IEEE80211MACOperation 2546 The WTP per radio MAC Operation configuration, defined in 2547 Section 6.7. 2549 7.4. IEEE80211OFDMControl 2551 The WTP per radio OFDM MAC Operation configuration, defined in 2552 Section 6.10. 2554 7.5. IEEE80211Rateset 2556 The WTP per radio Basic Rate Set configuration, defined in 2557 Section 6.11. 2559 7.6. IEEE80211TxPower 2561 The WTP per radio Transmit Power configuration, defined in 2562 Section 6.18. 2564 7.7. IEEE80211QoS 2566 The WTP per radio Quality of Service configuration, defined in 2567 Section 6.22. 2569 7.8. IEEE80211RadioConfig 2571 The WTP per radio Radio Configuration, defined in Section 6.23. 2573 8. Technology Specific Message Element Values 2575 This section lists IEEE 802.11 specific values for the generic CAPWAP 2576 message elements which include fields whose values are technology 2577 specific. 2579 8.1. WTP Descriptor Message Element, Encryption Capabilities Field: 2581 IEEE 802.11 uses the following values: 2583 4 - Encrypt AES-CCMP 128: WTP supports AES-CCMP, as defined in 2584 [IEEE.802-11.2007]. 2586 5 - Encrypt TKIP-MIC: WTP supports TKIP and Michael, as defined in 2587 [IEEE.802-11.2007] and [WPA], respectively. 2589 9. Security Considerations 2591 This section describes security considerations for using IEEE 802.11 2592 with the CAPWAP protocol. 2594 9.1. IEEE 802.11 Security 2596 When used with an IEEE 802.11 infrastructure with WEP encryption, the 2597 CAPWAP protocol does not add any new vulnerabilities. Derived 2598 session keys between the STA and WTP can be compromised, resulting in 2599 many well-documented attacks. Implementers SHOULD discourage the use 2600 of WEP and encourage use of technically sound cryptographic solutions 2601 such as those in an IEEE 802.11 RSN. 2603 STA authentication is performed using IEEE 802.lX, and consequently 2604 EAP. Implementers SHOULD use EAP methods meeting the requirements 2605 specified [RFC4017]. 2607 When used with IEEE 802.11 RSN security, the CAPWAP protocol may 2608 introduce new vulnerabilities, depending on whether the link security 2609 (packet encryption and integrity verification) is provided by the WTP 2610 or the AC. When the link security function is provided by the AC, no 2611 new security concerns are introduced. 2613 However, when the WTP provides link security, a new vulnerability 2614 will exist when the following conditions are true: 2616 o The client is not the first to associate to the WTP/ESSID (i.e. 2617 other clients are associated), and a GTK already exists 2619 o traffic has been broadcast under the existing GTK 2621 Under these circumstances, the receive sequence counter (KeyRSC) 2622 associated with the GTK is non-zero, but because the AC anchors the 2623 4-way handshake with the client, the exact value of the KeyRSC is not 2624 known when the AC constructs the message containing the GTK. The 2625 client will update its Key RSC value to the current valid KeyRSC upon 2626 receipt of a valid multicast/broadcast message, but prior to this, 2627 previous multicast/broadcast traffic which was secured with the 2628 existing GTK may be replayed, and the client will accept this traffic 2629 as valid. 2631 Typically, busy networks will produce numerous multicast or broadcast 2632 frames per second, so the window of opportunity with respect to such 2633 replay is expected to be very small. In most conditions, it is 2634 expected that replayed frames could be detected (and logged) by the 2635 WTP. 2637 The only way to completely close this window is to provide the exact 2638 KeyRSC value in message 3 of the 4-way handshake; any other approach 2639 simply narrows the window to varying degrees. Given the low relative 2640 threat level this presents, the additional complexity introduced by 2641 providing the exact KeyRSC value is not warranted. That is, this 2642 specification provides for a calculated risk in this regard. 2644 The AC SHOULD use an RSC of 0 when computing message-3 of the 4-way 2645 802.11i handshake, unless the AC has knowledge of a more optimal RSC 2646 value to use. Mechanisms for determining a more optimal RSC value 2647 are outside the scope of this specification. 2649 10. IANA Considerations 2651 10.1. CAPWAP Message Types 2653 This specification defines two new Message Types used in the CAPWAP 2654 header. These values are defined in Section 3. 2656 10.2. CAPWAP Control Message Type 2658 This specification defines 27 new Message Types used in the CAPWAP 2659 header. These values are defined in Figure 8. 2661 10.3. IEEE 802.11 Key Status 2663 The Key Status field in the IEEE 802.11 Add WLAN message element (see 2664 Section 6.1) and IEEE 802.11 Update WLAN message element (see 2665 Section 6.21) is used to provide information about the status of the 2666 keying exchange. This document defines four values, and the 2667 remaining values are controlled and maintained by IANA and requires a 2668 Standards Action. 2670 10.4. IEEE 802.11 QoS 2672 The QoS field in the IEEE 802.11 Add WLAN message element (see 2673 Section 6.1) is used to configure a QoS policy for the WLAN. This 2674 document defines four values, and the remaining values are controlled 2675 and maintained by IANA and requires a Standards Action. 2677 10.5. IEEE 802.11 Auth Type 2679 The Auth Type field in the IEEE 802.11 Add WLAN message element (see 2680 Section 6.1) is used to configure the IEEE 802.11 authentication 2681 policy for the WLAN. This document defines two bits, and the 2682 remaining bits are controlled and maintained by IANA and requires a 2683 Standards Action. 2685 10.6. IEEE 802.11 Antenna Combiner 2687 The Combiner field in the IEEE 802.11 Antenna message element (see 2688 Section 6.2) is used to provide information about the WTP's antennas. 2689 This document defines four bits, and the remaining bits are 2690 controlled and maintained by IANA and requires a Standards Action. 2692 10.7. IEEE 802.11 Antenna Selection 2694 The Antenna Selection field in the IEEE 802.11 Antenna message 2695 element (see Section 6.2) is used to provide information about the 2696 WTP's antennas. This document defines two values, and the remaining 2697 values are controlled and maintained by IANA and requires a Standards 2698 Action. 2700 10.8. IEEE 802.11 Session Key Flags 2702 The Flags field in the IEEE 802.11 Station Session Key message 2703 element (see Section 6.15) is used to configure the session key 2704 association with the mobile device. This document defines two bits, 2705 and the remaining 14 bits are controlled and maintained by IANA and 2706 requires a Standards Action. 2708 10.9. IEEE 802.11 Tag Packets 2710 The Tag Packets field in the IEEE 802.11 WTP Quality of Service 2711 message element (see Section 6.22) is used to specify how the CAPWAP 2712 Data Channel packets are to be tagged. This document defines two 2713 bits, and the remaining 6 bits are controlled and maintained by IANA 2714 and requires a Standards Action. 2716 10.10. IEEE 802.11 WTP Radio Fail 2718 The Type field in the IEEE 802.11 WTP Radio Fail Alarm Indication 2719 message element (see Section 6.24) is used to provide information on 2720 why a WTP's radio has failed. This document defines two values, and 2721 the remaining values are controlled and maintained by IANA and 2722 requires a Standards Action. 2724 10.11. IEEE 802.11 WTP Radio Type 2726 The Radio Type field in the IEEE 802.11 WTP Radio Information message 2727 element (see Section 6.25) is used to provide information about the 2728 WTP's radio type. This document defines four bits, and the remaining 2729 28 bits are controlled and maintained by IANA and requires a 2730 Standards Action. 2732 11. Acknowledgements 2734 The following individuals are acknowledged for their contributions to 2735 this binding specification: Puneet Agarwal, Charles Clancy, Saravanan 2736 Govindan, Scott Kelly, Peter Nilsson, Bob O'Hara, David Perkins, 2737 Margaret Wasserman and Yong Zhang. 2739 12. References 2741 12.1. Normative References 2743 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2744 Requirement Levels", BCP 14, RFC 2119, March 1997. 2746 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 2747 Levkowetz, "Extensible Authentication Protocol (EAP)", 2748 RFC 3748, June 2004. 2750 [ISO.3166.1984] 2751 International Organization for Standardization, "Codes for 2752 the Representation of Names of Countries", ISO Standard 2753 3166, 1984. 2755 [FIPS.197.2001] 2756 National Institute of Standards and Technology, "Advanced 2757 Encryption Standard (AES)", FIPS PUB 197, November 2001, < 2758 http://csrc.nist.gov/publications/fips/fips197/ 2759 fips-197.pdf>. 2761 [IEEE.802-11.2007] 2762 "Information technology - Telecommunications and 2763 information exchange between systems - Local and 2764 metropolitan area networks - Specific requirements - Part 2765 11: Wireless LAN Medium Access Control (MAC) and Physical 2766 Layer (PHY) specifications", IEEE Standard 802.11, 2007, < 2767 http://standards.ieee.org/getieee802/download/ 2768 802.11-2007.pdf>. 2770 [I-D.ietf-capwap-protocol-specification] 2771 Calhoun, P., "CAPWAP Protocol Specification", 2772 draft-ietf-capwap-protocol-specification-10 (work in 2773 progress), March 2008. 2775 [IEEE.802-1X.2004] 2776 "Information technology - Telecommunications and 2777 information exchange between systems - Local and 2778 metropolitan area networks - Specific requirements - Port- 2779 Based Network Access Control", IEEE Standard 802.1X, 2004, 2780 . 2783 [IEEE.802-1Q.2005] 2784 "Information technology - Telecommunications and 2785 information exchange between systems - Local and 2786 metropolitan area networks - Specific requirements - 2787 Virtual Bridged Local Area Networks", IEEE Standard 2788 802.1Q, 2005, . 2791 12.2. Informational References 2793 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 2794 Authentication Protocol (EAP) Method Requirements for 2795 Wireless LANs", RFC 4017, March 2005. 2797 [RFC4118] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy 2798 for Control and Provisioning of Wireless Access Points 2799 (CAPWAP)", RFC 4118, June 2005. 2801 [WPA] "WiFi Protected Access (WPA), 2802 WPAfor802.11ver3_073004.pdf", August 2004, . 2805 Editors' Addresses 2807 Pat R. Calhoun 2808 Cisco Systems, Inc. 2809 170 West Tasman Drive 2810 San Jose, CA 95134 2812 Phone: +1 408-902-3240 2813 Email: pcalhoun@cisco.com 2815 Michael P. Montemurro 2816 Research In Motion 2817 5090 Commerce Blvd 2818 Mississauga, ON L4W 5M4 2819 Canada 2821 Phone: +1 905-629-4746 x4999 2822 Email: mmontemurro@rim.com 2824 Dorothy Stanley 2825 Aruba Networks 2826 1322 Crossman Ave 2827 Sunnyvale, CA 94089 2829 Phone: +1 630-363-1389 2830 Email: dstanley@arubanetworks.com 2832 Full Copyright Statement 2834 Copyright (C) The IETF Trust (2008). 2836 This document is subject to the rights, licenses and restrictions 2837 contained in BCP 78, and except as set forth therein, the authors 2838 retain all their rights. 2840 This document and the information contained herein are provided on an 2841 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2842 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2843 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2844 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2845 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2846 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2848 Intellectual Property 2850 The IETF takes no position regarding the validity or scope of any 2851 Intellectual Property Rights or other rights that might be claimed to 2852 pertain to the implementation or use of the technology described in 2853 this document or the extent to which any license under such rights 2854 might or might not be available; nor does it represent that it has 2855 made any independent effort to identify any such rights. Information 2856 on the procedures with respect to rights in RFC documents can be 2857 found in BCP 78 and BCP 79. 2859 Copies of IPR disclosures made to the IETF Secretariat and any 2860 assurances of licenses to be made available, or the result of an 2861 attempt made to obtain a general license or permission for the use of 2862 such proprietary rights by implementers or users of this 2863 specification can be obtained from the IETF on-line IPR repository at 2864 http://www.ietf.org/ipr. 2866 The IETF invites any interested party to bring to its attention any 2867 copyrights, patents or patent applications, or other proprietary 2868 rights that may cover technology that may be required to implement 2869 this standard. Please address the information to the IETF at 2870 ietf-ipr@ietf.org.