GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc8325

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.

Szigeti, et al. Standards Track [Page 1] RFC 8325 Mapping Diffserv to IEEE 802.11 February 2018

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

Szigeti, et al. Standards Track [Page 2] RFC 8325 Mapping Diffserv to IEEE 802.11 February 2018

     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).

Szigeti, et al. Standards Track [Page 3] RFC 8325 Mapping Diffserv to IEEE 802.11 February 2018

 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.

Szigeti, et al. Standards Track [Page 4] RFC 8325 Mapping Diffserv to IEEE 802.11 February 2018

 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.

Szigeti, et al. Standards Track [Page 5] RFC 8325 Mapping Diffserv to IEEE 802.11 February 2018

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.

Szigeti, et al. Standards Track [Page 6] RFC 8325 Mapping Diffserv to IEEE 802.11 February 2018

 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

Szigeti, et al. Standards Track [Page 7] RFC 8325 Mapping Diffserv to IEEE 802.11 February 2018

    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.

Szigeti, et al. Standards Track [Page 8] RFC 8325 Mapping Diffserv to IEEE 802.11 February 2018

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.

Szigeti, et al. Standards Track [Page 9] RFC 8325 Mapping Diffserv to IEEE 802.11 February 2018

 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.

Szigeti, et al. Standards Track [Page 10] RFC 8325 Mapping Diffserv to IEEE 802.11 February 2018

 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

Szigeti, et al. Standards Track [Page 11] RFC 8325 Mapping Diffserv to IEEE 802.11 February 2018

 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

Szigeti, et al. Standards Track [Page 12] RFC 8325 Mapping Diffserv to IEEE 802.11 February 2018

 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.

4. Recommendations for DSCP-to-UP Mapping

 The following section specifies downstream (wired-to-wireless)
 mappings between [RFC4594], "Configuration Guidelines for Diffserv
 Service Classes" and [IEEE.802.11-2016].  As such, this section draws
 heavily from [RFC4594], including service class definitions and
 recommendations.

Szigeti, et al. Standards Track [Page 13] RFC 8325 Mapping Diffserv to IEEE 802.11 February 2018

 This section assumes [IEEE.802.11-2016] wireless APs and/or WLAN
 controllers that support customizable, non-default DSCP-to-UP mapping
 schemes.
 This section also assumes that [IEEE.802.11-2016] APs and endpoint
 devices differentiate UP markings with corresponding queuing and
 dequeuing treatments, as described in Section 2.2.

4.1. Network Control Traffic

 Network Control Traffic is defined as packet flows that are essential
 for stable operation of the administered network [RFC4594],
 Section 3.  Network Control Traffic is different from user
 application control (signaling) that may be generated by some
 applications or services.  Network Control Traffic MAY be split into
 two service classes:
 o  Network Control, and
 o  Operations, Administration, and Maintenance (OAM)

4.1.1. Network Control Protocols

 The Network Control service class is used for transmitting packets
 between network devices (e.g., routers) that require control
 (routing) information to be exchanged between nodes within the
 administrative domain, as well as across a peering point between
 different administrative domains.
 [RFC4594], Section 3.2, recommends that Network Control Traffic be
 marked CS6 DSCP.  Additionally, as stated in [RFC4594], Section 3.1:
 "CS7 DSCP value SHOULD be reserved for future use, potentially for
 future routing or control protocols."
 By default (as described in Section 2.4), packets marked DSCP CS7
 will be mapped to UP 7 and serviced within the Voice Access Category
 (AC_VO).  This represents the RECOMMENDED mapping for CS7, that is,
 packets marked to CS7 DSCP are RECOMMENDED to be mapped to UP 7.
 However, by default (as described in Section 2.4), packets marked
 DSCP CS6 will be mapped to UP 6 and serviced within the Voice Access
 Category (AC_VO); such mapping and servicing is a contradiction to
 the intent expressed in [RFC4594], Section 3.2.  As such, it is
 RECOMMENDED to map Network Control Traffic marked CS6 to UP 7 (per
 [IEEE.802.11-2016], Section 10.2.4.2, Table 10-1), thereby admitting
 it to the Voice Access Category (AC_VO), albeit with a marking
 distinguishing it from (data-plane) voice traffic.

Szigeti, et al. Standards Track [Page 14] RFC 8325 Mapping Diffserv to IEEE 802.11 February 2018

 It should be noted that encapsulated routing protocols for
 encapsulated or overlay networks (e.g., VPN, Network Virtualization
 Overlays, etc.) are not Network Control Traffic for any physical
 network at the AP; hence, they SHOULD NOT be marked with CS6 in the
 first place.
 Additionally, and as previously noted, the Security Considerations
 section (Section 8) contains additional recommendations for hardening
 Wi-Fi-at-the-edge deployment models, where, for example, network
 control protocols are not expected to be sent nor received between
 APs and client endpoint devices that are downstream.

4.1.2. Operations, Administration, and Maintenance (OAM)

 The OAM (Operations, Administration, and Maintenance) service class
 is recommended for OAM&P (Operations, Administration, and Maintenance
 and Provisioning).  The OAM service class can include network
 management protocols, such as SNMP, Secure Shell (SSH), TFTP, Syslog,
 etc., as well as network services, such as NTP, DNS, DHCP, etc.
 [RFC4594], Section 3.3, recommends that OAM traffic be marked CS2
 DSCP.
 By default (as described in Section 2.3), packets marked DSCP CS2
 will be mapped to UP 2 and serviced with the Background Access
 Category (AC_BK).  Such servicing 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 OAM traffic, such that CS2 DSCP
 is mapped to UP 0, thereby admitting it to the Best Effort Access
 Category (AC_BE).

4.2. User Traffic

 User traffic is defined as packet flows between different users or
 subscribers.  It is the traffic that is sent to or from end-terminals
 and that supports a very wide variety of applications and services
 [RFC4594], Section 4.
 Network administrators can categorize their applications according to
 the type of behavior that they require and MAY choose to support all
 or a subset of the defined service classes.

4.2.1. Telephony

 The Telephony service class is recommended for applications that
 require real-time, very low delay, very low jitter, and very low
 packet loss for relatively constant-rate traffic sources (inelastic
 traffic sources).  This service class SHOULD be used for IP telephony
 service.  The fundamental service offered to traffic in the Telephony

