Network Working Group                                 P. Calhoun, Editor
Internet-Draft                                       Cisco Systems, Inc.
Intended status: Informational                     M. Montemurro, Editor
Expires: April 16, 2007                               Research In Motion
                                                      D. Stanley, Editor
                                                          Aruba Networks
                                                        October 13, 2006


                CAPWAP Protocol Binding for IEEE 802.11
            draft-ietf-capwap-protocol-binding-ieee80211-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 16, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).











Calhoun, Editor, et al.  Expires April 16, 2007                 [Page 1]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


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 (WLAN) protocol.  The
   CAPWAP Protocol Specification is defined separately [1].


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Goals  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Conventions used in this document  . . . . . . . . . . . .  4
     1.3.  Contributing Authors . . . . . . . . . . . . . . . . . . .  4
     1.4.  Acknowledgements . . . . . . . . . . . . . . . . . . . . .  4
     1.5.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  IEEE 802.11 Binding  . . . . . . . . . . . . . . . . . . . . .  6
     2.1.  Split MAC and Local MAC Functionality  . . . . . . . . . .  6
       2.1.1.  Split MAC  . . . . . . . . . . . . . . . . . . . . . .  6
       2.1.2.  Local MAC  . . . . . . . . . . . . . . . . . . . . . .  8
     2.2.  Roaming Behavior . . . . . . . . . . . . . . . . . . . . . 11
     2.3.  Group Key Refresh  . . . . . . . . . . . . . . . . . . . . 12
     2.4.  BSSID to WLAN ID Mapping . . . . . . . . . . . . . . . . . 13
     2.5.  Quality of Service for IEEE 802.11 MAC Management
           Messages . . . . . . . . . . . . . . . . . . . . . . . . . 13
     2.6.  Run State Operation  . . . . . . . . . . . . . . . . . . . 13
   3.  IEEE 802.11 Specific CAPWAP Control Messages . . . . . . . . . 14
     3.1.  IEEE 802.11 WLAN Configuration Request . . . . . . . . . . 14
     3.2.  IEEE 802.11 WLAN Configuration Response  . . . . . . . . . 15
   4.  CAPWAP Data Message Bindings . . . . . . . . . . . . . . . . . 16
   5.  CAPWAP Control Message bindings  . . . . . . . . . . . . . . . 18
     5.1.  Discovery Request Message  . . . . . . . . . . . . . . . . 18
     5.2.  Primary Discovery Request Message  . . . . . . . . . . . . 18
     5.3.  Join Request Request Message . . . . . . . . . . . . . . . 18
     5.4.  Configuration Status Message . . . . . . . . . . . . . . . 18
     5.5.  Configuration Status Response Message  . . . . . . . . . . 19
     5.6.  Configuration Update Request Message . . . . . . . . . . . 19
     5.7.  Station Configuration Request  . . . . . . . . . . . . . . 20
     5.8.  WTP Event Request  . . . . . . . . . . . . . . . . . . . . 20
   6.  IEEE 802.11 Message Element Definitions  . . . . . . . . . . . 21



