Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5413

SLAPP: Secure Light Access Point Protocol

Pages: 75
Historic
Part 2 of 3 – Pages 21 to 60
First   Prev   Next

Top   ToC   RFC5413 - Page 21   prevText

6. SLAPP Control Protocols

In this section, we describe two extensions for SLAPP -- one that is specific to 802.11 WLANs and another that is a technology-neutral protocol by which an AC can download a bootable image to a WTP.

6.1. 802.11 Control Protocol for SLAPP

This section describes a SLAPP extension that is targeted towards WTPs and ACs implementing the IEEE 802.11 WLAN standard. This extension contains all the technology-specific components that will be used by an AC to control and manage 802.11 WTPs.

6.1.1. Supported CAPWAP Architectures

The CAPWAP architecture taxonomy document [2] describes multiple architectures that are in use today in the WLAN industry. While there is a wide spectrum of variability present in these documented architectures, supporting every single variation or choice would lead to a complex protocol and negotiation phase. In the interest of limiting the complexity of the 802.11 component, we have limited the negotiation to four different architectural choices as listed below:
Top   ToC   RFC5413 - Page 22
   Local MAC, bridged mode:  This mode of operation falls under the
      Local MAC architecture.  The 802.11 MAC is terminated at the WTP.
      The WTP implements an L2 bridge that forwards packets between its
      WLAN interface and its Ethernet interface.

   Local MAC, tunneled mode:  This mode of operation also falls under
      the Local MAC architecture where the 802.11 MAC is terminated at
      the WTP.  The difference between this mode and the previous one is
      that in this mode, the WTP tunnels 802.3 frames to the AC using
      the mechanisms defined in Section 6.1.2.

   Split MAC, L2 crypto at WTP:  This mode of operation falls under the
      Split MAC architecture.  The 802.11 MAC is split between the WTP
      and the AC, the exact nature of the split is described in Section
      6.1.1.2.  The L2 crypto functions are implemented in the WTP are
      the ones used to satisfy this function irrespective of whether or
      not the AC is also capable of this function.  The WTP tunnels L2
      frames to the AC using mechanisms defined in Section 6.1.2.

   Split MAC, L2 crypto at AC:  This mode of operation also falls under
      the Split MAC architecture.  The difference between this one and
      the previous one is that the L2 crypto functions implemented in
      the AC are used to satisfy this function irrespective of whether
      or not these functions are also available at the WTP.  The WTP
      tunnels L2 frames to the AC using mechanisms defined in Section
      6.1.2.

6.1.1.1. Local MAC
The Local MAC architecture as documented in the CAPWAP architecture taxonomy document [2] performs all 802.11 frame processing at the WTP. The conversion from 802.11 to 802.3 and vice versa is also implemented at the WTP. This would mean that other functions like fragmentation/reassembly of 802.11 frames, and encryption/decryption of 802.11 frames is implemented at the WTP.
6.1.1.1.1. Bridged Mode
In this sub-mode of the Local MAC architecture, the 802.11 frames are converted to 802.3 frames and bridged onto the Ethernet interface of the WTP. These frames may be tagged with 802.1Q VLAN tags assigned by the AC.
Top   ToC   RFC5413 - Page 23
6.1.1.1.2. Tunneled Mode
In this sub-mode of the Local MAC architecture, the 802.11 frames are converted to 802.3 frames and are tunneled (using the tunneling mechanism defined in Section 6.1.2) to the AC to which the WTP is attached. These frames may be tagged with 802.1Q VLAN tags assigned by the AC.
6.1.1.2. Split MAC
In the Split MAC architecture, the MAC functions of an 802.11 AP are split between the WTP and the AC. The exact nature of the split is dependent upon the sub-modes listed in this section. In both cases, frames are tunneled to the AC using the mechanism defined in Section 6.1.2. Some of these Split MAC architectures convert the 802.11 frames into 802.3 frames, which may be 802.1Q-tagged using tags assigned by the AC, while other of these Split MAC architectures will tunnel the entire 802.11 frame to the AC. The AC and WTP agree on what type of frame will be tunneled during the control protocol registration in Section 6.1.3
6.1.1.2.1. L2 Crypto at the WTP
For this sub-mode of the Split MAC architecture, the 802.11 AP functions are split as follows: At the WTP: 802.11 control frame processing 802.11 encryption and decryption 802.11 fragmentation and reassembly Rate Adaptation 802.11 beacon generation Power-save buffering and Traffic Indication Map (TIM) processing At the AC: 802.11 Management frame processing 802.11 DS and portal
Top   ToC   RFC5413 - Page 24
   Split MAC implementations of this kind may tunnel either 802.11 or
   802.3 frames between the AC and the WTP.

6.1.1.2.2. L2 Crypto at the AC
For this sub-mode of the Split MAC architecture, the 802.11 AP functions are split as follows: At the WTP: 802.11 control frame processing Rate Adaptation 802.11 beacon generation Power-save buffering and TIM processing At the AC: 802.11 Management frame processing 802.11 encryption and decryption 802.11 fragmentation and reassembly 802.11 DS and portal Split MAC implementations of this kind tunnel 802.11 frames between the AC and the WTP.

6.1.2. Transport

