RFC 8325
Mapping Diffserv to IEEE 802.11
Internet Engineering Task Force (IETF) T. Szigeti Request for Comments: 8325 J. Henry Category: Standards Track Cisco Systems ISSN: 2070-1721 F. Baker February 2018 Mapping Diffserv to IEEE 802.11Abstract
As Internet traffic is increasingly sourced from and destined to wireless endpoints, it is crucial that Quality of Service (QoS) be aligned between wired and wireless networks; however, this is not always the case by default. This document specifies a set of mappings from Differentiated Services Code Point (DSCP) to IEEE 802.11 User Priority (UP) to reconcile the marking recommendations offered by the IETF and the IEEE so as to maintain consistent QoS treatment between wired and IEEE 802.11 wireless networks. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8325. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Related Work . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Interaction with RFC 7561 . . . . . . . . . . . . . . . . 4 1.3. Applicability Statement . . . . . . . . . . . . . . . . . 4 1.4. Document Organization . . . . . . . . . . . . . . . . . . 5 1.5. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.6. Terminology Used in This Document . . . . . . . . . . . . 6 2. Service Comparison and Default Interoperation of Diffserv and IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.1. Diffserv Domain Boundaries . . . . . . . . . . . . . . . 9 2.2. EDCF Queuing . . . . . . . . . . . . . . . . . . . . . . 10 2.3. Default DSCP-to-UP Mappings and Conflicts . . . . . . . . 10 2.4. Default UP-to-DSCP Mappings and Conflicts . . . . . . . . 11 3. Recommendations for Capabilities of Wireless Device Marking and Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 13 4. Recommendations for DSCP-to-UP Mapping . . . . . . . . . . . 13 4.1. Network Control Traffic . . . . . . . . . . . . . . . . . 14 4.1.1. Network Control Protocols . . . . . . . . . . . . . . 14 4.1.2. Operations, Administration, and Maintenance (OAM) . 15 4.2. User Traffic . . . . . . . . . . . . . . . . . . . . . . 15 4.2.1. Telephony . . . . . . . . . . . . . . . . . . . . . . 15 4.2.2. Signaling . . . . . . . . . . . . . . . . . . . . . . 16 4.2.3. Multimedia Conferencing . . . . . . . . . . . . . . . 17 4.2.4. Real-Time Interactive . . . . . . . . . . . . . . . . 17 4.2.5. Multimedia Streaming . . . . . . . . . . . . . . . . 17 4.2.6. Broadcast Video . . . . . . . . . . . . . . . . . . . 18 4.2.7. Low-Latency Data . . . . . . . . . . . . . . . . . . 18 4.2.8. High-Throughput Data . . . . . . . . . . . . . . . . 18 4.2.9. Standard . . . . . . . . . . . . . . . . . . . . . . 19 4.2.10. Low-Priority Data . . . . . . . . . . . . . . . . . . 20 4.3. Summary of Recommendations for DSCP-to-UP Mapping . . . . 20 5. Recommendations for Upstream Mapping and Marking . . . . . . 21 5.1. Upstream DSCP-to-UP Mapping within the Wireless Client Operating System . . . . . . . . . . . . . . . . . . . . 22 5.2. Upstream UP-to-DSCP Mapping at the Wireless AP . . . . . 22 5.3. Upstream DSCP-Passthrough at the Wireless AP . . . . . . 23 5.4. Upstream DSCP Marking at the Wireless AP . . . . . . . . 24 6. Overview of IEEE 802.11 QoS . . . . . . . . . . . . . . . . . 24 6.1. Distributed Coordination Function (DCF) . . . . . . . . . 25 6.1.1. Slot Time . . . . . . . . . . . . . . . . . . . . . . 25 6.1.2. Interframe Space (IFS) . . . . . . . . . . . . . . . 26 6.1.3. Contention Window (CW) . . . . . . . . . . . . . . . 26 6.2. Hybrid Coordination Function (HCF) . . . . . . . . . . . 27 6.2.1. User Priority (UP) . . . . . . . . . . . . . . . . . 27 6.2.2. Access Category (AC) . . . . . . . . . . . . . . . . 28 6.2.3. Arbitration Interframe Space (AIFS) . . . . . . . . . 29
6.2.4. Access Category CWs . . . . . . . . . . . . . . . . . 29
6.3. IEEE 802.11u QoS Map Set . . . . . . . . . . . . . . . . 30
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
8. Security Considerations . . . . . . . . . . . . . . . . . . . 31
8.1. Security Recommendations for General QoS . . . . . . . . 31
8.2. Security Recommendations for WLAN QoS . . . . . . . . . . 32
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
9.1. Normative References . . . . . . . . . . . . . . . . . . 34
9.2. Informative References . . . . . . . . . . . . . . . . . 35
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction
The wireless medium defined by IEEE 802.11 [IEEE.802.11-2016] has
become the preferred medium for endpoints connecting to business and
private networks. However, it presents several design challenges for
ensuring end-to-end QoS. Some of these challenges relate to the
nature of the IEEE 802.11 Radio Frequency (RF) medium itself, being a
half-duplex and shared medium, while other challenges relate to the
fact that the IEEE 802.11 standard is not administered by the same
standards body as IP networking standards. While the IEEE has
developed tools to enable QoS over wireless networks, little guidance
exists on how to maintain consistent QoS treatment between wired IP
networks and wireless IEEE 802.11 networks. The purpose of this
document is to provide such guidance.
1.1. Related Work
Several RFCs outline Diffserv QoS recommendations over IP networks,
including:
RFC 2474 Specifies the Diffserv Codepoint Field. This RFC also
details Class Selectors, as well as the Default
Forwarding (DF) PHB for best effort traffic. The Default
Forwarding PHB is referred to as the Default PHB in RFC
2474.
RFC 2475 Defines a Diffserv architecture.
RFC 3246 Specifies the Expedited Forwarding (EF) Per-Hop Behavior
(PHB).
RFC 2597 Specifies the Assured Forwarding (AF) PHB.
RFC 3662 Specifies a Lower-Effort Per-Domain Behavior (PDB).
RFC 4594 Presents configuration guidelines for Diffserv service classes. RFC 5127 Presents the aggregation of Diffserv service classes. RFC 5865 Specifies a DSCP for capacity-admitted traffic. Note: [RFC4594] is intended to be viewed as a framework for supporting Diffserv in any network, including wireless networks; 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], as well as [RFC5127], and [RFC8100]. In turn, the relevant standard for wireless QoS is IEEE 802.11, which is being progressively updated; at the time of writing, the current version of which is [IEEE.802.11-2016].1.2. Interaction with RFC 7561
There is also a recommendation from the Global System for Mobile Communications Association (GSMA) on DSCP-to-UP Mapping for IP Packet eXchange (IPX), specifically their Guidelines for IPX Provider networks [GSMA-IPX_Guidelines]. These GSMA Guidelines were developed without reference to existing IETF specifications for various services, referenced in Section 1.1. In turn, [RFC7561] was written based on these GSMA Guidelines, as explicitly called out in [RFC7561], Section 4.2. Thus, [RFC7561] conflicts with the overall Diffserv traffic-conditioning service plan, both in the services specified and the codepoints specified for them. As such, these two plans cannot be normalized. Rather, as discussed in [RFC2474], Section 2, the two domains (IEEE 802.11 and GSMA) are different Differentiated Services Domains separated by a Differentiated Services Boundary. At that boundary, codepoints from one domain are translated to codepoints for the other, and maybe to Default (zero) if there is no corresponding service to translate to.1.3. Applicability Statement
This document is applicable to the use of Differentiated Services that interconnect with IEEE 802.11 wireless LANs (referred to as Wi-Fi, throughout this document, for simplicity). These guidelines are applicable whether the wireless access points (APs) are deployed in an autonomous manner, managed by (centralized or distributed) WLAN controllers, or some hybrid deployment option. This is because, in all these cases, the wireless AP is the bridge between wired and wireless media.
This document applies to IP networks using Wi-Fi infrastructure at the link layer. Such networks typically include wired LANs with wireless APs at their edges; however, such networks can also include Wi-Fi backhaul, wireless mesh solutions, or any other type of AP-to- AP wireless network that extends the wired-network infrastructure.1.4. Document Organization
This document is organized as follows: Section 1 introduces the wired-to-wireless QoS challenge, references related work, outlines the organization of the document, and specifies both the requirements language and the terminology used in this document. Section 2 begins the discussion with a comparison of IETF Diffserv QoS and Wi-Fi QoS standards and highlights discrepancies between these that require reconciliation. Section 3 presents the marking and mapping capabilities that wireless APs and wireless endpoint devices are recommended to support. Section 4 presents DSCP-to-UP mapping recommendations for each of the [RFC4594] service classes, which are primarily applicable in the downstream (wired-to-wireless) direction. Section 5, in turn, considers upstream (wireless-to-wired) QoS options, their respective merits and recommendations. Section 6 (in the form of an Appendix) presents a brief overview of how QoS is achieved over IEEE 802.11 wireless networks, given the shared, half-duplex nature of the wireless medium. Section 7 contains IANA considerations. Section 8 presents security considerations relative to DSCP-to-UP mapping, UP-to-DSCP mapping, and re-marking.1.5. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
1.6. Terminology Used in This Document
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 QoS station (STA) to contend for the channel in order to transmit medium access control (MAC) service data units (MSDUs) with certain priorities; see [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); see [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. See the definition in [IEEE.802.11-2016], Section 3.1. Contention Window: See CW. CSMA/CA: Carrier Sense Multiple Access with Collision Avoidance. A MAC 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 MAC 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 units of
Slot Time) that a CW can take.
CWMin: Contention Window Minimum. The minimum value that a CW 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 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].
The DSCP is carried in the first 6 bits of the IPv4 Type of
Service (TOS) field and the IPv6 Traffic Class field (the
remaining 2 bits are used for IP Explicit Congestion Notification
(ECN) [RFC3168]).
EIFS: Extended Interframe Space. A unit of time that a station has
to defer before transmitting a frame if the previous frame
contained an error, as per [IEEE.802.11-2016], Section 10.3.2.3.7.
HCF: Hybrid Coordination Function. A coordination function that
combines and enhances aspects of the contention-based and
contention-free access methods to provide QoS stations (STAs) with
prioritized and parameterized QoS access to the WM, while
continuing to support non-QoS STAs for best-effort transfer; see
[IEEE.802.11-2016], Section 3.1.
IFS: Interframe Space. Period of silence between transmissions over
IEEE 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. See [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 IEEE
802.11 networks; it is defined in [IEEE.802.11-2016],
Section 10.3.2.13.
Trust: From a QoS-perspective, "trust" refers to the accepting of
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
UP markings. For example, if an AP 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 re-mark 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 [RFC4594].
UP: User Priority. A value associated with an MSDU that indicates
how the MSDU is to be handled. The UP is assigned to an MSDU in
the layers above the MAC; see [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.
Wireless: In the context of this document, "wireless" refers to the
media defined in IEEE 802.11 [IEEE.802.11-2016], and not 3G/4G LTE
or any other radio telecommunications specification.
2. Service Comparison and Default Interoperation of Diffserv and IEEE 802.11
(Section 6 provides a brief overview of IEEE 802.11 QoS.) The following comparisons between IEEE 802.11 and Diffserv services should be noted: [IEEE.802.11-2016] does not support an EF PHB service [RFC3246], as it is not possible to assure that a given access category will be serviced with strict priority over another (due to the random element within the contention process) [IEEE.802.11-2016] does not support an AF PHB service [RFC2597], again because it is not possible to assure that a given access category will be serviced with a minimum amount of assured bandwidth (due to the non-deterministic nature of the contention process) [IEEE.802.11-2016] loosely supports a Default PHB ([RFC2474]) via the Best Effort Access Category (AC_BE) [IEEE.802.11-2016] loosely supports a Lower Effort PDB service ([RFC3662]) via the Background Access Category (AC_BK) As such, these high-level considerations should be kept in mind when mapping from Diffserv to [IEEE.802.11-2016] (and vice versa); however, APs may or may not always be positioned at Diffserv domain boundaries, as will be discussed next.2.1. Diffserv Domain Boundaries
It is important to recognize that the wired-to-wireless edge may or may not function as an edge of a Diffserv domain or a domain boundary. In most commonly deployed WLAN models, the wireless AP represents not only the edge of the Diffserv domain, but also the edge of the network infrastructure itself. As such, only client endpoint devices (and no network infrastructure devices) are downstream from the access points in these deployment models. Note: security considerations and recommendations for hardening such Wi-Fi-at-the- edge deployment models are detailed in Section 8; these recommendations include mapping network control protocols (which are not used downstream from the AP in this deployment model) to UP 0.
Alternatively, in other deployment models, such as Wi-Fi backhaul, wireless mesh infrastructures, wireless AP-to-AP deployments, or in cases where a Wi-Fi link connects to a device providing service via another technology (e.g., Wi-Fi to Bluetooth or Zigbee router), the wireless AP extends the network infrastructure and thus, typically, the Diffserv domain. In such deployments, both client devices and infrastructure devices may be expected downstream from the APs, and, as such, network control protocols are RECOMMENDED to be mapped to UP 7 in this deployment model, as is discussed in Section 4.1.1. Thus, as can be seen from these two examples, the QoS treatment of packets at the AP will depend on the position of the AP in the network infrastructure and on the WLAN deployment model. However, regardless of whether or not the AP is at the Diffserv boundary, marking-specific incompatibilities exist from Diffserv to 802.11 (and vice versa) that must be reconciled, as will be discussed next.2.2. EDCF Queuing
[IEEE.802.11-2016] displays a reference implementation queuing model in Figure 10-24, which depicts four transmit queues, one per access category. However, in practical implementations, it is common for WLAN network equipment vendors to implement dedicated transmit queues on a per-UP (versus a per-AC) basis, which are then dequeued into their associated AC in a preferred (or even in a strict priority manner). For example, it is common for vendors to dequeue UP 5 ahead of UP 4 to the hardware performing the EDCA function (EDCAF) for the Video Access Category (AC_VI). Some of the recommendations made in Section 4 make reference to this common implementation model of queuing per UP.2.3. Default DSCP-to-UP Mappings and Conflicts
While no explicit guidance is offered in mapping (6-Bit) Layer 3 DSCP 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 these by what we will refer to as "default DSCP-to-UP mapping" (for lack of a better term), wherein the three Most Significant Bits (MSBs) of the DSCP are used as the corresponding L2 markings.
Note: There are mappings provided in [IEEE.802.11-2016], Annex V Tables V-1 and V2, but it bears mentioning that these mappings are provided as examples (as opposed to explicit recommendations). Furthermore, some of these mappings do not align with the intent and recommendations expressed in [RFC4594], as will be discussed in this and the following section (Section 2.4). However, when this default DSCP-to-UP mapping method is applied to packets marked per recommendations in [RFC4594] and destined to 802.11 WLAN clients, it will yield a number of inconsistent QoS mappings, specifically: 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 Category (AC_VO), for which it is intended o Multimedia Streaming (AF3-011xx0) will be mapped to UP 3 (011) and treated in the Best Effort Access Category (AC_BE) rather than the Video Access Category (AC_VI), for which it is intended o Broadcast Video (CS3-011000) will be mapped to UP 3 (011) and treated in the Best Effort Access Category (AC_BE) rather than the Video Access Category (AC_VI), for which it is intended o OAM traffic (CS2-010000) will be mapped to UP 2 (010) and treated in the Background Access Category (AC_BK), which is not the intent expressed in [RFC4594] for this service class It should also be noted that while [IEEE.802.11-2016] defines an intended use for each access category through the AC naming convention (for example, UP 6 and UP 7 belong to AC_VO, the Voice Access Category), [IEEE.802.11-2016] does not: o define how upper-layer markings (such as DSCP) should map to UPs (and, hence, to ACs) o define how UPs should translate to other mediums' Layer 2 QoS markings o strictly restrict each access category to applications reflected in the AC name2.4. Default UP-to-DSCP Mappings and Conflicts
In the opposite direction of flow (the upstream direction, that is, 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 DSCP values are derived from UP values by multiplying the UP values
by 8 (i.e., shifting the three UP bits to the left and adding three additional zeros to generate a DSCP value). This derived DSCP value is then used for QoS treatment between the wireless AP and the nearest classification and marking policy enforcement point (which may be the centralized wireless LAN controller, relatively deep within the network). Alternatively, in the case where there is no other classification and marking policy enforcement point, then this derived DSCP value will be used on the remainder of the Internet path. It goes without saying that when six bits of marking granularity are derived from three, then information is lost in translation. Servicing differentiation cannot be made for 12 classes of traffic (as recommended in [RFC4594]), but for only eight (with one of these classes being reserved for future use (i.e., UP 7, which maps to DSCP CS7). Such default upstream mapping can also yield several inconsistencies with [RFC4594], including: o Mapping UP 6 (which would include Voice or Telephony traffic, see [RFC4594]) to CS6, which [RFC4594] recommends for Network Control o Mapping UP 4 (which would include Multimedia Conferencing and/or Real-Time Interactive traffic, see [RFC4594]) to CS4, thus losing the ability to differentiate between these two distinct service classes, as recommended in [RFC4594], Sections 4.3 and 4.4 o Mapping UP 3 (which would include Multimedia Streaming and/or Broadcast Video traffic, see [RFC4594]) to CS3, thus losing the ability to differentiate between these two distinct service classes, as recommended in [RFC4594], Sections 4.5 and 4.6 o Mapping UP 2 (which would include Low-Latency Data and/or OAM traffic, see [RFC4594]) to CS2, thus 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 typically lower in capacity (being Network Control Traffic), as compared to Low-Latency Data queues (being user traffic)) o Mapping UP 1 (which would include High-Throughput Data and/or Low- Priority Data traffic, see [RFC4594]) to CS1, thus losing the ability to differentiate between these two distinct service classes, as recommended in [RFC4594], Sections 4.8 and 4.10, and causing legitimate business-relevant High-Throughput Data to receive a [RFC3662] Lower-Effort PDB, for which it is not intended
The following sections address these limitations and concerns in order to reconcile [RFC4594] and [IEEE.802.11-2016]. First downstream (wired-to-wireless) DSCP-to-UP mappings will be aligned and then upstream (wireless-to-wired) models will be addressed.3. Recommendations for Capabilities of Wireless Device Marking and Mapping
This document assumes and RECOMMENDS that all wireless APs (as the interconnects between wired-and-wireless networks) support the ability to: o mark DSCP, per Diffserv standards o mark UP, per the [IEEE.802.11-2016] standard o support fully configurable mappings between DSCP and UP o process DSCP markings set by wireless endpoint devices This document further assumes and RECOMMENDS that all wireless endpoint devices support the ability to: o mark DSCP, per Diffserv standards o mark UP, per the [IEEE.802.11-2016] standard o support fully configurable mappings between DSCP (set by applications in software) and UP (set by the operating system and/ or wireless network interface hardware drivers) Having made the assumptions and recommendations above, it bears mentioning that, while the mappings presented in this document are RECOMMENDED to replace the current common default practices (as discussed in Sections 2.3 and 2.4), these mapping recommendations are not expected to fit every last deployment model; as such, they MAY be overridden by network administrators, as needed.
(page 13 continued on part 2)
