Independent Submission                                     P. Narasimhan
Request for Comments: 5413                                    D. Harkins
Category: Historic                                         S. Ponnuswamy
ISSN: 2070-1721                                           Aruba Networks
                                                          February 2010


              SLAPP: Secure Light Access Point Protocol

Abstract

  The Control and Provisioning of Wireless Access Points (CAPWAP)
  problem statement describes a problem that needs to be addressed
  before a wireless LAN (WLAN) network designer can construct a
  solution composed of Wireless Termination Points (WTP) and Access
  Controllers (AC) from multiple, different vendors.  One of the
  primary goals is to find a solution that solves the interoperability
  between the two classes of devices (WTPs and ACs) that then enables
  an AC from one vendor to control and manage a WTP from another.

  In this document, we present a protocol that forms the common
  technology-independent framework and the ability to negotiate and
  add, on top of this framework, a control protocol that contains a
  technology-dependent component to arrive at a complete solution.  We
  have also presented two such control protocols -- an 802.11 Control
  protocol, and another, more generic image download protocol, in this
  document.

  Even though the text in this document is written to specifically
  address the problem stated in RFC 3990, the solution can be applied
  to any problem that has a controller (equivalent to the AC) managing
  one or more network elements (equivalent to the WTP).

Status of This Memo

  This document is not an Internet Standards Track specification; it is
  published for the historical record.

  This document defines a Historic Document for the Internet community.
  This is a contribution to the RFC Series, independently of any other
  RFC stream.  The RFC Editor has chosen to publish this document at
  its discretion and makes no statement about its value for
  implementation or deployment.  Documents approved for publication by
  the RFC Editor are not a candidate for any level of Internet
  Standard; see Section 2 of RFC 5741.






Narasimhan, et al.              Historic                        [Page 1]

RFC 5413                          SLAPP                    February 2010


  Information about the current status of this document, any errata,
  and how to provide feedback on it may be obtained at
  http://www.rfc-editor.org/info/rfc5413.

IESG Note

  This RFC documents the SLAPP protocol as it was when submitted to the
  IETF as a basis for further work in the CAPWAP Working Group, and
  therefore it may resemble the CAPWAP protocol specification in RFC
  5415 as well as other IETF work.  This RFC is being published solely
  for the historical record.  The protocol described in this RFC has
  not been thoroughly reviewed and may contain errors and omissions.

  RFC 5415 documents the standards track solution for the CAPWAP
  Working Group and obsoletes any and all mechanisms defined in this
  RFC.  This RFC is not a candidate for any level of Internet Standard
  and should not be used as a basis for any sort of Internet
  deployment.