The 802.11 Control Protocol has two components, one for transporting the specific control and provisioning messages and another to tunnel data traffic from the WTP to the AC. The SLAPP 802.11 Control Protocol uses the Generic Routing Encapsulation (GRE) [4] to encapsulate L2 frames. Depending on whether and how an architecture splits its MAC, some architectures may tunnel 802.11 frames directly to the AC while others may tunnel 802.3 frames, which may be optionally 802.1Q-tagged using tags assigned by the AC.
Top   ToC   RFC5413 - Page 25
   The delivery mechanism of these GRE packets is IP.  Therefore, the IP
   protocol of the outer packet is 47, indicating a GRE header follows.
   When GRE encapsulates 802.11 frames, the ether type in the GRE header
   is TBD; when GRE encapsulates 802.3 frames, the ether type in the GRE
   header is TBD2.

   Since IP is the delivery mechanism, all issues governing
   fragmentation and reassembly are handled by [5].

6.1.2.1. SLAPP 802.11 Control Protocol Header
When using the 802.11 Control Protocol, the type of SLAPP message is four (4), "control protocol packet". In this case, a two (2) octet field is appended to the SLAPP header to indicate the control protocol type as shown in Figure 8. The SLAPP 802.11 Control Protocol takes place in the "Negotiated Control Protocol" phase of Section 4.1, and all SLAPP 802.11 Control Protocol messages are therefore secured by the security association created immediately prior to entering that phase. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maj | Min | 4 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 802.11 Control Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: SLAPP Control Protocol Header Where valid 802.11 Control Protocol Types are: 1 : Registration Request - sent from WTP to AC 2 : Registration Response - sent from AC to WTP 3 : De-Registration Request - sent by either WTP or AC 4 : De-Registration Response - sent by the recipient of the corresponding request 5 : Configuration Request - sent by WTP to AC 6 : Configuration Response - sent by AC to WTP 7 : Configuration Update - sent by AC to WTP 8 : Configuration Acknowledgment - sent by the WTP to AC
Top   ToC   RFC5413 - Page 26
      9 : Status Request - sent by the AC to the WTP

      10 : Status Response - sent by the WTP to the AC

      11 : Statistics Request - sent by the AC to the WTP

      12 : Statistics Response - sent by the WTP to the AC

      13 : Event - sent by the WTP to the AC

      14 : Keepalive - sent either way

      15 : Key Config Request - sent by the AC to the WTP

      16 : Key Config Response - sent by the WTP to the AC

6.1.3. Provisioning and Configuration of WTP

All basic configuration functions are applicable per-Extended Service Set Identifier (ESSID) per-radio in a WTP. Some WTPs MAY support more than one ESSID per-radio, while all WTPs MUST support at least one ESSID per-radio, which may be considered the primary ESSID in case of multiple ESSID support. All per-WTP configurations and capabilities (e.g., number of radios) are handled as part of the discovery and initialization process. The provisioning of the regulatory domain of a WTP is beyond the scope of this document. A WTP, once provisioned for a specific regulatory domain, MUST restrict the operational modes, channel, transmit power, and any other necessary limits based on the knowledge contained within its software image and hardware capabilities. The WTP MUST communicate its capabilities limited by the regulatory domain as well as by the WTP hardware, if any, to the AC during the capability exchange. The allocation and assignment of Basic Service Set Identifiers (BSSIDs) to the primary interface and to the virtual access point (AP) interfaces, if supported, are outside the scope of this document.
6.1.3.1. Information Elements
Information elements (IEs) are used to communicate capability, configuration, status, and statistics information between the AC and the WTP.
Top   ToC   RFC5413 - Page 27
6.1.3.1.1. Structure of an Information Element
The structure of an information element is show below. The element ID starts with an element ID octet, followed by a 1-octet length, and the value of the element ID whose length is indicated in the Length field. The maximum length of an element is 255 octets. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Element ID | Length | Value .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.1.3.1.2. CAPWAP Mode
This element defines the MAC architecture modes (Section 6.1.1). Element ID : 1 Length : 1 Value : The following values are defined. Bit 0 : CAPWAP mode 1 - Local MAC, bridged mode Bit 1 : CAPWAP mode 2 - Local MAC, tunneled mode Bit 2 : CAPWAP mode 3 - Split MAC, WTP encryption, 802.3 tunneling Bit 3 : CAPWAP mode 4 - Split MAC, WTP encryption, 802.11 tunneling Bit 4 : CAPWAP mode 5 - Split MAC, AC encryption, 802.11 tunneling Bits 5-7 : Set to 0 When this element is included in the capabilities message, then the setting of a bit indicates the support for this CAPWAP mode at the WTP. When this element is used in configuration and status messages, then exactly one of bits 0-4 MUST be set.
6.1.3.1.3. Number of WLAN Interfaces
This element refers to the number of 802.11 WLANs present in the WTP. Element ID : 2 Length : 1
Top   ToC   RFC5413 - Page 28
      Value : 0-255

6.1.3.1.4. WLAN Interface Index
This element is used to refer to a particular instance of a WLAN interface when used in configuration and status messages. When used within a recursion element, the elements within the recursion element correspond to the WLAN interface specified in this element. Element ID : 3 Length : 1 Value : 0 - (Number of WLAN interfaces - 1)
6.1.3.1.5. WLAN Interface Hardware Vendor ID
This element is the WLAN Interface hardware vendor's SMI enterprise code in network octet order (these enterprise codes can be obtained from, and registered with, IANA). This field appears once for each instance of WLAN interface present in the WTP. Element ID : 4 Length : 4 Value : 32-bit value
6.1.3.1.6. WLAN Interface Type ID
This element is an ID assigned by the WLAN Interface hardware vendor to indicate the type of the WLAN interface. It is controlled by the hardware vendor and the range of possible values is beyond the scope of this document. This field appears once for each instance of a WLAN interface present in the WTP. Element ID : 5 Length : 4
6.1.3.1.7. Regulatory Domain
If a regulatory domain is provisioned in the WTP, then the WTP indicates this by including this element in the capabilities list. If this information is not available at the WTP, then this element SHOULD not be included in the capabilities list. The process by which this information is provisioned into the WTP is beyond the scope of this document.
Top   ToC   RFC5413 - Page 29
      Element ID : 6

      Length : 4

      Value : ISO code assigned to the regulatory domain

