tech-invite   World Map     

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

RFC 5415

 
 
 

Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification

Part 3 of 6, p. 40 to 67
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 40 
3.  CAPWAP Transport

   Communication between a WTP and an AC is established using the
   standard UDP client/server model.  The CAPWAP protocol supports both
   UDP and UDP-Lite [RFC3828] transport protocols.  When run over IPv4,
   UDP is used for the CAPWAP Control and Data channels.

   When run over IPv6, the CAPWAP Control channel always uses UDP, while
   the CAPWAP Data channel may use either UDP or UDP-Lite.  UDP-Lite is
   the default transport protocol for the CAPWAP Data channel.  However,
   if a middlebox or IPv4 to IPv6 gateway has been discovered, UDP is
   used for the CAPWAP Data channel.

   This section describes how the CAPWAP protocol is carried over IP and
   UDP/UDP-Lite transport protocols.  The CAPWAP Transport Protocol
   message element, Section 4.6.14, describes the rules to use in
   determining which transport protocol is to be used.

   In order for CAPWAP to be compatible with potential middleboxes in
   the network, CAPWAP implementations MUST send return traffic from the
   same port on which they received traffic from a given peer.  Further,
   any unsolicited requests generated by a CAPWAP node MUST be sent on
   the same port.

3.1.  UDP Transport

   One of the CAPWAP protocol requirements is to allow a WTP to reside
   behind a middlebox, firewall, and/or Network Address Translation
   (NAT) device.  Since a CAPWAP session is initiated by the WTP
   (client) to the well-known UDP port of the AC (server), the use of
   UDP is a logical choice.  When CAPWAP is run over IPv4, the UDP
   checksum field in CAPWAP packets MUST be set to zero.

   CAPWAP protocol control packets sent from the WTP to the AC use the
   CAPWAP Control channel, as defined in Section 1.4.  The CAPWAP
   control port at the AC is the well-known UDP port 5246.  The CAPWAP
   control port at the WTP can be any port selected by the WTP.

   CAPWAP protocol data packets sent from the WTP to the AC use the
   CAPWAP Data channel, as defined in Section 1.4.  The CAPWAP data port
   at the AC is the well-known UDP port 5247.  If an AC permits the
   administrator to change the CAPWAP control port, the CAPWAP data port
   MUST be the next consecutive port number.  The CAPWAP data port at
   the WTP can be any port selected by the WTP.

Top      Up      ToC       Page 41 
3.2.  UDP-Lite Transport

   When CAPWAP is run over IPv6, UDP-Lite is the default transport
   protocol, which reduces the checksum processing required for each
   packet (compared to the use of UDP over IPv6 [RFC2460]).  When UDP-
   Lite is used, the checksum field MUST have a coverage of 8 [RFC3828].

   UDP-Lite uses the same port assignments as UDP.

3.3.  AC Discovery

   The AC Discovery phase allows the WTP to determine which ACs are
   available and choose the best AC with which to establish a CAPWAP
   session.  The Discovery phase occurs when the WTP enters the optional
   Discovery state.  A WTP does not need to complete the AC Discovery
   phase if it uses a pre-configured AC.  This section details the
   mechanism used by a WTP to dynamically discover candidate ACs.

   A WTP and an AC will frequently not reside in the same IP subnet
   (broadcast domain).  When this occurs, the WTP must be capable of
   discovering the AC, without requiring that multicast services are
   enabled in the network.

   When the WTP attempts to establish communication with an AC, it sends
   the Discovery Request message and receives the Discovery Response
   message from the AC(s).  The WTP MUST send the Discovery Request
   message to either the limited broadcast IP address (255.255.255.255),
   the well-known CAPWAP multicast address (224.0.1.140), or to the
   unicast IP address of the AC.  For IPv6 networks, since broadcast
   does not exist, the use of "All ACs multicast address" (FF0X:0:0:0:0:
   0:0:18C) is used instead.  Upon receipt of the Discovery Request
   message, the AC sends a Discovery Response message to the unicast IP
   address of the WTP, regardless of whether the Discovery Request
   message was sent as a broadcast, multicast, or unicast message.

   WTP use of a limited IP broadcast, multicast, or unicast IP address
   is implementation dependent.  ACs, on the other hand, MUST support
   broadcast, multicast, and unicast discovery.

   When a WTP transmits a Discovery Request message to a unicast
   address, the WTP must first obtain the IP address of the AC.  Any
   static configuration of an AC's IP address on the WTP non-volatile
   storage is implementation dependent.  However, additional dynamic
   schemes are possible, for example:

Top      Up      ToC       Page 42 
   DHCP:  See [RFC5417] for more information on the use of DHCP to
      discover AC IP addresses.

   DNS:  The WTP MAY support use of DNS Service Records (SRVs) [RFC2782]
      to discover the AC address(es).  In this case, the WTP first
      obtains (e.g., from local configuration) the correct domain name
      suffix (e.g., "example.com") and performs an SRV lookup with
      Service name "capwap-control" and Proto "udp".  Thus, the name
      resolved in DNS would be, e.g., "_capwap-
      control._udp.example.com".  Note that the SRV record MAY specify a
      non-default port number for the control channel; the port number
      for the data channel is the next port number (control channel port
      + 1).

   An AC MAY also communicate alternative ACs to the WTP within the
   Discovery Response message through the AC IPv4 List (see
   Section 4.6.2) and AC IPv6 List (see Section 4.6.2).  The addresses
   provided in these two message elements are intended to help the WTP
   discover additional ACs through means other than those listed above.

   The AC Name with Priority message element (see Section 4.6.5) is used
   to communicate a list of preferred ACs to the WTP.  The WTP SHOULD
   attempt to utilize the ACs listed in the order provided by the AC.
   The Name-to-IP Address mapping is handled via the Discovery message
   exchange, in which the ACs provide their identity in the AC Name (see
   Section 4.6.4) message element in the Discovery Response message.

   Once the WTP has received Discovery Response messages from the
   candidate ACs, it MAY use other factors to determine the preferred
   AC.  For instance, each binding defines a WTP Radio Information
   message element (see Section 2.1), which the AC includes in Discovery
   Response messages.  The presence of one or more of these message
   elements is used to identify the CAPWAP bindings supported by the AC.
   A WTP MAY connect to an AC based on the supported bindings
   advertised.