Calhoun, Editor, et al.  Expires April 16, 2007                 [Page 2]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


     6.1.  IEEE 802.11 Add WLAN . . . . . . . . . . . . . . . . . . . 21
     6.2.  IEEE 802.11 Antenna  . . . . . . . . . . . . . . . . . . . 25
     6.3.  IEEE 802.11 Assigned WTP BSSID . . . . . . . . . . . . . . 26
     6.4.  IEEE 802.11 Delete WLAN  . . . . . . . . . . . . . . . . . 27
     6.5.  IEEE 802.11 Direct Sequence Control  . . . . . . . . . . . 27
     6.6.  IEEE 802.11 Information Element  . . . . . . . . . . . . . 28
     6.7.  IEEE 802.11 MAC Operation  . . . . . . . . . . . . . . . . 29
     6.8.  IEEE 802.11 MIC Countermeasures  . . . . . . . . . . . . . 31
     6.9.  IEEE 802.11 Multi-Domain Capability  . . . . . . . . . . . 31
     6.10. IEEE 802.11 OFDM Control . . . . . . . . . . . . . . . . . 32
     6.11. IEEE 802.11 Rate Set . . . . . . . . . . . . . . . . . . . 33
     6.12. IEEE 802.11 RSNA Error Report From Station . . . . . . . . 34
     6.13. IEEE 802.11 Station  . . . . . . . . . . . . . . . . . . . 36
     6.14. IEEE 802.11 Station QoS Profile  . . . . . . . . . . . . . 37
     6.15. IEEE 802.11 Station Session Key  . . . . . . . . . . . . . 37
     6.16. IEEE 802.11 Statistics . . . . . . . . . . . . . . . . . . 39
     6.17. IEEE 802.11 Supported Rates  . . . . . . . . . . . . . . . 43
     6.18. IEEE 802.11 Tx Power . . . . . . . . . . . . . . . . . . . 43
     6.19. IEEE 802.11 Tx Power Level . . . . . . . . . . . . . . . . 44
     6.20. IEEE 802.11 Update Station QoS . . . . . . . . . . . . . . 44
     6.21. IEEE 802.11 Update WLAN  . . . . . . . . . . . . . . . . . 45
     6.22. IEEE 802.11 WTP Quality of Service . . . . . . . . . . . . 47
     6.23. IEEE 802.11 WTP Radio Configuration  . . . . . . . . . . . 48
     6.24. IEEE 802.11 WTP Radio Fail Alarm Indication  . . . . . . . 50
     6.25. IEEE 802.11 WTP Radio Information  . . . . . . . . . . . . 50
   7.  IEEE 802.11 Binding WTP Saved Variables  . . . . . . . . . . . 52
     7.1.  IEEE80211AntennaInfo . . . . . . . . . . . . . . . . . . . 52
     7.2.  IEEE80211DSControl . . . . . . . . . . . . . . . . . . . . 52
     7.3.  IEEE80211MACOperation  . . . . . . . . . . . . . . . . . . 52
     7.4.  IEEE80211OFDMControl . . . . . . . . . . . . . . . . . . . 52
     7.5.  IEEE80211Rateset . . . . . . . . . . . . . . . . . . . . . 52
     7.6.  IEEE80211TxPower . . . . . . . . . . . . . . . . . . . . . 52
     7.7.  IEEE80211QoS . . . . . . . . . . . . . . . . . . . . . . . 52
     7.8.  IEEE80211RadioConfig . . . . . . . . . . . . . . . . . . . 52
   8.  Technology Specific Message Element Values . . . . . . . . . . 53
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 54
     9.1.  IEEE 802.11 Security . . . . . . . . . . . . . . . . . . . 54
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 55
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 56
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 56
     11.2. Informational References . . . . . . . . . . . . . . . . . 57
   Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 58
   Intellectual Property and Copyright Statements . . . . . . . . . . 59








Calhoun, Editor, et al.  Expires April 16, 2007                 [Page 3]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


1.  Introduction

   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 (WLAN) 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.

1.1.  Goals

   The goals for this CAPWAP protocol binding are listed below:

   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 which are the 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, or station to AC
   communication is 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 [2].

1.3.  Contributing Authors

   TBD

1.4.  Acknowledgements

   TBD







Calhoun, Editor, et al.  Expires April 16, 2007                 [Page 4]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


1.5.  Terminology

   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.

   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).

   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, Editor, et al.  Expires April 16, 2007                 [Page 5]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


2.  IEEE 802.11 Binding

   This section describes use of the CAPWAP protocol with IEEE 802.11
   WLANs, including Local and Split MAC operation, Group Key Refresh,
   BSSID to WLAN Mapping, IEEE 802.11 MAC management frame Quality of
   Service tagging and Run State operation.

2.1.  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 [7], reside in the AC.

2.1.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.

        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.



Calhoun, Editor, et al.  Expires April 16, 2007                 [Page 6]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


   All remaining IEEE 802.11 MAC management frames are supported on the
   AC, including the Association Request frame which allows the AC to be
   involved in the access policy enforcement portion of the IEEE 802.11
   protocol.  The IEEE 802.1X and IEEE 802.11 key management function
   are also located on the AC.  This implies that the 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 this does not exclude 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.

             Client                       WTP                        AC

                      Beacon
             <-----------------------------
                   Probe Request
             ----------------------------( - )------------------------->
                   Probe Response
             <-----------------------------
                              802.11 AUTH/Association
             <--------------------------------------------------------->
         Station Configuration Request[Add Station (Clear Text, 802.1X)]
                                             <------------------------->
                    802.1X Authentication & 802.11 Key Exchange
             <--------------------------------------------------------->
            Station Configuration Request[Add Station (AES-CCMP, PTK=x)]
                                             <------------------------->
                               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 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 IEEE 802.11 Add WLAN (see Section 6.1)
      message element.





