tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 5416

 
 
 

Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding for IEEE 802.11

Part 3 of 3, p. 50 to 76
Prev RFC Part

 


prevText      Top      Up      ToC       Page 50 
6.16.  IEEE 802.11 Statistics

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

Top      Up      ToC       Page 51 
   greatly across each field.  Applications or human operators using
   these counters need to be aware of the minimal possible times between
   rollover events in order to make sure that no consecutive rollover
   events are missed.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Radio ID   |                   Reserved                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Tx Fragment Count                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Multicast Tx Count                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Failed Count                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Retry Count                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Multiple Retry Count                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Frame Duplicate Count                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       RTS Success Count                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       RTS Failure Count                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       ACK Failure Count                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Rx Fragment Count                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Multicast RX Count                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        FCS Error  Count                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Tx Frame Count                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Decryption Errors                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Discarded QoS Fragment Count                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Associated Station Count                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  QoS CF Polls Received Count                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   QoS CF Polls Unused Count                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  QoS CF Polls Unusable Count                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 52 
   Type:   1039 for IEEE 802.11 Statistics

   Length:   80

   Radio ID:   An 8-bit value representing the radio, whose value is
      between one (1) and 31.

   Reserved:   All implementations complying with this protocol MUST set
      to zero any bits that are reserved in the version of the protocol
      supported by that implementation.  Receivers MUST ignore all bits
      not defined for the version of the protocol they support.

   Tx Fragment Count:   A 32-bit value representing the number of
      fragmented frames transmitted.  The value of this field comes from
      the IEEE 802.11 dot11TransmittedFragmentCount MIB element (see
      [IEEE.802-11.2007]).

   Multicast Tx Count:   A 32-bit value representing the number of
      multicast frames transmitted.  The value of this field comes from
      the IEEE 802.11 dot11MulticastTransmittedFrameCount MIB element
      (see [IEEE.802-11.2007]).

   Failed Count:   A 32-bit value representing the transmit excessive
      retries.  The value of this field comes from the IEEE 802.11
      dot11FailedCount MIB element (see [IEEE.802-11.2007]).

   Retry Count:   A 32-bit value representing the number of transmit
      retries.  The value of this field comes from the IEEE 802.11
      dot11RetryCount MIB element (see [IEEE.802-11.2007]).

   Multiple Retry Count:   A 32-bit value representing the number of
      transmits that required more than one retry.  The value of this
      field comes from the IEEE 802.11 dot11MultipleRetryCount MIB
      element (see [IEEE.802-11.2007]).

   Frame Duplicate Count:   A 32-bit value representing the duplicate
      frames received.  The value of this field comes from the IEEE
      802.11 dot11FrameDuplicateCount MIB element (see
      [IEEE.802-11.2007]).

   RTS Success Count:   A 32-bit value representing the number of
      successfully transmitted Ready To Send (RTS).  The value of this
      field comes from the IEEE 802.11 dot11RTSSuccessCount MIB element
      (see [IEEE.802-11.2007]).

Top      Up      ToC       Page 53 
   RTS Failure Count:   A 32-bit value representing the failed
      transmitted RTS.  The value of this field comes from the IEEE
      802.11 dot11RTSFailureCount MIB element (see [IEEE.802-11.2007]).

   ACK Failure Count:   A 32-bit value representing the number of failed
      acknowledgements.  The value of this field comes from the IEEE
      802.11 dot11ACKFailureCount MIB element (see [IEEE.802-11.2007]).

   Rx Fragment Count:   A 32-bit value representing the number of
      fragmented frames received.  The value of this field comes from
      the IEEE 802.11 dot11ReceivedFragmentCount MIB element (see
      [IEEE.802-11.2007]).

   Multicast RX Count:   A 32-bit value representing the number of
      multicast frames received.  The value of this field comes from the
      IEEE 802.11 dot11MulticastReceivedFrameCount MIB element (see
      [IEEE.802-11.2007]).

   FCS Error Count:   A 32-bit value representing the number of FCS
      failures.  The value of this field comes from the IEEE 802.11
      dot11FCSErrorCount MIB element (see [IEEE.802-11.2007]).

   Decryption Errors:   A 32-bit value representing the number of
      Decryption errors that occurred on the WTP.  Note that this field
      is only valid in cases where the WTP provides encryption/
      decryption services.  The value of this field comes from the IEEE
      802.11 dot11WEPUndecryptableCount MIB element (see
      [IEEE.802-11.2007]).

   Discarded QoS Fragment Count:   A 32-bit value representing the
      number of discarded QoS fragments received.  The value of this
      field comes from the IEEE 802.11 dot11QoSDiscardedFragmentCount
      MIB element (see [IEEE.802-11.2007]).

   Associated Station Count:   A 32-bit value representing the number of
      number of associated stations.  The value of this field comes from
      the IEEE 802.11 dot11AssociatedStationCount MIB element (see
      [IEEE.802-11.2007]).

   QoS CF Polls Received Count:   A 32-bit value representing the number
      of (+)CF-Polls received.  The value of this field comes from the
      IEEE 802.11 dot11QosCFPollsReceivedCount MIB element (see
      [IEEE.802-11.2007]).

   QoS CF Polls Unused Count:   A 32-bit value representing the number
      of (+)CF-Polls that have been received, but not used.  The value
      of this field comes from the IEEE 802.11
      dot11QosCFPollsUnusedCount MIB element (see [IEEE.802-11.2007]).

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