3.4.  Fragmentation/Reassembly

   While fragmentation and reassembly services are provided by IP, the
   CAPWAP protocol also provides such services.  Environments where the
   CAPWAP protocol is used involve firewall, NAT, and "middlebox"
   devices, which tend to drop IP fragments to minimize possible DoS
   attacks.  By providing fragmentation and reassembly at the
   application layer, any fragmentation required due to the tunneling
   component of the CAPWAP protocol becomes transparent to these
   intermediate devices.  Consequently, the CAPWAP protocol can be used
   in any network topology including firewall, NAT, and middlebox
   devices.

Top      Up      ToC       Page 43 
   It is important to note that the fragmentation mechanism employed by
   CAPWAP has known limitations and deficiencies, which are similar to
   those described in [RFC4963].  The limited size of the Fragment ID
   field (see Section 4.3) can cause wrapping of the field, and hence
   cause fragments from different datagrams to be incorrectly spliced
   together (known as "mis-associated").  For example, a 100Mpbs link
   with an MTU of 1500 (causing fragmentation at 1450 bytes) would cause
   the Fragment ID field wrap in 8 seconds.  Consequently, CAPWAP
   implementers are warned to properly size their buffers for reassembly
   purposes based on the expected wireless technology throughput.

   CAPWAP implementations SHOULD perform MTU Discovery (see
   Section 3.5), which can avoid the need for fragmentation.  At the
   time of writing of this specification, most enterprise switching and
   routing infrastructure were capable of supporting "mini-jumbo" frames
   (1800 bytes), which eliminates the need for fragmentation (assuming
   the station's MTU is 1500 bytes).  The need for fragmentation
   typically continues to exist when the WTP communicates with the AC
   over a Wide Area Network (WAN).  Therefore, future versions of the
   CAPWAP protocol SHOULD consider either increasing the size of the
   Fragment ID field or providing alternative extensions.

3.5.  MTU Discovery

   Once a WTP has discovered the AC with which it wishes to establish a
   CAPWAP session, it SHOULD perform a Path MTU (PMTU) discovery.  One
   recommendation for performing PMTU discovery is to have the WTP
   transmit Discovery Request (see Section 5.1) messages, and include
   the MTU Discovery Padding message element (see Section 4.6.32).  The
   actual procedures used for PMTU discovery are described in [RFC1191]
   for IPv4; for IPv6, [RFC1981] SHOULD be used.  Alternatively,
   implementers MAY use the procedures defined in [RFC4821].  The WTP
   SHOULD also periodically re-evaluate the PMTU using the guidelines
   provided in these two RFCs, using the Primary Discovery Request (see
   Section 5.3) along with the MTU Discovery Padding message element
   (see Section 4.6.32).  When the MTU is initially known, or updated in
   the case where an existing session already exists, the discovered
   PMTU is used to configure the DTLS component (see Section 2.3.2.1),
   while non-DTLS frames need to be fragmented to fit the MTU, defined
   in Section 3.4.

4.  CAPWAP Packet Formats

   This section contains the CAPWAP protocol packet formats.  A CAPWAP
   protocol packet consists of one or more CAPWAP Transport Layer packet
   headers followed by a CAPWAP message.  The CAPWAP message can be
   either of type Control or Data, where Control packets carry

Top      Up      ToC       Page 44 
   signaling, and Data packets carry user payloads.  The CAPWAP frame
   formats for CAPWAP Data packets, and for DTLS encapsulated CAPWAP
   Data and Control packets are defined below.

   The CAPWAP Control protocol includes two messages that are never
   protected by DTLS: the Discovery Request message and the Discovery
   Response message.  These messages need to be in the clear to allow
   the CAPWAP protocol to properly identify and process them.  The
   format of these packets are as follows:

       CAPWAP Control Packet (Discovery Request/Response):
       +-------------------------------------------+
       | IP  | UDP | CAPWAP | Control | Message    |
       | Hdr | Hdr | Header | Header  | Element(s) |
       +-------------------------------------------+

   All other CAPWAP Control protocol messages MUST be protected via the
   DTLS protocol, which ensures that the packets are both authenticated
   and encrypted.  These packets include the CAPWAP DTLS Header, which
   is described in Section 4.2.  The format of these packets is as
   follows:

    CAPWAP Control Packet (DTLS Security Required):
    +------------------------------------------------------------------+
    | IP  | UDP | CAPWAP   | DTLS | CAPWAP | Control| Message   | DTLS |
    | Hdr | Hdr | DTLS Hdr | Hdr  | Header | Header | Element(s)| Trlr |
    +------------------------------------------------------------------+
                           \---------- authenticated -----------/
                                  \------------- encrypted ------------/

   The CAPWAP protocol allows optional protection of data packets, using
   DTLS.  Use of data packet protection is determined by AC policy.
   When DTLS is utilized, the optional CAPWAP DTLS Header is present,
   which is described in Section 4.2.  The format of CAPWAP Data packets
   is shown below:

Top      Up      ToC       Page 45 
       CAPWAP Plain Text Data Packet :
       +-------------------------------+
       | IP  | UDP | CAPWAP | Wireless |
       | Hdr | Hdr | Header | Payload  |
       +-------------------------------+

       DTLS Secured CAPWAP Data Packet:
       +--------------------------------------------------------+
       | IP  | UDP |  CAPWAP  | DTLS | CAPWAP | Wireless | DTLS |
       | Hdr | Hdr | DTLS Hdr | Hdr  |  Hdr   | Payload  | Trlr |
       +--------------------------------------------------------+
                              \------ authenticated -----/
                                     \------- encrypted --------/

   UDP Header:  All CAPWAP packets are encapsulated within either UDP,
      or UDP-Lite when used over IPv6.  Section 3 defines the specific
      UDP or UDP-Lite usage.

   CAPWAP DTLS Header:  All DTLS encrypted CAPWAP protocol packets are
      prefixed with the CAPWAP DTLS Header (see Section 4.2).

   DTLS Header:  The DTLS Header provides authentication and encryption
      services to the CAPWAP payload it encapsulates.  This protocol is
      defined in [RFC4347].

   CAPWAP Header:  All CAPWAP protocol packets use a common header that
      immediately follows the CAPWAP preamble or DTLS Header.  The
      CAPWAP Header is defined in Section 4.3.

   Wireless Payload:  A CAPWAP protocol packet that contains a wireless
      payload is a CAPWAP Data packet.  The CAPWAP protocol does not
      specify the format of the wireless payload, which is defined by
      the appropriate wireless standard.  Additional information is in
      Section 4.4.

   Control Header:  The CAPWAP protocol includes a signaling component,
      known as the CAPWAP Control protocol.  All CAPWAP Control packets
      include a Control Header, which is defined in Section 4.5.1.
      CAPWAP Data packets do not contain a Control Header field.

   Message Elements:  A CAPWAP Control packet includes one or more
      message elements, which are found immediately following the
      Control Header.  These message elements are in a Type/Length/Value
      style header, defined in Section 4.6.

   A CAPWAP implementation MUST be capable of receiving a reassembled
   CAPWAP message of length 4096 bytes.  A CAPWAP implementation MAY
   indicate that it supports a higher maximum message length, by

Top      Up      ToC       Page 46 
   including the Maximum Message Length message element, see
   Section 4.6.31, in the Join Request message or the Join Response
   message.

4.1.  CAPWAP Preamble

   The CAPWAP preamble is common to all CAPWAP transport headers and is
   used to identify the header type that immediately follows.  The
   reason for this preamble is to avoid needing to perform byte
   comparisons in order to guess whether or not the frame is DTLS
   encrypted.  It also provides an extensibility framework that can be
   used to support additional transport types.  The format of the
   preamble is as follows:

         0
         0 1 2 3 4 5 6 7
        +-+-+-+-+-+-+-+-+
        |Version| Type  |
        +-+-+-+-+-+-+-+-+

   Version:  A 4-bit field that contains the version of CAPWAP used in
      this packet.  The value for this specification is zero (0).

   Type:  A 4-bit field that specifies the payload type that follows the
      UDP header.  The following values are supported:

      0 -   CAPWAP Header.  The CAPWAP Header (see Section 4.3)
            immediately follows the UDP header.  If the packet is
            received on the CAPWAP Data channel, the CAPWAP stack MUST
            treat the packet as a clear text CAPWAP Data packet.  If
            received on the CAPWAP Control channel, the CAPWAP stack
            MUST treat the packet as a clear text CAPWAP Control packet.
            If the control packet is not a Discovery Request or
            Discovery Response packet, the packet MUST be dropped.

      1 -   CAPWAP DTLS Header.  The CAPWAP DTLS Header (and DTLS
            packet) immediately follows the UDP header (see
            Section 4.2).

4.2.  CAPWAP DTLS Header

   The CAPWAP DTLS Header is used to identify the packet as a DTLS
   encrypted packet.  The first eight bits include the common CAPWAP
   Preamble.  The remaining 24 bits are padding to ensure 4-byte
   alignment, and MAY be used in a future version of the protocol.  The
   DTLS packet [RFC4347] always immediately follows this header.  The
   format of the CAPWAP DTLS Header is as follows:

Top      Up      ToC       Page 47 
        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |CAPWAP Preamble|                    Reserved                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   CAPWAP Preamble:  The CAPWAP Preamble is defined in Section 4.1.  The
      CAPWAP Preamble's Payload Type field MUST be set to one (1).

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

4.3.  CAPWAP Header

   All CAPWAP protocol messages are encapsulated using a common header
   format, regardless of the CAPWAP Control or CAPWAP Data transport
   used to carry the messages.  However, certain flags are not
   applicable for a given transport.  Refer to the specific transport
   section in order to determine which flags are valid.

   Note that the optional fields defined in this section MUST be present
   in the precise order shown below.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |CAPWAP Preamble|  HLEN   |   RID   | WBID    |T|F|L|W|M|K|Flags|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          Fragment ID          |     Frag Offset         |Rsvd |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 (optional) Radio MAC Address                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            (optional) Wireless Specific Information           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Payload ....                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   CAPWAP Preamble:  The CAPWAP Preamble is defined in Section 4.1.  The
      CAPWAP Preamble's Payload Type field MUST be set to zero (0).  If
      the CAPWAP DTLS Header is present, the version number in both
      CAPWAP Preambles MUST match.  The reason for this duplicate field
      is to avoid any possible tampering of the version field in the
      preamble that is not encrypted or authenticated.

Top      Up      ToC       Page 48 
   HLEN:  A 5-bit field containing the length of the CAPWAP transport
      header in 4-byte words (similar to IP header length).  This length
      includes the optional headers.

   RID:  A 5-bit field that contains the Radio ID number for this
      packet, whose value is between one (1) and 31.  Given that MAC
      Addresses are not necessarily unique across physical radios in a
      WTP, the Radio Identifier (RID) field is used to indicate with
      which physical radio the message is associated.

   WBID:  A 5-bit field that is the wireless binding identifier.  The
      identifier will indicate the type of wireless packet associated
      with the radio.  The following values are defined:

      0 -  Reserved

      1 -  IEEE 802.11

      2 -  Reserved

      3 -  EPCGlobal [EPCGlobal]

   T: The Type 'T' bit indicates the format of the frame being
      transported in the payload.  When this bit is set to one (1), the
      payload has the native frame format indicated by the WBID field.
      When this bit is zero (0), the payload is an IEEE 802.3 frame.

   F: The Fragment 'F' bit indicates whether this packet is a fragment.
      When this bit is one (1), the packet is a fragment and MUST be
      combined with the other corresponding fragments to reassemble the
      complete information exchanged between the WTP and AC.

   L: The Last 'L' bit is valid only if the 'F' bit is set and indicates
      whether the packet contains the last fragment of a fragmented
      exchange between WTP and AC.  When this bit is one (1), the packet
      is the last fragment.  When this bit is (zero) 0, the packet is
      not the last fragment.

   W: The Wireless 'W' bit is used to specify whether the optional
      Wireless Specific Information field is present in the header.  A
      value of one (1) is used to represent the fact that the optional
      header is present.

   M: The Radio MAC 'M' bit is used to indicate that the Radio MAC
      Address optional header is present.  This is used to communicate
      the MAC address of the receiving radio.

Top      Up      ToC       Page 49 
   K: The Keep-Alive 'K' bit indicates the packet is a Data Channel
      Keep-Alive packet.  This packet is used to map the data channel to
      the control channel for the specified Session ID and to maintain
      freshness of the data channel.  The 'K' bit MUST NOT be set for
      data packets containing user data.

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

   Fragment ID:  A 16-bit field whose value is assigned to each group of
      fragments making up a complete set.  The Fragment ID space is
      managed individually for each direction for every WTP/AC pair.
      The value of Fragment ID is incremented with each new set of
      fragments.  The Fragment ID wraps to zero after the maximum value
      has been used to identify a set of fragments.

   Fragment Offset:  A 13-bit field that indicates where in the payload
      this fragment belongs during re-assembly.  This field is valid
      when the 'F' bit is set to 1.  The fragment offset is measured in
      units of 8 octets (64 bits).  The first fragment has offset zero.
      Note that the CAPWAP protocol does not allow for overlapping
      fragments.

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

   Radio MAC Address:  This optional field contains the MAC address of
      the radio receiving the packet.  Because the native wireless frame
      format to IEEE 802.3 format causes the MAC address of the WTP's
      radio to be lost, this field allows the address to be communicated
      to the AC.  This field is only present if the 'M' bit is set.  The
      HLEN field assumes 4-byte alignment, and this field MUST be padded
      with zeroes (0x00) if it is not 4-byte aligned.

Top      Up      ToC       Page 50 
      The field contains the basic format:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Length    |                  MAC Address
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Length:  The length of the MAC address field.  The formats and
         lengths specified in [EUI-48] and [EUI-64] are supported.

      MAC Address:  The MAC address of the receiving radio.

   Wireless Specific Information:  This optional field contains
      technology-specific information that may be used to carry per-
      packet wireless information.  This field is only present if the
      'W' bit is set.  The WBID field in the CAPWAP Header is used to
      identify the format of the Wireless-Specific Information optional
      field.  The HLEN field assumes 4-byte alignment, and this field
      MUST be padded with zeroes (0x00) if it is not 4-byte aligned.

      The Wireless-Specific Information field uses the following format:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Length     |                Data...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Length:  The 8-bit field contains the length of the data field,
         with a maximum size of 255.

      Data:  Wireless-specific information, defined by the wireless-
         specific binding specified in the CAPWAP Header's WBID field.

   Payload:  This field contains the header for a CAPWAP Data Message or
      CAPWAP Control Message, followed by the data contained in the
      message.

4.4.  CAPWAP Data Messages

   There are two different types of CAPWAP Data packets: CAPWAP Data
   Channel Keep-Alive packets and Data Payload packets.  The first is
   used by the WTP to synchronize the control and data channels and to
   maintain freshness of the data channel.  The second is used to
   transmit user payloads between the AC and WTP.  This section
   describes both types of CAPWAP Data packet formats.

Top      Up      ToC       Page 51 
   Both CAPWAP Data messages are transmitted on the CAPWAP Data channel.

4.4.1.  CAPWAP Data Channel Keep-Alive

   The CAPWAP Data Channel Keep-Alive packet is used to bind the CAPWAP
   control channel with the data channel, and to maintain freshness of
   the data channel, ensuring that the channel is still functioning.
   The CAPWAP Data Channel Keep-Alive packet is transmitted by the WTP
   when the DataChannelKeepAlive timer expires (see Section 4.7.2).
   When the CAPWAP Data Channel Keep-Alive packet is transmitted, the
   WTP sets the DataChannelDeadInterval timer.

   In the CAPWAP Data Channel Keep-Alive packet, all of the fields in
   the CAPWAP Header, except the HLEN field and the 'K' bit, are set to
   zero upon transmission.  Upon receiving a CAPWAP Data Channel Keep-
   Alive packet, the AC transmits a CAPWAP Data Channel Keep-Alive
   packet back to the WTP.  The contents of the transmitted packet are
   identical to the contents of the received packet.

   Upon receiving a CAPWAP Data Channel Keep-Alive packet, the WTP
   cancels the DataChannelDeadInterval timer and resets the
   DataChannelKeepAlive timer.  The CAPWAP Data Channel Keep-Alive
   packet is retransmitted by the WTP in the same manner as the CAPWAP
   Control messages.  If the DataChannelDeadInterval timer expires, the
   WTP tears down the control DTLS session, and the data DTLS session if
   one existed.

   The CAPWAP Data Channel Keep-Alive packet contains the following
   payload immediately following the CAPWAP Header (see Section 4.3).

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Message Element Length     |  Message Element [0..N] ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message Element Length:   The 16-bit Length field indicates the
      number of bytes following the CAPWAP Header, with a maximum size
      of 65535.

   Message Element[0..N]:   The message element(s) carry the information
      pertinent to each of the CAPWAP Data Channel Keep-Alive message.
      The following message elements MUST be present in this CAPWAP
      message:

         Session ID, see Section 4.6.37.

Top      Up      ToC       Page 52 
4.4.2.  Data Payload

   A CAPWAP protocol Data Payload packet encapsulates a forwarded
   wireless frame.  The CAPWAP protocol defines two different modes of
   encapsulation: IEEE 802.3 and native wireless.  IEEE 802.3
   encapsulation requires that for 802.11 frames, the 802.11
   *Integration* function be performed in the WTP.  An IEEE 802.3-
   encapsulated user payload frame has the following format:

       +------------------------------------------------------+
       | IP Header | UDP Header | CAPWAP Header | 802.3 Frame |
       +------------------------------------------------------+

   The CAPWAP protocol also defines the native wireless encapsulation
   mode.  The format of the encapsulated CAPWAP Data frame is subject to
   the rules defined by the specific wireless technology binding.  Each
   wireless technology binding MUST contain a section entitled "Payload
   Encapsulation", which defines the format of the wireless payload that
   is encapsulated within CAPWAP Data packets.

   For 802.3 payload frames, the 802.3 frame is encapsulated (excluding
   the IEEE 802.3 Preamble, Start Frame Delimiter (SFD), and Frame Check
   Sequence (FCS) fields).  If the encapsulated frame would exceed the
   transport layer's MTU, the sender is responsible for the
   fragmentation of the frame, as specified in Section 3.4.  The CAPWAP
   protocol can support IEEE 802.3 frames whose length is defined in the
   IEEE 802.3as specification [FRAME-EXT].

4.4.3.  Establishment of a DTLS Data Channel

   If the AC and WTP are configured to tunnel the data channel over
   DTLS, the proper DTLS session must be initiated.  To avoid having to
   reauthenticate and reauthorize an AC and WTP, the DTLS data channel
   SHOULD be initiated using the TLS session resumption feature
   [RFC5246].

   The AC DTLS implementation MUST NOT initiate a data channel session
   for a DTLS session for which there is no active control channel
   session.

4.5.  CAPWAP Control Messages

   The CAPWAP Control protocol provides a control channel between the
   WTP and the AC.  Control messages are divided into the following
   message types:

   Discovery:  CAPWAP Discovery messages are used to identify potential
      ACs, their load and capabilities.

Top      Up      ToC       Page 53 
   Join:  CAPWAP Join messages are used by a WTP to request service from
      an AC, and for the AC to respond to the WTP.

   Control Channel Management:  CAPWAP Control channel management
      messages are used to maintain the control channel.

   WTP Configuration Management:  The WTP Configuration messages are
      used by the AC to deliver a specific configuration to the WTP.
      Messages that retrieve statistics from a WTP are also included in
      WTP Configuration Management.

   Station Session Management:  Station Session Management messages are
      used by the AC to deliver specific station policies to the WTP.

   Device Management Operations:  Device management operations are used
      to request and deliver a firmware image to the WTP.

   Binding-Specific CAPWAP Management Messages:  Messages in this
      category are used by the AC and the WTP to exchange protocol-
      specific CAPWAP management messages.  These messages may or may
      not be used to change the link state of a station.

   Discovery, Join, Control Channel Management, WTP Configuration
   Management, and Station Session Management CAPWAP Control messages
   MUST be implemented.  Device Management Operations messages MAY be
   implemented.

   CAPWAP Control messages sent from the WTP to the AC indicate that the
   WTP is operational, providing an implicit keep-alive mechanism for
   the WTP.  The Control Channel Management Echo Request and Echo
   Response messages provide an explicit keep-alive mechanism when other
   CAPWAP Control messages are not exchanged.

4.5.1.  Control Message Format

   All CAPWAP Control messages are sent encapsulated within the CAPWAP
   Header (see Section 4.3).  Immediately following the CAPWAP Header is
   the control header, which has the following format:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Message Type                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Seq Num    |        Msg Element Length     |     Flags     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Msg Element [0..N] ...
     +-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 54 
4.5.1.1.  Message Type

   The Message Type field identifies the function of the CAPWAP Control
   message.  To provide extensibility, the Message Type field is
   comprised of an IANA Enterprise Number [RFC3232] and an enterprise-
   specific message type number.  The first three octets contain the
   IANA Enterprise Number in network byte order, with zero used for
   CAPWAP base protocol (this specification) defined message types.  The
   last octet is the enterprise-specific message type number, which has
   a range from 0 to 255.

   The Message Type field is defined as:

         Message Type =
                 IANA Enterprise Number * 256 +
                     Enterprise Specific Message Type Number

   The CAPWAP protocol reliability mechanism requires that messages be
   defined in pairs, consisting of both a Request and a Response
   message.  The Response message MUST acknowledge the Request message.
   The assignment of CAPWAP Control Message Type Values always occurs in
   pairs.  All Request messages have odd numbered Message Type Values,
   and all Response messages have even numbered Message Type Values.
   The Request value MUST be assigned first.  As an example, assigning a
   Message Type Value of 3 for a Request message and 4 for a Response
   message is valid, while assigning a Message Type Value of 4 for a
   Response message and 5 for the corresponding Request message is
   invalid.

   When a WTP or AC receives a message with a Message Type Value field
   that is not recognized and is an odd number, the number in the
   Message Type Value Field is incremented by one, and a Response
   message with a Message Type Value field containing the incremented
   value and containing the Result Code message element with the value
   (Unrecognized Request) is returned to the sender of the received
   message.  If the unknown message type is even, the message is
   ignored.

Top      Up      ToC       Page 55 
   The valid values for CAPWAP Control Message Types are specified in
   the table below:

           CAPWAP Control Message           Message Type
                                              Value
           Discovery Request                    1
           Discovery Response                   2
           Join Request                         3
           Join Response                        4
           Configuration Status Request         5
           Configuration Status Response        6
           Configuration Update Request         7
           Configuration Update Response        8
           WTP Event Request                    9
           WTP Event Response                  10
           Change State Event Request          11
           Change State Event Response         12
           Echo Request                        13
           Echo Response                       14
           Image Data Request                  15
           Image Data Response                 16
           Reset Request                       17
           Reset Response                      18
           Primary Discovery Request           19
           Primary Discovery Response          20
           Data Transfer Request               21
           Data Transfer Response              22
           Clear Configuration Request         23
           Clear Configuration Response        24
           Station Configuration Request       25
           Station Configuration Response      26

4.5.1.2.  Sequence Number

   The Sequence Number field is an identifier value used to match
   Request and Response packets.  When a CAPWAP packet with a Request
   Message Type Value is received, the value of the Sequence Number
   field is copied into the corresponding Response message.

   When a CAPWAP Control message is sent, the sender's internal sequence
   number counter is monotonically incremented, ensuring that no two
   pending Request messages have the same sequence number.  The Sequence
   Number field wraps back to zero.

4.5.1.3.  Message Element Length

   The Length field indicates the number of bytes following the Sequence
   Number field.

Top      Up      ToC       Page 56 
4.5.1.4.  Flags

   The Flags field MUST be set to zero.

4.5.1.5.  Message Element [0..N]

   The message element(s) carry the information pertinent to each of the
   control message types.  Every control message in this specification
   specifies which message elements are permitted.

   When a WTP or AC receives a CAPWAP message without a message element
   that is specified as mandatory for the CAPWAP message, then the
   CAPWAP message is discarded.  If the received message was a Request
   message for which the corresponding Response message carries message
   elements, then a corresponding Response message with a Result Code
   message element indicating "Failure - Missing Mandatory Message
   Element" is returned to the sender.

   When a WTP or AC receives a CAPWAP message with a message element
   that the WTP or AC does not recognize, the CAPWAP message is
   discarded.  If the received message was a Request message for which
   the corresponding Response message carries message elements, then a
   corresponding Response message with a Result Code message element
   indicating "Failure - Unrecognized Message Element" and one or more
   Returned Message Element message elements is included, containing the
   unrecognized message element(s).

4.5.2.  Quality of Service

   The CAPWAP base protocol does not provide any Quality of Service
   (QoS) recommendations for use with the CAPWAP Data messages.  Any
   wireless-specific CAPWAP binding specification that has QoS
   requirements MUST define the application of QoS to the CAPWAP Data
   messages.

   The IP header also includes the Explicit Congestion Notification
   (ECN) bits [RFC3168].  Section 9.1.1 of [RFC3168] describes two
   levels of ECN functionality: full functionality and limited
   functionality.  CAPWAP ACs and WTPs SHALL implement the limited
   functionality and are RECOMMENDED to implement the full functionality
   described in [RFC3168].

Top      Up      ToC       Page 57 
4.5.2.1.  Applying QoS to CAPWAP Control Message

   It is recommended that CAPWAP Control messages be sent by both the AC
   and the WTP with an appropriate Quality-of-Service precedence value,
   ensuring that congestion in the network minimizes occurrences of
   CAPWAP Control channel disconnects.  Therefore, a QoS-enabled CAPWAP
   device SHOULD use the following values:

   802.1Q:   The priority tag of 7 SHOULD be used.

   DSCP:   The CS6 per-hop behavior Service Class SHOULD be used, which
      is described in [RFC2474]).

