Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFs   Ti+   SearchTech-invite World Map Symbol

RFC 8325

Proposed STD
Pages: 37
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: TSVWG

Mapping Diffserv to IEEE 802.11

Part 1 of 3, p. 1 to 13
None       Next Section

 


Top       ToC       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       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       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       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       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       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       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       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       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       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       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       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       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