draft-ietf-opsawg-capwap-hybridmac-08.txt		rfc7494.txt
	Network Working Group C. Shao		Internet Engineering Task Force (IETF) C. Shao
	Internet-Draft H. Deng		Request for Comments: 7494 H. Deng
	Intended status: Standards Track China Mobile		Category: Standards Track China Mobile
	Expires: June 21, 2015 R. Pazhyannur		ISSN: 2070-1721 R. Pazhyannur
	Cisco Systems		Cisco Systems
	F. Bari		F. Bari
	AT&T		AT&T
	R. Zhang		R. Zhang
	China Telecom		China Telecom
	S. Matsushima		S. Matsushima
	SoftBank Telecom		SoftBank Telecom
	December 18, 2014		April 2015
	IEEE 802.11 MAC Profile for CAPWAP		IEEE 802.11 Medium Access Control (MAC) Profile for Control and
	draft-ietf-opsawg-capwap-hybridmac-08		Provisioning of Wireless Access Points (CAPWAP)
	Abstract		Abstract
	The CAPWAP protocol binding for IEEE 802.11 defines two MAC (Medium		The Control and Provisioning of Wireless Access Points (CAPWAP)
	Access Control) modes for IEEE 802.11 WTP (Wireless Transmission		protocol binding for IEEE 802.11 defines two Medium Access Control
	Point): Split and Local MAC. In the Split MAC mode, the partitioning		(MAC) modes for IEEE 802.11 Wireless Transmission Points (WTPs):
	of encryption/decryption functions are not clearly defined. In the		Split and Local MAC. In the Split MAC mode, the partitioning of
	Split MAC mode description, IEEE 802.11 encryption is specified as		encryption/decryption functions is not clearly defined. In the Split
	located in either the AC (Access Controller) or the WTP, with no		MAC mode description, IEEE 802.11 encryption is specified as located
	clear way for the AC to inform the WTP of where the encryption		in either the Access Controller (AC) or the WTP, with no clear way
	functionality should be located. This leads to interoperability		for the AC to inform the WTP of where the encryption functionality
	issues, especially when the AC and WTP come from different vendors.		should be located. This leads to interoperability issues, especially
	To prevent interoperability issues, this specification defines an		when the AC and WTP come from different vendors. To prevent
	IEEE 802.11 MAC profile message element in which each profile		interoperability issues, this specification defines an IEEE 802.11
	specifies an unambiguous division of encryption functionality between		MAC Profile message element in which each profile specifies an
	the WTP and AC.		unambiguous division of encryption functionality between the WTP and
			AC.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This is an Internet Standards Track document.
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		This document is a product of the Internet Engineering Task Force
	Task Force (IETF). Note that other groups may also distribute		(IETF). It represents the consensus of the IETF community. It has
	working documents as Internet-Drafts. The list of current Internet-		received public review and has been approved for publication by the
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 5741.
	Internet-Drafts are draft documents valid for a maximum of six months		Information about the current status of this document, any errata,
	and may be updated, replaced, or obsoleted by other documents at any		and how to provide feedback on it may be obtained at
	time. It is inappropriate to use Internet-Drafts as reference		http://www.rfc-editor.org/info/rfc7494.
	material or to cite them other than as "work in progress."
	This Internet-Draft will expire on June 21, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2015 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. IEEE MAC Profile Descriptions . . . . . . . . . . . . . . . . 4		2. IEEE MAC Profile Descriptions . . . . . . . . . . . . . . . . 5
	2.1. Split MAC with WTP encryption . . . . . . . . . . . . . . 4		2.1. Split MAC with WTP Encryption . . . . . . . . . . . . . . 5
	2.2. Split MAC with AC encryption . . . . . . . . . . . . . . 5		2.2. Split MAC with AC Encryption . . . . . . . . . . . . . . 6
	2.3. IEEE 802.11 MAC Profile Frame Exchange . . . . . . . . . 6		2.3. IEEE 802.11 MAC Profile Frame Exchange . . . . . . . . . 8
	3. MAC Profile Message Element Definitions . . . . . . . . . . . 7		3. MAC Profile Message Element Definitions . . . . . . . . . . . 8
	3.1. IEEE 802.11 Supported MAC Profiles . . . . . . . . . . . 7		3.1. IEEE 802.11 Supported MAC Profiles . . . . . . . . . . . 8
	3.2. IEEE 802.11 MAC Profile . . . . . . . . . . . . . . . . . 8		3.2. IEEE 802.11 MAC Profile . . . . . . . . . . . . . . . . . 9
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 8		4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9		6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9		6.1. Normative References . . . . . . . . . . . . . . . . . . 11
	8. Normative References . . . . . . . . . . . . . . . . . . . . 9		6.2. Informative References . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12
			Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 12
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	The CAPWAP protocol supports two MAC modes of operation: Split and		The CAPWAP protocol supports two MAC modes of operation: Split and
	Local MAC, as described in [RFC5415], [RFC5416]. However, there are		Local MAC, as described in [RFC5415] and [RFC5416]. However, there
	MAC functions that have not been clearly defined. For example IEEE		are MAC functions that have not been clearly defined. For example,
	802.11 encryption is specified as located in either in the AC or the		IEEE 802.11 [IEEE.802.11] encryption is specified as located in
	WTP with no clear way to negotiate where it should be located.		either the AC or the WTP with no clear way to negotiate where it
	Because different vendors have different definitions of the MAC mode,		should be located. Because different vendors have different
	many MAC layer functions are mapped differently to either the WTP or		definitions of the MAC mode, many MAC-layer functions are mapped
	the AC by different vendors. Therefore, depending upon the vendor,		differently to either the WTP or the AC by different vendors.
	the operators in their deployments have to perform different		Therefore, depending upon the vendor, the operators in their
	configurations based on implementation of the two modes by their		deployments have to perform different configurations based on
	vendor. If there is no clear specification, then operators will		implementation of the two modes by their vendor. If there is no
	experience interoperability issues with WTPs and ACs from different		clear specification, then operators will experience interoperability
	vendors.		issues with WTPs and ACs from different vendors.
	Figure 1 from [RFC5416], illustrates how some functions are processed		Figure 1 from [RFC5416] illustrates how some functions are processed
	in different places in the Local MAC and Split MAC mode.		in different places in the Local MAC and Split MAC mode.
	Specifically, note that in the Split MAC mode the IEEE 802.11		Specifically, note that in the Split MAC mode, the IEEE 802.11
	encryption/decryption is specified as WTP/AC implying that it could		encryption/decryption is specified as WTP/AC, implying that it could
	be at either location. This is not an issue with Local MAC because		be at either location. This is not an issue with Local MAC because
	encryption is always at the WTP.		encryption is always at the WTP.
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Functions | Local MAC | Split MAC |		| Functions | Local MAC | Split MAC |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |Distribution Service | WTP/AC | AC |		| |Distribution Service | WTP/AC | AC |
	+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |Integration Service | WTP | AC |		| |Integration Service | WTP | AC |
	+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |Beacon Generation | WTP | WTP |		| |Beacon Generation | WTP | WTP |
	+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |Probe Response Generation| WTP | WTP |		| |Probe Response Generation| WTP | WTP |
	+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Function |Power Mgmt | WTP | WTP |		| Function |Power Mgmt/ | WTP | WTP |
	+ |/Packet Buffering | | |		+ |Packet Buffering | | |
	| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |Fragmentation | WTP | WTP/AC |		| |Fragmentation/ | WTP | WTP/AC |
	+ |/Defragmentation | | |		+ |Defragmentation | | |
	| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |Assoc/Disassoc/Reassoc | WTP/AC | AC |		| |Assoc/Disassoc/Reassoc | WTP/AC | AC |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |Classifying | WTP | AC |		| |Classifying | WTP | AC |
	+ IEEE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+ IEEE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 802.11 QoS |Scheduling | WTP | WTP/AC |		| 802.11 QoS |Scheduling | WTP | WTP/AC |
	+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |Queuing | WTP | WTP |		| |Queuing | WTP | WTP |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |IEEE 802.1X/EAP | AC | AC |		| |IEEE 802.1X/EAP | AC | AC |
	+ IEEE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+ IEEE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 802.11 RSN |RSNA Key Management | AC | AC |		| 802.11 RSN |RSNA Key Management | AC | AC |
	+ (WPA2) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+ (WPA2) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |IEEE 802.11 | WTP | WTP/AC |		| |IEEE 802.11 | WTP | WTP/AC |
	+ |Encryption/Decryption | | |		+ |Encryption/Decryption | | |
	|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Note:
			RSN - Robust Security Network
			RSNA - Robust Security Network Association
			WPA2 - Wi-Fi Protected Access 2
	Figure 1: Functions in Local MAC and Split MAC		Figure 1: Functions in Local MAC and Split MAC
	To solve this problem, this specification introduces IEEE 802.11 MAC		To solve this problem, this specification introduces the IEEE 802.11
	profile. The MAC profile unambiguously specifies where the various		MAC Profile. The IEEE 802.11 MAC Profile unambiguously specifies
	MAC functionality should be located.		where the various MAC functionalities should be located.
	2. IEEE MAC Profile Descriptions		2. IEEE MAC Profile Descriptions
	A IEEE MAC Profile refers to a description of how the MAC		A IEEE 802.11 MAC Profile refers to a description of how the MAC
	functionality is split between the WTP and AC shown in Figure 1.		functionality is split between the WTP and AC shown in Figure 1.
	2.1. Split MAC with WTP encryption		2.1. Split MAC with WTP Encryption
	The functional split for the Split MAC with WTP encryption is		The functional split for the Split MAC with WTP encryption is
	provided in Figure 2. This profile is similar to the Split MAC		provided in Figure 2. This profile is similar to the Split MAC
	description in [RFC5416], except that IEEE 802.11 encryption/		description in [RFC5416], except that IEEE 802.11 encryption/
	decryption is at the WTP. Note that fragmentation is always done at		decryption is at the WTP. Note that fragmentation is always done at
	the same entity as the encryption. Consequently, in this profile		the same entity as the encryption. Consequently, in this profile
	fragmentation/defragmentation is also done only at the WTP. Note		fragmentation/defragmentation is also done only at the WTP. Note
	that scheduling functionality is denoted as WTP/AC. As explained in		that scheduling functionality is denoted as WTP/AC. As explained in
	[RFC5416], this means that the admission control component of IEEE		[RFC5416], this means that the admission control component of IEEE
	802.11 resides on the AC, the real-time scheduling and queuing		802.11 resides on the AC; the real-time scheduling and queuing
	functions are on the WTP.		functions are on the WTP.
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Functions | Profile |		| Functions | Profile |
	| | 0 |		| | 0 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |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 |
	+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Function |Power Mgmt | WTP |		| Function |Power Mgmt/ | WTP |
	+ |/Packet Buffering | |		+ |Packet Buffering | |
	| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |Fragmentation | WTP |		| |Fragmentation/ | WTP |
	+ |/Defragmentation | |		+ |Defragmentation | |
	| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |Assoc/Disassoc/Reassoc | AC |		| |Assoc/Disassoc/Reassoc | AC |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |Classifying | AC |		| |Classifying | AC |
	+ IEEE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+ IEEE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 802.11 QoS |Scheduling | WTP/AC |		| 802.11 QoS |Scheduling | WTP/AC |
	+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |Queuing | WTP |		| |Queuing | WTP |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |IEEE 802.1X/EAP | AC |		| |IEEE 802.1X/EAP | AC |
	+ IEEE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+ IEEE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 802.11 RSN |RSNA Key Management | AC |		| 802.11 RSN |RSNA Key Management | AC |
	+ (WPA2) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+ (WPA2) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |IEEE 802.11 | WTP |		| |IEEE 802.11 | WTP |
	+ |Encryption/Decryption | |		+ |Encryption/Decryption | |
	|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Note:
			EAP - Extensible Authentication Protocol
	Figure 2: Functions in Split MAC with WTP Encryption		Figure 2: Functions in Split MAC with WTP Encryption
	2.2. Split MAC with AC encryption		2.2. Split MAC with AC Encryption
	The functional split for the Split MAC with AC encryption is provided		The functional split for the Split MAC with AC encryption is provided
	in Figure 3. This profile is similar to the Split MAC in [RFC5416]		in Figure 3. This profile is similar to the Split MAC in [RFC5416],
	except that IEEE 802.11 encryption/decryption is at the AC. Since		except that IEEE 802.11 encryption/decryption is at the AC. Since
	fragmentation is always done at the same entity as the encryption, in		fragmentation is always done at the same entity as the encryption, in
	this profile, AC does fragmentation/defragmentation.		this profile, AC does fragmentation/defragmentation.
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Functions | Profile |		| Functions | Profile |
	| | 1 |		| | 1 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |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 |
	+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Function |Power Mgmt | WTP |		| Function |Power Mgmt/ | WTP |
	+ |/Packet Buffering | |		+ |Packet Buffering | |
	| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |Fragmentation | AC |		| |Fragmentation/ | AC |
	+ |/Defragmentation | |		+ |Defragmentation | |
	| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |Assoc/Disassoc/Reassoc | AC |		| |Assoc/Disassoc/Reassoc | AC |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |Classifying | AC |		| |Classifying | AC |
	+ IEEE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+ IEEE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 802.11 QoS |Scheduling | WTP |		| 802.11 QoS |Scheduling | WTP |
	+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |Queuing | WTP |		| |Queuing | WTP |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |IEEE 802.1X/EAP | AC |		| |IEEE 802.1X/EAP | AC |
	+ IEEE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+ IEEE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 802.11 RSN |RSNA Key Management | AC |		| 802.11 RSN |RSNA Key Management | AC |
	+ (WPA2) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+ (WPA2) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |IEEE 802.11 | AC |		| |IEEE 802.11 | AC |
	+ |Encryption/Decryption | |		+ |Encryption/Decryption | |
	|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 3: Functions in Split MAC with AC encryption		Figure 3: Functions in Split MAC with AC encryption
	2.3. IEEE 802.11 MAC Profile Frame Exchange		2.3. IEEE 802.11 MAC Profile Frame Exchange
	An example of message exchange using the IEEE 802.11 MAC Profile		An example of message exchange using the IEEE 802.11 MAC Profile
	message element is shown in Figure 4. The WTP informs the AC of the		message element is shown in Figure 4. The WTP informs the AC of the
	various MAC profiles it supports. This happens either in a Discovery		various MAC Profiles it supports. This happens in either a Discovery
	Request message or the Join Request message. The AC determines the		Request message or the Join Request message. The AC determines the
	appropriate profile and configures the WTP with the profile while		appropriate profile and configures the WTP with the profile while
	configuring the WLAN.		configuring the WLAN.
	+-+-+-+-+-+-+ +-+-+-+-+-+-+		+-+-+-+-+-+-+ +-+-+-+-+-+-+
	| WTP | | AC |		| WTP | | AC |
	+-+-+-+-+-+-+ +-+-+-+-+-+-+		+-+-+-+-+-+-+ +-+-+-+-+-+-+
	|Join Request[Supported IEEE 802.11 |		|Join Request[Supported IEEE 802.11 |
	| MAC Profiles ] |		| MAC Profiles ] |
	|---------------------------------------->|		|---------------------------------------->|
	skipping to change at page 7, line 24		skipping to change at page 8, line 33
	| |		| |
	|IEEE 802.11 WLAN Config. Request [ |		|IEEE 802.11 WLAN Config. Request [ |
	| IEEE 802.11 Add WLAN, |		| IEEE 802.11 Add WLAN, |
	| IEEE 802.11 MAC Profile |		| IEEE 802.11 MAC Profile |
	| ] |		| ] |
	|<----------------------------------------|		|<----------------------------------------|
	| |		| |
	|IEEE 802.11 WLAN Config. Response |		|IEEE 802.11 WLAN Config. Response |
	|---------------------------------------->|		|---------------------------------------->|
	Figure 4: Message Exchange For Negotiating MAC Profile		Figure 4: Message Exchange for Negotiating MAC Profiles
	3. MAC Profile Message Element Definitions		3. MAC Profile Message Element Definitions
	3.1. IEEE 802.11 Supported MAC Profiles		3.1. IEEE 802.11 Supported MAC Profiles
	The IEEE 802.11 Supported MAC Profile message element allows the WTP		The IEEE 802.11 Supported MAC Profile message element allows the WTP
	to communicate the profiles it supports. The Discovery Request		to communicate the profiles it supports. The Discovery Request
	message, Primary Discovery Request message, and Join Request message		message, Primary Discovery Request message, and Join Request message
	may include one such message element.		may include one such message element.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0		0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0
	+=+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-		+=+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
	| Num_Profiles | Profile_1 | Profile_[2..N]..		| Num_Profiles | Profile_1 | Profile_[2..N]..
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
	Figure 5: IEEE 802.11 Supported MAC Profiles		Figure 5: IEEE 802.11 Supported MAC Profiles
	o Type: TBD for IEEE 802.11 Supported MAC Profiles		o Type: 1060 for IEEE 802.11 Supported MAC Profiles
	o Num_Profiles >=1: This refers to number of profiles present in		o Num_Profiles >=1: This refers to the number of profiles present in
	this message element. There must be at least one profile.		this message element. There must be at least one profile.
	o Profile: Each profile is identified by a value specified in		o Profile: Each profile is identified by a value specified in
	Section 3.2.		Section 3.2.
	3.2. IEEE 802.11 MAC Profile		3.2. IEEE 802.11 MAC Profile
	The IEEE 802.11 MAC Profile message element allows the AC to select a		The IEEE 802.11 MAC Profile message element allows the AC to select a
	profile. This message element may be provided along with the IEEE		profile. This message element may be provided along with the IEEE
	802.11 ADD WLAN message element while configuring a WLAN on the WTP.		802.11 ADD WLAN message element while configuring a WLAN on the WTP.
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	skipping to change at page 8, line 18		skipping to change at page 9, line 23
	profile. This message element may be provided along with the IEEE		profile. This message element may be provided along with the IEEE
	802.11 ADD WLAN message element while configuring a WLAN on the WTP.		802.11 ADD WLAN message element while configuring a WLAN on the WTP.
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	+=+-+-+-+-+-+-+-+		+=+-+-+-+-+-+-+-+
	| Profile |		| Profile |
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	Figure 6: IEEE 802.11 MAC Profile		Figure 6: IEEE 802.11 MAC Profile
	o Type: TBD for IEEE 802.11 MAC Profile		o Type: 1061 for IEEE 802.11 MAC Profile
	o Profile: The profile is identified by a value as given below		o Profile: The profile is identified by a value as given below
	* 0: This refers to the Split MAC Profile with WTP encryption		* 0: This refers to the IEEE 802.11 Split MAC Profile with WTP
	* 1: This refers to the Split MAC Profile with AC encryption		encryption
			* 1: This refers to the IEEE 802.11 Split MAC Profile with AC
			encryption
	4. Security Considerations		4. Security Considerations
	This document does not introduce any new security risks compared to		This document does not introduce any new security risks compared to
	[RFC5416]. The negotiation messages between the WTP and AC have		[RFC5416]. The negotiation messages between the WTP and AC have
	origin authentication and data integrity. As a result an attacker		origin authentication and data integrity. As a result, an attacker
	cannot interfere with the messages to force a less secure mode		cannot interfere with the messages to force a less-secure mode
	choice. The security considerations described in [RFC5416] apply		choice. The security considerations described in [RFC5416] apply
	here as well.		here as well.
	5. IANA Considerations		5. IANA Considerations
	This document requires the following IANA actions:		The following IANA actions have been completed.
	o This specification defines two new message elements, IEEE 802.11		o This specification defines two new message elements: IEEE 802.11
	Supported MAC Profiles (described in Section 3.1) and IEEE 802.11		Supported MAC Profiles (described in Section 3.1) and the IEEE
	MAC Profile (described in Section 3.2). These elements needs to		802.11 MAC Profile (described in Section 3.2). These elements
	be registered in the existing CAPWAP Message Element Type		have been registered in the existing "CAPWAP Message Element Type"
	registry, defined in [RFC5415]. The values for these elements		registry, defined in [RFC5415].
	needs to be between 1024 and 2047 (see Section 15.7 in [RFC5415]).
	CAPWAP Protocol Message Element Type Value		CAPWAP Protocol Message Element Type Value
	IEEE 802.11 Supported MAC Profiles TBD1		IEEE 802.11 Supported MAC Profiles 1060
	IEEE 802.11 MAC Profile TBD2		IEEE 802.11 MAC Profile 1061
	o The IEEE 802.11 Supported MAC Profiles message element and IEEE		o The IEEE 802.11 Supported MAC Profiles message element and IEEE
	802.11 MAC Profile message element include a Profile Field (as		802.11 MAC Profile message element include a Profile field (as
	defined in Section 3.2). The Profile field in the IEEE 802.11		defined in Section 3.2). The Profile field in the IEEE 802.11
	Supported MAC Profiles denotes the MAC profiles supported by the		Supported MAC Profiles denotes the MAC Profiles supported by the
	WTP. The profile field in the IEEE MAC profile denotes MAC		WTP. The Profile field in the IEEE 802.11 MAC Profile denotes the
	profile assigned to the WTP. The namespace for the field is 8		MAC Profile assigned to the WTP. The namespace for the field is 8
	bits (0-255). This specification defines two values, zero (0) and		bits (0-255). This specification defines two values: zero (0) and
	one (1) as described below. The remaining values (2-255) are		one (1) as described below. The remaining values (2-255) are
	controlled and maintained by IANA and require an Expert Review.		controlled and maintained by IANA, and the registration procedure
	IANA needs to create a new sub-registry called IEEE 802.11 Split		is Expert Review [RFC5226]. IANA has created a new subregistry
	MAC Profile and add the new sub-registry to the existing registry		called "IEEE 802.11 Split MAC Profile" under the existing registry
	"Control And Provisioning of Wireless Access Points (CAPWAP)		"Control And Provisioning of Wireless Access Points (CAPWAP)
	Parameters". The registry format is given below.		Parameters". The registry format is given below.
	Profile Type Value Reference		Profile Type Value Reference
	Split MAC with WTP encryption 0		Split MAC with WTP encryption 0 RFC 7494
	Split MAC with AC encryption 1		Split MAC with AC encryption 1 RFC 7494
	6. Contributors		6. References
	Yifan Chen chenyifan@chinamobile.com		6.1. Normative References
	Naibao Zhou zhounaibao@chinamobile.com		[IEEE.802.11]
			IEEE, "IEEE Standard for Information Technology -
			Telecommunications and information exchange between
			systems - Local and metropolitan area networks - Specific
			requirements Part 11: Wireless LAN Medium Access Control
			(MAC) and Physical Layer (PHY) Specifications", IEEE Std
			802.11-2012, March 2012,
			<http://standards.ieee.org/about/get/802/802.11.html>.
	7. Acknowledgments		[RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley,
			Ed., "Control And Provisioning of Wireless Access Points
			(CAPWAP) Protocol Specification", RFC 5415, March 2009,
			<http://www.rfc-editor.org/info/rfc5415>.
			[RFC5416] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley,
			Ed., "Control and Provisioning of Wireless Access Points
			(CAPWAP) Protocol Binding for IEEE 802.11", RFC 5416,
			March 2009, <http://www.rfc-editor.org/info/rfc5416>.
			6.2. Informative References
			[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
			IANA Considerations Section in RFCs", BCP 26, RFC 5226,
			May 2008, <http://www.rfc-editor.org/info/rfc5226>.
			Acknowledgments
	The authors are grateful for extremely valuable suggestions from		The authors are grateful for extremely valuable suggestions from
	Dorothy Stanley in developing this specification.		Dorothy Stanley in developing this specification.
	Guidance from management team: Melinda Shore, Scott Bradner, Chris		Guidance from the management team -- Melinda Shore, Scott Bradner,
	Liljenstolpe, Benoit Claise, Joel Jaeggli, Dan Romascanu are highly		Chris Liljenstolpe, Benoit Claise, Joel Jaeggli, and Dan Romascanu --
	appreciated.		is highly appreciated.
	8. Normative References		Contributors
	[RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And		Yifan Chen <chenyifan@chinamobile.com>
	Provisioning of Wireless Access Points (CAPWAP) Protocol
	Specification", RFC 5415, March 2009.
	[RFC5416] Calhoun, P., Montemurro, M., and D. Stanley, "Control and		Naibao Zhou <zhounaibao@chinamobile.com>
	Provisioning of Wireless Access Points (CAPWAP) Protocol
	Binding for IEEE 802.11", RFC 5416, March 2009.
	Authors' Addresses		Authors' Addresses
	Chunju Shao		Chunju Shao
	China Mobile		China Mobile
	No.32 Xuanwumen West Street		No.32 Xuanwumen West Street
	Beijing 100053		Beijing 100053
	China		China
	Email: shaochunju@chinamobile.com		EMail: shaochunju@chinamobile.com
	Hui Deng		Hui Deng
	China Mobile		China Mobile
	No.32 Xuanwumen West Street		No.32 Xuanwumen West Street
	Beijing 100053		Beijing 100053
	China		China
	Email: denghui@chinamobile.com		EMail: denghui@chinamobile.com
	Rajesh S. Pazhyannur		Rajesh S. Pazhyannur
	Cisco Systems		Cisco Systems
	170 West Tasman Drive		170 West Tasman Drive
	San Jose, CA 95134		San Jose, CA 95134
	USA		United States
	Email: rpazhyan@cisco.com
			EMail: rpazhyan@cisco.com
	Farooq Bari		Farooq Bari
	AT&T		AT&T
	7277 164th Ave NE		7277 164th Ave NE
	Redmond WA 98052		Redmond, WA 98052
	USA		United States
	Email: farooq.bari@att.com		EMail: farooq.bari@att.com
	Rong Zhang		Rong Zhang
	China Telecom		China Telecom
	No.109 Zhongshandadao avenue		No.109 Zhongshandadao avenue
	Guangzhou 510630		Guangzhou 510630
	China		China
	Email: zhangr@gsta.com		EMail: zhangr@gsta.com
	Satoru Matsushima		Satoru Matsushima
	SoftBank Telecom		SoftBank Telecom
	1-9-1 Higashi-Shinbashi, Munato-ku		1-9-1 Higashi-Shinbashi, Munato-ku
	Tokyo		Tokyo
	Japan		Japan
	Email: satoru.matsushima@g.softbank.co.jp		EMail: satoru.matsushima@g.softbank.co.jp
End of changes. 58 change blocks.
	135 lines changed or deleted		168 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/