--- 1/draft-ietf-tsvwg-ieee-802-11-07.txt 2017-09-15 18:13:07.343689900 -0700 +++ 2/draft-ietf-tsvwg-ieee-802-11-08.txt 2017-09-15 18:13:07.415691636 -0700 @@ -1,47 +1,47 @@ Transport Working Group T. Szigeti Internet-Draft J. Henry Intended status: Standards Track Cisco Systems -Expires: March 12, 2018 F. Baker - September 8, 2017 +Expires: March 19, 2018 F. Baker + September 15, 2017 Diffserv to IEEE 802.11 Mapping - draft-ietf-tsvwg-ieee-802-11-07 + draft-ietf-tsvwg-ieee-802-11-08 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 + case by default. This document specifies a set of 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 IEEE 802.11 wireless networks. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 https://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 March 12, 2018. + This Internet-Draft will expire on March 19, 2018. 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -82,21 +82,21 @@ 4.2.8. High-Throughput Data . . . . . . . . . . . . . . . . 18 4.2.9. Standard Service Class . . . . . . . . . . . . . . . 18 4.2.10. Low-Priority Data . . . . . . . . . . . . . . . . . . 19 4.3. DSCP-to-UP Mapping Recommendations Summary . . . . . . . 19 5. Upstream Mapping and Marking Recommendations . . . . . . . . 20 5.1. Upstream DSCP-to-UP Mapping within the Wireless Client Operating System . . . . . . . . . . . . . . . . . . . . 21 5.2. Upstream UP-to-DSCP Mapping at the Wireless Access Point 21 5.3. Upstream DSCP-Passthrough at the Wireless Access Point . 22 5.4. Upstream DSCP Marking at the Wireless Access Point . . . 23 - 6. Appendix: IEEE 802.11 QoS Overview . . . . . . . . . . . . . 23 + 6. IEEE 802.11 QoS Overview . . . . . . . . . . . . . . . . . . 23 6.1. Distributed Coordination Function (DCF) . . . . . . . . . 23 6.1.1. Slot Time . . . . . . . . . . . . . . . . . . . . . . 24 6.1.2. Interframe Spaces . . . . . . . . . . . . . . . . . . 24 6.1.3. Contention Windows . . . . . . . . . . . . . . . . . 25 6.2. Hybrid Coordination Function (HCF) . . . . . . . . . . . 26 6.2.1. User Priority (UP) . . . . . . . . . . . . . . . . . 26 6.2.2. Access Category (AC) . . . . . . . . . . . . . . . . 26 6.2.3. Arbitration Inter-Frame Space (AIFS) . . . . . . . . 27 6.2.4. Access Category Contention Windows (CW) . . . . . . . 28 @@ -159,30 +159,31 @@ with each traffic type. As such, this document draws heavily on [RFC4594], as well as [RFC5127], and [RFC8100]. In turn, the relevant standard for wireless QoS is IEEE 802.11, which is being progressively updated; the current version of which (at the time of writing) is [IEEE.802.11-2016]. 1.2. Interaction with RFC 7561 There is also a recommendation from the Global System for Mobile - Communications Association (GSMA), specifically their Mapping Quality - of Service (QoS) Procedures of Proxy Mobile IPv6 (PMIPv6) and WLAN - [RFC7561] specification. This GSMA specification was developed - without reference to existing IETF specifications for various - services, referenced in Section 1.1. Thus, [RFC7561] conflicts with - the overall Diffserv traffic-conditioning service plan, both in the - services specified and the code points specified for them. As such, - these two plans cannot be normalized. Rather, as discussed in - [RFC2474] Section 2, the two domains (IEEE 802.11 and GSMA) are - different Differentiated Services Domains separated by a + Communications Association (GSMA) on DSCP to UP Mapping, specifically + their Guidelines for IPX Provider networks [GSMA-IPX_Guidelines]. + These GSMA Guidelines were developed without reference to existing + IETF specifications for various services, referenced in Section 1.1. + In turn, [RFC7561] was written based on these GSMA Guidelines, as + explicitly called out in [RFC7561] Section 4.2. Thus, [RFC7561] + conflicts with the overall Diffserv traffic-conditioning service + plan, both in the services specified and the code points specified + for them. As such, these two plans cannot be normalized. Rather, as + discussed in [RFC2474] Section 2, the two domains (IEEE 802.11 and + GSMA) are different Differentiated Services Domains separated by a Differentiated Services Boundary. At that boundary, code points from one domain are translated to code points for the other, and maybe to Default (zero) if there is no corresponding service to translate to. 1.3. Applicability Statement This document is applicable to the use of Differentiated Services that interconnect with IEEE 802.11 wireless LANs (referred to as Wi- Fi, throughout this document, for simplicity). These guidelines are applicable whether the wireless access points (APs) are deployed in @@ -540,22 +541,22 @@ which it is not intended The following sections address these limitations and concerns in order to reconcile [RFC4594] and [IEEE.802.11-2016]. First downstream (wired-to-wireless) DSCP-to-UP mappings will be aligned and then upstream (wireless-to-wired) models will be addressed. 3. Wireless Device Marking and Mapping Capability Recommendations This document assumes and RECOMMENDS that all wireless access points - (as the bridges between wired-and-wireless networks) support the - ability to: + (as the interconnects between wired-and-wireless networks) support + the ability to: o mark DSCP, per Diffserv standards o mark UP, per the [IEEE.802.11-2016] standard o support fully-configurable mappings between DSCP and UP o process DSCP markings set by wireless endpoint devices This document further assumes and RECOMMENDS that all wireless @@ -930,21 +931,21 @@ | High- | AF11 | | | | | Throughput | AF12 | RFC2597 | 0 | AC_BE (Best Effort)| | Data | AF13 | | | | +---------------+------+---------+-------------+--------------------+ | Standard | DF | RFC2474 | 0 | AC_BE (Best Effort)| +---------------+------+---------+-------------+--------------------+ | Low-Priority | CS1 | RFC3662 | 1 | AC_BK (Background) | | Data | | | | | +-------------------------------------------------------------------+ - Note: All unusued codepoints are recommended to be mapped to UP 0 + Note: All unused codepoints are recommended to be mapped to UP 0 (See Security Considerations Section - Section 8) Figure 1: Summary of Downstream DSCP to IEEE 802.11 UP and AC Mapping Recommendations 5. Upstream Mapping and Marking Recommendations In the upstream direction (i.e. wireless-to-wired), there are three types of mapping that may be implemented: @@ -1073,21 +1074,21 @@ An alternative option to mapping is for the administrator to treat the wireless edge as the edge of the Diffserv domain and explicitly set (or reset) DSCP markings in the upstream direction according to administrative policy. This option is RECOMMENDED over mapping, as this typically is the most secure solution, as the network administrator directly enforces the Diffserv policy across the IP network (versus an application developer and/or the wireless endpoint device operating system developer, who may be functioning completely independently of the network administrator). -6. Appendix: IEEE 802.11 QoS Overview +6. IEEE 802.11 QoS Overview QoS is enabled on wireless networks by means of the Hybrid Coordination Function (HCF). To give better context to the enhancements in HCF that enable QoS, it may be helpful to begin with a review of the original Distributed Coordination Function (DCF). 6.1. Distributed Coordination Function (DCF) As has been noted, the Wi-Fi medium is a shared medium, with each station-including the wireless access point-contending for the medium @@ -1484,28 +1485,28 @@ all other traffic classes on the WLAN to be starved, as well hijacking queues on the wired IP network that are intended for the servicing of routing protocols. To this point, it was also recommended in Section 5.1 that packets requesting a marking of CS6 or CS7 DSCP SHOULD be remarked to DSCP 0 and mapped to UP 0 by the wireless client operating system. Finally, it should be noted that the recommendations put forward in this document are not intended to address all attack vectors leveraging QoS marking abuse. Mechanisms that may further help - mitigate security risks include strong device- and/or user- - authentication, access-control, rate limiting, control-plane - policing, encryption and other techniques; however, the - implementation recommendations for such mechanisms are beyond the - scope of this document to address in detail. Suffice it to say that - the security of the devices and networks implementing QoS, including - QoS mapping between wired and wireless networks, SHOULD be considered - in actual deployments. + mitigate security risks of both wired and wireless networks deploying + QoS include strong device- and/or user-authentication, access- + control, rate limiting, control-plane policing, encryption and other + techniques; however, the implementation recommendations for such + mechanisms are beyond the scope of this document to address in + detail. Suffice it to say that the security of the devices and + networks implementing QoS, including QoS mapping between wired and + wireless networks, SHOULD be considered in actual deployments. 9. Acknowledgements The authors wish to thank David Black, Gorry Fairhurst, Ruediger Geib, Vincent Roca, Brian Carpenter, David Blake, Cullen Jennings, David Benham and the TSVWG. The authors also acknowledge a great many inputs, notably from David Kloper, Mark Montanez, Glen Lavers, Michael Fingleton, Sarav Radhakrishnan, Karthik Dakshinamoorthy, Simone Arena, Ranga Marathe, @@ -1561,20 +1562,27 @@ DOI 10.17487/RFC4594, August 2006, . [RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic", RFC 5865, DOI 10.17487/RFC5865, May 2010, . 10.2. Informative References + [GSMA-IPX_Guidelines] + "Guidelines for IPX Provider networks (Previously Inter- + Service Provider IP Backbone Guidelines) Version 11.0", + GSMA Official Document, November 2014, + . + [I-D.ietf-tsvwg-le-phb] Bless, R., "A Lower Effort Per-Hop Behavior (LE PHB)", draft-ietf-tsvwg-le-phb-02 (work in progress), June 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,