draft-ietf-tsvwg-ieee-802-11-04.txt   draft-ietf-tsvwg-ieee-802-11-05.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: January 4, 2018 F. Baker Expires: January 28, 2018 F. Baker
July 3, 2017 July 27, 2017
Diffserv to IEEE 802.11 Mapping Diffserv to IEEE 802.11 Mapping
draft-ietf-tsvwg-ieee-802-11-04 draft-ietf-tsvwg-ieee-802-11-05
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 January 4, 2018. This Internet-Draft will expire on January 28, 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
(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 2, line 25 skipping to change at page 2, line 25
1.4. Document Organization . . . . . . . . . . . . . . . . . . 5 1.4. Document Organization . . . . . . . . . . . . . . . . . . 5
1.5. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.5. Requirements Language . . . . . . . . . . . . . . . . . . 5
1.6. Terminology Used in this Document . . . . . . . . . . . . 6 1.6. Terminology Used in this Document . . . . . . . . . . . . 6
2. Service Comparison and Default Interoperation of Diffserv and 2. Service Comparison and Default Interoperation of Diffserv and
IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . 8 IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1. Diffserv Domain Boundaries . . . . . . . . . . . . . . . 9 2.1. Diffserv Domain Boundaries . . . . . . . . . . . . . . . 9
2.2. Default DSCP-to-UP Mappings and Conflicts . . . . . . . . 10 2.2. Default DSCP-to-UP Mappings and Conflicts . . . . . . . . 10
2.3. Default UP-to-DSCP Mappings and Conflicts . . . . . . . . 11 2.3. Default UP-to-DSCP Mappings and Conflicts . . . . . . . . 11
3. Wireless Device Marking and Mapping Capability 3. Wireless Device Marking and Mapping Capability
Recommendations . . . . . . . . . . . . . . . . . . . . . . . 12 Recommendations . . . . . . . . . . . . . . . . . . . . . . . 12
4. DSCP-to-UP Mapping Recommendations . . . . . . . . . . . . . 12 4. DSCP-to-UP Mapping Recommendations . . . . . . . . . . . . . 13
4.1. Network Control Traffic . . . . . . . . . . . . . . . . . 13 4.1. Network Control Traffic . . . . . . . . . . . . . . . . . 13
4.1.1. Network Control Protocols . . . . . . . . . . . . . . 13 4.1.1. Network Control Protocols . . . . . . . . . . . . . . 14
4.1.2. Operations Administration Management (OAM) . . . . . 14 4.1.2. Operations Administration Management (OAM) . . . . . 14
4.2. User Traffic . . . . . . . . . . . . . . . . . . . . . . 14 4.2. User Traffic . . . . . . . . . . . . . . . . . . . . . . 15
4.2.1. Telephony . . . . . . . . . . . . . . . . . . . . . . 15 4.2.1. Telephony . . . . . . . . . . . . . . . . . . . . . . 15
4.2.2. Signaling . . . . . . . . . . . . . . . . . . . . . . 15 4.2.2. Signaling . . . . . . . . . . . . . . . . . . . . . . 15
4.2.3. Multimedia Conferencing . . . . . . . . . . . . . . . 16 4.2.3. Multimedia Conferencing . . . . . . . . . . . . . . . 16
4.2.4. Real-Time Interactive . . . . . . . . . . . . . . . . 16 4.2.4. Real-Time Interactive . . . . . . . . . . . . . . . . 16
4.2.5. Multimedia-Streaming . . . . . . . . . . . . . . . . 16 4.2.5. Multimedia-Streaming . . . . . . . . . . . . . . . . 17
4.2.6. Broadcast Video . . . . . . . . . . . . . . . . . . . 17 4.2.6. Broadcast Video . . . . . . . . . . . . . . . . . . . 17
4.2.7. Low-Latency Data . . . . . . . . . . . . . . . . . . 17 4.2.7. Low-Latency Data . . . . . . . . . . . . . . . . . . 17
4.2.8. High-Throughput Data . . . . . . . . . . . . . . . . 17 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 . . . . . . . . . . . . . . . . . . 18 4.2.10. Low-Priority Data . . . . . . . . . . . . . . . . . . 19
4.3. DSCP-to-UP Mapping Recommendations Summary . . . . . . . 18 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 . . . . . . . . . . . . . . . . . . . . 20 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-Trust 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 . . . 22 5.4. Upstream DSCP Marking at the Wireless Access Point . . . 23
6. Appendix: IEEE 802.11 QoS Overview . . . . . . . . . . . . . 22 6. Appendix: 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 . . . . . . . . . . . . . . . . . . . . . . 23 6.1.1. Slot Time . . . . . . . . . . . . . . . . . . . . . . 24
6.1.2. Interframe Spaces . . . . . . . . . . . . . . . . . . 24 6.1.2. Interframe Spaces . . . . . . . . . . . . . . . . . . 24
6.1.3. Contention Windows . . . . . . . . . . . . . . . . . 24 6.1.3. Contention Windows . . . . . . . . . . . . . . . . . 25
6.2. Hybrid Coordination Function (HCF) . . . . . . . . . . . 25 6.2. Hybrid Coordination Function (HCF) . . . . . . . . . . . 26
6.2.1. User Priority (UP) . . . . . . . . . . . . . . . . . 25 6.2.1. User Priority (UP) . . . . . . . . . . . . . . . . . 26
6.2.2. Access Category (AC) . . . . . . . . . . . . . . . . 25 6.2.2. Access Category (AC) . . . . . . . . . . . . . . . . 26
6.2.3. Arbitration Inter-Frame Space (AIFS) . . . . . . . . 26 6.2.3. Arbitration Inter-Frame Space (AIFS) . . . . . . . . 27
6.2.4. Access Category Contention Windows (CW) . . . . . . . 27 6.2.4. Access Category Contention Windows (CW) . . . . . . . 28
6.3. IEEE 802.11u QoS Map Set . . . . . . . . . . . . . . . . 28 6.3. IEEE 802.11u QoS Map Set . . . . . . . . . . . . . . . . 29
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
8. Security Considerations . . . . . . . . . . . . . . . . . . . 29 8. Security Considerations . . . . . . . . . . . . . . . . . . . 30
8.1. General QoS Security Recommendations . . . . . . . . . . 29 8.1. General QoS Security Recommendations . . . . . . . . . . 30
8.2. WLAN QoS Security Recommendations . . . . . . . . . . . . 30 8.2. WLAN QoS Security Recommendations . . . . . . . . . . . . 31
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
10.1. Normative References . . . . . . . . . . . . . . . . . . 31 10.1. Normative References . . . . . . . . . . . . . . . . . . 33
10.2. Informative References . . . . . . . . . . . . . . . . . 33 10.2. Informative References . . . . . . . . . . . . . . . . . 34
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 33 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
Wireless has become the preferred medium for endpoints connecting to Wireless has become the preferred medium for endpoints connecting to
business and private networks. However, the wireless medium defined business and private networks. However, the wireless medium defined
by IEEE 802.11 [IEEE.802.11-2016] presents several design challenges by IEEE 802.11 [IEEE.802.11-2016] presents several design challenges
for ensuring end-to-end quality of service. Some of these challenges for ensuring end-to-end quality of service. Some of these challenges
relate to the nature of the IEEE 802.11 RF medium itself, being a relate to the nature of the IEEE 802.11 RF medium itself, being a
half-duplex and shared medium, while other challenges relate to the half-duplex and shared medium, while other challenges relate to the
fact that the IEEE 802.11 standard is not administered by the same fact that the IEEE 802.11 standard is not administered by the same
skipping to change at page 4, line 14 skipping to change at page 4, line 14
o [RFC3662] specifies a Lower Effort Per-Domain Behavior (PDB) o [RFC3662] specifies a Lower Effort Per-Domain Behavior (PDB)
o [RFC4594] presents Configuration Guidelines for Diffserv Service o [RFC4594] presents Configuration Guidelines for Diffserv Service
Classes Classes
o [RFC5127] presents the Aggregation of Diffserv Service Classes o [RFC5127] presents the Aggregation of Diffserv Service Classes
o [RFC5865] specifies a DSCP for Capacity Admitted Traffic o [RFC5865] specifies a DSCP for Capacity Admitted Traffic
Note: [RFC4594] is intended to be viewed as a set of "project plans" Note: [RFC4594] is intended to be viewed as a framework for
for building all the (diffserv) furniture that one might want. Thus, supporting Diffserv in any network, including wireless networks;
it describes different types of traffic expected in IP networks and thus, it describes different types of traffic expected in IP networks
provides guidance as to what DSCP marking(s) should be associated and provides guidance as to what DSCP marking(s) should be associated
with each traffic type. As such, this document draws heavily on with each traffic type. As such, this document draws heavily on
[RFC4594], [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 GSMA, Mapping Quality of There is also a recommendation from the Global System for Mobile
Service (QoS) Procedures of Proxy Mobile IPv6 (PMIPv6) and WLAN Communications Association (GSMA), specifically their Mapping Quality
[RFC7561]. The GSMA specification was developed without reference to of Service (QoS) Procedures of Proxy Mobile IPv6 (PMIPv6) and WLAN
existing IETF specifications for various services, referenced in [RFC7561] specification. This GSMA specification was developed
Section 1.1. Thus, [RFC7561] conflicts with the overall Diffserv without reference to existing IETF specifications for various
traffic-conditioning service plan, both in the services specified and services, referenced in Section 1.1. Thus, [RFC7561] conflicts with
the code points specified for them. As such, these two plans cannot the overall Diffserv traffic-conditioning service plan, both in the
be normalized. Rather, as discussed in [RFC2474] Section 2, the two services specified and the code points specified for them. As such,
domains (IEEE 802.11 and GSMA) are different Differentiated Services these two plans cannot be normalized. Rather, as discussed in
Domains separated by a Differentiated Services Boundary. At that [RFC2474] Section 2, the two domains (IEEE 802.11 and GSMA) are
boundary, code points from one domain are translated to code points different Differentiated Services Domains separated by a
for the other, and maybe to Default (zero) if there is no Differentiated Services Boundary. At that boundary, code points from
corresponding service to translate 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.
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
an autonomous manner, managed by (centralized or distributed) WLAN an autonomous manner, managed by (centralized or distributed) WLAN
controllers or some hybrid deployment option. This is because in all controllers or some hybrid deployment option. This is because in all
these cases, the wireless access point is the bridge between wired these cases, the wireless access point is the bridge between wired
skipping to change at page 5, line 39 skipping to change at page 5, line 39
the [RFC4594] service classes, which are primarily applicable in the [RFC4594] service classes, which are primarily applicable in
the downstream (wired-to-wireless) direction. the downstream (wired-to-wireless) direction.
o Section 5, in turn, considers upstream (wireless-to-wired) QoS o Section 5, in turn, considers upstream (wireless-to-wired) QoS
options, their respective merits and recommendations. options, their respective merits and recommendations.
o Section 6 (in the form of an Appendix) presents a brief overview o Section 6 (in the form of an Appendix) presents a brief overview
of how QoS is achieved over IEEE 802.11 wireless networks, given of how QoS is achieved over IEEE 802.11 wireless networks, given
the shared, half-duplex nature of the wireless medium. the shared, half-duplex nature of the wireless medium.
o Section 7 on notes IANA considerations, security considerations, o Section 7 on notes IANA considerations
acknowledgements and references, respectively
o Section 8 presents security considerations relative to DSCP-to-UP,
UP-to-DSCP mapping and remarking
1.5. Requirements Language 1.5. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL", and "NOT "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL", and "NOT
RECOMMENDED" in this document are to be interpreted as described in RECOMMENDED" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
1.6. Terminology Used in this Document 1.6. Terminology Used in this Document
skipping to change at page 7, line 25 skipping to change at page 7, line 25
function where the same coordination function logic is active in function where the same coordination function logic is active in
every station (STA) in the basic service set (BSS) whenever the every station (STA) in the basic service set (BSS) whenever the
network is in operation. network is in operation.
DIFS: Distributed (Coordination Function) Interframe Space. A DIFS: Distributed (Coordination Function) Interframe Space. A
unit of time during which the medium has to be detected as idle unit of time during which the medium has to be detected as idle
before a station should attempt to send frames, as per before a station should attempt to send frames, as per
[IEEE.802.11-2016] Section 10.3.2.3.5. [IEEE.802.11-2016] Section 10.3.2.3.5.
DSCP: Differentiated Service Code Point [RFC2474] and [RFC2475]. DSCP: Differentiated Service Code Point [RFC2474] and [RFC2475].
The DSCP is carried in the first 6 bits of the IPv4 and IPv6 Type
of Service (TOS) Byte (the remaining 2 bits are used for IP
Explicit Congestion Notification [RFC3168]).
HCF: Hybrid Coordination Function A coordination function that HCF: Hybrid Coordination Function A coordination function that
combines and enhances aspects of the contention based and combines and enhances aspects of the contention based and
contention free access methods to provide quality-of-service (QoS) contention free access methods to provide quality-of-service (QoS)
stations (STAs) with prioritized and parameterized QoS access to stations (STAs) with prioritized and parameterized QoS access to
the wireless medium (WM), while continuing to support non-QoS STAs the wireless medium (WM), while continuing to support non-QoS STAs
for best-effort transfer. [IEEE.802.11-2016] Section 3.1. for best-effort transfer. [IEEE.802.11-2016] Section 3.1.
IFS: Interframe Space. Period of silence between transmissions IFS: Interframe Space. Period of silence between transmissions
over 802.11 networks. [IEEE.802.11-2016] describes several types over 802.11 networks. [IEEE.802.11-2016] describes several types
skipping to change at page 9, line 25 skipping to change at page 9, line 27
service via the Background Access Category (AC_BK) service via the Background Access Category (AC_BK)
As such, these high-level considerations should be kept in mind when As such, these high-level considerations should be kept in mind when
mapping from Diffserv to [IEEE.802.11-2016] (and vice-versa); mapping from Diffserv to [IEEE.802.11-2016] (and vice-versa);
however, access points may or may not always be positioned at however, access points may or may not always be positioned at
Diffserv domain boundaries, as will be discussed next. Diffserv domain boundaries, as will be discussed next.
2.1. Diffserv Domain Boundaries 2.1. Diffserv Domain Boundaries
It is important to recognize that the wired-to-wireless edge may or It is important to recognize that the wired-to-wireless edge may or
may not equate to the edge of the Diffserv domain. may not function as an edge of a Diffserv domain or a domain
boundary.
In most commonly-deployed WLAN models, the wireless access point In most commonly-deployed WLAN models, the wireless access point
represents not only the edge of the Diffserv domain, but also the represents not only the edge of the Diffserv domain, but also the
edge of the network infrastructure itself. As such, only client edge of the network infrastructure itself. As such, only client
endpoint devices (and no infrastructure devices) are downstream from endpoint devices (and no network infrastructure devices) are
the access points in these deployment models. Note: security downstream from the access points in these deployment models. Note:
considerations and recommendations for hardening such Wifi-at-the- security considerations and recommendations for hardening such Wifi-
edge deployment models are detailed in Section 8. at-the-edge deployment models are detailed in Section 8; these
recommendations include mapping network control protocols (which are
not used downstream from the AP in this deployment model) to UP 0.
Alternatively, in other deployment models, such as Wi-Fi backhaul, Alternatively, in other deployment models, such as Wi-Fi backhaul,
wireless mesh infrastructures, wireless AP-to-AP deployments, or in wireless mesh infrastructures, wireless AP-to-AP deployments, or in
cases where a Wi-Fi link connects to a device providing service via cases where a Wi-Fi link connects to a device providing service via
another technology (e.g. Wi-Fi to Bluetooth or Zigbee router), the another technology (e.g. Wi-Fi to Bluetooth or Zigbee router), the
wireless access point extends the network infrastructure and thus, wireless access point extends the network infrastructure and thus,
typically, the Diffserv domain. In such deployments, both client typically, the Diffserv domain. In such deployments, both client
devices and infrastructure devices may be expected downstream from devices and infrastructure devices may be expected downstream from
the access points. the access points, and as such network control protocols are
recommended to be mapped to UP 7 in this deployment model, as is
discussed in Section 4.1.1.
Thus the QoS treatment of packets at the access point will depend on Thus, as can be seen from these two examples, the QoS treatment of
the position of the AP in the network infrastructure and on the WLAN packets at the access point will depend on the position of the AP in
deployment model. the network infrastructure and on the WLAN deployment model.
However, regardless of the access point being at the Diffserv However, regardless of the access point being at the Diffserv
boundary or not, Diffserv to [IEEE.802.11-2016] (and vice-versa) boundary or not, Diffserv to [IEEE.802.11-2016] (and vice-versa)
marking-specific incompatibilities exist that must be reconciled, as marking-specific incompatibilities exist that must be reconciled, as
will be discussed next. will be discussed next.
2.2. Default DSCP-to-UP Mappings and Conflicts 2.2. Default DSCP-to-UP Mappings and Conflicts
While no explicit guidance is offered in mapping (6-Bit) Layer 3 DSCP While no explicit guidance is offered in mapping (6-Bit) Layer 3 DSCP
values to (3-Bit) Layer 2 markings (such as IEEE 802.1D, 802.1p or values to (3-Bit) Layer 2 markings (such as IEEE 802.1D, 802.1p or
skipping to change at page 10, line 34 skipping to change at page 10, line 43
specifically: specifically:
o Voice (EF-101110) will be mapped to UP 5 (101), and treated in the o Voice (EF-101110) will be mapped to UP 5 (101), and treated in the
Video Access Category (AC_VI), rather than the Voice Access Video Access Category (AC_VI), rather than the Voice Access
Category (AC_VO), for which it is intended Category (AC_VO), for which it is intended
o Multimedia Streaming (AF3-011xx0) will be mapped to UP3 (011) and o Multimedia Streaming (AF3-011xx0) will be mapped to UP3 (011) and
treated in the Best Effort Access Category (AC_BE), rather than treated in the Best Effort Access Category (AC_BE), rather than
the Video Access Category (AC_VI), for which it is intended the Video Access Category (AC_VI), for which it is intended
o Broadcast Video (CS3-011000) will be mapped to UP3 (011) and
treated in the Best Effort Access Category (AC_BE), rather than
the Video Access Category (AC_VI), for which it is intended
o OAM traffic (CS2-010000) will be mapped to UP 2 (010) and treated o OAM traffic (CS2-010000) will be mapped to UP 2 (010) and treated
in the Background Access Category (AC_BK), which is not the intent in the Background Access Category (AC_BK), which is not the intent
expressed in [RFC4594] for this service class expressed in [RFC4594] for this service class
It should also be noted that while [IEEE.802.11-2016] defines an It should also be noted that while [IEEE.802.11-2016] defines an
intended use for each access category through the AC naming intended use for each access category through the AC naming
convention (for example, UP 6 and UP 7 belong to AC_VO, the Voice convention (for example, UP 6 and UP 7 belong to AC_VO, the Voice
Access Category), [IEEE.802.11-2016] does not: Access Category), [IEEE.802.11-2016] does not:
o define how upper layer markings (such as DSCP) should map to UPs o define how upper layer markings (such as DSCP) should map to UPs
skipping to change at page 12, line 25 skipping to change at page 12, line 38
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 bridges between wired-and-wireless networks) support the
ability to: 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 trust 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
endpoint devices support the ability to: endpoint devices support 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 (set by o support fully-configurable mappings between DSCP (set by
applications in software) and UP (set by the operating system and/ applications in software) and UP (set by the operating system and/
skipping to change at page 14, line 5 skipping to change at page 14, line 18
between network devices (e.g. routers) that require control (routing) between network devices (e.g. routers) that require control (routing)
information to be exchanged between nodes within the administrative information to be exchanged between nodes within the administrative
domain, as well as across a peering point between different domain, as well as across a peering point between different
administrative domains. administrative domains.
The RECOMMENDED DSCP marking for Network Control is CS6, per The RECOMMENDED DSCP marking for Network Control is CS6, per
[RFC4594] Section 3.2; additionally, CS7 DSCP value SHOULD be [RFC4594] Section 3.2; additionally, CS7 DSCP value SHOULD be
reserved for future use, potentially for future routing or control reserved for future use, potentially for future routing or control
protocols, again, per [RFC4594] Section 3.2. protocols, again, per [RFC4594] Section 3.2.
By default, packets marked DSCP CS7 will be mapped to UP 7 and By default (as described in Section 2.2), packets marked DSCP CS7
serviced within the Voice Access Category (AC_VO). This represents will be mapped to UP 7 and serviced within the Voice Access Category
the RECOMMENDED mapping for CS7, that is, packets marked to CS7 DSCP (AC_VO). This represents the RECOMMENDED mapping for CS7, that is,
are RECOMMENDED to be mapped to UP 7. packets marked to CS7 DSCP are RECOMMENDED to be mapped to UP 7.
However, by default, packets marked DSCP CS6 will be mapped to UP 6 However, by default (as described in Section 2.2), packets marked
and serviced within the Voice Access Category (AC_VO); such mapping DSCP CS6 will be mapped to UP 6 and serviced within the Voice Access
and servicing is a contradiction to the intent expressed in [RFC Category (AC_VO); such mapping and servicing is a contradiction to
4594] section 3.2. As such, it is RECOMMENDED to map Network Control the intent expressed in [RFC 4594] section 3.2. As such, it is
traffic marked CS6 to UP 7 (per [IEEE.802.11-2016] Section 10.2.4.2, RECOMMENDED to map Network Control traffic marked CS6 to UP 7 (per
Table 10-1), thereby admitting it to the Voice Access Category [IEEE.802.11-2016] Section 10.2.4.2, Table 10-1), thereby admitting
(AC_VO), albeit with a marking distinguishing it from (data-plane) it to the Voice Access Category (AC_VO), albeit with a marking
voice traffic. distinguishing it from (data-plane) voice traffic.
It should be noted that encapsulated routing protocols for It should be noted that encapsulated routing protocols for
encapsulated or overlay networks (e.g., VPN, NVO3) are not network encapsulated or overlay networks (e.g., VPN, NVO3) are not network
control traffic for any physical network at the AP, and hence SHOULD control traffic for any physical network at the AP, and hence SHOULD
NOT be marked with CS6 in the first place. NOT be marked with CS6 in the first place.
Addtionally, and as previously noted, the Security Considerations Addtionally, and as previously noted, the Security Considerations
section (Section 8) contains additional recommendations for hardening section (Section 8) contains additional recommendations for hardening
Wifi-at-the-edge deployment models, where, for example, network Wifi-at-the-edge deployment models, where, for example, network
control protocols are not expected to be sent nor recevied between control protocols are not expected to be sent nor recevied between
APs and downstream endpoint client devices. APs and downstream endpoint client devices.
4.1.2. Operations Administration Management (OAM) 4.1.2. Operations Administration Management (OAM)
The OAM (Operations, Administration, and Management) service class is The OAM (Operations, Administration, and Management) service class is
RECOMMENDED for OAM&P (Operations, Administration, and Management and RECOMMENDED for OAM&P (Operations, Administration, and Management and
Provisioning). The RECOMMENDED DSCP marking for OAM is CS2, per Provisioning). The RECOMMENDED DSCP marking for OAM is CS2, per
[RFC4594] Section 3.3. [RFC4594] Section 3.3.
By default, packets marked DSCP CS2 will be mapped to UP 2 and By default (as described in Section 2.2), packets marked DSCP CS2
serviced with the Background Access Category (AC_BK). Such servicing will be mapped to UP 2 and serviced with the Background Access
is a contradiction to the intent expressed in [RFC4594] Section 3.3. Category (AC_BK). Such servicing is a contradiction to the intent
As such, it is RECOMMENDED that a non-default mapping be applied to expressed in [RFC4594] Section 3.3. As such, it is RECOMMENDED that
OAM traffic, such that CS2 DSCP is mapped to UP 0, thereby admitting a non-default mapping be applied to OAM traffic, such that CS2 DSCP
it to the Best Effort Access Category (AC_BE). is mapped to UP 0, thereby admitting it to the Best Effort Access
Category (AC_BE).
4.2. User Traffic 4.2. User Traffic
User traffic is defined as packet flows between different users or User traffic is defined as packet flows between different users or
subscribers. It is the traffic that is sent to or from end-terminals subscribers. It is the traffic that is sent to or from end-terminals
and that supports a very wide variety of applications and services and that supports a very wide variety of applications and services
[RFC4594] Section 4. [RFC4594] Section 4.
Network administrators can categorize their applications according to Network administrators can categorize their applications according to
the type of behavior that they require and MAY choose to support all the type of behavior that they require and MAY choose to support all
skipping to change at page 15, line 20 skipping to change at page 15, line 31
The Telephony service class is RECOMMENDED for applications that The Telephony service class is RECOMMENDED for applications that
require real-time, very low delay, very low jitter, and very low require real-time, very low delay, very low jitter, and very low
packet loss for relatively constant-rate traffic sources (inelastic packet loss for relatively constant-rate traffic sources (inelastic
traffic sources). This service class SHOULD be used for IP telephony traffic sources). This service class SHOULD be used for IP telephony
service. The fundamental service offered to traffic in the Telephony service. The fundamental service offered to traffic in the Telephony
service class is minimum jitter, delay, and packet loss service up to service class is minimum jitter, delay, and packet loss service up to
a specified upper bound. The RECOMMENDED DSCP marking for Telephony a specified upper bound. The RECOMMENDED DSCP marking for Telephony
is EF ([RFC4594] Section 4.1). is EF ([RFC4594] Section 4.1).
Traffic marked to DSCP EF will map by default to UP 5, and thus to Traffic marked to DSCP EF will map by default (as described in
the Video Access Category (AC_VI), rather than to the Voice Access Section 2.2) to UP 5, and thus to the Video Access Category (AC_VI),
Category (AC_VO), for which it is intended. Therefore, a non-default rather than to the Voice Access Category (AC_VO), for which it is
DSCP-to-UP mapping is RECOMMENDED, such that EF DSCP is mapped to UP intended. Therefore, a non-default DSCP-to-UP mapping is
6, thereby admitting it into the Voice Access Category (AC_VO). RECOMMENDED, such that EF DSCP is mapped to UP 6, thereby admitting
it into the Voice Access Category (AC_VO).
Similarly, the [RFC5865] VOICE-ADMIT DSCP (44/101100) is RECOMMENDED Similarly, the [RFC5865] VOICE-ADMIT DSCP (44/101100) is RECOMMENDED
to be mapped to UP 6, thereby admitting it also into the Voice Access to be mapped to UP 6, thereby admitting it also into the Voice Access
Category (AC_VO). Category (AC_VO).
4.2.2. Signaling 4.2.2. Signaling
The Signaling service class is RECOMMENDED for delay-sensitive The Signaling service class is RECOMMENDED for delay-sensitive
client-server (e.g. traditional telephony) and peer-to-peer client-server (e.g. traditional telephony) and peer-to-peer
application signaling. Telephony signaling includes signaling application signaling. Telephony signaling includes signaling
between IP phone and soft-switch, soft-client and soft-switch, and between IP phone and soft-switch, soft-client and soft-switch, and
media gateway and soft-switch as well as peer-to-peer using various media gateway and soft-switch as well as peer-to-peer using various
protocols. This service class is intended to be used for control of protocols. This service class is intended to be used for control of
sessions and applications. The RECOMMENDED DSCP marking for sessions and applications. The RECOMMENDED DSCP marking for
Signaling is CS5 ([RFC4594] Section 4.2). Signaling is CS5 ([RFC4594] Section 4.2).
While Signaling is RECOMMENDED to receive a superior level of service While Signaling is RECOMMENDED to receive a superior level of service
relative to the default class (i.e. AC_BE), it does not require the relative to the default class (i.e. AC_BE), it does not require the
highest level of service (i.e. AC_VO). This leaves only the Video highest level of service (i.e. AC_VO). This leaves only the Video
Access Category (AC_VI), which it will map to by default. Therefore Access Category (AC_VI), which it will map to by default (as
it is RECOMMENDED to map Signaling traffic marked CS5 DSCP to UP 5, described in Section 2.2). Therefore it is RECOMMENDED to map
thereby admitting it to the Video Access Category (AC_VI). Signaling traffic marked CS5 DSCP to UP 5, thereby admitting it to
the Video Access Category (AC_VI).
Note: Signaling traffic is not control plane traffic from the Note: Signaling traffic is not control plane traffic from the
perspective of the network (but rather is data plane traffic); as perspective of the network (but rather is data plane traffic); as
such, it does not merit provisioning in the Network Control service such, it does not merit provisioning in the Network Control service
class (marked CS6 and mapped to UP 6). However, Signaling traffic is class (marked CS6 and mapped to UP 6). However, Signaling traffic is
control-plane traffic from the perspective of the voice/video control-plane traffic from the perspective of the voice/video
telephony overlay-infrastructure. As such, Signaling should be telephony overlay-infrastructure. As such, Signaling should be
treated with preferential servicing vs. other data plane flows. One treated with preferential servicing vs. other data plane flows. One
way this may be achieved in certain WLAN deployments is by mapping way this may be achieved in certain WLAN deployments is by mapping
Signaling traffic marked CS5 to UP 5 (as recommended above and Signaling traffic marked CS5 to UP 5 (as recommended above and
skipping to change at page 16, line 19 skipping to change at page 16, line 33
4.2.3. Multimedia Conferencing 4.2.3. Multimedia Conferencing
The Multimedia Conferencing service class is RECOMMENDED for The Multimedia Conferencing service class is RECOMMENDED for
applications that require real-time service for rate-adaptive applications that require real-time service for rate-adaptive
traffic. The RECOMMENDED DSCP markings for Multimedia Conferencing traffic. The RECOMMENDED DSCP markings for Multimedia Conferencing
are AF41, AF42 and AF43 ([RFC4594] Section 4.3). are AF41, AF42 and AF43 ([RFC4594] Section 4.3).
The primary media type typically carried within the Multimedia The primary media type typically carried within the Multimedia
Conferencing service class is video; as such, it is RECOMMENDED to Conferencing service class is video; as such, it is RECOMMENDED to
map this class into the Video Access Category (which it does by map this class into the Video Access Category, which it does by
default). Specifically, it is RECOMMENDED to map AF41, AF42 and AF43 default (as described in Section 2.2). Specifically, it is
to UP 4, thereby admitting Multimedia Conferencing into the Video RECOMMENDED to map AF41, AF42 and AF43 to UP 4, thereby admitting
Access Category (AC_VI). Multimedia Conferencing into the Video Access Category (AC_VI).
4.2.4. Real-Time Interactive 4.2.4. Real-Time Interactive
The Real-Time Interactive service class is RECOMMENDED for The Real-Time Interactive service class is RECOMMENDED for
applications that require low loss and jitter and very low delay for applications that require low loss and jitter and very low delay for
variable rate inelastic traffic sources. Such applications may variable rate inelastic traffic sources. Such applications may
include inelastic video-conferencing applications, but may also include inelastic video-conferencing applications, but may also
include gaming applications (as pointed out in [RFC4594] Sections 2.1 include gaming applications (as pointed out in [RFC4594] Sections 2.1
through 2.3, and Section 4.4). The RECOMMENDED DSCP marking for through 2.3, and Section 4.4). The RECOMMENDED DSCP marking for
Real-Time Interactive traffic is CS4 ([RFC4594] Section 4.4). Real-Time Interactive traffic is CS4 ([RFC4594] Section 4.4).
The primary media type typically carried within the Real-Time The primary media type typically carried within the Real-Time
Interactive service class is video; as such, it is RECOMMENDED to map Interactive service class is video; as such, it is RECOMMENDED to map
this class into the Video Access Category (which it does by default). this class into the Video Access Category, which it does by default
Specifically, it is RECOMMENDED to map CS4 to UP 4, thereby admitting (as described in Section 2.2). Specifically, it is RECOMMENDED to
Real-Time Interactive traffic into the Video Access Category (AC_VI). map CS4 to UP 4, thereby admitting Real-Time Interactive traffic into
the Video Access Category (AC_VI).
4.2.5. Multimedia-Streaming 4.2.5. Multimedia-Streaming
The Multimedia Streaming service class is RECOMMENDED for The Multimedia Streaming service class is RECOMMENDED for
applications that require near-real-time packet forwarding of applications that require near-real-time packet forwarding of
variable rate elastic traffic sources. Typically these flows are variable rate elastic traffic sources. Typically these flows are
unidirectional. The RECOMMENDED DSCP markings for Multimedia unidirectional. The RECOMMENDED DSCP markings for Multimedia
Streaming are AF31, AF32 and AF33 ([RFC4594] Section 4.5). Streaming are AF31, AF32 and AF33 ([RFC4594] Section 4.5).
The primary media type typically carried within the Multimedia The primary media type typically carried within the Multimedia
Streaming service class is video; as such, it is RECOMMENDED to map Streaming service class is video; as such, it is RECOMMENDED to map
this class into the Video Access Category. Specifically, it is this class into the Video Access Category, which it will by default
RECOMMENDED to map AF31, AF32 and AF33 to UP 4, thereby admitting (as described in Section 2.2). Specifically, it is RECOMMENDED to
Multimedia Streaming into the Video Access Category (AC_VI). map AF31, AF32 and AF33 to UP 4, thereby admitting Multimedia
Streaming into the Video Access Category (AC_VI).
4.2.6. Broadcast Video 4.2.6. Broadcast Video
The Broadcast Video service class is RECOMMENDED for applications The Broadcast Video service class is RECOMMENDED for applications
that require near-real-time packet forwarding with very low packet that require near-real-time packet forwarding with very low packet
loss of constant rate and variable rate inelastic traffic sources. loss of constant rate and variable rate inelastic traffic sources.
Typically these flows are unidirectional. The RECOMMENDED DSCP Typically these flows are unidirectional. The RECOMMENDED DSCP
marking for Broadcast Video is CS3 ([RFC4594] Section 4.6). marking for Broadcast Video is CS3 ([RFC4594] Section 4.6).
As directly implied by the name, the primary media type typically As directly implied by the name, the primary media type typically
carried within the Broadcast Video service class is video; as such, carried within the Broadcast Video service class is video; as such,
it is RECOMMENDED to map this class into the Video Access Category. it is RECOMMENDED to map this class into the Video Access Category;
Specifically, it is RECOMMENDED to map CS4 to UP 4, thereby admitting however, by default (as described in Section 2.2), this service class
Broadcast Video into the Video Access Category (AC_VI). will map to UP 3, and thus the Best Effort Access Category (AC_BE).
Therefore, a non-default mapping is RECOMMENDED, such that CS4 maps
to UP 4, thereby admitting Broadcast Video into the Video Access
Category (AC_VI).
4.2.7. Low-Latency Data 4.2.7. Low-Latency Data
The Low-Latency Data service class is RECOMMENDED for elastic and The Low-Latency Data service class is RECOMMENDED for elastic and
time-sensitive data applications, often of a transactional nature, time-sensitive data applications, often of a transactional nature,
where a user is waiting for a response via the network in order to where a user is waiting for a response via the network in order to
continue with a task at hand. As such, these flows are considered continue with a task at hand. As such, these flows are considered
foreground traffic, with delays or drops to such traffic directly foreground traffic, with delays or drops to such traffic directly
impacting user-productivity. The RECOMMENDED DSCP markings for Low- impacting user-productivity. The RECOMMENDED DSCP markings for Low-
Latency Data are AF21, AF22 and AF23 ([RFC4594] Section 4.7). Latency Data are AF21, AF22 and AF23 ([RFC4594] Section 4.7).
By default (as described in Section 2.2), Low-Latency Data will map
to UP 2 and thus to the Background Access Category (AC_BK), which is
contrary to the intent expressed in [RFC4594].
In line with the assumption made in Section 4, mapping Low-Latency In line with the assumption made in Section 4, mapping Low-Latency
Data to UP 3 may allow such to receive a superior level of service Data to UP 3 may allow such to receive a superior level of service
via transmit queues servicing the EDCAF hardware for the Best Effort via transmit queues servicing the EDCAF hardware for the Best Effort
Access Category (AC_BE). Therefore it is RECOMMENDED to map Low- Access Category (AC_BE). Therefore it is RECOMMENDED to map Low-
Latency Data traffic marked AF2x DSCP to UP 3, thereby admitting it Latency Data traffic marked AF2x DSCP to UP 3, thereby admitting it
to the Best Effort Access Category (AC_BE). to the Best Effort Access Category (AC_BE).
4.2.8. High-Throughput Data 4.2.8. High-Throughput Data
The High-Throughput Data service class is RECOMMENDED for elastic The High-Throughput Data service class is RECOMMENDED for elastic
skipping to change at page 18, line 5 skipping to change at page 18, line 26
traffic sources and, more specifically, is configured to provide traffic sources and, more specifically, is configured to provide
efficient, yet constrained (when necessary) throughput for TCP efficient, yet constrained (when necessary) throughput for TCP
longer-lived flows. These flows are typically non-user-interactive. longer-lived flows. These flows are typically non-user-interactive.
Per [RFC4594]-Section 4.8, it can be assumed that this class will Per [RFC4594]-Section 4.8, it can be assumed that this class will
consume any available bandwidth and that packets traversing congested consume any available bandwidth and that packets traversing congested
links may experience higher queuing delays or packet loss. It is links may experience higher queuing delays or packet loss. It is
also assumed that this traffic is elastic and responds dynamically to also assumed that this traffic is elastic and responds dynamically to
packet loss. The RECOMMENDED DSCP markings for High-Throughput Data packet loss. The RECOMMENDED DSCP markings for High-Throughput Data
are AF11, AF12 and AF13 ([RFC4594] Section 4.8). are AF11, AF12 and AF13 ([RFC4594] Section 4.8).
By default (as described in Section 2.2), High-Throughput Data will
map to UP 1 and thus to the Background Access Category (AC_BK), which
is contrary to the intent expressed in [RFC4594].
Unfortunately, there really is no corresponding fit for the High- Unfortunately, there really is no corresponding fit for the High-
Throughput Data service class within the constrained 4 Access Throughput Data service class within the constrained 4 Access
Category [IEEE.802.11-2016] model. If the High-Throughput Data Category [IEEE.802.11-2016] model. If the High-Throughput Data
service class is assigned to the Best Effort Access Category (AC_BE), service class is assigned to the Best Effort Access Category (AC_BE),
then it would contend with Low-Latency Data (while [RFC4594] then it would contend with Low-Latency Data (while [RFC4594]
recommends a distinction in servicing between these service classes) recommends a distinction in servicing between these service classes)
as well as with the default service class; alternatively, if it is as well as with the default service class; alternatively, if it is
assigned to the Background Access Category (AC_BK), then it would assigned to the Background Access Category (AC_BK), then it would
receive a less-then-best-effort service and contend with Low-Priority receive a less-then-best-effort service and contend with Low-Priority
Data (as discussed in Section 4.2.10). Data (as discussed in Section 4.2.10).
skipping to change at page 18, line 31 skipping to change at page 19, line 8
4.2.9. Standard Service Class 4.2.9. Standard Service Class
The Standard service class is RECOMMENDED for traffic that has not The Standard service class is RECOMMENDED for traffic that has not
been classified into one of the other supported forwarding service been classified into one of the other supported forwarding service
classes in the Diffserv network domain. This service class provides classes in the Diffserv network domain. This service class provides
the Internet's "best-effort" forwarding behavior. The RECOMMENDED the Internet's "best-effort" forwarding behavior. The RECOMMENDED
DSCP marking for the Standard Service Class is DF. ([RFC4594] DSCP marking for the Standard Service Class is DF. ([RFC4594]
Section 4.9) Section 4.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_BE) 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). This happens to correspond to the default mapping (as
described in Section 2.2).
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] and [I-D.ietf-tsvwg-le-phb]. 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).
This happens to correspond to the default mapping (as described in
Section 2.2).
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
downstream direction (i.e. from wired-to-wireless networks). downstream direction (i.e. from wired-to-wireless networks).
+------------------------------------------------------------------+ +------------------------------------------------------------------+
| IETF Diffserv | PHB |Reference| IEEE 802.11 | | IETF Diffserv | PHB |Reference| IEEE 802.11 |
| Service Class | | RFC |User Priority| Access Category | | Service Class | | RFC |User Priority| Access Category |
|===============+======+=========+=============+====================| |===============+======+=========+=============+====================|
| | | | 7 | AC_VO (Voice) | | | | | 7 | AC_VO (Voice) |
|Network Control| CS7 | RFC2474 | OR | |Network Control| CS7 | RFC2474 | OR |
|(reserved for | | | 0 | AC_BE (Best Effort)| |(reserved for | | | 0 | AC_BE (Best Effort)|
| future use) | | |See Security Considerations-Sec.8)| | future use) | | |See Security Considerations-Sec.8 |
+---------------+------+---------+-------------+--------------------+ +---------------+------+---------+-------------+--------------------+
| | | | 7 | AC_VO (Voice) | | | | | 7 | AC_VO (Voice) |
|Network Control| CS6 | RFC2474 | OR | |Network Control| CS6 | RFC2474 | OR |
| | | | 0 | AC_BE (Best Effort)| | | | | 0 | AC_BE (Best Effort)|
| | | |See Security Considerations-Sec.8)| | | | |See Security Considerations-Sec.8 |
+---------------+------+---------+-------------+--------------------+ +---------------+------+---------+-------------+--------------------+
| Telephony | EF | RFC3246 | 6 | AC_VO (Voice) | | Telephony | EF | RFC3246 | 6 | AC_VO (Voice) |
+---------------+------+---------+-------------+--------------------+ +---------------+------+---------+-------------+--------------------+
| VOICE-ADMIT |VOICE-| RFC5865 | 6 | AC_VO (Voice) | | VOICE-ADMIT | VA | RFC5865 | 6 | AC_VO (Voice) |
| |ADMIT | | | | | | | | | |
+---------------+------+---------+-------------+--------------------+ +---------------+------+---------+-------------+--------------------+
| Signaling | CS5 | RFC2474 | 5 | AC_VI (Video) | | Signaling | CS5 | RFC2474 | 5 | AC_VI (Video) |
+---------------+------+---------+-------------+--------------------+ +---------------+------+---------+-------------+--------------------+
| Multimedia | AF41 | | | | | Multimedia | AF41 | | | |
| Conferencing | AF42 | RFC2597 | 4 | AC_VI (Video) | | Conferencing | AF42 | RFC2597 | 4 | AC_VI (Video) |
| | AF43 | | | | | | AF43 | | | |
+---------------+------+---------+-------------+--------------------+ +---------------+------+---------+-------------+--------------------+
| Real-Time | CS4 | RFC2474 | 4 | AC_VI (Video) | | Real-Time | CS4 | RFC2474 | 4 | AC_VI (Video) |
| Interactive | | | | | | Interactive | | | | |
+---------------+------+---------+-------------+--------------------+ +---------------+------+---------+-------------+--------------------+
skipping to change at page 20, line 15 skipping to change at page 20, line 45
Note: All unusued codepoints are recommended to be mapped to UP 0 Note: All unusued 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:
o DSCP-to-UP mapping within the wireless client operating system
o UP-to-DSCP mapping at the wireless access point o DSCP-to-UP mapping within the wireless client operating system,
and
o DSCP-Trust at the wireless access point (effectively a 1:1 DSCP- o UP-to-DSCP mapping at the wireless access point, or
to-DSCP mapping) o DSCP-Passthrough at the wireless access point (effectively a 1:1
DSCP-to-DSCP mapping)
Alternatively, the network administrator MAY choose to use the As an alternative to the latter two options, the network
wireless-to-wired edge as a Diffserv boundary and explicitly set (or administrator MAY choose to use the wireless-to-wired edge as a
reset) DSCP markings according to administrative policy, thus making Diffserv boundary and explicitly set (or reset) DSCP markings
the wireless edge a Diffserv policy enforcement point. according to administrative policy, thus making the wireless edge a
Diffserv policy enforcement point. This is RECOMMENDED whenever
supported.
Each of these options will now be considered. Each of these options will now be considered.
5.1. Upstream DSCP-to-UP Mapping within the Wireless Client Operating 5.1. Upstream DSCP-to-UP Mapping within the Wireless Client Operating
System System
Some operating systems on wireless client devices utilize a similar Some operating systems on wireless client devices utilize a similar
default DSCP-to-UP mapping scheme as described in Section 2.2. As default DSCP-to-UP mapping scheme as described in Section 2.2. As
such, this can lead to the same conflicts as described in that such, this can lead to the same conflicts as described in that
section, but in the upstream direction. section, but in the upstream direction.
skipping to change at page 21, line 34 skipping to change at page 22, line 18
As such, UP-to-DSCP mapping allows for wireless L2 markings to affect As such, UP-to-DSCP mapping allows for wireless L2 markings to affect
the QoS treatment of a packet over the wired IP network (that is, the QoS treatment of a packet over the wired IP network (that is,
until the packet reaches the nearest classification and marking until the packet reaches the nearest classification and marking
policy enforcement point). policy enforcement point).
It should be further noted that nowhere in the [IEEE.802.11-2016] It should be further noted that nowhere in the [IEEE.802.11-2016]
specifications is there an intent expressed for UP markings to be specifications is there an intent expressed for UP markings to be
used to influence QoS treatment over wired IP networks. Furthermore, used to influence QoS treatment over wired IP networks. Furthermore,
[RFC2474], [RFC2475] and [RFC8100] all allow for the host to set DSCP [RFC2474], [RFC2475] and [RFC8100] all allow for the host to set DSCP
markings for end-to-end QoS treatment over IP networks. Therefore, markings for end-to-end QoS treatment over IP networks. Therefore,
it is NOT RECOMMENDED that wireless access points trust Layer 2 it is NOT RECOMMENDED that wireless access points leverage Layer 2
[IEEE.802.11-2016] UP markings as set by wireless hosts and [IEEE.802.11-2016] UP markings as set by wireless hosts and
subsequently perform a UP-to-DSCP mapping in the upstream direction, subsequently perform a UP-to-DSCP mapping in the upstream direction,
but rather, if wireless host markings are to be trusted (as per but rather, if wireless host markings are to be leveraged (as per
business requirements, technical constraints and administrative business requirements, technical constraints and administrative
policies), then it is RECOMMENDED to trust the Layer 3 DSCP markings policies), then it is RECOMMENDED to pass through the Layer 3 DSCP
set by these wireless hosts instead, as is discussed in the next markings set by these wireless hosts instead, as is discussed in the
section. next section.
5.3. Upstream DSCP-Trust at the Wireless Access Point 5.3. Upstream DSCP-Passthrough at the Wireless Access Point
It is generally NOT RECOMMENDED to trust DSCP markings from It is generally NOT RECOMMENDED to pass through DSCP markings from
unauthenticated and unauthorized devices, as these are typically unauthenticated and unauthorized devices, as these are typically
considered untrusted sources. considered untrusted sources.
When business requirements and/or technical constraints and/or When business requirements and/or technical constraints and/or
administrative policies require a trust function at the wireless administrative policies require QoS markings to be passed through at
edge, then it is RECOMMENDED to trust DSCP (over [IEEE.802.11-2016] the wireless edge, then it is RECOMMENDED to pass through Layer 3
UP markings) markings in the upstream direction, for the following DSCP markings (over Layer 2 [IEEE.802.11-2016] UP markings) in the
reasons: upstream direction, for the following 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 present wireless device operating systems generate UP values 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 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, 3 MSB of the encapsulated 6-bit DSCP); then, at the access point,
these 3-bit markings are converted back into DSCP values, these 3-bit markings are converted back into DSCP values,
typically in the default manner described in Section 2.3; as such, 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 information is lost in the translation from a 6-bit marking to a
3-bit marking (which is then subsequently translated back to a 3-bit marking (which is then subsequently translated back to a
6-bit marking); trusting the original (encapsulated) DSCP marking 6-bit marking); passing through the original (encapsulated) DSCP
prevents such loss of information marking prevents such loss of information
o A practical implementation benefit is also realized by trusting o A practical implementation benefit is also realized by passing
the DSCP set by wireless client devices, as enabling applications through the DSCP set by wireless client devices, as enabling
to mark DSCP is much more prevalent and accessible to programmers applications to mark DSCP is much more prevalent and accessible to
of applications running on wireless device platforms, vis-a-vis programmers of applications running on wireless device platforms,
trying to explicitly set UP values, which requires special hooks vis-a-vis trying to explicitly set UP values, which requires
into the wireless device operating system and/or hardware device special hooks into the wireless device operating system and/or
drivers, many of which do not support such functionality hardware device 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
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
skipping to change at page 29, line 20 skipping to change at page 30, line 20
infrastructure devices through the IEEE 802.11 medium are not infrastructure devices through the IEEE 802.11 medium are not
included in the cases covered by the presence of the QoS Map element, included in the cases covered by the presence of the QoS Map element,
and therefore are not included in the present recommendation. and therefore are not included in the present recommendation.
7. IANA Considerations 7. IANA Considerations
This memo asks the IANA for no new parameters. This memo asks the IANA for no new parameters.
8. Security Considerations 8. Security Considerations
The recommendations put forward in this document do not present any The recommendations in this document concern widely-deployed wired
additional security concerns that do not already exist in wired and and wireless network functionality, and for that reason do not
wireless devices. In fact, several of the recommendations made in present additional security concerns that do not already exist in
this document serve to mitigate and protect wired and wireless these networks. In fact, several of the recommendations made in this
networks from potential abuse arising from existing vulnerabilities. document serve to protect wired and wireless networks from potential
abuse, as is discussed further in this section.
8.1. General QoS Security Recommendations 8.1. General QoS Security Recommendations
It may be possible for a wired or wireless device (which could be It may be possible for a wired or wireless device (which could be
either a host or a network device) to mark packets (or map packet either a host or a network device) to mark packets (or map packet
markings) in a manner that interferes with or degrades existing QoS markings) in a manner that interferes with or degrades existing QoS
policies. Such marking or mapping may be done intentionally or policies. Such marking or mapping may be done intentionally or
unintentionally by developers and/or users and/or administrators of unintentionally by developers and/or users and/or administrators of
such devices. such devices.
To illustrate: A gaming application designed to run on a smart-phone To illustrate: A gaming application designed to run on a smart-phone
or tablet may request that all its packets be marked DSCP EF and/or or tablet may request that all its packets be marked DSCP EF and/or
UP 6. However, if the traffic from such an application is trusted UP 6. However, if the traffic from such an application is forwarded
over a business network, then this could interfere with QoS policies without change over a business network, then this could interfere
intended to provide priority services for business voice with QoS policies intended to provide priority services for business
applications. voice applications.
To mitigate such scenarios it is RECOMMENDED to implement general QoS To mitigate such scenarios it is RECOMMENDED to implement general QoS
security measures, including: security measures, including:
Setting a trust boundary reflective of business objectives and Setting a traffic conditioning policy reflective of business
policy, such that traffic from authorized users and/or objectives and policy, such that traffic from authorized users
applications and/or endpoints will be accepted by the network; and/or applications and/or endpoints will be accepted by the
otherwise packet markings will be "bleached" (i.e. remarked to network; otherwise packet markings will be "bleached" (i.e.
DSCP DF and/or UP 0). Additionally, Section 5.3 made it clear remarked to DSCP DF and/or UP 0). Additionally, Section 5.3 made
that it is generally NOT RECOMMENDED to trust DSCP markings from it clear that it is generally NOT RECOMMENDED to pass through DSCP
unauthorized and/or unauthenticated devices, as these are markings from unauthorized and/or unauthenticated devices, as
typically considered untrusted sources. This is especially these are typically considered untrusted sources. This is
relevant for IoT deployments, where tens-of-billions of devices especially relevant for IoT deployments, where tens-of-billions of
are being connected to IP networks, many of which have little or devices that may have little or no security are being connected to
no security. IP networks.
Policing EF marked packet flows, as detailed in [RFC2474] Policing EF marked packet flows, as detailed in [RFC2474]
Section 7 and [RFC3246] Section 3. Section 7 and [RFC3246] Section 3.
In addition to these general QoS security recommendations, WLAN- In addition to these general QoS security recommendations, WLAN-
specific QoS security recommendations can serve to further mitigate specific QoS security recommendations can serve to further mitigate
attacks and potential network abuse. attacks and potential network abuse.
8.2. WLAN QoS Security Recommendations 8.2. WLAN QoS Security Recommendations
skipping to change at page 30, line 29 skipping to change at page 31, line 30
basis with the network (as represented by the AP). This means that basis with the network (as represented by the AP). This means that
any wireless client could potentially monopolize the air by sending any wireless client could potentially monopolize the air by sending
packets marked to preferred UP values (i.e. UP values 4-7) in the packets marked to preferred UP values (i.e. UP values 4-7) in the
upstream direction. Similarly, airtime could be monopolized if upstream direction. Similarly, airtime could be monopolized if
excessive amounts of downstream traffic were marked/mapped to these excessive amounts of downstream traffic were marked/mapped to these
same preferred UP values. As such, the ability to mark/map to these same preferred UP values. As such, the ability to mark/map to these
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 to UP 7 and DSCP downstream. This codepoint would map by default (as described
would be assigned to the Voice Access Category (AC_VO). Such a flood in Section 2.2) to UP 7 and would be assigned to the Voice Access
could cause Denial-of-Service to not only wireless voice Category (AC_VO). Such a flood could cause Denial-of-Service to not
applications, but also to all other traffic classes. only wireless voice applications, but also to all other traffic
classes. Similarly, an uninformed application developer may request
all traffic from his/her application to be marked CS7 or CS6,
thinking this would acheive in the best overall servicing oftheir
application traffic, while not realizing that such a marking (if
honored by the client operating system) could cause not only WLAN
DoS, but also IP network instability, as the traffic marked CS7 or
CS6 finds its way into queues intended for servicing (relatively low-
bandwidth) network control protocols, potentially starving legitimate
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. network be mapped to UP 0; this recommendation applies both at the
access point (in the downstream direction) and within the wireless
endpoint device operating system (in the upstream direction).
Such a policy of mapping unused codepoints to UP 0 would also prevent Such a policy of mapping unused codepoints to UP 0 would also prevent
an attack where non-standard codepoints were used to cause WLAN DoS. an attack where non-standard codepoints were used to cause WLAN DoS.
Consider the case where codepoints are mapped to UP values using a Consider the case where codepoints are mapped to UP values using a
range function (e.g. DSCP values 48-55 all map to UP 6), then an range function (e.g. DSCP values 48-55 all map to UP 6), then an
attacker could flood packets marked, for example to DSCP 49, in attacker could flood packets marked, for example to DSCP 49, in
either the upstream or downstream direction over the WLAN, causing either the upstream or downstream direction over the WLAN, causing
DoS to all other traffic classes in the process. DoS to all other traffic classes in the process.
It should be strongly noted that in the wireless deployment model In the majority of WLAN deployments, the AP represents not only the
where the AP represents not only the edge of the Diffserv domain, but edge of the Diffserv domain, but also the edge of the network
also the edge of the network infrastructure itselt, then CS6 and CS7 infrastructure itself; that is, only wireless client endpoint devices
are downstream from the AP. In such a deployment model, CS6 and CS7
also fall into the category of codepoints that are not in use over also fall into the category of codepoints that are not in use over
the wireless LAN. This is because only wireless endpoint client the wireless LAN (since only wireless endpoint client devices are
devices are downstream from the AP in this model, and as such, these downstream from the AP in this model and these devices do not
devices do not (legitimately) participate in network control protocol [legitimately] participate in network control protocol exchanges).
exchanges. As such, it is RECOMMENDED that CS6 and CS7 DSCP be As such, it is RECOMMENDED that CS6 and CS7 DSCP be mapped to UP 0 in
mapped to UP 0 in these Wifi-at-the-edge deployment models. these Wifi-at-the-edge deployment models. Otherwise, it would be
Otherwise, it would be easy for a malicious developer, or even an easy for a malicious application developer, or even an inadvertently
inadvertently poorly-programmed IoT device, to cause WLAN DoS and poorly-programmed IoT device, to cause WLAN DoS and even wired IP
even wired IP network instability by flooding traffic marked CS6 network instability by flooding traffic marked CS6 DSCP, which would
DSCP, which would (by default) be mapped to UP 6, causing all other by default (as described in Section 2.2) be mapped to UP 6, causing
traffic classes on the WLAN to be starved, as well hijacking queues all other traffic classes on the WLAN to be starved, as well
on the wired IP network that are intended for the servicing of hijacking queues on the wired IP network that are intended for the
routing protocols. To this point, it was also recommended in servicing of routing protocols. To this point, it was also
Section 5.1 that packets requesting a marking of CS6 or CS7 DSCP recommended in Section 5.1 that packets requesting a marking of CS6
SHOULD be remarked to DSCP 0 and mapped to UP 0 by the wireless or CS7 DSCP SHOULD be remarked to DSCP 0 and mapped to UP 0 by the
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 include strong device- and/or user-
authentication, access-control, rate limiting, control-plane authentication, access-control, rate limiting, control-plane
policing, encryption and other techniques; however, the policing, encryption and other techniques; however, the
implementation recommendations for such mechanisms are beyond the implementation recommendations for such mechanisms are beyond the
scope of this document to address in detail. Suffice it to say that scope of this document to address in detail. Suffice it to say that
the security of the devices and networks implementing QoS, including the security of the devices and networks implementing QoS, including
skipping to change at page 32, line 35 skipping to change at page 33, line 41
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<http://www.rfc-editor.org/info/rfc2475>. <http://www.rfc-editor.org/info/rfc2475>.
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, "Assured Forwarding PHB Group", RFC 2597,
DOI 10.17487/RFC2597, June 1999, DOI 10.17487/RFC2597, June 1999,
<http://www.rfc-editor.org/info/rfc2597>. <http://www.rfc-editor.org/info/rfc2597>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001,
<http://www.rfc-editor.org/info/rfc3168>.
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,
J., Courtney, W., Davari, S., Firoiu, V., and D. J., Courtney, W., Davari, S., Firoiu, V., and D.
Stiliadis, "An Expedited Forwarding PHB (Per-Hop Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002, Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002,
<http://www.rfc-editor.org/info/rfc3246>. <http://www.rfc-editor.org/info/rfc3246>.
[RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort
Per-Domain Behavior (PDB) for Differentiated Services", Per-Domain Behavior (PDB) for Differentiated Services",
RFC 3662, DOI 10.17487/RFC3662, December 2003, RFC 3662, DOI 10.17487/RFC3662, December 2003,
<http://www.rfc-editor.org/info/rfc3662>. <http://www.rfc-editor.org/info/rfc3662>.
 End of changes. 64 change blocks. 
182 lines changed or deleted 238 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/