draft-ietf-tsvwg-ieee-802-11-01.txt   draft-ietf-tsvwg-ieee-802-11-02.txt 
Transport Working Group T. Szigeti Transport Working Group T. Szigeti
Internet-Draft Cisco Systems Internet-Draft J. Henry
Intended status: Standards Track F. Baker Intended status: Standards Track Cisco Systems
Expires: May 19, 2017 November 15, 2016 Expires: November 9, 2017 F. Baker
May 8, 2017
DiffServ to IEEE 802.11 Mapping Diffserv to IEEE 802.11 Mapping
draft-ietf-tsvwg-ieee-802-11-01 draft-ietf-tsvwg-ieee-802-11-02
Abstract Abstract
As internet traffic is increasingly sourced-from and destined-to As internet traffic is increasingly sourced-from and destined-to
wireless endpoints, it is crucial that Quality of Service be aligned wireless endpoints, it is crucial that Quality of Service be aligned
between wired and wireless networks; however, this is not always the between wired and wireless networks; however, this is not always the
case by default. This is due to the fact that two independent case by default. This document specifies a set Differentiated
standards bodies provide QoS guidance on wired and wireless networks: Services Code Point (DSCP) to IEEE 802.11 User Priority (UP) mappings
specifically, the IETF specifies standards and design recommendations to reconcile the marking recommendations offered by the IETF and the
for wired IP networks, while a separate and autonomous standards- IEEE so as to maintain consistent QoS treatment between wired and
body, the IEEE, administers the standards for wireless 802.11 IEEE 802.11 wireless networks.
networks. The purpose of this document is to propose a set
Differentiated Services Code Point (DSCP) to IEEE 802.11 User
Priority (UP) mappings to reconcile the marking recommendations
offered by these two standards bodies, and, as such, to optimize
wired-and-wireless interconnect QoS.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 19, 2017. This Internet-Draft will expire on November 9, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
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
2. Comparison and Default Interoperation of DiffServ and IEEE 1.6. Terminology Used in this Document . . . . . . . . . . . . 5
802.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Service Comparison and Default Interoperation of Diffserv and
2.1. Default DSCP-to-UP Mappings and Conflicts . . . . . . . . 6 IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Default UP-to-DSCP Mappings and Conflicts . . . . . . . . 7 2.1. Diffserv Domain Boundaries . . . . . . . . . . . . . . . 9
2.2. Default DSCP-to-UP Mappings and Conflicts . . . . . . . . 9
2.3. Default UP-to-DSCP Mappings and Conflicts . . . . . . . . 10
3. Wireless Device Marking and Mapping Capability 3. Wireless Device Marking and Mapping Capability
Recommendations . . . . . . . . . . . . . . . . . . . . . . . 8 Recommendations . . . . . . . . . . . . . . . . . . . . . . . 12
4. DSCP-to-UP Mapping Recommendations . . . . . . . . . . . . . 9 4. DSCP-to-UP Mapping Recommendations . . . . . . . . . . . . . 12
4.1. Network Control Traffic . . . . . . . . . . . . . . . . . 9 4.1. Network Control Traffic . . . . . . . . . . . . . . . . . 13
4.1.1. Network Control Protocols . . . . . . . . . . . . . . 9 4.1.1. Network Control Protocols . . . . . . . . . . . . . . 13
4.1.2. Operations Administration Management (OAM) . . . . . 10 4.1.2. Operations Administration Management (OAM) . . . . . 14
4.2. User Traffic . . . . . . . . . . . . . . . . . . . . . . 10 4.2. User Traffic . . . . . . . . . . . . . . . . . . . . . . 15
4.2.1. Telephony . . . . . . . . . . . . . . . . . . . . . . 11 4.2.1. Telephony . . . . . . . . . . . . . . . . . . . . . . 15
4.2.2. Signaling . . . . . . . . . . . . . . . . . . . . . . 11 4.2.2. Signaling . . . . . . . . . . . . . . . . . . . . . . 15
4.2.3. Multimedia Conferencing . . . . . . . . . . . . . . . 12 4.2.3. Multimedia Conferencing . . . . . . . . . . . . . . . 16
4.2.4. Real-Time Interactive . . . . . . . . . . . . . . . . 12 4.2.4. Real-Time Interactive . . . . . . . . . . . . . . . . 16
4.2.5. Multimedia-Streaming . . . . . . . . . . . . . . . . 13 4.2.5. Multimedia-Streaming . . . . . . . . . . . . . . . . 17
4.2.6. Broadcast Video . . . . . . . . . . . . . . . . . . . 13 4.2.6. Broadcast Video . . . . . . . . . . . . . . . . . . . 17
4.2.7. Low-Latency Data . . . . . . . . . . . . . . . . . . 13 4.2.7. Low-Latency Data . . . . . . . . . . . . . . . . . . 17
4.2.8. High-Throughput Data . . . . . . . . . . . . . . . . 14 4.2.8. High-Throughput Data . . . . . . . . . . . . . . . . 18
4.2.9. Standard Service Class . . . . . . . . . . . . . . . 14 4.2.9. Standard Service Class . . . . . . . . . . . . . . . 18
4.2.10. Low-Priority Data . . . . . . . . . . . . . . . . . . 14 4.2.10. Low-Priority Data . . . . . . . . . . . . . . . . . . 19
4.3. DSCP-to-UP Mapping Recommendations Summary . . . . . . . 15 4.3. DSCP-to-UP Mapping Recommendations Summary . . . . . . . 19
5. Upstream Mapping Recommendations . . . . . . . . . . . . . . 17 5. Upstream Mapping and Marking Recommendations . . . . . . . . 20
5.1. Upstream DSCP-to-UP Mapping within the Wireless Client 5.1. Upstream DSCP-to-UP Mapping within the Wireless Client
Operating System . . . . . . . . . . . . . . . . . . . . 17 Operating System . . . . . . . . . . . . . . . . . . . . 21
5.2. UP-to-DSCP Mapping at the Wireless Access Point . . . . . 17 5.2. Upstream UP-to-DSCP Mapping at the Wireless Access Point 21
5.3. DSCP-Trust at the Wireless Access Point . . . . . . . . . 18 5.3. Upstream DSCP-Trust at the Wireless Access Point . . . . 22
6. Appendix: IEEE 802.11 QoS Overview . . . . . . . . . . . . . 18 5.4. Upstream DSCP Marking at the Wireless Access Point . . . 22
6.1. Distributed Coordination Function (DCF) . . . . . . . . . 19 6. Appendix: IEEE 802.11 QoS Overview . . . . . . . . . . . . . 23
6.1.1. Slot Time . . . . . . . . . . . . . . . . . . . . . . 19 6.1. Distributed Coordination Function (DCF) . . . . . . . . . 23
6.1.2. Interframe Spaces . . . . . . . . . . . . . . . . . . 20 6.1.1. Slot Time . . . . . . . . . . . . . . . . . . . . . . 24
6.1.3. Contention Windows . . . . . . . . . . . . . . . . . 20 6.1.2. Interframe Spaces . . . . . . . . . . . . . . . . . . 24
6.2. Hybrid Coordination Function (HCF) . . . . . . . . . . . 21 6.1.3. Contention Windows . . . . . . . . . . . . . . . . . 25
6.2.1. User Priority (UP) . . . . . . . . . . . . . . . . . 21
6.2.2. Access Category (AC) . . . . . . . . . . . . . . . . 21 6.2. Hybrid Coordination Function (HCF) . . . . . . . . . . . 25
6.2.3. Arbitration Inter-Frame Space (AIFS) . . . . . . . . 22 6.2.1. User Priority (UP) . . . . . . . . . . . . . . . . . 25
6.2.4. Access Category Contention Windows (CW) . . . . . . . 23 6.2.2. Access Category (AC) . . . . . . . . . . . . . . . . 26
6.3. IEEE 802.11u QoS Map Set . . . . . . . . . . . . . . . . 24 6.2.3. Arbitration Inter-Frame Space (AIFS) . . . . . . . . 27
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 6.2.4. Access Category Contention Windows (CW) . . . . . . . 27
8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 6.3. IEEE 802.11u QoS Map Set . . . . . . . . . . . . . . . . 28
8.1. Privacy Considerations . . . . . . . . . . . . . . . . . 25 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 8. Security Considerations . . . . . . . . . . . . . . . . . . . 29
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
10.1. Normative References . . . . . . . . . . . . . . . . . . 25 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
10.2. Informative References . . . . . . . . . . . . . . . . . 26 10.1. Normative References . . . . . . . . . . . . . . . . . . 31
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 27 10.2. Informative References . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
Wireless has become the medium of choice for endpoints connecting to Wireless has become the preferred medium for endpoints connecting to
business and private networks. However, the wireless medium defined business and private networks. However, the wireless medium defined
by IEEE 802.11 [IEEE.802-11.2012] presents several design challenges by IEEE 802.11 [IEEE.802.11-2016] presents several design challenges
for ensuring end-to-end quality of service. Some of these challenges for ensuring end-to-end quality of service. Some of these challenges
relate to the nature of 802.11 RF medium itself, being a half-duplex relate to the nature of the IEEE 802.11 RF medium itself, being a
and shared media, while other challenges relate to the fact that the half-duplex and shared medium, while other challenges relate to the
802.11 standard is not administered by the standards body that fact that the IEEE 802.11 standard is not administered by the same
administers the rest of the IP network. While the IEEE has developed standards body as IP networking standards. While the IEEE has
tools to enable QoS over wireless networks, little guidance exists on developed tools to enable QoS over wireless networks, little guidance
how to optimally interconnect wired IP and wireless 802.11 networks, exists on how to maintain consistency of QoS treatment between wired
which is the aim of this document. IP and wireless IEEE 802.11 networks. The purpose of this 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 o [RFC2474] 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 Forwarding (DF)
treatment. treatment.
o [RFC2475] defines a DiffServ architecture o [RFC2475] defines a Diffserv architecture
o [RFC3246] specifies the Expedited Forwarding (EF) Per-Hop Behavior o [RFC3246] specifies the Expedited Forwarding (EF) Per-Hop Behavior
(PHB) (PHB)
o [RFC2597] details the Assured Forwarding (AF) PHB. o [RFC2597] specifies the Assured Forwarding (AF) PHB.
o [RFC3662] outlines a Lower Effort Per-Domain Behavior (PDB)
o [RFC4594] presents Configuration Guidelines for DiffServ Service o [RFC3662] specifies a Lower Effort Per-Domain Behavior (PDB)
o [RFC4594] presents Configuration Guidelines for Diffserv Service
Classes Classes
o [RFC5127] discusses the Aggregation of Diffserv Service Classes o [RFC5127] presents the Aggregation of Diffserv Service Classes
o [RFC5865] introduces a DSCP for Capacity Admitted Traffic o [RFC5865] specifies a DSCP for Capacity Admitted Traffic
This draft draws heavily on [RFC4594], [RFC5127], and Note: [RFC4594] is intended to be viewed as a set of "project plans"
[I-D.ietf-tsvwg-diffserv-intercon]. for building all the (diffserv) furniture that one might want. Thus,
it describes different types of traffic expected in IP networks and
provides guidance as to what DSCP marking(s) should be associated
with each traffic type. As such, this document draws heavily on
[RFC4594], [RFC5127], and [RFC8100].
In turn, the relevant standard for wireless QoS is IEEE 802.11, which In turn, the relevant standard for wireless QoS is IEEE 802.11, which
is being progressively updated; the current version of which (at the is being progressively updated; the current version of which (at the
time of writing) is IEEE 802.11-2012. time of writing) is [IEEE.802.11-2016].
1.2. Interaction with RFC 7561 1.2. Interaction with RFC 7561
There is also a recommendation from GSMA, Mapping Quality of Service There is also a recommendation from the GSMA, Mapping Quality of
(QoS) Procedures of Proxy Mobile IPv6 (PMIPv6) and WLAN [RFC7561]. Service (QoS) Procedures of Proxy Mobile IPv6 (PMIPv6) and WLAN
The GSMA specification was developed without reference to the service [RFC7561]. The GSMA specification was developed without reference to
plan documented in Section 1.1, and conflicts both in the services existing IETF specifications for various services, referenced in
specified and the code points specified for them. As such, the two Section 1.1. Thus, [RFC7561] conflicts with the overall Diffserv
plans cannot be normalized. Rather, as discussed in [RFC2474] traffic-conditioning service plan, both in the services specified and
section 2, the two domains (802.11 and GSMA) are different the code points specified for them. As such, these two plans cannot
Differentiated Services Domains separated by a Differentiated be normalized. Rather, as discussed in [RFC2474] Section 2, the two
Services Boundary. At that boundary, code points from one domain are domains (IEEE 802.11 and GSMA) are different Differentiated Services
translated to code points for the other, and maybe to Default (zero) Domains separated by a Differentiated Services Boundary. At that
if there is no corresponding service to translate to. boundary, code points from one domain are translated to code points
for the other, and maybe to Default (zero) if there is no
corresponding service to translate to.
1.3. Applicability Statement 1.3. Applicability Statement
This document is applicable to the use of Differentiated Services This document is applicable to the use of Differentiated Services
that interconnect with IEEE 802.11 wireless LANs (referred to as Wi- that interconnect with IEEE 802.11 wireless LANs (referred to as Wi-
Fi, throughout this document, for simplicity). These guidelines are Fi, throughout this document, for simplicity). These guidelines are
applicable whether the wireless access points (APs) are deployed in applicable whether the wireless access points (APs) are deployed in
an autonomous manner, managed by (centralized or distributed) WLAN an autonomous manner, managed by (centralized or distributed) WLAN
controllers or some hybrid deployment option. This is because in all controllers or some hybrid deployment option. This is because in all
these cases, the wireless access point is the bridge between wired these cases, the wireless access point is the bridge between wired
and wireless media. and wireless media.
This document primarily applies to wired IP networks that have This document applies to IP networks using WiFi infrastructure at the
wireless access points at their edges, but can also be applied to Wi- link layer. Such networks typically include wired LANs with wireless
Fi backhaul, wireless mesh solutions or any other type of AP-to-AP access points at their edges, however, such networks can also include
wireless network that serves to extend the IP network infrastructure. Wi-Fi backhaul, wireless mesh solutions or any other type of AP-to-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 outlines the abstract, related work, organization and o Section 1 introduces the wired-to-wireless QoS challenge,
the requirements language of this document. references related work, outlines the organization of the
document, and specifies both the requirements language and the
terminology used in this document.
o Section 2 begins the discussion with a comparison of IETF DiffServ o 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 o Section 3 presents the marking and mapping capabilities that
wireless access points and wireless endpoint devices are wireless access points and wireless endpoint devices are
recommended to support. recommended to support.
o Section 4 presents DSCP-to-UP mapping recommendations for each of o Section 4 presents DSCP-to-UP mapping recommendations for each of
the [RFC4594] traffic classes, which are primarily applicable in the [RFC4594] service classes, which are primarily applicable in
the downstream (wired-to-wireless) direction. the downstream (wired-to-wireless) direction.
o Section 5, in turn, considers upstream (wireless-to-wired) QoS o Section 5, in turn, considers upstream (wireless-to-wired) QoS
options, their respective merits and recommendations. options, their respective merits and recommendations.
o Section 6 (in the form of an Appendix) presents a brief overview o Section 6 (in the form of an Appendix) presents a brief overview
of how QoS is achieved over IEEE 802.11 wireless networks, given of how QoS is achieved over IEEE 802.11 wireless networks, given
the shared, half-duplex nature of the wireless medium. the shared, half-duplex nature of the wireless medium.
o Section 7 on notes IANA considerations, security considerations, o Section 7 on notes IANA considerations, security considerations,
acknowledgements and references, respectively acknowledgements and references, respectively
1.5. Requirements Language 1.5. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL", and "NOT "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL", and "NOT
RECOMMENDED" in this document are to be interpreted as described in RECOMMENDED" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
2. Comparison and Default Interoperation of DiffServ and IEEE 802.11 1.6. Terminology Used in this Document
Key terminology used in this document includes:
AC: Access Category. A label for the common set of enhanced
distributed channel access (EDCA) parameters that are used by a
quality-of-service (QoS) station (STA) to contend for the channel
in order to transmit medium access control (MAC) service data
units (MSDUs) with certain priorities. [IEEE.802.11-2016]
Section 3.2.
AIFS: Arbitration Interframe Space. Interframe space used by QoS
stations before transmission of data and other frame types defined
by [IEEE.802.11-2016] Section 10.3.2.3.6.
AP: Access Point. An entity that contains one station (STA) and
provides access to the distribution services, via the wireless
medium (WM) for associated STAs. An AP comprises a STA and a
distribution system access function (DSAF) [IEEE.802.11-2016]
Section 3.1.
BSS: Basic Service Set. Informally, a wireless cell; formally, a
set of stations that have successfully synchronized using the JOIN
service primitives and one STA that has 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
profiles has been verified via the scanning procedure. Membership
in a BSS does not imply that wireless communication with all other
members of the BSS is possible. Defined in [IEEE.802.11-2016]
Section 3.1.
Contention Window: See CW.
CSMA/CA: Carrier Sense Multiple Access with Collision Avoidance.
A media access control method in which carrier sensing is used,
but nodes attempt to avoid collisions by transmitting only when
the channel is sensed to be "idle". When these do transmit, nodes
transmit their packet data in its entirety.
CSMA/CD: Carrier Sense Multiple Access with Collision Detection.
A media access control method (used most notably in early Ethernet
technology) for local area networking. It uses a carrier-sensing
scheme in which a transmitting station detects collisions by
sensing transmissions from other stations while transmitting a
frame. When this collision condition is detected, the station
stops transmitting that frame, transmits a jam signal, and then
waits for a random time interval before trying to resend the
frame.
CW: Contention Window. Limits a CWMin and CWMax, from which a
random backoff is computed.
CWMax: Contention Window Maximum. The maximum value (in unit of
Slot Time) that a contention window can take.
CWMin: Contention Window Minimum. The minimum value that a
contention window can take.
DCF: Distributed Coordinated Function. A class of coordination
function where the same coordination function logic is active in
every station (STA) in the basic service set (BSS) whenever the
network is in operation.
DIFS: Distributed (Coordination Function) Interframe Space. A
unit of time during which the medium has to be detected as idle
before a station should attempt to send frames, as per
[IEEE.802.11-2016] Section 10.3.2.3.5.
DSCP: Differentiated Service Code Point [RFC2474] and [RFC2475].
HCF: Hybrid Coordination Function A coordination function that
combines and enhances aspects of the contention based and
contention free access methods to provide quality-of-service (QoS)
stations (STAs) with prioritized and parameterized QoS access to
the wireless medium (WM), while continuing to support non-QoS STAs
for best-effort transfer. [IEEE.802.11-2016] Section 3.1.
IFS: Interframe Space. Period of silence between transmissions
over 802.11 networks. [IEEE.802.11-2016] describes several types
of Interframe Spaces.
Random Backoff Timer: A pseudorandom integer period of time (in
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.
Stations desiring to initiate transfer of data frames and-or
Management frames using the DCF shall invoke the carrier sense
mechanism to determine the busy-or-idle state of the medium. If
the medium is busy, the STA shall defer until the medium is
determined to be idle without interruption for a period of time
equal to DIFS when the last frame detected on the medium was
received correctly, or after the medium is determined to be idle
without interruption for a period of time equal to EIFS when the
last frame detected on the medium was not received correctly.
After this DIFS or EIFS medium idle time, the STA shall then
generate a random backoff period for an additional deferral time
before transmitting. [IEEE.802.11-2016] Section 10.3.3.
RF: Radio Frequency.
SIFS: Short Interframe Space. An IFS used before transmission of
specific frames as defined in [IEEE.802.11-2016]
Section 10.3.2.3.3.
Slot Time: A unit of time used to count time intervals in 802.11
networks, and defined in [IEEE.802.11-2016] Section 10.3.2.13.
Trust: From a QoS-perspective, trust refers to the accepting of
the QoS markings of a packet by a network device. Trust is
typically extended at Layer 3 (by accepting the DSCP), but may
also be extended at lower layers, such as at Layer 2 by accepting
User Priority markings. For example, if an access point is
configured to trust DSCP markings and it receives a packet marked
EF, then it would treat the packet with the Expedite Forwarding
PHB and propagate the EF marking value (DSCP 46) as it transmits
the packet. Alternatively, if a network device is configured to
operate in an untrusted manner, then it would remark packets as
these entered the device, typically to DF (or to a different
marking value at the network administrator's preference). Note:
The terms "trusted" and "untrusted" are used extensively in RFC
4594.
UP: User Priority. A value associated with a medium access
control (MAC) service data unit (MSDU) that indicates how the MSDU
is to be handled. The UP is assigned to an MSDU in the layers
above the MAC [IEEE.802.11-2016] Section 3.1. The UP defines a
level of priority for the associated frame, on a scale of 0 to 7.
Wi-Fi: An interoperability certification defined by the Wi-Fi
Alliance. However, this term is commonly used, including in the
present document, to be the equivalent of IEEE 802.11.
2. Service Comparison and Default Interoperation of Diffserv and 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 should be The following comparisons between IEEE 802.11 and Diffserv services
noted: should be noted:
o 802.11 does not support a [RFC3246] EF PHB service, as it is not o [IEEE.802.11-2016] does not support a [RFC3246] EF PHB service, as
possible to guarantee that a given access category will be it is not possible to assure that a given access category will be
serviced with strict priority over another (due to the random serviced with strict priority over another (due to the random
element within the contention process) element within the contention process)
o 802.11 does not support a [RFC2597] AF PHB service, again because o [IEEE.802.11-2016] does not support a [RFC2597] AF PHB service,
it is not possible to guarantee that a given access category will again because it is not possible to assure that a given access
be serviced with a minimum amount of assured bandwidth (due to the category will be serviced with a minimum amount of assured
non-deterministic nature of the contention process) bandwidth (due to the non-deterministic nature of the contention
process)
o 802.11 loosely supports a [RFC2474] Default Forwarding service via o [IEEE.802.11-2016] loosely supports a [RFC2474] Default Forwarding
the Best Effort Access Category (AC_BE) service via the Best Effort Access Category (AC_BE)
o 802.11 loosely supports a [RFC3662] Lower PDB service via the o [IEEE.802.11-2016] loosely supports a [RFC3662] Lower Effort PDB
Background Access Category (AC_BK) service via the Background Access Category (AC_BK)
As such, these are high-level considerations that need to be kept in As such, these high-level considerations should be kept in mind when
mind when mapping from DiffServ to 802.11 (and vice-versa); however, mapping from Diffserv to [IEEE.802.11-2016] (and vice-versa);
some additional marking-specific incompatibilities must also be however, access points may or may not always be positioned at
reconciled, as will be discussed next. Diffserv domain boundaries, as will be discussed next.
2.1. Default DSCP-to-UP Mappings and Conflicts 2.1. Diffserv Domain Boundaries
It is important to note that the wired-to-wireless edge may or may
not equate to the edge of the Diffserv domain.
In most commonly-deployed WLAN models, the wireless access point
represents not only the edge of the Diffserv domain, but also the
edge of the network infrastructure itself. As such, only client
devices (and no infrastructure devices) are downstream from the
access points in these deployment models. In such deployment models,
it is RECOMMENDED that all packets marked to Diffserv Codepoints not
in use over the wireless network be dropped or remarked at the edge
of the Diffserv domain, as will be discussed in detail in
Section 4.1.1.
Alternatively, in other deployment models, such as Wi-Fi backhaul,
wireless mesh infrastructures, or other types of wireless AP-to-AP
deployments, the wireless access points extend the network
infrastructure and thus, typically, the Diffserv domain. In such
deployments, both client devices and infrastructure devices may be
expected downstream from the access points.
Thus the QoS treatment of packets at the access point will depend on
the position of the AP in the network infrastructure and on the WLAN
deployment model.
However, regardless of the access point being at the Diffserv
boundary or not, Diffserv to [IEEE.802.11-2016] (and vice-versa)
marking-specific incompatibilities exist that must be reconciled, as
will be discussed next.
2.2. Default DSCP-to-UP Mappings and Conflicts
While no explicit guidance is offered in mapping (6-Bit) Layer 3 DSCP While no explicit guidance is offered in mapping (6-Bit) Layer 3 DSCP
values to (3-Bit) Layer 2 markings (such as IEEE 802.1D, 802.1p or values to (3-Bit) Layer 2 markings (such as IEEE 802.1D, 802.1p or
802.11e), a common practice in the networking industry is to map 802.11e), a common practice in the networking industry is to map
these by what we will refer to as 'Default DSCP-to-UP Mapping' (for these by what we will refer to as 'Default DSCP-to-UP Mapping' (for
lack of a better term), wherein the 3 Most Significant Bits (MSB) of lack of a better term), wherein the 3 Most Significant Bits (MSB) of
the DSCP are transcribed to generate the corresponding L2 markings. the DSCP are used as the corresponding L2 markings.
Note: There are example mappings in IEEE 802.11 (in the Annex V Note: There are mappings provided in [IEEE.802.11-2016] Annex V
Tables V-1 and V2), but these mappings are provided as examples (vs. Tables V-1 and V2, but it bears mentioning that these mappings are
as recommendations). Furthermore, some of these mappings do not provided as examples (as opposed to explicit recommendations).
align with the intent and recommendations expressed in [RFC4594], as Furthermore, some of these mappings do not align with the intent and
will be discussed in the following section. recommendations expressed in [RFC4594], as will be discussed in this
and the following section (Section 2.3).
However, when this default DSCP-to-UP mapping method is applied to However, when this default DSCP-to-UP mapping method is applied to
packets marked per [RFC4594] recommendations and destined to 802.11 packets marked per [RFC4594] recommendations and destined to 802.11
WLAN clients, it will yield a number of sub-optimal QoS mappings, WLAN clients, it will yield a number of inconsistent QoS mappings,
specifically: specifically:
o Voice (EF-101110) will be mapped to UP 5 (101), and treated in the o Voice (EF-101110) will be mapped to UP 5 (101), and treated in the
Video Access Category (AC_VI), rather than the Voice Access Video Access Category (AC_VI), rather than the Voice Access
Category (AC_VO), for which it is intended Category (AC_VO), for which it is intended
o Multimedia Streaming (AF3-011xx0) will be mapped to UP3 (011) and o Multimedia Streaming (AF3-011xx0) will be mapped to UP3 (011) and
treated in the Best Effort Access Category (AC_BE), rather than treated in the Best Effort Access Category (AC_BE), rather than
the Video Access Category (AC_VI), for which it is intended the Video Access Category (AC_VI), for which it is intended
o 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 traffic class expressed in [RFC4594] for this service class
It should also be noted that while IEEE 802.11 defines an intended It should also be noted that while [IEEE.802.11-2016] defines an
use for each access category through the AC naming convention (for intended use for each access category through the AC naming
example, UP 6 and UP 7 belong to AC_VO, the Voice Access Category), convention (for example, UP 6 and UP 7 belong to AC_VO, the Voice
802.11 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 medium Layer 2 QoS
markings markings
o strictly restrict each access category to applications reflected o strictly restrict each access category to applications reflected
in the AC name in the AC name
2.2. Default UP-to-DSCP Mappings and Conflicts 2.3. Default UP-to-DSCP Mappings and Conflicts
In the opposite direction of flow (the upstream direction, that is, In the opposite direction of flow (the upstream direction, that is,
from wireless-to-wired), many APs use what we will refer to as from wireless-to-wired), many APs use what we will refer to as
'Default UP-to-DSCP Mapping' (for lack of a better term), wherein 'Default UP-to-DSCP Mapping' (for lack of a better term), wherein
DSCP values are derived from UP values by multiplying the UP values DSCP values are derived from UP values by multiplying the UP values
by 8 (i.e. shifting the 3 UP bits to the left and adding three by 8 (i.e. shifting the 3 UP bits to the left and adding three
additional zeros to generate a DSCP value). This derived DSCP value additional zeros to generate a DSCP value). This derived DSCP value
is then used for QoS treatment between the wireless access point and is then used for QoS treatment between the wireless access point and
the nearest classification and marking policy enforcement point the nearest classification and marking policy enforcement point
(which may be the centralized wireless LAN controller, relatively (which may be the centralized wireless LAN controller, relatively
skipping to change at page 7, line 41 skipping to change at page 11, line 19
It goes without saying that when 6 bits of marking granularity are It goes without saying that when 6 bits of marking granularity are
derived from 3, then information is lost in translation. Servicing derived from 3, then information is lost in translation. Servicing
differentiation cannot be made for 12 classes of traffic (as differentiation cannot be made for 12 classes of traffic (as
recommended in [RFC4594]), but for only 8 (with one of these classes recommended in [RFC4594]), but for only 8 (with one of these classes
being reserved for future use (i.e. UP 7 which maps to DSCP CS7). 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 (Voice) to CS6, which [RFC4594] recommends for o Mapping UP 6 ([RFC4594] Voice) to CS6, which [RFC4594] recommends
Network Control for Network Control
o Mapping UP 4 (Multimedia Conferencing and/or Real-Time o Mapping UP 4 ([RFC4594] Multimedia Conferencing and/or Real-Time
Interactive) to CS4, thus losing the ability to distinguish Interactive) to CS4, thus losing the ability to differentiate
between these two distinct traffic classes between these two distinct service classes, as recommended in
[RFC4594] Sections 4.3 and 4.4
o Mapping UP 3 (Multimedia Streaming and/or Broadcast Video) to CS3, o Mapping UP 3 ([RFC4594] Multimedia Streaming and/or Broadcast
thus losing the ability to distinguish between these two distinct Video) to CS3, thus losing the ability to differentiate between
traffic classes these two distinct service classes, as recommended in [RFC4594]
Sections 4.5 and 4.6
o Mapping UP 2 (Low-Latency Data and/or OAM) to CS2, thus losing the o Mapping UP 2 ([RFC4594] Low-Latency Data and/or OAM) to CS2, thus
ability to distinguish between these two distinct traffic classes, losing the ability to differentiate between these two distinct
service classes, as recommended in [RFC4594] Sections 4.7 and 3.3,
and possibly overwhelming the queues provisioned for OAM (which is and possibly overwhelming the queues provisioned for OAM (which is
typically lower in capacity [being network control traffic], as typically lower in capacity [being network control traffic], as
compared to Low-Latency Data queues [being user traffic]) compared to Low-Latency Data queues [being user traffic])
o Mapping UP 1 (High-Throughput Data and/or Low-Priority Data) to o Mapping UP 1 ([RFC4594] High-Throughput Data and/or Low-Priority
CS1, thus losing the ability to distinguish between these two Data) to CS1, thus losing the ability to differentiate between
distinct traffic classes and causing legitimate business-relevant these two distinct service classes, as recommended in [RFC4594]
High-Throughput Data to receive a [RFC3662] Lower PDB, for which Sections 4.8 and 4.10, and causing legitimate business-relevant
it is not intended High-Throughput Data to receive a [RFC3662] Lower Effort PDB, for
which it is not intended
Thus, the next sections of this draft seek to address these The following sections address these limitations and concerns in
limitations and concerns and reconcile the intents of [RFC4594] and order to reconcile [RFC4594] and [IEEE.802.11-2016]. First
IEEE 802.11. First the downstream (wired-to-wireless) DSCP-to-UP downstream (wired-to-wireless) DSCP-to-UP mappings will be aligned
mappings will be aligned and then upstream (wireless-to-wired) models and then upstream (wireless-to-wired) models will be addressed.
will be addressed.
3. Wireless Device Marking and Mapping Capability Recommendations 3. Wireless Device Marking and Mapping Capability Recommendations
This document assumes and RECOMMENDS that all wireless access points This document assumes and RECOMMENDS that all wireless access points
(as the bridges between wired-and-wireless networks) support the (as the bridges between wired-and-wireless networks) support the
ability to: ability to:
o mark DSCP, per DiffServ standards o mark DSCP, per Diffserv standards
o mark UP, per the 802.11 standard o mark UP, per the [IEEE.802.11-2016] standard
o support fully-configurable mappings between DSCP and UP o support fully-configurable mappings between DSCP and UP
o trust the DSCP markings set by wireless endpoint devices (as o trust DSCP markings set by wireless endpoint devices
discussed in Section 5.3)
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 802.11 standard o mark UP, per the [IEEE.802.11-2016] standard
o support fully-configurable mappings between DSCP (set by o support fully-configurable mappings between DSCP (set by
applications in software) and UP (set by the operating system and/ applications in software) and UP (set by the operating system and/
or wireless network interface hardware drivers) or wireless network interface hardware drivers)
Having made the assumptions and recommendations above, it bears Having made the assumptions and recommendations above, it bears
mentioning while the mappings presented in this document are mentioning while the mappings presented in this document are
RECOMMENDED to replace the current common default practices (as RECOMMENDED to replace the current common default practices (as
discussed in Section 2.1 and Section 2.2), these mapping discussed in Section 2.2 and Section 2.3), these mapping
recommendations are not expected to fit every last deployment model, recommendations are not expected to fit every last deployment model,
and as such may be overridden by network administrators, as needed. and as such MAY be overridden by network administrators, as needed.
4. DSCP-to-UP Mapping Recommendations 4. DSCP-to-UP Mapping Recommendations
The following section proposes 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. As such, this section draws heavily Service Classes and [IEEE.802.11-2016]. As such, this section draws
from [RFC4594], including traffic class definitions and heavily from [RFC4594], including service class definitions and
recommendations. recommendations.
This section assumes wireless access points and/or WLAN controllers This section assumes [IEEE.802.11-2016] wireless access points and/or
that support customizable, non-default DSCP-to-UP mapping schemes. WLAN controllers that support customizable, non-default DSCP-to-UP
mapping schemes.
This section also assumes that [IEEE.802.11-2016] access points and
endpoint devices differentiate UP markings with corresponding queuing
and dequeuing treatments. To illustrate, [IEEE.802.11-2016] displays
a reference implementation model in Figure 10-24 which depicts four
transmit queues, one per access category. In practical
implementations, however, it is common for WLAN network equipment
vendors to implement dedicated transmit queues on a per-UP (versus a
per access category) basis, which are then dequeued into their
associated access category in a preferred (or even in a strict
priority manner). For example, it is common for vendors to dequeue
UP 5 ahead of UP 4 to the hardware performing the EDCA function
(EDCAF) for the Video Access Category (AC_VI). As such, Signaling
traffic (marked UP 5, per the recommendations made in Section 4.2.2)
may benefit from such a treatment versus other video flows in the
same access category which are marked to UP 4 (in addition to a
preferred treatment over flows in the Best Effort and Background
access categories).
4.1. Network Control Traffic 4.1. Network Control Traffic
Network control traffic is defined as packet flows that are essential Network control traffic is defined as packet flows that are essential
for stable operation of the administered network. Network control for stable operation of the administered network [RFC4594] Section 3.
traffic is different from user application control (signaling) that Network control traffic is different from user application control
may be generated by some applications or services. Network Control (signaling) that may be generated by some applications or services.
Traffic may be split into two service classes: Network control traffic MAY be split into two service classes:
o Network Control, and o Network Control, and
o Operations Administration and Management (OAM) o Operations Administration and Management (OAM)
4.1.1. Network Control Protocols 4.1.1. Network Control Protocols
The Network Control service class is used for transmitting packets The Network Control service class is used for transmitting packets
between network devices (routers) that require control (routing) between network devices (routers) that require control (routing)
information to be exchanged between nodes within the administrative information to be exchanged between nodes within the administrative
domain as well as across a peering point between different domain as well as across a peering point between different
administrative domains. The RECOMMENDED DSCP marking for Network administrative domains. The RECOMMENDED DSCP marking for Network
Control is CS6. Control is CS6, per [RFC4594] Section 3.2.
Before discussing a mapping recommendation for Network Control Before discussing a mapping recommendation for Network Control
traffic marked CS6 DSCP, it is interesting to note a relevant traffic marked CS6 DSCP, it is interesting to note a relevant
recommendation from [RFC4594] pertaining to traffic marked CS7 DSCP: recommendation from [RFC4594] pertaining to traffic marked CS7 DSCP:
in [RFC4594] Section 3.1 it is RECOMMENDED that packets marked CS7 in [RFC4594] Section 3.1 it is RECOMMENDED that packets marked CS7
DSCP (a codepoint that SHOULD be reserved for future use) be dropped DSCP (a codepoint that SHOULD be reserved for future use) be dropped
or remarked at the edge of the DiffServ domain. or remarked at the edge of the Diffserv domain.
Following this recommendation, it is RECOMMENDED that all packets Following this recommendation, it is RECOMMENDED that all packets
marked to DiffServ Codepoints not in use over the wireless network be marked to Diffserv Codepoints not in use over the wireless network be
dropped or remarked at the edge of the DiffServ domain. dropped or remarked at the edge of the Diffserv domain.
It is important to note that the wired-to-wireless edge may or may It is important to note that the wired-to-wireless edge may or may
not equate to the edge of the DiffServ domain; as such, this not equate to the edge of the Diffserv domain, as discussed in
recommendation may or may not apply at the wired-to-wireless edge. Section 2.1; as such, this recommendation may or may not apply at the
wired-to-wireless edge (and vice-versa).
For example, in most commonly deployed models, the wireless access In most commonly-deployed WLAN models, where wireless access point
point represents not only the edge of the DiffServ domain, but also represents not only the edge of the Diffserv domain, but also the
the edge of the network infrastructure itself. As such, and in line edge of the network infrastructure itself. Traffic marked CS7 DSCP
with the above recommendation, traffic marked CS7 DSCP SHOULD be SHOULD be dropped or remarked at this edge (as it is typically
dropped or remarked at this edge (as it is typically unused, as CS7 unused, as CS7 SHOULD be reserved for future use). Network control
SHOULD be reserved for future use). So too SHOULD Network Control traffic marked CS6 DSCP SHOULD also be dropped or remarked at this
traffic marked CS6 DSCP, considering that only client devices (and no edge, considering that only client devices (and no network
network infrastructure devices) are downstream from the wireless infrastructure devices) are downstream from the wireless access
access points in these deployment models. In such cases, no Network points in these deployment models; such client devices would be
Control traffic would be (legitimately) expected to be sent or considered as untrusted sources of a network control traffic. In
received from wireless client endpoint devices, and thus this such cases, no Network control traffic would be (legitimately)
recommendation would apply. expected to be sent or received from wireless client endpoint
devices, and thus this recommendation would apply.
Alternatively, in other deployment models, such as Wi-Fi backhaul, Alternatively, in other deployment models, where the wireless access
wireless mesh infrastructures, or any other type of wireless AP-to-AP point extends the network infrastructure and thus, typically, the
deployments, the wireless access point extends the network Diffserv domain, the above recommendation would not apply, as the
infrastructure and thus, typically, the DiffServ domain. In such wired-to-wireless edge does not represent the edge of the Diffserv
cases, the above recommendation would not apply, as the wired-to- domain. Furthermore, as these deployment models require Network
wireless edge does not represent the edge of the DiffServ domain. Control traffic to be propagated across the wireless network, it is
Furthermore, as these deployment models require Network Control
traffic to be propagated across the wireless network, 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-2012, Section 9.2.4.2, Table 9-1), thereby admitting it [IEEE.802.11-2016] Section 10.2.4.2, Table 10-1), thereby admitting
to the Voice Access Category (AC_VO). it to the Voice Access Category (AC_VO). Similarly, if CS7 is in use
as a network control protocol it would be RECOMMENDED to map it also
to UP 7.
It should be noted that encapsulated routing protocols for
encapsulated or overlay networks (e.g., VPN, NVO3) are not network
control traffic for any physical network at the AP, and hence SHOULD
NOT be marked with CS6 in the first place.
4.1.2. Operations Administration Management (OAM) 4.1.2. Operations Administration Management (OAM)
The OAM (Operations, Administration, and Management) service class is The OAM (Operations, Administration, and Management) service class is
RECOMMENDED for OAM&P (Operations, Administration, and Management and RECOMMENDED for OAM&P (Operations, Administration, and Management and
Provisioning). The RECOMMENDED DSCP marking for OAM is CS2. Provisioning). The RECOMMENDED DSCP marking for OAM is CS2, per
[RFC4594] Section 3.3.
By default, packets marked DSCP CS2 will be mapped to UP 2 and By default, packets marked DSCP CS2 will be mapped to UP 2 and
serviced with the Background Access Category (AC_BK). Such servicing serviced with the Background Access Category (AC_BK). Such servicing
is a contradiction to the intent expressed in [RFC4594] Section 3.3. is a contradiction to the intent expressed in [RFC4594] Section 3.3.
As such, it is RECOMMENDED that a non-default mapping be applied to As such, it is RECOMMENDED that a non-default mapping be applied to
OAM traffic, such that CS2 DSCP is mapped to UP 0, thereby admitting OAM traffic, such that CS2 DSCP is mapped to UP 0, thereby admitting
it to the Best Effort Access Category (AC_BE). it to the Best Effort Access Category (AC_BE).
4.2. User Traffic 4.2. User Traffic
User traffic is defined as packet flows between different users or User traffic is defined as packet flows between different users or
subscribers. It is the traffic that is sent to or from end-terminals subscribers. It is the traffic that is sent to or from end-terminals
and that supports a very wide variety of applications and services. and that supports a very wide variety of applications and services
[RFC4594] Section 4.
Network administrators can categorize their applications according to Network administrators can categorize their applications according to
the type of behavior that they require and MAY choose to support all the type of behavior that they require and MAY choose to support all
or a subset of the defined service classes. or a subset of the defined service classes.
4.2.1. Telephony 4.2.1. Telephony
The Telephony service class is RECOMMENDED for applications that The Telephony service class is RECOMMENDED for applications that
require real-time, very low delay, very low jitter, and very low require real-time, very low delay, very low jitter, and very low
packet loss for relatively constant-rate traffic sources (inelastic packet loss for relatively constant-rate traffic sources (inelastic
traffic sources). This service class SHOULD be used for IP telephony traffic sources). This service class SHOULD be used for IP telephony
service. The fundamental service offered to traffic in the Telephony service. The fundamental service offered to traffic in the Telephony
service class is minimum jitter, delay, and packet loss service up to service class is minimum jitter, delay, and packet loss service up to
a specified upper bound. The RECOMMENDED DSCP marking for Telephony a specified upper bound. The RECOMMENDED DSCP marking for Telephony
is EF. is EF ([RFC4594] Section 4.1).
Traffic marked to DSCP EF will map by default to UP 5, and thus to Traffic marked to DSCP EF will map by default to UP 5, and thus to
the Video Access Category (AC_VI), rather than to the Voice Access the Video Access Category (AC_VI), rather than to the Voice Access
Category (AC_VO), for which it is intended. Therefore, a non-default Category (AC_VO), for which it is intended. Therefore, a non-default
DSCP-to-UP mapping is RECOMMENDED, such that EF DSCP is mapped to UP DSCP-to-UP mapping is RECOMMENDED, such that EF DSCP is mapped to UP
6, thereby admitting it into the Voice Access Category (AC_VO). 6, thereby admitting it into the Voice Access Category (AC_VO).
Similarly, the [RFC5865] VOICE-ADMIT DSCP (44/101100) is RECOMMENDED Similarly, the [RFC5865] VOICE-ADMIT DSCP (44/101100) is RECOMMENDED
to be mapped to UP 6, thereby admitting it also into the Voice Access to be mapped to UP 6, thereby admitting it also into the Voice Access
Category (AC_VO). Category (AC_VO).
4.2.2. Signaling 4.2.2. Signaling
The Signaling service class is RECOMMENDED for delay-sensitive The Signaling service class is RECOMMENDED for delay-sensitive
client-server (traditional telephony) and peer-to-peer application client-server (e.g. traditional telephony) and peer-to-peer
signaling. Telephony signaling includes signaling between IP phone application signaling. Telephony signaling includes signaling
and soft-switch, soft-client and soft-switch, and media gateway and between IP phone and soft-switch, soft-client and soft-switch, and
soft-switch as well as peer-to-peer using various protocols. This media gateway and soft-switch as well as peer-to-peer using various
service class is intended to be used for control of sessions and protocols. This service class is intended to be used for control of
applications. The RECOMMENDED DSCP marking for Signaling is CS5. sessions and applications. The RECOMMENDED DSCP marking for
Signaling is CS5 ([RFC4594] Section 4.2).
While Signaling is RECOMMENDED to receive a superior level of service While Signaling is RECOMMENDED to receive a superior level of service
relative to the default class (i.e. AC_BE), it does not require the relative to the default class (i.e. AC_BE), it does not require the
highest level of service (i.e. AC_VO). This leaves only the Video highest level of service (i.e. AC_VO). This leaves only the Video
Access Category (AC_VI), which it will map to by default. Therefore Access Category (AC_VI), which it will map to by default. Therefore
it is RECOMMENDED to map Signaling traffic marked CS5 DSCP to UP 5, it is RECOMMENDED to map Signaling traffic marked CS5 DSCP to UP 5,
thereby admitting it to the Video Access Category (AC_VI). thereby admitting it to the Video Access Category (AC_VI).
Note: Signaling traffic is not control plane traffic from the Note: Signaling traffic is not control plane traffic from the
perspective of the network (but rather is data plane traffic); as perspective of the network (but rather is data plane traffic); as
such, it does not merit provisioning in the Network Control service such, it does not merit provisioning in the Network Control service
class (marked CS6 and mapped to UP 6). However, Signaling traffic is class (marked CS6 and mapped to UP 6). However, Signaling traffic is
control-plane traffic from the perspective of the voice/video control-plane traffic from the perspective of the voice/video
telephony overlay-infrastructure. As such, Signaling should be telephony overlay-infrastructure. As such, Signaling should be
treated with preferential servicing vs. other data plane flows. One treated with preferential servicing vs. other data plane flows. One
way this may be achieved in certain WLAN deployments is by mapping way this may be achieved in certain WLAN deployments is by mapping
Signaling traffic marked CS5 to UP 5 (as recommended above). To Signaling traffic marked CS5 to UP 5 (as recommended above and
illustrate: IEEE 802.11-2012 displays a reference implementation following the EDCAF treatment logic described in Section 4.
model in Figure 9-19 which depicts four transmit queues, one per
access category. In practical implementation, however, it is common
for WLAN network equipment vendors to actually implement dedicated
transmit queues on a per-UP basis, which are then dequeued into their
associated access category in a preferred (or even strict priority
manner). For example, (and specific to this point): it is common for
vendors to dequeue UP 5 ahead of UP 4 to the hardware performing the
EDCA function (EDCAF) for the Video Access Category (AC_VI). As
such, Signaling traffic may benefit from such treatment vs. other
video flows in the same access category (as well as vs. data flows in
the Best Effort and Background Access Categories) due to this
differentiation in servicing under such implementations.
4.2.3. Multimedia Conferencing 4.2.3. Multimedia Conferencing
The Multimedia Conferencing service class is RECOMMENDED for The Multimedia Conferencing service class is RECOMMENDED for
applications that require real-time service for rate-adaptive applications that require real-time service for rate-adaptive
traffic. The RECOMMENDED DSCP markings for Multimedia Conferencing traffic. The RECOMMENDED DSCP markings for Multimedia Conferencing
are AF41, AF42 and AF43. are AF41, AF42 and AF43 ([RFC4594] Section 4.3).
The primary media type typically carried within the Multimedia The primary media type typically carried within the Multimedia
Conferencing service class is video; as such, it is RECOMMENDED to Conferencing service class is video; as such, it is RECOMMENDED to
map this class into the Video Access Category (which it does by map this class into the Video Access Category (which it does by
default). Specifically, it is RECOMMENDED to map AF41, AF42 and AF43 default). Specifically, it is RECOMMENDED to map AF41, AF42 and AF43
to UP 4, thereby admitting Multimedia Conferencing into the Video to UP 4, thereby admitting Multimedia Conferencing into the Video
Access Category (AC_VI). Access Category (AC_VI).
4.2.4. Real-Time Interactive 4.2.4. Real-Time Interactive
The Real-Time Interactive traffic class is RECOMMENDED for The Real-Time Interactive service class is RECOMMENDED for
applications that require low loss and jitter and very low delay for applications that require low loss and jitter and very low delay for
variable rate inelastic traffic sources. Such applications may variable rate inelastic traffic sources. Such applications may
include inelastic video-conferencing applications, but may also include inelastic video-conferencing applications, but may also
include gaming applications (as pointed out in [RFC4594] Sections 2.1 include gaming applications (as pointed out in [RFC4594] Sections 2.1
through 2.3, and Section 4.4). The RECOMMENDED DSCP marking for through 2.3, and Section 4.4). The RECOMMENDED DSCP marking for
Real-Time Interactive traffic is CS4. Real-Time Interactive traffic is CS4 ([RFC4594] Section 4.4).
The primary media type typically carried within the Real-Time The primary media type typically carried within the Real-Time
Interactive service class is video; as such, it is RECOMMENDED to map Interactive service class is video; as such, it is RECOMMENDED to map
this class into the Video Access Category (which it does by default). this class into the Video Access Category (which it does by default).
Specifically, it is RECOMMENDED to map CS4 to UP 4, thereby admitting Specifically, it is RECOMMENDED to map CS4 to UP 4, thereby admitting
Real-Time Interactive traffic into the Video Access Category (AC_VI). Real-Time Interactive traffic into the Video Access Category (AC_VI).
4.2.5. Multimedia-Streaming 4.2.5. Multimedia-Streaming
The Multimedia Streaming service class is RECOMMENDED for The Multimedia Streaming service class is RECOMMENDED for
applications that require near-real-time packet forwarding of applications that require near-real-time packet forwarding of
variable rate elastic traffic sources. Typically these flows are variable rate elastic traffic sources. Typically these flows are
unidirectional. The RECOMMENDED DSCP markings for Multimedia unidirectional. The RECOMMENDED DSCP markings for Multimedia
Streaming are AF31, AF32 and AF33. Streaming are AF31, AF32 and AF33 ([RFC4594] Section 4.5).
The primary media type typically carried within the Multimedia The primary media type typically carried within the Multimedia
Streaming service class is video; as such, it is RECOMMENDED to map Streaming service class is video; as such, it is RECOMMENDED to map
this class into the Video Access Category. Specifically, it is this class into the Video Access Category. Specifically, it is
RECOMMENDED to map AF31, AF32 and AF33 to UP 4, thereby admitting RECOMMENDED to map AF31, AF32 and AF33 to UP 4, thereby admitting
Multimedia 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. The RECOMMENDED DSCP Typically these flows are unidirectional. The RECOMMENDED DSCP
marking for Broadcast Video is CS3. marking for Broadcast Video is CS3 ([RFC4594] Section 4.6).
As directly implied by the name, the primary media type typically As directly implied by the name, the primary media type typically
carried within the Broadcast Video service class is video; as such, carried within the Broadcast Video service class is video; as such,
it is RECOMMENDED to map this class into the Video Access Category. it is RECOMMENDED to map this class into the Video Access Category.
Specifically, it is RECOMMENDED to map CS4 to UP 4, thereby admitting Specifically, it is RECOMMENDED to map CS4 to UP 4, thereby admitting
Broadcast Video into the Video Access Category (AC_VI). Broadcast Video into the Video Access Category (AC_VI).
4.2.7. Low-Latency Data 4.2.7. Low-Latency Data
The Low-Latency Data service class is RECOMMENDED for elastic and The Low-Latency Data service class is RECOMMENDED for elastic and
time-sensitive data applications, often of a transactional nature, time-sensitive data applications, often of a transactional nature,
where a user is waiting for a response via the network in order to where a user is waiting for a response via the network in order to
continue with a task at hand. As such, these flows may be considered continue with a task at hand. As such, these flows are considered
foreground traffic, with delays or drops to such traffic directly foreground traffic, with delays or drops to such traffic directly
impacting user-productivity. The RECOMMENDED DSCP markings for Low- impacting user-productivity. The RECOMMENDED DSCP markings for Low-
Latency Data are AF21, AF22 and AF23. Latency Data are AF21, AF22 and AF23 ([RFC4594] Section 4.7).
In line with the recommendations made in Section 4.2.2, mapping Low- In line with the assumption made in Section 4, mapping Low-Latency
Latency Data to UP 3 may allow such to receive a superior level of Data to UP 3 may allow such to receive a superior level of service
service via transmit queues servicing the EDCAF hardware for the Best via transmit queues servicing the EDCAF hardware for the Best Effort
Effort Access Category (AC_BE). Therefore it is RECOMMENDED to map Access Category (AC_BE). Therefore it is RECOMMENDED to map Low-
Low-Latency Data traffic marked AF2x DSCP to UP 3, thereby admitting Latency Data traffic marked AF2x DSCP to UP 3, thereby admitting it
it to the Best Effort Access Category (AC_BE). to the Best Effort Access Category (AC_BE).
4.2.8. High-Throughput Data 4.2.8. High-Throughput Data
The High-Throughput Data service class is RECOMMENDED for elastic The High-Throughput Data service class is RECOMMENDED for elastic
applications that require timely packet forwarding of variable rate applications that require timely packet forwarding of variable rate
traffic sources and, more specifically, is configured to provide traffic sources and, more specifically, is configured to provide
efficient, yet constrained (when necessary) throughput for TCP efficient, yet constrained (when necessary) throughput for TCP
longer-lived flows. These flows are typically non-user-interactive. longer-lived flows. These flows are typically non-user-interactive.
Per [RFC4594]-Section 4.8, it can be assumed that this class will Per [RFC4594]-Section 4.8, it can be assumed that this class will
consume any available bandwidth and that packets traversing congested consume any available bandwidth and that packets traversing congested
links may experience higher queuing delays or packet loss. It is links may experience higher queuing delays or packet loss. It is
also assumed that this traffic is elastic and responds dynamically to also assumed that this traffic is elastic and responds dynamically to
packet loss. The RECOMMENDED DSCP markings for High-Throughput Data packet loss. The RECOMMENDED DSCP markings for High-Throughput Data
are AF11, AF12 and AF13. are AF11, AF12 and AF13 ([RFC4594] Section 4.8).
Unfortunately, there really is no corresponding fit for the High- Unfortunately, there really is no corresponding fit for the High-
Throughput Data traffic class within the constrained 4 Access Throughput Data service class within the constrained 4 Access
Category 802.11 model. If the High-Throughput Data traffic class is Category [IEEE.802.11-2016] model. If the High-Throughput Data
assigned to the Best Effort Access Category (AC_BE), then it would service class is assigned to the Best Effort Access Category (AC_BE),
contend with Low-Latency Data (while [RFC4594] recommends a then it would contend with Low-Latency Data (while [RFC4594]
distinction in servicing between these traffic classes) as well as recommends a distinction in servicing between these service classes)
with the default traffic class; alternatively, if it is assigned to as well as with the default service class; alternatively, if it is
the Background Access Category (AC_BK), then it would receive a less- assigned to the Background Access Category (AC_BK), then it would
then-best-effort service and contend with Low-Priority Data (as receive a less-then-best-effort service and contend with Low-Priority
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 802.11 model, it is Throughout Data service class within the [IEEE.802.11-2016] model, it
generally RECOMMENDED to map High-Throughput Data to UP 0, thereby is generally RECOMMENDED to map High-Throughput Data to UP 0, thereby
admitting it to the Best Effort Access Category (AC_BE). admitting it to the Best Effort Access Category (AC_BE).
4.2.9. Standard Service Class 4.2.9. Standard Service Class
The Standard service class is RECOMMENDED for traffic that has not The Standard service class is RECOMMENDED for traffic that has not
been classified into one of the other supported forwarding service been classified into one of the other supported forwarding service
classes in the DiffServ network domain. This service class provides classes in the Diffserv network domain. This service class provides
the Internet's "best-effort" forwarding behavior. The RECOMMENDED the Internet's "best-effort" forwarding behavior. The RECOMMENDED
DSCP marking for the Standard Service Class is DF. DSCP marking for the Standard Service Class is DF. ([RFC4594]
Section 4.9)
The Standard Service Class loosely corresponds to the 802.11 Best The Standard Service Class loosely corresponds to the
Effort Access Category (AC_BK) and therefore it is RECOMMENDED to map [IEEE.802.11-2016] Best Effort Access Category (AC_BK) and therefore
Standard Service Class traffic marked DF DSCP to UP 0, thereby it is RECOMMENDED to map Standard Service Class traffic marked DF
admitting it to the Best Effort Access Category (AC_BE). DSCP to UP 0, thereby admitting it to the Best Effort Access Category
(AC_BE).
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 service without guarantees. This service class is willing to accept without service assurances. This service class
is specified in [RFC3662]. is specified in [RFC3662].
The Low-Priority Data service class loosely corresponds to the 802.11 The Low-Priority Data service class loosely corresponds to the
Background Access Category (AC_BK) and therefore it is RECOMMENDED to [IEEE.802.11-2016] Background Access Category (AC_BK) and therefore
map Low-Priority Data traffic marked CS1 DSCP to UP 1, thereby it is RECOMMENDED to map Low-Priority Data traffic marked CS1 DSCP to
admitting it to the Background Access Category (AC_BK). UP 1, thereby admitting it to the Background Access Category (AC_BK).
4.3. DSCP-to-UP Mapping Recommendations Summary 4.3. DSCP-to-UP Mapping Recommendations Summary
Figure 1 summarizes the [RFC4594] DSCP marking recommendations mapped Figure 1 summarizes the [RFC4594] DSCP marking recommendations mapped
to IEEE 802.11 UP and access categories applied in the downstream to [IEEE.802.11-2016] UP and access categories applied in the
direction (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 |
|===============+======+=========+=============+===================| |===============+======+=========+=============+===================|
|Network Control| CS6 | RFC2474 | (See Section 4.1.1) | | | | | 7 | AC_VO (Voice) |
|Network Control| CS7 | RFC2474 | OR |
|(reserved for | | | Remark/Drop at Diffserv Boundary|
| future use) | | | (See Section 4.1.1) |
+---------------+------+---------+-------------+-------------------+
| | | | 7 | AC_VO (Voice) |
|Network Control| CS6 | RFC2474 | OR |
| | | | Remark/Drop at Diffserv Boundary|
| | | | (See Section 4.1.1) |
+---------------+------+---------+-------------+-------------------+ +---------------+------+---------+-------------+-------------------+
| Telephony | EF | RFC3246 | 6 | AC_VO (Voice) | | Telephony | EF | RFC3246 | 6 | AC_VO (Voice) |
+---------------+------+---------+-------------+-------------------+ +---------------+------+---------+-------------+-------------------+
| VOICE-ADMIT |VOICE-| RFC5865 | 6 | AC_VO (Voice) | | VOICE-ADMIT |VOICE-| RFC5865 | 6 | AC_VO (Voice) |
| |ADMIT | | | | | |ADMIT | | | |
+---------------+------+---------+-------------+-------------------+ +---------------+------+---------+-------------+-------------------+
| Signaling | CS5 | RFC2474 | 5 | AC_VI (Video) | | Signaling | CS5 | RFC2474 | 5 | AC_VI (Video) |
+---------------+------+---------+-------------+-------------------+ +---------------+------+---------+-------------+-------------------+
| Multimedia | AF41 | | | | | Multimedia | AF41 | | | |
| Conferencing | AF42 | RFC2597 | 4 | AC_VI (Video) | | Conferencing | AF42 | RFC2597 | 4 | AC_VI (Video) |
skipping to change at page 17, line 5 skipping to change at page 20, line 27
+---------------+------+---------+-------------+-------------------+ +---------------+------+---------+-------------+-------------------+
| Standard | DF | RFC2474 | 0 |AC_BE (Best Effort)| | Standard | DF | RFC2474 | 0 |AC_BE (Best Effort)|
+---------------+------+---------+-------------+-------------------+ +---------------+------+---------+-------------+-------------------+
| Low-Priority | CS1 | RFC3662 | 1 | AC_BK (Background)| | Low-Priority | CS1 | RFC3662 | 1 | AC_BK (Background)|
| Data | | | | | | Data | | | | |
+------------------------------------------------------------------+ +------------------------------------------------------------------+
Figure 1: Summary of Downstream DSCP to IEEE 802.11 UP and AC Mapping Figure 1: Summary of Downstream DSCP to IEEE 802.11 UP and AC Mapping
Recommendations Recommendations
5. Upstream Mapping Recommendations 5. Upstream Mapping and Marking Recommendations
In the upstream direction, there are three types of mapping that may In the upstream direction (i.e. wireless-to-wired), there are three
occur: 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
o UP-to-DSCP mapping at the wireless access point o UP-to-DSCP mapping at the wireless access point
o DSCP-Trust at the wireless access point o DSCP-Trust at the wireless access point (effectively a 1:1 DSCP-
to-DSCP mapping)
Alternatively, the network administrator MAY choose to use the
wireless-to-wired edge as a Diffserv boundary and explicitly set (or
reset) DSCP markings according to administrative policy, thus making
the wireless edge a Diffserv policy enforcement point.
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.1. As default DSCP-to-UP mapping scheme as described in Section 2.2. As
such, this can lead to the same conflicts as described in that such, this can lead to the same conflicts as described in that
section, but in the upstream direction. section, but in the upstream direction.
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
such wireless client operating systems utilize instead the same DSCP- such wireless client operating systems utilize instead the same DSCP-
to-UP mapping recommendations presented in Section 4 and/or fully to-UP mapping recommendations presented in Section 4.
customizable UP markings.
5.2. UP-to-DSCP Mapping at the Wireless Access Point 5.2. Upstream UP-to-DSCP Mapping at the Wireless Access Point
UP-to-DSCP mapping generates a DSCP value for the IP packet (either UP-to-DSCP mapping generates a DSCP value for the IP packet (either
an unencapsulated IP packet or an IP packet encapsulated within a an unencapsulated IP packet or an IP packet encapsulated within a
tunneling protocol such as CAPWAP - and destined towards a wireless tunneling protocol such as CAPWAP - and destined towards a wireless
LAN controller for decapsulation and forwarding) from the Layer 2 LAN controller for decapsulation and forwarding) from the Layer 2
IEEE UP markings of the wireless frame. [IEEE.802.11-2016] UP marking. This is typically done in the manner
described in Section 2.3.
It should be noted that any explicit remarking policy to be performed It should be noted that any explicit remarking policy to be performed
on such a packet only takes place at the nearest classification and on such a packet only takes place at the nearest classification and
marking policy enforcement point, which may be: marking policy enforcement point, which may be:
o At the wireless access point o At the wireless access point
o At the wired network switch port o At the wired network switch port
o At the wireless LAN controller o At the wireless LAN controller
As such, UP-to-DSCP mapping allows for wireless L2 markings to affect As such, UP-to-DSCP mapping allows for wireless L2 markings to affect
the QoS treatment of a packet over the wired IP network (that is, the QoS treatment of a packet over the wired IP network (that is,
until the packet reaches the nearest classification and marking until the packet reaches the nearest classification and marking
policy enforcement point). policy enforcement point).
It should be noted that nowhere in the IEEE 802.11 specifications is It should be further noted that nowhere in the [IEEE.802.11-2016]
there an intent expressed for 802.11 UP to be used to influence QoS specifications is there an intent expressed for UP markings to be
treatment over wired IP networks. Furthermore, both [RFC2474] and used to influence QoS treatment over wired IP networks. Furthermore,
[RFC2475] allow for the host to set DSCP markings for QoS treatment [RFC2474], [RFC2475] and [RFC8100] all allow for the host to set DSCP
over IP networks. Therefore, it is NOT RECOMMENDED that wireless markings for end-to-end QoS treatment over IP networks. Therefore,
access points trust UP markings as set by these hosts and it is NOT RECOMMENDED that wireless access points trust Layer 2
[IEEE.802.11-2016] UP markings as set by wireless hosts and
subsequently perform a UP-to-DSCP mapping in the upstream direction, subsequently perform a UP-to-DSCP mapping in the upstream direction,
but rather, if wireless host markings are to be trusted (as per but rather, if wireless host markings are to be trusted (as per
business requirements, technical constraints and administrative business requirements, technical constraints and administrative
preference), then it is RECOMMENDED to trust the DSCP markings set by policies), then it is RECOMMENDED to trust the Layer 3 DSCP markings
these wireless hosts. set by these wireless hosts instead, as is discussed in the next
section.
5.3. DSCP-Trust at the Wireless Access Point 5.3. Upstream DSCP-Trust at the Wireless Access Point
On wireless access points that can trust DSCP markings of packets It is NOT RECOMMENDED to trust DSCP markings from devices that are
encapsulated within wireless frames it is RECOMMENDED to trust DSCP not authenticated and authorized; these are considered untrusted
markings in the upstream direction, for the following reasons: sources.
o [RFC2474] and [RFC2475] allow for hosts to set DSCP markings to When business requirements and/or technical constraints and/or
achieve and end-to-end differentiated service administrative policies require a trust function at the wireless
edge, then it is RECOMMENDED to trust DSCP (over [IEEE.802.11-2016]
UP markings) markings in the upstream direction, for the following
reasons:
o IEEE 802.11 does not specify that UP markings are to be used to o [RFC2474], [RFC2475] and [RFC8100] all allow for hosts to set DSCP
affect QoS treatment over wired IP networks markings to achieve an end-to-end differentiated service
o [IEEE.802.11-2016] does not specify that UP markings are to be
used to affect QoS treatment over wired IP networks
o Most wireless device operating systems generate UP values by the o Most wireless device operating systems generate UP values by the
same method as described in Section 3.1 (i.e. by using the 3 MSB same method as described in Section 2.2 (i.e. by using the 3 MSB
of the encapsulated 6-bit DSCP); then, at the access point, these of the encapsulated 6-bit DSCP); then, at the access point, these
3-bit mappings are converted back into DSCP values, either by the 3-bit markings are converted back into DSCP values, typically in
default operation described in Section 3.2 or by a customized the default manner described in Section 2.3; as such, information
mapping as described in Section 4; in either case, information is is lost in the translation from a 6-bit marking to a 3-bit marking
lost in the transitions from 6-bit marking to 3-bit marking and (which is then subsequently translated back to a 6-bit marking);
then back to 6-bit marking; trusting the encapsulated DSCP trusting the original (encapsulated) DSCP marking prevents such
prevents this loss of information loss of information
o A practical implementation benefit is also realized by trusting o A practical implementation benefit is also realized by trusting
the DSCP set by wireless client devices, as enabling applications the DSCP set by wireless client devices, as enabling applications
to mark DSCP is much more prevalent and accessible to programmers to mark DSCP is much more prevalent and accessible to programmers
of wireless applications vis-a-vis trying to explicitly set UP of applications running on wireless device platforms, vis-a-vis
values, which requires special hooks into the wireless device trying to explicitly set UP values, which requires special hooks
operating system and/or hardware device drivers, many of which (at into the wireless device operating system and/or hardware device
the time of writing) have little or no resources to support such drivers, many of which do not support such functionality
functionality
5.4. Upstream DSCP Marking at the Wireless Access Point
An alternative option to mapping is for the administrator to treat
the wireless edge as the edge of the Diffserv domain and explicitly
set (or reset) DSCP markings in the upstream direction according to
administrative policy. This option is RECOMMENDED over mapping, as
this typically is the most secure solution, as the network
administrator directly enforces the Diffserv policy across the IP
network (versus an application developer and/or the wireless endpoint
device operating system developer, who may be functioning completely
independently of the network administrator).
6. Appendix: IEEE 802.11 QoS Overview 6. Appendix: IEEE 802.11 QoS Overview
QoS is enabled on wireless networks by means of the Hybrid QoS is enabled on wireless networks by means of the Hybrid
Coordination Function (HCF). To give better context to the Coordination Function (HCF). To give better context to the
enhancements in HCF that enable QoS, it may be helpful to begin with enhancements in HCF that enable QoS, it may be helpful to begin with
a review of the original Distributed Coordination Function (DCF). a review of the original Distributed Coordination Function (DCF).
6.1. Distributed Coordination Function (DCF) 6.1. Distributed Coordination Function (DCF)
skipping to change at page 19, line 36 skipping to change at page 23, line 43
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 802.11 Avoidance (CSMA/CA). The original CSMA/CA mechanism used in IEEE
was the Distributed Coordination Function. DCF is a timer-based 802.11 was the Distributed Coordination Function. DCF is a timer-
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 contention windows.
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 802.11 standard. For example, the IEEE 802.11-2012 described by the [IEEE.802.11-2016] standard. For example, the
standard specifies the slot time to be 20 us (IEEE 802.11-2012 [IEEE.802.11-2016] standard specifies the slot time to be 20 us
Table 16-2) for legacy implementations (such as 802.11b, supporting ([IEEE.802.11-2016] Table 15-5) for legacy implementations (such as
1, 2, 5.5 and 11 Mbps data rates), while newer implementations IEEE 802.11b, supporting 1, 2, 5.5 and 11 Mbps data rates), while
(including 802.11g, 80.11a, 802.11n and 802.11ac, supporting data newer implementations (including IEEE 802.11g, 80.11a, 802.11n and
rates from 500 Mbps to over 1 Gbps) define a shorter slot time of 9 802.11ac, supporting data rates from 500 Mbps to over 1 Gbps) define
us (IEEE 802.11-2012, Section 18.4.4, Table 18-17). a shorter slot time of 9 us ([IEEE.802.11-2016], Section 17.4.4,
Table 17-21).
6.1.2. Interframe Spaces 6.1.2. Interframe Spaces
The time interval between frames that are transmitted over the air is The time interval between frames that are transmitted over the air is
called the Interframe Space (IFS). Several IFS are defined in called the Interframe Space (IFS). Several IFS are defined in
802.11, with the two most relevant to DCF being the Short Interframe [IEEE.802.11-2016], with the two most relevant to DCF being the Short
Space (SIFS) and the DCF Interframe Space (DIFS). Interframe Space (SIFS) and the DCF Interframe Space (DIFS).
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
802.11 frame and to generate a response frame. Like slot times, the [IEEE.802.11-2016] frame and to generate a response frame. Like slot
SIFS can vary according to the performance implementation of the times, the SIFS can vary according to the performance implementation
802.11 standard. The SIFS for 802.11a, 802.11n and 802.11ac (in 5 of the [IEEE.802.11-2016] standard. The SIFS for IEEE 802.11a,
Ghz) is 16 us (IEEE 802.11-2012, Section 18.4.4, Table 18-17). 802.11n and 802.11ac (in 5 GHz) is 16 us ([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 idle for the duration of a
DIFS interval. The DIFS is calculated as: 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 offset
this, each station must wait, not only a fixed amount of time (the this, each station must wait, not only a fixed amount of time (the
DIFS) but also a random amount of time (the random backoff) prior to DIFS), but also a random amount of time (the random backoff) prior to
transmission. The range of the generated random backoff timer is transmission. The range of the generated random backoff timer is
bounded by the Contention Window. bounded by the Contention Window.
6.1.3. Contention Windows 6.1.3. Contention Windows
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 Contention Window minimum value (CWmin), inclusive. The CWmin for
DCF (in 5 GHz) is specified as 15 slot times (IEEE 802.11- 2012, DCF (in 5 GHz) is specified as 15 slot times ([IEEE.802.11-2016],
Section 18.4.4, Table 18-17). Section 17.4.4, 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 will occur. At this point, the stations effectively a collision may occur. At this point, the stations effectively begin
begin the process again, waiting a DIFS and generate a new random the process again, waiting a DIFS and generate a new random backoff
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 Contention Window approximatively doubles in size (thus
exponentially increasing the range of the random value). This exponentially increasing the range of the random value). This
process repeats as often as necessary if collisions continue to process repeats as often as necessary if collisions continue to
occur, until the maximum Contention Window size (CWmax) is reached. occur, until the maximum Contention Window size (CWmax) is reached.
The CWmax for DCF is specified as 1023 slot times (IEEE 802.11-2012, The CWmax for DCF is specified as 1023 slot times
Section 18.4.4, Table 18-17). ([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 pre-defined limit is reached), but the Contention Window sizes
are fixed at the CWmax value. are fixed at the 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 us slot times may be as high as 9
ms of jitter per attempt. And as previously noted, multiple attempts ms of jitter per attempt. And, as previously noted, multiple
can be made at CWmax. 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 802.11, which enhanced DCF in 2005 to support QoS, specifying HCF in IEEE 802.11,
was integrated into the main 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 802.11 frame format is the inclusion of One of the key changes to the [IEEE.802.11-2016] frame format is the
a QoS Control field, with 3 bits dedicated for QoS markings. These inclusion of a QoS Control field, with 3 bits dedicated for QoS
bits are referred to the User Priority (UP) bits and these support markings. These bits are referred to the User Priority (UP) bits and
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 non-
configurable and standard-specified mapping of UP markings to 802.11 configurable and standard-specified mapping of UP markings to
Access Categories (AC) that generate differentiated treatment over [IEEE.802.11-2016] Access Categories (AC) that generate
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-2012, Section 9.2.4.2, Table 9-1). (adapted from [IEEE.802.11-2016], Section 10.2.4.2, Table 10-1).
+-----------------------------------------+ +-----------------------------------------+
| User | Access | Designative | | User | Access | Designative |
| Priority | Category | (informative) | | Priority | Category | (informative) |
|===========+============+================| |===========+============+================|
| 7 | AC_VO | Voice | | 7 | AC_VO | Voice |
+-----------+------------+----------------+ +-----------+------------+----------------+
| 6 | AC_VO | Voice | | 6 | AC_VO | Voice |
+-----------+------------+----------------+ +-----------+------------+----------------+
| 5 | AC_VI | Video | | 5 | AC_VI | Video |
skipping to change at page 22, line 38 skipping to change at page 27, line 8
Figure 2: IEEE 802.11 Access Categories and User Priority Mappings Figure 2: IEEE 802.11 Access Categories and User Priority Mappings
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 Inter-Frame 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 air is clear before attempting transmission. With time to ensure the medium is idle before attempting transmission.
DCF, the DIFS is constant for all types of traffic. However, with With DCF, the DIFS is constant for all types of traffic. However,
802.11 the fixed amount of time that a station has to wait will with [IEEE.802.11-2016] the fixed amount of time that a station has
depend on the access category and is referred to as an Arbitration to wait will depend on the access category and is referred to as an
Interframe Space (AIFS). AIFS are defined in slot times and the AIFS Arbitration Interframe Space (AIFS). AIFS are defined in slot times
per access category are shown in Figure 3 (adapted from IEEE and the AIFS per access category are shown in Figure 3 (adapted from
802.11-2012, Section 8.4.2.31, Table 8-105). [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 Contention Windows (CW)
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 802.11 access category, but so are the relative skewed according to [IEEE.802.11-2016] access category, but so are
sizes of the Contention Windows that bound the random backoff timers, the relative sizes of the Contention Windows that bound the random
as shown in Figure 4 (adapted from IEEE 802.11-2012, backoff timers, as shown in Figure 4 (adapted from
Section 8.4.2.31, Table 8-105). [IEEE.802.11-2016], 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 |
skipping to change at page 24, line 4 skipping to change at page 28, line 27
Figure 4: Contention Window Sizes by Access Category Figure 4: Contention Window 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 proposed addendum to the IEEE IEEE 802.11u [IEEE.802-11u.2011] is an addendum that has now been
802.11 standard which includes, among other enhancements, a mechanism included within the main [IEEE.802.11-2016] standard, and which
by which wireless access points can communicate DSCP to/from UP includes, among other enhancements, a mechanism by which wireless
mappings that have been configured on the wired IP network. access points can communicate DSCP to/from UP mappings that have been
Specifically, a QoS Map Set information element (described in IEEE configured on the wired IP network. Specifically, a QoS Map Set
802.11u-2011 Section 7.3.2.95) is transmitted from an AP to a information element (described in [IEEE.802.11-2016] Section 9.4.2.95
wireless endpoint device in an association / re-association Response and commonly referred to as the QoS Map element) is transmitted from
frame (or within a special QoS Map Configure frame). The purpose of an AP to a wireless endpoint device in an association / re-
the QoS Map Set information element is to provide the mapping of association Response frame (or within a special QoS Map Configure
frame).
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 Quality of Service constructs (i.e. DSCP) to User
Priorities so that a wireless endpoint device (that supports this Priorities. One intended effect of receiving such a map is for the
function and is administratively configured to enable it) can perform wireless endpoint device (that supports this function and is
corresponding DSCP-to-UP mapping within the device (i.e. between administratively configured to enable it) to perform corresponding
applications and the operating system / wireless network interface DSCP-to-UP mapping within the device (i.e. between applications and
hardware drivers) to align with what the APs are mapping in the the operating system / wireless network interface hardware drivers)
downstream direction, so as to achieve consistent end-to-end QoS. to align with what the APs are mapping in the downstream direction,
so as to achieve consistent end-to-end QoS in both directions.
The QoS Map Set information 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) are 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 this QoS Map Set information following recommendations apply when the QoS Map element is enabled:
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 4.1.1 (that packets marked to unused DiffServ Codepoints be Section 4.1.1 that packets marked to unused Diffserv Codepoints be
remarked at the edge of the DiffServ domain), and remarked at the edge of the Diffserv domain), 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 make in line with Section 4.3, to correspond to the DiffServ to be made in line with Section 4.3, to correspond to the Diffserv
Codepoints that are in use over the IP network. Codepoints that are in use over the IP network.
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
such, the model where this element is used is that of a network where
the AP is the edge of the Diffserv domain. Networks where the AP
extends the Diffserv domain by connecting other APs and
infrastructure devices through the IEEE 802.11 medium are not
included in the cases covered by the presence of the QoS Map element,
and therefore are not included in the present recommendation.
7. IANA Considerations 7. IANA Considerations
This memo asks the IANA for no new parameters. This memo asks the IANA for no new parameters.
8. Security Considerations 8. Security Considerations
The recommendation offered in Section 4.1.1 (of dropping or remarking The recommendations put forward in this document do not present any
packets marked with DiffServ Codepoints not in use at the edge of the additional security concerns that do not already exist in wired and
DiffServ domain) is to address a Denial-of-Service attack vector that wireless devices. In fact, several of the recommendations made in
exists at wired-to-wireless edges due to the requirement of trusting this document serve to mitigate and protect wired and wireless
traffic markings to ensure end-to-end QoS. For example, consider a networks from potential abuse arising from existing vulnerabilities.
malicious user flooding traffic marked CS7 or CS6 DSCP toward the
WLAN. These codepoints would map by default to UP 7 and UP 6
(respectively), both of which would be assigned to the Voice Access
Category (AC_VO). Such a flood could cause a Denial-of-Service to
wireless voice applications.
8.1. Privacy Considerations For example, it may be possible for a wireless device, either a host
or a network device, to mark packets in a manner that interferes with
or degrades existing QoS policies. Similarly, it may be possible for
a device to map L2/L3 markings in a manner that causes similar
effects. Such marking or mapping may be done intentionally or
unintentionally by the developers and/or users and/or administrators
of such devices. To illustrate: A gaming application designed to run
on a smart-phone or tablet may request that all its packets be marked
DSCP EF and/or UP 6. However, if the traffic from such an
application is trusted over a business network, then this could
interfere with QoS policies intended to provide priority services for
enterprise voice applications. To mitigate such attack vectors it is
RECOMMENDED to implement security measures, such as policing EF
marked packet flows, as detailed in [RFC2474] Section 7 and [RFC3246]
Section 3.
Furthermore, several recommendations have been made in this document
to mitigate the potential for deliberate or inadvertent violations.
Specifically the following recommendations have been made for
primarily security reasons:
Section 4.1.1 RECOMMENDED that all packets marked to Diffserv
Codepoints not in use over the wireless network be dropped or
remarked at the edge of the Diffserv domain. This recommendation
may help mitigate a Denial-of-Service attack vector that exists at
wired-to-wireless edges in the downstream direction. For example,
consider a malicious user flooding traffic marked CS7 or CS6 DSCP
toward the WLAN. These codepoints would map by default to UP 7
and UP 6 (respectively), both of which would be assigned to the
Voice Access Category (AC_VO). Such a flood could cause a Denial-
of-Service to wireless voice applications.
Section 5.3 made it clear that it is NOT RECOMMENDED to trust DSCP
markings from devices that are not authenticated and authorized,
as these are considered untrusted sources. This is especially
relevant for IoT, as billions of devices are being connected to IP
networks, many of which have little or no security.
Section 5.4 RECOMMENDED that the administrator treat the wireless
edge as the edge of the Diffserv domain and explicitly set (or
reset) DSCP markings in the upstream direction according to
administrative policy. UP-to-DSCP mapping was explicitly NOT
RECOMMENDED in Section 5.2. Also DSCP-trust was heavily caveated
in Section 5.3. These recommendations collectively serve to
mitigate Denial-of-Service attacks in the upstream direction. For
example, consider a malicious user flooding traffic from a
wireless endpoint device marked DSCP 48 and/or UP 6. If default
UP-to-DSCP mapping were enabled at the access-point, these flows
would be mapped to DSCP 48, and could thus interfere with QoS
policies intended to protect control plane protocols over the IP
network, resulting in potential network instability; such could
likewise happen if DSCP-trust were enabled in the same scenario.
Furthermore, it should be noted that the recommendations put forward
in this document are not intended to address all attack vectors
leveraging QoS marking abuse. Mechanisms that may further help
mitigate security risks include strong device- and/or user-
authentication, access-control, rate limiting, control-plane
policing, encryption and other techniques; however, the
implementation recommendations for such mechanisms are beyond the
scope of this document to address in detail. Suffice it to say that
the security of the devices and networks implementing QoS, including
QoS mapping between wired and wireless networks, SHOULD be considered
in actual deployments.
9. Acknowledgements 9. Acknowledgements
The authors wish to thank TSVWG reviewers. 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 acknowledge a great many inputs, notably from Jerome The authors also acknowledge a great many inputs, notably from David
Henry, David Kloper, Mark Montanez, Glen Lavers, Michael Fingleton, Kloper, Mark Montanez, Glen Lavers, Michael Fingleton, Sarav
Sarav Radhakrishnan, Karthik Dakshinamoorthy, Simone Arena, Ranga Radhakrishnan, Karthik Dakshinamoorthy, Simone Arena, Ranga Marathe,
Marathe, Ramachandra Murthy and many others. Ramachandra Murthy and many others.
10. References 10. References
10.1. Normative References 10.1. Normative References
[IEEE.802-11.2012] [IEEE.802.11-2016]
"Information technology - Telecommunications and "Information technology - Telecommunications and
information exchange between systems - Local and information exchange between systems - Local and
metropolitan area networks - Specific requirements - Part metropolitan area networks - Specific requirements - Part
11: Wireless LAN Medium Access Control (MAC) and Physical 11: Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) specifications", IEEE Standard 802.11, 2012, Layer (PHY) specifications", IEEE Standard 802.11, 2016,
<http://standards.ieee.org/getieee802/ <https://standards.ieee.org/findstds/
download/802.11-2012.pdf>. 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,
<http://www.rfc-editor.org/info/rfc2119>. <http://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,
DOI 10.17487/RFC2474, December 1998, DOI 10.17487/RFC2474, December 1998,
skipping to change at page 26, line 37 skipping to change at page 32, line 31
[RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort
Per-Domain Behavior (PDB) for Differentiated Services", Per-Domain Behavior (PDB) for Differentiated Services",
RFC 3662, DOI 10.17487/RFC3662, December 2003, RFC 3662, DOI 10.17487/RFC3662, December 2003,
<http://www.rfc-editor.org/info/rfc3662>. <http://www.rfc-editor.org/info/rfc3662>.
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
Guidelines for DiffServ Service Classes", RFC 4594, Guidelines for DiffServ Service Classes", RFC 4594,
DOI 10.17487/RFC4594, August 2006, DOI 10.17487/RFC4594, August 2006,
<http://www.rfc-editor.org/info/rfc4594>. <http://www.rfc-editor.org/info/rfc4594>.
[RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of
Diffserv Service Classes", RFC 5127, DOI 10.17487/RFC5127,
February 2008, <http://www.rfc-editor.org/info/rfc5127>.
[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,
<http://www.rfc-editor.org/info/rfc5865>. <http://www.rfc-editor.org/info/rfc5865>.
10.2. Informative References [RFC8100] Geib, R., Ed. and D. Black, "Diffserv-Interconnection
Classes and Practice", RFC 8100, DOI 10.17487/RFC8100,
March 2017, <http://www.rfc-editor.org/info/rfc8100>.
[I-D.ietf-tsvwg-diffserv-intercon] 10.2. Informative References
Geib, R. and D. Black, "Diffserv-Interconnection classes
and practice", draft-ietf-tsvwg-diffserv-intercon-12 (work
in progress), October 2016.
[IEEE.802-11u.2011] [IEEE.802-11u.2011]
"Information technology - Telecommunications and "Information technology - Telecommunications and
information exchange between systems - Local and information exchange between systems - Local and
metropolitan area networks - Specific requirements - Part metropolitan area networks - Specific requirements - Part
11: Wireless LAN Medium Access Control (MAC) and Physical 11: Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) specifications", IEEE Standard 802.11, 2011, Layer (PHY) specifications", IEEE Standard 802.11, 2011,
<http://standards.ieee.org/getieee802/ <http://standards.ieee.org/getieee802/
download/802.11u-2011.pdf>. download/802.11u-2011.pdf>.
[RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of
Diffserv Service Classes", RFC 5127, DOI 10.17487/RFC5127,
February 2008, <http://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,
<http://www.rfc-editor.org/info/rfc7561>. <http://www.rfc-editor.org/info/rfc7561>.
Appendix A. Change Log Appendix A. Change Log
Initial Version: July 2015 Initial Version: July 2015
Authors' Addresses Authors' Addresses
Tim Szigeti Tim Szigeti
Cisco Systems Cisco Systems
Vancouver, British Columbia V7X 1J1 Vancouver, British Columbia V6K 3L4
Canada Canada
Email: szigeti@cisco.com Email: szigeti@cisco.com
Jerome Henry
Cisco Systems
Research Triangle Park, North Carolina 27709
USA
Email: jerhenry@cisco.com
Fred Baker Fred Baker
Santa Barbara, California 93117 Santa Barbara, California 93117
USA USA
Email: FredBaker.IETF@gmail.com Email: FredBaker.IETF@gmail.com
 End of changes. 138 change blocks. 
399 lines changed or deleted 708 lines changed or added

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