6.17.  IEEE 802.11 Supported Rates

   The IEEE 802.11 Supported Rates message element is sent by the WTP to
   indicate the rates that it supports, and contains the following
   fields.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Radio ID   |               Supported Rates...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   1040 for IEEE 802.11 Supported Rates

   Length:   >= 3

   Radio ID:   An 8-bit value representing the radio, whose value is
      between one (1) and 31.

   Supported Rates:   The WTP includes the Supported Rates that its
      hardware supports.  The format is identical to the Rate Set
      message element and is between 2 and 8 bytes in length.

6.18.  IEEE 802.11 Tx Power

   The IEEE 802.11 Tx Power message element value is bi-directional.
   When sent by the WTP, it contains the current power level of the
   radio in question.  When sent by the AC, it contains the power level
   to which the WTP MUST adhere.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Radio ID   |    Reserved   |        Current Tx Power       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   1041 for IEEE 802.11 Tx Power

Top      Up      ToC       Page 55 
   Length:   4

   Radio ID:   An 8-bit value representing the radio to configure, whose
      value is between one (1) and 31.

   Reserved:   All implementations complying with this protocol MUST set
      to zero any bits that are reserved in the version of the protocol
      supported by that implementation.  Receivers MUST ignore all bits
      not defined for the version of the protocol they support.

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

6.19.  IEEE 802.11 Tx Power Level

   The IEEE 802.11 Tx Power Level message element is sent by the WTP and
   contains the different power levels supported.  The values found in
   this message element are found in the IEEE 802.11
   Dot11PhyTxPowerEntry MIB table, see [IEEE.802-11.2007].

   The value field contains the following:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Radio ID   |   Num Levels  |        Power Level [n]        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   1042 for IEEE 802.11 Tx Power Level

   Length:   >= 4

   Radio ID:   An 8-bit value representing the radio to configure, whose
      value is between one (1) and 31.

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

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

Top      Up      ToC       Page 56 
6.20.  IEEE 802.11 Update Station QoS

   The IEEE 802.11 Update Station QoS message element is used to change
   the Quality of Service policy on the WTP for a given station.  The
   QoS tags included in this message element are to be applied to
   packets received at the WTP from the station indicated through the
   MAC Address field.  This message element overrides the default values
   provided through the IEEE 802.11 WTP Quality of Service message
   element (see Section 6.22).  Any tagging performed by the WTP MUST be
   directly applied to the packets received from the station, as well as
   the CAPWAP tunnel, if the packets are tunneled to the AC.  See
   Section 2.6 for more information.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Radio ID    |                  MAC Address                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          MAC Address          |       QoS Sub-Element...      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   1043 for IEEE 802.11 Update Station QoS

   Length:   8

   Radio ID:   The Radio Identifier, whose value is between one (1) and
      31, typically refers to some interface index on the WTP.

   MAC Address:   The station's MAC Address.

   QoS Sub-Element:   The IEEE 802.11 WTP Quality of Service message
      element contains four QoS sub-elements, one for every QoS profile.
      The order of the QoS profiles are Voice, Video, Best Effort, and
      Background.

      0                   1
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Reserved|8021p|RSV| DSCP Tag  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      Reserved:   All implementations complying with this protocol MUST
         set to zero any bits that are reserved in the version of the
         protocol supported by that implementation.  Receivers MUST
         ignore all bits not defined for the version of the protocol
         they support.