6.1.3.1.8. 802.11 PHY Mode and Channel Information
This element indicates the list of 802.11 Physical Layer (PHY) modes supported by the WTP along with a list of channels and maximum power level supported for this mode. This element appears once for each instance of WLAN interface at the WTP. There could be multiple instances of this element if the WLAN interface supports multiple PHY types. Element ID : 7 Length : Variable Valid : This field consists of PHY mode : With a length of 1 octet with values as follows: 0 : Radio Disabled/Inactive 1 : IEEE 802.11b 2 : IEEE 802.11g 3 : IEEE 802.11a 4-255 : Reserved Power Level : In the capabilities messages, this indicates the maximum power level supported in this mode by the WTP; while in the configuration and status messages, this field indicates the desired power level or the current power level that the WTP is operating at. The field has a length of 1 octet and the power level is indicated in dBm. Channel Information : A variable number of 2-octet values that indicate the center frequencies (in KHz) of all supported channels in this PHY mode. When this element is used in configuration and status messages, the Power Level field indicates the desired or current operating power level. The Channel field has exactly one 2-octet value indicating the desired or current operating frequency.
Top   ToC   RFC5413 - Page 30
6.1.3.1.9. Cryptographic Capability
In the capabilities message, this element contains the list of cryptographic algorithms that are supported by the WTP. This appears once for each instance of the WLAN interface present in the WTP. In configuration and status messages, this element is used to indicate the configured cryptographic capabilities at the WTP. Element ID : 8 Length : 1 Value : The following bits are defined: Bit 0 : WEP Bit 1 : TKIP Bit 2 : AES-CCMP Bits 3-7 : Reserved
6.1.3.1.10. Other IEEE 802.11 Standards Support
This element contains a bitmap indicating support at the WTP for various IEEE 802.11 standards. Element ID : 9 Length : 4 Value : A bitmap as follows: Bit 0 : WPA Bit 1 : 802.11i Bit 2 : WMM Bit 3 : WMM-SA Bit 4 : U-APSD Bits 5-32 : Reserved
Top   ToC   RFC5413 - Page 31
6.1.3.1.11. Antenna Information Element
In the capabilities message, this element is formatted as follows Element ID : 10 Length : 4 Value : Formatted as follows: Bits 0-7 : Number of Antennae Bit 8 : Individually Configurable, 0 = No, 1 = Yes Bit 9 : Diversity support, 0 = No, 1 = Yes Bit 10 : 0 = Internal, 1 = External Bits 11-31 : Reserved In configuration and status messages, this element is formatted as follows: Element ID : 10 Length : 4 Value : Formatted as follows: Bits 0-7 : Antenna Number - is a number between 0 and the number of antennae indicated by the WTP. The value is valid only if Bit 8 is set; otherwise, it MUST be ignored. Bit 8 : Antenna Select - if this bit is reset, then the antenna selection is left to the algorithm on the WTP. If this bit is set, then the Antenna Number field indicates the antenna that should be used for transmit and receive. Bits 9-31 : Reserved
6.1.3.1.12. Number of BSSIDs
This element indicates the number of BSSIDs supported by the WLAN interface. This element is optional in the capabilities part of the registration request message, and if it is absent, then the number of BSSIDs is set to 1. This element appears once for each instance of a WLAN interface present in the WTP.
Top   ToC   RFC5413 - Page 32
      Element ID : 11

      Length : 1

      Value : The number of BSSIDs that the WLAN interface is capable of
      supporting.

6.1.3.1.13. BSSID Index
This element is used when sending configuration or status specific to a certain BSSID in the WTP. Element ID : 12 Length : 1 Valid values are from 0 to (Number of BSSIDs -1)
6.1.3.1.14. ESSID
This element is used in configuration and status messages to either configure the ESSID on a certain BSSID or report the current operating value. Element ID : 13 Length : Variable, between 0 and 32 both inclusive. Value : Variable, contains ASCII characters. There is no default value for this parameter.
6.1.3.1.15. ESSID Announcement Policy
This element is used in configuration and status messages to control the announcement of the ESSID in 802.11 beacons. For the Local MAC modes of operation, this field is also used to control whether the WTP should respond to Probe Requests that have a NULL ESSID in them. Element ID : 14 Length : 1 Value : Defined as follows: Bit 0 : ESSID announcement, 0 = Hide ESSID, 1 = Display ESSID in 802.11 beacons. The default value for this bit is 1.
Top   ToC   RFC5413 - Page 33
      Bit 1 : Probe Response policy, 0 = Respond to Probe Requests that
              contain a NULL ESSID, 1 = Respond only to Probe Requests
              that match the configured ESSID.  The default value for
              this bit is 0.

      Bit 2-7 : Reserved

