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/