4.5.3.  Retransmissions

   The CAPWAP Control protocol operates as a reliable transport.  For
   each Request message, a Response message is defined, which is used to
   acknowledge receipt of the Request message.  In addition, the control
   header Sequence Number field is used to pair the Request and Response
   messages (see Section 4.5.1).

   Response messages are not explicitly acknowledged; therefore, if a
   Response message is not received, the original Request message is
   retransmitted.

   Implementations MUST keep track of the sequence number of the last
   received Request message, and MUST cache the corresponding Response
   message.  If a retransmission with the same sequence number is
   received, the cached Response message MUST be retransmitted without
   re-processing the Request.  If an older Request message is received,
   meaning one where the sequence number is smaller, it MUST be ignored.
   A newer Request message, meaning one whose sequence number is larger,
   is processed as usual.

   Note: A sequence number is considered "smaller" when s1 is smaller
   than s2 modulo 256 if and only if (s1<s2 and (s2-s1)<128) or
   (s1>s2 and (s1-s2)>128).

   Both the WTP and the AC can only have a single request outstanding at
   any given time.  Retransmitted Request messages MUST NOT be altered
   by the sender.

   After transmitting a Request message, the RetransmitInterval (see
   Section 4.7) timer and MaxRetransmit (see Section 4.8) variable are
   used to determine if the original Request message needs to be
   retransmitted.  The RetransmitInterval timer is used the first time
   the Request is retransmitted.  The timer is then doubled every