6.1.3.1.16. Beacon Interval
This element is used to configure the beacon interval on a BSSID on the WTP. Element ID : 15 Length : 2 Value : Valid values for the beacon interval as allowed by IEEE 802.11 The default value for this parameter is 100.
6.1.3.1.17. DTIM period
This element is used to configure the DTIM period on a BSSID present on the WTP. Element ID : 16 Length : 2 Value : Valid values for the DTIM period as allowed by IEEE 802.11. The default value for this parameter is 1.
6.1.3.1.18. Basic Rates
Configure or report the configured set of basic rates. Element ID : 17 Length : 4 Value : Each of the bits in the following list is interpreted as follows. If the bit is set, then that particular rate is to be configured as a basic rate. If the bit is reset, then the rate is not to be configured as a basic rate.
Top   ToC   RFC5413 - Page 34
         Bit 0 : 1 Mbps

         Bit 1 : 2 Mbps

         Bit 2 : 5.5 Mbps

         Bit 3 : 11 Mbps

         Bit 4 : 6 Mbps

         Bit 5 : 9 Mbps

         Bit 6 : 12 Mbps

         Bit 7 : 18 Mbps

         Bit 8 : 24 Mbps

         Bit 9 : 36 Mbps

         Bit 10 : 48 Mbps

         Bit 11 : 54 Mbps

         Bits 12-31 : Reserved

6.1.3.1.19. Supported Rates
Configure or report the configured set of basic rates. Element ID : 18 Length : 4 Value : Each of the bits in the following list is interpreted as follows. If the bit is set, then that particular rate is to be configured as a supported rate. If the bit is reset, then the rate is not to be configured as a supported rate. Bit 0 : 1 Mbps Bit 1 : 2 Mbps Bit 2 : 5.5 Mbps Bit 3 : 11 Mbps Bit 4 : 6 Mbps
Top   ToC   RFC5413 - Page 35
         Bit 5 : 9 Mbps

         Bit 6 : 12 Mbps

         Bit 7 : 18 Mbps

         Bit 8 : 24 Mbps

         Bit 9 : 36 Mbps

         Bit 10 : 48 Mbps

         Bit 11 : 54 Mbps

         Bits 12-31 : Reserved

6.1.3.1.20. 802.11 Retry Count
This element is used to configure long and short retries for each BSSID present on the WTP. Element ID : 19 Length : 2 Value : as follows: Bits 0-7 : Short retry count, default value is 3. Bits 8-15 : Long retry count, default value is 3.
6.1.3.1.21. Fragmentation Threshold
This element is used to configure the fragmentation threshold on a BSSID present on the WTP. Element ID : 20 Length : 2 Value : Valid values for the fragmentation threshold as allowed by IEEE 802.11. The default value for this parameter is 2346.
Top   ToC   RFC5413 - Page 36
6.1.3.1.22. RTS Threshold
This element is used to configure the Request to Send (RTS) threshold on a BSSID present on the WTP. Element ID : 21 Length : 2 Value : Valid values for RTS threshold as allowed by IEEE 802.11. The default value for this parameter is 2346.
6.1.3.1.23. Short/Long Preamble
This element is used to configure the preamble type used for transmission in 802.11b mode. Element ID : 22 Length : 1 Value : Defined as follows: 0 : Disable Short preamble 1 : Enable Short preamble 2-255 : Reserved The default value for this parameter is 0.
6.1.3.1.24. 802.1Q Tag
This element is used to configure the tagging of packets belonging to a particular SSID when transferred between the AC and the WTP in CAPWAP modes 2-3, or before the WTP bridges the 802.3 frame to its wired interface when operating in CAPWAP mode 1. Element ID : 23 Length : 2 Value : 802.1Q tag If this element is absent in the configuration, then the WTP MUST assume that no tagging is required and should expect to receive untagged frames on frames destined towards the wireless interface.
Top   ToC   RFC5413 - Page 37
6.1.3.1.25. SLAPP Registration ID
A successful registration response from an AC to a WTP MUST contain this element. It is used in messages between the WTP and the AC on all other messages during the duration for which the registration is active. Element ID : 24 Length : 4 Value : A 32-bit unsigned number allocated by the AC
6.1.3.1.26. WTP Name
The AC uses this element to assign a string of ASCII characters to the WTP. Element ID : 25 Length : Variable, between 0 and 64 both inclusive Value : A variable length string of ASCII characters
6.1.3.1.27. Event Filter
The AC uses this element to assign importance to events, enable or disable notification, and to configure the global event notification policy. When the Event Identifier is 0, this element serves as a global notification policy message. The bitmap indicates the types of events that require the WTP to generate a notification. When the Event Identifier is non-zero, this element is used to configure a specific event for notification and its importance level. The importance level is specified by setting exactly one bit in the bitmap. If none of the bits are set in the bitmap, the element should be interpreted as a cancellation request. The WTP should stop sending notifications for the corresponding event specified in the Element Identifier. Element ID : 26 Length : 4 Value : Defined as follows: Bits 0 - 15: Event Identifier Bit 16: Fatal - The system is not usable.
Top   ToC   RFC5413 - Page 38
         Bit 17: Alert - Immediate action is required.

         Bit 18: Critical

         Bit 19: Error

         Bit 20: Warning

         Bit 21: Notification

         Bit 22: Informational

         Bit 23: Debug

         Bits 24 - 31: Reserved

6.1.3.1.28. Radio Mode
The AC uses this element to indicate the mode of operation for the radio for each WLAN interface. Element ID : 27 Length : 1 Value : The following are valid values: 0 : Radio is disabled 1 : Radio is enabled 2-255 : Reserved
6.1.3.1.29. IEEE 802.11e Element
The AC uses this element to configure 802.11e functions at the WTP. Element ID : 28 Length : 4 Value : A bitmap as follows: Bit 0 : WMM Bit 1 : WMM-SA Bit 2 : U-APSD
Top   ToC   RFC5413 - Page 39
         Bits 3-32 : Reserved