Calhoun, Editor, et al.  Expires April 16, 2007                 [Page 7]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


   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.

   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.4.8 in [1]).  In the
      above example, the WLAN is configured for IEEE 802.1X, and
      therefore the '802.1X only' policy bit is enabled.

   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 an Add Station message element, an IEEE 802.11 Station
      message element, an IEEE 802.11 Station Session Key message
      element and an IEEE 802.11 Information Element message element
      which includes the RSNIE to the WTP, delivering the security
      policy to enforce for the station (in this case AES-CCMP), and the
      encryption key to use.  If encryption/decryption is handled in the
      AC, the IEEE 802.11 Information message element with an RSNIE
      would not be included.

   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.

2.1.2.  Local MAC

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














Calhoun, Editor, et al.  Expires April 16, 2007                 [Page 8]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


        Function                               Location
            Distribution Service                      WTP
            Integration Service                       WTP
            Beacon Generation                         WTP
            Probe Response Generation                 WTP
            Power Mgmt/Packet Buffering               WTP
            Fragmentation/Defragmentation             WTP
            Assoc/Disassoc/Reassoc                    WTP

       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 3: Mapping of 802.11 Functions for Local AP Architecture

   Since the Distribution and Integration Services exist on the WTP,
   station generated frames are not forwarded to the AC, with the
   exception listed in the following paragraphs.

   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 and RSNA Key Management functions reside in the AC.
   Therefore, the WTP MUST forward all IEEE 802.1X/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, Editor, et al.  Expires April 16, 2007                 [Page 9]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


             Client                       WTP                        AC

                      Beacon
             <-----------------------------
                       Probe
             <---------------------------->
                    802.11 AUTH
             <-----------------------------
                                 802.11 Association
             <---------------------------( - )------------------------->
        Station Configuration Request[Add Station (Clear Text, 802.1X)]
                                             <------------------------->
                    802.1X Authentication & 802.11 Key Exchange
             <--------------------------------------------------------->
                               802.11 Action Frames
             <--------------------------------------------------------->
            Station Configuration Request[Add Station (AES-CCMP, PTK=x)]
                                             <------------------------->
                     802.11 DATA
             <----------------------------->

                     Figure 4: Local MAC Message Flow

   Figure 4 provides an illustration of the division of labor in a Local
   MAC architecture.  In this example, a WLAN has been created that is
   configured for IEEE 802.11, 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.

   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 10.1 in [1]).  In the
      above example, the WLAN is configured for IEEE 802.1X, and
      therefore the '802.1X only' policy bit is enabled.

   o  The WTP forwards all IEEE 802.1X and IEEE 802.11 key exchange
      messages to the AC for processing.





Calhoun, Editor, et al.  Expires April 16, 2007                [Page 10]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


   o  The AC transmits another Station Configuration Request message
      including an Add Station message element, an IEEE 802.11 Station
      message element, an IEEE 802.11 Station Session Key message
      element and 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), as well as the
      encryption key to use.  The Add Station message element MAY
      include a VLAN name, which when present is used by the WTP to
      identify the VLAN on which the user's data frames are to be
      bridged.

   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.2.  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 5 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 WPA or WPA2,
   both with key caching (where the IEEE 802.1x exchange would be
   bypassed) and without.

            Client              Old WTP              WTP              AC

                          Association Request/Response
             <--------------------------------------( - )-------------->
         Station Configuration Request[Add Station (Clear Text, 802.1X)]
                                                      <---------------->
             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 (AES-CCMP, PTK=x)]
                                                      <---------------->




Calhoun, Editor, et al.  Expires April 16, 2007                [Page 11]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


                     Figure 5: Client Roaming Example

2.3.  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 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 STA's in the
   BSS 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 STA's 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 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 STA's 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 6: Group Key Update Procedure






Calhoun, Editor, et al.  Expires April 16, 2007                [Page 12]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


2.4.  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.

   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.5.  Quality of Service for 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.

   802.1P:   The precedence value of 7 SHOULD be used for all IEEE
      802.11 MAC management frames, except for Probe Requests which
      SHOULD use 4.

   DSCP:   The DSCP tag value of 46 SHOULD be used for all IEEE 802.11
      MAC management frames, except for Probe Requests which SHOULD use
      34.

2.6.  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.







Calhoun, Editor, et al.  Expires April 16, 2007                [Page 13]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


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.3 in [1] for CAPWAP Control message definitions and the
   derivation of the Message Type value from the IANA Enterprise number.

   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      3398912
           IEEE 802.11 WLAN Configuration Response     3398913

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 admistrative 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 Request message (see Section 4.3 in [1]) has
   been received by the WTP.

   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 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



