Internet DRAFT - draft-ietf-capwap-protocol-binding-ieee80211
draft-ietf-capwap-protocol-binding-ieee80211
Network Working Group P. Calhoun, Editor
Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track M. Montemurro, Editor
Expires: May 4, 2009 Research In Motion
D. Stanley, Editor
Aruba Networks
October 31, 2008
CAPWAP Protocol Binding for IEEE 802.11
draft-ietf-capwap-protocol-binding-ieee80211-12
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 May 4, 2009.
Calhoun, Editor, et al. Expires May 4, 2009 [Page 1]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 October 2008
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 . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Conventions used in this document . . . . . . . . . . . . 6
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2. IEEE 802.11 Binding . . . . . . . . . . . . . . . . . . . . . 8
2.1. CAPWAP Wireless Binding Identifier . . . . . . . . . . . 8
2.2. Split MAC and Local MAC Functionality . . . . . . . . . . 8
2.2.1. Split MAC . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2. Local MAC . . . . . . . . . . . . . . . . . . . . . . 13
2.3. Roaming Behavior . . . . . . . . . . . . . . . . . . . . 16
2.4. Group Key Refresh . . . . . . . . . . . . . . . . . . . . 17
2.5. BSSID to WLAN ID Mapping . . . . . . . . . . . . . . . . 18
2.6. CAPWAP Data Channel QoS Behavior . . . . . . . . . . . . 19
2.6.1. IEEE 802.11 Data Frames . . . . . . . . . . . . . . . 19
2.6.2. IEEE 802.11 MAC Management Messages . . . . . . . . . 22
2.7. Run State Operation . . . . . . . . . . . . . . . . . . . 22
3. IEEE 802.11 Specific CAPWAP Control Messages . . . . . . . . . 23
3.1. IEEE 802.11 WLAN Configuration Request . . . . . . . . . 23
3.2. IEEE 802.11 WLAN Configuration Response . . . . . . . . . 24
4. CAPWAP Data Message Bindings . . . . . . . . . . . . . . . . . 25
5. CAPWAP Control Message bindings . . . . . . . . . . . . . . . 27
5.1. Discovery Request Message . . . . . . . . . . . . . . . . 27
5.2. Discovery Response Message . . . . . . . . . . . . . . . 27
5.3. Primary Discovery Request Message . . . . . . . . . . . . 27
5.4. Primary Discovery Response Message . . . . . . . . . . . 27
5.5. Join Request Message . . . . . . . . . . . . . . . . . . 27
5.6. Join Response Message . . . . . . . . . . . . . . . . . . 28
5.7. Configuration Status Request Message . . . . . . . . . . 28
5.8. Configuration Status Response Message . . . . . . . . . . 28
5.9. Configuration Update Request Message . . . . . . . . . . 29
5.10. Station Configuration Request . . . . . . . . . . . . . . 30
Calhoun, Editor, et al. Expires May 4, 2009 [Page 2]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 October 2008
5.11. Change State Event Request . . . . . . . . . . . . . . . 30
5.12. WTP Event Request . . . . . . . . . . . . . . . . . . . . 30
6. IEEE 802.11 Message Element Definitions . . . . . . . . . . . 31
6.1. IEEE 802.11 Add WLAN . . . . . . . . . . . . . . . . . . 31
6.2. IEEE 802.11 Antenna . . . . . . . . . . . . . . . . . . . 37
6.3. IEEE 802.11 Assigned WTP BSSID . . . . . . . . . . . . . 38
6.4. IEEE 802.11 Delete WLAN . . . . . . . . . . . . . . . . . 39
6.5. IEEE 802.11 Direct Sequence Control . . . . . . . . . . . 39
6.6. IEEE 802.11 Information Element . . . . . . . . . . . . . 41
6.7. IEEE 802.11 MAC Operation . . . . . . . . . . . . . . . . 41
6.8. IEEE 802.11 MIC Countermeasures . . . . . . . . . . . . . 43
6.9. IEEE 802.11 Multi-Domain Capability . . . . . . . . . . . 44
6.10. IEEE 802.11 OFDM Control . . . . . . . . . . . . . . . . 45
6.11. IEEE 802.11 Rate Set . . . . . . . . . . . . . . . . . . 46
6.12. IEEE 802.11 RSNA Error Report From Station . . . . . . . 47
6.13. IEEE 802.11 Station . . . . . . . . . . . . . . . . . . . 49
6.14. IEEE 802.11 Station QoS Profile . . . . . . . . . . . . . 50
6.15. IEEE 802.11 Station Session Key . . . . . . . . . . . . . 51
6.16. IEEE 802.11 Statistics . . . . . . . . . . . . . . . . . 53
6.17. IEEE 802.11 Supported Rates . . . . . . . . . . . . . . . 57
6.18. IEEE 802.11 Tx Power . . . . . . . . . . . . . . . . . . 57
6.19. IEEE 802.11 Tx Power Level . . . . . . . . . . . . . . . 58
6.20. IEEE 802.11 Update Station QoS . . . . . . . . . . . . . 59
6.21. IEEE 802.11 Update WLAN . . . . . . . . . . . . . . . . . 60
6.22. IEEE 802.11 WTP Quality of Service . . . . . . . . . . . 64
6.23. IEEE 802.11 WTP Radio Configuration . . . . . . . . . . . 66
6.24. IEEE 802.11 WTP Radio Fail Alarm Indication . . . . . . . 68
6.25. IEEE 802.11 WTP Radio Information . . . . . . . . . . . . 69
7. IEEE 802.11 Binding WTP Saved Variables . . . . . . . . . . . 71
7.1. IEEE80211AntennaInfo . . . . . . . . . . . . . . . . . . 71
7.2. IEEE80211DSControl . . . . . . . . . . . . . . . . . . . 71
7.3. IEEE80211MACOperation . . . . . . . . . . . . . . . . . . 71
7.4. IEEE80211OFDMControl . . . . . . . . . . . . . . . . . . 71
7.5. IEEE80211Rateset . . . . . . . . . . . . . . . . . . . . 71
7.6. IEEE80211TxPower . . . . . . . . . . . . . . . . . . . . 71
7.7. IEEE80211QoS . . . . . . . . . . . . . . . . . . . . . . 71
7.8. IEEE80211RadioConfig . . . . . . . . . . . . . . . . . . 71
8. Technology Specific Message Element Values . . . . . . . . . . 72
8.1. WTP Descriptor Message Element, Encryption
Capabilities Field: . . . . . . . . . . . . . . . . . . . 72
9. Security Considerations . . . . . . . . . . . . . . . . . . . 73
9.1. IEEE 802.11 Security . . . . . . . . . . . . . . . . . . 73
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 75
10.1. CAPWAP Wireless Binding Identifier . . . . . . . . . . . 75
10.2. CAPWAP IEEE 802.11 Message Types . . . . . . . . . . . . 75
10.3. CAPWAP Message Element Type . . . . . . . . . . . . . . . 75
10.4. IEEE 802.11 Key Status . . . . . . . . . . . . . . . . . 75
10.5. IEEE 802.11 QoS . . . . . . . . . . . . . . . . . . . . . 76
Calhoun, Editor, et al. Expires May 4, 2009 [Page 3]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 October 2008
10.6. IEEE 802.11 Auth Type . . . . . . . . . . . . . . . . . . 76
10.7. IEEE 802.11 Antenna Combiner . . . . . . . . . . . . . . 76
10.8. IEEE 802.11 Antenna Selection . . . . . . . . . . . . . . 76
10.9. IEEE 802.11 Session Key Flags . . . . . . . . . . . . . . 77
10.10. IEEE 802.11 Tagging Policy . . . . . . . . . . . . . . . 77
10.11. IEEE 802.11 WTP Radio Fail . . . . . . . . . . . . . . . 77
10.12. IEEE 802.11 WTP Radio Type . . . . . . . . . . . . . . . 77
10.13. WTP Encryption Capabilities . . . . . . . . . . . . . . . 78
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 79
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 80
12.1. Normative References . . . . . . . . . . . . . . . . . . 80
12.2. Informational References . . . . . . . . . . . . . . . . 81
Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 82
Intellectual Property and Copyright Statements . . . . . . . . . . 83
Calhoun, Editor, et al. Expires May 4, 2009 [Page 4]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 October 2008
1. Introduction
The CAPWAP protocol [I-D.ietf-capwap-protocol-specification] 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, but
instead relies on 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. New protocol
specifications published outside of this document (e.g., IEEE
802.11n, IEEE 802.11r) are therefore not supported through this
binding, and must be addressed either through a separate CAPWAP
binding, or an update to this binding.
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
Calhoun, Editor, et al. Expires May 4, 2009 [Page 5]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 October 2008
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 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.
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.
Calhoun, Editor, et al. Expires May 4, 2009 [Page 6]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 October 2008
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, Editor, et al. Expires May 4, 2009 [Page 7]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 October 2008
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 tagging and Run State operation.
2.1. CAPWAP Wireless Binding Identifier
The CAPWAP Header, defined in section 4.3 of
[I-D.ietf-capwap-protocol-specification] requires that all CAPWAP
binding specifications have a Wireless Binding Identifier (WBID)
assigned. This document, which defines the IEEE 802.11 binding, uses
the 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, Editor, et al. Expires May 4, 2009 [Page 8]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 October 2008
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 which 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 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, Editor, et al. Expires May 4, 2009 [Page 9]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 October 2008
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 AES-CCMP link layer encryption (Counter mode with
Cipher-block chaining Message authentication code Protocol, 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 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, Editor, et al. Expires May 4, 2009 [Page 10]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 October 2008
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
[I-D.ietf-capwap-protocol-specification]). 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 the station has associated with.
- 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 obust 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 the station has associated with.
- 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, Editor, et al. Expires May 4, 2009 [Page 11]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 October 2008
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 the station has associated with.
- An IEEE 802.11 Station Session Key message element with the
flag fields' '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 EAPOL-Key exchange between the Station and the
AC, the Receive Sequence Counter (RSC) field for the 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, Editor, et al. Expires May 4, 2009 [Page 12]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 October 2008
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, implementors 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, Editor, et al. Expires May 4, 2009 [Page 13]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 October 2008
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, Editor, et al. Expires May 4, 2009 [Page 14]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 October 2008
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.
Calhoun, Editor, et al. Expires May 4, 2009 [Page 15]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 October 2008
o The WTP forwards the IEEE 802.11 Authentication and Association
frames to the AC.
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
[I-D.ietf-capwap-protocol-specification]). 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 the station has associated with
- 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.
Calhoun, Editor, et al. Expires May 4, 2009 [Page 16]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 October 2008
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].
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 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.
Calhoun, Editor, et al. Expires May 4, 2009 [Page 17]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 October 2008
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 STA's in the
BSS 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 STA's 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 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 STA's 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, Editor, et al. Expires May 4, 2009 [Page 18]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 October 2008
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 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 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 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.
When an IEEE 802.11 Update Station QoS message element is received,
Calhoun, Editor, et al. Expires May 4, 2009 [Page 19]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 October 2008
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 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 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
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
communicated that tunneling is not required, as part of the IEEE
Calhoun, Editor, et al. Expires May 4, 2009 [Page 20]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 October 2008
802.11 Add WLAN message element Section 6.1. In the case where
tunneling is not used, the 'I' and 'O' bits have the following
behavior:
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.
The CAPWAP protocol supports the Explicit Congestion Notification
(ECN) bits [RFC3168]. Additional details on ECN support can be found
[I-D.ietf-capwap-protocol-specification].
Calhoun, Editor, et al. Expires May 4, 2009 [Page 21]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 October 2008
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
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
[RFC2598]).
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.
Calhoun, Editor, et al. Expires May 4, 2009 [Page 22]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 October 2008
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 [I-D.ietf-capwap-protocol-specification] for
CAPWAP Control message definitions and the derivation of the Message
Type value from the IANA Enterprise number.
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
[I-D.ietf-capwap-protocol-specification]) 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.
Calhoun, Editor, et al. Expires May 4, 2009 [Page 23]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 October 2008
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
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
[I-D.ietf-capwap-protocol-specification]
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
[I-D.ietf-capwap-protocol-specification]
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
[I-D.ietf-capwap-protocol-specification]
Calhoun, Editor, et al. Expires May 4, 2009 [Page 24]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 October 2008
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
[I-D.ietf-capwap-protocol-specification]) 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 (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: 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.
Calhoun, Editor, et al. Expires May 4, 2009 [Page 25]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 October 2008
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.5Mbps would be set to 55,
while 11Mbps 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Calhoun, Editor, et al. Expires May 4, 2009 [Page 26]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 October 2008
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.
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
Calhoun, Editor, et al. Expires May 4, 2009 [Page 27]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 October 2008
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 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
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
Calhoun, Editor, et al. Expires May 4, 2009 [Page 28]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 October 2008
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
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
Calhoun, Editor, et al. Expires May 4, 2009 [Page 29]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 October 2008
5.10. Station Configuration Request
The following IEEE 802.11 specific message elements MAY 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 elements MAY 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, Editor, et al. Expires May 4, 2009 [Page 30]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 October 2008
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
Calhoun, Editor, et al. Expires May 4, 2009 [Page 31]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 October 2008
EDCA Parameter Set information element
QoS Capability information element
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, 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
Calhoun, Editor, et al. Expires May 4, 2009 [Page 32]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 October 2008
Length: >= 20
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].
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].
Calhoun, Editor, et al. Expires May 4, 2009 [Page 33]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 October 2008
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 Timesubfield
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].
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:
Calhoun, Editor, et al. Expires May 4, 2009 [Page 34]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 October 2008
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 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
[I-D.ietf-capwap-protocol-specification] 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
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:
Calhoun, Editor, et al. Expires May 4, 2009 [Page 35]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 October 2008
0 - Best Effort
1 - Video
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 modes. 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
[I-D.ietf-capwap-protocol-specification]). 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 [I-D.ietf-capwap-protocol-specification]). 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
[I-D.ietf-capwap-protocol-specification]). Note that this
option MUST NOT be selected with Split-MAC mode.
Calhoun, Editor, et al. Expires May 4, 2009 [Page 36]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 October 2008
2 - 802.11 Tunnel: All user traffic is to be tunneled to the AC
in 802.11 format.
Supress 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.
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 receive 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
receive antenna)
Calhoun, Editor, et al. Expires May 4, 2009 [Page 37]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 October 2008
Combiner: An 8-bit value specifying the combiner selection. The
following enumerated values are supported:
1 - Sectorized (Left)
2 - Sectorized (Right)
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Calhoun, Editor, et al. Expires May 4, 2009 [Page 38]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 October 2008
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.
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.
Calhoun, Editor, et al. Expires May 4, 2009 [Page 39]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 October 2008
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
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]).
Calhoun, Editor, et al. Expires May 4, 2009 [Page 40]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 October 2008
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Calhoun, Editor, et al. Expires May 4, 2009 [Page 41]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 October 2008
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
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 an 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]).
Calhoun, Editor, et al. Expires May 4, 2009 [Page 42]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 October 2008
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
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 TU,
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].
Calhoun, Editor, et al. Expires May 4, 2009 [Page 43]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 October 2008
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.
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.
Calhoun, Editor, et al. Expires May 4, 2009 [Page 44]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 October 2008
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 Channnel #: 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]).
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.
Calhoun, Editor, et al. Expires May 4, 2009 [Page 45]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 October 2008
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 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
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Calhoun, Editor, et al. Expires May 4, 2009 [Page 46]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 October 2008
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].
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Calhoun, Editor, et al. Expires May 4, 2009 [Page 47]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 October 2008
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 on.
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.
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]).
Calhoun, Editor, et al. Expires May 4, 2009 [Page 48]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 October 2008
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.
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.
Calhoun, Editor, et al. Expires May 4, 2009 [Page 49]
Internet-Draft CAPWAP Protocol Binding for IEEE 802.11 October 2008
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.