6.1.3.1.30. Configuration Statistics
This element defines the statistics relating to configuration and registration events as seen by the WTP. Element ID : 29 Length : 32 Value : The value is as follows: * Configuration Requests : 4 octets - Number of Configuration Request messages sent by the WTP since the last reboot or reset of the counters. * Configuration Responses : 4 octets * Configuration Updates : 4 octets * Configuration ACKs : 4 octets * Registration Requests : 4 octets * Registration Responses : 4 octets * De-Registration Requests : 4 octets * De-Registration Responses : 4 octets
6.1.3.1.31. Transmit Frame Counters
This information element contains a set of counters relating to the transmit side of the wireless link at the WTP. These counters apply to either a BSS or an Access Category (if Wireless Multimedia (WMM) is enabled). Element ID : 30 Length : 112 octets Value : The value of this element is defined as follows: * Total received from the network : 4 octets * Successfully transmitted frames (total) : 4 octets
Top   ToC   RFC5413 - Page 40
      *  Successfully transmitted 802.11 Mgmt frames : 4 octets

      *  Successfully transmitted 802.11 Data frames : 4 octets

      *  Transmitted 802.11 Control frames : 4 octets

      *  Frames that reached max-retry limit : 4 octets

      *  Transmitted frames with 1 retry attempt : 4 octets

      *  Transmitted frames with 2 retry attempts : 4 octets

      *  Transmitted frames with more than 2 retry attempts : 4 octets

      *  Frames transmitted at each 802.11 PHY rate : 12*4 octets - The
         counters indicate the number of frames at each of the following
         rates, respectively: 1, 2, 5.5, 11, 6, 9, 12, 18, 24, 36, 48,
         54 Mbps.

      *  Total frame dropped : 4 octets

      *  Frames dropped due to insufficient resources : 4 octets

      *  Frames dropped due to power-save timeouts : 4 octets

      *  Frames dropped due to other reasons : 4 octets

      *  Fragments transmitted : 4 octets

      *  Fragments dropped : 4 octets

      *  Power-save multicast frames : 4 octets

      *  Power-save unicast frames : 4 octets

6.1.3.1.32. Received Frame Counters
This information element includes all statistics related to the reception of the frames by WTP. These counters apply to either a BSS or an Access Category (if WMM is enabled). Element ID : 31 Length : 108 octets Value : The value of this element is defined as follows: * Total Frames received : 4 octets
Top   ToC   RFC5413 - Page 41
      *  Frames with the retry bit set : 4 octets

      *  802.11 Data frames received : 4 octets

      *  802.11 Mgmt frames received : 4 octets

      *  802.11 Control frames received : 4 octets

      *  Cyclic Redundancy Check (CRC) errors : 4 octets

      *  PHY errors : 4 octets

      *  Total Fragments received : 4 octets

      *  Reassembled frames : 4 octets

      *  Reassembly failures : 4 octets

      *  Successful Decryption : 4 octets

      *  Decryption failures : 4 octets

      *  Rate statistics : 48 octets - The number of frames received at
         each of the 802.11 PHY rates, respectively - 1, 2, 5.5, 11, 6,
         9, 12, 18, 24, 36, 49, 54 Mbps.

      *  Total frames dropped : 4 octets

      *  Frames dropped due to insufficient resources : 4 octets

      *  Frames dropped due to other reasons : 4 octets

6.1.3.1.33. Association Statistics
This element includes information about the current stations associated with the BSS. Element ID : 32 Length : Variable Value : The value is defined as follows: * Total association requests : 4 octets * Total associations accepted : 4 octets * Total associations rejected : 4 octets
Top   ToC   RFC5413 - Page 42
      *  Current associations : 4 octets

      *  For each associated station,

         +  Station MAC address : 6 octets

         +  Power save state : 1 octet

         +  Current Tx rate : 1 octet

         +  Rate of last packet : 1 octet

         +  Preamble type : 1 octet

         +  WMM/U-APSD state : 1 octet

6.1.3.1.34. Status Element
The status IE is included in the status response message sent by the WTP to the AC. It contains a set of fields that are used to indicate the status of various states at the WTP or each BSS configured in the WTP. Element ID : 33 Length : 2 octets Value : The value is defined as follows: Enterprise Resource Planning (ERP) element, if applicable. If not applicable, then this field MUST be set to 0. Noise Floor : 1 octet
6.1.3.1.35. Event Configuration
This element is used by the AC to configure the set of events that it wants to be notified by the WTP. Element ID : 34 Length : 4 octets Value : The value is defined as follows: * Radar Detection - 1 octet
Top   ToC   RFC5413 - Page 43
         +  Bit 0 : 1 = notify on detecting radar interference, 0
            otherwise.

         +  Bit 1 : 1 = notify of channel change due to radar
            interference, 0 otherwise.

         +  All other bits are reserved.

      *  Excessive Retry Event - 1 octet.  Number of successive frames
         that have not been acknowledged by a client.  A value of 0
         disables notification.

      *  Noise Floor Threshold - 1 octet.  Defines the threshold above
         which an event would be generated by the WTP.

      *  802.11 Management and Action Frame Notification - 1 octet.

         +  Bit 0 : If set, notify the AC of Probe Requests from
            stations (please use with caution).  If reset, then no Probe
            Response notification is needed.

         +  Bit 1 : If set, the WTP should notify the AC of all other
            management frames from stations.

         +  All other bits are reserved.