Copyright Notice

  Copyright (c) 2010 IETF Trust and the persons identified as the
  document authors.  All rights reserved.

  This document is subject to BCP 78 and the IETF Trust's Legal
  Provisions Relating to IETF Documents
  (http//:trustee.ietf.org/license-info) in effect on the date of
  publication of this document.  Please review these documents
  carefully, as they describe your rights and restrictions with respect
  to this document.





















Narasimhan, et al.              Historic                        [Page 2]

RFC 5413                          SLAPP                    February 2010


Table of Contents

  1. Introduction ....................................................4
  2. Definitions .....................................................7
     2.1. Conventions Used in This Document ..........................7
  3. Topology ........................................................7
  4. Protocol ........................................................8
     4.1. Protocol Description .......................................8
          4.1.1. State Machine Explanation ...........................9
     4.2. Format of a SLAPP Header ..................................10
     4.3. Version ...................................................11
     4.4. Retransmission ............................................12
     4.5. Discovery .................................................12
          4.5.1. SLAPP Discover Request .............................13
          4.5.2. SLAPP Discover Response ............................15
     4.6. SLAPP Discovery Process ...................................17
          4.6.1. WTP ................................................17
          4.6.2. AC .................................................19
  5. Security Association ...........................................19
     5.1. Example Authentication Models (Informative) ...............20
          5.1.1. Mutual Authentication ..............................20
          5.1.2. WTP-Only Authentication ............................21
          5.1.3. Anonymous Authentication ...........................21
  6. SLAPP Control Protocols ........................................21
     6.1. 802.11 Control Protocol for SLAPP .........................21
          6.1.1. Supported CAPWAP Architectures .....................21
          6.1.2. Transport ..........................................24
          6.1.3. Provisioning and Configuration of WTP ..............26
          6.1.4. Protocol Operation .................................60
     6.2. Image Download Protocol ...................................66
          6.2.1. Image Download Packet ..............................66
          6.2.2. Image Download Request .............................67
          6.2.3. Image Download Process .............................68
          6.2.4. Image Download State Machine .......................69
  7. Security Considerations ........................................73
  8. Extensibility to Other Technologies ............................73
  9. Informative References .........................................74














Narasimhan, et al.              Historic                        [Page 3]

RFC 5413                          SLAPP                    February 2010


1.  Introduction

  The need for a protocol by which wireless LAN (WLAN) Access
  Controllers (ACs) can control and manage Wireless Termination Points
  (WTPs) from a different vendor has been presented in the CAPWAP
  problem statement [3].  We believe that this problem is more general
  than as stated in [3] and can be found in any application, including
  non-wireless ones, that requires a central controller to control and
  manage one or more network elements from a different vendor.

  One way to solve the CAPWAP problem is to define a complete control
  protocol that enables an AC from one vendor to control and manage a
  WTP from a different vendor.  But a solution that is primarily
  focused towards solving the problem for one particular underlying
  technology (IEEE 802.11, in this case) may find it difficult to
  address other underlying technologies.  Different underlying
  technologies may differ on the set of configurable options, and
  different architectural choices that are specific to that underlying
  technology (similar to the Local Medium Access Control (MAC) versus
  Split MAC architectures in 802.11).  The architectural choices that
  are good for one underlying technology may not necessarily work for
  another.  Not to forget that there may be multiple architectural
  choices [2] even for the same underlying technology.  A monolithic
  control protocol that strives to solve this problem for multiple
  technologies runs the risk of adding too much complexity and not
  realizing the desired goals, or it runs the risk of being too rigid
  and hampering technological innovation.

  A different way to solve this problem is to split the solution space
  into two components -- one that is technology-agnostic or
  independent, and another that is specific to the underlying
  technology or even different approaches to the same underlying
  technology.  The technology-independent component would be a common
  framework that would be an important component of the solution to
  this class of problems without any dependency on the underlying
  technology (i.e., 802.11, 802.16, etc.) being used.  The technology-
  specific component would be a control protocol that would be
  negotiated using this common framework and can be easily defined to
  be relevant to that technology without the need for having any
  dependency on other underlying technologies.  This approach also
  lends itself easily to extend the solution as new technologies arise
  or as new innovative methods to solve the same problem for an
  existing technology present themselves in the future.

  In this document, we present secure light access point protocol
  (SLAPP), a technology-independent protocol by which network elements
  that are meant to be centrally managed by a controller can discover
  one or more controllers, perform a security association with one of



Narasimhan, et al.              Historic                        [Page 4]

RFC 5413                          SLAPP                    February 2010


  them, and negotiate a control protocol that they would use to perform
  the technology-specific components of the control and provisioning
  protocol.  We have also presented two control protocols in this
  document -- an 802.11 control protocol for provisioning and managing
  a set of 802.11 WTPs, and an image download protocol that is very
  generic and can be applied to any underlying technology.

  Figure 1 shows the model by which a technology-specific control
  protocol can be negotiated using SLAPP to complete a solution for a
  certain underlying technology.  The figure shows a control protocol
  for 802.11 and 802.16 technology components, but the SLAPP model does
  not preclude multiple control protocols within a certain technology
  segment.  For example, a certain technology-specific control protocol
  may choose to support only the Local MAC architecture [2] while
  deciding not to support the Split MAC architecture [2].  While the
  image download protocol is presented in this document, a SLAPP
  implementation MUST NOT assume that this control protocol is
  supported by other SLAPP implementations.

































Narasimhan, et al.              Historic                        [Page 5]

RFC 5413                          SLAPP                    February 2010


                                             Negotiated
           SLAPP                             Control
                                             Protocol

  +-------------------------+              +------------+
  |                         |              |            |
  |         SLAPP           |              |  Image     |
  | (technology-independent +-------+----->|  Download  |
  |      framework)         |       |      |  protocol  |
  |                         |       |      |            |
  |  negotiate one control  |       |      +------------+
  |  protocol here          |       |
  +-------------------------+       |
                                    |      +------------+
                                    |      |            |
                                    |      |   802.11   |
                                    +----->|  control   |
                                    |      |  protocol  |
                                    |      |            |
                                    |      +------------+
                                    |
                                    |
                                    |      +------------+
                                    |      |            |
                                    |      |   802.16   |
                                    +----->|  control   |
                                    |      |  protocol  |
                                    |      |            |
                                    |      +------------+
                                    |
                                    |         .......

                     Figure 1: SLAPP Protocol Model

  The control protocols that are negotiable using SLAPP are expected to
  be published ones that have gone through a review process in
  standards bodies such as the IETF.  The control protocols can either
  re-use the security association created during SLAPP or have the
  option of clearing all SLAPP state and restarting with whatever
  mechanisms are defined in the control protocol.

  Recently, there was a significant amount of interest in a similar
  problem in the Radio Frequency Identification (RFID) space that has
  led to the definition of a simple lightweight RFID reader protocol
  (SLRRP) [9].  It is quite possible that SLRRP could be a
  technology-specific (RFID, in this case) control protocol negotiated
  during a common technology-independent framework.




Narasimhan, et al.              Historic                        [Page 6]

RFC 5413                          SLAPP                    February 2010


  All of the text in the document would seem to be written with a WLAN
  problem in mind.  Please note that while the letter of the document
  does position the solution to solve a CAPWAP-specific problem, the
  spirit of the document is to address the more general problem.

2.  Definitions

2.1.  Conventions Used in This Document

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

3.  Topology

  The SLAPP protocol supports multiple topologies for interconnecting
  WTPs and ACs as indicated in Figure 2.

  In Figure 2, we have captured four different interconnection
  topologies:

  1.  The WTP is directly connected to the AC without any intermediate
      nodes.  Many WTPs are deployed in the plenum of buildings and are
      required to be powered over the Ethernet cable that is connecting
      it to the network.  Many ACs in the marketplace can supply power
      over Ethernet, and in the case where the AC is the one powering
      the WTP, the WTP is directly connected to the AC.

  2.  The WTP is not directly connected to the AC, but both the AC and
      the WTP are in the same Layer 2 (L2) (broadcast) domain.

  3.  The WTP is not directly connected to the AC, and they are not
      present in the same L2 (broadcast) domain.  They are on two
      different broadcast domains and have a node on the path that
      routes between two or more subnets.

  4.  The fourth case is a subset of the third one with the exception
      that the intermediate nodes on the path from the WTP to the AC
      may not necessarily be in the same administrative domain.  The
      intermediate network may also span one or more WAN links that may
      have lower capacity than if both the AC and the WTP are within
      the same building or campus.









Narasimhan, et al.              Historic                        [Page 7]

RFC 5413                          SLAPP                    February 2010


              +-----------------+            +-------+
              |                 |    (1)     |       |
              |       AC        +------------+  WTP  |
              |                 |            |       |
              +--------+--------+            +-------+
                       |
                       |
                       |
                   +---+---+
              (2)  |       |
            +------+  L2   +--------+
            |      |       |        |
            |      +---+---+        |
            |                       |
            |                       |
      +-----+-----+             +---+---+    +-------+
      |           |             |       | (3)|       |
      |    WTP    |             |   L3  +----+  WTP  |
      |           |             |       |    |       |
      +-----------+             +---+---+    +-------+
                                    |
                                    |
                                    |
                                +---+----+    +-------+
                                |        | (4)|       |
                                |Internet+----+  WTP  |
                                |        |    |       |
                                +--------+    +-------+

                          Figure 2: SLAPP Topology

4.  Protocol

4.1.  Protocol Description

  The SLAPP state machine for both the WTP and AC is shown in Figure 3.
  Both the WTP and the AC discover each other, negotiate a control
  protocol, perform a secure handshake to establish a secure channel
  between them, and then use that secure channel to protect a
  Negotiated Control Protocol.

  The WTP maintains the following variable for its state machine:

  abandon: a timer that sets the maximum amount of time the WTP will
     wait for an acquired AC to begin the Datagram Transport Layer
     Security (DTLS) handshake.





Narasimhan, et al.              Historic                        [Page 8]

RFC 5413                          SLAPP                    February 2010


     /--------\  /-----------\
     |        |  |           |
     |        v  v           |
     |  +-------------+      |
     | C| discovering |<-\   |
     |  +-------------+  |   |
     |        |          |   |
     |        v          |   |
     |  +-----------+    |   |
     \--| acquiring |    |   |
        +-----------+    |   |
              |          |   |
              v          |   |
        +----------+     |   |
       C| securing |-----/   |
        +----------+         |
              |              |
              v              |
      +----------------+     |
      |  negotiated    |     |
     C|    control     |-----/
      |   protocol     |
      +----------------+

                       Figure 3: SLAPP State Machine

4.1.1.  State Machine Explanation

  Note: The symbol "C" indicates an event that results in the state
  remaining the same.

  Discovering

     AC: This is a quiescent state for the AC in which it waits for
         WTPs to request its acquisition.  When a request is received,
         the AC transitions to Acquiring.

    WTP: The WTP is actively discovering an AC.  When the WTP receives
         a response to its Discover Request, it transitions to
         Acquiring.

  Acquiring

     AC: A discover request from a WTP has been received.  If the
         request is invalid or the AC wishes to not acquire the WTP, it
         drops the packet and transitions back to Discovering.
         Otherwise, a Discover Response is sent and the AC transitions
         to Securing.



Narasimhan, et al.              Historic                        [Page 9]

RFC 5413                          SLAPP                    February 2010


    WTP: A discover response from an AC has been received.  If the
         response is not valid, the WTP transitions to Discovering;
         otherwise, it sets the abandon timer to a suitable value to
         await a DTLS exchange.  If the timer fires in Acquiring, the
         WTP transitions back to Discovering.  If a DTLS "client hello"
         is received, the WTP transitions to Securing and cancels the
         abandon timer.

  Securing

     AC: The AC performs the "client end" of the DTLS exchange.  Any
         error in the DTLS exchange results in the AC transitioning to
         Discovering.  When the DTLS exchange finishes, the AC
         transitions to the Negotiated Control Protocol.

    WTP: The WTP performs the "server end" of the DTLS exchange.  Any
         error in the DTLS exchange results in the WTP transitioning to
         Discovering.  When the DTLS exchange finishes, the WTP
         transitions to the Negotiated Control Protocol.

  Negotiated Control Protocol

     AC: The AC performs its side of the protocol agreed to during the
         discovery process.  Please refer to Section 6.1 for the SLAPP
         802.11 Control Protocol.  For the Image Download Protocol
         example, see Section 6.2.

    WTP: The WTP performs its side of the protocol agreed to during the
         discovery process.  Please refer to Section 6.1 for the SLAPP
         802.11 Control Protocol.  For the Image Download Protocol
         example, see Section 6.2.

4.2.  Format of a SLAPP Header

  All SLAPP packets begin with the same header as shown in Figure 4.

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

                         Figure 4: SLAPP Header

  Where:

     Maj (4 bits): the major number of the SLAPP version




Narasimhan, et al.              Historic                       [Page 10]

RFC 5413                          SLAPP                    February 2010


     Min (4 bits): the minor number of the SLAPP version

     Type (1 octet): the type of SLAPP message

     Length (two octets): the length of the SLAPP message, including
     the entire SLAPP header

  The following types of SLAPP messages have been defined:

     name                     type
     -----                   ------
     discover request           1
     discover response          2
     image download control     3
     control protocol packet    4
     reserved                  5-255

4.3.  Version

  SLAPP messages include a version in the form of major.minor.  This
  document describes the 1.0 version of SLAPP, that is the major
  version is one (1) and the minor version is zero (0).

  Major versions are incremented when the format of a SLAPP message
  changes or the meaning of a SLAPP message changes such that it would
  not be properly parsed by an older, existing version of SLAPP.  Minor
  versions are incremented when some incremental additions have been
  made to SLAPP that enhance its capabilities or convey additional
  information in a way that does not change the format or meaning of
  the SLAPP message.

  Future versions of SLAPP MAY NOT mandate support for earlier major
  versions of SLAPP, so an implementation MUST NOT assume that a peer
  that supports version "n" will therefore support version "n - i"
  (where both "n" and "i" are non-zero integers and "n" is greater than
  "i").

  A SLAPP implementation that receives a SLAPP message with a higher
  major version number MUST drop that message.  A SLAPP implementation
  that receives a SLAPP message with a lower major version SHOULD drop
  down to the version of SLAPP the peer supports.  If that version of
  SLAPP is not supported, the message MUST be dropped.  However, there
  may be valid reasons for which a peer wishes to drop a SLAPP message
  with a supported major version.

  A SLAPP implementation that receives a SLAPP message with a higher
  minor version number MUST NOT drop that message.  It MUST respond
  with the minor version number that it supports and will necessarily



Narasimhan, et al.              Historic                       [Page 11]

RFC 5413                          SLAPP                    February 2010


  not support whatever incremental capabilities were added that
  justified the bump in the minor version.  A SLAPP implementation that
  receives a SLAPP message with a lower minor version MUST NOT drop
  that message.  It SHOULD revert back to the minor version that the
  peer supports and not include any incremental capabilities that were
  added that justified the bump in the minor version.

4.4.  Retransmission

  SLAPP is a request response protocol.  Discovery and security
  handshake requests are made by the WTP, and responses to them are
  made by the AC.  Image Download packets are initiated by the AC and
  acknowledged by the WTP (in a negative fashion, see Section 6.2).

  Retransmissions are handled solely by the initiator of the packet.
  After each packet for which a response is required is transmitted,
  the sender MUST set a retransmission timer and resend the packet upon
  its expiry.  The receiver MUST be capable of either regenerating a
  previous response upon receipt of a retransmitted packet or caching a
  previous response and resending upon receipt of a retransmitted
  packet.

  The retransmission timer MUST be configurable and default to one (1)
  second.  No maximum or minimum for the timer is specified by this
  version of SLAPP.

  Each time a retransmission is made, a counter SHOULD be incremented,
  and the number of retransmissions attempted by a sender before giving
  up and declaring a SLAPP failure SHOULD be four (4)-- that is, the
  number of attempts made for each packet before declaring failure is
  five (5).

  The exception to this rule is Image Download packets, which are not
  individually acknowledged by the WTP (see Section 6.2).  The final
  packet is acknowledged and lost packets are indicated through Image
  Download Requests.

4.5.  Discovery

  When a WTP boots up and wants to interoperate with an Access
  Controller so that it can be configured by the AC, one of the first
  things it needs to do is to discover one or more ACs in its network
  neighborhood.  This section contains the details of this discovery
  mechanism.

  As described in Section 3, an AC and a WTP could reside in the same
  Layer 2 domain, or be separated by a Layer 3 cloud including
  intermediate clouds that are not under the same administrative domain



Narasimhan, et al.              Historic                       [Page 12]

RFC 5413                          SLAPP                    February 2010


  (for example, an AC and a WTP separated by a wide-area public
  network).  So any proposed discovery mechanism should have provisions
  to enable a WTP to discover an AC across all these topologies.

  We assume that a WTP, prior to starting the discovery process, has
  already obtained an IP address on its wired segment.

4.5.1.  SLAPP Discover Request

  The SLAPP discovery process is initiated by sending a SLAPP discover
  request packet.  The packet can be addressed to the broadcast IP
  address, a well-known multicast address, or (if the IP address of an
  AC is either configured prior to the WTP booting up or is learned
  during the boot-up sequence) addressed to a unicast IP address.  Lack
  of a response to one method of discovery SHOULD result in the WTP
  trying another method of discovery.  The SLAPP discover request
  packet is a UDP packet addressed to port [TBD] designated as the
  SLAPP discovery port.  The source port can be any random port.  The
  payload of the SLAPP discover request packet is shown in Figure 5.

   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  |    Type = 1   |           Length              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                         Transaction ID                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                         WTP Identifier                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |    WTP Identifier (continued) |             Flags             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                      WTP Vendor ID                            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                      WTP HW Version                           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                      WTP SW Version                           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | n controltypes| control type  |  .  .  .
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 5: SLAPP Discover Request

4.5.1.1.  Transaction ID

  The transaction ID is a randomly generated, 32-bit number that is
  maintained during one phase of the SLAPP discovery process.  It is
  generated by a WTP starting a discovery process.  When one discovery
  method fails to find an AC and the WTP attempts another discovery



Narasimhan, et al.              Historic                       [Page 13]

RFC 5413                          SLAPP                    February 2010


  method it MUST NOT re-use the Transaction ID.  All ACs that intend to
  respond to a SLAPP discover request must use the same value for this
  field as in the request frame.

4.5.1.2.  WTP Identifier

  This field allows the WTP to specify a unique identifier for itself.
  This MAY be, for instance, its 48-bit MAC address or it could be any
  other string such as a serial number.

4.5.1.3.  Flags

  The Flags field is used to indicate certain things about the discover
  request.  For example, bit 0 in the Flags field indicates whether the
  discover request packet is being sent to the AC, if unicast, based on
  a configuration at the WTP or based on some other means of discovery.
  This bit should always be set to the discover mode if the SLAPP
  discover request packet is being sent to either a broadcast or
  multicast address.  Here are the valid values for various bits in the
  Flags field.

     Bit 0:
     0 - Configuration mode
     1 - Discover mode

     Bits 1-15:
     Must always be set to 0 by the transmitter
     Must be ignored by the receiver

4.5.1.4.  WTP Vendor ID

  This 32-bit field is the WTP vendor's Structure of Management
  Information (SMI) enterprise code in network octet order (these
  enterprise codes can be obtained from, and registered with, IANA).

4.5.1.5.  WTP HW Version

  This 32-bit field indicates the version of hardware present in the
  WTP.  This is a number that is totally left to the WTP vendor to
  choose.

4.5.1.6.  WTP SW Version

  This 32-bit field indicates the version of software present in the
  WTP.  This is a number that is totally left to the WTP vendor to
  choose.





Narasimhan, et al.              Historic                       [Page 14]

RFC 5413                          SLAPP                    February 2010


4.5.1.7.  Number of Control Types

  This 8-bit field indicates the number of 8-bit control protocol
  indicators that follow it and therefore implicitly indicates the
  number of different control protocols the WTP is capable of
  supporting.  This number MUST be at least one (1).

4.5.1.8.  Control Types

  This 8-bit field indicates the type of control protocol the WTP
  supports and is willing to use when communicating with an AC.  There
  MAY be multiple "control type" indicators in a single SLAPP Discover
  Request.

     Valid Control Types
     -------------------
     0      - RESERVED (MUST not be used)
     1      - Image Download Control Protocol
     2      - 802.11 SLAPP Control Protocol
     3-255  - RESERVED (to IANA)

4.5.2.  SLAPP Discover Response

  An AC that receives a SLAPP discover request packet from a WTP can
  choose to respond with a SLAPP discover response packet.  The format
  of the SLAPP discover response packet is shown in Figure 6.

   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  |    Type = 2   |           Length              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                         Transaction ID                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                        WTP Identifier                         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |    WTP Identifier (continued) |             Flags             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                      AC HW Vendor ID                          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                       AC HW Version                           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                       AC SW Version                           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | control type  |
  +-+-+-+-+-+-+-+-+

                    Figure 6: SLAPP Discover Response



Narasimhan, et al.              Historic                       [Page 15]

RFC 5413                          SLAPP                    February 2010


  The SLAPP discover response packet is a UDP packet.  It is always
  unicast to the WTP's IP address.  The source IP address is that of
  the AC sending the response.  The source port is the SLAPP discover
  port [TBD] and the destination port is the same as the source port
  used in the SLAPP discover request.  The WTP's MAC address and the
  transaction ID must be identical to the values contained in the SLAPP
  discover request.  The Status field indicates to the WTP whether the
  AC is either accepting the discover request and is willing to allow
  the WTP to proceed to the next stage (ACK) or whether it is denying
  the WTP's earlier request (NACK).  The AC includes its own vendor ID,
  hardware, and software versions in the response.

4.5.2.1.  Transaction ID

  The value of the Transaction ID field should be identical to its
  value in the SLAPP discover request packet sent by the WTP.

4.5.2.2.  WTP Identifier

  The WTP Identifier that was sent in the corresponding SLAPP discover
  request frame.

4.5.2.3.  Flags

  This field is unused by this version of SLAPP.  It MUST be set to
  zero (0) on transmission and ignored upon receipt.

4.5.2.4.  AC Vendor ID

  If the value of the Status field is a 1, indicating that the AC is
  sending a successful response, then the values in this field and the
  following two are valid.  The 32-bit AC Vendor ID points to the
  vendor ID of the AC.  If the value of the Status field is not 1, then
  this field should be set to 0 by the AC and ignored by the WTP.

4.5.2.5.  AC HW Version

  If the value of the Status field is 1, then this 32-bit field
  contains the value of the AC's hardware version.  This value is
  chosen by the AC vendor.  If the value of the Status field is not 1,
  then this field should be set to 0 by the AC and ignored by the WTP.

4.5.2.6.  AC SW Version

  If the value of the Status field is 1, then this 32-bit field
  contains the value of the AC's software version.  This value is
  chosen by the AC vendor.  If the value of the Status field is not 1,
  then this field should be set to 0 by the AC and ignored by the WTP.



Narasimhan, et al.              Historic                       [Page 16]

RFC 5413                          SLAPP                    February 2010


4.5.2.7.  Control Type

  The control type that the AC will use to communicate with the WTP.
  This value MUST match one of the control types passed in the
  corresponding SLAPP Discover Request.

4.6.  SLAPP Discovery Process

4.6.1.  WTP

  There are multiple ways in which a WTP can discover an AC.

  1.  Static configuration: An administrator, prior to deploying a WTP,
      can configure an IP address of an AC on the WTP's non-volatile
      memory.  If this is the case, then the SLAPP discover request
      packet is addressed to the configured IP address.

  2.  DHCP options: As part of the DHCP response, the DHCP server could
      be configured to use option 43 to deliver the IP address of an AC
      to which the WTP should address the SLAPP discover request
      packet.  If the IP address of an AC is handed to the WTP as part
      of the DHCP response, then the WTP should address the SLAPP
      discover request packet to this IP address.

  3.  DNS configuration: Instead of configuring a static IP address on
      the WTP's non-volatile memory, an administrator can configure a
      Fully-Qualified Domain Name (FQDN) of an AC.  If the FQDN of an
      AC is configured, then the WTP queries its configured DNS server
      for the IP address associated with the configured FQDN of the AC.
      If the DNS query is successful and the WTP acquires the IP
      address of an AC from the DNS server, then the above discover
      request packet is addressed to the unicast address of the AC.

  4.  Broadcast: The WTP sends a discover request packet addressed to
      the broadcast IP address with the WTP's IP address as the source.
      A network administrator, if necessary, could configure the
      default router for the subnet that the WTP is on with a helper
      address and unicast it to any address on a different subnet.

  5.  IP Multicast: A WTP can send the above payload to a SLAPP IP
      multicast address [TBD].

  6.  DNS: If there is no DNS FQDN configured on the WTP, and the WTP
      is unable to discover an AC by any of the above methods, then it
      should attempt to query the DNS server for a well-known FQDN of
      an AC [TBD].  If this DNS query succeeds, then the WTP should
      address the SLAPP discover request packet to the unicast address
      of the AC.



Narasimhan, et al.              Historic                       [Page 17]

RFC 5413                          SLAPP                    February 2010


  The above process is summarized in the sequence shown in Figure 7.

  SLAPP discovery start:
     Static IP address config option:
       Is a static IP address for an AC configured?
         If yes, send SLAPP discover request to that unicast IP address
           SLAPP discover response within discovery_timer?
             If yes, go to "done"
             If not, go to "Static FQDN config option"
         If not, go to "Static FQDN config option"
     Static FQDN config option:
       Is a static FQDN configured?
         If yes, send a DNS query for the IP address for the FQDN.
         Is DNS query successful?
           If yes, send SLAPP discover request to that IP address
           SLAPP discover response within discovery timer?
             If yes, go to "done"
             If not, go to "DHCP options option"
           If not, go to "DHCP options option"
      DHCP options option:
        Is the IP address of an AC present in the DHCP response?
          If yes, send SLAPP discover request to the AC's IP address
          SLAPP discover response within discovery timer?
            If yes, go to "done"
            If not, go to "Broadcast option"
          If not, go to "Broadcast option"
      Broadcast option:
        Send SLAPP discover packet to the broadcast address
        SLAPP discover response within discovery timer?
          If yes, go to "done"
          If not, go to "Multicast option"
      Multicast option:
        Send SLAPP discover packet to the SLAPP multicast address
        SLAPP discover response within discovery timer?
          If yes, go to "done"
          If not, go to "DNS discovery option"
      DNS discovery option:
        Query the DNS server for a well-known DNS name
        Is the DNS discovery successful?
          If yes, send SLAPP discover request to that IP address
          SLAPP discover response within discovery timer?
            If yes, go to "done"
            If not, go to "SLAPP discovery restart"
          If not, go to "SLAPP discovery restart"







Narasimhan, et al.              Historic                       [Page 18]

RFC 5413                          SLAPP                    February 2010


      SLAPP discovery restart:
        Set timer for SLAPP discovery idle timer
        When timer expires, go to "SLAPP discovery start"
      done:
        Go to the next step

                                Figure 7

4.6.2.  AC

  When an AC receives a SLAPP discover request, it must determine
  whether or not it wishes to acquire the WTP.  An AC MAY only agree to
  acquire those WTPs whose WTP Identifiers are statically configured in
  its configuration.  Or an AC that is willing to gratuitously acquire
  WTPs MAY accept any request pending authentication.  An AC MUST only
  choose to acquire WTPs that speak a common Negotiated Control
  Protocol, but other factors may influence its decision.  For
  instance, if the Negotiated Control Protocol is the Image Download
  protocol defined in this memo, the AC MUST NOT acquire a WTP for
  which it does not have a compatible image to download as determined
  by the WTP's HW Vendor ID, HW Version, and Software Version.
  Whatever its decision, the AC MUST respond one of two ways.

  1.  The AC sends a SLAPP discover response indicating its agreement
      to acquire the WTP.

  2.  The AC silently drops the SLAPP discover request and does not
      respond at all.

5.  Security Association

  Once an AC has been discovered by a WTP and agreed to acquire it (by
  sending a Discover Response), it will initiate a DTLS [6] [8]
  exchange with the WTP by assuming the role of the "client".  The WTP
  assumes the role of the "server".  The port used by both the WTP and
  AC for this exchange will be [TBD].

  An obvious question is "Why is the AC acting as a client?".  The
  reason is to allow for non-mutual authentication in which the WTP is
  authenticated by the AC (see Section 5.1.2).

  Informational note: DTLS is used because it provides a secure and
  connectionless channel using a widely accepted and analyzed protocol.
  In addition, the myriad of authentication options in DTLS allows for
  a wide array of options with which to secure the channel between the
  WTP and the AC -- mutual and certificate-based; asymmetric or non-
  mutual authentication; anonymous authentication, etc.  Furthermore,
  DTLS defines its own fragmentation and reassembly techniques as well



Narasimhan, et al.              Historic                       [Page 19]

RFC 5413                          SLAPP                    February 2010


  as ways in which peers agree on an effective MTU.  Using DTLS
  obviates the need to redefine these aspects of a protocol and
  therefore lessens code bloat as the same problem doesn't need to be
  solved yet again in another place.

  Failure of the DTLS handshake protocol will cause both parties to
  abandon the exchange.  The AC SHOULD blacklist this WTP for a period
  of time to prevent a misconfigured WTP from repeatedly discovering
  and failing authentication.  The WTP MUST return to the discovery
  state of SLAPP to locate another suitable AC with which it will
  initiate a DTLS exchange.

  Once the DTLS handshake has succeeded, the WTP and AP transition into
  "image download state" and protect all further SLAPP messages with
  the DTLS-negotiated cipher suite.

5.1.  Example Authentication Models (Informative)

  Any valid cipher suite in [7] can be used to authenticate the WTP
  and/or the AC.  Different scenarios require different authentication
  models.  The following examples are illustrative only and not meant
  to be exhaustive.

  Since neither side typically involves a human being, a username/
  password-based authentication is not possible.

  Zero-config requirements on certain WTP deployments can predicate
  certain authentication options and eliminate others.

5.1.1.  Mutual Authentication

  When mutually authenticating, the WTP authenticates the AC, thereby
  ensuring that the AC to which it is connecting is a trusted AC, and
  the AC authenticates the WTP, thereby ensuring that the WTP that is
  connecting is a trusted WTP.

  Mutual authentication is typically achieved by using certificates on
  the WTP and AC, which ensure public keys each party owns.  These
  certificates are digitally signed by a Certification Authority, a
  trusted third party.

  Enrolling each WTP in a Certification Authority is outside the scope
  of this document, but it should be noted that a manufacturing
  Certification Authority does not necessarily provide the level of
  assurance necessary as it will only guarantee that a WTP or AC was
  manufactured by a particular company and cannot distinguish between a
  trusted WTP and a WTP that is not trusted but was purchased from the
  same manufacturer as the AC.



Narasimhan, et al.              Historic                       [Page 20]

RFC 5413                          SLAPP                    February 2010


5.1.2.  WTP-Only Authentication

  Some deployments may only require the WTP to authenticate to the AC
  and not the other way around.

  In this case, the WTP has a keypair that can uniquely identify it
  (for example, using a certificate) and, that keypair is used in a
  "server-side authentication" [7] exchange.

  This authentication model does not authenticate the AC and a rogue AC
  could assert control of a valid WTP.  It should be noted, though,
  that this will only allow the WTP to provide service for networks
  made available by the rogue AC.  No unauthorized network access is
  possible.

5.1.3.  Anonymous Authentication

  In some deployments, it MAY just be necessary to foil the casual
  snooping of packets.  In this case, an unauthenticated, but
  encrypted, connection can suffice.  Typically a Diffie-Hellman
  exchange is performed between the AC and WTP and the resulting
  unauthenticated key is used to encrypt traffic between the AC and
  WTP.

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:





Narasimhan, et al.              Historic                       [Page 21]

RFC 5413                          SLAPP                    February 2010


  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.









Narasimhan, et al.              Historic                       [Page 22]

RFC 5413                          SLAPP                    February 2010


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




Narasimhan, et al.              Historic                       [Page 23]

RFC 5413                          SLAPP                    February 2010


  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.








Narasimhan, et al.              Historic                       [Page 24]

RFC 5413                          SLAPP                    February 2010


  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



Narasimhan, et al.              Historic                       [Page 25]

RFC 5413                          SLAPP                    February 2010


     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.






Narasimhan, et al.              Historic                       [Page 26]

RFC 5413                          SLAPP                    February 2010


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



Narasimhan, et al.              Historic                       [Page 27]

RFC 5413                          SLAPP                    February 2010


     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.



Narasimhan, et al.              Historic                       [Page 28]

RFC 5413                          SLAPP                    February 2010


     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.



Narasimhan, et al.              Historic                       [Page 29]

RFC 5413                          SLAPP                    February 2010


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







Narasimhan, et al.              Historic                       [Page 30]

RFC 5413                          SLAPP                    February 2010


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.




Narasimhan, et al.              Historic                       [Page 31]

RFC 5413                          SLAPP                    February 2010


     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.




Narasimhan, et al.              Historic                       [Page 32]

RFC 5413                          SLAPP                    February 2010


     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.




Narasimhan, et al.              Historic                       [Page 33]

RFC 5413                          SLAPP                    February 2010


        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



Narasimhan, et al.              Historic                       [Page 34]

RFC 5413                          SLAPP                    February 2010


        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.







Narasimhan, et al.              Historic                       [Page 35]

RFC 5413                          SLAPP                    February 2010


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.



Narasimhan, et al.              Historic                       [Page 36]

RFC 5413                          SLAPP                    February 2010


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.



Narasimhan, et al.              Historic                       [Page 37]

RFC 5413                          SLAPP                    February 2010


        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



Narasimhan, et al.              Historic                       [Page 38]

RFC 5413                          SLAPP                    February 2010


        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




Narasimhan, et al.              Historic                       [Page 39]

RFC 5413                          SLAPP                    February 2010


     *  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



Narasimhan, et al.              Historic                       [Page 40]

RFC 5413                          SLAPP                    February 2010


     *  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



Narasimhan, et al.              Historic                       [Page 41]

RFC 5413                          SLAPP                    February 2010


     *  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





Narasimhan, et al.              Historic                       [Page 42]

RFC 5413                          SLAPP                    February 2010


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





Narasimhan, et al.              Historic                       [Page 43]

RFC 5413                          SLAPP                    February 2010


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




Narasimhan, et al.              Historic                       [Page 44]

RFC 5413                          SLAPP                    February 2010


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.













Narasimhan, et al.              Historic                       [Page 45]

RFC 5413                          SLAPP                    February 2010


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





Narasimhan, et al.              Historic                       [Page 46]

RFC 5413                          SLAPP                    February 2010


  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:



Narasimhan, et al.              Historic                       [Page 47]

RFC 5413                          SLAPP                    February 2010


           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




Narasimhan, et al.              Historic                       [Page 48]

RFC 5413                          SLAPP                    February 2010


        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.





















Narasimhan, et al.              Historic                       [Page 49]

RFC 5413                          SLAPP                    February 2010


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:



Narasimhan, et al.              Historic                       [Page 50]

RFC 5413                          SLAPP                    February 2010


        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





Narasimhan, et al.              Historic                       [Page 51]

RFC 5413                          SLAPP                    February 2010


  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:



Narasimhan, et al.              Historic                       [Page 52]

RFC 5413                          SLAPP                    February 2010


     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:



Narasimhan, et al.              Historic                       [Page 53]

RFC 5413                          SLAPP                    February 2010


     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.















Narasimhan, et al.              Historic                       [Page 54]

RFC 5413                          SLAPP                    February 2010


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



Narasimhan, et al.              Historic                       [Page 55]

RFC 5413                          SLAPP                    February 2010


  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.

























Narasimhan, et al.              Historic                       [Page 56]

RFC 5413                          SLAPP                    February 2010


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




Narasimhan, et al.              Historic                       [Page 57]

RFC 5413                          SLAPP                    February 2010


  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
























Narasimhan, et al.              Historic                       [Page 58]

RFC 5413                          SLAPP                    February 2010


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.







Narasimhan, et al.              Historic                       [Page 59]

RFC 5413                          SLAPP                    February 2010


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.

6.1.4.  Protocol Operation

  The SLAPP 802.11 Control Protocol operation is described in this
  section.



Narasimhan, et al.              Historic                       [Page 60]

RFC 5413                          SLAPP                    February 2010


6.1.4.1.  SLAPP 802.11 Control Protocol State Machine

6.1.4.1.1.  At the WTP

      +-------------+
      | discovering |<-------------------------------+<----+
      +-------------+                                |     |
        ^  ^                                         |     |
        |  |          +-----------+                  |     |
        |  |          | securing  |                  |     |
        |  |          +----+------+                  |     |
        |  |               |                         |     |
        |  |               v                         |     |
        |  |        +--------------+                 |     |
        |  |   +--->| Unregistered |                 |     |
        |  |   |    +------+-------+                 |     |
        |  |   |           |                         |     |
        |  |   |           |Registration             |     |
        |  |   |Timeout    |Request                  |     |
        |  |   |           |                         |     |
        |  |   |           v                         |     |
        |  |   |    +--------------+                 |     |
        |  |   +----+ Registration |                 |     |
        |  |        |              |                 |     |
        |  | Reject |              |                 |     |
        |  +--------+   Pending    |                 |     |
        | nTimeout>3|              |                 |     |
        |           |              |                 |     |
        |           +------+-------+                 |     |
        |                  |                         |     |
        |                  |Accept                   |     |
        |                  |                         |     |
        |                  |                         |     |
        |                  v                         |     |
        |           +------+-------+                 |     |
        |           |  Registered  |                 |     |
        |      +--->|              |                 |     |
        |      |    +------+-------+                 |     |
        |      |           |                         |     |
        |      |Timeout    |Config                   |     |
        |      |           |Request                  |     |
        |      |           |                         |     |
        |      |           v                         |     |
        |      |    +------+-------+                 |     |
        |      +----+              |           Reject|     |
        |           |Configuration |                 |     |
        |   Reject  | Pending      |                 |     |
        +-----------+              |                 |     |



Narasimhan, et al.              Historic                       [Page 61]

RFC 5413                          SLAPP                    February 2010


        ^ nTimeout>3+------+-------+                 |     |
        |                  |                         |     |
        |                  |                         |     |
  De-reg|                  |    +----------------+   |     |
   resp |                  |    v     Accept     |   |     |
   +----+---+       +------+----+--+           +-+---+--+  |
   |        | De-reg|              |           | Update |  |
   |  De    +<------+ Configured   +-----------+        |  |
   |Register| req   |              |           | Pending|  |
   |        |       |              |           +----+---+  |
   +--------+       +------+-------+                       |
                           |                               |
                           |                               |
                           |                               |
                       Too |Many                           |
                       Keepalive                           |
                       Failures                            |
                           |                               |
                           |                               |
                           |   De-Register                 |
                           +-------------------------------+

  In Configured and/or Registered states, respond to
  Status Requests, Statistics Requests, Keepalives, Key Config

           Figure 26: SLAPP 802.11 Control Protocol at the WTP

6.1.4.1.1.1.  State Machine Explanation

  Unregistered: The transition into this state is from the securing
     state (Figure 3).  Send registration request message to move to
     Registration Pending state, set timer for registration response.

  Registration Pending: On a registration response from the AC, cancel
     registration timer.  If the response is successful, move to
     Registered state.  If not, move to discovering state (Figure 3).
     If timer expires, if nTimeout >3, then move to discovering state.
     If not, return to Unregistered state.

  Registered: Send Configuration Request message to AC to move to
     Configuration Pending state, and set timer for Configuration
     Response.  In this state, respond to status request, statistics
     request, and keepalive messages from the AC.

  Configuration Pending: If a Configuration Response is received from
     the AC, cancel the Configuration Response timer.  If the response
     is successful and the configuration is acceptable, then send the
     Configuration ACK message to AC, and move to Configured state.  If



Narasimhan, et al.              Historic                       [Page 62]

RFC 5413                          SLAPP                    February 2010


     the Configuration Request is rejected or the configuration is not
     acceptable, then send a de-register request to the AC and move to
     discovering.  If the Configuration Response timer expires, move to
     Registered state unless nTimeout >3, in which case move to
     discovering state.

  Configured: In the Configured state, the WTP responds to the status
     request, statistics request, and keepalive messages from the AC.
     If it receives a de-register request message from the AC, then it
     sends a de-register response to the AC and moves to the
     discovering state.  If the WTP receives a Configuration Update
     message, then it moves to the Update Pending state.  If it
     receives too many consecutive keepalive failures (no responses
     from the AC to keepalive requests), then it sends a de-register
     message to the AC and moves to the discovering state.

  Update Pending: In the Update Pending state, the WTP analyzes the
     configuration information received in the Configuration Update
     message.  If the configuration is found to be acceptable, then it
     applies the configuration and returns to the Configured state.  If
     the WTP chooses to reject the configuration update, then it sends
     a de-register request to the AC and moves to the discovering
     state.

  De-register: From the Configured state, the WTP moves to the
     De-register state when it receives a de-register request message
     from the AC.  It sends a de-register response to the AC and moves
     to the discovering state.























Narasimhan, et al.              Historic                       [Page 63]

RFC 5413                          SLAPP                    February 2010


6.1.4.1.2.  At the AC

           +----------+
           | securing |
           +----+-----+
                |
                |
                |
                v
           +--------------+
  +--------| Unregistered |
  |        +----+---------+
  |             |
  |Timeout      |Register
  |             |request
  |             v                   +-------------+
  |         +----------+   Accept   | Registration|
  |     +---+Register  +----------->|  Pending    |
  |     |   |Processing|            +-+-----+-----+
  |     |   +----------+              |     |
  |     |                             |     |
  |     |Reject                    Timeout  |
  |     |                             |     |Config
  |     |                             |     |Request
  |     |      +--------------+       |     |
  |     +----->|              |<------+     |
  |            |  discovering |             v
  +----------->|              |        +------------+
               +--------------+        | Registered |
                   ^     ^  ^          +----+-------+
                   |     |  |               |
                   |     |  |               |Config
                   |     |  |               |Response
                   |     |  |               v
                   |     |  | Timeout  +------------+
                   |     |  +----------| Config     |
                   |     |   or Reject | Pending    |
                   |     |             +----+-------+
                   |     |                  |
                   |     |                  |Config ACK
                   |     |                  v
                   |     |De-Register  +------------+
                   |     +-------------|            |
                   |     or Keepalive  | Configured |<--+
                   |        failures   |            |   |
                   |                   +----+-------+   |





Narasimhan, et al.              Historic                       [Page 64]

RFC 5413                          SLAPP                    February 2010


             Reject|                        |           |
                 or|                        |           |
             Timeout     +-----------+      |Config     |
                   |     | Update    |      |Update     |
                   +-----| Pending   |<-----+           |
                         +----+------+                  |
                              |           Accept        |
                              +-------------------------+

           Figure 27: SLAPP 802.11 Control Protocol at the AC

6.1.4.1.2.1.  State Machine Explanation

  The states "securing" and "discovering" are described in Figure 3.

  Unregistered: This state is entered from the securing state described
     in Figure 3.  In this state, the AC is waiting for a registration
     request message from the WTP.  Upon receiving the registration
     request message, it moves into the Registration Processing state.

  Registration Processing: In this state, the AC must determine whether
     or not it can accept the new WTP.  If the AC decides to accept the
     WTP, it must pick a CAPWAP mode to operate in and send a
     registration response message with a success code and moves to the
     Registration Pending state.  If the AC chooses to reject the
     current registration request from the WTP, it must send a
     registration response with a failure code and move to the
     discovering state.

  Registration Pending: If the timer expires before a response from the
     WTP is received, then the AC destroys the registration state and
     moves to the discovering state.  If a Configuration Request
     message is received from the WTP, then the AC moves into the
     Registered state and processes the Configuration Request message.
     It sends a Configuration Response message to the WTP with the
     appropriate IEs and moves into the Configuration Pending state.

  Configuration Pending: If the timer expires before a response is
     received from the WTP, then the AC destroys the current
     registration and moves into the discovering state.  If a
     Configuration ACK is received from the WTP, but contains a failure
     code, then the AC again destroys the registration state and moves
     into the discovering state.  If the Configuration ACK from the WTP
     is successful, then the AC moves to the Configured state.

  Configured: In the Configured state, the AC can send a status
     request, statistics request, keepalive, and Key Configuration
     messages to the WTP.  Any response to these messages from the WTP



Narasimhan, et al.              Historic                       [Page 65]

RFC 5413                          SLAPP                    February 2010


     that indicates an unknown SLAPP registration ID or an unknown AC
     causes the AC to destroy any registration or configuration state
     and move to the discovering state.  From the configured state, the
     AC can send a Configuration Update message and move into the
     Update Pending state.  If it receives a de-register request from
     the WTP, then it destroys all current registration and
     configuration state and moves into the discovering state.  If a
     number of successive keepalive messages go unacknowledged by the
     WTP, then the AC moves into the discovering state.

  Update Pending: When the AC receives a Configuration ACK message with
     a success code, then it returns to the Configured state.  If the
     status code is a failure or if the timer expires before the
     Configuration ACK is received from the WTP, the AC destroys all
     registration and configuration state for the WTP and moves into
     the discovering state.

6.2.  Image Download Protocol

  The Image Download protocol is a control protocol defined in this
  document that is generic enough to be agnostic to the underlying
  technology.

  In the Image Download protocol, the WTP obtains a bootable image from
  the AC by receiving a series of image transfer packets.  Missed image
  data packets are re-requested by the WTP by sending image data
  request packets indicating the missing packets.

  The image to download is divided into slices of equal size (except
  for the last slice, which can be less than the slice size provided,
  it is also greater than zero).  The size of each slice depends on the
  MTU determined by the DTLS exchange and SHOULD be the realized MTU
  minus the size of an Image Download Request (Figure 29).

  Note that the Image Download packet and Image Download Request is
  encapsulated in a DTLS header that secures the image download.

6.2.1  Image Download Packet

  The format of an Image Download packet is shown in Figure 28.











Narasimhan, et al.              Historic                       [Page 66]

RFC 5413                          SLAPP                    February 2010


   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  |    Type = 3   |           Length              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  RESERVED |M|R|            packet sequence number             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  ~                     image data slice                          ~
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 28: SLAPP Image Download Packet

  where:

  length: variable

  RESERVED: Unused in this version of SLAPP, MUST be zero (0) on
     transmission and ignored upon receipt.

  M: The "More" bit indicating that the current packet is not the final
     one.

  R: The "Request" bit.  This bit MUST be set to one (1) when the
     packet is the response to a request and zero (0) otherwise.

  packet sequence number: A monotonically increasing counter that
     assigns a unique number to each slice of the image.

  image data slice: A portion of the bootable image.

6.2.2.  Image Download Request

  The format of an Image Download Request is shown in Figure 29.

   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  |    Type = 3   |           Length              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  RESERVED |M|R|            packet sequence number             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 29: SLAPP Image Download Request Packet

  where:

  length: eight (8) octets




Narasimhan, et al.              Historic                       [Page 67]

RFC 5413                          SLAPP                    February 2010


  RESERVED: Unused in this version of SLAPP, MUST be zero on
     transmission and ignored upon receipt.

  M: The "More" bit.  This MUST be equal to the one (1) when negatively
     acknowledging a missed packet and set to zero (0) when indicating
     the end of the Image Download protocol.

  R: the "Request" bit.  This MUST be one in an Image Download Request.

  packet sequence number: The packet sequence number of the missing
     image data slice.

6.2.3.  Image Download Process

  The AC will divide the bootable image into a series of slices and
  send each slice as an Image Download packet.  The size of each image
  data slice (and therefore the size of each Image Download packet)
  depends on the MTU of the connection determined during the DTLS
  handshake.  With the transmission of each slice, the AC MUST
  increment the packet sequence number.

  Image Download packets are negatively ACK'd.  An AC MUST NOT assume
  anything about the reception of packets; it sends based upon negative
  ACKs.  One could naively assume that since the packets are sent
  sequentially, that all packets with a sequence number of "n - 1" are
  implicitly ack'd by the receipt of a request for the packet with
  sequence number "n" to be retransmitted.  Such an assumption would be
  incorrect since previous requests could, themselves, have been
  dropped.

  The Image Download process is initiated by the WTP requesting a
  packet with the packet sequence number of zero (0).  The AC sets the
  packet sequence counter for this WTP to one (1) and sends the first
  slice.  The "Request" bit for the first slice sent by the AC MUST be
  set to zero (0) since the first slice was technically not requested.

  The WTP sets a periodic timer that, when it fires, causes the WTP to
  send Image Download Requests for slices that have been missed since
  the last periodic timer had fired.  Since individual Image Download
  packets are not ack'd, the AC MUST NOT set a timer when each one is
  sent.

  If a WTP notices missed image transfer packets -- when the difference
  between the packet sequence number of a received image transfer
  packet and the packet sequence number of the last image transfer
  packet previously received is greater than one -- it will note that
  fact in a bitmask.  When the periodic timer fires, the WTP will
  request the slices that are absent from that bitmask.  Each slice



Narasimhan, et al.              Historic                       [Page 68]

RFC 5413                          SLAPP                    February 2010


  will be requested by sending a Download Request with a length of
  eight (8) and indicating the sequence number of the packet requested.
  The AC MUST interleave these retransmissions with packets in the
  sequence.

  Since both sides implicitly agree upon the MTU of the link, the WTP
  will know the slice size that the AC will use during the Image
  Download process.  A dropped packet will therefore result in an
  internal buffer pointer on the WTP being incremented by the slice
  size and the lost packet requested.  When the lost packet is
  received, it can be inserted into the buffer in the space provided by
  the pointer increment when its loss was first detected.  That is,
  loss of packet <n> will result in packet <n> being re-requested and
  when received inserted into the buffer at an offset of <n-1> *
  <slicesize> from the start of the buffer.

  The final packet sent by the AC will not have the "more" bit set, and
  this indicates to the WTP that the end of the image has been
  received.  This final packet is acknowledged by the WTP indicating
  the end of the Image Download process.

  A lost final packet will result in the AC resending the final packet
  again (see Section 4.4).

6.2.4.  Image Download State Machine

  The Image Download protocol is a Negotiated Control Protocol defined
  for SLAPP.  Transitions to it come from the "secure" state and
  transitions out of it go to the "acquire" state.  See Figure 3.

6.2.4.1.  AC

  The AC's state machine for the Image Download protocol is shown in
  Figure 30.  The AC maintains the following variables for its state
  machine:

  seq_num: The current slice that is being sent.

  nslices: The total number of slices in the image.

  req_num: The number of the slice that was requested.

  more: Whether the "More bit" in the packet should be set.

  starved: A timer that sets the maximum amount of time in which an AC
     will attempt to download an image.





Narasimhan, et al.              Historic                       [Page 69]

RFC 5413                          SLAPP                    February 2010


  Note: The symbol "C" indicates an event in a state that results in
  the state remaining the same.

                             |
                             v
                        +----------+
                        |  waiting |
                        +----------+
                             |
                             |   seq_num = 1, more = 1,
                             |   nslices = x, starved = t
               M bit         v
  +----------+  is 0  +-------------+
  | finished |<-------|  received   |<------\
  +----------+        |             |<----\ |
                      +-------------+     | |
   req_num = requested       |            | |
                packet       | M bit is 1 | |
                             V            | |
                        +----------+      | |
            seq_num++, C|  sending |------/ |
            req_num=0   +----------+        |
                             |              |
                          |  |              |
      +-------------+     |  |              |
      | discovering |<----/  |              |
      |             |<----\  |              |
      +-------------+     |  |              |
                          |  v              v
                         +--------+         |
                         | idle   |---------/
                         +--------+

    Figure 30: SLAPP Image Download Protocol State Machine at the AC

  The following states are defined:

  Waiting: When the AC leaves the SLAPP state of "Secure", it enters
     the "Waiting" state of the Image Download protocol.  seq_num is
     set to one (1), more is set to one (1), nslices is set to the
     number of slices in the particular image to download, and starved
     is set to the maximum amount of time the AC will devote to
     downloading a particular image.








Narasimhan, et al.              Historic                       [Page 70]

RFC 5413                          SLAPP                    February 2010


  Received: The AC enters this state when it has received an Image
     Download Request.  If the sequence number of the packet is zero
     (0), it sets seq_num to one (1) and transitions to Sending; else,
     if the M bit is set, it sets req_num to the sequence number of the
     request and transitions to Sending; else, (if the M bit is clear)
     it transitions to Finished.

  Sending: The AC is sending a slice to the WTP.  If req_num is equal
     to zero (0), it sends the slice indicated by seq_num and
     increments seq_num.  If req_num is greater than zero (0), it sends
     the slice indicated by req_num and sets req_num to zero (0).  The
     "More" bit in either case is set depending on the value of more.
     As long as no request packets are received Sending transitions to
     Sending.  When seq_num equals nslices "More" is set to zero (0)
     and the state transitions to Idle.  If the starved timer expires,
     the AC transitions to the SLAPP state of Discovering.

  Idle: The AC has sent all the slices in the image and is just waiting
     for requests.  If the starved timer expires the AC transitions to
     the SLAPP state of Discovering.

  Finished: The Image Download protocol has terminated.  The starved
     timer is canceled.

6.2.4.2.  WTP

  The WTP's state machine for the Image Download protocol is shown in
  Figure 31.  The WTP maintains the following variables for its state
  machine:

  recv_num: The sequence number of the last received slice.

  req: A bitmask whose length equals the number of slices in the image.

  retry: A timer.

  giveup: A timer.

  final: The sequence number of the last slice.

  Note: The symbol "C" indicates an event in a state that results in
  the state remaining the same.









Narasimhan, et al.              Historic                       [Page 71]

RFC 5413                          SLAPP                    February 2010


                              |
                              v
                         +----------+
                         |   init   |    recv_num = 0,
                         +----------+    final = 0, req = 0,
                              |          giveup = t
                              v
   +----------+         +-----------+
   | finished |<------- |  sending  |<-------\
   +----------+         +-----------+        |
                              |              | retry fires
                              v              |
                       +--------------+      |
     bit in req =     C|  receiving   |------/
  seq_num in packet    +--------------+
       is set                 |
                              | giveup fires
                              v
                       +-------------+
                       | discovering |
                       +-------------+

    Figure 31: SLAPP Image Download Protocol State Machine at the WTP

  The following states are defined:

  Init:

     When the WTP leaves the SLAPP state of "Secure", it enters the
     "Init" state of the Image Download protocol.  recv_num, final, and
     the req bitmask are set to zero (0), and the giveup timer is set
     to a suitably large number.  The WTP transitions directly to
     Sending.

  Sending:

     If recv_num is zero (0) the WTP sends a request for a packet with
     sequence number of zero (0) and the "More" bit set to one (1).
     Otherwise, for every unset bit in req between one (1) and
     recv_num, a request packet is sent with the sequence number
     corresponding to the unset bit in req and the "More" bit set to
     more.

     If there are no unset bits in req and final is non-zero, a request
     packet is sent for the sequence number represented by final with
     the "More" bit cleared, giveup is cleared and the state machine
     transitions to Finished.  Otherwise, retry is set to a suitable
     value and the WTP transitions to Receiving.



Narasimhan, et al.              Historic                       [Page 72]

RFC 5413                          SLAPP                    February 2010


  Receiving:

     In this state, the WTP receives Image Download packets.  The bit
     in req corresponding to the sequence number in the received packet
     is set, indicating this packet has been received.  If the sequence
     number of the received packet has already been received, the
     packet is silently dropped; otherwise, the data in the packet is
     stored as the indicated slice in a file that represents the
     downloaded image.  If the received packet has the "More" bit
     cleared, final is set to the sequence number in that packet.  When
     the retry timer fires, the WTP transitions to Sending.  If the
     giveup timer fires, the WTP transitions to the SLAPP state of
     Discovering.

  Finished:

     The Image Download protocol has finished.

7.  Security Considerations

  This document describes a protocol, SLAPP, which uses a different
  protocol, DTLS, to provide for authentication, key exchange, and bulk
  data encryption of a Negotiated Control Protocol.  Its security
  considerations are therefore those of DTLS.

  The AC creates state upon receipt of an acceptable Discover Request.
  AC implementations of SLAPP SHOULD therefore take measures to protect
  themselves from denial-of-service attacks that attempt to exhaust
  resources on target machines.  These measures could take the form of
  randomly dropping connections when the number of open connections
  reaches a certain threshold.

  The WTP exposes information about itself during the discovery phase.
  Some of this information could not be gleaned by other means.

8.  Extensibility to Other Technologies

  The SLAPP protocol can be considered to be a technology-independent
  protocol that can be extended with technology-specific components to
  solve an interoperability problem where a central controller from one
  vendor is expected to control and manage network elements from a
  different vendor.

  While the description of the SLAPP protocol in this document assumes
  that it is meant to solve the multi-vendor interoperability problem,
  as defined in the CAPWAP problem statement [3], splitting the





Narasimhan, et al.              Historic                       [Page 73]

RFC 5413                          SLAPP                    February 2010


  solution to two components where technology-dependent control
  protocols are negotiated using a technology-independent framework
  enables the use of SLAPP as the common framework for multiple
  underlying technologies that are vastly different from one another.

9.  Informative References

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

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

  [3]   O'Hara, B., Calhoun, P., and J. Kempf, "Configuration and
        Provisioning for Wireless Access Points (CAPWAP) Problem
        Statement", RFC 3990, February 2005.

  [4]   Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina,
        "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.

  [5]   Braden, R., Ed., "Requirements for Internet Hosts -
        Communication Layers", STD 3, RFC 1122, October 1989.

  [6]   Rescorla, E. and N. Modadugu, "Datagram Transport Layer
        Security", RFC 4347, April 2006.

  [7]   Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
        Protocol Version 1.2", RFC 5246, August 2008.

  [8]   Modadugu, N. and E. Rescorla, "The Design and Implementation of
        Datagram TLS",
        <http://crypto.stanford.edu/~nagendra/papers/dtls.pdf>.

  [9]   Krishna, P. and D. Husak, "Simple Lightweight RFID Reader
        Protocol", Work in Progress, August 2005.















Narasimhan, et al.              Historic                       [Page 74]

RFC 5413                          SLAPP                    February 2010


Authors' Addresses

  Partha Narasimhan
  Aruba Networks
  1322 Crossman Ave
  Sunnyvale, CA  94089

  Phone: +1 408-480-4716
  EMail: [email protected]


  Dan Harkins
  Aruba Networks
  1322 Crossman Ave
  Sunnyvale, CA  94089

  EMail: [email protected]


  Subbu Ponnuswamy
  Aruba Networks
  1322 Crossman Ave
  Sunnyvale, CA  94089

  Phone: +1 408-754-1213
  EMail: [email protected]

























Narasimhan, et al.              Historic                       [Page 75]