draft-ietf-tsvwg-ieee-802-11-02.txt		draft-ietf-tsvwg-ieee-802-11-03.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: November 9, 2017 F. Baker		Expires: November 25, 2017 F. Baker
	May 8, 2017		May 24, 2017
	Diffserv to IEEE 802.11 Mapping		Diffserv to IEEE 802.11 Mapping
	draft-ietf-tsvwg-ieee-802-11-02		draft-ietf-tsvwg-ieee-802-11-03
	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
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	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 9, 2017.		This Internet-Draft will expire on November 25, 2017.
	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		(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
	skipping to change at page 8, line 41 ¶		skipping to change at page 8, line 41 ¶
	present document, to be the equivalent of IEEE 802.11.		present document, to be the equivalent of IEEE 802.11.
	2. Service Comparison and Default Interoperation of Diffserv and IEEE		2. Service Comparison and Default Interoperation of Diffserv and IEEE
	802.11		802.11
	(Section 6 provides a brief overview of IEEE 802.11 QoS.)		(Section 6 provides a brief overview of IEEE 802.11 QoS.)
	The following comparisons between IEEE 802.11 and Diffserv services		The following comparisons between IEEE 802.11 and Diffserv services
	should be noted:		should be noted:
	o [IEEE.802.11-2016] does not support a [RFC3246] EF PHB service, as		o [IEEE.802.11-2016] does not support an EF PHB service [RFC3246],
	it is not possible to assure that a given access category will be		as it is not possible to assure that a given access category will
	serviced with strict priority over another (due to the random		be serviced with strict priority over another (due to the random
	element within the contention process)		element within the contention process)
	o [IEEE.802.11-2016] does not support a [RFC2597] AF PHB service,		o [IEEE.802.11-2016] does not support an AF PHB service [RFC2597],
	again because it is not possible to assure that a given access		again because it is not possible to assure that a given access
	category will be serviced with a minimum amount of assured		category will be serviced with a minimum amount of assured
	bandwidth (due to the non-deterministic nature of the contention		bandwidth (due to the non-deterministic nature of the contention
	process)		process)
	o [IEEE.802.11-2016] loosely supports a [RFC2474] Default Forwarding		o [IEEE.802.11-2016] loosely supports a [RFC2474] Default Forwarding
	service via the Best Effort Access Category (AC_BE)		service via the Best Effort Access Category (AC_BE)
	o [IEEE.802.11-2016] loosely supports a [RFC3662] Lower Effort PDB		o [IEEE.802.11-2016] loosely supports a [RFC3662] Lower Effort PDB
	service via the Background Access Category (AC_BK)		service via the Background Access Category (AC_BK)
	skipping to change at page 11, line 8 ¶		skipping to change at page 11, line 8 ¶
	In the opposite direction of flow (the upstream direction, that is,		In the opposite direction of flow (the upstream direction, that is,
	from wireless-to-wired), many APs use what we will refer to as		from wireless-to-wired), many APs use what we will refer to as
	'Default UP-to-DSCP Mapping' (for lack of a better term), wherein		'Default UP-to-DSCP Mapping' (for lack of a better term), wherein
	DSCP values are derived from UP values by multiplying the UP values		DSCP values are derived from UP values by multiplying the UP values
	by 8 (i.e. shifting the 3 UP bits to the left and adding three		by 8 (i.e. shifting the 3 UP bits to the left and adding three
	additional zeros to generate a DSCP value). This derived DSCP value		additional zeros to generate a DSCP value). This derived DSCP value
	is then used for QoS treatment between the wireless access point and		is then used for QoS treatment between the wireless access point and
	the nearest classification and marking policy enforcement point		the nearest classification and marking policy enforcement point
	(which may be the centralized wireless LAN controller, relatively		(which may be the centralized wireless LAN controller, relatively
	deep within the network).		deep within the network). Alternatively, in the case where there is
			no other classification and marking policy enforcement point, then
			this derived DSCP value will be used on the remainder of the Internet
			path.
	It goes without saying that when 6 bits of marking granularity are		It goes without saying that when 6 bits of marking granularity are
	derived from 3, then information is lost in translation. Servicing		derived from 3, then information is lost in translation. Servicing
	differentiation cannot be made for 12 classes of traffic (as		differentiation cannot be made for 12 classes of traffic (as
	recommended in [RFC4594]), but for only 8 (with one of these classes		recommended in [RFC4594]), but for only 8 (with one of these classes
	being reserved for future use (i.e. UP 7 which maps to DSCP CS7).		being reserved for future use (i.e. UP 7 which maps to DSCP CS7).
	Such default upstream mapping can also yield several inconsistencies		Such default upstream mapping can also yield several inconsistencies
	with [RFC4594], including:		with [RFC4594], including:
	skipping to change at page 19, line 9 ¶		skipping to change at page 19, line 9 ¶
	The Standard Service Class loosely corresponds to the		The Standard Service Class loosely corresponds to the
	[IEEE.802.11-2016] Best Effort Access Category (AC_BK) and therefore		[IEEE.802.11-2016] Best Effort Access Category (AC_BK) and therefore
	it is RECOMMENDED to map Standard Service Class traffic marked DF		it is RECOMMENDED to map Standard Service Class traffic marked DF
	DSCP to UP 0, thereby admitting it to the Best Effort Access Category		DSCP to UP 0, thereby admitting it to the Best Effort Access Category
	(AC_BE).		(AC_BE).
	4.2.10. Low-Priority Data		4.2.10. Low-Priority Data
	The Low-Priority Data service class serves applications that the user		The Low-Priority Data service class serves applications that the user
	is willing to accept without service assurances. This service class		is willing to accept without service assurances. This service class
	is specified in [RFC3662].		is specified in [RFC3662] and [I-D.ietf-tsvwg-le-phb].
	The Low-Priority Data service class loosely corresponds to the		The Low-Priority Data service class loosely corresponds to the
	[IEEE.802.11-2016] Background Access Category (AC_BK) and therefore		[IEEE.802.11-2016] Background Access Category (AC_BK) and therefore
	it is RECOMMENDED to map Low-Priority Data traffic marked CS1 DSCP to		it is RECOMMENDED to map Low-Priority Data traffic marked CS1 DSCP to
	UP 1, thereby admitting it to the Background Access Category (AC_BK).		UP 1, thereby admitting it to the Background Access Category (AC_BK).
	4.3. DSCP-to-UP Mapping Recommendations Summary		4.3. DSCP-to-UP Mapping Recommendations Summary
	Figure 1 summarizes the [RFC4594] DSCP marking recommendations mapped		Figure 1 summarizes the [RFC4594] DSCP marking recommendations mapped
	to [IEEE.802.11-2016] UP and access categories applied in the		to [IEEE.802.11-2016] UP and access categories applied in the
	skipping to change at page 22, line 25 ¶		skipping to change at page 22, line 25 ¶
	edge, then it is RECOMMENDED to trust DSCP (over [IEEE.802.11-2016]		edge, then it is RECOMMENDED to trust DSCP (over [IEEE.802.11-2016]
	UP markings) markings in the upstream direction, for the following		UP markings) markings in the upstream direction, for the following
	reasons:		reasons:
	o [RFC2474], [RFC2475] and [RFC8100] all allow for hosts to set DSCP		o [RFC2474], [RFC2475] and [RFC8100] all allow for hosts to set DSCP
	markings to achieve an end-to-end differentiated service		markings to achieve an end-to-end differentiated service
	o [IEEE.802.11-2016] does not specify that UP markings are to be		o [IEEE.802.11-2016] does not specify that UP markings are to be
	used to affect QoS treatment over wired IP networks		used to affect QoS treatment over wired IP networks
	o Most wireless device operating systems generate UP values by the		o Most present wireless device operating systems generate UP values
	same method as described in Section 2.2 (i.e. by using the 3 MSB		by the same method as described in Section 2.2 (i.e. by using the
	of the encapsulated 6-bit DSCP); then, at the access point, these		3 MSB of the encapsulated 6-bit DSCP); then, at the access point,
	3-bit markings are converted back into DSCP values, typically in		these 3-bit markings are converted back into DSCP values,
	the default manner described in Section 2.3; as such, information		typically in the default manner described in Section 2.3; as such,
	is lost in the translation from a 6-bit marking to a 3-bit marking		information is lost in the translation from a 6-bit marking to a
	(which is then subsequently translated back to a 6-bit marking);		3-bit marking (which is then subsequently translated back to a
	trusting the original (encapsulated) DSCP marking prevents such		6-bit marking); trusting the original (encapsulated) DSCP marking
	loss of information		prevents such loss of information
	o A practical implementation benefit is also realized by trusting		o A practical implementation benefit is also realized by trusting
	the DSCP set by wireless client devices, as enabling applications		the DSCP set by wireless client devices, as enabling applications
	to mark DSCP is much more prevalent and accessible to programmers		to mark DSCP is much more prevalent and accessible to programmers
	of applications running on wireless device platforms, vis-a-vis		of applications running on wireless device platforms, vis-a-vis
	trying to explicitly set UP values, which requires special hooks		trying to explicitly set UP values, which requires special hooks
	into the wireless device operating system and/or hardware device		into the wireless device operating system and/or hardware device
	drivers, many of which do not support such functionality		drivers, many of which do not support such functionality
	5.4. Upstream DSCP Marking at the Wireless Access Point		5.4. Upstream DSCP Marking at the Wireless Access Point
	skipping to change at page 33, line 5 ¶		skipping to change at page 32, line 46 ¶
	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>.		<http://www.rfc-editor.org/info/rfc5865>.
	[RFC8100] Geib, R., Ed. and D. Black, "Diffserv-Interconnection		[RFC8100] Geib, R., Ed. and D. Black, "Diffserv-Interconnection
	Classes and Practice", RFC 8100, DOI 10.17487/RFC8100,		Classes and Practice", RFC 8100, DOI 10.17487/RFC8100,
	March 2017, <http://www.rfc-editor.org/info/rfc8100>.		March 2017, <http://www.rfc-editor.org/info/rfc8100>.
	10.2. Informative References		10.2. Informative References
			[I-D.ietf-tsvwg-le-phb]
			Bless, R., "A Lower Effort Per-Hop Behavior (LE PHB)",
			draft-ietf-tsvwg-le-phb-01 (work in progress), February
			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>.
	[RFC7561] Kaippallimalil, J., Pazhyannur, R., and P. Yegani,		[RFC7561] Kaippallimalil, J., Pazhyannur, R., and P. Yegani,
End of changes. 9 change blocks.
	19 lines changed or deleted		27 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/