Top      Up      ToC       Page 57 
      8021p:   The 3-bit 802.1p priority value to use if packets are to
         be IEEE 802.1p tagged.  This field is used only if the 'P' bit
         in the WTP Quality of Service message element was set;
         otherwise, its contents MUST be ignored.

      RSV:   All implementations complying with this protocol MUST set
         to zero any bits that are reserved in the version of the
         protocol supported by that implementation.  Receivers MUST
         ignore all bits not defined for the version of the protocol
         they support.

      DSCP Tag:   The 6-bit DSCP label to use if packets are eligible to
         be DSCP tagged, specifically an IPv4 or IPv6 packet (see
         [RFC2474]).  This field is used only if the 'D' bit in the WTP
         Quality of Service message element was set; otherwise, its
         contents MUST be ignored.

6.21.  IEEE 802.11 Update WLAN

   The IEEE 802.11 Update WLAN message element is used by the AC to
   define a wireless LAN on the WTP.  The inclusion of this message
   element MUST also include the IEEE 802.11 Information Element message
   element, containing the following 802.11 IEs:

   Power Constraint information element

   WPA information element  [WPA]

   RSN information element

   Enhanced Distributed Channel Access (EDCA) Parameter Set information
      element

   QoS Capability information element

   WMM information element  [WMM]

   These IEEE 802.11 Information Elements are stored by the WTP and
   included in any Probe Responses and Beacons generated, as specified
   in the IEEE 802.11 standard [IEEE.802-11.2007].

   If cryptographic services are provided at the WTP, the WTP MUST
   observe the algorithm dictated in the Group Cipher Suite field of the
   RSN Information Element sent by the AC.  The RSN Information Element
   is used to communicate any supported algorithm, including WEP, TKIP,
   and AES-CCMP.  In the case of static WEP keys, the RSN Information
   Element is still used to indicate the cryptographic algorithm even
   though no key exchange occurred.

Top      Up      ToC       Page 58 
   The message element uses the following format:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Radio ID   |     WLAN ID   |           Capability          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Key Index   |   Key Status  |           Key Length          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                             Key...                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   1044 for IEEE 802.11 Update WLAN

   Length:   >= 8

   Radio ID:   An 8-bit value representing the radio, whose value is
      between one (1) and 31.

   WLAN ID:   An 8-bit value specifying the WLAN Identifier.  The value
      MUST be between one (1) and 16.

   Capability:   A 16-bit value containing the Capability information
      field to be advertised by the WTP in the Probe Request and Beacon
      frames.  Each bit of the Capability field represents a different
      WTP capability, which are described in detail in
      [IEEE.802-11.2007].  The format of the field is:

        0                   1
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |E|I|C|F|P|S|B|A|M|Q|T|D|V|O|K|L|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      E (ESS):   The AC MUST set the Extended Service Set (ESS) subfield
        to 1.

      I (IBSS):   The AC MUST set the Independent Basic Service Set
        (IBSS) subfield to 0.

      C (CF-Pollable):   The AC sets the Contention Free Pollable (CF-
        Pollable) subfield based on the table found in
        [IEEE.802-11.2007].

      F (CF-Poll Request):   The AC sets the CF-Poll Request subfield
        based on the table found in [IEEE.802-11.2007].