Szigeti, et al. Standards Track [Page 15] RFC 8325 Mapping Diffserv to IEEE 802.11 February 2018

 service class is minimum jitter, delay, and packet loss service up to
 a specified upper bound.  [RFC4594], Section 4.1, recommends that
 Telephony traffic be marked EF DSCP.
 Traffic marked to DSCP EF will map by default (as described in
 Section 2.3) to UP 5 and, thus, to the Video Access Category (AC_VI)
 rather than to the Voice Access 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 6, thereby admitting
 it into the Voice Access Category (AC_VO).
 Similarly, the VOICE-ADMIT DSCP (44 decimal / 101100 binary)
 described in [RFC5865] is RECOMMENDED to be mapped to UP 6, thereby
 admitting it also into the Voice Access Category (AC_VO).

4.2.2. Signaling

 The Signaling service class is recommended for delay-sensitive
 client-server (e.g., traditional telephony) and peer-to-peer
 application signaling.  Telephony signaling includes signaling
 between 1) IP phone and soft-switch, 2) soft-client and soft-switch,
 and 3) media gateway and soft-switch as well as peer-to-peer using
 various protocols.  This service class is intended to be used for
 control of sessions and applications.  [RFC4594], Section 4.2,
 recommends that Signaling traffic be marked CS5 DSCP.
 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
 highest level of service (i.e., AC_VO).  This leaves only the Video
 Access Category (AC_VI), which it will map to by default (as
 described in Section 2.3).  Therefore, it is RECOMMENDED to map
 Signaling traffic marked CS5 DSCP to UP 5, thereby admitting it to
 the Video Access Category (AC_VI).
 Note: Signaling traffic is not control-plane traffic from the
 perspective of the network (but rather is data-plane traffic); as
 such, it does not merit provisioning in the Network Control service
 class (marked CS6 and mapped to UP 6).  However, Signaling traffic is
 control-plane traffic from the perspective of the voice/video
 telephony overlay-infrastructure.  As such, Signaling should be
 treated with preferential servicing versus other data-plane flows.
 This may be achieved in common WLAN deployments by mapping Signaling
 traffic marked CS5 to UP 5.  On APs supporting per-UP EDCAF queuing
 logic (as described in Section 2.2), this will result in preferential
 treatment for Signaling traffic versus other video flows in the same
 access category (AC_VI), which are marked to UP 4, as well as
 preferred treatment over flows in the Best Effort (AC_BE) and
 Background (AC_BK) Access Categories.

Szigeti, et al. Standards Track [Page 16] RFC 8325 Mapping Diffserv to IEEE 802.11 February 2018

4.2.3. Multimedia Conferencing

 The Multimedia Conferencing service class is recommended for
 applications that require real-time service for rate-adaptive
 traffic.  [RFC4594], Section 4.3, recommends Multimedia Conferencing
 traffic be marked AF4x (that is, AF41, AF42, and AF43, according to
 the rules defined in [RFC2475]).
 The primary media type typically carried within the Multimedia
 Conferencing service class is video; as such, it is RECOMMENDED to
 map this class into the Video Access Category (AC_VI), which it does
 by default (as described in Section 2.3).  Specifically, it is
 RECOMMENDED to map AF41, AF42, and AF43 to UP 4, thereby admitting
 Multimedia Conferencing into the Video Access Category (AC_VI).

4.2.4. Real-Time Interactive

 The Real-Time Interactive service class is recommended for
 applications that require low loss and jitter and very low delay for
 variable-rate inelastic traffic sources.  Such applications may
 include inelastic video-conferencing applications, but may also
 include gaming applications (as pointed out in [RFC4594], Sections
 2.1 through 2.3 and Section 4.4).  [RFC4594], Section 4.4, recommends
 Real-Time Interactive traffic be marked CS4 DSCP.
 The primary media type typically carried within the Real-Time
 Interactive service class is video; as such, it is RECOMMENDED to map
 this class into the Video Access Category (AC_VI), which it does by
 default (as described in Section 2.3).  Specifically, it is
 RECOMMENDED to map CS4 to UP 4, thereby admitting Real-Time
 Interactive traffic into the Video Access Category (AC_VI).

4.2.5. Multimedia Streaming

 The Multimedia Streaming service class is recommended for
 applications that require near-real-time packet forwarding of
 variable-rate elastic traffic sources.  Typically, these flows are
 unidirectional.  [RFC4594], Section 4.5, recommends Multimedia
 Streaming traffic be marked AF3x (that is, AF31, AF32, and AF33,
 according to the rules defined in [RFC2475]).
 The primary media type typically carried within the Multimedia
 Streaming service class is video; as such, it is RECOMMENDED to map
 this class into the Video Access Category (AC_VI), which it will by
 default (as described in Section 2.3).  Specifically, it is
 RECOMMENDED to map AF31, AF32, and AF33 to UP 4, thereby admitting
 Multimedia Streaming into the Video Access Category (AC_VI).

Szigeti, et al. Standards Track [Page 17] RFC 8325 Mapping Diffserv to IEEE 802.11 February 2018

4.2.6. Broadcast Video

 The Broadcast Video service class is recommended for applications
 that require near-real-time packet forwarding with very low packet
 loss of constant rate and variable-rate inelastic traffic sources.
 Typically these flows are unidirectional.  [RFC4594] Section 4.6
 recommends Broadcast Video traffic be marked CS3 DSCP.
 As directly implied by the name, the primary media type typically
 carried within the Broadcast Video service class is video; as such,
 it is RECOMMENDED to map this class into the Video Access Category
 (AC_VI); however, by default (as described in Section 2.3), this
 service class will map to UP 3 and, thus, the Best Effort Access
 Category (AC_BE).  Therefore, a non-default mapping is RECOMMENDED,
 such that CS4 maps to UP 4, thereby admitting Broadcast Video into
 the Video Access Category (AC_VI).

4.2.7. Low-Latency Data

 The Low-Latency Data service class is recommended for elastic and
 time-sensitive data applications, often of a transactional nature,
 where a user is waiting for a response via the network in order to
 continue with a task at hand.  As such, these flows are considered
 foreground traffic, with delays or drops to such traffic directly
 impacting user productivity.  [RFC4594], Section 4.7, recommends
 Low-Latency Data be marked AF2x (that is, AF21, AF22, and AF23,
 according to the rules defined in [RFC2475]).
 By default (as described in Section 2.3), Low-Latency Data will map
 to UP 2 and, thus, to the Background Access Category (AC_BK), which
 is contrary to the intent expressed in [RFC4594].
 Mapping Low-Latency Data to UP 3 may allow targeted traffic to
 receive a superior level of service via per-UP transmit queues
 servicing the EDCAF hardware for the Best Effort Access Category
 (AC_BE), as described in Section 2.2.  Therefore it is RECOMMENDED to
 map Low-Latency Data traffic marked AF2x DSCP to UP 3, thereby
 admitting it to the Best Effort Access Category (AC_BE).

