draft-ietf-tsvwg-ieee-802-11-11.txt   rfc8325.txt 
Transport Working Group T. Szigeti Internet Engineering Task Force (IETF) T. Szigeti
Internet-Draft J. Henry Request for Comments: 8325 J. Henry
Intended status: Best Current Practice Cisco Systems Category: Standards Track Cisco Systems
Expires: June 21, 2018 F. Baker ISSN: 2070-1721 F. Baker
December 18, 2017 February 2018
Diffserv to IEEE 802.11 Mapping Mapping Diffserv to IEEE 802.11
draft-ietf-tsvwg-ieee-802-11-11
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 (QoS) be
between wired and wireless networks; however, this is not always the aligned between wired and wireless networks; however, this is not
case by default. This document specifies a set of Differentiated always the case by default. This document specifies a set of
Services Code Point (DSCP) to IEEE 802.11 User Priority (UP) mappings mappings from Differentiated Services Code Point (DSCP) to IEEE
to reconcile the marking recommendations offered by the IETF and the 802.11 User Priority (UP) to reconcile the marking recommendations
IEEE so as to maintain consistent QoS treatment between wired and offered by the IETF and the IEEE so as to maintain consistent QoS
IEEE 802.11 wireless networks. treatment between wired and IEEE 802.11 wireless networks.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on June 21, 2018. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8325.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
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 . . . . . . . . . . . . . . . . . . . . . . . . . 9 IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1. Diffserv Domain Boundaries . . . . . . . . . . . . . . . 9 2.1. Diffserv Domain Boundaries . . . . . . . . . . . . . . . 9
2.2. EDCF Queuing . . . . . . . . . . . . . . . . . . . . . . 10 2.2. EDCF Queuing . . . . . . . . . . . . . . . . . . . . . . 10
2.3. Default DSCP-to-UP Mappings and Conflicts . . . . . . . . 10 2.3. Default DSCP-to-UP Mappings and Conflicts . . . . . . . . 10
2.4. Default UP-to-DSCP Mappings and Conflicts . . . . . . . . 11 2.4. Default UP-to-DSCP Mappings and Conflicts . . . . . . . . 11
3. Wireless Device Marking and Mapping Capability 3. Recommendations for Capabilities of Wireless Device Marking
Recommendations . . . . . . . . . . . . . . . . . . . . . . . 13 and Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 13
4. DSCP-to-UP Mapping Recommendations . . . . . . . . . . . . . 13 4. Recommendations for DSCP-to-UP Mapping . . . . . . . . . . . 13
4.1. Network Control Traffic . . . . . . . . . . . . . . . . . 14 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) . . . . . 15 4.1.2. Operations, Administration, and Maintenance (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 . . . . . . . . . . . . . . . . . . . . . . 16 4.2.2. Signaling . . . . . . . . . . . . . . . . . . . . . . 16
4.2.3. Multimedia Conferencing . . . . . . . . . . . . . . . 16 4.2.3. Multimedia Conferencing . . . . . . . . . . . . . . . 17
4.2.4. Real-Time Interactive . . . . . . . . . . . . . . . . 17 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 . . . . . . . . . . . . . . . . . . . 18
4.2.7. Low-Latency Data . . . . . . . . . . . . . . . . . . 18 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 . . . . . . . . . . . . . . . 19 4.2.9. Standard . . . . . . . . . . . . . . . . . . . . . . 19
4.2.10. Low-Priority Data . . . . . . . . . . . . . . . . . . 19 4.2.10. Low-Priority Data . . . . . . . . . . . . . . . . . . 20
4.3. DSCP-to-UP Mapping Recommendations Summary . . . . . . . 20 4.3. Summary of Recommendations for DSCP-to-UP Mapping . . . . 20
5. Upstream Mapping and Marking Recommendations . . . . . . . . 21 5. Recommendations for Upstream Mapping and Marking . . . . . . 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 . . . . . . . . . . . . . . . . . . . . 22 Operating System . . . . . . . . . . . . . . . . . . . . 22
5.2. Upstream UP-to-DSCP Mapping at the Wireless Access Point 22 5.2. Upstream UP-to-DSCP Mapping at the Wireless AP . . . . . 22
5.3. Upstream DSCP-Passthrough at the Wireless Access Point . 23 5.3. Upstream DSCP-Passthrough at the Wireless AP . . . . . . 23
5.4. Upstream DSCP Marking at the Wireless Access Point . . . 24 5.4. Upstream DSCP Marking at the Wireless AP . . . . . . . . 24
6. IEEE 802.11 QoS Overview . . . . . . . . . . . . . . . . . . 24 6. Overview of IEEE 802.11 QoS . . . . . . . . . . . . . . . . . 24
6.1. Distributed Coordination Function (DCF) . . . . . . . . . 24 6.1. Distributed Coordination Function (DCF) . . . . . . . . . 25
6.1.1. Slot Time . . . . . . . . . . . . . . . . . . . . . . 25 6.1.1. Slot Time . . . . . . . . . . . . . . . . . . . . . . 25
6.1.2. Interframe Spaces . . . . . . . . . . . . . . . . . . 25 6.1.2. Interframe Space (IFS) . . . . . . . . . . . . . . . 26
6.1.3. Contention Windows . . . . . . . . . . . . . . . . . 26 6.1.3. Contention Window (CW) . . . . . . . . . . . . . . . 26
6.2. Hybrid Coordination Function (HCF) . . . . . . . . . . . 27 6.2. Hybrid Coordination Function (HCF) . . . . . . . . . . . 27
6.2.1. User Priority (UP) . . . . . . . . . . . . . . . . . 27 6.2.1. User Priority (UP) . . . . . . . . . . . . . . . . . 27
6.2.2. Access Category (AC) . . . . . . . . . . . . . . . . 27 6.2.2. Access Category (AC) . . . . . . . . . . . . . . . . 28
6.2.3. Arbitration Inter-Frame Space (AIFS) . . . . . . . . 28 6.2.3. Arbitration Interframe Space (AIFS) . . . . . . . . . 29
6.2.4. Access Category Contention Windows (CW) . . . . . . . 29 6.2.4. Access Category CWs . . . . . . . . . . . . . . . . . 29
6.3. IEEE 802.11u QoS Map Set . . . . . . . . . . . . . . . . 30 6.3. IEEE 802.11u QoS Map Set . . . . . . . . . . . . . . . . 30
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
8. Security Considerations . . . . . . . . . . . . . . . . . . . 31 8. Security Considerations . . . . . . . . . . . . . . . . . . . 31
8.1. General QoS Security Recommendations . . . . . . . . . . 31 8.1. Security Recommendations for General QoS . . . . . . . . 31
8.2. WLAN QoS Security Recommendations . . . . . . . . . . . . 32 8.2. Security Recommendations for WLAN QoS . . . . . . . . . . 32
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 9.1. Normative References . . . . . . . . . . . . . . . . . . 34
10.1. Normative References . . . . . . . . . . . . . . . . . . 34 9.2. Informative References . . . . . . . . . . . . . . . . . 35
10.2. Informative References . . . . . . . . . . . . . . . . . 35 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 37
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
IEEE 802.11 [IEEE.802.11-2016] wireless has become the preferred The wireless medium defined by IEEE 802.11 [IEEE.802.11-2016] has
medium for endpoints connecting to business and private networks. become the preferred medium for endpoints connecting to business and
However, the wireless medium defined by IEEE 802.11 private networks. However, it presents several design challenges for
[IEEE.802.11-2016] presents several design challenges for ensuring ensuring end-to-end QoS. Some of these challenges relate to the
end-to-end quality of service. Some of these challenges relate to nature of the IEEE 802.11 Radio Frequency (RF) medium itself, being a
the nature of the IEEE 802.11 Radio Frequency (RF) medium itself, half-duplex and shared medium, while other challenges relate to the
being a half-duplex and shared medium, while other challenges relate fact that the IEEE 802.11 standard is not administered by the same
to the fact that the IEEE 802.11 standard is not administered by the standards body as IP networking standards. While the IEEE has
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 consistent QoS treatment between wired IP
IP and wireless IEEE 802.11 networks. The purpose of this document networks and wireless IEEE 802.11 networks. The purpose of this
is to provide such guidance. document 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:
o [RFC2474] specifies the Diffserv Codepoint Field. This RFC also RFC 2474 Specifies the Diffserv Codepoint Field. This RFC also
details Class Selectors, as well as the Default Forwarding (DF) details Class Selectors, as well as the Default
treatment. Forwarding (DF) PHB for best effort traffic. The Default
Forwarding PHB is referred to as the Default PHB in RFC
2474.
o [RFC2475] defines a Diffserv architecture RFC 2475 Defines a Diffserv architecture.
o [RFC3246] specifies the Expedited Forwarding (EF) Per-Hop Behavior RFC 3246 Specifies the Expedited Forwarding (EF) Per-Hop Behavior
(PHB) (PHB).
o [RFC2597] specifies the Assured Forwarding (AF) PHB. RFC 2597 Specifies the Assured Forwarding (AF) PHB.
o [RFC3662] specifies a Lower Effort Per-Domain Behavior (PDB) RFC 3662 Specifies a Lower-Effort Per-Domain Behavior (PDB).
o [RFC4594] presents Configuration Guidelines for Diffserv Service RFC 4594 Presents configuration guidelines for Diffserv service
Classes classes.
o [RFC5127] presents the Aggregation of Diffserv Service Classes RFC 5127 Presents the aggregation of Diffserv service classes.
o [RFC5865] specifies a DSCP for Capacity Admitted Traffic RFC 5865 Specifies a DSCP for capacity-admitted traffic.
Note: [RFC4594] is intended to be viewed as a framework for Note: [RFC4594] is intended to be viewed as a framework for
supporting Diffserv in any network, including wireless networks; supporting Diffserv in any network, including wireless networks;
thus, it describes different types of traffic expected in IP networks thus, it describes different types of traffic expected in IP networks
and 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], 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; at the time of writing, the current
time of writing) is [IEEE.802.11-2016]. version of which 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 for IP Packet Communications Association (GSMA) on DSCP-to-UP Mapping for IP Packet
eXchange (IPX), specifically their Guidelines for IPX Provider eXchange (IPX), specifically their Guidelines for IPX Provider
networks [GSMA-IPX_Guidelines]. These GSMA Guidelines were developed networks [GSMA-IPX_Guidelines]. These GSMA Guidelines were developed
without reference to existing IETF specifications for various without reference to existing IETF specifications for various
services, referenced in Section 1.1. In turn, [RFC7561] was written services, referenced in Section 1.1. In turn, [RFC7561] was written
based on these GSMA Guidelines, as explicitly called out in [RFC7561] based on these GSMA Guidelines, as explicitly called out in
Section 4.2. Thus, [RFC7561] conflicts with the overall Diffserv [RFC7561], Section 4.2. Thus, [RFC7561] conflicts with the overall
traffic-conditioning service plan, both in the services specified and Diffserv traffic-conditioning service plan, both in the services
the code points specified for them. As such, these two plans cannot specified and the codepoints specified for them. As such, these two
be normalized. Rather, as discussed in [RFC2474] Section 2, the two plans cannot be normalized. Rather, as discussed in [RFC2474],
domains (IEEE 802.11 and GSMA) are different Differentiated Services Section 2, the two domains (IEEE 802.11 and GSMA) are different
Domains separated by a Differentiated Services Boundary. At that Differentiated Services Domains separated by a Differentiated
boundary, code points from one domain are translated to code points Services Boundary. At that boundary, codepoints from one domain are
for the other, and maybe to Default (zero) if there is no translated to codepoints for the other, and maybe to Default (zero)
corresponding service to translate to. 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
Fi, throughout this document, for simplicity). These guidelines are Wi-Fi, throughout this document, for simplicity). These guidelines
applicable whether the wireless access points (APs) are deployed in are applicable whether the wireless access points (APs) are deployed
an autonomous manner, managed by (centralized or distributed) WLAN in 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
these cases, the wireless access point is the bridge between wired all these cases, the wireless AP is the bridge between wired and
and wireless media. wireless media.
This document applies to IP networks using WiFi infrastructure at the This document applies to IP networks using Wi-Fi infrastructure at
link layer. Such networks typically include wired LANs with wireless the link layer. Such networks typically include wired LANs with
access points at their edges, however, such networks can also include wireless APs at their edges; however, such networks can also include
Wi-Fi backhaul, wireless mesh solutions or any other type of AP-to-AP Wi-Fi backhaul, wireless mesh solutions, or any other type of AP-to-
wireless network that extends the wired network infrastructure. AP wireless network that extends the wired-network infrastructure.
1.4. Document Organization 1.4. Document Organization
This document is organized as follows: This document is organized as follows:
o Section 1 introduces the wired-to-wireless QoS challenge, Section 1 introduces the wired-to-wireless QoS challenge, references
references related work, outlines the organization of the related work, outlines the organization of the document, and
document, and specifies both the requirements language and the specifies both the requirements language and the terminology used in
terminology used in this document. this document.
o Section 2 begins the discussion with a comparison of IETF Diffserv Section 2 begins the discussion with a comparison of IETF Diffserv
QoS and Wi-Fi QoS standards and highlights discrepancies between QoS and Wi-Fi QoS standards and highlights discrepancies between
these that require reconciliation. these that require reconciliation.
o Section 3 presents the marking and mapping capabilities that Section 3 presents the marking and mapping capabilities that wireless
wireless access points and wireless endpoint devices are APs and wireless endpoint devices are recommended to support.
recommended to support.
o Section 4 presents DSCP-to-UP mapping recommendations for each of Section 4 presents DSCP-to-UP mapping recommendations for each of the
the [RFC4594] service classes, which are primarily applicable in [RFC4594] service classes, which are primarily applicable in the
the downstream (wired-to-wireless) direction. downstream (wired-to-wireless) direction.
o Section 5, in turn, considers upstream (wireless-to-wired) QoS 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 Section 6 (in the form of an Appendix) presents a brief overview of
of how QoS is achieved over IEEE 802.11 wireless networks, given how QoS is achieved over IEEE 802.11 wireless networks, given the
the shared, half-duplex nature of the wireless medium. shared, half-duplex nature of the wireless medium.
o Section 7 on notes IANA considerations Section 7 contains IANA considerations.
o Section 8 presents security considerations relative to DSCP-to-UP, Section 8 presents security considerations relative to DSCP-to-UP
UP-to-DSCP mapping and remarking mapping, UP-to-DSCP mapping, and re-marking.
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", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. 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 QoS station (STA) to contend for the channel in order to transmit
in order to transmit medium access control (MAC) service data medium access control (MAC) service data units (MSDUs) with
units (MSDUs) with certain priorities. [IEEE.802.11-2016] certain priorities; see [IEEE.802.11-2016], Section 3.2.
Section 3.2.
AIFS: Arbitration Interframe Space. Interframe space used by QoS AIFS: Arbitration Interframe Space. Interframe space used by QoS
stations before transmission of data and other frame types defined stations before transmission of data and other frame types defined
by [IEEE.802.11-2016] Section 10.3.2.3.6. by [IEEE.802.11-2016], Section 10.3.2.3.6.
AP: Access Point. An entity that contains one station (STA) and AP: Access Point. An entity that contains one station (STA) and
provides access to the distribution services, via the wireless provides access to the distribution services, via the wireless
medium (WM) for associated STAs. An AP comprises a STA and a medium (WM) for associated STAs. An AP comprises a STA and a
distribution system access function (DSAF) [IEEE.802.11-2016] distribution system access function (DSAF); see
Section 3.1. [IEEE.802.11-2016], Section 3.1.
BSS: Basic Service Set. Informally, a wireless cell; formally, a BSS: Basic Service Set. Informally, a wireless cell; formally, a set
set of stations that have successfully synchronized using the JOIN of stations that have successfully synchronized using the JOIN
service primitives and one STA that has used the START primitive. service primitives and one STA that has used the START primitive.
Alternatively, a set of STAs that have used the START primitive Alternatively, a set of STAs that have used the START primitive
specifying matching mesh profiles where the match of the mesh specifying matching mesh profiles where the match of the mesh
profiles has been verified via the scanning procedure. Membership profiles has been verified via the scanning procedure. Membership
in a BSS does not imply that wireless communication with all other in a BSS does not imply that wireless communication with all other
members of the BSS is possible. Defined in [IEEE.802.11-2016] members of the BSS is possible. See the definition in
Section 3.1. [IEEE.802.11-2016], Section 3.1.
Contention Window: See CW. Contention Window: See CW.
CSMA/CA: Carrier Sense Multiple Access with Collision Avoidance. CSMA/CA: Carrier Sense Multiple Access with Collision Avoidance. A
A media access control method in which carrier sensing is used, MAC method in which carrier sensing is used, but nodes attempt to
but nodes attempt to avoid collisions by transmitting only when avoid collisions by transmitting only when the channel is sensed
the channel is sensed to be "idle". When these do transmit, nodes to be "idle". When these do transmit, nodes transmit their packet
transmit their packet data in its entirety. data in its entirety.
CSMA/CD: Carrier Sense Multiple Access with Collision Detection. CSMA/CD: Carrier Sense Multiple Access with Collision Detection. A
A media access control method (used most notably in early Ethernet MAC method (used most notably in early Ethernet technology) for
technology) for local area networking. It uses a carrier-sensing local area networking. It uses a carrier-sensing scheme in which
scheme in which a transmitting station detects collisions by a transmitting station detects collisions by sensing transmissions
sensing transmissions from other stations while transmitting a from other stations while transmitting a frame. When this
frame. When this collision condition is detected, the station collision condition is detected, the station stops transmitting
stops transmitting that frame, transmits a jam signal, and then that frame, transmits a jam signal, and then waits for a random
waits for a random time interval before trying to resend the time interval before trying to resend the frame.
frame.
CW: Contention Window. Limits a CWMin and CWMax, from which a CW: Contention Window. Limits a CWMin and CWMax, from which a
random backoff is computed. random backoff is computed.
CWMax: Contention Window Maximum. The maximum value (in unit of CWMax: Contention Window Maximum. The maximum value (in units of
Slot Time) that a contention window can take. Slot Time) that a CW can take.
CWMin: Contention Window Minimum. The minimum value that a CWMin: Contention Window Minimum. The minimum value that a CW can
contention window can take. take.
DCF: Distributed Coordinated Function. A class of coordination DCF: Distributed Coordinated Function. A class of coordination
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 BSS whenever the network is in
network is in operation. operation.
DIFS: Distributed (Coordination Function) Interframe Space. A DIFS: Distributed (Coordination Function) Interframe Space. A unit
unit of time during which the medium has to be detected as idle of time during which the medium has to be detected as idle before
before a station should attempt to send frames, as per 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 Type of
of Service (TOS) Byte (the remaining 2 bits are used for IP Service (TOS) field and the IPv6 Traffic Class field (the
Explicit Congestion Notification [RFC3168]). remaining 2 bits are used for IP Explicit Congestion Notification
(ECN) [RFC3168]).
EIFS: Extended Interframe Space. A unit of time that a station EIFS: Extended Interframe Space. A unit of time that a station has
has to defer before transmitting a frame if the previous frame 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. 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 QoS stations (STAs) with
stations (STAs) with prioritized and parameterized QoS access to prioritized and parameterized QoS access to the WM, while
the wireless medium (WM), while continuing to support non-QoS STAs continuing to support non-QoS STAs for best-effort transfer; see
for best-effort transfer. [IEEE.802.11-2016] Section 3.1. [IEEE.802.11-2016], Section 3.1.
IFS: Interframe Space. Period of silence between transmissions IFS: Interframe Space. Period of silence between transmissions over
over 802.11 networks. [IEEE.802.11-2016] describes several types IEEE 802.11 networks. [IEEE.802.11-2016] describes several types
of Interframe Spaces. of Interframe Spaces.
Random Backoff Timer: A pseudorandom integer period of time (in Random Backoff Timer: A pseudorandom integer period of time (in
units of Slot Time) over the interval (0,CW), where CWmin is-less- units of Slot Time) over the interval (0,CW), where CWmin is less
than-or-equal-to CW, which in turn is less-than-or-equal-to CWMax. than or equal to CW, which in turn is less than or equal to CWMax.
Stations desiring to initiate transfer of data frames and-or Stations desiring to initiate transfer of data frames and/or
Management frames using the DCF shall invoke the carrier sense management frames using the DCF shall invoke the carrier sense
mechanism to determine the busy-or-idle state of the medium. If mechanism to determine the busy-or-idle state of the medium. If
the medium is busy, the STA shall defer until the medium is the medium is busy, the STA shall defer until the medium is
determined to be idle without interruption for a period of time determined to be idle without interruption for a period of time
equal to DIFS when the last frame detected on the medium was equal to DIFS when the last frame detected on the medium was
received correctly, or after the medium is determined to be idle received correctly or after the medium is determined to be idle
without interruption for a period of time equal to EIFS when the without interruption for a period of time equal to EIFS when the
last frame detected on the medium was not received correctly. last frame detected on the medium was not received correctly.
After this DIFS or EIFS medium idle time, the STA shall then After this DIFS or EIFS medium idle time, the STA shall then
generate a random backoff period for an additional deferral time generate a random backoff period for an additional deferral time
before transmitting. [IEEE.802.11-2016] Section 10.3.3. before transmitting. See [IEEE.802.11-2016], Section 10.3.3.
RF: Radio Frequency. RF: Radio Frequency.
SIFS: Short Interframe Space. An IFS used before transmission of SIFS: Short Interframe Space. An IFS used before transmission of
specific frames as defined in [IEEE.802.11-2016] specific frames as defined in [IEEE.802.11-2016],
Section 10.3.2.3.3. Section 10.3.2.3.3.
Slot Time: A unit of time used to count time intervals in 802.11 Slot Time: A unit of time used to count time intervals in IEEE
networks, and defined in [IEEE.802.11-2016] Section 10.3.2.13. 802.11 networks; it is defined in [IEEE.802.11-2016],
Section 10.3.2.13.
Trust: From a QoS-perspective, trust refers to the accepting of Trust: From a QoS-perspective, "trust" refers to the accepting of
the QoS markings of a packet by a network device. Trust is the QoS markings of a packet by a network device. Trust is
typically extended at Layer 3 (by accepting the DSCP), but may typically extended at Layer 3 (by accepting the DSCP), but may
also be extended at lower layers, such as at Layer 2 by accepting also be extended at lower layers, such as at Layer 2 by accepting
User Priority markings. For example, if an access point is UP markings. For example, if an AP is configured to trust DSCP
configured to trust DSCP markings and it receives a packet marked markings and it receives a packet marked EF, then it would treat
EF, then it would treat the packet with the Expedite Forwarding the packet with the Expedite Forwarding PHB and propagate the EF
PHB and propagate the EF marking value (DSCP 46) as it transmits marking value (DSCP 46) as it transmits the packet.
the packet. Alternatively, if a network device is configured to Alternatively, if a network device is configured to operate in an
operate in an untrusted manner, then it would remark packets as untrusted manner, then it would re-mark packets as these entered
these entered the device, typically to DF (or to a different the device, typically to DF (or to a different marking value at
marking value at the network administrator's preference). Note: the network administrator's preference). Note: The terms
The terms "trusted" and "untrusted" are used extensively in "trusted" and "untrusted" are used extensively in [RFC4594].
[RFC4594].
UP: User Priority. A value associated with a medium access UP: User Priority. A value associated with an MSDU that indicates
control (MAC) service data unit (MSDU) that indicates how the MSDU how the MSDU is to be handled. The UP is assigned to an MSDU in
is to be handled. The UP is assigned to an MSDU in the layers the layers above the MAC; see [IEEE.802.11-2016], Section 3.1.
above the MAC [IEEE.802.11-2016] Section 3.1. The UP defines a The UP defines a level of priority for the associated frame, on a
level of priority for the associated frame, on a scale of 0 to 7. 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 Wireless: In the context of this document, "wireless" refers to the
the media defined in IEEE 802.11 [IEEE.802.11-2016], and not 3G/4G media defined in IEEE 802.11 [IEEE.802.11-2016], and not 3G/4G LTE
LTE or any other radio telecommunications specification. 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
802.11 IEEE 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], [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
be serviced with strict priority over another (due to the random be serviced with strict priority over another (due to the random
element within the contention process) element within the contention process)
o [IEEE.802.11-2016] does not support an AF PHB service [RFC2597], [IEEE.802.11-2016] does not support an AF PHB service [RFC2597],
again because it is not possible to assure that a given access again because it is not possible to assure that a given access
category will be serviced with a minimum amount of assured category will be serviced with a minimum amount of assured
bandwidth (due to the non-deterministic nature of the contention bandwidth (due to the non-deterministic nature of the contention
process) process)
o [IEEE.802.11-2016] loosely supports a [RFC2474] Default Forwarding [IEEE.802.11-2016] loosely supports a Default PHB ([RFC2474]) via
service via the Best Effort Access Category (AC_BE) the Best Effort Access Category (AC_BE)
o [IEEE.802.11-2016] loosely supports a [RFC3662] Lower Effort PDB [IEEE.802.11-2016] loosely supports a Lower Effort PDB service
service via the Background Access Category (AC_BK) ([RFC3662]) 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, APs may or may not always be positioned at Diffserv domain
Diffserv domain boundaries, as will be discussed next. 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 function as an edge of a Diffserv domain or a domain may not function as an edge of a Diffserv domain or a domain
boundary. boundary.
In most commonly-deployed WLAN models, the wireless access point In most commonly deployed WLAN models, the wireless AP represents not
represents not only the edge of the Diffserv domain, but also the only the edge of the Diffserv domain, but also the edge of the
edge of the network infrastructure itself. As such, only client network infrastructure itself. As such, only client endpoint devices
endpoint devices (and no network infrastructure devices) are (and no network infrastructure devices) are downstream from the
downstream from the access points in these deployment models. Note: access points in these deployment models. Note: security
security considerations and recommendations for hardening such Wifi- considerations and recommendations for hardening such Wi-Fi-at-the-
at-the-edge deployment models are detailed in Section 8; these edge deployment models are detailed in Section 8; these
recommendations include mapping network control protocols (which are recommendations include mapping network control protocols (which are
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 AP extends the network infrastructure and thus, typically,
typically, the Diffserv domain. In such deployments, both client the Diffserv domain. In such deployments, both client devices and
devices and infrastructure devices may be expected downstream from infrastructure devices may be expected downstream from the APs, and,
the access points, and as such network control protocols are as such, network control protocols are RECOMMENDED to be mapped to UP
RECOMMENDED to be mapped to UP 7 in this deployment model, as is 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 AP will depend on the position of the AP in the
the network infrastructure and on the WLAN deployment model. network infrastructure and on the WLAN deployment model.
However, regardless of the access point being at the Diffserv However, regardless of whether or not the AP is at the Diffserv
boundary or not, Diffserv to [IEEE.802.11-2016] (and vice-versa) boundary, marking-specific incompatibilities exist from Diffserv to
marking-specific incompatibilities exist that must be reconciled, as 802.11 (and vice versa) that must be reconciled, as will be discussed
will be discussed next. next.
2.2. EDCF Queuing 2.2. EDCF Queuing
[IEEE.802.11-2016] displays a reference implementation queuing model [IEEE.802.11-2016] displays a reference implementation queuing model
in Figure 10-24, which depicts four transmit queues, one per access in Figure 10-24, which depicts four transmit queues, one per access
category. category.
However, in practical implementations, it is common for WLAN network However, in practical implementations, it is common for WLAN network
equipment vendors to implement dedicated transmit queues on a per-UP equipment vendors to implement dedicated transmit queues on a per-UP
(versus a per access category) basis, which are then dequeued into (versus a per-AC) basis, which are then dequeued into their
their associated access category in a preferred (or even in a strict associated AC in a preferred (or even in a strict priority manner).
priority manner). For example, it is common for vendors to dequeue For example, it is common for vendors to dequeue UP 5 ahead of UP 4
UP 5 ahead of UP 4 to the hardware performing the EDCA function to the hardware performing the EDCA function (EDCAF) for the Video
(EDCAF) for the Video Access Category (AC_VI). Access Category (AC_VI).
Some of the recommendations made in Section 4 make reference to this Some of the recommendations made in Section 4 make reference to this
common implementation model of queuing per UP. common implementation model of queuing per UP.
2.3. Default DSCP-to-UP Mappings and Conflicts 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 three Most Significant Bits
the DSCP are used as the corresponding L2 markings. (MSBs) of 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.4). 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 recommendations in [RFC4594] and destined to
WLAN clients, it will yield a number of inconsistent QoS mappings, 802.11 WLAN clients, it will yield a number of inconsistent QoS
specifically: mappings, 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 UP 3 (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
the Video Access Category (AC_VI), for which it is intended Video Access Category (AC_VI), for which it is intended
o Broadcast Video (CS3-011000) will be mapped to UP3 (011) and o Broadcast Video (CS3-011000) will be mapped to UP 3 (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
the Video Access Category (AC_VI), for which it is intended 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
(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 mediums' 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.4. 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 three 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 AP and the
the nearest classification and marking policy enforcement point nearest classification and marking policy enforcement point (which
(which may be the centralized wireless LAN controller, relatively may be the centralized wireless LAN controller, relatively deep
deep within the network). Alternatively, in the case where there is within the network). Alternatively, in the case where there is no
no other classification and marking policy enforcement point, then other classification and marking policy enforcement point, then this
this derived DSCP value will be used on the remainder of the Internet derived DSCP value will be used on the remainder of the Internet
path. path.
It goes without saying that when 6 bits of marking granularity are It goes without saying that when six bits of marking granularity are
derived from 3, then information is lost in translation. Servicing derived from three, then information is lost in translation.
differentiation cannot be made for 12 classes of traffic (as Servicing differentiation cannot be made for 12 classes of traffic
recommended in [RFC4594]), but for only 8 (with one of these classes (as recommended in [RFC4594]), but for only eight (with one of these
being reserved for future use (i.e. UP 7 which maps to DSCP CS7). classes being reserved for future use (i.e., UP 7, which maps to DSCP
CS7).
Such default upstream mapping can also yield several inconsistencies Such default upstream mapping can also yield several inconsistencies
with [RFC4594], including: with [RFC4594], including:
o Mapping UP 6 ([RFC4594] Voice) to CS6, which [RFC4594] recommends o Mapping UP 6 (which would include Voice or Telephony traffic, see
for Network Control [RFC4594]) to CS6, which [RFC4594] recommends for Network Control
o Mapping UP 4 ([RFC4594] Multimedia Conferencing and/or Real-Time o Mapping UP 4 (which would include Multimedia Conferencing and/or
Interactive) to CS4, thus losing the ability to differentiate Real-Time Interactive traffic, see [RFC4594]) to CS4, thus losing
between these two distinct service classes, as recommended in the ability to differentiate between these two distinct service
[RFC4594] Sections 4.3 and 4.4 classes, as recommended in [RFC4594], Sections 4.3 and 4.4
o Mapping UP 3 ([RFC4594] Multimedia Streaming and/or Broadcast o Mapping UP 3 (which would include Multimedia Streaming and/or
Video) to CS3, thus losing the ability to differentiate between Broadcast Video traffic, see [RFC4594]) to CS3, thus losing the
these two distinct service classes, as recommended in [RFC4594] ability to differentiate between these two distinct service
Sections 4.5 and 4.6 classes, as recommended in [RFC4594], Sections 4.5 and 4.6
o Mapping UP 2 ([RFC4594] Low-Latency Data and/or OAM) to CS2, thus o Mapping UP 2 (which would include Low-Latency Data and/or OAM
losing the ability to differentiate between these two distinct traffic, see [RFC4594]) to CS2, thus losing the ability to
service classes, as recommended in [RFC4594] Sections 4.7 and 3.3, differentiate between these two distinct service classes, as
and possibly overwhelming the queues provisioned for OAM (which is recommended in [RFC4594], Sections 4.7 and 3.3, and possibly
typically lower in capacity [being network control traffic], as overwhelming the queues provisioned for OAM (which is typically
compared to Low-Latency Data queues [being user traffic]) lower in capacity (being Network Control Traffic), as compared to
Low-Latency Data queues (being user traffic))
o Mapping UP 1 ([RFC4594] High-Throughput Data and/or Low-Priority o Mapping UP 1 (which would include High-Throughput Data and/or Low-
Data) to CS1, thus losing the ability to differentiate between Priority Data traffic, see [RFC4594]) to CS1, thus losing the
these two distinct service classes, as recommended in [RFC4594] ability to differentiate between these two distinct service
Sections 4.8 and 4.10, and causing legitimate business-relevant classes, as recommended in [RFC4594], Sections 4.8 and 4.10, and
High-Throughput Data to receive a [RFC3662] Lower Effort PDB, for causing legitimate business-relevant High-Throughput Data to
which it is not intended receive a [RFC3662] Lower-Effort PDB, for which it is not intended
The following sections address these limitations and concerns in The following sections address these limitations and concerns in
order to reconcile [RFC4594] and [IEEE.802.11-2016]. First order to reconcile [RFC4594] and [IEEE.802.11-2016]. First
downstream (wired-to-wireless) DSCP-to-UP mappings will be aligned downstream (wired-to-wireless) DSCP-to-UP mappings will be aligned
and then upstream (wireless-to-wired) models will be addressed. and then upstream (wireless-to-wired) models will be addressed.
3. Wireless Device Marking and Mapping Capability Recommendations 3. Recommendations for Capabilities of Wireless Device Marking and
Mapping
This document assumes and RECOMMENDS that all wireless access points This document assumes and RECOMMENDS that all wireless APs (as the
(as the interconnects between wired-and-wireless networks) support interconnects between wired-and-wireless networks) support the
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 process DSCP markings set by wireless endpoint devices o process DSCP markings set by wireless endpoint devices
This document further assumes and RECOMMENDS that all wireless This document further assumes and RECOMMENDS that all wireless
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/
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 that, 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.3 and Section 2.4), these mapping discussed in Sections 2.3 and 2.4), these mapping recommendations are
recommendations are not expected to fit every last deployment model, not expected to fit every last deployment model; as such, they MAY be
and as such MAY be overridden by network administrators, as needed. overridden by network administrators, as needed.
4. DSCP-to-UP Mapping Recommendations 4. Recommendations for DSCP-to-UP Mapping
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 APs and/or WLAN
WLAN controllers that support customizable, non-default DSCP-to-UP controllers that support customizable, non-default DSCP-to-UP mapping
mapping schemes. schemes.
This section also assumes that [IEEE.802.11-2016] access points and This section also assumes that [IEEE.802.11-2016] APs and endpoint
endpoint devices differentiate UP markings with corresponding queuing devices differentiate UP markings with corresponding queuing and
and dequeuing treatments, as described in Section 2.2. dequeuing treatments, as described in Section 2.2.
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],
Network control traffic is different from user application control Section 3. Network Control Traffic is different from user
(signaling) that may be generated by some applications or services. application control (signaling) that may be generated by some
Network control traffic MAY be split into two service classes: applications or services. Network Control Traffic MAY be split into
two service classes:
o Network Control, and o Network Control, and
o Operations Administration and Management (OAM) o Operations, Administration, and Maintenance (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
information to be exchanged between nodes within the administrative (routing) information to be exchanged between nodes within the
domain, as well as across a peering point between different administrative domain, as well as across a peering point between
administrative domains. different administrative domains.
[RFC4594] Section 3.2 recommends that Network Control traffic be [RFC4594], Section 3.2, recommends that Network Control Traffic be
marked CS6 DSCP. Additionally, as stated in [RFC4594] Section 3.1: marked CS6 DSCP. Additionally, as stated in [RFC4594], Section 3.1:
"CS7 DSCP value SHOULD be reserved for future use, potentially for "CS7 DSCP value SHOULD be reserved for future use, potentially for
future routing or control protocols." future routing or control protocols."
By default (as described in Section 2.3), packets marked DSCP CS7 By default (as described in Section 2.4), 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.3), packets marked However, by default (as described in Section 2.4), 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, Network Virtualization encapsulated or overlay networks (e.g., VPN, Network Virtualization
Overlays, etc.) are not network control traffic for any physical Overlays, etc.) are not Network Control Traffic for any physical
network at the AP, and hence SHOULD NOT be marked with CS6 in the network at the AP; hence, they SHOULD NOT be marked with CS6 in the
first place. first place.
Addtionally, and as previously noted, the Security Considerations Additionally, 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 Wi-Fi-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 received between
APs and downstream endpoint client devices. APs and client endpoint devices that are downstream.
4.1.2. Operations Administration Management (OAM) 4.1.2. Operations, Administration, and Maintenance (OAM)
The OAM (Operations, Administration, and Management) service class is The OAM (Operations, Administration, and Maintenance) service class
recommended for OAM&P (Operations, Administration, and Management and is recommended for OAM&P (Operations, Administration, and Maintenance
Provisioning). The OAM service class can include network management and Provisioning). The OAM service class can include network
protocols, such as SNMP, SSH, TFTP, Syslog, etc., as well as network management protocols, such as SNMP, Secure Shell (SSH), TFTP, Syslog,
services, such as NTP, DNS, DHCP, etc. [RFC4594] Section 3.3 etc., as well as network services, such as NTP, DNS, DHCP, etc.
recommends that OAM traffic be marked CS2 DSCP. [RFC4594], Section 3.3, recommends that OAM traffic be marked CS2
DSCP.
By default (as described in Section 2.3), 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. [RFC4594] Section 4.1 recommends that a specified upper bound. [RFC4594], Section 4.1, recommends that
Telephony traffic be marked EF DSCP. 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.3) 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 VOICE-ADMIT DSCP (44 decimal / 101100 binary)
to be mapped to UP 6, thereby admitting it also into the Voice Access described in [RFC5865] is RECOMMENDED to be mapped to UP 6, thereby
Category (AC_VO). admitting it also into the Voice Access 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 1) IP phone and soft-switch, 2) soft-client and soft-switch,
media gateway and soft-switch as well as peer-to-peer using various and 3) media gateway and soft-switch as well as peer-to-peer using
protocols. This service class is intended to be used for control of various protocols. This service class is intended to be used for
sessions and applications. [RFC4594] Section 4.2 recommends that control of sessions and applications. [RFC4594], Section 4.2,
Signaling traffic be marked CS5 DSCP. recommends that 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.3). 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. This treated with preferential servicing versus other data-plane flows.
may be achieved in common WLAN deployments by mapping Signaling This may be achieved in common WLAN deployments by mapping Signaling
traffic marked CS5 to UP 5. On APs supporting per-UP EDCAF queuing traffic marked CS5 to UP 5. On APs supporting per-UP EDCAF queuing
logic (as described in Section 2.2) this will result in preferential logic (as described in Section 2.2), this will result in preferential
treatment for Signaling traffic versus other video flows in the same treatment for Signaling traffic versus other video flows in the same
access category (AC_VI), which are marked to UP 4, as well as access category (AC_VI), which are marked to UP 4, as well as
preferred treatment over flows in the Best Effort (AC_BE) and preferred treatment over flows in the Best Effort (AC_BE) and
Background (AC_BK) access categories. 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. [RFC4594] Section 4.3 recommends Multimedia Conferencing traffic. [RFC4594], Section 4.3, recommends Multimedia Conferencing
traffic be marked AF4x (that is, AF41, AF42 and AF43, according to traffic be marked AF4x (that is, AF41, AF42, and AF43, according to
the rules defined in [RFC2475]). 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 (AC_VI), which it does
default (as described in Section 2.3). Specifically, it is by 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
through 2.3, and Section 4.4). [RFC4594] Section 4.4 recommends 2.1 through 2.3 and Section 4.4). [RFC4594], Section 4.4, recommends
Real-Time Interactive traffic be marked CS4 DSCP. 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 (AC_VI), which it does by
(as described in Section 2.3). Specifically, it is RECOMMENDED to default (as described in Section 2.3). Specifically, it is
map CS4 to UP 4, thereby admitting Real-Time Interactive traffic into RECOMMENDED to map CS4 to UP 4, thereby admitting Real-Time
the Video Access Category (AC_VI). 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. [RFC4594] Section 4.5 recommends Multimedia unidirectional. [RFC4594], Section 4.5, recommends Multimedia
Streaming traffic be marked AF3x (that is, AF31, AF32 and AF33, Streaming traffic be marked AF3x (that is, AF31, AF32, and AF33,
according to the rules defined in [RFC2475]). 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 (AC_VI), which it will by
(as described in Section 2.3). Specifically, it is RECOMMENDED to default (as described in Section 2.3). Specifically, it is
map AF31, AF32 and AF33 to UP 4, thereby admitting Multimedia RECOMMENDED to map AF31, AF32, and AF33 to UP 4, thereby admitting
Streaming into the Video Access Category (AC_VI). 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. [RFC4594] Section 4.6 Typically these flows are unidirectional. [RFC4594] Section 4.6
recommends Broadcast Video traffic be marked CS3 DSCP. 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.3), this service class (AC_VI); however, by default (as described in Section 2.3), this
will map to UP 3, and thus the Best Effort Access Category (AC_BE). service class will map to UP 3 and, thus, the Best Effort Access
Therefore, a non-default mapping is RECOMMENDED, such that CS4 maps Category (AC_BE). Therefore, a non-default mapping is RECOMMENDED,
to UP 4, thereby admitting Broadcast Video into the Video Access such that CS4 maps to UP 4, thereby admitting Broadcast Video into
Category (AC_VI). 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. [RFC4594] Section 4.7 recommends Low- impacting user productivity. [RFC4594], Section 4.7, recommends
Latency Data be marked AF2x (that is, AF21, AF22 and AF23, according Low-Latency Data be marked AF2x (that is, AF21, AF22, and AF23,
to the rules defined in [RFC2475]). according to the rules defined in [RFC2475]).
By default (as described in Section 2.3), 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
contrary to the intent expressed in [RFC4594]. is contrary to the intent expressed in [RFC4594].
Mapping Low-Latency Data to UP 3 may allow such to receive a superior Mapping Low-Latency Data to UP 3 may allow targeted traffic to
level of service via per-UP transmit queues servicing the EDCAF receive a superior level of service via per-UP transmit queues
hardware for the Best Effort Access Category (AC_BE), as described in servicing the EDCAF hardware for the Best Effort Access Category
Section 2.2. Therefore it is RECOMMENDED to map Low-Latency Data (AC_BE), as described in Section 2.2. Therefore it is RECOMMENDED to
traffic marked AF2x DSCP to UP 3, thereby admitting it to the Best map Low-Latency Data traffic marked AF2x DSCP to UP 3, thereby
Effort Access Category (AC_BE). admitting it 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
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 not user interactive.
According to [RFC4594] Section 4.8, it can be assumed that this class According to [RFC4594], Section 4.8, it can be assumed that this
will consume any available bandwidth and that packets traversing class will consume any available bandwidth and that packets
congested links may experience higher queuing delays or packet loss. traversing congested links may experience higher queuing delays or
It is also assumed that this traffic is elastic and responds packet loss. It is also assumed that this traffic is elastic and
dynamically to packet loss. [RFC4594] Section 4.8 recommends High- responds dynamically to packet loss. [RFC4594], Section 4.8,
Throughput Data be marked AF1x (that is, AF11, AF12 and AF13, recommends High-Throughput Data be marked AF1x (that is, AF11, AF12,
according to the rules defined in [RFC2475]). and AF13, according to the rules defined in [RFC2475]).
By default (as described in Section 2.3), 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),
is contrary to the intent expressed in [RFC4594]. 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).
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
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. [RFC4594] the Internet's "best-effort" forwarding behavior. [RFC4594],
Section 4.9 states that the "Standard service class MUST use the Section 4.9, states that the "Standard service class MUST use the
Default Forwarding (DF) PHB." 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); therefore, it
it is RECOMMENDED to map Standard Service Class traffic marked DF is RECOMMENDED to map Standard service class traffic marked DF DSCP
DSCP to UP 0, thereby admitting it to the Best Effort Access Category 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.3). 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 [LE-PHB].
[RFC3662] and [RFC4594] both recommend Low-Priority Data be marked [RFC3662] and [RFC4594] both recommend Low-Priority Data be marked
CS1 DSCP. CS1 DSCP.
Note: This marking recommendation may change in the future, as Note: This marking recommendation may change in the future, as
[I-D.ietf-tsvwg-le-phb] defines a Lower Effort (LE) per-hop behavior [LE-PHB] defines a Lower Effort (LE) PHB for Low-Priority Data
(PHB) for Low-Priority Data traffic and recommends an additional DSCP traffic and recommends an additional DSCP for this traffic.
for this traffic.
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); therefore, it
it is RECOMMENDED to map Low-Priority Data traffic marked CS1 DSCP to is RECOMMENDED to map Low-Priority Data traffic marked CS1 DSCP to UP
UP 1, thereby admitting it to the Background Access Category (AC_BK). 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.3). Section 2.3).
4.3. DSCP-to-UP Mapping Recommendations Summary 4.3. Summary of Recommendations for DSCP-to-UP Mapping
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 | RFC 2474 | 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 | RFC 2474 | OR |
| | | | 0 | AC_BE (Best Effort)| | | | | 0 | AC_BE (Best Effort)|
| | | |See Security Considerations-Sec.8 | | | | | See Security Considerations |
+---------------+------+---------+-------------+--------------------+ +---------------+------+----------+-------------+--------------------+
| Telephony | EF | RFC3246 | 6 | AC_VO (Voice) | | Telephony | EF | RFC 3246 | 6 | AC_VO (Voice) |
+---------------+------+---------+-------------+--------------------+ +---------------+------+----------+-------------+--------------------+
| VOICE-ADMIT | VA | RFC5865 | 6 | AC_VO (Voice) | | VOICE-ADMIT | VA | RFC 5865 | 6 | AC_VO (Voice) |
| | | | | | | | | | | |
+---------------+------+---------+-------------+--------------------+ +---------------+------+----------+-------------+--------------------+
| Signaling | CS5 | RFC2474 | 5 | AC_VI (Video) | | Signaling | CS5 | RFC 2474 | 5 | AC_VI (Video) |
+---------------+------+---------+-------------+--------------------+ +---------------+------+----------+-------------+--------------------+
| Multimedia | AF41 | | | | | Multimedia | AF41 | | | |
| Conferencing | AF42 | RFC2597 | 4 | AC_VI (Video) | | Conferencing | AF42 | RFC 2597 | 4 | AC_VI (Video) |
| | AF43 | | | | | | AF43 | | | |
+---------------+------+---------+-------------+--------------------+ +---------------+------+----------+-------------+--------------------+
| Real-Time | CS4 | RFC2474 | 4 | AC_VI (Video) | | Real-Time | CS4 | RFC 2474 | 4 | AC_VI (Video) |
| Interactive | | | | | | Interactive | | | | |
+---------------+------+---------+-------------+--------------------+ +---------------+------+----------+-------------+--------------------+
| Multimedia | AF31 | | | | | Multimedia | AF31 | | | |
| Streaming | AF32 | RFC2597 | 4 | AC_VI (Video) | | Streaming | AF32 | RFC 2597 | 4 | AC_VI (Video) |
| | AF33 | | | | | | AF33 | | | |
+---------------+------+---------+-------------+--------------------+ +---------------+------+----------+-------------+--------------------+
|Broadcast Video| CS3 | RFC2474 | 4 | AC_VI (Video) | |Broadcast Video| CS3 | RFC 2474 | 4 | AC_VI (Video) |
+---------------+------+---------+-------------+--------------------+ +---------------+------+----------+-------------+--------------------+
| Low- | AF21 | | | | | Low- | AF21 | | | |
| Latency | AF22 | RFC2597 | 3 | AC_BE (Best Effort)| | Latency | AF22 | RFC 2597 | 3 | AC_BE (Best Effort)|
| Data | AF23 | | | | | Data | AF23 | | | |
+---------------+------+---------+-------------+--------------------+ +---------------+------+----------+-------------+--------------------+
| OAM | CS2 | RFC2474 | 0 | AC_BE (Best Effort)| | OAM | CS2 | RFC 2474 | 0 | AC_BE (Best Effort)|
+---------------+------+---------+-------------+--------------------+ +---------------+------+----------+-------------+--------------------+
| High- | AF11 | | | | | High- | AF11 | | | |
| Throughput | AF12 | RFC2597 | 0 | AC_BE (Best Effort)| | Throughput | AF12 | RFC 2597 | 0 | AC_BE (Best Effort)|
| Data | AF13 | | | | | Data | AF13 | | | |
+---------------+------+---------+-------------+--------------------+ +---------------+------+----------+-------------+--------------------+
| Standard | DF | RFC2474 | 0 | AC_BE (Best Effort)| | Standard | DF | RFC 2474 | 0 | AC_BE (Best Effort)|
+---------------+------+---------+-------------+--------------------+ +---------------+------+----------+-------------+--------------------+
| Low-Priority | CS1 | RFC3662 | 1 | AC_BK (Background) | | Low-Priority | CS1 | RFC 3662 | 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 below)
Figure 1: Summary of Downstream DSCP to IEEE 802.11 UP and AC Mapping Figure 1: Summary of Mapping Recommendations from Downstream
Recommendations DSCP to IEEE 802.11 UP and AC
5. Upstream Mapping and Marking Recommendations 5. Recommendations for Upstream Mapping and Marking
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 AP, or
o DSCP-Passthrough at the wireless access point (effectively a 1:1 o DSCP-Passthrough at the wireless AP (effectively a 1:1 DSCP-to-
DSCP-to-DSCP mapping) 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 approach is RECOMMENDED Diffserv policy enforcement point; this approach is RECOMMENDED
whenever the APs support the required classification and marking whenever the APs support the required classification and marking
capabilities. 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.3. As default DSCP-to-UP mapping scheme as that described in Section 2.3.
such, this can lead to the same conflicts as described in that As 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 instead utilize the same DSCP-to-UP
mapping recommendations presented in Section 4, with the explicit mapping recommendations presented in Section 4. Note that it is
RECOMMENDATION that packets requesting a marking of CS6 or CS7 DSCP explicitly stated that packets requesting a marking of CS6 or CS7
SHOULD be mapped to UP 0 (and not to UP 7). Furthermore, in such DSCP SHOULD be mapped to UP 0 (and not to UP 7). Furthermore, in
cases the wireless client operating system SHOULD remark such packets such cases, the wireless client operating system SHOULD re-mark such
to DSCP 0. This is because CS6 and CS7 DSCP, as well as UP 7 packets to DSCP 0. This is because CS6 and CS7 DSCP, as well as UP 7
markings, are intended for network control protocols and these SHOULD markings, are intended for network control protocols, and these
NOT be sourced from wireless client endpoint devices. This SHOULD NOT be sourced from wireless client endpoint devices. This
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 AP
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 Control and Provisioning of Wireless
LAN controller for decapsulation and forwarding) from the Layer 2 Access Points (CAPWAP) -- and destined towards a wireless 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.4. described in Section 2.4.
It should be noted that any explicit remarking policy to be performed It should be noted that any explicit re-marking policy to be
on such a packet only takes place at the nearest classification and performed on such a packet generally takes place at the nearest
marking policy enforcement point, which may be: classification and marking policy enforcement point, which may be:
o At the wireless access point
o At the wired network switch port o At the wireless AP, and/or
o At the wired network switch port, and/or
o At the wireless LAN controller o At the wireless LAN controller
Note: Multiple classification and marking policy enforcement points
may exist, as some devices have the capability to re-mark at only
Layer 2 or Layer 3, while other devices can re-mark at either/both
layers.
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 specification is there an intent expressed for UP markings to be used
used to influence QoS treatment over wired IP networks. Furthermore, to influence QoS treatment over wired IP networks. Furthermore,
[RFC2474], [RFC2475], and [RFC8100] all allow for the host to set
[RFC2474], [RFC2475] and [RFC8100] all allow for the host to set DSCP DSCP markings for end-to-end QoS treatment over IP networks.
markings for end-to-end QoS treatment over IP networks. Therefore, Therefore, wireless APs MUST NOT leverage Layer 2 [IEEE.802.11-2016]
wireless access points MUST NOT leverage Layer 2 [IEEE.802.11-2016] UP markings as set by wireless hosts and subsequently perform a
UP markings as set by wireless hosts and subsequently perform a UP- UP-to-DSCP mapping in the upstream direction. But rather, if
to-DSCP mapping in the upstream direction. But rather, if wireless wireless host markings are to be leveraged (as per business
host markings are to be leveraged (as per business requirements, requirements, technical constraints, and administrative policies),
technical constraints and administrative policies), then it is then it is RECOMMENDED to pass through the Layer 3 DSCP markings set
RECOMMENDED to pass through the Layer 3 DSCP markings set by these by these wireless hosts instead, as is discussed in the next section.
wireless hosts instead, as is discussed in the next section.
5.3. Upstream DSCP-Passthrough at the Wireless Access Point 5.3. Upstream DSCP-Passthrough at the Wireless AP
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
DSCP markings (over Layer 2 [IEEE.802.11-2016] UP markings) in the DSCP markings (over Layer 2 [IEEE.802.11-2016] UP markings) in the
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
markings to achieve an end-to-end differentiated service DSCP 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.3 (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 MSBs of the encapsulated 6-bit DSCP); then, at the AP, these
these 3-bit markings are converted back into DSCP values, 3-bit markings are converted back into DSCP values, typically in
typically in the default manner described in Section 2.4; as such, the default manner described in Section 2.4; as such, information
information is lost in the translation from a 6-bit marking to a is lost in the translation from a 6-bit marking to a 3-bit marking
3-bit marking (which is then subsequently translated back to a (which is then subsequently translated back to a 6-bit marking);
6-bit marking); passing through the original (encapsulated) DSCP passing through the original (encapsulated) DSCP marking prevents
marking prevents such loss of information 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
special hooks into the wireless device operating system and/or special hooks into the wireless device operating system and/or
hardware device drivers, many of which do not support such hardware device drivers, many of which do not support such
functionality functionality
CS6 and CS7 are exceptions to this pass through recommendation CS6 and CS7 are exceptions to this passthrough recommendation because
because wireless hosts SHOULD NOT use them (see Section 5.1) and wireless hosts SHOULD NOT use them (see Section 5.1) and traffic with
traffic with those two markings poses a threat to operation of the those two markings poses a threat to operation of the wired network
wired network (see Section 8.2). CS6 and CS7 SHOULD NOT be passed (see Section 8.2). CS6 and CS7 SHOULD NOT be passed through to the
through to the wired network in the upstream direction unless the wired network in the upstream direction unless the AP has been
access point has been specifically configured to do that by a network specifically configured to do that by a network administrator or
administrator or operator. operator.
5.4. Upstream DSCP Marking at the Wireless Access Point 5.4. Upstream DSCP Marking at the Wireless AP
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 because 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 developer of the
device operating system developer, who may be functioning completely operating system of the wireless endpoint device, who may be
independently of the network administrator). functioning completely independently of the network administrator).
6. IEEE 802.11 QoS Overview 6. Overview of IEEE 802.11 QoS
QoS is enabled on wireless networks by means of the Hybrid QoS is enabled on wireless networks by means of the Hybrid
Coordination Function (HCF). To give better context to the Coordination Function (HCF). To give better context to the
enhancements in HCF that enable QoS, it may be helpful to begin with enhancements in HCF that enable QoS, it may be helpful to begin with
a review of the original Distributed Coordination Function (DCF). a review of the original Distributed Coordination Function (DCF).
6.1. Distributed Coordination Function (DCF) 6.1. Distributed Coordination Function (DCF)
As has been noted, the Wi-Fi medium is a shared medium, with each As has been noted, the Wi-Fi medium is a shared medium, with each
station-including the wireless access point-contending for the medium station -- including the wireless AP -- contending for the medium on
on equal terms. As such, it shares the same challenge as any other equal terms. As such, it shares the same challenge as any other
shared medium in requiring a mechanism to prevent (or avoid) shared medium in requiring a mechanism to prevent (or avoid)
collisions which can occur when two (or more) stations attempt collisions, which can occur when two (or more) stations attempt
simultaneous transmission. simultaneous transmission.
The IEEE Ethernet working group solved this challenge by implementing The IEEE Ethernet Working Group solved this challenge by implementing
a Carrier Sense Multiple Access/Collision Detection (CSMA/CD) a Carrier Sense Multiple Access/Collision Detection (CSMA/CD)
mechanism that could detect collisions over the shared physical cable mechanism that could detect collisions over the shared physical cable
(as collisions could be detected as reflected energy pulses over the (as collisions could be detected as reflected energy pulses over the
physical wire). Once a collision was detected, then a pre-defined physical wire). Once a collision was detected, then a predefined set
set of rules was invoked that required stations to back off and wait of rules was invoked that required stations to back off and wait
random periods of time before re-attempting transmission. While random periods of time before reattempting transmission. While CSMA/
CSMA/CD improved the usage of Ethernet as a shared medium, it should CD improved the usage of Ethernet as a shared medium, it should be
be noted the ultimate solution to solving Ethernet collisions was the noted the ultimate solution to solving Ethernet collisions was the
advance of switching technologies, which treated each Ethernet cable advance of switching technologies, which treated each Ethernet cable
as a dedicated collision domain. as a dedicated collision domain.
However, unlike Ethernet (which uses physical cables), collisions However, unlike Ethernet (which uses physical cables), collisions
cannot be directly detected over the wireless medium, as RF energy is cannot be directly detected over the wireless medium, as RF energy is
radiated over the air and colliding bursts are not necessarily radiated over the air and colliding bursts are not necessarily
reflected back to the transmitting stations. Therefore, a different reflected back to the transmitting stations. Therefore, a different
mechanism is required for this medium. mechanism is required for this medium.
As such, the IEEE modified the CSMA/CD mechanism to adapt it to As such, the IEEE modified the CSMA/CD mechanism to adapt it to
wireless networks to provide Carrier Sense Multiple Access/Collision wireless networks to provide Carrier Sense Multiple Access/Collision
Avoidance (CSMA/CA). The original CSMA/CA mechanism used in IEEE Avoidance (CSMA/CA). The original CSMA/CA mechanism used in IEEE
802.11 was the Distributed Coordination Function. DCF is a timer- 802.11 was the Distributed Coordination Function. DCF is a timer-
based system that leverages three key sets of timers, the slot time, based system that leverages three key sets of timers, the slot time,
interframe spaces and contention windows. interframe spaces and CWs.
6.1.1. Slot Time 6.1.1. Slot Time
The slot time is the basic unit of time measure for both DCF and HCF, The slot time is the basic unit of time measure for both DCF and HCF,
on which all other timers are based. The slot time duration varies on which all other timers are based. The slot-time duration varies
with the different generations of data-rates and performances with the different generations of data rates and performances
described by the [IEEE.802.11-2016] standard. For example, the described by [IEEE.802.11-2016]. For example, [IEEE.802.11-2016]
[IEEE.802.11-2016] standard specifies the slot time to be 20 us specifies the slot time to be 20 microseconds ([IEEE.802.11-2016],
([IEEE.802.11-2016] Table 15-5) for legacy implementations (such as Table 15-5) for legacy implementations (such as IEEE 802.11b,
IEEE 802.11b, supporting 1, 2, 5.5 and 11 Mbps data rates), while supporting 1, 2, 5.5, and 11 Mbps data rates), while newer
newer implementations (including IEEE 802.11g, 802.11a, 802.11n and 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 microseconds
([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 Space (IFS)
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 IFSs are defined in
[IEEE.802.11-2016], with the most relevant to DCF being the Short [IEEE.802.11-2016], with the most relevant to DCF being the Short
Interframe Space (SIFS), the DCF Interframe Space (DIFS) and the Interframe Space (SIFS), the DCF Interframe Space (DIFS), and the
Extended Interframe Space (EIFS). 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 frame (as specified in [IEEE.802.11-2016]) and to generate a response
times, the SIFS can vary according to the performance implementation frame. Like slot times, the SIFS can vary according to the
of the [IEEE.802.11-2016] standard. The SIFS for IEEE 802.11a, performance implementation of [IEEE.802.11-2016]. The SIFS for IEEE
802.11n and 802.11ac (in 5 GHz) is 16 us ([IEEE.802.11-2016], 802.11a, 802.11n, and 802.11ac (in 5 GHz) is 16 microseconds
Section 17.4.4, Table 17-21). ([IEEE.802.11-2016], 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
period, as will be discussed in the next section). If the channel is period, as will be discussed in the next section). If the channel is
found busy during the DIFS interval, the station must defer its found busy during the DIFS interval, the station must defer its
transmission until the medium is found idle for the duration of a transmission until the medium is found to be idle for the duration of
DIFS interval. The DIFS is calculated as: a DIFS interval. The DIFS is calculated as:
DIFS = SIFS + (2 * Slot time) DIFS = SIFS + (2 * Slot time)
However, if all stations waited only a fixed amount of time before However, if all stations waited only a fixed amount of time before
attempting transmission then collisions would be frequent. To offset attempting transmission, then collisions would be frequent. To
this, each station must wait, not only a fixed amount of time (the offset this, each station must wait, not only a fixed amount of time
DIFS), but also a random amount of time (the random backoff) prior to (the DIFS), but also a random amount of time (the random backoff)
transmission. The range of the generated random backoff timer is prior to transmission. The range of the generated random backoff
bounded by the Contention Window. timer is bounded by the CW.
6.1.3. Contention Windows 6.1.3. Contention Window (CW)
Contention windows bound the range of the generated random backoff Contention windows bound the range of the generated random backoff
timer that each station must wait (in addition to the DIFS) before timer that each station must wait (in addition to the DIFS) before
attempting transmission. The initial range is set between 0 and the attempting transmission. The initial range is set between 0 and the
Contention Window minimum value (CWmin), inclusive. The CWmin for CW minimum value (CWmin), inclusive. The CWmin for DCF (in 5 GHz) is
DCF (in 5 GHz) is specified as 15 slot times ([IEEE.802.11-2016], specified as 15 slot times ([IEEE.802.11-2016], Section 17.4.4,
Section 17.4.4, Table 17-21). Table 17-21).
However, it is possible that two (or more) stations happen to pick However, it is possible that two (or more) stations happen to pick
the exact same random value within this range. If this happens then the exact same random value within this range. If this happens, then
a collision may occur. At this point, the stations effectively begin a collision may occur. At this point, the stations effectively begin
the process again, waiting a DIFS and generate a new random backoff the process again, waiting a DIFS and generate a new random backoff
value. However, a key difference is that for this subsequent value. However, a key difference is that for this subsequent
attempt, the Contention Window approximatively doubles in size (thus attempt, the CW approximately doubles in size (thus, exponentially
exponentially increasing the range of the random value). This increasing the range of the random value). This process repeats as
process repeats as often as necessary if collisions continue to often as necessary if collisions continue to occur, until the maximum
occur, until the maximum Contention Window size (CWmax) is reached. CW size (CWmax) is reached. The CWmax for DCF is specified as 1023
The CWmax for DCF is specified as 1023 slot times slot times ([IEEE.802.11-2016], Section 17.4.4, Table 17-21).
([IEEE.802.11-2016], Section 17.4.4, Table 17-21).
At this point, transmission attempts may still continue (until some At this point, transmission attempts may still continue (until some
other pre-defined limit is reached), but the Contention Window sizes other predefined limit is reached), but the CW sizes are fixed at the
are fixed at the CWmax value. CWmax value.
Incidentally it may be observed that a significant amount of jitter Incidentally it may be observed that a significant amount of jitter
can be introduced by this contention process for wireless can be introduced by this contention process for wireless
transmission access. For example, the incremental transmission delay transmission access. For example, the incremental transmission delay
of 1023 slot times (CWmax) using 9 us slot times may be as high as 9 of 1023 slot times (CWmax) using 9-microsecond slot times may be as
ms of jitter per attempt. And, as previously noted, multiple high as 9 ms of jitter per attempt. And, as previously noted,
attempts can be made at CWmax. multiple attempts can be made at CWmax.
6.2. Hybrid Coordination Function (HCF) 6.2. Hybrid Coordination Function (HCF)
Therefore, as can be seen from the preceding description of DCF, Therefore, as can be seen from the preceding description of DCF,
there is no preferential treatment of one station over another when there is no preferential treatment of one station over another when
contending for the shared wireless media; nor is there any contending for the shared wireless media; nor is there any
preferential treatment of one type of traffic over another during the preferential treatment of one type of traffic over another during the
same contention process. To support the latter requirement, the IEEE same contention process. To support the latter requirement, the IEEE
enhanced DCF in 2005 to support QoS, specifying HCF in IEEE 802.11, enhanced DCF in 2005 to support QoS, specifying HCF in IEEE 802.11,
which was integrated into the main IEEE 802.11 standard in 2007. which was integrated into the main IEEE 802.11 standard in 2007.
6.2.1. User Priority (UP) 6.2.1. User Priority (UP)
One of the key changes to the [IEEE.802.11-2016] frame format is the One of the key changes to the frame format in [IEEE.802.11-2016] is
inclusion of a QoS Control field, with 3 bits dedicated for QoS the inclusion of a QoS Control field, with 3 bits dedicated for QoS
markings. These bits are referred to the User Priority (UP) bits and markings. These bits are referred to the User Priority (UP) bits and
these support eight distinct marking values: 0-7, inclusive. these support eight distinct marking values: 0-7, inclusive.
While such markings allow for frame differentiation, these alone do While such markings allow for frame differentiation, these alone do
not directly affect over-the-air treatment. Rather it is the non- not directly affect over-the-air treatment. Rather, it is the
configurable and standard-specified mapping of UP markings to non-configurable and standard-specified mapping of UP markings to the
[IEEE.802.11-2016] Access Categories (AC) that generate Access Categories (ACs) from [IEEE.802.11-2016] that generate
differentiated treatment over wireless media. differentiated treatment over wireless media.
6.2.2. Access Category (AC) 6.2.2. Access Category (AC)
Pairs of UP values are mapped to four defined access categories that Pairs of UP values are mapped to four defined access categories that
correspondingly specify different treatments of frames over the air. correspondingly specify different treatments of frames over the air.
These access categories (in order of relative priority from the top These access categories (in order of relative priority from the top
down) and their corresponding UP mappings are shown in Figure 2 down) and their corresponding UP mappings are shown in Figure 2
(adapted from [IEEE.802.11-2016], Section 10.2.4.2, Table 10-1). (adapted from [IEEE.802.11-2016], Section 10.2.4.2, Table 10-1).
skipping to change at page 28, line 26 skipping to change at page 28, line 34
+-----------+------------+----------------+ +-----------+------------+----------------+
| 3 | AC_BE | Best Effort | | 3 | AC_BE | Best Effort |
+-----------+------------+----------------+ +-----------+------------+----------------+
| 0 | AC_BE | Best Effort | | 0 | AC_BE | Best Effort |
+-----------+------------+----------------+ +-----------+------------+----------------+
| 2 | AC_BK | Background | | 2 | AC_BK | Background |
+-----------+------------+----------------+ +-----------+------------+----------------+
| 1 | AC_BK | Background | | 1 | AC_BK | Background |
+-----------------------------------------+ +-----------------------------------------+
Figure 2: IEEE 802.11 Access Categories and User Priority Mappings Figure 2: Mappings between IEEE 802.11
Access Categories and User Priority
The manner in which these four access categories achieve The manner in which these four access categories achieve
differentiated service over-the-air is primarily by tuning the fixed differentiated service over-the-air is primarily by tuning the fixed
and random timers that stations have to wait before sending their and random timers that stations have to wait before sending their
respective types of traffic, as will be discussed next. respective types of traffic, as will be discussed next.
6.2.3. Arbitration Inter-Frame Space (AIFS) 6.2.3. Arbitration Interframe Space (AIFS)
As previously mentioned, each station must wait a fixed amount of As previously mentioned, each station must wait a fixed amount of
time to ensure the medium is idle before attempting transmission. time to ensure the medium is idle before attempting transmission.
With DCF, the DIFS is constant for all types of traffic. However, With DCF, the DIFS is constant for all types of traffic. However,
with [IEEE.802.11-2016] the fixed amount of time that a station has with [IEEE.802.11-2016], the fixed amount of time that a station has
to wait will depend on the access category and is referred to as an to wait will depend on the access category and is referred to as an
Arbitration Interframe Space (AIFS). AIFS are defined in slot times Arbitration Interframe Space (AIFS). AIFSs are defined in slot times
and the AIFS per access category are shown in Figure 3 (adapted from and the AIFSs per access category are shown in Figure 3 (adapted from
[IEEE.802.11-2016], Section 9.4.2.29, Table 9-137). [IEEE.802.11-2016], Section 9.4.2.29, Table 9-137).
+------------------------------------------+ +-------------------------------------------+
| Access | Designative | AIFS | | Access | Designative | AIFS |
| Category | (informative) |(slot times)| | Category | (informative) |(slot times)|
|===========+=================+============| |============+=================+============|
| AC_VO | Voice | 2 | | AC_VO | Voice | 2 |
+-----------+-----------------+------------+ +------------+-----------------+------------+
| AC_VI | Video | 2 | | AC_VI | Video | 2 |
+-----------+-----------------+------------+ +------------+-----------------+------------+
| AC_BE | Best Effort | 3 | | AC_BE | Best Effort | 3 |
+-----------+-----------------+------------+ +------------+-----------------+------------+
| AC_BK | Background | 7 | | AC_BK | Background | 7 |
+-----------+-----------------+------------+ +------------+-----------------+------------+
Figure 3: Arbitration Interframe Spaces by Access Category Figure 3: Arbitration Interframe Spaces by Access Category
6.2.4. Access Category Contention Windows (CW) 6.2.4. Access Category CWs
Not only is the fixed amount of time that a station has to wait Not only is the fixed amount of time that a station has to wait
skewed according to [IEEE.802.11-2016] access category, but so are skewed according to its [IEEE.802.11-2016] access category, but so
the relative sizes of the Contention Windows that bound the random are the relative sizes of the CWs that bound the random backoff
backoff timers, as shown in Figure 4 (adapted from timers, as shown in Figure 4 (adapted from [IEEE.802.11-2016],
[IEEE.802.11-2016], Section 9.4.2.29, Table 9-137). Section 9.4.2.29, Table 9-137).
+-------------------------------------------------------+ +-------------------------------------------------------+
| Access | Designative | CWmin | CWmax | | Access | Designative | CWmin | CWmax |
| Category | (informative) |(slot times)|(slot times)| | Category | (informative) |(slot times)|(slot times)|
|===========+=================+============|============| |===========+=================+============|============|
| AC_VO | Voice | 3 | 7 | | AC_VO | Voice | 3 | 7 |
+-----------+-----------------+------------+------------+ +-----------+-----------------+------------+------------+
| AC_VI | Video | 7 | 15 | | AC_VI | Video | 7 | 15 |
+-----------+-----------------+------------+------------+ +-----------+-----------------+------------+------------+
| AC_BE | Best Effort | 15 | 1023 | | AC_BE | Best Effort | 15 | 1023 |
+-----------+-----------------+------------+------------+ +-----------+-----------------+------------+------------+
| AC_BK | Background | 15 | 1023 | | AC_BK | Background | 15 | 1023 |
+-----------+-----------------+------------+------------+ +-----------+-----------------+------------+------------+
Figure 4: Contention Window Sizes by Access Category Figure 4: CW Sizes by Access Category
When the fixed and randomly generated timers are added together on a When the fixed and randomly generated timers are added together on a
per access category basis, then traffic assigned to the Voice Access per-access-category basis, then traffic assigned to the Voice Access
Category (i.e. traffic marked to UP 6 or 7) will receive a Category (i.e., traffic marked to UP 6 or 7) will receive a
statistically superior service relative to traffic assigned to the statistically superior service relative to traffic assigned to the
Video Access Category (i.e. traffic marked UP 5 and 4), which, in Video Access Category (i.e., traffic marked UP 5 and 4), which, in
turn, will receive a statistically superior service relative to turn, will receive a statistically superior service relative to
traffic assigned to the Best Effort Access Category traffic (i.e. traffic assigned to the Best Effort Access Category traffic (i.e.,
traffic marked UP 3 and 0), which finally will receive a traffic marked UP 3 and 0), which finally will receive a
statistically superior service relative to traffic assigned to the statistically superior service relative to traffic assigned to the
Background Access Category traffic (i.e. traffic marked to UP 2 and Background Access Category traffic (i.e., traffic marked to UP 2 and
1). 1).
6.3. IEEE 802.11u QoS Map Set 6.3. IEEE 802.11u QoS Map Set
IEEE 802.11u [IEEE.802-11u.2011] is an addendum that has now been IEEE 802.11u [IEEE.802-11u-2011] is an addendum that has now been
included within the main [IEEE.802.11-2016] standard, and which included within the main standard ([IEEE.802.11-2016]), and which
includes, among other enhancements, a mechanism by which wireless includes, among other enhancements, a mechanism by which wireless APs
access points can communicate DSCP to/from UP mappings that have been can communicate DSCP to/from UP mappings that have been configured on
configured on the wired IP network. Specifically, a QoS Map Set the wired IP network. Specifically, a QoS Map Set information
information element (described in [IEEE.802.11-2016] Section 9.4.2.95 element (described in [IEEE.802.11-2016], Section 9.4.2.95, and
and commonly referred to as the QoS Map element) is transmitted from commonly referred to as the "QoS Map element") is transmitted from an
an AP to a wireless endpoint device in an association / re- AP to a wireless endpoint device in an association / re-association
association Response frame (or within a special QoS Map Configure Response frame (or within a special QoS Map Configure frame).
frame).
The purpose of the QoS Map element is to provide the mapping of The purpose of the QoS Map element is to provide the mapping of
higher layer Quality of Service constructs (i.e. DSCP) to User higher-layer QoS constructs (i.e., DSCP) to User Priorities. One
Priorities. One intended effect of receiving such a map is for the intended effect of receiving such a map is for the wireless endpoint
wireless endpoint device (that supports this function and is device (that supports this function and is administratively
administratively configured to enable it) to perform corresponding configured to enable it) to perform corresponding DSCP-to-UP mapping
DSCP-to-UP mapping within the device (i.e. between applications and within the device (i.e., between applications and the operating
the operating system / wireless network interface hardware drivers) system / wireless network interface hardware drivers) to align with
to align with what the APs are mapping in the downstream direction, what the APs are mapping in the downstream direction, so as to
so as to achieve consistent end-to-end QoS in both directions. achieve consistent end-to-end QoS in both directions.
The QoS Map element includes two key components: The QoS Map element includes two key components:
1) each of the eight UP values (0-7) are associated with a range of 1) each of the eight UP values (0-7) is associated with a range of
DSCP values, and DSCP values, and
2) (up to 21) exceptions from these range-based DSCP to/from UP 2) (up to 21) exceptions from these range-based DSCP to/from UP
mapping associations may be optionally and explicitly specified. mapping associations may be optionally and explicitly specified.
In line with the recommendations put forward in this document, the In line with the recommendations put forward in this document, the
following recommendations apply when the QoS Map element is enabled: following recommendations apply when the QoS Map element is enabled:
1) each of the eight UP values (0-7) are RECOMMENDED to be mapped to 1) each of the eight UP values (0-7) are RECOMMENDED to be mapped to
DSCP 0 (as a baseline, so as to meet the recommendation made in DSCP 0 (as a baseline, so as to meet the recommendation made in
Section 8.2 Section 8.2, and
2) (up to 21) exceptions from this baseline mapping are RECOMMENDED 2) (up to 21) exceptions from this baseline mapping are RECOMMENDED
to be made in line with Section 4.3, to correspond to the Diffserv to be made in line with Section 4.3, to correspond to the
Codepoints that are in use over the IP network. Diffserv Codepoints that are in use over the IP network.
It is important to note that the QoS Map element is intended to be It is important to note that the QoS Map element is intended to be
transmitted from a wireless access point to a non-AP station. As transmitted from a wireless AP to a non-AP station. As such, the
such, the model where this element is used is that of a network where model where this element is used is that of a network where the AP is
the AP is the edge of the Diffserv domain. Networks where the AP the edge of the Diffserv domain. Networks where the AP extends the
extends the Diffserv domain by connecting other APs and Diffserv domain by connecting other APs and infrastructure devices
infrastructure devices through the IEEE 802.11 medium are not through the IEEE 802.11 medium are not included in the cases covered
included in the cases covered by the presence of the QoS Map element, by the presence of the QoS Map element, and therefore are not
and therefore are not included in the present recommendation. included in the present recommendation.
7. IANA Considerations 7. IANA Considerations
This memo asks the IANA for no new parameters. This document has no IANA actions.
8. Security Considerations 8. Security Considerations
The recommendations in this document concern widely-deployed wired The recommendations in this document concern widely deployed wired
and wireless network functionality, and for that reason do not and wireless network functionality, and, for that reason, do not
present additional security concerns that do not already exist in present additional security concerns that do not already exist in
these networks. In fact, several of the recommendations made in this these networks. In fact, several of the recommendations made in this
document serve to protect wired and wireless networks from potential document serve to protect wired and wireless networks from potential
abuse, as is discussed further in this section. abuse, as is discussed further in this section.
8.1. General QoS Security Recommendations 8.1. Security Recommendations for General QoS
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 smartphone
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
security measures, including: QoS security measures, including:
o 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 re-marked 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 Internet of Things (IoT) deployments,
devices are being connected to IP networks with little or no where tens of billions of devices are being connected to IP
security capabilities (making such vulernable to be utilized as networks with little or no security capabilities, leaving them
agents for DDoS attacks, the effects of which can be amplified vulnerable to be utilized as agents for DDoS attacks. These
with preferential QoS treatments, should the packet markings of attacks can be amplified with preferential QoS treatments, should
such devices be trusted). the packet markings of such devices be trusted.
o 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. Security Recommendations for WLAN QoS
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
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 (as described DSCP downstream. This codepoint would map by default (as described
in Section 2.3) 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 be marked CS7 or CS6, thinking
thinking this would acheive in the best overall servicing of their this would achieve the best overall servicing of their application
application traffic, while not realizing that such a marking (if traffic, while not realizing that such a marking (if honored by the
honored by the client operating system) could cause not only WLAN client operating system) could cause not only WLAN DoS, but also IP
DoS, but also IP network instability, as the traffic marked CS7 or network instability, as the traffic marked CS7 or CS6 finds its way
CS6 finds its way into queues intended for servicing (relatively low- into queues intended for servicing (relatively low-bandwidth) network
bandwidth) network control protocols, potentially starving legitimate control protocols, potentially starving legitimate network control
network control protocols in the process. 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 authorized or explicitly packets marked to Diffserv Codepoints not authorized or explicitly
provisioned for use over the wireless network by the network provisioned for use over the wireless network by the network
administrator be mapped to UP 0; this recommendation applies both at administrator be mapped to UP 0; this recommendation applies both at
the access point (in the downstream direction) and within the the AP (in the downstream direction) and within the operating system
wireless endpoint device operating system (in the upstream of the wireless endpoint device (in the upstream direction).
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
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 client endpoint 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 Wi-Fi-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.3) 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 as
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 re-marked to DSCP 0 and mapped to UP 0 by the
wireless client operating system. wireless client operating system.
Finally, it should be noted that the recommendations put forward in Finally, it should be noted that the recommendations put forward in
this document are not intended to address all attack vectors this document are not intended to address all attack vectors
leveraging QoS marking abuse. Mechanisms that may further help leveraging QoS marking abuse. Mechanisms that may further help
mitigate security risks of both wired and wireless networks deploying mitigate security risks of both wired and wireless networks deploying
QoS include strong device- and/or user-authentication, access- QoS include strong device- and/or user-authentication, access-
control, rate limiting, control-plane policing, encryption and other control, rate-limiting, control-plane policing, encryption, and other
techniques; however, the implementation recommendations for such techniques; however, the implementation recommendations for such
mechanisms are beyond the scope of this document to address in mechanisms are beyond the scope of this document to address in
detail. Suffice it to say that the security of the devices and detail. Suffice it to say that the security of the devices and
networks implementing QoS, including QoS mapping between wired and networks implementing QoS, including QoS mapping between wired and
wireless networks, merits consideration in actual deployments. wireless networks, merits consideration in actual deployments.
9. Acknowledgements 9. References
The authors wish to thank David Black, Gorry Fairhurst, Ruediger
Geib, Vincent Roca, Brian Carpenter, David Blake, Cullen Jennings,
David Benham and the TSVWG.
The authors also acknowledge a great many inputs, notably from David
Kloper, Mark Montanez, Glen Lavers, Michael Fingleton, Sarav
Radhakrishnan, Karthik Dakshinamoorthy, Simone Arena, Ranga Marathe,
Ramachandra Murthy and many others.
10. References
10.1. Normative References 9.1. Normative References
[IEEE.802.11-2016] [IEEE.802.11-2016]
"Information technology - Telecommunications and IEEE, "IEEE Standard for Information technology -
information exchange between systems - Local and Telecommunications and information exchange between
metropolitan area networks - Specific requirements - Part systems - Local and metropolitan area networks - Specific
11: Wireless LAN Medium Access Control (MAC) and Physical requirements - Part 11: Wireless LAN Medium Access Control
Layer (PHY) specifications", IEEE Standard 802.11, 2016, (MAC) and Physical Layer (PHY) Specifications",
<https://standards.ieee.org/findstds/ IEEE 802.11, DOI 10.1109/IEEESTD.2016.7786995, December
2016, <https://standards.ieee.org/findstds/
standard/802.11-2016.html>. standard/802.11-2016.html>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
skipping to change at page 35, line 30 skipping to change at page 35, line 24
[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 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
10.2. Informative References 9.2. Informative References
[GSMA-IPX_Guidelines] [GSMA-IPX_Guidelines]
"Guidelines for IPX Provider networks (Previously Inter- GSM Association, "Guidelines for IPX Provider networks
Service Provider IP Backbone Guidelines) Version 11.0", (Previously Inter-Service Provider IP Backbone Guidelines)
GSMA Official Document, November 2014, Version 11.0", Official Document IR.34, 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] [IEEE.802-11u-2011]
Bless, R., "A Lower Effort Per-Hop Behavior (LE PHB)", IEEE, "IEEE Standard for Information technology -
draft-ietf-tsvwg-le-phb-02 (work in progress), June 2017. Telecommunications and information exchange between
systems - Local and metropolitan area networks - Specific
[IEEE.802-11u.2011] requirements - Part 11: Wireless LAN Medium Access Control
"Information technology - Telecommunications and (MAC) and Physical Layer (PHY) specifications: Amendment
information exchange between systems - Local and 9: Interworking with External Networks", IEEE 802.11,
metropolitan area networks - Specific requirements - Part DO 10.1109/IEEESTD.2011.5721908, February 2011,
11: Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) specifications", IEEE Standard 802.11, 2011,
<http://standards.ieee.org/getieee802/ <http://standards.ieee.org/getieee802/
download/802.11u-2011.pdf>. download/802.11u-2011.pdf>.
[LE-PHB] Bless, R., "A Lower Effort Per-Hop Behavior (LE PHB)",
Work in Progress, draft-ietf-tsvwg-le-phb-02, June 2017.
[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,
<https://www.rfc-editor.org/info/rfc2475>. <https://www.rfc-editor.org/info/rfc2475>.
[RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of
Diffserv Service Classes", RFC 5127, DOI 10.17487/RFC5127, Diffserv Service Classes", RFC 5127, DOI 10.17487/RFC5127,
February 2008, <https://www.rfc-editor.org/info/rfc5127>. February 2008, <https://www.rfc-editor.org/info/rfc5127>.
[RFC7561] Kaippallimalil, J., Pazhyannur, R., and P. Yegani, [RFC7561] Kaippallimalil, J., Pazhyannur, R., and P. Yegani,
"Mapping Quality of Service (QoS) Procedures of Proxy "Mapping Quality of Service (QoS) Procedures of Proxy
Mobile IPv6 (PMIPv6) and WLAN", RFC 7561, Mobile IPv6 (PMIPv6) and WLAN", RFC 7561,
DOI 10.17487/RFC7561, June 2015, DOI 10.17487/RFC7561, June 2015,
<https://www.rfc-editor.org/info/rfc7561>. <https://www.rfc-editor.org/info/rfc7561>.
[RFC8100] Geib, R., Ed. and D. Black, "Diffserv-Interconnection [RFC8100] Geib, R., Ed. and D. Black, "Diffserv-Interconnection
Classes and Practice", RFC 8100, DOI 10.17487/RFC8100, Classes and Practice", RFC 8100, DOI 10.17487/RFC8100,
March 2017, <https://www.rfc-editor.org/info/rfc8100>. March 2017, <https://www.rfc-editor.org/info/rfc8100>.
Appendix A. Change Log Acknowledgements
Initial Version: July 2015 The authors wish to thank David Black, Gorry Fairhurst, Ruediger
Geib, Vincent Roca, Brian Carpenter, David Blake, Cullen Jennings,
David Benham, and the TSVWG.
The authors also acknowledge a great many inputs, notably from David
Kloper, Mark Montanez, Glen Lavers, Michael Fingleton, Sarav
Radhakrishnan, Karthik Dakshinamoorthy, Simone Arena, Ranga Marathe,
Ramachandra Murthy, and many others.
Authors' Addresses Authors' Addresses
Tim Szigeti Tim Szigeti
Cisco Systems Cisco Systems
Vancouver, British Columbia V6K 3L4 Vancouver, British Columbia V6K 3L4
Canada Canada
Email: szigeti@cisco.com Email: szigeti@cisco.com
Jerome Henry Jerome Henry
Cisco Systems Cisco Systems
Research Triangle Park, North Carolina 27709 Research Triangle Park, North Carolina 27709
USA United States of America
Email: jerhenry@cisco.com Email: jerhenry@cisco.com
Fred Baker Fred Baker
Santa Barbara, California 93117 Santa Barbara, California 93117
USA United States of America
Email: FredBaker.IETF@gmail.com Email: FredBaker.IETF@gmail.com
 End of changes. 256 change blocks. 
756 lines changed or deleted 752 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/