Top      Up      ToC       Page 59 
      P (Privacy):   The AC sets the Privacy subfield based on the
        confidentiality requirements of the WLAN, as defined in
        [IEEE.802-11.2007].

      S (Short Preamble):   The AC sets the Short Preamble subfield
        based on whether the use of short preambles are permitted on the
        WLAN, as defined in [IEEE.802-11.2007].

      B (PBCC):   The AC sets the Packet Binary Convolutional Code
        (PBCC) modulation option subfield based on whether the use of
        PBCC is permitted on the WLAN, as defined in [IEEE.802-11.2007].

      A (Channel Agility):   The AC sets the Channel Agility subfield
        based on whether the WTP is capable of supporting the High Rate
        Direct Sequence Spread Spectrum (HR/DSSS), as defined in
        [IEEE.802-11.2007].

      M (Spectrum Management):   The AC sets the Spectrum Management
        subfield according to the value of the
        dot11SpectrumManagementRequired MIB variable, as defined in
        [IEEE.802-11.2007].

      Q (QoS):   The AC sets the Quality of Service (QoS) subfield based
        on the table found in [IEEE.802-11.2007].

      T (Short Slot Time):   The AC sets the Short Slot Time subfield
        according to the value of the WTP's currently used slot time
        value, as defined in [IEEE.802-11.2007].

      D (APSD):   The AC sets the APSD subfield according to the value
        of the dot11APSDOptionImplemented Management Information Base
        (MIB) variable, as defined in [IEEE.802-11.2007].

      V (Reserved):   The AC sets the Reserved subfield to zero, as
        defined in [IEEE.802-11.2007].

      O (DSSS-OFDM):   The AC sets the DSSS-OFDM subfield to indicate
        the use of Direct Sequence Spread Spectrum with Orthogonal
        Frequency Division Multiplexing (DSSS-OFDM), as defined in
        [IEEE.802-11.2007].

      K (Delayed Block ACK):   The AC sets the Delayed Block ACK
        subfield according to the value of the
        dot11DelayedBlockAckOptionImplemented MIB variable, as defined
        in [IEEE.802-11.2007].

Top      Up      ToC       Page 60 
      L (Immediate Block ACK):   The AC sets the Delayed Block ACK
        subfield according to the value of the
        dot11ImmediateBlockAckOptionImplemented MIB variable, as defined
        in [IEEE.802-11.2007].

   Key-Index:   The Key-Index associated with the key.

   Key Status:   A 1-byte value that specifies the state and usage of
      the key that has been included.  The following values describe the
      key usage and its status:

      0 -  A value of zero, with the inclusion of the RSN Information
           Element means that the WLAN uses per-station encryption keys,
           and therefore the key in the 'Key' field is only used for
           multicast traffic.

      1 -  When set to one, the WLAN employs a shared WEP key, also
           known as a static WEP key, and uses the encryption key for
           both unicast and multicast traffic for all stations.

      2 -  The value of 2 indicates that the AC will begin rekeying the
           GTK with the STA's in the BSS.  It is only valid when IEEE
           802.11 is enabled as the security policy for the BSS.

      3 -  The value of 3 indicates that the AC has completed rekeying
           the GTK and broadcast packets no longer need to be duplicated
           and transmitted with both GTK's.

   Key Length:   A 16-bit value representing the length of the Key
      field.

   Key:   A Session Key, whose length is known via the Key Length field,
      used to provide data privacy.  For static WEP keys, which is true
      when the 'Key Status' bit is set to one, this key is used for both
      unicast and multicast traffic.  For encryption schemes that employ
      a separate encryption key for unicast and multicast traffic, the
      key included here only applies to multicast data, and the cipher
      suite is specified in an accompanied RSN Information Element.  In
      these scenarios, the key, and cipher information, is communicated
      via the Add Station message element, see Section 4.6.8 in
      [RFC5415].  When used with WEP, the Key field includes the
      broadcast key.  When used with CCMP, the Key field includes the
      128-bit Group Temporal Key.  When used with TKIP, the Key field
      includes the 256-bit Group Temporal Key (which consists of a 128-
      bit key used as input for TKIP key mixing, and two 64-bit keys
      used for Michael).

Top      Up      ToC       Page 61 
6.22.  IEEE 802.11 WTP Quality of Service

   The IEEE 802.11 WTP Quality of Service message element value is sent
   by the AC to the WTP to communicate Quality of Service configuration
   information.  The QoS tags included in this message element are the
   default QoS values to be applied to packets received by the WTP from
   stations on a particular radio.  Any tagging performed by the WTP
   MUST be directly applied to the packets received from the station, as
   well as the CAPWAP tunnel, if the packets are tunneled to the AC.
   See Section 2.6 for more information.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Radio ID    |Tagging Policy |       QoS Sub-Element ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   1045 for IEEE 802.11 WTP Quality of Service

   Length:   34

   Radio ID:   The Radio Identifier, whose value is between one (1) and
      31, typically refers to some interface index on the WTP.

   Tagging Policy:   A bit field indicating how the WTP is to mark
      packets for QoS purposes.  The required WTP behavior is defined in
      Section 2.6.1.  The field has the following format:

         0 1 2 3 4 5 6 7
        +-+-+-+-+-+-+-+-+
        |Rsvd |P|Q|D|O|I|
        +-+-+-+-+-+-+-+-+

      Rsvd:  A set of reserved bits for future use.  All implementations
         complying with this protocol MUST set to zero any bits that are
         reserved in the version of the protocol supported by that
         implementation.  Receivers MUST ignore all bits not defined for
         the version of the protocol they support.

      P:   When set, the WTP is to employ the 802.1p QoS mechanism (see
           Section 2.6.1.1), and the WTP is to use the 'Q' bit.

      Q:   When the 'P' bit is set, the 'Q' bit is used by the AC to
           communicate to the WTP how 802.1p QoS is to be enforced.
           Details on the behavior of the 'Q' bit are specified in
           Section 2.6.1.1.