6.1.3.1.36. Radar Detection Event
This element is used by the WTP to notify the AC of the detection of radar interference and any channel changes as a result of this detection. Element ID : 35 Length : 10 octets Value : Defined as follows: BSSID : 6 octets. The BSSID of the WLAN interface that detected the radar interference. Channel : 2 octets. The channel on which radar interference was detected. New Channel : 2 octets. The new channel to which the WTP moved as a result of the detection of radar interference.
Top   ToC   RFC5413 - Page 44
6.1.3.1.37. Excessive Retry Event
This element is used by the WTP to indicate excessive retry events on transmission to an associated station. Element ID : 36 Length : 14 octets Value : Defined as follows: Station MAC : 6 octets Associated BSSID : 6 octets Length of last burst of excessive retries : 2 octets.
6.1.3.1.38. Noise Floor Event
This element is used by the WTP to notify the AC of the current noise floor at one of the WLAN interfaces exceeding the configured noise floor threshold. Element ID : 37 Length : 10 octets Value : Defined as follows: BSSID : 6 octets Current Channel : 2 octets Current Noise Floor : 2 octets
6.1.3.1.39. Raw 802.11 Frame
This element provides a generic capability for either a WTP or an AC to send a raw 802.11 frame to the other party. For example, it can be used to notify the AC of station association/disassociation events in the case of Local MAC architectures. Element ID : 252 Length : Variable Value : A raw 802.11 frame
Top   ToC   RFC5413 - Page 45
6.1.3.1.40. Vendor-Specific Element
This element is used to transfer vendor-specific information between the WTP and the AC. Element ID : 253 Length : Variable, > 3 Value : This variable-length element starts with a 3-octet Organizationally Unique Identifier (OUI), followed by a series of octets that are specific to the vendor represented by the OUI.
6.1.3.1.41. Recursion Element
This element type can be used to recursively define a variable-length element that should be interpreted as a series of other elements defined in this section. It can be used to bound a set of elements as a unit. Element ID : 254 Length : Variable Value : A variable length element that contains a set of one or more elements defined in this section.
6.1.3.1.42. Pad Element
This is a generic element type that can be used to pad the packets, if necessary. Element ID : 255 Length : Variable Value : A variable-length element that MUST be filled with all 0s at the source and MUST be ignored at the destination.
Top   ToC   RFC5413 - Page 46
6.1.3.2. SLAPP 802.11 Control Protocol Messages
6.1.3.2.1. Registration Request
At the start of the SLAPP 802.11 Control Protocol, the WTP sends a registration request to the AC that it authenticated with. The registration request carries a list of information elements indicating the WTP's capabilities to the AC. The message starts with the SLAPP 802.11 Control Protocol header (Figure 8) with a SLAPP Control Protocol message type of 1. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maj | Min | 4 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transaction ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Information Elements ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: SLAPP 802.11 Registration Request Flags : Reserved Transaction ID : A 32-bit random number chosen by the WTP at the start of a new registration phase. This number is used in the registration response by the AC to match the response to the corresponding request. The following information elements are mandatory in the capabilities exchange: 1 : CAPWAP mode 2 : Number of WLAN interfaces For each WLAN interface: 7 : 802.11 PHY mode and Channel Information 8 : Cryptographic Capability 9 : Other 802.11 standards support
Top   ToC   RFC5413 - Page 47
   The following information elements may be optionally included in the
   registration request:

      For each WLAN interface:

         4 : WLAN Interface HW Vendor ID

         5 : WLAN Interface Type ID

         6 : Regulatory Domain

         10 : Antenna Information Element

         11 : Number of BSSIDs

         253 : Vendor-Specific Element

6.1.3.2.2. Registration Response
Upon receiving a registration request, the AC may either chose to accept the WTP or reject its registration request. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maj | Min | 4 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transaction ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Information Elements ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: SLAPP 802.11 Registration Response Flags : Bit 0 : Indicates the status of the transaction, 0 = successful response from the AC, 1 = the registration request is being rejected by the AC. Bits 1-7 : Reserved Bits 8-15 : If bit 0 = 1 (i.e., the registration request is being rejected by the AC), then this field contains a reason code. Otherwise, these bits are currently set to 0. The following reason codes are currently defined:
Top   ToC   RFC5413 - Page 48
            0 : Reserved

            1 : Unspecified reason

            2 : Unable to handle more WTPs

            3 : Incompatible capabilities

            4-255 : Reserved

      Transaction ID : A 32-bit random number chosen by the WTP at the
      start of a new registration phase.  This number is used in the
      registration response by the AC to match the response to the
      corresponding request.

   The following information elements are mandatory if the transaction
   is successful:

      1 : CAPWAP mode - the mode that the AC chooses from among the list
      of supported modes sent by the WTP in the registration request.

      24 : SLAPP registration ID

6.1.3.2.3. De-Registration Request
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maj | Min | 4 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SLAPP Registration ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reason Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: SLAPP 802.11 De-Registration Request Flags : Reserved SLAPP Registration ID : The registration ID assigned by the AC upon successful registration. Reason Code : The following are valid values: 0 : Unspecified reason
Top   ToC   RFC5413 - Page 49
         1 : The device that is the source of the frame is going down.

         All other values are reserved.

