idnits 2.17.1 draft-ietf-capwap-protocol-binding-ieee80211-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2497. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2508. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2515. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2521. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of lines with control characters in the document. ** The abstract seems to contain references ([3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 11, 2007) is 6163 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '2' == Outdated reference: A later version (-15) exists of draft-ietf-capwap-protocol-specification-07 -- Possible downref: Non-RFC (?) normative reference: ref. '4' Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 9 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 Expires: December 13, 2007 M. Montemurro, Editor 5 Research In Motion 6 D. Stanley, Editor 7 Aruba Networks 8 June 11, 2007 10 CAPWAP Protocol Binding for IEEE 802.11 11 draft-ietf-capwap-protocol-binding-ieee80211-04 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 December 13, 2007. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 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 protocol. The CAPWAP 55 Protocol Specification is defined separately [3]. 57 1. Introduction 59 This specification defines the Control And Provisioning of Wireless 60 Access Points (CAPWAP) Protocol Binding Specification for use with 61 the IEEE 802.11 Wireless Local Area Network protocol. Use of CAPWAP 62 control message fields, new control messages and message elements are 63 defined. The minimum required definitions for a binding-specific 64 Statistics message element, Station message element, and WTP Radio 65 Information message element are included. 67 1.1. Goals 69 The goals for this CAPWAP protocol binding are listed below: 71 1. To centralize the authentication and policy enforcement functions 72 for an IEEE 802.11 wireless network. The AC may also provide 73 centralized bridging, forwarding, and encryption of user traffic. 74 Centralization of these functions will enable reduced cost and 75 higher efficiency by applying the capabilities of network 76 processing silicon to the wireless network, as in wired LANs. 78 2. To enable shifting of the higher level protocol processing from 79 the WTP. This leaves the time-critical applications of wireless 80 control and access in the WTP, making efficient use of the 81 computing power available in WTPs which are subject to severe cost 82 pressure. 84 The CAPWAP protocol binding extensions defined herein apply solely to 85 the interface between the WTP and the AC. Inter-AC and station-to-AC 86 communication are strictly outside the scope of this document. 88 1.2. Conventions used in this document 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in RFC 2119 [1]. 94 1.3. Terminology 96 Access Controller (AC): The network entity that provides WTP access 97 to the network infrastructure in the data plane, control plane, 98 management plane, or a combination therein. 100 Basic Service Set (BSS): A set of stations controlled by a single 101 coordination function. 103 Distribution: The service that, by using association information, 104 delivers medium access control (MAC) service data units (MSDUs) 105 within the distribution system (DS). 107 Distribution System Service (DSS): The set of services provided by 108 the distribution system (DS) that enable the medium access control 109 (MAC) layer to transport MAC service data units (MSDUs) between 110 stations that are not in direct communication with each other over a 111 single instance of the wireless medium (WM). These services include 112 the transport of MSDUs between the access points (APs) of basic 113 service sets (BSSs) within an extended service set (ESS), transport 114 of MSDUs between portals and BSSs within an ESS, and transport of 115 MSDUs between stations in the same BSS in cases where the MSDU has a 116 multicast or broadcast destination address, or where the destination 117 is an individual address, but the station sending the MSDU chooses to 118 involve the DSS. DSSs are provided between pairs of IEEE 802.11 119 MACs. 121 Integration: The service that enables delivery of medium access 122 control (MAC) service data units (MSDUs) between the distribution 123 system (DS) and an existing, non-IEEE 802.11 local area network (via 124 a portal). 126 Station (STA): A device that contains an IEEE 802.11 conformant 127 medium access control (MAC) and physical layer (PHY) interface to the 128 wireless medium (WM). 130 Portal: The logical point at which medium access control (MAC) 131 service data units (MSDUs) from a non-IEEE 802.11 local area network 132 (LAN) enter the distribution system (DS) of an extended service set 133 (ESS). 135 WLAN: In this document, WLAN refers to a logical component 136 instantiated on a WTP device. A single physical WTP may operate a 137 number of WLANs. Each Basic Service Set Identifier (BSSID) and its 138 constituent wireless terminal radios is denoted as a distinct WLAN on 139 a physical WTP. 141 Wireless Termination Point (WTP): The physical or network entity that 142 contains an IEEE 802.11 RF antenna and wireless PHY to transmit and 143 receive station traffic for wireless access networks. 145 2. IEEE 802.11 Binding 147 This section describes use of the CAPWAP protocol with the IEEE 148 802.11 Wireless Local Area Network protocol, including Local and 149 Split MAC operation, Group Key Refresh, BSSID to WLAN Mapping, IEEE 150 802.11 MAC management frame Quality of Service tagging and Run State 151 operation. 153 2.1. Split MAC and Local MAC Functionality 155 The CAPWAP protocol, when used with IEEE 802.11 devices, requires 156 specific behavior from the WTP and the AC to support the required 157 IEEE 802.11 protocol functions. 159 For both the Split and Local MAC approaches, the CAPWAP functions, as 160 defined in the taxonomy specification [6], reside in the AC. 162 To provide system component interoperability, the WTP and AC MUST 163 support 802.11 encryption/decryption at the WTP. The WTP and AC MAY 164 support 802.11 encryption/decryption at the AC. 166 2.1.1. Split MAC 168 This section shows the division of labor between the WTP and the AC 169 in a Split MAC architecture. Figure 1 shows the separation of 170 functionality between CAPWAP components. 172 Function Location 173 Distribution Service AC 174 Integration Service AC 175 Beacon Generation WTP 176 Probe Response Generation WTP 177 Power Mgmt/Packet Buffering WTP 178 Fragmentation/Defragmentation WTP/AC 179 Assoc/Disassoc/Reassoc AC 181 IEEE 802.11 QOS 182 Classifying AC 183 Scheduling WTP/AC 184 Queuing WTP 186 IEEE 802.11 RSN 187 IEEE 802.1X/EAP AC 188 RSNA Key Management AC 189 IEEE 802.11 Encryption/Decryption WTP/AC 191 Figure 1: Mapping of 802.11 Functions for Split MAC Architecture 193 In a Split MAC Architecture,the Distribution and Integration services 194 reside on the AC, and therefore all user data is tunneled between the 195 WTP and the AC. As noted above, all real-time IEEE 802.11 services, 196 including the Beacon and Probe Response frames, are handled on the 197 WTP. 199 All remaining IEEE 802.11 MAC management frames are supported on the 200 AC, including the Association Request frame which allows the AC to be 201 involved in the access policy enforcement portion of the IEEE 802.11 202 protocol. The IEEE 802.1X and IEEE 802.11 key management function 203 are also located on the AC. This implies that the AAA client also 204 resides on the AC. 206 While the admission control component of IEEE 802.11 resides on the 207 AC, the real time scheduling and queuing functions are on the WTP. 208 Note that this does not prevent the AC from providing additional 209 policy and scheduling functionality. 211 Note that in the following figure, the use of '( - )' indicates that 212 processing of the frames is done on the WTP. 214 Client WTP AC 216 Beacon 217 <----------------------------- 218 Probe Request 219 ----------------------------( - )-------------------------> 220 Probe Response 221 <----------------------------- 222 802.11 AUTH/Association 223 <---------------------------------------------------------> 224 Station Configuration Request 225 [Add Station (Station Message 226 Elements)] 227 <--------------------------> 228 802.1X Authentication & 802.11 Key Exchange 229 <---------------------------------------------------------> 230 Station Configuration Request 231 [Add Station (AES-CCMP, 232 PTK=x)] 233 <--------------------------> 234 802.11 Action Frames 235 <---------------------------------------------------------> 236 802.11 DATA (1) 237 <---------------------------( - )-------------------------> 239 Figure 2: Split MAC Message Flow 241 Figure 2 provides an illustration of the division of labor in a Split 242 MAC architecture. In this example, a WLAN has been created that is 243 configured for IEEE 802.11, using 802.1X based end user 244 authentication and AES-CCMP link layer encryption. The following 245 process occurs: 247 o The WTP generates the IEEE 802.11 Beacon frames, using information 248 provided to it through the IEEE 802.11 Add WLAN (see Section 6.1) 249 message element, including the RSNIE, which indicates support of 250 802.1X and AES-CCMP. 252 o The WTP processes the Probe Request frame and responds with a 253 corresponding Probe Response frame. The Probe Request frame is 254 then forwarded to the AC for optional processing. 256 o The WTP forwards the IEEEE 802.11 Authentication and Association 257 frames to the AC, which is responsible for responding to the 258 client. 260 o Once the association is complete, the AC transmits a Station 261 Configuration Request message, which includes an Add Station 262 message element, to the WTP (see Section 4.5.8 in [3]). In the 263 above example, the WLAN was configured for IEEE 802.1X. 265 o If the WTP is providing encryption/decryption services, once the 266 client has completed the IEEE 802.11 key exchange, the AC 267 transmits another Station Configuration Request message which 268 includes an Add Station message element, an IEEE 802.11 Station 269 message element, an IEEE 802.11 Station Session Key message 270 element and an IEEE 802.11 Information Element message element 271 which includes the RSNIE to the WTP, delivering the security 272 policy to enforce for the station (in this case AES-CCMP), and the 273 encryption key to use. If encryption/decryption is handled in the 274 AC, the IEEE 802.11 Information message element with an RSNIE 275 would not be included. 277 o The WTP forwards any IEEE 802.11 Management Action frames received 278 to the AC. 280 o All IEEE 802.11 station data frames are tunneled between the WTP 281 and the AC. 283 The WTP SHALL include the IEEE 802.11 MAC header contents in all 284 frames transmitted to the AC. 286 When 802.11 encryption/decryption is performed at the WTP, the WTP 287 MUST decrypt the uplink frames, MUST set the Protected Frame field to 288 0, and MUST make the frame format consistent with that of an 289 unprotected 802.11 frame prior to transmitting the frames to the AC. 290 The fields added to an 802.11 protected frame, i.e., IV/EIV, MIC,and 291 ICV , MUST be stripped off prior to transmission from the WTP to AC. 292 For downlink frames, the Protected Frame field MUST be set to 0 by 293 the AC as the frame being sent is unencrypted. The WTP MUST apply 294 the required protection policy for the WLAN, and set the Protected 295 Frame field on transmission over the air. The Protected Frame field 296 always needs to accurately indicate the status of the 802.11 frame 297 that is carrying it. 299 When 802.11 encryption/decryption is performed at the AC,the WTP 300 SHALL NOT decrypt the uplink frames prior to transmitting the frames 301 to the AC. The AC and WTP SHALL populate the IEEE 802.11 MAC header 302 fields as described in Figure 3. 304 MAC header field Location 305 Frame Control: 306 Version AC 307 ToDS AC 308 FromDS AC 309 Type AC 310 SubType AC 311 MoreFrag WTP/AC 312 Retry WTP 313 Pwr Mgmt - 314 MoreData WTP 315 Protected WTP/AC 316 Order AC 317 Duration: WTP 318 Address 1: AC 319 Address 2: AC 320 Address 3: AC 321 Sequence Ctrl: WTP 322 Address 4: AC 323 QoS Control: AC 324 Frame Body: AC 325 FCS: WTP 327 Figure 3: Population of the IEEE 802.11 MAC header Fields for 328 Downlink Frames 330 When 802.11 encryption/decryption is performed at the AC, the 331 MoreFrag bit is populated at the AC. The Pwr Mgmt bit is not 332 applicable to downlink frames, and is set to 0. Note that the FCS 333 field is not included in 802.11 frames exchanged between the WTP and 334 the AC. Upon sending data frames to the AC, the WTP is responsible 335 for validating, and stripping the FCS field. Upon receiving data 336 frames from the AC, the WTP is responsible for adding the FCS field, 337 and populating the field as described in [2]. 339 2.1.2. Local MAC 341 This section shows the division of labor between the WTP and the AC 342 in a Local MAC architecture. Figure 4 shows the separation of 343 functionality among CAPWAP components. 345 Function Location 346 Distribution Service WTP/AC 347 Integration Service WTP 348 Beacon Generation WTP 349 Probe Response Generation WTP 350 Power Mgmt/Packet Buffering WTP 351 Fragmentation/Defragmentation WTP 352 Assoc/Disassoc/Reassoc WTP/AC 354 IEEE 802.11 QOS 355 Classifying WTP 356 Scheduling WTP 357 Queuing WTP 359 IEEE 802.11 RSN 360 IEEE 802.1X/EAP AC 361 RSNA Key Management AC 362 IEEE 802.11 Encryption/Decryption WTP 364 Figure 4: Mapping of 802.11 Functions for Local AP Architecture 366 In the Local MAC mode, the integration service exists on the WTP, 367 while the distribution service MAY reside on either the WTP or the 368 AC. When it resides on the AC, station generated frames are not 369 forwarded to the AC in their native format, but encapsulated as 802.3 370 frames. 372 While the MAC is terminated on the WTP, it is necessary for the AC to 373 be aware of mobility events within the WTPs. Thus the WTP MUST 374 forward the IEEE 802.11 Association Request frames to the AC. The AC 375 MAY reply with a failed Association Response frame if it deems it 376 necessary, and upon receipt of a failed Association Response frame 377 from the AC, the WTP MUST send a Disassociation frame to the station. 379 The IEEE 802.1X and RSNA Key Management functions reside in the AC. 380 Therefore, the WTP MUST forward all IEEE 802.1X/RSNA Key Management 381 frames to the AC and forward the corresponding responses to the 382 station. This implies that the AAA client also resides on the AC. 384 Note that in the following figure, the use of '( - )' indicates that 385 processing of the frames is done on the WTP. 387 Client WTP AC 389 Beacon 390 <----------------------------- 391 Probe 392 <----------------------------> 393 802.11 AUTH 394 <----------------------------- 395 802.11 Association 396 <---------------------------( - )-------------------------> 397 Station Configuration Request[ 398 Add Station (Station Message 399 Elements)] 400 <--------------------------> 401 802.1X Authentication & 802.11 Key Exchange 402 <---------------------------------------------------------> 403 802.11 Action Frames 404 <---------------------------------------------------------> 405 Station Configuration Request[ 406 Add Station (AES-CCMP, 407 PTK=x)] 408 <--------------------------> 409 802.11 DATA 410 <-----------------------------> 412 Figure 5: Local MAC Message Flow 414 Figure 5 provides an illustration of the division of labor in a Local 415 MAC architecture. In this example, a WLAN that is configured for 416 IEEE 802.11 has been created using AES-CCMP for privacy. The 417 following process occurs: 419 o The WTP generates the IEEE 802.11 Beacon frames, using information 420 provided to it through the Add WLAN (see Section 6.1) message 421 element. 423 o The WTP processes a Probe Request frame and responds with a 424 corresponding Probe Response frame. 426 o The WTP forwards the IEEE 802.11 Authentication and Association 427 frames to the AC. 429 o Once the association is complete, the AC transmits a Station 430 Configuration Request message, which includes the Add Station 431 message element, to the WTP (see Section 10.1 in [3]). In the 432 above example, the WLAN is configured for IEEE 802.1X, and 433 therefore the '802.1X only' policy bit is enabled. 435 o The WTP forwards all IEEE 802.1X and IEEE 802.11 key exchange 436 messages to the AC for processing. 438 o The AC transmits another Station Configuration Request message 439 including an Add Station message element, an IEEE 802.11 Station 440 message element, an IEEE 802.11 Station Session Key message 441 element and an IEEE 802.11 Information Element message element 442 which includes the RSNIE to the WTP, stating the security policy 443 to enforce for the client (in this case AES-CCMP), as well as the 444 encryption key to use. The Add Station message element MAY 445 include a VLAN name, which when present is used by the WTP to 446 identify the VLAN on which the user's data frames are to be 447 bridged. 449 o The WTP forwards any IEEE 802.11 Management Action frames received 450 to the AC. 452 o The WTP MAY locally bridge client data frames (and provide the 453 necessary encryption and decryption services). The WTP MAY also 454 tunnel client data frames to the AC, using 802.3 frame tunnel mode 455 or 802.11 frame tunnel mode. 457 2.2. Roaming Behavior 459 This section expands upon the examples provided in the previous 460 section, and describes how the CAPWAP control protocol is used to 461 provide secure roaming. 463 Once a client has successfully associated with the network in a 464 secure fashion, it is likely to attempt to roam to another WTP. 465 Figure 6 shows an example of a currently associated station moving 466 from its "Old WTP" to a "New WTP". The figure is valid for multiple 467 different security policies, including IEEE 802.1X and WPA or WPA2, 468 both with key caching (where the IEEE 802.1x exchange would be 469 bypassed) and without. 471 Client Old WTP New WTP AC 473 Association Request/Response 474 <--------------------------------------( - )--------------> 475 Station Configuration Request[ 476 Add Station (Station Message 477 Elements)] 478 <----------------> 479 802.1X Authentication (if no key cache entry exists) 480 <--------------------------------------( - )--------------> 481 802.11 4-way Key Exchange 482 <--------------------------------------( - )--------------> 483 Station Configuration Request 484 [Delete Station] 485 <----------------------------------> 486 Station Configuration Request 487 [Add Station (AES-CCMP, 488 PTK=x)] 489 <----------------> 491 Figure 6: Client Roaming Example 493 2.3. Group Key Refresh 495 Periodically, the Group Key (GTK)for the BSS needs to be updated. 496 The AC uses an EAPOL-Key frame to update the group key for each STA 497 in the BSS. While the AC is updating the GTK, each L2 broadcast 498 frame transmitted to the BSS needs to be duplicated and transmitted 499 using both the current GTK and the new GTK. Once the GTK update 500 process has completed, broadcast frames transmitted to the BSS will 501 be encrypted using the new GTK. 503 In the case of Split MAC, the AC needs to duplicate all broadcast 504 packets and update the key index so that the packet is transmitted 505 using both the current and new GTK to ensure that all STA's in the 506 BSS receive the broadcast frames. In the case of local MAC, the WTP 507 needs to duplicate and transmit broadcast frames using the 508 appropriate index to ensure that all STA's in the BSS continue to 509 receive broadcast frames. 511 The Group Key update procedure is shown in the following figure. The 512 AC will signal the update to the GTK using an IEEE 802.11 513 Configuration Request message, including an IEEE 802.11 Update WLAN 514 message element with the new GTK, its index, the TSC for the Group 515 Key and the Key Status set to 3 (begin GTK update). The AC will then 516 begin updating the GTK for each STA. During this time, the AC (for 517 Split MAC) or WTP (for Local MAC) MUST duplicate broadcast packets 518 and transmit them encrypted with both the current and new GTK. When 519 the AC has completed the GTK update to all STA's in the BSS, the AC 520 MUST transmit an IEEE 802.11 Configuration Request message including 521 an IEEE 802.11 Update WLAN message element containing the new GTK, 522 its index, and the Key Status set to 4 (GTK update complete). 524 Client WTP AC 526 IEEE 802.11 WLAN Configuration Request [Update 527 WLAN (GTK, GTK Index, GTK Start, 528 Group TSC) ] 529 <-------------------------------------------- 530 802.1X EAPoL (GTK Message 1) 531 <-------------( - )------------------------------------------- 532 802.1X EAPoL (GTK Message 2) 533 -------------( - )-------------------------------------------> 534 IEEE 802.11 WLAN Configuration Request [ Update 535 WLAN (GTK Index, GTK Complete) ] 536 <-------------------------------------------- 538 Figure 7: Group Key Update Procedure 540 2.4. BSSID to WLAN ID Mapping 542 The CAPWAP protocol binding enables the WTP to assign BSSIDs upon 543 creation of a WLAN (see Section 6.1). While manufacturers are free 544 to assign BSSIDs using any arbitrary mechanism, it is advised that 545 where possible the BSSIDs are assigned as a contiguous block. 547 When assigned as a block, implementations can still assign any of the 548 available BSSIDs to any WLAN. One possible method is for the WTP to 549 assign the address using the following algorithm: base BSSID address 550 + WLAN ID. 552 The WTP communicates the maximum number of BSSIDs that it supports 553 during configuration via the IEEE 802.11 WTP WLAN Radio Configuration 554 message element (see Section 6.23). 556 2.5. Quality of Service for IEEE 802.11 MAC Management Messages 558 It is recommended that IEEE 802.11 MAC Management frames be sent by 559 both the AC and the WTP with appropriate Quality of Service values, 560 listed below, to ensure that congestion in the network minimizes 561 occurrences of packet loss. 563 802.1P: The precedence value of 7 SHOULD be used for all IEEE 564 802.11 MAC management frames, except for Probe Requests which 565 SHOULD use 4. 567 DSCP: The DSCP tag value of 46 SHOULD be used for all IEEE 802.11 568 MAC management frames, except for Probe Requests which SHOULD use 569 34. 571 2.6. Run State Operation 573 The Run state is the normal state of operation for the CAPWAP 574 protocol in both the WTP and the AC. 576 When the WTP receives a WLAN Configuration Request message (see 577 Section 3.1), it MUST respond with a WLAN Configuration Response 578 message (see Section 3.2) and it remains in the Run state. 580 When the AC sends a WLAN Configuration Request message (see 581 Section 3.1) or receives the corresponding WLAN Configuration 582 Response message (see Section 3.2) from the WTP, it remains in the 583 Run state. 585 3. IEEE 802.11 Specific CAPWAP Control Messages 587 This section defines CAPWAP Control Messages that are specific to the 588 IEEE 802.11 binding. Two messages are defined, IEEE 802.11 WLAN 589 Configuration Request and IEEE 802.11 WLAN Configuration Response. 590 See Section 4.4 in [3] for CAPWAP Control message definitions and the 591 derivation of the Message Type value from the IANA Enterprise number. 593 The valid message types for IEEE 802.11 specific control messages are 594 listed below. The IANA Enterprise number used with these messages is 595 13277. 597 CAPWAP Control Message Message Type 598 Value 600 IEEE 802.11 WLAN Configuration Request 3398912 601 IEEE 802.11 WLAN Configuration Response 3398913 603 3.1. IEEE 802.11 WLAN Configuration Request 605 The IEEE 802.11 WLAN Configuration Request is sent by the AC to the 606 WTP in order to change services provided by the WTP. This control 607 message is used to either create, update or delete a WLAN on the WTP. 609 The IEEE 802.11 WLAN Configuration Request is sent as a result of 610 either some manual admistrative process (e.g., deleting a WLAN), or 611 automatically to create a WLAN on a WTP. When sent automatically to 612 create a WLAN, this control message is sent after the CAPWAP 613 Configuration Update Request message (see Section 8.5 in [3]) has 614 been received by the WTP. 616 Upon receiving this control message, the WTP will modify the 617 necessary services, and transmit an IEEE 802.11 WLAN Configuration 618 Response. 620 A WTP MAY provide service for more than one WLAN, therefore every 621 WLAN is identified through a numerical index. For instance, a WTP 622 that is capable of supporting up to 16 SSIDs, could accept up to 16 623 IEEE 802.11 WLAN Configuration Request messages that include the Add 624 WLAN message element. 626 Since the index is the primary identifier for a WLAN, an AC MAY 627 attempt to ensure that the same WLAN is identified through the same 628 index number on all of its WTPs. An AC that does not follow this 629 approach MUST find some other means of maintaining a WLAN-Identifier- 630 to-SSID mapping table. 632 The following message elements MAY be included in the IEEE 802.11 633 WLAN Configuration Request message. Only one message element MUST be 634 present. 636 o IEEE 802.11 Add WLAN, see Section 6.1 638 o IEEE 802.11 Delete WLAN, see Section 6.4 640 o IEEE 802.11 Update WLAN, see Section 6.21 642 The following message element MAY be present. 644 o IEEE 802.11 Information Element, see Section 6.6 646 3.2. IEEE 802.11 WLAN Configuration Response 648 The IEEE 802.11 WLAN Configuration Response message is sent by the 649 WTP to the AC. It is used to acknowledge receipt of an IEEE 802.11 650 WLAN Configuration Request message, and to indicate that the 651 requested configuration was successfully applied, or that an error 652 related to the processing of the IEEE 802.11 WLAN Configuration 653 Request message occurred on the WTP. 655 The following message element MAY be included in the IEEE 802.11 WLAN 656 Configuration Response message. 658 o IEEE 802.11 Assigned WTP BSSID, see Section 6.3 660 The following message element MUST be included in the IEEE 802.11 661 WLAN Configuration Response message. 663 o Result Code, see Section 4.5.31 in [3] 665 4. CAPWAP Data Message Bindings 667 This section describes the CAPWAP Data Message bindings to support 668 transport of IEEE 802.11 frames. 670 Payload encapsulation: The CAPWAP protocol defines the CAPWAP data 671 message, which is used to encapsulate a wireless payload. For 672 IEEE 802.11, the IEEE 802.11 header and payload are encapsulated 673 (excluding the IEEE 802.11 FCS checksum). The IEEE 802.11 FCS 674 checksum is handled by the WTP. This allows the WTP to validate 675 an IEEE 802.11 frame prior to sending it to the AC. Similarly, 676 when an AC wishes to transmit a frame to a station, the WTP 677 computes and adds the FCS checksum. 679 Optional Wireless Specific Information: The optional CAPWAP header 680 field (see Section 4.2 in [3]) is only used with CAPWAP data 681 messages, and it serves two purposes, depending upon the direction 682 of the message. For messages from the WTP to the AC, the field 683 uses the format described in the "IEEE 802.11 Frame Info" field 684 (see below). However, for messages sent by the AC to the WTP, the 685 format used is described in the "Destination WLANs" field (also 686 defined below). 688 IEEE 802.11 Frame Info: When an IEEE 802.11 frame is received from a 689 station over the air, it is encapsulated and this field is used to 690 include radio and PHY specific information associated with the 691 frame. 693 The IEEE 802.11 Frame Info field has the following format: 695 0 1 2 3 696 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 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | RSSI | SNR | Data Rate | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 RSSI: RSSI is a signed, 8-bit value. It is the received signal 702 strength indication, in dBm. 704 SNR: SNR is a signed, 8-bit value. It is the signal to noise 705 ratio of the received IEEE 802.11 frame, in dB. 707 Data Rate: The data rate field is a 16 bit unsigned value. The 708 contents of the field is set to 10 times the data rate in Mbps 709 of the packet received by the WTP. For instance, a packet 710 received at 5.5Mbps would be set to 55, while 11Mbps would be 711 set to 110. 713 Destination WLANs The Destination WLANs field is used to specify the 714 target WLANs for a given frame, and is only used with broadcast 715 and multicast frames. This field allows the AC to transmit a 716 single broadcast or multicast frame to the WTP, and allows the WTP 717 to perform the necessary frame replication. The field uses the 718 following format: 720 0 1 2 3 721 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 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 | WLAN ID bitmap | Reserved | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 WLAN ID bitmap: This bit field indicates the WLAN ID (see 727 Section 6.1) on which the WTP will transmit the included frame. 728 For instance, if a multicast packet is to be transmitted on 729 WLANs 1 and 3, bits 1 and 3 of this field would be enabled. 730 This field is to be set to zero for unicast packets and is 731 unused if the WTP is not providing IEEE 802.11 encryption. 733 Reserved: All implementations complying with this protocol MUST 734 set to zero any bits that are reserved in the version of the 735 protocol supported by that implementation. Receivers MUST 736 ignore all bits not defined for the version of the protocol 737 they support. 739 5. CAPWAP Control Message bindings 741 This section describes the IEEE 802.11 specific message elements 742 included in CAPWAP Control Messages. 744 5.1. Discovery Request Message 746 The following IEEE 802.11 specific message element MUST be included 747 in the CAPWAP Discovery Request Message. 749 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 750 802.11 WTP Radio Information message element MUST be present for 751 every radio in the WTP. 753 5.2. Discovery Response Message 755 The following IEEE 802.11 specific message element MUST be included 756 in the CAPWAP Discovery Response Message. 758 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 759 802.11 WTP Radio Information message element MUST be present for 760 every radio in the WTP. 762 5.3. Primary Discovery Request Message 764 The following IEEE 802.11 specific message element MUST be included 765 in the CAPWAP Primary Discovery Request Message. 767 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 768 802.11 WTP Radio Information message element MUST be present for 769 every radio in the WTP. 771 5.4. Primary Discovery Response Message 773 The following IEEE 802.11 specific message element MUST be included 774 in the CAPWAP Primary Discovery Response Message. 776 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 777 802.11 WTP Radio Information message element MUST be present for 778 every radio in the WTP. 780 5.5. Join Request Message 782 The following IEEE 802.11 specific message element MUST be included 783 in the CAPWAP Join Request Message. 785 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 786 802.11 WTP Radio Information message element MUST be present for 787 every radio in the WTP. 789 5.6. Join Response Message 791 The following IEEE 802.11 specific message element MUST be included 792 in the CAPWAP Join Response Message. 794 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 795 802.11 WTP Radio Information message element MUST be present for 796 every radio in the WTP. 798 5.7. Configuration Status Message 800 The following IEEE 802.11 specific message elements MAY be included 801 in the CAPWAP Configuration Status Message. More than one of each 802 message element listed MAY be included. 804 o IEEE 802.11 Antenna, see Section 6.2 806 o IEEE 802.11 Direct Sequence Control, see Section 6.5 808 o IEEE 802.11 MAC Operation, see Section 6.7 810 o IEEE 802.11 Multi Domain Capability, see Section 6.9 812 o IEEE 802.11 OFDM Control, see Section 6.10 814 o IEEE 802.11 Supported Rates, see Section 6.17 816 o IEEE 802.11 Tx Power, see Section 6.18 818 o IEEE 802.11 TX Power Level, see Section 6.19 820 o IEEE 802.11 WTP Radio Configuration, see Section 6.23 822 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 823 802.11 WTP Radio Information message element MUST be present for 824 every radio in the WTP. 826 5.8. Configuration Status Response Message 828 The following IEEE 802.11 specific message elements MAY be included 829 in the CAPWAP Configuration Status Response Message. More than one 830 of each message element listed MAY be included. 832 o IEEE 802.11 Antenna, see Section 6.2 833 o IEEE 802.11 Direct Sequence Control, see Section 6.5 835 o IEEE 802.11 MAC Operation, see Section 6.7 837 o IEEE 802.11 Multi Domain Capability, see Section 6.9 839 o IEEE 802.11 OFDM Control, see Section 6.10 841 o IEEE 802.11 Rate Set, see Section 6.11 843 o IEEE 802.11 Supported Rates, see Section 6.17 845 o IEEE 802.11 Tx Power, see Section 6.18 847 o IEEE 802.11 WTP Quality of Service, see Section 6.22 849 o IEEE 802.11 WTP Radio Configuration, see Section 6.23 851 5.9. Configuration Update Request Message 853 The following IEEE 802.11 specific message elements MAY be included 854 in the CAPWAP Configuration Update Request Message. More than one of 855 each message element listed MAY be included. 857 o IEEE 802.11 Antenna, see Section 6.2 859 o IEEE 802.11 Direct Sequence Control, see Section 6.5 861 o IEEE 802.11 MAC Operation, see Section 6.7 863 o IEEE 802.11 Multi Domain Capability, see Section 6.9 865 o IEEE 802.11 OFDM Control, see Section 6.10 867 o IEEE 802.11 Rate Set, see Section 6.11 869 o IEEE 802.11 RSNA Error Report From Station, see Section 6.12 871 o IEEE 802.11 Tx Power, see Section 6.18 873 o IEEE 802.11 WTP Quality of Service, see Section 6.22 875 o IEEE 802.11 WTP Radio Configuration, see Section 6.23 877 5.10. Station Configuration Request 879 The following IEEE 802.11 specific message elements MAY included in 880 the CAPWAP Station Configuration Request message. More than one of 881 each message element listed MAY be included. 883 o IEEE 802.11 Station, see Section 6.13 885 o IEEE 802.11 Station Session Key, see Section 6.15 887 o Station QoS Profile, see Section 6.14 889 5.11. Change State Event Request 891 The following IEEE 802.11 specific message elements MAY included in 892 the CAPWAP Station Configuration Request message. 894 o IEEE 802.11 WTP Radio Fail Alarm Indication, see Section 6.24 896 5.12. WTP Event Request 898 The following IEEE 802.11 specific message elements MAY be included 899 in the CAPWAP WTP Event Request message.More than one of each message 900 element listed MAY be included. 902 o IEEE 802.11 MIC Countermeasures, see Section 6.8 904 o IEEE 802.11 RSNA Error Report From Station, see Section 6.12 906 o IEEE 802.11 Statistics, see Section 6.16 908 6. IEEE 802.11 Message Element Definitions 910 The following IEEE 802.11 specific message elements are defined in 911 this section. 913 IEEE 802.11 Message Element Type Value 915 IEEE 802.11 Add WLAN 1024 916 IEEE 802.11 Antenna 1025 917 IEEE 802.11 Assigned WTP BSSID 1026 918 IEEE 802.11 Delete WLAN 1027 919 IEEE 802.11 Direct Sequence Control 1028 920 IEEE 802.11 Information Element 1029 921 IEEE 802.11 MAC Operation 1030 922 IEEE 802.11 MIC Countermeasures 1031 923 IEEE 802.11 Multi-Domain Capability 1032 924 IEEE 802.11 OFDM Control 1033 925 IEEE 802.11 Rate Set 1034 926 IEEE 802.11 RSNA Error Report From Station 1035 927 IEEE 802.11 Station 1036 928 IEEE 802.11 Station QoS Profile 1037 929 IEEE 802.11 Station Session Key 1038 930 IEEE 802.11 Statistics 1039 931 IEEE 802.11 Supported Rates 1040 932 IEEE 802.11 Tx Power 1041 933 IEEE 802.11 Tx Power Level 1042 934 IEEE 802.11 Update Station QoS 1043 935 IEEE 802.11 Update WLAN 1044 936 IEEE 802.11 WTP Quality of Service 1045 937 IEEE 802.11 WTP Radio Configuration 1046 938 IEEE 802.11 WTP Radio Fail Alarm Indication 1047 939 IEEE 802.11 WTP Radio Information 1048 941 6.1. IEEE 802.11 Add WLAN 943 The IEEE 802.11 Add WLAN message element is used by the AC to define 944 a WLAN on the WTP. The inclusion of this message element MUST also 945 include IEEE 802.11 Information Element message elements, containing 946 the following IEEE 802.11 IEs: 948 Power Capability information element 949 WPA information element 951 RSN information element 953 EDCA Parameter Set information element 955 QoS Capability information element 957 WMM information element 959 If present, the RSN information element is sent with the IEEE 802.11 960 Add WLAN message element to instruct the WTP on the usage of the Key 961 field. 963 An AC MAY include additional information elements as desired. The 964 message element uses the following format: 966 0 1 2 3 967 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 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 | Radio ID | WLAN ID | Capabilities | 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 971 | Key Index | Key Status | Key Length | 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 | Key... | 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 | Group TSC | 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 | Group TSC | QoS | Auth Type | 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 | MAC Mode | Tunnel Mode | Suppress SSID | SSID ... 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 Type: 1024 for IEEE 802.11 Add WLAN 984 Length: >= 49 986 Radio ID: An 8-bit value representing the radio. 988 WLAN ID: An 8-bit value specifying the WLAN Identifier. 990 Capability: A 16-bit value containing the capabilities information 991 field to be advertised by the WTP in the Probe Request and Beacon 992 frames. 994 Key-Index: The Key Index associated with the key. 996 Key Status: A 1 byte value that specifies the state and usage of 997 the key that has been included. The following values describe the 998 key usage and its status: 1000 0 - A value of zero, with the inclusion of the RSN Information 1001 Element means that the WLAN uses per-station encryption keys, and 1002 therefore the key in the 'Key' field is only used for multicast 1003 traffic. 1005 1 - When set to one, the WLAN employs a shared WEP key, also known 1006 as a static WEP key, and uses the encryption key for both unicast 1007 and multicast traffic for all stations. 1009 2 - The value of 2 indicates that the AC will begin rekeying the GTK 1010 with the STA's in the BSS. It is only valid when IEEE 802.11 is 1011 enabled as the security policy for the BSS. 1013 3 - The value of 3 indicates that the AC has completed rekeying the 1014 GTK and broadcast packets no longer need to be duplicated and 1015 transmitted with both GTK's. 1017 Key Length: A 16-bit value representing the length of the Key 1018 field. 1020 Key: A 32 byte Session Key to use to provide data privacy. For 1021 encryption schemes that employ a separate encryption key for 1022 unicast and multicast traffic, the key included here only applies 1023 to multicast frames, and the cipher suite is specified in an 1024 accompanied RSN Information Element. In these scenarios, the key 1025 and cipher information is communicated via the Add Station message 1026 element, see Section 4.5.8 in [3] and the IEEE 802.11 Station 1027 Session Key message element, see Section 6.15. 1029 Group TSC A 48-bit value containing the Transmit Sequence Counter 1030 for the updated group key. The WTP will set the TSC for 1031 broadcast/multicast frames to this value for the updated group 1032 key. 1034 QOS: An 8-bit value specifying the default QOS policy for the WTP 1035 to apply to network traffic received for a non-WMM enabled STA. 1037 The following values are supported: 1039 0 - Best Effort 1041 1 - Video 1043 2 - Voice 1045 3 - Background 1047 Auth Type: An 8-bit value specifying the supported authentication 1048 type. 1050 The following values are supported: 1052 0 - Open System 1054 1 - WEP Shared Key 1056 MAC Mode: This field specifies whether the WTP should support the 1057 WLAN in Local or Split MAC modes. Note that the AC MUST NOT 1058 request a mode of operation that was not advertised by the WTP 1059 during the discovery process (see Section 4.4.42 in [3]). The 1060 following values are supported: 1062 0 - Local-MAC: Service for the WLAN is to be provided in Local 1063 MAC mode. 1065 1 - Split-MAC: Service for the WLAN is to be provided in Split 1066 MAC mode. 1068 Tunnel Mode: This field specifies the frame tunneling type to be 1069 used for 802.11 data frames from all stations associated with the 1070 WLAN. The AC MUST NOT request a mode of operation that was not 1071 advertised by the WTP during the discovery process (see Section 1072 4.4.40 in [3]). IEEE 802.11 managment frames SHALL be tunneled 1073 using 802.11 Tunnel mode. The following values are supported: 1075 0 - Local Bridging: All user traffic is to be locally bridged. 1077 1 - 802.3 Tunnel: All user traffic is to be tunneled to the AC 1078 in 802.3 format (see Section 4.2 in [3]). 1080 2 - 802.11 Tunnel: All user traffic is to be tunneled to the AC 1081 in 802.11 format. 1083 Supress SSID: A boolean indicating whether the SSID is to be 1084 advertised by the WTP. A value of zero supresses the SSID in the 1085 802.11 Beacon and Probe Response frames, while a value of one will 1086 cause the WTP to populate the field. 1088 SSID: The SSID attribute is the service set identifier that will be 1089 advertised by the WTP for this WLAN. 1091 6.2. IEEE 802.11 Antenna 1093 The IEEE 802.11 Antenna message element is communicated by the WTP to 1094 the AC to provide information on the antennas available. The AC MAY 1095 use this element to reconfigure the WTP's antennas. The message 1096 element contains the following fields: 1098 0 1 2 3 1099 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 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 | Radio ID | Diversity | Combiner | Antenna Cnt | 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 | Antenna Selection [0..N] | 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1106 Type: 1025 for IEEE 802.11 Antenna 1108 Length: >= 5 1110 Radio ID: An 8-bit value representing the radio to configure. 1112 Diversity: An 8-bit value specifying whether the antenna is to 1113 provide receive diversity. The value of this field is the same as 1114 the IEEE 802.11 dot11DiversitySelectionRx MIB element, see [2]. 1115 The following values are supported: 1117 0 - Disabled 1119 1 - Enabled (may only be true if the antenna can be used as a 1120 receive antenna) 1122 Combiner: An 8-bit value specifying the combiner selection. The 1123 following values are supported: 1125 1 - Sectorized (Left) 1127 2 - Sectorized (Right) 1128 3 - Omni 1130 4 - MIMO 1132 Antenna Count: An 8-bit value specifying the number of Antenna 1133 Selection fields. This value SHOULD be the same as the one found 1134 in the IEEE 802.11 dot11CurrentTxAntenna MIB element (see [2]). 1136 Antenna Selection: One 8-bit antenna configuration value per 1137 antenna in the WTP. The following values are supported: 1139 1 - Internal Antenna 1141 2 - External Antenna 1143 6.3. IEEE 802.11 Assigned WTP BSSID 1145 The IEEE 802.11 Assigned WTP BSSID is only included by the WTP when 1146 the IEEE 802.11 WLAN Configuration Request included the IEEE 802.11 1147 Add WLAN message element. The BSSID value field of this message 1148 element contains the BSSID that has been assigned by the WTP, 1149 enabling the WTP to perform its own BSSID assignment. 1151 The WTP is free to assign the BSSIDs the way it sees fit, but it is 1152 highly recommended that the WTP assign the BSSID using the following 1153 algorithm: BSSID = {base BSSID} + WLAN ID. 1155 0 1 2 3 1156 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 1157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1158 | Radio ID | WLAN ID | BSSID 1159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1160 | BSSID | 1161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1163 Type: 1026 for IEEE 802.11 Assigned WTP BSSID 1165 Length: 6 1167 Radio ID: An 8-bit value representing the radio. 1169 WLAN ID: An 8-bit value specifying the WLAN Identifier. 1171 BSSID: The BSSID assigned by the WTP for the WLAN created as a 1172 result of receiving an IEEE 802.11 Add WLAN. 1174 6.4. IEEE 802.11 Delete WLAN 1176 The IEEE 802.11 Delete WLAN message element is used to inform the WTP 1177 that a previously created WLAN is to be deleted, and contains the 1178 following fields: 1180 0 1 1181 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1183 | Radio ID | WLAN ID | 1184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1186 Type: 1027 for IEEE 802.11 Delete WLAN 1188 Length: 3 1190 Radio ID: An 8-bit value representing the radio 1192 WLAN ID: An 8-bit value specifying the WLAN Identifier 1194 6.5. IEEE 802.11 Direct Sequence Control 1196 The IEEE 802.11 Direct Sequence Control message element is a bi- 1197 directional element. When sent by the WTP, it contains the current 1198 state. When sent by the AC, the WTP MUST adhere to the values 1199 provided. This element is only used for IEEE 802.11b radios. The 1200 message element has the following fields. 1202 0 1 2 3 1203 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 1204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1205 | Radio ID | Reserved | Current Chan | Current CCA | 1206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1207 | Energy Detect Threshold | 1208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1210 Type: 1028 for IEEE 802.11 Direct Sequence Control 1212 Length: 8 1214 Radio ID: An 8-bit value representing the radio to configure. 1216 Reserved: All implementations complying with this protocol MUST set 1217 to zero any bits that are reserved in the version of the protocol 1218 supported by that implementation. Receivers MUST ignore all bits 1219 not defined for the version of the protocol they support. 1221 Current Channel: This attribute contains the current operating 1222 frequency channel of the DSSS PHY. This value comes from the IEEE 1223 802.11 dot11CurrentChannel MIB element (see [2]). 1225 Current CCA: The current CCA method in operation, whose value can 1226 be found in the IEEE 802.11 dot11CCAModeSupported MIB element (see 1227 [2]). Valid values are: 1229 1 - energy detect only (edonly) 1231 2 - carrier sense only (csonly) 1233 4 - carrier sense and energy detect (edandcs) 1235 8 - carrier sense with timer (cswithtimer) 1237 16 - high rate carrier sense and energy detect (hrcsanded) 1239 Energy Detect Threshold: The current Energy Detect Threshold being 1240 used by the DSSS PHY. The value can be found in the IEEE 802.11 1241 dot11EDThreshold MIB element (see [2]). 1243 6.6. IEEE 802.11 Information Element 1245 The IEEE 802.11 Information Element is used to communicate any IE 1246 defined in the IEEE 802.11 protocol. The data field contains the raw 1247 IE as it would be included within an IEEE 802.11 MAC management 1248 message. 1250 0 1 2 3 1251 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 1252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1253 | Radio ID | WLAN ID |B|P| Flags |Info Element... 1254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1256 Type: 1029 for IEEE 802.11 Information Element 1258 Length: >= 2 1260 Radio ID: An 8-bit value representing the radio. 1262 WLAN ID: An 8-bit value specifying the WLAN Identifier. 1264 B: When set, the WTP is to include the information element in IEEE 1265 802.11 Beacons associated with the WLAN. 1267 P: When set, the WTP is to include the information element in Probe 1268 Responses associated with the WLAN. 1270 Flags: All implementations complying with this protocol MUST set to 1271 zero any bits that are reserved in the version of the protocol 1272 supported by that implementation. Receivers MUST ignore all bits 1273 not defined for the version of the protocol they support. 1275 Info Element: The IEEE 802.11 Information Element, which includes 1276 the type, length and value field. 1278 6.7. IEEE 802.11 MAC Operation 1280 The IEEE 802.11 MAC Operation message element is sent by the AC to 1281 set the IEEE 802.11 MAC parameters on the WTP, and contains the 1282 following fields. 1284 0 1 2 3 1285 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 1286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1287 | Radio ID | Reserved | RTS Threshold | 1288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1289 | Short Retry | Long Retry | Fragmentation Threshold | 1290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1291 | Tx MSDU Lifetime | 1292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1293 | Rx MSDU Lifetime | 1294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1296 Type: 1030 for IEEE 802.11 MAC Operation 1298 Length: 16 1300 Radio ID: An 8-bit value representing the radio to configure. 1302 Reserved: All implementations complying with this protocol MUST set 1303 to zero any bits that are reserved in the version of the protocol 1304 supported by that implementation. Receivers MUST ignore all bits 1305 not defined for the version of the protocol they support. 1307 RTS Threshold: This attribute indicates the number of octets in an 1308 MPDU, below which an RTS/CTS handshake MUST NOT be performed. An 1309 RTS/CTS handshake MUST be performed at the beginning of any frame 1310 exchange sequence where the MPDU is of type Data or Management, 1311 the MPDU has an individual address in the Address1 field, and the 1312 length of the MPDU is greater than this threshold. Setting this 1313 attribute to be larger than the maximum MSDU size MUST have the 1314 effect of turning off the RTS/CTS handshake for frames of Data or 1315 Management type transmitted by this STA. Setting this attribute 1316 to zero MUST have the effect of turning on the RTS/CTS handshake 1317 for all frames of Data or Management type transmitted by this STA. 1318 The default value of this attribute MUST be 2347. The value of 1319 this field comes from the IEEE 802.11 dot11RTSThreshold MIB 1320 element, (see [2]). 1322 Short Retry: This attribute indicates the maximum number of 1323 transmission attempts of a frame, the length of which is less than 1324 or equal to RTSThreshold, that MUST be made before a failure 1325 condition is indicated. The default value of this attribute MUST 1326 be 7. The value of this field comes from the IEEE 802.11 1327 dot11ShortRetryLimit MIB element, (see [2]). 1329 Long Retry: This attribute indicates the maximum number of 1330 transmission attempts of a frame, the length of which is greater 1331 than dot11RTSThreshold, that MUST be made before a failure 1332 condition is indicated. The default value of this attribute MUST 1333 be 4. The value of this field comes from the IEEE 802.11 1334 dot11LongRetryLimit MIB element, (see [2]). 1336 Fragmentation Threshold: This attribute specifies the current 1337 maximum size, in octets, of the MPDU that MAY be delivered to the 1338 PHY. An MSDU MUST be broken into fragments if its size exceeds 1339 the value of this attribute after adding MAC headers and trailers. 1340 An MSDU or MMPDU MUST be fragmented when the resulting frame has 1341 an individual address in the Address1 field, and the length of the 1342 frame is larger than this threshold. The default value for this 1343 attribute MUST be the lesser of 2346 or the aMPDUMaxLength of the 1344 attached PHY and MUST never exceed the lesser of 2346 or the 1345 aMPDUMaxLength of the attached PHY. The value of this attribute 1346 MUST never be less than 256. The value of this field comes from 1347 the IEEE 802.11 dot11FragmentationThreshold MIB element, (see 1348 [2]). 1350 Tx MSDU Lifetime: This attribute speficies the elapsed time in TU, 1351 after the initial transmission of an MSDU, after which further 1352 attempts to transmit the MSDU MUST be terminated. The default 1353 value of this attribute MUST be 512. The value of this field 1354 comes from the IEEE 802.11 dot11MaxTransmitMSDULifetime MIB 1355 element, (see [2]). 1357 Rx MSDU Lifetime: This attribute specifies the elapsed time in TU, 1358 after the initial reception of a fragmented MMPDU or MSDU, after 1359 which further attempts to reassemble the MMPDU or MSDU MUST be 1360 terminated. The default value MUST be 512. The value of this 1361 field comes from the IEEE 802.11 dot11MaxReceiveLifetime MIB 1362 element, (see [2]). 1364 6.8. IEEE 802.11 MIC Countermeasures 1366 The IEEE 802.11 MIC Countermeasures message element is sent by the 1367 WTP to the AC to indicate the occurrence of a MIC failure. For more 1368 information on MIC failure events, see the 1369 dot11RSNATKIPCounterMeasuresInvoked MIB element definition in [2]. 1371 0 1 2 3 1372 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 1373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1374 | Radio ID | WLAN ID | MAC Address | 1375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1376 | MAC Address | 1377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1379 Type: 1031 for IEEE 802.11 MIC Countermeasures 1381 Length: 8 1383 Radio ID: The Radio Identifier, typically refers to some interface 1384 index on the WTP. 1386 WLAN ID: This 8-bit unsigned integer includes the WLAN Identifier, 1387 on which the MIC failure occurred. 1389 MAC Address: The MAC Address of the station that caused the MIC 1390 failure. 1392 6.9. IEEE 802.11 Multi-Domain Capability 1394 The IEEE 802.11 Multi-Domain Capability message element is used by 1395 the AC to inform the WTP of regulatory limits. The AC will transmit 1396 one message element per frequency band to indicate the regulatory 1397 constraints in that domain. The message element contains the 1398 following fields. 1400 0 1 2 3 1401 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 1402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1403 | Radio ID | Reserved | First Channel # | 1404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1405 | Number of Channels | Max Tx Power Level | 1406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1408 Type: 1032 for IEEE 802.11 Multi-Domain Capability 1410 Length: 8 1412 Radio ID: An 8-bit value representing the radio to configure. 1414 Reserved: All implementations complying with this protocol MUST set 1415 to zero any bits that are reserved in the version of the protocol 1416 supported by that implementation. Receivers MUST ignore all bits 1417 not defined for the version of the protocol they support. 1419 First Channnel #: This attribute indicates the value of the lowest 1420 channel number in the subband for the associated domain country 1421 string. The value of this field comes from the IEEE 802.11 1422 dot11FirstChannelNumber MIB element (see [2]). 1424 Number of Channels: This attribute indicates the value of the total 1425 number of channels allowed in the subband for the associated 1426 domain country string. The value of this field comes from the 1427 IEEE 802.11 dot11NumberofChannels MIB element (see [2]). 1429 Max Tx Power Level: This attribute indicates the maximum transmit 1430 power, in dBm, allowed in the subband for the associated domain 1431 country string. The value of this field comes from the IEEE 1432 802.11 dot11MaximumTransmitPowerLevel MIB element (see [2]). 1434 6.10. IEEE 802.11 OFDM Control 1436 The IEEE 802.11 OFDM Control message element is a bi-directional 1437 element. When sent by the WTP, it contains the current state. When 1438 sent by the AC, the WTP MUST adhere to the received values. This 1439 message element is only used for 802.11a radios and contains the 1440 following fields: 1442 0 1 2 3 1443 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 1444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1445 | Radio ID | Reserved | Current Chan | Band Support | 1446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1447 | TI Threshold | 1448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1450 Type: 1033 for IEEE 802.11 OFDM Control 1452 Length: 8 1453 Radio ID: An 8-bit value representing the radio to configure. 1455 Reserved: All implementations complying with this protocol MUST set 1456 to zero any bits that are reserved in the version of the protocol 1457 supported by that implementation. Receivers MUST ignore all bits 1458 not defined for the version of the protocol they support. 1460 Current Channel: This attribute contains the current operating 1461 frequency channel of the OFDM PHY. The value of this field comes 1462 from the IEEE 802.11 dot11CurrentFrequency MIB element (see [2]). 1464 Band Supported: The capability of the OFDM PHY implementation to 1465 operate in the three U-NII bands. The value of this field comes 1466 from the IEEE 802.11 dot11FrequencyBandsSupported MIB element (see 1467 [2]), coded as an integer value of a three bit field as follows: 1469 Bit 0 - capable of operating in the lower (5.15-5.25 GHz) U-NII 1470 band 1472 Bit 1 - capable of operating in the middle (5.25-5.35 GHz) U-NII 1473 band 1475 Bit 2 - capable of operating in the upper (5.725-5.825 GHz) U-NII 1476 band 1478 For example, for an implementation capable of operating in the 1479 lower and mid bands this attribute would take the value 3. 1481 TI Threshold: The Threshold being used to detect a busy medium 1482 (frequency). CCA MUST report a busy medium upon detecting the 1483 RSSI above this threshold. The value of this field comes from the 1484 IEEE 802.11 dot11TIThreshold MIB element (see [2]). 1486 6.11. IEEE 802.11 Rate Set 1488 The rate set message element value is sent by the AC and contains the 1489 supported operational rates. It contains the following fields. 1491 0 1 2 3 1492 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 1493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1494 | Radio ID | Rate Set... 1495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1497 Type: 1034 for IEEE 802.11 Rate Set 1499 Length: >= 3 1501 Radio ID: An 8-bit value representing the radio to configure. 1503 Rate Set: The AC generates the Rate Set that the WTP is to include 1504 in its Beacon and Probe messages. The length of this field is 1505 between 2 and 8 bytes. The value of this field comes from the 1506 IEEE 802.11 dot11OperationalRateSet MIB element (see [2]). 1508 6.12. IEEE 802.11 RSNA Error Report From Station 1510 The IEEE 802.11 RSN Error Report From Station message element is used 1511 by a WTP to send RSN error reports to the AC. The WTP does not need 1512 to transmit any reports that do not include any failures. The fields 1513 from this message element come from the IEEE 802.11 1514 Dot11RSNAStatsEntry table, see [2]. 1516 0 1 2 3 1517 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 1518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1519 | Client MAC Address | 1520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1521 | Client MAC Address | BSSID | 1522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1523 | BSSID | 1524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1525 | Radio ID | WLAN ID | Reserved | 1526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1527 | TKIP ICV Errors | 1528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1529 | TKIP Local MIC Failures | 1530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1531 | TKIP Remote MIC Failures | 1532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1533 | CCMP Replays | 1534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1535 | CCMP Decrypt Errors | 1536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1537 | TKIP Replays | 1538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1540 Type: 1035 for IEEE 802.11 RSNA Error Report From Station 1542 Length: 14 1544 Client MAC Address: The Client MAC Address of the station. 1546 BSSID: The BSSID on which the failures are being reported on. 1548 Radio ID: The Radio Identifier, typically refers to some interface 1549 index on the WTP 1551 WLAN ID: The WLAN ID on which the RSNA failures are being reported. 1553 Reserved: All implementations complying with this protocol MUST set 1554 to zero any bits that are reserved in the version of the protocol 1555 supported by that implementation. Receivers MUST ignore all bits 1556 not defined for the version of the protocol they support. 1558 TKIP ICV Errors: A 32-bit value representing the number of TKIP ICV 1559 errors encountered when decrypting packets from the station. The 1560 value of this field comes from the IEEE 802.11 1561 dot11RSNAStatsTKIPICVErrors MIB element (see [2]). 1563 TKIP Local MIC Failures: A 32-bit value representing the number of 1564 MIC failures encountered when checking the integrity of packets 1565 received from the station. The value of this field comes from the 1566 IEEE 802.11 dot11RSNAStatsTKIPLocalMICFailures MIB element (see 1567 [2]). 1569 TKIP Remote MIC Failures: A 32-bit value representing the number of 1570 MIC failures reported by the station encountered (possibly via the 1571 EAPOL-Key frame). The value of this field comes from the IEEE 1572 802.11 dot11RSNAStatsTKIPRemoteMICFailures MIB element (see [2]). 1574 CCMP Replays: A 32-bit value representing the number of CCMP MPDUs 1575 discarded by the replay detection mechanism. The value of this 1576 field comes from the IEEE 802.11 dot11RSNACCMPReplays MIB element 1577 (see [2]). 1579 CCMP Decrypt Errors: A 32-bit value representing the number of CCMP 1580 MDPUs discarded by the decryption algorithm. The value of this 1581 field comes from the IEEE 802.11 dot11RSNACCMPDecryptErrors MIB 1582 element (see [2]). 1584 TKIP Replays: A 32-bit value representing the number of TKIP 1585 Replays detected in frames received from the station. The value 1586 of this field comes from the IEEE 802.11 dot11RSNAStatsTKIPReplays 1587 MIB element (see [2]). 1589 6.13. IEEE 802.11 Station 1591 The IEEE 802.11 Station message element accompanies the Add Station 1592 message element, and is used to deliver IEEE 802.11 station policy 1593 from the AC to the WTP. 1595 The latest IEEE 802.11 Station message element overrides any 1596 previously received message elements. 1598 If the QoS field is set, the WTP MUST observe and provide policing of 1599 the 802.11e priority tag to ensure that it does not exceed the value 1600 provided by the AC. 1602 0 1 2 3 1603 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 1604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1605 | Radio ID | Association ID | Flags | 1606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1607 | MAC Address | 1608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1609 | MAC Address | Capabilities | 1610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1611 | WLAN ID |Supported Rates| 1612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1614 Type: 1036 for IEEE 802.11 Station 1616 Length: >= 8 1618 Radio ID: An 8-bit value representing the radio 1620 Association ID: A 16-bit value specifying the IEEE 802.11 1621 Association Identifier 1623 Flags: All implementations complying with this protocol MUST set to 1624 zero any bits that are reserved in the version of the protocol 1625 supported by that implementation. Receivers MUST ignore all bits 1626 not defined for the version of the protocol they support. 1628 MAC Address: The station's MAC Address 1630 Capabilities: A 16-bit field containing the IEEE 802.11 1631 Capabilities Information Field to use with the station. 1633 WLAN ID: An 8-bit value specifying the WLAN Identifier 1634 Supported Rates: The variable length field containing the supported 1635 rates to be used with the station, as found in the IEEE 802.11 1636 dot11OperationalRateSet MIB element (see [2]). 1638 6.14. IEEE 802.11 Station QoS Profile 1640 The IEEE 802.11 Station QoS Profile message element contains the 1641 maximum IEEE 802.11e priority tag that may be used by the station. 1642 Any packet received that exceeds the value encoded in this message 1643 element MUST either be dropped or tagged using the maximum value 1644 permitted by to the user. The priority tag MUST be between zero (0) 1645 and seven (7). This message element MUST NOT be present without the 1646 IEEE 802.11 Station (see Section 6.13) message element 1648 0 1 2 3 1649 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1651 | MAC Address | 1652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1653 | MAC Address | 802.1P Precedence Tag | 1654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1656 Type: 1037 for IEEE 802.11 Station QOS Profile 1658 Length: 8 1660 MAC Address: The station's MAC Address 1662 802.1P Precedence Tag: The maximum 802.1P precedence value that the 1663 WTP will allow in the TID field in the extended 802.11e QOS Data 1664 header. 1666 6.15. IEEE 802.11 Station Session Key 1668 The IEEE 802.11 Station Session Key message element is sent when the 1669 AC determines that encryption of a station must be performed in the 1670 WTP. This message element MUST NOT be present without the IEEE 1671 802.11 Station (see Section 6.13) message element, and MUST NOT be 1672 sent if the WTP had not specifically advertised support for the 1673 requested encryption scheme. 1675 The RSN information element MUST sent along with the IEEE 802.11 1676 Station Session Key in order to instruct the WTP on the usage of the 1677 Key field. The AKM field of the RSM information element is used by 1678 the WTP to identify the authentication protocol. 1680 If the IEEE 802.11 Station Session Key message element's AKM-Only bit 1681 is set, the WTP MUST drop all IEEE 802.11 packets that are not part 1682 of the AKM (e.g., EAP). Note that AKM-Only is MAY be set while an 1683 encryption key is in force, requiring that the AKM packets be 1684 encrypted. Once the station has successfully completed 1685 authentication via the AKM, the AC MUST send a new Add Station 1686 message element to remove the AKM-Only restriction, and optionally 1687 push the session key down to the WTP. 1689 0 1 2 3 1690 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 1691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1692 | MAC Address | 1693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1694 | MAC Address |A|C| Flags | 1695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1696 | Pairwise TSC | 1697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1698 | Pairwise TSC | Pairwise RSC | 1699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1700 | Pairwise RSC | 1701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1702 | Key... 1703 +-+-+-+-+-+-+-+- 1705 Type: 1038 for IEEE 802.11 Station Session Key 1707 Length: >= 25 1709 MAC Address: The station's MAC Address 1711 Flags: All implementations complying with this protocol MUST set to 1712 zero any bits that are reserved in the version of the protocol 1713 supported by that implementation. Receivers MUST ignore all bits 1714 not defined for the version of the protocol they support. The 1715 following bits are defined: 1717 A: The one bit AKM-Only field is set by the AC to inform the WTP 1718 that is MUST NOT accept any 802.11 data frames, other than AKM 1719 frames. This is the equivalent of the WTP's IEEE 802.1X port 1720 for the station to be in the closed state. When set, the WTP 1721 MUST drop any non-IEEE 802.1X packets it receives from the 1722 station. 1724 C: The one bit field is set by the AC to inform the WTP that 1725 encryption services will be provided by the AC. When set, the 1726 WTP SHOULD police frames received from stations to ensure that 1727 are properly encrypted as specified in the RSN Information 1728 Element, but does not need to take specific cryptographic 1729 action on the frame. Similarly, for transmitted frames, the 1730 WTP only needs to forward already encrypted frames. 1732 Pairwise TSC: The 6 byte Transmit Sequence Counter (TSC) field to 1733 use for unicast packets transmitted to the station. 1735 Pairwise RSC: The 6 byte Receive Sequence Counter (RSC) to use for 1736 unicast packets received from the station. 1738 Key: The key the WTP is to use when encrypting traffic to/from the 1739 station. For dynamically created keys, this is commonly known as 1740 a Pairwise Transient Key (PTK). 1742 6.16. IEEE 802.11 Statistics 1744 The IEEE 802.11 Statistics message element is sent by the WTP to 1745 transmit its current statistics, and contains the following fields. 1747 0 1 2 3 1748 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 1749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1750 | Radio ID | Reserved | 1751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1752 | Tx Fragment Count | 1753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1754 | Multicast Tx Count | 1755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1756 | Failed Count | 1757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1758 | Retry Count | 1759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1760 | Multiple Retry Count | 1761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1762 | Frame Duplicate Count | 1763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1764 | RTS Success Count | 1765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1766 | RTS Failure Count | 1767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1768 | ACK Failure Count | 1769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1770 | Rx Fragment Count | 1771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1772 | Multicast RX Count | 1773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1774 | FCS Error Count | 1775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1776 | Tx Frame Count | 1777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1778 | Decryption Errors | 1779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1780 | Discarded QoS Fragment Count | 1781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1782 | Associated Station Count | 1783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1784 | QoS CF Polls Received Count | 1785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1786 | QoS CF Polls Unused Count | 1787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1788 | QoS CF Polls Unusable Count | 1789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1791 Type: 1039 for IEEE 802.11 Statistics 1793 Length: 60 1795 Radio ID: An 8-bit value representing the radio. 1797 Reserved: All implementations complying with this protocol MUST set 1798 to zero any bits that are reserved in the version of the protocol 1799 supported by that implementation. Receivers MUST ignore all bits 1800 not defined for the version of the protocol they support. 1802 Tx Fragment Count: A 32-bit value representing the number of 1803 fragmented frames transmitted. The value of this field comes from 1804 the IEEE 802.11 dot11TransmittedFragmentCount MIB element (see 1805 [2]). 1807 Multicast Tx Count: A 32-bit value representing the number of 1808 multicast frames transmitted. The value of this field comes from 1809 the IEEE 802.11 dot11MulticastTransmittedFrameCount MIB element 1810 (see [2]). 1812 Failed Count: A 32-bit value representing the transmit excessive 1813 retries. The value of this field comes from the IEEE 802.11 1814 dot11FailedCount MIB element (see [2]). 1816 Retry Count: A 32-bit value representing the number of transmit 1817 retries. The value of this field comes from the IEEE 802.11 1818 dot11RetryCount MIB element (see [2]). 1820 Multiple Retry Count: A 32-bit value representing the number of 1821 transmits that required more than one retry. The value of this 1822 field comes from the IEEE 802.11 dot11MultipleRetryCount MIB 1823 element (see [2]). 1825 Frame Duplicate Count: A 32-bit value representing the duplicate 1826 frames received. The value of this field comes from the IEEE 1827 802.11 dot11FrameDuplicateCount MIB element (see [2]). 1829 RTS Success Count: A 32-bit value representing the number of 1830 successfully transmitted Ready To Send (RTS). The value of this 1831 field comes from the IEEE 802.11 dot11RTSSuccessCount MIB element 1832 (see [2]). 1834 RTS Failure Count: A 32-bit value representing the failed 1835 transmitted RTS. The value of this field comes from the IEEE 1836 802.11 dot11RTSFailureCount MIB element (see [2]). 1838 ACK Failure Count: A 32-bit value representing the number of failed 1839 acknowledgements. The value of this field comes from the IEEE 1840 802.11 dot11ACKFailureCount MIB element (see [2]). 1842 Rx Fragment Count: A 32-bit value representing the number of 1843 fragmented frames received. The value of this field comes from 1844 the IEEE 802.11 dot11ReceivedFragmentCount MIB element (see [2]). 1846 Multicast RX Count: A 32-bit value representing the number of 1847 multicast frames received. The value of this field comes from the 1848 IEEE 802.11 dot11MulticastReceivedFrameCount MIB element (see 1849 [2]). 1851 FCS Error Count: A 32-bit value representing the number of FCS 1852 failures. The value of this field comes from the IEEE 802.11 1853 dot11FCSErrorCount MIB element (see [2]). 1855 Decryption Errors: A 32-bit value representing the number of 1856 Decryption errors that occurred on the WTP. Note that this field 1857 is only valid in cases where the WTP provides encryption/ 1858 decryption services. The value of this field comes from the IEEE 1859 802.11 dot11WEPUndecryptableCount MIB element (see [2]). 1861 Discarded QoS Fragment Count: A 32-bit value representing the 1862 number of discarded QoS fragments received. The value of this 1863 field comes from the IEEE 802.11 dot11QoSDiscardedFragmentCount 1864 MIB element (see [2]). 1866 Associated Station Count: A 32-bit value representing the number of 1867 number of associated stations. The value of this field comes from 1868 the IEEE 802.11 dot11AssociatedStationCount MIB element (see [2]). 1870 QoS CF Polls Received Count: A 32-bit value representing the number 1871 of (+)CF-Polls received. The value of this field comes from the 1872 IEEE 802.11 dot11QosCFPollsReceivedCount MIB element (see [2]). 1874 QoS CF Polls Unused Count: A 32-bit value representing the number 1875 of (+)CF-Polls that have been received, but not used. The value 1876 of this field comes from the IEEE 802.11 1877 dot11QosCFPollsUnusedCount MIB element (see [2]). 1879 QoS CF Polls Unusable Count: A 32-bit value representing the number 1880 of (+)CF-Polls that have been received, but could not be used due 1881 to the TXOP size being smaller than the timethat is required for 1882 one frame exchange sequence. The value of this field comes from 1883 the IEEE 802.11 dot11QosCFPollsUnusableCount MIB element (see 1884 [2]). 1886 6.17. IEEE 802.11 Supported Rates 1888 The IEEE 802.11 Supported Rates message element is sent by the WTP to 1889 indicate the rates that it supports, and contains the following 1890 fields. 1892 0 1 2 3 1893 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 1894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1895 | Radio ID | Supported Rates... 1896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1898 Type: 1040 for IEEE 802.11 Supported Rates 1900 Length: >= 3 1902 Radio ID: An 8-bit value representing the radio. 1904 Supported Rates: The WTP includes the Supported Rates that its 1905 hardware supports. The format is identical to the Rate Set 1906 message element and is between 2 and 8 bytes in length. 1908 6.18. IEEE 802.11 Tx Power 1910 The IEEE 802.11 Tx Power message element value is bi-directional. 1911 When sent by the WTP, it contains the current power level of the 1912 radio in question. When sent by the AC, it contains the power level 1913 the WTP MUST adhere to. 1915 0 1 2 3 1916 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 1917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1918 | Radio ID | Reserved | Current Tx Power | 1919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1921 Type: 1041 for IEEE 802.11 Tx Power 1923 Length: 4 1925 Radio ID: An 8-bit value representing the radio to configure. 1927 Reserved: All implementations complying with this protocol MUST set 1928 to zero any bits that are reserved in the version of the protocol 1929 supported by that implementation. Receivers MUST ignore all bits 1930 not defined for the version of the protocol they support. 1932 Current Tx Power: This attribute contains the current transmit 1933 output power in mW, as described in the dot11CurrentTxPowerLevel 1934 MIB variable, see [2]. 1936 6.19. IEEE 802.11 Tx Power Level 1938 The IEEE 802.11 Tx Power Level message element is sent by the WTP and 1939 contains the different power levels supported. The values found in 1940 this message element are found in the IEEE 802.11 1941 Dot11PhyTxPowerEntry MIB table, see [2]. 1943 The value field contains the following: 1945 0 1 2 3 1946 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 1947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1948 | Radio ID | Num Levels | Power Level [n] | 1949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1951 Type: 1042 for IEEE 802.11 Tx Power Level 1953 Length: >= 4 1955 Radio ID: An 8-bit value representing the radio to configure. 1957 Num Levels: The number of power level attributes. The value of 1958 this field comes from the IEEE 802.11 1959 dot11NumberSupportedPowerLevels MIB element (see [2]). 1961 Power Level: Each power level fields contains a supported power 1962 level, in mW. The value of this field comes from the 1963 corresponding IEEE 802.11 dot11TxPowerLevel[n] MIB element, see 1964 [2]. 1966 6.20. IEEE 802.11 Update Station QoS 1968 The IEEE 802.11 Update Station QoS message element is used to change 1969 the Quality of Service policy on the WTP for a given station. 1971 0 1 2 3 1972 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 1973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1974 | Radio ID | MAC Address | 1975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1976 | MAC Address | DSCP Tag | 802.1P Tag | 1977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1979 Type: 1043 for IEEE 802.11 Update Station QoS 1981 Length: 8 1983 Radio ID: The Radio Identifier, typically refers to some interface 1984 index on the WTP 1986 MAC Address: The station's MAC Address. 1988 DSCP Tag: The DSCP label to use if packets are to be DSCP tagged. 1990 802.1P Tag: The 802.1P precedence value to use if packets are to be 1991 IEEE 802.1P tagged. 1993 6.21. IEEE 802.11 Update WLAN 1995 The IEEE 802.11 Update WLAN message element is used by the AC to 1996 define a wireless LAN on the WTP. The inclusion of this message 1997 element MUST also include the IEEE 802.11 Information Element message 1998 element, containing the following 802.11 IEs: 2000 Power Capability information element 2002 WPA information element 2004 RSN information element 2006 EDCA Parameter Set information element 2008 QoS Capability information element 2010 WMM information element 2012 The message element uses the following format: 2014 0 1 2 3 2015 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 2016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2017 | Radio ID | WLAN ID | Capability | 2018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2019 | Key Index | Key Status | Key Length | 2020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2021 | Key... | 2022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2024 Type: 1044 for IEEE 802.11 Update WLAN 2026 Length: 43 2028 Radio ID: An 8-bit value representing the radio. 2030 WLAN ID: An 8-bit value specifying the WLAN Identifier. 2032 Capability: A 16-bit value containing the capabilities information 2033 field to be advertised by the WTP within the Probe and Beacon 2034 messages. 2036 Key-Index: The Key Index associated with the key. 2038 Key Status: A 1 byte value that specifies the state and usage of 2039 the key that has been included. The following values describe the 2040 key usage and its status: 2042 0 - A value of zero, with the inclusion of the RSN Information 2043 Element means that the WLAN uses per-station encryption keys, and 2044 therefore the key in the 'Key' field is only used for multicast 2045 traffic. 2047 1 - When set to one, the WLAN employs a shared WEP key, also known 2048 as a static WEP key, and uses the encryption key for both unicast 2049 and multicast traffic for all stations. 2051 2 - The value of 2 indicates that the AC will begin rekeying the GTK 2052 with the STA's in the BSS. It is only valid when IEEE 802.11 is 2053 enabled as the security policy for the BSS. 2055 3 - The value of 3 indicates that the AC has completed rekeying the 2056 GTK and broadcast packets no longer need to be duplicated and 2057 transmitted with both GTK's. 2059 Key Length: A 16-bit value representing the length of the Key 2060 field. 2062 Key: A 32 byte Session Key to use to provide data privacy. For 2063 static WEP keys, which is true when the 'Key Status' bit is set to 2064 one, this key is used for both unicast and multicast traffic. For 2065 encryption schemes that employ a separate encryption key for 2066 unicast and multicast traffic, the key included hereonly applies 2067 to multicast data, and the cipher suite is specified in an 2068 accompanied RSN Information Element. In these scenarios, the key, 2069 and cipher information, is communicated via the Add Station 2070 message element, see Section 4.5.8 in [3]. 2072 6.22. IEEE 802.11 WTP Quality of Service 2074 The IEEE 802.11 WTP Quality of Service message element value is sent 2075 by the AC to the WTP to communicate quality of service configuration 2076 information. 2078 0 1 2079 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2081 | Radio ID | Tag Packets | 2082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2084 Type: 1045 for IEEE 802.11 WTP Quality of Service 2086 Length: >= 2 2088 Radio ID: The Radio Identifier, typically refers to some interface 2089 index on the WTP 2091 Tag Packets: A value indicating whether CAPWAP packets should be 2092 tagged for QoS purposes. The following values are currently 2093 supported: 2095 0 - Untagged 2097 1 - 802.1P 2099 2 - DSCP 2101 Immediately following the above header is the following data 2102 structure. This data structure will be repeated five times; once 2103 for every QoS profile. The order of the QoS profiles are Voice, 2104 Video, Best Effort and Background. 2106 0 1 2 3 2107 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 2108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2109 | Queue Depth | CWMin | CWMax | 2110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2111 | CWMax | AIFS | Dot1P Tag | DSCP Tag | 2112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2114 Queue Depth: The number of packets that can be on the specific QoS 2115 transmit queue at any given time. 2117 CWMin: The Contention Window minimum value for the QoS transmit 2118 queue. The value of this field comes from the IEEE 802.11 2119 dot11EDCATableCWMin MIB element (see [2]). 2121 CWMax: The Contention Window maximum value for the QoS transmit 2122 queue. The value of this field comes from the IEEE 802.11 2123 dot11EDCATableCWMax MIB element (see [2]). 2125 AIFS: The Arbitration Inter Frame Spacing to use for the QoS 2126 transmit queue. The value of this field comes from the IEEE 2127 802.11 dot11EDCATableAIFSN MIB element (see [2]). 2129 Dot1P Tag: The 802.1P precedence value to use if packets are to be 2130 802.1P tagged. 2132 DSCP Tag: The DSCP label to use if packets are to be DSCP tagged. 2134 6.23. IEEE 802.11 WTP Radio Configuration 2136 The IEEE 802.11 WTP WLAN Radio Configuration message element is used 2137 by the AC to configure a Radio on the WTP, and by the WTP to deliver 2138 its radio configuration to the AC. The message element value 2139 contains the following fields: 2141 0 1 2 3 2142 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 2143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2144 | Radio ID |Short Preamble| Num of BSSIDs | DTIM Period | 2145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2146 | BSSID | 2147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2148 | BSSID | Beacon Period | 2149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2150 | Country Code | 2151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2153 Type: 1046 for IEEE 802.11 WTP WLAN Radio Configuration 2155 Length: 16 2157 Radio ID: An 8-bit value representing the radio to configure. 2159 Short Preamble: An 8-bit value indicating whether short preamble is 2160 supported. The following values are currently supported: 2162 0 - Short preamble not supported. 2164 1 - Short preamble is supported. 2166 BSSID: The WLAN Radio's base MAC Address. 2168 Number of BSSIDs: This attribute contains the maximum number of 2169 BSSIDs supported by the WTP. This value restricts the number of 2170 logical networks supported by the WTP, and is between 1 and 16. 2172 DTIM Period: This attribute specifies the number of beacon 2173 intervals that elapse between transmission of Beacons frames 2174 containing a TIM element whose DTIM Count field is 0. This value 2175 is transmitted in the DTIM Period field of Beacon frames. The 2176 value of this field comes from the IEEE 802.11 dot11DTIMPeriod MIB 2177 element (see [2]). 2179 Beacon Period: This attribute specifies the number of TU that a 2180 station uses for scheduling Beacon transmissions. This value is 2181 transmitted in Beacon and Probe Response frames. The value of 2182 this field comes from the IEEE 802.11 dot11BeaconPeriod MIB 2183 element (see [2]). 2185 Country Code: This attribute identifies the country in which the 2186 station is operating. The value of this field comes from the IEEE 2187 802.11 dot11CountryString MIB element (see [2]). Special 2188 attention is required with use of this field, as implementations 2189 which take action based on this field could violate regulatory 2190 requirements. Some regulatory bodies do permit configuration of 2191 the country code under certain restrictions, such as the FCC, when 2192 WTPs are certified as Software Defined Radios. 2194 The WTP and AC MAY ignore the value of this field, depending upon 2195 regulatory requirements, for example to avoid classification as a 2196 Software Defined Radio. When this field is used, the first two 2197 octets of this string is the two character country code as 2198 described in document ISO/IEC 3166- 1, and the third octet MUST 2199 have the value 1, 2 or 3 as defined below. When the value of the 2200 third octet is 255, the country code field is not used, and MUST 2201 be ignored. 2203 1 an ASCII space character, if the regulations under which the 2204 station is operating encompass all environments in the country, 2206 2 an ASCII 'O' character, if the regulations under which the 2207 station is operating are for an outdoor environment only, or 2209 3 an ASCII 'I' character, if the regulations under which the 2210 station is operating are for an indoor environment only 2212 255 Country Code field is not used; ignore the field. 2214 6.24. IEEE 802.11 WTP Radio Fail Alarm Indication 2216 The IEEE 802.11 WTP Radio Fail Alarm Indication message element is 2217 sent by the WTP to the AC when it detects a radio failure. 2219 0 1 2 3 2220 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2222 | Radio ID | Type | Status | Pad | 2223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2225 Type: 1047 for IEEE 802.11 WTP Radio Fail Alarm Indication 2227 Length: 4 2229 Radio ID: The Radio Identifier, typically refers to some interface 2230 index on the WTP 2232 Type: The type of radio failure detected. The following values are 2233 supported: 2235 1 - Receiver 2237 2 - Transmitter 2239 Status: An 8-bit boolean indicating whether the radio failure is 2240 being reported or cleared. A value of zero is used to clear the 2241 event, while a value of one is used to report the event. 2243 Pad: All implementations complying with version zero of this 2244 protocol MUST set these bits to zero. Receivers MUST ignore all 2245 bits not defined for the version of the protocol they support. 2247 6.25. IEEE 802.11 WTP Radio Information 2249 The IEEE 802.11 WTP Radio Information message element is used to 2250 communicate the radio information for each IEEE 802.11 radio in the 2251 WTP. The Discovery Request message, Primary Discovery Request 2252 message and Join Request message MUST include one such message 2253 element per radio in the WTP. The Radio-Type field is used by the AC 2254 in order to determine which IEEE 802.11 technology specific binding 2255 is to be used with the WTP. 2257 The message element contains two fields, as shown below. 2259 0 1 2 3 2260 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 2261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2262 | Radio ID | Radio Type | 2263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2264 | Radio Type | 2265 +-+-+-+-+-+-+-+-+ 2267 Type: 1048 for IEEE 802.11 WTP Radio Information 2269 Length: 5 2271 Radio ID: The Radio Identifier, which typically refers to an 2272 interface index on the WTP 2274 Radio Type: The type of radio present. Note this bitfield can be 2275 used to specify support for more than a single type of PHY/MAC. 2276 The following values are supported: 2278 1 - 802.11b: An IEEE 802.11b radio. 2280 2 - 802.11a: An IEEE 802.11a radio. 2282 4 - 802.11g: An IEEE 802.11g radio. 2284 8 - 802.11n: An IEEE 802.11n radio. 2286 0xOF - 802.11b, 802.11a, 802.11g and 802.11n: The 4 radio types 2287 indicated are supported in the WTP. 2289 7. IEEE 802.11 Binding WTP Saved Variables 2291 This section contains the IEEE 802.11 binding specific variables that 2292 SHOULD be saved in non-volatile memory on the WTP. 2294 7.1. IEEE80211AntennaInfo 2296 The WTP per radio antenna configuration, defined in Section 6.2. 2298 7.2. IEEE80211DSControl 2300 The WTP per radio Direct Sequence Control configuration, defined in 2301 Section 6.5. 2303 7.3. IEEE80211MACOperation 2305 The WTP per radio MAC Operation configuration, defined in 2306 Section 6.7. 2308 7.4. IEEE80211OFDMControl 2310 The WTP per radio MAC Operation configuration, defined in 2311 Section 6.10. 2313 7.5. IEEE80211Rateset 2315 The WTP per radio Basic Rate Set configuration, defined in 2316 Section 6.11. 2318 7.6. IEEE80211TxPower 2320 The WTP per radio Transmit Power configuration, defined in 2321 Section 6.18. 2323 7.7. IEEE80211QoS 2325 The WTP per radio Quality of Service configuration, defined in 2326 Section 6.22. 2328 7.8. IEEE80211RadioConfig 2330 The WTP per radio Radio Configuration, defined in Section 6.23. 2332 8. Technology Specific Message Element Values 2334 This section lists IEEE 802.11 specific values for the generic CAPWAP 2335 message elements which include fields whose values are technology 2336 specific. 2338 IEEE 802.11 uses the following values: 2340 4 - Encrypt AES-CCMP 128: WTP supports AES-CCMP, as defined in [4]. 2342 5 - Encrypt TKIP-MIC: WTP supports TKIP and Michael, as defined in 2343 [7]. 2345 9. Security Considerations 2347 This section describes security considerations for using IEEE 802.11 2348 with the CAPWAP protocol. 2350 9.1. IEEE 802.11 Security 2352 When used with an IEEE 802.11 infrastructure with WEP encryption, the 2353 CAPWAP protocol does not add any new vulnerabilities. Derived 2354 session keys between the STA and WTP can be compromised, resulting in 2355 many well-documented attacks. Implementors SHOULD discourage the use 2356 of WEP and encourage use of technically sound cryptographic solutions 2357 such as those in an IEEE 802.11 RSN. 2359 STA authentication is performed using IEEE 802.lX, and consequently 2360 EAP. Implementors SHOULD use EAP methods meeting the requirements 2361 specified [5]. 2363 When used with IEEE 802.11 RSN security, the CAPWAP protocol may 2364 introduce new vulnerabilities, depending on whether the link security 2365 (packet encryption and integrity verification) is provided by the WTP 2366 or the AC. When the link security function is provided by the AC, no 2367 new security concerns are introduced. 2369 However, when the WTP provides link security, a new vulnerability 2370 will exist when the following conditions are true: 2372 o The client is not the first to associate to the WTP/ESSID (i.e. 2373 other clients are associated), and a GTK already exists 2375 o traffic has been broadcast under the existing GTK 2377 Under these circumstances, the receive sequence counter (KeyRSC) 2378 associated with the GTK is non-zero, but because the AC anchors the 2379 4-way handshake with the client, the exact value of the KeyRSC is not 2380 known when the AC constructs the message containing the GTK. The 2381 client will update its Key RSC value to the current valid KeyRSC upon 2382 receipt of a valid multicast/broadcast message, but prior to this, 2383 previous multicast/broadcast traffic which was secured with the 2384 existing GTK may be replayed, and the client will accept this traffic 2385 as valid. 2387 Typically, busy networks will produce numerous multicast or broadcast 2388 frames per second, so the window of opportunity with respect to such 2389 replay is expected to be very small. In most conditions, it is 2390 expected that replayed frames could be detected (and logged) by the 2391 WTP. 2393 The only way to completely close this window is to provide the exact 2394 KeyRSC value in message 3 of the 4-way handshake; any other approach 2395 simply narrows the window to varying degrees. Given the low relative 2396 threat level this presents, the additional complexity introduced by 2397 providing the exact KeyRSC value is not warranted. That is, this 2398 specification provides for a calculated risk in this regard. 2400 The AC SHOULD use an RSC of 0 when computing message-3 of the 4-way 2401 802.11i handshake, unless the AC has knowledge of a more optimal RSC 2402 value to use. Mechanisms for determining a more optimal RSC value 2403 are outside the scope of this specification. 2405 10. IANA Considerations 2407 There are no IANA Considerations. 2409 11. Acknowledgements 2411 The following individuals are acknowledged for their contributions to 2412 this binding specification: Puneet Agarwal, Charles Clancy, Saravanan 2413 Govindan, Scott Kelly, Peter Nilsson, Bob O'Hara, David Perkins and 2414 Margaret Wasserman. 2416 12. References 2418 12.1. Normative References 2420 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2421 Levels", BCP 14, RFC 2119, March 1997. 2423 [2] "Information technology - Telecommunications and information 2424 exchange between systems - Local and metropolitan area networks 2425 - Specific requirements - Part 11: Wireless LAN Medium Access 2426 Control (MAC) and Physical Layer (PHY) specifications", 2427 IEEE Standard 802.11, 1999, 2428 . 2430 [3] Calhoun, P., Montemurro, M., Stanley, D., "CAPWAP Protocol 2431 Specification", draft-ietf-capwap-protocol-specification-07 2432 (work in progress), June 2007. 2434 [4] "Information technology - Telecommunications and information 2435 exchange between systems - Local and metropolitan area networks 2436 - Specific requirements - Part 11: Wireless LAN Medium Access 2437 Control (MAC) and Physical Layer (PHY) specifications Amendment 2438 6: Medium Access Control (MAC) Security Enhancements", 2439 IEEE Standard 802.11i, July 2004, 2440 . 2443 12.2. Informational References 2445 [5] Stanley, D., Walker, J., and B. Aboba, "Extensible 2446 Authentication Protocol (EAP) Method Requirements for Wireless 2447 LANs", RFC 4017, March 2005. 2449 [6] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy for 2450 Control and Provisioning of Wireless Access Points (CAPWAP)", 2451 RFC 4118, June 2005. 2453 [7] "WiFi Protected Access (WPA), WPAfor802.11ver3_073004.pdf", 2454 August 2004. 2456 Editors' Addresses 2458 Pat R. Calhoun 2459 Cisco Systems, Inc. 2460 170 West Tasman Drive 2461 San Jose, CA 95134 2463 Phone: +1 408-853-5269 2464 Email: pcalhoun@cisco.com 2466 Michael P. Montemurro 2467 Research In Motion 2468 5090 Commerce Blvd 2469 Mississauga, ON L4W 5M4 2470 Canada 2472 Phone: +1 905-629-4746 x4999 2473 Email: mmontemurro@rim.com 2475 Dorothy Stanley 2476 Aruba Networks 2477 1322 Crossman Ave 2478 Sunnyvale, CA 94089 2480 Phone: +1 630-363-1389 2481 Email: dstanley@arubanetworks.com 2483 Full Copyright Statement 2485 Copyright (C) The IETF Trust (2007). 2487 This document is subject to the rights, licenses and restrictions 2488 contained in BCP 78, and except as set forth therein, the authors 2489 retain all their rights. 2491 This document and the information contained herein are provided on an 2492 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2493 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2494 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2495 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2496 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2497 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2499 Intellectual Property 2501 The IETF takes no position regarding the validity or scope of any 2502 Intellectual Property Rights or other rights that might be claimed to 2503 pertain to the implementation or use of the technology described in 2504 this document or the extent to which any license under such rights 2505 might or might not be available; nor does it represent that it has 2506 made any independent effort to identify any such rights. Information 2507 on the procedures with respect to rights in RFC documents can be 2508 found in BCP 78 and BCP 79. 2510 Copies of IPR disclosures made to the IETF Secretariat and any 2511 assurances of licenses to be made available, or the result of an 2512 attempt made to obtain a general license or permission for the use of 2513 such proprietary rights by implementers or users of this 2514 specification can be obtained from the IETF on-line IPR repository at 2515 http://www.ietf.org/ipr. 2517 The IETF invites any interested party to bring to its attention any 2518 copyrights, patents or patent applications, or other proprietary 2519 rights that may cover technology that may be required to implement 2520 this standard. Please address the information to the IETF at 2521 ietf-ipr@ietf.org. 2523 Acknowledgment 2525 Funding for the RFC Editor function is provided by the IETF 2526 Administrative Support Activity (IASA).