RFC 5416
Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding for IEEE 802.11
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.
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
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
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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].
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 Example2.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
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 Procedure2.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.
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.
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
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.
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.
(page 21 continued on part 2)