6.1.3.2.4. De-Registration Response
The De-Registration Response is a simple ACK from the recipient of the corresponding De-Registration Request. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maj | Min | 4 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SLAPP Registration ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reason Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12: SLAPP 802.11 De-Registration Response Flags : Reserved SLAPP Registration ID : The registration ID assigned by the AC upon successful registration. Reason Code : The same reason code used in the corresponding request.
Top   ToC   RFC5413 - Page 50
6.1.3.2.5. Configuration Request
The Configuration Request message is used by the WTP to request a set of configurations for each BSS that the AC wishes to configure at 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maj | Min | 4 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 5 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SLAPP Registration ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Information Element ID list ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13: SLAPP 802.11 Configuration Request The Information Element ID list field contains the list of IEs that the WTP is interested in obtaining configuration information for.
6.1.3.2.6. Configuration Response
The Configuration Response message is used by the AC to respond to a Configuration Request by 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maj | Min | 4 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 6 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SLAPP Registration ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Information Element list ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14: SLAPP 802.11 Configuration Response The following information elements are mandatory in the Configuration Response: 01: CAPWAP mode For each WLAN interface:
Top   ToC   RFC5413 - Page 51
         03: WLAN Interface Index

         27: Radio Mode

         07: 802.11 PHY mode and Channel Selection

         For each BSSID:

            12: BSSID Index

            13: ESSID

            08: Cryptographic Selection

   The following information elements may be optionally included in the
   Configuration Response:

      10: Antenna Information Element

      25: WTP Name

      For each WLAN interface:

         For each BSSID:

            14: ESSID Announcement Policy

            15: Beacon Interval

            16: DTIM Period

            17: Basic Rates

            18: Supported Rates

            19: Retry Count

            20: Fragmentation Threshold

            21: RTS Threshold

            22: Short/Long Preamble

            23: 802.1Q Tag

            253: Vendor-Specific Element
Top   ToC   RFC5413 - Page 52
   If any of the optional IEs is absent in the Configuration Response
   message, then their default values are applied by the WTP.

6.1.3.2.7. Configuration Update
The Configuration Update message is initiated by the AC to push modified or updated configuration to the WTP. It has a format similar to that of the Configuration Response message defined above. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maj | Min | 4 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 7 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SLAPP Registration ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Information Element list ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 15: SLAPP 802.11 Configuration Update The list of mandatory and optional IEs for the Configuration Update message is the same as that for the Configuration Response message.
6.1.3.2.8. Configuration Acknowledgment
The Configuration Acknowledgment message is used by the WTP to inform the AC whether it has accepted the prior Configuration Update or Configuration Response message. The WTP can reject the configuration sent by the AC, in which case it MUST return to the discovery state. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maj | Min | 4 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 8 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SLAPP Registration ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 16: SLAPP 802.11 Configuration ACK The Status Code field contains one of the following values:
Top   ToC   RFC5413 - Page 53
      0 : Success - The WTP accepts that the configuration pushed by the
      AC and has applied it.

      1 : Failure - The WTP did not accept the configuration pushed by
      the AC and MUST be de-registered at the AC.

6.1.3.2.9. Status Request
The status request message is used by the AC to request the configuration and operational status from 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maj | Min | 4 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 9 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SLAPP Registration ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Information Element ID list ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 17: SLAPP 802.11 Status Request The Information Element ID list contains the list of IEs for which the AC requests status.
6.1.3.2.10. Status Response
The status response message is used by the WTP to respond to a status request from 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maj | Min | 4 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 10 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SLAPP Registration ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Information Element list ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 18: SLAPP 802.11 Status Response The Flags field contains one of the following values:
Top   ToC   RFC5413 - Page 54
      Bit 0 : If set, Unknown AC or SLAPP registration ID.  If this bit
      is reset, then this indicates a successful response.

      Bit 1 : If set, the WTP indicates that it has not been configured
      yet; otherwise, the WTP is in a configured state.

      All other values are reserved.

   The status IE is mandatory in a status response message.

6.1.3.2.11. Statistics Request
The Statistics request message is used by the AC to request statistics information from 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maj | Min | 4 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 11 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SLAPP Registration ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Information Element list ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 19: SLAPP 802.11 Statistics Request The Flags field contains the following bits: Bit 0 : If set to 1, then the WTP should reset the counters after sending the statistics response message. All other bits are reserved and MUST be set to 0 by the source and ignored by the destination.
Top   ToC   RFC5413 - Page 55
6.1.3.2.12. Statistics Response
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maj | Min | 4 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 12 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SLAPP Registration ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Information Element list ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 20: SLAPP 802.11 Statistics Response The Flags field contains the following bits: Bit 0 : If set, then the counters have been reset as requested by the AC. Bit 1 : If set, then the WTP has encountered a statistics request from either an unknown AC or with an unknown SLAPP registration ID. Bit 2 : If set, WTP indicates that it has not been configured yet; otherwise, the WTP is in a configured state. All other bits are reserved.
6.1.3.2.13. Keepalive
The keepalive messages can be initiated by either the WTP or the AC. It is used to probe the availability of the other party and the path between them. The initial message is termed the keepalive request, while the response to that message is termed the keepalive response. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maj | Min | 4 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 13 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SLAPP Registration ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 21: SLAPP Keepalive Packet
Top   ToC   RFC5413 - Page 56
   The Flags field has the following values:

      Bit 0 : Set to 0 in a keepalive request message, set to 1 in a
      keepalive response message.

      Bit 1 : Set to 0 in a keepalive request message, set to 1 in a
      keepalive response message if the initiator of the keepalive
      request is unknown or the SLAPP registration ID is incorrect, and
      set to 0 otherwise.

      All other bits are reserved and must be set to 0 by the source and
      ignored at the destination.