Calhoun, Editor, et al.  Expires April 16, 2007                [Page 14]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


   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

   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

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 MAY be included in the IEEE 802.11 WLAN
   Configuration Response message.

   o  IEEE 802.11 Assigned WTP BSSID, see Section 6.3

   The following message element MUST be included in the IEEE 802.11
   WLAN Configuration Response message.

   o  Result Code, see Section 4.4.31 in [1]




















Calhoun, Editor, et al.  Expires April 16, 2007                [Page 15]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


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:  The optional CAPWAP header
      field (see Section 4.1 in [1]) 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
      (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).

   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:   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
         contents of the field is set to 10 times the data rate in Mbps
         of the packet received by the WTP.  For instance, a packet
         received at 5.5Mbps would be set to 55, while 11Mbps would be
         set to 110.




Calhoun, Editor, et al.  Expires April 16, 2007                [Page 16]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


   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           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      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, bits 1 and 3 of this field would be enabled.
         This field is to be set to zero 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.


























Calhoun, Editor, et al.  Expires April 16, 2007                [Page 17]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


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.  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.

5.3.  Join Request 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.

5.4.  Configuration Status Message

   The following IEEE 802.11 specific message elements may be included
   in the CAPWAP Configuration Status Message.

   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





Calhoun, Editor, et al.  Expires April 16, 2007                [Page 18]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


   o  IEEE 802.11 Supported Rates, see Section 6.17

   o  IEEE 802.11 Tx Power, see Section 6.18

   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.5.  Configuration Status Response Message

   The following IEEE 802.11 specific message elements may be included
   in the CAPWAP Configuration Status Response Message.

   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.6.  Configuration Update Request Message

   The following IEEE 802.11 specific message elements may be included
   in the CAPWAP Configuration Update Request Message.

   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




Calhoun, Editor, et al.  Expires April 16, 2007                [Page 19]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


   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 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.7.  Station Configuration Request

   The following IEEE 802.11 specific message elements MAY included in
   the CAPWAP Station Configuration Request message.

   o  IEEE 802.11 Station, see Section 6.13

   o  IEEE 802.11 Station Session Key, see Section 6.15

   o  Station QoS Profile, see Section 6.14

5.8.  WTP Event Request

   The following IEEE 802.11 specific message elements may be included
   in the CAPWAP WTP Event Request message.

   o  IEEE 802.11 MIC Countermeasures, see Section 6.8

   o  IEEE 802.11 Statistics, see Section 6.16

   o  IEEE 802.11 WTP Radio Fail Alarm Indication, see Section 6.24
















Calhoun, Editor, et al.  Expires April 16, 2007                [Page 20]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


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



6.1.  IEEE 802.11 Add WLAN

   The IEEE 802.11 Add 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 IEEE 802.11 Information Element message elements,
   containing the following 802.11 IEs:

   Power Capability information element







Calhoun, Editor, et al.  Expires April 16, 2007                [Page 21]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


   WPA information element

   RSN information element

   EDCA Parameter Set information element

   QoS Capability information element

   WMM information element

   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.

   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    |          Capabilities         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   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:   >= 49

   Radio ID:   An 8-bit value representing the radio.

   WLAN ID:   An 8-bit value specifying the WLAN Identifier.

   Capability:   A 16-bit value containing the capabilities information
      field to be advertised by the WTP in the Probe Request and Beacon
      frames.







Calhoun, Editor, et al.  Expires April 16, 2007                [Page 22]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


   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 32 byte Session Key to use 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.4.8 in [1] and the IEEE 802.11 Station
      Session Key message element, see Section 6.15.

   Group TSC   A 48-bit value containing the Transmit Sequence Counter
      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 to enforce
      for station's traffic on this WLAN.

      The following values are supported:







Calhoun, Editor, et al.  Expires April 16, 2007                [Page 23]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


      0 -  Best Effort

      1 -  Video

      2 -  Voice

      3 -  Background

   Auth Type:   An 8-bit value specifying the supported authentication
      type.

      The following values are supported:

      0 -  Open System

      1 -  WEP Shared Key

      2 -  WPA/WPA2 802.1X

      3 -  WPA/WPA2 PSK

   MAC Mode:   This field specifies whether the WTP should support the
      WLAN in Local or Split MAC modes.  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.4.40 in [1]).  The
      following 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.4.38 in [1]).  IEEE 802.11 managment frames SHALL be tunneled
      using 802.11 Tunnel mode.  The following 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.2 in [1]).







