idnits 2.17.1 draft-ietf-tsvwg-ieee-802-11-07.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 use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (September 8, 2017) is 2422 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.802.11-2016' ** Obsolete normative reference: RFC 3662 (Obsoleted by RFC 8622) ** Downref: Normative reference to an Informational RFC: RFC 4594 == Outdated reference: A later version (-10) exists of draft-ietf-tsvwg-le-phb-02 Summary: 2 errors (**), 0 flaws (~~), 3 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: March 12, 2018 F. Baker 6 September 8, 2017 8 Diffserv to IEEE 802.11 Mapping 9 draft-ietf-tsvwg-ieee-802-11-07 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 https://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 March 12, 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 (https://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", and "OPTIONAL" in this 237 document are to be interpreted as described in [RFC2119]. 239 1.6. Terminology Used in this Document 241 Key terminology used in this document includes: 243 AC: Access Category. A label for the common set of enhanced 244 distributed channel access (EDCA) parameters that are used by a 245 quality-of-service (QoS) station (STA) to contend for the channel 246 in order to transmit medium access control (MAC) service data 247 units (MSDUs) with certain priorities. [IEEE.802.11-2016] 248 Section 3.2. 250 AIFS: Arbitration Interframe Space. Interframe space used by QoS 251 stations before transmission of data and other frame types defined 252 by [IEEE.802.11-2016] Section 10.3.2.3.6. 254 AP: Access Point. An entity that contains one station (STA) and 255 provides access to the distribution services, via the wireless 256 medium (WM) for associated STAs. An AP comprises a STA and a 257 distribution system access function (DSAF) [IEEE.802.11-2016] 258 Section 3.1. 260 BSS: Basic Service Set. Informally, a wireless cell; formally, a 261 set of stations that have successfully synchronized using the JOIN 262 service primitives and one STA that has used the START primitive. 263 Alternatively, a set of STAs that have used the START primitive 264 specifying matching mesh profiles where the match of the mesh 265 profiles has been verified via the scanning procedure. Membership 266 in a BSS does not imply that wireless communication with all other 267 members of the BSS is possible. Defined in [IEEE.802.11-2016] 268 Section 3.1. 270 Contention Window: See CW. 272 CSMA/CA: Carrier Sense Multiple Access with Collision Avoidance. 273 A media access control method in which carrier sensing is used, 274 but nodes attempt to avoid collisions by transmitting only when 275 the channel is sensed to be "idle". When these do transmit, nodes 276 transmit their packet data in its entirety. 278 CSMA/CD: Carrier Sense Multiple Access with Collision Detection. 279 A media access control method (used most notably in early Ethernet 280 technology) for local area networking. It uses a carrier-sensing 281 scheme in which a transmitting station detects collisions by 282 sensing transmissions from other stations while transmitting a 283 frame. When this collision condition is detected, the station 284 stops transmitting that frame, transmits a jam signal, and then 285 waits for a random time interval before trying to resend the 286 frame. 288 CW: Contention Window. Limits a CWMin and CWMax, from which a 289 random backoff is computed. 291 CWMax: Contention Window Maximum. The maximum value (in unit of 292 Slot Time) that a contention window can take. 294 CWMin: Contention Window Minimum. The minimum value that a 295 contention window can take. 297 DCF: Distributed Coordinated Function. A class of coordination 298 function where the same coordination function logic is active in 299 every station (STA) in the basic service set (BSS) whenever the 300 network is in operation. 302 DIFS: Distributed (Coordination Function) Interframe Space. A 303 unit of time during which the medium has to be detected as idle 304 before a station should attempt to send frames, as per 305 [IEEE.802.11-2016] Section 10.3.2.3.5. 307 DSCP: Differentiated Service Code Point [RFC2474] and [RFC2475]. 308 The DSCP is carried in the first 6 bits of the IPv4 and IPv6 Type 309 of Service (TOS) Byte (the remaining 2 bits are used for IP 310 Explicit Congestion Notification [RFC3168]). 312 HCF: Hybrid Coordination Function A coordination function that 313 combines and enhances aspects of the contention based and 314 contention free access methods to provide quality-of-service (QoS) 315 stations (STAs) with prioritized and parameterized QoS access to 316 the wireless medium (WM), while continuing to support non-QoS STAs 317 for best-effort transfer. [IEEE.802.11-2016] Section 3.1. 319 IFS: Interframe Space. Period of silence between transmissions 320 over 802.11 networks. [IEEE.802.11-2016] describes several types 321 of Interframe Spaces. 323 Random Backoff Timer: A pseudorandom integer period of time (in 324 units of Slot Time) over the interval (0,CW), where CWmin is-less- 325 than-or-equal-to CW, which in turn is less-than-or-equal-to CWMax. 326 Stations desiring to initiate transfer of data frames and-or 327 Management frames using the DCF shall invoke the carrier sense 328 mechanism to determine the busy-or-idle state of the medium. If 329 the medium is busy, the STA shall defer until the medium is 330 determined to be idle without interruption for a period of time 331 equal to DIFS when the last frame detected on the medium was 332 received correctly, or after the medium is determined to be idle 333 without interruption for a period of time equal to EIFS when the 334 last frame detected on the medium was not received correctly. 335 After this DIFS or EIFS medium idle time, the STA shall then 336 generate a random backoff period for an additional deferral time 337 before transmitting. [IEEE.802.11-2016] Section 10.3.3. 339 RF: Radio Frequency. 341 SIFS: Short Interframe Space. An IFS used before transmission of 342 specific frames as defined in [IEEE.802.11-2016] 343 Section 10.3.2.3.3. 345 Slot Time: A unit of time used to count time intervals in 802.11 346 networks, and defined in [IEEE.802.11-2016] Section 10.3.2.13. 348 Trust: From a QoS-perspective, trust refers to the accepting of 349 the QoS markings of a packet by a network device. Trust is 350 typically extended at Layer 3 (by accepting the DSCP), but may 351 also be extended at lower layers, such as at Layer 2 by accepting 352 User Priority markings. For example, if an access point is 353 configured to trust DSCP markings and it receives a packet marked 354 EF, then it would treat the packet with the Expedite Forwarding 355 PHB and propagate the EF marking value (DSCP 46) as it transmits 356 the packet. Alternatively, if a network device is configured to 357 operate in an untrusted manner, then it would remark packets as 358 these entered the device, typically to DF (or to a different 359 marking value at the network administrator's preference). Note: 360 The terms "trusted" and "untrusted" are used extensively in 361 [RFC4594]. 363 UP: User Priority. A value associated with a medium access 364 control (MAC) service data unit (MSDU) that indicates how the MSDU 365 is to be handled. The UP is assigned to an MSDU in the layers 366 above the MAC [IEEE.802.11-2016] Section 3.1. The UP defines a 367 level of priority for the associated frame, on a scale of 0 to 7. 369 Wi-Fi: An interoperability certification defined by the Wi-Fi 370 Alliance. However, this term is commonly used, including in the 371 present document, to be the equivalent of IEEE 802.11. 373 2. Service Comparison and Default Interoperation of Diffserv and IEEE 374 802.11 376 (Section 6 provides a brief overview of IEEE 802.11 QoS.) 378 The following comparisons between IEEE 802.11 and Diffserv services 379 should be noted: 381 o [IEEE.802.11-2016] does not support an EF PHB service [RFC3246], 382 as it is not possible to assure that a given access category will 383 be serviced with strict priority over another (due to the random 384 element within the contention process) 386 o [IEEE.802.11-2016] does not support an AF PHB service [RFC2597], 387 again because it is not possible to assure that a given access 388 category will be serviced with a minimum amount of assured 389 bandwidth (due to the non-deterministic nature of the contention 390 process) 392 o [IEEE.802.11-2016] loosely supports a [RFC2474] Default Forwarding 393 service via the Best Effort Access Category (AC_BE) 395 o [IEEE.802.11-2016] loosely supports a [RFC3662] Lower Effort PDB 396 service via the Background Access Category (AC_BK) 398 As such, these high-level considerations should be kept in mind when 399 mapping from Diffserv to [IEEE.802.11-2016] (and vice-versa); 400 however, access points may or may not always be positioned at 401 Diffserv domain boundaries, as will be discussed next. 403 2.1. Diffserv Domain Boundaries 405 It is important to recognize that the wired-to-wireless edge may or 406 may not function as an edge of a Diffserv domain or a domain 407 boundary. 409 In most commonly-deployed WLAN models, the wireless access point 410 represents not only the edge of the Diffserv domain, but also the 411 edge of the network infrastructure itself. As such, only client 412 endpoint devices (and no network infrastructure devices) are 413 downstream from the access points in these deployment models. Note: 414 security considerations and recommendations for hardening such Wifi- 415 at-the-edge deployment models are detailed in Section 8; these 416 recommendations include mapping network control protocols (which are 417 not used downstream from the AP in this deployment model) to UP 0. 419 Alternatively, in other deployment models, such as Wi-Fi backhaul, 420 wireless mesh infrastructures, wireless AP-to-AP deployments, or in 421 cases where a Wi-Fi link connects to a device providing service via 422 another technology (e.g. Wi-Fi to Bluetooth or Zigbee router), the 423 wireless access point extends the network infrastructure and thus, 424 typically, the Diffserv domain. In such deployments, both client 425 devices and infrastructure devices may be expected downstream from 426 the access points, and as such network control protocols are 427 recommended to be mapped to UP 7 in this deployment model, as is 428 discussed in Section 4.1.1. 430 Thus, as can be seen from these two examples, the QoS treatment of 431 packets at the access point will depend on the position of the AP in 432 the network infrastructure and on the WLAN deployment model. 434 However, regardless of the access point being at the Diffserv 435 boundary or not, Diffserv to [IEEE.802.11-2016] (and vice-versa) 436 marking-specific incompatibilities exist that must be reconciled, as 437 will be discussed next. 439 2.2. Default DSCP-to-UP Mappings and Conflicts 441 While no explicit guidance is offered in mapping (6-Bit) Layer 3 DSCP 442 values to (3-Bit) Layer 2 markings (such as IEEE 802.1D, 802.1p or 443 802.11e), a common practice in the networking industry is to map 444 these by what we will refer to as 'Default DSCP-to-UP Mapping' (for 445 lack of a better term), wherein the 3 Most Significant Bits (MSB) of 446 the DSCP are used as the corresponding L2 markings. 448 Note: There are mappings provided in [IEEE.802.11-2016] Annex V 449 Tables V-1 and V2, but it bears mentioning that these mappings are 450 provided as examples (as opposed to explicit recommendations). 451 Furthermore, some of these mappings do not align with the intent and 452 recommendations expressed in [RFC4594], as will be discussed in this 453 and the following section (Section 2.3). 455 However, when this default DSCP-to-UP mapping method is applied to 456 packets marked per [RFC4594] recommendations and destined to 802.11 457 WLAN clients, it will yield a number of inconsistent QoS mappings, 458 specifically: 460 o Voice (EF-101110) will be mapped to UP 5 (101), and treated in the 461 Video Access Category (AC_VI), rather than the Voice Access 462 Category (AC_VO), for which it is intended 464 o Multimedia Streaming (AF3-011xx0) will be mapped to UP3 (011) and 465 treated in the Best Effort Access Category (AC_BE), rather than 466 the Video Access Category (AC_VI), for which it is intended 468 o Broadcast Video (CS3-011000) will be mapped to UP3 (011) and 469 treated in the Best Effort Access Category (AC_BE), rather than 470 the Video Access Category (AC_VI), for which it is intended 472 o OAM traffic (CS2-010000) will be mapped to UP 2 (010) and treated 473 in the Background Access Category (AC_BK), which is not the intent 474 expressed in [RFC4594] for this service class 476 It should also be noted that while [IEEE.802.11-2016] defines an 477 intended use for each access category through the AC naming 478 convention (for example, UP 6 and UP 7 belong to AC_VO, the Voice 479 Access Category), [IEEE.802.11-2016] does not: 481 o define how upper layer markings (such as DSCP) should map to UPs 482 (and hence to ACs) 484 o define how UPs should translate to other medium Layer 2 QoS 485 markings 487 o strictly restrict each access category to applications reflected 488 in the AC name 490 2.3. Default UP-to-DSCP Mappings and Conflicts 492 In the opposite direction of flow (the upstream direction, that is, 493 from wireless-to-wired), many APs use what we will refer to as 494 'Default UP-to-DSCP Mapping' (for lack of a better term), wherein 495 DSCP values are derived from UP values by multiplying the UP values 496 by 8 (i.e. shifting the 3 UP bits to the left and adding three 497 additional zeros to generate a DSCP value). This derived DSCP value 498 is then used for QoS treatment between the wireless access point and 499 the nearest classification and marking policy enforcement point 500 (which may be the centralized wireless LAN controller, relatively 501 deep within the network). Alternatively, in the case where there is 502 no other classification and marking policy enforcement point, then 503 this derived DSCP value will be used on the remainder of the Internet 504 path. 506 It goes without saying that when 6 bits of marking granularity are 507 derived from 3, then information is lost in translation. Servicing 508 differentiation cannot be made for 12 classes of traffic (as 509 recommended in [RFC4594]), but for only 8 (with one of these classes 510 being reserved for future use (i.e. UP 7 which maps to DSCP CS7). 512 Such default upstream mapping can also yield several inconsistencies 513 with [RFC4594], including: 515 o Mapping UP 6 ([RFC4594] Voice) to CS6, which [RFC4594] recommends 516 for Network Control 518 o Mapping UP 4 ([RFC4594] Multimedia Conferencing and/or Real-Time 519 Interactive) to CS4, thus losing the ability to differentiate 520 between these two distinct service classes, as recommended in 521 [RFC4594] Sections 4.3 and 4.4 523 o Mapping UP 3 ([RFC4594] Multimedia Streaming and/or Broadcast 524 Video) to CS3, thus losing the ability to differentiate between 525 these two distinct service classes, as recommended in [RFC4594] 526 Sections 4.5 and 4.6 528 o Mapping UP 2 ([RFC4594] Low-Latency Data and/or OAM) to CS2, thus 529 losing the ability to differentiate between these two distinct 530 service classes, as recommended in [RFC4594] Sections 4.7 and 3.3, 531 and possibly overwhelming the queues provisioned for OAM (which is 532 typically lower in capacity [being network control traffic], as 533 compared to Low-Latency Data queues [being user traffic]) 535 o Mapping UP 1 ([RFC4594] High-Throughput Data and/or Low-Priority 536 Data) to CS1, thus losing the ability to differentiate between 537 these two distinct service classes, as recommended in [RFC4594] 538 Sections 4.8 and 4.10, and causing legitimate business-relevant 539 High-Throughput Data to receive a [RFC3662] Lower Effort PDB, for 540 which it is not intended 542 The following sections address these limitations and concerns in 543 order to reconcile [RFC4594] and [IEEE.802.11-2016]. First 544 downstream (wired-to-wireless) DSCP-to-UP mappings will be aligned 545 and then upstream (wireless-to-wired) models will be addressed. 547 3. Wireless Device Marking and Mapping Capability Recommendations 549 This document assumes and RECOMMENDS that all wireless access points 550 (as the bridges between wired-and-wireless networks) support the 551 ability to: 553 o mark DSCP, per Diffserv standards 555 o mark UP, per the [IEEE.802.11-2016] standard 557 o support fully-configurable mappings between DSCP and UP 559 o process DSCP markings set by wireless endpoint devices 561 This document further assumes and RECOMMENDS that all wireless 562 endpoint devices support the ability to: 564 o mark DSCP, per Diffserv standards 566 o mark UP, per the [IEEE.802.11-2016] standard 568 o support fully-configurable mappings between DSCP (set by 569 applications in software) and UP (set by the operating system and/ 570 or wireless network interface hardware drivers) 572 Having made the assumptions and recommendations above, it bears 573 mentioning while the mappings presented in this document are 574 RECOMMENDED to replace the current common default practices (as 575 discussed in Section 2.2 and Section 2.3), these mapping 576 recommendations are not expected to fit every last deployment model, 577 and as such MAY be overridden by network administrators, as needed. 579 4. DSCP-to-UP Mapping Recommendations 581 The following section specifies downstream (wired-to-wireless) 582 mappings between [RFC4594] Configuration Guidelines for Diffserv 583 Service Classes and [IEEE.802.11-2016]. As such, this section draws 584 heavily from [RFC4594], including service class definitions and 585 recommendations. 587 This section assumes [IEEE.802.11-2016] wireless access points and/or 588 WLAN controllers that support customizable, non-default DSCP-to-UP 589 mapping schemes. 591 This section also assumes that [IEEE.802.11-2016] access points and 592 endpoint devices differentiate UP markings with corresponding queuing 593 and dequeuing treatments. To illustrate, [IEEE.802.11-2016] displays 594 a reference implementation model in Figure 10-24 which depicts four 595 transmit queues, one per access category. In practical 596 implementations, however, it is common for WLAN network equipment 597 vendors to implement dedicated transmit queues on a per-UP (versus a 598 per access category) basis, which are then dequeued into their 599 associated access category in a preferred (or even in a strict 600 priority manner). For example, it is common for vendors to dequeue 601 UP 5 ahead of UP 4 to the hardware performing the EDCA function 602 (EDCAF) for the Video Access Category (AC_VI). As such, Signaling 603 traffic (marked UP 5, per the recommendations made in Section 4.2.2) 604 may benefit from such a treatment versus other video flows in the 605 same access category which are marked to UP 4 (in addition to a 606 preferred treatment over flows in the Best Effort and Background 607 access categories). 609 4.1. Network Control Traffic 611 Network control traffic is defined as packet flows that are essential 612 for stable operation of the administered network [RFC4594] Section 3. 613 Network control traffic is different from user application control 614 (signaling) that may be generated by some applications or services. 615 Network control traffic MAY be split into two service classes: 617 o Network Control, and 619 o Operations Administration and Management (OAM) 621 4.1.1. Network Control Protocols 623 The Network Control service class is used for transmitting packets 624 between network devices (e.g. routers) that require control (routing) 625 information to be exchanged between nodes within the administrative 626 domain, as well as across a peering point between different 627 administrative domains. 629 The RECOMMENDED DSCP marking for Network Control is CS6, per 630 [RFC4594] Section 3.2; additionally, CS7 DSCP value SHOULD be 631 reserved for future use, potentially for future routing or control 632 protocols, again, per [RFC4594] Section 3.2. 634 By default (as described in Section 2.2), packets marked DSCP CS7 635 will be mapped to UP 7 and serviced within the Voice Access Category 636 (AC_VO). This represents the RECOMMENDED mapping for CS7, that is, 637 packets marked to CS7 DSCP are RECOMMENDED to be mapped to UP 7. 639 However, by default (as described in Section 2.2), packets marked 640 DSCP CS6 will be mapped to UP 6 and serviced within the Voice Access 641 Category (AC_VO); such mapping and servicing is a contradiction to 642 the intent expressed in [RFC4594] Section 3.2. As such, it is 643 RECOMMENDED to map Network Control traffic marked CS6 to UP 7 (per 644 [IEEE.802.11-2016] Section 10.2.4.2, Table 10-1), thereby admitting 645 it to the Voice Access Category (AC_VO), albeit with a marking 646 distinguishing it from (data-plane) voice traffic. 648 It should be noted that encapsulated routing protocols for 649 encapsulated or overlay networks (e.g., VPN, NVO3) are not network 650 control traffic for any physical network at the AP, and hence SHOULD 651 NOT be marked with CS6 in the first place. 653 Addtionally, and as previously noted, the Security Considerations 654 section (Section 8) contains additional recommendations for hardening 655 Wifi-at-the-edge deployment models, where, for example, network 656 control protocols are not expected to be sent nor recevied between 657 APs and downstream endpoint client devices. 659 4.1.2. Operations Administration Management (OAM) 661 The OAM (Operations, Administration, and Management) service class is 662 RECOMMENDED for OAM&P (Operations, Administration, and Management and 663 Provisioning). The RECOMMENDED DSCP marking for OAM is CS2, per 664 [RFC4594] Section 3.3. 666 By default (as described in Section 2.2), packets marked DSCP CS2 667 will be mapped to UP 2 and serviced with the Background Access 668 Category (AC_BK). Such servicing is a contradiction to the intent 669 expressed in [RFC4594] Section 3.3. As such, it is RECOMMENDED that 670 a non-default mapping be applied to OAM traffic, such that CS2 DSCP 671 is mapped to UP 0, thereby admitting it to the Best Effort Access 672 Category (AC_BE). 674 4.2. User Traffic 676 User traffic is defined as packet flows between different users or 677 subscribers. It is the traffic that is sent to or from end-terminals 678 and that supports a very wide variety of applications and services 679 [RFC4594] Section 4. 681 Network administrators can categorize their applications according to 682 the type of behavior that they require and MAY choose to support all 683 or a subset of the defined service classes. 685 4.2.1. Telephony 687 The Telephony service class is RECOMMENDED for applications that 688 require real-time, very low delay, very low jitter, and very low 689 packet loss for relatively constant-rate traffic sources (inelastic 690 traffic sources). This service class SHOULD be used for IP telephony 691 service. The fundamental service offered to traffic in the Telephony 692 service class is minimum jitter, delay, and packet loss service up to 693 a specified upper bound. The RECOMMENDED DSCP marking for Telephony 694 is EF ([RFC4594] Section 4.1). 696 Traffic marked to DSCP EF will map by default (as described in 697 Section 2.2) to UP 5, and thus to the Video Access Category (AC_VI), 698 rather than to the Voice Access Category (AC_VO), for which it is 699 intended. Therefore, a non-default DSCP-to-UP mapping is 700 RECOMMENDED, such that EF DSCP is mapped to UP 6, thereby admitting 701 it into the Voice Access Category (AC_VO). 703 Similarly, the [RFC5865] VOICE-ADMIT DSCP (44/101100) is RECOMMENDED 704 to be mapped to UP 6, thereby admitting it also into the Voice Access 705 Category (AC_VO). 707 4.2.2. Signaling 709 The Signaling service class is RECOMMENDED for delay-sensitive 710 client-server (e.g. traditional telephony) and peer-to-peer 711 application signaling. Telephony signaling includes signaling 712 between IP phone and soft-switch, soft-client and soft-switch, and 713 media gateway and soft-switch as well as peer-to-peer using various 714 protocols. This service class is intended to be used for control of 715 sessions and applications. The RECOMMENDED DSCP marking for 716 Signaling is CS5 ([RFC4594] Section 4.2). 718 While Signaling is RECOMMENDED to receive a superior level of service 719 relative to the default class (i.e. AC_BE), it does not require the 720 highest level of service (i.e. AC_VO). This leaves only the Video 721 Access Category (AC_VI), which it will map to by default (as 722 described in Section 2.2). Therefore it is RECOMMENDED to map 723 Signaling traffic marked CS5 DSCP to UP 5, thereby admitting it to 724 the Video Access Category (AC_VI). 726 Note: Signaling traffic is not control plane traffic from the 727 perspective of the network (but rather is data plane traffic); as 728 such, it does not merit provisioning in the Network Control service 729 class (marked CS6 and mapped to UP 6). However, Signaling traffic is 730 control-plane traffic from the perspective of the voice/video 731 telephony overlay-infrastructure. As such, Signaling should be 732 treated with preferential servicing vs. other data plane flows. One 733 way this may be achieved in certain WLAN deployments is by mapping 734 Signaling traffic marked CS5 to UP 5 (as recommended above and 735 following the EDCAF treatment logic described in Section 4. 737 4.2.3. Multimedia Conferencing 739 The Multimedia Conferencing service class is RECOMMENDED for 740 applications that require real-time service for rate-adaptive 741 traffic. The RECOMMENDED DSCP markings for Multimedia Conferencing 742 are AF41, AF42 and AF43 ([RFC4594] Section 4.3). 744 The primary media type typically carried within the Multimedia 745 Conferencing service class is video; as such, it is RECOMMENDED to 746 map this class into the Video Access Category, which it does by 747 default (as described in Section 2.2). Specifically, it is 748 RECOMMENDED to map AF41, AF42 and AF43 to UP 4, thereby admitting 749 Multimedia Conferencing into the Video Access Category (AC_VI). 751 4.2.4. Real-Time Interactive 753 The Real-Time Interactive service class is RECOMMENDED for 754 applications that require low loss and jitter and very low delay for 755 variable rate inelastic traffic sources. Such applications may 756 include inelastic video-conferencing applications, but may also 757 include gaming applications (as pointed out in [RFC4594] Sections 2.1 758 through 2.3, and Section 4.4). The RECOMMENDED DSCP marking for 759 Real-Time Interactive traffic is CS4 ([RFC4594] Section 4.4). 761 The primary media type typically carried within the Real-Time 762 Interactive service class is video; as such, it is RECOMMENDED to map 763 this class into the Video Access Category, which it does by default 764 (as described in Section 2.2). Specifically, it is RECOMMENDED to 765 map CS4 to UP 4, thereby admitting Real-Time Interactive traffic into 766 the Video Access Category (AC_VI). 768 4.2.5. Multimedia-Streaming 770 The Multimedia Streaming service class is RECOMMENDED for 771 applications that require near-real-time packet forwarding of 772 variable rate elastic traffic sources. Typically these flows are 773 unidirectional. The RECOMMENDED DSCP markings for Multimedia 774 Streaming are AF31, AF32 and AF33 ([RFC4594] Section 4.5). 776 The primary media type typically carried within the Multimedia 777 Streaming service class is video; as such, it is RECOMMENDED to map 778 this class into the Video Access Category, which it will by default 779 (as described in Section 2.2). Specifically, it is RECOMMENDED to 780 map AF31, AF32 and AF33 to UP 4, thereby admitting Multimedia 781 Streaming into the Video Access Category (AC_VI). 783 4.2.6. Broadcast Video 785 The Broadcast Video service class is RECOMMENDED for applications 786 that require near-real-time packet forwarding with very low packet 787 loss of constant rate and variable rate inelastic traffic sources. 788 Typically these flows are unidirectional. The RECOMMENDED DSCP 789 marking for Broadcast Video is CS3 ([RFC4594] Section 4.6). 791 As directly implied by the name, the primary media type typically 792 carried within the Broadcast Video service class is video; as such, 793 it is RECOMMENDED to map this class into the Video Access Category; 794 however, by default (as described in Section 2.2), this service class 795 will map to UP 3, and thus the Best Effort Access Category (AC_BE). 796 Therefore, a non-default mapping is RECOMMENDED, such that CS4 maps 797 to UP 4, thereby admitting Broadcast Video into the Video Access 798 Category (AC_VI). 800 4.2.7. Low-Latency Data 802 The Low-Latency Data service class is RECOMMENDED for elastic and 803 time-sensitive data applications, often of a transactional nature, 804 where a user is waiting for a response via the network in order to 805 continue with a task at hand. As such, these flows are considered 806 foreground traffic, with delays or drops to such traffic directly 807 impacting user-productivity. The RECOMMENDED DSCP markings for Low- 808 Latency Data are AF21, AF22 and AF23 ([RFC4594] Section 4.7). 810 By default (as described in Section 2.2), Low-Latency Data will map 811 to UP 2 and thus to the Background Access Category (AC_BK), which is 812 contrary to the intent expressed in [RFC4594]. 814 In line with the assumption made in Section 4, mapping Low-Latency 815 Data to UP 3 may allow such to receive a superior level of service 816 via transmit queues servicing the EDCAF hardware for the Best Effort 817 Access Category (AC_BE). Therefore it is RECOMMENDED to map Low- 818 Latency Data traffic marked AF2x DSCP to UP 3, thereby admitting it 819 to the Best Effort Access Category (AC_BE). 821 4.2.8. High-Throughput Data 823 The High-Throughput Data service class is RECOMMENDED for elastic 824 applications that require timely packet forwarding of variable rate 825 traffic sources and, more specifically, is configured to provide 826 efficient, yet constrained (when necessary) throughput for TCP 827 longer-lived flows. These flows are typically non-user-interactive. 828 Per [RFC4594]-Section 4.8, it can be assumed that this class will 829 consume any available bandwidth and that packets traversing congested 830 links may experience higher queuing delays or packet loss. It is 831 also assumed that this traffic is elastic and responds dynamically to 832 packet loss. The RECOMMENDED DSCP markings for High-Throughput Data 833 are AF11, AF12 and AF13 ([RFC4594] Section 4.8). 835 By default (as described in Section 2.2), High-Throughput Data will 836 map to UP 1 and thus to the Background Access Category (AC_BK), which 837 is contrary to the intent expressed in [RFC4594]. 839 Unfortunately, there really is no corresponding fit for the High- 840 Throughput Data service class within the constrained 4 Access 841 Category [IEEE.802.11-2016] model. If the High-Throughput Data 842 service class is assigned to the Best Effort Access Category (AC_BE), 843 then it would contend with Low-Latency Data (while [RFC4594] 844 recommends a distinction in servicing between these service classes) 845 as well as with the default service class; alternatively, if it is 846 assigned to the Background Access Category (AC_BK), then it would 847 receive a less-then-best-effort service and contend with Low-Priority 848 Data (as discussed in Section 4.2.10). 850 As such, since there is no directly corresponding fit for the High- 851 Throughout Data service class within the [IEEE.802.11-2016] model, it 852 is generally RECOMMENDED to map High-Throughput Data to UP 0, thereby 853 admitting it to the Best Effort Access Category (AC_BE). 855 4.2.9. Standard Service Class 857 The Standard service class is RECOMMENDED for traffic that has not 858 been classified into one of the other supported forwarding service 859 classes in the Diffserv network domain. This service class provides 860 the Internet's "best-effort" forwarding behavior. The RECOMMENDED 861 DSCP marking for the Standard Service Class is DF. ([RFC4594] 862 Section 4.9) 864 The Standard Service Class loosely corresponds to the 865 [IEEE.802.11-2016] Best Effort Access Category (AC_BE) and therefore 866 it is RECOMMENDED to map Standard Service Class traffic marked DF 867 DSCP to UP 0, thereby admitting it to the Best Effort Access Category 868 (AC_BE). This happens to correspond to the default mapping (as 869 described in Section 2.2). 871 4.2.10. Low-Priority Data 873 The Low-Priority Data service class serves applications that the user 874 is willing to accept without service assurances. This service class 875 is specified in [RFC3662] and [I-D.ietf-tsvwg-le-phb]. 877 The Low-Priority Data service class loosely corresponds to the 878 [IEEE.802.11-2016] Background Access Category (AC_BK) and therefore 879 it is RECOMMENDED to map Low-Priority Data traffic marked CS1 DSCP to 880 UP 1, thereby admitting it to the Background Access Category (AC_BK). 881 This happens to correspond to the default mapping (as described in 882 Section 2.2). 884 4.3. DSCP-to-UP Mapping Recommendations Summary 886 Figure 1 summarizes the [RFC4594] DSCP marking recommendations mapped 887 to [IEEE.802.11-2016] UP and access categories applied in the 888 downstream direction (i.e. from wired-to-wireless networks). 890 +------------------------------------------------------------------+ 891 | IETF Diffserv | PHB |Reference| IEEE 802.11 | 892 | Service Class | | RFC |User Priority| Access Category | 893 |===============+======+=========+=============+====================| 894 | | | | 7 | AC_VO (Voice) | 895 |Network Control| CS7 | RFC2474 | OR | 896 |(reserved for | | | 0 | AC_BE (Best Effort)| 897 | future use) | | |See Security Considerations-Sec.8 | 898 +---------------+------+---------+-------------+--------------------+ 899 | | | | 7 | AC_VO (Voice) | 900 |Network Control| CS6 | RFC2474 | OR | 901 | | | | 0 | AC_BE (Best Effort)| 902 | | | |See Security Considerations-Sec.8 | 903 +---------------+------+---------+-------------+--------------------+ 904 | Telephony | EF | RFC3246 | 6 | AC_VO (Voice) | 905 +---------------+------+---------+-------------+--------------------+ 906 | VOICE-ADMIT | VA | RFC5865 | 6 | AC_VO (Voice) | 907 | | | | | | 908 +---------------+------+---------+-------------+--------------------+ 909 | Signaling | CS5 | RFC2474 | 5 | AC_VI (Video) | 910 +---------------+------+---------+-------------+--------------------+ 911 | Multimedia | AF41 | | | | 912 | Conferencing | AF42 | RFC2597 | 4 | AC_VI (Video) | 913 | | AF43 | | | | 914 +---------------+------+---------+-------------+--------------------+ 915 | Real-Time | CS4 | RFC2474 | 4 | AC_VI (Video) | 916 | Interactive | | | | | 917 +---------------+------+---------+-------------+--------------------+ 918 | Multimedia | AF31 | | | | 919 | Streaming | AF32 | RFC2597 | 4 | AC_VI (Video) | 920 | | AF33 | | | | 921 +---------------+------+---------+-------------+--------------------+ 922 |Broadcast Video| CS3 | RFC2474 | 4 | AC_VI (Video) | 923 +---------------+------+---------+-------------+--------------------+ 924 | Low- | AF21 | | | | 925 | Latency | AF22 | RFC2597 | 3 | AC_BE (Best Effort)| 926 | Data | AF23 | | | | 927 +---------------+------+---------+-------------+--------------------+ 928 | OAM | CS2 | RFC2474 | 0 | AC_BE (Best Effort)| 929 +---------------+------+---------+-------------+--------------------+ 930 | High- | AF11 | | | | 931 | Throughput | AF12 | RFC2597 | 0 | AC_BE (Best Effort)| 932 | Data | AF13 | | | | 933 +---------------+------+---------+-------------+--------------------+ 934 | Standard | DF | RFC2474 | 0 | AC_BE (Best Effort)| 935 +---------------+------+---------+-------------+--------------------+ 936 | Low-Priority | CS1 | RFC3662 | 1 | AC_BK (Background) | 937 | Data | | | | | 938 +-------------------------------------------------------------------+ 940 Note: All unusued codepoints are recommended to be mapped to UP 0 941 (See Security Considerations Section - Section 8) 943 Figure 1: Summary of Downstream DSCP to IEEE 802.11 UP and AC Mapping 944 Recommendations 946 5. Upstream Mapping and Marking Recommendations 948 In the upstream direction (i.e. wireless-to-wired), there are three 949 types of mapping that may be implemented: 951 o DSCP-to-UP mapping within the wireless client operating system, 952 and 954 o UP-to-DSCP mapping at the wireless access point, or 955 o DSCP-Passthrough at the wireless access point (effectively a 1:1 956 DSCP-to-DSCP mapping) 958 As an alternative to the latter two options, the network 959 administrator MAY choose to use the wireless-to-wired edge as a 960 Diffserv boundary and explicitly set (or reset) DSCP markings 961 according to administrative policy, thus making the wireless edge a 962 Diffserv policy enforcement point. This is RECOMMENDED whenever 963 supported. 965 Each of these options will now be considered. 967 5.1. Upstream DSCP-to-UP Mapping within the Wireless Client Operating 968 System 970 Some operating systems on wireless client devices utilize a similar 971 default DSCP-to-UP mapping scheme as described in Section 2.2. As 972 such, this can lead to the same conflicts as described in that 973 section, but in the upstream direction. 975 Therefore, to improve on these default mappings, and to achieve 976 parity and consistency with downstream QoS, it is RECOMMENDED that 977 wireless client operating systems utilize instead the same DSCP-to-UP 978 mapping recommendations presented in Section 4, with the explicit 979 RECOMMENDATION that packets requesting a marking of CS6 or CS7 DSCP 980 SHOULD be mapped to UP 0 (and not to UP 7). Furthermore, in such 981 cases the wireless client operating system SHOULD remark such packets 982 to DSCP 0. This is because CS6 and CS7 DSCP, as well as UP 7 983 markings, are intended for network control protocols and these SHOULD 984 NOT be sourced from wireless client endpoint devices. This 985 recommendation is detailed in the Security Considerations section 986 (Section 8). 988 5.2. Upstream UP-to-DSCP Mapping at the Wireless Access Point 990 UP-to-DSCP mapping generates a DSCP value for the IP packet (either 991 an unencapsulated IP packet or an IP packet encapsulated within a 992 tunneling protocol such as CAPWAP - and destined towards a wireless 993 LAN controller for decapsulation and forwarding) from the Layer 2 994 [IEEE.802.11-2016] UP marking. This is typically done in the manner 995 described in Section 2.3. 997 It should be noted that any explicit remarking policy to be performed 998 on such a packet only takes place at the nearest classification and 999 marking policy enforcement point, which may be: 1001 o At the wireless access point 1002 o At the wired network switch port 1004 o At the wireless LAN controller 1006 As such, UP-to-DSCP mapping allows for wireless L2 markings to affect 1007 the QoS treatment of a packet over the wired IP network (that is, 1008 until the packet reaches the nearest classification and marking 1009 policy enforcement point). 1011 It should be further noted that nowhere in the [IEEE.802.11-2016] 1012 specifications is there an intent expressed for UP markings to be 1013 used to influence QoS treatment over wired IP networks. Furthermore, 1014 [RFC2474], [RFC2475] and [RFC8100] all allow for the host to set DSCP 1015 markings for end-to-end QoS treatment over IP networks. Therefore, 1016 it is NOT RECOMMENDED that wireless access points leverage Layer 2 1017 [IEEE.802.11-2016] UP markings as set by wireless hosts and 1018 subsequently perform a UP-to-DSCP mapping in the upstream direction, 1019 but rather, if wireless host markings are to be leveraged (as per 1020 business requirements, technical constraints and administrative 1021 policies), then it is RECOMMENDED to pass through the Layer 3 DSCP 1022 markings set by these wireless hosts instead, as is discussed in the 1023 next section. 1025 5.3. Upstream DSCP-Passthrough at the Wireless Access Point 1027 It is generally NOT RECOMMENDED to pass through DSCP markings from 1028 unauthenticated and unauthorized devices, as these are typically 1029 considered untrusted sources. 1031 When business requirements and/or technical constraints and/or 1032 administrative policies require QoS markings to be passed through at 1033 the wireless edge, then it is RECOMMENDED to pass through Layer 3 1034 DSCP markings (over Layer 2 [IEEE.802.11-2016] UP markings) in the 1035 upstream direction, with the exception of CS6 and CS7 (as will be 1036 discussed further), 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 CS6 and CS7 are exceptions to this pass through recommendation 1064 because wireless hosts SHOULD NOT use them (see Section 5.1) and 1065 traffic with those two markings poses a threat to operation of the 1066 wired network (see Section 8.2). CS6 and CS7 SHOULD NOT be passed 1067 through to the wired network in the upstream direction unless the 1068 access point has been specifically configured to do that by a network 1069 administrator or operator. 1071 5.4. Upstream DSCP Marking at the Wireless Access Point 1073 An alternative option to mapping is for the administrator to treat 1074 the wireless edge as the edge of the Diffserv domain and explicitly 1075 set (or reset) DSCP markings in the upstream direction according to 1076 administrative policy. This option is RECOMMENDED over mapping, as 1077 this typically is the most secure solution, as the network 1078 administrator directly enforces the Diffserv policy across the IP 1079 network (versus an application developer and/or the wireless endpoint 1080 device operating system developer, who may be functioning completely 1081 independently of the network administrator). 1083 6. Appendix: IEEE 802.11 QoS Overview 1085 QoS is enabled on wireless networks by means of the Hybrid 1086 Coordination Function (HCF). To give better context to the 1087 enhancements in HCF that enable QoS, it may be helpful to begin with 1088 a review of the original Distributed Coordination Function (DCF). 1090 6.1. Distributed Coordination Function (DCF) 1092 As has been noted, the Wi-Fi medium is a shared medium, with each 1093 station-including the wireless access point-contending for the medium 1094 on equal terms. As such, it shares the same challenge as any other 1095 shared medium in requiring a mechanism to prevent (or avoid) 1096 collisions which can occur when two (or more) stations attempt 1097 simultaneous transmission. 1099 The IEEE Ethernet working group solved this challenge by implementing 1100 a Carrier Sense Multiple Access/Collision Detection (CSMA/CD) 1101 mechanism that could detect collisions over the shared physical cable 1102 (as collisions could be detected as reflected energy pulses over the 1103 physical wire). Once a collision was detected, then a pre-defined 1104 set of rules was invoked that required stations to back off and wait 1105 random periods of time before re-attempting transmission. While 1106 CSMA/CD improved the usage of Ethernet as a shared medium, it should 1107 be noted the ultimate solution to solving Ethernet collisions was the 1108 advance of switching technologies, which treated each Ethernet cable 1109 as a dedicated collision domain. 1111 However, unlike Ethernet (which uses physical cables), collisions 1112 cannot be directly detected over the wireless medium, as RF energy is 1113 radiated over the air and colliding bursts are not necessarily 1114 reflected back to the transmitting stations. Therefore, a different 1115 mechanism is required for this medium. 1117 As such, the IEEE modified the CSMA/CD mechanism to adapt it to 1118 wireless networks to provide Carrier Sense Multiple Access/Collision 1119 Avoidance (CSMA/CA). The original CSMA/CA mechanism used in IEEE 1120 802.11 was the Distributed Coordination Function. DCF is a timer- 1121 based system that leverages three key sets of timers, the slot time, 1122 interframe spaces and contention windows. 1124 6.1.1. Slot Time 1126 The slot time is the basic unit of time measure for both DCF and HCF, 1127 on which all other timers are based. The slot time duration varies 1128 with the different generations of data-rates and performances 1129 described by the [IEEE.802.11-2016] standard. For example, the 1130 [IEEE.802.11-2016] standard specifies the slot time to be 20 us 1131 ([IEEE.802.11-2016] Table 15-5) for legacy implementations (such as 1132 IEEE 802.11b, supporting 1, 2, 5.5 and 11 Mbps data rates), while 1133 newer implementations (including IEEE 802.11g, 802.11a, 802.11n and 1134 802.11ac, supporting data rates from 6.5 Mbps to over 2 Gbps per 1135 spatial stream) define a shorter slot time of 9 us 1136 ([IEEE.802.11-2016], Section 17.4.4, Table 17-21). 1138 6.1.2. Interframe Spaces 1140 The time interval between frames that are transmitted over the air is 1141 called the Interframe Space (IFS). Several IFS are defined in 1142 [IEEE.802.11-2016], with the two most relevant to DCF being the Short 1143 Interframe Space (SIFS) and the DCF Interframe Space (DIFS). 1145 The SIFS is the amount of time in microseconds required for a 1146 wireless interface to process a received RF signal and its associated 1148 [IEEE.802.11-2016] frame and to generate a response frame. Like slot 1149 times, the SIFS can vary according to the performance implementation 1150 of the [IEEE.802.11-2016] standard. The SIFS for IEEE 802.11a, 1151 802.11n and 802.11ac (in 5 GHz) is 16 us ([IEEE.802.11-2016], 1152 Section 17.4.4, Table 17-21). 1154 Additionally, a station must sense the status of the wireless medium 1155 before transmitting. If it finds that the medium is continuously 1156 idle for the duration of a DIFS, then it is permitted to attempt 1157 transmission of a frame (after waiting an additional random backoff 1158 period, as will be discussed in the next section). If the channel is 1159 found busy during the DIFS interval, the station must defer its 1160 transmission until the medium is found idle for the duration of a 1161 DIFS interval. The DIFS is calculated as: 1163 DIFS = SIFS + (2 * Slot time) 1165 However, if all stations waited only a fixed amount of time before 1166 attempting transmission then collisions would be frequent. To offset 1167 this, each station must wait, not only a fixed amount of time (the 1168 DIFS), but also a random amount of time (the random backoff) prior to 1169 transmission. The range of the generated random backoff timer is 1170 bounded by the Contention Window. 1172 6.1.3. Contention Windows 1174 Contention windows bound the range of the generated random backoff 1175 timer that each station must wait (in addition to the DIFS) before 1176 attempting transmission. The initial range is set between 0 and the 1177 Contention Window minimum value (CWmin), inclusive. The CWmin for 1178 DCF (in 5 GHz) is specified as 15 slot times ([IEEE.802.11-2016], 1179 Section 17.4.4, Table 17-21). 1181 However, it is possible that two (or more) stations happen to pick 1182 the exact same random value within this range. If this happens then 1183 a collision may occur. At this point, the stations effectively begin 1184 the process again, waiting a DIFS and generate a new random backoff 1185 value. However, a key difference is that for this subsequent 1186 attempt, the Contention Window approximatively doubles in size (thus 1187 exponentially increasing the range of the random value). This 1188 process repeats as often as necessary if collisions continue to 1189 occur, until the maximum Contention Window size (CWmax) is reached. 1190 The CWmax for DCF is specified as 1023 slot times 1191 ([IEEE.802.11-2016], Section 17.4.4, Table 17-21). 1193 At this point, transmission attempts may still continue (until some 1194 other pre-defined limit is reached), but the Contention Window sizes 1195 are fixed at the CWmax value. 1197 Incidentally it may be observed that a significant amount of jitter 1198 can be introduced by this contention process for wireless 1199 transmission access. For example, the incremental transmission delay 1200 of 1023 slot times (CWmax) using 9 us slot times may be as high as 9 1201 ms of jitter per attempt. And, as previously noted, multiple 1202 attempts can be made at CWmax. 1204 6.2. Hybrid Coordination Function (HCF) 1206 Therefore, as can be seen from the preceding description of DCF, 1207 there is no preferential treatment of one station over another when 1208 contending for the shared wireless media; nor is there any 1209 preferential treatment of one type of traffic over another during the 1210 same contention process. To support the latter requirement, the IEEE 1211 enhanced DCF in 2005 to support QoS, specifying HCF in IEEE 802.11, 1212 which was integrated into the main IEEE 802.11 standard in 2007. 1214 6.2.1. User Priority (UP) 1216 One of the key changes to the [IEEE.802.11-2016] frame format is the 1217 inclusion of a QoS Control field, with 3 bits dedicated for QoS 1218 markings. These bits are referred to the User Priority (UP) bits and 1219 these support eight distinct marking values: 0-7, inclusive. 1221 While such markings allow for frame differentiation, these alone do 1222 not directly affect over-the-air treatment. Rather it is the non- 1223 configurable and standard-specified mapping of UP markings to 1224 [IEEE.802.11-2016] Access Categories (AC) that generate 1225 differentiated treatment over wireless media. 1227 6.2.2. Access Category (AC) 1229 Pairs of UP values are mapped to four defined access categories that 1230 correspondingly specify different treatments of frames over the air. 1231 These access categories (in order of relative priority from the top 1232 down) and their corresponding UP mappings are shown in Figure 2 1233 (adapted from [IEEE.802.11-2016], Section 10.2.4.2, Table 10-1). 1235 +-----------------------------------------+ 1236 | User | Access | Designative | 1237 | Priority | Category | (informative) | 1238 |===========+============+================| 1239 | 7 | AC_VO | Voice | 1240 +-----------+------------+----------------+ 1241 | 6 | AC_VO | Voice | 1242 +-----------+------------+----------------+ 1243 | 5 | AC_VI | Video | 1244 +-----------+------------+----------------+ 1245 | 4 | AC_VI | Video | 1246 +-----------+------------+----------------+ 1247 | 3 | AC_BE | Best Effort | 1248 +-----------+------------+----------------+ 1249 | 0 | AC_BE | Best Effort | 1250 +-----------+------------+----------------+ 1251 | 2 | AC_BK | Background | 1252 +-----------+------------+----------------+ 1253 | 1 | AC_BK | Background | 1254 +-----------------------------------------+ 1256 Figure 2: IEEE 802.11 Access Categories and User Priority Mappings 1258 The manner in which these four access categories achieve 1259 differentiated service over-the-air is primarily by tuning the fixed 1260 and random timers that stations have to wait before sending their 1261 respective types of traffic, as will be discussed next. 1263 6.2.3. Arbitration Inter-Frame Space (AIFS) 1265 As previously mentioned, each station must wait a fixed amount of 1266 time to ensure the medium is idle before attempting transmission. 1267 With DCF, the DIFS is constant for all types of traffic. However, 1268 with [IEEE.802.11-2016] the fixed amount of time that a station has 1269 to wait will depend on the access category and is referred to as an 1270 Arbitration Interframe Space (AIFS). AIFS are defined in slot times 1271 and the AIFS per access category are shown in Figure 3 (adapted from 1272 [IEEE.802.11-2016], Section 9.4.2.29, Table 9-137). 1274 +------------------------------------------+ 1275 | Access | Designative | AIFS | 1276 | Category | (informative) |(slot times)| 1277 |===========+=================+============| 1278 | AC_VO | Voice | 2 | 1279 +-----------+-----------------+------------+ 1280 | AC_VI | Video | 2 | 1281 +-----------+-----------------+------------+ 1282 | AC_BE | Best Effort | 3 | 1283 +-----------+-----------------+------------+ 1284 | AC_BK | Background | 7 | 1285 +-----------+-----------------+------------+ 1287 Figure 3: Arbitration Interframe Spaces by Access Category 1289 6.2.4. Access Category Contention Windows (CW) 1291 Not only is the fixed amount of time that a station has to wait 1292 skewed according to [IEEE.802.11-2016] access category, but so are 1293 the relative sizes of the Contention Windows that bound the random 1294 backoff timers, as shown in Figure 4 (adapted from 1295 [IEEE.802.11-2016], Section 9.4.2.29, Table 9-137). 1297 +-------------------------------------------------------+ 1298 | Access | Designative | CWmin | CWmax | 1299 | Category | (informative) |(slot times)|(slot times)| 1300 |===========+=================+============|============| 1301 | AC_VO | Voice | 3 | 7 | 1302 +-----------+-----------------+------------+------------+ 1303 | AC_VI | Video | 7 | 15 | 1304 +-----------+-----------------+------------+------------+ 1305 | AC_BE | Best Effort | 15 | 1023 | 1306 +-----------+-----------------+------------+------------+ 1307 | AC_BK | Background | 15 | 1023 | 1308 +-----------+-----------------+------------+------------+ 1310 Figure 4: Contention Window Sizes by Access Category 1312 When the fixed and randomly generated timers are added together on a 1313 per access category basis, then traffic assigned to the Voice Access 1314 Category (i.e. traffic marked to UP 6 or 7) will receive a 1315 statistically superior service relative to traffic assigned to the 1316 Video Access Category (i.e. traffic marked UP 5 and 4), which, in 1317 turn, will receive a statistically superior service relative to 1318 traffic assigned to the Best Effort Access Category traffic (i.e. 1320 traffic marked UP 3 and 0), which finally will receive a 1321 statistically superior service relative to traffic assigned to the 1322 Background Access Category traffic (i.e. traffic marked to UP 2 and 1323 1). 1325 6.3. IEEE 802.11u QoS Map Set 1327 IEEE 802.11u [IEEE.802-11u.2011] is an addendum that has now been 1328 included within the main [IEEE.802.11-2016] standard, and which 1329 includes, among other enhancements, a mechanism by which wireless 1330 access points can communicate DSCP to/from UP mappings that have been 1331 configured on the wired IP network. Specifically, a QoS Map Set 1332 information element (described in [IEEE.802.11-2016] Section 9.4.2.95 1333 and commonly referred to as the QoS Map element) is transmitted from 1334 an AP to a wireless endpoint device in an association / re- 1335 association Response frame (or within a special QoS Map Configure 1336 frame). 1338 The purpose of the QoS Map element is to provide the mapping of 1339 higher layer Quality of Service constructs (i.e. DSCP) to User 1340 Priorities. One intended effect of receiving such a map is for the 1341 wireless endpoint device (that supports this function and is 1342 administratively configured to enable it) to perform corresponding 1343 DSCP-to-UP mapping within the device (i.e. between applications and 1344 the operating system / wireless network interface hardware drivers) 1345 to align with what the APs are mapping in the downstream direction, 1346 so as to achieve consistent end-to-end QoS in both directions. 1348 The QoS Map element includes two key components: 1350 1) each of the eight UP values (0-7) are associated with a range of 1351 DSCP values, and 1353 2) (up to 21) exceptions from these range-based DSCP to/from UP 1354 mapping associations may be optionally and explicitly specified. 1356 In line with the recommendations put forward in this document, the 1357 following recommendations apply when the QoS Map element is enabled: 1359 1) each of the eight UP values (0-7) are RECOMMENDED to be mapped to 1360 DSCP 0 (as a baseline, so as to meet the recommendation made in 1361 Section 8.2 1363 2) (up to 21) exceptions from this baseline mapping are RECOMMENDED 1364 to be made in line with Section 4.3, to correspond to the Diffserv 1365 Codepoints that are in use over the IP network. 1367 It is important to note that the QoS Map element is intended to be 1368 transmitted from a wireless access point to a non-AP station. As 1369 such, the model where this element is used is that of a network where 1370 the AP is the edge of the Diffserv domain. Networks where the AP 1371 extends the Diffserv domain by connecting other APs and 1372 infrastructure devices through the IEEE 802.11 medium are not 1373 included in the cases covered by the presence of the QoS Map element, 1374 and therefore are not included in the present recommendation. 1376 7. IANA Considerations 1378 This memo asks the IANA for no new parameters. 1380 8. Security Considerations 1382 The recommendations in this document concern widely-deployed wired 1383 and wireless network functionality, and for that reason do not 1384 present additional security concerns that do not already exist in 1385 these networks. In fact, several of the recommendations made in this 1386 document serve to protect wired and wireless networks from potential 1387 abuse, as is discussed further in this section. 1389 8.1. General QoS Security Recommendations 1391 It may be possible for a wired or wireless device (which could be 1392 either a host or a network device) to mark packets (or map packet 1393 markings) in a manner that interferes with or degrades existing QoS 1394 policies. Such marking or mapping may be done intentionally or 1395 unintentionally by developers and/or users and/or administrators of 1396 such devices. 1398 To illustrate: A gaming application designed to run on a smart-phone 1399 or tablet may request that all its packets be marked DSCP EF and/or 1400 UP 6. However, if the traffic from such an application is forwarded 1401 without change over a business network, then this could interfere 1402 with QoS policies intended to provide priority services for business 1403 voice applications. 1405 To mitigate such scenarios it is RECOMMENDED to implement general QoS 1406 security measures, including: 1408 Setting a traffic conditioning policy reflective of business 1409 objectives and policy, such that traffic from authorized users 1410 and/or applications and/or endpoints will be accepted by the 1411 network; otherwise packet markings will be "bleached" (i.e. 1412 remarked to DSCP DF and/or UP 0). Additionally, Section 5.3 made 1413 it clear that it is generally NOT RECOMMENDED to pass through DSCP 1414 markings from unauthorized and/or unauthenticated devices, as 1415 these are typically considered untrusted sources. This is 1416 especially relevant for IoT deployments, where tens-of-billions of 1417 devices that may have little or no security are being connected to 1418 IP networks. 1420 Policing EF marked packet flows, as detailed in [RFC2474] 1421 Section 7 and [RFC3246] Section 3. 1423 In addition to these general QoS security recommendations, WLAN- 1424 specific QoS security recommendations can serve to further mitigate 1425 attacks and potential network abuse. 1427 8.2. WLAN QoS Security Recommendations 1429 The wireless LAN presents a unique DoS attack vector, as endpoint 1430 devices contend for the shared media on a completely egalitarian 1431 basis with the network (as represented by the AP). This means that 1432 any wireless client could potentially monopolize the air by sending 1433 packets marked to preferred UP values (i.e. UP values 4-7) in the 1434 upstream direction. Similarly, airtime could be monopolized if 1435 excessive amounts of downstream traffic were marked/mapped to these 1436 same preferred UP values. As such, the ability to mark/map to these 1437 preferred UP values (of UP 4-7) should be controlled. 1439 If such marking/mapping were not controlled, then, for example, a 1440 malicious user could cause WLAN DoS by flooding traffic marked CS7 1441 DSCP downstream. This codepoint would map by default (as described 1442 in Section 2.2) to UP 7 and would be assigned to the Voice Access 1443 Category (AC_VO). Such a flood could cause Denial-of-Service to not 1444 only wireless voice applications, but also to all other traffic 1445 classes. Similarly, an uninformed application developer may request 1446 all traffic from his/her application to be marked CS7 or CS6, 1447 thinking this would acheive in the best overall servicing oftheir 1448 application traffic, while not realizing that such a marking (if 1449 honored by the client operating system) could cause not only WLAN 1450 DoS, but also IP network instability, as the traffic marked CS7 or 1451 CS6 finds its way into queues intended for servicing (relatively low- 1452 bandwidth) network control protocols, potentially starving legitimate 1453 network control protocols in the process. 1455 Therefore, to mitigate such an attack, it is RECOMMENDED that all 1456 packets marked to Diffserv Codepoints not in use over the wireless 1457 network be mapped to UP 0; this recommendation applies both at the 1458 access point (in the downstream direction) and within the wireless 1459 endpoint device operating system (in the upstream direction). 1461 Such a policy of mapping unused codepoints to UP 0 would also prevent 1462 an attack where non-standard codepoints were used to cause WLAN DoS. 1464 Consider the case where codepoints are mapped to UP values using a 1465 range function (e.g. DSCP values 48-55 all map to UP 6), then an 1466 attacker could flood packets marked, for example to DSCP 49, in 1467 either the upstream or downstream direction over the WLAN, causing 1468 DoS to all other traffic classes in the process. 1470 In the majority of WLAN deployments, the AP represents not only the 1471 edge of the Diffserv domain, but also the edge of the network 1472 infrastructure itself; that is, only wireless client endpoint devices 1473 are downstream from the AP. In such a deployment model, CS6 and CS7 1474 also fall into the category of codepoints that are not in use over 1475 the wireless LAN (since only wireless endpoint client devices are 1476 downstream from the AP in this model and these devices do not 1477 [legitimately] participate in network control protocol exchanges). 1478 As such, it is RECOMMENDED that CS6 and CS7 DSCP be mapped to UP 0 in 1479 these Wifi-at-the-edge deployment models. Otherwise, it would be 1480 easy for a malicious application developer, or even an inadvertently 1481 poorly-programmed IoT device, to cause WLAN DoS and even wired IP 1482 network instability by flooding traffic marked CS6 DSCP, which would 1483 by default (as described in Section 2.2) be mapped to UP 6, causing 1484 all other traffic classes on the WLAN to be starved, as well 1485 hijacking queues on the wired IP network that are intended for the 1486 servicing of routing protocols. To this point, it was also 1487 recommended in Section 5.1 that packets requesting a marking of CS6 1488 or CS7 DSCP SHOULD be remarked to DSCP 0 and mapped to UP 0 by the 1489 wireless client operating system. 1491 Finally, it should be noted that the recommendations put forward in 1492 this document are not intended to address all attack vectors 1493 leveraging QoS marking abuse. Mechanisms that may further help 1494 mitigate security risks include strong device- and/or user- 1495 authentication, access-control, rate limiting, control-plane 1496 policing, encryption and other techniques; however, the 1497 implementation recommendations for such mechanisms are beyond the 1498 scope of this document to address in detail. Suffice it to say that 1499 the security of the devices and networks implementing QoS, including 1500 QoS mapping between wired and wireless networks, SHOULD be considered 1501 in actual deployments. 1503 9. Acknowledgements 1505 The authors wish to thank David Black, Gorry Fairhurst, Ruediger 1506 Geib, Vincent Roca, Brian Carpenter, David Blake, Cullen Jennings, 1507 David Benham and the TSVWG. 1509 The authors also acknowledge a great many inputs, notably from David 1510 Kloper, Mark Montanez, Glen Lavers, Michael Fingleton, Sarav 1511 Radhakrishnan, Karthik Dakshinamoorthy, Simone Arena, Ranga Marathe, 1512 Ramachandra Murthy and many others. 1514 10. References 1516 10.1. Normative References 1518 [IEEE.802.11-2016] 1519 "Information technology - Telecommunications and 1520 information exchange between systems - Local and 1521 metropolitan area networks - Specific requirements - Part 1522 11: Wireless LAN Medium Access Control (MAC) and Physical 1523 Layer (PHY) specifications", IEEE Standard 802.11, 2016, 1524 . 1527 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1528 Requirement Levels", BCP 14, RFC 2119, 1529 DOI 10.17487/RFC2119, March 1997, 1530 . 1532 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1533 "Definition of the Differentiated Services Field (DS 1534 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1535 DOI 10.17487/RFC2474, December 1998, 1536 . 1538 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 1539 "Assured Forwarding PHB Group", RFC 2597, 1540 DOI 10.17487/RFC2597, June 1999, 1541 . 1543 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1544 of Explicit Congestion Notification (ECN) to IP", 1545 RFC 3168, DOI 10.17487/RFC3168, September 2001, 1546 . 1548 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 1549 J., Courtney, W., Davari, S., Firoiu, V., and D. 1550 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 1551 Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002, 1552 . 1554 [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort 1555 Per-Domain Behavior (PDB) for Differentiated Services", 1556 RFC 3662, DOI 10.17487/RFC3662, December 2003, 1557 . 1559 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 1560 Guidelines for DiffServ Service Classes", RFC 4594, 1561 DOI 10.17487/RFC4594, August 2006, 1562 . 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 10.2. Informative References 1571 [I-D.ietf-tsvwg-le-phb] 1572 Bless, R., "A Lower Effort Per-Hop Behavior (LE PHB)", 1573 draft-ietf-tsvwg-le-phb-02 (work in progress), June 2017. 1575 [IEEE.802-11u.2011] 1576 "Information technology - Telecommunications and 1577 information exchange between systems - Local and 1578 metropolitan area networks - Specific requirements - Part 1579 11: Wireless LAN Medium Access Control (MAC) and Physical 1580 Layer (PHY) specifications", IEEE Standard 802.11, 2011, 1581 . 1584 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1585 and W. Weiss, "An Architecture for Differentiated 1586 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 1587 . 1589 [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of 1590 Diffserv Service Classes", RFC 5127, DOI 10.17487/RFC5127, 1591 February 2008, . 1593 [RFC7561] Kaippallimalil, J., Pazhyannur, R., and P. Yegani, 1594 "Mapping Quality of Service (QoS) Procedures of Proxy 1595 Mobile IPv6 (PMIPv6) and WLAN", RFC 7561, 1596 DOI 10.17487/RFC7561, June 2015, 1597 . 1599 [RFC8100] Geib, R., Ed. and D. Black, "Diffserv-Interconnection 1600 Classes and Practice", RFC 8100, DOI 10.17487/RFC8100, 1601 March 2017, . 1603 Appendix A. Change Log 1605 Initial Version: July 2015 1607 Authors' Addresses 1609 Tim Szigeti 1610 Cisco Systems 1611 Vancouver, British Columbia V6K 3L4 1612 Canada 1614 Email: szigeti@cisco.com 1616 Jerome Henry 1617 Cisco Systems 1618 Research Triangle Park, North Carolina 27709 1619 USA 1621 Email: jerhenry@cisco.com 1623 Fred Baker 1624 Santa Barbara, California 93117 1625 USA 1627 Email: FredBaker.IETF@gmail.com