+Network Working Group P. Calhoun, Editor
+Internet-Draft Cisco Systems, Inc.
+Expires: December 13, 2007 M. Montemurro, Editor
+ Research In Motion
+ D. Stanley, Editor
+ Aruba Networks
+ June 11, 2007
+
+
+ CAPWAP Protocol Specification
+ draft-ietf-capwap-protocol-specification-07
+
+Status of this Memo
+
+ By submitting this Internet-Draft, each author represents that any
+ applicable patent or other IPR claims of which he or she is aware
+ have been or will be disclosed, and any of which he or she becomes
+ aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on December 13, 2007.
+
+Copyright Notice
+
+ Copyright (C) The IETF Trust (2007).
+
+
+
+
+
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 1]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+Abstract
+
+ This specification defines the Control And Provisioning of Wireless
+ Access Points (CAPWAP) Protocol. The CAPWAP protocol meets the IETF
+ CAPWAP working group protocol requirements. The CAPWAP protocol is
+ designed to be flexible, allowing it to be used for a variety of
+ wireless technologies. This document describes the base CAPWAP
+ protocol. The CAPWAP protocol binding which defines extensions for
+ use with the IEEE 802.11 wireless LAN protocol is available in [12].
+ Extensions are expected to be defined to enable use of the CAPWAP
+ protocol with additional wireless technologies.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 2]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+1. Introduction
+
+ This document describes the CAPWAP Protocol, a standard,
+ interoperable protocol which enables an Access Controller (AC) to
+ manage a collection of Wireless Termination Points (WTPs). The
+ CAPWAP protocol is defined to be independent of layer 2 technology.
+
+ The emergence of centralized IEEE 802.11 Wireless Local Area Network
+ (WLAN) architectures, in which simple IEEE 802.11 WTPs are managed by
+ an Access Controller (AC) suggested that a standards based,
+ interoperable protocol could radically simplify the deployment and
+ management of wireless networks. WTPs require a set of dynamic
+ management and control functions related to their primary task of
+ connecting the wireless and wired mediums. Traditional protocols for
+ managing WTPs are either manual static configuration via HTTP,
+ proprietary Layer 2 specific or non-existent (if the WTPs are self-
+ contained). An IEEE 802.11 binding is defined in [12] to support use
+ of the CAPWAP protocol with IEEE 802.11 WLAN networks.
+
+ CAPWAP assumes a network configuration consisting of multiple WTPs
+ communicating via the Internet Protocol (IP) to an AC. WTPs are
+ viewed as remote RF interfaces controlled by the AC. The CAPWAP
+ protocol supports two modes of operation: Split and Local MAC. In
+ Split MAC mode all L2 wireless data and management frames are
+ encapsulated via the CAPWAP protocol and exchanged between the AC and
+ the WTP. As shown in Figure 1, the wireless frames received from a
+ mobile device, which is referred to in this specification as a
+ Station (STA), are directly encapsulated by the WTP and forwarded to
+ the AC.
+
+ +-+ wireless frames +-+
+ | |--------------------------------| |
+ | | +-+ | |
+ | |--------------| |---------------| |
+ | |wireless PHY/ | | CAPWAP | |
+ | | MAC sublayer | | | |
+ +-+ +-+ +-+
+ STA WTP AC
+
+ Figure 1: Representative CAPWAP Architecture for Split MAC
+
+ The Local MAC mode of operation allows for the data frames to be
+ either locally bridged, or tunneled as 802.3 frames. The latter
+ implies that the WTP performs the 802 bridging function. In either
+ case the L2 wireless management frames are processed locally by the
+ WTP, and then forwarded to the AC. Figure 2 shows the Local MAC
+ mode, in which a station transmits a wireless frame which is
+ encapsulated in an 802.3 frame and forwarded to the AC.
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 3]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ +-+wireless frames +-+ 802.3 frames +-+
+ | |----------------| |--------------| |
+ | | | | | |
+ | |----------------| |--------------| |
+ | |wireless PHY/ | | CAPWAP | |
+ | | MAC sublayer | | | |
+ +-+ +-+ +-+
+ STA WTP AC
+
+ Figure 2: Representative CAPWAP Architecture for Local MAC
+
+ Provisioning WTPs with security credentials, and managing which WTPs
+ are authorized to provide service are traditionally handled by
+ proprietary solutions. Allowing these functions to be performed from
+ a centralized AC in an interoperable fashion increases manageability
+ and allows network operators to more tightly control their wireless
+ network infrastructure.
+
+1.1. Goals
+
+ The goals for the CAPWAP protocol are listed below:
+
+ 1. To centralize the authentication and policy enforcement functions
+ for a wireless network. The AC may also provide centralized
+ bridging, forwarding, and encryption of user traffic.
+ Centralization of these functions will enable reduced cost and
+ higher efficiency by applying the capabilities of network
+ processing silicon to the wireless network, as in wired LANs.
+
+ 2. To enable shifting of the higher level protocol processing from
+ the WTP. This leaves the time critical applications of wireless
+ control and access in the WTP, making efficient use of the
+ computing power available in WTPs which are the subject to severe
+ cost pressure.
+
+ 3. To provide a generic encapsulation and transport mechanism,
+ enabling the CAPWAP protocol to be applied to many access point
+ types in the future, via a specific wireless binding.
+
+ The CAPWAP protocol concerns itself solely with the interface between
+ the WTP and the AC. Inter-AC and station-to AC-communication are
+ strictly outside the scope of this document.
+
+1.2. Conventions used in this document
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [1].
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 4]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+1.3. Contributing Authors
+
+ This section lists and acknowledges the authors of significant text
+ and concepts included in this specification.
+
+ The CAPWAP Working Group selected the Lightweight Access Point
+ Protocol (LWAPP) [add reference, when available] to be used as the
+ basis of the CAPWAP protocol specification. The following people are
+ authors of the LWAPP document:
+
+ Bob O'Hara, Cisco Systems, Inc.
+ 170 West Tasman Drive, San Jose, CA 95134
+ Phone: +1 408-853-5513, Email: bob.ohara@cisco.com
+
+ Pat Calhoun, Cisco Systems, Inc.
+ 170 West Tasman Drive, San Jose, CA 95134
+ Phone: +1 408-853-5269, Email: pcalhoun@cisco.com
+
+ Rohit Suri, Cisco Systems, Inc.
+ 170 West Tasman Drive, San Jose, CA 95134
+ Phone: +1 408-853-5548, Email: rsuri@cisco.com
+
+ Nancy Cam Winget, Cisco Systems, Inc.
+ 170 West Tasman Drive, San Jose, CA 95134
+ Phone: +1 408-853-0532, Email: ncamwing@cisco.com
+
+ Scott Kelly, Aruba Networks
+ 1322 Crossman Ave, Sunnyvale, CA 94089
+ Phone: +1 408-754-8408, Email: skelly@arubanetworks.com
+
+ Michael Glenn Williams, Nokia, Inc.
+ 313 Fairchild Drive, Mountain View, CA 94043
+ Phone: +1 650-714-7758, Email: Michael.G.Williams@Nokia.com
+
+ Sue Hares, Nexthop Technologies, Inc.
+ 825 Victors Way, Suite 100, Ann Arbor, MI 48108
+ Phone: +1 734 222 1610, Email: shares@nexthop.com
+
+ DTLS is used as the security solution for the CAPWAP protocol. The
+ following people are authors of significant DTLS-related text
+ included in this document:
+
+ Scott Kelly, Aruba Networks
+ 1322 Crossman Ave, Sunnyvale, CA 94089
+ Phone: +1 408-754-8408, Email: skelly@arubanetworks.com
+
+ Eric Rescorla, Network Resonance
+ 2483 El Camino Real, #212,Palo Alto CA, 94303
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 5]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ Email: ekr@networkresonance.com
+
+ The concept of using DTLS to secure the CAPWAP protocol was part of
+ the Secure Light Access Point Protocol (SLAPP) proposal [add
+ reference when available]. The following people are authors of the
+ SLAPP proposal:
+
+ Partha Narasimhan, Aruba Networks
+ 1322 Crossman Ave, Sunnyvale, CA 94089
+ Phone: +1 408-480-4716, Email: partha@arubanetworks.com
+
+ Dan Harkins, Tropos Networks
+ 555 Del Rey Avenue, Sunnyvale, CA, 95085
+ Phone: +1 408 470 7372, Email: dharkins@tropos.com
+
+ Subbu Ponnuswamy, Aruba Networks
+ 1322 Crossman Ave, Sunnyvale, CA 94089
+ Phone: +1 408-754-1213, Email: subbu@arubanetworks.com
+
+
+ The following individuals contributed significant security related
+ text to the draft:
+
+ T. Charles Clancy, Laboratory for Telecommunications Sciences,
+ 8080 Greenmead Drive, College Park, MD 20740
+ Phone: +1 240-373-5069, Email: clancy@ltsnet.net
+
+ Scott Kelly, Aruba Networks
+ 1322 Crossman Ave, Sunnyvale, CA 94089
+ Phone: +1 408-754-8408, Email: skelly@arubanetworks.com
+
+1.4. Terminology
+
+ Access Controller (AC): The network entity that provides WTPs access
+ to the network infrastructure in the data plane, control plane,
+ management plane, or a combination therein.
+
+ CAPWAP Control Channel: A bi-directional flow defined by the AC IP
+ Address, WTP IP Address, AC control port, WTP control port and the
+ transport-layer protocol (UDP or UDP-Lite) over which CAPWAP control
+ packets are sent and received.
+
+ CAPWAP Data Channel: A bi-directional flow defined by the AC IP
+ Address, WTP IP Address, AC data port, WTP data port, and the
+ transport-layer protocol (UDP or UDP-Lite) over which CAPWAP data
+ packets are sent and received.
+
+ Station (STA): A device that contains an IEEE 802.11 conformant
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 6]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ medium access control (MAC) and physical layer (PHY) interface to the
+ wireless medium (WM).
+
+ Wireless Termination Point (WTP): The physical or network entity that
+ contains an RF antenna and wireless PHY to transmit and receive
+ station traffic for wireless access networks.
+
+ This document uses additional terminology defined in [15].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 7]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+2. Protocol Overview
+
+ The CAPWAP protocol is a generic protocol defining AC and WTP control
+ and data plane communication via a CAPWAP protocol transport
+ mechanism. CAPWAP control messages, and optionally CAPWAP data
+ messages, are secured using Datagram Transport Layer Security (DTLS)
+ [7]. DTLS is a standards-track IETF protocol based upon TLS. The
+ underlying security-related protocol mechanisms of TLS have been
+ successfully deployed for many years.
+
+ The CAPWAP protocol Transport layer carries two types of payload,
+ CAPWAP Data messages and CAPWAP Control messages. CAPWAP Data
+ messages encapsulate forwarded wireless frames. CAPWAP protocol
+ Control messages are management messages exchanged between a WTP and
+ an AC. The CAPWAP Data and Control packets are sent over separate
+ UDP ports. Since both data and control packets can exceed the
+ Maximum Transmission Unit (MTU) length, the payload of a CAPWAP data
+ or control message can be fragmented. The fragmentation behavior is
+ defined in Section 3.
+
+ The CAPWAP Protocol begins with a discovery phase. The WTPs send a
+ Discovery Request message, causing any Access Controller (AC)
+ receiving the message to respond with a Discovery Response message.
+ From the Discovery Response messages received, a WTP selects an AC
+ with which to establish a secure DTLS session. CAPWAP protocol
+ messages will be fragmented to the maximum length discovered to be
+ supported by the network.
+
+ Once the WTP and the AC have completed DTLS session establishment, a
+ configuration exchange occurs in which both devices agree on version
+ information. During this exchange the WTP may receive provisioning
+ settings. The WTP is then enabled for operation.
+
+ When the WTP and AC have completed the version and provision exchange
+ and the WTP is enabled, the CAPWAP protocol is used to encapsulate
+ the wireless data frames sent between the WTP and AC. The CAPWAP
+ protocol will fragment the L2 frames if the size of the encapsulated
+ wireless user data (Data) or protocol control (Management) frames
+ causes the resulting CAPWAP protocol packet to exceed the MTU
+ supported between the WTP and AC. Fragmented CAPWAP packets are
+ reassembled to reconstitute the original encapsulated payload.
+
+ The CAPWAP protocol provides for the delivery of commands from the AC
+ to the WTP for the management of stations that are communicating with
+ the WTP. This may include the creation of local data structures in
+ the WTP for the stations and the collection of statistical
+ information about the communication between the WTP and the stations.
+ The CAPWAP protocol provides a mechanism for the AC to obtain
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 8]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ statistical information collected by the WTP.
+
+ The CAPWAP protocol provides for a keep alive feature that preserves
+ the communication channel between the WTP and AC. If the AC fails to
+ appear alive, the WTP will try to discover a new AC.
+
+2.1. Wireless Binding Definition
+
+ The CAPWAP protocol is independent of a specific WTP radio
+ technology. Elements of the CAPWAP protocol are designed to
+ accommodate the specific needs of each wireless technology in a
+ standard way. Implementation of the CAPWAP protocol for a particular
+ wireless technology MUST follow the binding requirements defined for
+ that technology.
+
+ When defining a binding for wireless technologies, the authors MUST
+ include any necessary definitions for technology-specific messages
+ and all technology-specific message elements for those messages. At
+ a minimum, a binding MUST provide:
+
+ 1 - The definition for a binding-specific Statistics message
+ element, carried in the WTP Event Request message
+
+ 2 - A message element carried in the Station Configuration Request
+ message to configure station information on the WTP
+
+ 3 - A WTP Radio Information message element carried in the
+ Discovery, Primary Discovery and Join Request and Response
+ messages, indicating the binding specific radio types supported at
+ the WTP and AC.
+
+ If technology specific message elements are required for any of the
+ existing CAPWAP messages defined in this specification, they MUST
+ also be defined in the technology binding document.
+
+ The naming of binding-specific message elements MUST begin with the
+ name of the technology type, e.g., the binding for IEEE 802.11,
+ provided in [12], begins with "IEEE 802.11".
+
+ The CAPWAP binding concept is also used in any future specifications
+ that add functionality to either the base CAPWAP protocol
+ specification, or any published CAPWAP binding specification. A
+ separate WTP Radio Information message element MUST be created to
+ properly advertise support for the specification. This mechanism
+ allows for future protocol extensibility, while providing the
+ necessary capabilities advertisement, through the WTP Radio
+ Information message element, to ensure WTP/AC interoperability.
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 9]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+2.2. CAPWAP Session Establishment Overview
+
+ This section describes the session establishment process message
+ exchanges in the ideal case. The annotated ladder diagram shows the
+ AC on the right, the WTP on the left, and assumes the use of
+ certificates for DTLS authentication. The CAPWAP Protocol State
+ Machine is described in detail in Section 2.3. Note that DTLS allows
+ certain messages to be aggregated into a single frame, which is
+ denoted via an asterix in the following figure.
+
+ ============ ============
+ WTP AC
+ ============ ============
+ [----------- begin optional discovery ------------]
+
+ Discover Request
+ ------------------------------------>
+ Discover Response
+ <------------------------------------
+
+ [----------- end optional discovery ------------]
+
+ (-- begin DTLS handshake --)
+
+ ClientHello
+ ------------------------------------>
+ HelloVerifyRequest (with cookie)
+ <------------------------------------
+
+
+ ClientHello (with cookie)
+ ------------------------------------>
+ ServerHello,
+ Certificate,
+ ServerHelloDone*
+ <------------------------------------
+
+ (-- WTP callout for AC authorization --)
+
+ Certificate (optional),
+ ClientKeyExchange,
+ CertificateVerify (optional),
+ ChangeCipherSpec,
+ Finished*
+ ------------------------------------>
+
+ (-- AC callout for WTP authorization --)
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 10]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ ChangeCipherSpec,
+ Finished*
+ <------------------------------------
+
+ (-- DTLS session is established now --)
+
+ Join Request
+ ------------------------------------>
+ Join Response
+ <------------------------------------
+
+ (-- assume image is up to date --)
+
+ Configuration Status Request
+ ------------------------------------>
+ Configuration Status Response
+ <------------------------------------
+
+ (-- enter RUN state --)
+
+ :
+ :
+
+ Echo Request
+ ------------------------------------>
+ Echo Response
+ <------------------------------------
+
+ :
+ :
+
+ Event Request
+ ------------------------------------>
+ Event Response
+ <------------------------------------
+
+ :
+ :
+
+ At the end of the illustrated CAPWAP message exchange, the AC and WTP
+ are securely exchanging CAPWAP control messages. This is an
+ idealized illustration, provided to clarify protocol operation.
+ Section 2.3 provides a detailed description of the corresponding
+ state machine.
+
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 11]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+2.3. CAPWAP State Machine Definition
+
+ The following state diagram represents the lifecycle of a WTP-AC
+ session. Use of DTLS by the CAPWAP protocol results in the
+ juxtaposition of two nominally separate yet tightly bound state
+ machines. The DTLS and CAPWAP state machines are coupled through an
+ API consisting of commands (see Section 2.3.2.1) and notifications
+ (see Section 2.3.2.2). Certain transitions in the DTLS state machine
+ are triggered by commands from the CAPWAP state machine, while
+ certain transitions in the CAPWAP state machine are triggered by
+ notifications from the DTLS state machine.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 12]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ /-------------------------\
+ w| |
+ 5+----------+ x +------------+ |
+ | Run |-->| Reset |-\|
+ +----------+ +------------+ ||
+ u ^ ^ ^ y||
+ +------------+--------/ | | ||
+ | Data Check | /-------/ | ||
+ +------------+<-------\ | | ||
+ | | ||
+ /------------------+--------\ | ||
+ r| t| s| 4 v o| ||
+ +--------+ +-----------+ +--------------+||
+ | Join |---->| Configure | | Image Data |||
+ +--------+ q +-----------+ +--------------+||
+ ^ p| V| x| ||
+ | | \-------------------\ | ||
+ | \--------------------------------------\| | ||
+ \------------------------\ || | ||
+ /--------------<----------------+--------------\ || | ||
+ | /------------<-------------\ | | || | ||
+ | | m| |n z| vv v vv
+ | | +----------------+ +--------------+ +-----------+
+ | | | DTLS Setup | | DTLS Connect | | DTLS TD |
+ | | +----------------+ +--------------+ +-----------+
+ | | g| ^ ^ |h ^ ^
+ v v | | | | | |
+ | | | | | \-------\ | /-----------/
+ | | | | | | | |
+ | | v |e f| 2 v |j |k
+ | \->+------+ +------+ +-----------+
+ | | Idle |-->| Disc | | Authorize |
+ \--->+------+ a +------+ +-----------+
+ b| ^ |c
+ | | /----/
+ v d| |
+ +---------+ |
+ | Sulking |<-/
+ 3 +---------+
+
+ Figure 3: CAPWAP Integrated State Machine
+
+ The CAPWAP protocol state machine, depicted above, is used by both
+ the AC and the WTP. In cases where states are not shared (i.e. not
+ implemented in one or the other of the AC or WTP), this is explicitly
+ called out in the transition descriptions below. For every state
+ defined, only certain messages are permitted to be sent and received.
+ The CAPWAP control messages definitions specify the state(s) in which
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 13]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ each message is valid.
+
+ Since the WTP only communicates with a single AC, it only has a
+ single instance of the CAPWAP state machine. The AC has a separate
+ instance of the CAPWAP state machine per WTP it is communicating
+ with.
+
+2.3.1. CAPWAP Protocol State Transitions
+
+ This section describes the various state transitions, and the events
+ that cause them. This section does not discuss interactions between
+ DTLS- and CAPWAP-specific states. Those interactions, and DTLS-
+ specific states and transitions, are discussed in Section 2.3.2.
+
+ Idle to Discovery (a): This transition occurs once device
+ initialization is complete.
+
+ WTP: The WTP enters the Discovery state prior to transmitting the
+ first Discovery Request message (see Section 5.1). Upon
+ entering this state, the WTP sets the DiscoveryInterval timer
+ (see Section 4.7). The WTP resets the DiscoveryCount counter
+ to zero (0) (see Section 4.8). The WTP also clears all
+ information from ACs it may have received during a previous
+ Discovery phase.
+
+ AC: The AC does not maintain state information for the WTP upon
+ reception of the Discovery Request message, but it SHOULD
+ respond with a Discovery Response message (see Section 5.2).
+ This transition is a no-op for the AC.
+
+ Idle to Sulking (b): This transition occurs to force the WTP and AC
+ to enter a quiet period to avoid repeatedly attempting to
+ establish a connection.
+
+ WTP: The WTP enters this state when the FailedDTLSSessionCount or
+ the FailedDTLSAuthFailCount counter reaches
+ MaxFailedDTLSSessionRetry variable (see Section 4.8). Upon
+ entering this state, the WTP MUST start the SilentInterval
+ timer. While in the Sulking state, all received CAPWAP and
+ DTLS protocol messages received MUST be ignored.
+
+ AC: The AC enters this state with the specific WTP when the
+ FailedDTLSSessionCount or the FailedDTLSAuthFailCount counter
+ reaches MaxFailedDTLSSessionRetry variable (see Section 4.8).
+ Upon entering this state, the AC MUST start the SilentInterval
+ timer. While in the Sulking state, all received CAPWAP and
+ DTLS protocol messages received from the WTP MUST be ignored.
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 14]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ Discovery to Discovery (2): In the Discovery state, the WTP
+ determines which AC to connect to.
+
+ WTP: This transition occurs when the DiscoveryInterval timer
+ expires. If the WTP is configured with a list of ACs, it
+ transmits a Discovery Request message to every AC from which it
+ has not received a Discovery Response message. For every
+ transition to this event, the WTP increments the DiscoveryCount
+ counter. See Section 5.1 for more information on how the WTP
+ knows the ACs to which it should transmit the Discovery Request
+ messages. The WTP restarts the DiscoveryInterval timer
+ whenever it transmits Discovery Request messages.
+
+ AC: This is a no-op.
+
+ Discovery to Sulking (c): This transition occurs on a WTP when
+ Discovery or connectivity to the AC fails.
+
+ WTP: The WTP enters this state when the DiscoveryInterval timer
+ expires or the DiscoveryCount variable is equal to the
+ MaxDiscoveries variable (see Section 4.8). Upon entering this
+ state, the WTP MUST start the SilentInterval timer. While in
+ the Sulking state, all received CAPWAP protocol messages
+ received MUST be ignored.
+
+ AC: This is a no-op.
+
+ Sulking to Idle (d): This transition occurs on a WTP when it must
+ restart the discovery phase.
+
+ WTP: The WTP enters this state when the SilentInterval timer (see
+ Section 4.7) expires. The FailedDTLSSessionCount,
+ DiscoveryCount and FailedDTLSAuthFailCount counters are reset
+ to zero.
+
+ AC: The AC enters this state when the SilentInterval timer (see
+ Section 4.7) expires. The FailedDTLSSessionCount,
+ DiscoveryCount and FailedDTLSAuthFailCount counters are reset
+ to zero.
+
+ Sulking to Sulking (3): The Sulking state provides the silent
+ period, minimizing the possibility for Denial of Service (DoS)
+ attacks.
+
+ WTP: All packets received from the AC while in the sulking state
+ are ignored.
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 15]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ AC: All packets receive from the WTP while in the sulking state
+ are ignored.
+
+ Idle to DTLS Setup (e): This transition occurs to establish a secure
+ DTLS session with the peer.
+
+ WTP: The WTP initiates this transition by invoking the DTLSStart
+ command, which starts the DTLS session establishment with the
+ chosen AC. When the discovery phase is bypassed, it is assumed
+ the WTP has a locally configured AC.
+
+ AC: The AC initiates this transition by invoking the DTLSListen
+ command, which informs the DTLS stack that it is willing to
+ listen for an incoming session. The AC MAY provide optional
+ qualifiers in the DTLSListen command to only accept session
+ requests from specific WTPs.
+
+ Discovery to DTLS Setup (f): This transition occurs to establish a
+ secure DTLS session with the peer.
+
+ WTP: The WTP initiates this transition by invoking the DTLSStart
+ command (see Section 2.3.2.1), which starts the DTLS session
+ establishment with the chosen AC. The decision of which AC to
+ connect to is the result of the discovery phase, which is
+ described in Section 3.3.
+
+ AC: The AC initiates this transition by invoking the DTLSListen
+ command (see Section 2.3.2.1), which informs the DTLS stack
+ that it is willing to listen for an incoming session. The AC
+ MAY have maintained state information when it received the
+ Discovery Request message to provide optional qualifiers in the
+ DTLSListen command to only accept session requests from a
+ specific WTP. Note that maintaining state information based on
+ an unsecured Discovery Request message MAY lead to a Denial of
+ Service attack. Therefore the AC SHOULD ensure that the state
+ information is freed after a period, which is implementation
+ specific.
+
+ DTLS Setup to Idle (g): This transition occurs when the DTLS Session
+ failed to be established.
+
+ WTP: The WTP initiates this state transition when it receives a
+ DTLSEstablishFail notification from DTLS (see Section 2.3.2.2).
+ This error notification aborts the secure DTLS session
+ establishment. When this notification is received, the
+ FailedDTLSSessionCount counter is incremented.
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 16]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ AC: The WTP initiates this state transition when it receives a
+ DTLSEstablishFail notification from DTLS (see Section 2.3.2.2).
+ This error notification aborts the secure DTLS session
+ establishment. When this notification is received, the
+ FailedDTLSSessionCount counter is incremented.
+
+ DTLS Setup to Authorize (h): This transition occurs when an incoming
+ DTLS session is being established, and the DTLS stack needs
+ authorization to proceed with the session establishment.
+
+ WTP: This state transition occurs when the WTP receives the
+ DTLSPeerAuthorize notification (see Section 2.3.2.2). Upon
+ entering this state, the WTP performs an authorization check
+ against the AC credentials. See Section 2.4.4 for more
+ information on AC authorization.
+
+ AC: This state transition occurs when the AC receives the
+ DTLSPeerAuthorize notification (see Section 2.3.2.2). Upon
+ entering this state, the AC performs an authorization check
+ against the WTP credentials. See Section 2.4.4 for more
+ information on WTP authorization.
+
+ Authorize to DTLS Connect (j): This transition occurs to notify the
+ DTLS stack that the session should be established.
+
+ WTP: This state transition occurs when the WTP has either opted
+ to forgo the authorization check of the AC's credentials, or
+ the credentials were successfully authorized. This is done by
+ invoking the DTLSAccept DTLS command (see Section 2.3.2.1).
+
+ AC: This state transition occurs when the AC has either opted to
+ forgo the authorization check of the WTP's credentials, or the
+ credentials were successfully authorized. This is done by
+ invoking the DTLSAccept DTLS command (see Section 2.3.2.1).
+
+ Authorize to DTLS Teardown (k): This transition occurs to notify the
+ DTLS stack that the session should be aborted.
+
+ WTP: This state transition occurs when the WTP was unable to
+ authorize the AC, using the AC credentials. The WTP then
+ aborts the DTLS session by invoking the DTLSAbortSession
+ command (see Section 2.3.2.1).
+
+ AC: This state transition occurs when the AC was unable to
+ authorize the WTP, using the WTP credentials. The AC then
+ aborts the DTLS session by invoking the DTLSAbortSession
+ command (see Section 2.3.2.1).
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 17]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ DTLS Connect to Idle (m): This transition occurs when the DTLS
+ Session failed to be established.
+
+ WTP: This state transition occurs when the WTP receives either a
+ DTLSAborted or DTLSAuthenticateFail notification (see
+ Section 2.3.2.2), indicating that the DTLS session was not
+ successfully established. When this transition occurs due to
+ the DTLSAuthenticateFail notification, the
+ FailedDTLSAuthFailCount is incremented, otherwise the
+ FailedDTLSSessionCount counter is incremented.
+
+ AC: This state transition occurs when the AC receives either a
+ DTLSAborted or DTLSAuthenticateFail notification (see
+ Section 2.3.2.2), indicating that the DTLS session was not
+ successfully established. When this transition occurs due to
+ the DTLSAuthenticateFail notification, the
+ FailedDTLSAuthFailCount is incremented, otherwise the
+ FailedDTLSSessionCount counter is incremented.
+
+ DTLS Connect to Join (n): This transition occurs when the DTLS
+ Session is successfully established.
+
+ WTP: This state transition occurs when the WTP receives the
+ DTLSEstablished notification (see Section 2.3.2.2), indicating
+ that the DTLS session was successfully established. When this
+ notification is received, the FailedDTLSSessionCount counter is
+ set to zero.
+
+ AC: This state transition occurs when the AC receives the
+ DTLSEstablished notification (see Section 2.3.2.2), indicating
+ that the DTLS session was successfully established. When this
+ notification is received, the FailedDTLSSessionCount counter is
+ set to zero, and the WaitJoin timer is started (see
+ Section 4.7).
+
+ Join to DTLS Teardown (p): This transition occurs when the join
+ process failed.
+
+ WTP: This state transition occurs when the WTP receives a Join
+ Response message with a Result Code message element containing
+ an error, if the Image Identifier provided by the AC in the
+ Join Response message differs from the WTP's currently running
+ firmware version and the WTP has the requested image in its
+ non-volatile memory, or if the WaitDTLS timer expires. This
+ causes the WTP to initiate the DTLSShutdown command (see
+ Section 2.3.2.1). This transition also occurs if the WTP
+ receives one of the following DTLS notifications: DTLSAborted,
+ DTLSReassemblyFailure or DTLSPeerDisconnect.
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 18]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ AC: This state transition occurs either if the WaitJoin timer
+ expires or if the AC transmits a Join Response message with a
+ Result Code message element containing an error. This causes
+ the AC to initiate the DTLSShutdown command (see
+ Section 2.3.2.1). This transition also occurs if the AC
+ receives one of the following DTLS notifications: DTLSAborted,
+ DTLSReassemblyFailure or DTLSPeerDisconnect.
+
+ Join to Image Data (r): This state transition is used by the WTP and
+ the AC to download executable firmware.
+
+ WTP: The WTP enters the Image Data state when it receives a
+ successful Join Response message and determines and the
+ included Image Identifier message element is not the same as
+ its currently running image. The WTP also detects that the
+ requested image version is not currently available in the WTP's
+ non-volatile storage (see Section 9.1 for a full description of
+ the firmware download process). The WTP initializes the
+ EchoInterval timer (see Section 4.7), and transmits the Image
+ Data Request message (see Section 9.1.1) requesting the start
+ of the firmware download.
+
+ AC: This state transition occurs when the AC receives the Image
+ Data Request message from the WTP. The AC MUST transmit an
+ Image Data Response message (see Section 9.1.2) to the WTP,
+ which includes a portion of the firmware. The AC MUST start
+ the NeighborDeadInterval timer (see Section 4.7).
+
+ Join to Configure (q): This state transition is used by the WTP and
+ the AC to exchange configuration information.
+
+ WTP: The WTP enters the Configure state when it receives a
+ successful Join Response, and determines that the included
+ Image Identifier message element is the same as its currently
+ running image. The WTP transmits the Configuration Status
+ message (see Section 8.2) to the AC with message elements
+ describing its current configuration. The WTP also starts the
+ ResponseTimeout timer (see Section 4.7).
+
+ AC: This state transition occurs immediately after the AC
+ transmits the Join Response message to the WTP. If the AC
+ receives the Configuration Status message from the WTP, the AC
+ MUST transmit a Configuration Status Response message (see
+ Section 8.3) to the WTP, and MAY include specific message
+ elements to override the WTP's configuration. The WTP also
+ starts the ChangeStatePendingTimer timer (see Section 4.7).
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 19]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ Configure to Reset (s): This state transition is used to reset the
+ connection either due to an error during the configuration phase,
+ or when the WTP determines it needs to reset in order for the new
+ configuration to take effect.
+
+ WTP: The WTP enters the Reset state when it receives a
+ Configuration Status Response indicating an error or when it
+ determines that a reset of the WTP is required, due to the
+ characteristics of a new configuration.
+
+ AC: The AC transitions to the Reset state when it receives a
+ Change State Event message from the WTP that contains an error
+ for which AC policy does not permit the WTP to provide service.
+ This state transition also occurs when the AC
+ ChangeStatePendingTimer timer expires.
+
+ Configure to DTLS Teardown (V): This transition occurs when the
+ configuration process aborts due to a DTLS error.
+
+ WTP: The WTP enters this state when it receives one of the
+ following DTLS notifications: DTLSAborted,
+ DTLSReassemblyFailure or DTLSPeerDisconnect (see
+ Section 2.3.2.2). The WTP MAY tear down the DTLS session if it
+ receives frequent DTLSDecapFailure notifications.
+
+ AC: The AC enters this state when it receives one of the
+ following DTLS notifications: DTLSAborted,
+ DTLSReassemblyFailure or DTLSPeerDisconnect (see
+ Section 2.3.2.2). The WTP MAY tear down the DTLS session if it
+ receives frequent DTLSDecapFailure notifications.
+
+ Image Data to Image Data (4): The Image Data state is used by the
+ WTP and the AC during the firmware download phase.
+
+ WTP: The WTP enters the Image Data state when it receives an
+ Image Data Response message indicating that the AC has more
+ data to send.
+
+ AC: This state transition occurs when the AC receives the Image
+ Data Request message from the WTP while already in the Image
+ Data state, and it detects that the firmware download has not
+ completed.
+
+ Image Data to Reset (o): This state transition is used to reset the
+ DTLS connection prior to restarting the WTP after an image
+ download.
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 20]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ WTP: When an image download completes, the WTP enters the Reset
+ state. The WTP MAY also transition to this state upon
+ receiving an Image Data Response message from the AC (see
+ Section 9.1.2) indicating a failure.
+
+ AC: The AC enters the Reset state when the image download is
+ complete, or if an error occurs during the image download
+ process.
+
+ Image Data to DTLS Teardown (x): This transition occurs when the
+ firmware download process aborts due to a DTLS error.
+
+ WTP: The WTP enters this state when it receives one of the
+ following DTLS notifications: DTLSAborted,
+ DTLSReassemblyFailure or DTLSPeerDisconnect (see
+ Section 2.3.2.2). The WTP MAY tear down the DTLS session if it
+ receives frequent DTLSDecapFailure notifications.
+
+ AC: The AC enters this state when it receives one of the
+ following DTLS notifications: DTLSAborted,
+ DTLSReassemblyFailure or DTLSPeerDisconnect (see
+ Section 2.3.2.2). The WTP MAY tear down the DTLS session if it
+ receives frequent DTLSDecapFailure notifications.
+
+ Configure to Data Check (t): This state transition occurs when the
+ WTP and AC confirm the configuration.
+
+ WTP: The WTP enters this state when it receives a successful
+ Configuration Status Response message from the AC. The WTP
+ initializes the EchoInterval timer (see Section 4.7), and
+ transmits the Change State Event Request message (see
+ Section 8.6).
+
+ AC: This state transition occurs when the AC receives the Change
+ State Event Request message (see Section 8.6) from the WTP.
+ The AC responds with a Change State Event Response message (see
+ Section 8.7). The AC MUST start the NeighborDeadInterval timer
+ (see Section 4.7).
+
+ Data Check to Run (u): This state transition occurs when the linkage
+ between the control and data channels has occured, causing the WTP
+ and AC to enter their normal state of operation.
+
+ WTP: The WTP enters this state when it receives a successful
+ Change State Event Response message from the AC. The WTP
+ initiates the data channel, which MAY require the establishment
+ of a DTLS session, starts the DataChannelKeepAlive timer (see
+ Section 4.7) and transmits a Data Channel Keep Alive packet
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 21]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ (see Section 4.4.1). The WTP then starts the
+ DataChannelDeadInterval timer (see Section 4.7).
+
+ AC: This state transition occurs when the AC receives the Data
+ Channel Keep Alive packet (see Section 4.4.1), with a Session
+ ID message element matching that included by the WTP in the
+ Join Request message. Note that if AC policy is to require the
+ data channel to be encrypted, this process would also require
+ the establishment of a data channel DTLS session. Upon
+ receiving the Data Channel Keep Alive packet, the AC transmits
+ its own Data Channel Keep Alive packet.
+
+ Run to DTLS Teardown (u): This state transition occurs when an error
+ has occured in the DTLS stack, causing the DTLS session to be
+ torndown.
+
+ WTP: The WTP enters this state when it receives one of the
+ following DTLS notifications: DTLSAborted,
+ DTLSReassemblyFailure or DTLSPeerDisconnect (see
+ Section 2.3.2.2). The WTP MAY tear down the DTLS session if it
+ receives frequent DTLSDecapFailure notifications. The WTP also
+ transitions to this state if the underlying reliable
+ transport's RetransmitCount counter has reached the
+ MaxRetransmit variable (see Section 4.7).
+
+ AC: The AC enters this state when it receives one of the
+ following DTLS notifications: DTLSAborted,
+ DTLSReassemblyFailure or DTLSPeerDisconnect (see
+ Section 2.3.2.2). The WTP MAY tear down the DTLS session if it
+ receives frequent DTLSDecapFailure notifications. The AC
+ transitions to this state if the underlying reliable
+ transport's RetransmitCount counter has reached the
+ MaxRetransmit variable (see Section 4.7).
+
+ Run to Run (5): This is the normal state of operation.
+
+ WTP: This is the WTP's normal state of operation. There are many
+ events that result this state transition:
+
+ Configuration Update: The WTP receives a Configuration Update
+ Request message(see Section 8.4). The WTP MUST respond with
+ a Configuration Update Response message (see Section 8.5).
+
+ Change State Event: The WTP receives a Change State Event
+ Response message, or determines that it must initiate a
+ Change State Event Request message, as a result of a failure
+ or change in the state of a radio.
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 22]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ Echo Request: The WTP sends an Echo Request message
+ (Section 7.1) or receives the corresponding Echo Response
+ message, (see Section 7.2) from the AC.
+
+ Clear Config Request: The WTP receives a Clear Configuration
+ Request message (see Section 8.8). The WTP MUST reset its
+ configuration back to manufacturer defaults.
+
+ WTP Event: The WTP sends a WTP Event Request message,
+ delivering information to the AC (see Section 9.4). The WTP
+ receives a WTP Event Response message from the AC (see
+ Section 9.5).
+
+ Data Transfer: The WTP sends a Data Transfer Request message
+ to the AC (see Section 9.6). The WTP receives a Data
+ Transfer Response message from the AC (see Section 9.7).
+
+ Station Configuration Request: The WTP receives a Station
+ Configuration Request message (see Section 10.1), to which
+ it MUST respond with a Station Configuration Response
+ message (see Section 10.2).
+
+ AC: This is the AC's normal state of operation:
+
+ Configuration Update: The AC sends a Configuration Update
+ Request message (see Section 8.4) to the WTP to update its
+ configuration. The AC receives a Configuration Update
+ Response message (see Section 8.5) from the WTP.
+
+ Change State Event: The AC receives a Change State Event
+ Request message (see Section 8.6), to which it MUST respond
+ with the Change State Event Response message (see
+ Section 8.7).
+
+ Echo Request: The AC receives an Echo Request message (see
+ Section 7.1), to which it MUST respond with an Echo Response
+ message(see Section 7.2).
+
+ Clear Config Response: The AC receives a Clear Configuration
+ Response message from the WTP (see Section 8.9).
+
+ WTP Event: The AC receives a WTP Event Request message from
+ the WTP (see Section 9.4) and MUST generate a corresponding
+ WTP Event Response message (see Section 9.5).
+
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 23]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ Data Transfer: The AC receives a Data Transfer Request message
+ from the WTP (see Section 9.6) and MUST generate a
+ corresponding Data Transfer Response message (see
+ Section 9.7).
+
+ Station Configuration Request: The AC sends a Station
+ Configuration Request message (see Section 10.1) or receives
+ the corresponding Station Configuration Response message
+ (see Section 10.2) from the WTP.
+
+ Run to Reset (x): This state transition is used when either the AC
+ or WTP tear down the connection. This may occur as part of normal
+ operation, or due to error conditions.
+
+ WTP: The WTP enters the Reset state when it receives a Reset
+ Request message from the AC.
+
+ AC: The AC enters the Reset state when it transmits a Reset
+ Request message to the WTP.
+
+ Reset to DTLS Teardown (y): This transition occurs when the CAPWAP
+ reset is complete, to terminate the DTLS session.
+
+ WTP: This state transition occurs when the WTP receives a Reset
+ Response message. This causes the WTP to initiate the
+ DTLSShutdown command (see Section 2.3.2.1).
+
+ AC: This state transition occurs when the AC transmits a Reset
+ Response message. The AC does not invoke the DTLSShutdown
+ command (see Section 2.3.2.1).
+
+ DTLS Teardown to Idle (z): This transition occurs when the DTLS
+ session has been shutdown.
+
+ WTP: This state transition occurs when the WTP has successfully
+ cleaned up all resources associated with the control plane DTLS
+ session. The data plane DTLS session is also shutdown, and all
+ resources freed, if a DTLS session was established for the data
+ plane. Any timers set for the current instance of the state
+ machine are also cleared.
+
+ AC: This state transition occurs when the AC has successfully
+ cleaned up all resources associated with the control plane DTLS
+ session. The data plane DTLS session is also shutdown, and all
+ resources freed, if a DTLS session was established for the data
+ plane. Any timers set for the current instance of the state
+ machine are also cleared.
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 24]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+2.3.2. CAPWAP/DTLS Interface
+
+ This section describes the DTLS Commands used by CAPWAP, and the
+ notifications received from DTLS to the CAPWAP protocol stack.
+
+2.3.2.1. CAPWAP to DTLS Commands
+
+ Six commands are defined for the CAPWAP to DTLS API. These
+ "commands" are conceptual, and may be implemented as one or more
+ function calls. This API definition is provided to clarify
+ interactions between the DTLS and CAPWAP components of the integrated
+ CAPWAP state machine.
+
+ Below is a list of the minimal command API:
+
+ o DTLSStart is sent to the DTLS component to cause a DTLS session to
+ be established. Upon invoking the DTLSStart command, the WaitDTLS
+ timer is started. The WTP initiates this DTLS command, as the AC
+ does not initiate DTLS sessions.
+
+ o DTLSListen is sent to the DTLS component to allow the DTLS
+ component to listen for incoming DTLS session requests.
+
+ o DTLSAccept is sent to the DTLS component to allow the DTLS session
+ establishment to continue successfully.
+
+ o DTLSAbortSession is sent to the DTLS component to cause the
+ session that is in the process of being established to be aborted.
+ This command is also sent when the WaitDTLS timer expires. When
+ this command is executed, the FailedDTLSSessionCount counter is
+ incremented.
+
+ o DTLSShutdown is sent to the DTLS component to cause session
+ teardown.
+
+ o DTLSMtuUpdate is sent by the CAPWAP component to modify the MTU
+ size used by the DTLS component. The default size is 1468 bytes.
+
+2.3.2.2. DTLS to CAPWAP Notifications
+
+ DTLS notifications are defined for the DTLS to CAPWAP API. These
+ "notifications" are conceptual, and may be implemented in numerous
+ ways (e.g. as function return values). This API definition is
+ provided to clarify interactions between the DTLS and CAPWAP
+ components of the integrated CAPWAP state machine. It is important
+ to note that the notifications listed below MAY cause the CAPWAP
+ state machine to jump from one state to another using a state
+ transition not listed in Section 2.3.1. When a notification listed
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 25]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ below occurs, the target CAPWAP state shown in Figure 3 becomes the
+ current state.
+
+ Below is a list of the API notifications:
+
+ o DTLSPeerAuthorize is sent to the CAPWAP component during DTLS
+ session establishment once the peer's identity has been received.
+ This notification MAY be used by the CAPWAP component to authorize
+ the session, based on the peer's identity. The authorization
+ process will lead to the CAPWAP component initiating either the
+ DTLSAccept or DTLSAbortSession commands.
+
+ o DTLSEstablished is sent to the CAPWAP component to indicate that
+ that a secure channel now exists, using the parameters provided
+ during the DTLS initialization process. When this notification is
+ received, the FailedDTLSSessionCount counter is reset to zero.
+ When this notification is received, the WaitDTLS timer is stopped.
+
+ o DTLSEstablishFail is sent when the DTLS session establishment has
+ failed, either due to a local error, or due to the peer rejecting
+ the session establishment. When this notification is received,
+ the FailedDTLSSessionCount counter is incremented.
+
+ o DTLSAuthenticateFail is sent when DTLS session establishment
+ failed due to an authentication error. When this notification is
+ received, the FailedDTLSAuthFailCount counter is incremented.
+
+ o DTLSAborted is sent to the CAPWAP component to indicate that
+ session abort (as requested by CAPWAP) is complete; this occurs to
+ confirm a DTLS session abort, or when the WaitDTLS timer expires.
+ When this notification is received, the WaitDTLS timer is stopped.
+
+ o DTLSReassemblyFailure MAY be sent to the CAPWAP component to
+ indicate DTLS fragment reassembly failure.
+
+ o DTLSDecapFailure MAY be sent to the CAPWAP module to indicate a
+ decapsulation failure. DTLSDecapFailure MAY be sent to the CAPWAP
+ module to indicate an encryption/authentication failure. This
+ notification is intended for informative purposes only, and is not
+ intended to cause a change in the CAPWAP state machine (see
+ Section 12.4).
+
+ o DTLSPeerDisconnect is sent to the CAPWAP component to indicate the
+ DTLS session has been torn down. Note that this notification is
+ only received if the DTLS session has been established.
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 26]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+2.4. Use of DTLS in the CAPWAP Protocol
+
+ DTLS is used as a tightly-integrated, secure wrapper for the CAPWAP
+ protocol. In this document DTLS and CAPWAP are discussed as
+ nominally distinct entitites; however they are very closely coupled,
+ and may even be implemented inseparably. Since there are DTLS
+ library implementations currently available, and since security
+ protocols (e.g. IPsec, TLS) are often implemented in widely
+ available acceleration hardware, it is both convenient and forward-
+ looking to maintain a modular distinction in this document.
+
+ This section describes a detailed walk-through of the interactions
+ between the DTLS module and the CAPWAP module, via 'commands' (CAPWAP
+ to DTLS) and 'notifications' (DTLS to CAPWAP) as they would be
+ encountered during the normal course of operation.
+
+2.4.1. DTLS Handshake Processing
+
+ Details of the DTLS handshake process are specified in [8]. This
+ section describes the interactions between the DTLS session
+ establishment process and the CAPWAP protocol. Note that the
+ conceptual DTLS state is shown below to help understand the point at
+ which the DTLS states transition. In the normal case, the DTLS
+ handshake will proceed as follows (NOTE: this example uses
+ certificates, but preshared keys are also supported):
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 27]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ ============ ============
+ WTP AC
+ ============ ============
+ ClientHello ------>
+ <------ HelloVerifyRequest
+ (with cookie)
+
+ ClientHello ------>
+ (with cookie)
+ <------ ServerHello
+ <------ Certificate
+ <------ ServerHelloDone
+
+ (WTP callout for AC authorization
+ occurs in CAPWAP Auth state)
+
+ Certificate*
+ ClientKeyExchange
+ CertificateVerify*
+ [ChangeCipherSpec]
+ Finished ------>
+
+ (AC callout for WTP authorization
+ occurs in CAPWAP Auth state)
+
+ [ChangeCipherSpec]
+ <------ Finished
+
+
+ DTLS, as specified, provides its own retransmit timers with an
+ exponential back-off. However, DTLS will never terminate the
+ handshake due to non-responsiveness; instead, DTLS will continue to
+ increase its back-off timer period. Hence, timing out incomplete
+ DTLS handshakes is entirely the responsiblity of the CAPWAP module.
+
+ The DTLS implementation used by CAPWAP MUST support TLS Session
+ Resumption. Session resumption is used to establish the DTLS session
+ used for the data channel. The DTLS implementation on the WTP MUST
+ return some unique identifier to the CAPWAP module to enable
+ subsequent establishment of a DTLS-encrypted data channel, if
+ necessary.
+
+2.4.2. DTLS Session Establishment
+
+ The WTP, either through the Discovery process, or through pre-
+ configuration, determines the AC to connect to. The WTP uses the
+ DTLSStart command to request that a secure connection be established
+ to the selected AC. Prior to initiation of the DTLS handshake, the
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 28]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ WTP sets the WaitDTLS timer. Upon receiving the DTLSPeerAuthorize
+ DTLS notification, the AC sets the WaitDTLS timer. If the
+ DTLSEstablished notification is not received prior to timer
+ expiration, the DTLS session is aborted by issuing the
+ DTLSAbortSession DTLS command. This notification causes the CAPWAP
+ module to transition to the Idle state. Upon receiving a
+ DTLSEstablished notification, the WaitDTLS timer is deactivated.
+
+2.4.3. DTLS Error Handling
+
+ If the AC does not respond to any DTLS messages sent by the WTP, the
+ DTLS specification calls for the WTP to retransmit these messages.
+ If the WaitDTLS timer expires, CAPWAP will issue the DTLSAbortSession
+ command, causing DTLS to terminate the handshake and remove any
+ allocated session context. Note that DTLS MAY send a single TLS
+ Alert message to the AC to indicate session termination.
+
+ If the WTP does not respond to any DTLS messages sent by the AC, the
+ CAPWAP protocol allows for three possiblities, listed below. Note
+ that DTLS MAY send a single TLS Alert message to the AC to indicate
+ session termination.
+
+ o The message was lost in transit; in this case, the WTP will re-
+ transmit its last outstanding message, since it did not receive a
+ reply.
+
+ o The WTP sent a DTLS Alert, which was lost in transit; in this
+ case, the AC's WaitDTLS timer will expire, and the session will be
+ terminated.
+
+ o Communication with the WTP has completely failed; in this case,
+ the AC's WaitDTLS timer will expire, and the session will be
+ terminated.
+
+ The DTLS specification provides for retransmission of unacknowledged
+ requests. If retransmissions remain unacknowledged, the WaitDTLS
+ timer will eventually expire, at which time the CAPWAP component will
+ terminate the session.
+
+ If a cookie fails to validate, this could represent a WTP error, or
+ it could represent a DoS attack. Hence, AC resource utilization
+ SHOULD be minimized. The AC MAY log a message indicating the
+ failure, but SHOULD NOT attempt to reply to the WTP.
+
+ Since DTLS handshake messages are potentially larger than the maximum
+ record size, DTLS supports fragmenting of handshake messages across
+ multiple records. There are several potential causes of re-assembly
+ errors, including overlapping and/or lost fragments. The DTLS
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 29]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ component MUST send a DTLSReassemblyFailure notification to the
+ CAPWAP component. Whether precise information is given along with
+ notification is an implementation issue, and hence is beyond the
+ scope of this document. Upon receipt of such an error, the CAPWAP
+ component SHOULD log an appropriate error message. Whether
+ processing continues or the DTLS session is terminated is
+ implementation dependent.
+
+ DTLS decapsulation errors consist of three types: decryption errors,
+ authentication errors, and malformed DTLS record headers. Since DTLS
+ authenticates the data prior to encapsulation, if decryption fails,
+ it is difficult to detect this without first attempting to
+ authenticate the packet. If authentication fails, a decryption error
+ is also likely, but not guaranteed. Rather than attempt to derive
+ (and require the implementation of) algorithms for detecting
+ decryption failures, decryption failures are reported as
+ authentication failures. The DTLS component MUST provide a
+ DTLSDecapFailure notification to the CAPWAP component when such
+ errors occur. If a malformed DTLS record header is detected, the
+ packets SHOULD be silently discarded, and the receiver MAY log an
+ error message.
+
+ There is currently only one encapsulation error defined: MTU
+ exceeded. As part of DTLS session establishment, the CAPWAP
+ component informs the DTLS component of the MTU size. This may be
+ dynamically modified at any time when the CAPWAP component sends the
+ DTLSMtuUpdate command to the DTLS component (see Section 2.3.2.1).
+ The DTLS component returns this notification to the CAPWAP component
+ whenever a transmission request will result in a packet which exceeds
+ the MTU.
+
+2.4.4. DTLS EndPoint Authentication and Authorization
+
+ DTLS supports endpoint authentication with certificates or preshared
+ keys. The TLS algorithm suites for each endpoint authentication
+ method are described below.
+
+2.4.4.1. Authenticating with Certificates
+
+ Note that only block ciphers are currently recommended for use with
+ DTLS. To understand the reasoning behind this, see [17]. At
+ present, the following algorithms MUST be supported when using
+ certificates for CAPWAP authentication:
+
+ o TLS_RSA_WITH_AES_128_CBC_SHA
+
+ The following algorithms SHOULD be supported when using certificates:
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 30]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ o TLS_DH_RSA_WITH_AES_128_CBC_SHA
+
+ The following algorithms MAY be supported when using certificates:
+
+ o TLS_RSA_WITH_AES_256_CBC_SHA
+
+ o TLS_DH_RSA_WITH_AES_256_CBC_SHA
+
+2.4.4.2. Authenticating with Preshared Keys
+
+ Pre-shared keys present significant challenges from a security
+ perspective, and for that reason, their use is strongly discouraged.
+ Several methods for authenticating with preshared keys are defined
+ [6], and we focus on the following two:
+
+ o PSK key exchange algorithm - simplest method, ciphersuites use
+ only symmetric key algorithms
+
+ o DHE_PSK key exchange algorithm - use a PSK to authenticate a
+ Diffie-Hellman exchange. These ciphersuites give some additional
+ protection against dictionary attacks and also provide Perfect
+ Forward Secrecy (PFS).
+
+ The first approach (plain PSK) is susceptible to passive dictionary
+ attacks; hence, while this alorithm MUST be supported, special care
+ should be taken when choosing that method. In particular, user-
+ readable passphrases SHOULD NOT be used, and use of short PSKs SHOULD
+ be strongly discouraged.
+
+ The following cryptographic algorithms MUST be supported when using
+ preshared keys:
+
+ o TLS_PSK_WITH_AES_128_CBC_SHA
+
+ o TLS_DHE_PSK_WITH_AES_128_CBC_SHA
+
+ The following algorithms MAY be supported when using preshared keys:
+
+ o TLS_PSK_WITH_AES_256_CBC_SHA
+
+ o TLS_DHE_PSK_WITH_AES_256_CBC_SHA
+
+2.4.4.3. Certificate Usage
+
+ Certificate authorization by the AC and WTP is required so that only
+ an AC may perform the functions of an AC and that only a WTP may
+ perform the functions of a WTP. This restriction of functions to the
+ AC or WTP requires that the certificates used by the AC MUST be
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 31]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ distinguishable from the certificate used by the WTP. To accomplish
+ this differentiation, the x.509 certificates MUST include the
+ Extended Key Usage (EKU) certificate extension [4].
+
+ The EKU field indicates one or more purposes for which a certificate
+ may be used. It is an essential part in authorization. Its syntax
+ is as follows:
+
+ ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
+
+ KeyPurposeId ::= OBJECT IDENTIFIER
+
+
+ Here we define two KeyPurposeId values, one for the WTP and one for
+ the AC. Inclusion of one of these two values indicates a certificate
+ is authorized for use by a WTP or AC, respectively. These values are
+ formatted as id-kp fields.
+
+ id-kp OBJECT IDENTIFIER ::=
+ { iso(1) identified-organization(3) dod(6) internet(1)
+ security(5) mechanisms(5) pkix(7) 3 }
+
+ id-kp-capwapAC OBJECT IDENTIFIER ::= { id-kp 18 }
+
+ id-kp-capwapWTP OBJECT IDENTIFIER ::= { id-kp 19 }
+
+
+
+ For an AC, the id-kp-capwapAC EKU MUST be present in the certificate.
+ For a WTP, the id-kp-capwapWTP EKU MUST be present in the
+ certificate.
+
+ Part of the CAPWAP certificate validation process includes ensuring
+ that the proper EKU is included and allowing the CAPWAP session to be
+ established only if the extension properly represents the device.
+
+ The certificate common name (CN) for both the WTP and AC MUST be the
+ MAC address of that device. The MAC address MUST be formatted as
+ ASCII HEX, e.g. 01:23:45:67:89:ab.
+
+ ACs and WTPs SHOULD authorize (e.g. through access control lists)
+ certificates of devices to which they are connecting, based on the
+ MAC address and organizational information specified in the O and OU
+ fields. The identities specified in the certificates bind a
+ particular DTLS session to a specific pair of mutually-authenticated
+ and authorized MAC addresses.
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 32]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+2.4.4.4. PSK Usage
+
+ When DTLS uses PSK Ciphersuites, the ServerKeyExchange message MUST
+ contain the "PSK identity hint" field and the ClientKeyExchange
+ message MUST contain the "PSK identity" field. These fields are used
+ to help the WTP select the appropriate PSK for use with the AC, and
+ then indicate to the AC which key is being used. When PSKs are
+ provisioned to WTPs and ACs, both the PSK Hint and PSK Identity for
+ the key MUST be specified.
+
+ The PSK Hint SHOULD uniquely identify the AC and the PSK Identity
+ SHOULD uniquely identify the WTP. It is RECOMMENDED that these hints
+ and identities be the ASCII HEX-formatted MAC addresses of the
+ respective devices, since each pairwise combination of WTP and AC
+ SHOULD have a unique PSK. The PSK hint and identity SHOULD be
+ sufficient to perform authorization, as simply having knowledge of a
+ PSK does not necessarily imply authorization.
+
+ If a single PSK is being used for multiple devices on a CAPWAP
+ network, which is NOT RECOMMENDED, the PSK Hint and Identity can no
+ longer be a MAC address, so appropriate hints and identities SHOULD
+ be selected to identify the group of devices to which the PSK is
+ provisioned.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 33]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+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 [11] transport protocols. The UDP protocol is used
+ with IPv4. When CAPWAP is used over IPv6, the UDP-Lite protocol is
+ used. This section describes how the CAPWAP protocol is carried over
+ IP and UDP/UDP-Lite transport protocols.
+
+3.1. UDP Transport
+
+ One of the CAPWAP protocol requirements is to allow a WTP to reside
+ behind a 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. 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 [to be IANA
+ assigned]. 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 [to be IANA assigned]. The
+ CAPWAP data port at the WTP can be any port selected by the WTP.
+
+3.2. UDP-Lite Transport
+
+ When CAPWAP is run over IPv6, UDP-Lite is used as the transport
+ protocol, reducing the checksum processing required for each packet
+ (compared to UDP and IPv6). When UDP-Lite is used, the checksum
+ field MUST have a coverage of 8 [11].
+
+ 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 chose 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
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 34]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ (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),
+ a well known multicast address or to the unicast IP address of the
+ AC. For IPv6 networks, since broadcast does not exist, the use of
+ "All ACs multicast address" 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.
+
+ 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:
+
+ DHCP: See [13] for more information on the use of DHCP to discover
+ AC IP addresses.
+
+ DNS: The DNS name "CAPWAP-AC-Address" MAY be resolvable to one or
+ more AC addresses.
+
+ 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 Index 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
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 35]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ 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 "middle box"
+ 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 configuration.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 36]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+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
+ 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:
+
+
+
+
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 37]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ 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 RFC 4347 [8].
+
+ 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 signalling 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
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 38]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ including the Maximum Message Length message element, see
+ Section 4.6.29 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 header is to avoid needing to perform byte
+ comparisons in order to guess whether the frame is DTLS encrypted or
+ not. 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 which contains the version of CAPWAP used in
+ this packet. The value for this specification is zero (0).
+
+ Payload Type: A 4 bit field which 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 includes 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 [8] always immediately follows this header. The format
+ of the CAPWAP DTLS Header is as follows:
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 39]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ 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 which is not encrypted or authenticated.
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 40]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ 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 which contains the Radio ID number for this
+ packet. Given that MAC Addresses are not necessarily unique
+ across physical radios in a WTP, the Radio Identifier (RID) field
+ is used to indiciate which physical radio the message is
+ associated with.
+
+ WBID: A 5 bit field which is the wireless binding identifier. The
+ identifier will indicate the type of wireless packet type
+ associated with the radio. The following values are defined:
+
+ 1 - IEEE 802.11
+
+ 2 - IEEE 802.16
+
+ 3 - 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 1, the packet is
+ the last fragment. When this bit is 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 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.
+
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 41]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ 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 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 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. This is useful in packets sent
+ from the WTP to the AC, when the native wireless frame format is
+ converted to 802.3 by the WTP. 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.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 42]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ Length: The length of the MAC Address field [18] [19].
+
+ 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 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Wireless ID | Length | Data
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Wireless ID: The wireless binding identifier. The following
+ values are defined:
+
+ 1 - IEEE 802.11
+
+ 2 - IEEE 802.16
+
+ 3 - EPCGlobal
+
+ Length: The length of the data field
+
+ Data: Wireless specific information, defined by the wireless
+ specific binding.
+
+ 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.
+
+ Both CAPWAP data messages are transmitted on the CAPWAP data channel.
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 43]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+4.4.1. CAPWAP Data Keepalive
+
+ 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. 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 Length field indicates the number of
+ bytes following the CAPWAP Header.
+
+ Message Element[0..N]: The message element(s) carry the information
+ pertinent to each of the CAPWAP Data Keepalive message. The
+ following message elements MUST be present in this CAPWAP message:
+
+ Session ID, see Section 4.6.35
+
+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
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 44]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ encapsulation requires that the bridging 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.
+
+ If the encapsulated frame would exceed the transport layer's MTU, the
+ sender is responsible for fragmentation of the frame, as specified in
+ Section 3.4.
+
+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
+ MUST be initiated using the TLS session resumption feature [7].
+
+ When establishing the DTLS-encrypted data channel, the WTP MUST
+ provide the identifier returned during the initialization of the
+ control channel to the DTLS component so it can perform the
+ resumption using the proper session information.
+
+ The AC DTLS implementation MUST NOT accept a session resumption
+ request for a DTLS session in which the control channel for the
+ session has been torn down.
+
+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.
+
+ Join: CAPWAP Join messages are used by a WTP to request service from
+ an AC, and for the AC to respond to the WTP.
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 45]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ 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 which 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] ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 46]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+4.5.1.1. Message Type
+
+ The Message Type field identifies the function of the CAPWAP control
+ message. The Message Type field is comprised of an IANA Enterprise
+ Number and an enterprise specific message type number. The first
+ three octets contain the enterprise number in network byte order,
+ with zero used for CAPWAP protocol defined message types and the IEEE
+ 802.11 IANA assigned enterprise number 13277 is used for IEEE 802.11
+ technology specific 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.
+
+ The valid values for CAPWAP Control Message Types are specified in
+ the table below:
+
+
+
+
+
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 47]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ CAPWAP Control Message Message Type
+ Value
+ Discovery Request 1
+ Discovery Response 2
+ Join Request 3
+ Join Response 4
+ Configuration Status 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.
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 48]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+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. Control Message Quality of Service
+
+ 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 Quality of Service
+ enabled CAPWAP device SHOULD use the following values:
+
+ 802.1P: The precedence value of 7 SHOULD be used.
+
+ DSCP: The DSCP tag value of 46 SHOULD be used.
+
+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
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 49]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ Response message is not received, the original Request message is
+ retransmitted. Implementations MAY cache Response messages to
+ respond to a retransmitted Request messages with minimal local
+ processing. Retransmitted Request messages MUST NOT be altered by
+ the sender. The sender MUST assume that the original Request message
+ was processed, but that the Response message was lost. Any
+ alterations to the original Request message MUST have a new Sequence
+ Number, and be treated as a new Request message by the receiver.
+
+ 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
+ subsequent time the same Request message is retransmitted, up to
+ MaxRetransmit but no more than half the EchoInterval timer (see
+ Section 4.7.5). Response messages are not subject to these timers.
+
+ 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 which 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 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.
+
+ Unless otherwise specified, a control message that lists a set of
+ supported (or expected) message elements MUST not expect the message
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 50]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ 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.
+
+ 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. Type field values are allocated as follows:
+
+ Usage Type Values
+
+ CAPWAP Protocol Message Elements 1-1023
+ IEEE 802.11 Message Elements 1024-2047
+ IEEE 802.16 Message Elements 2048 - 3071
+ EPCGlobal Message Elements 3072 - 4095
+ Reserved for Future Use 4096 - 65024
+
+ The table below lists the CAPWAP protocol Message Elements and their
+ Type values.
+
+ CAPWAP Message Element Type Value
+
+ AC Descriptor 1
+ AC IPv4 List 2
+ AC IPv6 List 3
+ AC Name 4
+ AC Name with Index 5
+ AC Timestamp 6
+ Add MAC ACL Entry 7
+ Add Station 8
+ Add Static MAC ACL Entry 9
+ CAPWAP Control IPV4 Address 10
+ CAPWAP Control IPV6 Address 11
+ CAPWAP Timers 12
+ Data Transfer Data 13
+ Data Transfer Mode 14
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 51]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ Decryption Error Report 15
+ Decryption Error Report Period 16
+ Delete MAC ACL Entry 17
+ Delete Station 18
+ Delete Static MAC ACL Entry 19
+ Discovery Type 20
+ Duplicate IPv4 Address 21
+ Duplicate IPv6 Address 22
+ Idle Timeout 23
+ Image Data 24
+ Image Identifier 25
+ Image Info 26
+ Initiate Download 27
+ Location Data 28
+ Maximum Message Length 29
+ MTU Discovery Padding 30
+ 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
+ WTP IPv4 IP Address 42
+ WTP IPv6 IP Address 43
+ WTP MAC Type 44
+ WTP Name 45
+ WTP Operational Statistics 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.
+
+
+
+
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 52]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Vendor Identifier |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type=4 | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Value...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Vendor Identifier |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type=5 | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Value...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+ 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: A 8 bit bit mask specifying the authentication credential
+ type supported by the AC. The following values are supported (see
+ Section 2.4.4):
+
+ 1 - X.509 Certificate Based
+
+ 2 - Pre-Shared Secret
+
+ R-MAC Field: The AC supports the optional Radio MAC Address field
+ in the CAPWAP transport Header (see Section 4.3).
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 53]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ 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
+ following bit field values are supported:
+
+ 1 - Clear Text Data Channel Supported
+
+ 2 - DTLS Enabled Data Channel Supported
+
+ Vendor Identifier: A 32-bit value containing the IANA assigned "SMI
+ Network Management Private Enterprise Codes"
+
+ Type: Vendor specific encoding of AC information. The following
+ values are supported. The Hardware and Software Version values
+ MUST be included.
+
+ 4 - Hardware Version: The AC's hardware version number.
+
+ 5 - Software Version: The AC's Software (firmware) version
+ number.
+
+ Length: Length of vendor specific encoding of AC information.
+
+ Value: 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[] |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 54]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ Type: 2 for AC IPv4 List
+
+ Length: >= 4
+
+ The AC IP Address: An array of 32-bit integers containing AC IPv4
+ 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[] |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+ Type: 3 for AC IPV6 List
+
+ Length: >= 16
+
+ The AC IP Address: An array of 128-bit integers containing AC IPv6
+ Addresses.
+
+4.6.4. AC Name
+
+ The AC Name message element contains an UTF-8 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 ...
+ +-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 55]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ Type: 4 for AC Name
+
+ Length: > 0
+
+ Name: A variable length UTF-8 encoded string containing the AC's
+ name
+
+4.6.5. AC Name with Index
+
+ The AC Name with Index 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.
+
+ 0 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Index | AC Name...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 5 for AC Name with Index
+
+ Length: > 2
+
+ Index: The index of the preferred server (1=primary, 2=secondary).
+
+ AC Name: A variable length UTF-8 encoded string containing the AC
+ name.
+
+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 [3].
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 56]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+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.
+
+ 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 Type/MAC Addresses
+ fields in the array.
+
+ Length: The length of the MAC Address field.
+
+ 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...
+ +-+-+-+-+-+-+-+-+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 57]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ Type: 8 for Add Station
+
+ Length: >= 8
+
+ Radio ID: An 8-bit value representing the radio
+
+ Length: The length of the MAC Address field.
+
+ MAC Address: The station's MAC Address
+
+ VLAN Name: An optional variable length UTF-8 encoded string
+ 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.
+
+4.6.9. Add Static MAC ACL Entry
+
+ The Add Static MAC ACL Entry message element is used by an AC to add
+ a permanent ACL entry on a WTP, ensuring that the WTP no longer
+ provides any service to the MAC addresses provided in the message.
+ The MAC Addresses provided in this message element are expected to be
+ saved in non-volative memory on 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Num of Entries| Length | MAC Address ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 9 for Add Static MAC ACL Entry
+
+ Length: >= 8
+
+ Num of Entries: The number of instances of the Type/MAC Addresses
+ fields in the array.
+
+ Length: The length of the MAC Address field.
+
+ MAC Address: MAC Addresses to add to the permanent ACL.
+
+4.6.10. CAPWAP Control IPv4 Address
+
+ The CAPWAP Control IPv4 Address message element is sent by the AC to
+ the WTP during the discovery process and is used by the AC to provide
+ the interfaces available on the AC, and the current number of WTPs
+ connected. When multiple CAPWAP Control IPV4 Address message
+ elements are returned, the WTP SHOULD perform load balancing across
+ the multiple interfaces.
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 58]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | IP Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | WTP Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 10 for CAPWAP Control IPv4 Address
+
+ Length: 6
+
+ IP Address: The IP Address of an interface.
+
+ WTP Count: The number of WTPs currently connected to the interface.
+
+4.6.11. CAPWAP Control IPv6 Address
+
+ The CAPWAP Control IPv6 Address message element is sent by the AC to
+ the WTP during the discovery process and is used by the AC to provide
+ the interfaces available on the AC, and the current number of WTPs
+ connected. This message element is useful for the WTP to perform
+ load balancing across multiple interfaces.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | IP Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | IP Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | IP Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | IP Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | WTP Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 11 for CAPWAP Control IPv6 Address
+
+ Length: 18
+
+ IP Address: The IP Address of an interface.
+
+ WTP Count: The number of WTPs currently connected to the interface.
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 59]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+4.6.12. CAPWAP Timers
+
+ The CAPWAP Timers message element is used by an AC to configure
+ CAPWAP timers on a WTP.
+
+ 0 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Discovery | Echo Request |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 12 for CAPWAP Timers
+
+ Length: 2
+
+ Discovery: The number of seconds between CAPWAP Discovery messages,
+ when the WTP is in the discovery phase.
+
+ Echo Request: The number of seconds between WTP Echo Request CAPWAP
+ messages. The default value for this message element is specified
+ in Section 4.7.5.
+
+4.6.13. Data Transfer Data
+
+ The Data Transfer Data message element is used by the WTP to provide
+ information to the AC for debugging purposes.
+
+ 0 1 2
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Data Type | Data Length | Data ....
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 13 for Data Transfer Data
+
+ Length: >= 3
+
+ Data Type: An 8-bit value the type of information being sent. The
+ following values are supported:
+
+ 1 - WTP Crash Data
+
+ 2 - WTP Memory Dump
+
+
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 60]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ Data Length: Length of data field.
+
+ Data: Debug information.
+
+4.6.14. Data Transfer Mode
+
+ The Data Transfer Mode message element is used by the WTP to indicate
+ the type of data transfer information it is sending to the AC for
+ debugging purposes.
+
+ 0
+ 0 1 2 3 4 5 6 7
+ +-+-+-+-+-+-+-+-+
+ | Data Type |
+ +-+-+-+-+-+-+-+-+
+
+ Type: 14 for Data Transfer Mode
+
+ Length: 1
+
+ Data Type: An 8-bit value the type of information being requested.
+ The following values are supported:
+
+ 1 - WTP Crash Data
+
+ 2 - WTP Memory Dump
+
+4.6.15. Decryption Error Report
+
+ The Decryption Error Report message element value is used by the WTP
+ to inform the AC of decryption errors that have occurred since the
+ last report. Note that this error reporting mechanism is not used if
+ encryption and decryption services are provided in the AC.
+
+ 0 1 2
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID |Num Of Entries | Length |MAC Address...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 15 for Decryption Error Report
+
+ Length: >= 9
+
+ Radio ID: The Radio Identifier refers to an interface index on the
+ WTP.
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 61]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ Num of Entries: The number of instances of the Type/MAC Addresses
+ fields in the array.
+
+ Length: The length of the MAC Address field.
+
+ MAC Address: MAC addresses of the station that has caused
+ decryption errors.
+
+4.6.16. Decryption Error Report Period
+
+ The Decryption Error Report Period message element value is used by
+ the AC to inform the WTP how frequently it should send decryption
+ error report messages. Note that this error reporting mechanism is
+ not used if encryption and decryption services are provided in the
+ AC.
+
+ 0 1 2
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID | Report Interval |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 16 for Decryption Error Report Period
+
+ Length: 3
+
+ Radio ID: The Radio Identifier refers to an interface index on the
+ WTP.
+
+ Report Interval: A 16-bit unsigned integer indicating the time, in
+ seconds. The default value for this message element can be found
+ in Section 4.8.8.
+
+4.6.17. Delete MAC ACL Entry
+
+ The Delete MAC ACL Entry message element is used by an AC to delete a
+ MAC ACL entry on a WTP, ensuring that the WTP provides service to the
+ MAC addresses provided in the message.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Num of Entries| Length | MAC Address ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 62]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ Type: 17 for Delete MAC ACL Entry
+
+ Length: >= 8
+
+ Num of Entries: The number of instances of the Type/MAC Addresses
+ fields in the array.
+
+ Length: The length of the MAC Address field.
+
+ MAC Address: An array of MAC Addresses to delete from the ACL.
+
+4.6.18. Delete Station
+
+ The Delete Station message element is used by the AC to inform a WTP
+ that it should no longer provide service to a particular station.
+ The WTP MUST terminate service to the station immediately upon
+ receiving this message element.
+
+ The transmission of a Delete Station message element could occur for
+ various reasons, including for administrative reasons, or if the
+ station has roamed to another WTP.
+
+ The Delete Station message element MAY be sent by the WTP, in the WTP
+ Event Request message, to inform the AC that a particular station is
+ no longer being provided service. This could occur as a result of an
+ Idle Timeout (see section 4.4.43), due to internal resource shortages
+ or for some other reason.
+
+ 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...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 18 for Delete Station
+
+ Length: >= 8
+
+ Radio ID: An 8-bit value representing the radio
+
+ Length: The length of the MAC Address field.
+
+ MAC Address: The station's MAC Address
+
+
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 63]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+4.6.19. Delete Static MAC ACL Entry
+
+ The Delete Static MAC ACL Entry message element is used by an AC to
+ delete a previously added static MAC ACL entry on a WTP, ensuring
+ that the WTP provides service to the MAC addresses provided in the
+ message.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Num of Entries| Length | MAC Address ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 19 for Delete Static MAC ACL Entry
+
+ Length: >= 8
+
+ Num of Entries: The number of instances of the Type/MAC Addresses
+ fields in the array.
+
+ Length: The length of the MAC Address field.
+
+ MAC Address: An array of MAC Addresses to delete from the static
+ MAC ACL entry.
+
+4.6.20. Discovery Type
+
+ The Discovery Type message element is used by the WTP to indicate how
+ it has come to know about the existence of the AC to which it is
+ sending the Discovery Request message.
+
+ 0
+ 0 1 2 3 4 5 6 7
+ +-+-+-+-+-+-+-+-+
+ | Discovery Type|
+ +-+-+-+-+-+-+-+-+
+
+ Type: 20 for Discovery Type
+
+ Length: 1
+
+ Discovery Type: An 8-bit value indicating how the WTP discovered
+ the AC. The following values are supported:
+
+ 0 - Unknown
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 64]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ 1 - Static Configuration
+
+ 2 - DHCP
+
+ 3 - DNS
+
+ 4 - AC Referral (used when the AC was configured either through
+ the AC IPv4 List or AC IPv6 List message element)
+
+4.6.21. Duplicate IPv4 Address
+
+ The Duplicate IPv4 Address message element is used by a WTP to inform
+ an AC that it has detected another IP device using the same IP
+ address that the WTP is currently using.
+
+ The WTP MUST transmit this message element with the status set to 1
+ after it has detected a duplicate IP address. When the WTP detects
+ that the duplicate IP address has been cleared, it MUSY send this
+ message element with the status set to 0.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | IP Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Status | Length | MAC Address ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 21 for Duplicate IPv4 Address
+
+ Length: >= 12
+
+ IP Address: The IP Address currently used by the WTP.
+
+ Status: The status of the duplicate IP address. The value MUST be
+ set to 1 when a duplicate address is detected, and 0 when the
+ duplicate address has been cleared.
+
+ Length: The length of the MAC Address field.
+
+ MAC Address: The MAC Address of the offending device.
+
+4.6.22. Duplicate IPv6 Address
+
+ The Duplicate IPv6 Address message element is used by a WTP to inform
+ an AC that it has detected another host using the same IP address
+ that the WTP is currently using.
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 65]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ The WTP MUST transmit this message element with the status set to 1
+ after it has detected a duplicate IP address. When the WTP detects
+ that the duplicate IP address has been cleared, it MUST send this
+ message element with the status set to 0.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | IP Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | IP Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | IP Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | IP Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Status | Length | MAC Address ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 23 for Duplicate IPv6 Address
+
+ Length: >= 24
+
+ IP Address: The IP Address currently used by the WTP.
+
+ Status: The status of the duplicate IP address. The value MUST be
+ set to 1 when a duplicate address is detected, and 0 when the
+ duplicate address has been cleared.
+
+ Length: The length of the MAC Address field.
+
+ MAC Address: The MAC Address of the offending device.
+
+4.6.23. Idle Timeout
+
+ The Idle Timeout message element is sent by the AC to the WTP to
+ provide the idle timeout value that the WTP SHOULD enforce for its
+ active stations. The value applies to all radios on 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Timeout |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 66]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ Type: 23 for Idle Timeout
+
+ Length: 4
+
+ Timeout: The current idle timeout to be enforced by the WTP. The
+ default value for this message element is specified in
+ Section 4.8.5.
+
+4.6.24. Image Data
+
+ The Image Data message element is present in the Image Data Request
+ message sent by the AC and contains the following fields.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Opcode | Value ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 24 for Image Data
+
+ Length: >= 1
+
+ Opcode: An 8-bit value representing the transfer opcode. The
+ following values are supported:
+
+ 1 - Image data is included
+
+ 2 - Last Image Data Block is included (EOF)
+
+ 5 - An error occurred. Transfer is aborted
+
+ Value: The Image Data field contains up to 1024 characters. If the
+ block being sent is the last one, the Opcode is set to 2. The AC
+ MAY opt to abort the data transfer by setting the Opcode to 5.
+ When the Opcode is 5, the Value field has a zero length.
+
+4.6.25. Image Identifier
+
+ The Image Identifier message element is sent by the AC to the WTP and
+ is used to indicate the expected active software version that is to
+ be run on the WTP. The value is a variable length UTF-8 encoded
+ string, which is NOT zero terminated.
+
+
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 67]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Vendor Identifier |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Value...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 25 for Image Identifier
+
+ Length: >= 1
+
+ Value: A variable length UTF-8 encoded string containing the
+ firmware identifier to be run on the WTP.
+
+4.6.26. Image Information
+
+ The Image Information message element is present in the Image Data
+ Response message sent by the AC to the WTP and contains the following
+ fields.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | File Size | Hash |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Hash |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Hash |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Hash |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Hash |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 26 for Image Information
+
+ Length: 18
+
+ File Size: A 16-bit value containing the size of the file that will
+ be transfered by the AC to the WTP.
+
+ Hash: A 16 octet hash of the image. The hash is computed using
+ MD5, using the following pseudo-code:
+
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 68]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ #include <md5.h>
+ CapwapCreateHash(char *hash, char *image, int image_len)
+ {
+ MD_CTX context;
+
+ MDInit (&context);
+ MDUpdate (&context, buffer, len);
+ MDFinal (hash, &context);
+ }
+
+4.6.27. Initiate Download
+
+ The Initiate Download message element is used by the AC to inform the
+ WTP that the WTP SHOULD initiate a firmware upgrade. The WTP
+ subsequently transmits an Image Data Request message which includes
+ the Image Download message element. This message element does not
+ contain any data.
+
+ Type: 27 for Initiate Download
+
+ Length: 0
+
+4.6.28. Location Data
+
+ The Location Data message element is a variable length byte UTF-8
+ encoded string containing user defined location information (e.g.
+ "Next to Fridge"). This information is configurable by the network
+ administrator, and allows the WTP location to be determined. The
+ string is not zero terminated.
+
+ 0
+ 0 1 2 3 4 5 6 7
+ +-+-+-+-+-+-+-+-+-
+ | Location ...
+ +-+-+-+-+-+-+-+-+-
+
+ Type: 28 for Location Data
+
+ Length: > 0
+
+ Location: A non-zero terminated UTF-8 encoded string containing the
+ WTP location.
+
+4.6.29. Maximum Message Length
+
+ The Maximum Message Length message element is included in the Join
+ Request message by the WTP to indicate the maximum CAPWAP message
+ length that it supports to the AC. The Maximum Message Length
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 69]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ message element is optionally included in Join Response message by
+ the AC to indicate the maximum CAPWAP message length that it supports
+ to the WTP.
+
+ 0 1 2
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+ | Maximum Message Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+
+ Type: 29 for Maximim Message Length
+
+ Length: 2
+
+ Maximum Message Length An 16-bit unsigned integer indicating the
+ maximum message length.
+
+4.6.30. MTU Discovery Padding
+
+ The MTU Discovery Padding message element is used as padding to
+ perform MTU discovery, and MUST contain octets of value 0xFF, of any
+ length
+
+ 0
+ 0 1 2 3 4 5 6 7
+ +-+-+-+-+-+-+-+-+
+ | Padding...
+ +-+-+-+-+-+-+-+-
+
+
+ Type: 30 for MTU Discovery Padding
+
+ Length: variable
+
+ Pad: A variable length pad.
+
+4.6.31. Radio Administrative State
+
+ The Radio Administrative State message element is used to communicate
+ the state of a particular radio. The Radio Administrative State
+ message element is sent by the AC to change the state of the WTP.
+ The WTP saves the value, to ensure that it remains across WTP resets.
+ The WTP communicates this message element during the configuration
+ phase, in the Configuration Status Request message, to ensure that AC
+ has the WTP radio current administrative state settings. The message
+ element contains the following fields.
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 70]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ 0 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID | Admin State |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 31 for Radio Administrative State
+
+ Length: 2
+
+ Radio ID: An 8-bit value representing the radio to configure. The
+ Radio ID field MAY also include the value of 0xff, which is used
+ to identify the WTP. If an AC wishes to change the administrative
+ state of a WTP, it includes 0xff in the Radio ID field.
+
+ Admin State: An 8-bit value representing the administrative state
+ of the radio. The default value for the Admin State field is
+ listed in Section 4.8.1. The following values are supported:
+
+ 1 - Enabled
+
+ 2 - Disabled
+
+4.6.32. Radio Operational State
+
+ The Radio Operational State message element is sent by the WTP to the
+ AC to communicate a radio's operational state. This message element
+ is included in the Configuration Update Response message by the WTP
+ if it was requested to change the state of its radio, via the Radio
+ Administrative State message element, but was unable to comply to the
+ request. This message element is included in the Change State Event
+ message when a WTP radio state was changed unexpectedly. This could
+ occur due to a hardware failure. Note that the operational state
+ setting is not saved on the WTP, and therefore does not remain across
+ WTP resets. The value contains three fields, as shown below.
+
+ 0 1 2
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID | State | Cause |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 32 for Radio Operational State
+
+ Length: 3
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 71]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ Radio ID: The Radio Identifier refers to an interface index on the
+ WTP. A value of 0xFF is invalid, as it is not possible to change
+ the WTP's operational state.
+
+ State: An 8-bit boolean value representing the state of the radio.
+ A value of one disables the radio, while a value of two enables
+ it.
+
+ Cause: When a radio is inoperable, the cause field contains the
+ reason the radio is out of service. The following values are
+ supported:
+
+ 0 - Normal
+
+ 1 - Radio Failure
+
+ 2 - Software Failure
+
+ 3 - Administratively Set
+
+4.6.33. Result Code
+
+ The Result Code message element value is a 32-bit integer value,
+ indicating the result of the Request message corresponding to the
+ Sequence Number included in the Response message.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Result Code |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 33 for Result Code
+
+ Length: 4
+
+ Result Code: The following values are defined:
+
+ 0 Success
+
+ 1 Failure (AC List message element MUST be present)
+
+ 2 Success (NAT detected)
+
+ 3 Join Failure (unspecified)
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 72]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ 4 Join Failure (Resource Depletion)
+
+ 5 Join Failure (Unknown Source)
+
+ 6 Join Failure (Incorrect Data)
+
+ 7 Join Failure (Session ID already in use)
+
+ 8 Join Failure (WTP Hardware not supported)
+
+ 9 Join Failure (Binding Not Supported)
+
+ 10 Reset Failure (Unable to Reset)
+
+ 11 Reset Failure (Firmware Write Error)
+
+ 12 Configuration Failure (Unable to Apply Requested Configuration
+ - Service Provided Anyhow)
+
+ 13 Configuration Failure (Unable to Apply Requested Configuration
+ - Service Not Provided)
+
+ 14 Image Data Error (Invalid Checksum)
+
+ 15 Image Data Error (Invalid Data Length)
+
+ 16 Image Data Error (Other Error)
+
+ 17 Image Data Error (Image Already Present)
+
+ 18 Message Unexpected (Invalid in current state)
+
+ 19 Message Unexpected (Unrecognized Request)
+
+ 20 Failure - Missing Mandatory Message Element
+
+ 21 Failure - Unrecognized Message Element
+
+4.6.34. Returned Message Element
+
+ The Returned Message Element is sent by the WTP in the Change State
+ Event Request message to communicate to the AC which message elements
+ in the Configuration Status Response it was unable to apply locally.
+ The Returned Message Element message element contains a result code
+ indicating the reason that the configuration could not be applied,
+ and encapsulates the failed message element.
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 73]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ 0 1 2
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Reason | Message Element...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 34 for Returned Message Element
+
+ Length: >= 1
+
+ Reason: The reason why the configuration in the offending message
+ element could not be applied by the WTP.
+
+ 1 - Unknown Message Element
+
+ 2 - Unsupported Message Element
+
+ 3 - Unknown Message Element Value
+
+ 4 - Unsupported Message Element Value
+
+ Message Element: The Message Element field encapsulates the message
+ element sent by the AC in the Configuration Status Response
+ message that caused the error.
+
+4.6.35. Session ID
+
+ The Session ID message element value contains a randomly generated
+ unsigned 32-bit integer.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Session ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+ Type: 35 for Session ID
+
+ Length: 16
+
+ Session ID: A 32-bit unsigned integer used as a random session
+ identifier
+
+
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 74]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+4.6.36. Statistics Timer
+
+ The Statistics Timer message element value is used by the AC to
+ inform the WTP of the frequency with which it expects to receive
+ updated statistics.
+
+ 0 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Statistics Timer |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 36 for Statistics Timer
+
+ Length: 2
+
+ Statistics Timer: A 16-bit unsigned integer indicating the time, in
+ seconds. The default value for this timer is specified in
+ Section 4.7.12.
+
+4.6.37. Vendor Specific Payload
+
+ The Vendor Specific Payload message element is used to communicate
+ vendor specific information between the WTP and the AC. The message
+ element uses the following format:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Vendor Identifier |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Element ID | Value... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 37 for Vendor Specific
+
+ Length: >= 7
+
+ Vendor Identifier: A 32-bit value containing the IANA assigned "SMI
+ Network Management Private Enterprise Codes" [14]
+
+ Element ID: A 16-bit Element Identifier which is managed by the
+ vendor.
+
+ Value: The value associated with the vendor specific element.
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 75]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+4.6.38. WTP Board Data
+
+ The WTP Board Data message element is sent by the WTP to the AC and
+ contains information about the hardware present.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Vendor Identifier |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type=0 | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Value...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type=1 | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Value...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Optional additional vendor specific WTP board data TLVs.....
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+ Type: 38 for WTP Board Data
+
+ Length: >=14
+
+ Vendor Identifier: A 32-bit value containing the IANA assigned "SMI
+ Network Management Private Enterprise Codes"
+
+ Type: The following values are supported:
+
+ 0 - WTP Model Number: The WTP Model Number MUST be included in
+ the WTP Board Data message element.
+
+ 1 - WTP Serial Number: The WTP Serial Number MUST be included in
+ the WTP Board Data message element.
+
+ 2 - Board ID: A hardware identifier, which MAY be included in
+ the WTP Board Data mesage element.
+
+ 3 - Board Revision A revision number of the board, which MAY be
+ included in the WTP Board Data message element.
+
+ 4 - Base MAC Addres The WTP's Base MAC Address, which MAY be
+ assigned to the primary Ethernet interface.
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 76]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+4.6.39. WTP Descriptor
+
+ The WTP Descriptor message element is used by a WTP to communicate
+ its current hardware and software (firmware) configuration. 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Max Radios | Radios in use | Encryption Capabilities |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Vendor Identifier |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type=0 | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Value...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Vendor Identifier |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type=1 | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Value...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Vendor Identifier |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type=2 | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Value...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Vendor Identifier |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type=3 | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Value...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+ Type: 39 for WTP Descriptor
+
+ Length: >= 31
+
+ Max Radios: An 8-bit value representing the number of radios (where
+ each radio is identified via the Radio ID field) supported by the
+ WTP.
+
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 77]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ Radios in use: An 8-bit value representing the number of radios in
+ use in the WTP.
+
+ Encryption Capabilities: This 16-bit field is used by the WTP to
+ communicate its capabilities to the AC. A WTP that does not have
+ any encryption capabilities sets this field to zero (0). Refer to
+ the specific wireless binding for further specification of the
+ Encryption Capabilities field.
+
+ Vendor Identifier: A 32-bit value containing the IANA assigned "SMI
+ Network Management Private Enterprise Codes".
+
+ Type: The following values are supported. The Hardware Version,
+ Active Software Version, and Boot Version values MUST be included.
+ Zero or more Other Software Version values MAY be included.
+
+ 0 - Hardware Version: The WTP hardware version number.
+
+ 1 - Active Software Version: The WTP running software version
+ number.
+
+ 2 - Boot Version: The WTP boot loader version number.
+
+ 3 - Other Software Version: The WTP non-running software
+ (firmware) version number.
+
+ Length: Length of vendor specific encoding of WTP information.
+
+ Value: Vendor specific data of WTP information encoded in the UTF-8
+ format.
+
+4.6.40. WTP Fallback
+
+ The WTP Fallback message element is sent by the AC to the WTP to
+ enable or disable automatic CAPWAP fallback in the event that a WTP
+ detects its preferred AC, and is not currently connected to it.
+
+ 0
+ 0 1 2 3 4 5 6 7
+ +-+-+-+-+-+-+-+-+
+ | Mode |
+ +-+-+-+-+-+-+-+-+
+
+ Type: 40 for WTP Fallback
+
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 78]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ Length: 1
+
+ Mode: The 8-bit value indicates the status of automatic CAPWAP
+ fallback on the WTP. When enabled, if the WTP detects that its
+ primary AC is available, and that the WTP is not connected to the
+ primary AC, the WTP SHOULD automatically disconnect from its
+ current AC and reconnect to its primary AC. If disabled, the WTP
+ will only reconnect to its primary AC through manual intervention
+ (e.g., through the Reset Request message). The default value for
+ this field is specified in Section 4.8.10. The following values
+ are supported:
+
+ 1 - Enabled
+
+ 2 - Disabled
+
+4.6.41. WTP Frame Tunnel Mode
+
+ The WTP Frame Tunnel Mode message element allows the WTP to
+ communicate the tunneling modes of operation which it supports to the
+ AC. A WTP that advertises support for all types allows the AC to
+ select which type will be used, based on its local policy.
+
+ 0
+ 0 1 2 3 4 5 6 7
+ +-+-+-+-+-+-+-+-+
+ | Tunnel Mode |
+ +-+-+-+-+-+-+-+-+
+
+ Type: 41 for WTP Frame Tunnel Mode
+
+ Length: 1
+
+ Frame Tunnel Mode: The Frame Tunnel mode specifies the tunneling
+ modes for station data that are supported by the WTP. The
+ following values are supported:
+
+ 1 - Local Bridging: When Local Bridging is used, the WTP does
+ not tunnel user traffic to the AC; all user traffic is locally
+ bridged. This value MUST NOT be used when the WTP MAC Type is
+ set to Split-MAC.
+
+ 2 - 802.3 Frame Tunnel Mode: The 802.3 Frame Tunnel Mode
+ requires the WTP and AC to encapsulate all user payload as
+ native IEEE 802.3 frames (see Section 4.4). All user traffic
+ is tunneled to the AC. This value MUST NOT be used when the
+ WTP MAC Type is set to Split-MAC.
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 79]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ 4 - Native Frame Tunnel Mode: Native Frame Tunnel mode requires
+ the WTP and AC to encapsulate all user payloads as native
+ wireless frames, as defined by the wireless binding (see for
+ example Section 4.4).
+
+ 7 - All: The WTP is capable of supporting all frame tunnel
+ modes.
+
+4.6.42. WTP IPv4 IP Address
+
+ The WTP IPv4 address is used to perform NAT detection.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | WTP IPv4 IP Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+ Type: 42 for WTP IPv4 IP Address
+
+ Length: 4
+
+ WTP IPv4 IP Address: The IPv4 address from which the WTP is sending
+ packets. This field is used for NAT detection.
+
+4.6.43. WTP IPv6 IP Address
+
+ The WTP IPv6 address is used to perform NAT detection (e.g., IPv4 to
+ IPv6 NAT to help with technology transition).
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | WTP IPv6 IP Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | WTP IPv6 IP Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | WTP IPv6 IP Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | WTP IPv6 IP Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 80]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ Type: 43 for WTP IPv6 IP Address
+
+ Length: 32
+
+ WTP IPv6 IP Address: The IPv6 address from which the WTP is sending
+ packets. This field is used for NAT detection.
+
+4.6.44. WTP MAC Type
+
+ The WTP MAC-Type message element allows the WTP to communicate its
+ mode of operation to the AC. A WTP that advertises support for both
+ modes allows the AC to select the mode to use, based on local policy.
+
+ 0
+ 0 1 2 3 4 5 6 7
+ +-+-+-+-+-+-+-+-+
+ | MAC Type |
+ +-+-+-+-+-+-+-+-+
+
+ Type: 44 for WTP MAC Type
+
+ Length: 1
+
+ MAC Type: The MAC mode of operation supported by the WTP. The
+ following values are supported
+
+ 0 - Local-MAC: Local-MAC is the default mode that MUST be
+ supported by all WTPs.
+
+ 1 - Split-MAC: Split-MAC support is optional, and allows the AC
+ to receive and process native wireless frames.
+
+ 2 - Both: WTP is capable of supporting both Local-MAC and Split-
+ MAC.
+
+4.6.45. WTP Name
+
+ The WTP Name message element is a variable length byte UTF-8 encoded
+ string. The string is not zero terminated.
+
+ 0
+ 0 1 2 3 4 5 6 7
+ +-+-+-+-+-+-+-+-+-
+ | WTP Name ...
+ +-+-+-+-+-+-+-+-+-
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 81]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ Type: 45 for WTP Name
+
+ Length: variable
+
+ WTP Name: A non-zero terminated UTF-8 encoded string containing the
+ WTP name.
+
+4.6.46. WTP Operational Statistics
+
+ The WTP Operational Statistics message element is sent by the WTP to
+ the AC to provide statistics related to the operation of 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID | Tx Queue Level | Wireless Link Frames per Sec |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+ Type: 46 for WTP Operational Statistics
+
+ Length: 4
+
+ Radio ID: The radio ID of the radio to which the statistics apply.
+
+ Wireless Transmit Queue Level: The percentage of Wireless Transmit
+ queue utilization, calculated as the sum of utilized transmit
+ queue lengths divided by the sum of maximum transmit queue
+ lengths, multiplied by 100. The Wireless Transmit Queue Level is
+ representative of congestion conditions over wireless interfaces
+ between the WTP and stations.
+
+ Wireless Link Frames per Sec: The number of frames transmitted or
+ received per second by the WTP over the air interface.
+
+4.6.47. WTP Radio Statistics
+
+ The WTP Radio Statistics message element is sent by the WTP to the AC
+ to communicate statistics on radio behavior and reasons why the WTP
+ radio has been reset.
+
+
+
+
+
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 82]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ 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 | Last Fail Type| Reset Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | SW Failure Count | HW Failure Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Other Failure Count | Unknown Failure Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Config Update Count | Channel Change Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Band Change Count | Current Noise Floor |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 47 for WTP Radio Statistics
+
+ Length: 20
+
+ Radio ID: The radio ID of the radio to which the statistics apply.
+
+ Last Failure Type: The last WTP failure. The following values are
+ supported:
+
+ 0 - Statistic Not Supported
+
+ 1 - Software Failure
+
+ 2 - Hardware Failure
+
+ 3 - Other Failure
+
+ 255 - Unknown (e.g., WTP doesn't keep track of info)
+
+ Reset Count: The number of times that that the radio has been
+ reset.
+
+ SW Failure Count: The number of times that the radio has failed due
+ to software related reasons.
+
+ HW Failure Count: The number of times that the radio has failed due
+ to hardware related reasons.
+
+ Other Failure Count: The number of times that the radio has failed
+ due to known reasons, other than software or hardware failure.
+
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 83]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ Unknown Failure Count: The number of times that the radio has
+ failed for unknown reasons.
+
+ Config Update Count: The number of times that the radio
+ configuration has been updated.
+
+ Channel Change Count: The number of times that the radio channel
+ has been changed.
+
+ Band Change Count: The number of times that the radio has changed
+ frequency bands.
+
+ Current Noise Floor: A signed integer which indicates the noise
+ floor of the radio receiver in units of dBm.
+
+4.6.48. WTP Reboot Statistics
+
+ The WTP Reboot Statistics message element is sent by the WTP to the
+ AC to communicate reasons why WTP reboots have occurred.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Reboot Count | AC Initiated Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Link Failure Count | SW Failure Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | HW Failure Count | Other Failure Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Unknown Failure Count |Last Failure Type|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+ Type: 48 for WTP Reboot Statistics
+
+ Length: 15
+
+ Reboot Count: The number of reboots that have occurred due to a WTP
+ crash. A value of 65535 implies that this information is not
+ available on the WTP.
+
+ AC Initiated Count: The number of reboots that have occurred at the
+ request of a CAPWAP protocol message, such as a change in
+ configuration that required a reboot or an explicit CAPWAP
+ protocol reset request. A value of 65535 implies that this
+ information is not available on the WTP.
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 84]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ Link Failure Count: The number of times that a CAPWAP protocol
+ connection with an AC has failed due to link failure.
+
+ SW Failure Count: The number of times that a CAPWAP protocol
+ connection with an AC has failed due to software related reasons.
+
+ HW Failure Count: The number of times that a CAPWAP protocol
+ connection with an AC has failed due to hardware related reasons.
+
+ Other Failure Count: The number of times that a CAPWAP protocol
+ connection with an AC has failed due to known reasons, other than
+ AC initiated, link, SW or HW failure.
+
+ Unknown Failure Count: The number of times that a CAPWAP protocol
+ connection with an AC has failed for unknown reasons.
+
+ Last Failure Type: The failure type of the most recent WTP failure.
+ The following values are supported:
+
+ 0 - Not Supported
+
+ 1 - AC Initiated (see Section 9.2)
+
+ 2 - Link Failure
+
+ 3 - Software Failure
+
+ 4 - Hardware Failure
+
+ 5 - Other Failure
+
+ 255 - Unknown (e.g., WTP doesn't keep track of info)
+
+4.6.49. WTP Static IP Address Information
+
+ The WTP Static IP Address Information message element is used by an
+ AC to configure or clear a previously configured static IP address on
+ a WTP.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 85]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | IP Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Netmask |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Gateway |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Static |
+ +-+-+-+-+-+-+-+-+
+
+ Type: 49 for WTP Static IP Address Information
+
+ Length: 13
+
+ IP Address: The IP Address to assign to the WTP. This field is
+ only valid if the static field is set to one.
+
+ Netmask: The IP Netmask. This field is only valid if the static
+ field is set to one.
+
+ Gateway: The IP address of the gateway. This field is only valid
+ if the static field is set to one.
+
+ Netmask: The IP Netmask. This field is only valid if the static
+ field is set to one.
+
+ Static: An 8-bit boolean stating whether the WTP should use a
+ static IP address or not. A value of zero disables the static IP
+ address, while a value of one enables it.
+
+4.7. CAPWAP Protocol Timers
+
+ This section contains the CAPWAP timers.
+
+4.7.1. ChangeStatePendingTimer
+
+ The maximum time, in seconds, the AC will wait for the Change State
+ Event Request from the WTP after having transmitted a successful
+ Configuration Status Response message. The default value is 25
+ seconds.
+
+4.7.2. DataChannelDeadInterval
+
+ The minimum time, in seconds, a WTP MUST wait without having received
+ a Data Channel Keep Alive packet before the destination for the Data
+ Channel Keep Alive packets may be considered dead. The value of this
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 86]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ timer MUST be no less than 2*DataChannelKeepAlive seconds and no
+ greater that 240 seconds.
+
+ Default: 5
+
+4.7.3. DiscoveryInterval
+
+ The minimum time, in seconds, that a WTP MUST wait after receiving a
+ Discovery Response message, before initiating a DTLS handshake.
+
+ Default: 5
+
+4.7.4. DTLSSessionDelete
+
+ The minimum time, in seconds, a WTP MUST wait for DTLS session
+ deletion.
+
+ Default: 5
+
+4.7.5. EchoInterval
+
+ The minimum time, in seconds, between sending Echo Request messages
+ to the AC with which the WTP has joined.
+
+ Default: 30
+
+4.7.6. MaxDiscoveryInterval
+
+ The maximum time allowed between sending Discovery Request messages,
+ in seconds. This value MUST be no less than 2 seconds and no greater
+ than 180 seconds.
+
+ Default: 20 seconds.
+
+4.7.7. MaxFailedDTLSSessionRetry
+
+ The maximum number of failed DTLS session establishment attempts
+ before the CAPWAP device enters a silent period.
+
+ Default: 3.
+
+4.7.8. NeighborDeadInterval
+
+ The minimum time, in seconds, a WTP MUST wait without having received
+ an Echo Response message to its Echo Request message, before the
+ destination for the Echo Request may be considered dead. This value
+ MUST be no less than 2*EchoInterval seconds and no greater than 240
+ seconds.
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 87]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ Default: 60
+
+4.7.9. ResponseTimeout
+
+ The minimum time, in seconds, in which the WTP or AC MUST respond to
+ a CAPWAP Request message.
+
+ Default: 1
+
+4.7.10. RetransmitInterval
+
+ The minimum time, in seconds, in which a non-acknowledged CAPWAP
+ packet will be retransmitted.
+
+ Default: 3
+
+4.7.11. SilentInterval
+
+ For a WTP, this is the minimum time, in seconds, a WTP MUST wait
+ before it MAY again send Discovery Request messages or attempt to a
+ establish DTLS session. For an AC, this is the minimum time, in
+ seconds, during which the AC SHOULD ignore all CAPWAP and DTLS
+ packets received from the WTP that is in the Sulking state.
+
+ Default: 30
+
+4.7.12. StatisticsTimer
+
+ The default Statistics Interval is 120 seconds.
+
+4.7.13. WaitDTLS
+
+ The maximum time, in seconds, a WTP MUST wait without having received
+ a DTLS Handshake message from an AC. This timer MUST be greater than
+ 30 seconds.
+
+ Default: 60
+
+4.7.14. WaitJoin
+
+ The maximum time, in seconds, after which the DTLS session has been
+ established that the AC will wait before receiving a Join Request
+ message. This timer MUST be greater than 30 seconds.
+
+ Default: 60
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 88]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+4.8. CAPWAP Protocol Variables
+
+ A WTP or AC that implements the CAPWAP Discovery phase MUST allow for
+ the following variables to be configured by system management;
+ default values are specified, making explicit configuration
+ unnecessary in many cases. If the default values are explicitly
+ overriden by the AC, the WTP MUST save the values sent by the AC.
+
+4.8.1. AdminState
+
+ The default Administrative State value is enabled (1).
+
+4.8.2. DiscoveryCount
+
+ The number of Discovery Request messages transmitted by a WTP to a
+ single AC. This is a monotonically increasing counter.
+
+4.8.3. FailedDTLSAuthFailCount
+
+ The number of failed DTLS session establishment attempts due to
+ authentication failures.
+
+4.8.4. FailedDTLSSessionCount
+
+ The number of failed DTLS session establishment attempts.
+
+4.8.5. IdleTimeout
+
+ The default Idle Timeout is 300 seconds.
+
+4.8.6. MaxDiscoveries
+
+ The maximum number of Discovery Request messages that will be sent
+ after a WTP boots.
+
+ Default: 10
+
+4.8.7. MaxRetransmit
+
+ The maximum number of retransmissions for a given CAPWAP packet
+ before the link layer considers the peer dead.
+
+ Default: 5
+
+4.8.8. ReportInterval
+
+ The default Report Interval is 120 seconds.
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 89]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+4.8.9. RetransmitCount
+
+ The number of retransmissions for a given CAPWAP packet. This is a
+ monotonically increasing counter.
+
+4.8.10. WTPFallBack
+
+ The default WTP Fallback value is enabled (1).
+
+4.9. WTP Saved Variables
+
+ In addition to the values defined in Section 4.8, the following
+ values SHOULD be saved on the WTP in non-volatile memory. CAPWAP
+ wireless bindings MAY define additional values that SHOULD be stored
+ on the WTP.
+
+4.9.1. AdminRebootCount
+
+ The number of times the WTP has rebooted administratively, defined in
+ Section 4.6.48.
+
+4.9.2. FrameEncapType
+
+ For WTPs that support multiple Frame Encapsulation Types, it is
+ useful to save the value configured by the AC. The Frame
+ Encapsulation Type is defined in Section 4.6.41.
+
+4.9.3. LastRebootReason
+
+ The reason why the WTP last rebooted, defined in Section 4.6.48.
+
+4.9.4. MacType
+
+ For WTPs that support multiple MAC Types, it is useful to save the
+ value configured by the AC. The MACType is defined in
+ Section 4.6.44.
+
+4.9.5. PreferredACs
+
+ The preferred ACs, with the index, defined in Section 4.6.5.
+
+4.9.6. RebootCount
+
+ The number of times the WTP has rebooted, defined in Section 4.6.48.
+
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 90]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+4.9.7. Static ACL Table
+
+ The static ACL table saved on the WTP, as configured by the Add
+ Static MAC ACL Entry message element, see Section 4.6.9.
+
+4.9.8. Static IP Address
+
+ The static IP Address assigned to the WTP, as configured by the WTP
+ Static IP Address Information message element (see Section 4.6.49).
+
+4.9.9. WTPLinkFailureCount
+
+ The number of times the link to the AC has failed, see
+ Section 4.6.48.
+
+4.9.10. WTPLocation
+
+ The WTP Location, defined in Section 4.6.28.
+
+4.9.11. WTPName
+
+ The WTP Name, defined in Section 4.6.45.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 91]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+5. CAPWAP Discovery Operations
+
+ The Discovery messages are used by a WTP to determine which ACs are
+ available to provide service, and the capabilities and load of the
+ ACs.
+
+5.1. Discovery Request Message
+
+ The Discovery Request message is used by the WTP to automatically
+ discover potential ACs available in the network. The Discovery
+ Request message provides ACs with the primary capabilities of the
+ WTP. A WTP must exchange this information to ensure subsequent
+ exchanges with the ACs are consistent with the WTP's functional
+ characteristics.
+
+ Discovery Request messages MUST be sent by a WTP in the Discover
+ state after waiting for a random delay less than
+ MaxDiscoveryInterval, after a WTP first comes up or is
+ (re)initialized. A WTP MUST send no more than the maximum of
+ MaxDiscoveries Discovery Request messages, waiting for a random delay
+ less than MaxDiscoveryInterval between each successive message.
+
+ This is to prevent an explosion of WTP Discovery Request messages.
+ An example of this occurring is when many WTPs are powered on at the
+ same time.
+
+ Discovery Request messages MUST be sent by a WTP when no Echo
+ Response messages are received for NeighborDeadInterval and the WTP
+ returns to the Idle state. Discovery Request messages are sent after
+ NeighborDeadInterval. They MUST be sent after waiting for a random
+ delay less than MaxDiscoveryInterval. A WTP MAY send up to a maximum
+ of MaxDiscoveries Discovery Request messages, waiting for a random
+ delay less than MaxDiscoveryInterval between each successive message.
+
+ If a Discovery Response message is not received after sending the
+ maximum number of Discovery Request messages, the WTP enters the
+ Sulking state and MUST wait for an interval equal to SilentInterval
+ before sending further Discovery Request messages.
+
+ Upon receiving a Discovery Request message, the AC will respond with
+ a Discovery Response message sent to the address in the source
+ address of the received Discovery Request message.
+
+ It is possible for the AC to receive a cleartext Discovery Request
+ message while a DTLS session is already active with the WTP. This is
+ most likely the case if the WTP has rebooted, perhaps due to a
+ software or power failure, but could also be caused by a DoS attack.
+ In such cases, any WTP state, including the state machine instance,
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 92]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ MUST NOT be cleared until another DTLS session has been successfully
+ established, communicated via the DTLSSessionEstablished DTLS
+ notification (see Section 2.3.2.2).
+
+ The binding specific WTP Radio Information message element (see
+ Section 2.1) is included in the Discovery Request message to
+ advertise WTP support for one or more CAPWAP bindings.
+
+ The Discovery Request message is sent by the WTP when in the
+ Discovery State. The AC does not transmit this message.
+
+ The following message elements MUST be included in the Discovery
+ Request message:
+
+ o Discovery Type, see Section 4.6.20
+
+ o WTP Board Data, see Section 4.6.38
+
+ o WTP Descriptor, see Section 4.6.39
+
+ o WTP Frame Tunnel Mode, see Section 4.6.41
+
+ o WTP MAC Type, see Section 4.6.44
+
+ o WTP Radio Information message element(s)that the WTP supports;
+ These are defined by the individual link layer CAPWAP Binding
+ Protocols (see Section 2.1).
+
+5.2. Discovery Response Message
+
+ The Discovery Response message provides a mechanism for an AC to
+ advertise its services to requesting WTPs.
+
+ When a WTP receives a Discovery Response message, it MUST wait for an
+ interval not less than DiscoveryInterval for receipt of additional
+ Discovery Response messages. After the DiscoveryInterval elapses,
+ the WTP enters the DTLS-Init state and selects one of the ACs that
+ sent a Discovery Response message and send a DTLS Handshake to that
+ AC.
+
+ One or more binding specific WTP Radio Information message elements
+ (see Section 2.1) are included in the Discovery Request message to
+ advertise AC support for the CAPWAP bindings. The AC MAY include
+ only the bindings it shares in common with the WTP, known through the
+ WTP Radio Information message elements received in the Discovery
+ Request message, or it MAY include all of the bindings supported.
+ The WTP MAY use the supported bindings in its AC decision process.
+ Note that if the WTP joins an AC that does not support a specific
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 93]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ CAPWAP binding, service for that binding MUST NOT be provided by the
+ WTP.
+
+ The Discovery Response message is sent by the AC when in the Idle
+ State. The WTP does not transmit this message.
+
+ The following message elements MUST be included in the Discovery
+ Response Message:
+
+ o AC Descriptor, see Section 4.6.1
+
+ o AC Name, see Section 4.6.4
+
+ o WTP Radio Information message element(s)that the AC supports;
+ These are defined by the individual link layer CAPWAP Binding
+ Protocols (see Section 2.1 for more information).
+
+ o One of the following message elements MUST be included in the
+ Discovery Response Message:
+
+ * CAPWAP Control IPv4 Address, see Section 4.6.10
+
+ * CAPWAP Control IPv6 Address, see Section 4.6.11
+
+5.3. Primary Discovery Request Message
+
+ The Primary Discovery Request message is sent by the WTP to determine
+ whether its preferred (or primary) AC is available.
+
+ A Primary Discovery Request message is sent by a WTP when it has a
+ primary AC configured, and is connected to another AC. This
+ generally occurs as a result of a failover, and is used by the WTP as
+ a means to discover when its primary AC becomes available. Since the
+ WTP only has a single instance of the CAPWAP state machine, the
+ Primary Discovery Request is sent by the WTP when in the Run State.
+ The AC does not transmit this message.
+
+ The frequency of the Primary Discovery Request messages should be no
+ more often than the sending of the Echo Request message.
+
+ Upon receipt of a Primary Discovery Request message, the AC responds
+ with a Primary Discovery Response message sent to the address in the
+ source address of the received Primary Discovery Request message.
+
+ The following message elements MUST be included in the Primary
+ Discovery Request message.
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 94]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ o Discovery Type, see Section 4.6.20
+
+ o WTP Board Data, see Section 4.6.38
+
+ o WTP Descriptor, see Section 4.6.39
+
+ o WTP Frame Tunnel Mode, see Section 4.6.41
+
+ o WTP MAC Type, see Section 4.6.44
+
+ o WTP Radio Information message element(s)that the WTP supports;
+ These are defined by the individual link layer CAPWAP Binding
+ Protocols (see Section 2.1 for more information).
+
+5.4. Primary Discovery Response
+
+ The Primary Discovery Response message enables an AC to advertise its
+ availability and services to requesting WTPs that are configured to
+ have the AC as its primary AC.
+
+ The Primary Discovery Response message is sent by an AC after
+ receiving a Primary Discovery Request message.
+
+ When a WTP receives a Primary Discovery Response message, it may
+ establish a CAPWAP protocol connection to its primary AC, based on
+ the configuration of the WTP Fallback Status message element on the
+ WTP.
+
+ The Primary Discovery Response message is sent by the AC when in the
+ Idle State. The WTP does not transmit this message.
+
+ The following message elements MUST be included in the Primary
+ Discovery Response message.
+
+ o AC Descriptor, see Section 4.6.1
+
+ o AC Name, see Section 4.6.4
+
+ o WTP Radio Information message element(s)that the AC supports;
+ These are defined by the individual link layer CAPWAP Binding
+ Protocols (see Section 2.1 for more information).
+
+ One of the following message elements MUST be included in the
+ Discovery Response Message:
+
+ o CAPWAP Control IPv4 Address, see Section 4.6.10
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 95]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+6. CAPWAP Join Operations
+
+ The Join Request message is used by a WTP to request service from an
+ AC after a DTLS connection is established to that AC. The Join
+ Response message is used by the the AC to indicate that it will or
+ will not provide service.
+
+6.1. Join Request
+
+ The Join Request message is used by a WTP to request service through
+ the AC. A Join Request message is sent by a WTP after (optionally)
+ receiving one or more Discovery Response messages, and completion of
+ DTLS session establishment. When an AC receives a Join Request
+ message it responds with a Join Response message.
+
+ Upon completion of the DTLS handshake, and receiving the
+ DTLSEstablished notification, the WTP sends the Join Request message
+ to the AC. When the AC is notified of the DTLS session
+ establishment, it does not clear the WaitDTLS timer until it has
+ received the Join Request message, at which time it sends a Join
+ Response message to the WTP, indicating success or failure.
+
+ One or more WTP Radio Information message elements (see Section 2.1)
+ are included in the Join Request to request service for the CAPWAP
+ bindings by the AC. Including a binding that is unsupported by the
+ AC will result in a failed Join Response.
+
+ If the AC rejects the Join Request, it sends a Join Response message
+ with a failure indication and initiates an abort of the DTLS session
+ via the DTLSAbort command.
+
+ If an invalid (i.e. malformed) Join Request message is received, the
+ message MUST be silently discarded by the AC. No response is sent to
+ the WTP. The AC SHOULD log this event.
+
+ The Join Request is sent by the WTP when in the Join State. The AC
+ does not transmit this message.
+
+ The following message elements MUST be included in the Join Request
+ message.
+
+ o Location Data, see Section 4.6.28
+
+ o WTP Board Data, see Section 4.6.38
+
+ o WTP Descriptor, see Section 4.6.39
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 97]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ o WTP Name, see Section 4.6.45
+
+ o Session ID, see Section 4.6.35
+
+ o WTP Frame Tunnel Mode, see Section 4.6.41
+
+ o WTP MAC Type, see Section 4.6.44
+
+ o WTP Radio Information message element(s)that the WTP supports;
+ These are defined by the individual link layer CAPWAP Binding
+ Protocols (see Section 2.1 for more information).
+
+ At least one of the following message element MUST be included in the
+ Join Request message.
+
+ o WTP IPv4 IP Address, see Section 4.6.42
+
+ o WTP IPv6 IP Address, see Section 4.6.43
+
+ The following message element MAY be included in the Join Request
+ message.
+
+ o Maximum Message Length, see Section 4.6.29
+
+ o WTP Reboot Statistics, see Section 4.6.48
+
+ o WTP IPv4 IP Address, see Section 4.6.42
+
+ o WTP IPv6 IP Address, see Section 4.6.43
+
+6.2. Join Response
+
+ The Join Response message is sent by the AC to indicate to a WTP that
+ it is capable and willing to provide service to the WTP.
+
+ The WTP, receiving a Join Response message, checks for success or
+ failure. If the message indicates success, the WTP clears the
+ WaitDTLS timer for the session and proceeds to the Configure state.
+
+ If the WaitDTLS Timer expires prior to reception of the Join Response
+ message, the WTP MUST terminate the handshake, deallocate session
+ state and initiate the DTLSAbort command.
+
+ If an invalid (malformed) Join Response message is received, the WTP
+ SHOULD log an informative message detailing the error. This error
+ MUST be treated in the same manner as AC non-responsiveness. The
+ WaitDTLS timer will eventually expire, and the WTP MAY (if it is so
+ configured) attempts to join a new AC.
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 98]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ If one of the WTP Radio Information message elements (see
+ Section 2.1) in the Join Request message requested support for a
+ CAPWAP binding which the AC does not support, the AC sets the Result
+ Code message element to "Binding Not Supported".
+
+ The AC includes the Image Identifier message element to indicate the
+ software version it expects the WTP to run. This information is used
+ to determine whether the WTP MUST either change its currently running
+ firmware image, or download a new version (see Section 9.1.1).
+
+ The Join Response message is sent by the AC when in the Join State.
+ The WTP does not transmit this message.
+
+ The following message elements MAY be included in the Join Response
+ message.
+
+ o AC IPv4 List, see Section 4.6.2
+
+ o AC IPv6 List, see Section 4.6.3
+
+ o Image Identifier, see Section 4.6.25
+
+ o Maximum Message Length, see Section 4.6.29
+
+ The following message elements MUST be included in the Join Response
+ message.
+
+ o Result Code, see Section 4.6.33
+
+ o AC Descriptor, see Section 4.6.1
+
+ o AC Name, see Section 4.6.4
+
+ o WTP Radio Information message element(s)that the AC supports;
+ These are defined by the individual link layer CAPWAP Binding
+ Protocols (see Section 2.1).
+
+ One of the following message elements MUST be included in the
+ Discovery Response Message:
+
+ o CAPWAP Control IPv4 Address, see Section 4.6.10
+
+ o CAPWAP Control IPv6 Address, see Section 4.6.11
+
+
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 99]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+7. Control Channel Management
+
+ The Control Channel Management messages are used by the WTP and AC to
+ maintain a control communication channel. CAPWAP control messages,
+ such as the WTP Event Request message sent from the WTP to the AC
+ indicate to the AC that the WTP is operational. When such control
+ messages are not being sent, the Echo Request and Echo Response
+ messages are used to maintain the control communication channel.
+
+7.1. Echo Request
+
+ The Echo Request message is a keep-alive mechanism for CAPWAP control
+ messages.
+
+ Echo Request messages are sent periodically by a WTP in the Run state
+ (see Section 2.3) to determine the state of the control connection
+ between the WTP and the AC. The Echo Request message is sent by the
+ WTP when the EchoInterval timer expires. The WTP MUST start its
+ NeighborDeadInterval timer when the EchoInterval timer expires.
+
+ The Echo Request message is sent by the WTP when in the Run State.
+ The AC does not transmit this message.
+
+ The Echo Request message carries no message elements.
+
+ When an AC receives an Echo Request message it responds with an Echo
+ Response message.
+
+7.2. Echo Response
+
+ The Echo Response message acknowledges the Echo Request message.
+
+ An Echo Response message is sent by an AC after receiving an
+ EchoRequest message. After transmitting the Echo Response message,
+ the AC SHOULD reset its EchoInterval timer. If another Echo Request
+ message or other control message is not received by the AC when the
+ timer expires, the AC SHOULD consider the WTP to be no longer
+ reachable.
+
+ The Echo Response message is sent by the AC when in the Run State.
+ The WTP does not transmit this message.
+
+ The Echo Response message carries no message elements.
+
+ When a WTP receives an Echo Response message it stops the
+ NeighborDeadInterval timer, and initializes the EchoInterval to the
+ configured value.
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 100]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ If the NeighborDeadInterval timer expires prior to receiving an Echo
+ Response message, or other control message, the WTP enters the Idle
+ state.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 101]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+8. WTP Configuration Management
+
+ WTP Configuration messages are used to exchange configuration
+ information between the AC and the WTP.
+
+8.1. Configuration Consistency
+
+ The CAPWAP protocol provides flexibility in how WTP configuration is
+ managed. A WTP has two options:
+
+ 1. The WTP retains no configuration and accepts the configuration
+ provided by the AC.
+
+ 2. The WTP retains the configuration of parameters provided by the AC
+ that are non-default values.
+
+ If the WTP opts to save configuration locally, the CAPWAP protocol
+ state machine defines the Configure state, which allows for
+ configuration exchange. In the Configure state, the WTP sends its
+ current configuration overrides to the AC via the Configuration
+ Status message. A configuration override is a non-default parameter.
+ As an example, in the CAPWAP protocol, the default antenna
+ configuration is internal omni antenna. A WTP that either has no
+ internal antennas, or has been explicitly configured by the AC to use
+ external antennas, sends its antenna configuration during the
+ configure phase, allowing the AC to become aware of the WTP's current
+ configuration.
+
+ Once the WTP has provided its configuration to the AC, the AC sends
+ its configuration to the WTP. This allows the WTP to receive
+ configuration and policies from the AC.
+
+ The AC maintains a copy of each active WTP configuration. There is
+ no need for versioning or other means to identify configuration
+ changes. If a WTP becomes inactive, the AC MAY delete the inactive
+ WTP configuration. If a WTP fails, and connects to a new AC, the WTP
+ provides its overridden configuration parameters, allowing the new AC
+ to be aware of the WTP configuration.
+
+ This model allows for resiliency in case of an AC failure, ensuring
+ another AC can provide service to the WTP. A new AC would be
+ automatically updated with WTP configuration changes, eliminating the
+ need for inter-AC communication and the need for all ACs to be aware
+ of the configuration of all WTPs in the network.
+
+ Once the CAPWAP protocol enters the Run state, the WTPs begin to
+ provide service. It is common for administrators to require that
+ configuration changes be made while the network is operational.
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 102]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ Therefore, the Configuration Update Request is sent by the AC to the
+ WTP to make these changes at run-time.
+
+8.1.1. Configuration Flexibility
+
+ The CAPWAP protocol provides the flexibility to configure and manage
+ WTPs of varying design and functional characteristics. When a WTP
+ first discovers an AC, it provides primary functional information
+ relating to its type of MAC and to the nature of frames to be
+ exchanged. The AC configures the WTP appropriately. The AC also
+ establishes corresponding internal state for the WTP.
+
+8.2. Configuration Status
+
+ The Configuration Status message is sent by a WTP to deliver its
+ current configuration to the AC.
+
+ The Configuration Status message carries binding specific message
+ elements. Refer to the appropriate binding for the definition of
+ this structure.
+
+ When an AC receives a Configuration Status message it acts upon the
+ content of the message and responds to the WTP with a Configuration
+ Status Response message.
+
+ The Configuration Status message includes multiple Radio
+ Administrative State message elements, one for the WTP, and one for
+ each radio in the WTP.
+
+ The Configuration Status message is sent by the WTP when in the
+ Configure State. The AC does not transmit this message.
+
+ The following message elements MUST be included in the Configuration
+ Status message.
+
+ o AC Name, see Section 4.6.4
+
+ o AC Name with Index, see Section 4.6.5
+
+ o Radio Administrative State, see Section 4.6.31
+
+ o Statistics Timer, see Section 4.6.36
+
+ o WTP Reboot Statistics, see Section 4.6.48
+
+ The following message elements MAY be included in the Configuration
+ Status message.
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 103]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ o WTP Static IP Address Information, see Section 4.6.49
+
+8.3. Configuration Status Response
+
+ The Configuration Status Response message is sent by an AC and
+ provides a mechanism for the AC to override a WTP's requested
+ configuration.
+
+ A Configuration Status Response message is sent by an AC after
+ receiving a Configuration Request message.
+
+ The Configuration Status Response message carries binding specific
+ message elements. Refer to the appropriate binding for the
+ definition of this structure.
+
+ When a WTP receives a Configuration Status Response message it acts
+ upon the content of the message, as appropriate. If the
+ Configuration Status Response message includes a Radio Operational
+ State message element that causes a change in the operational state
+ of one of the radios, the WTP transmits a Change State Event to the
+ AC, as an acknowledgement of the change in state.
+
+ The Configuration Status Response message is sent by the AC when in
+ the Configure State. The WTP does not transmit this message.
+
+ The following message elements MUST be included in the Configuration
+ Status Response message.
+
+ o AC IPv4 List, see Section 4.6.2
+
+ o AC IPv6 List, see Section 4.6.3
+
+ o CAPWAP Timers, see Section 4.6.12
+
+ o Decryption Error Report Period, see Section 4.6.16
+
+ o Idle Timeout, see Section 4.6.23
+
+ o WTP Fallback, see Section 4.6.40
+
+ The following message element MAY be included in the Configuration
+ Status Response message.
+
+ o WTP Static IP Address Information, see Section 4.6.49
+
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 104]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+8.4. Configuration Update Request
+
+ Configuration Update Request messages are sent by the AC to provision
+ the WTP while in the Run state. This is used to modify the
+ configuration of the WTP while it is operational.
+
+ When a WTP receives a Configuration Update Request message, it
+ responds with a Configuration Update Response message, with a Result
+ Code message element indicating the result of the configuration
+ request.
+
+ The AC includes the Image Identifier and Initiate Download message
+ elements to force the WTP to update its firmware while in the Run
+ state. The WTP MAY proceed to download the requested firmware if it
+ determines the version specified in the Image Identifier message
+ element is not in its non-volatile storage (see Section 9.1.1).
+
+ The Configuration Update Request is sent by the AC when in the Run
+ State. The WTP does not transmit this message.
+
+ One or more of the following message elements MAY be included in the
+ Configuration Update message.
+
+ o AC Name with Index, see Section 4.6.5
+
+ o AC Timestamp, see Section 4.6.6
+
+ o Add MAC ACL Entry, see Section 4.6.7
+
+ o Add Static MAC ACL Entry, see Section 4.6.9
+
+ o CAPWAP Timers, see Section 4.6.12
+
+ o Decryption Error Report Period, see Section 4.6.16
+
+ o Delete MAC ACL Entry, see Section 4.6.17
+
+ o Delete Static MAC ACL Entry, see Section 4.6.19
+
+ o Idle Timeout, see Section 4.6.23
+
+ o Location Data, see Section 4.6.28
+
+ o Radio Administrative State, see Section 4.6.31
+
+ o Statistics Timer, see Section 4.6.36
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 105]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ o WTP Fallback, see Section 4.6.40
+
+ o WTP Name, see Section 4.6.45
+
+ o WTP Static IP Address Information, see Section 4.6.49
+
+ o Image Identifier, see Section 4.6.25
+
+ o Initiate Download, see Section 4.6.27
+
+8.5. Configuration Update Response
+
+ The Configuration Update Response message is the acknowledgement
+ message for the Configuration Update Request message.
+
+ The Configuration Update Response message is sent by a WTP after
+ receiving a Configuration Update Request message.
+
+ When an AC receives a Configuration Update Response message the
+ result code indicates if the WTP successfully accepted the
+ configuration.
+
+ The Configuration Update Response message is sent by the WTP when in
+ the Run State. The AC does not transmit this message.
+
+ The following message element MUST be present in the Configuration
+ Update message.
+
+ Result Code, see Section 4.6.33
+
+ The following message elements MAY be present in the Configuration
+ Update Response message.
+
+ o Radio Operational State, see Section 4.6.32
+
+8.6. Change State Event Request
+
+ The Change State Event Request message is used by the WTP for two
+ main purposes:
+
+ o When sent by the WTP following the reception of a Configuration
+ Status Response message from the AC, the WTP uses the Change State
+ Event Request message to provide an update on the WTP radio's
+ operational state and to confirm that the configuration provided
+ by the AC was successfully applied.
+
+ o When sent during the Run state, the WTP uses the Change State
+ Event Request message to notify the AC of an unexpected change in
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 106]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ the WTP's radio operational state.
+
+ When an AC receives a Change State Event Request message it responds
+ with a Change State Event Response message and modifies its data
+ structures for the WTP as needed. The AC MAY decide not to provide
+ service to the WTP if it receives an error, based on local policy,
+ and to transition to the Reset state.
+
+ The Change State Event Request message is sent by a WTP to
+ acknowledge or report an error condition to the AC for a requested
+ configuration in the Configuration Status Response message. The
+ Change State Event Request message includes the Result Code message
+ element, which indicates whether the configuration was successfully
+ applied. If the WTP is unable to apply a specfic configuration
+ request, it indicates the failure by including one or more Returned
+ Message Element message elements (see Section 4.6.34).
+
+ The Change State Event Request message is sent by the WTP in the
+ Configure or Run State. The AC does not transmit this message.
+
+ The WTP MAY save its configuration to persistent storage prior to
+ transmitting the response. However, this is implementation specific
+ and is not required.
+
+ The following message elements MUST be present in the Change State
+ Event Request message.
+
+ o Radio Operational State, see Section 4.6.32
+
+ o Result Code, see Section 4.6.33
+
+ One or more of the following message elements MAY be present in the
+ Change State Event Request message.
+
+ o Returned Message Element(s), see Section 4.6.34
+
+8.7. Change State Event Response
+
+ The Change State Event Response message acknowledges the Change State
+ Event Request message.
+
+ A Change State Event Response message is sent by an AC in response to
+ a Change State Event Request message.
+
+ The Change State Event Response message is sent by the AC when in the
+ Configure or Run state. The WTP does not transmit this message.
+
+ The Change State Event Response message carries no message elements.
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 107]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ The WTP does not take any action upon receipt of the Change State
+ Event Response message.
+
+8.8. Clear Configuration Request
+
+ The Clear Configuration Request message is used to reset the WTP
+ configuration.
+
+ The Clear Configuration Request message is sent by an AC to request
+ that a WTP reset its configuration to the manufacturing default
+ configuration. The Clear Config Request message is sent while in the
+ Run state.
+
+ The Clear Configuration Request is sent by the AC when in the Run
+ State. The WTP does not transmit this message.
+
+ The Clear Configuration Request message carries no message elements.
+
+ When a WTP receives a Clear Configuration Request message it resets
+ its configuration to the manufacturing default configuration.
+
+8.9. Clear Configuration Response
+
+ The Clear Configuration Response message is sent by the WTP after
+ receiving a Clear Configuration Request message and resetting its
+ configuration parameters to the manufacturing default values.
+
+ The Clear Configuration Response is sent by the WTP when in the Run
+ State. The AC does not transmit this message.
+
+ The Clear Configuration Request message MUST include the following
+ message element.
+
+ o Result Code, see Section 4.6.33
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 108]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+9. Device Management Operations
+
+ This section defines CAPWAP operations responsible for debugging,
+ gathering statistics, logging, and firmware management.
+
+9.1. Firmware Management
+
+ This section describes the firmware download procedures used by the
+ CAPWAP protocol. Firmware download can occur during the Image Data
+ or Run state.
+
+ Figure 4 provides an example of a WTP that performs a firmware
+ upgrade while in the Image Data state. In this example, the WTP does
+ not already have the requested firmware (Image Identifier = x), and
+ downloads the image from the AC.
+
+ WTP AC
+
+ Join Request
+ -------------------------------------------------------->
+
+ Join Response (Image Identifier = x)
+ <------------------------------------------------------
+
+ Image Data Request (Image Identifier = x)
+ -------------------------------------------------------->
+
+ Image Data Response (Result Code = Success,
+ Image Information = {size,hash},
+ Initiate Download)
+ <------------------------------------------------------
+
+ Image Data Request (Image Data = Data)
+ <------------------------------------------------------
+
+ Image Data Response (Result Code = Success)
+ -------------------------------------------------------->
+
+ .....
+
+ Image Data Request (Image Data = EOF)
+ <------------------------------------------------------
+
+ Image Data Response (Result Code = Success)
+ -------------------------------------------------------->
+
+ (WTP enters the Reset State)
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 109]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ Figure 4: WTP Firmware Download Case 1
+
+ Figure 5 provides an example in which the WTP has the image specified
+ by the AC in its non-volative storage. The WTP opts to NOT download
+ the firmware and immediately reset.
+
+ WTP AC
+
+ Join Request
+ -------------------------------------------------------->
+
+ Join Response (Image Identifier = x)
+ <------------------------------------------------------
+
+ (WTP enters the Reset State)
+
+ Figure 5: WTP Firmware Download Case 2
+
+ Figure 6 provides an example of a WTP that performs a firmware
+ upgrade while in the Run state. This mode of firmware upgrade allows
+ the WTP to download its image while continuing to provide service.
+ The WTP will not automatically reset until it is notified by the AC,
+ with a Reset Request message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 110]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ WTP AC
+
+ Configuration Update Request (Image Identifier = x)
+ <------------------------------------------------------
+
+ Configuration Update Response (Result Code = Success)
+ -------------------------------------------------------->
+
+
+ Image Data Request (Image Identifier = x)
+ -------------------------------------------------------->
+
+ Image Data Response (Result Code = Success,
+ Image Information = {size,hash},
+ Initiate Download)
+ <------------------------------------------------------
+
+ Image Data Request (Image Data = Data)
+ <------------------------------------------------------
+
+ Image Data Response (Result Code = Success)
+ -------------------------------------------------------->
+
+ .....
+
+ Image Data Request (Image Data = EOF)
+ <------------------------------------------------------
+
+ Image Data Response (Result Code = Success)
+ -------------------------------------------------------->
+
+ .....
+
+ (administratively requested reboot request)
+ Reset Request (Image Identifier = x)
+ <------------------------------------------------------
+
+ Reset Response (Result Code = Success)
+ -------------------------------------------------------->
+
+ Figure 6: WTP Firmware Download Case 3
+
+ Figure 7 provides another example of the firmware download while in
+ the Run state. In this example, the WTP already has the image
+ specified by the AC in its non-volative storage. The WTP opts to NOT
+ download the firmware. The WTP resets upon receipt of a Reset
+ Request message from the AC.
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 111]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ WTP AC
+
+ Configuration Update Request (Image Identifier = x,
+ Image Information = {size,hash},
+ Initiate Download)
+ <------------------------------------------------------
+
+ Configuration Update Response (Result Code = Already Have Image)
+ -------------------------------------------------------->
+
+ .....
+
+ (administratively requested reboot request)
+ Reset Request (Image Identifier = x)
+ <------------------------------------------------------
+
+ Reset Response (Result Code = Success)
+ -------------------------------------------------------->
+
+ Figure 7: WTP Firmware Download Case 4
+
+9.1.1. Image Data Request
+
+ The Image Data Request message is used to update firmware on the WTP.
+ This message and its companion Response message are used by the AC to
+ ensure that the image being run on each WTP is appropriate.
+
+ Image Data Request messages are exchanged between the WTP and the AC
+ to download a new firmware image to the WTP. When a WTP or AC
+ receives an Image Data Request message it responds with an Image Data
+ Response message. The message elements contained within the Image
+ Data Request message are required to determine the intent of the
+ request.
+
+ The decision that new firmware is to be downloaded to the WTP can
+ occur in one of two ways:
+
+ When the WTP joins the AC, the Join Response message includes the
+ Image Identifier message element, which informs the WTP of the
+ firmware it is expected to run. if the WTP does not currently have
+ the requested firmware version, it transmits an Image Data Request
+ message, with the appropriate Image Identifier message element.
+ If the WTP already has the requested firmware, it simply resets.
+
+ Once the WTP is in the Run state, it is possible for the AC to
+ cause the WTP to initiate a firmware download by sending a
+ Configuration Update Request message with the Initiate Download
+ and and Image Identifier message elements. The WTP then transmits
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 112]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ the Image Data Request message, which includes the Image
+ Identifier message element to start the download process. Note
+ that when the firmware is downloaded in this way, the WTP does not
+ automatically reset after the download is complete. The WTP will
+ only reset when it receives a Reset Request message from the AC.
+ If the WTP already had the requested firmware version in its non-
+ volatile storage, the WTP does not transmit the Image Data Request
+ message and responds with a Configuration Update Response message
+ with the Result Code set to Image Already Present.
+
+ Regardless of how the download was initiated, once the AC receives an
+ Image Data Request message with the Image Identifier message element,
+ it begins the transfer process by transmitting an Image Data Request
+ message that includes the Image Data message element. This continues
+ until the firmware image has been transfered.
+
+ The Image Data Request message is sent by the WTP or the AC when in
+ the Image Data or Run State.
+
+ The following message elements MAY be included in the Image Data
+ Request message.
+
+ o Image Data, see Section 4.6.24
+
+ o Image Identifier, see Section 4.6.25
+
+9.1.2. Image Data Response
+
+ The Image Data Response message acknowledges the Image Data Request
+ message.
+
+ An Image Data Response message is sent in response to a received
+ Image Data Request message. Its purpose is to acknowledge the
+ receipt of the Image Data Request message. The Result Code is
+ included to indicate whether a previously sent Image Data Request
+ message was invalid.
+
+ The Image Data Response message is sent by the WTP or the AC when in
+ the Image Data or Run State.
+
+ The following message element MUST be included in the Image Data
+ Response message.
+
+ o Result Code, see Section 4.6.33
+
+ The following message elements MAY be included in the Image Data
+ Response message.
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 113]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ o Image Information, see Section 4.6.26
+
+ o Initiate Download, see Section 4.6.27
+
+ Upon receiving an Image Data Response message indicating an error,
+ the WTP MAY retransmit a previous Image Data Reqest message, or
+ abandon the firmware download to the WTP by transitioning to the
+ Reset state.
+
+9.2. Reset Request
+
+ The Reset Request message is used to cause a WTP to reboot.
+
+ A Reset Request message is sent by an AC to cause a WTP to
+ reinitialize its operation.
+
+ The Reset Request is sent by the AC when in the Run State. The WTP
+ does not transmit this message.
+
+ The following message elements MUST be included in the Reset Request
+ message.
+
+ o Image Identifier, see Section 4.6.25
+
+ When a WTP receives a Reset Request message, it responds with a Reset
+ Response message indicating success and then reinitialize itself. If
+ the WTP is unable to write to its non-volatile storage, to ensure
+ that it runs the requested software version indicated in the Image
+ Identifier message element, it MAY send the appropriate Result Code
+ message element, but MUST reboot. If the WTP is unable to reset,
+ including a hardware reset, it sends a Reset Response message to the
+ AC with a Result Code message element indicating failure. The AC no
+ longer provides service to the WTP.
+
+9.3. Reset Response
+
+ The Reset Response message acknowledges the Reset Request message.
+
+ A Reset Response message is sent by the WTP after receiving a Reset
+ Request message.
+
+ The Reset Response is sent by the WTP when in the Run State. The AC
+ does not transmit this message.
+
+ The following message element MAY be included in the Image Data
+ Request message.
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 114]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ o Result Code, see Section 4.6.33
+
+ When an AC receives a successful Reset Response message, it is
+ notified that the WTP will reinitialize its operation. An AC that
+ receives a Reset Response message indicating failure may opt to no
+ longer provide service to the WTP.
+
+9.4. WTP Event Request
+
+ The WTP Event Request message is used by a WTP to send information to
+ its AC. The WTP Event Request message MAY be sent periodically, or
+ sent in response to an asynchronous event on the WTP. For example, a
+ WTP MAY collect statistics and use the WTP Event Request message to
+ transmit the statistics to the AC.
+
+ When an AC receives a WTP Event Request message it will respond with
+ a WTP Event Response message.
+
+ The presence of the Delete Station message element is used by the WTP
+ to inform the AC that it is no longer providing service to the
+ station. This could be the result of an Idle Timeout (see
+ Section 4.6.23), due to to resource shortages, or some other reason.
+
+ The WTP Event Request message is sent by the WTP when in the Run
+ State. The AC does not transmit this message.
+
+ The WTP Event Request message MUST contain one of the message
+ elements listed below, or a message element that is defined for a
+ specific wireless technology. More than one of each messsage element
+ listed MAY be included in the WTP Event Request message.
+
+ o Decryption Error Report, see Section 4.6.15
+
+ o Duplicate IPv4 Address, see Section 4.6.21
+
+ o Duplicate IPv6 Address, see Section 4.6.22
+
+ o WTP Operational Statistics, see Section 4.6.46
+
+ o WTP Radio Statistics, see Section 4.6.47
+
+ o WTP Reboot Statistics, see Section 4.6.48
+
+ o Delete Station, see Section 4.6.18
+
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 115]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+9.5. WTP Event Response
+
+ The WTP Event Response message acknowledges receipt of the WTP Event
+ Request message.
+
+ A WTP Event Response message is sent by an AC after receiving a WTP
+ Event Request message.
+
+ The WTP Event Response message is sent by the AC when in the Run
+ State. The WTP does not transmit this message.
+
+ The WTP Event Response message carries no message elements.
+
+9.6. Data Transfer Request
+
+ The Data Transfer Request message is used to deliver debug
+ information from the WTP to the AC.
+
+ Data Transfer Request messages are sent by the WTP to the AC when the
+ WTP determines that it has important information to send to the AC.
+ For instance, if the WTP detects that its previous reboot was caused
+ by a system crash, it can send the crash file to the AC. The remote
+ debugger function in the WTP also uses the Data Transfer Request
+ message to send console output to the AC for debugging purposes.
+
+ When the AC receives a Data Transfer Request message it responds to
+ the WTP with a Data Transfer Response message. The AC MAY log the
+ information received.
+
+ The Data Transfer Request message is sent by the WTP when in the Run
+ State. The AC does not transmit this message.
+
+ The Data Transfer Request message MUST contain one of the message
+ elements listed below.
+
+ o Data Transfer Data, see Section 4.6.13
+
+ o Data Transfer Mode, see Section 4.6.14
+
+9.7. Data Transfer Response
+
+ The Data Transfer Response message acknowledges the Data Transfer
+ Request message.
+
+ A Data Transfer Response message is sent in response to a received
+ Data Transfer Request message. Its purpose is to acknowledge receipt
+ of the Data Transfer Request message.
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 116]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ The Data Transfer Response message is sent by the AC when in the Run
+ State. The WTP does not transmit this message.
+
+ The Data Transfer Response message carries no message elements.
+
+ Upon receipt of a Data Transfer Response message, the WTP transmits
+ more information, if more information is available.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 117]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+10. Station Session Management
+
+ Messages in this section are used by the AC to create, modify or
+ delete station session state on the WTPs.
+
+10.1. Station Configuration Request
+
+ The Station Configuration Request message is used to create, modify
+ or delete station session state on a WTP. The message is sent by the
+ AC to the WTP, and MAY contain one or more message elements. The
+ message elements for this CAPWAP control message include information
+ that is generally highly technology specific. Refer to the
+ appropriate binding document for definitions of the messages elements
+ that are included in this control message.
+
+ The Station Configuration Request message is sent by the AC when in
+ the Run State. The WTP does not transmit this message.
+
+ The following CAPWAP Control message elements MAY be included in the
+ Station Configuration Request message. More than one of each message
+ element listed MAY be included in the Station Configuration Request
+ message.
+
+ o Add Station, see Section 4.6.8
+
+ o Delete Station, see Section 4.6.18
+
+10.2. Station Configuration Response
+
+ The Station Configuration Response message is used to acknowledge a
+ previously received Station Configuration Request message.
+
+ The Station Configuration Response message is sent by the WTP when in
+ the Run State. The AC does not transmit this message.
+
+ The following message element MUST be present in the Station
+ Configuration Response message.
+
+ o Result Code, see Section 4.6.33
+
+ The Result Code message element indicates that the requested
+ configuration was successfully applied, or that an error related to
+ processing of the Station Configuration Request message occurred on
+ the WTP.
+
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 118]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+11. NAT Considerations
+
+ There are three specific situations in which a NAT deployment may be
+ used in conjunction with a CAPWAP-enabled deployment. The first
+ consists of a configuration in which a single WTP is behind a NAT
+ system. Since all communication is initiated by the WTP, and all
+ communication is performed over IP using two UDP ports, the protocol
+ easily traverses NAT systems in this configuration.
+
+ In the second case, two or more WTPs are deployed behind the same NAT
+ system. Here, the AC would receive multiple connection requests from
+ the same IP address, and cannot differentiate the originating WTP of
+ the connection requests. The CAPWAP Data Check state, which
+ establishes the data plane connection and communicates the Data
+ Keepalive, includes the Session Identifier message element, which is
+ used to bind the control and data plane. Use of the Session
+ Identifier message element enables the AC to match the control and
+ data plane flows from multiple WTPs behind the same NAT system
+ (multiple WTPs sharing the same IP address).
+
+ In the third configuration, the AC is deployed behind a NAT. Two
+ issues exist in this situation. First, an AC communicates its
+ interfaces and corresponding WTP load using the CAPWAP Control
+ IP(v4/v6) Address message element. This message element is currently
+ mandatory, and if NAT compliance becomes an issue, it is possible to
+ either:
+
+ 1. Make the CAPWAP Control IP (v4/v6) Address optional, allowing the
+ WTP to use the known IP Address. Note that this approach
+ eliminates the ability to perform load balancing of WTP across
+ ACs, and therefore is not the recommended approach.
+
+ 2. Allow an AC to configure a NAT'ed address for every AC that would
+ otherwise be communicated in the CAPWAP Control IP (v4/v6) Address
+ message element.
+
+ 3. Require that if a WTP determines that the AC List message element
+ contains a set of IP Addresses that are different from the AC IP
+ Address the WTP is currently using, then assume that NAT is
+ present, and require that the WTP communicate with the AC IP
+ Address (and ignore the CAPWAP Control IP (v4/v6) Address message
+ element(s)).
+
+ The CAPWAP protocol allows for all of the AC identities supporting a
+ group of WTPs to be communicated through the AC List message element.
+ This feature MUST be disabled when the AC is behind a NAT and the IP
+ Address that is embedded is invalid.
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 119]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ The CAPWAP protocol allows an AC to configure a static IP address on
+ a WTP using the WTP Static IP Address Information message element.
+ This message element SHOULD NOT be used in NAT'ed environments,
+ unless the administrator is familiar with the internal IP addressing
+ scheme within the WTP's private network, and does not rely on the
+ public address seen by the AC.
+
+ When a WTP detects the duplicate address condition, it generates a
+ message to the AC, which includes the Duplicate IP Address message
+ element. The IP Address embedded within this message element is
+ different from the public IP address seen by the AC.
+
+ When CAPWAP is run over IPv6, NAT support can only be provided if the
+ IPv6 NAT system is capable of performing address translation over the
+ UDP-Lite 3828 protocol [11]. A protocol interoperability issues will
+ exist if the NAT system is being utilized for IPv4/IPv6 address
+ translation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 120]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+12. Security Considerations
+
+ This section describes security considerations for the CAPWAP
+ protocol. It also provides security recommendations for protocols
+ used in conjunction with CAPWAP.
+
+12.1. CAPWAP Security
+
+ As it is currently specified, the CAPWAP protocol sits between the
+ security mechanisms specified by the wireless link layer protocol
+ (e.g.IEEE 802.11i) and AAA. One goal of CAPWAP is to bootstrap trust
+ between the STA and WTP using a series of preestablished trust
+ relationships:
+
+
+ STA WTP AC AAA
+ ==============================================
+
+ DTLS Cred AAA Cred
+ <------------><------------->
+
+ EAP Credential
+ <------------------------------------------>
+
+ wireless link layer
+ (e.g.802.11 PTK)
+ <--------------> or
+ <--------------------------->
+ (derived)
+
+ Within CAPWAP, DTLS is used to secure the link between the WTP and
+ AC. In addition to securing control messages, it's also a link in
+ this chain of trust for establishing link layer keys. Consequently,
+ much rests on the security of DTLS.
+
+ In some CAPWAP deployment scenarios, there are two channels between
+ the WTP and AC: the control channel, carrying CAPWAP control
+ messages, and the data channel, over which client data packets are
+ tunneled between the AC and WTP. Typically, the control channel is
+ secured by DTLS, while the data channel is not.
+
+ The use of parallel protected and unprotected channels deserves
+ special consideration, but does not create a threat. There are two
+ potential concerns: attempting to convert protected data into un-
+ protected data and attempting to convert un-protected data into
+ protected data. These concerns are addressed below.
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 121]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+12.1.1. Converting Protected Data into Unprotected Data
+
+ Since CAPWAP does not support authentication-only ciphers (i.e. all
+ supported ciphersuites include encryption and authentication), it is
+ not possible to convert protected data into unprotected data. Since
+ encrypted data is (ideally) indistinguishable from random data, the
+ probability of an encrypted packet passing for a well-formed packet
+ is effectively zero.
+
+12.1.2. Converting Unprotected Data into Protected Data (Insertion)
+
+ The use of message authentication makes it impossible for the
+ attacker to forge protected records. This makes conversion of
+ unprotected records to protected records impossible.
+
+12.1.3. Deletion of Protected Records
+
+ An attacker could remove protected records from the stream, though
+ not undetectably so, due the built-in reliability of the underlying
+ CAPWAP protocol. In the worst case, the attacker would remove the
+ same record repeatedly, resulting in a CAPWAP session timeout and
+ restart. This is effectively a DoS attack, and could be accomplished
+ by a man in the middle regardless of the CAPWAP protocol security
+ mechanisms chosen.
+
+12.1.4. Insertion of Unprotected Records
+
+ An attacker could inject packets into the unprotected channel, but
+ this may become evident if sequence number desynchronization occurs
+ as a result. Only if the attacker is a MiM can packets be inserted
+ undetectably. This is a consequence of that channel's lack of
+ protection, and not a new threat resulting from the CAPWAP security
+ mechanism.
+
+12.2. Session ID Security
+
+ Since DTLS does not export a unique session identifier, there can be
+ no explicit protocol binding between the DTLS layer and CAPWAP layer.
+ As a result, implementations MUST provide a mechanism for performing
+ this binding. For example, an AC MUST NOT associate decrypted DTLS
+ control packets with a particular WTP session based solely on the
+ Session ID in the packet header. Instead, identification should be
+ done based on which DTLS session decrypted the packet. Otherwise one
+ authenticated WTP could spoof another authenticated WTP by altering
+ the Session ID in the encrypted CAPWAP header.
+
+ It should be noted that when the CAPWAP data channel is unencrypted,
+ the WTP Session ID is exposed and possibly known to adversaries and
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 122]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ other WTPs. This would allow the forgery of the source of data-
+ channel traffic. This, however, should not be a surprise for
+ unencrypted data channels. When the data channel is encrypted, the
+ Session ID is not exposed, and therefore can safely be used to
+ associate a data and control channel. The 64-bit length of the
+ Session ID mitigates online guessing attacks where an adversarial,
+ authenticated WTP tries to correlate his own data channel with
+ another WTP's control channel. Note that for encrypted data
+ channels, the Session ID should only be used for correlation for the
+ first packet immediately after the initial DTLS handshake. Future
+ correlation should instead be done via identification of a packet's
+ DTLS session.
+
+12.3. Discovery Attacks
+
+ Since the Discovery Request messages are sent in the clear, it is
+ important that AC implementations NOT assume that receiving such a
+ request from a WTP implies that it has rebooted, and consequently
+ tear down any active DTLS sessions. Discovery Request messages can
+ easily be spoofed by malicious devices, so it is important that the
+ AC maintain two separate sets of states for the WTP until the
+ DTLSSessionEstablished notification is received, indicating that the
+ WTP was authenticated. Once a new DTLS session is successfully
+ established, any state referring to the old session can be cleared.
+
+12.4. Interference with a DTLS Session
+
+ If a WTP or AC repeatedly receives packets which fail DTLS
+ authentication or decryption, this could indicate a DTLS
+ desynchronization between the AC and WTP, a link prone to
+ undetectable bit errors, or an attacker trying to disrupt a DTLS
+ session.
+
+ In the state machine (section 2.3), transitions to the DTLS tear down
+ state can be triggered by frequently receiving DTLS packets with
+ authentication or decryption errors. The threshold or technique for
+ deciding when to move to the tear down state should be chosen
+ carefully. Being able to easily transition to DTLS TD allows easy
+ detection of malfunctioning devices, but allows for denial of service
+ attacks. Making it difficult to transition to DTLS TD prevents
+ denial of service attacks, but makes it more difficult to detect and
+ reset a malfunctioning session. Implementers should set this policy
+ with care.
+
+12.5. Use of Preshared Keys in CAPWAP
+
+ While use of preshared keys may provide deployment and provisioning
+ advantages not found in public key based deployments, it also
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 123]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ introduces a number of operational and security concerns. In
+ particular, because the keys must typically be entered manually, it
+ is common for people to base them on memorable words or phrases.
+ These are referred to as "low entropy passwords/passphrases".
+
+ Use of low-entropy preshared keys, coupled with the fact that the
+ keys are often not frequently updated, tends to significantly
+ increase exposure. For these reasons, the following recommendations
+ are made:
+
+ o When DTLS is used with a preshared-key (PSK) ciphersuite, each WTP
+ SHOULD have a unique PSK. Since WTPs will likely be widely
+ deployed, their physical security is not guaranteed. If PSKs are
+ not unique for each WTP, key reuse would allow the compromise of
+ one WTP to result in the compromise of others
+
+ o Generating PSKs from low entropy passwords is NOT RECOMMENDED.
+
+ o It is RECOMMENDED that implementations that allow the
+ administrator to manually configure the PSK also provide a
+ capability for generation of new random PSKs, taking RFC 4086 [2]
+ into account.
+
+ o Preshared keys SHOULD be periodically updated. Implementations
+ MAY facilitate this by providing an administrative interface for
+ automatic key generation and periodic update, or it MAY be
+ accomplished manually instead.
+
+ Every pairwise combination of WTP and AC on the network SHOULD have a
+ unqiue PSK. This prevents the domino effect (see Guidance for AAA
+ Key Management [16]). If PSKs are tied to specific WTPs, then
+ knowledge of the PSK implies a binding to a specified identity that
+ can be authorized.
+
+ If PSKs are shared, this binding between device and identity is no
+ longer possible. Compromise of one WTP can yield compromise of
+ another WTP, violating the CAPWAP security hierarchy. Consequently,
+ sharing keys between WTPs is NOT RECOMMENDED.
+
+12.6. Use of Certificates in CAPWAP
+
+ For public-key-based DTLS deployments, each device SHOULD have unique
+ credentials, with an extended key usage authorizing the device to act
+ as either a WTP or AC. If devices do not have unique credentials, it
+ is possible that by compromising one device, any other device using
+ the same credential may also be considered to be compromised.
+
+ Certificate validation involves checking a large variety of things.
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 124]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+ Since the necessary things to validate are often environment-
+ specific, many are beyond the scope of this document. In this
+ section, we provide some basic guidance on certificate validation.
+
+ Each device is responsible for authenticating and authorizing devices
+ with which they communicate. Authentication entails validation of
+ the chain of trust leading to the peer certificate, followed by the
+ the peer certificate itself. At a minimum, devices SHOULD use SSH-
+ style certificate caching to guarantee consistency. If devices have
+ access to a certificate authority, they SHOULD properly validate the
+ trust chain. Implementations SHOULD also provide a secure method for
+ verifying that the credential in question has not been revoked.
+
+ Note that if the WTP relies on the AC for network connectivity (e.g.
+ the AC is a layer 2 switch to which the WTP is directly connected),
+ the WTP may not be able to contact an OCSP server or otherwise obtain
+ an up to date CRL if a compromised AC doesn't explicitly permit this.
+ This cannot be avoided, except through effective physical security
+ and monitoring measures at the AC.
+
+ Proper validation of certificates typically requires checking to
+ ensure the certificate has not yet expired. If devices have a real-
+ time clock, they SHOULD verify the certificate validity dates. If no
+ real-time clock is available, the device SHOULD make a best-effort
+ attempt to validate the certificate validity dates through other
+ means. Failure to check a certificate's temporal validity can make a
+ device vulnerable to man-in-the-middle attacks launched using
+ compromised, expired certificates, and therefore devices should make
+ every effort to perform this validation.
+
+12.7. AAA Security
+
+ The AAA protocol is used to distribute EAP keys to the ACs, and
+ consequently its security is important to the overall system
+ security. When used with TLS or IPsec, security guidelines specified
+ in RFC 3539 [5] SHOULD be followed.
+
+ In general, the link between the AC and AAA server SHOULD be secured
+ using a strong ciphersuite keyed with mutually authenticated session
+ keys. Implementations SHOULD NOT rely solely on Basic RADIUS shared
+ secret authentication as it is often vulnerable to dictionary
+ attacks, but rather SHOULD use stronger underlying security
+ mechanisms.
+
+
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 125]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+13. Management Considerations
+
+ The CAPWAP protocol assumes that it is the only configuration
+ interface to the WTP to configure parameters that are specified in
+ the CAPWAP specifications. While the use of a separate management
+ protocol MAY be used for the purposes of monitoring the WTP directly,
+ configuring the WTP through a separate management interface is not
+ recommended. Configuring the WTP through a separate protocol, such
+ as via a CLI or SNMP, could lead to the AC state being out of sync
+ with the WTP.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 126]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+14. IANA Considerations
+
+ A separate UDP port for data channel communications is (currently)
+ the selected demultiplexing mechanism, and a port must be assigned
+ for this purpose in Section 3.1. The UDP port numbers are listed by
+ IANA at http://www.iana.org/assignments/port-numbers.
+
+ IANA needs to assign an organization local multicast address called
+ the "All ACs multicast address" from the IPv6 multicast address
+ registry in Section 3.3
+
+14.1. CAPWAP Message Types
+
+ The Message Type field in the CAPWAP header (Section 4.5.1.1) is used
+ to identify the operation performed by the message. There are
+ multiple namespaces, which is identified via the first three octets
+ of the field containing the IANA Enterprise Number [10]. When the
+ Enterprise Number is set to zero, the message types are reserved for
+ use by the base CAPWAP specification which are controlled and
+ maintained by IANA and requires a Standards Action.
+
+14.2. Wireless Binding Identifiers
+
+ The Wireless Binding Identifier (WBID) field in the CAPWAP header
+ (Section 4.3) is used to identify the wireless technology associated
+ with the packet. Due to the limited address space available, a new
+ WBID request requires Standards Action.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 127]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+15. Acknowledgements
+
+ The following individuals are acknowledged for their contributions to
+ this protocol specification: Puneet Agarwal, Saravanan Govindan,
+ Peter Nilsson, and David Perkins.
+
+ Michael Vakulenko contributed text to describe how CAPWAP can be used
+ over layer 3 (IP/UDP) networks.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 128]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+16. References
+
+16.1. Normative References
+
+ [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [2] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
+ Requirements for Security", BCP 106, RFC 4086, June 2005.
+
+ [3] Mills, D., "Network Time Protocol (Version 3) Specification,
+ Implementation", RFC 1305, March 1992.
+
+ [4] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
+ Public Key Infrastructure Certificate and Certificate
+ Revocation List (CRL) Profile", RFC 3280, April 2002.
+
+ [5] Aboba, B. and J. Wood, "Authentication, Authorization and
+ Accounting (AAA) Transport Profile", RFC 3539, June 2003.
+
+ [6] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for
+ Transport Layer Security (TLS)", RFC 4279, December 2005.
+
+ [7] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
+ Protocol Version 1.1", RFC 4346, April 2006.
+
+ [8] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
+ Security", RFC 4347, April 2006.
+
+ [9] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
+ Extensions", RFC 2132, March 1997.
+
+ [10] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+ Considerations Section in RFCs", BCP 26, RFC 2434,
+ October 1998.
+
+ [11] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G.
+ Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)",
+ RFC 3828, July 2004.
+
+ [12] Calhoun, P., Montemurro, M., Stanley, D., "CAPWAP Protocol
+ Binding for IEEE 802.11", draft-ietf-capwap-protocol-
+ binding-ieee80211-04 (work in progress), June 2007.
+
+ [13] Calhoun, P., "CAPWAP Access Controller DHCP Option",
+ draft-ietf-capwap-dhc-ac-option-00 (work in progress),
+ June 2007.
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 129]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+16.2. Informational References
+
+ [14] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-
+ line Database", RFC 3232, January 2002.
+
+ [15] Manner, J. and M. Kojo, "Mobility Related Terminology",
+ RFC 3753, June 2004.
+
+ [16] Housley, R. and B. Aboba, "Guidance for AAA Key Management",
+ draft-housley-aaa-key-mgmt-09 (work in progress),
+ February 2007.
+
+ [17] Modadugu et al, N., "The Design and Implementation of Datagram
+ TLS", Feb 2004.
+
+ [18] IEEE, "Guidelines for use of a 48-bit Extended Unique
+ Identifier", Dec 2005.
+
+ [19] IEEE, "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64)
+ REGISTRATION AUTHORITY".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 130]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+Editors' Addresses
+
+ Pat R. Calhoun
+ Cisco Systems, Inc.
+ 170 West Tasman Drive
+ San Jose, CA 95134
+
+ Phone: +1 408-853-5269
+ Email: pcalhoun@cisco.com
+
+
+ Michael P. Montemurro
+ Research In Motion
+ 5090 Commerce Blvd
+ Mississauga, ON L4W 5M4
+ Canada
+
+ Phone: +1 905-629-4746 x4999
+ Email: mmontemurro@rim.com
+
+
+ Dorothy Stanley
+ Aruba Networks
+ 1322 Crossman Ave
+ Sunnyvale, CA 94089
+
+ Phone: +1 630-363-1389
+ Email: dstanley@arubanetworks.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 131]
+
+Internet-Draft CAPWAP Protocol Specification June 2007
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2007).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+ THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+ OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+
+Acknowledgment
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+Calhoun, Editor, et al. Expires December 13, 2007 [Page 132]
+
+
+Html markup produced by rfcmarkup 1.111, available from
+https://tools.ietf.org/tools/rfcmarkup/
+
+
diff --git a/doc/rfc5416.txt b/doc/rfc5416.txt
new file mode 100644
index 00000000..4c0829c5
--- /dev/null
+++ b/doc/rfc5416.txt
@@ -0,0 +1,4259 @@
+
+
+
+
+
+
+Network Working Group P. Calhoun, Ed.
+Request for Comments: 5416 Cisco Systems, Inc.
+Category: Standards Track M. Montemurro, Ed.
+ Research In Motion
+ D. Stanley, Ed.
+ Aruba Networks
+ March 2009
+
+
+ Control and Provisioning of Wireless Access Points (CAPWAP) Protocol
+ Binding for IEEE 802.11
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (c) 2009 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 in effect on the date of
+ publication of this document (http://trustee.ietf.org/license-info).
+ Please review these documents carefully, as they describe your rights
+ and restrictions with respect to this document.
+
+ This document may contain material from IETF Documents or IETF
+ Contributions published or made publicly available before November
+ 10, 2008. The person(s) controlling the copyright in some of this
+ material may not have granted the IETF Trust the right to allow
+ modifications of such material outside the IETF Standards Process.
+ Without obtaining an adequate license from the person(s) controlling
+ the copyright in such materials, this document may not be modified
+ outside the IETF Standards Process, and derivative works of it may
+ not be created outside the IETF Standards Process, except to format
+ it for publication as an RFC or to translate it into languages other
+ than English.
+
+
+
+
+
+
+
+
+
+Calhoun, et al. Standards Track [Page 1]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+Abstract
+
+ Wireless LAN product architectures have evolved from single
+ autonomous access points to systems consisting of a centralized
+ Access Controller (AC) and Wireless Termination Points (WTPs). The
+ general goal of centralized control architectures is to move access
+ control, including user authentication and authorization, mobility
+ management, and radio management from the single access point to a
+ centralized controller.
+
+ This specification defines the Control And Provisioning of Wireless
+ Access Points (CAPWAP) Protocol Binding Specification for use with
+ the IEEE 802.11 Wireless Local Area Network protocol.
+
+Table of Contents
+
+ 1. Introduction ....................................................4
+ 1.1. Goals ......................................................5
+ 1.2. Conventions Used in This Document ..........................5
+ 1.3. Terminology ................................................5
+ 2. IEEE 802.11 Binding .............................................7
+ 2.1. CAPWAP Wireless Binding Identifier .........................7
+ 2.2. Split MAC and Local MAC Functionality ......................7
+ 2.2.1. Split MAC ...........................................7
+ 2.2.2. Local MAC ..........................................12
+ 2.3. Roaming Behavior ..........................................15
+ 2.4. Group Key Refresh .........................................16
+ 2.5. BSSID to WLAN ID Mapping ..................................17
+ 2.6. CAPWAP Data Channel QoS Behavior ..........................18
+ 2.6.1. IEEE 802.11 Data Frames ............................18
+ 2.6.1.1. 802.1p Support ............................19
+ 2.6.1.2. DSCP Support ..............................19
+ 2.6.2. IEEE 802.11 MAC Management Messages ................21
+ 2.7. Run State Operation .......................................21
+ 3. IEEE 802.11 Specific CAPWAP Control Messages ...................21
+ 3.1. IEEE 802.11 WLAN Configuration Request ....................22
+ 3.2. IEEE 802.11 WLAN Configuration Response ...................23
+ 4. CAPWAP Data Message Bindings ...................................23
+ 5. CAPWAP Control Message Bindings ................................25
+ 5.1. Discovery Request Message .................................25
+ 5.2. Discovery Response Message ................................25
+ 5.3. Primary Discovery Request Message .........................25
+ 5.4. Primary Discovery Response Message ........................26
+ 5.5. Join Request Message ......................................26
+ 5.6. Join Response Message .....................................26
+ 5.7. Configuration Status Request Message ......................26
+ 5.8. Configuration Status Response Message .....................27
+ 5.9. Configuration Update Request Message ......................27
+
+
+
+Calhoun, et al. Standards Track [Page 2]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ 5.10. Station Configuration Request ............................28
+ 5.11. Change State Event Request ...............................28
+ 5.12. WTP Event Request ........................................28
+ 6. IEEE 802.11 Message Element Definitions ........................29
+ 6.1. IEEE 802.11 Add WLAN ......................................29
+ 6.2. IEEE 802.11 Antenna .......................................35
+ 6.3. IEEE 802.11 Assigned WTP BSSID ............................36
+ 6.4. IEEE 802.11 Delete WLAN ...................................37
+ 6.5. IEEE 802.11 Direct Sequence Control .......................37
+ 6.6. IEEE 802.11 Information Element ...........................38
+ 6.7. IEEE 802.11 MAC Operation .................................39
+ 6.8. IEEE 802.11 MIC Countermeasures ...........................41
+ 6.9. IEEE 802.11 Multi-Domain Capability .......................42
+ 6.10. IEEE 802.11 OFDM Control .................................43
+ 6.11. IEEE 802.11 Rate Set .....................................44
+ 6.12. IEEE 802.11 RSNA Error Report From Station ...............44
+ 6.13. IEEE 802.11 Station ......................................46
+ 6.14. IEEE 802.11 Station QoS Profile ..........................47
+ 6.15. IEEE 802.11 Station Session Key ..........................48
+ 6.16. IEEE 802.11 Statistics ...................................50
+ 6.17. IEEE 802.11 Supported Rates ..............................54
+ 6.18. IEEE 802.11 Tx Power .....................................54
+ 6.19. IEEE 802.11 Tx Power Level ...............................55
+ 6.20. IEEE 802.11 Update Station QoS ...........................56
+ 6.21. IEEE 802.11 Update WLAN ..................................57
+ 6.22. IEEE 802.11 WTP Quality of Service .......................61
+ 6.23. IEEE 802.11 WTP Radio Configuration ......................63
+ 6.24. IEEE 802.11 WTP Radio Fail Alarm Indication ..............65
+ 6.25. IEEE 802.11 WTP Radio Information ........................66
+ 7. IEEE 802.11 Binding WTP Saved Variables ........................67
+ 7.1. IEEE80211AntennaInfo ......................................67
+ 7.2. IEEE80211DSControl ........................................67
+ 7.3. IEEE80211MACOperation .....................................67
+ 7.4. IEEE80211OFDMControl ......................................67
+ 7.5. IEEE80211Rateset ..........................................67
+ 7.6. IEEE80211TxPower ..........................................67
+ 7.7. IEEE80211QoS ..............................................68
+ 7.8. IEEE80211RadioConfig ......................................68
+ 8. Technology Specific Message Element Values .....................68
+ 8.1. WTP Descriptor Message Element, Encryption
+ Capabilities Field ........................................68
+ 9. Security Considerations ........................................68
+ 9.1. IEEE 802.11 Security ......................................68
+ 10. IANA Considerations ...........................................70
+ 10.1. CAPWAP Wireless Binding Identifier .......................70
+ 10.2. CAPWAP IEEE 802.11 Message Types .........................70
+ 10.3. CAPWAP Message Element Type ..............................70
+ 10.4. IEEE 802.11 Key Status ...................................71
+
+
+
+Calhoun, et al. Standards Track [Page 3]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ 10.5. IEEE 802.11 QoS ..........................................71
+ 10.6. IEEE 802.11 Auth Type ....................................71
+ 10.7. IEEE 802.11 Antenna Combiner .............................71
+ 10.8. IEEE 802.11 Antenna Selection ............................72
+ 10.9. IEEE 802.11 Session Key Flags ............................72
+ 10.10. IEEE 802.11 Tagging Policy ..............................72
+ 10.11. IEEE 802.11 WTP Radio Fail ..............................72
+ 10.12. IEEE 802.11 WTP Radio Type ..............................73
+ 10.13. WTP Encryption Capabilities .............................73
+ 11. Acknowledgments ...............................................73
+ 12. References ....................................................73
+ 12.1. Normative References .....................................73
+ 12.2. Informative References ...................................75
+
+1. Introduction
+
+ The CAPWAP protocol [RFC5415] defines an extensible protocol to allow
+ an Access Controller to manage wireless agnostic Wireless Termination
+ Points. The CAPWAP protocol itself does not include any specific
+ wireless technologies; instead, it relies on a binding specification
+ to extend the technology to a particular wireless technology.
+
+ This specification defines the Control And Provisioning of Wireless
+ Access Points (CAPWAP) Protocol Binding Specification for use with
+ the IEEE 802.11 Wireless Local Area Network protocol. Use of CAPWAP
+ control message fields, new control messages, and message elements
+ are defined. The minimum required definitions for a binding-specific
+ Statistics message element, Station message element, and WTP Radio
+ Information message element are included.
+
+ Note that this binding only supports the IEEE 802.11-2007
+ specification. Of note, this binding does not support the ad hoc
+ network mode defined in the IEEE 802.11-2007 standard. This
+ specification also does not cover the use of data frames with the
+ four-address format, commonly referred to as Wireless Bridges, whose
+ use is not specified in the IEEE 802.11-2007 standard. This protocol
+ specification does not currently officially support IEEE 802.11n.
+ That said, the protocol does allow a WTP to advertise support for an
+ IEEE 802.11n radio; however, the protocol does not allow for any of
+ the protocol's additional features to be configured and/or used. New
+ IEEE protocol specifications published outside of this document
+ (e.g., IEEE 802.11v, IEEE 802.11r) are also not supported through
+ this binding, and in addition to IEEE 802.11n, must be addressed
+ either through a separate CAPWAP binding, or an update to this
+ binding.
+
+
+
+
+
+
+Calhoun, et al. Standards Track [Page 4]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ In order to address immediate market needs for standards still being
+ developed by the IEEE 802.11 standards body, the WiFi Alliance
+ created interim pseudo-standards specifications. Two such
+ specifications are widely used in the industry, namely the WiFi
+ Protect Access [WPA] and the WiFi MultiMedia [WMM] specifications.
+ Given their widespread adoption, this CAPWAP binding requires the use
+ of these two specifications.
+
+1.1. Goals
+
+ The goals of this CAPWAP protocol binding are to make the
+ capabilities of the CAPWAP protocol available for use in conjunction
+ with IEEE 802.11 wireless networks. The capabilities to be made
+ available can be summarized as:
+
+ 1. To centralize the authentication and policy enforcement functions
+ for an IEEE 802.11 wireless network. The AC may also provide
+ centralized bridging, forwarding, and encryption of user traffic.
+ Centralization of these functions will enable reduced cost and
+ higher efficiency by applying the capabilities of network
+ processing silicon to the wireless network, as in wired LANs.
+
+ 2. To enable shifting of the higher-level protocol processing from
+ the WTP. This leaves the time-critical applications of wireless
+ control and access in the WTP, making efficient use of the
+ computing power available in WTPs that are subject to severe cost
+ pressure.
+
+ The CAPWAP protocol binding extensions defined herein apply solely to
+ the interface between the WTP and the AC. Inter-AC and station-to-AC
+ communication are strictly outside the scope of this document.
+
+1.2. Conventions Used in This Document
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [RFC2119].
+
+1.3. Terminology
+
+ This section contains definitions for terms used frequently
+ throughout this document. However, many additional definitions can
+ be found in [IEEE.802-11.2007].
+
+ Access Controller (AC): The network entity that provides WTP access
+ to the network infrastructure in the data plane, control plane,
+ management plane, or a combination therein.
+
+
+
+
+Calhoun, et al. Standards Track [Page 5]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ Basic Service Set (BSS): A set of stations controlled by a single
+ coordination function.
+
+ Distribution: The service that, by using association information,
+ delivers medium access control (MAC) service data units (MSDUs)
+ within the distribution system (DS).
+
+ Distribution System Service (DSS): The set of services provided by
+ the distribution system (DS) that enable the medium access control
+ (MAC) layer to transport MAC service data units (MSDUs) between
+ stations that are not in direct communication with each other over a
+ single instance of the wireless medium (WM). These services include
+ the transport of MSDUs between the access points (APs) of basic
+ service sets (BSSs) within an extended service set (ESS), transport
+ of MSDUs between portals and BSSs within an ESS, and transport of
+ MSDUs between stations in the same BSS in cases where the MSDU has a
+ multicast or broadcast destination address, or where the destination
+ is an individual address but the station sending the MSDU chooses to
+ involve the DSS. DSSs are provided between pairs of IEEE 802.11
+ MACs.
+
+ Integration: The service that enables delivery of medium access
+ control (MAC) service data units (MSDUs) between the distribution
+ system (DS) and an existing, non-IEEE 802.11 local area network (via
+ a portal).
+
+ Station (STA): A device that contains an IEEE 802.11 conformant
+ medium access control (MAC) and physical layer (PHY) interface to the
+ wireless medium (WM).
+
+ Portal: The logical point at which medium access control (MAC)
+ service data units (MSDUs) from a non-IEEE 802.11 local area network
+ (LAN) enter the distribution system (DS) of an extended service set
+ (ESS).
+
+ WLAN: In this document, WLAN refers to a logical component
+ instantiated on a WTP device. A single physical WTP may operate a
+ number of WLANs. Each Basic Service Set Identifier (BSSID) and its
+ constituent wireless terminal radios is denoted as a distinct WLAN on
+ a physical WTP.
+
+ Wireless Termination Point (WTP): The physical or network entity that
+ contains an IEEE 802.11 RF antenna and wireless PHY to transmit and
+ receive station traffic for wireless access networks.
+
+
+
+
+
+
+
+Calhoun, et al. Standards Track [Page 6]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+2. IEEE 802.11 Binding
+
+ This section describes use of the CAPWAP protocol with the IEEE
+ 802.11 Wireless Local Area Network protocol, including Local and
+ Split MAC operation, Group Key Refresh, Basic Service Set
+ Identification (BSSID) to WLAN Mapping, IEEE 802.11 MAC management
+ frame Quality of Service (Qos) tagging and Run State operation.
+
+2.1. CAPWAP Wireless Binding Identifier
+
+ The CAPWAP Header, defined in Section 4.3 of [RFC5415] requires that
+ all CAPWAP binding specifications have a Wireless Binding Identifier
+ (WBID) assigned. This document, which defines the IEEE 802.11
+ binding, uses the value one (1).
+
+2.2. Split MAC and Local MAC Functionality
+
+ The CAPWAP protocol, when used with IEEE 802.11 devices, requires
+ specific behavior from the WTP and the AC to support the required
+ IEEE 802.11 protocol functions.
+
+ For both the Split and Local MAC approaches, the CAPWAP functions, as
+ defined in the taxonomy specification [RFC4118], reside in the AC.
+
+ To provide system component interoperability, the WTP and AC MUST
+ support 802.11 encryption/decryption at the WTP. The WTP and AC MAY
+ support 802.11 encryption/decryption at the AC.
+
+2.2.1. Split MAC
+
+ This section shows the division of labor between the WTP and the AC
+ in a Split MAC architecture. Figure 1 shows the separation of
+ functionality between CAPWAP components.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Calhoun, et al. Standards Track [Page 7]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ Function Location
+ Distribution Service AC
+ Integration Service AC
+ Beacon Generation WTP
+ Probe Response Generation WTP
+ Power Mgmt/Packet Buffering WTP
+ Fragmentation/Defragmentation WTP/AC
+ Assoc/Disassoc/Reassoc AC
+
+ IEEE 802.11 QoS
+ Classifying AC
+ Scheduling WTP/AC
+ Queuing WTP
+
+ IEEE 802.11 RSN
+ IEEE 802.1X/EAP AC
+ RSNA Key Management AC
+ IEEE 802.11 Encryption/Decryption WTP/AC
+
+ Figure 1: Mapping of 802.11 Functions for Split MAC Architecture
+
+ In a Split MAC Architecture, the Distribution and Integration
+ services reside on the AC, and therefore all user data is tunneled
+ between the WTP and the AC. As noted above, all real-time IEEE
+ 802.11 services, including the Beacon and Probe Response frames, are
+ handled on the WTP.
+
+ All remaining IEEE 802.11 MAC management frames are supported on the
+ AC, including the Association Request frame that allows the AC to be
+ involved in the access policy enforcement portion of the IEEE 802.11
+ protocol. The IEEE 802.1X [IEEE.802-1X.2004], Extensible
+ Authentication Protocol (EAP) [RFC3748] and IEEE Robust Security
+ Network Association (RSNA) Key Management [IEEE.802-11.2007]
+ functions are also located on the AC. This implies that the
+ Authentication, Authorization, and Accounting (AAA) client also
+ resides on the AC.
+
+ While the admission control component of IEEE 802.11 resides on the
+ AC, the real-time scheduling and queuing functions are on the WTP.
+ Note that this does not prevent the AC from providing additional
+ policy and scheduling functionality.
+
+ Note that in the following figure, the use of '( - )' indicates that
+ processing of the frames is done on the WTP. This figure represents
+ a case where encryption services are provided by the AC.
+
+
+
+
+
+
+Calhoun, et al. Standards Track [Page 8]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ Client WTP AC
+
+ Beacon
+ <-----------------------------
+ Probe Request
+ ----------------------------( - )------------------------->
+ Probe Response
+ <-----------------------------
+ 802.11 AUTH/Association
+ <--------------------------------------------------------->
+ Station Configuration Request
+ [Add Station (Station MAC
+ Address), IEEE 802.11 Add
+ Station (WLAN ID), IEEE
+ 802.11 Session Key(Flag=A)]
+ <-------------------------->
+ 802.1X Authentication & 802.11 Key Exchange
+ <--------------------------------------------------------->
+ Station Configuration Request
+ [Add Station(Station MAC
+ Address), IEEE 802.11 Add
+ Station (WLAN ID), IEEE 802.11
+ Station Session Key(Flag=C)]
+ <-------------------------->
+ 802.11 Action Frames
+ <--------------------------------------------------------->
+ 802.11 DATA (1)
+ <---------------------------( - )------------------------->
+
+ Figure 2: Split MAC Message Flow
+
+ Figure 2 provides an illustration of the division of labor in a Split
+ MAC architecture. In this example, a WLAN has been created that is
+ configured for IEEE 802.11, using 802.1X-based end user
+ authentication and Advanced Encryption Standard-Counter Mode with
+ CBC-MAC Protocol (AES-CCMP) link layer encryption (CCMP, see
+ [FIPS.197.2001]). The following process occurs:
+
+ o The WTP generates the IEEE 802.11 Beacon frames, using information
+ provided to it through the IEEE 802.11 Add WLAN (see Section 6.1)
+ message element, including the Robust Security Network Information
+ Element (RSNIE), which indicates support of 802.1X and AES-CCMP.
+
+ o The WTP processes the Probe Request frame and responds with a
+ corresponding Probe Response frame. The Probe Request frame is
+ then forwarded to the AC for optional processing.
+
+
+
+
+
+Calhoun, et al. Standards Track [Page 9]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ o The WTP forwards the IEEEE 802.11 Authentication and Association
+ frames to the AC, which is responsible for responding to the
+ client.
+
+ o Once the association is complete, the AC transmits a Station
+ Configuration Request message, which includes an Add Station
+ message element, to the WTP (see Section 4.6.8 in [RFC5415]). In
+ the above example, the WLAN was configured for IEEE 802.1X, and
+ therefore the IEEE 802.11 Station Session Key is included with the
+ flag field's 'A' bit set.
+
+ o If the WTP is providing encryption/decryption services, once the
+ client has completed the IEEE 802.11 key exchange, the AC
+ transmits another Station Configuration Request message, which
+ includes:
+
+ - An Add Station message element.
+
+ - An IEEE 802.11 Add Station message element, which includes the
+ WLAN Identifier with which the station has associated.
+
+ - An IEEE 802.11 Station Session Key message element, which
+ includes the pairwise encryption key.
+
+ - An IEEE 802.11 Information Element message element, which
+ includes the Robust Security Network Information Element
+ (RSNIE) to the WTP, stating the security policy to enforce for
+ the client (in this case AES-CCMP).
+
+ o If the WTP is providing encryption/decryption services, once the
+ client has completed the IEEE 802.11 key exchange, the AC
+ transmits another Station Configuration Request message, which
+ includes:
+
+ - An Add Station message element.
+
+ - An IEEE 802.11 Add Station message element, which includes the
+ WLAN Identifier with which the station has associated.
+
+ - An IEEE 802.11 Station Session Key message element, which
+ includes the pairwise encryption key.
+
+ - An IEEE 802.11 Information Element message element, which
+ includes the Robust Security Network Information Element
+ (RSNIE) to the WTP, stating the security policy to enforce for
+ the client (in this case AES-CCMP).
+
+
+
+
+
+Calhoun, et al. Standards Track [Page 10]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ o If the AC is providing encryption/decryption services, once the
+ client has completed the IEEE 802.11 key exchange, the AC
+ transmits another Station Configuration Request message, which
+ includes:
+
+ - An Add Station message element.
+
+ - An IEEE 802.11 Add Station message element, which includes the
+ WLAN Identifier with which the station has associated.
+
+ - An IEEE 802.11 Station Session Key message element with the
+ flag field's 'C' bit enabled (indicating that the AC will
+ provide crypto services).
+
+ o The WTP forwards any IEEE 802.11 Management Action frames received
+ to the AC.
+
+ o All IEEE 802.11 station data frames are tunneled between the WTP
+ and the AC.
+
+ Note that during the EAP over LAN (EAPOL)-Key exchange between the
+ Station and the AC, the Receive Sequence Counter (RSC) field for the
+ Group Key (GTK) needs to be included in the frame. The value of zero
+ (0) is used by the AC during this exchange. Additional details are
+ available in Section 9.1.
+
+ The WTP SHALL include the IEEE 802.11 MAC header contents in all
+ frames transmitted to the AC.
+
+ When 802.11 encryption/decryption is performed at the WTP, the WTP
+ MUST decrypt the uplink frames, MUST set the Protected Frame field to
+ 0, and MUST make the frame format consistent with that of an
+ unprotected 802.11 frame prior to transmitting the frames to the AC.
+ The fields added to an 802.11 protected frame (i.e., Initialization
+ Vector/Extended Initialization Vector (IV/EIV), Message Integrity
+ Code (MIC), and Integrity Check Value (ICV)) MUST be stripped off
+ prior to transmission from the WTP to AC. For downlink frames, the
+ Protected Frame field MUST be set to 0 by the AC as the frame being
+ sent is unencrypted. The WTP MUST apply the required protection
+ policy for the WLAN, and set the Protected Frame field on
+ transmission over the air. The Protected Frame field always needs to
+ accurately indicate the status of the 802.11 frame that is carrying
+ it.
+
+ When 802.11 encryption/decryption is performed at the AC, the WTP
+ SHALL NOT decrypt the uplink frames prior to transmitting the frames
+ to the AC. The AC and WTP SHALL populate the IEEE 802.11 MAC header
+ fields as described in Figure 3.
+
+
+
+Calhoun, et al. Standards Track [Page 11]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ MAC header field Location
+ Frame Control:
+ Version AC
+ ToDS AC
+ FromDS AC
+ Type AC
+ SubType AC
+ MoreFrag WTP/AC
+ Retry WTP
+ Pwr Mgmt -
+ MoreData WTP
+ Protected WTP/AC
+ Order AC
+ Duration: WTP
+ Address 1: AC
+ Address 2: AC
+ Address 3: AC
+ Sequence Ctrl: WTP
+ Address 4: AC
+ QoS Control: AC
+ Frame Body: AC
+ FCS: WTP
+
+ Figure 3: Population of the IEEE 802.11 MAC Header Fields for
+ Downlink Frames
+
+ When 802.11 encryption/decryption is performed at the AC, the
+ MoreFrag bit is populated at the AC. The Pwr Mgmt bit is not
+ applicable to downlink frames, and is set to 0. Note that the Frame
+ Check Sequence (FCS) field is not included in 802.11 frames exchanged
+ between the WTP and the AC. Upon sending data frames to the AC, the
+ WTP is responsible for validating and stripping the FCS field. Upon
+ receiving data frames from the AC, the WTP is responsible for adding
+ the FCS field, and populating the field as described in
+ [IEEE.802-11.2007].
+
+ Note that when the WTP tunnels data packets to the AC (and vice
+ versa), the CAPWAP protocol does not guarantee in-order delivery.
+ When the protocol being transported over IEEE 802.11 is IP, out-of-
+ order delivery is not an issue as IP has no such requirements.
+ However, implementers need to be aware of this protocol
+ characteristic before deciding to use CAPWAP.
+
+2.2.2. Local MAC
+
+ This section shows the division of labor between the WTP and the AC
+ in a Local MAC architecture. Figure 4 shows the separation of
+ functionality among CAPWAP components.
+
+
+
+Calhoun, et al. Standards Track [Page 12]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ Function Location
+ Distribution Service WTP/AC
+ Integration Service WTP
+ Beacon Generation WTP
+ Probe Response Generation WTP
+ Power Mgmt/Packet Buffering WTP
+ Fragmentation/Defragmentation WTP
+ Assoc/Disassoc/Reassoc WTP/AC
+
+ IEEE 802.11 QoS
+ Classifying WTP
+ Scheduling WTP
+ Queuing WTP
+
+ IEEE 802.11 RSN
+ IEEE 802.1X/EAP AC
+ RSNA Key Management AC
+ IEEE 802.11 Encryption/Decryption WTP
+
+ Figure 4: Mapping of 802.11 Functions for Local AP Architecture
+
+ In the Local MAC mode, the integration service exists on the WTP,
+ while the distribution service MAY reside on either the WTP or the
+ AC. When it resides on the AC, station-generated frames are not
+ forwarded to the AC in their native format, but encapsulated as 802.3
+ frames.
+
+ While the MAC is terminated on the WTP, it is necessary for the AC to
+ be aware of mobility events within the WTPs. Thus, the WTP MUST
+ forward the IEEE 802.11 Association Request frames to the AC. The AC
+ MAY reply with a failed Association Response frame if it deems it
+ necessary, and upon receipt of a failed Association Response frame
+ from the AC, the WTP MUST send a Disassociation frame to the station.
+
+ The IEEE 802.1X [IEEE.802-1X.2004], EAP, and IEEE RSNA Key Management
+ [IEEE.802-11.2007] functions reside in the AC. Therefore, the WTP
+ MUST forward all IEEE 802.1X, EAP, and RSNA Key Management frames to
+ the AC and forward the corresponding responses to the station. This
+ implies that the AAA client also resides on the AC.
+
+ Note that in the following figure, the use of '( - )' indicates that
+ processing of the frames is done on the WTP.
+
+
+
+
+
+
+
+
+
+Calhoun, et al. Standards Track [Page 13]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ Client WTP AC
+
+ Beacon
+ <-----------------------------
+ Probe
+ <---------------------------->
+ 802.11 AUTH
+ <-----------------------------
+ 802.11 Association
+ <---------------------------( - )------------------------->
+ Station Configuration Request
+ [Add Station (Station MAC
+ Address), IEEE 802.11 Add
+ Station (WLAN ID), IEEE
+ 802.11 Session Key(Flag=A)]
+ <-------------------------->
+ 802.1X Authentication & 802.11 Key Exchange
+ <--------------------------------------------------------->
+ Station Configuration Request
+ [Add Station(Station MAC
+ Address), IEEE 802.11 Add
+ Station (WLAN ID), IEEE 802.11
+ Station session Key (Key=x),
+ IEEE 802.11 Information
+ Element(RSNIE(Pairwise
+ Cipher=CCMP))]
+ <-------------------------->
+ 802.11 Action Frames
+ <--------------------------------------------------------->
+ 802.11 DATA
+ <----------------------------->
+
+ Figure 5: Local MAC Message Flow
+
+ Figure 5 provides an illustration of the division of labor in a Local
+ MAC architecture. In this example, a WLAN that is configured for
+ IEEE 802.11 has been created using AES-CCMP for privacy. The
+ following process occurs:
+
+ o The WTP generates the IEEE 802.11 Beacon frames, using information
+ provided to it through the Add WLAN (see Section 6.1) message
+ element.
+
+ o The WTP processes a Probe Request frame and responds with a
+ corresponding Probe Response frame.
+
+ o The WTP forwards the IEEE 802.11 Authentication and Association
+ frames to the AC.
+
+
+
+Calhoun, et al. Standards Track [Page 14]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ o Once the association is complete, the AC transmits a Station
+ Configuration Request message, which includes the Add Station
+ message element, to the WTP (see Section 4.6.8 in [RFC5415]). In
+ the above example, the WLAN was configured for IEEE 802.1X, and
+ therefore the IEEE 802.11 Station Session Key is included with the
+ flag field's 'A' bit set.
+
+ o The WTP forwards all IEEE 802.1X and IEEE 802.11 key exchange
+ messages to the AC for processing.
+
+ o The AC transmits another Station Configuration Request message,
+ which includes:
+
+ - An Add Station message element, which MAY include a Virtual LAN
+ (VLAN) [IEEE.802-1Q.2005] name, which when present is used by
+ the WTP to identify the VLAN on which the user's data frames
+ are to be bridged.
+
+ - An IEEE 802.11 Add Station message element, which includes the
+ WLAN Identifier with which the station has associated.
+
+ - An IEEE 802.11 Station Session Key message element, which
+ includes the pairwise encryption key.
+
+ - An IEEE 802.11 Information Element message element, which
+ includes the RSNIE to the WTP, stating the security policy to
+ enforce for the client (in this case AES-CCMP).
+
+ o The WTP forwards any IEEE 802.11 Management Action frames received
+ to the AC.
+
+ o The WTP MAY locally bridge client data frames (and provide the
+ necessary encryption and decryption services). The WTP MAY also
+ tunnel client data frames to the AC, using 802.3 frame tunnel mode
+ or 802.11 frame tunnel mode.
+
+2.3. Roaming Behavior
+
+ This section expands upon the examples provided in the previous
+ section, and describes how the CAPWAP control protocol is used to
+ provide secure roaming.
+
+ Once a client has successfully associated with the network in a
+ secure fashion, it is likely to attempt to roam to another WTP.
+ Figure 6 shows an example of a currently associated station moving
+ from its "Old WTP" to a "New WTP". The figure is valid for multiple
+ different security policies, including IEEE 802.1X and Wireless
+ Protected Access (WPA) or Wireless Protected Access 2 (WPA2) [WPA].
+
+
+
+Calhoun, et al. Standards Track [Page 15]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ In the event that key caching was employed, the 802.1X Authentication
+ step would be eliminated. Note that the example represents one where
+ crypto services are provided by the WTP, so in a case where the AC
+ provided this function the last Station Configuration Request would
+ be different.
+
+ Client Old WTP New WTP AC
+
+ Association Request/Response
+ <--------------------------------------( - )-------------->
+ Station Configuration Request
+ [Add Station (Station MAC
+ Address), IEEE 802.11 Add
+ Station (WLAN ID), IEEE
+ 802.11 Session Key(Flag=A)]
+ <---------------->
+ 802.1X Authentication (if no key cache entry exists)
+ <--------------------------------------( - )-------------->
+ 802.11 4-way Key Exchange
+ <--------------------------------------( - )-------------->
+ Station Configuration Request
+ [Delete Station]
+ <---------------------------------->
+ Station Configuration Request
+ [Add Station(Station MAC
+ Address), IEEE 802.11 Add
+ Station (WLAN ID), IEEE 802.11
+ Station session Key (Key=x),
+ IEEE 802.11 Information
+ Element(RSNIE(Pairwise
+ Cipher=CCMP))]
+ <---------------->
+
+ Figure 6: Client Roaming Example
+
+2.4. Group Key Refresh
+
+ Periodically, the Group Key (GTK) for the BSS needs to be updated.
+ The AC uses an EAPOL-Key frame to update the group key for each STA
+ in the BSS. While the AC is updating the GTK, each Layer 2 (L2)
+ broadcast frame transmitted to the BSS needs to be duplicated and
+ transmitted using both the current GTK and the new GTK. Once the GTK
+ update process has completed, broadcast frames transmitted to the BSS
+ will be encrypted using the new GTK.
+
+ In the case of Split MAC, the AC needs to duplicate all broadcast
+ packets and update the key index so that the packet is transmitted
+ using both the current and new GTK to ensure that all STAs in the BSS
+
+
+
+Calhoun, et al. Standards Track [Page 16]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ receive the broadcast frames. In the case of Local MAC, the WTP
+ needs to duplicate and transmit broadcast frames using the
+ appropriate index to ensure that all STAs in the BSS continue to
+ receive broadcast frames.
+
+ The Group Key update procedure is shown in the following figure. The
+ AC will signal the update to the GTK using an IEEE 802.11
+ Configuration Request message, including an IEEE 802.11 Update WLAN
+ message element with the new GTK, its index, the Transmit Sequence
+ Counter (TSC) for the Group Key and the Key Status set to 3 (begin
+ GTK update). The AC will then begin updating the GTK for each STA.
+ During this time, the AC (for Split MAC) or WTP (for Local MAC) MUST
+ duplicate broadcast packets and transmit them encrypted with both the
+ current and new GTK. When the AC has completed the GTK update to all
+ STAs in the BSS, the AC MUST transmit an IEEE 802.11 Configuration
+ Request message including an IEEE 802.11 Update WLAN message element
+ containing the new GTK, its index, and the Key Status set to 4 (GTK
+ update complete).
+
+ Client WTP AC
+
+ IEEE 802.11 WLAN Configuration Request [Update
+ WLAN (GTK, GTK Index, GTK Start,
+ Group TSC) ]
+ <--------------------------------------------
+ 802.1X EAPoL (GTK Message 1)
+ <-------------( - )-------------------------------------------
+ 802.1X EAPoL (GTK Message 2)
+ -------------( - )------------------------------------------->
+ IEEE 802.11 WLAN Configuration Request [ Update
+ WLAN (GTK Index, GTK Complete) ]
+ <--------------------------------------------
+
+ Figure 7: Group Key Update Procedure
+
+2.5. BSSID to WLAN ID Mapping
+
+ The CAPWAP protocol binding enables the WTP to assign BSSIDs upon
+ creation of a WLAN (see Section 6.1). While manufacturers are free
+ to assign BSSIDs using any arbitrary mechanism, it is advised that
+ where possible the BSSIDs are assigned as a contiguous block.
+
+ When assigned as a block, implementations can still assign any of the
+ available BSSIDs to any WLAN. One possible method is for the WTP to
+ assign the address using the following algorithm: base BSSID address
+ + WLAN ID.
+
+
+
+
+
+Calhoun, et al. Standards Track [Page 17]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ The WTP communicates the maximum number of BSSIDs that it supports
+ during configuration via the IEEE 802.11 WTP WLAN Radio Configuration
+ message element (see Section 6.23).
+
+2.6. CAPWAP Data Channel QoS Behavior
+
+ The CAPWAP IEEE 802.11 binding specification provides procedures to
+ allow for the WTP to enforce Quality of Service on IEEE 802.11 Data
+ Frames and MAC Management messages.
+
+2.6.1. IEEE 802.11 Data Frames
+
+ When the WLAN is created on the WTP, a default Quality of Service
+ policy is established through the IEEE 802.11 WTP Quality of Service
+ message element (see Section 6.22). This default policy will cause
+ the WTP to use the default QoS values for any station associated with
+ the WLAN in question. The AC MAY also override the policy for a
+ given station by sending the IEEE 802.11 Update Station QoS message
+ element (see Section 6.20), known as a station-specific QoS policy.
+
+ Beyond the default, and per station QoS policy, the IEEE 802.11
+ protocol also allows a station to request special QoS treatment for a
+ specific flow through the Traffic Specification (TSPEC) Information
+ Elements found in the IEEE 802.11-2007's QoS Action Frame.
+ Alternatively, stations MAY also use the WiFi Alliance's WMM
+ specification instead to request QoS treatment for a flow (see
+ [WMM]). This requires the WTP to observe the Status Code in the IEEE
+ 802.11-2007 and WMM QoS Action Add Traffic System (ADDTS) responses
+ from the AC, and provide the services requested in the TSPEC
+ Information Element. Similarly, the WTP MUST observe the Reason Code
+ Information Element in the IEEE 802.11-2007 and WMM QoS Action DELTS
+ responses from the AC by removing the policy associated with the
+ TSPEC.
+
+ The IEEE 802.11 WTP Quality of Service message element's Tagging
+ Policy field indicates how the packets are to be tagged, known as the
+ Tagging Policy. There are five bits defined, two of which are used
+ to indicate the type of QoS to be used by the WTP. The first is the
+ 'P' bit, which is set to inform the WTP it is to use the 802.1p QoS
+ mechanism. When set, the 'Q' bit is used to inform the WTP which
+ 802.1p priority values it is to use.
+
+ The 'D' bit is set to inform the WTP it is to use the Differentiated
+ Services Code Point (DSCP) QoS mechanism. When set, the 'I' and 'O'
+ bits are used to inform the WTP which values it is to use in the
+ inner header, in the station's original packet, or the outer header,
+ the latter of which is only valid when tunneling is enabled.
+
+
+
+
+Calhoun, et al. Standards Track [Page 18]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ When an IEEE 802.11 Update Station QoS message element is received,
+ while the specific 802.1p priority or DSCP values may change for a
+ given station, known as the station specific policy, the original
+ Tagging Policy (the use of the five bits) remains the same.
+
+ The use of the DSCP and 802.1p QoS mechanisms are not mutually
+ exclusive. An AC MAY request that a WTP use none, one, or both types
+ of QoS mechanisms at the same time.
+
+2.6.1.1. 802.1p Support
+
+ The IEEE 802.11 WTP Quality of Service and IEEE 802.11 Update Station
+ QoS message elements include the "802.1p Tag" field, which is the
+ 802.1p priority value. This value is used by the WTP by adding an
+ 802.1Q header (see [IEEE.802-1Q.2005]) with the priority field set
+ according to the policy provided. Note that this tagging is only
+ valid for interfaces that support 802.1p. The actual treatment does
+ not change for either Split or Local MAC modes, or when tunneling is
+ used. The only exception is when tunneling is used, the 802.1Q
+ header is added to the outer packet (tunneled) header. The IEEE
+ 802.11 standard does not permit the station's packet to include an
+ 802.1Q header. Instead, the QoS mechanisms defined in the IEEE
+ 802.11 standard are used by stations to mark a packet's priority.
+ When the 'P' bit is set in the Tagging Policy, the 'Q' bit has the
+ following behavior:
+
+ Q=1: The WTP marks the priority field in the 802.1Q header to
+ either the default or the station-specific 802.1p policy.
+
+ Q=0: The WTP marks the priority field in the 802.1Q header to the
+ value found in the User Priority field of the QoS Control
+ field of the IEEE 802.11 header. If the QoS Control field is
+ not present in the IEEE 802.11 header, then the behavior
+ described under 'Q=1' is used.
+
+2.6.1.2. DSCP Support
+
+ The IEEE 802.11 WTP Quality of Service and IEEE 802.11 Update Station
+ QoS message elements also provide a "DSCP Tag", which is used by the
+ WTP when the 'D' bit is set to mark the DSCP field of both the IPv4
+ and IPv6 headers (see [RFC2474]). When DSCP is used, the WTP marks
+ the inner packet (the original packet received by the station) when
+ the 'I' bit is set. Similarly, the WTP marks the outer packet
+ (tunnel header's DSCP field) when the 'O' bit is set.
+
+ When the 'D' bit is set, the treatment of the packet differs based on
+ whether the WTP is tunneling the station's packets to the AC.
+ Tunneling does not occur in a Local MAC mode when the AC has
+
+
+
+Calhoun, et al. Standards Track [Page 19]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ communicated that tunneling is not required, as part of the IEEE
+ 802.11 Add WLAN message element, see Section 6.1. In the case where
+ tunneling is not used, the 'I' and 'O' bits have the following
+ behaviors:
+
+ O=1: This option is invalid when tunneling is not enabled for
+ station data frames.
+
+ O=0: This option is invalid when tunneling is not enabled for
+ station data frames.
+
+ I=1: The WTP sets the DSCP field in the station's packet to either
+ the default policy or the station-specific policy if one
+ exists.
+
+ I=0: The WTP MUST NOT modify the DSCP field in the station's
+ packet.
+
+ For Split MAC mode, or Local MAC with tunneling enabled, the WTP
+ needs to contend with both the inner packet (the station's original
+ packet) as well as the tunnel header (added by the WTP). In this
+ mode of operation, the bits are treated as follows:
+
+ O=1: The WTP sets the DSCP field in the tunnel header to either the
+ default policy or the station specific policy if one exists.
+
+ O=0: The WTP sets the DSCP field in the tunnel header to the value
+ found in the inner packet's DSCP field. If encryption
+ services are provided by the AC (see Section 6.15), the packet
+ is encrypted; therefore, the WTP cannot access the inner DSCP
+ field, in which case it uses the behavior described when the
+ 'O' bit is set. This occurs also if the inner packet is not
+ IPv4 or IPv6, and thus does not have a DSCP field.
+
+ I=1: The WTP sets the DSCP field in the station's packet to either
+ the default policy or the station-specific policy if one
+ exists. If encryption services are provided by the AC (see
+ Section 6.15), the packet is encrypted; therefore, the WTP
+ cannot access the inner DSCP field, in which case it uses the
+ behavior described when the 'I' bit is not set. This occurs
+ also if the inner packet is not IPv4 or IPv6, and thus does
+ not have a DSCP field.
+
+ I=0: The WTP MUST NOT modify the DSCP field in the station's
+ packet.
+
+
+
+
+
+
+Calhoun, et al. Standards Track [Page 20]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ The CAPWAP protocol supports the Explicit Congestion Notification
+ (ECN) bits [RFC3168]. Additional details on ECN support can be found
+ in [RFC5415].
+
+2.6.2. IEEE 802.11 MAC Management Messages
+
+ It is recommended that IEEE 802.11 MAC Management frames be sent by
+ both the AC and the WTP with appropriate Quality of Service values,
+ listed below, to ensure that congestion in the network minimizes
+ occurrences of packet loss. Note that the QoS Mechanism specified in
+ the Tagging Policy is used as specified by the AC in the IEEE 802.11
+ WTP Quality of Service message element (see Section 6.22). However,
+ the station-specific policy is not used for IEEE 802.11 MAC
+ Management frames.
+
+ 802.1p: The precedence value of 7 (decimal) SHOULD be used for all
+ IEEE 802.11 MAC management frames, except for Probe
+ Requests, which SHOULD use 4.
+
+ DSCP: All IEEE 802.11 MAC management frames SHOULD use the CS6
+ per- hop behavior (see [RFC2474]), while IEEE 802.11 Probe
+ Requests should use the Low Drop Assured Forwarding per-hop
+ behavior (see [RFC3246]).
+
+2.7. Run State Operation
+
+ The Run state is the normal state of operation for the CAPWAP
+ protocol in both the WTP and the AC.
+
+ When the WTP receives a WLAN Configuration Request message (see
+ Section 3.1), it MUST respond with a WLAN Configuration Response
+ message (see Section 3.2), and it remains in the Run state.
+
+ When the AC sends a WLAN Configuration Request message (see
+ Section 3.1) or receives the corresponding WLAN Configuration
+ Response message (see Section 3.2) from the WTP, it remains in the
+ Run state.
+
+3. IEEE 802.11 Specific CAPWAP Control Messages
+
+ This section defines CAPWAP Control messages that are specific to the
+ IEEE 802.11 binding. Two messages are defined: IEEE 802.11 WLAN
+ Configuration Request and IEEE 802.11 WLAN Configuration Response.
+ See Section 4.5 in [RFC5415] for CAPWAP Control message definitions
+ and the derivation of the Message Type value from the IANA Enterprise
+ number.
+
+
+
+
+
+Calhoun, et al. Standards Track [Page 21]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ The valid message types for IEEE 802.11-specific control messages are
+ listed below. The IANA Enterprise number used with these messages is
+ 13277.
+
+ CAPWAP Control Message Message Type
+ Value
+
+ IEEE 802.11 WLAN Configuration Request 3398913
+ IEEE 802.11 WLAN Configuration Response 3398914
+
+3.1. IEEE 802.11 WLAN Configuration Request
+
+ The IEEE 802.11 WLAN Configuration Request is sent by the AC to the
+ WTP in order to change services provided by the WTP. This control
+ message is used to either create, update, or delete a WLAN on the
+ WTP.
+
+ The IEEE 802.11 WLAN Configuration Request is sent as a result of
+ either some manual administrative process (e.g., deleting a WLAN), or
+ automatically to create a WLAN on a WTP. When sent automatically to
+ create a WLAN, this control message is sent after the CAPWAP
+ Configuration Update Response message (see Section 8.5 in [RFC5415])
+ has been received by the AC.
+
+ Upon receiving this control message, the WTP will modify the
+ necessary services and transmit an IEEE 802.11 WLAN Configuration
+ Response.
+
+ A WTP MAY provide service for more than one WLAN; therefore, every
+ WLAN is identified through a numerical index. For instance, a WTP
+ that is capable of supporting up to 16 Service Set Identifiers
+ (SSIDs), could accept up to 16 IEEE 802.11 WLAN Configuration Request
+ messages that include the Add WLAN message element.
+
+ Since the index is the primary identifier for a WLAN, an AC MAY
+ attempt to ensure that the same WLAN is identified through the same
+ index number on all of its WTPs. An AC that does not follow this
+ approach MUST find some other means of maintaining a WLAN-Identifier-
+ to-SSID mapping table.
+
+ The following message elements MAY be included in the IEEE 802.11
+ WLAN Configuration Request message. Only one message element MUST be
+ present.
+
+ o IEEE 802.11 Add WLAN, see Section 6.1
+
+ o IEEE 802.11 Delete WLAN, see Section 6.4
+
+
+
+
+Calhoun, et al. Standards Track [Page 22]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ o IEEE 802.11 Update WLAN, see Section 6.21
+
+ The following message element MAY be present.
+
+ o IEEE 802.11 Information Element, see Section 6.6
+
+ o Vendor-Specific Payload, see [RFC5415]
+
+3.2. IEEE 802.11 WLAN Configuration Response
+
+ The IEEE 802.11 WLAN Configuration Response message is sent by the
+ WTP to the AC. It is used to acknowledge receipt of an IEEE 802.11
+ WLAN Configuration Request message, and to indicate that the
+ requested configuration was successfully applied or that an error
+ related to the processing of the IEEE 802.11 WLAN Configuration
+ Request message occurred on the WTP.
+
+ The following message element MUST be included in the IEEE 802.11
+ WLAN Configuration Response message.
+
+ o Result Code, see Section 4.6.34 in [RFC5415]
+
+ The following message element MAY be included in the IEEE 802.11 WLAN
+ Configuration Response message.
+
+ o IEEE 802.11 Assigned WTP BSSID, see Section 6.3
+
+ o Vendor-Specific Payload, see [RFC5415]
+
+4. CAPWAP Data Message Bindings
+
+ This section describes the CAPWAP data message bindings to support
+ transport of IEEE 802.11 frames.
+
+ Payload encapsulation: The CAPWAP protocol defines the CAPWAP data
+ message, which is used to encapsulate a wireless payload. For
+ IEEE 802.11, the IEEE 802.11 header and payload are encapsulated
+ (excluding the IEEE 802.11 FCS checksum). The IEEE 802.11 FCS
+ checksum is handled by the WTP. This allows the WTP to validate
+ an IEEE 802.11 frame prior to sending it to the AC. Similarly,
+ when an AC wishes to transmit a frame to a station, the WTP
+ computes and adds the FCS checksum.
+
+ Optional Wireless Specific Information: This optional CAPWAP header
+ field (see Section 4.3 in [RFC5415]) is only used with CAPWAP data
+ messages, and it serves two purposes, depending upon the direction
+ of the message. For messages from the WTP to the AC, the field
+ uses the format described in the "IEEE 802.11 Frame Info" field
+
+
+
+Calhoun, et al. Standards Track [Page 23]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ (see below). However, for messages sent by the AC to the WTP, the
+ format used is described in the "Destination WLANs" field (also
+ defined below).
+
+ Note that in both cases, the two optional headers fit in the
+ "Data" field of the Wireless Specific Information header.
+
+ IEEE 802.11 Frame Info: When an IEEE 802.11 frame is received from a
+ station over the air, it is encapsulated and this field is used to
+ include radio and PHY-specific information associated with the
+ frame.
+
+ The IEEE 802.11 Frame Info field has the following format:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | RSSI | SNR | Data Rate |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ RSSI: Received Signal Strength Indication (RSSI) is a signed,
+ 8-bit value. It is the received signal strength indication, in
+ dBm.
+
+ SNR: SNR is a signed, 8-bit value. It is the signal-to-noise
+ ratio of the received IEEE 802.11 frame, in dB.
+
+ Data Rate: The data rate field is a 16-bit unsigned value. The
+ data rate field is a 16-bit unsigned value expressing the data
+ rate of the packets received by the WTP in units of 0.1 Mbps.
+ For instance, a packet received at 5.5 Mbps would be set to 55,
+ while 11 Mbps would be set to 110.
+
+ Destination WLANs: The Destination WLANs field is used to specify
+ the target WLANs for a given frame, and is only used with
+ broadcast and multicast frames. This field allows the AC to
+ transmit a single broadcast or multicast frame to the WTP and
+ allows the WTP to perform the necessary frame replication. The
+ field uses the following format:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | WLAN ID bitmap | Reserved |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+Calhoun, et al. Standards Track [Page 24]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ WLAN ID bitmap: This bit field indicates the WLAN ID (see
+ Section 6.1) on which the WTP will transmit the included frame.
+ For instance, if a multicast packet is to be transmitted on
+ WLANs 1 and 3, the bits for WLAN 1 and 3 of this field would be
+ enabled. WLAN 1 is represented by bit 15 in the figure above,
+ or the least significant bit, while WLAN 16 would be
+ represented by bit zero (0), or the most significant bit, in
+ the figure. This field is to be set to all zeroes for unicast
+ packets and is unused if the WTP is not providing IEEE 802.11
+ encryption.
+
+ Reserved: All implementations complying with this protocol MUST
+ set to zero any bits that are reserved in the version of the
+ protocol supported by that implementation. Receivers MUST
+ ignore all bits not defined for the version of the protocol
+ they support.
+
+5. CAPWAP Control Message Bindings
+
+ This section describes the IEEE 802.11-specific message elements
+ included in CAPWAP Control Messages.
+
+5.1. Discovery Request Message
+
+ The following IEEE 802.11-specific message element MUST be included
+ in the CAPWAP Discovery Request Message.
+
+ o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE
+ 802.11 WTP Radio Information message element MUST be present for
+ every radio in the WTP.
+
+5.2. Discovery Response Message
+
+ The following IEEE 802.11-specific message element MUST be included
+ in the CAPWAP Discovery Response Message.
+
+ o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE
+ 802.11 WTP Radio Information message element MUST be present for
+ every radio in the WTP.
+
+5.3. Primary Discovery Request Message
+
+ The following IEEE 802.11 specific message element MUST be included
+ in the CAPWAP Primary Discovery Request message.
+
+ o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE
+ 802.11 WTP Radio Information message element MUST be present for
+ every radio in the WTP.
+
+
+
+Calhoun, et al. Standards Track [Page 25]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+5.4. Primary Discovery Response Message
+
+ The following IEEE 802.11-specific message element MUST be included
+ in the CAPWAP Primary Discovery Response message.
+
+ o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE
+ 802.11 WTP Radio Information message element MUST be present for
+ every radio in the WTP.
+
+5.5. Join Request Message
+
+ The following IEEE 802.11-specific message element MUST be included
+ in the CAPWAP Join Request message.
+
+ o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE
+ 802.11 WTP Radio Information message element MUST be present for
+ every radio in the WTP.
+
+5.6. Join Response Message
+
+ The following IEEE 802.11-specific message element MUST be included
+ in the CAPWAP Join Response message.
+
+ o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE
+ 802.11 WTP Radio Information message element MUST be present for
+ every radio in the WTP.
+
+5.7. Configuration Status Request Message
+
+ The following IEEE 802.11-specific message elements MAY be included
+ in the CAPWAP Configuration Status Request message. More than one of
+ each message element listed MAY be included.
+
+ o IEEE 802.11 Antenna, see Section 6.2
+
+ o IEEE 802.11 Direct Sequence Control, see Section 6.5
+
+ o IEEE 802.11 MAC Operation, see Section 6.7
+
+ o IEEE 802.11 Multi-Domain Capability, see Section 6.9
+
+ o IEEE 802.11 Orthogonal Frequency Division Multiplexing (OFDM)
+ Control, see Section 6.10
+
+ o IEEE 802.11 Supported Rates, see Section 6.17
+
+ o IEEE 802.11 Tx Power, see Section 6.18
+
+
+
+
+Calhoun, et al. Standards Track [Page 26]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ o IEEE 802.11 TX Power Level, see Section 6.19
+
+ o IEEE 802.11 WTP Radio Configuration, see Section 6.23
+
+ o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE
+ 802.11 WTP Radio Information message element MUST be present for
+ every radio in the WTP.
+
+5.8. Configuration Status Response Message
+
+ The following IEEE 802.11 specific message elements MAY be included
+ in the CAPWAP Configuration Status Response Message. More than one
+ of each message element listed MAY be included.
+
+ o IEEE 802.11 Antenna, see Section 6.2
+
+ o IEEE 802.11 Direct Sequence Control, see Section 6.5
+
+ o IEEE 802.11 MAC Operation, see Section 6.7
+
+ o IEEE 802.11 Multi-Domain Capability, see Section 6.9
+
+ o IEEE 802.11 OFDM Control, see Section 6.10
+
+ o IEEE 802.11 Rate Set, see Section 6.11
+
+ o IEEE 802.11 Supported Rates, see Section 6.17
+
+ o IEEE 802.11 Tx Power, see Section 6.18
+
+ o IEEE 802.11 WTP Quality of Service, see Section 6.22
+
+ o IEEE 802.11 WTP Radio Configuration, see Section 6.23
+
+5.9. Configuration Update Request Message
+
+ The following IEEE 802.11-specific message elements MAY be included
+ in the CAPWAP Configuration Update Request message. More than one of
+ each message element listed MAY be included.
+
+ o IEEE 802.11 Antenna, see Section 6.2
+
+ o IEEE 802.11 Direct Sequence Control, see Section 6.5
+
+ o IEEE 802.11 MAC Operation, see Section 6.7
+
+ o IEEE 802.11 Multi-Domain Capability, see Section 6.9
+
+
+
+
+Calhoun, et al. Standards Track [Page 27]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ o IEEE 802.11 OFDM Control, see Section 6.10
+
+ o IEEE 802.11 Rate Set, see Section 6.11
+
+ o IEEE 802.11 RSNA Error Report from Station, see Section 6.12
+
+ o IEEE 802.11 Tx Power, see Section 6.18
+
+ o IEEE 802.11 WTP Quality of Service, see Section 6.22
+
+ o IEEE 802.11 WTP Radio Configuration, see Section 6.23
+
+5.10. Station Configuration Request
+
+ The following IEEE 802.11-specific message elements MAY be included
+ in the CAPWAP Station Configuration Request message. More than one
+ of each message element listed MAY be included.
+
+ o IEEE 802.11 Station, see Section 6.13
+
+ o IEEE 802.11 Station Session Key, see Section 6.15
+
+ o IEEE 802.11 Station QoS Profile, see Section 6.14
+
+ o IEEE 802.11 Update Station Qos, see Section 6.20
+
+5.11. Change State Event Request
+
+ The following IEEE 802.11-specific message element MAY be included in
+ the CAPWAP Station Configuration Request message.
+
+ o IEEE 802.11 WTP Radio Fail Alarm Indication, see Section 6.24
+
+5.12. WTP Event Request
+
+ The following IEEE 802.11-specific message elements MAY be included
+ in the CAPWAP WTP Event Request message. More than one of each
+ message element listed MAY be included.
+
+ o IEEE 802.11 MIC Countermeasures, see Section 6.8
+
+ o IEEE 802.11 RSNA Error Report from Station, see Section 6.12
+
+ o IEEE 802.11 Statistics, see Section 6.16
+
+
+
+
+
+
+
+Calhoun, et al. Standards Track [Page 28]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+6. IEEE 802.11 Message Element Definitions
+
+ The following IEEE 802.11-specific message elements are defined in
+ this section.
+
+ IEEE 802.11 Message Element Type Value
+
+ IEEE 802.11 Add WLAN 1024
+ IEEE 802.11 Antenna 1025
+ IEEE 802.11 Assigned WTP BSSID 1026
+ IEEE 802.11 Delete WLAN 1027
+ IEEE 802.11 Direct Sequence Control 1028
+ IEEE 802.11 Information Element 1029
+ IEEE 802.11 MAC Operation 1030
+ IEEE 802.11 MIC Countermeasures 1031
+ IEEE 802.11 Multi-Domain Capability 1032
+ IEEE 802.11 OFDM Control 1033
+ IEEE 802.11 Rate Set 1034
+ IEEE 802.11 RSNA Error Report From Station 1035
+ IEEE 802.11 Station 1036
+ IEEE 802.11 Station QoS Profile 1037
+ IEEE 802.11 Station Session Key 1038
+ IEEE 802.11 Statistics 1039
+ IEEE 802.11 Supported Rates 1040
+ IEEE 802.11 Tx Power 1041
+ IEEE 802.11 Tx Power Level 1042
+ IEEE 802.11 Update Station QoS 1043
+ IEEE 802.11 Update WLAN 1044
+ IEEE 802.11 WTP Quality of Service 1045
+ IEEE 802.11 WTP Radio Configuration 1046
+ IEEE 802.11 WTP Radio Fail Alarm Indication 1047
+ IEEE 802.11 WTP Radio Information 1048
+
+ Figure 8: IEEE 802.11 Binding Message Elements
+
+6.1. IEEE 802.11 Add WLAN
+
+ The IEEE 802.11 Add WLAN message element is used by the AC to define
+ a WLAN on the WTP. The inclusion of this message element MUST also
+ include IEEE 802.11 Information Element message elements, containing
+ the following IEEE 802.11 IEs:
+
+ Power Constraint information element
+
+ EDCA Parameter Set information element
+
+ QoS Capability information element
+
+
+
+
+Calhoun, et al. Standards Track [Page 29]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ WPA information element [WPA]
+
+ RSN information element
+
+ WMM information element [WMM]
+
+ These IEEE 802.11 Information Elements are stored by the WTP and
+ included in any Probe Responses and Beacons generated, as specified
+ in the IEEE 802.11 standard [IEEE.802-11.2007]. If present, the RSN
+ Information Element is sent with the IEEE 802.11 Add WLAN message
+ element to instruct the WTP on the usage of the Key field.
+
+ If cryptographic services are provided at the WTP, the WTP MUST
+ observe the algorithm dictated in the Group Cipher Suite field of the
+ RSN Information Element sent by the AC. The RSN Information Element
+ is used to communicate any supported algorithm, including WEP,
+ Temporal Key Integrity Protocol (TKIP) and AES-CCMP. In the case of
+ static WEP keys, the RSN Information Element is still used to
+ indicate the cryptographic algorithm even though no key exchange
+ occurred.
+
+ An AC MAY include additional Information Elements as desired. The
+ message element uses the following format:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID | WLAN ID | Capability |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Key Index | Key Status | Key Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Key... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Group TSC |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Group TSC | QoS | Auth Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | MAC Mode | Tunnel Mode | Suppress SSID | SSID ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 1024 for IEEE 802.11 Add WLAN
+
+ Length: >= 20
+
+ Radio ID: An 8-bit value representing the radio, whose value is
+ between one (1) and 31.
+
+
+
+
+
+Calhoun, et al. Standards Track [Page 30]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ WLAN ID: An 8-bit value specifying the WLAN Identifier. The value
+ MUST be between one (1) and 16.
+
+ Capability: A 16-bit value containing the Capability information
+ field to be advertised by the WTP in the Probe Request and Beacon
+ frames. Each bit of the Capability field represents a different
+ WTP capability, which are described in detail in
+ [IEEE.802-11.2007]. The format of the field is:
+
+ 0 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |E|I|C|F|P|S|B|A|M|Q|T|D|V|O|K|L|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ E (ESS): The AC MUST set the Extended Service Set (ESS) subfield
+ to 1.
+
+ I (IBSS): The AC MUST set the Independent Basic Service Set
+ (IBSS) subfield to 0.
+
+ C (CF-Pollable): The AC sets the Contention Free Pollable (CF-
+ Pollable) subfield based on the table found in
+ [IEEE.802-11.2007].
+
+ F (CF-Poll Request): The AC sets the CF-Poll Request subfield
+ based on the table found in [IEEE.802-11.2007].
+
+ P (Privacy): The AC sets the Privacy subfield based on the
+ confidentiality requirements of the WLAN, as defined in
+ [IEEE.802-11.2007].
+
+ S (Short Preamble): The AC sets the Short Preamble subfield
+ based on whether the use of short preambles is permitted on the
+ WLAN, as defined in [IEEE.802-11.2007].
+
+ B (PBCC): The AC sets the Packet Binary Convolutional Code
+ (PBCC) modulation option subfield based on whether the use of
+ PBCC is permitted on the WLAN, as defined in [IEEE.802-11.2007].
+
+ A (Channel Agility): The AC sets the Channel Agility subfield
+ based on whether the WTP is capable of supporting the High Rate
+ Direct Sequence Spread Spectrum (HR/DSSS), as defined in
+ [IEEE.802-11.2007].
+
+
+
+
+
+
+
+Calhoun, et al. Standards Track [Page 31]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ M (Spectrum Management): The AC sets the Spectrum Management
+ subfield according to the value of the
+ dot11SpectrumManagementRequired MIB variable, as defined in
+ [IEEE.802-11.2007].
+
+ Q (QoS): The AC sets the Quality of Service (QoS) subfield based
+ on the table found in [IEEE.802-11.2007].
+
+ T (Short Slot Time): The AC sets the Short Slot Time subfield
+ according to the value of the WTP's currently used slot time
+ value, as defined in [IEEE.802-11.2007].
+
+ D (APSD): The AC sets the Automatic Power Save Delivery (APSD)
+ subfield according to the value of the
+ dot11APSDOptionImplemented Management Information Base (MIB)
+ variable, as defined in [IEEE.802-11.2007].
+
+ V (Reserved): The AC sets the Reserved subfield to zero, as
+ defined in [IEEE.802-11.2007].
+
+ O (DSSS-OFDM): The AC sets the DSSS-OFDM subfield to indicate
+ the use of Direct Sequence Spread Spectrum with Orthogonal
+ Frequency Division Multiplexing (DSSS-OFDM), as defined in
+ [IEEE.802-11.2007].
+
+ K (Delayed Block ACK): The AC sets the Delayed Block ACK
+ subfield according to the value of the
+ dot11DelayedBlockAckOptionImplemented MIB variable, as defined
+ in [IEEE.802-11.2007].
+
+ L (Immediate Block ACK): The AC sets the Delayed Block ACK
+ subfield according to the value of the
+ dot11ImmediateBlockAckOptionImplemented MIB variable, as defined
+ in [IEEE.802-11.2007].
+
+ Key-Index: The Key Index associated with the key.
+
+ Key Status: A 1-byte value that specifies the state and usage of
+ the key that has been included. Note this field is ignored if the
+ Key Length field is set to zero (0). The following values
+ describe the key usage and its status:
+
+ 0 - A value of zero, with the inclusion of the RSN Information
+ Element means that the WLAN uses per-station encryption keys,
+ and therefore the key in the 'Key' field is only used for
+ multicast traffic.
+
+
+
+
+
+Calhoun, et al. Standards Track [Page 32]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ 1 - When set to one, the WLAN employs a shared Wired Equivalent
+ Privacy (WEP) key, also known as a static WEP key, and uses
+ the encryption key for both unicast and multicast traffic for
+ all stations.
+
+ 2 - The value of 2 indicates that the AC will begin rekeying the
+ GTK with the STA's in the BSS. It is only valid when IEEE
+ 802.11 is enabled as the security policy for the BSS.
+
+ 3 - The value of 3 indicates that the AC has completed rekeying
+ the GTK and broadcast packets no longer need to be duplicated
+ and transmitted with both GTK's.
+
+ Key Length: A 16-bit value representing the length of the Key
+ field.
+
+ Key: A Session Key, whose length is known via the Key Length field,
+ used to provide data privacy. For encryption schemes that employ
+ a separate encryption key for unicast and multicast traffic, the
+ key included here only applies to multicast frames, and the cipher
+ suite is specified in an accompanied RSN Information Element. In
+ these scenarios, the key and cipher information is communicated
+ via the Add Station message element, see Section 4.6.8 in
+ [RFC5415] and the IEEE 802.11 Station Session Key message element,
+ see Section 6.15. When used with WEP, the key field includes the
+ broadcast key. When used with CCMP, the Key field includes the
+ 128-bit Group Temporal Key. When used with TKIP, the Key field
+ includes the 256-bit Group Temporal Key (which consists of a 128-
+ bit key used as input for TKIP key mixing, and two 64-bit keys
+ used for Michael).
+
+ Group TSC: A 48-bit value containing the Transmit Sequence Counter
+ (TSC) for the updated group key. The WTP will set the TSC for
+ broadcast/multicast frames to this value for the updated group
+ key.
+
+ QoS: An 8-bit value specifying the default QoS policy for the WTP
+ to apply to network traffic received for a non-WMM enabled STA.
+
+ The following enumerated values are supported:
+
+ 0 - Best Effort
+
+ 1 - Video
+
+
+
+
+
+
+
+Calhoun, et al. Standards Track [Page 33]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ 2 - Voice
+
+ 3 - Background
+
+ Auth Type: An 8-bit value specifying the supported authentication
+ type.
+
+ The following enumerated values are supported:
+
+ 0 - Open System
+
+ 1 - WEP Shared Key
+
+ MAC Mode: This field specifies whether the WTP should support the
+ WLAN in Local or Split MAC mode. Note that the AC MUST NOT
+ request a mode of operation that was not advertised by the WTP
+ during the discovery process (see Section 4.6.43 in [RFC5415]).
+ The following enumerated values are supported:
+
+ 0 - Local MAC: Service for the WLAN is to be provided in Local
+ MAC mode.
+
+ 1 - Split MAC: Service for the WLAN is to be provided in Split
+ MAC mode.
+
+ Tunnel Mode: This field specifies the frame tunneling type to be
+ used for 802.11 data frames from all stations associated with the
+ WLAN. The AC MUST NOT request a mode of operation that was not
+ advertised by the WTP during the discovery process (see Section
+ 4.6.42 in [RFC5415]). All IEEE 802.11 management frames MUST be
+ tunneled using 802.11 Tunnel mode. The following enumerated
+ values are supported:
+
+ 0 - Local Bridging: All user traffic is to be locally bridged.
+
+ 1 - 802.3 Tunnel: All user traffic is to be tunneled to the AC
+ in 802.3 format (see Section 4.4.2 in [RFC5415]). Note that
+ this option MUST NOT be selected with Split MAC mode.
+
+ 2 - 802.11 Tunnel: All user traffic is to be tunneled to the AC
+ in 802.11 format.
+
+ Suppress SSID: A boolean indicating whether the SSID is to be
+ advertised by the WTP. A value of zero suppresses the SSID in the
+ 802.11 Beacon and Probe Response frames, while a value of one will
+ cause the WTP to populate the field.
+
+
+
+
+
+Calhoun, et al. Standards Track [Page 34]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ SSID: The SSID attribute is the service set identifier that will be
+ advertised by the WTP for this WLAN. The SSID field contains any
+ ASCII character and MUST NOT exceed 32 octets in length, as
+ defined in [IEEE.802-11.2007].
+
+6.2. IEEE 802.11 Antenna
+
+ The IEEE 802.11 Antenna message element is communicated by the WTP to
+ the AC to provide information on the antennas available. The AC MAY
+ use this element to reconfigure the WTP's antennas. The message
+ element contains the following fields:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID | Diversity | Combiner | Antenna Cnt |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Antenna Selection...
+ +-+-+-+-+-+-+-+-+
+
+ Type: 1025 for IEEE 802.11 Antenna
+
+ Length: >= 5
+
+ Radio ID: An 8-bit value representing the radio to configure, whose
+ value is between one (1) and 31.
+
+ Diversity: An 8-bit value specifying whether the antenna is to
+ provide receiver diversity. The value of this field is the same
+ as the IEEE 802.11 dot11DiversitySelectionRx MIB element, see
+ [IEEE.802-11.2007]. The following enumerated values are
+ supported:
+
+ 0 - Disabled
+
+ 1 - Enabled (may only be true if the antenna can be used as a
+ receiving antenna)
+
+ Combiner: An 8-bit value specifying the combiner selection. The
+ following enumerated values are supported:
+
+ 1 - Sectorized (Left)
+
+ 2 - Sectorized (Right)
+
+
+
+
+
+
+
+Calhoun, et al. Standards Track [Page 35]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ 3 - Omni
+
+ 4 - Multiple Input/Multiple Output (MIMO)
+
+ Antenna Count: An 8-bit value specifying the number of Antenna
+ Selection fields. This value SHOULD be the same as the one found
+ in the IEEE 802.11 dot11CurrentTxAntenna MIB element (see
+ [IEEE.802-11.2007]).
+
+ Antenna Selection: One 8-bit antenna configuration value per
+ antenna in the WTP, containing up to 255 antennas. The following
+ enumerated values are supported:
+
+ 1 - Internal Antenna
+
+ 2 - External Antenna
+
+6.3. IEEE 802.11 Assigned WTP BSSID
+
+ The IEEE 802.11 Assigned WTP BSSID is only included by the WTP when
+ the IEEE 802.11 WLAN Configuration Request included the IEEE 802.11
+ Add WLAN message element. The BSSID value field of this message
+ element contains the BSSID that has been assigned by the WTP,
+ enabling the WTP to perform its own BSSID assignment.
+
+ The WTP is free to assign the BSSIDs the way it sees fit, but it is
+ highly recommended that the WTP assign the BSSID using the following
+ algorithm: BSSID = {base BSSID} + WLAN ID.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID | WLAN ID | BSSID
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | BSSID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 1026 for IEEE 802.11 Assigned WTP BSSID
+
+ Length: 8
+
+ Radio ID: An 8-bit value representing the radio, whose value is
+ between one (1) and 31.
+
+ WLAN ID: An 8-bit value specifying the WLAN Identifier. The value
+ MUST be between one (1) and 16.
+
+
+
+
+
+Calhoun, et al. Standards Track [Page 36]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ BSSID: The BSSID assigned by the WTP for the WLAN created as a
+ result of receiving an IEEE 802.11 Add WLAN.
+
+6.4. IEEE 802.11 Delete WLAN
+
+ The IEEE 802.11 Delete WLAN message element is used to inform the WTP
+ that a previously created WLAN is to be deleted, and contains the
+ following fields:
+
+ 0 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID | WLAN ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 1027 for IEEE 802.11 Delete WLAN
+
+ Length: 2
+
+ Radio ID: An 8-bit value representing the radio, whose value is
+ between one (1) and 31.
+
+ WLAN ID: An 8-bit value specifying the WLAN Identifier. The value
+ MUST be between one (1) and 16.
+
+6.5. IEEE 802.11 Direct Sequence Control
+
+ The IEEE 802.11 Direct Sequence Control message element is a bi-
+ directional element. When sent by the WTP, it contains the current
+ state. When sent by the AC, the WTP MUST adhere to the values
+ provided. This element is only used for IEEE 802.11b radios. The
+ message element has the following fields.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID | Reserved | Current Chan | Current CCA |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Energy Detect Threshold |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 1028 for IEEE 802.11 Direct Sequence Control
+
+ Length: 8
+
+
+
+
+
+
+
+Calhoun, et al. Standards Track [Page 37]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ Radio ID: An 8-bit value representing the radio to configure, whose
+ value is between one (1) and 31.
+
+ Reserved: All implementations complying with this protocol MUST set
+ to zero any bits that are reserved in the version of the protocol
+ supported by that implementation. Receivers MUST ignore all bits
+ not defined for the version of the protocol they support.
+
+ Current Channel: This attribute contains the current operating
+ frequency channel of the Direct Sequence Spread Spectrum (DSSS)
+ PHY. This value comes from the IEEE 802.11 dot11CurrentChannel
+ MIB element (see [IEEE.802-11.2007]).
+
+ Current CCA: The current Clear Channel Assessment (CCA) method in
+ operation, whose value can be found in the IEEE 802.11
+ dot11CCAModeSupported MIB element (see [IEEE.802-11.2007]). Valid
+ values are:
+
+ 1 - energy detect only (edonly)
+
+ 2 - carrier sense only (csonly)
+
+ 4 - carrier sense and energy detect (edandcs)
+
+ 8 - carrier sense with timer (cswithtimer)
+
+ 16 - high rate carrier sense and energy detect (hrcsanded)
+
+ Energy Detect Threshold: The current Energy Detect Threshold being
+ used by the DSSS PHY. The value can be found in the IEEE 802.11
+ dot11EDThreshold MIB element (see [IEEE.802-11.2007]).
+
+6.6. IEEE 802.11 Information Element
+
+ The IEEE 802.11 Information Element is used to communicate any IE
+ defined in the IEEE 802.11 protocol. The data field contains the raw
+ IE as it would be included within an IEEE 802.11 MAC management
+ message.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID | WLAN ID |B|P| Reserved |Info Element...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+Calhoun, et al. Standards Track [Page 38]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ Type: 1029 for IEEE 802.11 Information Element
+
+ Length: >= 4
+
+ Radio ID: An 8-bit value representing the radio, whose value is
+ between one (1) and 31.
+
+ WLAN ID: An 8-bit value specifying the WLAN Identifier. The value
+ MUST be between one (1) and 16.
+
+ B: When set, the WTP is to include the Information Element in IEEE
+ 802.11 Beacons associated with the WLAN.
+
+ P: When set, the WTP is to include the Information Element in Probe
+ Responses associated with the WLAN.
+
+ Reserved: All implementations complying with this protocol MUST set
+ to zero any bits that are reserved in the version of the protocol
+ supported by that implementation. Receivers MUST ignore all bits
+ not defined for the version of the protocol they support.
+
+ Info Element: The IEEE 802.11 Information Element, which includes
+ the type, length, and value field.
+
+6.7. IEEE 802.11 MAC Operation
+
+ The IEEE 802.11 MAC Operation message element is sent by the AC to
+ set the IEEE 802.11 MAC parameters on the WTP, and contains the
+ following fields.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID | Reserved | RTS Threshold |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Short Retry | Long Retry | Fragmentation Threshold |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Tx MSDU Lifetime |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Rx MSDU Lifetime |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 1030 for IEEE 802.11 MAC Operation
+
+ Length: 16
+
+
+
+
+
+
+Calhoun, et al. Standards Track [Page 39]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ Radio ID: An 8-bit value representing the radio to configure, whose
+ value is between one (1) and 31.
+
+ Reserved: All implementations complying with this protocol MUST set
+ to zero any bits that are reserved in the version of the protocol
+ supported by that implementation. Receivers MUST ignore all bits
+ not defined for the version of the protocol they support.
+
+ RTS Threshold: This attribute indicates the number of octets in an
+ MAC Protocol Data Unit (MPDU), below which a Request To Send/Clear
+ To Send (RTS/CTS) handshake MUST NOT be performed. An RTS/CTS
+ handshake MUST be performed at the beginning of any frame exchange
+ sequence where the MPDU is of type Data or Management, the MPDU
+ has an individual address in the Address1 field, and the length of
+ the MPDU is greater than this threshold. Setting this attribute
+ to be larger than the maximum MSDU size MUST have the effect of
+ turning off the RTS/CTS handshake for frames of Data or Management
+ type transmitted by this STA. Setting this attribute to zero MUST
+ have the effect of turning on the RTS/CTS handshake for all frames
+ of Data or Management type transmitted by this STA. The default
+ value of this attribute MUST be 2347. The value of this field
+ comes from the IEEE 802.11 dot11RTSThreshold MIB element, (see
+ [IEEE.802-11.2007]).
+
+ Short Retry: This attribute indicates the maximum number of
+ transmission attempts of a frame, the length of which is less than
+ or equal to RTSThreshold, that MUST be made before a failure
+ condition is indicated. The default value of this attribute MUST
+ be 7. The value of this field comes from the IEEE 802.11
+ dot11ShortRetryLimit MIB element, (see [IEEE.802-11.2007]).
+
+ Long Retry: This attribute indicates the maximum number of
+ transmission attempts of a frame, the length of which is greater
+ than dot11RTSThreshold, that MUST be made before a failure
+ condition is indicated. The default value of this attribute MUST
+ be 4. The value of this field comes from the IEEE 802.11
+ dot11LongRetryLimit MIB element, (see [IEEE.802-11.2007]).
+
+ Fragmentation Threshold: This attribute specifies the current
+ maximum size, in octets, of the MPDU that MAY be delivered to the
+ PHY. A MAC Service Data Unit (MSDU) MUST be broken into fragments
+ if its size exceeds the value of this attribute after adding MAC
+ headers and trailers. An MSDU or MAC Management Protocol Data
+ Unit (MMPDU) MUST be fragmented when the resulting frame has an
+ individual address in the Address1 field, and the length of the
+ frame is larger than this threshold. The default value for this
+ attribute MUST be the lesser of 2346 or the aMPDUMaxLength of the
+ attached PHY and MUST never exceed the lesser of 2346 or the
+
+
+
+Calhoun, et al. Standards Track [Page 40]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ aMPDUMaxLength of the attached PHY. The value of this attribute
+ MUST never be less than 256. The value of this field comes from
+ the IEEE 802.11 dot11FragmentationThreshold MIB element, (see
+ [IEEE.802-11.2007]).
+
+ Tx MSDU Lifetime: This attribute specifies the elapsed time in Time
+ Units (TUs), after the initial transmission of an MSDU, after
+ which further attempts to transmit the MSDU MUST be terminated.
+ The default value of this attribute MUST be 512. The value of
+ this field comes from the IEEE 802.11 dot11MaxTransmitMSDULifetime
+ MIB element, (see [IEEE.802-11.2007]).
+
+ Rx MSDU Lifetime: This attribute specifies the elapsed time in TU,
+ after the initial reception of a fragmented MMPDU or MSDU, after
+ which further attempts to reassemble the MMPDU or MSDU MUST be
+ terminated. The default value MUST be 512. The value of this
+ field comes from the IEEE 802.11 dot11MaxReceiveLifetime MIB
+ element, (see [IEEE.802-11.2007]).
+
+6.8. IEEE 802.11 MIC Countermeasures
+
+ The IEEE 802.11 MIC Countermeasures message element is sent by the
+ WTP to the AC to indicate the occurrence of a MIC failure. For more
+ information on MIC failure events, see the
+ dot11RSNATKIPCounterMeasuresInvoked MIB element definition in
+ [IEEE.802-11.2007].
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID | WLAN ID | MAC Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | MAC Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 1031 for IEEE 802.11 MIC Countermeasures
+
+ Length: 8
+
+ Radio ID: The Radio Identifier, whose value is between one (1) and
+ 31, typically refers to some interface index on the WTP.
+
+ WLAN ID: This 8-bit unsigned integer includes the WLAN Identifier,
+ on which the MIC failure occurred. The value MUST be between one
+ (1) and 16.
+
+
+
+
+
+
+Calhoun, et al. Standards Track [Page 41]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ MAC Address: The MAC Address of the station that caused the MIC
+ failure.
+
+6.9. IEEE 802.11 Multi-Domain Capability
+
+ The IEEE 802.11 Multi-Domain Capability message element is used by
+ the AC to inform the WTP of regulatory limits. The AC will transmit
+ one message element per frequency band to indicate the regulatory
+ constraints in that domain. The message element contains the
+ following fields.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID | Reserved | First Channel # |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Number of Channels | Max Tx Power Level |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 1032 for IEEE 802.11 Multi-Domain Capability
+
+ Length: 8
+
+ Radio ID: An 8-bit value representing the radio to configure, whose
+ value is between one (1) and 31.
+
+ Reserved: All implementations complying with this protocol MUST set
+ to zero any bits that are reserved in the version of the protocol
+ supported by that implementation. Receivers MUST ignore all bits
+ not defined for the version of the protocol they support.
+
+ First Channel #: This attribute indicates the value of the lowest
+ channel number in the sub-band for the associated domain country
+ string. The value of this field comes from the IEEE 802.11
+ dot11FirstChannelNumber MIB element (see [IEEE.802-11.2007]).
+
+ Number of Channels: This attribute indicates the value of the total
+ number of channels allowed in the sub-band for the associated
+ domain country string (see Section 6.23). The value of this field
+ comes from the IEEE 802.11 dot11NumberofChannels MIB element (see
+ [IEEE.802-11.2007]).
+
+ Max Tx Power Level: This attribute indicates the maximum transmit
+ power, in dBm, allowed in the sub-band for the associated domain
+ country string (see Section 6.23). The value of this field comes
+ from the IEEE 802.11 dot11MaximumTransmitPowerLevel MIB element
+ (see [IEEE.802-11.2007]).
+
+
+
+
+Calhoun, et al. Standards Track [Page 42]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+6.10. IEEE 802.11 OFDM Control
+
+ The IEEE 802.11 Orthogonal Frequency Division Multiplexing (OFDM)
+ Control message element is a bi-directional element. When sent by
+ the WTP, it contains the current state. When sent by the AC, the WTP
+ MUST adhere to the received values. This message element is only
+ used for 802.11a radios and contains the following fields:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID | Reserved | Current Chan | Band Support |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | TI Threshold |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 1033 for IEEE 802.11 OFDM Control
+
+ Length: 8
+
+ Radio ID: An 8-bit value representing the radio to configure, whose
+ value is between one (1) and 31.
+
+ Reserved: All implementations complying with this protocol MUST set
+ to zero any bits that are reserved in the version of the protocol
+ supported by that implementation. Receivers MUST ignore all bits
+ not defined for the version of the protocol they support.
+
+ Current Channel: This attribute contains the current operating
+ frequency channel of the OFDM PHY. The value of this field comes
+ from the IEEE 802.11 dot11CurrentFrequency MIB element (see
+ [IEEE.802-11.2007]).
+
+ Band Supported: The capability of the OFDM PHY implementation to
+ operate in the three Unlicensed National Information
+ Infrastructure (U-NII) bands. The value of this field comes from
+ the IEEE 802.11 dot11FrequencyBandsSupported MIB element (see
+ [IEEE.802-11.2007]), coded as a bit field, whose values are:
+
+ Bit 0 - capable of operating in the 5.15-5.25 GHz band
+
+ Bit 1 - capable of operating in the 5.25-5.35 GHz band
+
+ Bit 2 - capable of operating in the 5.725-5.825 GHz band
+
+
+
+
+
+
+
+Calhoun, et al. Standards Track [Page 43]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ Bit 3 - capable of operating in the 5.47-5.725 GHz band
+
+ Bit 4 - capable of operating in the lower Japanese 5.25 GHz band
+
+ Bit 5 - capable of operating in the 5.03-5.091 GHz band
+
+ Bit 6 - capable of operating in the 4.94-4.99 GHz band
+
+ For example, for an implementation capable of operating in the
+ 5.15-5.35 GHz bands, this attribute would take the value 3.
+
+ TI Threshold: The threshold being used to detect a busy medium
+ (frequency). CCA MUST report a busy medium upon detecting the
+ RSSI above this threshold. The value of this field comes from the
+ IEEE 802.11 dot11TIThreshold MIB element (see [IEEE.802-11.2007]).
+
+6.11. IEEE 802.11 Rate Set
+
+ The rate set message element value is sent by the AC and contains the
+ supported operational rates. It contains the following fields.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID | Rate Set...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 1034 for IEEE 802.11 Rate Set
+
+ Length: >= 3
+
+ Radio ID: An 8-bit value representing the radio to configure, whose
+ value is between one (1) and 31.
+
+ Rate Set: The AC generates the Rate Set that the WTP is to include
+ in its Beacon and Probe messages. The length of this field is
+ between 2 and 8 bytes. The value of this field comes from the
+ IEEE 802.11 dot11OperationalRateSet MIB element (see
+ [IEEE.802-11.2007]).
+
+6.12. IEEE 802.11 RSNA Error Report From Station
+
+ The IEEE 802.11 RSN Error Report From Station message element is used
+ by a WTP to send RSN error reports to the AC. The WTP does not need
+ to transmit any reports that do not include any failures. The fields
+ from this message element come from the IEEE 802.11
+ Dot11RSNAStatsEntry table, see [IEEE.802-11.2007].
+
+
+
+
+Calhoun, et al. Standards Track [Page 44]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Client MAC Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Client MAC Address | BSSID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | BSSID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID | WLAN ID | Reserved |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | TKIP ICV Errors |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | TKIP Local MIC Failures |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | TKIP Remote MIC Failures |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | CCMP Replays |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | CCMP Decrypt Errors |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | TKIP Replays |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+ Type: 1035 for IEEE 802.11 RSNA Error Report From Station
+
+ Length: 40
+
+ Client MAC Address: The Client MAC Address of the station.
+
+ BSSID: The BSSID on which the failures are being reported.
+
+ Radio ID: The Radio Identifier, whose value is between one (1) and
+ 31, typically refers to some interface index on the WTP.
+
+ WLAN ID: The WLAN ID on which the RSNA failures are being reported.
+ The value MUST be between one (1) and 16.
+
+ Reserved: All implementations complying with this protocol MUST set
+ to zero any bits that are reserved in the version of the protocol
+ supported by that implementation. Receivers MUST ignore all bits
+ not defined for the version of the protocol they support.
+
+
+
+
+
+
+
+
+Calhoun, et al. Standards Track [Page 45]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ TKIP ICV Errors: A 32-bit value representing the number of Temporal
+ Key Integrity Protocol (TKIP) (as defined in [IEEE.802-11.2007])
+ ICV errors encountered when decrypting packets from the station.
+ The value of this field comes from the IEEE 802.11
+ dot11RSNAStatsTKIPICVErrors MIB element (see [IEEE.802-11.2007]).
+
+ TKIP Local MIC Failures: A 32-bit value representing the number of
+ MIC failures encountered when checking the integrity of packets
+ received from the station. The value of this field comes from the
+ IEEE 802.11 dot11RSNAStatsTKIPLocalMICFailures MIB element (see
+ [IEEE.802-11.2007]).
+
+ TKIP Remote MIC Failures: A 32-bit value representing the number of
+ MIC failures reported by the station encountered (possibly via the
+ EAPOL-Key frame). The value of this field comes from the IEEE
+ 802.11 dot11RSNAStatsTKIPRemoteMICFailures MIB element (see
+ [IEEE.802-11.2007]).
+
+ CCMP Replays: A 32-bit value representing the number of CCMP MPDUs
+ discarded by the replay detection mechanism. The value of this
+ field comes from the IEEE 802.11 dot11RSNACCMPReplays MIB element
+ (see [IEEE.802-11.2007]).
+
+ CCMP Decrypt Errors: A 32-bit value representing the number of CCMP
+ MDPUs discarded by the decryption algorithm. The value of this
+ field comes from the IEEE 802.11 dot11RSNACCMPDecryptErrors MIB
+ element (see [IEEE.802-11.2007]).
+
+ TKIP Replays: A 32-bit value representing the number of TKIP
+ Replays detected in frames received from the station. The value
+ of this field comes from the IEEE 802.11 dot11RSNAStatsTKIPReplays
+ MIB element (see [IEEE.802-11.2007]).
+
+6.13. IEEE 802.11 Station
+
+ The IEEE 802.11 Station message element accompanies the Add Station
+ message element, and is used to deliver IEEE 802.11 station policy
+ from the AC to the WTP.
+
+ The latest IEEE 802.11 Station message element overrides any
+ previously received message elements.
+
+ If the QoS field is set, the WTP MUST observe and provide policing of
+ the 802.11e priority tag to ensure that it does not exceed the value
+ provided by the AC.
+
+
+
+
+
+
+Calhoun, et al. Standards Track [Page 46]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID | Association ID | Flags |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | MAC Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | MAC Address | Capabilities |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | WLAN ID |Supported Rates|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 1036 for IEEE 802.11 Station
+
+ Length: >= 14
+
+ Radio ID: An 8-bit value representing the radio, whose value is
+ between one (1) and 31.
+
+ Association ID: A 16-bit value specifying the IEEE 802.11
+ Association Identifier.
+
+ Flags: All implementations complying with this protocol MUST set to
+ zero any bits that are reserved in the version of the protocol
+ supported by that implementation. Receivers MUST ignore all bits
+ not defined for the version of the protocol they support.
+
+ MAC Address: The station's MAC Address
+
+ Capabilities: A 16-bit field containing the IEEE 802.11
+ Capabilities Information Field to use with the station.
+
+ WLAN ID: An 8-bit value specifying the WLAN Identifier. The value
+ MUST be between one (1) and 16.
+
+ Supported Rates: The variable-length field containing the supported
+ rates to be used with the station, as found in the IEEE 802.11
+ dot11OperationalRateSet MIB element (see [IEEE.802-11.2007]).
+ This field MUST NOT exceed 126 octets and specifies the set of
+ data rates at which the station may transmit data, where each
+ octet represents a data rate.
+
+6.14. IEEE 802.11 Station QoS Profile
+
+ The IEEE 802.11 Station QoS Profile message element contains the
+ maximum IEEE 802.11e priority tag that may be used by the station.
+ Any packet received that exceeds the value encoded in this message
+ element MUST be tagged using the maximum value permitted by to the
+
+
+
+Calhoun, et al. Standards Track [Page 47]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ user. The priority tag MUST be between zero (0) and seven (7). This
+ message element MUST NOT be present without the IEEE 802.11 Station
+ (see Section 6.13) message element.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | MAC Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | MAC Address | Reserved |8021p|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 1037 for IEEE 802.11 Station QoS Profile
+
+ Length: 8
+
+ MAC Address: The station's MAC Address
+
+ Reserved: All implementations complying with this protocol MUST set
+ to zero any bits that are reserved in the version of the protocol
+ supported by that implementation. Receivers MUST ignore all bits
+ not defined for the version of the protocol they support.
+
+ 8021p: The maximum 802.1p priority value that the WTP will allow in
+ the Traffic Identifier (TID) field in the extended 802.11e QoS
+ Data header.
+
+6.15. IEEE 802.11 Station Session Key
+
+ The IEEE 802.11 Station Session Key message element is sent by the AC
+ to provision encryption keys, or to configure an access policy, on
+ the WTP. This message element MUST NOT be present without the IEEE
+ 802.11 Station (see Section 6.13) message element, and MUST NOT be
+ sent if the WTP had not specifically advertised support for the
+ requested encryption scheme, through the WTP Descriptor Message
+ Element's Encryption Capabilities field (see Section 8.1).
+
+ When the Key field is non-zero in length, the RSN Information Element
+ MUST be sent along with the IEEE 802.11 Station Session Key in order
+ to instruct the WTP on the usage of the Key field. The WTP MUST
+ observe the Authentication and Key Management (AKM) field of the RSN
+ Information Element in order to identify the authentication protocol
+ to be enforced with the station.
+
+ If cryptographic services are provided at the WTP, the WTP MUST
+ observe the algorithm dictated in the Pairwise Cipher Suite field of
+ the RSN Information Element sent by the AC. The RSN Information
+ Element included here is the one sent by the AC in the third message
+
+
+
+Calhoun, et al. Standards Track [Page 48]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ of the 4-Way Key Handshake, which specifies which cipher is to be
+ applied to provide encryption and decryption services with the
+ station. The RSN Information Element is used to communicate any
+ supported algorithm, including WEP, TKIP, and AES-CCMP. In the case
+ of static WEP keys, the RSN Information Element is still used to
+ indicate the cryptographic algorithm even though no key exchange
+ occurred.
+
+ If the IEEE 802.11 Station Session Key message element's 'AKM-Only'
+ bit is set, the WTP MUST drop all IEEE 802.11 packets that are not
+ part of the Authentication and Key Management (AKM), such as EAP.
+ Note that AKM-Only MAY be set while an encryption key is in force,
+ requiring that the AKM packets be encrypted. Once the station has
+ successfully completed authentication via the AKM, the AC MUST send a
+ new Add Station message element to remove the AKM-Only restriction,
+ and optionally push the session key down to the WTP.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | MAC Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | MAC Address |A|C| Flags |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Pairwise TSC |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Pairwise TSC | Pairwise RSC |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Pairwise RSC |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Key...
+ +-+-+-+-+-+-+-+-
+
+ Type: 1038 for IEEE 802.11 Station Session Key
+
+ Length: >= 25
+
+ MAC Address: The station's MAC Address
+
+ Flags: All implementations complying with this protocol MUST set to
+ zero any bits that are reserved in the version of the protocol
+ supported by that implementation. Receivers MUST ignore all bits
+ not defined for the version of the protocol they support. The
+ following bits are defined:
+
+
+
+
+
+
+
+Calhoun, et al. Standards Track [Page 49]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ A: The 1-bit AKM-Only field is set by the AC to inform the WTP
+ that is MUST NOT accept any 802.11 Data Frames other than AKM
+ frames. This is the equivalent of the WTP's IEEE 802.1X port
+ for the station to be in the closed state. When set, the WTP
+ MUST drop any non-IEEE 802.1X packets it receives from the
+ station.
+
+ C: The 1-bit field is set by the AC to inform the WTP that
+ encryption services will be provided by the AC. When set,
+ the WTP SHOULD police frames received from stations to ensure
+ that they are properly encrypted as specified in the RSN
+ Information Element, but does not need to take specific
+ cryptographic action on the frame. Similarly, for
+ transmitted frames, the WTP only needs to forward already
+ encrypted frames. Since packets received by the WTP will be
+ encrypted, the WTP cannot modify the contents of the packets,
+ including modifying the DSCP markings of the encapsulated
+ packet. In this case, this function would be the
+ responsibility of the AC.
+
+ Pairwise TSC: The 6-byte Transmit Sequence Counter (TSC) field to
+ use for unicast packets transmitted to the station.
+
+ Pairwise RSC: The 6-byte Receive Sequence Counter (RSC) to use for
+ unicast packets received from the station.
+
+ Key: The pairwise key the WTP is to use when encrypting traffic to/
+ from the station. The format of the keys differs based on the
+ crypto algorithm used. For unicast WEP keys, the Key field
+ consists of the actual unicast encryption key (note, this is used
+ when WEP is used in conjunction with 802.1X, and therefore a
+ unicast encryption key exists). When used with CCMP, the Key
+ field includes the 128-bit Temporal Key. When used with TKIP, the
+ Key field includes the 256-bit Temporal Key (which consists of a
+ 128-bit key used as input for TKIP key mixing, and two 64-bit keys
+ used for Michael).
+
+6.16. IEEE 802.11 Statistics
+
+ The IEEE 802.11 Statistics message element is sent by the WTP to
+ transmit its current statistics, and it contains the following
+ fields. All of the fields in this message element are set to zero
+ upon WTP initialization. The fields will roll over when they reach
+ their maximum value of 4294967295. Due to the nature of each counter
+ representing different data points, the rollover event will vary
+
+
+
+
+
+
+Calhoun, et al. Standards Track [Page 50]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ greatly across each field. Applications or human operators using
+ these counters need to be aware of the minimal possible times between
+ rollover events in order to make sure that no consecutive rollover
+ events are missed.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID | Reserved |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Tx Fragment Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Multicast Tx Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Failed Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Retry Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Multiple Retry Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Frame Duplicate Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | RTS Success Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | RTS Failure Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | ACK Failure Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Rx Fragment Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Multicast RX Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | FCS Error Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Tx Frame Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Decryption Errors |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Discarded QoS Fragment Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Associated Station Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | QoS CF Polls Received Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | QoS CF Polls Unused Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | QoS CF Polls Unusable Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+Calhoun, et al. Standards Track [Page 51]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ Type: 1039 for IEEE 802.11 Statistics
+
+ Length: 80
+
+ Radio ID: An 8-bit value representing the radio, whose value is
+ between one (1) and 31.
+
+ Reserved: All implementations complying with this protocol MUST set
+ to zero any bits that are reserved in the version of the protocol
+ supported by that implementation. Receivers MUST ignore all bits
+ not defined for the version of the protocol they support.
+
+ Tx Fragment Count: A 32-bit value representing the number of
+ fragmented frames transmitted. The value of this field comes from
+ the IEEE 802.11 dot11TransmittedFragmentCount MIB element (see
+ [IEEE.802-11.2007]).
+
+ Multicast Tx Count: A 32-bit value representing the number of
+ multicast frames transmitted. The value of this field comes from
+ the IEEE 802.11 dot11MulticastTransmittedFrameCount MIB element
+ (see [IEEE.802-11.2007]).
+
+ Failed Count: A 32-bit value representing the transmit excessive
+ retries. The value of this field comes from the IEEE 802.11
+ dot11FailedCount MIB element (see [IEEE.802-11.2007]).
+
+ Retry Count: A 32-bit value representing the number of transmit
+ retries. The value of this field comes from the IEEE 802.11
+ dot11RetryCount MIB element (see [IEEE.802-11.2007]).
+
+ Multiple Retry Count: A 32-bit value representing the number of
+ transmits that required more than one retry. The value of this
+ field comes from the IEEE 802.11 dot11MultipleRetryCount MIB
+ element (see [IEEE.802-11.2007]).
+
+ Frame Duplicate Count: A 32-bit value representing the duplicate
+ frames received. The value of this field comes from the IEEE
+ 802.11 dot11FrameDuplicateCount MIB element (see
+ [IEEE.802-11.2007]).
+
+ RTS Success Count: A 32-bit value representing the number of
+ successfully transmitted Ready To Send (RTS). The value of this
+ field comes from the IEEE 802.11 dot11RTSSuccessCount MIB element
+ (see [IEEE.802-11.2007]).
+
+
+
+
+
+
+
+Calhoun, et al. Standards Track [Page 52]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ RTS Failure Count: A 32-bit value representing the failed
+ transmitted RTS. The value of this field comes from the IEEE
+ 802.11 dot11RTSFailureCount MIB element (see [IEEE.802-11.2007]).
+
+ ACK Failure Count: A 32-bit value representing the number of failed
+ acknowledgements. The value of this field comes from the IEEE
+ 802.11 dot11ACKFailureCount MIB element (see [IEEE.802-11.2007]).
+
+ Rx Fragment Count: A 32-bit value representing the number of
+ fragmented frames received. The value of this field comes from
+ the IEEE 802.11 dot11ReceivedFragmentCount MIB element (see
+ [IEEE.802-11.2007]).
+
+ Multicast RX Count: A 32-bit value representing the number of
+ multicast frames received. The value of this field comes from the
+ IEEE 802.11 dot11MulticastReceivedFrameCount MIB element (see
+ [IEEE.802-11.2007]).
+
+ FCS Error Count: A 32-bit value representing the number of FCS
+ failures. The value of this field comes from the IEEE 802.11
+ dot11FCSErrorCount MIB element (see [IEEE.802-11.2007]).
+
+ Decryption Errors: A 32-bit value representing the number of
+ Decryption errors that occurred on the WTP. Note that this field
+ is only valid in cases where the WTP provides encryption/
+ decryption services. The value of this field comes from the IEEE
+ 802.11 dot11WEPUndecryptableCount MIB element (see
+ [IEEE.802-11.2007]).
+
+ Discarded QoS Fragment Count: A 32-bit value representing the
+ number of discarded QoS fragments received. The value of this
+ field comes from the IEEE 802.11 dot11QoSDiscardedFragmentCount
+ MIB element (see [IEEE.802-11.2007]).
+
+ Associated Station Count: A 32-bit value representing the number of
+ number of associated stations. The value of this field comes from
+ the IEEE 802.11 dot11AssociatedStationCount MIB element (see
+ [IEEE.802-11.2007]).
+
+ QoS CF Polls Received Count: A 32-bit value representing the number
+ of (+)CF-Polls received. The value of this field comes from the
+ IEEE 802.11 dot11QosCFPollsReceivedCount MIB element (see
+ [IEEE.802-11.2007]).
+
+ QoS CF Polls Unused Count: A 32-bit value representing the number
+ of (+)CF-Polls that have been received, but not used. The value
+ of this field comes from the IEEE 802.11
+ dot11QosCFPollsUnusedCount MIB element (see [IEEE.802-11.2007]).
+
+
+
+Calhoun, et al. Standards Track [Page 53]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ QoS CF Polls Unusable Count: A 32-bit value representing the number
+ of (+)CF-Polls that have been received, but could not be used due
+ to the Transmission Opportunity (TXOP) size being smaller than the
+ time that is required for one frame exchange sequence. The value
+ of this field comes from the IEEE 802.11
+ dot11QosCFPollsUnusableCount MIB element (see [IEEE.802-11.2007]).
+
+6.17. IEEE 802.11 Supported Rates
+
+ The IEEE 802.11 Supported Rates message element is sent by the WTP to
+ indicate the rates that it supports, and contains the following
+ fields.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID | Supported Rates...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 1040 for IEEE 802.11 Supported Rates
+
+ Length: >= 3
+
+ Radio ID: An 8-bit value representing the radio, whose value is
+ between one (1) and 31.
+
+ Supported Rates: The WTP includes the Supported Rates that its
+ hardware supports. The format is identical to the Rate Set
+ message element and is between 2 and 8 bytes in length.
+
+6.18. IEEE 802.11 Tx Power
+
+ The IEEE 802.11 Tx Power message element value is bi-directional.
+ When sent by the WTP, it contains the current power level of the
+ radio in question. When sent by the AC, it contains the power level
+ to which the WTP MUST adhere.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID | Reserved | Current Tx Power |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 1041 for IEEE 802.11 Tx Power
+
+
+
+
+
+
+
+Calhoun, et al. Standards Track [Page 54]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ Length: 4
+
+ Radio ID: An 8-bit value representing the radio to configure, whose
+ value is between one (1) and 31.
+
+ Reserved: All implementations complying with this protocol MUST set
+ to zero any bits that are reserved in the version of the protocol
+ supported by that implementation. Receivers MUST ignore all bits
+ not defined for the version of the protocol they support.
+
+ Current Tx Power: This attribute contains the current transmit
+ output power in mW, as described in the dot11CurrentTxPowerLevel
+ MIB variable, see [IEEE.802-11.2007].
+
+6.19. IEEE 802.11 Tx Power Level
+
+ The IEEE 802.11 Tx Power Level message element is sent by the WTP and
+ contains the different power levels supported. The values found in
+ this message element are found in the IEEE 802.11
+ Dot11PhyTxPowerEntry MIB table, see [IEEE.802-11.2007].
+
+ The value field contains the following:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID | Num Levels | Power Level [n] |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 1042 for IEEE 802.11 Tx Power Level
+
+ Length: >= 4
+
+ Radio ID: An 8-bit value representing the radio to configure, whose
+ value is between one (1) and 31.
+
+ Num Levels: The number of power level attributes. The value of
+ this field comes from the IEEE 802.11
+ dot11NumberSupportedPowerLevels MIB element (see
+ [IEEE.802-11.2007]).
+
+ Power Level: Each power level field contains a supported power
+ level, in mW. The value of this field comes from the
+ corresponding IEEE 802.11 dot11TxPowerLevel[n] MIB element, see
+ [IEEE.802-11.2007].
+
+
+
+
+
+
+Calhoun, et al. Standards Track [Page 55]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+6.20. IEEE 802.11 Update Station QoS
+
+ The IEEE 802.11 Update Station QoS message element is used to change
+ the Quality of Service policy on the WTP for a given station. The
+ QoS tags included in this message element are to be applied to
+ packets received at the WTP from the station indicated through the
+ MAC Address field. This message element overrides the default values
+ provided through the IEEE 802.11 WTP Quality of Service message
+ element (see Section 6.22). Any tagging performed by the WTP MUST be
+ directly applied to the packets received from the station, as well as
+ the CAPWAP tunnel, if the packets are tunneled to the AC. See
+ Section 2.6 for more information.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID | MAC Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | MAC Address | QoS Sub-Element... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 1043 for IEEE 802.11 Update Station QoS
+
+ Length: 8
+
+ Radio ID: The Radio Identifier, whose value is between one (1) and
+ 31, typically refers to some interface index on the WTP.
+
+ MAC Address: The station's MAC Address.
+
+ QoS Sub-Element: The IEEE 802.11 WTP Quality of Service message
+ element contains four QoS sub-elements, one for every QoS profile.
+ The order of the QoS profiles are Voice, Video, Best Effort, and
+ Background.
+
+ 0 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Reserved|8021p|RSV| DSCP Tag |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+ Reserved: All implementations complying with this protocol MUST
+ set to zero any bits that are reserved in the version of the
+ protocol supported by that implementation. Receivers MUST
+ ignore all bits not defined for the version of the protocol
+ they support.
+
+
+
+
+Calhoun, et al. Standards Track [Page 56]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ 8021p: The 3-bit 802.1p priority value to use if packets are to
+ be IEEE 802.1p tagged. This field is used only if the 'P' bit
+ in the WTP Quality of Service message element was set;
+ otherwise, its contents MUST be ignored.
+
+ RSV: All implementations complying with this protocol MUST set
+ to zero any bits that are reserved in the version of the
+ protocol supported by that implementation. Receivers MUST
+ ignore all bits not defined for the version of the protocol
+ they support.
+
+ DSCP Tag: The 6-bit DSCP label to use if packets are eligible to
+ be DSCP tagged, specifically an IPv4 or IPv6 packet (see
+ [RFC2474]). This field is used only if the 'D' bit in the WTP
+ Quality of Service message element was set; otherwise, its
+ contents MUST be ignored.
+
+6.21. IEEE 802.11 Update WLAN
+
+ The IEEE 802.11 Update WLAN message element is used by the AC to
+ define a wireless LAN on the WTP. The inclusion of this message
+ element MUST also include the IEEE 802.11 Information Element message
+ element, containing the following 802.11 IEs:
+
+ Power Constraint information element
+
+ WPA information element [WPA]
+
+ RSN information element
+
+ Enhanced Distributed Channel Access (EDCA) Parameter Set information
+ element
+
+ QoS Capability information element
+
+ WMM information element [WMM]
+
+ These IEEE 802.11 Information Elements are stored by the WTP and
+ included in any Probe Responses and Beacons generated, as specified
+ in the IEEE 802.11 standard [IEEE.802-11.2007].
+
+ If cryptographic services are provided at the WTP, the WTP MUST
+ observe the algorithm dictated in the Group Cipher Suite field of the
+ RSN Information Element sent by the AC. The RSN Information Element
+ is used to communicate any supported algorithm, including WEP, TKIP,
+ and AES-CCMP. In the case of static WEP keys, the RSN Information
+ Element is still used to indicate the cryptographic algorithm even
+ though no key exchange occurred.
+
+
+
+Calhoun, et al. Standards Track [Page 57]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ The message element uses the following format:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID | WLAN ID | Capability |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Key Index | Key Status | Key Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Key... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 1044 for IEEE 802.11 Update WLAN
+
+ Length: >= 8
+
+ Radio ID: An 8-bit value representing the radio, whose value is
+ between one (1) and 31.
+
+ WLAN ID: An 8-bit value specifying the WLAN Identifier. The value
+ MUST be between one (1) and 16.
+
+ Capability: A 16-bit value containing the Capability information
+ field to be advertised by the WTP in the Probe Request and Beacon
+ frames. Each bit of the Capability field represents a different
+ WTP capability, which are described in detail in
+ [IEEE.802-11.2007]. The format of the field is:
+
+ 0 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |E|I|C|F|P|S|B|A|M|Q|T|D|V|O|K|L|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ E (ESS): The AC MUST set the Extended Service Set (ESS) subfield
+ to 1.
+
+ I (IBSS): The AC MUST set the Independent Basic Service Set
+ (IBSS) subfield to 0.
+
+ C (CF-Pollable): The AC sets the Contention Free Pollable (CF-
+ Pollable) subfield based on the table found in
+ [IEEE.802-11.2007].
+
+ F (CF-Poll Request): The AC sets the CF-Poll Request subfield
+ based on the table found in [IEEE.802-11.2007].
+
+
+
+
+
+Calhoun, et al. Standards Track [Page 58]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ P (Privacy): The AC sets the Privacy subfield based on the
+ confidentiality requirements of the WLAN, as defined in
+ [IEEE.802-11.2007].
+
+ S (Short Preamble): The AC sets the Short Preamble subfield
+ based on whether the use of short preambles are permitted on the
+ WLAN, as defined in [IEEE.802-11.2007].
+
+ B (PBCC): The AC sets the Packet Binary Convolutional Code
+ (PBCC) modulation option subfield based on whether the use of
+ PBCC is permitted on the WLAN, as defined in [IEEE.802-11.2007].
+
+ A (Channel Agility): The AC sets the Channel Agility subfield
+ based on whether the WTP is capable of supporting the High Rate
+ Direct Sequence Spread Spectrum (HR/DSSS), as defined in
+ [IEEE.802-11.2007].
+
+ M (Spectrum Management): The AC sets the Spectrum Management
+ subfield according to the value of the
+ dot11SpectrumManagementRequired MIB variable, as defined in
+ [IEEE.802-11.2007].
+
+ Q (QoS): The AC sets the Quality of Service (QoS) subfield based
+ on the table found in [IEEE.802-11.2007].
+
+ T (Short Slot Time): The AC sets the Short Slot Time subfield
+ according to the value of the WTP's currently used slot time
+ value, as defined in [IEEE.802-11.2007].
+
+ D (APSD): The AC sets the APSD subfield according to the value
+ of the dot11APSDOptionImplemented Management Information Base
+ (MIB) variable, as defined in [IEEE.802-11.2007].
+
+ V (Reserved): The AC sets the Reserved subfield to zero, as
+ defined in [IEEE.802-11.2007].
+
+ O (DSSS-OFDM): The AC sets the DSSS-OFDM subfield to indicate
+ the use of Direct Sequence Spread Spectrum with Orthogonal
+ Frequency Division Multiplexing (DSSS-OFDM), as defined in
+ [IEEE.802-11.2007].
+
+ K (Delayed Block ACK): The AC sets the Delayed Block ACK
+ subfield according to the value of the
+ dot11DelayedBlockAckOptionImplemented MIB variable, as defined
+ in [IEEE.802-11.2007].
+
+
+
+
+
+
+Calhoun, et al. Standards Track [Page 59]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ L (Immediate Block ACK): The AC sets the Delayed Block ACK
+ subfield according to the value of the
+ dot11ImmediateBlockAckOptionImplemented MIB variable, as defined
+ in [IEEE.802-11.2007].
+
+ Key-Index: The Key-Index associated with the key.
+
+ Key Status: A 1-byte value that specifies the state and usage of
+ the key that has been included. The following values describe the
+ key usage and its status:
+
+ 0 - A value of zero, with the inclusion of the RSN Information
+ Element means that the WLAN uses per-station encryption keys,
+ and therefore the key in the 'Key' field is only used for
+ multicast traffic.
+
+ 1 - When set to one, the WLAN employs a shared WEP key, also
+ known as a static WEP key, and uses the encryption key for
+ both unicast and multicast traffic for all stations.
+
+ 2 - The value of 2 indicates that the AC will begin rekeying the
+ GTK with the STA's in the BSS. It is only valid when IEEE
+ 802.11 is enabled as the security policy for the BSS.
+
+ 3 - The value of 3 indicates that the AC has completed rekeying
+ the GTK and broadcast packets no longer need to be duplicated
+ and transmitted with both GTK's.
+
+ Key Length: A 16-bit value representing the length of the Key
+ field.
+
+ Key: A Session Key, whose length is known via the Key Length field,
+ used to provide data privacy. For static WEP keys, which is true
+ when the 'Key Status' bit is set to one, this key is used for both
+ unicast and multicast traffic. For encryption schemes that employ
+ a separate encryption key for unicast and multicast traffic, the
+ key included here only applies to multicast data, and the cipher
+ suite is specified in an accompanied RSN Information Element. In
+ these scenarios, the key, and cipher information, is communicated
+ via the Add Station message element, see Section 4.6.8 in
+ [RFC5415]. When used with WEP, the Key field includes the
+ broadcast key. When used with CCMP, the Key field includes the
+ 128-bit Group Temporal Key. When used with TKIP, the Key field
+ includes the 256-bit Group Temporal Key (which consists of a 128-
+ bit key used as input for TKIP key mixing, and two 64-bit keys
+ used for Michael).
+
+
+
+
+
+Calhoun, et al. Standards Track [Page 60]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+6.22. IEEE 802.11 WTP Quality of Service
+
+ The IEEE 802.11 WTP Quality of Service message element value is sent
+ by the AC to the WTP to communicate Quality of Service configuration
+ information. The QoS tags included in this message element are the
+ default QoS values to be applied to packets received by the WTP from
+ stations on a particular radio. Any tagging performed by the WTP
+ MUST be directly applied to the packets received from the station, as
+ well as the CAPWAP tunnel, if the packets are tunneled to the AC.
+ See Section 2.6 for more information.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID |Tagging Policy | QoS Sub-Element ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 1045 for IEEE 802.11 WTP Quality of Service
+
+ Length: 34
+
+ Radio ID: The Radio Identifier, whose value is between one (1) and
+ 31, typically refers to some interface index on the WTP.
+
+ Tagging Policy: A bit field indicating how the WTP is to mark
+ packets for QoS purposes. The required WTP behavior is defined in
+ Section 2.6.1. The field has the following format:
+
+ 0 1 2 3 4 5 6 7
+ +-+-+-+-+-+-+-+-+
+ |Rsvd |P|Q|D|O|I|
+ +-+-+-+-+-+-+-+-+
+
+ Rsvd: A set of reserved bits for future use. All implementations
+ complying with this protocol MUST set to zero any bits that are
+ reserved in the version of the protocol supported by that
+ implementation. Receivers MUST ignore all bits not defined for
+ the version of the protocol they support.
+
+ P: When set, the WTP is to employ the 802.1p QoS mechanism (see
+ Section 2.6.1.1), and the WTP is to use the 'Q' bit.
+
+ Q: When the 'P' bit is set, the 'Q' bit is used by the AC to
+ communicate to the WTP how 802.1p QoS is to be enforced.
+ Details on the behavior of the 'Q' bit are specified in
+ Section 2.6.1.1.
+
+
+
+
+
+Calhoun, et al. Standards Track [Page 61]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ D: When set, the WTP is to employ the DSCP QoS mechanism (see
+ Section 2.6.1.2), and the WTP is to use the 'O' and 'I' bits.
+
+ O: When the 'D' bit is set, the 'O' bit is used by the AC to
+ communicate to the WTP how DSCP QoS is to be enforced on the
+ outer (tunneled) header. Details on the behavior of the 'O'
+ bit are specified in Section 2.6.1.2.
+
+ I: When the 'D' bit is set, the 'I' bit is used by the AC to
+ communicate to the WTP how DSCP QoS is to be enforced on the
+ station's packet (inner) header. Details on the behavior of
+ the 'I' bit are specified in Section 2.6.1.2.
+
+ QoS Sub-Element: The IEEE 802.11 WTP Quality of Service message
+ element contains four QoS sub-elements, one for every QoS profile.
+ The order of the QoS profiles are Voice, Video, Best Effort, and
+ Background.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Queue Depth | CWMin | CWMax |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | CWMax | AIFS | Reserved|8021p|RSV| DSCP Tag |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Queue Depth: The number of packets that can be on the specific
+ QoS transmit queue at any given time.
+
+ CWMin: The Contention Window minimum (CWmin) value for the QoS
+ transmit queue. The value of this field comes from the IEEE
+ 802.11 dot11EDCATableCWMin MIB element (see
+ [IEEE.802-11.2007]).
+
+ CWMax: The Contention Window maximum (CWmax) value for the QoS
+ transmit queue. The value of this field comes from the IEEE
+ 802.11 dot11EDCATableCWMax MIB element (see
+ [IEEE.802-11.2007]).
+
+ AIFS: The Arbitration Inter Frame Spacing (AIFS) to use for the
+ QoS transmit queue. The value of this field comes from the
+ IEEE 802.11 dot11EDCATableAIFSN MIB element (see
+ [IEEE.802-11.2007]).
+
+
+
+
+
+
+
+
+Calhoun, et al. Standards Track [Page 62]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ Reserved: All implementations complying with this protocol MUST
+ set to zero any bits that are reserved in the version of the
+ protocol supported by that implementation. Receivers MUST
+ ignore all bits not defined for the version of the protocol
+ they support.
+
+ 8021p: The 3-bit 802.1p priority value to use if packets are to
+ be IEEE 802.1p tagged. This field is used only if the 'P' bit
+ is set; otherwise, its contents MUST be ignored.
+
+ RSV: All implementations complying with this protocol MUST set
+ to zero any bits that are reserved in the version of the
+ protocol supported by that implementation. Receivers MUST
+ ignore all bits not defined for the version of the protocol
+ they support.
+
+ DSCP Tag: The 6-bit DSCP label to use if packets are eligible to
+ be DSCP tagged, specifically an IPv4 or IPv6 packet (see
+ [RFC2474]). This field is used only if the 'D' bit is set;
+ otherwise, its contents MUST be ignored.
+
+6.23. IEEE 802.11 WTP Radio Configuration
+
+ The IEEE 802.11 WTP WLAN Radio Configuration message element is used
+ by the AC to configure a Radio on the WTP, and by the WTP to deliver
+ its radio configuration to the AC. The message element value
+ contains the following fields:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID |Short Preamble| Num of BSSIDs | DTIM Period |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | BSSID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | BSSID | Beacon Period |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Country String |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 1046 for IEEE 802.11 WTP WLAN Radio Configuration
+
+ Length: 16
+
+ Radio ID: An 8-bit value representing the radio to configure, whose
+ value is between one (1) and 31.
+
+
+
+
+
+Calhoun, et al. Standards Track [Page 63]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ Short Preamble: An 8-bit value indicating whether short preamble is
+ supported. The following enumerated values are currently
+ supported:
+
+ 0 - Short preamble not supported.
+
+ 1 - Short preamble is supported.
+
+ BSSID: The WLAN Radio's base MAC Address.
+
+ Number of BSSIDs: This attribute contains the maximum number of
+ BSSIDs supported by the WTP. This value restricts the number of
+ logical networks supported by the WTP, and is between 1 and 16.
+
+ DTIM Period: This attribute specifies the number of Beacon
+ intervals that elapse between transmission of Beacons frames
+ containing a Traffic Indication Map (TIM) element whose Delivery
+ Traffic Indication Message (DTIM) Count field is 0. This value is
+ transmitted in the DTIM Period field of Beacon frames. The value
+ of this field comes from the IEEE 802.11 dot11DTIMPeriod MIB
+ element (see [IEEE.802-11.2007]).
+
+ Beacon Period: This attribute specifies the number of Time Unit
+ (TU) that a station uses for scheduling Beacon transmissions.
+ This value is transmitted in Beacon and Probe Response frames.
+ The value of this field comes from the IEEE 802.11
+ dot11BeaconPeriod MIB element (see [IEEE.802-11.2007]).
+
+ Country String: This attribute identifies the country in which the
+ station is operating. The value of this field comes from the IEEE
+ 802.11 dot11CountryString MIB element (see [IEEE.802-11.2007]).
+ Some regulatory domains do not allow WTPs to have user
+ configurable country string, and require that it be a fixed value
+ during the manufacturing process. Therefore, WTP vendors that
+ wish to allow for the configuration of this field will need to
+ validate this behavior during its radio certification process.
+ Other WTP vendors may simply wish to treat this WTP configuration
+ parameter as read-only. The country strings can be found in
+ [ISO.3166-1].
+
+ The WTP and AC MAY ignore the value of this field, depending upon
+ regulatory requirements, for example to avoid classification as a
+ Software-Defined Radio. When this field is used, the first two
+ octets of this string is the two-character country string as
+ described in [ISO.3166-1], and the third octet MUST either be a
+ space, 'O', 'I', or X' as defined below. When the value of the
+
+
+
+
+
+Calhoun, et al. Standards Track [Page 64]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ third octet is 255 (HEX 0xff), the country string field is not
+ used, and MUST be ignored. The following are the possible values
+ for the third octet:
+
+ 1. an ASCII space character, if the regulations under which the
+ station is operating encompass all environments in the
+ country,
+
+ 2. an ASCII 'O' character, if the regulations under which the
+ station is operating are for an outdoor environment only, or
+
+ 3. an ASCII 'I' character, if the regulations under which the
+ station is operating are for an indoor environment only,
+
+ 4. an ASCII 'X' character, if the station is operating under a
+ non-country entity. The first two octets of the non-country
+ entity shall be two ASCII 'XX' characters,
+
+ 5. a HEX 0xff character means that the country string field is
+ not used and MUST be ignored.
+
+ Note that the last byte of the Country String MUST be set to NULL.
+
+6.24. IEEE 802.11 WTP Radio Fail Alarm Indication
+
+ The IEEE 802.11 WTP Radio Fail Alarm Indication message element is
+ sent by the WTP to the AC when it detects a radio failure.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID | Type | Status | Pad |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type: 1047 for IEEE 802.11 WTP Radio Fail Alarm Indication
+
+ Length: 4
+
+ Radio ID: The Radio Identifier, whose value is between one (1) and
+ 31, typically refers to some interface index on the WTP.
+
+ Type: The type of radio failure detected. The following enumerated
+ values are supported:
+
+ 1 - Receiver
+
+ 2 - Transmitter
+
+
+
+
+Calhoun, et al. Standards Track [Page 65]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ Status: An 8-bit boolean indicating whether the radio failure is
+ being reported or cleared. A value of zero is used to clear the
+ event, while a value of one is used to report the event.
+
+ Pad: All implementations complying with version zero of this
+ protocol MUST set these bits to zero. Receivers MUST ignore all
+ bits not defined for the version of the protocol they support.
+
+6.25. IEEE 802.11 WTP Radio Information
+
+ The IEEE 802.11 WTP Radio Information message element is used to
+ communicate the radio information for each IEEE 802.11 radio in the
+ WTP. The Discovery Request message, Primary Discovery Request
+ message, and Join Request message MUST include one such message
+ element per radio in the WTP. The Radio-Type field is used by the AC
+ in order to determine which IEEE 802.11 technology specific binding
+ is to be used with the WTP.
+
+ The message element contains two fields, as shown below.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio ID | Radio Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Radio Type |
+ +-+-+-+-+-+-+-+-+
+
+ Type: 1048 for IEEE 802.11 WTP Radio Information
+
+ Length: 5
+
+ Radio ID: The Radio Identifier, whose value is between one (1) and
+ 31, which typically refers to an interface index on the WTP.
+
+ Radio Type: The type of radio present. Note this is a bit field
+ that is used to specify support for more than a single type of
+ PHY/MAC. The field has the following format:
+
+ 0 1 2 3 4 5 6 7
+ +-+-+-+-+-+-+-+-+
+ |Reservd|N|G|A|B|
+ +-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+Calhoun, et al. Standards Track [Page 66]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ Reservd: A set of reserved bits for future use. All
+ implementations complying with this protocol MUST set to zero
+ any bits that are reserved in the version of the protocol
+ supported by that implementation. Receivers MUST ignore all
+ bits not defined for the version of the protocol they support.
+
+ N: An IEEE 802.11n radio.
+
+ G: An IEEE 802.11g radio.
+
+ A: An IEEE 802.11a radio.
+
+ B: An IEEE 802.11b radio.
+
+7. IEEE 802.11 Binding WTP Saved Variables
+
+ This section contains the IEEE 802.11 binding specific variables that
+ SHOULD be saved in non-volatile memory on the WTP.
+
+7.1. IEEE80211AntennaInfo
+
+ The WTP-per-radio antenna configuration, defined in Section 6.2.
+
+7.2. IEEE80211DSControl
+
+ The WTP-per-radio Direct Sequence Control configuration, defined in
+ Section 6.5.
+
+7.3. IEEE80211MACOperation
+
+ The WTP-per-radio MAC Operation configuration, defined in
+ Section 6.7.
+
+7.4. IEEE80211OFDMControl
+
+ The WTP-per-radio OFDM MAC Operation configuration, defined in
+ Section 6.10.
+
+7.5. IEEE80211Rateset
+
+ The WTP-per-radio Basic Rate Set configuration, defined in
+ Section 6.11.
+
+7.6. IEEE80211TxPower
+
+ The WTP-per-radio Transmit Power configuration, defined in
+ Section 6.18.
+
+
+
+
+Calhoun, et al. Standards Track [Page 67]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+7.7. IEEE80211QoS
+
+ The WTP-per-radio Quality of Service configuration, defined in
+ Section 6.22.
+
+7.8. IEEE80211RadioConfig
+
+ The WTP-per-radio Radio Configuration, defined in Section 6.23.
+
+8. Technology Specific Message Element Values
+
+ This section lists IEEE 802.11-specific values for the generic CAPWAP
+ message elements that include fields whose values are technology
+ specific.
+
+8.1. WTP Descriptor Message Element, Encryption Capabilities Field
+
+ This specification defines two new bits for the WTP Descriptor's
+ Encryption Capabilities field, as defined in [RFC5415]. Note that
+ only the bits defined in this specification are described below. WEP
+ is not explicitly advertised as a WTP capability since all WTPs are
+ expected to support the encryption cipher. The format of the
+ Encryption Capabilities field is:
+
+ 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |A|T| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ A: WTP supports AES-CCMP, as defined in [IEEE.802-11.2007].
+
+ T: WTP supports TKIP and Michael, as defined in [IEEE.802-11.2007]
+ and [WPA], respectively.
+
+9. Security Considerations
+
+ This section describes security considerations for using IEEE 802.11
+ with the CAPWAP protocol. A complete threat analysis of the CAPWAP
+ protocol can also be found in [RFC5418].
+
+9.1. IEEE 802.11 Security
+
+ When used with an IEEE 802.11 infrastructure with WEP encryption, the
+ CAPWAP protocol does not add any new vulnerabilities. Derived
+ Session Keys between the STA and WTP can be compromised, resulting in
+
+
+
+
+
+Calhoun, et al. Standards Track [Page 68]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ many well-documented attacks. Implementers SHOULD discourage the use
+ of WEP and encourage the use of technically-sound cryptographic
+ solutions such as those in an IEEE 802.11 RSN.
+
+ STA authentication is performed using IEEE 802.lX, and consequently
+ EAP. Implementers SHOULD use EAP methods meeting the requirements
+ specified [RFC4017].
+
+ When used with IEEE 802.11 RSN security, the CAPWAP protocol may
+ introduce new vulnerabilities, depending on whether the link security
+ (packet encryption and integrity verification) is provided by the WTP
+ or the AC. When the link security function is provided by the AC, no
+ new security concerns are introduced.
+
+ However, when the WTP provides link security, a new vulnerability
+ will exist when the following conditions are true:
+
+ o The client is not the first to associate to the WTP/ESSID (i.e.,
+ other clients are associated), a GTK already exists, and
+
+ o traffic has been broadcast under the existing GTK.
+
+ Under these circumstances, the receive sequence counter (KeyRSC)
+ associated with the GTK is non-zero, but because the AC anchors the
+ 4-way handshake with the client, the exact value of the KeyRSC is not
+ known when the AC constructs the message containing the GTK. The
+ client will update its Key RSC value to the current valid KeyRSC upon
+ receipt of a valid multicast/broadcast message, but prior to this,
+ previous multicast/broadcast traffic that was secured with the
+ existing GTK may be replayed, and the client will accept this traffic
+ as valid.
+
+ Typically, busy networks will produce numerous multicast or broadcast
+ frames per second, so the window of opportunity with respect to such
+ replay is expected to be very small. In most conditions, it is
+ expected that replayed frames could be detected (and logged) by the
+ WTP.
+
+ The only way to completely close this window is to provide the exact
+ KeyRSC value in message 3 of the 4-way handshake; any other approach
+ simply narrows the window to varying degrees. Given the low relative
+ threat level this presents, the additional complexity introduced by
+ providing the exact KeyRSC value is not warranted. That is, this
+ specification provides for a calculated risk in this regard.
+
+
+
+
+
+
+
+Calhoun, et al. Standards Track [Page 69]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ The AC SHOULD use an RSC of 0 when computing message-3 of the 4-way
+ 802.11i handshake, unless the AC has knowledge of a more optimal RSC
+ value to use. Mechanisms for determining a more optimal RSC value
+ are outside the scope of this specification.
+
+10. IANA Considerations
+
+ This section details the actions IANA has taken per this
+ specification. There are numerous registries that have been be
+ created, and the contents, document action (see [RFC5226], and
+ registry format are all included below. Note that in cases where bit
+ fields are referred to, the bit numbering is left to right, where the
+ leftmost bit is labeled as bit zero (0).
+
+10.1. CAPWAP Wireless Binding Identifier
+
+ This specification requires a value assigned from the Wireless
+ Binding Identifier namespace, defined in [RFC5415]. (1) has been
+ assigned (see Section 2.1, as it is used in implementations.
+
+10.2. CAPWAP IEEE 802.11 Message Types
+
+ IANA created a new sub-registry in the existing CAPWAP Message Type
+ registry, which is defined in [RFC5415].
+
+ IANA created and maintains the CAPWAP IEEE 802.11 Message Types
+ sub-registry for all message types whose Enterprise Number is set to
+ 13277. The namespace is 8 bits (3398912-3399167), where the value
+ 3398912 is reserved and must not be assigned. The values 3398913 and
+ 3398914 are allocated in this specification, and can be found in
+ Section 3. Any new assignments of a CAPWAP IEEE 802.11 Message Type
+ (whose Enterprise Number is set to 13277) require an Expert Review.
+ The format of the registry maintained by IANA is as follows:
+
+ CAPWAP IEEE 802.11 Message Type Reference
+ Control Message Value
+
+10.3. CAPWAP Message Element Type
+
+ This specification defines new values to be registered to the
+ existing CAPWAP Message Element Type registry, defined in [RFC5415].
+ The values used in this document, 1024 through 1048, as listed in
+ Figure 8 are recommended as implementations already exist that make
+ use of these values.
+
+
+
+
+
+
+
+Calhoun, et al. Standards Track [Page 70]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+10.4. IEEE 802.11 Key Status
+
+ The Key Status field in the IEEE 802.11 Add WLAN message element (see
+ Section 6.1) and IEEE 802.11 Update WLAN message element (see
+ Section 6.21) is used to provide information about the status of the
+ keying exchange. This document defines four values, zero (0) through
+ three (3), and the remaining values (4-255) are controlled and
+ maintained by IANA and requires an Expert Review.
+
+10.5. IEEE 802.11 QoS
+
+ The QoS field in the IEEE 802.11 Add WLAN message element (see
+ Section 6.1) is used to configure a QoS policy for the WLAN. The
+ namespace is 8 bits (0-255), where the values zero (0) through three
+ (3) are allocated in this specification, and can be found in
+ Section 6.1. This namespace is managed by IANA and assignments
+ require an Expert Review. IANA created the IEEE 802.11 QoS registry,
+ whose format is:
+
+ IEEE 802.11 QoS Type Value Reference
+
+10.6. IEEE 802.11 Auth Type
+
+ The Auth Type field in the IEEE 802.11 Add WLAN message element (see
+ Section 6.1) is 8 bits and is used to configure the IEEE 802.11
+ authentication policy for the WLAN. The namespace is 8 bits (0-255),
+ where the values zero (0) and one (1) are allocated in this
+ specification, and can be found in Section 6.1. This namespace is
+ managed by IANA and assignments require an Expert Review. IANA
+ created the IEEE 802.11 Auth Type registry, whose format is:
+
+ IEEE 802.11 Auth Type Type Value Reference
+
+10.7. IEEE 802.11 Antenna Combiner
+
+ The Combiner field in the IEEE 802.11 Antenna message element (see
+ Section 6.2) is used to provide information about the WTP's antennas.
+ The namespace is 8 bits (0-255), where the values one (1) through
+ four (4) are allocated in this specification, and can be found in
+ Section 6.2. This namespace is managed by IANA and assignments
+ require an Expert Review. IANA created the IEEE 802.11 Antenna
+ Combiner registry, whose format is:
+
+ IEEE 802.11 Antenna Combiner Type Value Reference
+
+
+
+
+
+
+
+Calhoun, et al. Standards Track [Page 71]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+10.8. IEEE 802.11 Antenna Selection
+
+ The Antenna Selection field in the IEEE 802.11 Antenna message
+ element (see Section 6.2) is used to provide information about the
+ WTP's antennas. The namespace is 8 bits (0-255), where the values
+ zero (0) is reserved and used and the values one (1) through two (2)
+ are allocated in this specification, and can be found in Section 6.2.
+ This namespace is managed by IANA and assignments require an Expert
+ Review. IANA created the IEEE 802.11 Antenna Selection registry,
+ whose format is:
+
+ IEEE 802.11 Antenna Selection Type Value Reference
+
+10.9. IEEE 802.11 Session Key Flags
+
+ The flags field in the IEEE 802.11 Station Session Key message
+ element (see Section 6.15) is 16 bits and is used to configure the
+ session key association with the mobile device. This specification
+ defines bits zero (0) and one (1), while bits two (2) through fifteen
+ are reserved. The reserved bits are managed by IANA and assignment
+ requires an Expert Review. IANA created the IEEE 802.11 Session Key
+ Flags registry, whose format is:
+
+ IEEE 802.11 Station Session Key Bit Position Reference
+
+10.10. IEEE 802.11 Tagging Policy
+
+ The Tagging Policy field in the IEEE 802.11 WTP Quality of Service
+ message element (see Section 6.22) is 8 bits and is used to specify
+ how the CAPWAP Data Channel packets are to be tagged. This
+ specification defines bits three (3) through seven (7). The
+ remaining bits are managed by IANA and assignment requires an Expert
+ Review. IANA created the IEEE 802.11 Tagging Policy registry, whose
+ format is:
+
+ IEEE 802.11 Tagging Policy Bit Position Reference
+
+10.11. IEEE 802.11 WTP Radio Fail
+
+ The Type field in the IEEE 802.11 WTP Radio Fail Alarm Indication
+ message element (see Section 6.24) is used to provide information on
+ why a WTP's radio has failed. The namespace is 8 bits (0-255), where
+ the value zero (0) is reserved and unused, while the values one (1)
+ and two (2) are allocated in this specification, and can be found in
+ Section 6.24. This namespace is managed by IANA and assignments
+ require an Expert Review. IANA created the IEEE 802.11 WTP Radio
+ Fail registry, whose format is:
+
+
+
+
+Calhoun, et al. Standards Track [Page 72]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ IEEE 802.11 WTP Radio Fail Type Value Reference
+
+10.12. IEEE 802.11 WTP Radio Type
+
+ The Radio Type field in the IEEE 802.11 WTP Radio Information message
+ element (see Section 6.25) is 8 bits and is used to provide
+ information about the WTP's radio type. This specification defines
+ bits four (4) through seven (7). The remaining bits are managed by
+ IANA and assignment requires an Expert Review. IANA created the IEEE
+ 802.11 WTP Radio Type registry, whose format is:
+
+ IEEE 802.11 WTP Radio Type Bit Position Reference
+
+10.13. WTP Encryption Capabilities
+
+ The WTP Encryption Capabilities field in the WTP Descriptor message
+ element (see Section 8.1) is 16 bits and is used by the WTP to
+ indicate its IEEE 802.11 encryption capabilities. This specification
+ defines bits 12 and 13. The reserved bits are managed by IANA and
+ assignment requires an Expert Review. IANA created the IEEE 802.11
+ Encryption Capabilities registry, whose format is:
+
+ IEEE 802.11 Encryption Capabilities Bit Position Reference
+
+11. Acknowledgments
+
+ The following individuals are acknowledged for their contributions to
+ this binding specification: Puneet Agarwal, Charles Clancy, Pasi
+ Eronen, Saravanan Govindan, Scott Kelly, Peter Nilsson, Bob O'Hara,
+ David Perkins, Margaret Wasserman, and Yong Zhang.
+
+12. References
+
+12.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to
+ Indicate Requirement Levels", BCP 14, RFC 2119,
+ March 1997.
+
+ [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
+ "Definition of the Differentiated Services Field
+ (DS Field) in the IPv4 and IPv6 Headers",
+ RFC 2474, December 1998.
+
+ [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le
+ Boudec, J., Courtney, W., Davari, S., Firoiu, V.,
+ and D. Stiliadis, "An Expedited Forwarding PHB
+ (Per-Hop Behavior)", RFC 3246, March 2002.
+
+
+
+Calhoun, et al. Standards Track [Page 73]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The
+ Addition of Explicit Congestion Notification
+ (ECN) to IP", RFC 3168, September 2001.
+
+ [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson,
+ J., and H. Levkowetz, "Extensible Authentication
+ Protocol (EAP)", RFC 3748, June 2004.
+
+ [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for
+ Writing an IANA Considerations Section in RFCs",
+ BCP 26, RFC 5226, May 2008.
+
+ [FIPS.197.2001] National Institute of Standards and Technology,
+ "Advanced Encryption Standard (AES)", FIPS PUB
+ 197, November 2001, .
+
+ [ISO.3166-1] ISO Standard, "International Organization for
+ Standardization, Codes for the representation of
+ names of countries and their subdivisions - Part
+ 1: Country codes", ISO Standard 3166-1:1997,
+ 1997.
+
+ [IEEE.802-11.2007] "Information technology - Telecommunications and
+ information exchange between systems - Local and
+ metropolitan area networks - Specific
+ requirements - Part 11: Wireless LAN Medium
+ Access Control (MAC) and Physical Layer (PHY)
+ specifications", IEEE Standard 802.11, 2007,
+ .
+
+ [RFC5415] Montemurro, M., Stanley, D., and P. Calhoun,
+ "CAPWAP Protocol Specification", RFC 5415, March
+ 2009.
+
+ [IEEE.802-1X.2004] "Information technology - Telecommunications and
+ information exchange between systems - Local and
+ metropolitan area networks - Specific
+ requirements - Port-Based Network Access
+ Control", IEEE Standard 802.1X, 2004, .
+
+
+
+
+
+
+
+
+Calhoun, et al. Standards Track [Page 74]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+ [IEEE.802-1Q.2005] "Information technology - Telecommunications and
+ information exchange between systems - Local and
+ metropolitan area networks - Specific
+ requirements - Virtual Bridged Local Area
+ Networks", IEEE Standard 802.1Q, 2005, .
+
+12.2. Informative References
+
+ [RFC4017] Stanley, D., Walker, J., and B. Aboba,
+ "Extensible Authentication Protocol (EAP) Method
+ Requirements for Wireless LANs", RFC 4017,
+ March 2005.
+
+ [RFC4118] Yang, L., Zerfos, P., and E. Sadot, "Architecture
+ Taxonomy for Control and Provisioning of Wireless
+ Access Points (CAPWAP)", RFC 4118, June 2005.
+
+ [RFC5418] Kelly, S. and C. Clancy, "Control And
+ Provisioning for Wireless Access Points (CAPWAP)
+ Threat Analysis for IEEE 802.11 Deployments",
+ RFC 5418, March 2009.
+
+ [WPA] "Deploying Wi-Fi Protected Access (WPA) and WPA2
+ in the Enterprise", March 2005, .
+
+ [WMM] "Support for Multimedia Applications with Quality
+ of Service in WiFi Networks)", September 2004,
+ .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Calhoun, et al. Standards Track [Page 75]
+
+RFC 5416 CAPWAP Protocol Binding for IEEE 802.11 March 2009
+
+
+Editors' Addresses
+
+ Pat R. Calhoun (editor)
+ Cisco Systems, Inc.
+ 170 West Tasman Drive
+ San Jose, CA 95134
+
+ Phone: +1 408-902-3240
+ EMail: pcalhoun@cisco.com
+
+
+ Michael P. Montemurro (editor)
+ Research In Motion
+ 5090 Commerce Blvd
+ Mississauga, ON L4W 5M4
+ Canada
+
+ Phone: +1 905-629-4746 x4999
+ EMail: mmontemurro@rim.com
+
+
+ Dorothy Stanley (editor)
+ Aruba Networks
+ 1322 Crossman Ave
+ Sunnyvale, CA 94089
+
+ Phone: +1 630-363-1389
+ EMail: dstanley@arubanetworks.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Calhoun, et al. Standards Track [Page 76]
+