draft-ietf-tsvwg-ieee-802-11-06.txt		draft-ietf-tsvwg-ieee-802-11-07.txt
	Transport Working Group T. Szigeti		Transport Working Group T. Szigeti
	Internet-Draft J. Henry		Internet-Draft J. Henry
	Intended status: Standards Track Cisco Systems		Intended status: Standards Track Cisco Systems
	Expires: February 17, 2018 F. Baker		Expires: March 12, 2018 F. Baker
	August 16, 2017		September 8, 2017
	Diffserv to IEEE 802.11 Mapping		Diffserv to IEEE 802.11 Mapping
	draft-ietf-tsvwg-ieee-802-11-06		draft-ietf-tsvwg-ieee-802-11-07
	Abstract		Abstract
	As internet traffic is increasingly sourced-from and destined-to		As internet traffic is increasingly sourced-from and destined-to
	wireless endpoints, it is crucial that Quality of Service be aligned		wireless endpoints, it is crucial that Quality of Service be aligned
	between wired and wireless networks; however, this is not always the		between wired and wireless networks; however, this is not always the
	case by default. This document specifies a set Differentiated		case by default. This document specifies a set Differentiated
	Services Code Point (DSCP) to IEEE 802.11 User Priority (UP) mappings		Services Code Point (DSCP) to IEEE 802.11 User Priority (UP) mappings
	to reconcile the marking recommendations offered by the IETF and the		to reconcile the marking recommendations offered by the IETF and the
	IEEE so as to maintain consistent QoS treatment between wired and		IEEE so as to maintain consistent QoS treatment between wired and
	IEEE 802.11 wireless networks.		IEEE 802.11 wireless networks.
	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 https://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 February 17, 2018.		This Internet-Draft will expire on March 12, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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		(https://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 . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	skipping to change at page 5, line 47 ¶		skipping to change at page 5, line 47 ¶
	the shared, half-duplex nature of the wireless medium.		the shared, half-duplex nature of the wireless medium.
	o Section 7 on notes IANA considerations		o Section 7 on notes IANA considerations
	o Section 8 presents security considerations relative to DSCP-to-UP,		o Section 8 presents security considerations relative to DSCP-to-UP,
	UP-to-DSCP mapping and remarking		UP-to-DSCP mapping and remarking
	1.5. Requirements Language		1.5. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL", and "NOT		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	RECOMMENDED" in this document are to be interpreted as described in		document are to be interpreted as described in [RFC2119].
	[RFC2119].
	1.6. Terminology Used in this Document		1.6. Terminology Used in this Document
	Key terminology used in this document includes:		Key terminology used in this document includes:
	AC: Access Category. A label for the common set of enhanced		AC: Access Category. A label for the common set of enhanced
	distributed channel access (EDCA) parameters that are used by a		distributed channel access (EDCA) parameters that are used by a
	quality-of-service (QoS) station (STA) to contend for the channel		quality-of-service (QoS) station (STA) to contend for the channel
	in order to transmit medium access control (MAC) service data		in order to transmit medium access control (MAC) service data
	units (MSDUs) with certain priorities. [IEEE.802.11-2016]		units (MSDUs) with certain priorities. [IEEE.802.11-2016]
	skipping to change at page 8, line 28 ¶		skipping to change at page 8, line 28 ¶
	typically extended at Layer 3 (by accepting the DSCP), but may		typically extended at Layer 3 (by accepting the DSCP), but may
	also be extended at lower layers, such as at Layer 2 by accepting		also be extended at lower layers, such as at Layer 2 by accepting
	User Priority markings. For example, if an access point is		User Priority markings. For example, if an access point is
	configured to trust DSCP markings and it receives a packet marked		configured to trust DSCP markings and it receives a packet marked
	EF, then it would treat the packet with the Expedite Forwarding		EF, then it would treat the packet with the Expedite Forwarding
	PHB and propagate the EF marking value (DSCP 46) as it transmits		PHB and propagate the EF marking value (DSCP 46) as it transmits
	the packet. Alternatively, if a network device is configured to		the packet. Alternatively, if a network device is configured to
	operate in an untrusted manner, then it would remark packets as		operate in an untrusted manner, then it would remark packets as
	these entered the device, typically to DF (or to a different		these entered the device, typically to DF (or to a different
	marking value at the network administrator's preference). Note:		marking value at the network administrator's preference). Note:
	The terms "trusted" and "untrusted" are used extensively in RFC		The terms "trusted" and "untrusted" are used extensively in
	4594.		[RFC4594].
	UP: User Priority. A value associated with a medium access		UP: User Priority. A value associated with a medium access
	control (MAC) service data unit (MSDU) that indicates how the MSDU		control (MAC) service data unit (MSDU) that indicates how the MSDU
	is to be handled. The UP is assigned to an MSDU in the layers		is to be handled. The UP is assigned to an MSDU in the layers
	above the MAC [IEEE.802.11-2016] Section 3.1. The UP defines a		above the MAC [IEEE.802.11-2016] Section 3.1. The UP defines a
	level of priority for the associated frame, on a scale of 0 to 7.		level of priority for the associated frame, on a scale of 0 to 7.
	Wi-Fi: An interoperability certification defined by the Wi-Fi		Wi-Fi: An interoperability certification defined by the Wi-Fi
	Alliance. However, this term is commonly used, including in the		Alliance. However, this term is commonly used, including in the
	present document, to be the equivalent of IEEE 802.11.		present document, to be the equivalent of IEEE 802.11.
	skipping to change at page 14, line 26 ¶		skipping to change at page 14, line 26 ¶
	protocols, again, per [RFC4594] Section 3.2.		protocols, again, per [RFC4594] Section 3.2.
	By default (as described in Section 2.2), packets marked DSCP CS7		By default (as described in Section 2.2), packets marked DSCP CS7
	will be mapped to UP 7 and serviced within the Voice Access Category		will be mapped to UP 7 and serviced within the Voice Access Category
	(AC_VO). This represents the RECOMMENDED mapping for CS7, that is,		(AC_VO). This represents the RECOMMENDED mapping for CS7, that is,
	packets marked to CS7 DSCP are RECOMMENDED to be mapped to UP 7.		packets marked to CS7 DSCP are RECOMMENDED to be mapped to UP 7.
	However, by default (as described in Section 2.2), packets marked		However, by default (as described in Section 2.2), packets marked
	DSCP CS6 will be mapped to UP 6 and serviced within the Voice Access		DSCP CS6 will be mapped to UP 6 and serviced within the Voice Access
	Category (AC_VO); such mapping and servicing is a contradiction to		Category (AC_VO); such mapping and servicing is a contradiction to
	the intent expressed in [RFC 4594] section 3.2. As such, it is		the intent expressed in [RFC4594] Section 3.2. As such, it is
	RECOMMENDED to map Network Control traffic marked CS6 to UP 7 (per		RECOMMENDED to map Network Control traffic marked CS6 to UP 7 (per
	[IEEE.802.11-2016] Section 10.2.4.2, Table 10-1), thereby admitting		[IEEE.802.11-2016] Section 10.2.4.2, Table 10-1), thereby admitting
	it to the Voice Access Category (AC_VO), albeit with a marking		it to the Voice Access Category (AC_VO), albeit with a marking
	distinguishing it from (data-plane) voice traffic.		distinguishing it from (data-plane) voice traffic.
	It should be noted that encapsulated routing protocols for		It should be noted that encapsulated routing protocols for
	encapsulated or overlay networks (e.g., VPN, NVO3) are not network		encapsulated or overlay networks (e.g., VPN, NVO3) are not network
	control traffic for any physical network at the AP, and hence SHOULD		control traffic for any physical network at the AP, and hence SHOULD
	NOT be marked with CS6 in the first place.		NOT be marked with CS6 in the first place.
	skipping to change at page 33, line 23 ¶		skipping to change at page 33, line 23 ¶
	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, 2016,		Layer (PHY) specifications", IEEE Standard 802.11, 2016,
	<https://standards.ieee.org/findstds/		<https://standards.ieee.org/findstds/
	standard/802.11-2016.html>.		standard/802.11-2016.html>.
	[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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,		[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
	"Definition of the Differentiated Services Field (DS		"Definition of the Differentiated Services Field (DS
	Field) in the IPv4 and IPv6 Headers", RFC 2474,		Field) in the IPv4 and IPv6 Headers", RFC 2474,
	DOI 10.17487/RFC2474, December 1998,		DOI 10.17487/RFC2474, December 1998,
	<http://www.rfc-editor.org/info/rfc2474>.		<https://www.rfc-editor.org/info/rfc2474>.
	[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
	and W. Weiss, "An Architecture for Differentiated
	Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
	<http://www.rfc-editor.org/info/rfc2475>.
	[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,		[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
	"Assured Forwarding PHB Group", RFC 2597,		"Assured Forwarding PHB Group", RFC 2597,
	DOI 10.17487/RFC2597, June 1999,		DOI 10.17487/RFC2597, June 1999,
	<http://www.rfc-editor.org/info/rfc2597>.		<https://www.rfc-editor.org/info/rfc2597>.
	[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition		[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
	of Explicit Congestion Notification (ECN) to IP",		of Explicit Congestion Notification (ECN) to IP",
	RFC 3168, DOI 10.17487/RFC3168, September 2001,		RFC 3168, DOI 10.17487/RFC3168, September 2001,
	<http://www.rfc-editor.org/info/rfc3168>.		<https://www.rfc-editor.org/info/rfc3168>.
	[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,		[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,
	J., Courtney, W., Davari, S., Firoiu, V., and D.		J., Courtney, W., Davari, S., Firoiu, V., and D.
	Stiliadis, "An Expedited Forwarding PHB (Per-Hop		Stiliadis, "An Expedited Forwarding PHB (Per-Hop
	Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002,		Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002,
	<http://www.rfc-editor.org/info/rfc3246>.		<https://www.rfc-editor.org/info/rfc3246>.
	[RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort		[RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort
	Per-Domain Behavior (PDB) for Differentiated Services",		Per-Domain Behavior (PDB) for Differentiated Services",
	RFC 3662, DOI 10.17487/RFC3662, December 2003,		RFC 3662, DOI 10.17487/RFC3662, December 2003,
	<http://www.rfc-editor.org/info/rfc3662>.		<https://www.rfc-editor.org/info/rfc3662>.
	[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration		[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
	Guidelines for DiffServ Service Classes", RFC 4594,		Guidelines for DiffServ Service Classes", RFC 4594,
	DOI 10.17487/RFC4594, August 2006,		DOI 10.17487/RFC4594, August 2006,
	<http://www.rfc-editor.org/info/rfc4594>.		<https://www.rfc-editor.org/info/rfc4594>.
	[RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of
	Diffserv Service Classes", RFC 5127, DOI 10.17487/RFC5127,
	February 2008, <http://www.rfc-editor.org/info/rfc5127>.
	[RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated		[RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated
	Services Code Point (DSCP) for Capacity-Admitted Traffic",		Services Code Point (DSCP) for Capacity-Admitted Traffic",
	RFC 5865, DOI 10.17487/RFC5865, May 2010,		RFC 5865, DOI 10.17487/RFC5865, May 2010,
	<http://www.rfc-editor.org/info/rfc5865>.		<https://www.rfc-editor.org/info/rfc5865>.
	[RFC8100] Geib, R., Ed. and D. Black, "Diffserv-Interconnection
	Classes and Practice", RFC 8100, DOI 10.17487/RFC8100,
	March 2017, <http://www.rfc-editor.org/info/rfc8100>.
	10.2. Informative References		10.2. Informative References
	[I-D.ietf-tsvwg-le-phb]		[I-D.ietf-tsvwg-le-phb]
	Bless, R., "A Lower Effort Per-Hop Behavior (LE PHB)",		Bless, R., "A Lower Effort Per-Hop Behavior (LE PHB)",
	draft-ietf-tsvwg-le-phb-02 (work in progress), June 2017.		draft-ietf-tsvwg-le-phb-02 (work in progress), June 2017.
	[IEEE.802-11u.2011]		[IEEE.802-11u.2011]
	"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, 2011,		Layer (PHY) specifications", IEEE Standard 802.11, 2011,
	<http://standards.ieee.org/getieee802/		<http://standards.ieee.org/getieee802/
	download/802.11u-2011.pdf>.		download/802.11u-2011.pdf>.
			[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
			and W. Weiss, "An Architecture for Differentiated
			Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
			<https://www.rfc-editor.org/info/rfc2475>.
			[RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of
			Diffserv Service Classes", RFC 5127, DOI 10.17487/RFC5127,
			February 2008, <https://www.rfc-editor.org/info/rfc5127>.
	[RFC7561] Kaippallimalil, J., Pazhyannur, R., and P. Yegani,		[RFC7561] Kaippallimalil, J., Pazhyannur, R., and P. Yegani,
	"Mapping Quality of Service (QoS) Procedures of Proxy		"Mapping Quality of Service (QoS) Procedures of Proxy
	Mobile IPv6 (PMIPv6) and WLAN", RFC 7561,		Mobile IPv6 (PMIPv6) and WLAN", RFC 7561,
	DOI 10.17487/RFC7561, June 2015,		DOI 10.17487/RFC7561, June 2015,
	<http://www.rfc-editor.org/info/rfc7561>.		<https://www.rfc-editor.org/info/rfc7561>.
			[RFC8100] Geib, R., Ed. and D. Black, "Diffserv-Interconnection
			Classes and Practice", RFC 8100, DOI 10.17487/RFC8100,
			March 2017, <https://www.rfc-editor.org/info/rfc8100>.
	Appendix A. Change Log		Appendix A. Change Log
	Initial Version: July 2015		Initial Version: July 2015
	Authors' Addresses		Authors' Addresses
	Tim Szigeti		Tim Szigeti
	Cisco Systems		Cisco Systems
	Vancouver, British Columbia V6K 3L4		Vancouver, British Columbia V6K 3L4
End of changes. 18 change blocks.
	34 lines changed or deleted		33 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/