Top      Up      ToC       Page 58 
   subsequent time the same Request message is retransmitted, up to
   MaxRetransmit but no more than half the EchoInterval timer (see
   Section 4.7.7).  Response messages are not subject to these timers.

   If the sender stops retransmitting a Request message before reaching
   MaxRetransmit retransmissions (which leads to transition to DTLS
   Teardown, as described in Section 2.3.1), it cannot know whether the
   recipient received and processed the Request or not.  In most
   situations, the sender SHOULD NOT do this, and instead continue
   retransmitting until a Response message is received, or transition to
   DTLS Teardown occurs.  However, if the sender does decide to continue
   the connection with a new or modified Request message, the new
   message MUST have a new sequence number, and be treated as a new
   Request message by the receiver.  Note that there is a high chance
   that both the WTP and the AC's sequence numbers will become out of
   sync.

   When a Request message is retransmitted, it MUST be re-encrypted via
   the DTLS stack.  If the peer had received the Request message, and
   the corresponding Response message was lost, it is necessary to
   ensure that retransmitted Request messages are not identified as
   replays by the DTLS stack.  Similarly, any cached Response messages
   that are retransmitted as a result of receiving a retransmitted
   Request message MUST be re-encrypted via DTLS.

   Duplicate Response messages, identified by the Sequence Number field
   in the CAPWAP Control message header, SHOULD be discarded upon
   receipt.

