Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8325

Mapping Diffserv to IEEE 802.11

Pages: 37
Proposed Standard
Errata
Updated by:  8622
Part 1 of 3 – Pages 1 to 13
None   None   Next

Top   ToC   RFC8325 - Page 1
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.11

Abstract

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.
Top   ToC   RFC8325 - Page 2

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
Top   ToC   RFC8325 - Page 3
       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).
Top   ToC   RFC8325 - Page 4
   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.
Top   ToC   RFC8325 - Page 5
   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.
Top   ToC   RFC8325 - Page 6

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.
Top   ToC   RFC8325 - Page 7
   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
Top   ToC   RFC8325 - Page 8
      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.
Top   ToC   RFC8325 - Page 9

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.
Top   ToC   RFC8325 - Page 10
   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.
Top   ToC   RFC8325 - Page 11
   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 name

2.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
Top   ToC   RFC8325 - Page 12
   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
Top   ToC   RFC8325 - Page 13
   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)

Next Section