draft-ietf-opsawg-capwap-hybridmac-00.txt		draft-ietf-opsawg-capwap-hybridmac-01.txt
	Network Working Group C. Shao		Network Working Group C. Shao
	Internet-Draft H. Deng		Internet-Draft H. Deng
	Intended status: Informational China Mobile		Intended status: Standards Track China Mobile
	Expires: November 10, 2013 F. Bari		Expires: April 14, 2014 R. Pazhyannur
			Cisco
			F. Bari
	AT&T		AT&T
	R. Zhang		R. Zhang
	China Telecom		China Telecom
	S. Matsushima		S. Matsushima
	SoftBank Telecom		SoftBank Telecom
	May 09, 2013		October 11, 2013
	Hybrid-MAC Model for CAPWAP		IEEE 802.11 MAC Profile for CAPWAP
	draft-ietf-opsawg-capwap-hybridmac-00		draft-ietf-opsawg-capwap-hybridmac-01
	Abstract		Abstract
	The CAPWAP protocol supports two modes of operation: Split and Local		The CAPWAP protocol defines two modes of operation for IEEE 802.11
	MAC (medium access control), which has been described in		WTPs: Split and Local MAC (medium access control), as described in
	[RFC5415].There are many functions in IEEE 802l.11 MAC layer that		[RFC5415],[RFC5416]. Specifically, [RFC5416] describes in detail the
	have not yet been clearly defined whether they belong to either the		division of labor between WTP and AC in the Split and Local MAC
	WTP (Wireless Termination Points) or the AC (Access Controller)in the		modes. Unfortunately, there are many functions that have not yet
	Split and Local modes. Because different vendors have their own		been clearly defined whether they belong to the WTP or the AC. For
	definition of these two models, depending upon the vendor many MAC		example IEEE 802.11 encryption is specified as located in either in
	layer functions continue to be mapped differently to either the WTP		the AC or the WTP with no clear way to negotiate where it should be
	or AC. If there is no clear definition of split MAC and local MAC,		located. This lack of specification leads to interoperability
	then operators will not only need to perform vendor specific		between AC and WTP when AC and WTP come from different vendors. To
	configurations in their network but will continue to experience		solve this problem, this specification defines the concept of IEEE
	difficulty in interoperating WTPs and ACs from different vendors.		802.11 MAC profile where each profile refers to a table containing an
			unambigous division of labor between WTP and AC. The profile is used
			as follows: the WTP informs the AC of the supported profiles and the
			AC selects the profile when it configures the WTP.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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."
	This Internet-Draft will expire on November 10, 2013.		This Internet-Draft will expire on April 14, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Conventions used in this document . . . . . . . . . . . . . . 3		2. Conventions used in this document . . . . . . . . . . . . . . 4
	3. The difference between Local MAC and Split MAC . . . . . . . 3		3. IEEE MAC Profile Descriptions . . . . . . . . . . . . . . . . 4
	4. Functions in Local MAC and Split MAC . . . . . . . . . . . . 4		3.1. Split MAC Profile . . . . . . . . . . . . . . . . . . . . 4
	5. Hybrid-MAC model recommendation . . . . . . . . . . . . . . . 5		3.2. Local MAC Profile . . . . . . . . . . . . . . . . . . . . 5
	6. Hybrid-MAC model Frames Exchange . . . . . . . . . . . . . . 6		3.3. Hybrid MAC Profile . . . . . . . . . . . . . . . . . . . 6
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 7		3.3.1. Hybrid-MAC model Frames Exchange . . . . . . . . . . 7
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		4. IEEE 802.11 MAC Profile . . . . . . . . . . . . . . . . . . . 8
	9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7		5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	11. Normative References . . . . . . . . . . . . . . . . . . . . 7		7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
			9. Normative References . . . . . . . . . . . . . . . . . . . . 9
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	The CAPWAP protocol supports two modes of operation: Split and Local		The CAPWAP protocol supports two MAC modes of operation: Split and
	MAC (medium access control), which has been described in [RFC5415].In		Local MAC, which has been described in [RFC5415][RFC5416]. In Split
	Split MAC mode, all L2 wireless data and management frames are		MAC mode, all L2 wireless data and management frames are encapsulated
	encapsulated via the CAPWAP protocol and exchanged between the AC and		via the CAPWAP protocol and exchanged between the AC and the WTP.
	the WTP. The Local MAC mode of operation allows for the data frames		The Local MAC mode of operation allows for the data frames to be
	to be either locally bridged or tunneled as 802.3 frames. The latter		either locally bridged or tunneled as 802.3 frames. Unfortunately,
	implies that the WTP performs the 802.11 Integration function.		there are many functions that have not yet been clearly defined
	Unfortunately, there are many functions that have not yet been		whether they belong to either the WTP or the AC in the Split and
	clearly defined whether they belong to either the WTP or the AC in		Local modes. For example IEEE 802.11 encryption is specified as
	the Split and Local modes. Because different vendors have their own		located in either in the AC or the WTP with no clear way to negotiate
	definition of the two models, many MAC layer functions are mapped		where it should be located. Because different vendors have their own
			definition of the MAC mode, many MAC layer functions are mapped
	differently to either the WTP or the AC by different vendors.		differently to either the WTP or the AC by different vendors.
	Therefore, depending upon the vendor, the operators in their		Therefore, depending upon the vendor, the operators in their
	deployments have to perform different configurations based on		deployments have to perform different configurations based on
	implementation of the two modes by their vendor. If there is no		implementation of the two modes by their vendor. If there is no
	clear definition of split MAC and local MAC, then operators will		clear definition of split MAC and local MAC, then operators will
	continue to experience difficulty in interoperating WTPs and ACs from		continue to experience difficulty in interoperating WTPs and ACs from
	different vendors.		different vendors.
	2. Conventions used in this document		Figure 1 quoted from [RFC5416], illustrates how the functions are
			processed in different places in the Local MAC and Split MAC.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT",		Further, for some functions such as the Frag. / Defrag. Assoc. /
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		Disassoc / Reassoc., Encryption the protocol does not explicitly map
	document are to be interpreted as described in [RFC2119].		processing of such functions to the WTP or the AC. Therefore the
			location of these features becomes vendor specific and this increases
	3. The difference between Local MAC and Split MAC		the difficulty of interoperability between WTPs and ACs from
			different vendors.
	The main difference between Local MAC and Split MAC lies in the
	processing of the wireless frames. This is shown in Figure 1 where
	depending upon the mode, either the WTP or the AC performs the 802.11
	Integration function. According to the 802.11 protocol definition,
	the 802.11 wireless frame is divided into three kinds of frames,
	including wireless control frames, wireless management frames, and
	wireless data frames.
	Wireless control frames, such as TS, CTS, ACK, PS-POLL, etc., are
	processed locally by WTP in both Local MAC and Split MAC. However,
	wireless management frames, including Beacon, Probe, Association,
	Authentication, are processed differently in the Local MAC and the
	Split MAC. In the Local MAC, depending upon the vendor wireless
	management frames can be processed in the WTP or the AC. In the case
	of Split MAC, the real-time part of wireless frames are processed in
	WTP, while the non-real-time frames are processed in the AC. This is
	shown in Figure 1 quoted from [RFC5416]. In Split MAC mode, the
	wireless data frames received from a mobile device are directly
	encapsulated by the WTP and forwarded to the AC. The Local MAC mode
	of operation allows data frames to be processed locally by the WTP
	and then forwarded to the AC.
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Local MAC | Split MAC |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| | | 802.3 MAC | |
	+ 802.3 MAC + AC +-+-+-+-+-+-+-+-+- AC +
	| | | 802.11MAC NonRT| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 802.11 MAC | | 802.11 MAC RT | |
	+-+-+-+-+-+-+-+-+ WTP +-+-+-+-+-+-+-+-+- WTP +
	| 802.11 PHY | | 802.11 PHY | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: The comparison between Local MAC and Split MAC
	4. Functions in Local MAC and Split MAC
	As shown in Figure 2 quoted from [RFC5416], main functions are
	processed in different places in the Local MAC and Split MAC. In
	addition, for some functions (for example, the Frag. / Defrag.
	Assoc. / Disassoc / Reassoc., Etc.) the protocol does not
	explicitly map processing of such functions to the WTP or the AC.
	Therefore the location of these features becomes vendor specific and
	this increases the difficulty of interoperability between WTPs and
	ACs from different vendors.
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Functions describe | 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 |
	skipping to change at page 5, line 17		skipping to change at page 4, line 12
	| |Queuing | WTP | WTP |		| |Queuing | WTP | WTP |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |IEEE 802.1X/EWTP | AC | AC |		| |IEEE 802.1X/EWTP | AC | AC |
	+ IEEE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+ IEEE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 802.11 RSN |RSNA Key Management | WTP | AC |		| 802.11 RSN |RSNA Key Management | WTP | AC |
	+ (WPA2) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+ (WPA2) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |IEEE 802.11 | WTP | WTP/AC |		| |IEEE 802.11 | WTP | WTP/AC |
	+ |Encryption/Decryption | | |		+ |Encryption/Decryption | | |
	|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2: Functions in Local MAC and Split MAC		Figure 1: Functions in Local MAC and Split MAC
	5. Hybrid-MAC model recommendation		To allievate the above mentioned problem, this specification
			introduces IEEE MAC profle. The MAC profile unamabigously specifies
			where the various MAC fucntionaity should be located. Further we
			define different MAC profiles based on currently known MAC
			implementations. The WTP may support one or more pfofiles and will
			indicate the supported profiles to the AC. The AC will select a
			profile and configure it the WTP.
	As discussed above, if the functions have been clearly defined to be		2. Conventions used in this document
	implemented in WTP or AC, the interoperability will be much better
	between different vendors products. To achieve this goal a common		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT",
	Hybrid-MAC model, as shown in Figure 3, is proposed.		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in [RFC2119].
			3. IEEE MAC Profile Descriptions
			A IEEE MAC Profile refers to a description of a fucntional split
			between the WTP and AC s shown in Figure 1
			3.1. Split MAC Profile
			The functional split for the Split MAC profile is provided in Figure
			2. The Split MAC profile is identical to the Split MAC mode defined
			in [RFC5416]. Description of various fucntionality is available in
			Section 2.2.1 of [RFC5416].
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Functions describe | Hybrid-MAC|		| Functions | Split MAC |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |Distribution Service | AC |
			+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |Integration Service | AC |
			+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |Beacon Generation | WTP |
			+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |Probe Response Generation| WTP |
			+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Function |Power Mgmt | WTP |
			+ |/Packet Buffering | |
			| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |Fragmentation | WTP/AC |
			+ |/Defragmentation | |
			| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |Assoc/Disassoc/Reassoc | AC |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |Classifying | AC |
			+ IEEE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| 802.11 QoS |Scheduling | WTP/AC |
			+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |Queuing | WTP |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |IEEE 802.1X/EAP | AC |
			+ IEEE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| 802.11 RSN |RSNA Key Management | AC |
			+ (WPA2) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |IEEE 802.11 | WTP/AC |
			+ |Encryption/Decryption | |
			|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Figure 2: Functions in Split MAC
			3.2. Local MAC Profile
			The functional split for the Local MAC profile is provided in Figure
			3. The local MAC profile is identical to the Local MAC mode defined
			in [RFC5416]. Description of various fucntionality is available in
			Section 2.2.2 of [RFC5416].
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Functions | Local MAC |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |Distribution Service | WTP/AC |
			+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |Integration Service | WTP |
			+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |Beacon Generation | WTP |
			+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |Probe Response Generation| WTP |
			+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Function |Power Mgmt | WTP |
			+ |/Packet Buffering | |
			| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |Fragmentation | WTP |
			+ |/Defragmentation | |
			| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |Assoc/Disassoc/Reassoc | WTP/AC |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |Classifying | WTP |
			+ IEEE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| 802.11 QoS |Scheduling | WTP |
			+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |Queuing | WTP |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |IEEE 802.1X/EAP | AC |
			+ IEEE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| 802.11 RSN |RSNA Key Management | AC |
			+ (WPA2) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |IEEE 802.11 | WTP |
			+ |Encryption/Decryption | |
			|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Figure 3: Functions in Local MAC
			3.3. Hybrid MAC Profile
			The functional split for the Hybrid MAC profile is provided in Figure
			4. The Hybrid MAC is similar to the Split MAC except that scheduling
			is done only at the WTP, and IEEE 802.11 encryption/decryption is
			done at the WTP. Note that the Split MAC profile allowed encryption
			to be either at the WTP or the AC.
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Functions | Hybrid MAC|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |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 |
	skipping to change at page 6, line 13		skipping to change at page 7, line 18
	| |Queuing | WTP |		| |Queuing | WTP |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |IEEE 802.1X/EWTP | AC |		| |IEEE 802.1X/EWTP | 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 | |
	|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 3: Functions in Hybrid MAC		Figure 4: Functions in Hybrid MAC
	6. Hybrid-MAC model Frames Exchange		3.3.1. Hybrid-MAC model Frames Exchange
	An example of frame exchange using the proposed Hybrid-MAC Model		An example of frame exchange using the proposed Hybrid-MAC Model
	shown in Figure 4.		shown in Figure 5.
	+-+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+-+		+-+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+-+
	| STA | | WTP | | AC |		| STA | | WTP | | AC |
	+-+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+-+		+-+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+-+
	| | |		| | |
	| Beacon | |		| Beacon | |
	|<-------------------------| |		|<-------------------------| |
	| Probe | |		| Probe | |
	|<------------------------>| |		|<------------------------>| |
	| 802.11 AUTH/Association |		| 802.11 AUTH/Association |
	skipping to change at page 7, line 8		skipping to change at page 8, line 12
	| |<------------------------------|		| |<------------------------------|
	| | |		| | |
	| |Station Configuration Response |		| |Station Configuration Response |
	| |------------------------------>|		| |------------------------------>|
	| 802.11 Action Frames |		| 802.11 Action Frames |
	|<-------------------------------------------------------->|		|<-------------------------------------------------------->|
	| DATA Frame Exchange |		| DATA Frame Exchange |
	| 802.11 Data | 802.11 or 802.3 Data |		| 802.11 Data | 802.11 or 802.3 Data |
	|<-------------------------+------------------------------>|		|<-------------------------+------------------------------>|
	Figure 4: Hybrid-MAC model Frames Exchange		Figure 5: Hybrid-MAC model Frames Exchange
	7. Security Considerations		4. IEEE 802.11 MAC Profile
			The IEEE 802.11 WTP Profile message element allows the WTP to
			communicate the profile it supports to the AC. The Discovery Request
			message, Primary Discovery Request message, and Join Request message
			may include one such message element
			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
			+=+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
			| Num_Profiles | Profile_1 | Profile_[2..N]..
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
			Figure 6: IEEE 802.11 MAC Profile
			o Type: TBD for IEEE 802.11 MAC Profile
			o Num_Profiles >=1: This refers to number of profiles presnt in this
			messaage element. There must be at least one profile.
			o Profile: Each profile is idnentified by a value as given below
			* 0: This refers to the Local MAC Profile described in
			Section 3.2
			* 1: This refers to the Split MAC Profile described in
			Section 3.1
			* 2: This refers to the Hybrid MAC Profile described in
			Section 3.3
			5. Security Considerations
	This document doesn't specify security risk difference from		This document doesn't specify security risk difference from
	[RFC5416]. It could directly refer to Security section of [RFC5416]		[RFC5416]. It could directly refer to Security section of [RFC5416]
	8. IANA Considerations		6. IANA Considerations
	This document make no request for IANA registration.		This document requires the following IANA actions.
	9. Contributors		o This specification defines a new message element, IEEE 802.11 MAC
			Profile. The format of this option is described in Section 3.3.
			Type value for this option needs to be assigned from the same
			numbering space as allocated for the other IEEE 802.11 message
			elements as defined in [RFC5416] in the CAPWAP IEEE 802.11 Message
			Types sub-registry
			o The Profile field in the IEEE 802.11 MAC Profile Type message
			element (see Figure 6) The namespace is 8 bits (0-255), where the
			value of zero (0) through two (2) are allocated in this
			specification, and can be found in Figure 6. This namespace is
			managed by IANA and assignments require an Expert Review under the
			registry IEEE 802.11 MAC Profile for CAPWAP
			7. Contributors
			Yifan Chen chenyifan@chinamobile.com
	Naibao Zhou zhounaibao@chinamobile.com		Naibao Zhou zhounaibao@chinamobile.com
	10. Acknowledgments		8. Acknowledgments
	The author thanks the kind advices from Dorothy Stanley in the		The author thanks the kind advices from Dorothy Stanley in the
	development of this document.		development of this document.
	The efforts of Margaret Wasserman, Wes George in reviewing this		The efforts of Margaret Wasserman, Wes George in reviewing this
	document are gratefully acknowledged.		document are gratefully acknowledged.
	Guidance from management team: Melinda Shore, Scott Bradner, Chris		Guidance from management team: Melinda Shore, Scott Bradner, Chris
	Liljenstolpe, Benoit Claise, Joel Jaeggli, Romascanu Dan are highly		Liljenstolpe, Benoit Claise, Joel Jaeggli, Romascanu Dan are highly
	appreciated.		appreciated.
	11. Normative References		9. Normative References
	[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.
	[RFC4564] Govindan, S., Cheng, H., Yao, ZH., Zhou, WH., and L. Yang,		[RFC4564] Govindan, S., Cheng, H., Yao, ZH., Zhou, WH., and L. Yang,
	"Objectives for Control and Provisioning of Wireless		"Objectives for Control and Provisioning of Wireless
	Access Points (CAPWAP)", RFC 4564, July 2006.		Access Points (CAPWAP)", RFC 4564, July 2006.
	[RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And		[RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And
	Provisioning of Wireless Access Points (CAPWAP) Protocol		Provisioning of Wireless Access Points (CAPWAP) Protocol
	skipping to change at page 8, line 23		skipping to change at page 10, line 27
	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
			Cisco
			170 West Tasman Drive
			San Jose, CA 95134
			USA
			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		USA
	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
End of changes. 25 change blocks.
	113 lines changed or deleted		228 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/