draft-ietf-tsvwg-ieee-802-11-09.txt   draft-ietf-tsvwg-ieee-802-11-10.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: Best Current Practice Cisco Systems
Expires: March 22, 2018 F. Baker Expires: June 18, 2018 F. Baker
September 18, 2017 December 15, 2017
Diffserv to IEEE 802.11 Mapping Diffserv to IEEE 802.11 Mapping
draft-ietf-tsvwg-ieee-802-11-09 draft-ietf-tsvwg-ieee-802-11-10
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 of 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
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 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 22, 2018. This Internet-Draft will expire on June 18, 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 19 skipping to change at page 2, line 19
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Related work . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Related work . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Interaction with RFC 7561 . . . . . . . . . . . . . . . . 4 1.2. Interaction with RFC 7561 . . . . . . . . . . . . . . . . 4
1.3. Applicability Statement . . . . . . . . . . . . . . . . . 4 1.3. Applicability Statement . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1. Diffserv Domain Boundaries . . . . . . . . . . . . . . . 9 2.1. Diffserv Domain Boundaries . . . . . . . . . . . . . . . 9
2.2. Default DSCP-to-UP Mappings and Conflicts . . . . . . . . 10 2.2. EDCF Queuing . . . . . . . . . . . . . . . . . . . . . . 10
2.3. Default UP-to-DSCP Mappings and Conflicts . . . . . . . . 11 2.3. Default DSCP-to-UP Mappings and Conflicts . . . . . . . . 10
2.4. 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 . . . . . . . . . . . . . . . . . . . . . . . 13
4. DSCP-to-UP Mapping Recommendations . . . . . . . . . . . . . 13 4. DSCP-to-UP Mapping Recommendations . . . . . . . . . . . . . 13
4.1. Network Control Traffic . . . . . . . . . . . . . . . . . 13 4.1. Network Control Traffic . . . . . . . . . . . . . . . . . 14
4.1.1. Network Control Protocols . . . . . . . . . . . . . . 14 4.1.1. Network Control Protocols . . . . . . . . . . . . . . 14
4.1.2. Operations Administration Management (OAM) . . . . . 14 4.1.2. Operations Administration Management (OAM) . . . . . 15
4.2. User Traffic . . . . . . . . . . . . . . . . . . . . . . 15 4.2. User Traffic . . . . . . . . . . . . . . . . . . . . . . 15
4.2.1. Telephony . . . . . . . . . . . . . . . . . . . . . . 15 4.2.1. Telephony . . . . . . . . . . . . . . . . . . . . . . 15
4.2.2. Signaling . . . . . . . . . . . . . . . . . . . . . . 15 4.2.2. Signaling . . . . . . . . . . . . . . . . . . . . . . 16
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 . . . . . . . . . . . . . . . . 17
4.2.5. Multimedia-Streaming . . . . . . . . . . . . . . . . 17 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 . . . . . . . . . . . . . . . . . . 18
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 . . . . . . . . . . . . . . . 19
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 . . . . . . . 20
5. Upstream Mapping and Marking Recommendations . . . . . . . . 20 5. Upstream Mapping and Marking Recommendations . . . . . . . . 21
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 . . . . . . . . . . . . . . . . . . . . 22
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 22
5.3. Upstream DSCP-Passthrough at the Wireless Access Point . 22 5.3. Upstream DSCP-Passthrough at the Wireless Access Point . 23
5.4. Upstream DSCP Marking at the Wireless Access Point . . . 23 5.4. Upstream DSCP Marking at the Wireless Access Point . . . 24
6. IEEE 802.11 QoS Overview . . . . . . . . . . . . . . . . . . 23 6. IEEE 802.11 QoS Overview . . . . . . . . . . . . . . . . . . 24
6.1. Distributed Coordination Function (DCF) . . . . . . . . . 23 6.1. Distributed Coordination Function (DCF) . . . . . . . . . 24
6.1.1. Slot Time . . . . . . . . . . . . . . . . . . . . . . 24 6.1.1. Slot Time . . . . . . . . . . . . . . . . . . . . . . 25
6.1.2. Interframe Spaces . . . . . . . . . . . . . . . . . . 24 6.1.2. Interframe Spaces . . . . . . . . . . . . . . . . . . 25
6.1.3. Contention Windows . . . . . . . . . . . . . . . . . 25 6.1.3. Contention Windows . . . . . . . . . . . . . . . . . 26
6.2. Hybrid Coordination Function (HCF) . . . . . . . . . . . 27
6.2. Hybrid Coordination Function (HCF) . . . . . . . . . . . 26 6.2.1. User Priority (UP) . . . . . . . . . . . . . . . . . 27
6.2.1. User Priority (UP) . . . . . . . . . . . . . . . . . 26 6.2.2. Access Category (AC) . . . . . . . . . . . . . . . . 27
6.2.2. Access Category (AC) . . . . . . . . . . . . . . . . 26 6.2.3. Arbitration Inter-Frame Space (AIFS) . . . . . . . . 28
6.2.3. Arbitration Inter-Frame Space (AIFS) . . . . . . . . 27 6.2.4. Access Category Contention Windows (CW) . . . . . . . 29
6.2.4. Access Category Contention Windows (CW) . . . . . . . 28 6.3. IEEE 802.11u QoS Map Set . . . . . . . . . . . . . . . . 30
6.3. IEEE 802.11u QoS Map Set . . . . . . . . . . . . . . . . 29 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 8. Security Considerations . . . . . . . . . . . . . . . . . . . 31
8. Security Considerations . . . . . . . . . . . . . . . . . . . 30 8.1. General QoS Security Recommendations . . . . . . . . . . 31
8.1. General QoS Security Recommendations . . . . . . . . . . 30 8.2. WLAN QoS Security Recommendations . . . . . . . . . . . . 32
8.2. WLAN QoS Security Recommendations . . . . . . . . . . . . 31 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 10.1. Normative References . . . . . . . . . . . . . . . . . . 34
10.1. Normative References . . . . . . . . . . . . . . . . . . 33 10.2. Informative References . . . . . . . . . . . . . . . . . 35
10.2. Informative References . . . . . . . . . . . . . . . . . 34 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 36
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
Wireless has become the preferred medium for endpoints connecting to IEEE 802.11 [IEEE.802.11-2016] wireless has become the preferred
business and private networks. However, the wireless medium defined medium for endpoints connecting to business and private networks.
by IEEE 802.11 [IEEE.802.11-2016] presents several design challenges However, the wireless medium defined by IEEE 802.11
for ensuring end-to-end quality of service. Some of these challenges [IEEE.802.11-2016] presents several design challenges for ensuring
relate to the nature of the IEEE 802.11 RF medium itself, being a end-to-end quality of service. Some of these challenges relate to
half-duplex and shared medium, while other challenges relate to the the nature of the IEEE 802.11 Radio Frequency (RF) medium itself,
fact that the IEEE 802.11 standard is not administered by the same being a half-duplex and shared medium, while other challenges relate
standards body as IP networking standards. While the IEEE has to the fact that the IEEE 802.11 standard is not administered by the
same standards body as IP networking standards. While the IEEE has
developed tools to enable QoS over wireless networks, little guidance developed tools to enable QoS over wireless networks, little guidance
exists on how to maintain consistency of QoS treatment between wired exists on how to maintain consistency of QoS treatment between wired
IP and wireless IEEE 802.11 networks. The purpose of this document IP and wireless IEEE 802.11 networks. The purpose of this document
is to provide such guidance. is to provide such guidance.
1.1. Related work 1.1. Related work
Several RFCs outline Diffserv QoS recommendations over IP networks, Several RFCs outline Diffserv QoS recommendations over IP networks,
including: including:
skipping to change at page 4, line 28 skipping to change at page 4, line 30
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) on DSCP to UP Mapping, specifically Communications Association (GSMA) on DSCP to UP Mapping for IP Packet
their Guidelines for IPX Provider networks [GSMA-IPX_Guidelines]. eXchange (IPX), specifically their Guidelines for IPX Provider
These GSMA Guidelines were developed without reference to existing networks [GSMA-IPX_Guidelines]. These GSMA Guidelines were developed
IETF specifications for various services, referenced in Section 1.1. without reference to existing IETF specifications for various
In turn, [RFC7561] was written based on these GSMA Guidelines, as services, referenced in Section 1.1. In turn, [RFC7561] was written
explicitly called out in [RFC7561] Section 4.2. Thus, [RFC7561] based on these GSMA Guidelines, as explicitly called out in [RFC7561]
conflicts with the overall Diffserv traffic-conditioning service Section 4.2. Thus, [RFC7561] conflicts with the overall Diffserv
plan, both in the services specified and the code points specified traffic-conditioning service plan, both in the services specified and
for them. As such, these two plans cannot be normalized. Rather, as the code points specified for them. As such, these two plans cannot
discussed in [RFC2474] Section 2, the two domains (IEEE 802.11 and be normalized. Rather, as discussed in [RFC2474] Section 2, the two
GSMA) are different Differentiated Services Domains separated by a domains (IEEE 802.11 and GSMA) are different Differentiated Services
Differentiated Services Boundary. At that boundary, code points from Domains separated by a Differentiated Services Boundary. At that
one domain are translated to code points for the other, and maybe to boundary, code points from one domain are translated to code points
Default (zero) if there is no corresponding service to translate to. 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 47 skipping to change at page 5, line 50
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 o Section 7 on notes IANA considerations
o Section 8 presents security considerations relative to DSCP-to-UP, o Section 8 presents security considerations relative to DSCP-to-UP,
UP-to-DSCP mapping and remarking 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", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
1.6. Terminology Used in this Document 1.6. Terminology Used in this Document
Key terminology used in this document includes: Key terminology used in this document includes:
AC: Access Category. A label for the common set of enhanced AC: Access Category. A label for the common set of enhanced
distributed channel access (EDCA) parameters that are used by a distributed channel access (EDCA) parameters that are used by a
quality-of-service (QoS) station (STA) to contend for the channel quality-of-service (QoS) station (STA) to contend for the channel
in order to transmit medium access control (MAC) service data in order to transmit medium access control (MAC) service data
units (MSDUs) with certain priorities. [IEEE.802.11-2016] units (MSDUs) with certain priorities. [IEEE.802.11-2016]
skipping to change at page 7, line 29 skipping to change at page 7, line 32
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 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 of Service (TOS) Byte (the remaining 2 bits are used for IP
Explicit Congestion Notification [RFC3168]). Explicit Congestion Notification [RFC3168]).
EIFS: Extended Interframe Space. A unit of time that a station
has to defer before transmitting a frame if the previous frame
contained an error, as per [IEEE.802.11-2016] Section 10.3.2.3.7.
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
of Interframe Spaces. of Interframe Spaces.
skipping to change at page 8, line 41 skipping to change at page 8, line 49
UP: User Priority. A value associated with a medium access UP: User Priority. A value associated with a medium access
control (MAC) service data unit (MSDU) that indicates how the MSDU control (MAC) service data unit (MSDU) that indicates how the MSDU
is to be handled. The UP is assigned to an MSDU in the layers is to be handled. The UP is assigned to an MSDU in the layers
above the MAC [IEEE.802.11-2016] Section 3.1. The UP defines a above the MAC [IEEE.802.11-2016] Section 3.1. The UP defines a
level of priority for the associated frame, on a scale of 0 to 7. level of priority for the associated frame, on a scale of 0 to 7.
Wi-Fi: An interoperability certification defined by the Wi-Fi Wi-Fi: An interoperability certification defined by the Wi-Fi
Alliance. However, this term is commonly used, including in the Alliance. However, this term is commonly used, including in the
present document, to be the equivalent of IEEE 802.11. present document, to be the equivalent of IEEE 802.11.
Wireless: In the context of this document, "wireless" refers to
the media defined in IEEE 802.11 [IEEE.802.11-2016], and not 3G/4G
LTE or any other radio telecommunications specification.
2. Service Comparison and Default Interoperation of Diffserv and IEEE 2. Service Comparison and Default Interoperation of Diffserv and IEEE
802.11 802.11
(Section 6 provides a brief overview of IEEE 802.11 QoS.) (Section 6 provides a brief overview of IEEE 802.11 QoS.)
The following comparisons between IEEE 802.11 and Diffserv services The following comparisons between IEEE 802.11 and Diffserv services
should be noted: should be noted:
o [IEEE.802.11-2016] does not support an EF PHB service [RFC3246], o [IEEE.802.11-2016] does not support an EF PHB service [RFC3246],
as it is not possible to assure that a given access category will as it is not possible to assure that a given access category will
skipping to change at page 9, line 48 skipping to change at page 10, line 10
not used downstream from the AP in this deployment model) to UP 0. 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, and as such network control protocols are the access points, and as such network control protocols are
recommended to be mapped to UP 7 in this deployment model, as is RECOMMENDED to be mapped to UP 7 in this deployment model, as is
discussed in Section 4.1.1. discussed in Section 4.1.1.
Thus, as can be seen from these two examples, the QoS treatment of Thus, as can be seen from these two examples, the QoS treatment of
packets at the access point will depend on the position of the AP in packets at the access point will depend on the position of the AP in
the network infrastructure and on the WLAN 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. EDCF Queuing
[IEEE.802.11-2016] displays a reference implementation queuing model
in Figure 10-24, which depicts four transmit queues, one per access
category.
However, in practical implementations, it is common for WLAN network
equipment vendors to implement dedicated transmit queues on a per-UP
(versus a per access category) basis, which are then dequeued into
their associated access category in a preferred (or even in a strict
priority manner). For example, it is common for vendors to dequeue
UP 5 ahead of UP 4 to the hardware performing the EDCA function
(EDCAF) for the Video Access Category (AC_VI).
Some of the recommendations made in Section 4 make reference to this
common implementation model of queuing per UP.
2.3. 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
802.11e), a common practice in the networking industry is to map 802.11e), a common practice in the networking industry is to map
these by what we will refer to as 'Default DSCP-to-UP Mapping' (for these by what we will refer to as 'Default DSCP-to-UP Mapping' (for
lack of a better term), wherein the 3 Most Significant Bits (MSB) of lack of a better term), wherein the 3 Most Significant Bits (MSB) of
the DSCP are used as the corresponding L2 markings. the DSCP are used as the corresponding L2 markings.
Note: There are mappings provided in [IEEE.802.11-2016] Annex V Note: There are mappings provided in [IEEE.802.11-2016] Annex V
Tables V-1 and V2, but it bears mentioning that these mappings are Tables V-1 and V2, but it bears mentioning that these mappings are
provided as examples (as opposed to explicit recommendations). provided as examples (as opposed to explicit recommendations).
Furthermore, some of these mappings do not align with the intent and Furthermore, some of these mappings do not align with the intent and
recommendations expressed in [RFC4594], as will be discussed in this recommendations expressed in [RFC4594], as will be discussed in this
and the following section (Section 2.3). and the following section (Section 2.4).
However, when this default DSCP-to-UP mapping method is applied to However, when this default DSCP-to-UP mapping method is applied to
packets marked per [RFC4594] recommendations and destined to 802.11 packets marked per [RFC4594] recommendations and destined to 802.11
WLAN clients, it will yield a number of inconsistent QoS mappings, WLAN clients, it will yield a number of inconsistent QoS mappings,
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
skipping to change at page 11, line 16 skipping to change at page 11, line 42
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
(and hence to ACs) (and hence to ACs)
o define how UPs should translate to other medium Layer 2 QoS o define how UPs should translate to other medium Layer 2 QoS
markings markings
o strictly restrict each access category to applications reflected o strictly restrict each access category to applications reflected
in the AC name in the AC name
2.3. Default UP-to-DSCP Mappings and Conflicts 2.4. Default UP-to-DSCP Mappings and Conflicts
In the opposite direction of flow (the upstream direction, that is, In the opposite direction of flow (the upstream direction, that is,
from wireless-to-wired), many APs use what we will refer to as from wireless-to-wired), many APs use what we will refer to as
'Default UP-to-DSCP Mapping' (for lack of a better term), wherein 'Default UP-to-DSCP Mapping' (for lack of a better term), wherein
DSCP values are derived from UP values by multiplying the UP values DSCP values are derived from UP values by multiplying the UP values
by 8 (i.e. shifting the 3 UP bits to the left and adding three by 8 (i.e. shifting the 3 UP bits to the left and adding three
additional zeros to generate a DSCP value). This derived DSCP value additional zeros to generate a DSCP value). This derived DSCP value
is then used for QoS treatment between the wireless access point and is then used for QoS treatment between the wireless access point and
the nearest classification and marking policy enforcement point the nearest classification and marking policy enforcement point
(which may be the centralized wireless LAN controller, relatively (which may be the centralized wireless LAN controller, relatively
skipping to change at page 13, line 8 skipping to change at page 13, line 33
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/
or wireless network interface hardware drivers) or wireless network interface hardware drivers)
Having made the assumptions and recommendations above, it bears Having made the assumptions and recommendations above, it bears
mentioning while the mappings presented in this document are mentioning while the mappings presented in this document are
RECOMMENDED to replace the current common default practices (as RECOMMENDED to replace the current common default practices (as
discussed in Section 2.2 and Section 2.3), these mapping discussed in Section 2.3 and Section 2.4), these mapping
recommendations are not expected to fit every last deployment model, recommendations are not expected to fit every last deployment model,
and as such MAY be overridden by network administrators, as needed. and as such MAY be overridden by network administrators, as needed.
4. DSCP-to-UP Mapping Recommendations 4. DSCP-to-UP Mapping Recommendations
The following section specifies downstream (wired-to-wireless) The following section specifies downstream (wired-to-wireless)
mappings between [RFC4594] Configuration Guidelines for Diffserv mappings between [RFC4594] Configuration Guidelines for Diffserv
Service Classes and [IEEE.802.11-2016]. As such, this section draws Service Classes and [IEEE.802.11-2016]. As such, this section draws
heavily from [RFC4594], including service class definitions and heavily from [RFC4594], including service class definitions and
recommendations. recommendations.
This section assumes [IEEE.802.11-2016] wireless access points and/or This section assumes [IEEE.802.11-2016] wireless access points and/or
WLAN controllers that support customizable, non-default DSCP-to-UP WLAN controllers that support customizable, non-default DSCP-to-UP
mapping schemes. mapping schemes.
This section also assumes that [IEEE.802.11-2016] access points and This section also assumes that [IEEE.802.11-2016] access points and
endpoint devices differentiate UP markings with corresponding queuing endpoint devices differentiate UP markings with corresponding queuing
and dequeuing treatments. To illustrate, [IEEE.802.11-2016] displays and dequeuing treatments, as described in Section 2.2.
a reference implementation model in Figure 10-24 which depicts four
transmit queues, one per access category. In practical
implementations, however, it is common for WLAN network equipment
vendors to implement dedicated transmit queues on a per-UP (versus a
per access category) basis, which are then dequeued into their
associated access category in a preferred (or even in a strict
priority manner). For example, it is common for vendors to dequeue
UP 5 ahead of UP 4 to the hardware performing the EDCA function
(EDCAF) for the Video Access Category (AC_VI). As such, Signaling
traffic (marked UP 5, per the recommendations made in Section 4.2.2)
may benefit from such a treatment versus other video flows in the
same access category which are marked to UP 4 (in addition to a
preferred treatment over flows in the Best Effort and Background
access categories).
4.1. Network Control Traffic 4.1. Network Control Traffic
Network control traffic is defined as packet flows that are essential Network control traffic is defined as packet flows that are essential
for stable operation of the administered network [RFC4594] Section 3. for stable operation of the administered network [RFC4594] Section 3.
Network control traffic is different from user application control Network control traffic is different from user application control
(signaling) that may be generated by some applications or services. (signaling) that may be generated by some applications or services.
Network control traffic MAY be split into two service classes: Network control traffic MAY be split into two service classes:
o Network Control, and o Network Control, and
skipping to change at page 14, line 13 skipping to change at page 14, line 25
o Operations Administration and Management (OAM) o Operations Administration and Management (OAM)
4.1.1. Network Control Protocols 4.1.1. Network Control Protocols
The Network Control service class is used for transmitting packets The Network Control service class is used for transmitting packets
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 [RFC4594] Section 3.2 recommends that Network Control traffic be
[RFC4594] Section 3.2; additionally, CS7 DSCP value SHOULD be marked CS6 DSCP. Additionally, as stated in [RFC4594] Section 3.1:
reserved for future use, potentially for future routing or control "CS7 DSCP value SHOULD be reserved for future use, potentially for
protocols, again, per [RFC4594] Section 3.2. future routing or control protocols."
By default (as described in Section 2.2), packets marked DSCP CS7 By default (as described in Section 2.3), packets marked DSCP CS7
will be mapped to UP 7 and serviced within the Voice Access Category will be mapped to UP 7 and serviced within the Voice Access Category
(AC_VO). This represents the RECOMMENDED mapping for CS7, that is, (AC_VO). This represents the RECOMMENDED mapping for CS7, that is,
packets marked to CS7 DSCP are RECOMMENDED to be mapped to UP 7. packets marked to CS7 DSCP are RECOMMENDED to be mapped to UP 7.
However, by default (as described in Section 2.2), packets marked However, by default (as described in Section 2.3), packets marked
DSCP CS6 will be mapped to UP 6 and serviced within the Voice Access DSCP CS6 will be mapped to UP 6 and serviced within the Voice Access
Category (AC_VO); such mapping and servicing is a contradiction to Category (AC_VO); such mapping and servicing is a contradiction to
the intent expressed in [RFC4594] Section 3.2. As such, it is the intent expressed in [RFC4594] Section 3.2. As such, it is
RECOMMENDED to map Network Control traffic marked CS6 to UP 7 (per RECOMMENDED to map Network Control traffic marked CS6 to UP 7 (per
[IEEE.802.11-2016] Section 10.2.4.2, Table 10-1), thereby admitting [IEEE.802.11-2016] Section 10.2.4.2, Table 10-1), thereby admitting
it to the Voice Access Category (AC_VO), albeit with a marking it to the Voice Access Category (AC_VO), albeit with a marking
distinguishing it from (data-plane) 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, Network Virtualization
control traffic for any physical network at the AP, and hence SHOULD Overlays, etc.) are not network control traffic for any physical
NOT be marked with CS6 in the first place. network at the AP, and hence SHOULD 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 OAM service class can include network management
[RFC4594] Section 3.3. protocols, such as SNMP, SSH, TFTP, Syslog, etc., as well as network
services, such as NTP, DNS, DHCP, etc. [RFC4594] Section 3.3
recommends that OAM traffic be marked CS2 DSCP.
By default (as described in Section 2.2), packets marked DSCP CS2 By default (as described in Section 2.3), packets marked DSCP CS2
will be mapped to UP 2 and serviced with the Background Access will be mapped to UP 2 and serviced with the Background Access
Category (AC_BK). Such servicing is a contradiction to the intent Category (AC_BK). Such servicing is a contradiction to the intent
expressed in [RFC4594] Section 3.3. As such, it is RECOMMENDED that expressed in [RFC4594] Section 3.3. As such, it is RECOMMENDED that
a non-default mapping be applied to OAM traffic, such that CS2 DSCP a non-default mapping be applied to OAM traffic, such that CS2 DSCP
is mapped to UP 0, thereby admitting it to the Best Effort Access is mapped to UP 0, thereby admitting it to the Best Effort Access
Category (AC_BE). 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
or a subset of the defined service classes. or a subset of the defined service classes.
4.2.1. Telephony 4.2.1. Telephony
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. [RFC4594] Section 4.1 recommends that
is EF ([RFC4594] Section 4.1). Telephony traffic be marked EF DSCP.
Traffic marked to DSCP EF will map by default (as described in Traffic marked to DSCP EF will map by default (as described in
Section 2.2) to UP 5, and thus to the Video Access Category (AC_VI), Section 2.3) to UP 5, and thus to the Video Access Category (AC_VI),
rather than to the Voice Access Category (AC_VO), for which it is rather than to the Voice Access Category (AC_VO), for which it is
intended. Therefore, a non-default DSCP-to-UP mapping is intended. Therefore, a non-default DSCP-to-UP mapping is
RECOMMENDED, such that EF DSCP is mapped to UP 6, thereby admitting RECOMMENDED, such that EF DSCP is mapped to UP 6, thereby admitting
it into the Voice Access Category (AC_VO). 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. [RFC4594] Section 4.2 recommends that
Signaling is CS5 ([RFC4594] Section 4.2). Signaling traffic be marked CS5 DSCP.
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 (as Access Category (AC_VI), which it will map to by default (as
described in Section 2.2). Therefore it is RECOMMENDED to map described in Section 2.3). Therefore it is RECOMMENDED to map
Signaling traffic marked CS5 DSCP to UP 5, thereby admitting it to Signaling traffic marked CS5 DSCP to UP 5, thereby admitting it to
the Video Access Category (AC_VI). 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. This
way this may be achieved in certain WLAN deployments is by mapping may be achieved in common WLAN deployments by mapping Signaling
Signaling traffic marked CS5 to UP 5 (as recommended above and traffic marked CS5 to UP 5. On APs supporting per-UP EDCAF queuing
following the EDCAF treatment logic described in Section 4. logic (as described in Section 2.2) this will result in preferential
treatment for Signaling traffic versus other video flows in the same
access category (AC_VI), which are marked to UP 4, as well as
preferred treatment over flows in the Best Effort (AC_BE) and
Background (AC_BK) access categories.
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. [RFC4594] Section 4.3 recommends Multimedia Conferencing
are AF41, AF42 and AF43 ([RFC4594] Section 4.3). traffic be marked AF4x (that is, AF41, AF42 and AF43, according to
the rules defined in [RFC2475]).
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 (as described in Section 2.2). Specifically, it is default (as described in Section 2.3). Specifically, it is
RECOMMENDED to map AF41, AF42 and AF43 to UP 4, thereby admitting RECOMMENDED to map AF41, AF42 and AF43 to UP 4, thereby admitting
Multimedia Conferencing into the Video 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). [RFC4594] Section 4.4 recommends
Real-Time Interactive traffic is CS4 ([RFC4594] Section 4.4). Real-Time Interactive traffic be marked CS4 DSCP.
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
(as described in Section 2.2). Specifically, it is RECOMMENDED to (as described in Section 2.3). Specifically, it is RECOMMENDED to
map CS4 to UP 4, thereby admitting Real-Time Interactive traffic into map CS4 to UP 4, thereby admitting Real-Time Interactive traffic into
the Video Access Category (AC_VI). 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. [RFC4594] Section 4.5 recommends Multimedia
Streaming are AF31, AF32 and AF33 ([RFC4594] Section 4.5). Streaming traffic be marked AF3x (that is, AF31, AF32 and AF33,
according to the rules defined in [RFC2475]).
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, which it will by default this class into the Video Access Category, which it will by default
(as described in Section 2.2). Specifically, it is RECOMMENDED to (as described in Section 2.3). Specifically, it is RECOMMENDED to
map AF31, AF32 and AF33 to UP 4, thereby admitting Multimedia map AF31, AF32 and AF33 to UP 4, thereby admitting Multimedia
Streaming into the Video Access Category (AC_VI). 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. [RFC4594] Section 4.6
marking for Broadcast Video is CS3 ([RFC4594] Section 4.6). recommends Broadcast Video traffic be marked CS3 DSCP.
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;
however, by default (as described in Section 2.2), this service class however, by default (as described in Section 2.3), this service class
will map to UP 3, and thus the Best Effort Access Category (AC_BE). 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 Therefore, a non-default mapping is RECOMMENDED, such that CS4 maps
to UP 4, thereby admitting Broadcast Video into the Video Access to UP 4, thereby admitting Broadcast Video into the Video Access
Category (AC_VI). 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. [RFC4594] Section 4.7 recommends Low-
Latency Data are AF21, AF22 and AF23 ([RFC4594] Section 4.7). Latency Data be marked AF2x (that is, AF21, AF22 and AF23, according
to the rules defined in [RFC2475]).
By default (as described in Section 2.2), Low-Latency Data will map By default (as described in Section 2.3), Low-Latency Data will map
to UP 2 and thus to the Background Access Category (AC_BK), which is to UP 2 and thus to the Background Access Category (AC_BK), which is
contrary to the intent expressed in [RFC4594]. contrary to the intent expressed in [RFC4594].
In line with the assumption made in Section 4, mapping Low-Latency Mapping Low-Latency Data to UP 3 may allow such to receive a superior
Data to UP 3 may allow such to receive a superior level of service level of service via per-UP transmit queues servicing the EDCAF
via transmit queues servicing the EDCAF hardware for the Best Effort hardware for the Best Effort Access Category (AC_BE), as described in
Access Category (AC_BE). Therefore it is RECOMMENDED to map Low- Section 2.2. Therefore it is RECOMMENDED to map Low-Latency Data
Latency Data traffic marked AF2x DSCP to UP 3, thereby admitting it traffic marked AF2x DSCP to UP 3, thereby admitting it to the Best
to the Best Effort Access Category (AC_BE). 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
applications that require timely packet forwarding of variable rate applications that require timely packet forwarding of variable rate
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 According to [RFC4594] Section 4.8, it can be assumed that this class
consume any available bandwidth and that packets traversing congested will consume any available bandwidth and that packets traversing
links may experience higher queuing delays or packet loss. It is congested links may experience higher queuing delays or packet loss.
also assumed that this traffic is elastic and responds dynamically to It is also assumed that this traffic is elastic and responds
packet loss. The RECOMMENDED DSCP markings for High-Throughput Data dynamically to packet loss. [RFC4594] Section 4.8 recommends High-
are AF11, AF12 and AF13 ([RFC4594] Section 4.8). Throughput Data be marked AF1x (that is, AF11, AF12 and AF13,
according to the rules defined in [RFC2475]).
By default (as described in Section 2.2), High-Throughput Data will By default (as described in Section 2.3), High-Throughput Data will
map to UP 1 and thus to the Background Access Category (AC_BK), which map to UP 1 and thus to the Background Access Category (AC_BK), which
is contrary to the intent expressed in [RFC4594]. 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
skipping to change at page 18, line 48 skipping to change at page 19, line 23
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).
As such, since there is no directly corresponding fit for the High- As such, since there is no directly corresponding fit for the High-
Throughout Data service class within the [IEEE.802.11-2016] model, it Throughout Data service class within the [IEEE.802.11-2016] model, it
is generally RECOMMENDED to map High-Throughput Data to UP 0, thereby is generally RECOMMENDED to map High-Throughput Data to UP 0, thereby
admitting it to the Best Effort Access Category (AC_BE). admitting it to the Best Effort Access Category (AC_BE).
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. [RFC4594]
DSCP marking for the Standard Service Class is DF. ([RFC4594] Section 4.9 states that the "Standard service class MUST use the
Section 4.9) Default Forwarding (DF) PHB."
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_BE) 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). This happens to correspond to the default mapping (as (AC_BE). This happens to correspond to the default mapping (as
described in Section 2.2). described in Section 2.3).
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].
[RFC3662] and [RFC4594] both recommend Low-Priority Data be marked
CS1 DSCP.
Note: This marking recommendation may change in the future, as
[I-D.ietf-tsvwg-le-phb] defines a Lower Effort (LE) per-hop behavior
(PHB) and states: "The RECOMMENDED codepoint for the LE PHB is
'000010'.
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 This happens to correspond to the default mapping (as described in
Section 2.2). Section 2.3).
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 |
skipping to change at page 20, line 36 skipping to change at page 21, line 18
| 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 unused 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 21, line 4 skipping to change at page 21, line 33
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 DSCP-to-UP mapping within the wireless client operating system,
and and
o UP-to-DSCP mapping at the wireless access point, or o UP-to-DSCP mapping at the wireless access point, or
o DSCP-Passthrough at the wireless access point (effectively a 1:1 o DSCP-Passthrough at the wireless access point (effectively a 1:1
DSCP-to-DSCP mapping) DSCP-to-DSCP mapping)
As an alternative to the latter two options, the network As an alternative to the latter two options, the network
administrator MAY choose to use the wireless-to-wired edge as a administrator MAY choose to use the wireless-to-wired edge as a
Diffserv boundary and explicitly set (or reset) DSCP markings Diffserv boundary and explicitly set (or reset) DSCP markings
according to administrative policy, thus making the wireless edge a according to administrative policy, thus making the wireless edge a
Diffserv policy enforcement point. This is RECOMMENDED whenever Diffserv policy enforcement point; this approach is RECOMMENDED
supported. whenever the APs support the required classification and marking
capabilities.
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.3. 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.
Therefore, to improve on these default mappings, and to achieve Therefore, to improve on these default mappings, and to achieve
parity and consistency with downstream QoS, it is RECOMMENDED that parity and consistency with downstream QoS, it is RECOMMENDED that
wireless client operating systems utilize instead the same DSCP-to-UP wireless client operating systems utilize instead the same DSCP-to-UP
mapping recommendations presented in Section 4, with the explicit mapping recommendations presented in Section 4, with the explicit
RECOMMENDATION that packets requesting a marking of CS6 or CS7 DSCP RECOMMENDATION that packets requesting a marking of CS6 or CS7 DSCP
SHOULD be mapped to UP 0 (and not to UP 7). Furthermore, in such SHOULD be mapped to UP 0 (and not to UP 7). Furthermore, in such
cases the wireless client operating system SHOULD remark such packets cases the wireless client operating system SHOULD remark such packets
skipping to change at page 21, line 44 skipping to change at page 22, line 33
recommendation is detailed in the Security Considerations section recommendation is detailed in the Security Considerations section
(Section 8). (Section 8).
5.2. Upstream UP-to-DSCP Mapping at the Wireless Access Point 5.2. Upstream UP-to-DSCP Mapping at the Wireless Access Point
UP-to-DSCP mapping generates a DSCP value for the IP packet (either UP-to-DSCP mapping generates a DSCP value for the IP packet (either
an unencapsulated IP packet or an IP packet encapsulated within a an unencapsulated IP packet or an IP packet encapsulated within a
tunneling protocol such as CAPWAP - and destined towards a wireless tunneling protocol such as CAPWAP - and destined towards a wireless
LAN controller for decapsulation and forwarding) from the Layer 2 LAN controller for decapsulation and forwarding) from the Layer 2
[IEEE.802.11-2016] UP marking. This is typically done in the manner [IEEE.802.11-2016] UP marking. This is typically done in the manner
described in Section 2.3. described in Section 2.4.
It should be noted that any explicit remarking policy to be performed It should be noted that any explicit remarking policy to be performed
on such a packet only takes place at the nearest classification and on such a packet only takes place at the nearest classification and
marking policy enforcement point, which may be: marking policy enforcement point, which may be:
o At the wireless access point o At the wireless access point
o At the wired network switch port o At the wired network switch port
o At the wireless LAN controller o At the wireless LAN controller
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]
skipping to change at page 22, line 16 skipping to change at page 23, line 4
o At the wireless LAN controller o At the wireless LAN controller
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 leverage Layer 2 wireless access points MUST NOT leverage Layer 2 [IEEE.802.11-2016]
[IEEE.802.11-2016] UP markings as set by wireless hosts and UP markings as set by wireless hosts and subsequently perform a UP-
subsequently perform a UP-to-DSCP mapping in the upstream direction, to-DSCP mapping in the upstream direction. But rather, if wireless
but rather, if wireless host markings are to be leveraged (as per host markings are to be leveraged (as per business requirements,
business requirements, technical constraints and administrative technical constraints and administrative policies), then it is
policies), then it is RECOMMENDED to pass through the Layer 3 DSCP RECOMMENDED to pass through the Layer 3 DSCP markings set by these
markings set by these wireless hosts instead, as is discussed in the wireless hosts instead, as is discussed in the next section.
next section.
5.3. Upstream DSCP-Passthrough at the Wireless Access Point 5.3. Upstream DSCP-Passthrough at the Wireless Access Point
It is generally NOT RECOMMENDED to pass through 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 QoS markings to be passed through at administrative policies require QoS markings to be passed through at
the wireless edge, then it is RECOMMENDED to pass through Layer 3 the wireless edge, then it is RECOMMENDED to pass through Layer 3
skipping to change at page 22, line 47 skipping to change at page 23, line 35
upstream direction, with the exception of CS6 and CS7 (as will be upstream direction, with the exception of CS6 and CS7 (as will be
discussed further), for the following reasons: discussed further), 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.3 (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.4; 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); passing through the original (encapsulated) DSCP 6-bit marking); passing through the original (encapsulated) DSCP
marking prevents such loss of information marking prevents such loss of information
o A practical implementation benefit is also realized by passing o A practical implementation benefit is also realized by passing
through the DSCP set by wireless client devices, as enabling through the DSCP set by wireless client devices, as enabling
applications to mark DSCP is much more prevalent and accessible to applications to mark DSCP is much more prevalent and accessible to
programmers of applications running on wireless device platforms, programmers of applications running on wireless device platforms,
vis-a-vis trying to explicitly set UP values, which requires vis-a-vis trying to explicitly set UP values, which requires
skipping to change at page 24, line 48 skipping to change at page 25, line 36
IEEE 802.11b, supporting 1, 2, 5.5 and 11 Mbps data rates), while IEEE 802.11b, supporting 1, 2, 5.5 and 11 Mbps data rates), while
newer implementations (including IEEE 802.11g, 802.11a, 802.11n and newer implementations (including IEEE 802.11g, 802.11a, 802.11n and
802.11ac, supporting data rates from 6.5 Mbps to over 2 Gbps per 802.11ac, supporting data rates from 6.5 Mbps to over 2 Gbps per
spatial stream) define a shorter slot time of 9 us spatial stream) define a shorter slot time of 9 us
([IEEE.802.11-2016], Section 17.4.4, Table 17-21). ([IEEE.802.11-2016], Section 17.4.4, Table 17-21).
6.1.2. Interframe Spaces 6.1.2. Interframe Spaces
The time interval between frames that are transmitted over the air is The time interval between frames that are transmitted over the air is
called the Interframe Space (IFS). Several IFS are defined in called the Interframe Space (IFS). Several IFS are defined in
[IEEE.802.11-2016], with the two most relevant to DCF being the Short [IEEE.802.11-2016], with the most relevant to DCF being the Short
Interframe Space (SIFS) and the DCF Interframe Space (DIFS). Interframe Space (SIFS), the DCF Interframe Space (DIFS) and the
Extended Interframe Space (EIFS).
The SIFS is the amount of time in microseconds required for a The SIFS is the amount of time in microseconds required for a
wireless interface to process a received RF signal and its associated wireless interface to process a received RF signal and its associated
[IEEE.802.11-2016] frame and to generate a response frame. Like slot [IEEE.802.11-2016] frame and to generate a response frame. Like slot
times, the SIFS can vary according to the performance implementation times, the SIFS can vary according to the performance implementation
of the [IEEE.802.11-2016] standard. The SIFS for IEEE 802.11a, of the [IEEE.802.11-2016] standard. The SIFS for IEEE 802.11a,
802.11n and 802.11ac (in 5 GHz) is 16 us ([IEEE.802.11-2016], 802.11n and 802.11ac (in 5 GHz) is 16 us ([IEEE.802.11-2016],
Section 17.4.4, Table 17-21). Section 17.4.4, Table 17-21).
Additionally, a station must sense the status of the wireless medium Additionally, a station must sense the status of the wireless medium
before transmitting. If it finds that the medium is continuously before transmitting. If it finds that the medium is continuously
idle for the duration of a DIFS, then it is permitted to attempt idle for the duration of a DIFS, then it is permitted to attempt
transmission of a frame (after waiting an additional random backoff transmission of a frame (after waiting an additional random backoff
skipping to change at page 30, line 46 skipping to change at page 31, line 46
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 forwarded UP 6. However, if the traffic from such an application is forwarded
without change over a business network, then this could interfere without change over a business network, then this could interfere
with QoS policies intended to provide priority services for business with QoS policies intended to provide priority services for business
voice 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 traffic conditioning policy reflective of business o Setting a traffic conditioning policy reflective of business
objectives and policy, such that traffic from authorized users objectives and policy, such that traffic from authorized users
and/or applications and/or endpoints will be accepted by the and/or applications and/or endpoints will be accepted by the
network; otherwise packet markings will be "bleached" (i.e. network; otherwise packet markings will be "bleached" (i.e.
remarked to DSCP DF and/or UP 0). Additionally, Section 5.3 made remarked to DSCP DF and/or UP 0). Additionally, Section 5.3 made
it clear that it is generally NOT RECOMMENDED to pass through DSCP it clear that it is generally NOT RECOMMENDED to pass through DSCP
markings from unauthorized and/or unauthenticated devices, as markings from unauthorized and/or unauthenticated devices, as
these are typically considered untrusted sources. This is these are typically considered untrusted sources. This is
especially relevant for IoT deployments, where tens-of-billions of especially relevant for IoT deployments, where tens-of-billions of
devices that may have little or no security are being connected to devices are being connected to IP networks with little or no
IP networks. security capabilities (making such vulernable to be utilized as
agents for DDoS attacks, the effects of which can be amplified
with preferential QoS treatments, should the packet markings of
such devices be trusted).
Policing EF marked packet flows, as detailed in [RFC2474] o 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
The wireless LAN presents a unique DoS attack vector, as endpoint The wireless LAN presents a unique DoS attack vector, as endpoint
devices contend for the shared media on a completely egalitarian devices contend for the shared media on a completely egalitarian
skipping to change at page 31, line 31 skipping to change at page 32, line 34
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 (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.3) 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 of their 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 authorized or explicitly
network be mapped to UP 0; this recommendation applies both at the provisioned for use over the wireless network by the network
access point (in the downstream direction) and within the wireless administrator be mapped to UP 0; this recommendation applies both at
endpoint device operating system (in the upstream direction). 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.
In the majority of WLAN deployments, the AP represents not only the In the majority of WLAN deployments, the AP represents not only the
edge of the Diffserv domain, but also the edge of the network edge of the Diffserv domain, but also the edge of the network
infrastructure itself; that is, only wireless client endpoint devices infrastructure itself; that is, only wireless client endpoint devices
are downstream from the AP. In such a deployment model, CS6 and CS7 are downstream from the AP. In such a deployment model, CS6 and CS7
skipping to change at page 32, line 24 skipping to change at page 33, line 28
are downstream from the AP. In such a deployment model, CS6 and CS7 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 (since only wireless endpoint client devices are the wireless LAN (since only wireless endpoint client devices are
downstream from the AP in this model and these devices do not downstream from the AP in this model and these devices do not
[legitimately] participate in network control protocol exchanges). [legitimately] participate in network control protocol exchanges).
As such, it is RECOMMENDED that CS6 and CS7 DSCP be mapped to UP 0 in As such, it is RECOMMENDED that CS6 and CS7 DSCP be mapped to UP 0 in
these Wifi-at-the-edge deployment models. Otherwise, it would be these Wifi-at-the-edge deployment models. Otherwise, it would be
easy for a malicious application developer, or even an inadvertently easy for a malicious application developer, or even an inadvertently
poorly-programmed IoT device, to cause WLAN DoS and even wired IP poorly-programmed IoT device, to cause WLAN DoS and even wired IP
network instability by flooding traffic marked CS6 DSCP, which would network instability by flooding traffic marked CS6 DSCP, which would
by default (as described in Section 2.2) be mapped to UP 6, causing by default (as described in Section 2.3) be mapped to UP 6, causing
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
skipping to change at page 34, line 15 skipping to change at page 35, line 26
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
Guidelines for DiffServ Service Classes", RFC 4594, Guidelines for DiffServ Service Classes", RFC 4594,
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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
10.2. Informative References 10.2. Informative References
[GSMA-IPX_Guidelines] [GSMA-IPX_Guidelines]
"Guidelines for IPX Provider networks (Previously Inter- "Guidelines for IPX Provider networks (Previously Inter-
Service Provider IP Backbone Guidelines) Version 11.0", Service Provider IP Backbone Guidelines) Version 11.0",
GSMA Official Document, November 2014, GSMA Official Document, November 2014,
<https://www.gsma.com/newsroom/wp-content/uploads/ <https://www.gsma.com/newsroom/wp-content/uploads/
IR.34-v11.0.pdf>. IR.34-v11.0.pdf>.
[I-D.ietf-tsvwg-le-phb] [I-D.ietf-tsvwg-le-phb]
 End of changes. 83 change blocks. 
182 lines changed or deleted 227 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/