4.2.8. High-Throughput Data

 The High-Throughput Data service class is recommended for elastic
 applications that require timely packet forwarding of variable-rate
 traffic sources and, more specifically, is configured to provide
 efficient, yet constrained (when necessary) throughput for TCP
 longer-lived flows.  These flows are typically not user interactive.
 According to [RFC4594], Section 4.8, it can be assumed that this
 class will consume any available bandwidth and that packets

Szigeti, et al. Standards Track [Page 18] RFC 8325 Mapping Diffserv to IEEE 802.11 February 2018

 traversing congested links may experience higher queuing delays or
 packet loss.  It is also assumed that this traffic is elastic and
 responds dynamically to packet loss.  [RFC4594], Section 4.8,
 recommends High-Throughput Data be marked AF1x (that is, AF11, AF12,
 and AF13, according to the rules defined in [RFC2475]).
 By default (as described in Section 2.3), High-Throughput Data will
 map to UP 1 and, thus, to the Background Access Category (AC_BK),
 which is contrary to the intent expressed in [RFC4594].
 Unfortunately, there really is no corresponding fit for the High-
 Throughput Data service class within the constrained 4 Access
 Category [IEEE.802.11-2016] model.  If the High-Throughput Data
 service class is assigned to the Best Effort Access Category (AC_BE),
 then it would contend with Low-Latency Data (while [RFC4594]
 recommends a distinction in servicing between these service classes)
 as well as with the default service class; alternatively, if it is
 assigned to the Background Access Category (AC_BK), then it would
 receive a less-then-best-effort service and contend with Low-Priority
 Data (as discussed in Section 4.2.10).
 As such, since there is no directly corresponding fit for the High-
 Throughout Data service class within the [IEEE.802.11-2016] model, it
 is generally RECOMMENDED to map High-Throughput Data to UP 0, thereby
 admitting it to the Best Effort Access Category (AC_BE).

4.2.9. Standard

 The Standard service class is recommended for traffic that has not
 been classified into one of the other supported forwarding service
 classes in the Diffserv network domain.  This service class provides
 the Internet's "best-effort" forwarding behavior.  [RFC4594],
 Section 4.9, states that the "Standard service class MUST use the
 Default Forwarding (DF) PHB".
 The Standard service class loosely corresponds to the
 [IEEE.802.11-2016] Best Effort Access Category (AC_BE); therefore, it
 is RECOMMENDED to map Standard service class traffic marked DF DSCP
 to UP 0, thereby admitting it to the Best Effort Access Category
 (AC_BE).  This happens to correspond to the default mapping (as
 described in Section 2.3).

Szigeti, et al. Standards Track [Page 19] RFC 8325 Mapping Diffserv to IEEE 802.11 February 2018

4.2.10. Low-Priority Data

 The Low-Priority Data service class serves applications that the user
 is willing to accept without service assurances.  This service class
 is specified in [RFC3662] and [LE-PHB].
 [RFC3662] and [RFC4594] both recommend Low-Priority Data be marked
 CS1 DSCP.
 Note: This marking recommendation may change in the future, as
 [LE-PHB] defines a Lower Effort (LE) PHB for Low-Priority Data
 traffic and recommends an additional DSCP for this traffic.
 The Low-Priority Data service class loosely corresponds to the
 [IEEE.802.11-2016] Background Access Category (AC_BK); therefore, it
 is RECOMMENDED to map Low-Priority Data traffic marked CS1 DSCP to UP
 1, thereby admitting it to the Background Access Category (AC_BK).
 This happens to correspond to the default mapping (as described in
 Section 2.3).

4.3. Summary of Recommendations for DSCP-to-UP Mapping

 Figure 1 summarizes the [RFC4594] DSCP marking recommendations mapped
 to [IEEE.802.11-2016] UP and Access Categories applied in the
 downstream direction (i.e., from wired-to-wireless networks).
+-------------------------------------------------------------------+
| IETF Diffserv | PHB  |Reference |         IEEE 802.11              |
| Service Class |      |   RFC    |User Priority|  Access Category   |
|===============+======+==========+=============+====================|
|               |      |          |     7       |    AC_VO (Voice)   |
|Network Control| CS7  | RFC 2474 |            OR                    |
|(reserved for  |      |          |     0       | AC_BE (Best Effort)|
| future use)   |      |          |See Security Considerations-Sec.8 |
+---------------+------+----------+-------------+--------------------+
|               |      |          |     7       |    AC_VO (Voice)   |
|Network Control| CS6  | RFC 2474 |            OR                    |
|               |      |          |     0       | AC_BE (Best Effort)|
|               |      |          |    See Security Considerations   |
+---------------+------+----------+-------------+--------------------+
|   Telephony   |  EF  | RFC 3246 |     6       |    AC_VO (Voice)   |
+---------------+------+----------+-------------+--------------------+
|  VOICE-ADMIT  |  VA  | RFC 5865 |     6       |    AC_VO (Voice)   |
|               |      |          |             |                    |
+---------------+------+----------+-------------+--------------------+
|   Signaling   | CS5  | RFC 2474 |     5       |    AC_VI (Video)   |

Szigeti, et al. Standards Track [Page 20] RFC 8325 Mapping Diffserv to IEEE 802.11 February 2018

