--- 1/draft-ietf-tsvwg-ieee-802-11-02.txt 2017-05-25 08:13:10.092403654 -0700 +++ 2/draft-ietf-tsvwg-ieee-802-11-03.txt 2017-05-25 08:13:10.164405356 -0700 @@ -1,19 +1,19 @@ Transport Working Group T. Szigeti Internet-Draft J. Henry Intended status: Standards Track Cisco Systems -Expires: November 9, 2017 F. Baker - May 8, 2017 +Expires: November 25, 2017 F. Baker + May 24, 2017 Diffserv to IEEE 802.11 Mapping - draft-ietf-tsvwg-ieee-802-11-02 + draft-ietf-tsvwg-ieee-802-11-03 Abstract As internet traffic is increasingly sourced-from and destined-to wireless endpoints, it is crucial that Quality of Service be aligned between wired and wireless networks; however, this is not always the case by default. This document specifies a set Differentiated Services Code Point (DSCP) to IEEE 802.11 User Priority (UP) mappings to reconcile the marking recommendations offered by the IETF and the IEEE so as to maintain consistent QoS treatment between wired and @@ -27,21 +27,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -363,26 +363,26 @@ present document, to be the equivalent of IEEE 802.11. 2. Service Comparison and Default Interoperation of Diffserv and IEEE 802.11 (Section 6 provides a brief overview of IEEE 802.11 QoS.) The following comparisons between IEEE 802.11 and Diffserv services should be noted: - o [IEEE.802.11-2016] does not support a [RFC3246] EF PHB service, as - it is not possible to assure that a given access category will be - serviced with strict priority over another (due to the random + o [IEEE.802.11-2016] does not support an EF PHB service [RFC3246], + as it is not possible to assure that a given access category will + be serviced with strict priority over another (due to the random 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 category will be serviced with a minimum amount of assured bandwidth (due to the non-deterministic nature of the contention process) o [IEEE.802.11-2016] loosely supports a [RFC2474] Default Forwarding service via the Best Effort Access Category (AC_BE) o [IEEE.802.11-2016] loosely supports a [RFC3662] Lower Effort PDB service via the Background Access Category (AC_BK) @@ -474,21 +474,24 @@ In the opposite direction of flow (the upstream direction, that is, 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 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 additional zeros to generate a DSCP value). This derived DSCP value is then used for QoS treatment between the wireless access point and the nearest classification and marking policy enforcement point (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 derived from 3, then information is lost in translation. Servicing differentiation cannot be made for 12 classes of traffic (as 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). Such default upstream mapping can also yield several inconsistencies with [RFC4594], including: @@ -846,21 +850,21 @@ The Standard Service Class loosely corresponds to the [IEEE.802.11-2016] Best Effort Access Category (AC_BK) and therefore it is RECOMMENDED to map Standard Service Class traffic marked DF DSCP to UP 0, thereby admitting it to the Best Effort Access Category (AC_BE). 4.2.10. Low-Priority Data The Low-Priority Data service class serves applications that the user 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 [IEEE.802.11-2016] Background Access Category (AC_BK) and therefore 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). 4.3. DSCP-to-UP Mapping Recommendations Summary Figure 1 summarizes the [RFC4594] DSCP marking recommendations mapped to [IEEE.802.11-2016] UP and access categories applied in the @@ -1000,29 +1004,29 @@ edge, then it is RECOMMENDED to trust DSCP (over [IEEE.802.11-2016] UP markings) markings in the upstream direction, for the following reasons: o [RFC2474], [RFC2475] and [RFC8100] all allow for hosts to set DSCP markings to achieve an end-to-end differentiated service o [IEEE.802.11-2016] does not specify that UP markings are to be used to affect QoS treatment over wired IP networks - o Most wireless device operating systems generate UP values by the - same method as described in Section 2.2 (i.e. by using the 3 MSB - of the encapsulated 6-bit DSCP); then, at the access point, these - 3-bit markings are converted back into DSCP values, typically in - the default manner described in Section 2.3; as such, information - is lost in the translation from a 6-bit marking to a 3-bit marking - (which is then subsequently translated back to a 6-bit marking); - trusting the original (encapsulated) DSCP marking prevents such - loss of information + o Most present wireless device operating systems generate UP values + by the same method as described in Section 2.2 (i.e. by using the + 3 MSB of the encapsulated 6-bit DSCP); then, at the access point, + these 3-bit markings are converted back into DSCP values, + typically in the default manner described in Section 2.3; as such, + information is lost in the translation from a 6-bit marking to a + 3-bit marking (which is then subsequently translated back to a + 6-bit marking); trusting the original (encapsulated) DSCP marking + prevents such loss of information o A practical implementation benefit is also realized by trusting the DSCP set by wireless client devices, as enabling applications to mark DSCP is much more prevalent and accessible to programmers of applications running on wireless device platforms, vis-a-vis trying to explicitly set UP values, which requires special hooks into the wireless device operating system and/or hardware device drivers, many of which do not support such functionality 5.4. Upstream DSCP Marking at the Wireless Access Point @@ -1475,20 +1479,25 @@ Services Code Point (DSCP) for Capacity-Admitted Traffic", RFC 5865, DOI 10.17487/RFC5865, May 2010, . [RFC8100] Geib, R., Ed. and D. Black, "Diffserv-Interconnection Classes and Practice", RFC 8100, DOI 10.17487/RFC8100, March 2017, . 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] "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 Standard 802.11, 2011, . [RFC7561] Kaippallimalil, J., Pazhyannur, R., and P. Yegani,