draft-ietf-tsvwg-ieee-802-11-07.txt   draft-ietf-tsvwg-ieee-802-11-08.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: March 12, 2018 F. Baker Expires: March 19, 2018 F. Baker
September 8, 2017 September 15, 2017
Diffserv to IEEE 802.11 Mapping Diffserv to IEEE 802.11 Mapping
draft-ietf-tsvwg-ieee-802-11-07 draft-ietf-tsvwg-ieee-802-11-08
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 of 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 https://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 March 12, 2018. This Internet-Draft will expire on March 19, 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
(https://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
skipping to change at page 2, line 47 skipping to change at page 2, line 47
4.2.8. High-Throughput Data . . . . . . . . . . . . . . . . 18 4.2.8. High-Throughput Data . . . . . . . . . . . . . . . . 18
4.2.9. Standard Service Class . . . . . . . . . . . . . . . 18 4.2.9. Standard Service Class . . . . . . . . . . . . . . . 18
4.2.10. Low-Priority Data . . . . . . . . . . . . . . . . . . 19 4.2.10. Low-Priority Data . . . . . . . . . . . . . . . . . . 19
4.3. DSCP-to-UP Mapping Recommendations Summary . . . . . . . 19 4.3. DSCP-to-UP Mapping Recommendations Summary . . . . . . . 19
5. Upstream Mapping and Marking Recommendations . . . . . . . . 20 5. Upstream Mapping and Marking Recommendations . . . . . . . . 20
5.1. Upstream DSCP-to-UP Mapping within the Wireless Client 5.1. Upstream DSCP-to-UP Mapping within the Wireless Client
Operating System . . . . . . . . . . . . . . . . . . . . 21 Operating System . . . . . . . . . . . . . . . . . . . . 21
5.2. Upstream UP-to-DSCP Mapping at the Wireless Access Point 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.3. Upstream DSCP-Passthrough at the Wireless Access Point . 22
5.4. Upstream DSCP Marking at the Wireless Access Point . . . 23 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. Distributed Coordination Function (DCF) . . . . . . . . . 23
6.1.1. Slot Time . . . . . . . . . . . . . . . . . . . . . . 24 6.1.1. Slot Time . . . . . . . . . . . . . . . . . . . . . . 24
6.1.2. Interframe Spaces . . . . . . . . . . . . . . . . . . 24 6.1.2. Interframe Spaces . . . . . . . . . . . . . . . . . . 24
6.1.3. Contention Windows . . . . . . . . . . . . . . . . . 25 6.1.3. Contention Windows . . . . . . . . . . . . . . . . . 25
6.2. Hybrid Coordination Function (HCF) . . . . . . . . . . . 26 6.2. Hybrid Coordination Function (HCF) . . . . . . . . . . . 26
6.2.1. User Priority (UP) . . . . . . . . . . . . . . . . . 26 6.2.1. User Priority (UP) . . . . . . . . . . . . . . . . . 26
6.2.2. Access Category (AC) . . . . . . . . . . . . . . . . 26 6.2.2. Access Category (AC) . . . . . . . . . . . . . . . . 26
6.2.3. Arbitration Inter-Frame Space (AIFS) . . . . . . . . 27 6.2.3. Arbitration Inter-Frame Space (AIFS) . . . . . . . . 27
6.2.4. Access Category Contention Windows (CW) . . . . . . . 28 6.2.4. Access Category Contention Windows (CW) . . . . . . . 28
skipping to change at page 4, line 28 skipping to change at page 4, line 28
with each traffic type. As such, this document draws heavily on with each traffic type. As such, this document draws heavily on
[RFC4594], as well as [RFC5127], and [RFC8100]. [RFC4594], as well as [RFC5127], and [RFC8100].
In turn, the relevant standard for wireless QoS is IEEE 802.11, which In turn, the relevant standard for wireless QoS is IEEE 802.11, which
is being progressively updated; the current version of which (at the is being progressively updated; the current version of which (at the
time of writing) is [IEEE.802.11-2016]. time of writing) is [IEEE.802.11-2016].
1.2. Interaction with RFC 7561 1.2. Interaction with RFC 7561
There is also a recommendation from the Global System for Mobile There is also a recommendation from the Global System for Mobile
Communications Association (GSMA), specifically their Mapping Quality Communications Association (GSMA) on DSCP to UP Mapping, specifically
of Service (QoS) Procedures of Proxy Mobile IPv6 (PMIPv6) and WLAN their Guidelines for IPX Provider networks [GSMA-IPX_Guidelines].
[RFC7561] specification. This GSMA specification was developed These GSMA Guidelines were developed without reference to existing
without reference to existing IETF specifications for various IETF specifications for various services, referenced in Section 1.1.
services, referenced in Section 1.1. Thus, [RFC7561] conflicts with In turn, [RFC7561] was written based on these GSMA Guidelines, as
the overall Diffserv traffic-conditioning service plan, both in the explicitly called out in [RFC7561] Section 4.2. Thus, [RFC7561]
services specified and the code points specified for them. As such, conflicts with the overall Diffserv traffic-conditioning service
these two plans cannot be normalized. Rather, as discussed in plan, both in the services specified and the code points specified
[RFC2474] Section 2, the two domains (IEEE 802.11 and GSMA) are for them. As such, these two plans cannot be normalized. Rather, as
different Differentiated Services Domains separated by a 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 Differentiated Services Boundary. At that boundary, code points from
one domain are translated to code points for the other, and maybe to one domain are translated to code points for the other, and maybe to
Default (zero) if there is no corresponding service to translate to. Default (zero) if there is no corresponding service to translate to.
1.3. Applicability Statement 1.3. Applicability Statement
This document is applicable to the use of Differentiated Services This document is applicable to the use of Differentiated Services
that interconnect with IEEE 802.11 wireless LANs (referred to as Wi- that interconnect with IEEE 802.11 wireless LANs (referred to as Wi-
Fi, throughout this document, for simplicity). These guidelines are Fi, throughout this document, for simplicity). These guidelines are
applicable whether the wireless access points (APs) are deployed in applicable whether the wireless access points (APs) are deployed in
skipping to change at page 12, line 29 skipping to change at page 12, line 29
which it is not intended which it is not intended
The following sections address these limitations and concerns in The following sections address these limitations and concerns in
order to reconcile [RFC4594] and [IEEE.802.11-2016]. First order to reconcile [RFC4594] and [IEEE.802.11-2016]. First
downstream (wired-to-wireless) DSCP-to-UP mappings will be aligned downstream (wired-to-wireless) DSCP-to-UP mappings will be aligned
and then upstream (wireless-to-wired) models will be addressed. and then upstream (wireless-to-wired) models will be addressed.
3. Wireless Device Marking and Mapping Capability Recommendations 3. Wireless Device Marking and Mapping Capability Recommendations
This document assumes and RECOMMENDS that all wireless access points This document assumes and RECOMMENDS that all wireless access points
(as the bridges between wired-and-wireless networks) support the (as the interconnects between wired-and-wireless networks) support
ability to: the ability to:
o mark DSCP, per Diffserv standards o mark DSCP, per Diffserv standards
o mark UP, per the [IEEE.802.11-2016] standard o mark UP, per the [IEEE.802.11-2016] standard
o support fully-configurable mappings between DSCP and UP o support fully-configurable mappings between DSCP and UP
o process DSCP markings set by wireless endpoint devices o process DSCP markings set by wireless endpoint devices
This document further assumes and RECOMMENDS that all wireless This document further assumes and RECOMMENDS that all wireless
skipping to change at page 20, line 36 skipping to change at page 20, line 36
| High- | AF11 | | | | | High- | AF11 | | | |
| Throughput | AF12 | RFC2597 | 0 | AC_BE (Best Effort)| | Throughput | AF12 | RFC2597 | 0 | AC_BE (Best Effort)|
| Data | AF13 | | | | | Data | AF13 | | | |
+---------------+------+---------+-------------+--------------------+ +---------------+------+---------+-------------+--------------------+
| Standard | DF | RFC2474 | 0 | AC_BE (Best Effort)| | Standard | DF | RFC2474 | 0 | AC_BE (Best Effort)|
+---------------+------+---------+-------------+--------------------+ +---------------+------+---------+-------------+--------------------+
| Low-Priority | CS1 | RFC3662 | 1 | AC_BK (Background) | | Low-Priority | CS1 | RFC3662 | 1 | AC_BK (Background) |
| Data | | | | | | 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) (See Security Considerations Section - Section 8)
Figure 1: Summary of Downstream DSCP to IEEE 802.11 UP and AC Mapping Figure 1: Summary of Downstream DSCP to IEEE 802.11 UP and AC Mapping
Recommendations Recommendations
5. Upstream Mapping and Marking Recommendations 5. Upstream Mapping and Marking Recommendations
In the upstream direction (i.e. wireless-to-wired), there are three In the upstream direction (i.e. wireless-to-wired), there are three
types of mapping that may be implemented: types of mapping that may be implemented:
skipping to change at page 23, line 37 skipping to change at page 23, line 37
An alternative option to mapping is for the administrator to treat An alternative option to mapping is for the administrator to treat
the wireless edge as the edge of the Diffserv domain and explicitly the wireless edge as the edge of the Diffserv domain and explicitly
set (or reset) DSCP markings in the upstream direction according to set (or reset) DSCP markings in the upstream direction according to
administrative policy. This option is RECOMMENDED over mapping, as administrative policy. This option is RECOMMENDED over mapping, as
this typically is the most secure solution, as the network this typically is the most secure solution, as the network
administrator directly enforces the Diffserv policy across the IP administrator directly enforces the Diffserv policy across the IP
network (versus an application developer and/or the wireless endpoint network (versus an application developer and/or the wireless endpoint
device operating system developer, who may be functioning completely device operating system developer, who may be functioning completely
independently of the network administrator). 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 QoS is enabled on wireless networks by means of the Hybrid
Coordination Function (HCF). To give better context to the Coordination Function (HCF). To give better context to the
enhancements in HCF that enable QoS, it may be helpful to begin with enhancements in HCF that enable QoS, it may be helpful to begin with
a review of the original Distributed Coordination Function (DCF). a review of the original Distributed Coordination Function (DCF).
6.1. Distributed Coordination Function (DCF) 6.1. Distributed Coordination Function (DCF)
As has been noted, the Wi-Fi medium is a shared medium, with each As has been noted, the Wi-Fi medium is a shared medium, with each
station-including the wireless access point-contending for the medium station-including the wireless access point-contending for the medium
skipping to change at page 31, line 36 skipping to change at page 31, line 36
preferred UP values (of UP 4-7) should be controlled. preferred UP values (of UP 4-7) should be controlled.
If such marking/mapping were not controlled, then, for example, a If such marking/mapping were not controlled, then, for example, a
malicious user could cause WLAN DoS by flooding traffic marked CS7 malicious user could cause WLAN DoS by flooding traffic marked CS7
DSCP downstream. This codepoint would map by default (as described DSCP downstream. This codepoint would map by default (as described
in Section 2.2) to UP 7 and would be assigned to the Voice Access in Section 2.2) to UP 7 and would be assigned to the Voice Access
Category (AC_VO). Such a flood could cause Denial-of-Service to not Category (AC_VO). Such a flood could cause Denial-of-Service to not
only wireless voice applications, but also to all other traffic only wireless voice applications, but also to all other traffic
classes. Similarly, an uninformed application developer may request classes. Similarly, an uninformed application developer may request
all traffic from his/her application to be marked CS7 or CS6, all traffic from his/her application to be marked CS7 or CS6,
thinking this would acheive in the best overall servicing oftheir thinking this would acheive in the best overall servicing of their
application traffic, while not realizing that such a marking (if application traffic, while not realizing that such a marking (if
honored by the client operating system) could cause not only WLAN honored by the client operating system) could cause not only WLAN
DoS, but also IP network instability, as the traffic marked CS7 or DoS, but also IP network instability, as the traffic marked CS7 or
CS6 finds its way into queues intended for servicing (relatively low- CS6 finds its way into queues intended for servicing (relatively low-
bandwidth) network control protocols, potentially starving legitimate bandwidth) network control protocols, potentially starving legitimate
network control protocols in the process. network control protocols in the process.
Therefore, to mitigate such an attack, it is RECOMMENDED that all Therefore, to mitigate such an attack, it is RECOMMENDED that all
packets marked to Diffserv Codepoints not in use over the wireless packets marked to Diffserv Codepoints not in use over the wireless
network be mapped to UP 0; this recommendation applies both at the network be mapped to UP 0; this recommendation applies both at the
skipping to change at page 32, line 35 skipping to change at page 32, line 35
all other traffic classes on the WLAN to be starved, as well all other traffic classes on the WLAN to be starved, as well
hijacking queues on the wired IP network that are intended for the hijacking queues on the wired IP network that are intended for the
servicing of routing protocols. To this point, it was also servicing of routing protocols. To this point, it was also
recommended in Section 5.1 that packets requesting a marking of CS6 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 or CS7 DSCP SHOULD be remarked to DSCP 0 and mapped to UP 0 by the
wireless client operating system. wireless client operating system.
Finally, it should be noted that the recommendations put forward in Finally, it should be noted that the recommendations put forward in
this document are not intended to address all attack vectors this document are not intended to address all attack vectors
leveraging QoS marking abuse. Mechanisms that may further help leveraging QoS marking abuse. Mechanisms that may further help
mitigate security risks include strong device- and/or user- mitigate security risks of both wired and wireless networks deploying
authentication, access-control, rate limiting, control-plane QoS include strong device- and/or user-authentication, access-
policing, encryption and other techniques; however, the control, rate limiting, control-plane policing, encryption and other
implementation recommendations for such mechanisms are beyond the techniques; however, the implementation recommendations for such
scope of this document to address in detail. Suffice it to say that mechanisms are beyond the scope of this document to address in
the security of the devices and networks implementing QoS, including detail. Suffice it to say that the security of the devices and
QoS mapping between wired and wireless networks, SHOULD be considered networks implementing QoS, including QoS mapping between wired and
in actual deployments. wireless networks, SHOULD be considered in actual deployments.
9. Acknowledgements 9. Acknowledgements
The authors wish to thank David Black, Gorry Fairhurst, Ruediger The authors wish to thank David Black, Gorry Fairhurst, Ruediger
Geib, Vincent Roca, Brian Carpenter, David Blake, Cullen Jennings, Geib, Vincent Roca, Brian Carpenter, David Blake, Cullen Jennings,
David Benham and the TSVWG. David Benham and the TSVWG.
The authors also acknowledge a great many inputs, notably from David The authors also acknowledge a great many inputs, notably from David
Kloper, Mark Montanez, Glen Lavers, Michael Fingleton, Sarav Kloper, Mark Montanez, Glen Lavers, Michael Fingleton, Sarav
Radhakrishnan, Karthik Dakshinamoorthy, Simone Arena, Ranga Marathe, Radhakrishnan, Karthik Dakshinamoorthy, Simone Arena, Ranga Marathe,
skipping to change at page 34, line 17 skipping to change at page 34, line 17
DOI 10.17487/RFC4594, August 2006, DOI 10.17487/RFC4594, August 2006,
<https://www.rfc-editor.org/info/rfc4594>. <https://www.rfc-editor.org/info/rfc4594>.
[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,
<https://www.rfc-editor.org/info/rfc5865>. <https://www.rfc-editor.org/info/rfc5865>.
10.2. Informative References 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,
<https://www.gsma.com/newsroom/wp-content/uploads/
IR.34-v11.0.pdf>.
[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,
 End of changes. 12 change blocks. 
29 lines changed or deleted 37 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/