4.6.  CAPWAP Protocol Message Elements

   This section defines the CAPWAP Protocol message elements that are
   included in CAPWAP protocol control messages.

   Message elements are used to carry information needed in control
   messages.  Every message element is identified by the Type Value
   field, defined below.  The total length of the message elements is
   indicated in the message element's length field.

   All of the message element definitions in this document use a diagram
   similar to the one below in order to depict its format.  Note that to
   simplify this specification, these diagrams do not include the header
   fields (Type and Length).  The header field values are defined in the
   message element descriptions.

Top      Up      ToC       Page 59 
   Unless otherwise specified, a control message that lists a set of
   supported (or expected) message elements MUST NOT expect the message
   elements to be in any specific order.  The sender MAY include the
   message elements in any order.  Unless otherwise noted, one message
   element of each type is present in a given control message.

   Unless otherwise specified, any configuration information sent by the
   AC to the WTP MAY be saved to non-volatile storage (see Section 8.1)
   for more information).

   Additional message elements may be defined in separate IETF
   documents.

   The format of a message element uses the TLV format shown here:

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

   The 16-bit Type field identifies the information carried in the Value
   field and Length (16 bits) indicates the number of bytes in the Value
   field.  The value of zero (0) is reserved and MUST NOT be used.  The
   rest of the Type field values are allocated as follows:

              Usage                              Type Values

   CAPWAP Protocol Message Elements                   1 - 1023
   IEEE 802.11 Message Elements                    1024 - 2047
   Reserved for Future Use                         2048 - 3071
   EPCGlobal Message Elements                      3072 - 4095
   Reserved for Future Use                         4096 - 65535

   The table below lists the CAPWAP protocol Message Elements and their
   Type values.

