idnits 2.17.1 draft-ietf-capwap-protocol-binding-ieee80211-00.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 on line 2419. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2430. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2437. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2443. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 21 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 13, 2006) is 6404 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '5' is defined on line 2354, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 2365, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 2368, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 2371, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4346 (ref. '8') (Obsoleted by RFC 5246) Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 7 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: Informational M. Montemurro, Editor 5 Expires: April 16, 2007 Research In Motion 6 D. Stanley, Editor 7 Aruba Networks 8 October 13, 2006 10 CAPWAP Protocol Binding for IEEE 802.11 11 draft-ietf-capwap-protocol-binding-ieee80211-00 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 16, 2007. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 Wireless LAN product architectures have evolved from single 45 autonomous access points to systems consisting of a centralized 46 Access Controller (AC) and Wireless Termination Points (WTPs). The 47 general goal of centralized control architectures is to move access 48 control, including user authentication and authorization, mobility 49 management and radio management from the single access point to a 50 centralized controller. 52 This specification defines the Control And Provisioning of Wireless 53 Access Points (CAPWAP) Protocol Binding Specification for use with 54 the IEEE 802.11 Wireless Local Area Network (WLAN) protocol. The 55 CAPWAP Protocol Specification is defined separately [1]. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.2. Conventions used in this document . . . . . . . . . . . . 4 62 1.3. Contributing Authors . . . . . . . . . . . . . . . . . . . 4 63 1.4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 4 64 1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 65 2. IEEE 802.11 Binding . . . . . . . . . . . . . . . . . . . . . 6 66 2.1. Split MAC and Local MAC Functionality . . . . . . . . . . 6 67 2.1.1. Split MAC . . . . . . . . . . . . . . . . . . . . . . 6 68 2.1.2. Local MAC . . . . . . . . . . . . . . . . . . . . . . 8 69 2.2. Roaming Behavior . . . . . . . . . . . . . . . . . . . . . 11 70 2.3. Group Key Refresh . . . . . . . . . . . . . . . . . . . . 12 71 2.4. BSSID to WLAN ID Mapping . . . . . . . . . . . . . . . . . 13 72 2.5. Quality of Service for IEEE 802.11 MAC Management 73 Messages . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 2.6. Run State Operation . . . . . . . . . . . . . . . . . . . 13 75 3. IEEE 802.11 Specific CAPWAP Control Messages . . . . . . . . . 14 76 3.1. IEEE 802.11 WLAN Configuration Request . . . . . . . . . . 14 77 3.2. IEEE 802.11 WLAN Configuration Response . . . . . . . . . 15 78 4. CAPWAP Data Message Bindings . . . . . . . . . . . . . . . . . 16 79 5. CAPWAP Control Message bindings . . . . . . . . . . . . . . . 18 80 5.1. Discovery Request Message . . . . . . . . . . . . . . . . 18 81 5.2. Primary Discovery Request Message . . . . . . . . . . . . 18 82 5.3. Join Request Request Message . . . . . . . . . . . . . . . 18 83 5.4. Configuration Status Message . . . . . . . . . . . . . . . 18 84 5.5. Configuration Status Response Message . . . . . . . . . . 19 85 5.6. Configuration Update Request Message . . . . . . . . . . . 19 86 5.7. Station Configuration Request . . . . . . . . . . . . . . 20 87 5.8. WTP Event Request . . . . . . . . . . . . . . . . . . . . 20 88 6. IEEE 802.11 Message Element Definitions . . . . . . . . . . . 21 89 6.1. IEEE 802.11 Add WLAN . . . . . . . . . . . . . . . . . . . 21 90 6.2. IEEE 802.11 Antenna . . . . . . . . . . . . . . . . . . . 25 91 6.3. IEEE 802.11 Assigned WTP BSSID . . . . . . . . . . . . . . 26 92 6.4. IEEE 802.11 Delete WLAN . . . . . . . . . . . . . . . . . 27 93 6.5. IEEE 802.11 Direct Sequence Control . . . . . . . . . . . 27 94 6.6. IEEE 802.11 Information Element . . . . . . . . . . . . . 28 95 6.7. IEEE 802.11 MAC Operation . . . . . . . . . . . . . . . . 29 96 6.8. IEEE 802.11 MIC Countermeasures . . . . . . . . . . . . . 31 97 6.9. IEEE 802.11 Multi-Domain Capability . . . . . . . . . . . 31 98 6.10. IEEE 802.11 OFDM Control . . . . . . . . . . . . . . . . . 32 99 6.11. IEEE 802.11 Rate Set . . . . . . . . . . . . . . . . . . . 33 100 6.12. IEEE 802.11 RSNA Error Report From Station . . . . . . . . 34 101 6.13. IEEE 802.11 Station . . . . . . . . . . . . . . . . . . . 36 102 6.14. IEEE 802.11 Station QoS Profile . . . . . . . . . . . . . 37 103 6.15. IEEE 802.11 Station Session Key . . . . . . . . . . . . . 37 104 6.16. IEEE 802.11 Statistics . . . . . . . . . . . . . . . . . . 39 105 6.17. IEEE 802.11 Supported Rates . . . . . . . . . . . . . . . 43 106 6.18. IEEE 802.11 Tx Power . . . . . . . . . . . . . . . . . . . 43 107 6.19. IEEE 802.11 Tx Power Level . . . . . . . . . . . . . . . . 44 108 6.20. IEEE 802.11 Update Station QoS . . . . . . . . . . . . . . 44 109 6.21. IEEE 802.11 Update WLAN . . . . . . . . . . . . . . . . . 45 110 6.22. IEEE 802.11 WTP Quality of Service . . . . . . . . . . . . 47 111 6.23. IEEE 802.11 WTP Radio Configuration . . . . . . . . . . . 48 112 6.24. IEEE 802.11 WTP Radio Fail Alarm Indication . . . . . . . 50 113 6.25. IEEE 802.11 WTP Radio Information . . . . . . . . . . . . 50 114 7. IEEE 802.11 Binding WTP Saved Variables . . . . . . . . . . . 52 115 7.1. IEEE80211AntennaInfo . . . . . . . . . . . . . . . . . . . 52 116 7.2. IEEE80211DSControl . . . . . . . . . . . . . . . . . . . . 52 117 7.3. IEEE80211MACOperation . . . . . . . . . . . . . . . . . . 52 118 7.4. IEEE80211OFDMControl . . . . . . . . . . . . . . . . . . . 52 119 7.5. IEEE80211Rateset . . . . . . . . . . . . . . . . . . . . . 52 120 7.6. IEEE80211TxPower . . . . . . . . . . . . . . . . . . . . . 52 121 7.7. IEEE80211QoS . . . . . . . . . . . . . . . . . . . . . . . 52 122 7.8. IEEE80211RadioConfig . . . . . . . . . . . . . . . . . . . 52 123 8. Technology Specific Message Element Values . . . . . . . . . . 53 124 9. Security Considerations . . . . . . . . . . . . . . . . . . . 54 125 9.1. IEEE 802.11 Security . . . . . . . . . . . . . . . . . . . 54 126 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55 127 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 56 128 11.1. Normative References . . . . . . . . . . . . . . . . . . . 56 129 11.2. Informational References . . . . . . . . . . . . . . . . . 57 130 Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 58 131 Intellectual Property and Copyright Statements . . . . . . . . . . 59 133 1. Introduction 135 This specification defines the Control And Provisioning of Wireless 136 Access Points (CAPWAP) Protocol Binding Specification for use with 137 the IEEE 802.11 Wireless Local Area Network (WLAN) protocol. Use of 138 CAPWAP control message fields, new control messages and message 139 elements are defined. The minimum required definitions for a 140 binding-specific Statistics message element, Station message element, 141 and WTP Radio Information message element are included. 143 1.1. Goals 145 The goals for this CAPWAP protocol binding are listed below: 147 1. To centralize the authentication and policy enforcement functions 148 for an IEEE 802.11 wireless network. The AC may also provide 149 centralized bridging, forwarding, and encryption of user traffic. 150 Centralization of these functions will enable reduced cost and 151 higher efficiency by applying the capabilities of network 152 processing silicon to the wireless network, as in wired LANs. 154 2. To enable shifting of the higher level protocol processing from 155 the WTP. This leaves the time critical applications of wireless 156 control and access in the WTP, making efficient use of the 157 computing power available in WTPs which are the subject to severe 158 cost pressure. 160 The CAPWAP protocol binding extensions defined herein apply solely to 161 the interface between the WTP and the AC. Inter-AC, or station to AC 162 communication is strictly outside the scope of this document. 164 1.2. Conventions used in this document 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in RFC 2119 [2]. 170 1.3. Contributing Authors 172 TBD 174 1.4. Acknowledgements 176 TBD 178 1.5. Terminology 180 Access Controller (AC): The network entity that provides WTP access 181 to the network infrastructure in the data plane, control plane, 182 management plane, or a combination therein. 184 Basic Service Set (BSS): A set of stations controlled by a single 185 coordination function. 187 Distribution: The service that, by using association information, 188 delivers medium access control (MAC) service data units (MSDUs) 189 within the distribution system (DS). 191 Distribution System Service (DSS): The set of services provided by 192 the distribution system (DS) that enable the medium access control 193 (MAC) layer to transport MAC service data units (MSDUs) between 194 stations that are not in direct communication with each other over a 195 single instance of the wireless medium (WM). These services include 196 the transport of MSDUs between the access points (APs) of basic 197 service sets (BSSs) within an extended service set (ESS), transport 198 of MSDUs between portals and BSSs within an ESS, and transport of 199 MSDUs between stations in the same BSS in cases where the MSDU has a 200 multicast or broadcast destination address, or where the destination 201 is an individual address, but the station sending the MSDU chooses to 202 involve the DSS. DSSs are provided between pairs of IEEE 802.11 203 MACs. 205 Integration: The service that enables delivery of medium access 206 control (MAC) service data units (MSDUs) between the distribution 207 system (DS) and an existing, non-IEEE 802.11 local area network (via 208 a portal). 210 Station (STA): A device that contains an IEEE 802.11 conformant 211 medium access control (MAC) and physical layer (PHY) interface to the 212 wireless medium (WM). 214 Portal: The logical point at which medium access control (MAC) 215 service data units (MSDUs) from a non-IEEE 802.11 local area network 216 (LAN) enter the distribution system (DS) of an extended service set 217 (ESS). 219 Wireless Termination Point (WTP): The physical or network entity that 220 contains an IEEE 802.11 RF antenna and wireless PHY to transmit and 221 receive station traffic for wireless access networks. 223 2. IEEE 802.11 Binding 225 This section describes use of the CAPWAP protocol with IEEE 802.11 226 WLANs, including Local and Split MAC operation, Group Key Refresh, 227 BSSID to WLAN Mapping, IEEE 802.11 MAC management frame Quality of 228 Service tagging and Run State operation. 230 2.1. Split MAC and Local MAC Functionality 232 The CAPWAP protocol, when used with IEEE 802.11 devices, requires 233 specific behavior from the WTP and the AC, to support the required 234 IEEE 802.11 protocol functions. 236 For both the Split and Local MAC approaches, the CAPWAP functions, as 237 defined in the taxonomy specification [7], reside in the AC. 239 2.1.1. Split MAC 241 This section shows the division of labor between the WTP and the AC 242 in a Split MAC architecture. Figure 1 shows the separation of 243 functionality between CAPWAP components. 245 Function Location 246 Distribution Service AC 247 Integration Service AC 248 Beacon Generation WTP 249 Probe Response Generation WTP 250 Power Mgmt/Packet Buffering WTP 251 Fragmentation/Defragmentation WTP/AC 252 Assoc/Disassoc/Reassoc AC 254 IEEE 802.11 QOS 255 Classifying AC 256 Scheduling WTP/AC 257 Queuing WTP 259 IEEE 802.11 RSN 260 IEEE 802.1X/EAP AC 261 RSNA Key Management AC 262 IEEE 802.11 Encryption/Decryption WTP/AC 264 Figure 1: Mapping of 802.11 Functions for Split MAC Architecture 266 In a Split MAC Architecture,the Distribution and Integration services 267 reside on the AC, and therefore all user data is tunneled between the 268 WTP and the AC. As noted above, all real-time IEEE 802.11 services, 269 including the beacon and probe response frames, are handled on the 270 WTP. 272 All remaining IEEE 802.11 MAC management frames are supported on the 273 AC, including the Association Request frame which allows the AC to be 274 involved in the access policy enforcement portion of the IEEE 802.11 275 protocol. The IEEE 802.1X and IEEE 802.11 key management function 276 are also located on the AC. This implies that the AAA client also 277 resides on the AC. 279 While the admission control component of IEEE 802.11 resides on the 280 AC, the real time scheduling and queuing functions are on the WTP. 281 Note this does not exclude the AC from providing additional policy 282 and scheduling functionality. 284 Note that in the following figure, the use of '( - )' indicates that 285 processing of the frames is done on the WTP. 287 Client WTP AC 289 Beacon 290 <----------------------------- 291 Probe Request 292 ----------------------------( - )-------------------------> 293 Probe Response 294 <----------------------------- 295 802.11 AUTH/Association 296 <---------------------------------------------------------> 297 Station Configuration Request[Add Station (Clear Text, 802.1X)] 298 <-------------------------> 299 802.1X Authentication & 802.11 Key Exchange 300 <---------------------------------------------------------> 301 Station Configuration Request[Add Station (AES-CCMP, PTK=x)] 302 <-------------------------> 303 802.11 Action Frames 304 <---------------------------------------------------------> 305 802.11 DATA (1) 306 <---------------------------( - )-------------------------> 308 Figure 2: Split MAC Message Flow 310 Figure 2 provides an illustration of the division of labor in a Split 311 MAC architecture. In this example, a WLAN has been created that is 312 configured for IEEE 802.11, using AES-CCMP for privacy. The 313 following process occurs: 315 o The WTP generates the IEEE 802.11 beacon frames, using information 316 provided to it through the IEEE 802.11 Add WLAN (see Section 6.1) 317 message element. 319 o The WTP processes the probe request frame and responds with a 320 corresponding probe response frame. The probe request frame is 321 then forwarded to the AC for optional processing. 323 o The WTP forwards the IEEEE 802.11 Authentication and Association 324 frames to the AC, which is responsible for responding to the 325 client. 327 o Once the association is complete, the AC transmits a Station 328 Configuration Request message, which includes an Add Station 329 message element, to the WTP (see Section 4.4.8 in [1]). In the 330 above example, the WLAN is configured for IEEE 802.1X, and 331 therefore the '802.1X only' policy bit is enabled. 333 o If the WTP is providing encryption/decryption services, once the 334 client has completed the IEEE 802.11 key exchange, the AC 335 transmits another Station Configuration Request message which 336 includes an Add Station message element, an IEEE 802.11 Station 337 message element, an IEEE 802.11 Station Session Key message 338 element and an IEEE 802.11 Information Element message element 339 which includes the RSNIE to the WTP, delivering the security 340 policy to enforce for the station (in this case AES-CCMP), and the 341 encryption key to use. If encryption/decryption is handled in the 342 AC, the IEEE 802.11 Information message element with an RSNIE 343 would not be included. 345 o The WTP forwards any IEEE 802.11 Management Action frames received 346 to the AC. 348 o All IEEE 802.11 station data frames are tunneled between the WTP 349 and the AC. 351 2.1.2. Local MAC 353 This section shows the division of labor between the WTP and the AC 354 in a Local MAC architecture. Figure 3 shows the separation of 355 functionality among CAPWAP components. 357 Function Location 358 Distribution Service WTP 359 Integration Service WTP 360 Beacon Generation WTP 361 Probe Response Generation WTP 362 Power Mgmt/Packet Buffering WTP 363 Fragmentation/Defragmentation WTP 364 Assoc/Disassoc/Reassoc WTP 366 IEEE 802.11 QOS 367 Classifying WTP 368 Scheduling WTP 369 Queuing WTP 371 IEEE 802.11 RSN 372 IEEE 802.1X/EAP AC 373 RSNA Key Management AC 374 IEEE 802.11 Encryption/Decryption WTP 376 Figure 3: Mapping of 802.11 Functions for Local AP Architecture 378 Since the Distribution and Integration Services exist on the WTP, 379 station generated frames are not forwarded to the AC, with the 380 exception listed in the following paragraphs. 382 While the MAC is terminated on the WTP, it is necessary for the AC to 383 be aware of mobility events within the WTPs. Thus the WTP MUST 384 forward the IEEE 802.11 Association Request frames to the AC. The AC 385 MAY reply with a failed Association Response frame if it deems it 386 necessary, and upon receipt of a failed Association Response frame 387 from the AC, the WTP must send a Disassociation frame to the station. 389 The IEEE 802.1X and RSNA Key Management functions reside in the AC. 390 Therefore, the WTP MUST forward all IEEE 802.1X/RSNA Key Management 391 frames to the AC and forward the corresponding responses to the 392 station. This implies that the AAA client also resides on the AC. 394 Note that in the following figure, the use of '( - )' indicates that 395 processing of the frames is done on the WTP. 397 Client WTP AC 399 Beacon 400 <----------------------------- 401 Probe 402 <----------------------------> 403 802.11 AUTH 404 <----------------------------- 405 802.11 Association 406 <---------------------------( - )-------------------------> 407 Station Configuration Request[Add Station (Clear Text, 802.1X)] 408 <-------------------------> 409 802.1X Authentication & 802.11 Key Exchange 410 <---------------------------------------------------------> 411 802.11 Action Frames 412 <---------------------------------------------------------> 413 Station Configuration Request[Add Station (AES-CCMP, PTK=x)] 414 <-------------------------> 415 802.11 DATA 416 <-----------------------------> 418 Figure 4: Local MAC Message Flow 420 Figure 4 provides an illustration of the division of labor in a Local 421 MAC architecture. In this example, a WLAN has been created that is 422 configured for IEEE 802.11, using AES-CCMP for privacy. The 423 following process occurs: 425 o The WTP generates the IEEE 802.11 beacon frames, using information 426 provided to it through the Add WLAN (see Section 6.1) message 427 element. 429 o The WTP processes a probe request frame and responds with a 430 corresponding probe response frame. 432 o The WTP forwards the IEEE 802.11 Authentication and Association 433 frames to the AC. 435 o Once the association is complete, the AC transmits a Station 436 Configuration Request message, which includes the Add Station 437 message element, to the WTP (see Section 10.1 in [1]). In the 438 above example, the WLAN is configured for IEEE 802.1X, and 439 therefore the '802.1X only' policy bit is enabled. 441 o The WTP forwards all IEEE 802.1X and IEEE 802.11 key exchange 442 messages to the AC for processing. 444 o The AC transmits another Station Configuration Request message 445 including an Add Station message element, an IEEE 802.11 Station 446 message element, an IEEE 802.11 Station Session Key message 447 element and an IEEE 802.11 Information Element message element 448 which includes the RSNIE to the WTP, stating the security policy 449 to enforce for the client (in this case AES-CCMP), as well as the 450 encryption key to use. The Add Station message element MAY 451 include a VLAN name, which when present is used by the WTP to 452 identify the VLAN on which the user's data frames are to be 453 bridged. 455 o The WTP forwards any IEEE 802.11 Management Action frames received 456 to the AC. 458 o The WTP may locally bridge client data frames (and provide the 459 necessary encryption and decryption services). The WTP may also 460 tunnel client data frames to the AC, using 802.3 frame tunnel mode 461 or 802.11 frame tunnel mode. 463 2.2. Roaming Behavior 465 This section expands upon the examples provided in the previous 466 section, and describes how the CAPWAP control protocol is used to 467 provide secure roaming. 469 Once a client has successfully associated with the network in a 470 secure fashion, it is likely to attempt to roam to another WTP. 471 Figure 5 shows an example of a currently associated station moving 472 from its "Old WTP" to a "new WTP". The figure is valid for multiple 473 different security policies, including IEEE 802.1X and WPA or WPA2, 474 both with key caching (where the IEEE 802.1x exchange would be 475 bypassed) and without. 477 Client Old WTP WTP AC 479 Association Request/Response 480 <--------------------------------------( - )--------------> 481 Station Configuration Request[Add Station (Clear Text, 802.1X)] 482 <----------------> 483 802.1X Authentication (if no key cache entry exists) 484 <--------------------------------------( - )--------------> 485 802.11 4-way Key Exchange 486 <--------------------------------------( - )--------------> 487 Station Configuration Request[Delete Station] 488 <----------------------------------> 489 Station Configuration Request[Add Station (AES-CCMP, PTK=x)] 490 <----------------> 492 Figure 5: Client Roaming Example 494 2.3. Group Key Refresh 496 Periodically, the Group Key (GTK)for the BSS needs to be updated. 497 The AC uses an EAPOL-Key frame to update the group key for each STA 498 in the BSS. While the AC is updating the GTK, each L2 broadcast 499 frame transmitted to the BSS needs to be duplicated and transmitted 500 using both the current GTK and the new GTK. Once the GTK update 501 process has completed, broadcast frames transmitted to the BSS will 502 be encrypted using the new GTK. 504 In the case of Split MAC, the AC needs to duplicate all broadcast 505 packets and update the key index so that the packet is transmitted 506 using both the current and new GTK to ensure that all STA's in the 507 BSS receive the broadcast frames. In the case of local MAC, the WTP 508 needs to duplicate and transmit broadcast frames using the 509 appropriate index to ensure that all STA's in the BSS continue to 510 receive broadcast frames. 512 The Group Key update procedure is shown in the following figure. The 513 AC will signal the update to the GTK using an IEEE 802.11 514 Configuration Request message, including an IEEE 802.11 Update WLAN 515 message element with the new GTK, its index, the TSC for the Group 516 Key and the Key Status set to 3 (begin GTK update). The AC will then 517 begin updating the GTK for each STA. During this time, the AC (for 518 Split MAC) or WTP (for Local MAC) must duplicate broadcast packets 519 and transmit them encrypted with both the current and new GTK. When 520 the AC has completed the GTK update to all STA's in the BSS, the AC 521 must transmit an IEEE 802.11 Configuration Request message including 522 an IEEE 802.11 Update WLAN message element containing the new GTK, 523 its index, and the Key Status set to 4 (GTK update complete). 525 Client WTP AC 527 IEEE 802.11 WLAN Configuration Request ( Update WLAN (GTK, GTK Index, GTK Start, Group TSC) ) 528 <---------------------------------------------- 529 802.1X EAPoL (GTK Message 1) 530 <-------------( - )------------------------------------------- 531 802.1X EAPoL (GTK Message 2) 532 -------------( - )-------------------------------------------> 533 IEEE 802.11 WLAN Configuration Request ( Update WLAN (GTK Index, GTK Complete) ) 534 <--------------------------------------------- 536 Figure 6: Group Key Update Procedure 538 2.4. BSSID to WLAN ID Mapping 540 The CAPWAP protocol binding enables the WTP to assign BSSIDs upon 541 creation of a WLAN (see Section 6.1). While manufacturers are free 542 to assign BSSIDs using any arbitrary mechanism, it is advised that 543 where possible the BSSIDs are assigned as a contiguous block. 545 When assigned as a block, implementations can still assign any of the 546 available BSSIDs to any WLAN. One possible method is for the WTP to 547 assign the address using the following algorithm: base BSSID address 548 + WLAN ID. 550 The WTP communicates the maximum number of BSSIDs that it supports 551 during configuration via the IEEE 802.11 WTP WLAN Radio Configuration 552 message element (see Section 6.23). 554 2.5. Quality of Service for IEEE 802.11 MAC Management Messages 556 It is recommended that IEEE 802.11 MAC Management frames be sent by 557 both the AC and the WTP with appropriate Quality of Service values, 558 listed below, to ensure that congestion in the network minimizes 559 occurrences of packet loss. 561 802.1P: The precedence value of 7 SHOULD be used for all IEEE 562 802.11 MAC management frames, except for Probe Requests which 563 SHOULD use 4. 565 DSCP: The DSCP tag value of 46 SHOULD be used for all IEEE 802.11 566 MAC management frames, except for Probe Requests which SHOULD use 567 34. 569 2.6. Run State Operation 571 The Run state is the normal state of operation for the CAPWAP 572 protocol in both the WTP and the AC. 574 When the WTP receives a WLAN Configuration Request message (see 575 Section 3.1), it MUST respond with a WLAN Configuration Response 576 message (see Section 3.2) and it remains in the Run state. 578 When the AC sends a WLAN Configuration Request message (see 579 Section 3.1) or receives the corresponding WLAN Configuration 580 Response message (see Section 3.2) from the WTP, it remains in the 581 Run state. 583 3. IEEE 802.11 Specific CAPWAP Control Messages 585 This section defines CAPWAP Control Messages that are specific to the 586 IEEE 802.11 binding. Two messages are defined, IEEE 802.11 WLAN 587 Configuration Request and IEEE 802.11 WLAN Configuration Response. 588 See Section 4.3 in [1] for CAPWAP Control message definitions and the 589 derivation of the Message Type value from the IANA Enterprise number. 591 The valid message types for IEEE 802.11 specific control messages are 592 listed below. The IANA Enterprise number used with these messages is 593 13277. 595 CAPWAP Control Message Message Type 596 Value 598 IEEE 802.11 WLAN Configuration Request 3398912 599 IEEE 802.11 WLAN Configuration Response 3398913 601 3.1. IEEE 802.11 WLAN Configuration Request 603 The IEEE 802.11 WLAN Configuration Request is sent by the AC to the 604 WTP in order to change services provided by the WTP. This control 605 message is used to either create, update or delete a WLAN on the WTP. 607 The IEEE 802.11 WLAN Configuration Request is sent as a result of 608 either some manual admistrative process (e.g., deleting a WLAN), or 609 automatically to create a WLAN on a WTP. When sent automatically to 610 create a WLAN, this control message is sent after the CAPWAP 611 Configuration Update Request message (see Section 4.3 in [1]) has 612 been received by the WTP. 614 Upon receiving this control message, the WTP will modify the 615 necessary services, and transmit an IEEE 802.11 WLAN Configuration 616 Response. 618 A WTP MAY provide service for more than one WLAN, therefore every 619 WLAN is identified through a numerical index. For instance, a WTP 620 that is capable of supporting up to 16 SSIDs, could accept up to 16 621 IEEE 802.11 WLAN Configuration Request messages that include the Add 622 WLAN message element. 624 Since the index is the primary identifier for a WLAN, an AC MAY 625 attempt to ensure that the same WLAN is identified through the same 626 index number on all of its WTPs. An AC that does not follow this 627 approach MUST find some other means of maintaining a WLAN Identifier 628 to SSID mapping table. 630 The following message elements may be included in the IEEE 802.11 631 WLAN Configuration Request message. Only one message element MUST be 632 present. 634 o IEEE 802.11 Add WLAN, see Section 6.1 636 o IEEE 802.11 Delete WLAN, see Section 6.4 638 o IEEE 802.11 Update WLAN, see Section 6.21 640 The following message element MAY be present. 642 o IEEE 802.11 Information Element, see Section 6.6 644 3.2. IEEE 802.11 WLAN Configuration Response 646 The IEEE 802.11 WLAN Configuration Response message is sent by the 647 WTP to the AC. It is used to acknowledge receipt of an IEEE 802.11 648 WLAN Configuration Request message, and to indicate that the 649 requested configuration was successfully applied, or that an error 650 related to the processing of the IEEE 802.11 WLAN Configuration 651 Request message occurred on the WTP. 653 The following message element MAY be included in the IEEE 802.11 WLAN 654 Configuration Response message. 656 o IEEE 802.11 Assigned WTP BSSID, see Section 6.3 658 The following message element MUST be included in the IEEE 802.11 659 WLAN Configuration Response message. 661 o Result Code, see Section 4.4.31 in [1] 663 4. CAPWAP Data Message Bindings 665 This section describes the CAPWAP Data Message bindings to support 666 transport of IEEE 802.11 frames. 668 Payload encapsulation: The CAPWAP protocol defines the CAPWAP data 669 message, which is used to encapsulate a wireless payload. For 670 IEEE 802.11, the IEEE 802.11 header and payload are encapsulated 671 (excluding the IEEE 802.11 FCS checksum). The IEEE 802.11 FCS 672 checksum is handled by the WTP. This allows the WTP to validate 673 an IEEE 802.11 frame prior to sending it to the AC. Similarly, 674 when an AC wishes to transmit a frame to a station, the WTP 675 computes and adds the FCS checksum. 677 Optional Wireless Specific Information: The optional CAPWAP header 678 field (see Section 4.1 in [1]) is only used with CAPWAP data 679 messages, and it serves two purposes, depending upon the direction 680 of the message. For messages from the WTP to the AC, the field 681 uses the format described in the "IEEE 802.11 Frame Info" field 682 (see below). However, for messages sent by the AC to the WTP, the 683 format used is described in the "Destination WLANs" field (also 684 defined below). 686 IEEE 802.11 Frame Info: When an IEEE 802.11 frame is received from a 687 station over the air, it is encapsulated and this field is used to 688 include radio and PHY specific information associated with the 689 frame. 691 The IEEE 802.11 Frame Info field has the following format: 693 0 1 2 3 694 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 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | RSSI | SNR | Data Rate | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 RSSI: RSSI is a signed, 8-bit value. It is the received signal 700 strength indication, in dBm. 702 SNR: SNR is a signed, 8-bit value. It is the signal to noise 703 ratio of the received IEEE 802.11 frame, in dB. 705 Data Rate: The data rate field is a 16 bit unsigned value. The 706 contents of the field is set to 10 times the data rate in Mbps 707 of the packet received by the WTP. For instance, a packet 708 received at 5.5Mbps would be set to 55, while 11Mbps would be 709 set to 110. 711 Destination WLANs The Destination WLANs field is used to specify the 712 target WLANs for a given frame, and is only used with broadcast 713 and multicast frames. This field allows the AC to transmit a 714 single broadcast or multicast frame to the WTP, and allows the WTP 715 to perform the necessary frame replication. The field uses the 716 following format: 718 0 1 2 3 719 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 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | WLAN ID bitmap | Reserved | 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 WLAN ID bitmap: This bit field indicates the WLAN ID (see 725 Section 6.1) on which the WTP will transmit the included frame. 726 For instance, if a multicast packet is to be transmitted on 727 WLANs 1 and 3, bits 1 and 3 of this field would be enabled. 728 This field is to be set to zero for unicast packets and is 729 unused if the WTP is not providing IEEE 802.11 encryption. 731 Reserved: All implementations complying with this protocol MUST 732 set to zero any bits that are reserved in the version of the 733 protocol supported by that implementation. Receivers MUST 734 ignore all bits not defined for the version of the protocol 735 they support. 737 5. CAPWAP Control Message bindings 739 This section describes the IEEE 802.11 specific message elements 740 included in CAPWAP Control Messages. 742 5.1. Discovery Request Message 744 The following IEEE 802.11 specific message element MUST be included 745 in the CAPWAP Discovery Request Message. 747 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 748 802.11 WTP Radio Information message element MUST be present for 749 every radio in the WTP. 751 5.2. Primary Discovery Request Message 753 The following IEEE 802.11 specific message element MUST be included 754 in the CAPWAP Primary Discovery Request Message. 756 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 757 802.11 WTP Radio Information message element MUST be present for 758 every radio in the WTP. 760 5.3. Join Request Request Message 762 The following IEEE 802.11 specific message element MUST be included 763 in the CAPWAP Primary Discovery Request Message. 765 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 766 802.11 WTP Radio Information message element MUST be present for 767 every radio in the WTP. 769 5.4. Configuration Status Message 771 The following IEEE 802.11 specific message elements may be included 772 in the CAPWAP Configuration Status Message. 774 o IEEE 802.11 Antenna, see Section 6.2 776 o IEEE 802.11 Direct Sequence Control, see Section 6.5 778 o IEEE 802.11 MAC Operation, see Section 6.7 780 o IEEE 802.11 Multi Domain Capability, see Section 6.9 782 o IEEE 802.11 OFDM Control, see Section 6.10 783 o IEEE 802.11 Supported Rates, see Section 6.17 785 o IEEE 802.11 Tx Power, see Section 6.18 787 o IEEE 802.11 TX Power Level, see Section 6.19 789 o IEEE 802.11 WTP Radio Configuration, see Section 6.23 791 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 792 802.11 WTP Radio Information message element MUST be present for 793 every radio in the WTP. 795 5.5. Configuration Status Response Message 797 The following IEEE 802.11 specific message elements may be included 798 in the CAPWAP Configuration Status Response Message. 800 o IEEE 802.11 Antenna, see Section 6.2 802 o IEEE 802.11 Direct Sequence Control, see Section 6.5 804 o IEEE 802.11 MAC Operation, see Section 6.7 806 o IEEE 802.11 Multi Domain Capability, see Section 6.9 808 o IEEE 802.11 OFDM Control, see Section 6.10 810 o IEEE 802.11 Rate Set, see Section 6.11 812 o IEEE 802.11 Supported Rates, see Section 6.17 814 o IEEE 802.11 Tx Power, see Section 6.18 816 o IEEE 802.11 WTP Quality of Service, see Section 6.22 818 o IEEE 802.11 WTP Radio Configuration, see Section 6.23 820 5.6. Configuration Update Request Message 822 The following IEEE 802.11 specific message elements may be included 823 in the CAPWAP Configuration Update Request Message. 825 o IEEE 802.11 Antenna, see Section 6.2 827 o IEEE 802.11 Direct Sequence Control, see Section 6.5 829 o IEEE 802.11 MAC Operation, see Section 6.7 830 o IEEE 802.11 Multi Domain Capability, see Section 6.9 832 o IEEE 802.11 OFDM Control, see Section 6.10 834 o IEEE 802.11 Rate Set, see Section 6.11 836 o IEEE 802.11 RSNA Error Report From Station, see Section 6.12 838 o IEEE 802.11 Tx Power, see Section 6.18 840 o IEEE 802.11 WTP Quality of Service, see Section 6.22 842 o IEEE 802.11 WTP Radio Configuration, see Section 6.23 844 5.7. Station Configuration Request 846 The following IEEE 802.11 specific message elements MAY included in 847 the CAPWAP Station Configuration Request message. 849 o IEEE 802.11 Station, see Section 6.13 851 o IEEE 802.11 Station Session Key, see Section 6.15 853 o Station QoS Profile, see Section 6.14 855 5.8. WTP Event Request 857 The following IEEE 802.11 specific message elements may be included 858 in the CAPWAP WTP Event Request message. 860 o IEEE 802.11 MIC Countermeasures, see Section 6.8 862 o IEEE 802.11 Statistics, see Section 6.16 864 o IEEE 802.11 WTP Radio Fail Alarm Indication, see Section 6.24 866 6. IEEE 802.11 Message Element Definitions 868 The following IEEE 802.11 specific message elements are defined in 869 this section. 871 IEEE 802.11 Message Element Type Value 873 IEEE 802.11 Add WLAN 1024 874 IEEE 802.11 Antenna 1025 875 IEEE 802.11 Assigned WTP BSSID 1026 876 IEEE 802.11 Delete WLAN 1027 877 IEEE 802.11 Direct Sequence Control 1028 878 IEEE 802.11 Information Element 1029 879 IEEE 802.11 MAC Operation 1030 880 IEEE 802.11 MIC Countermeasures 1031 881 IEEE 802.11 Multi-Domain Capability 1032 882 IEEE 802.11 OFDM Control 1033 883 IEEE 802.11 Rate Set 1034 884 IEEE 802.11 RSNA Error Report From Station 1035 885 IEEE 802.11 Station 1036 886 IEEE 802.11 Station QoS Profile 1037 887 IEEE 802.11 Station Session Key 1038 888 IEEE 802.11 Statistics 1039 889 IEEE 802.11 Supported Rates 1040 890 IEEE 802.11 Tx Power 1041 891 IEEE 802.11 Tx Power Level 1042 892 IEEE 802.11 Update Station QoS 1043 893 IEEE 802.11 Update WLAN 1044 894 IEEE 802.11 WTP Quality of Service 1045 895 IEEE 802.11 WTP Radio Configuration 1046 896 IEEE 802.11 WTP Radio Fail Alarm Indication 1047 897 IEEE 802.11 WTP Radio Information 1048 899 6.1. IEEE 802.11 Add WLAN 901 The IEEE 802.11 Add WLAN message element is used by the AC to define 902 a wireless LAN on the WTP. The inclusion of this message element 903 MUST also include IEEE 802.11 Information Element message elements, 904 containing the following 802.11 IEs: 906 Power Capability information element 907 WPA information element 909 RSN information element 911 EDCA Parameter Set information element 913 QoS Capability information element 915 WMM information element 917 If present, the RSN information element is sent with the IEEE 802.11 918 Add WLAN message element to instruct the WTP on the usage of the Key 919 field. 921 An AC MAY include additional information elements as desired. The 922 message element uses the following format: 924 0 1 2 3 925 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 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 | Radio ID | WLAN ID | Capabilities | 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 | Key Index | Key Status | Key Length | 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 | Key... | 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 | Group TSC | 934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 | Group TSC | QoS | Auth Type | 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 | MAC Mode | Tunnel Mode | Suppress SSID | SSID ... 938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 Type: 1024 for IEEE 802.11 Add WLAN 942 Length: >= 49 944 Radio ID: An 8-bit value representing the radio. 946 WLAN ID: An 8-bit value specifying the WLAN Identifier. 948 Capability: A 16-bit value containing the capabilities information 949 field to be advertised by the WTP in the Probe Request and Beacon 950 frames. 952 Key-Index: The Key Index associated with the key. 954 Key Status: A 1 byte value that specifies the state and usage of 955 the key that has been included. The following values describe the 956 key usage and its status: 958 0 - A value of zero, with the inclusion of the RSN Information 959 Element means that the WLAN uses per-station encryption keys, and 960 therefore the key in the 'Key' field is only used for multicast 961 traffic. 963 1 - When set to one, the WLAN employs a shared WEP key, also known 964 as a static WEP key, and uses the encryption key for both unicast 965 and multicast traffic for all stations. 967 2 - The value of 2 indicates that the AC will begin rekeying the GTK 968 with the STA's in the BSS. It is only valid when IEEE 802.11 is 969 enabled as the security policy for the BSS. 971 3 - The value of 3 indicates that the AC has completed rekeying the 972 GTK and broadcast packets no longer need to be duplicated and 973 transmitted with both GTK's. 975 Key Length: A 16-bit value representing the length of the Key 976 field. 978 Key: A 32 byte Session Key to use to provide data privacy. For 979 encryption schemes that employ a separate encryption key for 980 unicast and multicast traffic, the key included here only applies 981 to multicast frames, and the cipher suite is specified in an 982 accompanied RSN Information Element. In these scenarios, the key 983 and cipher information is communicated via the Add Station message 984 element, see Section 4.4.8 in [1] and the IEEE 802.11 Station 985 Session Key message element, see Section 6.15. 987 Group TSC A 48-bit value containing the Transmit Sequence Counter 988 for the updated group key. The WTP will set the TSC for 989 broadcast/multicast frames to this value for the updated group 990 key. 992 QOS: An 8-bit value specifying the default QoS policy to enforce 993 for station's traffic on this WLAN. 995 The following values are supported: 997 0 - Best Effort 999 1 - Video 1001 2 - Voice 1003 3 - Background 1005 Auth Type: An 8-bit value specifying the supported authentication 1006 type. 1008 The following values are supported: 1010 0 - Open System 1012 1 - WEP Shared Key 1014 2 - WPA/WPA2 802.1X 1016 3 - WPA/WPA2 PSK 1018 MAC Mode: This field specifies whether the WTP should support the 1019 WLAN in Local or Split MAC modes. Note that the AC MUST NOT 1020 request a mode of operation that was not advertised by the WTP 1021 during the discovery process (see Section 4.4.40 in [1]). The 1022 following values are supported: 1024 0 - Local-MAC: Service for the WLAN is to be provided in Local 1025 MAC mode. 1027 1 - Split-MAC: Service for the WLAN is to be provided in Split 1028 MAC mode. 1030 Tunnel Mode: This field specifies the frame tunneling type to be 1031 used for 802.11 data frames from all stations associated with the 1032 WLAN. The AC MUST NOT request a mode of operation that was not 1033 advertised by the WTP during the discovery process (see Section 1034 4.4.38 in [1]). IEEE 802.11 managment frames SHALL be tunneled 1035 using 802.11 Tunnel mode. The following values are supported: 1037 0 - Local Bridging: All user traffic is to be locally bridged. 1039 1 - 802.3 Tunnel: All user traffic is to be tunneled to the AC 1040 in 802.3 format (see Section 4.2 in [1]). 1042 2 - 802.11 Tunnel: All user traffic is to be tunneled to the AC 1043 in 802.11 format. 1045 Supress SSID: A boolean indicating whether the SSID is to be 1046 advertised by the WTP. A value of zero supresses the SSID in the 1047 802.11 Beacon and Probe Response frames, while a value of one will 1048 cause the WTP to populate the field. 1050 SSID: The SSID attribute is the service set identifier that will be 1051 advertised by the WTP for this WLAN. 1053 6.2. IEEE 802.11 Antenna 1055 The IEEE 802.11 Antenna message element is communicated by the WTP to 1056 the AC to provide information on the antennas available. The AC MAY 1057 use this element to reconfigure the WTP's antennas. The message 1058 element contains the following fields: 1060 0 1 2 3 1061 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 1062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1063 | Radio ID | Diversity | Combiner | Antenna Cnt | 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 | Antenna Selection [0..N] | 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 Type: 1025 for IEEE 802.11 Antenna 1070 Length: >= 5 1072 Radio ID: An 8-bit value representing the radio to configure. 1074 Diversity: An 8-bit value specifying whether the antenna is to 1075 provide receive diversity. The value of this field is the same as 1076 the IEEE 802.11 dot11DiversitySelectionRx MIB element, see [3]. 1077 The following values are supported: 1079 0 - Disabled 1081 1 - Enabled (may only be true if the antenna can be used as a 1082 receive antenna) 1084 Combiner: An 8-bit value specifying the combiner selection. The 1085 following values are supported: 1087 1 - Sectorized (Left) 1089 2 - Sectorized (Right) 1091 3 - Omni 1093 4 - MIMO 1095 Antenna Count: An 8-bit value specifying the number of Antenna 1096 Selection fields. This value should be the same as the one found 1097 in the IEEE 802.11 dot11CurrentTxAntenna MIB element (see [3]). 1099 Antenna Selection: One 8-bit antenna configuration value per 1100 antenna in the WTP. The following values are supported: 1102 1 - Internal Antenna 1104 2 - External Antenna 1106 6.3. IEEE 802.11 Assigned WTP BSSID 1108 The IEEE 802.11 Assigned WTP BSSID is only included by the WTP when 1109 the IEEE 802.11 WLAN Configuration Request included the IEEE 802.11 1110 Add WLAN message element. The BSSID value field of this message 1111 element contains the BSSID that has been assigned by the WTP, 1112 enabling the WTP to perform its own BSSID assignment. 1114 The WTP is free to assign the BSSIDs the way it sees fit, but it is 1115 highly recommended that the WTP assign the BSSID using the following 1116 algorithm: BSSID = {base BSSID} + WLAN ID. 1118 0 1 2 3 1119 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 1120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1121 | Radio ID | WLAN ID | BSSID 1122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1123 | BSSID | 1124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1126 Type: 1026 for IEEE 802.11 Assigned WTP BSSID 1128 Length: 6 1130 Radio ID: An 8-bit value representing the radio. 1132 WLAN ID: An 8-bit value specifying the WLAN Identifier. 1134 BSSID: The BSSID assigned by the WTP for the WLAN created as a 1135 result of receiving an IEEE 802.11 Add WLAN. 1137 6.4. IEEE 802.11 Delete WLAN 1139 The IEEE 802.11 Delete WLAN message element is used to inform the WTP 1140 that a previously created WLAN is to be deleted, and contains the 1141 following fields: 1143 0 1 1144 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1146 | Radio ID | WLAN ID | 1147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1149 Type: 1027 for IEEE 802.11 Delete WLAN 1151 Length: 3 1153 Radio ID: An 8-bit value representing the radio 1155 WLAN ID: An 8-bit value specifying the WLAN Identifier 1157 6.5. IEEE 802.11 Direct Sequence Control 1159 The IEEE 802.11 Direct Sequence Control message element is a bi- 1160 directional element. When sent by the WTP, it contains the current 1161 state. When sent by the AC, the WTP MUST adhere to the values 1162 provided. This element is only used for IEEE 802.11b radios. The 1163 message element has the following fields. 1165 0 1 2 3 1166 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 1167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1168 | Radio ID | Reserved | Current Chan | Current CCA | 1169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1170 | Energy Detect Threshold | 1171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1173 Type: 1028 for IEEE 802.11 Direct Sequence Control 1175 Length: 8 1176 Radio ID: An 8-bit value representing the radio to configure. 1178 Reserved: All implementations complying with this protocol MUST set 1179 to zero any bits that are reserved in the version of the protocol 1180 supported by that implementation. Receivers MUST ignore all bits 1181 not defined for the version of the protocol they support. 1183 Current Channel: This attribute contains the current operating 1184 frequency channel of the DSSS PHY. This value comes from the IEEE 1185 802.11 dot11CurrentChannel MIB element (see [3]). 1187 Current CCA: The current CCA method in operation, whose value can 1188 be found in the IEEE 802.11 dot11CCAModeSupported MIB element (see 1189 [3]). Valid values are: 1191 1 - energy detect only (edonly) 1193 2 - carrier sense only (csonly) 1195 4 - carrier sense and energy detect (edandcs) 1197 8 - carrier sense with timer (cswithtimer) 1199 16 - high rate carrier sense and energy detect (hrcsanded) 1201 Energy Detect Threshold: The current Energy Detect Threshold being 1202 used by the DSSS PHY. The value can be found in the IEEE 802.11 1203 dot11EDThreshold MIB element (see [3]). 1205 6.6. IEEE 802.11 Information Element 1207 The IEEE 802.11 Information Element is used to communicate any IE 1208 defined in the IEEE 802.11 protocol. The data field contains the raw 1209 IE as it would be included within an IEEE 802.11 MAC management 1210 message. 1212 0 1 2 3 1213 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 1214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1215 | Radio ID | WLAN ID |B|P| Flags |Info Element... 1216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1218 Type: 1029 for IEEE 802.11 Information Element 1220 Length: >= 2 1221 Radio ID: An 8-bit value representing the radio. 1223 WLAN ID: An 8-bit value specifying the WLAN Identifier. 1225 B: When set, the WTP is to include the information element in 1226 beacons associated with the WLAN. 1228 P: When set, the WTP is to include the information element in probe 1229 responses associated with the WLAN. 1231 Flags: All implementations complying with this protocol MUST set to 1232 zero any bits that are reserved in the version of the protocol 1233 supported by that implementation. Receivers MUST ignore all bits 1234 not defined for the version of the protocol they support. 1236 Info Element: The IEEE 802.11 Information Element, which includes 1237 the type, length and value field. 1239 6.7. IEEE 802.11 MAC Operation 1241 The IEEE 802.11 MAC Operation message element is sent by the AC to 1242 set the IEEE 802.11 MAC parameters on the WTP, and contains the 1243 following fields. 1245 0 1 2 3 1246 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 1247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1248 | Radio ID | Reserved | RTS Threshold | 1249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1250 | Short Retry | Long Retry | Fragmentation Threshold | 1251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1252 | Tx MSDU Lifetime | 1253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1254 | Rx MSDU Lifetime | 1255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1257 Type: 1030 for IEEE 802.11 MAC Operation 1259 Length: 16 1261 Radio ID: An 8-bit value representing the radio to configure. 1263 Reserved: All implementations complying with this protocol MUST set 1264 to zero any bits that are reserved in the version of the protocol 1265 supported by that implementation. Receivers MUST ignore all bits 1266 not defined for the version of the protocol they support. 1268 RTS Threshold: This attribute indicates the number of octets in an 1269 MPDU, below which an RTS/CTS handshake MUST NOT be performed. An 1270 RTS/CTS handshake MUST be performed at the beginning of any frame 1271 exchange sequence where the MPDU is of type Data or Management, 1272 the MPDU has an individual address in the Address1 field, and the 1273 length of the MPDU is greater than this threshold. Setting this 1274 attribute to be larger than the maximum MSDU size MUST have the 1275 effect of turning off the RTS/CTS handshake for frames of Data or 1276 Management type transmitted by this STA. Setting this attribute 1277 to zero MUST have the effect of turning on the RTS/CTS handshake 1278 for all frames of Data or Management type transmitted by this STA. 1279 The default value of this attribute MUST be 2347. The value of 1280 this field comes from the IEEE 802.11 dot11RTSThreshold MIB 1281 element, (see [3]). 1283 Short Retry: This attribute indicates the maximum number of 1284 transmission attempts of a frame, the length of which is less than 1285 or equal to RTSThreshold, that MUST be made before a failure 1286 condition is indicated. The default value of this attribute MUST 1287 be 7. The value of this field comes from the IEEE 802.11 1288 dot11ShortRetryLimit MIB element, (see [3]). 1290 Long Retry: This attribute indicates the maximum number of 1291 transmission attempts of a frame, the length of which is greater 1292 than dot11RTSThreshold, that MUST be made before a failure 1293 condition is indicated. The default value of this attribute MUST 1294 be 4. The value of this field comes from the IEEE 802.11 1295 dot11LongRetryLimit MIB element, (see [3]). 1297 Fragmentation Threshold: This attribute specifies the current 1298 maximum size, in octets, of the MPDU that MAY be delivered to the 1299 PHY. An MSDU MUST be broken into fragments if its size exceeds 1300 the value of this attribute after adding MAC headers and trailers. 1301 An MSDU or MMPDU MUST be fragmented when the resulting frame has 1302 an individual address in the Address1 field, and the length of the 1303 frame is larger than this threshold. The default value for this 1304 attribute MUST be the lesser of 2346 or the aMPDUMaxLength of the 1305 attached PHY and MUST never exceed the lesser of 2346 or the 1306 aMPDUMaxLength of the attached PHY. The value of this attribute 1307 MUST never be less than 256. The value of this field comes from 1308 the IEEE 802.11 dot11FragmentationThreshold MIB element, (see 1309 [3]). 1311 Tx MSDU Lifetime: This attribute speficies the elapsed time in TU, 1312 after the initial transmission of an MSDU, after which further 1313 attempts to transmit the MSDU MUST be terminated. The default 1314 value of this attribute MUST be 512. The value of this field 1315 comes from the IEEE 802.11 dot11MaxTransmitMSDULifetime MIB 1316 element, (see [3]). 1318 Rx MSDU Lifetime: This attribute specifies the elapsed time in TU, 1319 after the initial reception of a fragmented MMPDU or MSDU, after 1320 which further attempts to reassemble the MMPDU or MSDU MUST be 1321 terminated. The default value MUST be 512. The value of this 1322 field comes from the IEEE 802.11 dot11MaxReceiveLifetime MIB 1323 element, (see [3]). 1325 6.8. IEEE 802.11 MIC Countermeasures 1327 The IEEE 802.11 MIC Countermeasures message element is sent by the 1328 WTP to the AC to indicate the occurrence of a MIC failure. For more 1329 information on MIC failure events, see the 1330 dot11RSNATKIPCounterMeasuresInvoked MIB element definition in [3]. 1332 0 1 2 3 1333 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 1334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1335 | Radio ID | WLAN ID | MAC Address | 1336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1337 | MAC Address | 1338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1340 Type: 1031 for IEEE 802.11 MIC Countermeasures 1342 Length: 8 1344 Radio ID: The Radio Identifier, typically refers to some interface 1345 index on the WTP. 1347 WLAN ID: This 8-bit unsigned integer includes the WLAN Identifier, 1348 on which the MIC failure occurred. 1350 MAC Address: The MAC Address of the station that caused the MIC 1351 failure. 1353 6.9. IEEE 802.11 Multi-Domain Capability 1355 The IEEE 802.11 Multi-Domain Capability message element is used by 1356 the AC to inform the WTP of regulatory limits. The AC will transmit 1357 one message element per frequency band to indicate the regulatory 1358 constraints in that domain. The message element contains the 1359 following fields. 1361 0 1 2 3 1362 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 1363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1364 | Radio ID | Reserved | First Channel # | 1365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1366 | Number of Channels | Max Tx Power Level | 1367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1369 Type: 1032 for IEEE 802.11 Multi-Domain Capability 1371 Length: 8 1373 Radio ID: An 8-bit value representing the radio to configure. 1375 Reserved: All implementations complying with this protocol MUST set 1376 to zero any bits that are reserved in the version of the protocol 1377 supported by that implementation. Receivers MUST ignore all bits 1378 not defined for the version of the protocol they support. 1380 First Channnel #: This attribute indicates the value of the lowest 1381 channel number in the subband for the associated domain country 1382 string. The value of this field comes from the IEEE 802.11 1383 dot11FirstChannelNumber MIB element (see [3]). 1385 Number of Channels: This attribute indicates the value of the total 1386 number of channels allowed in the subband for the associated 1387 domain country string. The value of this field comes from the 1388 IEEE 802.11 dot11NumberofChannels MIB element (see [3]). 1390 Max Tx Power Level: This attribute indicates the maximum transmit 1391 power, in dBm, allowed in the subband for the associated domain 1392 country string. The value of this field comes from the IEEE 1393 802.11 dot11MaximumTransmitPowerLevel MIB element (see [3]). 1395 6.10. IEEE 802.11 OFDM Control 1397 The IEEE 802.11 OFDM Control message element is a bi-directional 1398 element. When sent by the WTP, it contains the current state. When 1399 sent by the AC, the WTP MUST adhere to the received values. This 1400 message element is only used for 802.11a radios and contains the 1401 following fields: 1403 0 1 2 3 1404 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 1405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1406 | Radio ID | Reserved | Current Chan | Band Support | 1407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1408 | TI Threshold | 1409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1411 Type: 1033 for IEEE 802.11 OFDM Control 1413 Length: 8 1415 Radio ID: An 8-bit value representing the radio to configure. 1417 Reserved: All implementations complying with this protocol MUST set 1418 to zero any bits that are reserved in the version of the protocol 1419 supported by that implementation. Receivers MUST ignore all bits 1420 not defined for the version of the protocol they support. 1422 Current Channel: This attribute contains the current operating 1423 frequency channel of the OFDM PHY. The value of this field comes 1424 from the IEEE 802.11 dot11CurrentFrequency MIB element (see [3]). 1426 Band Supported: The capability of the OFDM PHY implementation to 1427 operate in the three U-NII bands. The value of this field comes 1428 from the IEEE 802.11 dot11FrequencyBandsSupported MIB element (see 1429 [3]), coded as an integer value of a three bit field as follows: 1431 Bit 0 - capable of operating in the lower (5.15-5.25 GHz) U-NII 1432 band 1434 Bit 1 - capable of operating in the middle (5.25-5.35 GHz) U-NII 1435 band 1437 Bit 2 - capable of operating in the upper (5.725-5.825 GHz) U-NII 1438 band 1440 For example, for an implementation capable of operating in the 1441 lower and mid bands this attribute would take the value 3. 1443 TI Threshold: The Threshold being used to detect a busy medium 1444 (frequency). CCA MUST report a busy medium upon detecting the 1445 RSSI above this threshold. The value of this field comes from the 1446 IEEE 802.11 dot11TIThreshold MIB element (see [3]). 1448 6.11. IEEE 802.11 Rate Set 1450 The rate set message element value is sent by the AC and contains the 1451 supported operational rates. It contains the following fields. 1453 0 1 2 3 1454 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 1455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1456 | Radio ID | Rate Set... 1458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1460 Type: 1034 for IEEE 802.11 Rate Set 1462 Length: >= 3 1464 Radio ID: An 8-bit value representing the radio to configure. 1466 Rate Set: The AC generates the Rate Set that the WTP is to include 1467 in it's Beacon and Probe messages. The length of this field is 1468 between 2 and 8 bytes. The value of this field comes from the 1469 IEEE 802.11 dot11OperationalRateSet MIB element (see [3]). 1471 6.12. IEEE 802.11 RSNA Error Report From Station 1473 The IEEE 802.11 RSN Error Report From Station message element is sent 1474 by an AC to an WTP to send RSN error reports to the AC. The WTP does 1475 not need to transmit any reports that do not include any failures. 1476 The fields from this message element come from the IEEE 802.11 1477 Dot11RSNAStatsEntry table, see [3]. 1479 0 1 2 3 1480 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 1481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1482 | Client MAC Address | 1483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1484 | Client MAC Address | BSSID | 1485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1486 | BSSID | 1487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1488 | Radio ID | WLAN ID | Reserved | 1489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1490 | TKIP ICV Errors | 1491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1492 | TKIP Local MIC Failures | 1493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1494 | TKIP Remote MIC Failures | 1495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1496 | CCMP Replays | 1497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1498 | CCMP Decrypt Errors | 1499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1500 | TKIP Replays | 1501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1503 Type: 1035 for IEEE 802.11 RSNA Error Report From Station 1505 Length: 14 1507 Client MAC Address: The Client MAC Address of the station. 1509 BSSID: The BSSID on which the failures are being reported on. 1511 Radio ID: The Radio Identifier, typically refers to some interface 1512 index on the WTP 1514 WLAN ID: The WLAN ID on which the RSNA failures are being reported. 1516 Reserved: All implementations complying with this protocol MUST set 1517 to zero any bits that are reserved in the version of the protocol 1518 supported by that implementation. Receivers MUST ignore all bits 1519 not defined for the version of the protocol they support. 1521 TKIP ICV Errors: A 32-bit value representing the number of TKIP ICV 1522 errors encountered when decrypting packets from the station. The 1523 value of this field comes from the IEEE 802.11 1524 dot11RSNAStatsTKIPICVErrors MIB element (see [3]). 1526 TKIP Local MIC Failures: A 32-bit value representing the number of 1527 MIC failures encountered when checking the integrity of packets 1528 received from the station. The value of this field comes from the 1529 IEEE 802.11 dot11RSNAStatsTKIPLocalMICFailures MIB element (see 1530 [3]). 1532 TKIP Remote MIC Failures: A 32-bit value representing the number of 1533 MIC failures reported by the station encountered (possibly via the 1534 EAPOL-Key frame). The value of this field comes from the IEEE 1535 802.11 dot11RSNAStatsTKIPRemoteMICFailures MIB element (see [3]). 1537 CCMP Replays: A 32-bit value representing the number of CCMP MPDUs 1538 discarded by the replay detection mechanism. The value of this 1539 field comes from the IEEE 802.11 dot11RSNACCMPReplays MIB element 1540 (see [3]). 1542 CCMP Decrypt Errors: A 32-bit value representing the number of CCMP 1543 MDPUs discarded by the decryption algorithm. The value of this 1544 field comes from the IEEE 802.11 dot11RSNACCMPDecryptErrors MIB 1545 element (see [3]). 1547 TKIP Replays: A 32-bit value representing the number of TKIP 1548 Replays detected in frames received from the station. The value 1549 of this field comes from the IEEE 802.11 dot11RSNAStatsTKIPReplays 1550 MIB element (see [3]). 1552 6.13. IEEE 802.11 Station 1554 The IEEE 802.11 Station message element accompanies the Add Station 1555 message element, and is used to deliver IEEE 802.11 station policy 1556 from the AC to the WTP. 1558 The latest IEEE 802.11 Station message element overrides any 1559 previously received message elements. 1561 If the QoS field is set, the WTP MUST observe and provide policing of 1562 the 802.11e priority tag to ensure that it does not exceed the value 1563 provided by the AC. 1565 0 1 2 3 1566 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 1567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1568 | Radio ID | Association ID | Flags | 1569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1570 | MAC Address | 1571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1572 | MAC Address | Capabilities | 1573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1574 | WLAN ID |Supported Rates| 1575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1577 Type: 1036 for IEEE 802.11 Station 1579 Length: >= 8 1581 Radio ID: An 8-bit value representing the radio 1583 Association ID: A 16-bit value specifying the IEEE 802.11 1584 Association Identifier 1586 Flags: All implementations complying with this protocol MUST set to 1587 zero any bits that are reserved in the version of the protocol 1588 supported by that implementation. Receivers MUST ignore all bits 1589 not defined for the version of the protocol they support. 1591 MAC Address: The station's MAC Address 1593 Capabilities: A 16-bit field containing the IEEE 802.11 1594 Capabilities Information Field to use with the station. 1596 WLAN ID: An 8-bit value specifying the WLAN Identifier 1597 Supported Rates: The variable length field containing the supported 1598 rates to be used with the station, as found in the IEEE 802.11 1599 dot11OperationalRateSet MIB element (see [3]). 1601 6.14. IEEE 802.11 Station QoS Profile 1603 The IEEE 802.11 Station QoS Profile message element contains the 1604 maximum IEEE 802.11e priority tag that may be used by the station. 1605 Any packet received that exceeds the value encoded in this message 1606 element must either be dropped or tagged using the maximum value 1607 permitted by to the user. The priority tag must be between zero (0) 1608 and seven (7). 1610 0 1 2 3 1611 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 1612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1613 | MAC Address | 1614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1615 | MAC Address | 802.1P Precedence Tag | 1616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1618 Type: 1037 for IEEE 802.11 Station QOS Profile 1620 Length: 8 1622 MAC Address: The station's MAC Address 1624 802.1P Precedence Tag: The maximum 802.1P precedence value that the 1625 WTP will allow in the TID field in the extended 802.11e QOS Data 1626 header. 1628 6.15. IEEE 802.11 Station Session Key 1630 The IEEE 802.11 Station Session Key message element is sent when the 1631 AC determines that encryption of a station must be performed in the 1632 WTP. This message element MUST NOT be present without the IEEE 1633 802.11 Station (see Section 6.13) message element, and MUST NOT be 1634 sent if the WTP had not specifically advertised support for the 1635 requested encryption scheme. 1637 The RSN information element MUST sent along with the IEEE 802.11 1638 Station Session Key in order to instruct the WTP on the usage of the 1639 Key field. The AKM field of the RSM information element is used by 1640 the WTP to identify the authentication protocol. 1642 If the IEEE 802.11 Station Session Key message element's AKM-Only bit 1643 is set, the WTP MUST drop all IEEE 802.11 packets that are not part 1644 of the AKM (e.g., EAP). Note that AKM-Only is MAY be set while an 1645 encryption key is in force, requiring that the AKM packets be 1646 encrypted. Once the station has successfully completed 1647 authentication via the AKM, the AC must send a new Add Station 1648 message element to remove the AKM-Only restriction, and optionally 1649 push the session key down to the WTP. 1651 0 1 2 3 1652 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 1653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1654 | MAC Address | 1655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1656 | MAC Address |A|C| Flags | 1657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1658 | Pairwise TSC | 1659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1660 | Pairwise TSC | Pairwise RSC | 1661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1662 | Pairwise RSC | 1663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1664 | Key... 1665 +-+-+-+-+-+-+-+- 1667 Type: 1038 for IEEE 802.11 Station Session Key 1669 Length: >= 25 1671 MAC Address: The station's MAC Address 1673 Flags: All implementations complying with this protocol MUST set to 1674 zero any bits that are reserved in the version of the protocol 1675 supported by that implementation. Receivers MUST ignore all bits 1676 not defined for the version of the protocol they support. The 1677 following bits are defined: 1679 A: The one bit AKM-Only field is set by the AC to inform the WTP 1680 that is MUST NOT accept any 802.11 data frames, other than AKM 1681 frames. This is the equivalent of the WTP's IEEE 802.1X port 1682 for the station to be in the closed state. When set, the WTP 1683 MUST drop any non-IEEE 802.1X packets it receives from the 1684 station. 1686 C: The one bit field is set by the AC to inform the WTP that 1687 encryption services will be provided by the AC. When set, the 1688 WTP SHOULD police frames received from stations to ensure that 1689 are properly encrypted as specified in the RSN Information 1690 Element, but does not need to take specific cryptographic 1691 action on the frame. Similarly, for transmitted frames, the 1692 WTP only needs to forward already encrypted frames. 1694 Pairwise TSC: The 6 byte Transmit Sequence Counter (TSC) field to 1695 use for unicast packets transmitted to the station. 1697 Pairwise RSC: The 6 byte Receive Sequence Counter (RSC) to use for 1698 unicast packets received from the station. 1700 Key: The key the WTP is to use when encrypting traffic to/from the 1701 station. For dynamically created keys, this is commonly known as 1702 a Pairwise Transient Key (PTK). 1704 6.16. IEEE 802.11 Statistics 1706 The IEEE 802.11 Statistics message element is sent by the WTP to 1707 transmit its current statistics, and contains the following fields. 1709 0 1 2 3 1710 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 1711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1712 | Radio ID | Reserved | 1713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1714 | Tx Fragment Count | 1715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1716 | Multicast Tx Count | 1717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1718 | Failed Count | 1719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1720 | Retry Count | 1721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1722 | Multiple Retry Count | 1723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1724 | Frame Duplicate Count | 1725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1726 | RTS Success Count | 1727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1728 | RTS Failure Count | 1729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1730 | ACK Failure Count | 1731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1732 | Rx Fragment Count | 1733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1734 | Multicast RX Count | 1735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1736 | FCS Error Count | 1737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1738 | Tx Frame Count | 1739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1740 | Decryption Errors | 1741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1742 | Discarded QoS Fragment Count | 1743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1744 | Associated Station Count | 1745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1746 | QoS CF Polls Received Count | 1747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1748 | QoS CF Polls Unused Count | 1749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1750 | QoS CF Polls Unusable Count | 1751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1753 Type: 1039 for IEEE 802.11 Statistics 1755 Length: 60 1757 Radio ID: An 8-bit value representing the radio. 1759 Reserved: All implementations complying with this protocol MUST set 1760 to zero any bits that are reserved in the version of the protocol 1761 supported by that implementation. Receivers MUST ignore all bits 1762 not defined for the version of the protocol they support. 1764 Tx Fragment Count: A 32-bit value representing the number of 1765 fragmented frames transmitted. The value of this field comes from 1766 the IEEE 802.11 dot11TransmittedFragmentCount MIB element (see 1767 [3]). 1769 Multicast Tx Count: A 32-bit value representing the number of 1770 multicast frames transmitted. The value of this field comes from 1771 the IEEE 802.11 dot11MulticastTransmittedFrameCount MIB element 1772 (see [3]). 1774 Failed Count: A 32-bit value representing the transmit excessive 1775 retries. The value of this field comes from the IEEE 802.11 1776 dot11FailedCount MIB element (see [3]). 1778 Retry Count: A 32-bit value representing the number of transmit 1779 retries. The value of this field comes from the IEEE 802.11 1780 dot11RetryCount MIB element (see [3]). 1782 Multiple Retry Count: A 32-bit value representing the number of 1783 transmits that required more than one retry. The value of this 1784 field comes from the IEEE 802.11 dot11MultipleRetryCount MIB 1785 element (see [3]). 1787 Frame Duplicate Count: A 32-bit value representing the duplicate 1788 frames received. The value of this field comes from the IEEE 1789 802.11 dot11FrameDuplicateCount MIB element (see [3]). 1791 RTS Success Count: A 32-bit value representing the number of 1792 successfully transmitted Ready To Send (RTS). The value of this 1793 field comes from the IEEE 802.11 dot11RTSSuccessCount MIB element 1794 (see [3]). 1796 RTS Failure Count: A 32-bit value representing the failed 1797 transmitted RTS. The value of this field comes from the IEEE 1798 802.11 dot11RTSFailureCount MIB element (see [3]). 1800 ACK Failure Count: A 32-bit value representing the number of failed 1801 acknowledgements. The value of this field comes from the IEEE 1802 802.11 dot11ACKFailureCount MIB element (see [3]). 1804 Rx Fragment Count: A 32-bit value representing the number of 1805 fragmented frames received. The value of this field comes from 1806 the IEEE 802.11 dot11ReceivedFragmentCount MIB element (see [3]). 1808 Multicast RX Count: A 32-bit value representing the number of 1809 multicast frames received. The value of this field comes from the 1810 IEEE 802.11 dot11MulticastReceivedFrameCount MIB element (see 1811 [3]). 1813 FCS Error Count: A 32-bit value representing the number of FCS 1814 failures. The value of this field comes from the IEEE 802.11 1815 dot11FCSErrorCount MIB element (see [3]). 1817 Decryption Errors: A 32-bit value representing the number of 1818 Decryption errors that occurred on the WTP. Note that this field 1819 is only valid in cases where the WTP provides encryption/ 1820 decryption services. The value of this field comes from the IEEE 1821 802.11 dot11WEPUndecryptableCount MIB element (see [3]). 1823 Discarded QoS Fragment Count: A 32-bit value representing the 1824 number of discarded QoS fragments received. The value of this 1825 field comes from the IEEE 802.11 dot11QoSDiscardedFragmentCount 1826 MIB element (see [3]). 1828 Associated Station Count: A 32-bit value representing the number of 1829 number of associated stations. The value of this field comes from 1830 the IEEE 802.11 dot11AssociatedStationCount MIB element (see [3]). 1832 QoS CF Polls Received Count: A 32-bit value representing the number 1833 of (+)CF-Polls received. The value of this field comes from the 1834 IEEE 802.11 dot11QosCFPollsReceivedCount MIB element (see [3]). 1836 QoS CF Polls Unused Count: A 32-bit value representing the number 1837 of (+)CF-Polls that have been received, but not used. The value 1838 of this field comes from the IEEE 802.11 1839 dot11QosCFPollsUnusedCount MIB element (see [3]). 1841 QoS CF Polls Unusable Count: A 32-bit value representing the number 1842 of (+)CF-Polls that have been received, but could not be used due 1843 to the TXOP size being smaller than the timethat is required for 1844 one frame exchange sequence. The value of this field comes from 1845 the IEEE 802.11 dot11QosCFPollsUnusableCount MIB element (see 1846 [3]). 1848 6.17. IEEE 802.11 Supported Rates 1850 The IEEE 802.11 Supported Rates message element is sent by the WTP to 1851 indicate the rates that it supports, and contains the following 1852 fields. 1854 0 1 2 3 1855 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 1856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1857 | Radio ID | Supported Rates... 1858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1860 Type: 1040 for IEEE 802.11 Supported Rates 1862 Length: >= 3 1864 Radio ID: An 8-bit value representing the radio. 1866 Supported Rates: The WTP includes the Supported Rates that its 1867 hardware supports. The format is identical to the Rate Set 1868 message element and is between 2 and 8 bytes in length. 1870 6.18. IEEE 802.11 Tx Power 1872 The IEEE 802.11 Tx Power message element value is bi-directional. 1873 When sent by the WTP, it contains the current power level of the 1874 radio in question. When sent by the AC, it contains the power level 1875 the WTP MUST adhere to. 1877 0 1 2 3 1878 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1880 | Radio ID | Reserved | Current Tx Power | 1881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1883 Type: 1041 for IEEE 802.11 Tx Power 1885 Length: 4 1887 Radio ID: An 8-bit value representing the radio to configure. 1889 Reserved: All implementations complying with this protocol MUST set 1890 to zero any bits that are reserved in the version of the protocol 1891 supported by that implementation. Receivers MUST ignore all bits 1892 not defined for the version of the protocol they support. 1894 Current Tx Power: This attribute contains the current transmit 1895 output power in mW, as described in the dot11CurrentTxPowerLevel 1896 MIB variable, see [3]. 1898 6.19. IEEE 802.11 Tx Power Level 1900 The IEEE 802.11 Tx Power Level message element is sent by the WTP and 1901 contains the different power levels supported. The values found in 1902 this message element are found in the IEEE 802.11 1903 Dot11PhyTxPowerEntry MIB table, see [3]. 1905 The value field contains the following: 1907 0 1 2 3 1908 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1910 | Radio ID | Num Levels | Power Level [n] | 1911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1913 Type: 1042 for IEEE 802.11 Tx Power Level 1915 Length: >= 4 1917 Radio ID: An 8-bit value representing the radio to configure. 1919 Num Levels: The number of power level attributes. The value of 1920 this field comes from the IEEE 802.11 1921 dot11NumberSupportedPowerLevels MIB element (see [3]). 1923 Power Level: Each power level fields contains a supported power 1924 level, in mW. The value of this field comes from the 1925 corresponding IEEE 802.11 dot11TxPowerLevel[n] MIB element, see 1926 [3]. 1928 6.20. IEEE 802.11 Update Station QoS 1930 The IEEE 802.11 Update Station QoS message element is used to change 1931 the Quality of Service policy on the WTP for a given station. 1933 0 1 2 3 1934 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 1935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1936 | Radio ID | MAC Address | 1937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1938 | MAC Address | DSCP Tag | 802.1P Tag | 1939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1941 Type: 1043 for IEEE 802.11 Update Station QoS 1943 Length: 8 1945 Radio ID: The Radio Identifier, typically refers to some interface 1946 index on the WTP 1948 MAC Address: The station's MAC Address. 1950 DSCP Tag: The DSCP label to use if packets are to be DSCP tagged. 1952 802.1P Tag: The 802.1P precedence value to use if packets are to be 1953 IEEE 802.1P tagged. 1955 6.21. IEEE 802.11 Update WLAN 1957 The IEEE 802.11 Update WLAN message element is used by the AC to 1958 define a wireless LAN on the WTP. The inclusion of this message 1959 element MUST also include the IEEE 802.11 Information Element message 1960 element, containing the following 802.11 IEs: 1962 Power Capability information element 1964 WPA information element 1966 RSN information element 1968 EDCA Parameter Set information element 1970 QoS Capability information element 1972 WMM information element 1974 The message element uses the following format: 1976 0 1 2 3 1977 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 1978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1979 | Radio ID | WLAN ID | Capability | 1980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1981 | Key Index | Key Status | Key Length | 1982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1983 | Key... | 1984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1986 Type: 1044 for IEEE 802.11 Update WLAN 1988 Length: 43 1990 Radio ID: An 8-bit value representing the radio. 1992 WLAN ID: An 8-bit value specifying the WLAN Identifier. 1994 Capability: A 16-bit value containing the capabilities information 1995 field to be advertised by the WTP within the Probe and Beacon 1996 messages. 1998 Key-Index: The Key Index associated with the key. 2000 Key Status: A 1 byte value that specifies the state and usage of 2001 the key that has been included. The following values describe the 2002 key usage and its status: 2004 0 - A value of zero, with the inclusion of the RSN Information 2005 Element means that the WLAN uses per-station encryption keys, and 2006 therefore the key in the 'Key' field is only used for multicast 2007 traffic. 2009 1 - When set to one, the WLAN employs a shared WEP key, also known 2010 as a static WEP key, and uses the encryption key for both unicast 2011 and multicast traffic for all stations. 2013 2 - The value of 2 indicates that the AC will begin rekeying the GTK 2014 with the STA's in the BSS. It is only valid when IEEE 802.11 is 2015 enabled as the security policy for the BSS. 2017 3 - The value of 3 indicates that the AC has completed rekeying the 2018 GTK and broadcast packets no longer need to be duplicated and 2019 transmitted with both GTK's. 2021 Key Length: A 16-bit value representing the length of the Key 2022 field. 2024 Key: A 32 byte Session Key to use to provide data privacy. For 2025 static WEP keys, which is true when the 'Key Status' bit is set to 2026 one, this key is used for both unicast and multicast traffic. For 2027 encryption schemes that employ a separate encryption key for 2028 unicast and multicast traffic, the key included hereonly applies 2029 to multicast data, and the cipher suite is specified in an 2030 accompanied RSN Information Element. In these scenarios, the key, 2031 and cipher information, is communicated via the Add Station 2032 message element, see [1]. 2034 6.22. IEEE 802.11 WTP Quality of Service 2036 The IEEE 802.11 WTP Quality of Service message element value is sent 2037 by the AC to the WTP to communicate quality of service configuration 2038 information. 2040 0 1 2041 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2043 | Radio ID | Tag Packets | 2044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2046 Type: 1045 for IEEE 802.11 WTP Quality of Service 2048 Length: >= 2 2050 Radio ID: The Radio Identifier, typically refers to some interface 2051 index on the WTP 2053 Tag Packets: An value indicating whether CAPWAP packets should be 2054 tagged with for QoS purposes. The following values are currently 2055 supported: 2057 0 - Untagged 2059 1 - 802.1P 2061 2 - DSCP 2063 Immediately following the above header is the following data 2064 structure. This data structure will be repeated five times; once 2065 for every QoS profile. The order of the QoS profiles are Voice, 2066 Video, Best Effort and Background. 2068 0 1 2 3 2069 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 2070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2071 | Queue Depth | CWMin | CWMax | 2072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2073 | CWMax | AIFS | Dot1P Tag | DSCP Tag | 2074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2076 Queue Depth: The number of packets that can be on the specific QoS 2077 transmit queue at any given time. 2079 CWMin: The Contention Window minimum value for the QoS transmit 2080 queue. The value of this field comes from the IEEE 802.11 2081 dot11EDCATableCWMin MIB element (see [3]). 2083 CWMax: The Contention Window maximum value for the QoS transmit 2084 queue. The value of this field comes from the IEEE 802.11 2085 dot11EDCATableCWMax MIB element (see [3]). 2087 AIFS: The Arbitration Inter Frame Spacing to use for the QoS 2088 transmit queue. The value of this field comes from the IEEE 2089 802.11 dot11EDCATableAIFSN MIB element (see [3]). 2091 Dot1P Tag: The 802.1P precedence value to use if packets are to be 2092 802.1P tagged. 2094 DSCP Tag: The DSCP label to use if packets are to be DSCP tagged. 2096 6.23. IEEE 802.11 WTP Radio Configuration 2098 The IEEE 802.11 WTP WLAN Radio Configuration message element is used 2099 by the AC to configure a Radio on the WTP, and by the WTP to deliver 2100 its radio configuration to the AC. The message element value 2101 contains the following fields: 2103 0 1 2 3 2104 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 2105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2106 | Radio ID |Short Preamble| Num of BSSIDs | DTIM Period | 2107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2108 | BSSID | 2109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2110 | BSSID | Beacon Period | 2111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2112 | Country Code | 2113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2115 Type: 1046 for IEEE 802.11 WTP WLAN Radio Configuration 2117 Length: 16 2119 Radio ID: An 8-bit value representing the radio to configure. 2121 Short Preamble: An 8-bit value indicating whether short preamble is 2122 supported. The following values are currently supported: 2124 0 - Short preamble not supported. 2126 1 - Short preamble is supported. 2128 BSSID: The WLAN Radio's base MAC Address. 2130 Number of BSSIDs: This attribute contains the maximum number of 2131 BSSIDs supported by the WTP. This value restricts the number of 2132 logical networks supported by the WTP, and is between 1 and 16. 2134 DTIM Period: This attribute specifies the number of beacon 2135 intervals that elapse between transmission of Beacons frames 2136 containing a TIM element whose DTIM Count field is 0. This value 2137 is transmitted in the DTIM Period field of Beacon frames. The 2138 value of this field comes from the IEEE 802.11 dot11DTIMPeriod MIB 2139 element (see [3]). 2141 Beacon Period: This attribute specifies the number of TU that a 2142 station uses for scheduling Beacon transmissions. This value is 2143 transmitted in Beacon and Probe Response frames. The value of 2144 this field comes from the IEEE 802.11 dot11BeaconPeriod MIB 2145 element (see [3]). 2147 Country Code: This attribute identifies the country in which the 2148 station is operating. The value of this field comes from the IEEE 2149 802.11 dot11CountryString MIB element (see [3]). Special 2150 attention is required with use of this field, as implementations 2151 which take action based on this field could violate regulatory 2152 requirements. Some regulatory bodies do permit configuration of 2153 the country code under certain restrictions, such as the FCC, when 2154 WTPs are certified as Software Defined Radios. 2156 The WTP and AC may ignore the value of this field, depending upon 2157 regulatory requirements, for example to avoid classification as a 2158 Software Defined Radio. When this field is used, the first two 2159 octets of this string is the two character country code as 2160 described in document ISO/IEC 3166- 1, and the third octet MUST 2161 have the value 1, 2 or 3 as defined below. When the value of the 2162 third octet is 255, the country code field is not used, and MUST 2163 be ignored. 2165 1 an ASCII space character, if the regulations under which the 2166 station is operating encompass all environments in the country, 2168 2 an ASCII 'O' character, if the regulations under which the 2169 station is operating are for an outdoor environment only, or 2171 3 an ASCII 'I' character, if the regulations under which the 2172 station is operating are for an indoor environment only 2174 255 Country Code field is not used; ignore the field. 2176 6.24. IEEE 802.11 WTP Radio Fail Alarm Indication 2178 The IEEE 802.11 WTP Radio Fail Alarm Indication message element is 2179 sent by the WTP to the AC when it detects a radio failure. 2181 0 1 2 3 2182 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 2183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2184 | Radio ID | Type | Status | Pad | 2185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2187 Type: 1047 for IEEE 802.11 WTP Radio Fail Alarm Indication 2189 Length: 4 2191 Radio ID: The Radio Identifier, typically refers to some interface 2192 index on the WTP 2194 Type: The type of radio failure detected. The following values are 2195 supported: 2197 1 - Receiver 2199 2 - Transmitter 2201 Status: An 8-bit boolean indicating whether the radio failure is 2202 being reported or cleared. A value of zero is used to clear the 2203 event, while a value of one is used to report the event. 2205 Pad: All implementations complying with version zero of this 2206 protocol MUST set these bits to zero. Receivers MUST ignore all 2207 bits not defined for the version of the protocol they support. 2209 6.25. IEEE 802.11 WTP Radio Information 2211 The IEEE 802.11 WTP Radio Information message element is used to 2212 communicate the radio information for each IEEE 802.11 radio in the 2213 WTP. The Discovery Request message, Primary Discovery Request 2214 message and Join Request message MUST include one such message 2215 element per radio in the WTP. The Radio-Type field is used by the AC 2216 in order to determine which IEEE 802.11 technology specific binding 2217 is to be used with the WTP. 2219 The message element contains two fields, as shown below. 2221 0 1 2 3 2222 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 2223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2224 | Radio ID | Radio Type | 2225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2226 | Radio Type | 2227 +-+-+-+-+-+-+-+-+ 2229 Type: 1048 for IEEE 802.11 WTP Radio Information 2231 Length: 5 2233 Radio ID: The Radio Identifier, which typically refers to an 2234 interface index on the WTP 2236 Radio Type: The type of radio present. Note this bitfield can be 2237 used to specify support for more than a single type of PHY/MAC. 2238 The following values are supported: 2240 1 - 802.11b: An IEEE 802.11b radio. 2242 2 - 802.11a: An IEEE 802.11a radio. 2244 4 - 802.11g: An IEEE 802.11g radio. 2246 8 - 802.11n: An IEEE 802.11n radio. 2248 0xOF - 802.11b, 802.11a, 802.11g and 802.11n: The 4 radio types 2249 indicated are supported in the WTP. 2251 7. IEEE 802.11 Binding WTP Saved Variables 2253 This section contains the IEEE 802.11 binding specific variables that 2254 SHOULD be saved in non-volatile memory on the WTP. 2256 7.1. IEEE80211AntennaInfo 2258 The WTP per radio antenna configuration, defined in Section 6.2. 2260 7.2. IEEE80211DSControl 2262 The WTP per radio Direct Sequence Control configuration, defined in 2263 Section 6.5. 2265 7.3. IEEE80211MACOperation 2267 The WTP per radio MAC Operation configuration, defined in 2268 Section 6.7. 2270 7.4. IEEE80211OFDMControl 2272 The WTP per radio MAC Operation configuration, defined in 2273 Section 6.10. 2275 7.5. IEEE80211Rateset 2277 The WTP per radio Basic Rate Set configuration, defined in 2278 Section 6.11. 2280 7.6. IEEE80211TxPower 2282 The WTP per radio Transmit Power configuration, defined in 2283 Section 6.18. 2285 7.7. IEEE80211QoS 2287 The WTP per radio Quality of Service configuration, defined in 2288 Section 6.22. 2290 7.8. IEEE80211RadioConfig 2292 The WTP per radio Radio Configuration, defined in Section 6.23. 2294 8. Technology Specific Message Element Values 2296 This section lists IEEE 802.11 specific values for the generic CAPWAP 2297 message elements which include fields whose values are technology 2298 specific. 2300 IEEE 802.11 uses the following values: 2302 4 - Encrypt AES-CCMP 128: WTP supports AES-CCMP, as defined in [4]. 2304 5 - Encrypt TKIP-MIC: WTP supports TKIP and Michael, as defined in 2305 [11]. 2307 9. Security Considerations 2309 This section describes security considerations for using IEEE 802.11 2310 with the CAPWAP protocol. 2312 9.1. IEEE 802.11 Security 2314 When used with an IEEE 802.11 infrastructure with WEP encryption, the 2315 CAPWAP protocol does not add any new vulnerabilities. Derived 2316 session keys between the STA and WTP can be compromised, resulting in 2317 many well-documented attacks. Implementors SHOULD discourage the use 2318 of WEP and encourage use of technically sound cryptographic solutions 2319 such as those in an IEEE 802.11 RSN. 2321 STA authentication is performed using IEEE 802.lX, and consequently 2322 EAP. Implementors SHOULD use EAP methods meeting the requirements 2323 specified [6]. 2325 10. IANA Considerations 2327 There are no IANA Considerations. 2329 11. References 2331 11.1. Normative References 2333 [1] "draft-ietf-capwap-protocol-specification-03". 2335 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2336 Levels", BCP 14, RFC 2119, March 1997. 2338 [3] "Information technology - Telecommunications and information 2339 exchange between systems - Local and metropolitan area networks 2340 - Specific requirements - Part 11: Wireless LAN Medium Access 2341 Control (MAC) and Physical Layer (PHY) specifications", 2342 IEEE Standard 802.11, 1999, 2343 . 2346 [4] "Information technology - Telecommunications and information 2347 exchange between systems - Local and metropolitan area networks 2348 - Specific requirements - Part 11: Wireless LAN Medium Access 2349 Control (MAC) and Physical Layer (PHY) specifications Amendment 2350 6: Medium Access Control (MAC) Security Enhancements", 2351 IEEE Standard 802.11i, July 2004, . 2354 [5] Aboba, B. and J. Wood, "Authentication, Authorization and 2355 Accounting (AAA) Transport Profile", RFC 3539, June 2003. 2357 [6] Stanley, D., Walker, J., and B. Aboba, "Extensible 2358 Authentication Protocol (EAP) Method Requirements for Wireless 2359 LANs", RFC 4017, March 2005. 2361 [7] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy for 2362 Control and Provisioning of Wireless Access Points (CAPWAP)", 2363 RFC 4118, June 2005. 2365 [8] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 2366 Protocol Version 1.1", RFC 4346, April 2006. 2368 [9] Manner, J. and M. Kojo, "Mobility Related Terminology", 2369 RFC 3753, June 2004. 2371 [10] Rescorla et al, E., "Datagram Transport Layer Security", 2372 June 2004. 2374 11.2. Informational References 2376 [11] "WiFi Protected Access (WPA) rev 1.6", April 2003. 2378 Editors' Addresses 2380 Pat R. Calhoun 2381 Cisco Systems, Inc. 2382 170 West Tasman Drive 2383 San Jose, CA 95134 2385 Phone: +1 408-853-5269 2386 Email: pcalhoun@cisco.com 2388 Michael P. Montemurro 2389 Research In Motion 2390 5090 Commerce Blvd 2391 Mississauga, ON L4W 5M4 2392 Canada 2394 Phone: +1 905-629-4746 x4999 2395 Email: mmontemurro@rim.com 2397 Dorothy Stanley 2398 Aruba Networks 2399 1322 Crossman Ave 2400 Sunnyvale, CA 94089 2402 Phone: +1 630-363-1389 2403 Email: dstanley@arubanetworks.com 2405 Full Copyright Statement 2407 Copyright (C) The Internet Society (2006). 2409 This document is subject to the rights, licenses and restrictions 2410 contained in BCP 78, and except as set forth therein, the authors 2411 retain all their rights. 2413 This document and the information contained herein are provided on an 2414 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2415 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2416 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2417 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2418 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2419 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2421 Intellectual Property 2423 The IETF takes no position regarding the validity or scope of any 2424 Intellectual Property Rights or other rights that might be claimed to 2425 pertain to the implementation or use of the technology described in 2426 this document or the extent to which any license under such rights 2427 might or might not be available; nor does it represent that it has 2428 made any independent effort to identify any such rights. Information 2429 on the procedures with respect to rights in RFC documents can be 2430 found in BCP 78 and BCP 79. 2432 Copies of IPR disclosures made to the IETF Secretariat and any 2433 assurances of licenses to be made available, or the result of an 2434 attempt made to obtain a general license or permission for the use of 2435 such proprietary rights by implementers or users of this 2436 specification can be obtained from the IETF on-line IPR repository at 2437 http://www.ietf.org/ipr. 2439 The IETF invites any interested party to bring to its attention any 2440 copyrights, patents or patent applications, or other proprietary 2441 rights that may cover technology that may be required to implement 2442 this standard. Please address the information to the IETF at 2443 ietf-ipr@ietf.org. 2445 Acknowledgment 2447 Funding for the RFC Editor function is provided by the IETF 2448 Administrative Support Activity (IASA).