Calhoun, Editor, et al.  Expires April 16, 2007                [Page 24]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


      2 - 802.11 Tunnel:   All user traffic is to be tunneled to the AC
         in 802.11 format.

   Supress SSID:   A boolean indicating whether the SSID is to be
      advertised by the WTP.  A value of zero supresses the SSID in the
      802.11 Beacon and Probe Response frames, while a value of one will
      cause the WTP to populate the field.

   SSID:   The SSID attribute is the service set identifier that will be
      advertised by the WTP for this WLAN.

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 [0..N]                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   1025 for IEEE 802.11 Antenna

   Length:   >= 5

   Radio ID:   An 8-bit value representing the radio to configure.

   Diversity:   An 8-bit value specifying whether the antenna is to
      provide receive diversity.  The value of this field is the same as
      the IEEE 802.11 dot11DiversitySelectionRx MIB element, see [3].
      The following values are supported:

      0 -  Disabled

      1 -  Enabled (may only be true if the antenna can be used as a
         receive antenna)

   Combiner:   An 8-bit value specifying the combiner selection.  The
      following values are supported:







Calhoun, Editor, et al.  Expires April 16, 2007                [Page 25]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


      1 -  Sectorized (Left)

      2 -  Sectorized (Right)

      3 -  Omni

      4 -  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 [3]).

   Antenna Selection:   One 8-bit antenna configuration value per
      antenna in the WTP.  The following 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:   6

   Radio ID:   An 8-bit value representing the radio.







Calhoun, Editor, et al.  Expires April 16, 2007                [Page 26]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


   WLAN ID:   An 8-bit value specifying the WLAN Identifier.

   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:   3

   Radio ID:   An 8-bit value representing the radio

   WLAN ID:   An 8-bit value specifying the WLAN Identifier

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, Editor, et al.  Expires April 16, 2007                [Page 27]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


   Radio ID:   An 8-bit value representing the radio to configure.

   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 DSSS PHY.  This value comes from the IEEE
      802.11 dot11CurrentChannel MIB element (see [3]).

   Current CCA:   The current CCA method in operation, whose value can
      be found in the IEEE 802.11 dot11CCAModeSupported MIB element (see
      [3]).  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 [3]).

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|   Flags   |Info Element...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   1029 for IEEE 802.11 Information Element

   Length:   >= 2






Calhoun, Editor, et al.  Expires April 16, 2007                [Page 28]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


   Radio ID:   An 8-bit value representing the radio.

   WLAN ID:   An 8-bit value specifying the WLAN Identifier.

   B:   When set, the WTP is to include the information element in
      beacons associated with the WLAN.

   P:   When set, the WTP is to include the information element in probe
      responses associated with the WLAN.

   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.

   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

   Radio ID:   An 8-bit value representing the radio to configure.

   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, Editor, et al.  Expires April 16, 2007                [Page 29]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


   RTS Threshold:   This attribute indicates the number of octets in an
      MPDU, below which an 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 [3]).

   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 [3]).

   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 [3]).

   Fragmentation Threshold:   This attribute specifies the current
      maximum size, in octets, of the MPDU that MAY be delivered to the
      PHY.  An MSDU MUST be broken into fragments if its size exceeds
      the value of this attribute after adding MAC headers and trailers.
      An MSDU or 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
      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
      [3]).

   Tx MSDU Lifetime:   This attribute speficies the elapsed time in TU,
      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



Calhoun, Editor, et al.  Expires April 16, 2007                [Page 30]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


      element, (see [3]).

   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 [3]).

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 [3].

      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, 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.

   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.







Calhoun, Editor, et al.  Expires April 16, 2007                [Page 31]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


         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.

   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 Channnel #:   This attribute indicates the value of the lowest
      channel number in the subband for the associated domain country
      string.  The value of this field comes from the IEEE 802.11
      dot11FirstChannelNumber MIB element (see [3]).

   Number of Channels:   This attribute indicates the value of the total
      number of channels allowed in the subband for the associated
      domain country string.  The value of this field comes from the
      IEEE 802.11 dot11NumberofChannels MIB element (see [3]).

   Max Tx Power Level:   This attribute indicates the maximum transmit
      power, in dBm, allowed in the subband for the associated domain
      country string.  The value of this field comes from the IEEE
      802.11 dot11MaximumTransmitPowerLevel MIB element (see [3]).

6.10.  IEEE 802.11 OFDM Control

   The IEEE 802.11 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                          |