Top      Up      ToC       Page 60 
   CAPWAP Message Element                            Type Value

   AC Descriptor                                         1
   AC IPv4 List                                          2
   AC IPv6 List                                          3
   AC Name                                               4
   AC Name with Priority                                 5
   AC Timestamp                                          6
   Add MAC ACL Entry                                     7
   Add Station                                           8
   Reserved                                              9
   CAPWAP Control IPV4 Address                          10
   CAPWAP Control IPV6 Address                          11
   CAPWAP Local IPV4 Address                            30
   CAPWAP Local IPV6 Address                            50
   CAPWAP Timers                                        12
   CAPWAP Transport Protocol                            51
   Data Transfer Data                                   13
   Data Transfer Mode                                   14
   Decryption Error Report                              15
   Decryption Error Report Period                       16
   Delete MAC ACL Entry                                 17
   Delete Station                                       18
   Reserved                                             19
   Discovery Type                                       20
   Duplicate IPv4 Address                               21
   Duplicate IPv6 Address                               22
   ECN Support                                          53
   Idle Timeout                                         23
   Image Data                                           24
   Image Identifier                                     25
   Image Information                                    26
   Initiate Download                                    27
   Location Data                                        28
   Maximum Message Length                               29
   MTU Discovery Padding                                52
   Radio Administrative State                           31
   Radio Operational State                              32
   Result Code                                          33
   Returned Message Element                             34
   Session ID                                           35
   Statistics Timer                                     36
   Vendor Specific Payload                              37
   WTP Board Data                                       38
   WTP Descriptor                                       39
   WTP Fallback                                         40
   WTP Frame Tunnel Mode                                41
   Reserved                                             42