+---------------+------+----------+-------------+--------------------+
|   Multimedia  | AF41 |          |             |                    |
| Conferencing  | AF42 | RFC 2597 |     4       |    AC_VI (Video)   |
|               | AF43 |          |             |                    |
+---------------+------+----------+-------------+--------------------+
|   Real-Time   | CS4  | RFC 2474 |     4       |    AC_VI (Video)   |
|  Interactive  |      |          |             |                    |
+---------------+------+----------+-------------+--------------------+
|  Multimedia   | AF31 |          |             |                    |
|  Streaming    | AF32 | RFC 2597 |     4       |    AC_VI (Video)   |
|               | AF33 |          |             |                    |
+---------------+------+----------+-------------+--------------------+
|Broadcast Video| CS3  | RFC 2474 |     4       |    AC_VI (Video)   |
+---------------+------+----------+-------------+--------------------+
|    Low-       | AF21 |          |             |                    |
|    Latency    | AF22 | RFC 2597 |     3       | AC_BE (Best Effort)|
|    Data       | AF23 |          |             |                    |
+---------------+------+----------+-------------+--------------------+
|     OAM       | CS2  | RFC 2474 |     0       | AC_BE (Best Effort)|
+---------------+------+----------+-------------+--------------------+
|    High-      | AF11 |          |             |                    |
|  Throughput   | AF12 | RFC 2597 |     0       | AC_BE (Best Effort)|
|    Data       | AF13 |          |             |                    |
+---------------+------+----------+-------------+--------------------+
|   Standard    | DF   | RFC 2474 |     0       | AC_BE (Best Effort)|
+---------------+------+----------+-------------+--------------------+
| Low-Priority  | CS1  | RFC 3662 |     1       | AC_BK (Background) |
|     Data      |      |          |             |                    |
+--------------------------------------------------------------------+
Note: All unused codepoints are RECOMMENDED to be mapped to UP 0
(See Security Considerations below)
     Figure 1: Summary of Mapping Recommendations from Downstream
                     DSCP to IEEE 802.11 UP and AC

5. Recommendations for Upstream Mapping and Marking

 In the upstream direction (i.e., wireless-to-wired), there are three
 types of mapping that may be implemented:
 o  DSCP-to-UP mapping within the wireless client operating system,
    and
 o  UP-to-DSCP mapping at the wireless AP, or
 o  DSCP-Passthrough at the wireless AP (effectively a 1:1 DSCP-to-
    DSCP mapping)

Szigeti, et al. Standards Track [Page 21] RFC 8325 Mapping Diffserv to IEEE 802.11 February 2018

 As an alternative to the latter two options, 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; this approach is RECOMMENDED
 whenever the APs support the required classification and marking
 capabilities.
 Each of these options will now be considered.

5.1. Upstream DSCP-to-UP Mapping within the Wireless Client Operating

    System
 Some operating systems on wireless client devices utilize a similar
 default DSCP-to-UP mapping scheme as that described in Section 2.3.
 As such, this can lead to the same conflicts as described in that
 section, but in the upstream direction.
 Therefore, to improve on these default mappings, and to achieve
 parity and consistency with downstream QoS, it is RECOMMENDED that
 wireless client operating systems instead utilize the same DSCP-to-UP
 mapping recommendations presented in Section 4.  Note that it is
 explicitly stated that packets requesting a marking of CS6 or CS7
 DSCP SHOULD be mapped to UP 0 (and not to UP 7).  Furthermore, in
 such cases, the wireless client operating system SHOULD re-mark such
 packets to DSCP 0.  This is because CS6 and CS7 DSCP, as well as UP 7
 markings, are intended for network control protocols, and these
 SHOULD NOT be sourced from wireless client endpoint devices.  This
 recommendation is detailed in the Security Considerations section
 (Section 8).

5.2. Upstream UP-to-DSCP Mapping at the Wireless AP

 UP-to-DSCP mapping generates a DSCP value for the IP packet (either
 an unencapsulated IP packet or an IP packet encapsulated within a
 tunneling protocol such as Control and Provisioning of Wireless
 Access Points (CAPWAP) -- and destined towards a wireless LAN
 controller for decapsulation and forwarding) from the Layer 2
 [IEEE.802.11-2016] UP marking.  This is typically done in the manner
 described in Section 2.4.
 It should be noted that any explicit re-marking policy to be
 performed on such a packet generally takes place at the nearest
 classification and marking policy enforcement point, which may be:
 o  At the wireless AP, and/or

Szigeti, et al. Standards Track [Page 22] RFC 8325 Mapping Diffserv to IEEE 802.11 February 2018

 o  At the wired network switch port, and/or
 o  At the wireless LAN controller
 Note: Multiple classification and marking policy enforcement points
 may exist, as some devices have the capability to re-mark at only
 Layer 2 or Layer 3, while other devices can re-mark at either/both
 layers.
 As such, UP-to-DSCP mapping allows for wireless L2 markings to affect
 the QoS treatment of a packet over the wired IP network (that is,
 until the packet reaches the nearest classification and marking
 policy enforcement point).
 It should be further noted that nowhere in the [IEEE.802.11-2016]
 specification is there an intent expressed for UP markings to be used
 to influence QoS treatment over wired IP networks.  Furthermore,
 [RFC2474], [RFC2475], and [RFC8100] all allow for the host to set
 DSCP markings for end-to-end QoS treatment over IP networks.
 Therefore, wireless APs MUST NOT leverage 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.  But rather, if
 wireless host markings are to be leveraged (as per business
 requirements, technical constraints, and administrative policies),
 then it is RECOMMENDED to pass through the Layer 3 DSCP markings set
 by these wireless hosts instead, as is discussed in the next section.

5.3. Upstream DSCP-Passthrough at the Wireless AP

 It is generally NOT RECOMMENDED to pass through DSCP markings from
 unauthenticated and unauthorized devices, as these are typically
 considered untrusted sources.
 When business requirements and/or technical constraints and/or
 administrative policies require QoS markings to be passed through at
 the wireless edge, then it is RECOMMENDED to pass through Layer 3
 DSCP markings (over Layer 2 [IEEE.802.11-2016] UP markings) in the
 upstream direction, with the exception of CS6 and CS7 (as will be
 discussed further), for the following reasons:
 o  [RFC2474], [RFC2475], and [RFC8100] all allow for hosts to set
    DSCP 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

Szigeti, et al. Standards Track [Page 23] RFC 8325 Mapping Diffserv to IEEE 802.11 February 2018

 o  Most present wireless device operating systems generate UP values
    by the same method as described in Section 2.3 (i.e., by using the
    3 MSBs of the encapsulated 6-bit DSCP); then, at the AP, these
    3-bit markings are converted back into DSCP values, typically in
    the default manner described in Section 2.4; as such, information
    is lost in the translation from a 6-bit marking to a 3-bit marking
    (which is then subsequently translated back to a 6-bit marking);
    passing through the original (encapsulated) DSCP marking prevents
    such loss of information
 o  A practical implementation benefit is also realized by passing
    through the DSCP set by wireless client devices, as enabling
    applications to mark DSCP is much more prevalent and accessible to
    programmers of applications running on wireless device platforms,
    vis-a-vis trying to explicitly set UP values, which requires
    special hooks into the wireless device operating system and/or
    hardware device drivers, many of which do not support such
    functionality
 CS6 and CS7 are exceptions to this passthrough recommendation because
 wireless hosts SHOULD NOT use them (see Section 5.1) and traffic with
 those two markings poses a threat to operation of the wired network
 (see Section 8.2).  CS6 and CS7 SHOULD NOT be passed through to the
 wired network in the upstream direction unless the AP has been
 specifically configured to do that by a network administrator or
 operator.

