idnits 2.17.1 draft-ietf-tsvwg-ieee-802-11-06.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 (August 16, 2017) is 2439 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: February 17, 2018 F. Baker 6 August 16, 2017 8 Diffserv to IEEE 802.11 Mapping 9 draft-ietf-tsvwg-ieee-802-11-06 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 February 17, 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, with the exception of CS6 and CS7 (as will be 1037 discussed further), for the following reasons: 1039 o [RFC2474], [RFC2475] and [RFC8100] all allow for hosts to set DSCP 1040 markings to achieve an end-to-end differentiated service 1042 o [IEEE.802.11-2016] does not specify that UP markings are to be 1043 used to affect QoS treatment over wired IP networks 1045 o Most present wireless device operating systems generate UP values 1046 by the same method as described in Section 2.2 (i.e. by using the 1047 3 MSB of the encapsulated 6-bit DSCP); then, at the access point, 1048 these 3-bit markings are converted back into DSCP values, 1049 typically in the default manner described in Section 2.3; as such, 1050 information is lost in the translation from a 6-bit marking to a 1051 3-bit marking (which is then subsequently translated back to a 1052 6-bit marking); passing through the original (encapsulated) DSCP 1053 marking prevents such loss of information 1055 o A practical implementation benefit is also realized by passing 1056 through the DSCP set by wireless client devices, as enabling 1057 applications to mark DSCP is much more prevalent and accessible to 1058 programmers of applications running on wireless device platforms, 1059 vis-a-vis trying to explicitly set UP values, which requires 1060 special hooks into the wireless device operating system and/or 1061 hardware device drivers, many of which do not support such 1062 functionality 1064 CS6 and CS7 are exceptions to this pass through recommendation 1065 because wireless hosts SHOULD NOT use them (see Section 5.1) and 1066 traffic with those two markings poses a threat to operation of the 1067 wired network (see Section 8.2). CS6 and CS7 SHOULD NOT be passed 1068 through to the wired network in the upstream direction unless the 1069 access point has been specifically configured to do that by a network 1070 administrator or operator. 1072 5.4. Upstream DSCP Marking at the Wireless Access Point 1074 An alternative option to mapping is for the administrator to treat 1075 the wireless edge as the edge of the Diffserv domain and explicitly 1076 set (or reset) DSCP markings in the upstream direction according to 1077 administrative policy. This option is RECOMMENDED over mapping, as 1078 this typically is the most secure solution, as the network 1079 administrator directly enforces the Diffserv policy across the IP 1080 network (versus an application developer and/or the wireless endpoint 1081 device operating system developer, who may be functioning completely 1082 independently of the network administrator). 1084 6. Appendix: IEEE 802.11 QoS Overview 1086 QoS is enabled on wireless networks by means of the Hybrid 1087 Coordination Function (HCF). To give better context to the 1088 enhancements in HCF that enable QoS, it may be helpful to begin with 1089 a review of the original Distributed Coordination Function (DCF). 1091 6.1. Distributed Coordination Function (DCF) 1093 As has been noted, the Wi-Fi medium is a shared medium, with each 1094 station-including the wireless access point-contending for the medium 1095 on equal terms. As such, it shares the same challenge as any other 1096 shared medium in requiring a mechanism to prevent (or avoid) 1097 collisions which can occur when two (or more) stations attempt 1098 simultaneous transmission. 1100 The IEEE Ethernet working group solved this challenge by implementing 1101 a Carrier Sense Multiple Access/Collision Detection (CSMA/CD) 1102 mechanism that could detect collisions over the shared physical cable 1103 (as collisions could be detected as reflected energy pulses over the 1104 physical wire). Once a collision was detected, then a pre-defined 1105 set of rules was invoked that required stations to back off and wait 1106 random periods of time before re-attempting transmission. While 1107 CSMA/CD improved the usage of Ethernet as a shared medium, it should 1108 be noted the ultimate solution to solving Ethernet collisions was the 1109 advance of switching technologies, which treated each Ethernet cable 1110 as a dedicated collision domain. 1112 However, unlike Ethernet (which uses physical cables), collisions 1113 cannot be directly detected over the wireless medium, as RF energy is 1114 radiated over the air and colliding bursts are not necessarily 1115 reflected back to the transmitting stations. Therefore, a different 1116 mechanism is required for this medium. 1118 As such, the IEEE modified the CSMA/CD mechanism to adapt it to 1119 wireless networks to provide Carrier Sense Multiple Access/Collision 1120 Avoidance (CSMA/CA). The original CSMA/CA mechanism used in IEEE 1121 802.11 was the Distributed Coordination Function. DCF is a timer- 1122 based system that leverages three key sets of timers, the slot time, 1123 interframe spaces and contention windows. 1125 6.1.1. Slot Time 1127 The slot time is the basic unit of time measure for both DCF and HCF, 1128 on which all other timers are based. The slot time duration varies 1129 with the different generations of data-rates and performances 1130 described by the [IEEE.802.11-2016] standard. For example, the 1131 [IEEE.802.11-2016] standard specifies the slot time to be 20 us 1132 ([IEEE.802.11-2016] Table 15-5) for legacy implementations (such as 1133 IEEE 802.11b, supporting 1, 2, 5.5 and 11 Mbps data rates), while 1134 newer implementations (including IEEE 802.11g, 802.11a, 802.11n and 1135 802.11ac, supporting data rates from 6.5 Mbps to over 2 Gbps per 1136 spatial stream) define a shorter slot time of 9 us 1137 ([IEEE.802.11-2016], Section 17.4.4, Table 17-21). 1139 6.1.2. Interframe Spaces 1141 The time interval between frames that are transmitted over the air is 1142 called the Interframe Space (IFS). Several IFS are defined in 1143 [IEEE.802.11-2016], with the two most relevant to DCF being the Short 1144 Interframe Space (SIFS) and the DCF Interframe Space (DIFS). 1146 The SIFS is the amount of time in microseconds required for a 1147 wireless interface to process a received RF signal and its associated 1149 [IEEE.802.11-2016] frame and to generate a response frame. Like slot 1150 times, the SIFS can vary according to the performance implementation 1151 of the [IEEE.802.11-2016] standard. The SIFS for IEEE 802.11a, 1152 802.11n and 802.11ac (in 5 GHz) is 16 us ([IEEE.802.11-2016], 1153 Section 17.4.4, Table 17-21). 1155 Additionally, a station must sense the status of the wireless medium 1156 before transmitting. If it finds that the medium is continuously 1157 idle for the duration of a DIFS, then it is permitted to attempt 1158 transmission of a frame (after waiting an additional random backoff 1159 period, as will be discussed in the next section). If the channel is 1160 found busy during the DIFS interval, the station must defer its 1161 transmission until the medium is found idle for the duration of a 1162 DIFS interval. The DIFS is calculated as: 1164 DIFS = SIFS + (2 * Slot time) 1166 However, if all stations waited only a fixed amount of time before 1167 attempting transmission then collisions would be frequent. To offset 1168 this, each station must wait, not only a fixed amount of time (the 1169 DIFS), but also a random amount of time (the random backoff) prior to 1170 transmission. The range of the generated random backoff timer is 1171 bounded by the Contention Window. 1173 6.1.3. Contention Windows 1175 Contention windows bound the range of the generated random backoff 1176 timer that each station must wait (in addition to the DIFS) before 1177 attempting transmission. The initial range is set between 0 and the 1178 Contention Window minimum value (CWmin), inclusive. The CWmin for 1179 DCF (in 5 GHz) is specified as 15 slot times ([IEEE.802.11-2016], 1180 Section 17.4.4, Table 17-21). 1182 However, it is possible that two (or more) stations happen to pick 1183 the exact same random value within this range. If this happens then 1184 a collision may occur. At this point, the stations effectively begin 1185 the process again, waiting a DIFS and generate a new random backoff 1186 value. However, a key difference is that for this subsequent 1187 attempt, the Contention Window approximatively doubles in size (thus 1188 exponentially increasing the range of the random value). This 1189 process repeats as often as necessary if collisions continue to 1190 occur, until the maximum Contention Window size (CWmax) is reached. 1191 The CWmax for DCF is specified as 1023 slot times 1192 ([IEEE.802.11-2016], Section 17.4.4, Table 17-21). 1194 At this point, transmission attempts may still continue (until some 1195 other pre-defined limit is reached), but the Contention Window sizes 1196 are fixed at the CWmax value. 1198 Incidentally it may be observed that a significant amount of jitter 1199 can be introduced by this contention process for wireless 1200 transmission access. For example, the incremental transmission delay 1201 of 1023 slot times (CWmax) using 9 us slot times may be as high as 9 1202 ms of jitter per attempt. And, as previously noted, multiple 1203 attempts can be made at CWmax. 1205 6.2. Hybrid Coordination Function (HCF) 1207 Therefore, as can be seen from the preceding description of DCF, 1208 there is no preferential treatment of one station over another when 1209 contending for the shared wireless media; nor is there any 1210 preferential treatment of one type of traffic over another during the 1211 same contention process. To support the latter requirement, the IEEE 1212 enhanced DCF in 2005 to support QoS, specifying HCF in IEEE 802.11, 1213 which was integrated into the main IEEE 802.11 standard in 2007. 1215 6.2.1. User Priority (UP) 1217 One of the key changes to the [IEEE.802.11-2016] frame format is the 1218 inclusion of a QoS Control field, with 3 bits dedicated for QoS 1219 markings. These bits are referred to the User Priority (UP) bits and 1220 these support eight distinct marking values: 0-7, inclusive. 1222 While such markings allow for frame differentiation, these alone do 1223 not directly affect over-the-air treatment. Rather it is the non- 1224 configurable and standard-specified mapping of UP markings to 1225 [IEEE.802.11-2016] Access Categories (AC) that generate 1226 differentiated treatment over wireless media. 1228 6.2.2. Access Category (AC) 1230 Pairs of UP values are mapped to four defined access categories that 1231 correspondingly specify different treatments of frames over the air. 1232 These access categories (in order of relative priority from the top 1233 down) and their corresponding UP mappings are shown in Figure 2 1234 (adapted from [IEEE.802.11-2016], Section 10.2.4.2, Table 10-1). 1236 +-----------------------------------------+ 1237 | User | Access | Designative | 1238 | Priority | Category | (informative) | 1239 |===========+============+================| 1240 | 7 | AC_VO | Voice | 1241 +-----------+------------+----------------+ 1242 | 6 | AC_VO | Voice | 1243 +-----------+------------+----------------+ 1244 | 5 | AC_VI | Video | 1245 +-----------+------------+----------------+ 1246 | 4 | AC_VI | Video | 1247 +-----------+------------+----------------+ 1248 | 3 | AC_BE | Best Effort | 1249 +-----------+------------+----------------+ 1250 | 0 | AC_BE | Best Effort | 1251 +-----------+------------+----------------+ 1252 | 2 | AC_BK | Background | 1253 +-----------+------------+----------------+ 1254 | 1 | AC_BK | Background | 1255 +-----------------------------------------+ 1257 Figure 2: IEEE 802.11 Access Categories and User Priority Mappings 1259 The manner in which these four access categories achieve 1260 differentiated service over-the-air is primarily by tuning the fixed 1261 and random timers that stations have to wait before sending their 1262 respective types of traffic, as will be discussed next. 1264 6.2.3. Arbitration Inter-Frame Space (AIFS) 1266 As previously mentioned, each station must wait a fixed amount of 1267 time to ensure the medium is idle before attempting transmission. 1268 With DCF, the DIFS is constant for all types of traffic. However, 1269 with [IEEE.802.11-2016] the fixed amount of time that a station has 1270 to wait will depend on the access category and is referred to as an 1271 Arbitration Interframe Space (AIFS). AIFS are defined in slot times 1272 and the AIFS per access category are shown in Figure 3 (adapted from 1273 [IEEE.802.11-2016], Section 9.4.2.29, Table 9-137). 1275 +------------------------------------------+ 1276 | Access | Designative | AIFS | 1277 | Category | (informative) |(slot times)| 1278 |===========+=================+============| 1279 | AC_VO | Voice | 2 | 1280 +-----------+-----------------+------------+ 1281 | AC_VI | Video | 2 | 1282 +-----------+-----------------+------------+ 1283 | AC_BE | Best Effort | 3 | 1284 +-----------+-----------------+------------+ 1285 | AC_BK | Background | 7 | 1286 +-----------+-----------------+------------+ 1288 Figure 3: Arbitration Interframe Spaces by Access Category 1290 6.2.4. Access Category Contention Windows (CW) 1292 Not only is the fixed amount of time that a station has to wait 1293 skewed according to [IEEE.802.11-2016] access category, but so are 1294 the relative sizes of the Contention Windows that bound the random 1295 backoff timers, as shown in Figure 4 (adapted from 1296 [IEEE.802.11-2016], Section 9.4.2.29, Table 9-137). 1298 +-------------------------------------------------------+ 1299 | Access | Designative | CWmin | CWmax | 1300 | Category | (informative) |(slot times)|(slot times)| 1301 |===========+=================+============|============| 1302 | AC_VO | Voice | 3 | 7 | 1303 +-----------+-----------------+------------+------------+ 1304 | AC_VI | Video | 7 | 15 | 1305 +-----------+-----------------+------------+------------+ 1306 | AC_BE | Best Effort | 15 | 1023 | 1307 +-----------+-----------------+------------+------------+ 1308 | AC_BK | Background | 15 | 1023 | 1309 +-----------+-----------------+------------+------------+ 1311 Figure 4: Contention Window Sizes by Access Category 1313 When the fixed and randomly generated timers are added together on a 1314 per access category basis, then traffic assigned to the Voice Access 1315 Category (i.e. traffic marked to UP 6 or 7) will receive a 1316 statistically superior service relative to traffic assigned to the 1317 Video Access Category (i.e. traffic marked UP 5 and 4), which, in 1318 turn, will receive a statistically superior service relative to 1319 traffic assigned to the Best Effort Access Category traffic (i.e. 1321 traffic marked UP 3 and 0), which finally will receive a 1322 statistically superior service relative to traffic assigned to the 1323 Background Access Category traffic (i.e. traffic marked to UP 2 and 1324 1). 1326 6.3. IEEE 802.11u QoS Map Set 1328 IEEE 802.11u [IEEE.802-11u.2011] is an addendum that has now been 1329 included within the main [IEEE.802.11-2016] standard, and which 1330 includes, among other enhancements, a mechanism by which wireless 1331 access points can communicate DSCP to/from UP mappings that have been 1332 configured on the wired IP network. Specifically, a QoS Map Set 1333 information element (described in [IEEE.802.11-2016] Section 9.4.2.95 1334 and commonly referred to as the QoS Map element) is transmitted from 1335 an AP to a wireless endpoint device in an association / re- 1336 association Response frame (or within a special QoS Map Configure 1337 frame). 1339 The purpose of the QoS Map element is to provide the mapping of 1340 higher layer Quality of Service constructs (i.e. DSCP) to User 1341 Priorities. One intended effect of receiving such a map is for the 1342 wireless endpoint device (that supports this function and is 1343 administratively configured to enable it) to perform corresponding 1344 DSCP-to-UP mapping within the device (i.e. between applications and 1345 the operating system / wireless network interface hardware drivers) 1346 to align with what the APs are mapping in the downstream direction, 1347 so as to achieve consistent end-to-end QoS in both directions. 1349 The QoS Map element includes two key components: 1351 1) each of the eight UP values (0-7) are associated with a range of 1352 DSCP values, and 1354 2) (up to 21) exceptions from these range-based DSCP to/from UP 1355 mapping associations may be optionally and explicitly specified. 1357 In line with the recommendations put forward in this document, the 1358 following recommendations apply when the QoS Map element is enabled: 1360 1) each of the eight UP values (0-7) are RECOMMENDED to be mapped to 1361 DSCP 0 (as a baseline, so as to meet the recommendation made in 1362 Section 8.2 1364 2) (up to 21) exceptions from this baseline mapping are RECOMMENDED 1365 to be made in line with Section 4.3, to correspond to the Diffserv 1366 Codepoints that are in use over the IP network. 1368 It is important to note that the QoS Map element is intended to be 1369 transmitted from a wireless access point to a non-AP station. As 1370 such, the model where this element is used is that of a network where 1371 the AP is the edge of the Diffserv domain. Networks where the AP 1372 extends the Diffserv domain by connecting other APs and 1373 infrastructure devices through the IEEE 802.11 medium are not 1374 included in the cases covered by the presence of the QoS Map element, 1375 and therefore are not included in the present recommendation. 1377 7. IANA Considerations 1379 This memo asks the IANA for no new parameters. 1381 8. Security Considerations 1383 The recommendations in this document concern widely-deployed wired 1384 and wireless network functionality, and for that reason do not 1385 present additional security concerns that do not already exist in 1386 these networks. In fact, several of the recommendations made in this 1387 document serve to protect wired and wireless networks from potential 1388 abuse, as is discussed further in this section. 1390 8.1. General QoS Security Recommendations 1392 It may be possible for a wired or wireless device (which could be 1393 either a host or a network device) to mark packets (or map packet 1394 markings) in a manner that interferes with or degrades existing QoS 1395 policies. Such marking or mapping may be done intentionally or 1396 unintentionally by developers and/or users and/or administrators of 1397 such devices. 1399 To illustrate: A gaming application designed to run on a smart-phone 1400 or tablet may request that all its packets be marked DSCP EF and/or 1401 UP 6. However, if the traffic from such an application is forwarded 1402 without change over a business network, then this could interfere 1403 with QoS policies intended to provide priority services for business 1404 voice applications. 1406 To mitigate such scenarios it is RECOMMENDED to implement general QoS 1407 security measures, including: 1409 Setting a traffic conditioning policy reflective of business 1410 objectives and policy, such that traffic from authorized users 1411 and/or applications and/or endpoints will be accepted by the 1412 network; otherwise packet markings will be "bleached" (i.e. 1413 remarked to DSCP DF and/or UP 0). Additionally, Section 5.3 made 1414 it clear that it is generally NOT RECOMMENDED to pass through DSCP 1415 markings from unauthorized and/or unauthenticated devices, as 1416 these are typically considered untrusted sources. This is 1417 especially relevant for IoT deployments, where tens-of-billions of 1418 devices that may have little or no security are being connected to 1419 IP networks. 1421 Policing EF marked packet flows, as detailed in [RFC2474] 1422 Section 7 and [RFC3246] Section 3. 1424 In addition to these general QoS security recommendations, WLAN- 1425 specific QoS security recommendations can serve to further mitigate 1426 attacks and potential network abuse. 1428 8.2. WLAN QoS Security Recommendations 1430 The wireless LAN presents a unique DoS attack vector, as endpoint 1431 devices contend for the shared media on a completely egalitarian 1432 basis with the network (as represented by the AP). This means that 1433 any wireless client could potentially monopolize the air by sending 1434 packets marked to preferred UP values (i.e. UP values 4-7) in the 1435 upstream direction. Similarly, airtime could be monopolized if 1436 excessive amounts of downstream traffic were marked/mapped to these 1437 same preferred UP values. As such, the ability to mark/map to these 1438 preferred UP values (of UP 4-7) should be controlled. 1440 If such marking/mapping were not controlled, then, for example, a 1441 malicious user could cause WLAN DoS by flooding traffic marked CS7 1442 DSCP downstream. This codepoint would map by default (as described 1443 in Section 2.2) to UP 7 and would be assigned to the Voice Access 1444 Category (AC_VO). Such a flood could cause Denial-of-Service to not 1445 only wireless voice applications, but also to all other traffic 1446 classes. Similarly, an uninformed application developer may request 1447 all traffic from his/her application to be marked CS7 or CS6, 1448 thinking this would acheive in the best overall servicing oftheir 1449 application traffic, while not realizing that such a marking (if 1450 honored by the client operating system) could cause not only WLAN 1451 DoS, but also IP network instability, as the traffic marked CS7 or 1452 CS6 finds its way into queues intended for servicing (relatively low- 1453 bandwidth) network control protocols, potentially starving legitimate 1454 network control protocols in the process. 1456 Therefore, to mitigate such an attack, it is RECOMMENDED that all 1457 packets marked to Diffserv Codepoints not in use over the wireless 1458 network be mapped to UP 0; this recommendation applies both at the 1459 access point (in the downstream direction) and within the wireless 1460 endpoint device operating system (in the upstream direction). 1462 Such a policy of mapping unused codepoints to UP 0 would also prevent 1463 an attack where non-standard codepoints were used to cause WLAN DoS. 1465 Consider the case where codepoints are mapped to UP values using a 1466 range function (e.g. DSCP values 48-55 all map to UP 6), then an 1467 attacker could flood packets marked, for example to DSCP 49, in 1468 either the upstream or downstream direction over the WLAN, causing 1469 DoS to all other traffic classes in the process. 1471 In the majority of WLAN deployments, the AP represents not only the 1472 edge of the Diffserv domain, but also the edge of the network 1473 infrastructure itself; that is, only wireless client endpoint devices 1474 are downstream from the AP. In such a deployment model, CS6 and CS7 1475 also fall into the category of codepoints that are not in use over 1476 the wireless LAN (since only wireless endpoint client devices are 1477 downstream from the AP in this model and these devices do not 1478 [legitimately] participate in network control protocol exchanges). 1479 As such, it is RECOMMENDED that CS6 and CS7 DSCP be mapped to UP 0 in 1480 these Wifi-at-the-edge deployment models. Otherwise, it would be 1481 easy for a malicious application developer, or even an inadvertently 1482 poorly-programmed IoT device, to cause WLAN DoS and even wired IP 1483 network instability by flooding traffic marked CS6 DSCP, which would 1484 by default (as described in Section 2.2) be mapped to UP 6, causing 1485 all other traffic classes on the WLAN to be starved, as well 1486 hijacking queues on the wired IP network that are intended for the 1487 servicing of routing protocols. To this point, it was also 1488 recommended in Section 5.1 that packets requesting a marking of CS6 1489 or CS7 DSCP SHOULD be remarked to DSCP 0 and mapped to UP 0 by the 1490 wireless client operating system. 1492 Finally, it should be noted that the recommendations put forward in 1493 this document are not intended to address all attack vectors 1494 leveraging QoS marking abuse. Mechanisms that may further help 1495 mitigate security risks include strong device- and/or user- 1496 authentication, access-control, rate limiting, control-plane 1497 policing, encryption and other techniques; however, the 1498 implementation recommendations for such mechanisms are beyond the 1499 scope of this document to address in detail. Suffice it to say that 1500 the security of the devices and networks implementing QoS, including 1501 QoS mapping between wired and wireless networks, SHOULD be considered 1502 in actual deployments. 1504 9. Acknowledgements 1506 The authors wish to thank David Black, Gorry Fairhurst, Ruediger 1507 Geib, Vincent Roca, Brian Carpenter, David Blake, Cullen Jennings, 1508 David Benham and the TSVWG. 1510 The authors also acknowledge a great many inputs, notably from David 1511 Kloper, Mark Montanez, Glen Lavers, Michael Fingleton, Sarav 1512 Radhakrishnan, Karthik Dakshinamoorthy, Simone Arena, Ranga Marathe, 1513 Ramachandra Murthy and many others. 1515 10. References 1517 10.1. Normative References 1519 [IEEE.802.11-2016] 1520 "Information technology - Telecommunications and 1521 information exchange between systems - Local and 1522 metropolitan area networks - Specific requirements - Part 1523 11: Wireless LAN Medium Access Control (MAC) and Physical 1524 Layer (PHY) specifications", IEEE Standard 802.11, 2016, 1525 . 1528 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1529 Requirement Levels", BCP 14, RFC 2119, 1530 DOI 10.17487/RFC2119, March 1997, 1531 . 1533 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1534 "Definition of the Differentiated Services Field (DS 1535 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1536 DOI 10.17487/RFC2474, December 1998, 1537 . 1539 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1540 and W. Weiss, "An Architecture for Differentiated 1541 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 1542 . 1544 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 1545 "Assured Forwarding PHB Group", RFC 2597, 1546 DOI 10.17487/RFC2597, June 1999, 1547 . 1549 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1550 of Explicit Congestion Notification (ECN) to IP", 1551 RFC 3168, DOI 10.17487/RFC3168, September 2001, 1552 . 1554 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 1555 J., Courtney, W., Davari, S., Firoiu, V., and D. 1556 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 1557 Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002, 1558 . 1560 [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort 1561 Per-Domain Behavior (PDB) for Differentiated Services", 1562 RFC 3662, DOI 10.17487/RFC3662, December 2003, 1563 . 1565 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 1566 Guidelines for DiffServ Service Classes", RFC 4594, 1567 DOI 10.17487/RFC4594, August 2006, 1568 . 1570 [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of 1571 Diffserv Service Classes", RFC 5127, DOI 10.17487/RFC5127, 1572 February 2008, . 1574 [RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated 1575 Services Code Point (DSCP) for Capacity-Admitted Traffic", 1576 RFC 5865, DOI 10.17487/RFC5865, May 2010, 1577 . 1579 [RFC8100] Geib, R., Ed. and D. Black, "Diffserv-Interconnection 1580 Classes and Practice", RFC 8100, DOI 10.17487/RFC8100, 1581 March 2017, . 1583 10.2. Informative References 1585 [I-D.ietf-tsvwg-le-phb] 1586 Bless, R., "A Lower Effort Per-Hop Behavior (LE PHB)", 1587 draft-ietf-tsvwg-le-phb-02 (work in progress), June 2017. 1589 [IEEE.802-11u.2011] 1590 "Information technology - Telecommunications and 1591 information exchange between systems - Local and 1592 metropolitan area networks - Specific requirements - Part 1593 11: Wireless LAN Medium Access Control (MAC) and Physical 1594 Layer (PHY) specifications", IEEE Standard 802.11, 2011, 1595 . 1598 [RFC7561] Kaippallimalil, J., Pazhyannur, R., and P. Yegani, 1599 "Mapping Quality of Service (QoS) Procedures of Proxy 1600 Mobile IPv6 (PMIPv6) and WLAN", RFC 7561, 1601 DOI 10.17487/RFC7561, June 2015, 1602 . 1604 Appendix A. Change Log 1606 Initial Version: July 2015 1608 Authors' Addresses 1610 Tim Szigeti 1611 Cisco Systems 1612 Vancouver, British Columbia V6K 3L4 1613 Canada 1615 Email: szigeti@cisco.com 1617 Jerome Henry 1618 Cisco Systems 1619 Research Triangle Park, North Carolina 27709 1620 USA 1622 Email: jerhenry@cisco.com 1624 Fred Baker 1625 Santa Barbara, California 93117 1626 USA 1628 Email: FredBaker.IETF@gmail.com