Calhoun, Editor, et al.  Expires April 16, 2007                [Page 32]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   1033 for IEEE 802.11 OFDM Control

   Length:   8

   Radio ID:   An 8-bit value representing the radio to configure.

   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 [3]).

   Band Supported:   The capability of the OFDM PHY implementation to
      operate in the three U-NII bands.  The value of this field comes
      from the IEEE 802.11 dot11FrequencyBandsSupported MIB element (see
      [3]), coded as an integer value of a three bit field as follows:

      Bit 0 -  capable of operating in the lower (5.15-5.25 GHz) U-NII
         band

      Bit 1 -  capable of operating in the middle (5.25-5.35 GHz) U-NII
         band

      Bit 2 -  capable of operating in the upper (5.725-5.825 GHz) U-NII
         band

      For example, for an implementation capable of operating in the
      lower and mid 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 [3]).

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...



Calhoun, Editor, et al.  Expires April 16, 2007                [Page 33]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   1034 for IEEE 802.11 Rate Set

   Length:   >= 3

   Radio ID:   An 8-bit value representing the radio to configure.

   Rate Set:   The AC generates the Rate Set that the WTP is to include
      in it's 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 [3]).

6.12.  IEEE 802.11 RSNA Error Report From Station

   The IEEE 802.11 RSN Error Report From Station message element is sent
   by an AC to an 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 [3].

      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                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+







Calhoun, Editor, et al.  Expires April 16, 2007                [Page 34]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


   Type:   1035 for IEEE 802.11 RSNA Error Report From Station

   Length:   14

   Client MAC Address:   The Client MAC Address of the station.

   BSSID:   The BSSID on which the failures are being reported on.

   Radio ID:   The Radio Identifier, typically refers to some interface
      index on the WTP

   WLAN ID:   The WLAN ID on which the RSNA failures are being reported.

   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.

   TKIP ICV Errors:   A 32-bit value representing the number of TKIP ICV
      errors encountered when decrypting packets from the station.  The
      value of this field comes from the IEEE 802.11
      dot11RSNAStatsTKIPICVErrors MIB element (see [3]).

   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
      [3]).

   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 [3]).

   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 [3]).

   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 [3]).

   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 [3]).



Calhoun, Editor, et al.  Expires April 16, 2007                [Page 35]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


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.

      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:   >= 8

   Radio ID:   An 8-bit value representing the radio

   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






Calhoun, Editor, et al.  Expires April 16, 2007                [Page 36]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


   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 [3]).

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 either be dropped or tagged using the maximum value
   permitted by to the user.  The priority tag must be between zero (0)
   and seven (7).

        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          |     802.1P Precedence Tag     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   1037 for IEEE 802.11 Station QOS Profile

   Length:   8

   MAC Address:   The station's MAC Address

   802.1P Precedence Tag:   The maximum 802.1P precedence value that the
      WTP will allow in the 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 when the
   AC determines that encryption of a station must be performed in 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.

   The RSN information element MUST sent along with the IEEE 802.11
   Station Session Key in order to instruct the WTP on the usage of the
   Key field.  The AKM field of the RSM information element is used by
   the WTP to identify the authentication protocol.

   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 AKM (e.g., EAP).  Note that AKM-Only is MAY be set while an



Calhoun, Editor, et al.  Expires April 16, 2007                [Page 37]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


   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:

      A:   The one 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 one 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
         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.



Calhoun, Editor, et al.  Expires April 16, 2007                [Page 38]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


   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 key the WTP is to use when encrypting traffic to/from the
      station.  For dynamically created keys, this is commonly known as
      a Pairwise Transient Key (PTK).

6.16.  IEEE 802.11 Statistics

   The IEEE 802.11 Statistics message element is sent by the WTP to
   transmit its current statistics, and contains the following fields.





































Calhoun, Editor, et al.  Expires April 16, 2007                [Page 39]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


        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, Editor, et al.  Expires April 16, 2007                [Page 40]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


   Type:   1039 for IEEE 802.11 Statistics

   Length:   60

   Radio ID:   An 8-bit value representing the radio.

   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
      [3]).

   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 [3]).

   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 [3]).

   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 [3]).

   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 [3]).

   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 [3]).

   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 [3]).

   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 [3]).





Calhoun, Editor, et al.  Expires April 16, 2007                [Page 41]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


   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 [3]).

   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 [3]).

   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
      [3]).

   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 [3]).

   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 [3]).

   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 [3]).

   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 [3]).

   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 [3]).

   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 [3]).

   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 TXOP size being smaller than the timethat is required for
      one frame exchange sequence.  The value of this field comes from
      the IEEE 802.11 dot11QosCFPollsUnusableCount MIB element (see
      [3]).