5.4. Upstream DSCP Marking at the Wireless AP

 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 because the network
 administrator directly enforces the Diffserv policy across the IP
 network (versus an application developer and/or the developer of the
 operating system of the wireless endpoint device, who may be
 functioning completely independently of the network administrator).

6. Overview of IEEE 802.11 QoS

 QoS is enabled on wireless networks by means of the Hybrid
 Coordination Function (HCF).  To give better context to the
 enhancements in HCF that enable QoS, it may be helpful to begin with
 a review of the original Distributed Coordination Function (DCF).

Szigeti, et al. Standards Track [Page 24] RFC 8325 Mapping Diffserv to IEEE 802.11 February 2018

6.1. Distributed Coordination Function (DCF)

 As has been noted, the Wi-Fi medium is a shared medium, with each
 station -- including the wireless AP -- contending for the medium on
 equal terms.  As such, it shares the same challenge as any other
 shared medium in requiring a mechanism to prevent (or avoid)
 collisions, which can occur when two (or more) stations attempt
 simultaneous transmission.
 The IEEE Ethernet Working Group solved this challenge by implementing
 a Carrier Sense Multiple Access/Collision Detection (CSMA/CD)
 mechanism that could detect collisions over the shared physical cable
 (as collisions could be detected as reflected energy pulses over the
 physical wire).  Once a collision was detected, then a predefined set
 of rules was invoked that required stations to back off and wait
 random periods of time before reattempting transmission.  While CSMA/
 CD improved the usage of Ethernet as a shared medium, it should be
 noted the ultimate solution to solving Ethernet collisions was the
 advance of switching technologies, which treated each Ethernet cable
 as a dedicated collision domain.
 However, unlike Ethernet (which uses physical cables), collisions
 cannot be directly detected over the wireless medium, as RF energy is
 radiated over the air and colliding bursts are not necessarily
 reflected back to the transmitting stations.  Therefore, a different
 mechanism is required for this medium.
 As such, the IEEE modified the CSMA/CD mechanism to adapt it to
 wireless networks to provide Carrier Sense Multiple Access/Collision
 Avoidance (CSMA/CA).  The original CSMA/CA mechanism used in IEEE
 802.11 was the Distributed Coordination Function.  DCF is a timer-
 based system that leverages three key sets of timers, the slot time,
 interframe spaces and CWs.

6.1.1. Slot Time

 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
 with the different generations of data rates and performances
 described by [IEEE.802.11-2016].  For example, [IEEE.802.11-2016]
 specifies the slot time to be 20 microseconds ([IEEE.802.11-2016],
 Table 15-5) for legacy implementations (such as IEEE 802.11b,
 supporting 1, 2, 5.5, and 11 Mbps data rates), while newer
 implementations (including IEEE 802.11g, 802.11a, 802.11n, and
 802.11ac, supporting data rates from 6.5 Mbps to over 2 Gbps per
 spatial stream) define a shorter slot time of 9 microseconds
 ([IEEE.802.11-2016], Section 17.4.4, Table 17-21).

Szigeti, et al. Standards Track [Page 25] RFC 8325 Mapping Diffserv to IEEE 802.11 February 2018

6.1.2. Interframe Space (IFS)

 The time interval between frames that are transmitted over the air is
 called the Interframe Space (IFS).  Several IFSs are defined in
 [IEEE.802.11-2016], with the most relevant to DCF being the Short
 Interframe Space (SIFS), the DCF Interframe Space (DIFS), and the
 Extended Interframe Space (EIFS).
 The SIFS is the amount of time in microseconds required for a
 wireless interface to process a received RF signal and its associated
 frame (as specified in [IEEE.802.11-2016]) and to generate a response
 frame.  Like slot times, the SIFS can vary according to the
 performance implementation of [IEEE.802.11-2016].  The SIFS for IEEE
 802.11a, 802.11n, and 802.11ac (in 5 GHz) is 16 microseconds
 ([IEEE.802.11-2016], Section 17.4.4, Table 17-21).
 Additionally, a station must sense the status of the wireless medium
 before transmitting.  If it finds that the medium is continuously
 idle for the duration of a DIFS, then it is permitted to attempt
 transmission of a frame (after waiting an additional random backoff
 period, as will be discussed in the next section).  If the channel is
 found busy during the DIFS interval, the station must defer its
 transmission until the medium is found to be idle for the duration of
 a DIFS interval.  The DIFS is calculated as:
    DIFS = SIFS + (2 * Slot time)
 However, if all stations waited only a fixed amount of time before
 attempting transmission, then collisions would be frequent.  To
 offset 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 transmission.  The range of the generated random backoff
 timer is bounded by the CW.

6.1.3. Contention Window (CW)

 Contention windows bound the range of the generated random backoff
 timer that each station must wait (in addition to the DIFS) before
 attempting transmission.  The initial range is set between 0 and the
 CW minimum value (CWmin), inclusive.  The CWmin for DCF (in 5 GHz) is
 specified as 15 slot times ([IEEE.802.11-2016], Section 17.4.4,
 Table 17-21).
 However, it is possible that two (or more) stations happen to pick
 the exact same random value within this range.  If this happens, then
 a collision may occur.  At this point, the stations effectively begin
 the process again, waiting a DIFS and generate a new random backoff
 value.  However, a key difference is that for this subsequent

Szigeti, et al. Standards Track [Page 26] RFC 8325 Mapping Diffserv to IEEE 802.11 February 2018

 attempt, the CW approximately doubles in size (thus, exponentially
 increasing the range of the random value).  This process repeats as
 often as necessary if collisions continue to occur, until the maximum
 CW size (CWmax) is reached.  The CWmax for DCF is specified as 1023
 slot times ([IEEE.802.11-2016], Section 17.4.4, Table 17-21).
 At this point, transmission attempts may still continue (until some
 other predefined limit is reached), but the CW sizes are fixed at the
 CWmax value.
 Incidentally it may be observed that a significant amount of jitter
 can be introduced by this contention process for wireless
 transmission access.  For example, the incremental transmission delay
 of 1023 slot times (CWmax) using 9-microsecond slot times may be as
 high as 9 ms of jitter per attempt.  And, as previously noted,
 multiple attempts can be made at CWmax.

6.2. Hybrid Coordination Function (HCF)

 Therefore, as can be seen from the preceding description of DCF,
 there is no preferential treatment of one station over another when
 contending for the shared wireless media; nor is there any
 preferential treatment of one type of traffic over another during the
 same contention process.  To support the latter requirement, the IEEE
 enhanced DCF in 2005 to support QoS, specifying HCF in IEEE 802.11,
 which was integrated into the main IEEE 802.11 standard in 2007.

6.2.1. User Priority (UP)

 One of the key changes to the frame format in [IEEE.802.11-2016] is
 the inclusion of a QoS Control field, with 3 bits dedicated for QoS
 markings.  These bits are referred to the User Priority (UP) bits and
 these support eight distinct marking values: 0-7, inclusive.
 While such markings allow for frame differentiation, these alone do
 not directly affect over-the-air treatment.  Rather, it is the
 non-configurable and standard-specified mapping of UP markings to the
 Access Categories (ACs) from [IEEE.802.11-2016] that generate
 differentiated treatment over wireless media.

Szigeti, et al. Standards Track [Page 27] RFC 8325 Mapping Diffserv to IEEE 802.11 February 2018

6.2.2. Access Category (AC)

 Pairs of UP values are mapped to four defined access categories that
 correspondingly specify different treatments of frames over the air.
 These access categories (in order of relative priority from the top
 down) and their corresponding UP mappings are shown in Figure 2
 (adapted from [IEEE.802.11-2016], Section 10.2.4.2, Table 10-1).
              +-----------------------------------------+
              |   User    |   Access   | Designative    |
              | Priority  |  Category  | (informative)  |
              |===========+============+================|
              |     7     |    AC_VO   |     Voice      |
              +-----------+------------+----------------+
              |     6     |    AC_VO   |     Voice      |
              +-----------+------------+----------------+
              |     5     |    AC_VI   |     Video      |
              +-----------+------------+----------------+
              |     4     |    AC_VI   |     Video      |
              +-----------+------------+----------------+
              |     3     |    AC_BE   |   Best Effort  |
              +-----------+------------+----------------+
              |     0     |    AC_BE   |   Best Effort  |
              +-----------+------------+----------------+
              |     2     |    AC_BK   |   Background   |
              +-----------+------------+----------------+
              |     1     |    AC_BK   |   Background   |
              +-----------------------------------------+
                Figure 2: Mappings between IEEE 802.11
                  Access Categories and User Priority
 The manner in which these four access categories achieve
 differentiated service over-the-air is primarily by tuning the fixed
 and random timers that stations have to wait before sending their
 respective types of traffic, as will be discussed next.

Szigeti, et al. Standards Track [Page 28] RFC 8325 Mapping Diffserv to IEEE 802.11 February 2018

6.2.3. Arbitration Interframe Space (AIFS)

 As previously mentioned, each station must wait a fixed amount of
 time to ensure the medium is idle before attempting transmission.
 With DCF, the DIFS is constant for all types of traffic.  However,
 with [IEEE.802.11-2016], the fixed amount of time that a station has
 to wait will depend on the access category and is referred to as an
 Arbitration Interframe Space (AIFS).  AIFSs are defined in slot times
 and the AIFSs per access category are shown in Figure 3 (adapted from
 [IEEE.802.11-2016], Section 9.4.2.29, Table 9-137).
             +-------------------------------------------+
             |   Access   | Designative     |   AIFS     |
             |  Category  | (informative)   |(slot times)|
             |============+=================+============|
             |   AC_VO    |     Voice       |     2      |
             +------------+-----------------+------------+
             |   AC_VI    |     Video       |     2      |
             +------------+-----------------+------------+
             |   AC_BE    |   Best Effort   |     3      |
             +------------+-----------------+------------+
             |   AC_BK    |   Background    |     7      |
             +------------+-----------------+------------+
      Figure 3: Arbitration Interframe Spaces by Access Category

6.2.4. Access Category CWs

 Not only is the fixed amount of time that a station has to wait
 skewed according to its [IEEE.802.11-2016] access category, but so
 are the relative sizes of the CWs that bound the random backoff
 timers, as shown in Figure 4 (adapted from [IEEE.802.11-2016],
 Section 9.4.2.29, Table 9-137).
       +-------------------------------------------------------+
       |   Access  |  Designative    |   CWmin    |   CWmax    |
       |  Category |  (informative)  |(slot times)|(slot times)|
       |===========+=================+============|============|
       |   AC_VO   |     Voice       |     3      |     7      |
       +-----------+-----------------+------------+------------+
       |   AC_VI   |     Video       |     7      |     15     |
       +-----------+-----------------+------------+------------+
       |   AC_BE   |   Best Effort   |     15     |    1023    |
       +-----------+-----------------+------------+------------+
       |   AC_BK   |   Background    |     15     |    1023    |
       +-----------+-----------------+------------+------------+
                 Figure 4: CW Sizes by Access Category

Szigeti, et al. Standards Track [Page 29] RFC 8325 Mapping Diffserv to IEEE 802.11 February 2018

 When the fixed and randomly generated timers are added together on a
 per-access-category basis, then traffic assigned to the Voice Access
 Category (i.e., traffic marked to UP 6 or 7) will receive a
 statistically superior service relative to traffic assigned to the
 Video Access Category (i.e., traffic marked UP 5 and 4), which, in
 turn, will receive a statistically superior service relative to
 traffic assigned to the Best Effort Access Category traffic (i.e.,
 traffic marked UP 3 and 0), which finally will receive a
 statistically superior service relative to traffic assigned to the
 Background Access Category traffic (i.e., traffic marked to UP 2 and
 1).

6.3. IEEE 802.11u QoS Map Set

 IEEE 802.11u [IEEE.802-11u-2011] is an addendum that has now been
 included within the main standard ([IEEE.802.11-2016]), and which
 includes, among other enhancements, a mechanism by which wireless APs
 can communicate DSCP to/from UP mappings that have been configured on
 the wired IP network.  Specifically, a QoS Map Set information
 element (described in [IEEE.802.11-2016], Section 9.4.2.95, and
 commonly referred to as the "QoS Map element") is transmitted from an
 AP to a wireless endpoint device in an association / re-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 QoS constructs (i.e., DSCP) to User Priorities.  One
 intended effect of receiving such a map is for the wireless endpoint
 device (that supports this function and is administratively
 configured to enable it) to perform corresponding DSCP-to-UP mapping
 within the device (i.e., between applications and the operating
 system / wireless network interface hardware drivers) 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 element includes two key components:
 1)  each of the eight UP values (0-7) is associated with a range of
     DSCP values, and
 2)  (up to 21) exceptions from these range-based DSCP to/from UP
     mapping associations may be optionally and explicitly specified.

Szigeti, et al. Standards Track [Page 30] RFC 8325 Mapping Diffserv to IEEE 802.11 February 2018

 In line with the recommendations put forward in this document, the
 following recommendations apply when the QoS Map element is enabled:
 1)  each of the eight UP values (0-7) are RECOMMENDED to be mapped to
     DSCP 0 (as a baseline, so as to meet the recommendation made in
     Section 8.2, and
 2)  (up to 21) exceptions from this baseline mapping are RECOMMENDED
     to be made in line with Section 4.3, to correspond to the
     Diffserv 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 AP 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

 This document has no IANA actions.

8. Security Considerations

 The recommendations in this document concern widely deployed wired
 and wireless network functionality, and, for that reason, do not
 present additional security concerns that do not already exist in
 these networks.  In fact, several of the recommendations made in this
 document serve to protect wired and wireless networks from potential
 abuse, as is discussed further in this section.

8.1. Security Recommendations for General QoS

 It may be possible for a wired or wireless device (which could be
 either a host or a network device) to mark packets (or map packet
 markings) in a manner that interferes with or degrades existing QoS
 policies.  Such marking or mapping may be done intentionally or
 unintentionally by developers and/or users and/or administrators of
 such devices.
 To illustrate: A gaming application designed to run on a smartphone
 or tablet may request that all its packets be marked DSCP EF and/or
 UP 6.  However, if the traffic from such an application is forwarded
 without change over a business network, then this could interfere
 with QoS policies intended to provide priority services for business
 voice applications.

Szigeti, et al. Standards Track [Page 31] RFC 8325 Mapping Diffserv to IEEE 802.11 February 2018

 To mitigate such scenarios, it is RECOMMENDED to implement general
 QoS security measures, including:
 o  Setting a traffic conditioning policy reflective of business
    objectives and policy, such that traffic from authorized users
    and/or applications and/or endpoints will be accepted by the
    network; otherwise, packet markings will be "bleached" (i.e.,
    re-marked to DSCP DF and/or UP 0).  Additionally, Section 5.3 made
    it clear that it is generally NOT RECOMMENDED to pass through DSCP
    markings from unauthorized and/or unauthenticated devices, as
    these are typically considered untrusted sources.  This is
    especially relevant for Internet of Things (IoT) deployments,
    where tens of billions of devices are being connected to IP
    networks with little or no security capabilities, leaving them
    vulnerable to be utilized as agents for DDoS attacks.  These
    attacks can be amplified with preferential QoS treatments, should
    the packet markings of such devices be trusted.
 o  Policing EF marked packet flows, as detailed in [RFC2474],
    Section 7, and [RFC3246], Section 3.
 In addition to these general QoS security recommendations, WLAN-
 specific QoS security recommendations can serve to further mitigate
 attacks and potential network abuse.

8.2. Security Recommendations for WLAN QoS

 The wireless LAN presents a unique DoS attack vector, as endpoint
 devices contend for the shared media on a completely egalitarian
 basis with the network (as represented by the AP).  This means that
 any wireless client could potentially monopolize the air by sending
 packets marked to preferred UP values (i.e., UP values 4-7) in the
 upstream direction.  Similarly, airtime could be monopolized if
 excessive amounts of downstream traffic were marked/mapped to these
 same preferred UP values.  As such, the ability to mark/map to these
 preferred UP values (of UP 4-7) should be controlled.
 If such marking/mapping were not controlled, then, for example, a
 malicious user could cause WLAN DoS by flooding traffic marked CS7
 DSCP downstream.  This codepoint would map by default (as described
 in Section 2.3) to UP 7 and would be assigned to the Voice Access
 Category (AC_VO).  Such a flood could cause Denial-of-Service to not
 only wireless voice applications, but also to all other traffic
 classes.  Similarly, an uninformed application developer may request
 all traffic from his/her application be marked CS7 or CS6, thinking
 this would achieve the best overall servicing of their application
 traffic, while not realizing that such a marking (if honored by the
 client operating system) could cause not only WLAN DoS, but also IP

Szigeti, et al. Standards Track [Page 32] RFC 8325 Mapping Diffserv to IEEE 802.11 February 2018

 network instability, as the traffic marked CS7 or CS6 finds its way
 into queues intended for servicing (relatively low-bandwidth) network
 control protocols, potentially starving legitimate network control
 protocols in the process.
 Therefore, to mitigate such an attack, it is RECOMMENDED that all
 packets marked to Diffserv Codepoints not authorized or explicitly
 provisioned for use over the wireless network by the network
 administrator be mapped to UP 0; this recommendation applies both at
 the AP (in the downstream direction) and within the operating system
 of the wireless endpoint device (in the upstream direction).
 Such a policy of mapping unused codepoints to UP 0 would also prevent
 an attack where non-standard codepoints were used to cause WLAN DoS.
 Consider the case where codepoints are mapped to UP values using a
 range function (e.g., DSCP values 48-55 all map to UP 6), then an
 attacker could flood packets marked, for example, to DSCP 49, in
 either the upstream or downstream direction over the WLAN, causing
 DoS to all other traffic classes in the process.
 In the majority of WLAN deployments, the AP represents not only the
 edge of the Diffserv domain, but also the edge of the network
 infrastructure itself; that is, only wireless client endpoint devices
 are downstream from the AP.  In such a deployment model, CS6 and CS7
 also fall into the category of codepoints that are not in use over
 the wireless LAN (since only wireless client endpoint devices are
 downstream from the AP in this model and these devices do not
 (legitimately) participate in network control protocol exchanges).
 As such, it is RECOMMENDED that CS6 and CS7 DSCP be mapped to UP 0 in
 these Wi-Fi-at-the-edge deployment models.  Otherwise, it would be
 easy for a malicious application developer, or even an inadvertently
 poorly programmed IoT device, to cause WLAN DoS and even wired IP
 network instability by flooding traffic marked CS6 DSCP, which would,
 by default (as described in Section 2.3), be mapped to UP 6, causing
 all other traffic classes on the WLAN to be starved, as well as
 hijacking queues on the wired IP network that are intended for the
 servicing of routing protocols.  To this point, it was also
 recommended in Section 5.1 that packets requesting a marking of CS6
 or CS7 DSCP SHOULD be re-marked to DSCP 0 and mapped to UP 0 by the
 wireless client operating system.
 Finally, 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 of both wired and wireless networks deploying
 QoS include strong device- and/or user-authentication, access-
 control, rate-limiting, control-plane policing, encryption, and other
 techniques; however, the implementation recommendations for such

Szigeti, et al. Standards Track [Page 33] RFC 8325 Mapping Diffserv to IEEE 802.11 February 2018

 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, merits consideration in actual deployments.

9. References

9.1. Normative References

 [IEEE.802.11-2016]
            IEEE, "IEEE Standard for Information technology -
            Telecommunications and information exchange between
            systems - Local and metropolitan area networks - Specific
            requirements - Part 11: Wireless LAN Medium Access Control
            (MAC) and Physical Layer (PHY) Specifications",
            IEEE 802.11, DOI 10.1109/IEEESTD.2016.7786995, December
            2016, <https://standards.ieee.org/findstds/
            standard/802.11-2016.html>.
 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119,
            DOI 10.17487/RFC2119, March 1997,
            <https://www.rfc-editor.org/info/rfc2119>.
 [RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
            "Definition of the Differentiated Services Field (DS
            Field) in the IPv4 and IPv6 Headers", RFC 2474,
            DOI 10.17487/RFC2474, December 1998,
            <https://www.rfc-editor.org/info/rfc2474>.
 [RFC2597]  Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
            "Assured Forwarding PHB Group", RFC 2597,
            DOI 10.17487/RFC2597, June 1999,
            <https://www.rfc-editor.org/info/rfc2597>.
 [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
            of Explicit Congestion Notification (ECN) to IP",
            RFC 3168, DOI 10.17487/RFC3168, September 2001,
            <https://www.rfc-editor.org/info/rfc3168>.
 [RFC3246]  Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,
            J., Courtney, W., Davari, S., Firoiu, V., and D.
            Stiliadis, "An Expedited Forwarding PHB (Per-Hop
            Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002,
            <https://www.rfc-editor.org/info/rfc3246>.

Szigeti, et al. Standards Track [Page 34] RFC 8325 Mapping Diffserv to IEEE 802.11 February 2018

 [RFC3662]  Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort
            Per-Domain Behavior (PDB) for Differentiated Services",
            RFC 3662, DOI 10.17487/RFC3662, December 2003,
            <https://www.rfc-editor.org/info/rfc3662>.
 [RFC4594]  Babiarz, J., Chan, K., and F. Baker, "Configuration
            Guidelines for DiffServ Service Classes", RFC 4594,
            DOI 10.17487/RFC4594, August 2006,
            <https://www.rfc-editor.org/info/rfc4594>.
 [RFC5865]  Baker, F., Polk, J., and M. Dolly, "A Differentiated
            Services Code Point (DSCP) for Capacity-Admitted Traffic",
            RFC 5865, DOI 10.17487/RFC5865, May 2010,
            <https://www.rfc-editor.org/info/rfc5865>.
 [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
            2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
            May 2017, <https://www.rfc-editor.org/info/rfc8174>.

9.2. Informative References

 [GSMA-IPX_Guidelines]
            GSM Association, "Guidelines for IPX Provider networks
            (Previously Inter-Service Provider IP Backbone Guidelines)
            Version 11.0", Official Document IR.34, November 2014,
            <https://www.gsma.com/newsroom/wp-content/uploads/
            IR.34-v11.0.pdf>.
 [IEEE.802-11u-2011]
            IEEE, "IEEE Standard for Information technology -
            Telecommunications and information exchange between
            systems - Local and metropolitan area networks - Specific
            requirements - Part 11: Wireless LAN Medium Access Control
            (MAC) and Physical Layer (PHY) specifications: Amendment
            9: Interworking with External Networks", IEEE 802.11,
            DO 10.1109/IEEESTD.2011.5721908, February 2011,
            <http://standards.ieee.org/getieee802/
            download/802.11u-2011.pdf>.
 [LE-PHB]   Bless, R., "A Lower Effort Per-Hop Behavior (LE PHB)",
            Work in Progress, draft-ietf-tsvwg-le-phb-02, June 2017.
 [RFC2475]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
            and W. Weiss, "An Architecture for Differentiated
            Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
            <https://www.rfc-editor.org/info/rfc2475>.

Szigeti, et al. Standards Track [Page 35] RFC 8325 Mapping Diffserv to IEEE 802.11 February 2018

 [RFC5127]  Chan, K., Babiarz, J., and F. Baker, "Aggregation of
            Diffserv Service Classes", RFC 5127, DOI 10.17487/RFC5127,
            February 2008, <https://www.rfc-editor.org/info/rfc5127>.
 [RFC7561]  Kaippallimalil, J., Pazhyannur, R., and P. Yegani,
            "Mapping Quality of Service (QoS) Procedures of Proxy
            Mobile IPv6 (PMIPv6) and WLAN", RFC 7561,
            DOI 10.17487/RFC7561, June 2015,
            <https://www.rfc-editor.org/info/rfc7561>.
 [RFC8100]  Geib, R., Ed. and D. Black, "Diffserv-Interconnection
            Classes and Practice", RFC 8100, DOI 10.17487/RFC8100,
            March 2017, <https://www.rfc-editor.org/info/rfc8100>.

Szigeti, et al. Standards Track [Page 36] RFC 8325 Mapping Diffserv to IEEE 802.11 February 2018

Acknowledgements

 The authors wish to thank David Black, Gorry Fairhurst, Ruediger
 Geib, Vincent Roca, Brian Carpenter, David Blake, Cullen Jennings,
 David Benham, and the TSVWG.
 The authors also acknowledge a great many inputs, notably from David
 Kloper, Mark Montanez, Glen Lavers, Michael Fingleton, Sarav
 Radhakrishnan, Karthik Dakshinamoorthy, Simone Arena, Ranga Marathe,
 Ramachandra Murthy, and many others.

Authors' Addresses

 Tim Szigeti
 Cisco Systems
 Vancouver, British Columbia  V6K 3L4
 Canada
 Email: szigeti@cisco.com
 Jerome Henry
 Cisco Systems
 Research Triangle Park, North Carolina  27709
 United States of America
 Email: jerhenry@cisco.com
 Fred Baker
 Santa Barbara, California  93117
 United States of America
 Email: FredBaker.IETF@gmail.com

Szigeti, et al. Standards Track [Page 37]

/data/webs/external/dokuwiki/data/pages/rfc/rfc8325.txt · Last modified: 2018/02/14 01:09 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki