GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5416

Network Working Group P. Calhoun, Ed. Request for Comments: 5416 Cisco Systems, Inc. Category: Standards Track M. Montemurro, Ed.

                                                    Research In Motion
                                                       D. Stanley, Ed.
                                                        Aruba Networks
                                                            March 2009
Control and Provisioning of Wireless Access Points (CAPWAP) Protocol
                      Binding for IEEE 802.11

Status of This Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

 Copyright (c) 2009 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents in effect on the date of
 publication of this document (http://trustee.ietf.org/license-info).
 Please review these documents carefully, as they describe your rights
 and restrictions with respect to this document.
 This document may contain material from IETF Documents or IETF
 Contributions published or made publicly available before November
 10, 2008.  The person(s) controlling the copyright in some of this
 material may not have granted the IETF Trust the right to allow
 modifications of such material outside the IETF Standards Process.
 Without obtaining an adequate license from the person(s) controlling
 the copyright in such materials, this document may not be modified
 outside the IETF Standards Process, and derivative works of it may
 not be created outside the IETF Standards Process, except to format
 it for publication as an RFC or to translate it into languages other
 than English.

Calhoun, et al. Standards Track [Page 1] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

Abstract

 Wireless LAN product architectures have evolved from single
 autonomous access points to systems consisting of a centralized
 Access Controller (AC) and Wireless Termination Points (WTPs).  The
 general goal of centralized control architectures is to move access
 control, including user authentication and authorization, mobility
 management, and radio management from the single access point to a
 centralized controller.
 This specification defines the Control And Provisioning of Wireless
 Access Points (CAPWAP) Protocol Binding Specification for use with
 the IEEE 802.11 Wireless Local Area Network protocol.

Table of Contents

 1. Introduction ....................................................4
    1.1. Goals ......................................................5
    1.2. Conventions Used in This Document ..........................5
    1.3. Terminology ................................................5
 2. IEEE 802.11 Binding .............................................7
    2.1. CAPWAP Wireless Binding Identifier .........................7
    2.2. Split MAC and Local MAC Functionality ......................7
         2.2.1. Split MAC ...........................................7
         2.2.2. Local MAC ..........................................12
    2.3. Roaming Behavior ..........................................15
    2.4. Group Key Refresh .........................................16
    2.5. BSSID to WLAN ID Mapping ..................................17
    2.6. CAPWAP Data Channel QoS Behavior ..........................18
         2.6.1. IEEE 802.11 Data Frames ............................18
                2.6.1.1. 802.1p Support ............................19
                2.6.1.2. DSCP Support ..............................19
         2.6.2. IEEE 802.11 MAC Management Messages ................21
    2.7. Run State Operation .......................................21
 3. IEEE 802.11 Specific CAPWAP Control Messages ...................21
    3.1. IEEE 802.11 WLAN Configuration Request ....................22
    3.2. IEEE 802.11 WLAN Configuration Response ...................23
 4. CAPWAP Data Message Bindings ...................................23
 5. CAPWAP Control Message Bindings ................................25
    5.1. Discovery Request Message .................................25
    5.2. Discovery Response Message ................................25
    5.3. Primary Discovery Request Message .........................25
    5.4. Primary Discovery Response Message ........................26
    5.5. Join Request Message ......................................26
    5.6. Join Response Message .....................................26
    5.7. Configuration Status Request Message ......................26
    5.8. Configuration Status Response Message .....................27
    5.9. Configuration Update Request Message ......................27

Calhoun, et al. Standards Track [Page 2] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

    5.10. Station Configuration Request ............................28
    5.11. Change State Event Request ...............................28
    5.12. WTP Event Request ........................................28
 6. IEEE 802.11 Message Element Definitions ........................29
    6.1. IEEE 802.11 Add WLAN ......................................29
    6.2. IEEE 802.11 Antenna .......................................35
    6.3. IEEE 802.11 Assigned WTP BSSID ............................36
    6.4. IEEE 802.11 Delete WLAN ...................................37
    6.5. IEEE 802.11 Direct Sequence Control .......................37
    6.6. IEEE 802.11 Information Element ...........................38
    6.7. IEEE 802.11 MAC Operation .................................39
    6.8. IEEE 802.11 MIC Countermeasures ...........................41
    6.9. IEEE 802.11 Multi-Domain Capability .......................42
    6.10. IEEE 802.11 OFDM Control .................................43
    6.11. IEEE 802.11 Rate Set .....................................44
    6.12. IEEE 802.11 RSNA Error Report From Station ...............44
    6.13. IEEE 802.11 Station ......................................46
    6.14. IEEE 802.11 Station QoS Profile ..........................47
    6.15. IEEE 802.11 Station Session Key ..........................48
    6.16. IEEE 802.11 Statistics ...................................50
    6.17. IEEE 802.11 Supported Rates ..............................54
    6.18. IEEE 802.11 Tx Power .....................................54
    6.19. IEEE 802.11 Tx Power Level ...............................55
    6.20. IEEE 802.11 Update Station QoS ...........................56
    6.21. IEEE 802.11 Update WLAN ..................................57
    6.22. IEEE 802.11 WTP Quality of Service .......................61
    6.23. IEEE 802.11 WTP Radio Configuration ......................63
    6.24. IEEE 802.11 WTP Radio Fail Alarm Indication ..............65
    6.25. IEEE 802.11 WTP Radio Information ........................66
 7. IEEE 802.11 Binding WTP Saved Variables ........................67
    7.1. IEEE80211AntennaInfo ......................................67
    7.2. IEEE80211DSControl ........................................67
    7.3. IEEE80211MACOperation .....................................67
    7.4. IEEE80211OFDMControl ......................................67
    7.5. IEEE80211Rateset ..........................................67
    7.6. IEEE80211TxPower ..........................................67
    7.7. IEEE80211QoS ..............................................68
    7.8. IEEE80211RadioConfig ......................................68
 8. Technology Specific Message Element Values .....................68
    8.1. WTP Descriptor Message Element, Encryption
         Capabilities Field ........................................68
 9. Security Considerations ........................................68
    9.1. IEEE 802.11 Security ......................................68
 10. IANA Considerations ...........................................70
    10.1. CAPWAP Wireless Binding Identifier .......................70
    10.2. CAPWAP IEEE 802.11 Message Types .........................70
    10.3. CAPWAP Message Element Type ..............................70
    10.4. IEEE 802.11 Key Status ...................................71

Calhoun, et al. Standards Track [Page 3] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

    10.5. IEEE 802.11 QoS ..........................................71
    10.6. IEEE 802.11 Auth Type ....................................71
    10.7. IEEE 802.11 Antenna Combiner .............................71
    10.8. IEEE 802.11 Antenna Selection ............................72
    10.9. IEEE 802.11 Session Key Flags ............................72
    10.10. IEEE 802.11 Tagging Policy ..............................72
    10.11. IEEE 802.11 WTP Radio Fail ..............................72
    10.12. IEEE 802.11 WTP Radio Type ..............................73
    10.13. WTP Encryption Capabilities .............................73
 11. Acknowledgments ...............................................73
 12. References ....................................................73
    12.1. Normative References .....................................73
    12.2. Informative References ...................................75

1. Introduction

 The CAPWAP protocol [RFC5415] defines an extensible protocol to allow
 an Access Controller to manage wireless agnostic Wireless Termination
 Points.  The CAPWAP protocol itself does not include any specific
 wireless technologies; instead, it relies on a binding specification
 to extend the technology to a particular wireless technology.
 This specification defines the Control And Provisioning of Wireless
 Access Points (CAPWAP) Protocol Binding Specification for use with
 the IEEE 802.11 Wireless Local Area Network protocol.  Use of CAPWAP
 control message fields, new control messages, and message elements
 are defined.  The minimum required definitions for a binding-specific
 Statistics message element, Station message element, and WTP Radio
 Information message element are included.
 Note that this binding only supports the IEEE 802.11-2007
 specification.  Of note, this binding does not support the ad hoc
 network mode defined in the IEEE 802.11-2007 standard.  This
 specification also does not cover the use of data frames with the
 four-address format, commonly referred to as Wireless Bridges, whose
 use is not specified in the IEEE 802.11-2007 standard.  This protocol
 specification does not currently officially support IEEE 802.11n.
 That said, the protocol does allow a WTP to advertise support for an
 IEEE 802.11n radio; however, the protocol does not allow for any of
 the protocol's additional features to be configured and/or used.  New
 IEEE protocol specifications published outside of this document
 (e.g., IEEE 802.11v, IEEE 802.11r) are also not supported through
 this binding, and in addition to IEEE 802.11n, must be addressed
 either through a separate CAPWAP binding, or an update to this
 binding.

Calhoun, et al. Standards Track [Page 4] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

 In order to address immediate market needs for standards still being
 developed by the IEEE 802.11 standards body, the WiFi Alliance
 created interim pseudo-standards specifications.  Two such
 specifications are widely used in the industry, namely the WiFi
 Protect Access [WPA] and the WiFi MultiMedia [WMM] specifications.
 Given their widespread adoption, this CAPWAP binding requires the use
 of these two specifications.

1.1. Goals

 The goals of this CAPWAP protocol binding are to make the
 capabilities of the CAPWAP protocol available for use in conjunction
 with IEEE 802.11 wireless networks.  The capabilities to be made
 available can be summarized as:
 1. To centralize the authentication and policy enforcement functions
    for an IEEE 802.11 wireless network.  The AC may also provide
    centralized bridging, forwarding, and encryption of user traffic.
    Centralization of these functions will enable reduced cost and
    higher efficiency by applying the capabilities of network
    processing silicon to the wireless network, as in wired LANs.
 2. To enable shifting of the higher-level protocol processing from
    the WTP.  This leaves the time-critical applications of wireless
    control and access in the WTP, making efficient use of the
    computing power available in WTPs that are subject to severe cost
    pressure.
 The CAPWAP protocol binding extensions defined herein apply solely to
 the interface between the WTP and the AC.  Inter-AC and station-to-AC
 communication are strictly outside the scope of this document.

1.2. Conventions Used in This Document

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in RFC 2119 [RFC2119].

1.3. Terminology

 This section contains definitions for terms used frequently
 throughout this document.  However, many additional definitions can
 be found in [IEEE.802-11.2007].
 Access Controller (AC): The network entity that provides WTP access
 to the network infrastructure in the data plane, control plane,
 management plane, or a combination therein.

Calhoun, et al. Standards Track [Page 5] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

 Basic Service Set (BSS): A set of stations controlled by a single
 coordination function.
 Distribution: The service that, by using association information,
 delivers medium access control (MAC) service data units (MSDUs)
 within the distribution system (DS).
 Distribution System Service (DSS): The set of services provided by
 the distribution system (DS) that enable the medium access control
 (MAC) layer to transport MAC service data units (MSDUs) between
 stations that are not in direct communication with each other over a
 single instance of the wireless medium (WM).  These services include
 the transport of MSDUs between the access points (APs) of basic
 service sets (BSSs) within an extended service set (ESS), transport
 of MSDUs between portals and BSSs within an ESS, and transport of
 MSDUs between stations in the same BSS in cases where the MSDU has a
 multicast or broadcast destination address, or where the destination
 is an individual address but the station sending the MSDU chooses to
 involve the DSS.  DSSs are provided between pairs of IEEE 802.11
 MACs.
 Integration: The service that enables delivery of medium access
 control (MAC) service data units (MSDUs) between the distribution
 system (DS) and an existing, non-IEEE 802.11 local area network (via
 a portal).
 Station (STA): A device that contains an IEEE 802.11 conformant
 medium access control (MAC) and physical layer (PHY) interface to the
 wireless medium (WM).
 Portal: The logical point at which medium access control (MAC)
 service data units (MSDUs) from a non-IEEE 802.11 local area network
 (LAN) enter the distribution system (DS) of an extended service set
 (ESS).
 WLAN: In this document, WLAN refers to a logical component
 instantiated on a WTP device.  A single physical WTP may operate a
 number of WLANs.  Each Basic Service Set Identifier (BSSID) and its
 constituent wireless terminal radios is denoted as a distinct WLAN on
 a physical WTP.
 Wireless Termination Point (WTP): The physical or network entity that
 contains an IEEE 802.11 RF antenna and wireless PHY to transmit and
 receive station traffic for wireless access networks.

Calhoun, et al. Standards Track [Page 6] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

2. IEEE 802.11 Binding

 This section describes use of the CAPWAP protocol with the IEEE
 802.11 Wireless Local Area Network protocol, including Local and
 Split MAC operation, Group Key Refresh, Basic Service Set
 Identification (BSSID) to WLAN Mapping, IEEE 802.11 MAC management
 frame Quality of Service (Qos) tagging and Run State operation.

2.1. CAPWAP Wireless Binding Identifier

 The CAPWAP Header, defined in Section 4.3 of [RFC5415] requires that
 all CAPWAP binding specifications have a Wireless Binding Identifier
 (WBID) assigned.  This document, which defines the IEEE 802.11
 binding, uses the value one (1).

2.2. Split MAC and Local MAC Functionality

 The CAPWAP protocol, when used with IEEE 802.11 devices, requires
 specific behavior from the WTP and the AC to support the required
 IEEE 802.11 protocol functions.
 For both the Split and Local MAC approaches, the CAPWAP functions, as
 defined in the taxonomy specification [RFC4118], reside in the AC.
 To provide system component interoperability, the WTP and AC MUST
 support 802.11 encryption/decryption at the WTP.  The WTP and AC MAY
 support 802.11 encryption/decryption at the AC.

2.2.1. Split MAC

 This section shows the division of labor between the WTP and the AC
 in a Split MAC architecture.  Figure 1 shows the separation of
 functionality between CAPWAP components.

Calhoun, et al. Standards Track [Page 7] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

      Function                               Location
          Distribution Service                      AC
          Integration Service                       AC
          Beacon Generation                         WTP
          Probe Response Generation                 WTP
          Power Mgmt/Packet Buffering               WTP
          Fragmentation/Defragmentation             WTP/AC
          Assoc/Disassoc/Reassoc                    AC
     IEEE 802.11 QoS
          Classifying                               AC
          Scheduling                                WTP/AC
          Queuing                                   WTP
     IEEE 802.11 RSN
          IEEE 802.1X/EAP                           AC
          RSNA Key Management                       AC
          IEEE 802.11 Encryption/Decryption         WTP/AC
   Figure 1: Mapping of 802.11 Functions for Split MAC Architecture
 In a Split MAC Architecture, the Distribution and Integration
 services reside on the AC, and therefore all user data is tunneled
 between the WTP and the AC.  As noted above, all real-time IEEE
 802.11 services, including the Beacon and Probe Response frames, are
 handled on the WTP.
 All remaining IEEE 802.11 MAC management frames are supported on the
 AC, including the Association Request frame that allows the AC to be
 involved in the access policy enforcement portion of the IEEE 802.11
 protocol.  The IEEE 802.1X [IEEE.802-1X.2004], Extensible
 Authentication Protocol (EAP) [RFC3748] and IEEE Robust Security
 Network Association (RSNA) Key Management [IEEE.802-11.2007]
 functions are also located on the AC.  This implies that the
 Authentication, Authorization, and Accounting (AAA) client also
 resides on the AC.
 While the admission control component of IEEE 802.11 resides on the
 AC, the real-time scheduling and queuing functions are on the WTP.
 Note that this does not prevent the AC from providing additional
 policy and scheduling functionality.
 Note that in the following figure, the use of '( - )' indicates that
 processing of the frames is done on the WTP.  This figure represents
 a case where encryption services are provided by the AC.

Calhoun, et al. Standards Track [Page 8] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

           Client                      WTP                         AC
                    Beacon
           <-----------------------------
                 Probe Request
           ----------------------------( - )------------------------->
                 Probe Response
           <-----------------------------
                            802.11 AUTH/Association
           <--------------------------------------------------------->
                                      Station Configuration Request
                                        [Add Station (Station MAC
                                        Address), IEEE 802.11 Add
                                        Station (WLAN ID), IEEE
                                        802.11 Session Key(Flag=A)]
                                          <-------------------------->
                  802.1X Authentication & 802.11 Key Exchange
           <--------------------------------------------------------->
                                      Station Configuration Request
                                        [Add Station(Station MAC
                                        Address), IEEE 802.11 Add
                                        Station (WLAN ID), IEEE 802.11
                                        Station Session Key(Flag=C)]
                                          <-------------------------->
                             802.11 Action Frames
           <--------------------------------------------------------->
                                 802.11 DATA (1)
           <---------------------------( - )------------------------->
                   Figure 2: Split MAC Message Flow
 Figure 2 provides an illustration of the division of labor in a Split
 MAC architecture.  In this example, a WLAN has been created that is
 configured for IEEE 802.11, using 802.1X-based end user
 authentication and Advanced Encryption Standard-Counter Mode with
 CBC-MAC Protocol (AES-CCMP) link layer encryption (CCMP, see
 [FIPS.197.2001]).  The following process occurs:
 o  The WTP generates the IEEE 802.11 Beacon frames, using information
    provided to it through the IEEE 802.11 Add WLAN (see Section 6.1)
    message element, including the Robust Security Network Information
    Element (RSNIE), which indicates support of 802.1X and AES-CCMP.
 o  The WTP processes the Probe Request frame and responds with a
    corresponding Probe Response frame.  The Probe Request frame is
    then forwarded to the AC for optional processing.

Calhoun, et al. Standards Track [Page 9] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

 o  The WTP forwards the IEEEE 802.11 Authentication and Association
    frames to the AC, which is responsible for responding to the
    client.
 o  Once the association is complete, the AC transmits a Station
    Configuration Request message, which includes an Add Station
    message element, to the WTP (see Section 4.6.8 in [RFC5415]).  In
    the above example, the WLAN was configured for IEEE 802.1X, and
    therefore the IEEE 802.11 Station Session Key is included with the
    flag field's 'A' bit set.
 o  If the WTP is providing encryption/decryption services, once the
    client has completed the IEEE 802.11 key exchange, the AC
    transmits another Station Configuration Request message, which
    includes:
  1. An Add Station message element.
  1. An IEEE 802.11 Add Station message element, which includes the

WLAN Identifier with which the station has associated.

  1. An IEEE 802.11 Station Session Key message element, which

includes the pairwise encryption key.

  1. An IEEE 802.11 Information Element message element, which

includes the Robust Security Network Information Element

       (RSNIE) to the WTP, stating the security policy to enforce for
       the client (in this case AES-CCMP).
 o  If the WTP is providing encryption/decryption services, once the
    client has completed the IEEE 802.11 key exchange, the AC
    transmits another Station Configuration Request message, which
    includes:
  1. An Add Station message element.
  1. An IEEE 802.11 Add Station message element, which includes the

WLAN Identifier with which the station has associated.

  1. An IEEE 802.11 Station Session Key message element, which

includes the pairwise encryption key.

  1. An IEEE 802.11 Information Element message element, which

includes the Robust Security Network Information Element

       (RSNIE) to the WTP, stating the security policy to enforce for
       the client (in this case AES-CCMP).

Calhoun, et al. Standards Track [Page 10] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

 o  If the AC is providing encryption/decryption services, once the
    client has completed the IEEE 802.11 key exchange, the AC
    transmits another Station Configuration Request message, which
    includes:
  1. An Add Station message element.
  1. An IEEE 802.11 Add Station message element, which includes the

WLAN Identifier with which the station has associated.

  1. An IEEE 802.11 Station Session Key message element with the

flag field's 'C' bit enabled (indicating that the AC will

       provide crypto services).
 o  The WTP forwards any IEEE 802.11 Management Action frames received
    to the AC.
 o  All IEEE 802.11 station data frames are tunneled between the WTP
    and the AC.
 Note that during the EAP over LAN (EAPOL)-Key exchange between the
 Station and the AC, the Receive Sequence Counter (RSC) field for the
 Group Key (GTK) needs to be included in the frame.  The value of zero
 (0) is used by the AC during this exchange.  Additional details are
 available in Section 9.1.
 The WTP SHALL include the IEEE 802.11 MAC header contents in all
 frames transmitted to the AC.
 When 802.11 encryption/decryption is performed at the WTP, the WTP
 MUST decrypt the uplink frames, MUST set the Protected Frame field to
 0, and MUST make the frame format consistent with that of an
 unprotected 802.11 frame prior to transmitting the frames to the AC.
 The fields added to an 802.11 protected frame (i.e., Initialization
 Vector/Extended Initialization Vector (IV/EIV), Message Integrity
 Code (MIC), and Integrity Check Value (ICV)) MUST be stripped off
 prior to transmission from the WTP to AC.  For downlink frames, the
 Protected Frame field MUST be set to 0 by the AC as the frame being
 sent is unencrypted.  The WTP MUST apply the required protection
 policy for the WLAN, and set the Protected Frame field on
 transmission over the air.  The Protected Frame field always needs to
 accurately indicate the status of the 802.11 frame that is carrying
 it.
 When 802.11 encryption/decryption is performed at the AC, the WTP
 SHALL NOT decrypt the uplink frames prior to transmitting the frames
 to the AC.  The AC and WTP SHALL populate the IEEE 802.11 MAC header
 fields as described in Figure 3.

Calhoun, et al. Standards Track [Page 11] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

         MAC header field        Location
                 Frame Control:
                         Version         AC
                         ToDS            AC
                         FromDS          AC
                         Type            AC
                         SubType         AC
                         MoreFrag        WTP/AC
                         Retry           WTP
                         Pwr Mgmt        -
                         MoreData        WTP
                         Protected       WTP/AC
                         Order           AC
                 Duration:           WTP
                 Address 1:          AC
                 Address 2:          AC
                 Address 3:          AC
                 Sequence Ctrl:      WTP
                 Address 4:          AC
                 QoS Control:        AC
                 Frame Body:         AC
                 FCS:                WTP
     Figure 3: Population of the IEEE 802.11 MAC Header Fields for
                            Downlink Frames
 When 802.11 encryption/decryption is performed at the AC, the
 MoreFrag bit is populated at the AC.  The Pwr Mgmt bit is not
 applicable to downlink frames, and is set to 0.  Note that the Frame
 Check Sequence (FCS) field is not included in 802.11 frames exchanged
 between the WTP and the AC.  Upon sending data frames to the AC, the
 WTP is responsible for validating and stripping the FCS field.  Upon
 receiving data frames from the AC, the WTP is responsible for adding
 the FCS field, and populating the field as described in
 [IEEE.802-11.2007].
 Note that when the WTP tunnels data packets to the AC (and vice
 versa), the CAPWAP protocol does not guarantee in-order delivery.
 When the protocol being transported over IEEE 802.11 is IP, out-of-
 order delivery is not an issue as IP has no such requirements.
 However, implementers need to be aware of this protocol
 characteristic before deciding to use CAPWAP.

2.2.2. Local MAC

 This section shows the division of labor between the WTP and the AC
 in a Local MAC architecture.  Figure 4 shows the separation of
 functionality among CAPWAP components.

Calhoun, et al. Standards Track [Page 12] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

      Function                               Location
          Distribution Service                      WTP/AC
          Integration Service                       WTP
          Beacon Generation                         WTP
          Probe Response Generation                 WTP
          Power Mgmt/Packet Buffering               WTP
          Fragmentation/Defragmentation             WTP
          Assoc/Disassoc/Reassoc                    WTP/AC
     IEEE 802.11 QoS
          Classifying                               WTP
          Scheduling                                WTP
          Queuing                                   WTP
     IEEE 802.11 RSN
          IEEE 802.1X/EAP                           AC
          RSNA Key Management                       AC
          IEEE 802.11 Encryption/Decryption         WTP
    Figure 4: Mapping of 802.11 Functions for Local AP Architecture
 In the Local MAC mode, the integration service exists on the WTP,
 while the distribution service MAY reside on either the WTP or the
 AC.  When it resides on the AC, station-generated frames are not
 forwarded to the AC in their native format, but encapsulated as 802.3
 frames.
 While the MAC is terminated on the WTP, it is necessary for the AC to
 be aware of mobility events within the WTPs.  Thus, the WTP MUST
 forward the IEEE 802.11 Association Request frames to the AC.  The AC
 MAY reply with a failed Association Response frame if it deems it
 necessary, and upon receipt of a failed Association Response frame
 from the AC, the WTP MUST send a Disassociation frame to the station.
 The IEEE 802.1X [IEEE.802-1X.2004], EAP, and IEEE RSNA Key Management
 [IEEE.802-11.2007] functions reside in the AC.  Therefore, the WTP
 MUST forward all IEEE 802.1X, EAP, and RSNA Key Management frames to
 the AC and forward the corresponding responses to the station.  This
 implies that the AAA client also resides on the AC.
 Note that in the following figure, the use of '( - )' indicates that
 processing of the frames is done on the WTP.

Calhoun, et al. Standards Track [Page 13] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

           Client                      WTP                         AC
                    Beacon
           <-----------------------------
                     Probe
           <---------------------------->
                      802.11 AUTH
           <-----------------------------
                               802.11 Association
           <---------------------------( - )------------------------->
                                      Station Configuration Request
                                        [Add Station (Station MAC
                                        Address), IEEE 802.11 Add
                                        Station (WLAN ID), IEEE
                                        802.11 Session Key(Flag=A)]
                                          <-------------------------->
                  802.1X Authentication & 802.11 Key Exchange
           <--------------------------------------------------------->
                                      Station Configuration Request
                                        [Add Station(Station MAC
                                        Address), IEEE 802.11 Add
                                        Station (WLAN ID), IEEE 802.11
                                        Station session Key (Key=x),
                                        IEEE 802.11 Information
                                        Element(RSNIE(Pairwise
                                        Cipher=CCMP))]
                                          <-------------------------->
                             802.11 Action Frames
           <--------------------------------------------------------->
                   802.11 DATA
           <----------------------------->
                   Figure 5: Local MAC Message Flow
 Figure 5 provides an illustration of the division of labor in a Local
 MAC architecture.  In this example, a WLAN that is configured for
 IEEE 802.11 has been created using AES-CCMP for privacy.  The
 following process occurs:
 o  The WTP generates the IEEE 802.11 Beacon frames, using information
    provided to it through the Add WLAN (see Section 6.1) message
    element.
 o  The WTP processes a Probe Request frame and responds with a
    corresponding Probe Response frame.
 o  The WTP forwards the IEEE 802.11 Authentication and Association
    frames to the AC.

Calhoun, et al. Standards Track [Page 14] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

 o  Once the association is complete, the AC transmits a Station
    Configuration Request message, which includes the Add Station
    message element, to the WTP (see Section 4.6.8 in [RFC5415]).  In
    the above example, the WLAN was configured for IEEE 802.1X, and
    therefore the IEEE 802.11 Station Session Key is included with the
    flag field's 'A' bit set.
 o  The WTP forwards all IEEE 802.1X and IEEE 802.11 key exchange
    messages to the AC for processing.
 o  The AC transmits another Station Configuration Request message,
    which includes:
  1. An Add Station message element, which MAY include a Virtual LAN

(VLAN) [IEEE.802-1Q.2005] name, which when present is used by

       the WTP to identify the VLAN on which the user's data frames
       are to be bridged.
  1. An IEEE 802.11 Add Station message element, which includes the

WLAN Identifier with which the station has associated.

  1. An IEEE 802.11 Station Session Key message element, which

includes the pairwise encryption key.

  1. An IEEE 802.11 Information Element message element, which

includes the RSNIE to the WTP, stating the security policy to

       enforce for the client (in this case AES-CCMP).
 o  The WTP forwards any IEEE 802.11 Management Action frames received
    to the AC.
 o  The WTP MAY locally bridge client data frames (and provide the
    necessary encryption and decryption services).  The WTP MAY also
    tunnel client data frames to the AC, using 802.3 frame tunnel mode
    or 802.11 frame tunnel mode.

2.3. Roaming Behavior

 This section expands upon the examples provided in the previous
 section, and describes how the CAPWAP control protocol is used to
 provide secure roaming.
 Once a client has successfully associated with the network in a
 secure fashion, it is likely to attempt to roam to another WTP.
 Figure 6 shows an example of a currently associated station moving
 from its "Old WTP" to a "New WTP".  The figure is valid for multiple
 different security policies, including IEEE 802.1X and Wireless
 Protected Access (WPA) or Wireless Protected Access 2 (WPA2) [WPA].

Calhoun, et al. Standards Track [Page 15] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

 In the event that key caching was employed, the 802.1X Authentication
 step would be eliminated.  Note that the example represents one where
 crypto services are provided by the WTP, so in a case where the AC
 provided this function the last Station Configuration Request would
 be different.
          Client              Old WTP            New WTP           AC
                        Association Request/Response
           <--------------------------------------( - )-------------->
                                      Station Configuration Request
                                        [Add Station (Station MAC
                                        Address), IEEE 802.11 Add
                                        Station (WLAN ID), IEEE
                                        802.11 Session Key(Flag=A)]
                                                    <---------------->
           802.1X Authentication (if no key cache entry exists)
           <--------------------------------------( - )-------------->
                         802.11 4-way Key Exchange
           <--------------------------------------( - )-------------->
                              Station Configuration Request
                                [Delete Station]
                                  <---------------------------------->
                                      Station Configuration Request
                                        [Add Station(Station MAC
                                        Address), IEEE 802.11 Add
                                        Station (WLAN ID), IEEE 802.11
                                        Station session Key (Key=x),
                                        IEEE 802.11 Information
                                        Element(RSNIE(Pairwise
                                        Cipher=CCMP))]
                                                    <---------------->
                   Figure 6: Client Roaming Example

2.4. Group Key Refresh

 Periodically, the Group Key (GTK) for the BSS needs to be updated.
 The AC uses an EAPOL-Key frame to update the group key for each STA
 in the BSS.  While the AC is updating the GTK, each Layer 2 (L2)
 broadcast frame transmitted to the BSS needs to be duplicated and
 transmitted using both the current GTK and the new GTK.  Once the GTK
 update process has completed, broadcast frames transmitted to the BSS
 will be encrypted using the new GTK.
 In the case of Split MAC, the AC needs to duplicate all broadcast
 packets and update the key index so that the packet is transmitted
 using both the current and new GTK to ensure that all STAs in the BSS

Calhoun, et al. Standards Track [Page 16] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

 receive the broadcast frames.  In the case of Local MAC, the WTP
 needs to duplicate and transmit broadcast frames using the
 appropriate index to ensure that all STAs in the BSS continue to
 receive broadcast frames.
 The Group Key update procedure is shown in the following figure.  The
 AC will signal the update to the GTK using an IEEE 802.11
 Configuration Request message, including an IEEE 802.11 Update WLAN
 message element with the new GTK, its index, the Transmit Sequence
 Counter (TSC) for the Group Key and the Key Status set to 3 (begin
 GTK update).  The AC will then begin updating the GTK for each STA.
 During this time, the AC (for Split MAC) or WTP (for Local MAC) MUST
 duplicate broadcast packets and transmit them encrypted with both the
 current and new GTK.  When the AC has completed the GTK update to all
 STAs in the BSS, the AC MUST transmit an IEEE 802.11 Configuration
 Request message including an IEEE 802.11 Update WLAN message element
 containing the new GTK, its index, and the Key Status set to 4 (GTK
 update complete).
      Client           WTP                                          AC
                       IEEE 802.11 WLAN Configuration Request [Update
                         WLAN (GTK, GTK Index, GTK Start,
                         Group TSC) ]
                       <--------------------------------------------
                             802.1X EAPoL (GTK Message 1)
      <-------------( - )-------------------------------------------
                             802.1X EAPoL (GTK Message 2)
      -------------( - )------------------------------------------->
                       IEEE 802.11 WLAN Configuration Request [ Update
                         WLAN (GTK Index, GTK Complete) ]
                       <--------------------------------------------
                 Figure 7: Group Key Update Procedure

2.5. BSSID to WLAN ID Mapping

 The CAPWAP protocol binding enables the WTP to assign BSSIDs upon
 creation of a WLAN (see Section 6.1).  While manufacturers are free
 to assign BSSIDs using any arbitrary mechanism, it is advised that
 where possible the BSSIDs are assigned as a contiguous block.
 When assigned as a block, implementations can still assign any of the
 available BSSIDs to any WLAN.  One possible method is for the WTP to
 assign the address using the following algorithm: base BSSID address
 + WLAN ID.

Calhoun, et al. Standards Track [Page 17] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

 The WTP communicates the maximum number of BSSIDs that it supports
 during configuration via the IEEE 802.11 WTP WLAN Radio Configuration
 message element (see Section 6.23).

2.6. CAPWAP Data Channel QoS Behavior

 The CAPWAP IEEE 802.11 binding specification provides procedures to
 allow for the WTP to enforce Quality of Service on IEEE 802.11 Data
 Frames and MAC Management messages.

2.6.1. IEEE 802.11 Data Frames

 When the WLAN is created on the WTP, a default Quality of Service
 policy is established through the IEEE 802.11 WTP Quality of Service
 message element (see Section 6.22).  This default policy will cause
 the WTP to use the default QoS values for any station associated with
 the WLAN in question.  The AC MAY also override the policy for a
 given station by sending the IEEE 802.11 Update Station QoS message
 element (see Section 6.20), known as a station-specific QoS policy.
 Beyond the default, and per station QoS policy, the IEEE 802.11
 protocol also allows a station to request special QoS treatment for a
 specific flow through the Traffic Specification (TSPEC) Information
 Elements found in the IEEE 802.11-2007's QoS Action Frame.
 Alternatively, stations MAY also use the WiFi Alliance's WMM
 specification instead to request QoS treatment for a flow (see
 [WMM]).  This requires the WTP to observe the Status Code in the IEEE
 802.11-2007 and WMM QoS Action Add Traffic System (ADDTS) responses
 from the AC, and provide the services requested in the TSPEC
 Information Element.  Similarly, the WTP MUST observe the Reason Code
 Information Element in the IEEE 802.11-2007 and WMM QoS Action DELTS
 responses from the AC by removing the policy associated with the
 TSPEC.
 The IEEE 802.11 WTP Quality of Service message element's Tagging
 Policy field indicates how the packets are to be tagged, known as the
 Tagging Policy.  There are five bits defined, two of which are used
 to indicate the type of QoS to be used by the WTP.  The first is the
 'P' bit, which is set to inform the WTP it is to use the 802.1p QoS
 mechanism.  When set, the 'Q' bit is used to inform the WTP which
 802.1p priority values it is to use.
 The 'D' bit is set to inform the WTP it is to use the Differentiated
 Services Code Point (DSCP) QoS mechanism.  When set, the 'I' and 'O'
 bits are used to inform the WTP which values it is to use in the
 inner header, in the station's original packet, or the outer header,
 the latter of which is only valid when tunneling is enabled.

Calhoun, et al. Standards Track [Page 18] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

 When an IEEE 802.11 Update Station QoS message element is received,
 while the specific 802.1p priority or DSCP values may change for a
 given station, known as the station specific policy, the original
 Tagging Policy (the use of the five bits) remains the same.
 The use of the DSCP and 802.1p QoS mechanisms are not mutually
 exclusive.  An AC MAY request that a WTP use none, one, or both types
 of QoS mechanisms at the same time.

2.6.1.1. 802.1p Support

 The IEEE 802.11 WTP Quality of Service and IEEE 802.11 Update Station
 QoS message elements include the "802.1p Tag" field, which is the
 802.1p priority value.  This value is used by the WTP by adding an
 802.1Q header (see [IEEE.802-1Q.2005]) with the priority field set
 according to the policy provided.  Note that this tagging is only
 valid for interfaces that support 802.1p.  The actual treatment does
 not change for either Split or Local MAC modes, or when tunneling is
 used.  The only exception is when tunneling is used, the 802.1Q
 header is added to the outer packet (tunneled) header.  The IEEE
 802.11 standard does not permit the station's packet to include an
 802.1Q header.  Instead, the QoS mechanisms defined in the IEEE
 802.11 standard are used by stations to mark a packet's priority.
 When the 'P' bit is set in the Tagging Policy, the 'Q' bit has the
 following behavior:
 Q=1:   The WTP marks the priority field in the 802.1Q header to
        either the default or the station-specific 802.1p policy.
 Q=0:   The WTP marks the priority field in the 802.1Q header to the
        value found in the User Priority field of the QoS Control
        field of the IEEE 802.11 header.  If the QoS Control field is
        not present in the IEEE 802.11 header, then the behavior
        described under 'Q=1' is used.