Top      Up      ToC       Page 61 
   Reserved                                             43
   WTP MAC Type                                         44
   WTP Name                                             45
   Unused/Reserved                                      46
   WTP Radio Statistics                                 47
   WTP Reboot Statistics                                48
   WTP Static IP Address Information                    49

4.6.1.  AC Descriptor

   The AC Descriptor message element is used by the AC to communicate
   its current state.  The value contains the following fields.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Stations           |             Limit             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Active WTPs          |            Max WTPs           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Security   |  R-MAC Field  |   Reserved1   |  DTLS Policy  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  AC Information Sub-Element...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   1 for AC Descriptor

   Length:   >= 12

   Stations:   The number of stations currently served by the AC

   Limit:   The maximum number of stations supported by the AC

   Active WTPs:   The number of WTPs currently attached to the AC

   Max WTPs:   The maximum number of WTPs supported by the AC

   Security:   An 8-bit mask specifying the authentication credential
      type supported by the AC (see Section 2.4.4).  The field has the
      following format:

         0 1 2 3 4 5 6 7
        +-+-+-+-+-+-+-+-+
        |Reserved |S|X|R|
        +-+-+-+-+-+-+-+-+

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

      S:    The AC supports the pre-shared secret authentication, as
            described in Section 12.6.

      X:    The AC supports X.509 Certificate authentication, as
            described in Section 12.7.

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

   R-MAC Field:   The AC supports the optional Radio MAC Address field
      in the CAPWAP transport header (see Section 4.3).  The following
      enumerated values are supported:

      0 -  Reserved

      1 -  Supported

      2 -  Not Supported

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

   DTLS Policy:   The AC communicates its policy on the use of DTLS for
      the CAPWAP data channel.  The AC MAY communicate more than one
      supported option, represented by the bit field below.  The WTP
      MUST abide by one of the options communicated by AC.  The field
      has the following format:

         0 1 2 3 4 5 6 7
        +-+-+-+-+-+-+-+-+
        |Reserved |D|C|R|
        +-+-+-+-+-+-+-+-+

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

      D:    DTLS-Enabled Data Channel Supported

      C:    Clear Text Data Channel Supported

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

   AC Information Sub-Element:   The AC Descriptor message element
      contains multiple AC Information sub-elements, and defines two
      sub-types, each of which MUST be present.  The AC Information sub-
      element has the following format:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                AC Information Vendor Identifier               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      AC Information Type      |     AC Information Length     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     AC Information Data...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      AC Information Vendor Identifier:   A 32-bit value containing the
         IANA-assigned "Structure of Management Information (SMI)
         Network Management Private Enterprise Codes".

      AC Information Type:   Vendor-specific encoding of AC information
         in the UTF-8 format [RFC3629].  The following enumerated values
         are supported.  Both the Hardware and Software Version sub-
         elements MUST be included in the AC Descriptor message element.
         The values listed below are used in conjunction with the AC
         Information Vendor Identifier field, whose value MUST be set to
         zero (0).  This field, combined with the AC Information Vendor
         Identifier set to a non-zero (0) value, allows vendors to use a
         private namespace.