Calhoun, Editor, et al.  Expires April 16, 2007                [Page 42]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


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.

   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
   the WTP MUST adhere to.

        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

   Length:   4

   Radio ID:   An 8-bit value representing the radio to configure.

   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, Editor, et al.  Expires April 16, 2007                [Page 43]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


   Current Tx Power:   This attribute contains the current transmit
      output power in mW, as described in the dot11CurrentTxPowerLevel
      MIB variable, see [3].

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 [3].

   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.

   Num Levels:   The number of power level attributes.  The value of
      this field comes from the IEEE 802.11
      dot11NumberSupportedPowerLevels MIB element (see [3]).

   Power Level:   Each power level fields contains a supported power
      level, in mW.  The value of this field comes from the
      corresponding IEEE 802.11 dot11TxPowerLevel[n] MIB element, see
      [3].

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.

      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          |   DSCP Tag    |  802.1P Tag   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





Calhoun, Editor, et al.  Expires April 16, 2007                [Page 44]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


   Type:   1043 for IEEE 802.11 Update Station QoS

   Length:   8

   Radio ID:   The Radio Identifier, typically refers to some interface
      index on the WTP

   MAC Address:   The station's MAC Address.

   DSCP Tag:   The DSCP label to use if packets are to be DSCP tagged.

   802.1P Tag:   The 802.1P precedence value to use if packets are to be
      IEEE 802.1P tagged.

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 Capability information element

   WPA information element

   RSN information element

   EDCA Parameter Set information element

   QoS Capability information element

   WMM information element

   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...                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+







Calhoun, Editor, et al.  Expires April 16, 2007                [Page 45]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


   Type:   1044 for IEEE 802.11 Update WLAN

   Length:   43

   Radio ID:   An 8-bit value representing the radio.

   WLAN ID:   An 8-bit value specifying the WLAN Identifier.

   Capability:   A 16-bit value containing the capabilities information
      field to be advertised by the WTP within the Probe and Beacon
      messages.

   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 32 byte Session Key to use 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 hereonly 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 [1].




Calhoun, Editor, et al.  Expires April 16, 2007                [Page 46]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


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.

      0                   1
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Radio ID    |  Tag Packets  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   1045 for IEEE 802.11 WTP Quality of Service

   Length:   >= 2

   Radio ID:   The Radio Identifier, typically refers to some interface
      index on the WTP

   Tag Packets:   An value indicating whether CAPWAP packets should be
      tagged with for QoS purposes.  The following values are currently
      supported:

      0 -  Untagged

      1 -  802.1P

      2 -  DSCP

      Immediately following the above header is the following data
      structure.  This data structure will be repeated five times; once
      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      |   Dot1P Tag   |   DSCP Tag    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Queue Depth:   The number of packets that can be on the specific QoS
      transmit queue at any given time.






Calhoun, Editor, et al.  Expires April 16, 2007                [Page 47]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


   CWMin:   The Contention Window minimum value for the QoS transmit
      queue.  The value of this field comes from the IEEE 802.11
      dot11EDCATableCWMin MIB element (see [3]).

   CWMax:   The Contention Window maximum value for the QoS transmit
      queue.  The value of this field comes from the IEEE 802.11
      dot11EDCATableCWMax MIB element (see [3]).

   AIFS:   The Arbitration Inter Frame Spacing to use for the QoS
      transmit queue.  The value of this field comes from the IEEE
      802.11 dot11EDCATableAIFSN MIB element (see [3]).

   Dot1P Tag:   The 802.1P precedence value to use if packets are to be
      802.1P tagged.

   DSCP Tag:   The DSCP label to use if packets are to be DSCP tagged.

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 Code                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



   Type:   1046 for IEEE 802.11 WTP WLAN Radio Configuration

   Length:   16

   Radio ID:   An 8-bit value representing the radio to configure.

   Short Preamble:   An 8-bit value indicating whether short preamble is
      supported.  The following values are currently supported:





Calhoun, Editor, et al.  Expires April 16, 2007                [Page 48]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


      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 TIM element whose 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 [3]).

   Beacon Period:   This attribute specifies the number of 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 [3]).

   Country Code:   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 [3]).  Special
      attention is required with use of this field, as implementations
      which take action based on this field could violate regulatory
      requirements.  Some regulatory bodies do permit configuration of
      the country code under certain restrictions, such as the FCC, when
      WTPs are certified as Software Defined Radios.

      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 code as
      described in document ISO/IEC 3166- 1, and the third octet MUST
      have the value 1, 2 or 3 as defined below.  When the value of the
      third octet is 255, the country code field is not used, and MUST
      be ignored.

      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