Top      Up      ToC       Page 62 
      D:   When set, the WTP is to employ the DSCP QoS mechanism (see
           Section 2.6.1.2), and the WTP is to use the 'O' and 'I' bits.

      O:   When the 'D' bit is set, the 'O' bit is used by the AC to
           communicate to the WTP how DSCP QoS is to be enforced on the
           outer (tunneled) header.  Details on the behavior of the 'O'
           bit are specified in Section 2.6.1.2.

      I:   When the 'D' bit is set, the 'I' bit is used by the AC to
           communicate to the WTP how DSCP QoS is to be enforced on the
           station's packet (inner) header.  Details on the behavior of
           the 'I' bit are specified in Section 2.6.1.2.

   QoS Sub-Element:   The IEEE 802.11 WTP Quality of Service message
      element contains four QoS sub-elements, one for every QoS profile.
      The order of the QoS profiles are Voice, Video, Best Effort, and
      Background.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Queue Depth  |             CWMin             |     CWMax     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     CWMax     |     AIFS      | Reserved|8021p|RSV| DSCP Tag  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

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

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

Top      Up      ToC       Page 63 
      Reserved:   All implementations complying with this protocol MUST
         set to zero any bits that are reserved in the version of the
         protocol supported by that implementation.  Receivers MUST
         ignore all bits not defined for the version of the protocol
         they support.

      8021p:   The 3-bit 802.1p priority value to use if packets are to
         be IEEE 802.1p tagged.  This field is used only if the 'P' bit
         is set; otherwise, its contents MUST be ignored.

      RSV:   All implementations complying with this protocol MUST set
         to zero any bits that are reserved in the version of the
         protocol supported by that implementation.  Receivers MUST
         ignore all bits not defined for the version of the protocol
         they support.

      DSCP Tag:   The 6-bit DSCP label to use if packets are eligible to
         be DSCP tagged, specifically an IPv4 or IPv6 packet (see
         [RFC2474]).  This field is used only if the 'D' bit is set;
         otherwise, its contents MUST be ignored.

6.23.  IEEE 802.11 WTP Radio Configuration

   The IEEE 802.11 WTP WLAN Radio Configuration message element is used
   by the AC to configure a Radio on the WTP, and by the WTP to deliver
   its radio configuration to the AC.  The message element value
   contains the following fields:

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Radio ID   |Short Preamble| Num of BSSIDs |  DTIM Period  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            BSSID                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          BSSID                |      Beacon Period            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Country String                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   1046 for IEEE 802.11 WTP WLAN Radio Configuration

   Length:   16

   Radio ID:   An 8-bit value representing the radio to configure, whose
      value is between one (1) and 31.

