draft-ietf-capwap-protocol-binding-ieee80211-07.txt   draft-ietf-capwap-protocol-binding-ieee80211-08.txt 
Network Working Group P. Calhoun, Editor Network Working Group P. Calhoun, Editor
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track M. Montemurro, Editor Intended status: Standards Track M. Montemurro, Editor
Expires: January 11, 2009 Research In Motion Expires: March 13, 2009 Research In Motion
D. Stanley, Editor D. Stanley, Editor
Aruba Networks Aruba Networks
July 10, 2008 September 9, 2008
CAPWAP Protocol Binding for IEEE 802.11 CAPWAP Protocol Binding for IEEE 802.11
draft-ietf-capwap-protocol-binding-ieee80211-07 draft-ietf-capwap-protocol-binding-ieee80211-08
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 11, 2009. This Internet-Draft will expire on March 13, 2009.
Abstract Abstract
Wireless LAN product architectures have evolved from single Wireless LAN product architectures have evolved from single
autonomous access points to systems consisting of a centralized autonomous access points to systems consisting of a centralized
Access Controller (AC) and Wireless Termination Points (WTPs). The Access Controller (AC) and Wireless Termination Points (WTPs). The
general goal of centralized control architectures is to move access general goal of centralized control architectures is to move access
control, including user authentication and authorization, mobility control, including user authentication and authorization, mobility
management and radio management from the single access point to a management and radio management from the single access point to a
centralized controller. centralized controller.
This specification defines the Control And Provisioning of Wireless This specification defines the Control And Provisioning of Wireless
Access Points (CAPWAP) Protocol Binding Specification for use with Access Points (CAPWAP) Protocol Binding Specification for use with
the IEEE 802.11 Wireless Local Area Network protocol. the IEEE 802.11 Wireless Local Area Network protocol.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Conventions used in this document . . . . . . . . . . . . 5 1.2. Conventions used in this document . . . . . . . . . . . . 6
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2. IEEE 802.11 Binding . . . . . . . . . . . . . . . . . . . . . 7 2. IEEE 802.11 Binding . . . . . . . . . . . . . . . . . . . . . 8
2.1. Split MAC and Local MAC Functionality . . . . . . . . . . 7 2.1. CAPWAP Wireless Binding Identifier . . . . . . . . . . . 8
2.1.1. Split MAC . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Split MAC and Local MAC Functionality . . . . . . . . . . 8
2.1.2. Local MAC . . . . . . . . . . . . . . . . . . . . . . 11 2.2.1. Split MAC . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Roaming Behavior . . . . . . . . . . . . . . . . . . . . 13 2.2.2. Local MAC . . . . . . . . . . . . . . . . . . . . . . 12
2.3. Group Key Refresh . . . . . . . . . . . . . . . . . . . . 14 2.3. Roaming Behavior . . . . . . . . . . . . . . . . . . . . 15
2.4. BSSID to WLAN ID Mapping . . . . . . . . . . . . . . . . 15 2.4. Group Key Refresh . . . . . . . . . . . . . . . . . . . . 16
2.5. Quality of Service for IEEE 802.11 MAC Management 2.5. BSSID to WLAN ID Mapping . . . . . . . . . . . . . . . . 17
Messages . . . . . . . . . . . . . . . . . . . . . . . . 15 2.6. CAPWAP Data Channel QoS Behavior . . . . . . . . . . . . 17
2.6. Run State Operation . . . . . . . . . . . . . . . . . . . 16 2.6.1. IEEE 802.11 Data Frames . . . . . . . . . . . . . . . 17
3. IEEE 802.11 Specific CAPWAP Control Messages . . . . . . . . . 17 2.6.2. IEEE 802.11 MAC Management Messages . . . . . . . . . 20
3.1. IEEE 802.11 WLAN Configuration Request . . . . . . . . . 17 2.7. Run State Operation . . . . . . . . . . . . . . . . . . . 21
3.2. IEEE 802.11 WLAN Configuration Response . . . . . . . . . 18 3. IEEE 802.11 Specific CAPWAP Control Messages . . . . . . . . . 22
4. CAPWAP Data Message Bindings . . . . . . . . . . . . . . . . . 19 3.1. IEEE 802.11 WLAN Configuration Request . . . . . . . . . 22
5. CAPWAP Control Message bindings . . . . . . . . . . . . . . . 21 3.2. IEEE 802.11 WLAN Configuration Response . . . . . . . . . 23
5.1. Discovery Request Message . . . . . . . . . . . . . . . . 21 4. CAPWAP Data Message Bindings . . . . . . . . . . . . . . . . . 24
5.2. Discovery Response Message . . . . . . . . . . . . . . . 21 5. CAPWAP Control Message bindings . . . . . . . . . . . . . . . 26
5.3. Primary Discovery Request Message . . . . . . . . . . . . 21 5.1. Discovery Request Message . . . . . . . . . . . . . . . . 26
5.4. Primary Discovery Response Message . . . . . . . . . . . 21 5.2. Discovery Response Message . . . . . . . . . . . . . . . 26
5.5. Join Request Message . . . . . . . . . . . . . . . . . . 21 5.3. Primary Discovery Request Message . . . . . . . . . . . . 26
5.6. Join Response Message . . . . . . . . . . . . . . . . . . 22 5.4. Primary Discovery Response Message . . . . . . . . . . . 26
5.7. Configuration Status Message . . . . . . . . . . . . . . 22 5.5. Join Request Message . . . . . . . . . . . . . . . . . . 26
5.8. Configuration Status Response Message . . . . . . . . . . 22 5.6. Join Response Message . . . . . . . . . . . . . . . . . . 27
5.9. Configuration Update Request Message . . . . . . . . . . 23 5.7. Configuration Status Message . . . . . . . . . . . . . . 27
5.10. Station Configuration Request . . . . . . . . . . . . . . 24 5.8. Configuration Status Response Message . . . . . . . . . . 27
5.11. Change State Event Request . . . . . . . . . . . . . . . 24 5.9. Configuration Update Request Message . . . . . . . . . . 28
5.12. WTP Event Request . . . . . . . . . . . . . . . . . . . . 24 5.10. Station Configuration Request . . . . . . . . . . . . . . 29
6. IEEE 802.11 Message Element Definitions . . . . . . . . . . . 25 5.11. Change State Event Request . . . . . . . . . . . . . . . 29
6.1. IEEE 802.11 Add WLAN . . . . . . . . . . . . . . . . . . 25 5.12. WTP Event Request . . . . . . . . . . . . . . . . . . . . 29
6.2. IEEE 802.11 Antenna . . . . . . . . . . . . . . . . . . . 30 6. IEEE 802.11 Message Element Definitions . . . . . . . . . . . 30
6.3. IEEE 802.11 Assigned WTP BSSID . . . . . . . . . . . . . 32 6.1. IEEE 802.11 Add WLAN . . . . . . . . . . . . . . . . . . 30
6.4. IEEE 802.11 Delete WLAN . . . . . . . . . . . . . . . . . 32 6.2. IEEE 802.11 Antenna . . . . . . . . . . . . . . . . . . . 36
6.5. IEEE 802.11 Direct Sequence Control . . . . . . . . . . . 33 6.3. IEEE 802.11 Assigned WTP BSSID . . . . . . . . . . . . . 37
6.6. IEEE 802.11 Information Element . . . . . . . . . . . . . 34 6.4. IEEE 802.11 Delete WLAN . . . . . . . . . . . . . . . . . 38
6.7. IEEE 802.11 MAC Operation . . . . . . . . . . . . . . . . 35 6.5. IEEE 802.11 Direct Sequence Control . . . . . . . . . . . 38
6.8. IEEE 802.11 MIC Countermeasures . . . . . . . . . . . . . 36 6.6. IEEE 802.11 Information Element . . . . . . . . . . . . . 39
6.9. IEEE 802.11 Multi-Domain Capability . . . . . . . . . . . 37 6.7. IEEE 802.11 MAC Operation . . . . . . . . . . . . . . . . 40
6.10. IEEE 802.11 OFDM Control . . . . . . . . . . . . . . . . 38 6.8. IEEE 802.11 MIC Countermeasures . . . . . . . . . . . . . 42
6.11. IEEE 802.11 Rate Set . . . . . . . . . . . . . . . . . . 39 6.9. IEEE 802.11 Multi-Domain Capability . . . . . . . . . . . 43
6.12. IEEE 802.11 RSNA Error Report From Station . . . . . . . 40 6.10. IEEE 802.11 OFDM Control . . . . . . . . . . . . . . . . 44
6.13. IEEE 802.11 Station . . . . . . . . . . . . . . . . . . . 42 6.11. IEEE 802.11 Rate Set . . . . . . . . . . . . . . . . . . 45
6.14. IEEE 802.11 Station QoS Profile . . . . . . . . . . . . . 43 6.12. IEEE 802.11 RSNA Error Report From Station . . . . . . . 45
6.15. IEEE 802.11 Station Session Key . . . . . . . . . . . . . 43 6.13. IEEE 802.11 Station . . . . . . . . . . . . . . . . . . . 47
6.16. IEEE 802.11 Statistics . . . . . . . . . . . . . . . . . 45 6.14. IEEE 802.11 Station QoS Profile . . . . . . . . . . . . . 48
6.17. IEEE 802.11 Supported Rates . . . . . . . . . . . . . . . 49 6.15. IEEE 802.11 Station Session Key . . . . . . . . . . . . . 49
6.18. IEEE 802.11 Tx Power . . . . . . . . . . . . . . . . . . 49 6.16. IEEE 802.11 Statistics . . . . . . . . . . . . . . . . . 51
6.19. IEEE 802.11 Tx Power Level . . . . . . . . . . . . . . . 50 6.17. IEEE 802.11 Supported Rates . . . . . . . . . . . . . . . 55
6.20. IEEE 802.11 Update Station QoS . . . . . . . . . . . . . 50 6.18. IEEE 802.11 Tx Power . . . . . . . . . . . . . . . . . . 55
6.21. IEEE 802.11 Update WLAN . . . . . . . . . . . . . . . . . 51 6.19. IEEE 802.11 Tx Power Level . . . . . . . . . . . . . . . 56
6.22. IEEE 802.11 WTP Quality of Service . . . . . . . . . . . 53 6.20. IEEE 802.11 Update Station QoS . . . . . . . . . . . . . 56
6.23. IEEE 802.11 WTP Radio Configuration . . . . . . . . . . . 54 6.21. IEEE 802.11 Update WLAN . . . . . . . . . . . . . . . . . 58
6.24. IEEE 802.11 WTP Radio Fail Alarm Indication . . . . . . . 56 6.22. IEEE 802.11 WTP Quality of Service . . . . . . . . . . . 60
6.25. IEEE 802.11 WTP Radio Information . . . . . . . . . . . . 57 6.23. IEEE 802.11 WTP Radio Configuration . . . . . . . . . . . 62
7. IEEE 802.11 Binding WTP Saved Variables . . . . . . . . . . . 59 6.24. IEEE 802.11 WTP Radio Fail Alarm Indication . . . . . . . 64
7.1. IEEE80211AntennaInfo . . . . . . . . . . . . . . . . . . 59 6.25. IEEE 802.11 WTP Radio Information . . . . . . . . . . . . 65
7.2. IEEE80211DSControl . . . . . . . . . . . . . . . . . . . 59 7. IEEE 802.11 Binding WTP Saved Variables . . . . . . . . . . . 67
7.3. IEEE80211MACOperation . . . . . . . . . . . . . . . . . . 59 7.1. IEEE80211AntennaInfo . . . . . . . . . . . . . . . . . . 67
7.4. IEEE80211OFDMControl . . . . . . . . . . . . . . . . . . 59 7.2. IEEE80211DSControl . . . . . . . . . . . . . . . . . . . 67
7.5. IEEE80211Rateset . . . . . . . . . . . . . . . . . . . . 59 7.3. IEEE80211MACOperation . . . . . . . . . . . . . . . . . . 67
7.6. IEEE80211TxPower . . . . . . . . . . . . . . . . . . . . 59 7.4. IEEE80211OFDMControl . . . . . . . . . . . . . . . . . . 67
7.7. IEEE80211QoS . . . . . . . . . . . . . . . . . . . . . . 59 7.5. IEEE80211Rateset . . . . . . . . . . . . . . . . . . . . 67
7.8. IEEE80211RadioConfig . . . . . . . . . . . . . . . . . . 59 7.6. IEEE80211TxPower . . . . . . . . . . . . . . . . . . . . 67
8. Technology Specific Message Element Values . . . . . . . . . . 60 7.7. IEEE80211QoS . . . . . . . . . . . . . . . . . . . . . . 67
7.8. IEEE80211RadioConfig . . . . . . . . . . . . . . . . . . 67
8. Technology Specific Message Element Values . . . . . . . . . . 68
8.1. WTP Descriptor Message Element, Encryption 8.1. WTP Descriptor Message Element, Encryption
Capabilities Field: . . . . . . . . . . . . . . . . . . . 60 Capabilities Field: . . . . . . . . . . . . . . . . . . . 68
9. Security Considerations . . . . . . . . . . . . . . . . . . . 61 9. Security Considerations . . . . . . . . . . . . . . . . . . . 69
9.1. IEEE 802.11 Security . . . . . . . . . . . . . . . . . . 61 9.1. IEEE 802.11 Security . . . . . . . . . . . . . . . . . . 69
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 63 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 71
10.1. CAPWAP Message Types . . . . . . . . . . . . . . . . . . 63 10.1. CAPWAP Wireless Binding Identifier . . . . . . . . . . . 71
10.2. CAPWAP Control Message Type . . . . . . . . . . . . . . . 63 10.2. CAPWAP IEEE 802.11 Message Types . . . . . . . . . . . . 71
10.3. IEEE 802.11 Key Status . . . . . . . . . . . . . . . . . 63 10.3. CAPWAP Message Element Type . . . . . . . . . . . . . . . 71
10.4. IEEE 802.11 QoS . . . . . . . . . . . . . . . . . . . . . 63 10.4. IEEE 802.11 Key Status . . . . . . . . . . . . . . . . . 71
10.5. IEEE 802.11 Auth Type . . . . . . . . . . . . . . . . . . 63 10.5. IEEE 802.11 QoS . . . . . . . . . . . . . . . . . . . . . 72
10.6. IEEE 802.11 Antenna Combiner . . . . . . . . . . . . . . 63 10.6. IEEE 802.11 Auth Type . . . . . . . . . . . . . . . . . . 72
10.7. IEEE 802.11 Antenna Selection . . . . . . . . . . . . . . 63 10.7. IEEE 802.11 Antenna Combiner . . . . . . . . . . . . . . 72
10.8. IEEE 802.11 Session Key Flags . . . . . . . . . . . . . . 64 10.8. IEEE 802.11 Antenna Selection . . . . . . . . . . . . . . 72
10.9. IEEE 802.11 Tag Packets . . . . . . . . . . . . . . . . . 64 10.9. IEEE 802.11 Session Key Flags . . . . . . . . . . . . . . 73
10.10. IEEE 802.11 WTP Radio Fail . . . . . . . . . . . . . . . 64 10.10. IEEE 802.11 Tagging Policy . . . . . . . . . . . . . . . 73
10.11. IEEE 802.11 WTP Radio Type . . . . . . . . . . . . . . . 64 10.11. IEEE 802.11 WTP Radio Fail . . . . . . . . . . . . . . . 73
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 65 10.12. IEEE 802.11 WTP Radio Type . . . . . . . . . . . . . . . 73
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 66 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 75
12.1. Normative References . . . . . . . . . . . . . . . . . . 66 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 76
12.2. Informational References . . . . . . . . . . . . . . . . 67 12.1. Normative References . . . . . . . . . . . . . . . . . . 76
Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 68 12.2. Informational References . . . . . . . . . . . . . . . . 77
Intellectual Property and Copyright Statements . . . . . . . . . . 69 Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 78
Intellectual Property and Copyright Statements . . . . . . . . . . 79
1. Introduction 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 This specification defines the Control And Provisioning of Wireless
Access Points (CAPWAP) Protocol Binding Specification for use with Access Points (CAPWAP) Protocol Binding Specification for use with
the IEEE 802.11 Wireless Local Area Network protocol. The CAPWAP the IEEE 802.11 Wireless Local Area Network protocol. Use of CAPWAP
Protocol Specification is defined separately control message fields, new control messages and message elements are
[I-D.ietf-capwap-protocol-specification]. Use of CAPWAP control
message fields, new control messages and message elements are
defined. The minimum required definitions for a binding-specific defined. The minimum required definitions for a binding-specific
Statistics message element, Station message element, and WTP Radio Statistics message element, Station message element, and WTP Radio
Information message element are included. 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 1.1. Goals
The goals for this CAPWAP protocol binding are listed below: 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 1. To centralize the authentication and policy enforcement functions
for an IEEE 802.11 wireless network. The AC may also provide for an IEEE 802.11 wireless network. The AC may also provide
centralized bridging, forwarding, and encryption of user traffic. centralized bridging, forwarding, and encryption of user traffic.
Centralization of these functions will enable reduced cost and Centralization of these functions will enable reduced cost and
higher efficiency by applying the capabilities of network higher efficiency by applying the capabilities of network
processing silicon to the wireless network, as in wired LANs. processing silicon to the wireless network, as in wired LANs.
2. To enable shifting of the higher level protocol processing from 2. To enable shifting of the higher level protocol processing from
the WTP. This leaves the time-critical applications of wireless the WTP. This leaves the time-critical applications of wireless
skipping to change at page 7, line 13 skipping to change at page 8, line 13
receive station traffic for wireless access networks. receive station traffic for wireless access networks.
2. IEEE 802.11 Binding 2. IEEE 802.11 Binding
This section describes use of the CAPWAP protocol with the IEEE This section describes use of the CAPWAP protocol with the IEEE
802.11 Wireless Local Area Network protocol, including Local and 802.11 Wireless Local Area Network protocol, including Local and
Split MAC operation, Group Key Refresh, Basic Service Set Split MAC operation, Group Key Refresh, Basic Service Set
Identification (BSSID) to WLAN Mapping, IEEE 802.11 MAC management Identification (BSSID) to WLAN Mapping, IEEE 802.11 MAC management
frame Quality of Service tagging and Run State operation. frame Quality of Service tagging and Run State operation.
2.1. Split MAC and Local MAC Functionality 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 The CAPWAP protocol, when used with IEEE 802.11 devices, requires
specific behavior from the WTP and the AC to support the required specific behavior from the WTP and the AC to support the required
IEEE 802.11 protocol functions. IEEE 802.11 protocol functions.
For both the Split and Local MAC approaches, the CAPWAP functions, as For both the Split and Local MAC approaches, the CAPWAP functions, as
defined in the taxonomy specification [RFC4118], reside in the AC. defined in the taxonomy specification [RFC4118], reside in the AC.
To provide system component interoperability, the WTP and AC MUST 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 WTP. The WTP and AC MAY
support 802.11 encryption/decryption at the AC. support 802.11 encryption/decryption at the AC.
2.1.1. Split MAC 2.2.1. Split MAC
This section shows the division of labor between the WTP and the AC This section shows the division of labor between the WTP and the AC
in a Split MAC architecture. Figure 1 shows the separation of in a Split MAC architecture. Figure 1 shows the separation of
functionality between CAPWAP components. functionality between CAPWAP components.
Function Location Function Location
Distribution Service AC Distribution Service AC
Integration Service AC Integration Service AC
Beacon Generation WTP Beacon Generation WTP
Probe Response Generation WTP Probe Response Generation WTP
skipping to change at page 11, line 14 skipping to change at page 12, line 41
When 802.11 encryption/decryption is performed at the AC, the When 802.11 encryption/decryption is performed at the AC, the
MoreFrag bit is populated at the AC. The Pwr Mgmt bit is not 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 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 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 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 WTP is responsible for validating, and stripping the FCS field. Upon
receiving data frames from the AC, the WTP is responsible for adding receiving data frames from the AC, the WTP is responsible for adding
the FCS field, and populating the field as described in the FCS field, and populating the field as described in
[IEEE.802-11.2007]. [IEEE.802-11.2007].
2.1.2. Local MAC 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 This section shows the division of labor between the WTP and the AC
in a Local MAC architecture. Figure 4 shows the separation of in a Local MAC architecture. Figure 4 shows the separation of
functionality among CAPWAP components. functionality among CAPWAP components.
Function Location Function Location
Distribution Service WTP/AC Distribution Service WTP/AC
Integration Service WTP Integration Service WTP
Beacon Generation WTP Beacon Generation WTP
Probe Response Generation WTP Probe Response Generation WTP
skipping to change at page 13, line 40 skipping to change at page 15, line 27
user's data frames are to be bridged. user's data frames are to be bridged.
o The WTP forwards any IEEE 802.11 Management Action frames received o The WTP forwards any IEEE 802.11 Management Action frames received
to the AC. to the AC.
o The WTP MAY locally bridge client data frames (and provide the o The WTP MAY locally bridge client data frames (and provide the
necessary encryption and decryption services). The WTP MAY also necessary encryption and decryption services). The WTP MAY also
tunnel client data frames to the AC, using 802.3 frame tunnel mode tunnel client data frames to the AC, using 802.3 frame tunnel mode
or 802.11 frame tunnel mode. or 802.11 frame tunnel mode.
2.2. Roaming Behavior 2.3. Roaming Behavior
This section expands upon the examples provided in the previous This section expands upon the examples provided in the previous
section, and describes how the CAPWAP control protocol is used to section, and describes how the CAPWAP control protocol is used to
provide secure roaming. provide secure roaming.
Once a client has successfully associated with the network in a Once a client has successfully associated with the network in a
secure fashion, it is likely to attempt to roam to another WTP. secure fashion, it is likely to attempt to roam to another WTP.
Figure 6 shows an example of a currently associated station moving 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 from its "Old WTP" to a "New WTP". The figure is valid for multiple
different security policies, including IEEE 802.1X and Wireless different security policies, including IEEE 802.1X and Wireless
skipping to change at page 14, line 28 skipping to change at page 16, line 27
Station Configuration Request Station Configuration Request
[Delete Station] [Delete Station]
<----------------------------------> <---------------------------------->
Station Configuration Request Station Configuration Request
[Add Station (AES-CCMP, [Add Station (AES-CCMP,
PTK=x)] PTK=x)]
<----------------> <---------------->
Figure 6: Client Roaming Example Figure 6: Client Roaming Example
2.3. Group Key Refresh 2.4. Group Key Refresh
Periodically, the Group Key (GTK)for the BSS needs to be updated. 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 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 in the BSS. While the AC is updating the GTK, each L2 broadcast
frame transmitted to the BSS needs to be duplicated and transmitted frame transmitted to the BSS needs to be duplicated and transmitted
using both the current GTK and the new GTK. Once the GTK update using both the current GTK and the new GTK. Once the GTK update
process has completed, broadcast frames transmitted to the BSS will process has completed, broadcast frames transmitted to the BSS will
be encrypted using the new GTK. be encrypted using the new GTK.
In the case of Split MAC, the AC needs to duplicate all broadcast In the case of Split MAC, the AC needs to duplicate all broadcast
skipping to change at page 15, line 27 skipping to change at page 17, line 25
802.1X EAPoL (GTK Message 1) 802.1X EAPoL (GTK Message 1)
<-------------( - )------------------------------------------- <-------------( - )-------------------------------------------
802.1X EAPoL (GTK Message 2) 802.1X EAPoL (GTK Message 2)
-------------( - )-------------------------------------------> -------------( - )------------------------------------------->
IEEE 802.11 WLAN Configuration Request [ Update IEEE 802.11 WLAN Configuration Request [ Update
WLAN (GTK Index, GTK Complete) ] WLAN (GTK Index, GTK Complete) ]
<-------------------------------------------- <--------------------------------------------
Figure 7: Group Key Update Procedure Figure 7: Group Key Update Procedure
2.4. BSSID to WLAN ID Mapping 2.5. BSSID to WLAN ID Mapping
The CAPWAP protocol binding enables the WTP to assign BSSIDs upon The CAPWAP protocol binding enables the WTP to assign BSSIDs upon
creation of a WLAN (see Section 6.1). While manufacturers are free creation of a WLAN (see Section 6.1). While manufacturers are free
to assign BSSIDs using any arbitrary mechanism, it is advised that to assign BSSIDs using any arbitrary mechanism, it is advised that
where possible the BSSIDs are assigned as a contiguous block. where possible the BSSIDs are assigned as a contiguous block.
When assigned as a block, implementations can still assign any of the 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 available BSSIDs to any WLAN. One possible method is for the WTP to
assign the address using the following algorithm: base BSSID address assign the address using the following algorithm: base BSSID address
+ WLAN ID. + WLAN ID.
The WTP communicates the maximum number of BSSIDs that it supports The WTP communicates the maximum number of BSSIDs that it supports
during configuration via the IEEE 802.11 WTP WLAN Radio Configuration during configuration via the IEEE 802.11 WTP WLAN Radio Configuration
message element (see Section 6.23). message element (see Section 6.23).
2.5. Quality of Service for IEEE 802.11 MAC Management Messages 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,
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
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 IP header also includes the Explicit Congestion Notification
(ECN) bits [RFC3168]. When packets received from stations are
encapsulated by the WTP, the ECN bits are set to zero (0) in the
outer header. The WTP does not modify the ECN bits in the original
station's packet header. This mode of operation is detailed as the
"limited functionality option" in [RFC3168].
2.6.2. IEEE 802.11 MAC Management Messages
It is recommended that IEEE 802.11 MAC Management frames be sent by 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, both the AC and the WTP with appropriate Quality of Service values,
listed below, to ensure that congestion in the network minimizes listed below, to ensure that congestion in the network minimizes
occurrences of packet loss. 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 SHOULD be used for all IEEE 802.1p: The precedence value of 7 (decimal) SHOULD be used for all
802.11 MAC management frames, except for Probe Requests which IEEE 802.11 MAC management frames, except for Probe Requests which
SHOULD use 4. SHOULD use 4.
DSCP: The DSCP tag value of 46 SHOULD be used for all IEEE 802.11 DSCP: All IEEE 802.11 MAC management frames SHOULD use the
MAC management frames, except for Probe Requests which SHOULD use Expedited Forwarding per-hop behavior (see [RFC2598]), while IEEE
34. 802.11 Probe Requests should use the Low Drop Assured Forwarding
per-hop behavior (see [RFC2598]).
2.6. Run State Operation 2.7. Run State Operation
The Run state is the normal state of operation for the CAPWAP The Run state is the normal state of operation for the CAPWAP
protocol in both the WTP and the AC. protocol in both the WTP and the AC.
When the WTP receives a WLAN Configuration Request message (see When the WTP receives a WLAN Configuration Request message (see
Section 3.1), it MUST respond with a WLAN Configuration Response Section 3.1), it MUST respond with a WLAN Configuration Response
message (see Section 3.2) and it remains in the Run state. message (see Section 3.2) and it remains in the Run state.
When the AC sends a WLAN Configuration Request message (see When the AC sends a WLAN Configuration Request message (see
Section 3.1) or receives the corresponding WLAN Configuration Section 3.1) or receives the corresponding WLAN Configuration
skipping to change at page 17, line 21 skipping to change at page 22, line 21
CAPWAP Control message definitions and the derivation of the Message CAPWAP Control message definitions and the derivation of the Message
Type value from the IANA Enterprise number. Type value from the IANA Enterprise number.
The valid message types for IEEE 802.11 specific control messages are The valid message types for IEEE 802.11 specific control messages are
listed below. The IANA Enterprise number used with these messages is listed below. The IANA Enterprise number used with these messages is
13277. 13277.
CAPWAP Control Message Message Type CAPWAP Control Message Message Type
Value Value
IEEE 802.11 WLAN Configuration Request 3398912 IEEE 802.11 WLAN Configuration Request 3398913
IEEE 802.11 WLAN Configuration Response 3398913 IEEE 802.11 WLAN Configuration Response 3398914
3.1. IEEE 802.11 WLAN Configuration Request 3.1. IEEE 802.11 WLAN Configuration Request
The IEEE 802.11 WLAN Configuration Request is sent by the AC to the 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 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. 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 The IEEE 802.11 WLAN Configuration Request is sent as a result of
either some manual administrative process (e.g., deleting a WLAN), or either some manual administrative process (e.g., deleting a WLAN), or
automatically to create a WLAN on a WTP. When sent automatically to automatically to create a WLAN on a WTP. When sent automatically to
create a WLAN, this control message is sent after the CAPWAP create a WLAN, this control message is sent after the CAPWAP
Configuration Update Request message (see Section 8.4 in Configuration Update Response message (see Section 8.5 in
[I-D.ietf-capwap-protocol-specification]) has been received by the [I-D.ietf-capwap-protocol-specification]) has been received by the
WTP. AC.
Upon receiving this control message, the WTP will modify the Upon receiving this control message, the WTP will modify the
necessary services, and transmit an IEEE 802.11 WLAN Configuration necessary services, and transmit an IEEE 802.11 WLAN Configuration
Response. Response.
A WTP MAY provide service for more than one WLAN, therefore every A WTP MAY provide service for more than one WLAN, therefore every
WLAN is identified through a numerical index. For instance, a WTP WLAN is identified through a numerical index. For instance, a WTP
that is capable of supporting up to 16 Service Set Identifiers that is capable of supporting up to 16 Service Set Identifiers
(SSIDs), could accept up to 16 IEEE 802.11 WLAN Configuration Request (SSIDs), could accept up to 16 IEEE 802.11 WLAN Configuration Request
messages that include the Add WLAN message element. messages that include the Add WLAN message element.
skipping to change at page 18, line 34 skipping to change at page 23, line 34
The IEEE 802.11 WLAN Configuration Response message is sent by the 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 WTP to the AC. It is used to acknowledge receipt of an IEEE 802.11
WLAN Configuration Request message, and to indicate that the WLAN Configuration Request message, and to indicate that the
requested configuration was successfully applied, or that an error requested configuration was successfully applied, or that an error
related to the processing of the IEEE 802.11 WLAN Configuration related to the processing of the IEEE 802.11 WLAN Configuration
Request message occurred on the WTP. Request message occurred on the WTP.
The following message element MUST be included in the IEEE 802.11 The following message element MUST be included in the IEEE 802.11
WLAN Configuration Response message. WLAN Configuration Response message.
o Result Code, see Section 4.6.35 in o Result Code, see Section 4.6.34 in
[I-D.ietf-capwap-protocol-specification] [I-D.ietf-capwap-protocol-specification]
The following message element MAY be included in the IEEE 802.11 WLAN The following message element MAY be included in the IEEE 802.11 WLAN
Configuration Response message. Configuration Response message.
o IEEE 802.11 Assigned WTP BSSID, see Section 6.3 o IEEE 802.11 Assigned WTP BSSID, see Section 6.3
o Vendor Specific Payload, see o Vendor Specific Payload, see
[I-D.ietf-capwap-protocol-specification] [I-D.ietf-capwap-protocol-specification]
skipping to change at page 24, line 15 skipping to change at page 29, line 15
5.10. Station Configuration Request 5.10. Station Configuration Request
The following IEEE 802.11 specific message elements MAY included in The following IEEE 802.11 specific message elements MAY included in
the CAPWAP Station Configuration Request message. More than one of the CAPWAP Station Configuration Request message. More than one of
each message element listed MAY be included. each message element listed MAY be included.
o IEEE 802.11 Station, see Section 6.13 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 Session Key, see Section 6.15
o Station QoS Profile, see Section 6.14 o IEEE 802.11 Station QoS Profile, see Section 6.14
5.11. Change State Event Request 5.11. Change State Event Request
The following IEEE 802.11 specific message elements MAY included in The following IEEE 802.11 specific message elements MAY included in
the CAPWAP Station Configuration Request message. the CAPWAP Station Configuration Request message.
o IEEE 802.11 WTP Radio Fail Alarm Indication, see Section 6.24 o IEEE 802.11 WTP Radio Fail Alarm Indication, see Section 6.24
5.12. WTP Event Request 5.12. WTP Event Request
skipping to change at page 25, line 47 skipping to change at page 30, line 47
Figure 8: IEEE 802.11 Binding Message Elements Figure 8: IEEE 802.11 Binding Message Elements
6.1. IEEE 802.11 Add WLAN 6.1. IEEE 802.11 Add WLAN
The IEEE 802.11 Add WLAN message element is used by the AC to define 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 a WLAN on the WTP. The inclusion of this message element MUST also
include IEEE 802.11 Information Element message elements, containing include IEEE 802.11 Information Element message elements, containing
the following IEEE 802.11 IEs: the following IEEE 802.11 IEs:
Power Capability information element Power Constraint information element
WPA information element
RSN information element
EDCA Parameter Set information element EDCA Parameter Set information element
QoS Capability information element QoS Capability information element
WMM information element WPA information element [WPA]
If present, the RSN information element is sent with the IEEE 802.11 RSN information element
Add WLAN message element to instruct the WTP on the usage of the Key
field. 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 An AC MAY include additional information elements as desired. The
message element uses the following format: message element uses the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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 | | Radio ID | WLAN ID | Capability |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Index | Key Status | Key Length | | Key Index | Key Status | Key Length |
skipping to change at page 26, line 38 skipping to change at page 32, line 4
| Key... | | Key... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group TSC | | Group TSC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group TSC | QoS | Auth Type | | Group TSC | QoS | Auth Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Mode | Tunnel Mode | Suppress SSID | SSID ... | MAC Mode | Tunnel Mode | Suppress SSID | SSID ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 1024 for IEEE 802.11 Add WLAN Type: 1024 for IEEE 802.11 Add WLAN
Length: >= 52 Length: >= 52
Radio ID: An 8-bit value representing the radio. Radio ID: An 8-bit value representing the radio.
WLAN ID: An 8-bit value specifying the WLAN Identifier. WLAN ID: An 8-bit value specifying the WLAN Identifier. The value
MUST be between one (1) and 15.
Capability: A 16-bit value containing the capability information Capability: A 16-bit value containing the capability information
field to be advertised by the WTP in the Probe Request and Beacon field to be advertised by the WTP in the Probe Request and Beacon
frames. Each bit of the Capability field represents a different frames. Each bit of the Capability field represents a different
WTP capability, which are described in detail in WTP capability, which are described in detail in
[IEEE.802-11.2007]. The format of the field is: [IEEE.802-11.2007]. The format of the field is:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 28, line 34 skipping to change at page 33, line 47
in [IEEE.802-11.2007]. in [IEEE.802-11.2007].
L (Immediate Block ACK): The AC sets the Delayed Block ACK L (Immediate Block ACK): The AC sets the Delayed Block ACK
subfield according to the value of the subfield according to the value of the
dot11ImmediateBlockAckOptionImplemented MIB variable, as dot11ImmediateBlockAckOptionImplemented MIB variable, as
defined in [IEEE.802-11.2007]. defined in [IEEE.802-11.2007].
Key-Index: The Key Index associated with the key. Key-Index: The Key Index associated with the key.
Key Status: A 1 byte value that specifies the state and usage of Key Status: A 1 byte value that specifies the state and usage of
the key that has been included. The following values describe the the key that has been included. Note this field is ignored if the
key usage and its status: Key Length field is set to zero (0). The following values
describe the key usage and its status:
0 - A value of zero, with the inclusion of the RSN Information 0 - A value of zero, with the inclusion of the RSN Information
Element means that the WLAN uses per-station encryption keys, Element means that the WLAN uses per-station encryption keys,
and therefore the key in the 'Key' field is only used for and therefore the key in the 'Key' field is only used for
multicast traffic. multicast traffic.
1 - When set to one, the WLAN employs a shared Wired Equivalent 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 Privacy (WEP) key, also known as a static WEP key, and uses the
encryption key for both unicast and multicast traffic for all encryption key for both unicast and multicast traffic for all
stations. stations.
skipping to change at page 29, line 12 skipping to change at page 34, line 26
GTK with the STA's in the BSS. It is only valid when IEEE 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. 802.11 is enabled as the security policy for the BSS.
3 - The value of 3 indicates that the AC has completed rekeying 3 - The value of 3 indicates that the AC has completed rekeying
the GTK and broadcast packets no longer need to be duplicated the GTK and broadcast packets no longer need to be duplicated
and transmitted with both GTK's. and transmitted with both GTK's.
Key Length: A 16-bit value representing the length of the Key Key Length: A 16-bit value representing the length of the Key
field. field.
Key: A 32 byte Session Key to use to provide data privacy. For Key: A Session Key, whose length is known via the key length field,
encryption schemes that employ a separate encryption key for used to provide data privacy. For encryption schemes that employ
unicast and multicast traffic, the key included here only applies a separate encryption key for unicast and multicast traffic, the
to multicast frames, and the cipher suite is specified in an key included here only applies to multicast frames, and the cipher
accompanied RSN Information Element. In these scenarios, the key suite is specified in an accompanied RSN Information Element. In
and cipher information is communicated via the Add Station message these scenarios, the key and cipher information is communicated
element, see Section 4.6.8 in via the Add Station message element, see Section 4.6.8 in
[I-D.ietf-capwap-protocol-specification] and the IEEE 802.11 [I-D.ietf-capwap-protocol-specification] and the IEEE 802.11
Station Session Key message element, see Section 6.15. Station Session Key message element, see Section 6.15.
Group TSC A 48-bit value containing the Transmit Sequence Counter Group TSC A 48-bit value containing the Transmit Sequence Counter
for the updated group key. The WTP will set the TSC for for the updated group key. The WTP will set the TSC for
broadcast/multicast frames to this value for the updated group broadcast/multicast frames to this value for the updated group
key. key.
QOS: An 8-bit value specifying the default QOS policy for the WTP 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. to apply to network traffic received for a non-WMM enabled STA.
skipping to change at page 30, line 4 skipping to change at page 35, line 16
3 - Background 3 - Background
Auth Type: An 8-bit value specifying the supported authentication Auth Type: An 8-bit value specifying the supported authentication
type. type.
The following enumerated values are supported: The following enumerated values are supported:
0 - Open System 0 - Open System
1 - WEP Shared Key 1 - WEP Shared Key
MAC Mode: This field specifies whether the WTP should support the MAC Mode: This field specifies whether the WTP should support the
WLAN in Local or Split MAC modes. Note that the AC MUST NOT 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 request a mode of operation that was not advertised by the WTP
during the discovery process (see Section 4.6.46 in during the discovery process (see Section 4.6.43 in
[I-D.ietf-capwap-protocol-specification]). The following [I-D.ietf-capwap-protocol-specification]). The following
enumerated values are supported: enumerated values are supported:
0 - Local-MAC: Service for the WLAN is to be provided in Local 0 - Local-MAC: Service for the WLAN is to be provided in Local
MAC mode. MAC mode.
1 - Split-MAC: Service for the WLAN is to be provided in Split 1 - Split-MAC: Service for the WLAN is to be provided in Split
MAC mode. MAC mode.
Tunnel Mode: This field specifies the frame tunneling type to be Tunnel Mode: This field specifies the frame tunneling type to be
used for 802.11 data frames from all stations associated with the 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 WLAN. The AC MUST NOT request a mode of operation that was not
advertised by the WTP during the discovery process (see Section advertised by the WTP during the discovery process (see Section
4.6.43 in [I-D.ietf-capwap-protocol-specification]). IEEE 802.11 4.6.42 in [I-D.ietf-capwap-protocol-specification]). All IEEE
management frames SHALL be tunneled using 802.11 Tunnel mode. The 802.11 management frames MUST be tunneled using 802.11 Tunnel
following enumerated values are supported: mode. The following enumerated values are supported:
0 - Local Bridging: All user traffic is to be locally bridged. 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 1 - 802.3 Tunnel: All user traffic is to be tunneled to the AC
in 802.3 format (see Section 4.3 in in 802.3 format (see Section 4.4.2 in
[I-D.ietf-capwap-protocol-specification]). [I-D.ietf-capwap-protocol-specification]). Note that this
option MUST NOT be selected with Split-MAC mode.
2 - 802.11 Tunnel: All user traffic is to be tunneled to the AC 2 - 802.11 Tunnel: All user traffic is to be tunneled to the AC
in 802.11 format. in 802.11 format.
Supress SSID: A boolean indicating whether the SSID is to be Supress SSID: A boolean indicating whether the SSID is to be
advertised by the WTP. A value of zero suppresses the SSID in the 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 802.11 Beacon and Probe Response frames, while a value of one will
cause the WTP to populate the field. cause the WTP to populate the field.
SSID: The SSID attribute is the service set identifier that will be SSID: The SSID attribute is the service set identifier that will be
skipping to change at page 31, line 31 skipping to change at page 36, line 48
the IEEE 802.11 dot11DiversitySelectionRx MIB element, see the IEEE 802.11 dot11DiversitySelectionRx MIB element, see
[IEEE.802-11.2007]. The following enumerated values are [IEEE.802-11.2007]. The following enumerated values are
supported: supported:
0 - Disabled 0 - Disabled
1 - Enabled (may only be true if the antenna can be used as a 1 - Enabled (may only be true if the antenna can be used as a
receive antenna) receive antenna)
Combiner: An 8-bit value specifying the combiner selection. The Combiner: An 8-bit value specifying the combiner selection. The
following values are supported: following enumerated values are supported:
1 - Sectorized (Left) 1 - Sectorized (Left)
2 - Sectorized (Right) 2 - Sectorized (Right)
3 - Omni 3 - Omni
4 - Multiple Input/Multiple Output (MIMO) 4 - Multiple Input/Multiple Output (MIMO)
Antenna Count: An 8-bit value specifying the number of Antenna Antenna Count: An 8-bit value specifying the number of Antenna
skipping to change at page 32, line 32 skipping to change at page 38, line 4
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 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 | Radio ID | WLAN ID | BSSID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BSSID | | BSSID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 1026 for IEEE 802.11 Assigned WTP BSSID Type: 1026 for IEEE 802.11 Assigned WTP BSSID
Length: 8 Length: 8
Radio ID: An 8-bit value representing the radio. Radio ID: An 8-bit value representing the radio.
WLAN ID: An 8-bit value specifying the WLAN Identifier. WLAN ID: An 8-bit value specifying the WLAN Identifier. The value
MUST be between one (1) and 15.
BSSID: The BSSID assigned by the WTP for the WLAN created as a BSSID: The BSSID assigned by the WTP for the WLAN created as a
result of receiving an IEEE 802.11 Add WLAN. result of receiving an IEEE 802.11 Add WLAN.
6.4. IEEE 802.11 Delete WLAN 6.4. IEEE 802.11 Delete WLAN
The IEEE 802.11 Delete WLAN message element is used to inform the WTP 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 that a previously created WLAN is to be deleted, and contains the
following fields: following fields:
skipping to change at page 33, line 4 skipping to change at page 38, line 23
The IEEE 802.11 Delete WLAN message element is used to inform the WTP 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 that a previously created WLAN is to be deleted, and contains the
following fields: following fields:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | WLAN ID | | Radio ID | WLAN ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 1027 for IEEE 802.11 Delete WLAN Type: 1027 for IEEE 802.11 Delete WLAN
Length: 2 Length: 2
Radio ID: An 8-bit value representing the radio Radio ID: An 8-bit value representing the radio
WLAN ID: An 8-bit value specifying the WLAN Identifier WLAN ID: An 8-bit value specifying the WLAN Identifier. The value
MUST be between one (1) and 15.
6.5. IEEE 802.11 Direct Sequence Control 6.5. IEEE 802.11 Direct Sequence Control
The IEEE 802.11 Direct Sequence Control message element is a bi- The IEEE 802.11 Direct Sequence Control message element is a bi-
directional element. When sent by the WTP, it contains the current directional element. When sent by the WTP, it contains the current
state. When sent by the AC, the WTP MUST adhere to the values 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 provided. This element is only used for IEEE 802.11b radios. The
message element has the following fields. message element has the following fields.
0 1 2 3 0 1 2 3
skipping to change at page 34, line 31 skipping to change at page 40, line 4
The IEEE 802.11 Information Element is used to communicate any IE 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 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 IE as it would be included within an IEEE 802.11 MAC management
message. message.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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... | Radio ID | WLAN ID |B|P| Reserved |Info Element...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 1029 for IEEE 802.11 Information Element Type: 1029 for IEEE 802.11 Information Element
Length: >= 4 Length: >= 4
Radio ID: An 8-bit value representing the radio. Radio ID: An 8-bit value representing the radio.
WLAN ID: An 8-bit value specifying the WLAN Identifier. WLAN ID: An 8-bit value specifying the WLAN Identifier. The value
MUST be between one (1) and 15.
B: When set, the WTP is to include the information element in IEEE B: When set, the WTP is to include the information element in IEEE
802.11 Beacons associated with the WLAN. 802.11 Beacons associated with the WLAN.
P: When set, the WTP is to include the information element in Probe P: When set, the WTP is to include the information element in Probe
Responses associated with the WLAN. Responses associated with the WLAN.
Reserved: All implementations complying with this protocol MUST set Reserved: All implementations complying with this protocol MUST set
to zero any bits that are reserved in the version of the protocol to zero any bits that are reserved in the version of the protocol
supported by that implementation. Receivers MUST ignore all bits supported by that implementation. Receivers MUST ignore all bits
skipping to change at page 37, line 23 skipping to change at page 42, line 46
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 1031 for IEEE 802.11 MIC Countermeasures Type: 1031 for IEEE 802.11 MIC Countermeasures
Length: 8 Length: 8
Radio ID: The Radio Identifier, typically refers to some interface Radio ID: The Radio Identifier, typically refers to some interface
index on the WTP. index on the WTP.
WLAN ID: This 8-bit unsigned integer includes the WLAN Identifier, WLAN ID: This 8-bit unsigned integer includes the WLAN Identifier,
on which the MIC failure occurred. on which the MIC failure occurred. The value MUST be between one
(1) and 15.
MAC Address: The MAC Address of the station that caused the MIC MAC Address: The MAC Address of the station that caused the MIC
failure. failure.
6.9. IEEE 802.11 Multi-Domain Capability 6.9. IEEE 802.11 Multi-Domain Capability
The IEEE 802.11 Multi-Domain Capability message element is used by 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 the AC to inform the WTP of regulatory limits. The AC will transmit
one message element per frequency band to indicate the regulatory one message element per frequency band to indicate the regulatory
constraints in that domain. The message element contains the constraints in that domain. The message element contains the
skipping to change at page 38, line 17 skipping to change at page 43, line 42
supported by that implementation. Receivers MUST ignore all bits supported by that implementation. Receivers MUST ignore all bits
not defined for the version of the protocol they support. not defined for the version of the protocol they support.
First Channnel #: This attribute indicates the value of the lowest First Channnel #: This attribute indicates the value of the lowest
channel number in the sub-band for the associated domain country channel number in the sub-band for the associated domain country
string. The value of this field comes from the IEEE 802.11 string. The value of this field comes from the IEEE 802.11
dot11FirstChannelNumber MIB element (see [IEEE.802-11.2007]). dot11FirstChannelNumber MIB element (see [IEEE.802-11.2007]).
Number of Channels: This attribute indicates the value of the total Number of Channels: This attribute indicates the value of the total
number of channels allowed in the sub-band for the associated number of channels allowed in the sub-band for the associated
domain country string. The value of this field comes from the domain country string (see Section 6.23). The value of this field
IEEE 802.11 dot11NumberofChannels MIB element (see comes from the IEEE 802.11 dot11NumberofChannels MIB element (see
[IEEE.802-11.2007]). [IEEE.802-11.2007]).
Max Tx Power Level: This attribute indicates the maximum transmit Max Tx Power Level: This attribute indicates the maximum transmit
power, in dBm, allowed in the sub-band for the associated domain power, in dBm, allowed in the sub-band for the associated domain
country string. The value of this field comes from the IEEE country string (see Section 6.23). The value of this field comes
802.11 dot11MaximumTransmitPowerLevel MIB element (see from the IEEE 802.11 dot11MaximumTransmitPowerLevel MIB element
[IEEE.802-11.2007]). (see [IEEE.802-11.2007]).
6.10. IEEE 802.11 OFDM Control 6.10. IEEE 802.11 OFDM Control
The IEEE 802.11 Orthogonal Frequency Division Multiplexing (OFDM) The IEEE 802.11 Orthogonal Frequency Division Multiplexing (OFDM)
Control message element is a bi-directional element. When sent by 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 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 MUST adhere to the received values. This message element is only
used for 802.11a radios and contains the following fields: used for 802.11a radios and contains the following fields:
0 1 2 3 0 1 2 3
skipping to change at page 41, line 14 skipping to change at page 46, line 41
Length: 40 Length: 40
Client MAC Address: The Client MAC Address of the station. Client MAC Address: The Client MAC Address of the station.
BSSID: The BSSID on which the failures are being reported on. BSSID: The BSSID on which the failures are being reported on.
Radio ID: The Radio Identifier, typically refers to some interface Radio ID: The Radio Identifier, typically refers to some interface
index on the WTP index on the WTP
WLAN ID: The WLAN ID on which the RSNA failures are being reported. WLAN ID: The WLAN ID on which the RSNA failures are being reported.
The value MUST be between one (1) and 15.
Reserved: All implementations complying with this protocol MUST set Reserved: All implementations complying with this protocol MUST set
to zero any bits that are reserved in the version of the protocol to zero any bits that are reserved in the version of the protocol
supported by that implementation. Receivers MUST ignore all bits supported by that implementation. Receivers MUST ignore all bits
not defined for the version of the protocol they support. not defined for the version of the protocol they support.
TKIP ICV Errors: A 32-bit value representing the number of Temporal TKIP ICV Errors: A 32-bit value representing the number of Temporal
Key Integrity Protocol (TKIP) (as defined in [IEEE.802-11.2007]) Key Integrity Protocol (TKIP) (as defined in [IEEE.802-11.2007])
ICV errors encountered when decrypting packets from the station. ICV errors encountered when decrypting packets from the station.
The value of this field comes from the IEEE 802.11 The value of this field comes from the IEEE 802.11
skipping to change at page 42, line 49 skipping to change at page 48, line 36
Flags: All implementations complying with this protocol MUST set to Flags: All implementations complying with this protocol MUST set to
zero any bits that are reserved in the version of the protocol zero any bits that are reserved in the version of the protocol
supported by that implementation. Receivers MUST ignore all bits supported by that implementation. Receivers MUST ignore all bits
not defined for the version of the protocol they support. not defined for the version of the protocol they support.
MAC Address: The station's MAC Address MAC Address: The station's MAC Address
Capabilities: A 16-bit field containing the IEEE 802.11 Capabilities: A 16-bit field containing the IEEE 802.11
Capabilities Information Field to use with the station. Capabilities Information Field to use with the station.
WLAN ID: An 8-bit value specifying the WLAN Identifier WLAN ID: An 8-bit value specifying the WLAN Identifier. The value
MUST be between one (1) and 15.
Supported Rates: The variable length field containing the supported Supported Rates: The variable length field containing the supported
rates to be used with the station, as found in the IEEE 802.11 rates to be used with the station, as found in the IEEE 802.11
dot11OperationalRateSet MIB element (see [IEEE.802-11.2007]). dot11OperationalRateSet MIB element (see [IEEE.802-11.2007]).
This field MUST NOT exceed 126 octets and specifies the set of This field MUST NOT exceed 126 octets and specifies the set of
data rates at which the station may transmit data, where each data rates at which the station may transmit data, where each
octet represents a data rate. octet represents a data rate.
6.14. IEEE 802.11 Station QoS Profile 6.14. IEEE 802.11 Station QoS Profile
The IEEE 802.11 Station QoS Profile message element contains the The IEEE 802.11 Station QoS Profile message element contains the
maximum IEEE 802.11e priority tag that may be used by the station. maximum IEEE 802.11e priority tag that may be used by the station.
Any packet received that exceeds the value encoded in this message Any packet received that exceeds the value encoded in this message
element MUST either be dropped or tagged using the maximum value element MUST be tagged using the maximum value permitted by to the
permitted by to the user. The priority tag MUST be between zero (0) user. The priority tag MUST be between zero (0) and seven (7). This
and seven (7). This message element MUST NOT be present without the message element MUST NOT be present without the IEEE 802.11 Station
IEEE 802.11 Station (see Section 6.13) message element (see Section 6.13) message element.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address | | MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address | 802.1p Priority Tag | | MAC Address | 802.1p Priority Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 1037 for IEEE 802.11 Station QOS Profile Type: 1037 for IEEE 802.11 Station QOS Profile
skipping to change at page 43, line 48 skipping to change at page 49, line 34
this field are valid, while the remaining bits MUST be set to zero this field are valid, while the remaining bits MUST be set to zero
(0). (0).
6.15. IEEE 802.11 Station Session Key 6.15. IEEE 802.11 Station Session Key
The IEEE 802.11 Station Session Key message element is sent when the The IEEE 802.11 Station Session Key message element is sent when the
AC determines that encryption of a station must be performed in the AC determines that encryption of a station must be performed in the
WTP. This message element MUST NOT be present without the IEEE WTP. This message element MUST NOT be present without the IEEE
802.11 Station (see Section 6.13) message element, and MUST NOT be 802.11 Station (see Section 6.13) message element, and MUST NOT be
sent if the WTP had not specifically advertised support for the sent if the WTP had not specifically advertised support for the
requested encryption scheme. requested encryption scheme, through the WTP Descriptor Message
Element's Encryption Capabilities Field (see Section 8.1).
The RSN information element MUST sent along with the IEEE 802.11 The RSN information element MUST sent along with the IEEE 802.11
Station Session Key in order to instruct the WTP on the usage of the Station Session Key in order to instruct the WTP on the usage of the
Key field. The AKM field of the RSM information element is used by Key field. The WTP MUST observe the AKM field of the RSN information
the WTP to identify the authentication protocol. element in order to identify the authentication protocol to be
enforced with the station.
If cryptographic services are provided at the WTP, the WTP MUST
observe the algorithm dictated in the Pairwise Cipher Suite field of
the RSN information element sent by the AC. The RSN Information
Element included here is the one sent by the AC in the third message
of the 4-Way Key Handshake, which specifies which cipher is to be
applied to provide encryption and decryption services with the
station. The RSN Information Element is used to communicate any
supported algorithm, including WEP, TKIP and AES-CCMP. In the case
of static WEP keys, the RSN Information Element is still used to
indicate the cryptographic algorithm even though no key exchange
occurred.
If the IEEE 802.11 Station Session Key message element's AKM-Only bit If the IEEE 802.11 Station Session Key message element's AKM-Only bit
is set, the WTP MUST drop all IEEE 802.11 packets that are not part is set, the WTP MUST drop all IEEE 802.11 packets that are not part
of the Authentication and Key Management (AKM), such as EAP. Note of the Authentication and Key Management (AKM), such as EAP. Note
that AKM-Only is MAY be set while an encryption key is in force, that AKM-Only is MAY be set while an encryption key is in force,
requiring that the AKM packets be encrypted. Once the station has requiring that the AKM packets be encrypted. Once the station has
successfully completed authentication via the AKM, the AC MUST send a successfully completed authentication via the AKM, the AC MUST send a
new Add Station message element to remove the AKM-Only restriction, new Add Station message element to remove the AKM-Only restriction,
and optionally push the session key down to the WTP. and optionally push the session key down to the WTP.
skipping to change at page 45, line 11 skipping to change at page 51, line 11
for the station to be in the closed state. When set, the WTP for the station to be in the closed state. When set, the WTP
MUST drop any non-IEEE 802.1X packets it receives from the MUST drop any non-IEEE 802.1X packets it receives from the
station. station.
C: The one bit field is set by the AC to inform the WTP that C: The one bit field is set by the AC to inform the WTP that
encryption services will be provided by the AC. When set, the encryption services will be provided by the AC. When set, the
WTP SHOULD police frames received from stations to ensure that WTP SHOULD police frames received from stations to ensure that
are properly encrypted as specified in the RSN Information are properly encrypted as specified in the RSN Information
Element, but does not need to take specific cryptographic Element, but does not need to take specific cryptographic
action on the frame. Similarly, for transmitted frames, the action on the frame. Similarly, for transmitted frames, the
WTP only needs to forward already encrypted frames. WTP only needs to forward already encrypted frames. Since
packets received by the WTP will be encrypted, the WTP cannot
modify the contents of the packets, including modifying the
DSCP markings of the encapsulated packet. In this case, this
function would be the responsibility of the AC.
Pairwise TSC: The 6 byte Transmit Sequence Counter (TSC) field to Pairwise TSC: The 6 byte Transmit Sequence Counter (TSC) field to
use for unicast packets transmitted to the station. use for unicast packets transmitted to the station.
Pairwise RSC: The 6 byte Receive Sequence Counter (RSC) to use for Pairwise RSC: The 6 byte Receive Sequence Counter (RSC) to use for
unicast packets received from the station. unicast packets received from the station.
Key: The key the WTP is to use when encrypting traffic to/from the Key: The key the WTP is to use when encrypting traffic to/from the
station. For dynamically created keys, this is commonly known as station. For dynamically created keys, such as those used with
a Pairwise Transient Key (PTK). WPA and RSN, this is commonly known as a Pairwise Transient Key
(PTK). For static keys, such as those used in WEP, the Key field
contains the actual encryption key.
6.16. IEEE 802.11 Statistics 6.16. IEEE 802.11 Statistics
The IEEE 802.11 Statistics message element is sent by the WTP to The IEEE 802.11 Statistics message element is sent by the WTP to
transmit its current statistics, and contains the following fields. transmit its current statistics, and contains the following fields.
All of the fields in this message element are set to zero upon WTP All of the fields in this message element are set to zero upon WTP
initialization. The fields will roll over when they reach their initialization. The fields will roll over when they reach their
maximum value of 65535. Due to the nature of each counter maximum value of 4294967295. Due to the nature of each counter
representing different data points, the roll over event will vary representing different data points, the roll over event will vary
greatly across each field. Applications or human operators using greatly across each field. Applications or human operators using
these counters need to be aware about the minimal possible times these counters need to be aware about the minimal possible times
between rollover events in order to make sure that no consecutive between rollover events in order to make sure that no consecutive
rollover events are missed. rollover events are missed.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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 | | Radio ID | Reserved |
skipping to change at page 50, line 49 skipping to change at page 56, line 49
[IEEE.802-11.2007]). [IEEE.802-11.2007]).
Power Level: Each power level fields contains a supported power Power Level: Each power level fields contains a supported power
level, in mW. The value of this field comes from the level, in mW. The value of this field comes from the
corresponding IEEE 802.11 dot11TxPowerLevel[n] MIB element, see corresponding IEEE 802.11 dot11TxPowerLevel[n] MIB element, see
[IEEE.802-11.2007]. [IEEE.802-11.2007].
6.20. IEEE 802.11 Update Station QoS 6.20. IEEE 802.11 Update Station QoS
The IEEE 802.11 Update Station QoS message element is used to change The IEEE 802.11 Update Station QoS message element is used to change
the Quality of Service policy on the WTP for a given station. the Quality of Service policy on the WTP for a given station. The
QoS tags included in this message element are to be applied to
packets received at the WTP from the station indicated through the
MAC Address field. This message element overrides the default values
provided through the IEEE 802.11 WTP Quality of Service message
element (see Section 6.22. Any tagging performed by the WTP MUST be
directly applied to the packets receive from the station, as well as
the CAPWAP tunnel, if the packets are tunneled to the AC. See
Section 2.6 for more information.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | MAC Address | | Radio ID | MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address | DSCP Tag | 802.1p Tag | | MAC Address | QoS Sub-Element... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 1043 for IEEE 802.11 Update Station QoS Type: 1043 for IEEE 802.11 Update Station QoS
Length: 8 Length: 8
Radio ID: The Radio Identifier, typically refers to some interface Radio ID: The Radio Identifier, typically refers to some interface
index on the WTP index on the WTP
MAC Address: The station's MAC Address. MAC Address: The station's MAC Address.
DSCP Tag: The DSCP label to use if packets are to be DSCP tagged. QoS Sub-Element: The IEEE 802.11 WTP Quality of Service message
element contains four QoS sub-elements, one for every QoS profile.
The order of the QoS profiles are Voice, Video, Best Effort and
Background.
802.1p Tag: The 802.1p priority value to use if packets are to be 0 1
IEEE 802.1p tagged. Only the three least significant bits of this 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
field are valid, while the remaining bits MUST be set to zero (0). +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved|8021p|RSV| DSCP Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved: All implementations complying with this protocol MUST
set to zero any bits that are reserved in the version of the
protocol supported by that implementation. Receivers MUST
ignore all bits not defined for the version of the protocol
they support.
8021p: The three bit 802.1p priority value to use if packets are
to be IEEE 802.1p tagged. This field is used only if the 'P'
bit in the WTP Quality of Service message element was set;
otherwise, its contents MUST be ignored.
RSV: All implementations complying with this protocol MUST set
to zero any bits that are reserved in the version of the
protocol supported by that implementation. Receivers MUST
ignore all bits not defined for the version of the protocol
they support.
DSCP Tag: The 6 bit DSCP label to use if packets are eligible to
be DSCP tagged, specifically an IPv4 or IPv6 packet (see
[RFC2474]). This field is used only if the 'D' bit in the WTP
Quality of Service message element was set; otherwise, its
contents MUST be ignored.
6.21. IEEE 802.11 Update WLAN 6.21. IEEE 802.11 Update WLAN
The IEEE 802.11 Update WLAN message element is used by the AC to The IEEE 802.11 Update WLAN message element is used by the AC to
define a wireless LAN on the WTP. The inclusion of this message define a wireless LAN on the WTP. The inclusion of this message
element MUST also include the IEEE 802.11 Information Element message element MUST also include the IEEE 802.11 Information Element message
element, containing the following 802.11 IEs: element, containing the following 802.11 IEs:
Power Capability information element Power Constraint information element
WPA information element WPA information element [WPA]
RSN information element RSN information element
EDCA Parameter Set information element EDCA Parameter Set information element
QoS Capability information element QoS Capability information element
WMM information element WMM information element [WMM]
These IEEE 802.11 information elements are stored by the WTP and
included in any Probe Responses and Beacons generated, as specified
in the IEEE 802.11 standard [IEEE.802-11.2007].
If cryptographic services are provided at the WTP, the WTP MUST
observe the algorithm dictated in the Group Cipher Suite field of the
RSN information element sent by the AC. The RSN Information Element
is used to communicate any supported algorithm, including WEP, TKIP
and AES-CCMP. In the case of static WEP keys, the RSN Information
Element is still used to indicate the cryptographic algorithm even
though no key exchange occurred.
The message element uses the following format: The message element uses the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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 | | Radio ID | WLAN ID | Capability |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Index | Key Status | Key Length | | Key Index | Key Status | Key Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key... | | Key... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 1044 for IEEE 802.11 Update WLAN Type: 1044 for IEEE 802.11 Update WLAN
Length: 40 Length: 40
Radio ID: An 8-bit value representing the radio. Radio ID: An 8-bit value representing the radio.
WLAN ID: An 8-bit value specifying the WLAN Identifier. WLAN ID: An 8-bit value specifying the WLAN Identifier. The value
MUST be between one (1) and 15.
Capability: A 16-bit value containing the capabilities information Capability: A 16-bit value containing the capabilities information
field to be advertised by the WTP within the Probe and Beacon field to be advertised by the WTP within the Probe and Beacon
messages. messages.
Key-Index: The Key Index associated with the key. Key-Index: The Key Index associated with the key.
Key Status: A 1 byte value that specifies the state and usage of Key Status: A 1 byte value that specifies the state and usage of
the key that has been included. The following values describe the the key that has been included. The following values describe the
key usage and its status: key usage and its status:
skipping to change at page 53, line 8 skipping to change at page 60, line 8
GTK with the STA's in the BSS. It is only valid when IEEE 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. 802.11 is enabled as the security policy for the BSS.
3 - The value of 3 indicates that the AC has completed rekeying 3 - The value of 3 indicates that the AC has completed rekeying
the GTK and broadcast packets no longer need to be duplicated the GTK and broadcast packets no longer need to be duplicated
and transmitted with both GTK's. and transmitted with both GTK's.
Key Length: A 16-bit value representing the length of the Key Key Length: A 16-bit value representing the length of the Key
field. field.
Key: A 32 byte Session Key to use to provide data privacy. For Key: A Session Key, whose length is known via the key length field,
static WEP keys, which is true when the 'Key Status' bit is set to used to provide data privacy. For static WEP keys, which is true
one, this key is used for both unicast and multicast traffic. For when the 'Key Status' bit is set to one, this key is used for both
encryption schemes that employ a separate encryption key for unicast and multicast traffic. For encryption schemes that employ
unicast and multicast traffic, the key included here only applies a separate encryption key for unicast and multicast traffic, the
to multicast data, and the cipher suite is specified in an key included here only applies to multicast data, and the cipher
accompanied RSN Information Element. In these scenarios, the key, suite is specified in an accompanied RSN Information Element. In
and cipher information, is communicated via the Add Station these scenarios, the key, and cipher information, is communicated
message element, see Section 4.6.8 in via the Add Station message element, see Section 4.6.8 in
[I-D.ietf-capwap-protocol-specification]. [I-D.ietf-capwap-protocol-specification].
6.22. IEEE 802.11 WTP Quality of Service 6.22. IEEE 802.11 WTP Quality of Service
The IEEE 802.11 WTP Quality of Service message element value is sent The IEEE 802.11 WTP Quality of Service message element value is sent
by the AC to the WTP to communicate quality of service configuration by the AC to the WTP to communicate quality of service configuration
information. information. The QoS tag included in this message element are the
default QoS values to be applied to packets received by the WTP from
stations on a particular radio. Any tagging performed by the WTP
MUST be directly applied to the packets receive from the station, as
well as the CAPWAP tunnel, if the packets are tunneled to the AC.
See Section 2.6 for more information.
0 1 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 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 | Tag Packets | | Radio ID |Tagging Policy | QoS Sub-Element ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 1045 for IEEE 802.11 WTP Quality of Service Type: 1045 for IEEE 802.11 WTP Quality of Service
Length: 34 Length: 34
Radio ID: The Radio Identifier, typically refers to some interface Radio ID: The Radio Identifier, typically refers to some interface
index on the WTP index on the WTP
Tag Packets: A bit field indicating whether CAPWAP packets should Tagging Policy: A bit field indicating how the WTP is to mark
be tagged for QoS purposes. The following bit values are packets for QoS purposes. The required WTP behavior is defined in
currently supported: Section 2.6.1. The field has the following format:
0 - Untagged 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|Rsvd |P|Q|D|O|I|
+-+-+-+-+-+-+-+-+
Rsvd: A set of reserved bits for future use. All implementations
complying with this protocol MUST set to zero any bits that are
reserved in the version of the protocol supported by that
implementation. Receivers MUST ignore all bits not defined for
the version of the protocol they support.
1 - 802.1p P: When set, the WTP is to employ the 802.1p QoS mechanism (see
Section 2.6.1.1), and the WTP is to use the 'Q' bit.
2 - DSCP Q: When the 'P' bit is set, the 'Q' bit is used by the AC to
communicate to the WTP how 802.1p QoS is to be enforced.
Details on the behavior of the 'Q' bit is specified in
Section 2.6.1.1.
Immediately following the above header is the following data D: When set, the WTP is to employ the DSCP QoS mechanism (see
structure. This data structure will be repeated four times; once Section 2.6.1.2), and the WTP is to use the 'O' and 'I' bits.
for every QoS profile. The order of the QoS profiles are Voice,
Video, Best Effort and Background. O: When the 'D' bit is set, the 'O' bit is used by the AC to
communicate to the WTP how DSCP QoS is to be enforced on the
outer (tunneled) header. Details on the behavior of the 'O'
bit is specified in Section 2.6.1.2.
I: When the 'D' bit is set, the 'I' bit is used by the AC to
communicate to the WTP how DSCP QoS is to be enforced on the
station's packet (inner) header. Details on the behavior of
the 'I' bit is specified in Section 2.6.1.2.
QoS Sub-Element: The IEEE 802.11 WTP Quality of Service message
element contains four QoS sub-elements, one for every QoS profile.
The order of the QoS profiles are Voice, Video, Best Effort and
Background.
0 1 2 3 0 1 2 3
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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Queue Depth | CWMin | CWMax | | Queue Depth | CWMin | CWMax |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CWMax | AIFS | 802.1p Tag | DSCP Tag | | CWMax | AIFS | Reserved|8021p|RSV| DSCP Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Queue Depth: The number of packets that can be on the specific QoS Queue Depth: The number of packets that can be on the specific
transmit queue at any given time. QoS transmit queue at any given time.
CWMin: The Contention Window minimum (CWmin) value for the QoS CWMin: The Contention Window minimum (CWmin) value for the QoS
transmit queue. The value of this field comes from the IEEE transmit queue. The value of this field comes from the IEEE
802.11 dot11EDCATableCWMin MIB element (see [IEEE.802-11.2007]). 802.11 dot11EDCATableCWMin MIB element (see
[IEEE.802-11.2007]).
CWMax: The Contention Window maximum (CWmax) value for the QoS CWMax: The Contention Window maximum (CWmax) value for the QoS
transmit queue. The value of this field comes from the IEEE transmit queue. The value of this field comes from the IEEE
802.11 dot11EDCATableCWMax MIB element (see [IEEE.802-11.2007]). 802.11 dot11EDCATableCWMax MIB element (see
[IEEE.802-11.2007]).
AIFS: The Arbitration Inter Frame Spacing (AIFS) to use for the QoS AIFS: The Arbitration Inter Frame Spacing (AIFS) to use for the
transmit queue. The value of this field comes from the IEEE QoS transmit queue. The value of this field comes from the
802.11 dot11EDCATableAIFSN MIB element (see [IEEE.802-11.2007]). IEEE 802.11 dot11EDCATableAIFSN MIB element (see
[IEEE.802-11.2007]).
802.1p Tag: The 802.1p priority value to use if packets are to be Reserved: All implementations complying with this protocol MUST
802.1p tagged. Only the three least significant bits of this set to zero any bits that are reserved in the version of the
field are valid, while the remaining bits MUST be set to zero (0). protocol supported by that implementation. Receivers MUST
ignore all bits not defined for the version of the protocol
they support.
DSCP Tag: The DSCP label to use if packets are to be DSCP tagged. 8021p: The three bit 802.1p priority value to use if packets are
to be IEEE 802.1p tagged. This field is used only if the 'P'
bit is set; otherwise, its contents MUST be ignored.
RSV: All implementations complying with this protocol MUST set
to zero any bits that are reserved in the version of the
protocol supported by that implementation. Receivers MUST
ignore all bits not defined for the version of the protocol
they support.
DSCP Tag: The 6 bit DSCP label to use if packets are eligible to
be DSCP tagged, specifically an IPv4 or IPv6 packet (see
[RFC2474]). This field is used only if the 'D' bit is set;
otherwise, its contents MUST be ignored.
6.23. IEEE 802.11 WTP Radio Configuration 6.23. IEEE 802.11 WTP Radio Configuration
The IEEE 802.11 WTP WLAN Radio Configuration message element is used The IEEE 802.11 WTP WLAN Radio Configuration message element is used
by the AC to configure a Radio on the WTP, and by the WTP to deliver by the AC to configure a Radio on the WTP, and by the WTP to deliver
its radio configuration to the AC. The message element value its radio configuration to the AC. The message element value
contains the following fields: contains the following fields:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID |Short Preamble| Num of BSSIDs | DTIM Period | | Radio ID |Short Preamble| Num of BSSIDs | DTIM Period |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BSSID | | BSSID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BSSID | Beacon Period | | BSSID | Beacon Period |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Country Code | | Country String |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 1046 for IEEE 802.11 WTP WLAN Radio Configuration Type: 1046 for IEEE 802.11 WTP WLAN Radio Configuration
Length: 16 Length: 16
Radio ID: An 8-bit value representing the radio to configure. Radio ID: An 8-bit value representing the radio to configure.
Short Preamble: An 8-bit value indicating whether short preamble is Short Preamble: An 8-bit value indicating whether short preamble is
supported. The following enumerated values are currently supported. The following enumerated values are currently
supported: supported:
skipping to change at page 55, line 38 skipping to change at page 63, line 40
transmitted in the DTIM Period field of Beacon frames. The value transmitted in the DTIM Period field of Beacon frames. The value
of this field comes from the IEEE 802.11 dot11DTIMPeriod MIB of this field comes from the IEEE 802.11 dot11DTIMPeriod MIB
element (see [IEEE.802-11.2007]). element (see [IEEE.802-11.2007]).
Beacon Period: This attribute specifies the number of Time Unit Beacon Period: This attribute specifies the number of Time Unit
(TU) that a station uses for scheduling Beacon transmissions. (TU) that a station uses for scheduling Beacon transmissions.
This value is transmitted in Beacon and Probe Response frames. This value is transmitted in Beacon and Probe Response frames.
The value of this field comes from the IEEE 802.11 The value of this field comes from the IEEE 802.11
dot11BeaconPeriod MIB element (see [IEEE.802-11.2007]). dot11BeaconPeriod MIB element (see [IEEE.802-11.2007]).
Country Code: This attribute identifies the country in which the Country String: This attribute identifies the country in which the
station is operating. The value of this field comes from the IEEE station is operating. The value of this field comes from the IEEE
802.11 dot11CountryString MIB element (see [IEEE.802-11.2007]). 802.11 dot11CountryString MIB element (see [IEEE.802-11.2007]).
Some regulatory domains do not allow WTPs to have user Some regulatory domains do not allow WTPs to have user
configurable country codes, and require that it be a fixed value configurable country string, and require that it be a fixed value
during the manufacturing process. Therefore, WTP vendors that during the manufacturing process. Therefore, WTP vendors that
wish to allow for the configuration of this field will need to wish to allow for the configuration of this field will need to
validate this behavior during its radio certification process. validate this behavior during its radio certification process.
Other WTP vendors may simply wish to treat this WTP configuration Other WTP vendors may simply wish to treat this WTP configuration
parameter as read-only. The country codes can be found in parameter as read-only. The country strings can be found in
[ISO.3166.1984]. [ISO.3166-1].
The WTP and AC MAY ignore the value of this field, depending upon The WTP and AC MAY ignore the value of this field, depending upon
regulatory requirements, for example to avoid classification as a regulatory requirements, for example to avoid classification as a
Software Defined Radio. When this field is used, the first two Software Defined Radio. When this field is used, the first two
octets of this string is the two character country code as octets of this string is the two character country string as
described in document ISO/IEC 3166- 1, and the third octet MUST described in document [ISO.3166-1], and the third octet MUST have
have the value 1, 2 or 3 as defined below. When the value of the the value 1, 2 or 3 as defined below. When the value of the third
third octet is 255, the country code field is not used, and MUST octet is 255, the country string field is not used, and MUST be
be ignored. ignored.
1 an ASCII space character, if the regulations under which the 1. an ASCII space character, if the regulations under which the
station is operating encompass all environments in the country, station is operating encompass all environments in the country,
2 an ASCII 'O' character, if the regulations under which the 2. an ASCII 'O' character, if the regulations under which the
station is operating are for an outdoor environment only, or station is operating are for an outdoor environment only, or
3 an ASCII 'I' character, if the regulations under which the 3. an ASCII 'I' character, if the regulations under which the
station is operating are for an indoor environment only station is operating are for an indoor environment only.
255 Country Code field is not used; ignore the field. 4. an ASCII 'X' character, if the station is operating under a
non-country entity. The first two octets of the non-country
entity shall be two ASCII 'XX' characters.
Note that the last byte of the Country String MUST be set to NULL.
6.24. IEEE 802.11 WTP Radio Fail Alarm Indication 6.24. IEEE 802.11 WTP Radio Fail Alarm Indication
The IEEE 802.11 WTP Radio Fail Alarm Indication message element is The IEEE 802.11 WTP Radio Fail Alarm Indication message element is
sent by the WTP to the AC when it detects a radio failure. sent by the WTP to the AC when it detects a radio failure.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Type | Status | Pad | | Radio ID | Type | Status | Pad |
skipping to change at page 57, line 41 skipping to change at page 65, line 46
Type: 1048 for IEEE 802.11 WTP Radio Information Type: 1048 for IEEE 802.11 WTP Radio Information
Length: 5 Length: 5
Radio ID: The Radio Identifier, which typically refers to an Radio ID: The Radio Identifier, which typically refers to an
interface index on the WTP interface index on the WTP
Radio Type: The type of radio present. Note this is a bit field Radio Type: The type of radio present. Note this is a bit field
which is used to specify support for more than a single type of which is used to specify support for more than a single type of
PHY/MAC. The following bit values are supported: PHY/MAC. The field has the following format:
1 - 802.11b: An IEEE 802.11b radio. 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|Reservd|N|G|A|B|
+-+-+-+-+-+-+-+-+
Reservd: A set of reserved bits for future use. All
implementations complying with this protocol MUST set to zero
any bits that are reserved in the version of the protocol
supported by that implementation. Receivers MUST ignore all
bits not defined for the version of the protocol they support.
2 - 802.11a: An IEEE 802.11a radio. N: An IEEE 802.11n radioP.
4 - 802.11g: An IEEE 802.11g radio. G: An IEEE 802.11g radio.
8 - 802.11n: An IEEE 802.11n radio. A: An IEEE 802.11a radio.
B: An IEEE 802.11b radio.
7. IEEE 802.11 Binding WTP Saved Variables 7. IEEE 802.11 Binding WTP Saved Variables
This section contains the IEEE 802.11 binding specific variables that This section contains the IEEE 802.11 binding specific variables that
SHOULD be saved in non-volatile memory on the WTP. SHOULD be saved in non-volatile memory on the WTP.
7.1. IEEE80211AntennaInfo 7.1. IEEE80211AntennaInfo
The WTP per radio antenna configuration, defined in Section 6.2. The WTP per radio antenna configuration, defined in Section 6.2.
skipping to change at page 60, line 13 skipping to change at page 68, line 13
The WTP per radio Radio Configuration, defined in Section 6.23. The WTP per radio Radio Configuration, defined in Section 6.23.
8. Technology Specific Message Element Values 8. Technology Specific Message Element Values
This section lists IEEE 802.11 specific values for the generic CAPWAP This section lists IEEE 802.11 specific values for the generic CAPWAP
message elements which include fields whose values are technology message elements which include fields whose values are technology
specific. specific.
8.1. WTP Descriptor Message Element, Encryption Capabilities Field: 8.1. WTP Descriptor Message Element, Encryption Capabilities Field:
IEEE 802.11 uses the following values: This specification defines two new bits for the WTP Descriptor's
Encryption Capabilities field, as defined in
[I-D.ietf-capwap-protocol-specification]. Note that only the bits
defined in this specification are described below. The format of the
Encryption Capabilities Field is:
4 - Encrypt AES-CCMP 128: WTP supports AES-CCMP, as defined in 0 1 2 3 4 5 6 7
[IEEE.802-11.2007]. +-+-+-+-+-+-+-+-+
| |A|T| |
+-+-+-+-+-+-+-+-+
5 - Encrypt TKIP-MIC: WTP supports TKIP and Michael, as defined in A: WTP supports AES-CCMP, as defined in [IEEE.802-11.2007].
[IEEE.802-11.2007] and [WPA], respectively.
T: WTP supports TKIP and Michael, as defined in [IEEE.802-11.2007]
and [WPA], respectively.
9. Security Considerations 9. Security Considerations
This section describes security considerations for using IEEE 802.11 This section describes security considerations for using IEEE 802.11
with the CAPWAP protocol. with the CAPWAP protocol.
9.1. IEEE 802.11 Security 9.1. IEEE 802.11 Security
When used with an IEEE 802.11 infrastructure with WEP encryption, the When used with an IEEE 802.11 infrastructure with WEP encryption, the
CAPWAP protocol does not add any new vulnerabilities. Derived CAPWAP protocol does not add any new vulnerabilities. Derived
skipping to change at page 63, line 7 skipping to change at page 71, line 7
providing the exact KeyRSC value is not warranted. That is, this providing the exact KeyRSC value is not warranted. That is, this
specification provides for a calculated risk in this regard. specification provides for a calculated risk in this regard.
The AC SHOULD use an RSC of 0 when computing message-3 of the 4-way The AC SHOULD use an RSC of 0 when computing message-3 of the 4-way
802.11i handshake, unless the AC has knowledge of a more optimal RSC 802.11i handshake, unless the AC has knowledge of a more optimal RSC
value to use. Mechanisms for determining a more optimal RSC value value to use. Mechanisms for determining a more optimal RSC value
are outside the scope of this specification. are outside the scope of this specification.
10. IANA Considerations 10. IANA Considerations
10.1. CAPWAP Message Types This section details the actions to be taken by IANA during the
publication of the specification. There are numerous registries that
need to be created, and the contents, document action (see [RFC5226],
and registry format are all included below. Note that in cases where
bit fields are referred to, the bit numbering is left to right, where
the leftmost bit is labelled as bit zero (0).
This specification defines two new Message Types used in the CAPWAP 10.1. CAPWAP Wireless Binding Identifier
header. These values are defined in Section 3.
10.2. CAPWAP Control Message Type This specification requires a value assigned from the Wireless
Binding Identifier namespace, defined in
[I-D.ietf-capwap-protocol-specification]. The value assigned is to
be added to Section 2.1. The value of one (1)is highly recommended,
as it is used in implementations.
This specification defines 27 new Message Types used in the CAPWAP 10.2. CAPWAP IEEE 802.11 Message Types
header. These values are defined in Figure 8.
10.3. IEEE 802.11 Key Status This document creates a new sub-registry to the existing CAPWAP
Message Type registry, which is defined in
[I-D.ietf-capwap-protocol-specification].
IANA will create and maintain the CAPWAP IEEE 802.11 Message Types
sub-registry for all message types whose Enterprise Number is set to
13277. The namespace is 32 bits (0-4294967295), where the values
3398911 and 3398912 are reserved and must not be assigned. The
values 3398913 and 3398914 are allocated in this specification, and
can be found in Section 3. Any new assignments of a CAPWAP IEEE
802.11 Message Type, whose Enterprise Number is set to 13277)
requires a Expert Review. The format of the registry to be
maintained by IANA has the following format:
CAPWAP IEEE 802.11 Message Type Reference
Control Message Value
10.3. CAPWAP Message Element Type
This specification defines new values to be registered to the
existing CAPWAP Message Element Type registry, defined in
[I-D.ietf-capwap-protocol-specification]. The values used in this
document, 1024 through 1048, as listed in Figure 8 are recommended as
implementations already exist that make use of these values.
10.4. IEEE 802.11 Key Status
The Key Status field in the IEEE 802.11 Add WLAN message element (see The Key Status field in the IEEE 802.11 Add WLAN message element (see
Section 6.1) and IEEE 802.11 Update WLAN message element (see Section 6.1) and IEEE 802.11 Update WLAN message element (see
Section 6.21) is used to provide information about the status of the Section 6.21) is used to provide information about the status of the
keying exchange. This document defines four values, and the keying exchange. This document defines four values, and the
remaining values are controlled and maintained by IANA and requires a remaining values are controlled and maintained by IANA and requires a
Standards Action. Expert Review.
10.4. IEEE 802.11 QoS 10.5. IEEE 802.11 QoS
The QoS field in the IEEE 802.11 Add WLAN message element (see The QoS field in the IEEE 802.11 Add WLAN message element (see
Section 6.1) is used to configure a QoS policy for the WLAN. This Section 6.1) is used to configure a QoS policy for the WLAN. The
document defines four values, and the remaining values are controlled namespace is 8 bits (0-255), where the values zero (0) through four
and maintained by IANA and requires a Standards Action. (4) are allocated in this specification, and can be found in
Section 6.1. This namespace is managed by IANA and assignments
require a Expert Review. IANA will create the IEEE 802.11 QoS
registry, whose format is:
10.5. IEEE 802.11 Auth Type IEEE 802.11 QoS Type Value Reference
10.6. IEEE 802.11 Auth Type
The Auth Type field in the IEEE 802.11 Add WLAN message element (see The Auth Type field in the IEEE 802.11 Add WLAN message element (see
Section 6.1) is used to configure the IEEE 802.11 authentication Section 6.1) is 8 bits and is used to configure the IEEE 802.11
policy for the WLAN. This document defines two bits, and the authentication policy for the WLAN. The namespace is 8 bits (0-255),
remaining bits are controlled and maintained by IANA and requires a where the values zero (0) and one (1) are allocated in this
Standards Action. specification, and can be found in Section 6.1. This namespace is
managed by IANA and assignments require a Expert Review. IANA will
create the IEEE 802.11 Auth Type registry, whose format is:
10.6. IEEE 802.11 Antenna Combiner IEEE 802.11 Auth Type Type Value Reference
10.7. IEEE 802.11 Antenna Combiner
The Combiner field in the IEEE 802.11 Antenna message element (see The Combiner field in the IEEE 802.11 Antenna message element (see
Section 6.2) is used to provide information about the WTP's antennas. Section 6.2) is used to provide information about the WTP's antennas.
This document defines four bits, and the remaining bits are The namespace is 8 bits (0-255), where the values zero (0) and one
controlled and maintained by IANA and requires a Standards Action. (1) are allocated in this specification, and can be found in
Section 6.2. This namespace is managed by IANA and assignments
require a Expert Review. IANA will create the IEEE 802.11 Antenna
Combiner registry, whose format is:
10.7. IEEE 802.11 Antenna Selection IEEE 802.11 Antenna Combiner Type Value Reference
10.8. IEEE 802.11 Antenna Selection
The Antenna Selection field in the IEEE 802.11 Antenna message The Antenna Selection field in the IEEE 802.11 Antenna message
element (see Section 6.2) is used to provide information about the element (see Section 6.2) is used to provide information about the
WTP's antennas. This document defines two values, and the remaining WTP's antennas. The namespace is 8 bits (0-255), where the values
values are controlled and maintained by IANA and requires a Standards zero (0) is reserved and used and the values one (1) through four (4)
Action. are allocated in this specification, and can be found in Section 6.2.
10.8. IEEE 802.11 Session Key Flags This namespace is managed by IANA and assignments require a Expert
Review. IANA will create the IEEE 802.11 Antenna Selection registry,
whose format is:
IEEE 802.11 Antenna Selection Type Value Reference
10.9. IEEE 802.11 Session Key Flags
The Flags field in the IEEE 802.11 Station Session Key message The Flags field in the IEEE 802.11 Station Session Key message
element (see Section 6.15) is used to configure the session key element (see Section 6.15) is 16 bits and is used to configure the
association with the mobile device. This document defines two bits, session key association with the mobile device. This specification
and the remaining 14 bits are controlled and maintained by IANA and defines bits zero (0) and one (1), while bits two (2) through sixteen
requires a Standards Action. are reserved. The reserved bits are managed by IANA and whose
assignment requires a Expert Review. IANA will create the IEEE
802.11 Session Key Flags registry, whose format is:
10.9. IEEE 802.11 Tag Packets IEEE 802.11 Station Session Key Bit Position Reference
The Tag Packets field in the IEEE 802.11 WTP Quality of Service 10.10. IEEE 802.11 Tagging Policy
message element (see Section 6.22) is used to specify how the CAPWAP
Data Channel packets are to be tagged. This document defines two
bits, and the remaining 6 bits are controlled and maintained by IANA
and requires a Standards Action.
10.10. IEEE 802.11 WTP Radio Fail The Tagging Policy field in the IEEE 802.11 WTP Quality of Service
message element (see Section 6.22) is 8 bits and is used to specify
how the CAPWAP Data Channel packets are to be tagged. This
specification defines bits five (5) through seven (7). The remaining
bits are managed by IANA and whose assignment requires a Expert
Review. IANA will create the IEEE 802.11 Tagging Policy registry,
whose format is:
IEEE 802.11 Tagging Policy Bit Position Reference
10.11. IEEE 802.11 WTP Radio Fail
The Type field in the IEEE 802.11 WTP Radio Fail Alarm Indication The Type field in the IEEE 802.11 WTP Radio Fail Alarm Indication
message element (see Section 6.24) is used to provide information on message element (see Section 6.24) is used to provide information on
why a WTP's radio has failed. This document defines two values, and why a WTP's radio has failed. The namespace is 8 bits (0-255), where
the remaining values are controlled and maintained by IANA and the values zero (0) is reserved and unused, while the values one (1)
requires a Standards Action. and two (2) are allocated in this specification, and can be found in
Section 6.24. This namespace is managed by IANA and assignments
require a Expert Review. IANA will create the IEEE 802.11 WTP Radio
Fail registry, whose format is:
10.11. IEEE 802.11 WTP Radio Type IEEE 802.11 WTP Radio Fail Type Value Reference
10.12. IEEE 802.11 WTP Radio Type
The Radio Type field in the IEEE 802.11 WTP Radio Information message The Radio Type field in the IEEE 802.11 WTP Radio Information message
element (see Section 6.25) is used to provide information about the element (see Section 6.25) is 8 bits and is used to provide
WTP's radio type. This document defines four bits, and the remaining information about the WTP's radio type. This specification defines
28 bits are controlled and maintained by IANA and requires a bits five (5) through seven (7). The remaining bits are managed by
Standards Action. IANA and whose assignment requires a Expert Review. IANA will create
the IEEE 802.11 WTP Radio Type registry, whose format is:
11. Acknowledgements IEEE 802.11 WTP Radio Type Bit Position Reference
11. Acknowledgments
The following individuals are acknowledged for their contributions to The following individuals are acknowledged for their contributions to
this binding specification: Puneet Agarwal, Charles Clancy, Saravanan this binding specification: Puneet Agarwal, Charles Clancy, Pasi
Govindan, Scott Kelly, Peter Nilsson, Bob O'Hara, David Perkins, Eronen, Saravanan Govindan, Scott Kelly, Peter Nilsson, Bob O'Hara,
Margaret Wasserman and Yong Zhang. David Perkins, Margaret Wasserman and Yong Zhang.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004. RFC 3748, June 2004.
[ISO.3166.1984] [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
International Organization for Standardization, "Codes for "Assured Forwarding PHB Group", RFC 2597, June 1999.
the Representation of Names of Countries", ISO Standard
3166, 1984. [RFC2598] Jacobson, V., Nichols, K., and K. Poduri, "An Expedited
Forwarding PHB", RFC 2598, June 1999.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001.
[FIPS.197.2001] [FIPS.197.2001]
National Institute of Standards and Technology, "Advanced National Institute of Standards and Technology, "Advanced
Encryption Standard (AES)", FIPS PUB 197, November 2001, < Encryption Standard (AES)", FIPS PUB 197, November 2001, <
http://csrc.nist.gov/publications/fips/fips197/ http://csrc.nist.gov/publications/fips/fips197/
fips-197.pdf>. fips-197.pdf>.
[ISO.3166-1]
ISO Standard, "International Organization for
Standardization, Codes for the representation of names of
countries and their subdivisions - Part 1: Country codes",
ISO Standard 3166-1:1997, 1997.
[IEEE.802-11.2007] [IEEE.802-11.2007]
"Information technology - Telecommunications and "Information technology - Telecommunications and
information exchange between systems - Local and information exchange between systems - Local and
metropolitan area networks - Specific requirements - Part metropolitan area networks - Specific requirements - Part
11: Wireless LAN Medium Access Control (MAC) and Physical 11: Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) specifications", IEEE Standard 802.11, 2007, < Layer (PHY) specifications", IEEE Standard 802.11, 2007, <
http://standards.ieee.org/getieee802/download/ http://standards.ieee.org/getieee802/download/
802.11-2007.pdf>. 802.11-2007.pdf>.
[I-D.ietf-capwap-protocol-specification] [I-D.ietf-capwap-protocol-specification]
Calhoun, P., "CAPWAP Protocol Specification", Calhoun, P., "CAPWAP Protocol Specification",
draft-ietf-capwap-protocol-specification-10 (work in draft-ietf-capwap-protocol-specification-11 (work in
progress), March 2008. progress), July 2008.
[IEEE.802-1X.2004] [IEEE.802-1X.2004]
"Information technology - Telecommunications and "Information technology - Telecommunications and
information exchange between systems - Local and information exchange between systems - Local and
metropolitan area networks - Specific requirements - Port- metropolitan area networks - Specific requirements - Port-
Based Network Access Control", IEEE Standard 802.1X, 2004, Based Network Access Control", IEEE Standard 802.1X, 2004,
<http://standards.ieee.org/getieee802/download/ <http://standards.ieee.org/getieee802/download/
802.1X-2004.pdf>. 802.1X-2004.pdf>.
[IEEE.802-1Q.2005] [IEEE.802-1Q.2005]
skipping to change at page 67, line 18 skipping to change at page 77, line 38
12.2. Informational References 12.2. Informational References
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible
Authentication Protocol (EAP) Method Requirements for Authentication Protocol (EAP) Method Requirements for
Wireless LANs", RFC 4017, March 2005. Wireless LANs", RFC 4017, March 2005.
[RFC4118] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy [RFC4118] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy
for Control and Provisioning of Wireless Access Points for Control and Provisioning of Wireless Access Points
(CAPWAP)", RFC 4118, June 2005. (CAPWAP)", RFC 4118, June 2005.
[WPA] "WiFi Protected Access (WPA), [WPA] "Deploying Wi-Fi Protected Access (WPA) and WPA2 in the
WPAfor802.11ver3_073004.pdf", August 2004, <www.wi- Enterprise", March 2005, <www.wi-fi.org>.
[WMM] "Support for Multimedia Applications with Quality of
Service in WiFi Networks)", September 2004, <www.wi-
fi.org>. fi.org>.
Editors' Addresses Editors' Addresses
Pat R. Calhoun Pat R. Calhoun
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
Phone: +1 408-902-3240 Phone: +1 408-902-3240
 End of changes. 125 change blocks. 
293 lines changed or deleted 735 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/