Top      Up      ToC       Page 64 
         4 -   Hardware Version: The AC's hardware version number.

         5 -   Software Version: The AC's Software (firmware) version
               number.

      AC Information Length:   Length of vendor-specific encoding of AC
         information, with a maximum size of 1024.

      AC Information Data:   Vendor-specific encoding of AC information.

4.6.2.  AC IPv4 List

   The AC IPv4 List message element is used to configure a WTP with the
   latest list of ACs available for the WTP to join.


        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       AC IP Address[]                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   2 for AC IPv4 List

   Length:   >= 4

   AC IP Address:   An array of 32-bit integers containing AC IPv4
      Addresses, containing no more than 1024 addresses.

4.6.3.  AC IPv6 List

   The AC IPv6 List message element is used to configure a WTP with the
   latest list of ACs available for the WTP to join.


        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       AC IP Address[]                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       AC IP Address[]                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       AC IP Address[]                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       AC IP Address[]                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 65 
   Type:   3 for AC IPV6 List

   Length:   >= 16

   AC IP Address:   An array of 128-bit integers containing AC IPv6
      Addresses, containing no more than 1024 addresses.

4.6.4.  AC Name

   The AC Name message element contains an UTF-8 [RFC3629]
   representation of the AC identity.  The value is a variable-length
   byte string.  The string is NOT zero terminated.

      0
      0 1 2 3 4 5 6 7
     +-+-+-+-+-+-+-+-+
     |   Name ...
     +-+-+-+-+-+-+-+-+

   Type:   4 for AC Name

   Length:   >= 1

   Name:   A variable-length UTF-8 encoded string [RFC3629] containing
      the AC's name, whose maximum size MUST NOT exceed 512 bytes.

4.6.5.  AC Name with Priority

   The AC Name with Priority message element is sent by the AC to the
   WTP to configure preferred ACs.  The number of instances of this
   message element is equal to the number of ACs configured on the WTP.
   The WTP also uses this message element to send its configuration to
   the AC.

      0                   1
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Priority  |   AC Name...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   5 for AC Name with Priority

   Length:   >= 2

   Priority:   A value between 1 and 255 specifying the priority order
      of the preferred AC.  For instance, the value of one (1) is used
      to set the primary AC, the value of two (2) is used to set the
      secondary, etc.

Top      Up      ToC       Page 66 
   AC Name:   A variable-length UTF-8 encoded string [RFC3629]
      containing the AC name, whose maximum size MUST NOT exceed 512
      bytes.

4.6.6.  AC Timestamp

   The AC Timestamp message element is sent by the AC to synchronize the
   WTP clock.

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

   Type:   6 for AC Timestamp

   Length:   4

   Timestamp:   The AC's current time, allowing all of the WTPs to be
      time synchronized in the format defined by Network Time Protocol
      (NTP) in RFC 1305 [RFC1305].  Only the most significant 32 bits of
      the NTP time are included in this field.

4.6.7.  Add MAC ACL Entry

   The Add MAC Access Control List (ACL) Entry message element is used
   by an AC to add a MAC ACL list entry on a WTP, ensuring that the WTP
   no longer provides service to the MAC addresses provided in the
   message.  The MAC addresses provided in this message element are not
   expected to be saved in non-volatile memory on the WTP.  The MAC ACL
   table on the WTP is cleared every time the WTP establishes a new
   session with an 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Num of Entries|    Length     |         MAC Address ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   7 for Add MAC ACL Entry

   Length:   >= 8

   Num of Entries:   The number of instances of the Length/MAC Address
      fields in the array.  This value MUST NOT exceed 255.

Top      Up      ToC       Page 67 
   Length:  The length of the MAC Address field.  The formats and
      lengths specified in [EUI-48] and [EUI-64] are supported.

   MAC Address:   MAC addresses to add to the ACL.

4.6.8.  Add Station

   The Add Station message element is used by the AC to inform a WTP
   that it should forward traffic for a station.  The Add Station
   message element is accompanied by technology-specific binding
   information element(s), which may include security parameters.
   Consequently, the security parameters MUST be applied by the WTP for
   the station.

   After station policy has been delivered to the WTP through the Add
   Station message element, an AC MAY change any policies by sending a
   modified Add Station message element.  When a WTP receives an Add
   Station message element for an existing station, it MUST override any
   existing state for the station.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Radio ID   |     Length    |          MAC Address ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  VLAN Name...
     +-+-+-+-+-+-+-+-+

   Type:   8 for Add Station

   Length:   >= 8

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

   Length:  The length of the MAC Address field.  The formats and
      lengths specified in [EUI-48] and [EUI-64] are supported.

   MAC Address:   The station's MAC address.

   VLAN Name:   An optional variable-length UTF-8 encoded string
      [RFC3629], with a maximum length of 512 octets, containing the
      VLAN Name on which the WTP is to locally bridge user data.  Note
      this field is only valid with WTPs configured in Local MAC mode.


Next RFC Part