Top      Up      ToC       Page 64 
   Short Preamble:   An 8-bit value indicating whether short preamble is
      supported.  The following enumerated values are currently
      supported:

      0 -  Short preamble not supported.

      1 -  Short preamble is supported.

   BSSID:   The WLAN Radio's base MAC Address.

   Number of BSSIDs:   This attribute contains the maximum number of
      BSSIDs supported by the WTP.  This value restricts the number of
      logical networks supported by the WTP, and is between 1 and 16.

   DTIM Period:   This attribute specifies the number of Beacon
      intervals that elapse between transmission of Beacons frames
      containing a Traffic Indication Map (TIM) element whose Delivery
      Traffic Indication Message (DTIM) Count field is 0.  This value is
      transmitted in the DTIM Period field of Beacon frames.  The value
      of this field comes from the IEEE 802.11 dot11DTIMPeriod MIB
      element (see [IEEE.802-11.2007]).

   Beacon Period:   This attribute specifies the number of Time Unit
      (TU) that a station uses for scheduling Beacon transmissions.
      This value is transmitted in Beacon and Probe Response frames.
      The value of this field comes from the IEEE 802.11
      dot11BeaconPeriod MIB element (see [IEEE.802-11.2007]).

   Country String:   This attribute identifies the country in which the
      station is operating.  The value of this field comes from the IEEE
      802.11 dot11CountryString MIB element (see [IEEE.802-11.2007]).
      Some regulatory domains do not allow WTPs to have user
      configurable country string, and require that it be a fixed value
      during the manufacturing process.  Therefore, WTP vendors that
      wish to allow for the configuration of this field will need to
      validate this behavior during its radio certification process.
      Other WTP vendors may simply wish to treat this WTP configuration
      parameter as read-only.  The country strings can be found in
      [ISO.3166-1].

      The WTP and AC MAY ignore the value of this field, depending upon
      regulatory requirements, for example to avoid classification as a
      Software-Defined Radio.  When this field is used, the first two
      octets of this string is the two-character country string as
      described in [ISO.3166-1], and the third octet MUST either be a
      space, 'O', 'I', or X' as defined below.  When the value of the

Top      Up      ToC       Page 65 
      third octet is 255 (HEX 0xff), the country string field is not
      used, and MUST be ignored.  The following are the possible values
      for the third octet:

      1.   an ASCII space character, if the regulations under which the
           station is operating encompass all environments in the
           country,

      2.   an ASCII 'O' character, if the regulations under which the
           station is operating are for an outdoor environment only, or

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

      4.   an ASCII 'X' character, if the station is operating under a
           non-country entity.  The first two octets of the non-country
           entity shall be two ASCII 'XX' characters,

      5.   a HEX 0xff character means that the country string field is
           not used and MUST be ignored.

      Note that the last byte of the Country String MUST be set to NULL.

6.24.  IEEE 802.11 WTP Radio Fail Alarm Indication

   The IEEE 802.11 WTP Radio Fail Alarm Indication message element is
   sent by the WTP to the AC when it detects a radio failure.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Radio ID    |     Type      |    Status     |      Pad      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   1047 for IEEE 802.11 WTP Radio Fail Alarm Indication

   Length:   4

   Radio ID:   The Radio Identifier, whose value is between one (1) and
      31, typically refers to some interface index on the WTP.

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

      1 -  Receiver

      2 -  Transmitter

Top      Up      ToC       Page 66 
   Status:   An 8-bit boolean indicating whether the radio failure is
      being reported or cleared.  A value of zero is used to clear the
      event, while a value of one is used to report the event.

   Pad:   All implementations complying with version zero of this
      protocol MUST set these bits to zero.  Receivers MUST ignore all
      bits not defined for the version of the protocol they support.

6.25.  IEEE 802.11 WTP Radio Information

   The IEEE 802.11 WTP Radio Information message element is used to
   communicate the radio information for each IEEE 802.11 radio in the
   WTP.  The Discovery Request message, Primary Discovery Request
   message, and Join Request message MUST include one such message
   element per radio in the WTP.  The Radio-Type field is used by the AC
   in order to determine which IEEE 802.11 technology specific binding
   is to be used with the WTP.

   The message element contains two fields, as shown below.

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

   Type:   1048 for IEEE 802.11 WTP Radio Information

   Length:   5

   Radio ID:   The Radio Identifier, whose value is between one (1) and
      31, which typically refers to an interface index on the WTP.

   Radio Type:   The type of radio present.  Note this is a bit field
      that is used to specify support for more than a single type of
      PHY/MAC.  The field has the following format:

         0 1 2 3 4 5 6 7
        +-+-+-+-+-+-+-+-+
        |Reservd|N|G|A|B|
        +-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 67 
      Reservd:  A set of reserved bits for future use.  All
         implementations complying with this protocol MUST set to zero
         any bits that are reserved in the version of the protocol
         supported by that implementation.  Receivers MUST ignore all
         bits not defined for the version of the protocol they support.

      N:   An IEEE 802.11n radio.

      G:   An IEEE 802.11g radio.

      A:   An IEEE 802.11a radio.

      B:   An IEEE 802.11b radio.