6.1.3.2.14. Key Configuration
In CAPWAP mode 5, the 802.11 crypto functions are performed at the AC. So there is no need for the AC to send PTKs/GTKs to the WTP. When one of the CAPWAP Modes 1-4 has been negotiated between the AC and WTP, it is necessary for the AC to send both unicast and broadcast/multicast keys to the WTP. This is accomplished after the 802.1x authenticator (which resides on the AC) has successfully authenticated the supplicant. Key Configuration Requests are differentiated -- unicast or broadcast -- by setting or clearing the high-order bit of the "Flags" field. The setting of this bit determines the contents of the Key Configuration Request following the SLAPP Registration ID.
Top   ToC   RFC5413 - Page 57
6.1.3.2.14.1.  Unicast Key Configuration Request

   The Unicast Key Configuration Request is used by the AC to inform the
   WTP of the key to use when protecting unicast frames to and from a
   specified supplicant.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Maj  |  Min  |      4        |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              15               |0|          Flags              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    SLAPP Registration ID                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     supplicant MAC address                    ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | supplicant mac address (cont) |  Supp 802.1Q tag      | RSVD  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     unicast key length        |         unicast key           ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 22: Unicast Key Configuration Request

   Note the high-order bit of the "Flags" field is cleared to indicate a
   unicast key is being sent.  The 802.1Q tag field is used to indicate
   to the WTP which VLAN this supplicant is in and which broadcast/
   multicast key to use when communicating to it with broadcast/
   multicast frames.

6.1.3.2.14.2.  Broadcast/Multicast Key Configuration Request

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Maj  |  Min  |      4        |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              15               |1|          Flags              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    SLAPP Registration ID                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    801.1q tag         | RSVD  | broadcast/multicast key length|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                  broadcast/multicast key                      ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 23: Group Key Configuration Request
Top   ToC   RFC5413 - Page 58
   Note the high-order bit of the "Flags" field is set, indicating a
   broadcast/multicast key is being sent.  The bits marked "RSVD" are
   reserved and MUST be set to zero by the AC and ignored by the WTP.

6.1.3.2.14.3.  Unicast Key Configuration Response

   The WTP acknowledges receipt of a Unicast Key Configuration Request
   by sending a Unicast Key Configuration Response.  This response
   mirrors the request but does not send back the key length or the key
   itself.  (The RSVD bits are returned for alignment purposes and MUST
   be set to zero by the WTP and ignored 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Maj  |  Min  |      4        |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              16               |0|          Flags              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    SLAPP Registration ID                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     supplicant MAC address                    ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | supplicant mac address (cont) |  Supp 802.1Q tag      | RSVD  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 24: Unicast Key Configuration Response
Top   ToC   RFC5413 - Page 59
6.1.3.2.14.4.  Multicast Key Configuration Response

   The WTP acknowledges receipt of a Multicast Key Configuration Request
   by sending a Multicast Key Configuration Response.  This response
   mirrors the request, but it does not send back the key length or the
   key itself.  (The RSVD bits are returned for alignment purposes and
   MUST be set to zero by the WTP and ignored 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Maj  |  Min  |      4        |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              16               |0|          Flags              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    SLAPP Registration ID                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    801.1q tag         | RSVD  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 25: Group Key Configuration Response

6.1.3.3. Monitoring and Statistics
An AC may want to periodically monitor the health of a WTP, collect the necessary information for diagnostics, and get notifications on pre-defined events at the WTP that may be of interest. This section defines a set of WTP statistics and events and describes the process of collecting statistics from WTPs and configuring the event notification mechanism at the WTP. It is beyond the scope of this document to describe what should/could be done with the collected information.
6.1.3.3.1. Statistics Collection Procedure
The simple statistics collection procedure defined here does not require the WTP to maintain any timers or any similar mechanisms. A WTP is responsible only for maintaining the statistics defined in Information Elements 29, 30, 31, and 32. The WTP must also respond to a statistics request message from the AC by delivering the appropriate statistics to the AC using a statistics response message. For example, if an AC is interested in gathering periodic statistics about some specific statistics, it is the responsibility of the AC to poll the WTP at the appropriate intervals.
Top   ToC   RFC5413 - Page 60
6.1.3.3.2. Events Procedure
The event notification process includes the following: 1) Event Registration: the registration of events of interest at the WTP by the AC and 2) Notification: The communication of event-related information by the WTP to the AC whenever the conditions for a specific registered event has occurred. The set of events supported by a WTP and the event-specific parameters that may be configured as part of a event registration are given in Section 6.1.3.3.3.
6.1.3.3.3. WTP Events
This section defines a set of WTP events along with the event- specific parameters that may be configured by ACs and the event- related information that should be delivered to the ACs by WTPs when the conditions for a particular configured event have occurred. Radar Detection Event: Configure whether the AC is interested in receiving a notification whenever a radar event is detected. The WTP may notify the AC about the type of radar interference and the new channel that the WTP has moved to as a result, if any, using the Radar Detection Event Element (element ID: 35). Excessive Retry Event: Configure the number of consecutive transmission failures before a notification is generated. The WTP may notify the MAC address of the station (STA) and the number of consecutive unacknowledged frames so far using the Excessive Retry Event Element (element ID : 36). Noise Floor Event: Configure the noise floor threshold above which an event notification would be generated by the WTP. The WTP may notify the AC with the most recent measured noise floor that exceeded the configured threshold using the Noise Floor Event Element (element ID : 37). De-Authentication Event: Configure whether the AC is interested in receiving a notification whenever a station has been de- authenticated by the WTP. The WTP may notify the AC with the MAC address of the STA along with a reason code (inactivity, etc.). Association Event: Needed in Local MAC architecture. Disassociation Event: Needed in Local MAC architecture.


(page 60 continued on part 3)

Next Section