idnits 2.17.1 draft-ietf-tsvwg-ieee-802-11-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 27, 2017) is 2458 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 4594' is mentioned on line 643, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.802.11-2016' ** Downref: Normative reference to an Informational RFC: RFC 2475 ** Obsolete normative reference: RFC 3662 (Obsoleted by RFC 8622) ** Downref: Normative reference to an Informational RFC: RFC 4594 ** Downref: Normative reference to an Informational RFC: RFC 5127 ** Downref: Normative reference to an Informational RFC: RFC 8100 == Outdated reference: A later version (-10) exists of draft-ietf-tsvwg-le-phb-02 Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Working Group T. Szigeti 3 Internet-Draft J. Henry 4 Intended status: Standards Track Cisco Systems 5 Expires: January 28, 2018 F. Baker 6 July 27, 2017 8 Diffserv to IEEE 802.11 Mapping 9 draft-ietf-tsvwg-ieee-802-11-05 11 Abstract 13 As internet traffic is increasingly sourced-from and destined-to 14 wireless endpoints, it is crucial that Quality of Service be aligned 15 between wired and wireless networks; however, this is not always the 16 case by default. This document specifies a set Differentiated 17 Services Code Point (DSCP) to IEEE 802.11 User Priority (UP) mappings 18 to reconcile the marking recommendations offered by the IETF and the 19 IEEE so as to maintain consistent QoS treatment between wired and 20 IEEE 802.11 wireless networks. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 28, 2018. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Related work . . . . . . . . . . . . . . . . . . . . . . 3 58 1.2. Interaction with RFC 7561 . . . . . . . . . . . . . . . . 4 59 1.3. Applicability Statement . . . . . . . . . . . . . . . . . 4 60 1.4. Document Organization . . . . . . . . . . . . . . . . . . 5 61 1.5. Requirements Language . . . . . . . . . . . . . . . . . . 5 62 1.6. Terminology Used in this Document . . . . . . . . . . . . 6 63 2. Service Comparison and Default Interoperation of Diffserv and 64 IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 2.1. Diffserv Domain Boundaries . . . . . . . . . . . . . . . 9 66 2.2. Default DSCP-to-UP Mappings and Conflicts . . . . . . . . 10 67 2.3. Default UP-to-DSCP Mappings and Conflicts . . . . . . . . 11 68 3. Wireless Device Marking and Mapping Capability 69 Recommendations . . . . . . . . . . . . . . . . . . . . . . . 12 70 4. DSCP-to-UP Mapping Recommendations . . . . . . . . . . . . . 13 71 4.1. Network Control Traffic . . . . . . . . . . . . . . . . . 13 72 4.1.1. Network Control Protocols . . . . . . . . . . . . . . 14 73 4.1.2. Operations Administration Management (OAM) . . . . . 14 74 4.2. User Traffic . . . . . . . . . . . . . . . . . . . . . . 15 75 4.2.1. Telephony . . . . . . . . . . . . . . . . . . . . . . 15 76 4.2.2. Signaling . . . . . . . . . . . . . . . . . . . . . . 15 77 4.2.3. Multimedia Conferencing . . . . . . . . . . . . . . . 16 78 4.2.4. Real-Time Interactive . . . . . . . . . . . . . . . . 16 79 4.2.5. Multimedia-Streaming . . . . . . . . . . . . . . . . 17 80 4.2.6. Broadcast Video . . . . . . . . . . . . . . . . . . . 17 81 4.2.7. Low-Latency Data . . . . . . . . . . . . . . . . . . 17 82 4.2.8. High-Throughput Data . . . . . . . . . . . . . . . . 18 83 4.2.9. Standard Service Class . . . . . . . . . . . . . . . 18 84 4.2.10. Low-Priority Data . . . . . . . . . . . . . . . . . . 19 85 4.3. DSCP-to-UP Mapping Recommendations Summary . . . . . . . 19 86 5. Upstream Mapping and Marking Recommendations . . . . . . . . 20 87 5.1. Upstream DSCP-to-UP Mapping within the Wireless Client 88 Operating System . . . . . . . . . . . . . . . . . . . . 21 89 5.2. Upstream UP-to-DSCP Mapping at the Wireless Access Point 21 90 5.3. Upstream DSCP-Passthrough at the Wireless Access Point . 22 91 5.4. Upstream DSCP Marking at the Wireless Access Point . . . 23 92 6. Appendix: IEEE 802.11 QoS Overview . . . . . . . . . . . . . 23 93 6.1. Distributed Coordination Function (DCF) . . . . . . . . . 23 94 6.1.1. Slot Time . . . . . . . . . . . . . . . . . . . . . . 24 95 6.1.2. Interframe Spaces . . . . . . . . . . . . . . . . . . 24 96 6.1.3. Contention Windows . . . . . . . . . . . . . . . . . 25 98 6.2. Hybrid Coordination Function (HCF) . . . . . . . . . . . 26 99 6.2.1. User Priority (UP) . . . . . . . . . . . . . . . . . 26 100 6.2.2. Access Category (AC) . . . . . . . . . . . . . . . . 26 101 6.2.3. Arbitration Inter-Frame Space (AIFS) . . . . . . . . 27 102 6.2.4. Access Category Contention Windows (CW) . . . . . . . 28 103 6.3. IEEE 802.11u QoS Map Set . . . . . . . . . . . . . . . . 29 104 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 105 8. Security Considerations . . . . . . . . . . . . . . . . . . . 30 106 8.1. General QoS Security Recommendations . . . . . . . . . . 30 107 8.2. WLAN QoS Security Recommendations . . . . . . . . . . . . 31 108 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 109 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 110 10.1. Normative References . . . . . . . . . . . . . . . . . . 33 111 10.2. Informative References . . . . . . . . . . . . . . . . . 34 112 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 35 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 115 1. Introduction 117 Wireless has become the preferred medium for endpoints connecting to 118 business and private networks. However, the wireless medium defined 119 by IEEE 802.11 [IEEE.802.11-2016] presents several design challenges 120 for ensuring end-to-end quality of service. Some of these challenges 121 relate to the nature of the IEEE 802.11 RF medium itself, being a 122 half-duplex and shared medium, while other challenges relate to the 123 fact that the IEEE 802.11 standard is not administered by the same 124 standards body as IP networking standards. While the IEEE has 125 developed tools to enable QoS over wireless networks, little guidance 126 exists on how to maintain consistency of QoS treatment between wired 127 IP and wireless IEEE 802.11 networks. The purpose of this document 128 is to provide such guidance. 130 1.1. Related work 132 Several RFCs outline Diffserv QoS recommendations over IP networks, 133 including: 135 o [RFC2474] specifies the Diffserv Codepoint Field. This RFC also 136 details Class Selectors, as well as the Default Forwarding (DF) 137 treatment. 139 o [RFC2475] defines a Diffserv architecture 141 o [RFC3246] specifies the Expedited Forwarding (EF) Per-Hop Behavior 142 (PHB) 144 o [RFC2597] specifies the Assured Forwarding (AF) PHB. 146 o [RFC3662] specifies a Lower Effort Per-Domain Behavior (PDB) 148 o [RFC4594] presents Configuration Guidelines for Diffserv Service 149 Classes 151 o [RFC5127] presents the Aggregation of Diffserv Service Classes 153 o [RFC5865] specifies a DSCP for Capacity Admitted Traffic 155 Note: [RFC4594] is intended to be viewed as a framework for 156 supporting Diffserv in any network, including wireless networks; 157 thus, it describes different types of traffic expected in IP networks 158 and provides guidance as to what DSCP marking(s) should be associated 159 with each traffic type. As such, this document draws heavily on 160 [RFC4594], as well as [RFC5127], and [RFC8100]. 162 In turn, the relevant standard for wireless QoS is IEEE 802.11, which 163 is being progressively updated; the current version of which (at the 164 time of writing) is [IEEE.802.11-2016]. 166 1.2. Interaction with RFC 7561 168 There is also a recommendation from the Global System for Mobile 169 Communications Association (GSMA), specifically their Mapping Quality 170 of Service (QoS) Procedures of Proxy Mobile IPv6 (PMIPv6) and WLAN 171 [RFC7561] specification. This GSMA specification was developed 172 without reference to existing IETF specifications for various 173 services, referenced in Section 1.1. Thus, [RFC7561] conflicts with 174 the overall Diffserv traffic-conditioning service plan, both in the 175 services specified and the code points specified for them. As such, 176 these two plans cannot be normalized. Rather, as discussed in 177 [RFC2474] Section 2, the two domains (IEEE 802.11 and GSMA) are 178 different Differentiated Services Domains separated by a 179 Differentiated Services Boundary. At that boundary, code points from 180 one domain are translated to code points for the other, and maybe to 181 Default (zero) if there is no corresponding service to translate to. 183 1.3. Applicability Statement 185 This document is applicable to the use of Differentiated Services 186 that interconnect with IEEE 802.11 wireless LANs (referred to as Wi- 187 Fi, throughout this document, for simplicity). These guidelines are 188 applicable whether the wireless access points (APs) are deployed in 189 an autonomous manner, managed by (centralized or distributed) WLAN 190 controllers or some hybrid deployment option. This is because in all 191 these cases, the wireless access point is the bridge between wired 192 and wireless media. 194 This document applies to IP networks using WiFi infrastructure at the 195 link layer. Such networks typically include wired LANs with wireless 196 access points at their edges, however, such networks can also include 197 Wi-Fi backhaul, wireless mesh solutions or any other type of AP-to-AP 198 wireless network that extends the wired network infrastructure. 200 1.4. Document Organization 202 This document is organized as follows: 204 o Section 1 introduces the wired-to-wireless QoS challenge, 205 references related work, outlines the organization of the 206 document, and specifies both the requirements language and the 207 terminology used in this document. 209 o Section 2 begins the discussion with a comparison of IETF Diffserv 210 QoS and Wi-Fi QoS standards and highlights discrepancies between 211 these that require reconciliation. 213 o Section 3 presents the marking and mapping capabilities that 214 wireless access points and wireless endpoint devices are 215 recommended to support. 217 o Section 4 presents DSCP-to-UP mapping recommendations for each of 218 the [RFC4594] service classes, which are primarily applicable in 219 the downstream (wired-to-wireless) direction. 221 o Section 5, in turn, considers upstream (wireless-to-wired) QoS 222 options, their respective merits and recommendations. 224 o Section 6 (in the form of an Appendix) presents a brief overview 225 of how QoS is achieved over IEEE 802.11 wireless networks, given 226 the shared, half-duplex nature of the wireless medium. 228 o Section 7 on notes IANA considerations 230 o Section 8 presents security considerations relative to DSCP-to-UP, 231 UP-to-DSCP mapping and remarking 233 1.5. Requirements Language 235 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 236 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL", and "NOT 237 RECOMMENDED" in this document are to be interpreted as described in 238 [RFC2119]. 240 1.6. Terminology Used in this Document 242 Key terminology used in this document includes: 244 AC: Access Category. A label for the common set of enhanced 245 distributed channel access (EDCA) parameters that are used by a 246 quality-of-service (QoS) station (STA) to contend for the channel 247 in order to transmit medium access control (MAC) service data 248 units (MSDUs) with certain priorities. [IEEE.802.11-2016] 249 Section 3.2. 251 AIFS: Arbitration Interframe Space. Interframe space used by QoS 252 stations before transmission of data and other frame types defined 253 by [IEEE.802.11-2016] Section 10.3.2.3.6. 255 AP: Access Point. An entity that contains one station (STA) and 256 provides access to the distribution services, via the wireless 257 medium (WM) for associated STAs. An AP comprises a STA and a 258 distribution system access function (DSAF) [IEEE.802.11-2016] 259 Section 3.1. 261 BSS: Basic Service Set. Informally, a wireless cell; formally, a 262 set of stations that have successfully synchronized using the JOIN 263 service primitives and one STA that has used the START primitive. 264 Alternatively, a set of STAs that have used the START primitive 265 specifying matching mesh profiles where the match of the mesh 266 profiles has been verified via the scanning procedure. Membership 267 in a BSS does not imply that wireless communication with all other 268 members of the BSS is possible. Defined in [IEEE.802.11-2016] 269 Section 3.1. 271 Contention Window: See CW. 273 CSMA/CA: Carrier Sense Multiple Access with Collision Avoidance. 274 A media access control method in which carrier sensing is used, 275 but nodes attempt to avoid collisions by transmitting only when 276 the channel is sensed to be "idle". When these do transmit, nodes 277 transmit their packet data in its entirety. 279 CSMA/CD: Carrier Sense Multiple Access with Collision Detection. 280 A media access control method (used most notably in early Ethernet 281 technology) for local area networking. It uses a carrier-sensing 282 scheme in which a transmitting station detects collisions by 283 sensing transmissions from other stations while transmitting a 284 frame. When this collision condition is detected, the station 285 stops transmitting that frame, transmits a jam signal, and then 286 waits for a random time interval before trying to resend the 287 frame. 289 CW: Contention Window. Limits a CWMin and CWMax, from which a 290 random backoff is computed. 292 CWMax: Contention Window Maximum. The maximum value (in unit of 293 Slot Time) that a contention window can take. 295 CWMin: Contention Window Minimum. The minimum value that a 296 contention window can take. 298 DCF: Distributed Coordinated Function. A class of coordination 299 function where the same coordination function logic is active in 300 every station (STA) in the basic service set (BSS) whenever the 301 network is in operation. 303 DIFS: Distributed (Coordination Function) Interframe Space. A 304 unit of time during which the medium has to be detected as idle 305 before a station should attempt to send frames, as per 306 [IEEE.802.11-2016] Section 10.3.2.3.5. 308 DSCP: Differentiated Service Code Point [RFC2474] and [RFC2475]. 309 The DSCP is carried in the first 6 bits of the IPv4 and IPv6 Type 310 of Service (TOS) Byte (the remaining 2 bits are used for IP 311 Explicit Congestion Notification [RFC3168]). 313 HCF: Hybrid Coordination Function A coordination function that 314 combines and enhances aspects of the contention based and 315 contention free access methods to provide quality-of-service (QoS) 316 stations (STAs) with prioritized and parameterized QoS access to 317 the wireless medium (WM), while continuing to support non-QoS STAs 318 for best-effort transfer. [IEEE.802.11-2016] Section 3.1. 320 IFS: Interframe Space. Period of silence between transmissions 321 over 802.11 networks. [IEEE.802.11-2016] describes several types 322 of Interframe Spaces. 324 Random Backoff Timer: A pseudorandom integer period of time (in 325 units of Slot Time) over the interval (0,CW), where CWmin is-less- 326 than-or-equal-to CW, which in turn is less-than-or-equal-to CWMax. 327 Stations desiring to initiate transfer of data frames and-or 328 Management frames using the DCF shall invoke the carrier sense 329 mechanism to determine the busy-or-idle state of the medium. If 330 the medium is busy, the STA shall defer until the medium is 331 determined to be idle without interruption for a period of time 332 equal to DIFS when the last frame detected on the medium was 333 received correctly, or after the medium is determined to be idle 334 without interruption for a period of time equal to EIFS when the 335 last frame detected on the medium was not received correctly. 336 After this DIFS or EIFS medium idle time, the STA shall then 337 generate a random backoff period for an additional deferral time 338 before transmitting. [IEEE.802.11-2016] Section 10.3.3. 340 RF: Radio Frequency. 342 SIFS: Short Interframe Space. An IFS used before transmission of 343 specific frames as defined in [IEEE.802.11-2016] 344 Section 10.3.2.3.3. 346 Slot Time: A unit of time used to count time intervals in 802.11 347 networks, and defined in [IEEE.802.11-2016] Section 10.3.2.13. 349 Trust: From a QoS-perspective, trust refers to the accepting of 350 the QoS markings of a packet by a network device. Trust is 351 typically extended at Layer 3 (by accepting the DSCP), but may 352 also be extended at lower layers, such as at Layer 2 by accepting 353 User Priority markings. For example, if an access point is 354 configured to trust DSCP markings and it receives a packet marked 355 EF, then it would treat the packet with the Expedite Forwarding 356 PHB and propagate the EF marking value (DSCP 46) as it transmits 357 the packet. Alternatively, if a network device is configured to 358 operate in an untrusted manner, then it would remark packets as 359 these entered the device, typically to DF (or to a different 360 marking value at the network administrator's preference). Note: 361 The terms "trusted" and "untrusted" are used extensively in RFC 362 4594. 364 UP: User Priority. A value associated with a medium access 365 control (MAC) service data unit (MSDU) that indicates how the MSDU 366 is to be handled. The UP is assigned to an MSDU in the layers 367 above the MAC [IEEE.802.11-2016] Section 3.1. The UP defines a 368 level of priority for the associated frame, on a scale of 0 to 7. 370 Wi-Fi: An interoperability certification defined by the Wi-Fi 371 Alliance. However, this term is commonly used, including in the 372 present document, to be the equivalent of IEEE 802.11. 374 2. Service Comparison and Default Interoperation of Diffserv and IEEE 375 802.11 377 (Section 6 provides a brief overview of IEEE 802.11 QoS.) 379 The following comparisons between IEEE 802.11 and Diffserv services 380 should be noted: 382 o [IEEE.802.11-2016] does not support an EF PHB service [RFC3246], 383 as it is not possible to assure that a given access category will 384 be serviced with strict priority over another (due to the random 385 element within the contention process) 387 o [IEEE.802.11-2016] does not support an AF PHB service [RFC2597], 388 again because it is not possible to assure that a given access 389 category will be serviced with a minimum amount of assured 390 bandwidth (due to the non-deterministic nature of the contention 391 process) 393 o [IEEE.802.11-2016] loosely supports a [RFC2474] Default Forwarding 394 service via the Best Effort Access Category (AC_BE) 396 o [IEEE.802.11-2016] loosely supports a [RFC3662] Lower Effort PDB 397 service via the Background Access Category (AC_BK) 399 As such, these high-level considerations should be kept in mind when 400 mapping from Diffserv to [IEEE.802.11-2016] (and vice-versa); 401 however, access points may or may not always be positioned at 402 Diffserv domain boundaries, as will be discussed next. 404 2.1. Diffserv Domain Boundaries 406 It is important to recognize that the wired-to-wireless edge may or 407 may not function as an edge of a Diffserv domain or a domain 408 boundary. 410 In most commonly-deployed WLAN models, the wireless access point 411 represents not only the edge of the Diffserv domain, but also the 412 edge of the network infrastructure itself. As such, only client 413 endpoint devices (and no network infrastructure devices) are 414 downstream from the access points in these deployment models. Note: 415 security considerations and recommendations for hardening such Wifi- 416 at-the-edge deployment models are detailed in Section 8; these 417 recommendations include mapping network control protocols (which are 418 not used downstream from the AP in this deployment model) to UP 0. 420 Alternatively, in other deployment models, such as Wi-Fi backhaul, 421 wireless mesh infrastructures, wireless AP-to-AP deployments, or in 422 cases where a Wi-Fi link connects to a device providing service via 423 another technology (e.g. Wi-Fi to Bluetooth or Zigbee router), the 424 wireless access point extends the network infrastructure and thus, 425 typically, the Diffserv domain. In such deployments, both client 426 devices and infrastructure devices may be expected downstream from 427 the access points, and as such network control protocols are 428 recommended to be mapped to UP 7 in this deployment model, as is 429 discussed in Section 4.1.1. 431 Thus, as can be seen from these two examples, the QoS treatment of 432 packets at the access point will depend on the position of the AP in 433 the network infrastructure and on the WLAN deployment model. 435 However, regardless of the access point being at the Diffserv 436 boundary or not, Diffserv to [IEEE.802.11-2016] (and vice-versa) 437 marking-specific incompatibilities exist that must be reconciled, as 438 will be discussed next. 440 2.2. Default DSCP-to-UP Mappings and Conflicts 442 While no explicit guidance is offered in mapping (6-Bit) Layer 3 DSCP 443 values to (3-Bit) Layer 2 markings (such as IEEE 802.1D, 802.1p or 444 802.11e), a common practice in the networking industry is to map 445 these by what we will refer to as 'Default DSCP-to-UP Mapping' (for 446 lack of a better term), wherein the 3 Most Significant Bits (MSB) of 447 the DSCP are used as the corresponding L2 markings. 449 Note: There are mappings provided in [IEEE.802.11-2016] Annex V 450 Tables V-1 and V2, but it bears mentioning that these mappings are 451 provided as examples (as opposed to explicit recommendations). 452 Furthermore, some of these mappings do not align with the intent and 453 recommendations expressed in [RFC4594], as will be discussed in this 454 and the following section (Section 2.3). 456 However, when this default DSCP-to-UP mapping method is applied to 457 packets marked per [RFC4594] recommendations and destined to 802.11 458 WLAN clients, it will yield a number of inconsistent QoS mappings, 459 specifically: 461 o Voice (EF-101110) will be mapped to UP 5 (101), and treated in the 462 Video Access Category (AC_VI), rather than the Voice Access 463 Category (AC_VO), for which it is intended 465 o Multimedia Streaming (AF3-011xx0) will be mapped to UP3 (011) and 466 treated in the Best Effort Access Category (AC_BE), rather than 467 the Video Access Category (AC_VI), for which it is intended 469 o Broadcast Video (CS3-011000) will be mapped to UP3 (011) and 470 treated in the Best Effort Access Category (AC_BE), rather than 471 the Video Access Category (AC_VI), for which it is intended 473 o OAM traffic (CS2-010000) will be mapped to UP 2 (010) and treated 474 in the Background Access Category (AC_BK), which is not the intent 475 expressed in [RFC4594] for this service class 477 It should also be noted that while [IEEE.802.11-2016] defines an 478 intended use for each access category through the AC naming 479 convention (for example, UP 6 and UP 7 belong to AC_VO, the Voice 480 Access Category), [IEEE.802.11-2016] does not: 482 o define how upper layer markings (such as DSCP) should map to UPs 483 (and hence to ACs) 485 o define how UPs should translate to other medium Layer 2 QoS 486 markings 488 o strictly restrict each access category to applications reflected 489 in the AC name 491 2.3. Default UP-to-DSCP Mappings and Conflicts 493 In the opposite direction of flow (the upstream direction, that is, 494 from wireless-to-wired), many APs use what we will refer to as 495 'Default UP-to-DSCP Mapping' (for lack of a better term), wherein 496 DSCP values are derived from UP values by multiplying the UP values 497 by 8 (i.e. shifting the 3 UP bits to the left and adding three 498 additional zeros to generate a DSCP value). This derived DSCP value 499 is then used for QoS treatment between the wireless access point and 500 the nearest classification and marking policy enforcement point 501 (which may be the centralized wireless LAN controller, relatively 502 deep within the network). Alternatively, in the case where there is 503 no other classification and marking policy enforcement point, then 504 this derived DSCP value will be used on the remainder of the Internet 505 path. 507 It goes without saying that when 6 bits of marking granularity are 508 derived from 3, then information is lost in translation. Servicing 509 differentiation cannot be made for 12 classes of traffic (as 510 recommended in [RFC4594]), but for only 8 (with one of these classes 511 being reserved for future use (i.e. UP 7 which maps to DSCP CS7). 513 Such default upstream mapping can also yield several inconsistencies 514 with [RFC4594], including: 516 o Mapping UP 6 ([RFC4594] Voice) to CS6, which [RFC4594] recommends 517 for Network Control 519 o Mapping UP 4 ([RFC4594] Multimedia Conferencing and/or Real-Time 520 Interactive) to CS4, thus losing the ability to differentiate 521 between these two distinct service classes, as recommended in 522 [RFC4594] Sections 4.3 and 4.4 524 o Mapping UP 3 ([RFC4594] Multimedia Streaming and/or Broadcast 525 Video) to CS3, thus losing the ability to differentiate between 526 these two distinct service classes, as recommended in [RFC4594] 527 Sections 4.5 and 4.6 529 o Mapping UP 2 ([RFC4594] Low-Latency Data and/or OAM) to CS2, thus 530 losing the ability to differentiate between these two distinct 531 service classes, as recommended in [RFC4594] Sections 4.7 and 3.3, 532 and possibly overwhelming the queues provisioned for OAM (which is 533 typically lower in capacity [being network control traffic], as 534 compared to Low-Latency Data queues [being user traffic]) 536 o Mapping UP 1 ([RFC4594] High-Throughput Data and/or Low-Priority 537 Data) to CS1, thus losing the ability to differentiate between 538 these two distinct service classes, as recommended in [RFC4594] 539 Sections 4.8 and 4.10, and causing legitimate business-relevant 540 High-Throughput Data to receive a [RFC3662] Lower Effort PDB, for 541 which it is not intended 543 The following sections address these limitations and concerns in 544 order to reconcile [RFC4594] and [IEEE.802.11-2016]. First 545 downstream (wired-to-wireless) DSCP-to-UP mappings will be aligned 546 and then upstream (wireless-to-wired) models will be addressed. 548 3. Wireless Device Marking and Mapping Capability Recommendations 550 This document assumes and RECOMMENDS that all wireless access points 551 (as the bridges between wired-and-wireless networks) support the 552 ability to: 554 o mark DSCP, per Diffserv standards 556 o mark UP, per the [IEEE.802.11-2016] standard 558 o support fully-configurable mappings between DSCP and UP 560 o process DSCP markings set by wireless endpoint devices 562 This document further assumes and RECOMMENDS that all wireless 563 endpoint devices support the ability to: 565 o mark DSCP, per Diffserv standards 567 o mark UP, per the [IEEE.802.11-2016] standard 569 o support fully-configurable mappings between DSCP (set by 570 applications in software) and UP (set by the operating system and/ 571 or wireless network interface hardware drivers) 573 Having made the assumptions and recommendations above, it bears 574 mentioning while the mappings presented in this document are 575 RECOMMENDED to replace the current common default practices (as 576 discussed in Section 2.2 and Section 2.3), these mapping 577 recommendations are not expected to fit every last deployment model, 578 and as such MAY be overridden by network administrators, as needed. 580 4. DSCP-to-UP Mapping Recommendations 582 The following section specifies downstream (wired-to-wireless) 583 mappings between [RFC4594] Configuration Guidelines for Diffserv 584 Service Classes and [IEEE.802.11-2016]. As such, this section draws 585 heavily from [RFC4594], including service class definitions and 586 recommendations. 588 This section assumes [IEEE.802.11-2016] wireless access points and/or 589 WLAN controllers that support customizable, non-default DSCP-to-UP 590 mapping schemes. 592 This section also assumes that [IEEE.802.11-2016] access points and 593 endpoint devices differentiate UP markings with corresponding queuing 594 and dequeuing treatments. To illustrate, [IEEE.802.11-2016] displays 595 a reference implementation model in Figure 10-24 which depicts four 596 transmit queues, one per access category. In practical 597 implementations, however, it is common for WLAN network equipment 598 vendors to implement dedicated transmit queues on a per-UP (versus a 599 per access category) basis, which are then dequeued into their 600 associated access category in a preferred (or even in a strict 601 priority manner). For example, it is common for vendors to dequeue 602 UP 5 ahead of UP 4 to the hardware performing the EDCA function 603 (EDCAF) for the Video Access Category (AC_VI). As such, Signaling 604 traffic (marked UP 5, per the recommendations made in Section 4.2.2) 605 may benefit from such a treatment versus other video flows in the 606 same access category which are marked to UP 4 (in addition to a 607 preferred treatment over flows in the Best Effort and Background 608 access categories). 610 4.1. Network Control Traffic 612 Network control traffic is defined as packet flows that are essential 613 for stable operation of the administered network [RFC4594] Section 3. 614 Network control traffic is different from user application control 615 (signaling) that may be generated by some applications or services. 616 Network control traffic MAY be split into two service classes: 618 o Network Control, and 620 o Operations Administration and Management (OAM) 622 4.1.1. Network Control Protocols 624 The Network Control service class is used for transmitting packets 625 between network devices (e.g. routers) that require control (routing) 626 information to be exchanged between nodes within the administrative 627 domain, as well as across a peering point between different 628 administrative domains. 630 The RECOMMENDED DSCP marking for Network Control is CS6, per 631 [RFC4594] Section 3.2; additionally, CS7 DSCP value SHOULD be 632 reserved for future use, potentially for future routing or control 633 protocols, again, per [RFC4594] Section 3.2. 635 By default (as described in Section 2.2), packets marked DSCP CS7 636 will be mapped to UP 7 and serviced within the Voice Access Category 637 (AC_VO). This represents the RECOMMENDED mapping for CS7, that is, 638 packets marked to CS7 DSCP are RECOMMENDED to be mapped to UP 7. 640 However, by default (as described in Section 2.2), packets marked 641 DSCP CS6 will be mapped to UP 6 and serviced within the Voice Access 642 Category (AC_VO); such mapping and servicing is a contradiction to 643 the intent expressed in [RFC 4594] section 3.2. As such, it is 644 RECOMMENDED to map Network Control traffic marked CS6 to UP 7 (per 645 [IEEE.802.11-2016] Section 10.2.4.2, Table 10-1), thereby admitting 646 it to the Voice Access Category (AC_VO), albeit with a marking 647 distinguishing it from (data-plane) voice traffic. 649 It should be noted that encapsulated routing protocols for 650 encapsulated or overlay networks (e.g., VPN, NVO3) are not network 651 control traffic for any physical network at the AP, and hence SHOULD 652 NOT be marked with CS6 in the first place. 654 Addtionally, and as previously noted, the Security Considerations 655 section (Section 8) contains additional recommendations for hardening 656 Wifi-at-the-edge deployment models, where, for example, network 657 control protocols are not expected to be sent nor recevied between 658 APs and downstream endpoint client devices. 660 4.1.2. Operations Administration Management (OAM) 662 The OAM (Operations, Administration, and Management) service class is 663 RECOMMENDED for OAM&P (Operations, Administration, and Management and 664 Provisioning). The RECOMMENDED DSCP marking for OAM is CS2, per 665 [RFC4594] Section 3.3. 667 By default (as described in Section 2.2), packets marked DSCP CS2 668 will be mapped to UP 2 and serviced with the Background Access 669 Category (AC_BK). Such servicing is a contradiction to the intent 670 expressed in [RFC4594] Section 3.3. As such, it is RECOMMENDED that 671 a non-default mapping be applied to OAM traffic, such that CS2 DSCP 672 is mapped to UP 0, thereby admitting it to the Best Effort Access 673 Category (AC_BE). 675 4.2. User Traffic 677 User traffic is defined as packet flows between different users or 678 subscribers. It is the traffic that is sent to or from end-terminals 679 and that supports a very wide variety of applications and services 680 [RFC4594] Section 4. 682 Network administrators can categorize their applications according to 683 the type of behavior that they require and MAY choose to support all 684 or a subset of the defined service classes. 686 4.2.1. Telephony 688 The Telephony service class is RECOMMENDED for applications that 689 require real-time, very low delay, very low jitter, and very low 690 packet loss for relatively constant-rate traffic sources (inelastic 691 traffic sources). This service class SHOULD be used for IP telephony 692 service. The fundamental service offered to traffic in the Telephony 693 service class is minimum jitter, delay, and packet loss service up to 694 a specified upper bound. The RECOMMENDED DSCP marking for Telephony 695 is EF ([RFC4594] Section 4.1). 697 Traffic marked to DSCP EF will map by default (as described in 698 Section 2.2) to UP 5, and thus to the Video Access Category (AC_VI), 699 rather than to the Voice Access Category (AC_VO), for which it is 700 intended. Therefore, a non-default DSCP-to-UP mapping is 701 RECOMMENDED, such that EF DSCP is mapped to UP 6, thereby admitting 702 it into the Voice Access Category (AC_VO). 704 Similarly, the [RFC5865] VOICE-ADMIT DSCP (44/101100) is RECOMMENDED 705 to be mapped to UP 6, thereby admitting it also into the Voice Access 706 Category (AC_VO). 708 4.2.2. Signaling 710 The Signaling service class is RECOMMENDED for delay-sensitive 711 client-server (e.g. traditional telephony) and peer-to-peer 712 application signaling. Telephony signaling includes signaling 713 between IP phone and soft-switch, soft-client and soft-switch, and 714 media gateway and soft-switch as well as peer-to-peer using various 715 protocols. This service class is intended to be used for control of 716 sessions and applications. The RECOMMENDED DSCP marking for 717 Signaling is CS5 ([RFC4594] Section 4.2). 719 While Signaling is RECOMMENDED to receive a superior level of service 720 relative to the default class (i.e. AC_BE), it does not require the 721 highest level of service (i.e. AC_VO). This leaves only the Video 722 Access Category (AC_VI), which it will map to by default (as 723 described in Section 2.2). Therefore it is RECOMMENDED to map 724 Signaling traffic marked CS5 DSCP to UP 5, thereby admitting it to 725 the Video Access Category (AC_VI). 727 Note: Signaling traffic is not control plane traffic from the 728 perspective of the network (but rather is data plane traffic); as 729 such, it does not merit provisioning in the Network Control service 730 class (marked CS6 and mapped to UP 6). However, Signaling traffic is 731 control-plane traffic from the perspective of the voice/video 732 telephony overlay-infrastructure. As such, Signaling should be 733 treated with preferential servicing vs. other data plane flows. One 734 way this may be achieved in certain WLAN deployments is by mapping 735 Signaling traffic marked CS5 to UP 5 (as recommended above and 736 following the EDCAF treatment logic described in Section 4. 738 4.2.3. Multimedia Conferencing 740 The Multimedia Conferencing service class is RECOMMENDED for 741 applications that require real-time service for rate-adaptive 742 traffic. The RECOMMENDED DSCP markings for Multimedia Conferencing 743 are AF41, AF42 and AF43 ([RFC4594] Section 4.3). 745 The primary media type typically carried within the Multimedia 746 Conferencing service class is video; as such, it is RECOMMENDED to 747 map this class into the Video Access Category, which it does by 748 default (as described in Section 2.2). Specifically, it is 749 RECOMMENDED to map AF41, AF42 and AF43 to UP 4, thereby admitting 750 Multimedia Conferencing into the Video Access Category (AC_VI). 752 4.2.4. Real-Time Interactive 754 The Real-Time Interactive service class is RECOMMENDED for 755 applications that require low loss and jitter and very low delay for 756 variable rate inelastic traffic sources. Such applications may 757 include inelastic video-conferencing applications, but may also 758 include gaming applications (as pointed out in [RFC4594] Sections 2.1 759 through 2.3, and Section 4.4). The RECOMMENDED DSCP marking for 760 Real-Time Interactive traffic is CS4 ([RFC4594] Section 4.4). 762 The primary media type typically carried within the Real-Time 763 Interactive service class is video; as such, it is RECOMMENDED to map 764 this class into the Video Access Category, which it does by default 765 (as described in Section 2.2). Specifically, it is RECOMMENDED to 766 map CS4 to UP 4, thereby admitting Real-Time Interactive traffic into 767 the Video Access Category (AC_VI). 769 4.2.5. Multimedia-Streaming 771 The Multimedia Streaming service class is RECOMMENDED for 772 applications that require near-real-time packet forwarding of 773 variable rate elastic traffic sources. Typically these flows are 774 unidirectional. The RECOMMENDED DSCP markings for Multimedia 775 Streaming are AF31, AF32 and AF33 ([RFC4594] Section 4.5). 777 The primary media type typically carried within the Multimedia 778 Streaming service class is video; as such, it is RECOMMENDED to map 779 this class into the Video Access Category, which it will by default 780 (as described in Section 2.2). Specifically, it is RECOMMENDED to 781 map AF31, AF32 and AF33 to UP 4, thereby admitting Multimedia 782 Streaming into the Video Access Category (AC_VI). 784 4.2.6. Broadcast Video 786 The Broadcast Video service class is RECOMMENDED for applications 787 that require near-real-time packet forwarding with very low packet 788 loss of constant rate and variable rate inelastic traffic sources. 789 Typically these flows are unidirectional. The RECOMMENDED DSCP 790 marking for Broadcast Video is CS3 ([RFC4594] Section 4.6). 792 As directly implied by the name, the primary media type typically 793 carried within the Broadcast Video service class is video; as such, 794 it is RECOMMENDED to map this class into the Video Access Category; 795 however, by default (as described in Section 2.2), this service class 796 will map to UP 3, and thus the Best Effort Access Category (AC_BE). 797 Therefore, a non-default mapping is RECOMMENDED, such that CS4 maps 798 to UP 4, thereby admitting Broadcast Video into the Video Access 799 Category (AC_VI). 801 4.2.7. Low-Latency Data 803 The Low-Latency Data service class is RECOMMENDED for elastic and 804 time-sensitive data applications, often of a transactional nature, 805 where a user is waiting for a response via the network in order to 806 continue with a task at hand. As such, these flows are considered 807 foreground traffic, with delays or drops to such traffic directly 808 impacting user-productivity. The RECOMMENDED DSCP markings for Low- 809 Latency Data are AF21, AF22 and AF23 ([RFC4594] Section 4.7). 811 By default (as described in Section 2.2), Low-Latency Data will map 812 to UP 2 and thus to the Background Access Category (AC_BK), which is 813 contrary to the intent expressed in [RFC4594]. 815 In line with the assumption made in Section 4, mapping Low-Latency 816 Data to UP 3 may allow such to receive a superior level of service 817 via transmit queues servicing the EDCAF hardware for the Best Effort 818 Access Category (AC_BE). Therefore it is RECOMMENDED to map Low- 819 Latency Data traffic marked AF2x DSCP to UP 3, thereby admitting it 820 to the Best Effort Access Category (AC_BE). 822 4.2.8. High-Throughput Data 824 The High-Throughput Data service class is RECOMMENDED for elastic 825 applications that require timely packet forwarding of variable rate 826 traffic sources and, more specifically, is configured to provide 827 efficient, yet constrained (when necessary) throughput for TCP 828 longer-lived flows. These flows are typically non-user-interactive. 829 Per [RFC4594]-Section 4.8, it can be assumed that this class will 830 consume any available bandwidth and that packets traversing congested 831 links may experience higher queuing delays or packet loss. It is 832 also assumed that this traffic is elastic and responds dynamically to 833 packet loss. The RECOMMENDED DSCP markings for High-Throughput Data 834 are AF11, AF12 and AF13 ([RFC4594] Section 4.8). 836 By default (as described in Section 2.2), High-Throughput Data will 837 map to UP 1 and thus to the Background Access Category (AC_BK), which 838 is contrary to the intent expressed in [RFC4594]. 840 Unfortunately, there really is no corresponding fit for the High- 841 Throughput Data service class within the constrained 4 Access 842 Category [IEEE.802.11-2016] model. If the High-Throughput Data 843 service class is assigned to the Best Effort Access Category (AC_BE), 844 then it would contend with Low-Latency Data (while [RFC4594] 845 recommends a distinction in servicing between these service classes) 846 as well as with the default service class; alternatively, if it is 847 assigned to the Background Access Category (AC_BK), then it would 848 receive a less-then-best-effort service and contend with Low-Priority 849 Data (as discussed in Section 4.2.10). 851 As such, since there is no directly corresponding fit for the High- 852 Throughout Data service class within the [IEEE.802.11-2016] model, it 853 is generally RECOMMENDED to map High-Throughput Data to UP 0, thereby 854 admitting it to the Best Effort Access Category (AC_BE). 856 4.2.9. Standard Service Class 858 The Standard service class is RECOMMENDED for traffic that has not 859 been classified into one of the other supported forwarding service 860 classes in the Diffserv network domain. This service class provides 861 the Internet's "best-effort" forwarding behavior. The RECOMMENDED 862 DSCP marking for the Standard Service Class is DF. ([RFC4594] 863 Section 4.9) 865 The Standard Service Class loosely corresponds to the 866 [IEEE.802.11-2016] Best Effort Access Category (AC_BE) and therefore 867 it is RECOMMENDED to map Standard Service Class traffic marked DF 868 DSCP to UP 0, thereby admitting it to the Best Effort Access Category 869 (AC_BE). This happens to correspond to the default mapping (as 870 described in Section 2.2). 872 4.2.10. Low-Priority Data 874 The Low-Priority Data service class serves applications that the user 875 is willing to accept without service assurances. This service class 876 is specified in [RFC3662] and [I-D.ietf-tsvwg-le-phb]. 878 The Low-Priority Data service class loosely corresponds to the 879 [IEEE.802.11-2016] Background Access Category (AC_BK) and therefore 880 it is RECOMMENDED to map Low-Priority Data traffic marked CS1 DSCP to 881 UP 1, thereby admitting it to the Background Access Category (AC_BK). 882 This happens to correspond to the default mapping (as described in 883 Section 2.2). 885 4.3. DSCP-to-UP Mapping Recommendations Summary 887 Figure 1 summarizes the [RFC4594] DSCP marking recommendations mapped 888 to [IEEE.802.11-2016] UP and access categories applied in the 889 downstream direction (i.e. from wired-to-wireless networks). 891 +------------------------------------------------------------------+ 892 | IETF Diffserv | PHB |Reference| IEEE 802.11 | 893 | Service Class | | RFC |User Priority| Access Category | 894 |===============+======+=========+=============+====================| 895 | | | | 7 | AC_VO (Voice) | 896 |Network Control| CS7 | RFC2474 | OR | 897 |(reserved for | | | 0 | AC_BE (Best Effort)| 898 | future use) | | |See Security Considerations-Sec.8 | 899 +---------------+------+---------+-------------+--------------------+ 900 | | | | 7 | AC_VO (Voice) | 901 |Network Control| CS6 | RFC2474 | OR | 902 | | | | 0 | AC_BE (Best Effort)| 903 | | | |See Security Considerations-Sec.8 | 904 +---------------+------+---------+-------------+--------------------+ 905 | Telephony | EF | RFC3246 | 6 | AC_VO (Voice) | 906 +---------------+------+---------+-------------+--------------------+ 907 | VOICE-ADMIT | VA | RFC5865 | 6 | AC_VO (Voice) | 908 | | | | | | 909 +---------------+------+---------+-------------+--------------------+ 910 | Signaling | CS5 | RFC2474 | 5 | AC_VI (Video) | 911 +---------------+------+---------+-------------+--------------------+ 912 | Multimedia | AF41 | | | | 913 | Conferencing | AF42 | RFC2597 | 4 | AC_VI (Video) | 914 | | AF43 | | | | 915 +---------------+------+---------+-------------+--------------------+ 916 | Real-Time | CS4 | RFC2474 | 4 | AC_VI (Video) | 917 | Interactive | | | | | 918 +---------------+------+---------+-------------+--------------------+ 919 | Multimedia | AF31 | | | | 920 | Streaming | AF32 | RFC2597 | 4 | AC_VI (Video) | 921 | | AF33 | | | | 922 +---------------+------+---------+-------------+--------------------+ 923 |Broadcast Video| CS3 | RFC2474 | 4 | AC_VI (Video) | 924 +---------------+------+---------+-------------+--------------------+ 925 | Low- | AF21 | | | | 926 | Latency | AF22 | RFC2597 | 3 | AC_BE (Best Effort)| 927 | Data | AF23 | | | | 928 +---------------+------+---------+-------------+--------------------+ 929 | OAM | CS2 | RFC2474 | 0 | AC_BE (Best Effort)| 930 +---------------+------+---------+-------------+--------------------+ 931 | High- | AF11 | | | | 932 | Throughput | AF12 | RFC2597 | 0 | AC_BE (Best Effort)| 933 | Data | AF13 | | | | 934 +---------------+------+---------+-------------+--------------------+ 935 | Standard | DF | RFC2474 | 0 | AC_BE (Best Effort)| 936 +---------------+------+---------+-------------+--------------------+ 937 | Low-Priority | CS1 | RFC3662 | 1 | AC_BK (Background) | 938 | Data | | | | | 939 +-------------------------------------------------------------------+ 941 Note: All unusued codepoints are recommended to be mapped to UP 0 942 (See Security Considerations Section - Section 8) 944 Figure 1: Summary of Downstream DSCP to IEEE 802.11 UP and AC Mapping 945 Recommendations 947 5. Upstream Mapping and Marking Recommendations 949 In the upstream direction (i.e. wireless-to-wired), there are three 950 types of mapping that may be implemented: 952 o DSCP-to-UP mapping within the wireless client operating system, 953 and 955 o UP-to-DSCP mapping at the wireless access point, or 956 o DSCP-Passthrough at the wireless access point (effectively a 1:1 957 DSCP-to-DSCP mapping) 959 As an alternative to the latter two options, the network 960 administrator MAY choose to use the wireless-to-wired edge as a 961 Diffserv boundary and explicitly set (or reset) DSCP markings 962 according to administrative policy, thus making the wireless edge a 963 Diffserv policy enforcement point. This is RECOMMENDED whenever 964 supported. 966 Each of these options will now be considered. 968 5.1. Upstream DSCP-to-UP Mapping within the Wireless Client Operating 969 System 971 Some operating systems on wireless client devices utilize a similar 972 default DSCP-to-UP mapping scheme as described in Section 2.2. As 973 such, this can lead to the same conflicts as described in that 974 section, but in the upstream direction. 976 Therefore, to improve on these default mappings, and to achieve 977 parity and consistency with downstream QoS, it is RECOMMENDED that 978 wireless client operating systems utilize instead the same DSCP-to-UP 979 mapping recommendations presented in Section 4, with the explicit 980 RECOMMENDATION that packets requesting a marking of CS6 or CS7 DSCP 981 SHOULD be mapped to UP 0 (and not to UP 7). Furthermore, in such 982 cases the wireless client operating system SHOULD remark such packets 983 to DSCP 0. This is because CS6 and CS7 DSCP, as well as UP 7 984 markings, are intended for network control protocols and these SHOULD 985 NOT be sourced from wireless client endpoint devices. This 986 recommendation is detailed in the Security Considerations section 987 (Section 8). 989 5.2. Upstream UP-to-DSCP Mapping at the Wireless Access Point 991 UP-to-DSCP mapping generates a DSCP value for the IP packet (either 992 an unencapsulated IP packet or an IP packet encapsulated within a 993 tunneling protocol such as CAPWAP - and destined towards a wireless 994 LAN controller for decapsulation and forwarding) from the Layer 2 995 [IEEE.802.11-2016] UP marking. This is typically done in the manner 996 described in Section 2.3. 998 It should be noted that any explicit remarking policy to be performed 999 on such a packet only takes place at the nearest classification and 1000 marking policy enforcement point, which may be: 1002 o At the wireless access point 1003 o At the wired network switch port 1005 o At the wireless LAN controller 1007 As such, UP-to-DSCP mapping allows for wireless L2 markings to affect 1008 the QoS treatment of a packet over the wired IP network (that is, 1009 until the packet reaches the nearest classification and marking 1010 policy enforcement point). 1012 It should be further noted that nowhere in the [IEEE.802.11-2016] 1013 specifications is there an intent expressed for UP markings to be 1014 used to influence QoS treatment over wired IP networks. Furthermore, 1015 [RFC2474], [RFC2475] and [RFC8100] all allow for the host to set DSCP 1016 markings for end-to-end QoS treatment over IP networks. Therefore, 1017 it is NOT RECOMMENDED that wireless access points leverage Layer 2 1018 [IEEE.802.11-2016] UP markings as set by wireless hosts and 1019 subsequently perform a UP-to-DSCP mapping in the upstream direction, 1020 but rather, if wireless host markings are to be leveraged (as per 1021 business requirements, technical constraints and administrative 1022 policies), then it is RECOMMENDED to pass through the Layer 3 DSCP 1023 markings set by these wireless hosts instead, as is discussed in the 1024 next section. 1026 5.3. Upstream DSCP-Passthrough at the Wireless Access Point 1028 It is generally NOT RECOMMENDED to pass through DSCP markings from 1029 unauthenticated and unauthorized devices, as these are typically 1030 considered untrusted sources. 1032 When business requirements and/or technical constraints and/or 1033 administrative policies require QoS markings to be passed through at 1034 the wireless edge, then it is RECOMMENDED to pass through Layer 3 1035 DSCP markings (over Layer 2 [IEEE.802.11-2016] UP markings) in the 1036 upstream direction, for the following reasons: 1038 o [RFC2474], [RFC2475] and [RFC8100] all allow for hosts to set DSCP 1039 markings to achieve an end-to-end differentiated service 1041 o [IEEE.802.11-2016] does not specify that UP markings are to be 1042 used to affect QoS treatment over wired IP networks 1044 o Most present wireless device operating systems generate UP values 1045 by the same method as described in Section 2.2 (i.e. by using the 1046 3 MSB of the encapsulated 6-bit DSCP); then, at the access point, 1047 these 3-bit markings are converted back into DSCP values, 1048 typically in the default manner described in Section 2.3; as such, 1049 information is lost in the translation from a 6-bit marking to a 1050 3-bit marking (which is then subsequently translated back to a 1051 6-bit marking); passing through the original (encapsulated) DSCP 1052 marking prevents such loss of information 1054 o A practical implementation benefit is also realized by passing 1055 through the DSCP set by wireless client devices, as enabling 1056 applications to mark DSCP is much more prevalent and accessible to 1057 programmers of applications running on wireless device platforms, 1058 vis-a-vis trying to explicitly set UP values, which requires 1059 special hooks into the wireless device operating system and/or 1060 hardware device drivers, many of which do not support such 1061 functionality 1063 5.4. Upstream DSCP Marking at the Wireless Access Point 1065 An alternative option to mapping is for the administrator to treat 1066 the wireless edge as the edge of the Diffserv domain and explicitly 1067 set (or reset) DSCP markings in the upstream direction according to 1068 administrative policy. This option is RECOMMENDED over mapping, as 1069 this typically is the most secure solution, as the network 1070 administrator directly enforces the Diffserv policy across the IP 1071 network (versus an application developer and/or the wireless endpoint 1072 device operating system developer, who may be functioning completely 1073 independently of the network administrator). 1075 6. Appendix: IEEE 802.11 QoS Overview 1077 QoS is enabled on wireless networks by means of the Hybrid 1078 Coordination Function (HCF). To give better context to the 1079 enhancements in HCF that enable QoS, it may be helpful to begin with 1080 a review of the original Distributed Coordination Function (DCF). 1082 6.1. Distributed Coordination Function (DCF) 1084 As has been noted, the Wi-Fi medium is a shared medium, with each 1085 station-including the wireless access point-contending for the medium 1086 on equal terms. As such, it shares the same challenge as any other 1087 shared medium in requiring a mechanism to prevent (or avoid) 1088 collisions which can occur when two (or more) stations attempt 1089 simultaneous transmission. 1091 The IEEE Ethernet working group solved this challenge by implementing 1092 a Carrier Sense Multiple Access/Collision Detection (CSMA/CD) 1093 mechanism that could detect collisions over the shared physical cable 1094 (as collisions could be detected as reflected energy pulses over the 1095 physical wire). Once a collision was detected, then a pre-defined 1096 set of rules was invoked that required stations to back off and wait 1097 random periods of time before re-attempting transmission. While 1098 CSMA/CD improved the usage of Ethernet as a shared medium, it should 1099 be noted the ultimate solution to solving Ethernet collisions was the 1100 advance of switching technologies, which treated each Ethernet cable 1101 as a dedicated collision domain. 1103 However, unlike Ethernet (which uses physical cables), collisions 1104 cannot be directly detected over the wireless medium, as RF energy is 1105 radiated over the air and colliding bursts are not necessarily 1106 reflected back to the transmitting stations. Therefore, a different 1107 mechanism is required for this medium. 1109 As such, the IEEE modified the CSMA/CD mechanism to adapt it to 1110 wireless networks to provide Carrier Sense Multiple Access/Collision 1111 Avoidance (CSMA/CA). The original CSMA/CA mechanism used in IEEE 1112 802.11 was the Distributed Coordination Function. DCF is a timer- 1113 based system that leverages three key sets of timers, the slot time, 1114 interframe spaces and contention windows. 1116 6.1.1. Slot Time 1118 The slot time is the basic unit of time measure for both DCF and HCF, 1119 on which all other timers are based. The slot time duration varies 1120 with the different generations of data-rates and performances 1121 described by the [IEEE.802.11-2016] standard. For example, the 1122 [IEEE.802.11-2016] standard specifies the slot time to be 20 us 1123 ([IEEE.802.11-2016] Table 15-5) for legacy implementations (such as 1124 IEEE 802.11b, supporting 1, 2, 5.5 and 11 Mbps data rates), while 1125 newer implementations (including IEEE 802.11g, 802.11a, 802.11n and 1126 802.11ac, supporting data rates from 6.5 Mbps to over 2 Gbps per 1127 spatial stream) define a shorter slot time of 9 us 1128 ([IEEE.802.11-2016], Section 17.4.4, Table 17-21). 1130 6.1.2. Interframe Spaces 1132 The time interval between frames that are transmitted over the air is 1133 called the Interframe Space (IFS). Several IFS are defined in 1134 [IEEE.802.11-2016], with the two most relevant to DCF being the Short 1135 Interframe Space (SIFS) and the DCF Interframe Space (DIFS). 1137 The SIFS is the amount of time in microseconds required for a 1138 wireless interface to process a received RF signal and its associated 1139 [IEEE.802.11-2016] frame and to generate a response frame. Like slot 1140 times, the SIFS can vary according to the performance implementation 1141 of the [IEEE.802.11-2016] standard. The SIFS for IEEE 802.11a, 1142 802.11n and 802.11ac (in 5 GHz) is 16 us ([IEEE.802.11-2016], 1143 Section 17.4.4, Table 17-21). 1145 Additionally, a station must sense the status of the wireless medium 1146 before transmitting. If it finds that the medium is continuously 1147 idle for the duration of a DIFS, then it is permitted to attempt 1148 transmission of a frame (after waiting an additional random backoff 1149 period, as will be discussed in the next section). If the channel is 1150 found busy during the DIFS interval, the station must defer its 1151 transmission until the medium is found idle for the duration of a 1152 DIFS interval. The DIFS is calculated as: 1154 DIFS = SIFS + (2 * Slot time) 1156 However, if all stations waited only a fixed amount of time before 1157 attempting transmission then collisions would be frequent. To offset 1158 this, each station must wait, not only a fixed amount of time (the 1159 DIFS), but also a random amount of time (the random backoff) prior to 1160 transmission. The range of the generated random backoff timer is 1161 bounded by the Contention Window. 1163 6.1.3. Contention Windows 1165 Contention windows bound the range of the generated random backoff 1166 timer that each station must wait (in addition to the DIFS) before 1167 attempting transmission. The initial range is set between 0 and the 1168 Contention Window minimum value (CWmin), inclusive. The CWmin for 1169 DCF (in 5 GHz) is specified as 15 slot times ([IEEE.802.11-2016], 1170 Section 17.4.4, Table 17-21). 1172 However, it is possible that two (or more) stations happen to pick 1173 the exact same random value within this range. If this happens then 1174 a collision may occur. At this point, the stations effectively begin 1175 the process again, waiting a DIFS and generate a new random backoff 1176 value. However, a key difference is that for this subsequent 1177 attempt, the Contention Window approximatively doubles in size (thus 1178 exponentially increasing the range of the random value). This 1179 process repeats as often as necessary if collisions continue to 1180 occur, until the maximum Contention Window size (CWmax) is reached. 1181 The CWmax for DCF is specified as 1023 slot times 1182 ([IEEE.802.11-2016], Section 17.4.4, Table 17-21). 1184 At this point, transmission attempts may still continue (until some 1185 other pre-defined limit is reached), but the Contention Window sizes 1186 are fixed at the CWmax value. 1188 Incidentally it may be observed that a significant amount of jitter 1189 can be introduced by this contention process for wireless 1190 transmission access. For example, the incremental transmission delay 1191 of 1023 slot times (CWmax) using 9 us slot times may be as high as 9 1192 ms of jitter per attempt. And, as previously noted, multiple 1193 attempts can be made at CWmax. 1195 6.2. Hybrid Coordination Function (HCF) 1197 Therefore, as can be seen from the preceding description of DCF, 1198 there is no preferential treatment of one station over another when 1199 contending for the shared wireless media; nor is there any 1200 preferential treatment of one type of traffic over another during the 1201 same contention process. To support the latter requirement, the IEEE 1202 enhanced DCF in 2005 to support QoS, specifying HCF in IEEE 802.11, 1203 which was integrated into the main IEEE 802.11 standard in 2007. 1205 6.2.1. User Priority (UP) 1207 One of the key changes to the [IEEE.802.11-2016] frame format is the 1208 inclusion of a QoS Control field, with 3 bits dedicated for QoS 1209 markings. These bits are referred to the User Priority (UP) bits and 1210 these support eight distinct marking values: 0-7, inclusive. 1212 While such markings allow for frame differentiation, these alone do 1213 not directly affect over-the-air treatment. Rather it is the non- 1214 configurable and standard-specified mapping of UP markings to 1215 [IEEE.802.11-2016] Access Categories (AC) that generate 1216 differentiated treatment over wireless media. 1218 6.2.2. Access Category (AC) 1220 Pairs of UP values are mapped to four defined access categories that 1221 correspondingly specify different treatments of frames over the air. 1222 These access categories (in order of relative priority from the top 1223 down) and their corresponding UP mappings are shown in Figure 2 1224 (adapted from [IEEE.802.11-2016], Section 10.2.4.2, Table 10-1). 1226 +-----------------------------------------+ 1227 | User | Access | Designative | 1228 | Priority | Category | (informative) | 1229 |===========+============+================| 1230 | 7 | AC_VO | Voice | 1231 +-----------+------------+----------------+ 1232 | 6 | AC_VO | Voice | 1233 +-----------+------------+----------------+ 1234 | 5 | AC_VI | Video | 1235 +-----------+------------+----------------+ 1236 | 4 | AC_VI | Video | 1237 +-----------+------------+----------------+ 1238 | 3 | AC_BE | Best Effort | 1239 +-----------+------------+----------------+ 1240 | 0 | AC_BE | Best Effort | 1241 +-----------+------------+----------------+ 1242 | 2 | AC_BK | Background | 1243 +-----------+------------+----------------+ 1244 | 1 | AC_BK | Background | 1245 +-----------------------------------------+ 1247 Figure 2: IEEE 802.11 Access Categories and User Priority Mappings 1249 The manner in which these four access categories achieve 1250 differentiated service over-the-air is primarily by tuning the fixed 1251 and random timers that stations have to wait before sending their 1252 respective types of traffic, as will be discussed next. 1254 6.2.3. Arbitration Inter-Frame Space (AIFS) 1256 As previously mentioned, each station must wait a fixed amount of 1257 time to ensure the medium is idle before attempting transmission. 1258 With DCF, the DIFS is constant for all types of traffic. However, 1259 with [IEEE.802.11-2016] the fixed amount of time that a station has 1260 to wait will depend on the access category and is referred to as an 1261 Arbitration Interframe Space (AIFS). AIFS are defined in slot times 1262 and the AIFS per access category are shown in Figure 3 (adapted from 1263 [IEEE.802.11-2016], Section 9.4.2.29, Table 9-137). 1265 +------------------------------------------+ 1266 | Access | Designative | AIFS | 1267 | Category | (informative) |(slot times)| 1268 |===========+=================+============| 1269 | AC_VO | Voice | 2 | 1270 +-----------+-----------------+------------+ 1271 | AC_VI | Video | 2 | 1272 +-----------+-----------------+------------+ 1273 | AC_BE | Best Effort | 3 | 1274 +-----------+-----------------+------------+ 1275 | AC_BK | Background | 7 | 1276 +-----------+-----------------+------------+ 1278 Figure 3: Arbitration Interframe Spaces by Access Category 1280 6.2.4. Access Category Contention Windows (CW) 1282 Not only is the fixed amount of time that a station has to wait 1283 skewed according to [IEEE.802.11-2016] access category, but so are 1284 the relative sizes of the Contention Windows that bound the random 1285 backoff timers, as shown in Figure 4 (adapted from 1286 [IEEE.802.11-2016], Section 9.4.2.29, Table 9-137). 1288 +-------------------------------------------------------+ 1289 | Access | Designative | CWmin | CWmax | 1290 | Category | (informative) |(slot times)|(slot times)| 1291 |===========+=================+============|============| 1292 | AC_VO | Voice | 3 | 7 | 1293 +-----------+-----------------+------------+------------+ 1294 | AC_VI | Video | 7 | 15 | 1295 +-----------+-----------------+------------+------------+ 1296 | AC_BE | Best Effort | 15 | 1023 | 1297 +-----------+-----------------+------------+------------+ 1298 | AC_BK | Background | 15 | 1023 | 1299 +-----------+-----------------+------------+------------+ 1301 Figure 4: Contention Window Sizes by Access Category 1303 When the fixed and randomly generated timers are added together on a 1304 per access category basis, then traffic assigned to the Voice Access 1305 Category (i.e. traffic marked to UP 6 or 7) will receive a 1306 statistically superior service relative to traffic assigned to the 1307 Video Access Category (i.e. traffic marked UP 5 and 4), which, in 1308 turn, will receive a statistically superior service relative to 1309 traffic assigned to the Best Effort Access Category traffic (i.e. 1311 traffic marked UP 3 and 0), which finally will receive a 1312 statistically superior service relative to traffic assigned to the 1313 Background Access Category traffic (i.e. traffic marked to UP 2 and 1314 1). 1316 6.3. IEEE 802.11u QoS Map Set 1318 IEEE 802.11u [IEEE.802-11u.2011] is an addendum that has now been 1319 included within the main [IEEE.802.11-2016] standard, and which 1320 includes, among other enhancements, a mechanism by which wireless 1321 access points can communicate DSCP to/from UP mappings that have been 1322 configured on the wired IP network. Specifically, a QoS Map Set 1323 information element (described in [IEEE.802.11-2016] Section 9.4.2.95 1324 and commonly referred to as the QoS Map element) is transmitted from 1325 an AP to a wireless endpoint device in an association / re- 1326 association Response frame (or within a special QoS Map Configure 1327 frame). 1329 The purpose of the QoS Map element is to provide the mapping of 1330 higher layer Quality of Service constructs (i.e. DSCP) to User 1331 Priorities. One intended effect of receiving such a map is for the 1332 wireless endpoint device (that supports this function and is 1333 administratively configured to enable it) to perform corresponding 1334 DSCP-to-UP mapping within the device (i.e. between applications and 1335 the operating system / wireless network interface hardware drivers) 1336 to align with what the APs are mapping in the downstream direction, 1337 so as to achieve consistent end-to-end QoS in both directions. 1339 The QoS Map element includes two key components: 1341 1) each of the eight UP values (0-7) are associated with a range of 1342 DSCP values, and 1344 2) (up to 21) exceptions from these range-based DSCP to/from UP 1345 mapping associations may be optionally and explicitly specified. 1347 In line with the recommendations put forward in this document, the 1348 following recommendations apply when the QoS Map element is enabled: 1350 1) each of the eight UP values (0-7) are RECOMMENDED to be mapped to 1351 DSCP 0 (as a baseline, so as to meet the recommendation made in 1352 Section 8.2 1354 2) (up to 21) exceptions from this baseline mapping are RECOMMENDED 1355 to be made in line with Section 4.3, to correspond to the Diffserv 1356 Codepoints that are in use over the IP network. 1358 It is important to note that the QoS Map element is intended to be 1359 transmitted from a wireless access point to a non-AP station. As 1360 such, the model where this element is used is that of a network where 1361 the AP is the edge of the Diffserv domain. Networks where the AP 1362 extends the Diffserv domain by connecting other APs and 1363 infrastructure devices through the IEEE 802.11 medium are not 1364 included in the cases covered by the presence of the QoS Map element, 1365 and therefore are not included in the present recommendation. 1367 7. IANA Considerations 1369 This memo asks the IANA for no new parameters. 1371 8. Security Considerations 1373 The recommendations in this document concern widely-deployed wired 1374 and wireless network functionality, and for that reason do not 1375 present additional security concerns that do not already exist in 1376 these networks. In fact, several of the recommendations made in this 1377 document serve to protect wired and wireless networks from potential 1378 abuse, as is discussed further in this section. 1380 8.1. General QoS Security Recommendations 1382 It may be possible for a wired or wireless device (which could be 1383 either a host or a network device) to mark packets (or map packet 1384 markings) in a manner that interferes with or degrades existing QoS 1385 policies. Such marking or mapping may be done intentionally or 1386 unintentionally by developers and/or users and/or administrators of 1387 such devices. 1389 To illustrate: A gaming application designed to run on a smart-phone 1390 or tablet may request that all its packets be marked DSCP EF and/or 1391 UP 6. However, if the traffic from such an application is forwarded 1392 without change over a business network, then this could interfere 1393 with QoS policies intended to provide priority services for business 1394 voice applications. 1396 To mitigate such scenarios it is RECOMMENDED to implement general QoS 1397 security measures, including: 1399 Setting a traffic conditioning policy reflective of business 1400 objectives and policy, such that traffic from authorized users 1401 and/or applications and/or endpoints will be accepted by the 1402 network; otherwise packet markings will be "bleached" (i.e. 1403 remarked to DSCP DF and/or UP 0). Additionally, Section 5.3 made 1404 it clear that it is generally NOT RECOMMENDED to pass through DSCP 1405 markings from unauthorized and/or unauthenticated devices, as 1406 these are typically considered untrusted sources. This is 1407 especially relevant for IoT deployments, where tens-of-billions of 1408 devices that may have little or no security are being connected to 1409 IP networks. 1411 Policing EF marked packet flows, as detailed in [RFC2474] 1412 Section 7 and [RFC3246] Section 3. 1414 In addition to these general QoS security recommendations, WLAN- 1415 specific QoS security recommendations can serve to further mitigate 1416 attacks and potential network abuse. 1418 8.2. WLAN QoS Security Recommendations 1420 The wireless LAN presents a unique DoS attack vector, as endpoint 1421 devices contend for the shared media on a completely egalitarian 1422 basis with the network (as represented by the AP). This means that 1423 any wireless client could potentially monopolize the air by sending 1424 packets marked to preferred UP values (i.e. UP values 4-7) in the 1425 upstream direction. Similarly, airtime could be monopolized if 1426 excessive amounts of downstream traffic were marked/mapped to these 1427 same preferred UP values. As such, the ability to mark/map to these 1428 preferred UP values (of UP 4-7) should be controlled. 1430 If such marking/mapping were not controlled, then, for example, a 1431 malicious user could cause WLAN DoS by flooding traffic marked CS7 1432 DSCP downstream. This codepoint would map by default (as described 1433 in Section 2.2) to UP 7 and would be assigned to the Voice Access 1434 Category (AC_VO). Such a flood could cause Denial-of-Service to not 1435 only wireless voice applications, but also to all other traffic 1436 classes. Similarly, an uninformed application developer may request 1437 all traffic from his/her application to be marked CS7 or CS6, 1438 thinking this would acheive in the best overall servicing oftheir 1439 application traffic, while not realizing that such a marking (if 1440 honored by the client operating system) could cause not only WLAN 1441 DoS, but also IP network instability, as the traffic marked CS7 or 1442 CS6 finds its way into queues intended for servicing (relatively low- 1443 bandwidth) network control protocols, potentially starving legitimate 1444 network control protocols in the process. 1446 Therefore, to mitigate such an attack, it is RECOMMENDED that all 1447 packets marked to Diffserv Codepoints not in use over the wireless 1448 network be mapped to UP 0; this recommendation applies both at the 1449 access point (in the downstream direction) and within the wireless 1450 endpoint device operating system (in the upstream direction). 1452 Such a policy of mapping unused codepoints to UP 0 would also prevent 1453 an attack where non-standard codepoints were used to cause WLAN DoS. 1455 Consider the case where codepoints are mapped to UP values using a 1456 range function (e.g. DSCP values 48-55 all map to UP 6), then an 1457 attacker could flood packets marked, for example to DSCP 49, in 1458 either the upstream or downstream direction over the WLAN, causing 1459 DoS to all other traffic classes in the process. 1461 In the majority of WLAN deployments, the AP represents not only the 1462 edge of the Diffserv domain, but also the edge of the network 1463 infrastructure itself; that is, only wireless client endpoint devices 1464 are downstream from the AP. In such a deployment model, CS6 and CS7 1465 also fall into the category of codepoints that are not in use over 1466 the wireless LAN (since only wireless endpoint client devices are 1467 downstream from the AP in this model and these devices do not 1468 [legitimately] participate in network control protocol exchanges). 1469 As such, it is RECOMMENDED that CS6 and CS7 DSCP be mapped to UP 0 in 1470 these Wifi-at-the-edge deployment models. Otherwise, it would be 1471 easy for a malicious application developer, or even an inadvertently 1472 poorly-programmed IoT device, to cause WLAN DoS and even wired IP 1473 network instability by flooding traffic marked CS6 DSCP, which would 1474 by default (as described in Section 2.2) be mapped to UP 6, causing 1475 all other traffic classes on the WLAN to be starved, as well 1476 hijacking queues on the wired IP network that are intended for the 1477 servicing of routing protocols. To this point, it was also 1478 recommended in Section 5.1 that packets requesting a marking of CS6 1479 or CS7 DSCP SHOULD be remarked to DSCP 0 and mapped to UP 0 by the 1480 wireless client operating system. 1482 Finally, it should be noted that the recommendations put forward in 1483 this document are not intended to address all attack vectors 1484 leveraging QoS marking abuse. Mechanisms that may further help 1485 mitigate security risks include strong device- and/or user- 1486 authentication, access-control, rate limiting, control-plane 1487 policing, encryption and other techniques; however, the 1488 implementation recommendations for such mechanisms are beyond the 1489 scope of this document to address in detail. Suffice it to say that 1490 the security of the devices and networks implementing QoS, including 1491 QoS mapping between wired and wireless networks, SHOULD be considered 1492 in actual deployments. 1494 9. Acknowledgements 1496 The authors wish to thank David Black, Gorry Fairhurst, Ruediger 1497 Geib, Vincent Roca, Brian Carpenter, David Blake, Cullen Jennings, 1498 David Benham and the TSVWG. 1500 The authors also acknowledge a great many inputs, notably from David 1501 Kloper, Mark Montanez, Glen Lavers, Michael Fingleton, Sarav 1502 Radhakrishnan, Karthik Dakshinamoorthy, Simone Arena, Ranga Marathe, 1503 Ramachandra Murthy and many others. 1505 10. References 1507 10.1. Normative References 1509 [IEEE.802.11-2016] 1510 "Information technology - Telecommunications and 1511 information exchange between systems - Local and 1512 metropolitan area networks - Specific requirements - Part 1513 11: Wireless LAN Medium Access Control (MAC) and Physical 1514 Layer (PHY) specifications", IEEE Standard 802.11, 2016, 1515 . 1518 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1519 Requirement Levels", BCP 14, RFC 2119, 1520 DOI 10.17487/RFC2119, March 1997, 1521 . 1523 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1524 "Definition of the Differentiated Services Field (DS 1525 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1526 DOI 10.17487/RFC2474, December 1998, 1527 . 1529 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1530 and W. Weiss, "An Architecture for Differentiated 1531 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 1532 . 1534 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 1535 "Assured Forwarding PHB Group", RFC 2597, 1536 DOI 10.17487/RFC2597, June 1999, 1537 . 1539 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1540 of Explicit Congestion Notification (ECN) to IP", 1541 RFC 3168, DOI 10.17487/RFC3168, September 2001, 1542 . 1544 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 1545 J., Courtney, W., Davari, S., Firoiu, V., and D. 1546 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 1547 Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002, 1548 . 1550 [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort 1551 Per-Domain Behavior (PDB) for Differentiated Services", 1552 RFC 3662, DOI 10.17487/RFC3662, December 2003, 1553 . 1555 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 1556 Guidelines for DiffServ Service Classes", RFC 4594, 1557 DOI 10.17487/RFC4594, August 2006, 1558 . 1560 [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of 1561 Diffserv Service Classes", RFC 5127, DOI 10.17487/RFC5127, 1562 February 2008, . 1564 [RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated 1565 Services Code Point (DSCP) for Capacity-Admitted Traffic", 1566 RFC 5865, DOI 10.17487/RFC5865, May 2010, 1567 . 1569 [RFC8100] Geib, R., Ed. and D. Black, "Diffserv-Interconnection 1570 Classes and Practice", RFC 8100, DOI 10.17487/RFC8100, 1571 March 2017, . 1573 10.2. Informative References 1575 [I-D.ietf-tsvwg-le-phb] 1576 Bless, R., "A Lower Effort Per-Hop Behavior (LE PHB)", 1577 draft-ietf-tsvwg-le-phb-02 (work in progress), June 2017. 1579 [IEEE.802-11u.2011] 1580 "Information technology - Telecommunications and 1581 information exchange between systems - Local and 1582 metropolitan area networks - Specific requirements - Part 1583 11: Wireless LAN Medium Access Control (MAC) and Physical 1584 Layer (PHY) specifications", IEEE Standard 802.11, 2011, 1585 . 1588 [RFC7561] Kaippallimalil, J., Pazhyannur, R., and P. Yegani, 1589 "Mapping Quality of Service (QoS) Procedures of Proxy 1590 Mobile IPv6 (PMIPv6) and WLAN", RFC 7561, 1591 DOI 10.17487/RFC7561, June 2015, 1592 . 1594 Appendix A. Change Log 1596 Initial Version: July 2015 1598 Authors' Addresses 1600 Tim Szigeti 1601 Cisco Systems 1602 Vancouver, British Columbia V6K 3L4 1603 Canada 1605 Email: szigeti@cisco.com 1607 Jerome Henry 1608 Cisco Systems 1609 Research Triangle Park, North Carolina 27709 1610 USA 1612 Email: jerhenry@cisco.com 1614 Fred Baker 1615 Santa Barbara, California 93117 1616 USA 1618 Email: FredBaker.IETF@gmail.com