7.  IEEE 802.11 Binding WTP Saved Variables

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

7.1.  IEEE80211AntennaInfo

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

7.2.  IEEE80211DSControl

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

7.3.  IEEE80211MACOperation

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

7.4.  IEEE80211OFDMControl

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

7.5.  IEEE80211Rateset

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

7.6.  IEEE80211TxPower

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

Top      Up      ToC       Page 68 
7.7.  IEEE80211QoS

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

7.8.  IEEE80211RadioConfig

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

8.  Technology Specific Message Element Values

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

8.1.  WTP Descriptor Message Element, Encryption Capabilities Field

   This specification defines two new bits for the WTP Descriptor's
   Encryption Capabilities field, as defined in [RFC5415].  Note that
   only the bits defined in this specification are described below.  WEP
   is not explicitly advertised as a WTP capability since all WTPs are
   expected to support the encryption cipher.  The format of the
   Encryption Capabilities field is:

                             1
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                       |A|T|   |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   A:   WTP supports AES-CCMP, as defined in [IEEE.802-11.2007].

   T:   WTP supports TKIP and Michael, as defined in [IEEE.802-11.2007]
        and [WPA], respectively.

9.  Security Considerations

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

9.1.  IEEE 802.11 Security

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

Top      Up      ToC       Page 69 
   many well-documented attacks.  Implementers SHOULD discourage the use
   of WEP and encourage the use of technically-sound cryptographic
   solutions such as those in an IEEE 802.11 RSN.

   STA authentication is performed using IEEE 802.lX, and consequently
   EAP.  Implementers SHOULD use EAP methods meeting the requirements
   specified [RFC4017].

   When used with IEEE 802.11 RSN security, the CAPWAP protocol may
   introduce new vulnerabilities, depending on whether the link security
   (packet encryption and integrity verification) is provided by the WTP
   or the AC.  When the link security function is provided by the AC, no
   new security concerns are introduced.

   However, when the WTP provides link security, a new vulnerability
   will exist when the following conditions are true:

   o  The client is not the first to associate to the WTP/ESSID (i.e.,
      other clients are associated), a GTK already exists, and

   o  traffic has been broadcast under the existing GTK.

   Under these circumstances, the receive sequence counter (KeyRSC)
   associated with the GTK is non-zero, but because the AC anchors the
   4-way handshake with the client, the exact value of the KeyRSC is not
   known when the AC constructs the message containing the GTK.  The
   client will update its Key RSC value to the current valid KeyRSC upon
   receipt of a valid multicast/broadcast message, but prior to this,
   previous multicast/broadcast traffic that was secured with the
   existing GTK may be replayed, and the client will accept this traffic
   as valid.

   Typically, busy networks will produce numerous multicast or broadcast
   frames per second, so the window of opportunity with respect to such
   replay is expected to be very small.  In most conditions, it is
   expected that replayed frames could be detected (and logged) by the
   WTP.

   The only way to completely close this window is to provide the exact
   KeyRSC value in message 3 of the 4-way handshake; any other approach
   simply narrows the window to varying degrees.  Given the low relative
   threat level this presents, the additional complexity introduced by
   providing the exact KeyRSC value is not warranted.  That is, this
   specification provides for a calculated risk in this regard.

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

10.  IANA Considerations

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

10.1.  CAPWAP Wireless Binding Identifier

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

10.2.  CAPWAP IEEE 802.11 Message Types

   IANA created a new sub-registry in the existing CAPWAP Message Type
   registry, which is defined in [RFC5415].

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

           CAPWAP IEEE 802.11               Message Type     Reference
           Control Message                     Value

10.3.  CAPWAP Message Element Type

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

Top      Up      ToC       Page 71 
10.4.  IEEE 802.11 Key Status

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

10.5.  IEEE 802.11 QoS

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

           IEEE 802.11 QoS                  Type Value       Reference

10.6.  IEEE 802.11 Auth Type

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

           IEEE 802.11 Auth Type            Type Value       Reference

10.7.  IEEE 802.11 Antenna Combiner

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

           IEEE 802.11 Antenna Combiner     Type Value       Reference

Top      Up      ToC       Page 72 
10.8.  IEEE 802.11 Antenna Selection

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

           IEEE 802.11 Antenna Selection    Type Value       Reference

10.9.  IEEE 802.11 Session Key Flags

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

           IEEE 802.11 Station Session Key   Bit Position    Reference

10.10.  IEEE 802.11 Tagging Policy

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

           IEEE 802.11 Tagging Policy        Bit Position    Reference

10.11.  IEEE 802.11 WTP Radio Fail

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

Top      Up      ToC       Page 73 
           IEEE 802.11 WTP Radio Fail       Type Value       Reference

10.12.  IEEE 802.11 WTP Radio Type

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

           IEEE 802.11 WTP Radio Type        Bit Position    Reference

10.13.  WTP Encryption Capabilities

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

          IEEE 802.11 Encryption Capabilities  Bit Position    Reference

11.  Acknowledgments

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

12.  References

12.1.  Normative References

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

   [RFC2474]           Nichols, K., Blake, S., Baker, F., and D. Black,
                       "Definition of the Differentiated Services Field
                       (DS Field) in the IPv4 and IPv6 Headers",
                       RFC 2474, December 1998.

   [RFC3246]           Davie, B., Charny, A., Bennet, J., Benson, K., Le
                       Boudec, J., Courtney, W., Davari, S., Firoiu, V.,
                       and D. Stiliadis, "An Expedited Forwarding PHB
                       (Per-Hop Behavior)", RFC 3246, March 2002.

Top      Up      ToC       Page 74 
   [RFC3168]           Ramakrishnan, K., Floyd, S., and D. Black, "The
                       Addition of Explicit Congestion Notification
                       (ECN) to IP", RFC 3168, September 2001.

   [RFC3748]           Aboba, B., Blunk, L., Vollbrecht, J., Carlson,
                       J., and H. Levkowetz, "Extensible Authentication
                       Protocol (EAP)", RFC 3748, June 2004.

   [RFC5226]           Narten, T. and H. Alvestrand, "Guidelines for
                       Writing an IANA Considerations Section in RFCs",
                       BCP 26, RFC 5226, May 2008.

   [FIPS.197.2001]     National Institute of Standards and Technology,
                       "Advanced Encryption Standard (AES)", FIPS PUB
                       197, November 2001, <http://csrc.nist.gov/
                       publications/fips/fips197/fips-197.pdf>.

   [ISO.3166-1]        ISO Standard, "International Organization for
                       Standardization, Codes for the representation of
                       names of countries and their subdivisions - Part
                       1: Country codes", ISO Standard 3166-1:1997,
                       1997.

   [IEEE.802-11.2007]  "Information technology - Telecommunications and
                       information exchange between systems - Local and
                       metropolitan area networks - Specific
                       requirements - Part 11: Wireless LAN Medium
                       Access Control (MAC) and Physical Layer (PHY)
                       specifications", IEEE Standard 802.11, 2007,
                       <http://standards.ieee.org/getieee802/download/
                       802.11-2007.pdf>.

   [RFC5415]           Montemurro, M., Stanley, D., and P. Calhoun,
                       "CAPWAP Protocol Specification", RFC 5415, March
                       2009.

   [IEEE.802-1X.2004]  "Information technology - Telecommunications and
                       information exchange between systems - Local and
                       metropolitan area networks - Specific
                       requirements - Port-Based Network Access
                       Control", IEEE Standard 802.1X, 2004, <http://
                       standards.ieee.org/getieee802/download/
                       802.1X-2004.pdf>.

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

12.2.  Informative References

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

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

   [RFC5418]           Kelly, S. and C. Clancy, "Control And
                       Provisioning for Wireless Access Points (CAPWAP)
                       Threat Analysis for IEEE 802.11 Deployments",
                       RFC 5418, March 2009.

   [WPA]               "Deploying Wi-Fi Protected Access (WPA) and WPA2
                       in the Enterprise", March 2005, <www.wi-fi.org>.

   [WMM]               "Support for Multimedia Applications with Quality
                       of Service in WiFi Networks)", September 2004,
                       <www.wi-fi.org>.

Top      Up      ToC       Page 76 
Editors' Addresses

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

   Phone: +1 408-902-3240
   EMail: pcalhoun@cisco.com


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

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


   Dorothy Stanley (editor)
   Aruba Networks
   1322 Crossman Ave
   Sunnyvale, CA  94089

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