2.6.1.2. DSCP Support

 The IEEE 802.11 WTP Quality of Service and IEEE 802.11 Update Station
 QoS message elements also provide a "DSCP Tag", which is used by the
 WTP when the 'D' bit is set to mark the DSCP field of both the IPv4
 and IPv6 headers (see [RFC2474]).  When DSCP is used, the WTP marks
 the inner packet (the original packet received by the station) when
 the 'I' bit is set.  Similarly, the WTP marks the outer packet
 (tunnel header's DSCP field) when the 'O' bit is set.
 When the 'D' bit is set, the treatment of the packet differs based on
 whether the WTP is tunneling the station's packets to the AC.
 Tunneling does not occur in a Local MAC mode when the AC has

Calhoun, et al. Standards Track [Page 19] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

 communicated that tunneling is not required, as part of the IEEE
 802.11 Add WLAN message element, see Section 6.1.  In the case where
 tunneling is not used, the 'I' and 'O' bits have the following
 behaviors:
 O=1:   This option is invalid when tunneling is not enabled for
        station data frames.
 O=0:   This option is invalid when tunneling is not enabled for
        station data frames.
 I=1:   The WTP sets the DSCP field in the station's packet to either
        the default policy or the station-specific policy if one
        exists.
 I=0:   The WTP MUST NOT modify the DSCP field in the station's
        packet.
 For Split MAC mode, or Local MAC with tunneling enabled, the WTP
 needs to contend with both the inner packet (the station's original
 packet) as well as the tunnel header (added by the WTP).  In this
 mode of operation, the bits are treated as follows:
 O=1:   The WTP sets the DSCP field in the tunnel header to either the
        default policy or the station specific policy if one exists.
 O=0:   The WTP sets the DSCP field in the tunnel header to the value
        found in the inner packet's DSCP field.  If encryption
        services are provided by the AC (see Section 6.15), the packet
        is encrypted; therefore, the WTP cannot access the inner DSCP
        field, in which case it uses the behavior described when the
        'O' bit is set.  This occurs also if the inner packet is not
        IPv4 or IPv6, and thus does not have a DSCP field.
 I=1:   The WTP sets the DSCP field in the station's packet to either
        the default policy or the station-specific policy if one
        exists.  If encryption services are provided by the AC (see
        Section 6.15), the packet is encrypted; therefore, the WTP
        cannot access the inner DSCP field, in which case it uses the
        behavior described when the 'I' bit is not set.  This occurs
        also if the inner packet is not IPv4 or IPv6, and thus does
        not have a DSCP field.
 I=0:   The WTP MUST NOT modify the DSCP field in the station's
        packet.

Calhoun, et al. Standards Track [Page 20] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

 The CAPWAP protocol supports the Explicit Congestion Notification
 (ECN) bits [RFC3168].  Additional details on ECN support can be found
 in [RFC5415].

2.6.2. IEEE 802.11 MAC Management Messages

 It is recommended that IEEE 802.11 MAC Management frames be sent by
 both the AC and the WTP with appropriate Quality of Service values,
 listed below, to ensure that congestion in the network minimizes
 occurrences of packet loss.  Note that the QoS Mechanism specified in
 the Tagging Policy is used as specified by the AC in the IEEE 802.11
 WTP Quality of Service message element (see Section 6.22).  However,
 the station-specific policy is not used for IEEE 802.11 MAC
 Management frames.
 802.1p:   The precedence value of 7 (decimal) SHOULD be used for all
           IEEE 802.11 MAC management frames, except for Probe
           Requests, which SHOULD use 4.
 DSCP:     All IEEE 802.11 MAC management frames SHOULD use the CS6
           per- hop behavior (see [RFC2474]), while IEEE 802.11 Probe
           Requests should use the Low Drop Assured Forwarding per-hop
           behavior (see [RFC3246]).

2.7. Run State Operation

 The Run state is the normal state of operation for the CAPWAP
 protocol in both the WTP and the AC.
 When the WTP receives a WLAN Configuration Request message (see
 Section 3.1), it MUST respond with a WLAN Configuration Response
 message (see Section 3.2), and it remains in the Run state.
 When the AC sends a WLAN Configuration Request message (see
 Section 3.1) or receives the corresponding WLAN Configuration
 Response message (see Section 3.2) from the WTP, it remains in the
 Run state.

3. IEEE 802.11 Specific CAPWAP Control Messages

 This section defines CAPWAP Control messages that are specific to the
 IEEE 802.11 binding.  Two messages are defined: IEEE 802.11 WLAN
 Configuration Request and IEEE 802.11 WLAN Configuration Response.
 See Section 4.5 in [RFC5415] for CAPWAP Control message definitions
 and the derivation of the Message Type value from the IANA Enterprise
 number.

Calhoun, et al. Standards Track [Page 21] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

 The valid message types for IEEE 802.11-specific control messages are
 listed below.  The IANA Enterprise number used with these messages is
 13277.
         CAPWAP Control Message                    Message Type
                                                      Value
         IEEE 802.11 WLAN Configuration Request      3398913
         IEEE 802.11 WLAN Configuration Response     3398914

3.1. IEEE 802.11 WLAN Configuration Request

 The IEEE 802.11 WLAN Configuration Request is sent by the AC to the
 WTP in order to change services provided by the WTP.  This control
 message is used to either create, update, or delete a WLAN on the
 WTP.
 The IEEE 802.11 WLAN Configuration Request is sent as a result of
 either some manual administrative process (e.g., deleting a WLAN), or
 automatically to create a WLAN on a WTP.  When sent automatically to
 create a WLAN, this control message is sent after the CAPWAP
 Configuration Update Response message (see Section 8.5 in [RFC5415])
 has been received by the AC.
 Upon receiving this control message, the WTP will modify the
 necessary services and transmit an IEEE 802.11 WLAN Configuration
 Response.
 A WTP MAY provide service for more than one WLAN; therefore, every
 WLAN is identified through a numerical index.  For instance, a WTP
 that is capable of supporting up to 16 Service Set Identifiers
 (SSIDs), could accept up to 16 IEEE 802.11 WLAN Configuration Request
 messages that include the Add WLAN message element.
 Since the index is the primary identifier for a WLAN, an AC MAY
 attempt to ensure that the same WLAN is identified through the same
 index number on all of its WTPs.  An AC that does not follow this
 approach MUST find some other means of maintaining a WLAN-Identifier-
 to-SSID mapping table.
 The following message elements MAY be included in the IEEE 802.11
 WLAN Configuration Request message.  Only one message element MUST be
 present.
 o  IEEE 802.11 Add WLAN, see Section 6.1
 o  IEEE 802.11 Delete WLAN, see Section 6.4

Calhoun, et al. Standards Track [Page 22] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

 o  IEEE 802.11 Update WLAN, see Section 6.21
 The following message element MAY be present.
 o  IEEE 802.11 Information Element, see Section 6.6
 o  Vendor-Specific Payload, see [RFC5415]

3.2. IEEE 802.11 WLAN Configuration Response

 The IEEE 802.11 WLAN Configuration Response message is sent by the
 WTP to the AC.  It is used to acknowledge receipt of an IEEE 802.11
 WLAN Configuration Request message, and to indicate that the
 requested configuration was successfully applied or that an error
 related to the processing of the IEEE 802.11 WLAN Configuration
 Request message occurred on the WTP.
 The following message element MUST be included in the IEEE 802.11
 WLAN Configuration Response message.
 o  Result Code, see Section 4.6.34 in [RFC5415]
 The following message element MAY be included in the IEEE 802.11 WLAN
 Configuration Response message.
 o  IEEE 802.11 Assigned WTP BSSID, see Section 6.3
 o  Vendor-Specific Payload, see [RFC5415]

4. CAPWAP Data Message Bindings

 This section describes the CAPWAP data message bindings to support
 transport of IEEE 802.11 frames.
 Payload encapsulation:  The CAPWAP protocol defines the CAPWAP data
    message, which is used to encapsulate a wireless payload.  For
    IEEE 802.11, the IEEE 802.11 header and payload are encapsulated
    (excluding the IEEE 802.11 FCS checksum).  The IEEE 802.11 FCS
    checksum is handled by the WTP.  This allows the WTP to validate
    an IEEE 802.11 frame prior to sending it to the AC.  Similarly,
    when an AC wishes to transmit a frame to a station, the WTP
    computes and adds the FCS checksum.
 Optional Wireless Specific Information:  This optional CAPWAP header
    field (see Section 4.3 in [RFC5415]) is only used with CAPWAP data
    messages, and it serves two purposes, depending upon the direction
    of the message.  For messages from the WTP to the AC, the field
    uses the format described in the "IEEE 802.11 Frame Info" field

Calhoun, et al. Standards Track [Page 23] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

    (see below).  However, for messages sent by the AC to the WTP, the
    format used is described in the "Destination WLANs" field (also
    defined below).
    Note that in both cases, the two optional headers fit in the
    "Data" field of the Wireless Specific Information header.
 IEEE 802.11 Frame Info:  When an IEEE 802.11 frame is received from a
    station over the air, it is encapsulated and this field is used to
    include radio and PHY-specific information associated with the
    frame.
    The IEEE 802.11 Frame Info field has the following format:
    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     RSSI      |     SNR       |           Data Rate           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    RSSI:   Received Signal Strength Indication (RSSI) is a signed,
       8-bit value.  It is the received signal strength indication, in
       dBm.
    SNR:   SNR is a signed, 8-bit value.  It is the signal-to-noise
       ratio of the received IEEE 802.11 frame, in dB.
    Data Rate:   The data rate field is a 16-bit unsigned value.  The
       data rate field is a 16-bit unsigned value expressing the data
       rate of the packets received by the WTP in units of 0.1 Mbps.
       For instance, a packet received at 5.5 Mbps would be set to 55,
       while 11 Mbps would be set to 110.
 Destination WLANs:  The Destination WLANs field is used to specify
    the target WLANs for a given frame, and is only used with
    broadcast and multicast frames.  This field allows the AC to
    transmit a single broadcast or multicast frame to the WTP and
    allows the WTP to perform the necessary frame replication.  The
    field uses the following format:
    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        WLAN ID bitmap         |            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Calhoun, et al. Standards Track [Page 24] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

    WLAN ID bitmap:   This bit field indicates the WLAN ID (see
       Section 6.1) on which the WTP will transmit the included frame.
       For instance, if a multicast packet is to be transmitted on
       WLANs 1 and 3, the bits for WLAN 1 and 3 of this field would be
       enabled.  WLAN 1 is represented by bit 15 in the figure above,
       or the least significant bit, while WLAN 16 would be
       represented by bit zero (0), or the most significant bit, in
       the figure.  This field is to be set to all zeroes for unicast
       packets and is unused if the WTP is not providing IEEE 802.11
       encryption.
    Reserved:   All implementations complying with this protocol MUST
       set to zero any bits that are reserved in the version of the
       protocol supported by that implementation.  Receivers MUST
       ignore all bits not defined for the version of the protocol
       they support.

5. CAPWAP Control Message Bindings

 This section describes the IEEE 802.11-specific message elements
 included in CAPWAP Control Messages.

5.1. Discovery Request Message

 The following IEEE 802.11-specific message element MUST be included
 in the CAPWAP Discovery Request Message.
 o  IEEE 802.11 WTP Radio Information, see Section 6.25.  An IEEE
    802.11 WTP Radio Information message element MUST be present for
    every radio in the WTP.

5.2. Discovery Response Message

 The following IEEE 802.11-specific message element MUST be included
 in the CAPWAP Discovery Response Message.
 o  IEEE 802.11 WTP Radio Information, see Section 6.25.  An IEEE
    802.11 WTP Radio Information message element MUST be present for
    every radio in the WTP.

5.3. Primary Discovery Request Message

 The following IEEE 802.11 specific message element MUST be included
 in the CAPWAP Primary Discovery Request message.
 o  IEEE 802.11 WTP Radio Information, see Section 6.25.  An IEEE
    802.11 WTP Radio Information message element MUST be present for
    every radio in the WTP.

Calhoun, et al. Standards Track [Page 25] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

5.4. Primary Discovery Response Message

 The following IEEE 802.11-specific message element MUST be included
 in the CAPWAP Primary Discovery Response message.
 o  IEEE 802.11 WTP Radio Information, see Section 6.25.  An IEEE
    802.11 WTP Radio Information message element MUST be present for
    every radio in the WTP.

5.5. Join Request Message

 The following IEEE 802.11-specific message element MUST be included
 in the CAPWAP Join Request message.
 o  IEEE 802.11 WTP Radio Information, see Section 6.25.  An IEEE
    802.11 WTP Radio Information message element MUST be present for
    every radio in the WTP.

5.6. Join Response Message

 The following IEEE 802.11-specific message element MUST be included
 in the CAPWAP Join Response message.
 o  IEEE 802.11 WTP Radio Information, see Section 6.25.  An IEEE
    802.11 WTP Radio Information message element MUST be present for
    every radio in the WTP.

5.7. Configuration Status Request Message

 The following IEEE 802.11-specific message elements MAY be included
 in the CAPWAP Configuration Status Request message.  More than one of
 each message element listed MAY be included.
 o  IEEE 802.11 Antenna, see Section 6.2
 o  IEEE 802.11 Direct Sequence Control, see Section 6.5
 o  IEEE 802.11 MAC Operation, see Section 6.7
 o  IEEE 802.11 Multi-Domain Capability, see Section 6.9
 o  IEEE 802.11 Orthogonal Frequency Division Multiplexing (OFDM)
    Control, see Section 6.10
 o  IEEE 802.11 Supported Rates, see Section 6.17
 o  IEEE 802.11 Tx Power, see Section 6.18

Calhoun, et al. Standards Track [Page 26] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

 o  IEEE 802.11 TX Power Level, see Section 6.19
 o  IEEE 802.11 WTP Radio Configuration, see Section 6.23
 o  IEEE 802.11 WTP Radio Information, see Section 6.25.  An IEEE
    802.11 WTP Radio Information message element MUST be present for
    every radio in the WTP.

5.8. Configuration Status Response Message

 The following IEEE 802.11 specific message elements MAY be included
 in the CAPWAP Configuration Status Response Message.  More than one
 of each message element listed MAY be included.
 o  IEEE 802.11 Antenna, see Section 6.2
 o  IEEE 802.11 Direct Sequence Control, see Section 6.5
 o  IEEE 802.11 MAC Operation, see Section 6.7
 o  IEEE 802.11 Multi-Domain Capability, see Section 6.9
 o  IEEE 802.11 OFDM Control, see Section 6.10
 o  IEEE 802.11 Rate Set, see Section 6.11
 o  IEEE 802.11 Supported Rates, see Section 6.17
 o  IEEE 802.11 Tx Power, see Section 6.18
 o  IEEE 802.11 WTP Quality of Service, see Section 6.22
 o  IEEE 802.11 WTP Radio Configuration, see Section 6.23

5.9. Configuration Update Request Message

 The following IEEE 802.11-specific message elements MAY be included
 in the CAPWAP Configuration Update Request message.  More than one of
 each message element listed MAY be included.
 o  IEEE 802.11 Antenna, see Section 6.2
 o  IEEE 802.11 Direct Sequence Control, see Section 6.5
 o  IEEE 802.11 MAC Operation, see Section 6.7
 o  IEEE 802.11 Multi-Domain Capability, see Section 6.9

Calhoun, et al. Standards Track [Page 27] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

 o  IEEE 802.11 OFDM Control, see Section 6.10
 o  IEEE 802.11 Rate Set, see Section 6.11
 o  IEEE 802.11 RSNA Error Report from Station, see Section 6.12
 o  IEEE 802.11 Tx Power, see Section 6.18
 o  IEEE 802.11 WTP Quality of Service, see Section 6.22
 o  IEEE 802.11 WTP Radio Configuration, see Section 6.23

5.10. Station Configuration Request

 The following IEEE 802.11-specific message elements MAY be included
 in the CAPWAP Station Configuration Request message.  More than one
 of each message element listed MAY be included.
 o  IEEE 802.11 Station, see Section 6.13
 o  IEEE 802.11 Station Session Key, see Section 6.15
 o  IEEE 802.11 Station QoS Profile, see Section 6.14
 o  IEEE 802.11 Update Station Qos, see Section 6.20

5.11. Change State Event Request

 The following IEEE 802.11-specific message element MAY be included in
 the CAPWAP Station Configuration Request message.
 o  IEEE 802.11 WTP Radio Fail Alarm Indication, see Section 6.24

5.12. WTP Event Request

 The following IEEE 802.11-specific message elements MAY be included
 in the CAPWAP WTP Event Request message.  More than one of each
 message element listed MAY be included.
 o  IEEE 802.11 MIC Countermeasures, see Section 6.8
 o  IEEE 802.11 RSNA Error Report from Station, see Section 6.12
 o  IEEE 802.11 Statistics, see Section 6.16

Calhoun, et al. Standards Track [Page 28] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

6. IEEE 802.11 Message Element Definitions

 The following IEEE 802.11-specific message elements are defined in
 this section.
 IEEE 802.11 Message Element                     Type Value
 IEEE 802.11 Add WLAN                               1024
 IEEE 802.11 Antenna                                1025
 IEEE 802.11 Assigned WTP BSSID                     1026
 IEEE 802.11 Delete WLAN                            1027
 IEEE 802.11 Direct Sequence Control                1028
 IEEE 802.11 Information Element                    1029
 IEEE 802.11 MAC Operation                          1030
 IEEE 802.11 MIC Countermeasures                    1031
 IEEE 802.11 Multi-Domain Capability                1032
 IEEE 802.11 OFDM Control                           1033
 IEEE 802.11 Rate Set                               1034
 IEEE 802.11 RSNA Error Report From Station         1035
 IEEE 802.11 Station                                1036
 IEEE 802.11 Station QoS Profile                    1037
 IEEE 802.11 Station Session Key                    1038
 IEEE 802.11 Statistics                             1039
 IEEE 802.11 Supported Rates                        1040
 IEEE 802.11 Tx Power                               1041
 IEEE 802.11 Tx Power Level                         1042
 IEEE 802.11 Update Station QoS                     1043
 IEEE 802.11 Update WLAN                            1044
 IEEE 802.11 WTP Quality of Service                 1045
 IEEE 802.11 WTP Radio Configuration                1046
 IEEE 802.11 WTP Radio Fail Alarm Indication        1047
 IEEE 802.11 WTP Radio Information                  1048
            Figure 8: IEEE 802.11 Binding Message Elements

6.1. IEEE 802.11 Add WLAN

 The IEEE 802.11 Add WLAN message element is used by the AC to define
 a WLAN on the WTP.  The inclusion of this message element MUST also
 include IEEE 802.11 Information Element message elements, containing
 the following IEEE 802.11 IEs:
 Power Constraint information element
 EDCA Parameter Set information element
 QoS Capability information element

Calhoun, et al. Standards Track [Page 29] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

 WPA information element  [WPA]
 RSN information element
 WMM information element  [WMM]
 These IEEE 802.11 Information Elements are stored by the WTP and
 included in any Probe Responses and Beacons generated, as specified
 in the IEEE 802.11 standard [IEEE.802-11.2007].  If present, the RSN
 Information Element is sent with the IEEE 802.11 Add WLAN message
 element to instruct the WTP on the usage of the Key field.
 If cryptographic services are provided at the WTP, the WTP MUST
 observe the algorithm dictated in the Group Cipher Suite field of the
 RSN Information Element sent by the AC.  The RSN Information Element
 is used to communicate any supported algorithm, including WEP,
 Temporal Key Integrity Protocol (TKIP) and AES-CCMP.  In the case of
 static WEP keys, the RSN Information Element is still used to
 indicate the cryptographic algorithm even though no key exchange
 occurred.
 An AC MAY include additional Information Elements as desired.  The
 message element uses the following format:
      0                   1                   2                   3
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Radio ID   |    WLAN ID    |          Capability           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Key Index   |   Key Status  |           Key Length          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             Key...                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Group TSC                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           Group TSC           |      QoS      |   Auth Type   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   MAC Mode    |  Tunnel Mode  | Suppress SSID |    SSID ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Type:   1024 for IEEE 802.11 Add WLAN
 Length:   >= 20
 Radio ID:   An 8-bit value representing the radio, whose value is
    between one (1) and 31.

Calhoun, et al. Standards Track [Page 30] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

 WLAN ID:   An 8-bit value specifying the WLAN Identifier.  The value
    MUST be between one (1) and 16.
 Capability:   A 16-bit value containing the Capability information
    field to be advertised by the WTP in the Probe Request and Beacon
    frames.  Each bit of the Capability field represents a different
    WTP capability, which are described in detail in
    [IEEE.802-11.2007].  The format of the field is:
      0                   1
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |E|I|C|F|P|S|B|A|M|Q|T|D|V|O|K|L|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    E (ESS):   The AC MUST set the Extended Service Set (ESS) subfield
      to 1.
    I (IBSS):   The AC MUST set the Independent Basic Service Set
      (IBSS) subfield to 0.
    C (CF-Pollable):   The AC sets the Contention Free Pollable (CF-
      Pollable) subfield based on the table found in
      [IEEE.802-11.2007].
    F (CF-Poll Request):   The AC sets the CF-Poll Request subfield
      based on the table found in [IEEE.802-11.2007].
    P (Privacy):   The AC sets the Privacy subfield based on the
      confidentiality requirements of the WLAN, as defined in
      [IEEE.802-11.2007].
    S (Short Preamble):   The AC sets the Short Preamble subfield
      based on whether the use of short preambles is permitted on the
      WLAN, as defined in [IEEE.802-11.2007].
    B (PBCC):   The AC sets the Packet Binary Convolutional Code
      (PBCC) modulation option subfield based on whether the use of
      PBCC is permitted on the WLAN, as defined in [IEEE.802-11.2007].
    A (Channel Agility):   The AC sets the Channel Agility subfield
      based on whether the WTP is capable of supporting the High Rate
      Direct Sequence Spread Spectrum (HR/DSSS), as defined in
      [IEEE.802-11.2007].

Calhoun, et al. Standards Track [Page 31] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

    M (Spectrum Management):   The AC sets the Spectrum Management
      subfield according to the value of the
      dot11SpectrumManagementRequired MIB variable, as defined in
      [IEEE.802-11.2007].
    Q (QoS):   The AC sets the Quality of Service (QoS) subfield based
      on the table found in [IEEE.802-11.2007].
    T (Short Slot Time):   The AC sets the Short Slot Time subfield
      according to the value of the WTP's currently used slot time
      value, as defined in [IEEE.802-11.2007].
    D (APSD):   The AC sets the Automatic Power Save Delivery (APSD)
      subfield according to the value of the
      dot11APSDOptionImplemented Management Information Base (MIB)
      variable, as defined in [IEEE.802-11.2007].
    V (Reserved):   The AC sets the Reserved subfield to zero, as
      defined in [IEEE.802-11.2007].
    O (DSSS-OFDM):   The AC sets the DSSS-OFDM subfield to indicate
      the use of Direct Sequence Spread Spectrum with Orthogonal
      Frequency Division Multiplexing (DSSS-OFDM), as defined in
      [IEEE.802-11.2007].
    K (Delayed Block ACK):   The AC sets the Delayed Block ACK
      subfield according to the value of the
      dot11DelayedBlockAckOptionImplemented MIB variable, as defined
      in [IEEE.802-11.2007].
    L (Immediate Block ACK):   The AC sets the Delayed Block ACK
      subfield according to the value of the
      dot11ImmediateBlockAckOptionImplemented MIB variable, as defined
      in [IEEE.802-11.2007].
 Key-Index:   The Key Index associated with the key.
 Key Status:   A 1-byte value that specifies the state and usage of
    the key that has been included.  Note this field is ignored if the
    Key Length field is set to zero (0).  The following values
    describe the key usage and its status:
    0 -  A value of zero, with the inclusion of the RSN Information
         Element means that the WLAN uses per-station encryption keys,
         and therefore the key in the 'Key' field is only used for
         multicast traffic.

Calhoun, et al. Standards Track [Page 32] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

    1 -  When set to one, the WLAN employs a shared Wired Equivalent
         Privacy (WEP) key, also known as a static WEP key, and uses
         the encryption key for both unicast and multicast traffic for
         all stations.
    2 -  The value of 2 indicates that the AC will begin rekeying the
         GTK with the STA's in the BSS.  It is only valid when IEEE
         802.11 is enabled as the security policy for the BSS.
    3 -  The value of 3 indicates that the AC has completed rekeying
         the GTK and broadcast packets no longer need to be duplicated
         and transmitted with both GTK's.
 Key Length:   A 16-bit value representing the length of the Key
    field.
 Key:   A Session Key, whose length is known via the Key Length field,
    used to provide data privacy.  For encryption schemes that employ
    a separate encryption key for unicast and multicast traffic, the
    key included here only applies to multicast frames, and the cipher
    suite is specified in an accompanied RSN Information Element.  In
    these scenarios, the key and cipher information is communicated
    via the Add Station message element, see Section 4.6.8 in
    [RFC5415] and the IEEE 802.11 Station Session Key message element,
    see Section 6.15.  When used with WEP, the key field includes the
    broadcast key.  When used with CCMP, the Key field includes the
    128-bit Group Temporal Key.  When used with TKIP, the Key field
    includes the 256-bit Group Temporal Key (which consists of a 128-
    bit key used as input for TKIP key mixing, and two 64-bit keys
    used for Michael).
 Group TSC:   A 48-bit value containing the Transmit Sequence Counter
    (TSC) for the updated group key.  The WTP will set the TSC for
    broadcast/multicast frames to this value for the updated group
    key.
 QoS:   An 8-bit value specifying the default QoS policy for the WTP
    to apply to network traffic received for a non-WMM enabled STA.
    The following enumerated values are supported:
    0 -  Best Effort
    1 -  Video

Calhoun, et al. Standards Track [Page 33] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

    2 -  Voice
    3 -  Background
 Auth Type:   An 8-bit value specifying the supported authentication
    type.
    The following enumerated values are supported:
    0 -  Open System
    1 -  WEP Shared Key
 MAC Mode:   This field specifies whether the WTP should support the
    WLAN in Local or Split MAC mode.  Note that the AC MUST NOT
    request a mode of operation that was not advertised by the WTP
    during the discovery process (see Section 4.6.43 in [RFC5415]).
    The following enumerated values are supported:
    0 - Local MAC:   Service for the WLAN is to be provided in Local
       MAC mode.
    1 - Split MAC:   Service for the WLAN is to be provided in Split
       MAC mode.
 Tunnel Mode:   This field specifies the frame tunneling type to be
    used for 802.11 data frames from all stations associated with the
    WLAN.  The AC MUST NOT request a mode of operation that was not
    advertised by the WTP during the discovery process (see Section
    4.6.42 in [RFC5415]).  All IEEE 802.11 management frames MUST be
    tunneled using 802.11 Tunnel mode.  The following enumerated
    values are supported:
    0 - Local Bridging:   All user traffic is to be locally bridged.
    1 - 802.3 Tunnel:   All user traffic is to be tunneled to the AC
       in 802.3 format (see Section 4.4.2 in [RFC5415]).  Note that
       this option MUST NOT be selected with Split MAC mode.
    2 - 802.11 Tunnel:   All user traffic is to be tunneled to the AC
       in 802.11 format.
 Suppress SSID:   A boolean indicating whether the SSID is to be
    advertised by the WTP.  A value of zero suppresses the SSID in the
    802.11 Beacon and Probe Response frames, while a value of one will
    cause the WTP to populate the field.

Calhoun, et al. Standards Track [Page 34] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

 SSID:   The SSID attribute is the service set identifier that will be
    advertised by the WTP for this WLAN.  The SSID field contains any
    ASCII character and MUST NOT exceed 32 octets in length, as
    defined in [IEEE.802-11.2007].

6.2. IEEE 802.11 Antenna

 The IEEE 802.11 Antenna message element is communicated by the WTP to
 the AC to provide information on the antennas available.  The AC MAY
 use this element to reconfigure the WTP's antennas.  The message
 element contains the following fields:
      0                   1                   2                   3
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Radio ID   |   Diversity   |    Combiner   |  Antenna Cnt  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Antenna Selection...
     +-+-+-+-+-+-+-+-+
 Type:   1025 for IEEE 802.11 Antenna
 Length:   >= 5
 Radio ID:   An 8-bit value representing the radio to configure, whose
    value is between one (1) and 31.
 Diversity:   An 8-bit value specifying whether the antenna is to
    provide receiver diversity.  The value of this field is the same
    as the IEEE 802.11 dot11DiversitySelectionRx MIB element, see
    [IEEE.802-11.2007].  The following enumerated values are
    supported:
    0 -  Disabled
    1 -  Enabled (may only be true if the antenna can be used as a
         receiving antenna)
 Combiner:   An 8-bit value specifying the combiner selection.  The
    following enumerated values are supported:
    1 -  Sectorized (Left)
    2 -  Sectorized (Right)

Calhoun, et al. Standards Track [Page 35] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

    3 -  Omni
    4 -  Multiple Input/Multiple Output (MIMO)
 Antenna Count:   An 8-bit value specifying the number of Antenna
    Selection fields.  This value SHOULD be the same as the one found
    in the IEEE 802.11 dot11CurrentTxAntenna MIB element (see
    [IEEE.802-11.2007]).
 Antenna Selection:   One 8-bit antenna configuration value per
    antenna in the WTP, containing up to 255 antennas.  The following
    enumerated values are supported:
    1 -  Internal Antenna
    2 -  External Antenna

6.3. IEEE 802.11 Assigned WTP BSSID

 The IEEE 802.11 Assigned WTP BSSID is only included by the WTP when
 the IEEE 802.11 WLAN Configuration Request included the IEEE 802.11
 Add WLAN message element.  The BSSID value field of this message
 element contains the BSSID that has been assigned by the WTP,
 enabling the WTP to perform its own BSSID assignment.
 The WTP is free to assign the BSSIDs the way it sees fit, but it is
 highly recommended that the WTP assign the BSSID using the following
 algorithm: BSSID = {base BSSID} + WLAN ID.
      0                   1                   2                   3
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Radio ID   |    WLAN ID    |           BSSID
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             BSSID                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Type:   1026 for IEEE 802.11 Assigned WTP BSSID
 Length:   8
 Radio ID:   An 8-bit value representing the radio, whose value is
    between one (1) and 31.
 WLAN ID:   An 8-bit value specifying the WLAN Identifier.  The value
    MUST be between one (1) and 16.

Calhoun, et al. Standards Track [Page 36] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

 BSSID:   The BSSID assigned by the WTP for the WLAN created as a
    result of receiving an IEEE 802.11 Add WLAN.

6.4. IEEE 802.11 Delete WLAN

 The IEEE 802.11 Delete WLAN message element is used to inform the WTP
 that a previously created WLAN is to be deleted, and contains the
 following fields:
    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Radio ID   |    WLAN ID    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Type:   1027 for IEEE 802.11 Delete WLAN
 Length:   2
 Radio ID:   An 8-bit value representing the radio, whose value is
    between one (1) and 31.
 WLAN ID:   An 8-bit value specifying the WLAN Identifier.  The value
    MUST be between one (1) and 16.

6.5. IEEE 802.11 Direct Sequence Control

 The IEEE 802.11 Direct Sequence Control message element is a bi-
 directional element.  When sent by the WTP, it contains the current
 state.  When sent by the AC, the WTP MUST adhere to the values
 provided.  This element is only used for IEEE 802.11b radios.  The
 message element has the following fields.
      0                   1                   2                   3
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Radio ID   |    Reserved   | Current Chan  |  Current CCA  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    Energy Detect Threshold                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Type:   1028 for IEEE 802.11 Direct Sequence Control
 Length:   8

Calhoun, et al. Standards Track [Page 37] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

 Radio ID:   An 8-bit value representing the radio to configure, whose
    value is between one (1) and 31.
 Reserved:   All implementations complying with this protocol MUST set
    to zero any bits that are reserved in the version of the protocol
    supported by that implementation.  Receivers MUST ignore all bits
    not defined for the version of the protocol they support.
 Current Channel:   This attribute contains the current operating
    frequency channel of the Direct Sequence Spread Spectrum (DSSS)
    PHY.  This value comes from the IEEE 802.11 dot11CurrentChannel
    MIB element (see [IEEE.802-11.2007]).
 Current CCA:   The current Clear Channel Assessment (CCA) method in
    operation, whose value can be found in the IEEE 802.11
    dot11CCAModeSupported MIB element (see [IEEE.802-11.2007]).  Valid
    values are:
       1 - energy detect only (edonly)
       2 - carrier sense only (csonly)
       4 - carrier sense and energy detect (edandcs)
       8 - carrier sense with timer (cswithtimer)
      16 - high rate carrier sense and energy detect (hrcsanded)
 Energy Detect Threshold:   The current Energy Detect Threshold being
    used by the DSSS PHY.  The value can be found in the IEEE 802.11
    dot11EDThreshold MIB element (see [IEEE.802-11.2007]).

6.6. IEEE 802.11 Information Element

 The IEEE 802.11 Information Element is used to communicate any IE
 defined in the IEEE 802.11 protocol.  The data field contains the raw
 IE as it would be included within an IEEE 802.11 MAC management
 message.
    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Radio ID    |    WLAN ID    |B|P| Reserved  |Info Element...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Calhoun, et al. Standards Track [Page 38] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

 Type:   1029 for IEEE 802.11 Information Element
 Length:   >= 4
 Radio ID:   An 8-bit value representing the radio, whose value is
    between one (1) and 31.
 WLAN ID:   An 8-bit value specifying the WLAN Identifier.  The value
    MUST be between one (1) and 16.
 B:   When set, the WTP is to include the Information Element in IEEE
    802.11 Beacons associated with the WLAN.
 P:   When set, the WTP is to include the Information Element in Probe
    Responses associated with the WLAN.
 Reserved:   All implementations complying with this protocol MUST set
    to zero any bits that are reserved in the version of the protocol
    supported by that implementation.  Receivers MUST ignore all bits
    not defined for the version of the protocol they support.
 Info Element:   The IEEE 802.11 Information Element, which includes
    the type, length, and value field.

6.7. IEEE 802.11 MAC Operation

 The IEEE 802.11 MAC Operation message element is sent by the AC to
 set the IEEE 802.11 MAC parameters on the WTP, and contains the
 following fields.
      0                   1                   2                   3
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Radio ID   |    Reserved   |         RTS Threshold         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Short Retry  |  Long Retry   |    Fragmentation Threshold    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Tx MSDU Lifetime                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Rx MSDU Lifetime                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Type:   1030 for IEEE 802.11 MAC Operation
 Length:   16

Calhoun, et al. Standards Track [Page 39] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

 Radio ID:   An 8-bit value representing the radio to configure, whose
    value is between one (1) and 31.
 Reserved:   All implementations complying with this protocol MUST set
    to zero any bits that are reserved in the version of the protocol
    supported by that implementation.  Receivers MUST ignore all bits
    not defined for the version of the protocol they support.
 RTS Threshold:   This attribute indicates the number of octets in an
    MAC Protocol Data Unit (MPDU), below which a Request To Send/Clear
    To Send (RTS/CTS) handshake MUST NOT be performed.  An RTS/CTS
    handshake MUST be performed at the beginning of any frame exchange
    sequence where the MPDU is of type Data or Management, the MPDU
    has an individual address in the Address1 field, and the length of
    the MPDU is greater than this threshold.  Setting this attribute
    to be larger than the maximum MSDU size MUST have the effect of
    turning off the RTS/CTS handshake for frames of Data or Management
    type transmitted by this STA.  Setting this attribute to zero MUST
    have the effect of turning on the RTS/CTS handshake for all frames
    of Data or Management type transmitted by this STA.  The default
    value of this attribute MUST be 2347.  The value of this field
    comes from the IEEE 802.11 dot11RTSThreshold MIB element, (see
    [IEEE.802-11.2007]).
 Short Retry:   This attribute indicates the maximum number of
    transmission attempts of a frame, the length of which is less than
    or equal to RTSThreshold, that MUST be made before a failure
    condition is indicated.  The default value of this attribute MUST
    be 7.  The value of this field comes from the IEEE 802.11
    dot11ShortRetryLimit MIB element, (see [IEEE.802-11.2007]).
 Long Retry:   This attribute indicates the maximum number of
    transmission attempts of a frame, the length of which is greater
    than dot11RTSThreshold, that MUST be made before a failure
    condition is indicated.  The default value of this attribute MUST
    be 4.  The value of this field comes from the IEEE 802.11
    dot11LongRetryLimit MIB element, (see [IEEE.802-11.2007]).
 Fragmentation Threshold:   This attribute specifies the current
    maximum size, in octets, of the MPDU that MAY be delivered to the
    PHY.  A MAC Service Data Unit (MSDU) MUST be broken into fragments
    if its size exceeds the value of this attribute after adding MAC
    headers and trailers.  An MSDU or MAC Management Protocol Data
    Unit (MMPDU) MUST be fragmented when the resulting frame has an
    individual address in the Address1 field, and the length of the
    frame is larger than this threshold.  The default value for this
    attribute MUST be the lesser of 2346 or the aMPDUMaxLength of the
    attached PHY and MUST never exceed the lesser of 2346 or the

Calhoun, et al. Standards Track [Page 40] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

    aMPDUMaxLength of the attached PHY.  The value of this attribute
    MUST never be less than 256.  The value of this field comes from
    the IEEE 802.11 dot11FragmentationThreshold MIB element, (see
    [IEEE.802-11.2007]).
 Tx MSDU Lifetime:   This attribute specifies the elapsed time in Time
    Units (TUs), after the initial transmission of an MSDU, after
    which further attempts to transmit the MSDU MUST be terminated.
    The default value of this attribute MUST be 512.  The value of
    this field comes from the IEEE 802.11 dot11MaxTransmitMSDULifetime
    MIB element, (see [IEEE.802-11.2007]).
 Rx MSDU Lifetime:   This attribute specifies the elapsed time in TU,
    after the initial reception of a fragmented MMPDU or MSDU, after
    which further attempts to reassemble the MMPDU or MSDU MUST be
    terminated.  The default value MUST be 512.  The value of this
    field comes from the IEEE 802.11 dot11MaxReceiveLifetime MIB
    element, (see [IEEE.802-11.2007]).

6.8. IEEE 802.11 MIC Countermeasures

 The IEEE 802.11 MIC Countermeasures message element is sent by the
 WTP to the AC to indicate the occurrence of a MIC failure.  For more
 information on MIC failure events, see the
 dot11RSNATKIPCounterMeasuresInvoked MIB element definition in
 [IEEE.802-11.2007].
    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Radio ID    |    WLAN ID    |          MAC Address          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          MAC Address                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Type:   1031 for IEEE 802.11 MIC Countermeasures
 Length:   8
 Radio ID:   The Radio Identifier, whose value is between one (1) and
    31, typically refers to some interface index on the WTP.
 WLAN ID:   This 8-bit unsigned integer includes the WLAN Identifier,
    on which the MIC failure occurred.  The value MUST be between one
    (1) and 16.

Calhoun, et al. Standards Track [Page 41] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

 MAC Address:   The MAC Address of the station that caused the MIC
    failure.

6.9. IEEE 802.11 Multi-Domain Capability

 The IEEE 802.11 Multi-Domain Capability message element is used by
 the AC to inform the WTP of regulatory limits.  The AC will transmit
 one message element per frequency band to indicate the regulatory
 constraints in that domain.  The message element contains the
 following fields.
       0                   1                   2                   3
       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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Radio ID   |    Reserved   |        First Channel #        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       Number of Channels      |       Max Tx Power Level      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Type:   1032 for IEEE 802.11 Multi-Domain Capability
 Length:   8
 Radio ID:   An 8-bit value representing the radio to configure, whose
    value is between one (1) and 31.
 Reserved:   All implementations complying with this protocol MUST set
    to zero any bits that are reserved in the version of the protocol
    supported by that implementation.  Receivers MUST ignore all bits
    not defined for the version of the protocol they support.
 First Channel #:   This attribute indicates the value of the lowest
    channel number in the sub-band for the associated domain country
    string.  The value of this field comes from the IEEE 802.11
    dot11FirstChannelNumber MIB element (see [IEEE.802-11.2007]).
 Number of Channels:   This attribute indicates the value of the total
    number of channels allowed in the sub-band for the associated
    domain country string (see Section 6.23).  The value of this field
    comes from the IEEE 802.11 dot11NumberofChannels MIB element (see
    [IEEE.802-11.2007]).
 Max Tx Power Level:   This attribute indicates the maximum transmit
    power, in dBm, allowed in the sub-band for the associated domain
    country string (see Section 6.23).  The value of this field comes
    from the IEEE 802.11 dot11MaximumTransmitPowerLevel MIB element
    (see [IEEE.802-11.2007]).

Calhoun, et al. Standards Track [Page 42] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

6.10. IEEE 802.11 OFDM Control

 The IEEE 802.11 Orthogonal Frequency Division Multiplexing (OFDM)
 Control message element is a bi-directional element.  When sent by
 the WTP, it contains the current state.  When sent by the AC, the WTP
 MUST adhere to the received values.  This message element is only
 used for 802.11a radios and contains the following fields:
      0                   1                   2                   3
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Radio ID   |    Reserved   | Current Chan  |  Band Support |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         TI Threshold                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Type:   1033 for IEEE 802.11 OFDM Control
 Length:   8
 Radio ID:   An 8-bit value representing the radio to configure, whose
    value is between one (1) and 31.
 Reserved:   All implementations complying with this protocol MUST set
    to zero any bits that are reserved in the version of the protocol
    supported by that implementation.  Receivers MUST ignore all bits
    not defined for the version of the protocol they support.
 Current Channel:   This attribute contains the current operating
    frequency channel of the OFDM PHY.  The value of this field comes
    from the IEEE 802.11 dot11CurrentFrequency MIB element (see
    [IEEE.802-11.2007]).
 Band Supported:   The capability of the OFDM PHY implementation to
    operate in the three Unlicensed National Information
    Infrastructure (U-NII) bands.  The value of this field comes from
    the IEEE 802.11 dot11FrequencyBandsSupported MIB element (see
    [IEEE.802-11.2007]), coded as a bit field, whose values are:
    Bit 0 -  capable of operating in the 5.15-5.25 GHz band
    Bit 1 -  capable of operating in the 5.25-5.35 GHz band
    Bit 2 -  capable of operating in the 5.725-5.825 GHz band

Calhoun, et al. Standards Track [Page 43] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

    Bit 3 -  capable of operating in the 5.47-5.725 GHz band
    Bit 4 -  capable of operating in the lower Japanese 5.25 GHz band
    Bit 5 -  capable of operating in the 5.03-5.091 GHz band
    Bit 6 -  capable of operating in the 4.94-4.99 GHz band
    For example, for an implementation capable of operating in the
    5.15-5.35 GHz bands, this attribute would take the value 3.
 TI Threshold:   The threshold being used to detect a busy medium
    (frequency).  CCA MUST report a busy medium upon detecting the
    RSSI above this threshold.  The value of this field comes from the
    IEEE 802.11 dot11TIThreshold MIB element (see [IEEE.802-11.2007]).

6.11. IEEE 802.11 Rate Set

 The rate set message element value is sent by the AC and contains the
 supported operational rates.  It contains the following fields.
       0                   1                   2                   3
       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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Radio ID   |                 Rate Set...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Type:   1034 for IEEE 802.11 Rate Set
 Length:   >= 3
 Radio ID:   An 8-bit value representing the radio to configure, whose
    value is between one (1) and 31.
 Rate Set:   The AC generates the Rate Set that the WTP is to include
    in its Beacon and Probe messages.  The length of this field is
    between 2 and 8 bytes.  The value of this field comes from the
    IEEE 802.11 dot11OperationalRateSet MIB element (see
    [IEEE.802-11.2007]).

6.12. IEEE 802.11 RSNA Error Report From Station

 The IEEE 802.11 RSN Error Report From Station message element is used
 by a WTP to send RSN error reports to the AC.  The WTP does not need
 to transmit any reports that do not include any failures.  The fields
 from this message element come from the IEEE 802.11
 Dot11RSNAStatsEntry table, see [IEEE.802-11.2007].

Calhoun, et al. Standards Track [Page 44] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Client MAC Address                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Client MAC Address       |             BSSID             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             BSSID                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Radio ID    |    WLAN ID    |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        TKIP ICV Errors                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    TKIP Local MIC Failures                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   TKIP Remote MIC Failures                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          CCMP Replays                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        CCMP Decrypt Errors                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          TKIP Replays                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Type:   1035 for IEEE 802.11 RSNA Error Report From Station
 Length:   40
 Client MAC Address:   The Client MAC Address of the station.
 BSSID:   The BSSID on which the failures are being reported.
 Radio ID:   The Radio Identifier, whose value is between one (1) and
    31, typically refers to some interface index on the WTP.
 WLAN ID:   The WLAN ID on which the RSNA failures are being reported.
    The value MUST be between one (1) and 16.
 Reserved:   All implementations complying with this protocol MUST set
    to zero any bits that are reserved in the version of the protocol
    supported by that implementation.  Receivers MUST ignore all bits
    not defined for the version of the protocol they support.

Calhoun, et al. Standards Track [Page 45] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

 TKIP ICV Errors:   A 32-bit value representing the number of Temporal
    Key Integrity Protocol (TKIP) (as defined in [IEEE.802-11.2007])
    ICV errors encountered when decrypting packets from the station.
    The value of this field comes from the IEEE 802.11
    dot11RSNAStatsTKIPICVErrors MIB element (see [IEEE.802-11.2007]).
 TKIP Local MIC Failures:   A 32-bit value representing the number of
    MIC failures encountered when checking the integrity of packets
    received from the station.  The value of this field comes from the
    IEEE 802.11 dot11RSNAStatsTKIPLocalMICFailures MIB element (see
    [IEEE.802-11.2007]).
 TKIP Remote MIC Failures:   A 32-bit value representing the number of
    MIC failures reported by the station encountered (possibly via the
    EAPOL-Key frame).  The value of this field comes from the IEEE
    802.11 dot11RSNAStatsTKIPRemoteMICFailures MIB element (see
    [IEEE.802-11.2007]).
 CCMP Replays:   A 32-bit value representing the number of CCMP MPDUs
    discarded by the replay detection mechanism.  The value of this
    field comes from the IEEE 802.11 dot11RSNACCMPReplays MIB element
    (see [IEEE.802-11.2007]).
 CCMP Decrypt Errors:   A 32-bit value representing the number of CCMP
    MDPUs discarded by the decryption algorithm.  The value of this
    field comes from the IEEE 802.11 dot11RSNACCMPDecryptErrors MIB
    element (see [IEEE.802-11.2007]).
 TKIP Replays:   A 32-bit value representing the number of TKIP
    Replays detected in frames received from the station.  The value
    of this field comes from the IEEE 802.11 dot11RSNAStatsTKIPReplays
    MIB element (see [IEEE.802-11.2007]).

6.13. IEEE 802.11 Station

 The IEEE 802.11 Station message element accompanies the Add Station
 message element, and is used to deliver IEEE 802.11 station policy
 from the AC to the WTP.
 The latest IEEE 802.11 Station message element overrides any
 previously received message elements.
 If the QoS field is set, the WTP MUST observe and provide policing of
 the 802.11e priority tag to ensure that it does not exceed the value
 provided by the AC.

Calhoun, et al. Standards Track [Page 46] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Radio ID   |        Association ID         |     Flags     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           MAC Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          MAC Address          |          Capabilities         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   WLAN ID     |Supported Rates|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Type:   1036 for IEEE 802.11 Station
 Length:   >= 14
 Radio ID:   An 8-bit value representing the radio, whose value is
    between one (1) and 31.
 Association ID:   A 16-bit value specifying the IEEE 802.11
    Association Identifier.
 Flags:   All implementations complying with this protocol MUST set to
    zero any bits that are reserved in the version of the protocol
    supported by that implementation.  Receivers MUST ignore all bits
    not defined for the version of the protocol they support.
 MAC Address:   The station's MAC Address
 Capabilities:   A 16-bit field containing the IEEE 802.11
    Capabilities Information Field to use with the station.
 WLAN ID:   An 8-bit value specifying the WLAN Identifier.  The value
    MUST be between one (1) and 16.
 Supported Rates:   The variable-length field containing the supported
    rates to be used with the station, as found in the IEEE 802.11
    dot11OperationalRateSet MIB element (see [IEEE.802-11.2007]).
    This field MUST NOT exceed 126 octets and specifies the set of
    data rates at which the station may transmit data, where each
    octet represents a data rate.

6.14. IEEE 802.11 Station QoS Profile

 The IEEE 802.11 Station QoS Profile message element contains the
 maximum IEEE 802.11e priority tag that may be used by the station.
 Any packet received that exceeds the value encoded in this message
 element MUST be tagged using the maximum value permitted by to the

Calhoun, et al. Standards Track [Page 47] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

 user.  The priority tag MUST be between zero (0) and seven (7).  This
 message element MUST NOT be present without the IEEE 802.11 Station
 (see Section 6.13) message element.
      0                   1                   2                   3
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           MAC Address                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          MAC Address          |         Reserved        |8021p|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Type:   1037 for IEEE 802.11 Station QoS Profile
 Length:   8
 MAC Address:   The station's MAC Address
 Reserved:   All implementations complying with this protocol MUST set
    to zero any bits that are reserved in the version of the protocol
    supported by that implementation.  Receivers MUST ignore all bits
    not defined for the version of the protocol they support.
 8021p:   The maximum 802.1p priority value that the WTP will allow in
    the Traffic Identifier (TID) field in the extended 802.11e QoS
    Data header.

6.15. IEEE 802.11 Station Session Key

 The IEEE 802.11 Station Session Key message element is sent by the AC
 to provision encryption keys, or to configure an access policy, on
 the WTP.  This message element MUST NOT be present without the IEEE
 802.11 Station (see Section 6.13) message element, and MUST NOT be
 sent if the WTP had not specifically advertised support for the
 requested encryption scheme, through the WTP Descriptor Message
 Element's Encryption Capabilities field (see Section 8.1).
 When the Key field is non-zero in length, the RSN Information Element
 MUST be sent along with the IEEE 802.11 Station Session Key in order
 to instruct the WTP on the usage of the Key field.  The WTP MUST
 observe the Authentication and Key Management (AKM) field of the RSN
 Information Element in order to identify the authentication protocol
 to be enforced with the station.
 If cryptographic services are provided at the WTP, the WTP MUST
 observe the algorithm dictated in the Pairwise Cipher Suite field of
 the RSN Information Element sent by the AC.  The RSN Information
 Element included here is the one sent by the AC in the third message

Calhoun, et al. Standards Track [Page 48] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

 of the 4-Way Key Handshake, which specifies which cipher is to be
 applied to provide encryption and decryption services with the
 station.  The RSN Information Element is used to communicate any
 supported algorithm, including WEP, TKIP, and AES-CCMP.  In the case
 of static WEP keys, the RSN Information Element is still used to
 indicate the cryptographic algorithm even though no key exchange
 occurred.
 If the IEEE 802.11 Station Session Key message element's 'AKM-Only'
 bit is set, the WTP MUST drop all IEEE 802.11 packets that are not
 part of the Authentication and Key Management (AKM), such as EAP.
 Note that AKM-Only MAY be set while an encryption key is in force,
 requiring that the AKM packets be encrypted.  Once the station has
 successfully completed authentication via the AKM, the AC MUST send a
 new Add Station message element to remove the AKM-Only restriction,
 and optionally push the session key down to the WTP.
      0                   1                   2                   3
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           MAC Address                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          MAC Address          |A|C|           Flags           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Pairwise TSC                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Pairwise TSC          |         Pairwise RSC          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Pairwise RSC                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Key...
     +-+-+-+-+-+-+-+-
 Type:   1038 for IEEE 802.11 Station Session Key
 Length:   >= 25
 MAC Address:   The station's MAC Address
 Flags:   All implementations complying with this protocol MUST set to
    zero any bits that are reserved in the version of the protocol
    supported by that implementation.  Receivers MUST ignore all bits
    not defined for the version of the protocol they support.  The
    following bits are defined:

Calhoun, et al. Standards Track [Page 49] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

    A:   The 1-bit AKM-Only field is set by the AC to inform the WTP
         that is MUST NOT accept any 802.11 Data Frames other than AKM
         frames.  This is the equivalent of the WTP's IEEE 802.1X port
         for the station to be in the closed state.  When set, the WTP
         MUST drop any non-IEEE 802.1X packets it receives from the
         station.
    C:   The 1-bit field is set by the AC to inform the WTP that
         encryption services will be provided by the AC.  When set,
         the WTP SHOULD police frames received from stations to ensure
         that they are properly encrypted as specified in the RSN
         Information Element, but does not need to take specific
         cryptographic action on the frame.  Similarly, for
         transmitted frames, the WTP only needs to forward already
         encrypted frames.  Since packets received by the WTP will be
         encrypted, the WTP cannot modify the contents of the packets,
         including modifying the DSCP markings of the encapsulated
         packet.  In this case, this function would be the
         responsibility of the AC.
 Pairwise TSC:   The 6-byte Transmit Sequence Counter (TSC) field to
    use for unicast packets transmitted to the station.
 Pairwise RSC:   The 6-byte Receive Sequence Counter (RSC) to use for
    unicast packets received from the station.
 Key:   The pairwise key the WTP is to use when encrypting traffic to/
    from the station.  The format of the keys differs based on the
    crypto algorithm used.  For unicast WEP keys, the Key field
    consists of the actual unicast encryption key (note, this is used
    when WEP is used in conjunction with 802.1X, and therefore a
    unicast encryption key exists).  When used with CCMP, the Key
    field includes the 128-bit Temporal Key.  When used with TKIP, the
    Key field includes the 256-bit Temporal Key (which consists of a
    128-bit key used as input for TKIP key mixing, and two 64-bit keys
    used for Michael).

6.16. IEEE 802.11 Statistics

 The IEEE 802.11 Statistics message element is sent by the WTP to
 transmit its current statistics, and it contains the following
 fields.  All of the fields in this message element are set to zero
 upon WTP initialization.  The fields will roll over when they reach
 their maximum value of 4294967295.  Due to the nature of each counter
 representing different data points, the rollover event will vary

Calhoun, et al. Standards Track [Page 50] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

 greatly across each field.  Applications or human operators using
 these counters need to be aware of the minimal possible times between
 rollover events in order to make sure that no consecutive rollover
 events are missed.
      0                   1                   2                   3
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Radio ID   |                   Reserved                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Tx Fragment Count                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Multicast Tx Count                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Failed Count                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Retry Count                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Multiple Retry Count                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Frame Duplicate Count                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       RTS Success Count                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       RTS Failure Count                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       ACK Failure Count                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Rx Fragment Count                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Multicast RX Count                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        FCS Error  Count                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Tx Frame Count                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Decryption Errors                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  Discarded QoS Fragment Count                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    Associated Station Count                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  QoS CF Polls Received Count                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   QoS CF Polls Unused Count                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  QoS CF Polls Unusable Count                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Calhoun, et al. Standards Track [Page 51] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

 Type:   1039 for IEEE 802.11 Statistics
 Length:   80
 Radio ID:   An 8-bit value representing the radio, whose value is
    between one (1) and 31.
 Reserved:   All implementations complying with this protocol MUST set
    to zero any bits that are reserved in the version of the protocol
    supported by that implementation.  Receivers MUST ignore all bits
    not defined for the version of the protocol they support.
 Tx Fragment Count:   A 32-bit value representing the number of
    fragmented frames transmitted.  The value of this field comes from
    the IEEE 802.11 dot11TransmittedFragmentCount MIB element (see
    [IEEE.802-11.2007]).
 Multicast Tx Count:   A 32-bit value representing the number of
    multicast frames transmitted.  The value of this field comes from
    the IEEE 802.11 dot11MulticastTransmittedFrameCount MIB element
    (see [IEEE.802-11.2007]).
 Failed Count:   A 32-bit value representing the transmit excessive
    retries.  The value of this field comes from the IEEE 802.11
    dot11FailedCount MIB element (see [IEEE.802-11.2007]).
 Retry Count:   A 32-bit value representing the number of transmit
    retries.  The value of this field comes from the IEEE 802.11
    dot11RetryCount MIB element (see [IEEE.802-11.2007]).
 Multiple Retry Count:   A 32-bit value representing the number of
    transmits that required more than one retry.  The value of this
    field comes from the IEEE 802.11 dot11MultipleRetryCount MIB
    element (see [IEEE.802-11.2007]).
 Frame Duplicate Count:   A 32-bit value representing the duplicate
    frames received.  The value of this field comes from the IEEE
    802.11 dot11FrameDuplicateCount MIB element (see
    [IEEE.802-11.2007]).
 RTS Success Count:   A 32-bit value representing the number of
    successfully transmitted Ready To Send (RTS).  The value of this
    field comes from the IEEE 802.11 dot11RTSSuccessCount MIB element
    (see [IEEE.802-11.2007]).

Calhoun, et al. Standards Track [Page 52] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

 RTS Failure Count:   A 32-bit value representing the failed
    transmitted RTS.  The value of this field comes from the IEEE
    802.11 dot11RTSFailureCount MIB element (see [IEEE.802-11.2007]).
 ACK Failure Count:   A 32-bit value representing the number of failed
    acknowledgements.  The value of this field comes from the IEEE
    802.11 dot11ACKFailureCount MIB element (see [IEEE.802-11.2007]).
 Rx Fragment Count:   A 32-bit value representing the number of
    fragmented frames received.  The value of this field comes from
    the IEEE 802.11 dot11ReceivedFragmentCount MIB element (see
    [IEEE.802-11.2007]).
 Multicast RX Count:   A 32-bit value representing the number of
    multicast frames received.  The value of this field comes from the
    IEEE 802.11 dot11MulticastReceivedFrameCount MIB element (see
    [IEEE.802-11.2007]).
 FCS Error Count:   A 32-bit value representing the number of FCS
    failures.  The value of this field comes from the IEEE 802.11
    dot11FCSErrorCount MIB element (see [IEEE.802-11.2007]).
 Decryption Errors:   A 32-bit value representing the number of
    Decryption errors that occurred on the WTP.  Note that this field
    is only valid in cases where the WTP provides encryption/
    decryption services.  The value of this field comes from the IEEE
    802.11 dot11WEPUndecryptableCount MIB element (see
    [IEEE.802-11.2007]).
 Discarded QoS Fragment Count:   A 32-bit value representing the
    number of discarded QoS fragments received.  The value of this
    field comes from the IEEE 802.11 dot11QoSDiscardedFragmentCount
    MIB element (see [IEEE.802-11.2007]).
 Associated Station Count:   A 32-bit value representing the number of
    number of associated stations.  The value of this field comes from
    the IEEE 802.11 dot11AssociatedStationCount MIB element (see
    [IEEE.802-11.2007]).
 QoS CF Polls Received Count:   A 32-bit value representing the number
    of (+)CF-Polls received.  The value of this field comes from the
    IEEE 802.11 dot11QosCFPollsReceivedCount MIB element (see
    [IEEE.802-11.2007]).
 QoS CF Polls Unused Count:   A 32-bit value representing the number
    of (+)CF-Polls that have been received, but not used.  The value
    of this field comes from the IEEE 802.11
    dot11QosCFPollsUnusedCount MIB element (see [IEEE.802-11.2007]).

Calhoun, et al. Standards Track [Page 53] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

 QoS CF Polls Unusable Count:   A 32-bit value representing the number
    of (+)CF-Polls that have been received, but could not be used due
    to the Transmission Opportunity (TXOP) size being smaller than the
    time that is required for one frame exchange sequence.  The value
    of this field comes from the IEEE 802.11
    dot11QosCFPollsUnusableCount MIB element (see [IEEE.802-11.2007]).

6.17. IEEE 802.11 Supported Rates

 The IEEE 802.11 Supported Rates message element is sent by the WTP to
 indicate the rates that it supports, and contains the following
 fields.
      0                   1                   2                   3
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Radio ID   |               Supported Rates...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Type:   1040 for IEEE 802.11 Supported Rates
 Length:   >= 3
 Radio ID:   An 8-bit value representing the radio, whose value is
    between one (1) and 31.
 Supported Rates:   The WTP includes the Supported Rates that its
    hardware supports.  The format is identical to the Rate Set
    message element and is between 2 and 8 bytes in length.

6.18. IEEE 802.11 Tx Power

 The IEEE 802.11 Tx Power message element value is bi-directional.
 When sent by the WTP, it contains the current power level of the
 radio in question.  When sent by the AC, it contains the power level
 to which the WTP MUST adhere.
      0                   1                   2                   3
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Radio ID   |    Reserved   |        Current Tx Power       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Type:   1041 for IEEE 802.11 Tx Power

Calhoun, et al. Standards Track [Page 54] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

 Length:   4
 Radio ID:   An 8-bit value representing the radio to configure, whose
    value is between one (1) and 31.
 Reserved:   All implementations complying with this protocol MUST set
    to zero any bits that are reserved in the version of the protocol
    supported by that implementation.  Receivers MUST ignore all bits
    not defined for the version of the protocol they support.
 Current Tx Power:   This attribute contains the current transmit
    output power in mW, as described in the dot11CurrentTxPowerLevel
    MIB variable, see [IEEE.802-11.2007].

6.19. IEEE 802.11 Tx Power Level

 The IEEE 802.11 Tx Power Level message element is sent by the WTP and
 contains the different power levels supported.  The values found in
 this message element are found in the IEEE 802.11
 Dot11PhyTxPowerEntry MIB table, see [IEEE.802-11.2007].
 The value field contains the following:
      0                   1                   2                   3
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Radio ID   |   Num Levels  |        Power Level [n]        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Type:   1042 for IEEE 802.11 Tx Power Level
 Length:   >= 4
 Radio ID:   An 8-bit value representing the radio to configure, whose
    value is between one (1) and 31.
 Num Levels:   The number of power level attributes.  The value of
    this field comes from the IEEE 802.11
    dot11NumberSupportedPowerLevels MIB element (see
    [IEEE.802-11.2007]).
 Power Level:   Each power level field contains a supported power
    level, in mW.  The value of this field comes from the
    corresponding IEEE 802.11 dot11TxPowerLevel[n] MIB element, see
    [IEEE.802-11.2007].

Calhoun, et al. Standards Track [Page 55] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

6.20. IEEE 802.11 Update Station QoS

 The IEEE 802.11 Update Station QoS message element is used to change
 the Quality of Service policy on the WTP for a given station.  The
 QoS tags included in this message element are to be applied to
 packets received at the WTP from the station indicated through the
 MAC Address field.  This message element overrides the default values
 provided through the IEEE 802.11 WTP Quality of Service message
 element (see Section 6.22).  Any tagging performed by the WTP MUST be
 directly applied to the packets received from the station, as well as
 the CAPWAP tunnel, if the packets are tunneled to the AC.  See
 Section 2.6 for more information.
    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Radio ID    |                  MAC Address                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          MAC Address          |       QoS Sub-Element...      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Type:   1043 for IEEE 802.11 Update Station QoS
 Length:   8
 Radio ID:   The Radio Identifier, whose value is between one (1) and
    31, typically refers to some interface index on the WTP.
 MAC Address:   The station's MAC Address.
 QoS Sub-Element:   The IEEE 802.11 WTP Quality of Service message
    element contains four QoS sub-elements, one for every QoS profile.
    The order of the QoS profiles are Voice, Video, Best Effort, and
    Background.
    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Reserved|8021p|RSV| DSCP Tag  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    Reserved:   All implementations complying with this protocol MUST
       set to zero any bits that are reserved in the version of the
       protocol supported by that implementation.  Receivers MUST
       ignore all bits not defined for the version of the protocol
       they support.

Calhoun, et al. Standards Track [Page 56] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

    8021p:   The 3-bit 802.1p priority value to use if packets are to
       be IEEE 802.1p tagged.  This field is used only if the 'P' bit
       in the WTP Quality of Service message element was set;
       otherwise, its contents MUST be ignored.
    RSV:   All implementations complying with this protocol MUST set
       to zero any bits that are reserved in the version of the
       protocol supported by that implementation.  Receivers MUST
       ignore all bits not defined for the version of the protocol
       they support.
    DSCP Tag:   The 6-bit DSCP label to use if packets are eligible to
       be DSCP tagged, specifically an IPv4 or IPv6 packet (see
       [RFC2474]).  This field is used only if the 'D' bit in the WTP
       Quality of Service message element was set; otherwise, its
       contents MUST be ignored.

6.21. IEEE 802.11 Update WLAN

 The IEEE 802.11 Update WLAN message element is used by the AC to
 define a wireless LAN on the WTP.  The inclusion of this message
 element MUST also include the IEEE 802.11 Information Element message
 element, containing the following 802.11 IEs:
 Power Constraint information element
 WPA information element  [WPA]
 RSN information element
 Enhanced Distributed Channel Access (EDCA) Parameter Set information
    element
 QoS Capability information element
 WMM information element  [WMM]
 These IEEE 802.11 Information Elements are stored by the WTP and
 included in any Probe Responses and Beacons generated, as specified
 in the IEEE 802.11 standard [IEEE.802-11.2007].
 If cryptographic services are provided at the WTP, the WTP MUST
 observe the algorithm dictated in the Group Cipher Suite field of the
 RSN Information Element sent by the AC.  The RSN Information Element
 is used to communicate any supported algorithm, including WEP, TKIP,
 and AES-CCMP.  In the case of static WEP keys, the RSN Information
 Element is still used to indicate the cryptographic algorithm even
 though no key exchange occurred.

Calhoun, et al. Standards Track [Page 57] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

 The message element uses the following format:
      0                   1                   2                   3
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Radio ID   |     WLAN ID   |           Capability          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Key Index   |   Key Status  |           Key Length          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             Key...                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Type:   1044 for IEEE 802.11 Update WLAN
 Length:   >= 8
 Radio ID:   An 8-bit value representing the radio, whose value is
    between one (1) and 31.
 WLAN ID:   An 8-bit value specifying the WLAN Identifier.  The value
    MUST be between one (1) and 16.
 Capability:   A 16-bit value containing the Capability information
    field to be advertised by the WTP in the Probe Request and Beacon
    frames.  Each bit of the Capability field represents a different
    WTP capability, which are described in detail in
    [IEEE.802-11.2007].  The format of the field is:
      0                   1
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |E|I|C|F|P|S|B|A|M|Q|T|D|V|O|K|L|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    E (ESS):   The AC MUST set the Extended Service Set (ESS) subfield
      to 1.
    I (IBSS):   The AC MUST set the Independent Basic Service Set
      (IBSS) subfield to 0.
    C (CF-Pollable):   The AC sets the Contention Free Pollable (CF-
      Pollable) subfield based on the table found in
      [IEEE.802-11.2007].
    F (CF-Poll Request):   The AC sets the CF-Poll Request subfield
      based on the table found in [IEEE.802-11.2007].

Calhoun, et al. Standards Track [Page 58] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

    P (Privacy):   The AC sets the Privacy subfield based on the
      confidentiality requirements of the WLAN, as defined in
      [IEEE.802-11.2007].
    S (Short Preamble):   The AC sets the Short Preamble subfield
      based on whether the use of short preambles are permitted on the
      WLAN, as defined in [IEEE.802-11.2007].
    B (PBCC):   The AC sets the Packet Binary Convolutional Code
      (PBCC) modulation option subfield based on whether the use of
      PBCC is permitted on the WLAN, as defined in [IEEE.802-11.2007].
    A (Channel Agility):   The AC sets the Channel Agility subfield
      based on whether the WTP is capable of supporting the High Rate
      Direct Sequence Spread Spectrum (HR/DSSS), as defined in
      [IEEE.802-11.2007].
    M (Spectrum Management):   The AC sets the Spectrum Management
      subfield according to the value of the
      dot11SpectrumManagementRequired MIB variable, as defined in
      [IEEE.802-11.2007].
    Q (QoS):   The AC sets the Quality of Service (QoS) subfield based
      on the table found in [IEEE.802-11.2007].
    T (Short Slot Time):   The AC sets the Short Slot Time subfield
      according to the value of the WTP's currently used slot time
      value, as defined in [IEEE.802-11.2007].
    D (APSD):   The AC sets the APSD subfield according to the value
      of the dot11APSDOptionImplemented Management Information Base
      (MIB) variable, as defined in [IEEE.802-11.2007].
    V (Reserved):   The AC sets the Reserved subfield to zero, as
      defined in [IEEE.802-11.2007].
    O (DSSS-OFDM):   The AC sets the DSSS-OFDM subfield to indicate
      the use of Direct Sequence Spread Spectrum with Orthogonal
      Frequency Division Multiplexing (DSSS-OFDM), as defined in
      [IEEE.802-11.2007].
    K (Delayed Block ACK):   The AC sets the Delayed Block ACK
      subfield according to the value of the
      dot11DelayedBlockAckOptionImplemented MIB variable, as defined
      in [IEEE.802-11.2007].

Calhoun, et al. Standards Track [Page 59] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

    L (Immediate Block ACK):   The AC sets the Delayed Block ACK
      subfield according to the value of the
      dot11ImmediateBlockAckOptionImplemented MIB variable, as defined
      in [IEEE.802-11.2007].
 Key-Index:   The Key-Index associated with the key.
 Key Status:   A 1-byte value that specifies the state and usage of
    the key that has been included.  The following values describe the
    key usage and its status:
    0 -  A value of zero, with the inclusion of the RSN Information
         Element means that the WLAN uses per-station encryption keys,
         and therefore the key in the 'Key' field is only used for
         multicast traffic.
    1 -  When set to one, the WLAN employs a shared WEP key, also
         known as a static WEP key, and uses the encryption key for
         both unicast and multicast traffic for all stations.
    2 -  The value of 2 indicates that the AC will begin rekeying the
         GTK with the STA's in the BSS.  It is only valid when IEEE
         802.11 is enabled as the security policy for the BSS.
    3 -  The value of 3 indicates that the AC has completed rekeying
         the GTK and broadcast packets no longer need to be duplicated
         and transmitted with both GTK's.
 Key Length:   A 16-bit value representing the length of the Key
    field.
 Key:   A Session Key, whose length is known via the Key Length field,
    used to provide data privacy.  For static WEP keys, which is true
    when the 'Key Status' bit is set to one, this key is used for both
    unicast and multicast traffic.  For encryption schemes that employ
    a separate encryption key for unicast and multicast traffic, the
    key included here only applies to multicast data, and the cipher
    suite is specified in an accompanied RSN Information Element.  In
    these scenarios, the key, and cipher information, is communicated
    via the Add Station message element, see Section 4.6.8 in
    [RFC5415].  When used with WEP, the Key field includes the
    broadcast key.  When used with CCMP, the Key field includes the
    128-bit Group Temporal Key.  When used with TKIP, the Key field
    includes the 256-bit Group Temporal Key (which consists of a 128-
    bit key used as input for TKIP key mixing, and two 64-bit keys
    used for Michael).

Calhoun, et al. Standards Track [Page 60] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

6.22. IEEE 802.11 WTP Quality of Service

 The IEEE 802.11 WTP Quality of Service message element value is sent
 by the AC to the WTP to communicate Quality of Service configuration
 information.  The QoS tags included in this message element are the
 default QoS values to be applied to packets received by the WTP from
 stations on a particular radio.  Any tagging performed by the WTP
 MUST be directly applied to the packets received from the station, as
 well as the CAPWAP tunnel, if the packets are tunneled to the AC.
 See Section 2.6 for more information.
      0                   1                   2                   3
      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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Radio ID    |Tagging Policy |       QoS Sub-Element ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Type:   1045 for IEEE 802.11 WTP Quality of Service
 Length:   34
 Radio ID:   The Radio Identifier, whose value is between one (1) and
    31, typically refers to some interface index on the WTP.
 Tagging Policy:   A bit field indicating how the WTP is to mark
    packets for QoS purposes.  The required WTP behavior is defined in
    Section 2.6.1.  The field has the following format:
       0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+
      |Rsvd |P|Q|D|O|I|
      +-+-+-+-+-+-+-+-+
    Rsvd:  A set of reserved bits for future use.  All implementations
       complying with this protocol MUST set to zero any bits that are
       reserved in the version of the protocol supported by that
       implementation.  Receivers MUST ignore all bits not defined for
       the version of the protocol they support.
    P:   When set, the WTP is to employ the 802.1p QoS mechanism (see
         Section 2.6.1.1), and the WTP is to use the 'Q' bit.
    Q:   When the 'P' bit is set, the 'Q' bit is used by the AC to
         communicate to the WTP how 802.1p QoS is to be enforced.
         Details on the behavior of the 'Q' bit are specified in
         Section 2.6.1.1.

Calhoun, et al. Standards Track [Page 61] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

    D:   When set, the WTP is to employ the DSCP QoS mechanism (see
         Section 2.6.1.2), and the WTP is to use the 'O' and 'I' bits.
    O:   When the 'D' bit is set, the 'O' bit is used by the AC to
         communicate to the WTP how DSCP QoS is to be enforced on the
         outer (tunneled) header.  Details on the behavior of the 'O'
         bit are specified in Section 2.6.1.2.
    I:   When the 'D' bit is set, the 'I' bit is used by the AC to
         communicate to the WTP how DSCP QoS is to be enforced on the
         station's packet (inner) header.  Details on the behavior of
         the 'I' bit are specified in Section 2.6.1.2.
 QoS Sub-Element:   The IEEE 802.11 WTP Quality of Service message
    element contains four QoS sub-elements, one for every QoS profile.
    The order of the QoS profiles are Voice, Video, Best Effort, and
    Background.
    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Queue Depth  |             CWMin             |     CWMax     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     CWMax     |     AIFS      | Reserved|8021p|RSV| DSCP Tag  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    Queue Depth:   The number of packets that can be on the specific
       QoS transmit queue at any given time.
    CWMin:   The Contention Window minimum (CWmin) value for the QoS
       transmit queue.  The value of this field comes from the IEEE
       802.11 dot11EDCATableCWMin MIB element (see
       [IEEE.802-11.2007]).
    CWMax:   The Contention Window maximum (CWmax) value for the QoS
       transmit queue.  The value of this field comes from the IEEE
       802.11 dot11EDCATableCWMax MIB element (see
       [IEEE.802-11.2007]).
    AIFS:   The Arbitration Inter Frame Spacing (AIFS) to use for the
       QoS transmit queue.  The value of this field comes from the
       IEEE 802.11 dot11EDCATableAIFSN MIB element (see
       [IEEE.802-11.2007]).

Calhoun, et al. Standards Track [Page 62] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

    Reserved:   All implementations complying with this protocol MUST
       set to zero any bits that are reserved in the version of the
       protocol supported by that implementation.  Receivers MUST
       ignore all bits not defined for the version of the protocol
       they support.
    8021p:   The 3-bit 802.1p priority value to use if packets are to
       be IEEE 802.1p tagged.  This field is used only if the 'P' bit
       is set; otherwise, its contents MUST be ignored.
    RSV:   All implementations complying with this protocol MUST set
       to zero any bits that are reserved in the version of the
       protocol supported by that implementation.  Receivers MUST
       ignore all bits not defined for the version of the protocol
       they support.
    DSCP Tag:   The 6-bit DSCP label to use if packets are eligible to
       be DSCP tagged, specifically an IPv4 or IPv6 packet (see
       [RFC2474]).  This field is used only if the 'D' bit is set;
       otherwise, its contents MUST be ignored.

6.23. IEEE 802.11 WTP Radio Configuration

 The IEEE 802.11 WTP WLAN Radio Configuration message element is used
 by the AC to configure a Radio on the WTP, and by the WTP to deliver
 its radio configuration to the AC.  The message element value
 contains the following fields:
       0                   1                   2                   3
       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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Radio ID   |Short Preamble| Num of BSSIDs |  DTIM Period  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            BSSID                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          BSSID                |      Beacon Period            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Country String                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Type:   1046 for IEEE 802.11 WTP WLAN Radio Configuration
 Length:   16
 Radio ID:   An 8-bit value representing the radio to configure, whose
    value is between one (1) and 31.

Calhoun, et al. Standards Track [Page 63] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

 Short Preamble:   An 8-bit value indicating whether short preamble is
    supported.  The following enumerated values are currently
    supported:
    0 -  Short preamble not supported.
    1 -  Short preamble is supported.
 BSSID:   The WLAN Radio's base MAC Address.
 Number of BSSIDs:   This attribute contains the maximum number of
    BSSIDs supported by the WTP.  This value restricts the number of
    logical networks supported by the WTP, and is between 1 and 16.
 DTIM Period:   This attribute specifies the number of Beacon
    intervals that elapse between transmission of Beacons frames
    containing a Traffic Indication Map (TIM) element whose Delivery
    Traffic Indication Message (DTIM) Count field is 0.  This value is
    transmitted in the DTIM Period field of Beacon frames.  The value
    of this field comes from the IEEE 802.11 dot11DTIMPeriod MIB
    element (see [IEEE.802-11.2007]).
 Beacon Period:   This attribute specifies the number of Time Unit
    (TU) that a station uses for scheduling Beacon transmissions.
    This value is transmitted in Beacon and Probe Response frames.
    The value of this field comes from the IEEE 802.11
    dot11BeaconPeriod MIB element (see [IEEE.802-11.2007]).
 Country String:   This attribute identifies the country in which the
    station is operating.  The value of this field comes from the IEEE
    802.11 dot11CountryString MIB element (see [IEEE.802-11.2007]).
    Some regulatory domains do not allow WTPs to have user
    configurable country string, and require that it be a fixed value
    during the manufacturing process.  Therefore, WTP vendors that
    wish to allow for the configuration of this field will need to
    validate this behavior during its radio certification process.
    Other WTP vendors may simply wish to treat this WTP configuration
    parameter as read-only.  The country strings can be found in
    [ISO.3166-1].
    The WTP and AC MAY ignore the value of this field, depending upon
    regulatory requirements, for example to avoid classification as a
    Software-Defined Radio.  When this field is used, the first two
    octets of this string is the two-character country string as
    described in [ISO.3166-1], and the third octet MUST either be a
    space, 'O', 'I', or X' as defined below.  When the value of the

Calhoun, et al. Standards Track [Page 64] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

    third octet is 255 (HEX 0xff), the country string field is not
    used, and MUST be ignored.  The following are the possible values
    for the third octet:
    1.   an ASCII space character, if the regulations under which the
         station is operating encompass all environments in the
         country,
    2.   an ASCII 'O' character, if the regulations under which the
         station is operating are for an outdoor environment only, or
    3.   an ASCII 'I' character, if the regulations under which the
         station is operating are for an indoor environment only,
    4.   an ASCII 'X' character, if the station is operating under a
         non-country entity.  The first two octets of the non-country
         entity shall be two ASCII 'XX' characters,
    5.   a HEX 0xff character means that the country string field is
         not used and MUST be ignored.
    Note that the last byte of the Country String MUST be set to NULL.

6.24. IEEE 802.11 WTP Radio Fail Alarm Indication

 The IEEE 802.11 WTP Radio Fail Alarm Indication message element is
 sent by the WTP to the AC when it detects a radio failure.
    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Radio ID    |     Type      |    Status     |      Pad      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Type:   1047 for IEEE 802.11 WTP Radio Fail Alarm Indication
 Length:   4
 Radio ID:   The Radio Identifier, whose value is between one (1) and
    31, typically refers to some interface index on the WTP.
 Type:   The type of radio failure detected.  The following enumerated
    values are supported:
    1 -  Receiver
    2 -  Transmitter

Calhoun, et al. Standards Track [Page 65] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

 Status:   An 8-bit boolean indicating whether the radio failure is
    being reported or cleared.  A value of zero is used to clear the
    event, while a value of one is used to report the event.
 Pad:   All implementations complying with version zero of this
    protocol MUST set these bits to zero.  Receivers MUST ignore all
    bits not defined for the version of the protocol they support.

6.25. IEEE 802.11 WTP Radio Information

 The IEEE 802.11 WTP Radio Information message element is used to
 communicate the radio information for each IEEE 802.11 radio in the
 WTP.  The Discovery Request message, Primary Discovery Request
 message, and Join Request message MUST include one such message
 element per radio in the WTP.  The Radio-Type field is used by the AC
 in order to determine which IEEE 802.11 technology specific binding
 is to be used with the WTP.
 The message element contains two fields, as shown below.
    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Radio ID    |                  Radio Type                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Radio Type   |
   +-+-+-+-+-+-+-+-+
 Type:   1048 for IEEE 802.11 WTP Radio Information
 Length:   5
 Radio ID:   The Radio Identifier, whose value is between one (1) and
    31, which typically refers to an interface index on the WTP.
 Radio Type:   The type of radio present.  Note this is a bit field
    that is used to specify support for more than a single type of
    PHY/MAC.  The field has the following format:
       0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+
      |Reservd|N|G|A|B|
      +-+-+-+-+-+-+-+-+

Calhoun, et al. Standards Track [Page 66] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

    Reservd:  A set of reserved bits for future use.  All
       implementations complying with this protocol MUST set to zero
       any bits that are reserved in the version of the protocol
       supported by that implementation.  Receivers MUST ignore all
       bits not defined for the version of the protocol they support.
    N:   An IEEE 802.11n radio.
    G:   An IEEE 802.11g radio.
    A:   An IEEE 802.11a radio.
    B:   An IEEE 802.11b radio.

7. IEEE 802.11 Binding WTP Saved Variables

 This section contains the IEEE 802.11 binding specific variables that
 SHOULD be saved in non-volatile memory on the WTP.

7.1. IEEE80211AntennaInfo

 The WTP-per-radio antenna configuration, defined in Section 6.2.

7.2. IEEE80211DSControl

 The WTP-per-radio Direct Sequence Control configuration, defined in
 Section 6.5.

7.3. IEEE80211MACOperation

 The WTP-per-radio MAC Operation configuration, defined in
 Section 6.7.

7.4. IEEE80211OFDMControl

 The WTP-per-radio OFDM MAC Operation configuration, defined in
 Section 6.10.

7.5. IEEE80211Rateset

 The WTP-per-radio Basic Rate Set configuration, defined in
 Section 6.11.

7.6. IEEE80211TxPower

 The WTP-per-radio Transmit Power configuration, defined in
 Section 6.18.

Calhoun, et al. Standards Track [Page 67] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

7.7. IEEE80211QoS

 The WTP-per-radio Quality of Service configuration, defined in
 Section 6.22.

7.8. IEEE80211RadioConfig

 The WTP-per-radio Radio Configuration, defined in Section 6.23.

8. Technology Specific Message Element Values

 This section lists IEEE 802.11-specific values for the generic CAPWAP
 message elements that include fields whose values are technology
 specific.

8.1. WTP Descriptor Message Element, Encryption Capabilities Field

 This specification defines two new bits for the WTP Descriptor's
 Encryption Capabilities field, as defined in [RFC5415].  Note that
 only the bits defined in this specification are described below.  WEP
 is not explicitly advertised as a WTP capability since all WTPs are
 expected to support the encryption cipher.  The format of the
 Encryption Capabilities field is:
                           1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       |A|T|   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 A:   WTP supports AES-CCMP, as defined in [IEEE.802-11.2007].
 T:   WTP supports TKIP and Michael, as defined in [IEEE.802-11.2007]
      and [WPA], respectively.

9. Security Considerations

 This section describes security considerations for using IEEE 802.11
 with the CAPWAP protocol.  A complete threat analysis of the CAPWAP
 protocol can also be found in [RFC5418].

9.1. IEEE 802.11 Security

 When used with an IEEE 802.11 infrastructure with WEP encryption, the
 CAPWAP protocol does not add any new vulnerabilities.  Derived
 Session Keys between the STA and WTP can be compromised, resulting in

Calhoun, et al. Standards Track [Page 68] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

 many well-documented attacks.  Implementers SHOULD discourage the use
 of WEP and encourage the use of technically-sound cryptographic
 solutions such as those in an IEEE 802.11 RSN.
 STA authentication is performed using IEEE 802.lX, and consequently
 EAP.  Implementers SHOULD use EAP methods meeting the requirements
 specified [RFC4017].
 When used with IEEE 802.11 RSN security, the CAPWAP protocol may
 introduce new vulnerabilities, depending on whether the link security
 (packet encryption and integrity verification) is provided by the WTP
 or the AC.  When the link security function is provided by the AC, no
 new security concerns are introduced.
 However, when the WTP provides link security, a new vulnerability
 will exist when the following conditions are true:
 o  The client is not the first to associate to the WTP/ESSID (i.e.,
    other clients are associated), a GTK already exists, and
 o  traffic has been broadcast under the existing GTK.
 Under these circumstances, the receive sequence counter (KeyRSC)
 associated with the GTK is non-zero, but because the AC anchors the
 4-way handshake with the client, the exact value of the KeyRSC is not
 known when the AC constructs the message containing the GTK.  The
 client will update its Key RSC value to the current valid KeyRSC upon
 receipt of a valid multicast/broadcast message, but prior to this,
 previous multicast/broadcast traffic that was secured with the
 existing GTK may be replayed, and the client will accept this traffic
 as valid.
 Typically, busy networks will produce numerous multicast or broadcast
 frames per second, so the window of opportunity with respect to such
 replay is expected to be very small.  In most conditions, it is
 expected that replayed frames could be detected (and logged) by the
 WTP.
 The only way to completely close this window is to provide the exact
 KeyRSC value in message 3 of the 4-way handshake; any other approach
 simply narrows the window to varying degrees.  Given the low relative
 threat level this presents, the additional complexity introduced by
 providing the exact KeyRSC value is not warranted.  That is, this
 specification provides for a calculated risk in this regard.

Calhoun, et al. Standards Track [Page 69] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

 The AC SHOULD use an RSC of 0 when computing message-3 of the 4-way
 802.11i handshake, unless the AC has knowledge of a more optimal RSC
 value to use.  Mechanisms for determining a more optimal RSC value
 are outside the scope of this specification.

10. IANA Considerations

 This section details the actions IANA has taken per this
 specification.  There are numerous registries that have been be
 created, and the contents, document action (see [RFC5226], and
 registry format are all included below.  Note that in cases where bit
 fields are referred to, the bit numbering is left to right, where the
 leftmost bit is labeled as bit zero (0).

10.1. CAPWAP Wireless Binding Identifier

 This specification requires a value assigned from the Wireless
 Binding Identifier namespace, defined in [RFC5415]. (1) has been
 assigned (see Section 2.1, as it is used in implementations.

10.2. CAPWAP IEEE 802.11 Message Types

 IANA created a new sub-registry in the existing CAPWAP Message Type
 registry, which is defined in [RFC5415].
 IANA created and maintains the CAPWAP IEEE 802.11 Message Types
 sub-registry for all message types whose Enterprise Number is set to
 13277.  The namespace is 8 bits (3398912-3399167), where the value
 3398912 is reserved and must not be assigned.  The values 3398913 and
 3398914 are allocated in this specification, and can be found in
 Section 3.  Any new assignments of a CAPWAP IEEE 802.11 Message Type
 (whose Enterprise Number is set to 13277) require an Expert Review.
 The format of the registry maintained by IANA is as follows:
         CAPWAP IEEE 802.11               Message Type     Reference
         Control Message                     Value

10.3. CAPWAP Message Element Type

 This specification defines new values to be registered to the
 existing CAPWAP Message Element Type registry, defined in [RFC5415].
 The values used in this document, 1024 through 1048, as listed in
 Figure 8 are recommended as implementations already exist that make
 use of these values.

Calhoun, et al. Standards Track [Page 70] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

10.4. IEEE 802.11 Key Status

 The Key Status field in the IEEE 802.11 Add WLAN message element (see
 Section 6.1) and IEEE 802.11 Update WLAN message element (see
 Section 6.21) is used to provide information about the status of the
 keying exchange.  This document defines four values, zero (0) through
 three (3), and the remaining values (4-255) are controlled and
 maintained by IANA and requires an Expert Review.

10.5. IEEE 802.11 QoS

 The QoS field in the IEEE 802.11 Add WLAN message element (see
 Section 6.1) is used to configure a QoS policy for the WLAN.  The
 namespace is 8 bits (0-255), where the values zero (0) through three
 (3) are allocated in this specification, and can be found in
 Section 6.1.  This namespace is managed by IANA and assignments
 require an Expert Review.  IANA created the IEEE 802.11 QoS registry,
 whose format is:
         IEEE 802.11 QoS                  Type Value       Reference

10.6. IEEE 802.11 Auth Type

 The Auth Type field in the IEEE 802.11 Add WLAN message element (see
 Section 6.1) is 8 bits and is used to configure the IEEE 802.11
 authentication policy for the WLAN.  The namespace is 8 bits (0-255),
 where the values zero (0) and one (1) are allocated in this
 specification, and can be found in Section 6.1.  This namespace is
 managed by IANA and assignments require an Expert Review.  IANA
 created the IEEE 802.11 Auth Type registry, whose format is:
         IEEE 802.11 Auth Type            Type Value       Reference

10.7. IEEE 802.11 Antenna Combiner

 The Combiner field in the IEEE 802.11 Antenna message element (see
 Section 6.2) is used to provide information about the WTP's antennas.
 The namespace is 8 bits (0-255), where the values one (1) through
 four (4) are allocated in this specification, and can be found in
 Section 6.2.  This namespace is managed by IANA and assignments
 require an Expert Review.  IANA created the IEEE 802.11 Antenna
 Combiner registry, whose format is:
         IEEE 802.11 Antenna Combiner     Type Value       Reference

Calhoun, et al. Standards Track [Page 71] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

10.8. IEEE 802.11 Antenna Selection

 The Antenna Selection field in the IEEE 802.11 Antenna message
 element (see Section 6.2) is used to provide information about the
 WTP's antennas.  The namespace is 8 bits (0-255), where the values
 zero (0) is reserved and used and the values one (1) through two (2)
 are allocated in this specification, and can be found in Section 6.2.
 This namespace is managed by IANA and assignments require an Expert
 Review.  IANA created the IEEE 802.11 Antenna Selection registry,
 whose format is:
         IEEE 802.11 Antenna Selection    Type Value       Reference

10.9. IEEE 802.11 Session Key Flags

 The flags field in the IEEE 802.11 Station Session Key message
 element (see Section 6.15) is 16 bits and is used to configure the
 session key association with the mobile device.  This specification
 defines bits zero (0) and one (1), while bits two (2) through fifteen
 are reserved.  The reserved bits are managed by IANA and assignment
 requires an Expert Review.  IANA created the IEEE 802.11 Session Key
 Flags registry, whose format is:
         IEEE 802.11 Station Session Key   Bit Position    Reference

10.10. IEEE 802.11 Tagging Policy

 The Tagging Policy field in the IEEE 802.11 WTP Quality of Service
 message element (see Section 6.22) is 8 bits and is used to specify
 how the CAPWAP Data Channel packets are to be tagged.  This
 specification defines bits three (3) through seven (7).  The
 remaining bits are managed by IANA and assignment requires an Expert
 Review.  IANA created the IEEE 802.11 Tagging Policy registry, whose
 format is:
         IEEE 802.11 Tagging Policy        Bit Position    Reference

10.11. IEEE 802.11 WTP Radio Fail

 The Type field in the IEEE 802.11 WTP Radio Fail Alarm Indication
 message element (see Section 6.24) is used to provide information on
 why a WTP's radio has failed.  The namespace is 8 bits (0-255), where
 the value zero (0) is reserved and unused, while the values one (1)
 and two (2) are allocated in this specification, and can be found in
 Section 6.24.  This namespace is managed by IANA and assignments
 require an Expert Review.  IANA created the IEEE 802.11 WTP Radio
 Fail registry, whose format is:

Calhoun, et al. Standards Track [Page 72] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

         IEEE 802.11 WTP Radio Fail       Type Value       Reference

10.12. IEEE 802.11 WTP Radio Type

 The Radio Type field in the IEEE 802.11 WTP Radio Information message
 element (see Section 6.25) is 8 bits and is used to provide
 information about the WTP's radio type.  This specification defines
 bits four (4) through seven (7).  The remaining bits are managed by
 IANA and assignment requires an Expert Review.  IANA created the IEEE
 802.11 WTP Radio Type registry, whose format is:
         IEEE 802.11 WTP Radio Type        Bit Position    Reference

10.13. WTP Encryption Capabilities

 The WTP Encryption Capabilities field in the WTP Descriptor message
 element (see Section 8.1) is 16 bits and is used by the WTP to
 indicate its IEEE 802.11 encryption capabilities.  This specification
 defines bits 12 and 13.  The reserved bits are managed by IANA and
 assignment requires an Expert Review.  IANA created the IEEE 802.11
 Encryption Capabilities registry, whose format is:
        IEEE 802.11 Encryption Capabilities  Bit Position    Reference

11. Acknowledgments

 The following individuals are acknowledged for their contributions to
 this binding specification: Puneet Agarwal, Charles Clancy, Pasi
 Eronen, Saravanan Govindan, Scott Kelly, Peter Nilsson, Bob O'Hara,
 David Perkins, Margaret Wasserman, and Yong Zhang.

12. References

12.1. Normative References

 [RFC2119]           Bradner, S., "Key words for use in RFCs to
                     Indicate Requirement Levels", BCP 14, RFC 2119,
                     March 1997.
 [RFC2474]           Nichols, K., Blake, S., Baker, F., and D. Black,
                     "Definition of the Differentiated Services Field
                     (DS Field) in the IPv4 and IPv6 Headers",
                     RFC 2474, December 1998.
 [RFC3246]           Davie, B., Charny, A., Bennet, J., Benson, K., Le
                     Boudec, J., Courtney, W., Davari, S., Firoiu, V.,
                     and D. Stiliadis, "An Expedited Forwarding PHB
                     (Per-Hop Behavior)", RFC 3246, March 2002.

Calhoun, et al. Standards Track [Page 73] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

 [RFC3168]           Ramakrishnan, K., Floyd, S., and D. Black, "The
                     Addition of Explicit Congestion Notification
                     (ECN) to IP", RFC 3168, September 2001.
 [RFC3748]           Aboba, B., Blunk, L., Vollbrecht, J., Carlson,
                     J., and H. Levkowetz, "Extensible Authentication
                     Protocol (EAP)", RFC 3748, June 2004.
 [RFC5226]           Narten, T. and H. Alvestrand, "Guidelines for
                     Writing an IANA Considerations Section in RFCs",
                     BCP 26, RFC 5226, May 2008.
 [FIPS.197.2001]     National Institute of Standards and Technology,
                     "Advanced Encryption Standard (AES)", FIPS PUB
                     197, November 2001, <http://csrc.nist.gov/
                     publications/fips/fips197/fips-197.pdf>.
 [ISO.3166-1]        ISO Standard, "International Organization for
                     Standardization, Codes for the representation of
                     names of countries and their subdivisions - Part
                     1: Country codes", ISO Standard 3166-1:1997,
                     1997.
 [IEEE.802-11.2007]  "Information technology - Telecommunications and
                     information exchange between systems - Local and
                     metropolitan area networks - Specific
                     requirements - Part 11: Wireless LAN Medium
                     Access Control (MAC) and Physical Layer (PHY)
                     specifications", IEEE Standard 802.11, 2007,
                     <http://standards.ieee.org/getieee802/download/
                     802.11-2007.pdf>.
 [RFC5415]           Montemurro, M., Stanley, D., and P. Calhoun,
                     "CAPWAP Protocol Specification", RFC 5415, March
                     2009.
 [IEEE.802-1X.2004]  "Information technology - Telecommunications and
                     information exchange between systems - Local and
                     metropolitan area networks - Specific
                     requirements - Port-Based Network Access
                     Control", IEEE Standard 802.1X, 2004, <http://
                     standards.ieee.org/getieee802/download/
                     802.1X-2004.pdf>.

Calhoun, et al. Standards Track [Page 74] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

 [IEEE.802-1Q.2005]  "Information technology - Telecommunications and
                     information exchange between systems - Local and
                     metropolitan area networks - Specific
                     requirements - Virtual Bridged Local Area
                     Networks", IEEE Standard 802.1Q, 2005, <http://
                     standards.ieee.org/getieee802/download/
                     802.1Q-2005.pdf>.

12.2. Informative References

 [RFC4017]           Stanley, D., Walker, J., and B. Aboba,
                     "Extensible Authentication Protocol (EAP) Method
                     Requirements for Wireless LANs", RFC 4017,
                     March 2005.
 [RFC4118]           Yang, L., Zerfos, P., and E. Sadot, "Architecture
                     Taxonomy for Control and Provisioning of Wireless
                     Access Points (CAPWAP)", RFC 4118, June 2005.
 [RFC5418]           Kelly, S. and C. Clancy, "Control And
                     Provisioning for Wireless Access Points (CAPWAP)
                     Threat Analysis for IEEE 802.11 Deployments",
                     RFC 5418, March 2009.
 [WPA]               "Deploying Wi-Fi Protected Access (WPA) and WPA2
                     in the Enterprise", March 2005, <www.wi-fi.org>.
 [WMM]               "Support for Multimedia Applications with Quality
                     of Service in WiFi Networks)", September 2004,
                     <www.wi-fi.org>.

Calhoun, et al. Standards Track [Page 75] RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009

Editors' Addresses

 Pat R. Calhoun (editor)
 Cisco Systems, Inc.
 170 West Tasman Drive
 San Jose, CA  95134
 Phone: +1 408-902-3240
 EMail: pcalhoun@cisco.com
 Michael P. Montemurro (editor)
 Research In Motion
 5090 Commerce Blvd
 Mississauga, ON  L4W 5M4
 Canada
 Phone: +1 905-629-4746 x4999
 EMail: mmontemurro@rim.com
 Dorothy Stanley (editor)
 Aruba Networks
 1322 Crossman Ave
 Sunnyvale, CA  94089
 Phone: +1 630-363-1389
 EMail: dstanley@arubanetworks.com

Calhoun, et al. Standards Track [Page 76]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5416.txt · Last modified: 2009/03/05 00:24 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki