draft-ietf-capwap-protocol-binding-ieee80211-02.txt   draft-ietf-capwap-protocol-binding-ieee80211-03.txt 
Network Working Group P. Calhoun, Editor Network Working Group P. Calhoun, Editor
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Expires: September 5, 2007 M. Montemurro, Editor Expires: September 11, 2007 M. Montemurro, Editor
Research In Motion Research In Motion
D. Stanley, Editor D. Stanley, Editor
Aruba Networks Aruba Networks
March 4, 2007
CAPWAP Protocol Binding for IEEE 802.11 CAPWAP Protocol Binding for IEEE 802.11
draft-ietf-capwap-protocol-binding-ieee80211-02 draft-ietf-capwap-protocol-binding-ieee80211-03
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 35
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 September 5, 2007. This Internet-Draft will expire on September 2, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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
skipping to change at page 2, line 29 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Conventions used in this document . . . . . . . . . . . . 4 1.2. Conventions used in this document . . . . . . . . . . . . 4
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. IEEE 802.11 Binding . . . . . . . . . . . . . . . . . . . . . 6 2. IEEE 802.11 Binding . . . . . . . . . . . . . . . . . . . . . 6
2.1. Split MAC and Local MAC Functionality . . . . . . . . . . 6 2.1. Split MAC and Local MAC Functionality . . . . . . . . . . 6
2.1.1. Split MAC . . . . . . . . . . . . . . . . . . . . . . 6 2.1.1. Split MAC . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2. Local MAC . . . . . . . . . . . . . . . . . . . . . . 9 2.1.2. Local MAC . . . . . . . . . . . . . . . . . . . . . . 10
2.2. Roaming Behavior . . . . . . . . . . . . . . . . . . . . . 12 2.2. Roaming Behavior . . . . . . . . . . . . . . . . . . . . . 12
2.3. Group Key Refresh . . . . . . . . . . . . . . . . . . . . 13 2.3. Group Key Refresh . . . . . . . . . . . . . . . . . . . . 13
2.4. BSSID to WLAN ID Mapping . . . . . . . . . . . . . . . . . 14 2.4. BSSID to WLAN ID Mapping . . . . . . . . . . . . . . . . . 14
2.5. Quality of Service for IEEE 802.11 MAC Management 2.5. Quality of Service for IEEE 802.11 MAC Management
Messages . . . . . . . . . . . . . . . . . . . . . . . . . 14 Messages . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.6. Run State Operation . . . . . . . . . . . . . . . . . . . 14 2.6. Run State Operation . . . . . . . . . . . . . . . . . . . 14
3. IEEE 802.11 Specific CAPWAP Control Messages . . . . . . . . . 15 3. IEEE 802.11 Specific CAPWAP Control Messages . . . . . . . . . 15
3.1. IEEE 802.11 WLAN Configuration Request . . . . . . . . . . 15 3.1. IEEE 802.11 WLAN Configuration Request . . . . . . . . . . 15
3.2. IEEE 802.11 WLAN Configuration Response . . . . . . . . . 16 3.2. IEEE 802.11 WLAN Configuration Response . . . . . . . . . 16
4. CAPWAP Data Message Bindings . . . . . . . . . . . . . . . . . 17 4. CAPWAP Data Message Bindings . . . . . . . . . . . . . . . . . 17
skipping to change at page 6, line 22 skipping to change at page 6, line 22
2.1. Split MAC and Local MAC Functionality 2.1. 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 [7], reside in the AC. defined in the taxonomy specification [7], reside in the AC.
This is a placeholder for the resolution of issue 138 once agreement To provide system component interoperability, the WTP and AC must
has been reached in the working group. support 802.11 encryption/decryption at the WTP. The WTP and AC MAY
support 802.11 encryption/decryption at the AC.
2.1.1. Split MAC 2.1.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
skipping to change at page 8, line 42 skipping to change at page 8, line 43
AC, the IEEE 802.11 Information message element with an RSNIE AC, the IEEE 802.11 Information message element with an RSNIE
would not be included. would not be included.
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 All IEEE 802.11 station data frames are tunneled between the WTP o All IEEE 802.11 station data frames are tunneled between the WTP
and the AC. and the AC.
The WTP SHALL include the IEEE 802.11 MAC header contents in all The WTP SHALL include the IEEE 802.11 MAC header contents in all
frames transmitted to the AC. When 802.11 encryption/decryption is frames transmitted to the AC.
performed at the WTP,the WTP SHALL decrypt the uplink frames prior to
transmitting the frames to the AC. The WTP SHALL also add padding, When 802.11 encryption/decryption is performed at the WTP, the WTP
if necessary, for downlink frames coming from the AC. When 802.11 MUST decrypt the uplink frames, MUST set the Protected Frame field to
encryption/decryption is performed at the AC,the WTP SHALL NOT 0, and MUST make the frame format consistent with that of an
decrypt the uplink frames prior to transmitting the frames to the AC. unprotected 802.11 frame prior to transmitting the frames to the AC.
The AC and WTP SHALL populate the IEEE 802.11 MAC header fields as The fields added to an 802.11 protected frame, i.e., IV/EIV, MIC,and
described in Figure 3. ICV , MUST be stripped off prior to transmission from the WTP to AC.
For downlink frames, the Protected Frame field MUST be set to 0 by
the AC as the frame being sent is unencrypted. The WTP MUST apply
the required protection policy for the WLAN, and set the Protected
Frame field on transmission over the air. The Protected Frame field
always needs to accurately indicate the status of the 802.11 frame
that is carrying it.
When 802.11 encryption/decryption is performed at the AC,the WTP
SHALL NOT decrypt the uplink frames prior to transmitting the frames
to the AC. The AC and WTP SHALL populate the IEEE 802.11 MAC header
fields as described in Figure 3.
MAC header field Location MAC header field Location
Frame Control: Frame Control:
Version AC Version AC
ToDS AC ToDS AC
FromDS AC FromDS AC
Type AC Type AC
SubType AC SubType AC
MoreFrag WTP/AC MoreFrag WTP/AC
Retry WTP Retry WTP
Pwr Mgmt - Pwr Mgmt -
MoreData WTP MoreData WTP
Protected AC Protected WTP/AC
Order AC Order AC
Duration: WTP Duration: WTP
Address 1: AC Address 1: AC
Address 2: AC Address 2: AC
Address 3: AC Address 3: AC
Sequence Ctrl: WTP Sequence Ctrl: WTP
Address 4: AC Address 4: AC
QoS Control: AC QoS Control: AC
Frame Body: AC Frame Body: AC
FCS: WTP FCS: WTP
 End of changes. 8 change blocks. 
17 lines changed or deleted 27 lines changed or added

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