Calhoun, Editor, et al.  Expires April 16, 2007                [Page 49]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


      3  an ASCII 'I' character, if the regulations under which the
         station is operating are for an indoor environment only

      255  Country Code field is not used; ignore the field.

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, typically refers to some interface
      index on the WTP

   Type:   The type of radio failure detected.  The following values are
      supported:

      1 -  Receiver

      2 -  Transmitter

   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.




Calhoun, Editor, et al.  Expires April 16, 2007                [Page 50]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


   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, which typically refers to an
      interface index on the WTP

   Radio Type:   The type of radio present.  Note this bitfield can be
      used to specify support for more than a single type of PHY/MAC.
      The following values are supported:

      1 - 802.11b:   An IEEE 802.11b radio.

      2 - 802.11a:   An IEEE 802.11a radio.

      4 - 802.11g:   An IEEE 802.11g radio.

      8 - 802.11n:   An IEEE 802.11n radio.

      0xOF - 802.11b, 802.11a, 802.11g and 802.11n:   The 4 radio types
         indicated are supported in the WTP.




















Calhoun, Editor, et al.  Expires April 16, 2007                [Page 51]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


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 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.

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.









Calhoun, Editor, et al.  Expires April 16, 2007                [Page 52]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


8.  Technology Specific Message Element Values

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

   IEEE 802.11 uses the following values:

   4 - Encrypt AES-CCMP 128:   WTP supports AES-CCMP, as defined in [4].

   5 - Encrypt TKIP-MIC:   WTP supports TKIP and Michael, as defined in
      [11].







































Calhoun, Editor, et al.  Expires April 16, 2007                [Page 53]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


9.  Security Considerations

   This section describes security considerations for using IEEE 802.11
   with the CAPWAP protocol.

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
   many well-documented attacks.  Implementors SHOULD discourage the use
   of WEP and encourage 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.  Implementors SHOULD use EAP methods meeting the requirements
   specified [6].


































Calhoun, Editor, et al.  Expires April 16, 2007                [Page 54]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


10.  IANA Considerations

   There are no IANA Considerations.
















































Calhoun, Editor, et al.  Expires April 16, 2007                [Page 55]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


11.  References

11.1.  Normative References

   [1]   "draft-ietf-capwap-protocol-specification-03".

   [2]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [3]   "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, 1999,
         <http://standards.ieee.org/getieee802/download/
         802.11-1999.pdf>.

   [4]   "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 Amendment
         6: Medium Access Control (MAC) Security Enhancements",
         IEEE Standard 802.11i, July 2004, <http://standards.ieee.org/
         getieee802/download/802.11i-2004.pdf>.

   [5]   Aboba, B. and J. Wood, "Authentication, Authorization and
         Accounting (AAA) Transport Profile", RFC 3539, June 2003.

   [6]   Stanley, D., Walker, J., and B. Aboba, "Extensible
         Authentication Protocol (EAP) Method Requirements for Wireless
         LANs", RFC 4017, March 2005.

   [7]   Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy for
         Control and Provisioning of Wireless Access Points (CAPWAP)",
         RFC 4118, June 2005.

   [8]   Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
         Protocol Version 1.1", RFC 4346, April 2006.

   [9]   Manner, J. and M. Kojo, "Mobility Related Terminology",
         RFC 3753, June 2004.

   [10]  Rescorla et al, E., "Datagram Transport Layer Security",
         June 2004.







Calhoun, Editor, et al.  Expires April 16, 2007                [Page 56]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


11.2.  Informational References

   [11]  "WiFi Protected Access (WPA) rev 1.6", April 2003.
















































Calhoun, Editor, et al.  Expires April 16, 2007                [Page 57]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


Editors' Addresses

   Pat R. Calhoun
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA  95134

   Phone: +1 408-853-5269
   Email: pcalhoun@cisco.com


   Michael P. Montemurro
   Research In Motion
   5090 Commerce Blvd
   Mississauga, ON  L4W 5M4
   Canada

   Phone: +1 905-629-4746 x4999
   Email: mmontemurro@rim.com


   Dorothy Stanley
   Aruba Networks
   1322 Crossman Ave
   Sunnyvale, CA  94089

   Phone: +1 630-363-1389
   Email: dstanley@arubanetworks.com























Calhoun, Editor, et al.  Expires April 16, 2007                [Page 58]


Internet-Draft   CAPWAP Protocol Binding for IEEE 802.11    October 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Calhoun, Editor, et al.  Expires April 16, 2007                [Page 59]