idnits 2.17.1 draft-ietf-tsvwg-ieee-802-11-10.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 date (December 15, 2017) is 2296 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (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 (~~), 2 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: Best Current Practice Cisco Systems 5 Expires: June 18, 2018 F. Baker 6 December 15, 2017 8 Diffserv to IEEE 802.11 Mapping 9 draft-ietf-tsvwg-ieee-802-11-10 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 of 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 June 18, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 2.1. Diffserv Domain Boundaries . . . . . . . . . . . . . . . 9 66 2.2. EDCF Queuing . . . . . . . . . . . . . . . . . . . . . . 10 67 2.3. Default DSCP-to-UP Mappings and Conflicts . . . . . . . . 10 68 2.4. Default UP-to-DSCP Mappings and Conflicts . . . . . . . . 11 69 3. Wireless Device Marking and Mapping Capability 70 Recommendations . . . . . . . . . . . . . . . . . . . . . . . 13 71 4. DSCP-to-UP Mapping Recommendations . . . . . . . . . . . . . 13 72 4.1. Network Control Traffic . . . . . . . . . . . . . . . . . 14 73 4.1.1. Network Control Protocols . . . . . . . . . . . . . . 14 74 4.1.2. Operations Administration Management (OAM) . . . . . 15 75 4.2. User Traffic . . . . . . . . . . . . . . . . . . . . . . 15 76 4.2.1. Telephony . . . . . . . . . . . . . . . . . . . . . . 15 77 4.2.2. Signaling . . . . . . . . . . . . . . . . . . . . . . 16 78 4.2.3. Multimedia Conferencing . . . . . . . . . . . . . . . 16 79 4.2.4. Real-Time Interactive . . . . . . . . . . . . . . . . 17 80 4.2.5. Multimedia-Streaming . . . . . . . . . . . . . . . . 17 81 4.2.6. Broadcast Video . . . . . . . . . . . . . . . . . . . 17 82 4.2.7. Low-Latency Data . . . . . . . . . . . . . . . . . . 18 83 4.2.8. High-Throughput Data . . . . . . . . . . . . . . . . 18 84 4.2.9. Standard Service Class . . . . . . . . . . . . . . . 19 85 4.2.10. Low-Priority Data . . . . . . . . . . . . . . . . . . 19 86 4.3. DSCP-to-UP Mapping Recommendations Summary . . . . . . . 20 87 5. Upstream Mapping and Marking Recommendations . . . . . . . . 21 88 5.1. Upstream DSCP-to-UP Mapping within the Wireless Client 89 Operating System . . . . . . . . . . . . . . . . . . . . 22 90 5.2. Upstream UP-to-DSCP Mapping at the Wireless Access Point 22 91 5.3. Upstream DSCP-Passthrough at the Wireless Access Point . 23 92 5.4. Upstream DSCP Marking at the Wireless Access Point . . . 24 93 6. IEEE 802.11 QoS Overview . . . . . . . . . . . . . . . . . . 24 94 6.1. Distributed Coordination Function (DCF) . . . . . . . . . 24 95 6.1.1. Slot Time . . . . . . . . . . . . . . . . . . . . . . 25 96 6.1.2. Interframe Spaces . . . . . . . . . . . . . . . . . . 25 97 6.1.3. Contention Windows . . . . . . . . . . . . . . . . . 26 98 6.2. Hybrid Coordination Function (HCF) . . . . . . . . . . . 27 99 6.2.1. User Priority (UP) . . . . . . . . . . . . . . . . . 27 100 6.2.2. Access Category (AC) . . . . . . . . . . . . . . . . 27 101 6.2.3. Arbitration Inter-Frame Space (AIFS) . . . . . . . . 28 102 6.2.4. Access Category Contention Windows (CW) . . . . . . . 29 103 6.3. IEEE 802.11u QoS Map Set . . . . . . . . . . . . . . . . 30 104 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 105 8. Security Considerations . . . . . . . . . . . . . . . . . . . 31 106 8.1. General QoS Security Recommendations . . . . . . . . . . 31 107 8.2. WLAN QoS Security Recommendations . . . . . . . . . . . . 32 108 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 109 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 110 10.1. Normative References . . . . . . . . . . . . . . . . . . 34 111 10.2. Informative References . . . . . . . . . . . . . . . . . 35 112 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 36 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 115 1. Introduction 117 IEEE 802.11 [IEEE.802.11-2016] wireless has become the preferred 118 medium for endpoints connecting to business and private networks. 119 However, the wireless medium defined by IEEE 802.11 120 [IEEE.802.11-2016] presents several design challenges for ensuring 121 end-to-end quality of service. Some of these challenges relate to 122 the nature of the IEEE 802.11 Radio Frequency (RF) medium itself, 123 being a half-duplex and shared medium, while other challenges relate 124 to the fact that the IEEE 802.11 standard is not administered by the 125 same standards body as IP networking standards. While the IEEE has 126 developed tools to enable QoS over wireless networks, little guidance 127 exists on how to maintain consistency of QoS treatment between wired 128 IP and wireless IEEE 802.11 networks. The purpose of this document 129 is to provide such guidance. 131 1.1. Related work 133 Several RFCs outline Diffserv QoS recommendations over IP networks, 134 including: 136 o [RFC2474] specifies the Diffserv Codepoint Field. This RFC also 137 details Class Selectors, as well as the Default Forwarding (DF) 138 treatment. 140 o [RFC2475] defines a Diffserv architecture 142 o [RFC3246] specifies the Expedited Forwarding (EF) Per-Hop Behavior 143 (PHB) 145 o [RFC2597] specifies the Assured Forwarding (AF) PHB. 147 o [RFC3662] specifies a Lower Effort Per-Domain Behavior (PDB) 149 o [RFC4594] presents Configuration Guidelines for Diffserv Service 150 Classes 152 o [RFC5127] presents the Aggregation of Diffserv Service Classes 154 o [RFC5865] specifies a DSCP for Capacity Admitted Traffic 156 Note: [RFC4594] is intended to be viewed as a framework for 157 supporting Diffserv in any network, including wireless networks; 158 thus, it describes different types of traffic expected in IP networks 159 and provides guidance as to what DSCP marking(s) should be associated 160 with each traffic type. As such, this document draws heavily on 161 [RFC4594], as well as [RFC5127], and [RFC8100]. 163 In turn, the relevant standard for wireless QoS is IEEE 802.11, which 164 is being progressively updated; the current version of which (at the 165 time of writing) is [IEEE.802.11-2016]. 167 1.2. Interaction with RFC 7561 169 There is also a recommendation from the Global System for Mobile 170 Communications Association (GSMA) on DSCP to UP Mapping for IP Packet 171 eXchange (IPX), specifically their Guidelines for IPX Provider 172 networks [GSMA-IPX_Guidelines]. These GSMA Guidelines were developed 173 without reference to existing IETF specifications for various 174 services, referenced in Section 1.1. In turn, [RFC7561] was written 175 based on these GSMA Guidelines, as explicitly called out in [RFC7561] 176 Section 4.2. Thus, [RFC7561] conflicts with the overall Diffserv 177 traffic-conditioning service plan, both in the services specified and 178 the code points specified for them. As such, these two plans cannot 179 be normalized. Rather, as discussed in [RFC2474] Section 2, the two 180 domains (IEEE 802.11 and GSMA) are different Differentiated Services 181 Domains separated by a Differentiated Services Boundary. At that 182 boundary, code points from one domain are translated to code points 183 for the other, and maybe to Default (zero) if there is no 184 corresponding service to translate to. 186 1.3. Applicability Statement 188 This document is applicable to the use of Differentiated Services 189 that interconnect with IEEE 802.11 wireless LANs (referred to as Wi- 190 Fi, throughout this document, for simplicity). These guidelines are 191 applicable whether the wireless access points (APs) are deployed in 192 an autonomous manner, managed by (centralized or distributed) WLAN 193 controllers or some hybrid deployment option. This is because in all 194 these cases, the wireless access point is the bridge between wired 195 and wireless media. 197 This document applies to IP networks using WiFi infrastructure at the 198 link layer. Such networks typically include wired LANs with wireless 199 access points at their edges, however, such networks can also include 200 Wi-Fi backhaul, wireless mesh solutions or any other type of AP-to-AP 201 wireless network that extends the wired network infrastructure. 203 1.4. Document Organization 205 This document is organized as follows: 207 o Section 1 introduces the wired-to-wireless QoS challenge, 208 references related work, outlines the organization of the 209 document, and specifies both the requirements language and the 210 terminology used in this document. 212 o Section 2 begins the discussion with a comparison of IETF Diffserv 213 QoS and Wi-Fi QoS standards and highlights discrepancies between 214 these that require reconciliation. 216 o Section 3 presents the marking and mapping capabilities that 217 wireless access points and wireless endpoint devices are 218 recommended to support. 220 o Section 4 presents DSCP-to-UP mapping recommendations for each of 221 the [RFC4594] service classes, which are primarily applicable in 222 the downstream (wired-to-wireless) direction. 224 o Section 5, in turn, considers upstream (wireless-to-wired) QoS 225 options, their respective merits and recommendations. 227 o Section 6 (in the form of an Appendix) presents a brief overview 228 of how QoS is achieved over IEEE 802.11 wireless networks, given 229 the shared, half-duplex nature of the wireless medium. 231 o Section 7 on notes IANA considerations 233 o Section 8 presents security considerations relative to DSCP-to-UP, 234 UP-to-DSCP mapping and remarking 236 1.5. Requirements Language 238 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 239 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 240 "OPTIONAL" in this document are to be interpreted as described in BCP 241 14 [RFC2119] [RFC8174] when, and only when, they appear in all 242 capitals, as shown here. 244 1.6. Terminology Used in this Document 246 Key terminology used in this document includes: 248 AC: Access Category. A label for the common set of enhanced 249 distributed channel access (EDCA) parameters that are used by a 250 quality-of-service (QoS) station (STA) to contend for the channel 251 in order to transmit medium access control (MAC) service data 252 units (MSDUs) with certain priorities. [IEEE.802.11-2016] 253 Section 3.2. 255 AIFS: Arbitration Interframe Space. Interframe space used by QoS 256 stations before transmission of data and other frame types defined 257 by [IEEE.802.11-2016] Section 10.3.2.3.6. 259 AP: Access Point. An entity that contains one station (STA) and 260 provides access to the distribution services, via the wireless 261 medium (WM) for associated STAs. An AP comprises a STA and a 262 distribution system access function (DSAF) [IEEE.802.11-2016] 263 Section 3.1. 265 BSS: Basic Service Set. Informally, a wireless cell; formally, a 266 set of stations that have successfully synchronized using the JOIN 267 service primitives and one STA that has used the START primitive. 268 Alternatively, a set of STAs that have used the START primitive 269 specifying matching mesh profiles where the match of the mesh 270 profiles has been verified via the scanning procedure. Membership 271 in a BSS does not imply that wireless communication with all other 272 members of the BSS is possible. Defined in [IEEE.802.11-2016] 273 Section 3.1. 275 Contention Window: See CW. 277 CSMA/CA: Carrier Sense Multiple Access with Collision Avoidance. 278 A media access control method in which carrier sensing is used, 279 but nodes attempt to avoid collisions by transmitting only when 280 the channel is sensed to be "idle". When these do transmit, nodes 281 transmit their packet data in its entirety. 283 CSMA/CD: Carrier Sense Multiple Access with Collision Detection. 284 A media access control method (used most notably in early Ethernet 285 technology) for local area networking. It uses a carrier-sensing 286 scheme in which a transmitting station detects collisions by 287 sensing transmissions from other stations while transmitting a 288 frame. When this collision condition is detected, the station 289 stops transmitting that frame, transmits a jam signal, and then 290 waits for a random time interval before trying to resend the 291 frame. 293 CW: Contention Window. Limits a CWMin and CWMax, from which a 294 random backoff is computed. 296 CWMax: Contention Window Maximum. The maximum value (in unit of 297 Slot Time) that a contention window can take. 299 CWMin: Contention Window Minimum. The minimum value that a 300 contention window can take. 302 DCF: Distributed Coordinated Function. A class of coordination 303 function where the same coordination function logic is active in 304 every station (STA) in the basic service set (BSS) whenever the 305 network is in operation. 307 DIFS: Distributed (Coordination Function) Interframe Space. A 308 unit of time during which the medium has to be detected as idle 309 before a station should attempt to send frames, as per 310 [IEEE.802.11-2016] Section 10.3.2.3.5. 312 DSCP: Differentiated Service Code Point [RFC2474] and [RFC2475]. 313 The DSCP is carried in the first 6 bits of the IPv4 and IPv6 Type 314 of Service (TOS) Byte (the remaining 2 bits are used for IP 315 Explicit Congestion Notification [RFC3168]). 317 EIFS: Extended Interframe Space. A unit of time that a station 318 has to defer before transmitting a frame if the previous frame 319 contained an error, as per [IEEE.802.11-2016] Section 10.3.2.3.7. 321 HCF: Hybrid Coordination Function A coordination function that 322 combines and enhances aspects of the contention based and 323 contention free access methods to provide quality-of-service (QoS) 324 stations (STAs) with prioritized and parameterized QoS access to 325 the wireless medium (WM), while continuing to support non-QoS STAs 326 for best-effort transfer. [IEEE.802.11-2016] Section 3.1. 328 IFS: Interframe Space. Period of silence between transmissions 329 over 802.11 networks. [IEEE.802.11-2016] describes several types 330 of Interframe Spaces. 332 Random Backoff Timer: A pseudorandom integer period of time (in 333 units of Slot Time) over the interval (0,CW), where CWmin is-less- 334 than-or-equal-to CW, which in turn is less-than-or-equal-to CWMax. 335 Stations desiring to initiate transfer of data frames and-or 336 Management frames using the DCF shall invoke the carrier sense 337 mechanism to determine the busy-or-idle state of the medium. If 338 the medium is busy, the STA shall defer until the medium is 339 determined to be idle without interruption for a period of time 340 equal to DIFS when the last frame detected on the medium was 341 received correctly, or after the medium is determined to be idle 342 without interruption for a period of time equal to EIFS when the 343 last frame detected on the medium was not received correctly. 344 After this DIFS or EIFS medium idle time, the STA shall then 345 generate a random backoff period for an additional deferral time 346 before transmitting. [IEEE.802.11-2016] Section 10.3.3. 348 RF: Radio Frequency. 350 SIFS: Short Interframe Space. An IFS used before transmission of 351 specific frames as defined in [IEEE.802.11-2016] 352 Section 10.3.2.3.3. 354 Slot Time: A unit of time used to count time intervals in 802.11 355 networks, and defined in [IEEE.802.11-2016] Section 10.3.2.13. 357 Trust: From a QoS-perspective, trust refers to the accepting of 358 the QoS markings of a packet by a network device. Trust is 359 typically extended at Layer 3 (by accepting the DSCP), but may 360 also be extended at lower layers, such as at Layer 2 by accepting 361 User Priority markings. For example, if an access point is 362 configured to trust DSCP markings and it receives a packet marked 363 EF, then it would treat the packet with the Expedite Forwarding 364 PHB and propagate the EF marking value (DSCP 46) as it transmits 365 the packet. Alternatively, if a network device is configured to 366 operate in an untrusted manner, then it would remark packets as 367 these entered the device, typically to DF (or to a different 368 marking value at the network administrator's preference). Note: 369 The terms "trusted" and "untrusted" are used extensively in 370 [RFC4594]. 372 UP: User Priority. A value associated with a medium access 373 control (MAC) service data unit (MSDU) that indicates how the MSDU 374 is to be handled. The UP is assigned to an MSDU in the layers 375 above the MAC [IEEE.802.11-2016] Section 3.1. The UP defines a 376 level of priority for the associated frame, on a scale of 0 to 7. 378 Wi-Fi: An interoperability certification defined by the Wi-Fi 379 Alliance. However, this term is commonly used, including in the 380 present document, to be the equivalent of IEEE 802.11. 382 Wireless: In the context of this document, "wireless" refers to 383 the media defined in IEEE 802.11 [IEEE.802.11-2016], and not 3G/4G 384 LTE or any other radio telecommunications specification. 386 2. Service Comparison and Default Interoperation of Diffserv and IEEE 387 802.11 389 (Section 6 provides a brief overview of IEEE 802.11 QoS.) 391 The following comparisons between IEEE 802.11 and Diffserv services 392 should be noted: 394 o [IEEE.802.11-2016] does not support an EF PHB service [RFC3246], 395 as it is not possible to assure that a given access category will 396 be serviced with strict priority over another (due to the random 397 element within the contention process) 399 o [IEEE.802.11-2016] does not support an AF PHB service [RFC2597], 400 again because it is not possible to assure that a given access 401 category will be serviced with a minimum amount of assured 402 bandwidth (due to the non-deterministic nature of the contention 403 process) 405 o [IEEE.802.11-2016] loosely supports a [RFC2474] Default Forwarding 406 service via the Best Effort Access Category (AC_BE) 408 o [IEEE.802.11-2016] loosely supports a [RFC3662] Lower Effort PDB 409 service via the Background Access Category (AC_BK) 411 As such, these high-level considerations should be kept in mind when 412 mapping from Diffserv to [IEEE.802.11-2016] (and vice-versa); 413 however, access points may or may not always be positioned at 414 Diffserv domain boundaries, as will be discussed next. 416 2.1. Diffserv Domain Boundaries 418 It is important to recognize that the wired-to-wireless edge may or 419 may not function as an edge of a Diffserv domain or a domain 420 boundary. 422 In most commonly-deployed WLAN models, the wireless access point 423 represents not only the edge of the Diffserv domain, but also the 424 edge of the network infrastructure itself. As such, only client 425 endpoint devices (and no network infrastructure devices) are 426 downstream from the access points in these deployment models. Note: 427 security considerations and recommendations for hardening such Wifi- 428 at-the-edge deployment models are detailed in Section 8; these 429 recommendations include mapping network control protocols (which are 430 not used downstream from the AP in this deployment model) to UP 0. 432 Alternatively, in other deployment models, such as Wi-Fi backhaul, 433 wireless mesh infrastructures, wireless AP-to-AP deployments, or in 434 cases where a Wi-Fi link connects to a device providing service via 435 another technology (e.g. Wi-Fi to Bluetooth or Zigbee router), the 436 wireless access point extends the network infrastructure and thus, 437 typically, the Diffserv domain. In such deployments, both client 438 devices and infrastructure devices may be expected downstream from 439 the access points, and as such network control protocols are 440 RECOMMENDED to be mapped to UP 7 in this deployment model, as is 441 discussed in Section 4.1.1. 443 Thus, as can be seen from these two examples, the QoS treatment of 444 packets at the access point will depend on the position of the AP in 445 the network infrastructure and on the WLAN deployment model. 447 However, regardless of the access point being at the Diffserv 448 boundary or not, Diffserv to [IEEE.802.11-2016] (and vice-versa) 449 marking-specific incompatibilities exist that must be reconciled, as 450 will be discussed next. 452 2.2. EDCF Queuing 454 [IEEE.802.11-2016] displays a reference implementation queuing model 455 in Figure 10-24, which depicts four transmit queues, one per access 456 category. 458 However, in practical implementations, it is common for WLAN network 459 equipment vendors to implement dedicated transmit queues on a per-UP 460 (versus a per access category) basis, which are then dequeued into 461 their associated access category in a preferred (or even in a strict 462 priority manner). For example, it is common for vendors to dequeue 463 UP 5 ahead of UP 4 to the hardware performing the EDCA function 464 (EDCAF) for the Video Access Category (AC_VI). 466 Some of the recommendations made in Section 4 make reference to this 467 common implementation model of queuing per UP. 469 2.3. Default DSCP-to-UP Mappings and Conflicts 471 While no explicit guidance is offered in mapping (6-Bit) Layer 3 DSCP 472 values to (3-Bit) Layer 2 markings (such as IEEE 802.1D, 802.1p or 473 802.11e), a common practice in the networking industry is to map 474 these by what we will refer to as 'Default DSCP-to-UP Mapping' (for 475 lack of a better term), wherein the 3 Most Significant Bits (MSB) of 476 the DSCP are used as the corresponding L2 markings. 478 Note: There are mappings provided in [IEEE.802.11-2016] Annex V 479 Tables V-1 and V2, but it bears mentioning that these mappings are 480 provided as examples (as opposed to explicit recommendations). 481 Furthermore, some of these mappings do not align with the intent and 482 recommendations expressed in [RFC4594], as will be discussed in this 483 and the following section (Section 2.4). 485 However, when this default DSCP-to-UP mapping method is applied to 486 packets marked per [RFC4594] recommendations and destined to 802.11 487 WLAN clients, it will yield a number of inconsistent QoS mappings, 488 specifically: 490 o Voice (EF-101110) will be mapped to UP 5 (101), and treated in the 491 Video Access Category (AC_VI), rather than the Voice Access 492 Category (AC_VO), for which it is intended 494 o Multimedia Streaming (AF3-011xx0) will be mapped to UP3 (011) and 495 treated in the Best Effort Access Category (AC_BE), rather than 496 the Video Access Category (AC_VI), for which it is intended 498 o Broadcast Video (CS3-011000) will be mapped to UP3 (011) and 499 treated in the Best Effort Access Category (AC_BE), rather than 500 the Video Access Category (AC_VI), for which it is intended 502 o OAM traffic (CS2-010000) will be mapped to UP 2 (010) and treated 503 in the Background Access Category (AC_BK), which is not the intent 504 expressed in [RFC4594] for this service class 506 It should also be noted that while [IEEE.802.11-2016] defines an 507 intended use for each access category through the AC naming 508 convention (for example, UP 6 and UP 7 belong to AC_VO, the Voice 509 Access Category), [IEEE.802.11-2016] does not: 511 o define how upper layer markings (such as DSCP) should map to UPs 512 (and hence to ACs) 514 o define how UPs should translate to other medium Layer 2 QoS 515 markings 517 o strictly restrict each access category to applications reflected 518 in the AC name 520 2.4. Default UP-to-DSCP Mappings and Conflicts 522 In the opposite direction of flow (the upstream direction, that is, 523 from wireless-to-wired), many APs use what we will refer to as 524 'Default UP-to-DSCP Mapping' (for lack of a better term), wherein 525 DSCP values are derived from UP values by multiplying the UP values 526 by 8 (i.e. shifting the 3 UP bits to the left and adding three 527 additional zeros to generate a DSCP value). This derived DSCP value 528 is then used for QoS treatment between the wireless access point and 529 the nearest classification and marking policy enforcement point 530 (which may be the centralized wireless LAN controller, relatively 531 deep within the network). Alternatively, in the case where there is 532 no other classification and marking policy enforcement point, then 533 this derived DSCP value will be used on the remainder of the Internet 534 path. 536 It goes without saying that when 6 bits of marking granularity are 537 derived from 3, then information is lost in translation. Servicing 538 differentiation cannot be made for 12 classes of traffic (as 539 recommended in [RFC4594]), but for only 8 (with one of these classes 540 being reserved for future use (i.e. UP 7 which maps to DSCP CS7). 542 Such default upstream mapping can also yield several inconsistencies 543 with [RFC4594], including: 545 o Mapping UP 6 ([RFC4594] Voice) to CS6, which [RFC4594] recommends 546 for Network Control 548 o Mapping UP 4 ([RFC4594] Multimedia Conferencing and/or Real-Time 549 Interactive) to CS4, thus losing the ability to differentiate 550 between these two distinct service classes, as recommended in 551 [RFC4594] Sections 4.3 and 4.4 553 o Mapping UP 3 ([RFC4594] Multimedia Streaming and/or Broadcast 554 Video) to CS3, thus losing the ability to differentiate between 555 these two distinct service classes, as recommended in [RFC4594] 556 Sections 4.5 and 4.6 558 o Mapping UP 2 ([RFC4594] Low-Latency Data and/or OAM) to CS2, thus 559 losing the ability to differentiate between these two distinct 560 service classes, as recommended in [RFC4594] Sections 4.7 and 3.3, 561 and possibly overwhelming the queues provisioned for OAM (which is 562 typically lower in capacity [being network control traffic], as 563 compared to Low-Latency Data queues [being user traffic]) 565 o Mapping UP 1 ([RFC4594] High-Throughput Data and/or Low-Priority 566 Data) to CS1, thus losing the ability to differentiate between 567 these two distinct service classes, as recommended in [RFC4594] 568 Sections 4.8 and 4.10, and causing legitimate business-relevant 569 High-Throughput Data to receive a [RFC3662] Lower Effort PDB, for 570 which it is not intended 572 The following sections address these limitations and concerns in 573 order to reconcile [RFC4594] and [IEEE.802.11-2016]. First 574 downstream (wired-to-wireless) DSCP-to-UP mappings will be aligned 575 and then upstream (wireless-to-wired) models will be addressed. 577 3. Wireless Device Marking and Mapping Capability Recommendations 579 This document assumes and RECOMMENDS that all wireless access points 580 (as the interconnects between wired-and-wireless networks) support 581 the ability to: 583 o mark DSCP, per Diffserv standards 585 o mark UP, per the [IEEE.802.11-2016] standard 587 o support fully-configurable mappings between DSCP and UP 589 o process DSCP markings set by wireless endpoint devices 591 This document further assumes and RECOMMENDS that all wireless 592 endpoint devices support the ability to: 594 o mark DSCP, per Diffserv standards 596 o mark UP, per the [IEEE.802.11-2016] standard 598 o support fully-configurable mappings between DSCP (set by 599 applications in software) and UP (set by the operating system and/ 600 or wireless network interface hardware drivers) 602 Having made the assumptions and recommendations above, it bears 603 mentioning while the mappings presented in this document are 604 RECOMMENDED to replace the current common default practices (as 605 discussed in Section 2.3 and Section 2.4), these mapping 606 recommendations are not expected to fit every last deployment model, 607 and as such MAY be overridden by network administrators, as needed. 609 4. DSCP-to-UP Mapping Recommendations 611 The following section specifies downstream (wired-to-wireless) 612 mappings between [RFC4594] Configuration Guidelines for Diffserv 613 Service Classes and [IEEE.802.11-2016]. As such, this section draws 614 heavily from [RFC4594], including service class definitions and 615 recommendations. 617 This section assumes [IEEE.802.11-2016] wireless access points and/or 618 WLAN controllers that support customizable, non-default DSCP-to-UP 619 mapping schemes. 621 This section also assumes that [IEEE.802.11-2016] access points and 622 endpoint devices differentiate UP markings with corresponding queuing 623 and dequeuing treatments, as described in Section 2.2. 625 4.1. Network Control Traffic 627 Network control traffic is defined as packet flows that are essential 628 for stable operation of the administered network [RFC4594] Section 3. 629 Network control traffic is different from user application control 630 (signaling) that may be generated by some applications or services. 631 Network control traffic MAY be split into two service classes: 633 o Network Control, and 635 o Operations Administration and Management (OAM) 637 4.1.1. Network Control Protocols 639 The Network Control service class is used for transmitting packets 640 between network devices (e.g. routers) that require control (routing) 641 information to be exchanged between nodes within the administrative 642 domain, as well as across a peering point between different 643 administrative domains. 645 [RFC4594] Section 3.2 recommends that Network Control traffic be 646 marked CS6 DSCP. Additionally, as stated in [RFC4594] Section 3.1: 647 "CS7 DSCP value SHOULD be reserved for future use, potentially for 648 future routing or control protocols." 650 By default (as described in Section 2.3), packets marked DSCP CS7 651 will be mapped to UP 7 and serviced within the Voice Access Category 652 (AC_VO). This represents the RECOMMENDED mapping for CS7, that is, 653 packets marked to CS7 DSCP are RECOMMENDED to be mapped to UP 7. 655 However, by default (as described in Section 2.3), packets marked 656 DSCP CS6 will be mapped to UP 6 and serviced within the Voice Access 657 Category (AC_VO); such mapping and servicing is a contradiction to 658 the intent expressed in [RFC4594] Section 3.2. As such, it is 659 RECOMMENDED to map Network Control traffic marked CS6 to UP 7 (per 660 [IEEE.802.11-2016] Section 10.2.4.2, Table 10-1), thereby admitting 661 it to the Voice Access Category (AC_VO), albeit with a marking 662 distinguishing it from (data-plane) voice traffic. 664 It should be noted that encapsulated routing protocols for 665 encapsulated or overlay networks (e.g., VPN, Network Virtualization 666 Overlays, etc.) are not network control traffic for any physical 667 network at the AP, and hence SHOULD NOT be marked with CS6 in the 668 first place. 670 Addtionally, and as previously noted, the Security Considerations 671 section (Section 8) contains additional recommendations for hardening 672 Wifi-at-the-edge deployment models, where, for example, network 673 control protocols are not expected to be sent nor recevied between 674 APs and downstream endpoint client devices. 676 4.1.2. Operations Administration Management (OAM) 678 The OAM (Operations, Administration, and Management) service class is 679 recommended for OAM&P (Operations, Administration, and Management and 680 Provisioning). The OAM service class can include network management 681 protocols, such as SNMP, SSH, TFTP, Syslog, etc., as well as network 682 services, such as NTP, DNS, DHCP, etc. [RFC4594] Section 3.3 683 recommends that OAM traffic be marked CS2 DSCP. 685 By default (as described in Section 2.3), packets marked DSCP CS2 686 will be mapped to UP 2 and serviced with the Background Access 687 Category (AC_BK). Such servicing is a contradiction to the intent 688 expressed in [RFC4594] Section 3.3. As such, it is RECOMMENDED that 689 a non-default mapping be applied to OAM traffic, such that CS2 DSCP 690 is mapped to UP 0, thereby admitting it to the Best Effort Access 691 Category (AC_BE). 693 4.2. User Traffic 695 User traffic is defined as packet flows between different users or 696 subscribers. It is the traffic that is sent to or from end-terminals 697 and that supports a very wide variety of applications and services 698 [RFC4594] Section 4. 700 Network administrators can categorize their applications according to 701 the type of behavior that they require and MAY choose to support all 702 or a subset of the defined service classes. 704 4.2.1. Telephony 706 The Telephony service class is recommended for applications that 707 require real-time, very low delay, very low jitter, and very low 708 packet loss for relatively constant-rate traffic sources (inelastic 709 traffic sources). This service class SHOULD be used for IP telephony 710 service. The fundamental service offered to traffic in the Telephony 711 service class is minimum jitter, delay, and packet loss service up to 712 a specified upper bound. [RFC4594] Section 4.1 recommends that 713 Telephony traffic be marked EF DSCP. 715 Traffic marked to DSCP EF will map by default (as described in 716 Section 2.3) to UP 5, and thus to the Video Access Category (AC_VI), 717 rather than to the Voice Access Category (AC_VO), for which it is 718 intended. Therefore, a non-default DSCP-to-UP mapping is 719 RECOMMENDED, such that EF DSCP is mapped to UP 6, thereby admitting 720 it into the Voice Access Category (AC_VO). 722 Similarly, the [RFC5865] VOICE-ADMIT DSCP (44/101100) is RECOMMENDED 723 to be mapped to UP 6, thereby admitting it also into the Voice Access 724 Category (AC_VO). 726 4.2.2. Signaling 728 The Signaling service class is recommended for delay-sensitive 729 client-server (e.g. traditional telephony) and peer-to-peer 730 application signaling. Telephony signaling includes signaling 731 between IP phone and soft-switch, soft-client and soft-switch, and 732 media gateway and soft-switch as well as peer-to-peer using various 733 protocols. This service class is intended to be used for control of 734 sessions and applications. [RFC4594] Section 4.2 recommends that 735 Signaling traffic be marked CS5 DSCP. 737 While Signaling is recommended to receive a superior level of service 738 relative to the default class (i.e. AC_BE), it does not require the 739 highest level of service (i.e. AC_VO). This leaves only the Video 740 Access Category (AC_VI), which it will map to by default (as 741 described in Section 2.3). Therefore it is RECOMMENDED to map 742 Signaling traffic marked CS5 DSCP to UP 5, thereby admitting it to 743 the Video Access Category (AC_VI). 745 Note: Signaling traffic is not control plane traffic from the 746 perspective of the network (but rather is data plane traffic); as 747 such, it does not merit provisioning in the Network Control service 748 class (marked CS6 and mapped to UP 6). However, Signaling traffic is 749 control-plane traffic from the perspective of the voice/video 750 telephony overlay-infrastructure. As such, Signaling should be 751 treated with preferential servicing vs. other data plane flows. This 752 may be achieved in common WLAN deployments by mapping Signaling 753 traffic marked CS5 to UP 5. On APs supporting per-UP EDCAF queuing 754 logic (as described in Section 2.2) this will result in preferential 755 treatment for Signaling traffic versus other video flows in the same 756 access category (AC_VI), which are marked to UP 4, as well as 757 preferred treatment over flows in the Best Effort (AC_BE) and 758 Background (AC_BK) access categories. 760 4.2.3. Multimedia Conferencing 762 The Multimedia Conferencing service class is recommended for 763 applications that require real-time service for rate-adaptive 764 traffic. [RFC4594] Section 4.3 recommends Multimedia Conferencing 765 traffic be marked AF4x (that is, AF41, AF42 and AF43, according to 766 the rules defined in [RFC2475]). 768 The primary media type typically carried within the Multimedia 769 Conferencing service class is video; as such, it is RECOMMENDED to 770 map this class into the Video Access Category, which it does by 771 default (as described in Section 2.3). Specifically, it is 772 RECOMMENDED to map AF41, AF42 and AF43 to UP 4, thereby admitting 773 Multimedia Conferencing into the Video Access Category (AC_VI). 775 4.2.4. Real-Time Interactive 777 The Real-Time Interactive service class is recommended for 778 applications that require low loss and jitter and very low delay for 779 variable rate inelastic traffic sources. Such applications may 780 include inelastic video-conferencing applications, but may also 781 include gaming applications (as pointed out in [RFC4594] Sections 2.1 782 through 2.3, and Section 4.4). [RFC4594] Section 4.4 recommends 783 Real-Time Interactive traffic be marked CS4 DSCP. 785 The primary media type typically carried within the Real-Time 786 Interactive service class is video; as such, it is RECOMMENDED to map 787 this class into the Video Access Category, which it does by default 788 (as described in Section 2.3). Specifically, it is RECOMMENDED to 789 map CS4 to UP 4, thereby admitting Real-Time Interactive traffic into 790 the Video Access Category (AC_VI). 792 4.2.5. Multimedia-Streaming 794 The Multimedia Streaming service class is recommended for 795 applications that require near-real-time packet forwarding of 796 variable rate elastic traffic sources. Typically these flows are 797 unidirectional. [RFC4594] Section 4.5 recommends Multimedia 798 Streaming traffic be marked AF3x (that is, AF31, AF32 and AF33, 799 according to the rules defined in [RFC2475]). 801 The primary media type typically carried within the Multimedia 802 Streaming service class is video; as such, it is RECOMMENDED to map 803 this class into the Video Access Category, which it will by default 804 (as described in Section 2.3). Specifically, it is RECOMMENDED to 805 map AF31, AF32 and AF33 to UP 4, thereby admitting Multimedia 806 Streaming into the Video Access Category (AC_VI). 808 4.2.6. Broadcast Video 810 The Broadcast Video service class is recommended for applications 811 that require near-real-time packet forwarding with very low packet 812 loss of constant rate and variable rate inelastic traffic sources. 813 Typically these flows are unidirectional. [RFC4594] Section 4.6 814 recommends Broadcast Video traffic be marked CS3 DSCP. 816 As directly implied by the name, the primary media type typically 817 carried within the Broadcast Video service class is video; as such, 818 it is RECOMMENDED to map this class into the Video Access Category; 819 however, by default (as described in Section 2.3), this service class 820 will map to UP 3, and thus the Best Effort Access Category (AC_BE). 821 Therefore, a non-default mapping is RECOMMENDED, such that CS4 maps 822 to UP 4, thereby admitting Broadcast Video into the Video Access 823 Category (AC_VI). 825 4.2.7. Low-Latency Data 827 The Low-Latency Data service class is recommended for elastic and 828 time-sensitive data applications, often of a transactional nature, 829 where a user is waiting for a response via the network in order to 830 continue with a task at hand. As such, these flows are considered 831 foreground traffic, with delays or drops to such traffic directly 832 impacting user-productivity. [RFC4594] Section 4.7 recommends Low- 833 Latency Data be marked AF2x (that is, AF21, AF22 and AF23, according 834 to the rules defined in [RFC2475]). 836 By default (as described in Section 2.3), Low-Latency Data will map 837 to UP 2 and thus to the Background Access Category (AC_BK), which is 838 contrary to the intent expressed in [RFC4594]. 840 Mapping Low-Latency Data to UP 3 may allow such to receive a superior 841 level of service via per-UP transmit queues servicing the EDCAF 842 hardware for the Best Effort Access Category (AC_BE), as described in 843 Section 2.2. Therefore it is RECOMMENDED to map Low-Latency Data 844 traffic marked AF2x DSCP to UP 3, thereby admitting it to the Best 845 Effort Access Category (AC_BE). 847 4.2.8. High-Throughput Data 849 The High-Throughput Data service class is recommended for elastic 850 applications that require timely packet forwarding of variable rate 851 traffic sources and, more specifically, is configured to provide 852 efficient, yet constrained (when necessary) throughput for TCP 853 longer-lived flows. These flows are typically non-user-interactive. 854 According to [RFC4594] Section 4.8, it can be assumed that this class 855 will consume any available bandwidth and that packets traversing 856 congested links may experience higher queuing delays or packet loss. 857 It is also assumed that this traffic is elastic and responds 858 dynamically to packet loss. [RFC4594] Section 4.8 recommends High- 859 Throughput Data be marked AF1x (that is, AF11, AF12 and AF13, 860 according to the rules defined in [RFC2475]). 862 By default (as described in Section 2.3), High-Throughput Data will 863 map to UP 1 and thus to the Background Access Category (AC_BK), which 864 is contrary to the intent expressed in [RFC4594]. 866 Unfortunately, there really is no corresponding fit for the High- 867 Throughput Data service class within the constrained 4 Access 868 Category [IEEE.802.11-2016] model. If the High-Throughput Data 869 service class is assigned to the Best Effort Access Category (AC_BE), 870 then it would contend with Low-Latency Data (while [RFC4594] 871 recommends a distinction in servicing between these service classes) 872 as well as with the default service class; alternatively, if it is 873 assigned to the Background Access Category (AC_BK), then it would 874 receive a less-then-best-effort service and contend with Low-Priority 875 Data (as discussed in Section 4.2.10). 877 As such, since there is no directly corresponding fit for the High- 878 Throughout Data service class within the [IEEE.802.11-2016] model, it 879 is generally RECOMMENDED to map High-Throughput Data to UP 0, thereby 880 admitting it to the Best Effort Access Category (AC_BE). 882 4.2.9. Standard Service Class 884 The Standard service class is recommended for traffic that has not 885 been classified into one of the other supported forwarding service 886 classes in the Diffserv network domain. This service class provides 887 the Internet's "best-effort" forwarding behavior. [RFC4594] 888 Section 4.9 states that the "Standard service class MUST use the 889 Default Forwarding (DF) PHB." 891 The Standard Service Class loosely corresponds to the 892 [IEEE.802.11-2016] Best Effort Access Category (AC_BE) and therefore 893 it is RECOMMENDED to map Standard Service Class traffic marked DF 894 DSCP to UP 0, thereby admitting it to the Best Effort Access Category 895 (AC_BE). This happens to correspond to the default mapping (as 896 described in Section 2.3). 898 4.2.10. Low-Priority Data 900 The Low-Priority Data service class serves applications that the user 901 is willing to accept without service assurances. This service class 902 is specified in [RFC3662] and [I-D.ietf-tsvwg-le-phb]. 904 [RFC3662] and [RFC4594] both recommend Low-Priority Data be marked 905 CS1 DSCP. 907 Note: This marking recommendation may change in the future, as 908 [I-D.ietf-tsvwg-le-phb] defines a Lower Effort (LE) per-hop behavior 909 (PHB) and states: "The RECOMMENDED codepoint for the LE PHB is 910 '000010'. 912 The Low-Priority Data service class loosely corresponds to the 913 [IEEE.802.11-2016] Background Access Category (AC_BK) and therefore 914 it is RECOMMENDED to map Low-Priority Data traffic marked CS1 DSCP to 915 UP 1, thereby admitting it to the Background Access Category (AC_BK). 916 This happens to correspond to the default mapping (as described in 917 Section 2.3). 919 4.3. DSCP-to-UP Mapping Recommendations Summary 921 Figure 1 summarizes the [RFC4594] DSCP marking recommendations mapped 922 to [IEEE.802.11-2016] UP and access categories applied in the 923 downstream direction (i.e. from wired-to-wireless networks). 925 +------------------------------------------------------------------+ 926 | IETF Diffserv | PHB |Reference| IEEE 802.11 | 927 | Service Class | | RFC |User Priority| Access Category | 928 |===============+======+=========+=============+====================| 929 | | | | 7 | AC_VO (Voice) | 930 |Network Control| CS7 | RFC2474 | OR | 931 |(reserved for | | | 0 | AC_BE (Best Effort)| 932 | future use) | | |See Security Considerations-Sec.8 | 933 +---------------+------+---------+-------------+--------------------+ 934 | | | | 7 | AC_VO (Voice) | 935 |Network Control| CS6 | RFC2474 | OR | 936 | | | | 0 | AC_BE (Best Effort)| 937 | | | |See Security Considerations-Sec.8 | 938 +---------------+------+---------+-------------+--------------------+ 939 | Telephony | EF | RFC3246 | 6 | AC_VO (Voice) | 940 +---------------+------+---------+-------------+--------------------+ 941 | VOICE-ADMIT | VA | RFC5865 | 6 | AC_VO (Voice) | 942 | | | | | | 943 +---------------+------+---------+-------------+--------------------+ 944 | Signaling | CS5 | RFC2474 | 5 | AC_VI (Video) | 945 +---------------+------+---------+-------------+--------------------+ 946 | Multimedia | AF41 | | | | 947 | Conferencing | AF42 | RFC2597 | 4 | AC_VI (Video) | 948 | | AF43 | | | | 949 +---------------+------+---------+-------------+--------------------+ 950 | Real-Time | CS4 | RFC2474 | 4 | AC_VI (Video) | 951 | Interactive | | | | | 952 +---------------+------+---------+-------------+--------------------+ 953 | Multimedia | AF31 | | | | 954 | Streaming | AF32 | RFC2597 | 4 | AC_VI (Video) | 955 | | AF33 | | | | 956 +---------------+------+---------+-------------+--------------------+ 957 |Broadcast Video| CS3 | RFC2474 | 4 | AC_VI (Video) | 958 +---------------+------+---------+-------------+--------------------+ 959 | Low- | AF21 | | | | 960 | Latency | AF22 | RFC2597 | 3 | AC_BE (Best Effort)| 961 | Data | AF23 | | | | 962 +---------------+------+---------+-------------+--------------------+ 963 | OAM | CS2 | RFC2474 | 0 | AC_BE (Best Effort)| 964 +---------------+------+---------+-------------+--------------------+ 965 | High- | AF11 | | | | 966 | Throughput | AF12 | RFC2597 | 0 | AC_BE (Best Effort)| 967 | Data | AF13 | | | | 968 +---------------+------+---------+-------------+--------------------+ 969 | Standard | DF | RFC2474 | 0 | AC_BE (Best Effort)| 970 +---------------+------+---------+-------------+--------------------+ 971 | Low-Priority | CS1 | RFC3662 | 1 | AC_BK (Background) | 972 | Data | | | | | 973 +-------------------------------------------------------------------+ 975 Note: All unused codepoints are RECOMMENDED to be mapped to UP 0 976 (See Security Considerations Section - Section 8) 978 Figure 1: Summary of Downstream DSCP to IEEE 802.11 UP and AC Mapping 979 Recommendations 981 5. Upstream Mapping and Marking Recommendations 983 In the upstream direction (i.e. wireless-to-wired), there are three 984 types of mapping that may be implemented: 986 o DSCP-to-UP mapping within the wireless client operating system, 987 and 989 o UP-to-DSCP mapping at the wireless access point, or 991 o DSCP-Passthrough at the wireless access point (effectively a 1:1 992 DSCP-to-DSCP mapping) 994 As an alternative to the latter two options, the network 995 administrator MAY choose to use the wireless-to-wired edge as a 996 Diffserv boundary and explicitly set (or reset) DSCP markings 997 according to administrative policy, thus making the wireless edge a 998 Diffserv policy enforcement point; this approach is RECOMMENDED 999 whenever the APs support the required classification and marking 1000 capabilities. 1002 Each of these options will now be considered. 1004 5.1. Upstream DSCP-to-UP Mapping within the Wireless Client Operating 1005 System 1007 Some operating systems on wireless client devices utilize a similar 1008 default DSCP-to-UP mapping scheme as described in Section 2.3. As 1009 such, this can lead to the same conflicts as described in that 1010 section, but in the upstream direction. 1012 Therefore, to improve on these default mappings, and to achieve 1013 parity and consistency with downstream QoS, it is RECOMMENDED that 1014 wireless client operating systems utilize instead the same DSCP-to-UP 1015 mapping recommendations presented in Section 4, with the explicit 1016 RECOMMENDATION that packets requesting a marking of CS6 or CS7 DSCP 1017 SHOULD be mapped to UP 0 (and not to UP 7). Furthermore, in such 1018 cases the wireless client operating system SHOULD remark such packets 1019 to DSCP 0. This is because CS6 and CS7 DSCP, as well as UP 7 1020 markings, are intended for network control protocols and these SHOULD 1021 NOT be sourced from wireless client endpoint devices. This 1022 recommendation is detailed in the Security Considerations section 1023 (Section 8). 1025 5.2. Upstream UP-to-DSCP Mapping at the Wireless Access Point 1027 UP-to-DSCP mapping generates a DSCP value for the IP packet (either 1028 an unencapsulated IP packet or an IP packet encapsulated within a 1029 tunneling protocol such as CAPWAP - and destined towards a wireless 1030 LAN controller for decapsulation and forwarding) from the Layer 2 1031 [IEEE.802.11-2016] UP marking. This is typically done in the manner 1032 described in Section 2.4. 1034 It should be noted that any explicit remarking policy to be performed 1035 on such a packet only takes place at the nearest classification and 1036 marking policy enforcement point, which may be: 1038 o At the wireless access point 1040 o At the wired network switch port 1042 o At the wireless LAN controller 1044 As such, UP-to-DSCP mapping allows for wireless L2 markings to affect 1045 the QoS treatment of a packet over the wired IP network (that is, 1046 until the packet reaches the nearest classification and marking 1047 policy enforcement point). 1049 It should be further noted that nowhere in the [IEEE.802.11-2016] 1050 specifications is there an intent expressed for UP markings to be 1051 used to influence QoS treatment over wired IP networks. Furthermore, 1053 [RFC2474], [RFC2475] and [RFC8100] all allow for the host to set DSCP 1054 markings for end-to-end QoS treatment over IP networks. Therefore, 1055 wireless access points MUST NOT leverage Layer 2 [IEEE.802.11-2016] 1056 UP markings as set by wireless hosts and subsequently perform a UP- 1057 to-DSCP mapping in the upstream direction. But rather, if wireless 1058 host markings are to be leveraged (as per business requirements, 1059 technical constraints and administrative policies), then it is 1060 RECOMMENDED to pass through the Layer 3 DSCP markings set by these 1061 wireless hosts instead, as is discussed in the next section. 1063 5.3. Upstream DSCP-Passthrough at the Wireless Access Point 1065 It is generally NOT RECOMMENDED to pass through DSCP markings from 1066 unauthenticated and unauthorized devices, as these are typically 1067 considered untrusted sources. 1069 When business requirements and/or technical constraints and/or 1070 administrative policies require QoS markings to be passed through at 1071 the wireless edge, then it is RECOMMENDED to pass through Layer 3 1072 DSCP markings (over Layer 2 [IEEE.802.11-2016] UP markings) in the 1073 upstream direction, with the exception of CS6 and CS7 (as will be 1074 discussed further), for the following reasons: 1076 o [RFC2474], [RFC2475] and [RFC8100] all allow for hosts to set DSCP 1077 markings to achieve an end-to-end differentiated service 1079 o [IEEE.802.11-2016] does not specify that UP markings are to be 1080 used to affect QoS treatment over wired IP networks 1082 o Most present wireless device operating systems generate UP values 1083 by the same method as described in Section 2.3 (i.e. by using the 1084 3 MSB of the encapsulated 6-bit DSCP); then, at the access point, 1085 these 3-bit markings are converted back into DSCP values, 1086 typically in the default manner described in Section 2.4; as such, 1087 information is lost in the translation from a 6-bit marking to a 1088 3-bit marking (which is then subsequently translated back to a 1089 6-bit marking); passing through the original (encapsulated) DSCP 1090 marking prevents such loss of information 1092 o A practical implementation benefit is also realized by passing 1093 through the DSCP set by wireless client devices, as enabling 1094 applications to mark DSCP is much more prevalent and accessible to 1095 programmers of applications running on wireless device platforms, 1096 vis-a-vis trying to explicitly set UP values, which requires 1097 special hooks into the wireless device operating system and/or 1098 hardware device drivers, many of which do not support such 1099 functionality 1101 CS6 and CS7 are exceptions to this pass through recommendation 1102 because wireless hosts SHOULD NOT use them (see Section 5.1) and 1103 traffic with those two markings poses a threat to operation of the 1104 wired network (see Section 8.2). CS6 and CS7 SHOULD NOT be passed 1105 through to the wired network in the upstream direction unless the 1106 access point has been specifically configured to do that by a network 1107 administrator or operator. 1109 5.4. Upstream DSCP Marking at the Wireless Access Point 1111 An alternative option to mapping is for the administrator to treat 1112 the wireless edge as the edge of the Diffserv domain and explicitly 1113 set (or reset) DSCP markings in the upstream direction according to 1114 administrative policy. This option is RECOMMENDED over mapping, as 1115 this typically is the most secure solution, as the network 1116 administrator directly enforces the Diffserv policy across the IP 1117 network (versus an application developer and/or the wireless endpoint 1118 device operating system developer, who may be functioning completely 1119 independently of the network administrator). 1121 6. IEEE 802.11 QoS Overview 1123 QoS is enabled on wireless networks by means of the Hybrid 1124 Coordination Function (HCF). To give better context to the 1125 enhancements in HCF that enable QoS, it may be helpful to begin with 1126 a review of the original Distributed Coordination Function (DCF). 1128 6.1. Distributed Coordination Function (DCF) 1130 As has been noted, the Wi-Fi medium is a shared medium, with each 1131 station-including the wireless access point-contending for the medium 1132 on equal terms. As such, it shares the same challenge as any other 1133 shared medium in requiring a mechanism to prevent (or avoid) 1134 collisions which can occur when two (or more) stations attempt 1135 simultaneous transmission. 1137 The IEEE Ethernet working group solved this challenge by implementing 1138 a Carrier Sense Multiple Access/Collision Detection (CSMA/CD) 1139 mechanism that could detect collisions over the shared physical cable 1140 (as collisions could be detected as reflected energy pulses over the 1141 physical wire). Once a collision was detected, then a pre-defined 1142 set of rules was invoked that required stations to back off and wait 1143 random periods of time before re-attempting transmission. While 1144 CSMA/CD improved the usage of Ethernet as a shared medium, it should 1145 be noted the ultimate solution to solving Ethernet collisions was the 1146 advance of switching technologies, which treated each Ethernet cable 1147 as a dedicated collision domain. 1149 However, unlike Ethernet (which uses physical cables), collisions 1150 cannot be directly detected over the wireless medium, as RF energy is 1151 radiated over the air and colliding bursts are not necessarily 1152 reflected back to the transmitting stations. Therefore, a different 1153 mechanism is required for this medium. 1155 As such, the IEEE modified the CSMA/CD mechanism to adapt it to 1156 wireless networks to provide Carrier Sense Multiple Access/Collision 1157 Avoidance (CSMA/CA). The original CSMA/CA mechanism used in IEEE 1158 802.11 was the Distributed Coordination Function. DCF is a timer- 1159 based system that leverages three key sets of timers, the slot time, 1160 interframe spaces and contention windows. 1162 6.1.1. Slot Time 1164 The slot time is the basic unit of time measure for both DCF and HCF, 1165 on which all other timers are based. The slot time duration varies 1166 with the different generations of data-rates and performances 1167 described by the [IEEE.802.11-2016] standard. For example, the 1168 [IEEE.802.11-2016] standard specifies the slot time to be 20 us 1169 ([IEEE.802.11-2016] Table 15-5) for legacy implementations (such as 1170 IEEE 802.11b, supporting 1, 2, 5.5 and 11 Mbps data rates), while 1171 newer implementations (including IEEE 802.11g, 802.11a, 802.11n and 1172 802.11ac, supporting data rates from 6.5 Mbps to over 2 Gbps per 1173 spatial stream) define a shorter slot time of 9 us 1174 ([IEEE.802.11-2016], Section 17.4.4, Table 17-21). 1176 6.1.2. Interframe Spaces 1178 The time interval between frames that are transmitted over the air is 1179 called the Interframe Space (IFS). Several IFS are defined in 1180 [IEEE.802.11-2016], with the most relevant to DCF being the Short 1181 Interframe Space (SIFS), the DCF Interframe Space (DIFS) and the 1182 Extended Interframe Space (EIFS). 1184 The SIFS is the amount of time in microseconds required for a 1185 wireless interface to process a received RF signal and its associated 1186 [IEEE.802.11-2016] frame and to generate a response frame. Like slot 1187 times, the SIFS can vary according to the performance implementation 1188 of the [IEEE.802.11-2016] standard. The SIFS for IEEE 802.11a, 1189 802.11n and 802.11ac (in 5 GHz) is 16 us ([IEEE.802.11-2016], 1190 Section 17.4.4, Table 17-21). 1192 Additionally, a station must sense the status of the wireless medium 1193 before transmitting. If it finds that the medium is continuously 1194 idle for the duration of a DIFS, then it is permitted to attempt 1195 transmission of a frame (after waiting an additional random backoff 1196 period, as will be discussed in the next section). If the channel is 1197 found busy during the DIFS interval, the station must defer its 1198 transmission until the medium is found idle for the duration of a 1199 DIFS interval. The DIFS is calculated as: 1201 DIFS = SIFS + (2 * Slot time) 1203 However, if all stations waited only a fixed amount of time before 1204 attempting transmission then collisions would be frequent. To offset 1205 this, each station must wait, not only a fixed amount of time (the 1206 DIFS), but also a random amount of time (the random backoff) prior to 1207 transmission. The range of the generated random backoff timer is 1208 bounded by the Contention Window. 1210 6.1.3. Contention Windows 1212 Contention windows bound the range of the generated random backoff 1213 timer that each station must wait (in addition to the DIFS) before 1214 attempting transmission. The initial range is set between 0 and the 1215 Contention Window minimum value (CWmin), inclusive. The CWmin for 1216 DCF (in 5 GHz) is specified as 15 slot times ([IEEE.802.11-2016], 1217 Section 17.4.4, Table 17-21). 1219 However, it is possible that two (or more) stations happen to pick 1220 the exact same random value within this range. If this happens then 1221 a collision may occur. At this point, the stations effectively begin 1222 the process again, waiting a DIFS and generate a new random backoff 1223 value. However, a key difference is that for this subsequent 1224 attempt, the Contention Window approximatively doubles in size (thus 1225 exponentially increasing the range of the random value). This 1226 process repeats as often as necessary if collisions continue to 1227 occur, until the maximum Contention Window size (CWmax) is reached. 1228 The CWmax for DCF is specified as 1023 slot times 1229 ([IEEE.802.11-2016], Section 17.4.4, Table 17-21). 1231 At this point, transmission attempts may still continue (until some 1232 other pre-defined limit is reached), but the Contention Window sizes 1233 are fixed at the CWmax value. 1235 Incidentally it may be observed that a significant amount of jitter 1236 can be introduced by this contention process for wireless 1237 transmission access. For example, the incremental transmission delay 1238 of 1023 slot times (CWmax) using 9 us slot times may be as high as 9 1239 ms of jitter per attempt. And, as previously noted, multiple 1240 attempts can be made at CWmax. 1242 6.2. Hybrid Coordination Function (HCF) 1244 Therefore, as can be seen from the preceding description of DCF, 1245 there is no preferential treatment of one station over another when 1246 contending for the shared wireless media; nor is there any 1247 preferential treatment of one type of traffic over another during the 1248 same contention process. To support the latter requirement, the IEEE 1249 enhanced DCF in 2005 to support QoS, specifying HCF in IEEE 802.11, 1250 which was integrated into the main IEEE 802.11 standard in 2007. 1252 6.2.1. User Priority (UP) 1254 One of the key changes to the [IEEE.802.11-2016] frame format is the 1255 inclusion of a QoS Control field, with 3 bits dedicated for QoS 1256 markings. These bits are referred to the User Priority (UP) bits and 1257 these support eight distinct marking values: 0-7, inclusive. 1259 While such markings allow for frame differentiation, these alone do 1260 not directly affect over-the-air treatment. Rather it is the non- 1261 configurable and standard-specified mapping of UP markings to 1262 [IEEE.802.11-2016] Access Categories (AC) that generate 1263 differentiated treatment over wireless media. 1265 6.2.2. Access Category (AC) 1267 Pairs of UP values are mapped to four defined access categories that 1268 correspondingly specify different treatments of frames over the air. 1269 These access categories (in order of relative priority from the top 1270 down) and their corresponding UP mappings are shown in Figure 2 1271 (adapted from [IEEE.802.11-2016], Section 10.2.4.2, Table 10-1). 1273 +-----------------------------------------+ 1274 | User | Access | Designative | 1275 | Priority | Category | (informative) | 1276 |===========+============+================| 1277 | 7 | AC_VO | Voice | 1278 +-----------+------------+----------------+ 1279 | 6 | AC_VO | Voice | 1280 +-----------+------------+----------------+ 1281 | 5 | AC_VI | Video | 1282 +-----------+------------+----------------+ 1283 | 4 | AC_VI | Video | 1284 +-----------+------------+----------------+ 1285 | 3 | AC_BE | Best Effort | 1286 +-----------+------------+----------------+ 1287 | 0 | AC_BE | Best Effort | 1288 +-----------+------------+----------------+ 1289 | 2 | AC_BK | Background | 1290 +-----------+------------+----------------+ 1291 | 1 | AC_BK | Background | 1292 +-----------------------------------------+ 1294 Figure 2: IEEE 802.11 Access Categories and User Priority Mappings 1296 The manner in which these four access categories achieve 1297 differentiated service over-the-air is primarily by tuning the fixed 1298 and random timers that stations have to wait before sending their 1299 respective types of traffic, as will be discussed next. 1301 6.2.3. Arbitration Inter-Frame Space (AIFS) 1303 As previously mentioned, each station must wait a fixed amount of 1304 time to ensure the medium is idle before attempting transmission. 1305 With DCF, the DIFS is constant for all types of traffic. However, 1306 with [IEEE.802.11-2016] the fixed amount of time that a station has 1307 to wait will depend on the access category and is referred to as an 1308 Arbitration Interframe Space (AIFS). AIFS are defined in slot times 1309 and the AIFS per access category are shown in Figure 3 (adapted from 1310 [IEEE.802.11-2016], Section 9.4.2.29, Table 9-137). 1312 +------------------------------------------+ 1313 | Access | Designative | AIFS | 1314 | Category | (informative) |(slot times)| 1315 |===========+=================+============| 1316 | AC_VO | Voice | 2 | 1317 +-----------+-----------------+------------+ 1318 | AC_VI | Video | 2 | 1319 +-----------+-----------------+------------+ 1320 | AC_BE | Best Effort | 3 | 1321 +-----------+-----------------+------------+ 1322 | AC_BK | Background | 7 | 1323 +-----------+-----------------+------------+ 1325 Figure 3: Arbitration Interframe Spaces by Access Category 1327 6.2.4. Access Category Contention Windows (CW) 1329 Not only is the fixed amount of time that a station has to wait 1330 skewed according to [IEEE.802.11-2016] access category, but so are 1331 the relative sizes of the Contention Windows that bound the random 1332 backoff timers, as shown in Figure 4 (adapted from 1333 [IEEE.802.11-2016], Section 9.4.2.29, Table 9-137). 1335 +-------------------------------------------------------+ 1336 | Access | Designative | CWmin | CWmax | 1337 | Category | (informative) |(slot times)|(slot times)| 1338 |===========+=================+============|============| 1339 | AC_VO | Voice | 3 | 7 | 1340 +-----------+-----------------+------------+------------+ 1341 | AC_VI | Video | 7 | 15 | 1342 +-----------+-----------------+------------+------------+ 1343 | AC_BE | Best Effort | 15 | 1023 | 1344 +-----------+-----------------+------------+------------+ 1345 | AC_BK | Background | 15 | 1023 | 1346 +-----------+-----------------+------------+------------+ 1348 Figure 4: Contention Window Sizes by Access Category 1350 When the fixed and randomly generated timers are added together on a 1351 per access category basis, then traffic assigned to the Voice Access 1352 Category (i.e. traffic marked to UP 6 or 7) will receive a 1353 statistically superior service relative to traffic assigned to the 1354 Video Access Category (i.e. traffic marked UP 5 and 4), which, in 1355 turn, will receive a statistically superior service relative to 1356 traffic assigned to the Best Effort Access Category traffic (i.e. 1358 traffic marked UP 3 and 0), which finally will receive a 1359 statistically superior service relative to traffic assigned to the 1360 Background Access Category traffic (i.e. traffic marked to UP 2 and 1361 1). 1363 6.3. IEEE 802.11u QoS Map Set 1365 IEEE 802.11u [IEEE.802-11u.2011] is an addendum that has now been 1366 included within the main [IEEE.802.11-2016] standard, and which 1367 includes, among other enhancements, a mechanism by which wireless 1368 access points can communicate DSCP to/from UP mappings that have been 1369 configured on the wired IP network. Specifically, a QoS Map Set 1370 information element (described in [IEEE.802.11-2016] Section 9.4.2.95 1371 and commonly referred to as the QoS Map element) is transmitted from 1372 an AP to a wireless endpoint device in an association / re- 1373 association Response frame (or within a special QoS Map Configure 1374 frame). 1376 The purpose of the QoS Map element is to provide the mapping of 1377 higher layer Quality of Service constructs (i.e. DSCP) to User 1378 Priorities. One intended effect of receiving such a map is for the 1379 wireless endpoint device (that supports this function and is 1380 administratively configured to enable it) to perform corresponding 1381 DSCP-to-UP mapping within the device (i.e. between applications and 1382 the operating system / wireless network interface hardware drivers) 1383 to align with what the APs are mapping in the downstream direction, 1384 so as to achieve consistent end-to-end QoS in both directions. 1386 The QoS Map element includes two key components: 1388 1) each of the eight UP values (0-7) are associated with a range of 1389 DSCP values, and 1391 2) (up to 21) exceptions from these range-based DSCP to/from UP 1392 mapping associations may be optionally and explicitly specified. 1394 In line with the recommendations put forward in this document, the 1395 following recommendations apply when the QoS Map element is enabled: 1397 1) each of the eight UP values (0-7) are RECOMMENDED to be mapped to 1398 DSCP 0 (as a baseline, so as to meet the recommendation made in 1399 Section 8.2 1401 2) (up to 21) exceptions from this baseline mapping are RECOMMENDED 1402 to be made in line with Section 4.3, to correspond to the Diffserv 1403 Codepoints that are in use over the IP network. 1405 It is important to note that the QoS Map element is intended to be 1406 transmitted from a wireless access point to a non-AP station. As 1407 such, the model where this element is used is that of a network where 1408 the AP is the edge of the Diffserv domain. Networks where the AP 1409 extends the Diffserv domain by connecting other APs and 1410 infrastructure devices through the IEEE 802.11 medium are not 1411 included in the cases covered by the presence of the QoS Map element, 1412 and therefore are not included in the present recommendation. 1414 7. IANA Considerations 1416 This memo asks the IANA for no new parameters. 1418 8. Security Considerations 1420 The recommendations in this document concern widely-deployed wired 1421 and wireless network functionality, and for that reason do not 1422 present additional security concerns that do not already exist in 1423 these networks. In fact, several of the recommendations made in this 1424 document serve to protect wired and wireless networks from potential 1425 abuse, as is discussed further in this section. 1427 8.1. General QoS Security Recommendations 1429 It may be possible for a wired or wireless device (which could be 1430 either a host or a network device) to mark packets (or map packet 1431 markings) in a manner that interferes with or degrades existing QoS 1432 policies. Such marking or mapping may be done intentionally or 1433 unintentionally by developers and/or users and/or administrators of 1434 such devices. 1436 To illustrate: A gaming application designed to run on a smart-phone 1437 or tablet may request that all its packets be marked DSCP EF and/or 1438 UP 6. However, if the traffic from such an application is forwarded 1439 without change over a business network, then this could interfere 1440 with QoS policies intended to provide priority services for business 1441 voice applications. 1443 To mitigate such scenarios it is RECOMMENDED to implement general QoS 1444 security measures, including: 1446 o Setting a traffic conditioning policy reflective of business 1447 objectives and policy, such that traffic from authorized users 1448 and/or applications and/or endpoints will be accepted by the 1449 network; otherwise packet markings will be "bleached" (i.e. 1450 remarked to DSCP DF and/or UP 0). Additionally, Section 5.3 made 1451 it clear that it is generally NOT RECOMMENDED to pass through DSCP 1452 markings from unauthorized and/or unauthenticated devices, as 1453 these are typically considered untrusted sources. This is 1454 especially relevant for IoT deployments, where tens-of-billions of 1455 devices are being connected to IP networks with little or no 1456 security capabilities (making such vulernable to be utilized as 1457 agents for DDoS attacks, the effects of which can be amplified 1458 with preferential QoS treatments, should the packet markings of 1459 such devices be trusted). 1461 o Policing EF marked packet flows, as detailed in [RFC2474] 1462 Section 7 and [RFC3246] Section 3. 1464 In addition to these general QoS security recommendations, WLAN- 1465 specific QoS security recommendations can serve to further mitigate 1466 attacks and potential network abuse. 1468 8.2. WLAN QoS Security Recommendations 1470 The wireless LAN presents a unique DoS attack vector, as endpoint 1471 devices contend for the shared media on a completely egalitarian 1472 basis with the network (as represented by the AP). This means that 1473 any wireless client could potentially monopolize the air by sending 1474 packets marked to preferred UP values (i.e. UP values 4-7) in the 1475 upstream direction. Similarly, airtime could be monopolized if 1476 excessive amounts of downstream traffic were marked/mapped to these 1477 same preferred UP values. As such, the ability to mark/map to these 1478 preferred UP values (of UP 4-7) should be controlled. 1480 If such marking/mapping were not controlled, then, for example, a 1481 malicious user could cause WLAN DoS by flooding traffic marked CS7 1482 DSCP downstream. This codepoint would map by default (as described 1483 in Section 2.3) to UP 7 and would be assigned to the Voice Access 1484 Category (AC_VO). Such a flood could cause Denial-of-Service to not 1485 only wireless voice applications, but also to all other traffic 1486 classes. Similarly, an uninformed application developer may request 1487 all traffic from his/her application to be marked CS7 or CS6, 1488 thinking this would acheive in the best overall servicing of their 1489 application traffic, while not realizing that such a marking (if 1490 honored by the client operating system) could cause not only WLAN 1491 DoS, but also IP network instability, as the traffic marked CS7 or 1492 CS6 finds its way into queues intended for servicing (relatively low- 1493 bandwidth) network control protocols, potentially starving legitimate 1494 network control protocols in the process. 1496 Therefore, to mitigate such an attack, it is RECOMMENDED that all 1497 packets marked to Diffserv Codepoints not authorized or explicitly 1498 provisioned for use over the wireless network by the network 1499 administrator be mapped to UP 0; this recommendation applies both at 1500 the access point (in the downstream direction) and within the 1501 wireless endpoint device operating system (in the upstream 1502 direction). 1504 Such a policy of mapping unused codepoints to UP 0 would also prevent 1505 an attack where non-standard codepoints were used to cause WLAN DoS. 1506 Consider the case where codepoints are mapped to UP values using a 1507 range function (e.g. DSCP values 48-55 all map to UP 6), then an 1508 attacker could flood packets marked, for example to DSCP 49, in 1509 either the upstream or downstream direction over the WLAN, causing 1510 DoS to all other traffic classes in the process. 1512 In the majority of WLAN deployments, the AP represents not only the 1513 edge of the Diffserv domain, but also the edge of the network 1514 infrastructure itself; that is, only wireless client endpoint devices 1515 are downstream from the AP. In such a deployment model, CS6 and CS7 1516 also fall into the category of codepoints that are not in use over 1517 the wireless LAN (since only wireless endpoint client devices are 1518 downstream from the AP in this model and these devices do not 1519 [legitimately] participate in network control protocol exchanges). 1520 As such, it is RECOMMENDED that CS6 and CS7 DSCP be mapped to UP 0 in 1521 these Wifi-at-the-edge deployment models. Otherwise, it would be 1522 easy for a malicious application developer, or even an inadvertently 1523 poorly-programmed IoT device, to cause WLAN DoS and even wired IP 1524 network instability by flooding traffic marked CS6 DSCP, which would 1525 by default (as described in Section 2.3) be mapped to UP 6, causing 1526 all other traffic classes on the WLAN to be starved, as well 1527 hijacking queues on the wired IP network that are intended for the 1528 servicing of routing protocols. To this point, it was also 1529 recommended in Section 5.1 that packets requesting a marking of CS6 1530 or CS7 DSCP SHOULD be remarked to DSCP 0 and mapped to UP 0 by the 1531 wireless client operating system. 1533 Finally, it should be noted that the recommendations put forward in 1534 this document are not intended to address all attack vectors 1535 leveraging QoS marking abuse. Mechanisms that may further help 1536 mitigate security risks of both wired and wireless networks deploying 1537 QoS include strong device- and/or user-authentication, access- 1538 control, rate limiting, control-plane policing, encryption and other 1539 techniques; however, the implementation recommendations for such 1540 mechanisms are beyond the scope of this document to address in 1541 detail. Suffice it to say that the security of the devices and 1542 networks implementing QoS, including QoS mapping between wired and 1543 wireless networks, merits consideration in actual deployments. 1545 9. Acknowledgements 1547 The authors wish to thank David Black, Gorry Fairhurst, Ruediger 1548 Geib, Vincent Roca, Brian Carpenter, David Blake, Cullen Jennings, 1549 David Benham and the TSVWG. 1551 The authors also acknowledge a great many inputs, notably from David 1552 Kloper, Mark Montanez, Glen Lavers, Michael Fingleton, Sarav 1553 Radhakrishnan, Karthik Dakshinamoorthy, Simone Arena, Ranga Marathe, 1554 Ramachandra Murthy and many others. 1556 10. References 1558 10.1. Normative References 1560 [IEEE.802.11-2016] 1561 "Information technology - Telecommunications and 1562 information exchange between systems - Local and 1563 metropolitan area networks - Specific requirements - Part 1564 11: Wireless LAN Medium Access Control (MAC) and Physical 1565 Layer (PHY) specifications", IEEE Standard 802.11, 2016, 1566 . 1569 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1570 Requirement Levels", BCP 14, RFC 2119, 1571 DOI 10.17487/RFC2119, March 1997, 1572 . 1574 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1575 "Definition of the Differentiated Services Field (DS 1576 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1577 DOI 10.17487/RFC2474, December 1998, 1578 . 1580 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 1581 "Assured Forwarding PHB Group", RFC 2597, 1582 DOI 10.17487/RFC2597, June 1999, 1583 . 1585 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1586 of Explicit Congestion Notification (ECN) to IP", 1587 RFC 3168, DOI 10.17487/RFC3168, September 2001, 1588 . 1590 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 1591 J., Courtney, W., Davari, S., Firoiu, V., and D. 1592 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 1593 Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002, 1594 . 1596 [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort 1597 Per-Domain Behavior (PDB) for Differentiated Services", 1598 RFC 3662, DOI 10.17487/RFC3662, December 2003, 1599 . 1601 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 1602 Guidelines for DiffServ Service Classes", RFC 4594, 1603 DOI 10.17487/RFC4594, August 2006, 1604 . 1606 [RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated 1607 Services Code Point (DSCP) for Capacity-Admitted Traffic", 1608 RFC 5865, DOI 10.17487/RFC5865, May 2010, 1609 . 1611 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1612 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1613 May 2017, . 1615 10.2. Informative References 1617 [GSMA-IPX_Guidelines] 1618 "Guidelines for IPX Provider networks (Previously Inter- 1619 Service Provider IP Backbone Guidelines) Version 11.0", 1620 GSMA Official Document, November 2014, 1621 . 1624 [I-D.ietf-tsvwg-le-phb] 1625 Bless, R., "A Lower Effort Per-Hop Behavior (LE PHB)", 1626 draft-ietf-tsvwg-le-phb-02 (work in progress), June 2017. 1628 [IEEE.802-11u.2011] 1629 "Information technology - Telecommunications and 1630 information exchange between systems - Local and 1631 metropolitan area networks - Specific requirements - Part 1632 11: Wireless LAN Medium Access Control (MAC) and Physical 1633 Layer (PHY) specifications", IEEE Standard 802.11, 2011, 1634 . 1637 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1638 and W. Weiss, "An Architecture for Differentiated 1639 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 1640 . 1642 [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of 1643 Diffserv Service Classes", RFC 5127, DOI 10.17487/RFC5127, 1644 February 2008, . 1646 [RFC7561] Kaippallimalil, J., Pazhyannur, R., and P. Yegani, 1647 "Mapping Quality of Service (QoS) Procedures of Proxy 1648 Mobile IPv6 (PMIPv6) and WLAN", RFC 7561, 1649 DOI 10.17487/RFC7561, June 2015, 1650 . 1652 [RFC8100] Geib, R., Ed. and D. Black, "Diffserv-Interconnection 1653 Classes and Practice", RFC 8100, DOI 10.17487/RFC8100, 1654 March 2017, . 1656 Appendix A. Change Log 1658 Initial Version: July 2015 1660 Authors' Addresses 1662 Tim Szigeti 1663 Cisco Systems 1664 Vancouver, British Columbia V6K 3L4 1665 Canada 1667 Email: szigeti@cisco.com 1669 Jerome Henry 1670 Cisco Systems 1671 Research Triangle Park, North Carolina 27709 1672 USA 1674 Email: jerhenry@cisco.com 1676 Fred Baker 1677 Santa Barbara, California 93117 1678 USA 1680 Email: FredBaker.IETF@gmail.com