idnits 2.17.1 draft-ietf-tsvwg-ieee-802-11-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (May 8, 2017) is 2544 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' ** Downref: Normative reference to an Informational RFC: RFC 2475 ** Obsolete normative reference: RFC 3662 (Obsoleted by RFC 8622) ** Downref: Normative reference to an Informational RFC: RFC 4594 ** Downref: Normative reference to an Informational RFC: RFC 5127 ** Downref: Normative reference to an Informational RFC: RFC 8100 Summary: 5 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: Standards Track Cisco Systems 5 Expires: November 9, 2017 F. Baker 6 May 8, 2017 8 Diffserv to IEEE 802.11 Mapping 9 draft-ietf-tsvwg-ieee-802-11-02 11 Abstract 13 As internet traffic is increasingly sourced-from and destined-to 14 wireless endpoints, it is crucial that Quality of Service be aligned 15 between wired and wireless networks; however, this is not always the 16 case by default. This document specifies a set Differentiated 17 Services Code Point (DSCP) to IEEE 802.11 User Priority (UP) mappings 18 to reconcile the marking recommendations offered by the IETF and the 19 IEEE so as to maintain consistent QoS treatment between wired and 20 IEEE 802.11 wireless networks. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on November 9, 2017. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Related work . . . . . . . . . . . . . . . . . . . . . . 3 58 1.2. Interaction with RFC 7561 . . . . . . . . . . . . . . . . 4 59 1.3. Applicability Statement . . . . . . . . . . . . . . . . . 4 60 1.4. Document Organization . . . . . . . . . . . . . . . . . . 5 61 1.5. Requirements Language . . . . . . . . . . . . . . . . . . 5 62 1.6. Terminology Used in this Document . . . . . . . . . . . . 5 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 . . . . . . . . 9 67 2.3. Default UP-to-DSCP Mappings and Conflicts . . . . . . . . 10 68 3. Wireless Device Marking and Mapping Capability 69 Recommendations . . . . . . . . . . . . . . . . . . . . . . . 12 70 4. DSCP-to-UP Mapping Recommendations . . . . . . . . . . . . . 12 71 4.1. Network Control Traffic . . . . . . . . . . . . . . . . . 13 72 4.1.1. Network Control Protocols . . . . . . . . . . . . . . 13 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-Trust at the Wireless Access Point . . . . 22 91 5.4. Upstream DSCP Marking at the Wireless Access Point . . . 22 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) . . . . . . . . . . . 25 99 6.2.1. User Priority (UP) . . . . . . . . . . . . . . . . . 25 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) . . . . . . . 27 103 6.3. IEEE 802.11u QoS Map Set . . . . . . . . . . . . . . . . 28 104 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 105 8. Security Considerations . . . . . . . . . . . . . . . . . . . 29 106 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 107 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 108 10.1. Normative References . . . . . . . . . . . . . . . . . . 31 109 10.2. Informative References . . . . . . . . . . . . . . . . . 32 110 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 33 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 113 1. Introduction 115 Wireless has become the preferred medium for endpoints connecting to 116 business and private networks. However, the wireless medium defined 117 by IEEE 802.11 [IEEE.802.11-2016] presents several design challenges 118 for ensuring end-to-end quality of service. Some of these challenges 119 relate to the nature of the IEEE 802.11 RF medium itself, being a 120 half-duplex and shared medium, while other challenges relate to the 121 fact that the IEEE 802.11 standard is not administered by the same 122 standards body as IP networking standards. While the IEEE has 123 developed tools to enable QoS over wireless networks, little guidance 124 exists on how to maintain consistency of QoS treatment between wired 125 IP and wireless IEEE 802.11 networks. The purpose of this document 126 is to provide such guidance. 128 1.1. Related work 130 Several RFCs outline Diffserv QoS recommendations over IP networks, 131 including: 133 o [RFC2474] specifies the Diffserv Codepoint Field. This RFC also 134 details Class Selectors, as well as the Default Forwarding (DF) 135 treatment. 137 o [RFC2475] defines a Diffserv architecture 139 o [RFC3246] specifies the Expedited Forwarding (EF) Per-Hop Behavior 140 (PHB) 142 o [RFC2597] specifies the Assured Forwarding (AF) PHB. 144 o [RFC3662] specifies a Lower Effort Per-Domain Behavior (PDB) 145 o [RFC4594] presents Configuration Guidelines for Diffserv Service 146 Classes 148 o [RFC5127] presents the Aggregation of Diffserv Service Classes 150 o [RFC5865] specifies a DSCP for Capacity Admitted Traffic 152 Note: [RFC4594] is intended to be viewed as a set of "project plans" 153 for building all the (diffserv) furniture that one might want. Thus, 154 it describes different types of traffic expected in IP networks and 155 provides guidance as to what DSCP marking(s) should be associated 156 with each traffic type. As such, this document draws heavily on 157 [RFC4594], [RFC5127], and [RFC8100]. 159 In turn, the relevant standard for wireless QoS is IEEE 802.11, which 160 is being progressively updated; the current version of which (at the 161 time of writing) is [IEEE.802.11-2016]. 163 1.2. Interaction with RFC 7561 165 There is also a recommendation from the GSMA, Mapping Quality of 166 Service (QoS) Procedures of Proxy Mobile IPv6 (PMIPv6) and WLAN 167 [RFC7561]. The GSMA specification was developed without reference to 168 existing IETF specifications for various services, referenced in 169 Section 1.1. Thus, [RFC7561] conflicts with the overall Diffserv 170 traffic-conditioning service plan, both in the services specified and 171 the code points specified for them. As such, these two plans cannot 172 be normalized. Rather, as discussed in [RFC2474] Section 2, the two 173 domains (IEEE 802.11 and GSMA) are different Differentiated Services 174 Domains separated by a Differentiated Services Boundary. At that 175 boundary, code points from one domain are translated to code points 176 for the other, and maybe to Default (zero) if there is no 177 corresponding service to translate to. 179 1.3. Applicability Statement 181 This document is applicable to the use of Differentiated Services 182 that interconnect with IEEE 802.11 wireless LANs (referred to as Wi- 183 Fi, throughout this document, for simplicity). These guidelines are 184 applicable whether the wireless access points (APs) are deployed in 185 an autonomous manner, managed by (centralized or distributed) WLAN 186 controllers or some hybrid deployment option. This is because in all 187 these cases, the wireless access point is the bridge between wired 188 and wireless media. 190 This document applies to IP networks using WiFi infrastructure at the 191 link layer. Such networks typically include wired LANs with wireless 192 access points at their edges, however, such networks can also include 193 Wi-Fi backhaul, wireless mesh solutions or any other type of AP-to-AP 194 wireless network that extends the wired network infrastructure. 196 1.4. Document Organization 198 This document is organized as follows: 200 o Section 1 introduces the wired-to-wireless QoS challenge, 201 references related work, outlines the organization of the 202 document, and specifies both the requirements language and the 203 terminology used in this document. 205 o Section 2 begins the discussion with a comparison of IETF Diffserv 206 QoS and Wi-Fi QoS standards and highlights discrepancies between 207 these that require reconciliation. 209 o Section 3 presents the marking and mapping capabilities that 210 wireless access points and wireless endpoint devices are 211 recommended to support. 213 o Section 4 presents DSCP-to-UP mapping recommendations for each of 214 the [RFC4594] service classes, which are primarily applicable in 215 the downstream (wired-to-wireless) direction. 217 o Section 5, in turn, considers upstream (wireless-to-wired) QoS 218 options, their respective merits and recommendations. 220 o Section 6 (in the form of an Appendix) presents a brief overview 221 of how QoS is achieved over IEEE 802.11 wireless networks, given 222 the shared, half-duplex nature of the wireless medium. 224 o Section 7 on notes IANA considerations, security considerations, 225 acknowledgements and references, respectively 227 1.5. Requirements Language 229 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 230 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL", and "NOT 231 RECOMMENDED" in this document are to be interpreted as described in 232 [RFC2119]. 234 1.6. Terminology Used in this Document 236 Key terminology used in this document includes: 238 AC: Access Category. A label for the common set of enhanced 239 distributed channel access (EDCA) parameters that are used by a 240 quality-of-service (QoS) station (STA) to contend for the channel 241 in order to transmit medium access control (MAC) service data 242 units (MSDUs) with certain priorities. [IEEE.802.11-2016] 243 Section 3.2. 245 AIFS: Arbitration Interframe Space. Interframe space used by QoS 246 stations before transmission of data and other frame types defined 247 by [IEEE.802.11-2016] Section 10.3.2.3.6. 249 AP: Access Point. An entity that contains one station (STA) and 250 provides access to the distribution services, via the wireless 251 medium (WM) for associated STAs. An AP comprises a STA and a 252 distribution system access function (DSAF) [IEEE.802.11-2016] 253 Section 3.1. 255 BSS: Basic Service Set. Informally, a wireless cell; formally, a 256 set of stations that have successfully synchronized using the JOIN 257 service primitives and one STA that has used the START primitive. 258 Alternatively, a set of STAs that have used the START primitive 259 specifying matching mesh profiles where the match of the mesh 260 profiles has been verified via the scanning procedure. Membership 261 in a BSS does not imply that wireless communication with all other 262 members of the BSS is possible. Defined in [IEEE.802.11-2016] 263 Section 3.1. 265 Contention Window: See CW. 267 CSMA/CA: Carrier Sense Multiple Access with Collision Avoidance. 268 A media access control method in which carrier sensing is used, 269 but nodes attempt to avoid collisions by transmitting only when 270 the channel is sensed to be "idle". When these do transmit, nodes 271 transmit their packet data in its entirety. 273 CSMA/CD: Carrier Sense Multiple Access with Collision Detection. 274 A media access control method (used most notably in early Ethernet 275 technology) for local area networking. It uses a carrier-sensing 276 scheme in which a transmitting station detects collisions by 277 sensing transmissions from other stations while transmitting a 278 frame. When this collision condition is detected, the station 279 stops transmitting that frame, transmits a jam signal, and then 280 waits for a random time interval before trying to resend the 281 frame. 283 CW: Contention Window. Limits a CWMin and CWMax, from which a 284 random backoff is computed. 286 CWMax: Contention Window Maximum. The maximum value (in unit of 287 Slot Time) that a contention window can take. 289 CWMin: Contention Window Minimum. The minimum value that a 290 contention window can take. 292 DCF: Distributed Coordinated Function. A class of coordination 293 function where the same coordination function logic is active in 294 every station (STA) in the basic service set (BSS) whenever the 295 network is in operation. 297 DIFS: Distributed (Coordination Function) Interframe Space. A 298 unit of time during which the medium has to be detected as idle 299 before a station should attempt to send frames, as per 300 [IEEE.802.11-2016] Section 10.3.2.3.5. 302 DSCP: Differentiated Service Code Point [RFC2474] and [RFC2475]. 304 HCF: Hybrid Coordination Function A coordination function that 305 combines and enhances aspects of the contention based and 306 contention free access methods to provide quality-of-service (QoS) 307 stations (STAs) with prioritized and parameterized QoS access to 308 the wireless medium (WM), while continuing to support non-QoS STAs 309 for best-effort transfer. [IEEE.802.11-2016] Section 3.1. 311 IFS: Interframe Space. Period of silence between transmissions 312 over 802.11 networks. [IEEE.802.11-2016] describes several types 313 of Interframe Spaces. 315 Random Backoff Timer: A pseudorandom integer period of time (in 316 units of Slot Time) over the interval (0,CW), where CWmin is-less- 317 than-or-equal-to CW, which in turn is less-than-or-equal-to CWMax. 318 Stations desiring to initiate transfer of data frames and-or 319 Management frames using the DCF shall invoke the carrier sense 320 mechanism to determine the busy-or-idle state of the medium. If 321 the medium is busy, the STA shall defer until the medium is 322 determined to be idle without interruption for a period of time 323 equal to DIFS when the last frame detected on the medium was 324 received correctly, or after the medium is determined to be idle 325 without interruption for a period of time equal to EIFS when the 326 last frame detected on the medium was not received correctly. 327 After this DIFS or EIFS medium idle time, the STA shall then 328 generate a random backoff period for an additional deferral time 329 before transmitting. [IEEE.802.11-2016] Section 10.3.3. 331 RF: Radio Frequency. 333 SIFS: Short Interframe Space. An IFS used before transmission of 334 specific frames as defined in [IEEE.802.11-2016] 335 Section 10.3.2.3.3. 337 Slot Time: A unit of time used to count time intervals in 802.11 338 networks, and defined in [IEEE.802.11-2016] Section 10.3.2.13. 340 Trust: From a QoS-perspective, trust refers to the accepting of 341 the QoS markings of a packet by a network device. Trust is 342 typically extended at Layer 3 (by accepting the DSCP), but may 343 also be extended at lower layers, such as at Layer 2 by accepting 344 User Priority markings. For example, if an access point is 345 configured to trust DSCP markings and it receives a packet marked 346 EF, then it would treat the packet with the Expedite Forwarding 347 PHB and propagate the EF marking value (DSCP 46) as it transmits 348 the packet. Alternatively, if a network device is configured to 349 operate in an untrusted manner, then it would remark packets as 350 these entered the device, typically to DF (or to a different 351 marking value at the network administrator's preference). Note: 352 The terms "trusted" and "untrusted" are used extensively in RFC 353 4594. 355 UP: User Priority. A value associated with a medium access 356 control (MAC) service data unit (MSDU) that indicates how the MSDU 357 is to be handled. The UP is assigned to an MSDU in the layers 358 above the MAC [IEEE.802.11-2016] Section 3.1. The UP defines a 359 level of priority for the associated frame, on a scale of 0 to 7. 361 Wi-Fi: An interoperability certification defined by the Wi-Fi 362 Alliance. However, this term is commonly used, including in the 363 present document, to be the equivalent of IEEE 802.11. 365 2. Service Comparison and Default Interoperation of Diffserv and IEEE 366 802.11 368 (Section 6 provides a brief overview of IEEE 802.11 QoS.) 370 The following comparisons between IEEE 802.11 and Diffserv services 371 should be noted: 373 o [IEEE.802.11-2016] does not support a [RFC3246] EF PHB service, as 374 it is not possible to assure that a given access category will be 375 serviced with strict priority over another (due to the random 376 element within the contention process) 378 o [IEEE.802.11-2016] does not support a [RFC2597] AF PHB service, 379 again because it is not possible to assure that a given access 380 category will be serviced with a minimum amount of assured 381 bandwidth (due to the non-deterministic nature of the contention 382 process) 384 o [IEEE.802.11-2016] loosely supports a [RFC2474] Default Forwarding 385 service via the Best Effort Access Category (AC_BE) 387 o [IEEE.802.11-2016] loosely supports a [RFC3662] Lower Effort PDB 388 service via the Background Access Category (AC_BK) 390 As such, these high-level considerations should be kept in mind when 391 mapping from Diffserv to [IEEE.802.11-2016] (and vice-versa); 392 however, access points may or may not always be positioned at 393 Diffserv domain boundaries, as will be discussed next. 395 2.1. Diffserv Domain Boundaries 397 It is important to note that the wired-to-wireless edge may or may 398 not equate to the edge of the Diffserv domain. 400 In most commonly-deployed WLAN models, the wireless access point 401 represents not only the edge of the Diffserv domain, but also the 402 edge of the network infrastructure itself. As such, only client 403 devices (and no infrastructure devices) are downstream from the 404 access points in these deployment models. In such deployment models, 405 it is RECOMMENDED that all packets marked to Diffserv Codepoints not 406 in use over the wireless network be dropped or remarked at the edge 407 of the Diffserv domain, as will be discussed in detail in 408 Section 4.1.1. 410 Alternatively, in other deployment models, such as Wi-Fi backhaul, 411 wireless mesh infrastructures, or other types of wireless AP-to-AP 412 deployments, the wireless access points extend the network 413 infrastructure and thus, typically, the Diffserv domain. In such 414 deployments, both client devices and infrastructure devices may be 415 expected downstream from the access points. 417 Thus the QoS treatment of packets at the access point will depend on 418 the position of the AP in the network infrastructure and on the WLAN 419 deployment model. 421 However, regardless of the access point being at the Diffserv 422 boundary or not, Diffserv to [IEEE.802.11-2016] (and vice-versa) 423 marking-specific incompatibilities exist that must be reconciled, as 424 will be discussed next. 426 2.2. Default DSCP-to-UP Mappings and Conflicts 428 While no explicit guidance is offered in mapping (6-Bit) Layer 3 DSCP 429 values to (3-Bit) Layer 2 markings (such as IEEE 802.1D, 802.1p or 430 802.11e), a common practice in the networking industry is to map 431 these by what we will refer to as 'Default DSCP-to-UP Mapping' (for 432 lack of a better term), wherein the 3 Most Significant Bits (MSB) of 433 the DSCP are used as the corresponding L2 markings. 435 Note: There are mappings provided in [IEEE.802.11-2016] Annex V 436 Tables V-1 and V2, but it bears mentioning that these mappings are 437 provided as examples (as opposed to explicit recommendations). 438 Furthermore, some of these mappings do not align with the intent and 439 recommendations expressed in [RFC4594], as will be discussed in this 440 and the following section (Section 2.3). 442 However, when this default DSCP-to-UP mapping method is applied to 443 packets marked per [RFC4594] recommendations and destined to 802.11 444 WLAN clients, it will yield a number of inconsistent QoS mappings, 445 specifically: 447 o Voice (EF-101110) will be mapped to UP 5 (101), and treated in the 448 Video Access Category (AC_VI), rather than the Voice Access 449 Category (AC_VO), for which it is intended 451 o Multimedia Streaming (AF3-011xx0) will be mapped to UP3 (011) and 452 treated in the Best Effort Access Category (AC_BE), rather than 453 the Video Access Category (AC_VI), for which it is intended 455 o OAM traffic (CS2-010000) will be mapped to UP 2 (010) and treated 456 in the Background Access Category (AC_BK), which is not the intent 457 expressed in [RFC4594] for this service class 459 It should also be noted that while [IEEE.802.11-2016] defines an 460 intended use for each access category through the AC naming 461 convention (for example, UP 6 and UP 7 belong to AC_VO, the Voice 462 Access Category), [IEEE.802.11-2016] does not: 464 o define how upper layer markings (such as DSCP) should map to UPs 465 (and hence to ACs) 467 o define how UPs should translate to other medium Layer 2 QoS 468 markings 470 o strictly restrict each access category to applications reflected 471 in the AC name 473 2.3. Default UP-to-DSCP Mappings and Conflicts 475 In the opposite direction of flow (the upstream direction, that is, 476 from wireless-to-wired), many APs use what we will refer to as 477 'Default UP-to-DSCP Mapping' (for lack of a better term), wherein 478 DSCP values are derived from UP values by multiplying the UP values 479 by 8 (i.e. shifting the 3 UP bits to the left and adding three 480 additional zeros to generate a DSCP value). This derived DSCP value 481 is then used for QoS treatment between the wireless access point and 482 the nearest classification and marking policy enforcement point 483 (which may be the centralized wireless LAN controller, relatively 484 deep within the network). 486 It goes without saying that when 6 bits of marking granularity are 487 derived from 3, then information is lost in translation. Servicing 488 differentiation cannot be made for 12 classes of traffic (as 489 recommended in [RFC4594]), but for only 8 (with one of these classes 490 being reserved for future use (i.e. UP 7 which maps to DSCP CS7). 492 Such default upstream mapping can also yield several inconsistencies 493 with [RFC4594], including: 495 o Mapping UP 6 ([RFC4594] Voice) to CS6, which [RFC4594] recommends 496 for Network Control 498 o Mapping UP 4 ([RFC4594] Multimedia Conferencing and/or Real-Time 499 Interactive) to CS4, thus losing the ability to differentiate 500 between these two distinct service classes, as recommended in 501 [RFC4594] Sections 4.3 and 4.4 503 o Mapping UP 3 ([RFC4594] Multimedia Streaming and/or Broadcast 504 Video) to CS3, thus losing the ability to differentiate between 505 these two distinct service classes, as recommended in [RFC4594] 506 Sections 4.5 and 4.6 508 o Mapping UP 2 ([RFC4594] Low-Latency Data and/or OAM) to CS2, thus 509 losing the ability to differentiate between these two distinct 510 service classes, as recommended in [RFC4594] Sections 4.7 and 3.3, 511 and possibly overwhelming the queues provisioned for OAM (which is 512 typically lower in capacity [being network control traffic], as 513 compared to Low-Latency Data queues [being user traffic]) 515 o Mapping UP 1 ([RFC4594] High-Throughput Data and/or Low-Priority 516 Data) to CS1, thus losing the ability to differentiate between 517 these two distinct service classes, as recommended in [RFC4594] 518 Sections 4.8 and 4.10, and causing legitimate business-relevant 519 High-Throughput Data to receive a [RFC3662] Lower Effort PDB, for 520 which it is not intended 522 The following sections address these limitations and concerns in 523 order to reconcile [RFC4594] and [IEEE.802.11-2016]. First 524 downstream (wired-to-wireless) DSCP-to-UP mappings will be aligned 525 and then upstream (wireless-to-wired) models will be addressed. 527 3. Wireless Device Marking and Mapping Capability Recommendations 529 This document assumes and RECOMMENDS that all wireless access points 530 (as the bridges between wired-and-wireless networks) support the 531 ability to: 533 o mark DSCP, per Diffserv standards 535 o mark UP, per the [IEEE.802.11-2016] standard 537 o support fully-configurable mappings between DSCP and UP 539 o trust DSCP markings set by wireless endpoint devices 541 This document further assumes and RECOMMENDS that all wireless 542 endpoint devices support the ability to: 544 o mark DSCP, per Diffserv standards 546 o mark UP, per the [IEEE.802.11-2016] standard 548 o support fully-configurable mappings between DSCP (set by 549 applications in software) and UP (set by the operating system and/ 550 or wireless network interface hardware drivers) 552 Having made the assumptions and recommendations above, it bears 553 mentioning while the mappings presented in this document are 554 RECOMMENDED to replace the current common default practices (as 555 discussed in Section 2.2 and Section 2.3), these mapping 556 recommendations are not expected to fit every last deployment model, 557 and as such MAY be overridden by network administrators, as needed. 559 4. DSCP-to-UP Mapping Recommendations 561 The following section specifies downstream (wired-to-wireless) 562 mappings between [RFC4594] Configuration Guidelines for Diffserv 563 Service Classes and [IEEE.802.11-2016]. As such, this section draws 564 heavily from [RFC4594], including service class definitions and 565 recommendations. 567 This section assumes [IEEE.802.11-2016] wireless access points and/or 568 WLAN controllers that support customizable, non-default DSCP-to-UP 569 mapping schemes. 571 This section also assumes that [IEEE.802.11-2016] access points and 572 endpoint devices differentiate UP markings with corresponding queuing 573 and dequeuing treatments. To illustrate, [IEEE.802.11-2016] displays 574 a reference implementation model in Figure 10-24 which depicts four 575 transmit queues, one per access category. In practical 576 implementations, however, it is common for WLAN network equipment 577 vendors to implement dedicated transmit queues on a per-UP (versus a 578 per access category) basis, which are then dequeued into their 579 associated access category in a preferred (or even in a strict 580 priority manner). For example, it is common for vendors to dequeue 581 UP 5 ahead of UP 4 to the hardware performing the EDCA function 582 (EDCAF) for the Video Access Category (AC_VI). As such, Signaling 583 traffic (marked UP 5, per the recommendations made in Section 4.2.2) 584 may benefit from such a treatment versus other video flows in the 585 same access category which are marked to UP 4 (in addition to a 586 preferred treatment over flows in the Best Effort and Background 587 access categories). 589 4.1. Network Control Traffic 591 Network control traffic is defined as packet flows that are essential 592 for stable operation of the administered network [RFC4594] Section 3. 593 Network control traffic is different from user application control 594 (signaling) that may be generated by some applications or services. 595 Network control traffic MAY be split into two service classes: 597 o Network Control, and 599 o Operations Administration and Management (OAM) 601 4.1.1. Network Control Protocols 603 The Network Control service class is used for transmitting packets 604 between network devices (routers) that require control (routing) 605 information to be exchanged between nodes within the administrative 606 domain as well as across a peering point between different 607 administrative domains. The RECOMMENDED DSCP marking for Network 608 Control is CS6, per [RFC4594] Section 3.2. 610 Before discussing a mapping recommendation for Network Control 611 traffic marked CS6 DSCP, it is interesting to note a relevant 612 recommendation from [RFC4594] pertaining to traffic marked CS7 DSCP: 613 in [RFC4594] Section 3.1 it is RECOMMENDED that packets marked CS7 614 DSCP (a codepoint that SHOULD be reserved for future use) be dropped 615 or remarked at the edge of the Diffserv domain. 617 Following this recommendation, it is RECOMMENDED that all packets 618 marked to Diffserv Codepoints not in use over the wireless network be 619 dropped or remarked at the edge of the Diffserv domain. 621 It is important to note that the wired-to-wireless edge may or may 622 not equate to the edge of the Diffserv domain, as discussed in 623 Section 2.1; as such, this recommendation may or may not apply at the 624 wired-to-wireless edge (and vice-versa). 626 In most commonly-deployed WLAN models, where wireless access point 627 represents not only the edge of the Diffserv domain, but also the 628 edge of the network infrastructure itself. Traffic marked CS7 DSCP 629 SHOULD be dropped or remarked at this edge (as it is typically 630 unused, as CS7 SHOULD be reserved for future use). Network control 631 traffic marked CS6 DSCP SHOULD also be dropped or remarked at this 632 edge, considering that only client devices (and no network 633 infrastructure devices) are downstream from the wireless access 634 points in these deployment models; such client devices would be 635 considered as untrusted sources of a network control traffic. In 636 such cases, no Network control traffic would be (legitimately) 637 expected to be sent or received from wireless client endpoint 638 devices, and thus this recommendation would apply. 640 Alternatively, in other deployment models, where the wireless access 641 point extends the network infrastructure and thus, typically, the 642 Diffserv domain, the above recommendation would not apply, as the 643 wired-to-wireless edge does not represent the edge of the Diffserv 644 domain. Furthermore, as these deployment models require Network 645 Control traffic to be propagated across the wireless network, it is 646 RECOMMENDED to map Network Control traffic marked CS6 to UP 7 (per 647 [IEEE.802.11-2016] Section 10.2.4.2, Table 10-1), thereby admitting 648 it to the Voice Access Category (AC_VO). Similarly, if CS7 is in use 649 as a network control protocol it would be RECOMMENDED to map it also 650 to UP 7. 652 It should be noted that encapsulated routing protocols for 653 encapsulated or overlay networks (e.g., VPN, NVO3) are not network 654 control traffic for any physical network at the AP, and hence SHOULD 655 NOT be marked with CS6 in the first place. 657 4.1.2. Operations Administration Management (OAM) 659 The OAM (Operations, Administration, and Management) service class is 660 RECOMMENDED for OAM&P (Operations, Administration, and Management and 661 Provisioning). The RECOMMENDED DSCP marking for OAM is CS2, per 662 [RFC4594] Section 3.3. 664 By default, packets marked DSCP CS2 will be mapped to UP 2 and 665 serviced with the Background Access Category (AC_BK). Such servicing 666 is a contradiction to the intent expressed in [RFC4594] Section 3.3. 667 As such, it is RECOMMENDED that a non-default mapping be applied to 668 OAM traffic, such that CS2 DSCP is mapped to UP 0, thereby admitting 669 it to the Best Effort Access Category (AC_BE). 671 4.2. User Traffic 673 User traffic is defined as packet flows between different users or 674 subscribers. It is the traffic that is sent to or from end-terminals 675 and that supports a very wide variety of applications and services 676 [RFC4594] Section 4. 678 Network administrators can categorize their applications according to 679 the type of behavior that they require and MAY choose to support all 680 or a subset of the defined service classes. 682 4.2.1. Telephony 684 The Telephony service class is RECOMMENDED for applications that 685 require real-time, very low delay, very low jitter, and very low 686 packet loss for relatively constant-rate traffic sources (inelastic 687 traffic sources). This service class SHOULD be used for IP telephony 688 service. The fundamental service offered to traffic in the Telephony 689 service class is minimum jitter, delay, and packet loss service up to 690 a specified upper bound. The RECOMMENDED DSCP marking for Telephony 691 is EF ([RFC4594] Section 4.1). 693 Traffic marked to DSCP EF will map by default to UP 5, and thus to 694 the Video Access Category (AC_VI), rather than to the Voice Access 695 Category (AC_VO), for which it is intended. Therefore, a non-default 696 DSCP-to-UP mapping is RECOMMENDED, such that EF DSCP is mapped to UP 697 6, thereby admitting it into the Voice Access Category (AC_VO). 699 Similarly, the [RFC5865] VOICE-ADMIT DSCP (44/101100) is RECOMMENDED 700 to be mapped to UP 6, thereby admitting it also into the Voice Access 701 Category (AC_VO). 703 4.2.2. Signaling 705 The Signaling service class is RECOMMENDED for delay-sensitive 706 client-server (e.g. traditional telephony) and peer-to-peer 707 application signaling. Telephony signaling includes signaling 708 between IP phone and soft-switch, soft-client and soft-switch, and 709 media gateway and soft-switch as well as peer-to-peer using various 710 protocols. This service class is intended to be used for control of 711 sessions and applications. The RECOMMENDED DSCP marking for 712 Signaling is CS5 ([RFC4594] Section 4.2). 714 While Signaling is RECOMMENDED to receive a superior level of service 715 relative to the default class (i.e. AC_BE), it does not require the 716 highest level of service (i.e. AC_VO). This leaves only the Video 717 Access Category (AC_VI), which it will map to by default. Therefore 718 it is RECOMMENDED to map Signaling traffic marked CS5 DSCP to UP 5, 719 thereby admitting it to the Video Access Category (AC_VI). 721 Note: Signaling traffic is not control plane traffic from the 722 perspective of the network (but rather is data plane traffic); as 723 such, it does not merit provisioning in the Network Control service 724 class (marked CS6 and mapped to UP 6). However, Signaling traffic is 725 control-plane traffic from the perspective of the voice/video 726 telephony overlay-infrastructure. As such, Signaling should be 727 treated with preferential servicing vs. other data plane flows. One 728 way this may be achieved in certain WLAN deployments is by mapping 729 Signaling traffic marked CS5 to UP 5 (as recommended above and 730 following the EDCAF treatment logic described in Section 4. 732 4.2.3. Multimedia Conferencing 734 The Multimedia Conferencing service class is RECOMMENDED for 735 applications that require real-time service for rate-adaptive 736 traffic. The RECOMMENDED DSCP markings for Multimedia Conferencing 737 are AF41, AF42 and AF43 ([RFC4594] Section 4.3). 739 The primary media type typically carried within the Multimedia 740 Conferencing service class is video; as such, it is RECOMMENDED to 741 map this class into the Video Access Category (which it does by 742 default). Specifically, it is RECOMMENDED to map AF41, AF42 and AF43 743 to UP 4, thereby admitting Multimedia Conferencing into the Video 744 Access Category (AC_VI). 746 4.2.4. Real-Time Interactive 748 The Real-Time Interactive service class is RECOMMENDED for 749 applications that require low loss and jitter and very low delay for 750 variable rate inelastic traffic sources. Such applications may 751 include inelastic video-conferencing applications, but may also 752 include gaming applications (as pointed out in [RFC4594] Sections 2.1 753 through 2.3, and Section 4.4). The RECOMMENDED DSCP marking for 754 Real-Time Interactive traffic is CS4 ([RFC4594] Section 4.4). 756 The primary media type typically carried within the Real-Time 757 Interactive service class is video; as such, it is RECOMMENDED to map 758 this class into the Video Access Category (which it does by default). 759 Specifically, it is RECOMMENDED to map CS4 to UP 4, thereby admitting 760 Real-Time Interactive traffic into the Video Access Category (AC_VI). 762 4.2.5. Multimedia-Streaming 764 The Multimedia Streaming service class is RECOMMENDED for 765 applications that require near-real-time packet forwarding of 766 variable rate elastic traffic sources. Typically these flows are 767 unidirectional. The RECOMMENDED DSCP markings for Multimedia 768 Streaming are AF31, AF32 and AF33 ([RFC4594] Section 4.5). 770 The primary media type typically carried within the Multimedia 771 Streaming service class is video; as such, it is RECOMMENDED to map 772 this class into the Video Access Category. Specifically, it is 773 RECOMMENDED to map AF31, AF32 and AF33 to UP 4, thereby admitting 774 Multimedia Streaming into the Video Access Category (AC_VI). 776 4.2.6. Broadcast Video 778 The Broadcast Video service class is RECOMMENDED for applications 779 that require near-real-time packet forwarding with very low packet 780 loss of constant rate and variable rate inelastic traffic sources. 781 Typically these flows are unidirectional. The RECOMMENDED DSCP 782 marking for Broadcast Video is CS3 ([RFC4594] Section 4.6). 784 As directly implied by the name, the primary media type typically 785 carried within the Broadcast Video service class is video; as such, 786 it is RECOMMENDED to map this class into the Video Access Category. 787 Specifically, it is RECOMMENDED to map CS4 to UP 4, thereby admitting 788 Broadcast Video into the Video Access Category (AC_VI). 790 4.2.7. Low-Latency Data 792 The Low-Latency Data service class is RECOMMENDED for elastic and 793 time-sensitive data applications, often of a transactional nature, 794 where a user is waiting for a response via the network in order to 795 continue with a task at hand. As such, these flows are considered 796 foreground traffic, with delays or drops to such traffic directly 797 impacting user-productivity. The RECOMMENDED DSCP markings for Low- 798 Latency Data are AF21, AF22 and AF23 ([RFC4594] Section 4.7). 800 In line with the assumption made in Section 4, mapping Low-Latency 801 Data to UP 3 may allow such to receive a superior level of service 802 via transmit queues servicing the EDCAF hardware for the Best Effort 803 Access Category (AC_BE). Therefore it is RECOMMENDED to map Low- 804 Latency Data traffic marked AF2x DSCP to UP 3, thereby admitting it 805 to the Best Effort Access Category (AC_BE). 807 4.2.8. High-Throughput Data 809 The High-Throughput Data service class is RECOMMENDED for elastic 810 applications that require timely packet forwarding of variable rate 811 traffic sources and, more specifically, is configured to provide 812 efficient, yet constrained (when necessary) throughput for TCP 813 longer-lived flows. These flows are typically non-user-interactive. 814 Per [RFC4594]-Section 4.8, it can be assumed that this class will 815 consume any available bandwidth and that packets traversing congested 816 links may experience higher queuing delays or packet loss. It is 817 also assumed that this traffic is elastic and responds dynamically to 818 packet loss. The RECOMMENDED DSCP markings for High-Throughput Data 819 are AF11, AF12 and AF13 ([RFC4594] Section 4.8). 821 Unfortunately, there really is no corresponding fit for the High- 822 Throughput Data service class within the constrained 4 Access 823 Category [IEEE.802.11-2016] model. If the High-Throughput Data 824 service class is assigned to the Best Effort Access Category (AC_BE), 825 then it would contend with Low-Latency Data (while [RFC4594] 826 recommends a distinction in servicing between these service classes) 827 as well as with the default service class; alternatively, if it is 828 assigned to the Background Access Category (AC_BK), then it would 829 receive a less-then-best-effort service and contend with Low-Priority 830 Data (as discussed in Section 4.2.10). 832 As such, since there is no directly corresponding fit for the High- 833 Throughout Data service class within the [IEEE.802.11-2016] model, it 834 is generally RECOMMENDED to map High-Throughput Data to UP 0, thereby 835 admitting it to the Best Effort Access Category (AC_BE). 837 4.2.9. Standard Service Class 839 The Standard service class is RECOMMENDED for traffic that has not 840 been classified into one of the other supported forwarding service 841 classes in the Diffserv network domain. This service class provides 842 the Internet's "best-effort" forwarding behavior. The RECOMMENDED 843 DSCP marking for the Standard Service Class is DF. ([RFC4594] 844 Section 4.9) 846 The Standard Service Class loosely corresponds to the 847 [IEEE.802.11-2016] Best Effort Access Category (AC_BK) and therefore 848 it is RECOMMENDED to map Standard Service Class traffic marked DF 849 DSCP to UP 0, thereby admitting it to the Best Effort Access Category 850 (AC_BE). 852 4.2.10. Low-Priority Data 854 The Low-Priority Data service class serves applications that the user 855 is willing to accept without service assurances. This service class 856 is specified in [RFC3662]. 858 The Low-Priority Data service class loosely corresponds to the 859 [IEEE.802.11-2016] Background Access Category (AC_BK) and therefore 860 it is RECOMMENDED to map Low-Priority Data traffic marked CS1 DSCP to 861 UP 1, thereby admitting it to the Background Access Category (AC_BK). 863 4.3. DSCP-to-UP Mapping Recommendations Summary 865 Figure 1 summarizes the [RFC4594] DSCP marking recommendations mapped 866 to [IEEE.802.11-2016] UP and access categories applied in the 867 downstream direction (i.e. from wired-to-wireless networks). 869 +------------------------------------------------------------------+ 870 | IETF Diffserv | PHB |Reference| IEEE 802.11 | 871 | Service Class | | RFC |User Priority| Access Category | 872 |===============+======+=========+=============+===================| 873 | | | | 7 | AC_VO (Voice) | 874 |Network Control| CS7 | RFC2474 | OR | 875 |(reserved for | | | Remark/Drop at Diffserv Boundary| 876 | future use) | | | (See Section 4.1.1) | 877 +---------------+------+---------+-------------+-------------------+ 878 | | | | 7 | AC_VO (Voice) | 879 |Network Control| CS6 | RFC2474 | OR | 880 | | | | Remark/Drop at Diffserv Boundary| 881 | | | | (See Section 4.1.1) | 882 +---------------+------+---------+-------------+-------------------+ 883 | Telephony | EF | RFC3246 | 6 | AC_VO (Voice) | 884 +---------------+------+---------+-------------+-------------------+ 885 | VOICE-ADMIT |VOICE-| RFC5865 | 6 | AC_VO (Voice) | 886 | |ADMIT | | | | 887 +---------------+------+---------+-------------+-------------------+ 888 | Signaling | CS5 | RFC2474 | 5 | AC_VI (Video) | 889 +---------------+------+---------+-------------+-------------------+ 890 | Multimedia | AF41 | | | | 891 | Conferencing | AF42 | RFC2597 | 4 | AC_VI (Video) | 892 | | AF43 | | | | 893 +---------------+------+---------+-------------+-------------------+ 894 | Real-Time | CS4 | RFC2474 | 4 | AC_VI (Video) | 895 | Interactive | | | | | 896 +---------------+------+---------+-------------+-------------------+ 897 | Multimedia | AF31 | | | | 898 | Streaming | AF32 | RFC2597 | 4 | AC_VI (Video) | 899 | | AF33 | | | | 900 +---------------+------+---------+-------------+-------------------+ 901 |Broadcast Video| CS3 | RFC2474 | 4 | AC_VI (Video) | 902 +---------------+------+---------+-------------+-------------------+ 903 | Low- | AF21 | | | | 904 | Latency | AF22 | RFC2597 | 3 |AC_BE (Best Effort)| 905 | Data | AF23 | | | | 906 +---------------+------+---------+-------------+-------------------+ 907 | OAM | CS2 | RFC2474 | 0 |AC_BE (Best Effort)| 908 +---------------+------+---------+-------------+-------------------+ 909 | High- | AF11 | | | | 910 | Throughput | AF12 | RFC2597 | 0 |AC_BE (Best Effort)| 911 | Data | AF13 | | | | 912 +---------------+------+---------+-------------+-------------------+ 913 | Standard | DF | RFC2474 | 0 |AC_BE (Best Effort)| 914 +---------------+------+---------+-------------+-------------------+ 915 | Low-Priority | CS1 | RFC3662 | 1 | AC_BK (Background)| 916 | Data | | | | | 917 +------------------------------------------------------------------+ 919 Figure 1: Summary of Downstream DSCP to IEEE 802.11 UP and AC Mapping 920 Recommendations 922 5. Upstream Mapping and Marking Recommendations 924 In the upstream direction (i.e. wireless-to-wired), there are three 925 types of mapping that MAY be implemented: 927 o DSCP-to-UP mapping within the wireless client operating system 929 o UP-to-DSCP mapping at the wireless access point 931 o DSCP-Trust at the wireless access point (effectively a 1:1 DSCP- 932 to-DSCP mapping) 934 Alternatively, the network administrator MAY choose to use the 935 wireless-to-wired edge as a Diffserv boundary and explicitly set (or 936 reset) DSCP markings according to administrative policy, thus making 937 the wireless edge a Diffserv policy enforcement point. 939 Each of these options will now be considered. 941 5.1. Upstream DSCP-to-UP Mapping within the Wireless Client Operating 942 System 944 Some operating systems on wireless client devices utilize a similar 945 default DSCP-to-UP mapping scheme as described in Section 2.2. As 946 such, this can lead to the same conflicts as described in that 947 section, but in the upstream direction. 949 Therefore, to improve on these default mappings, and to achieve 950 parity and consistency with downstream QoS, it is RECOMMENDED that 951 such wireless client operating systems utilize instead the same DSCP- 952 to-UP mapping recommendations presented in Section 4. 954 5.2. Upstream UP-to-DSCP Mapping at the Wireless Access Point 956 UP-to-DSCP mapping generates a DSCP value for the IP packet (either 957 an unencapsulated IP packet or an IP packet encapsulated within a 958 tunneling protocol such as CAPWAP - and destined towards a wireless 959 LAN controller for decapsulation and forwarding) from the Layer 2 960 [IEEE.802.11-2016] UP marking. This is typically done in the manner 961 described in Section 2.3. 963 It should be noted that any explicit remarking policy to be performed 964 on such a packet only takes place at the nearest classification and 965 marking policy enforcement point, which may be: 967 o At the wireless access point 969 o At the wired network switch port 971 o At the wireless LAN controller 973 As such, UP-to-DSCP mapping allows for wireless L2 markings to affect 974 the QoS treatment of a packet over the wired IP network (that is, 975 until the packet reaches the nearest classification and marking 976 policy enforcement point). 978 It should be further noted that nowhere in the [IEEE.802.11-2016] 979 specifications is there an intent expressed for UP markings to be 980 used to influence QoS treatment over wired IP networks. Furthermore, 981 [RFC2474], [RFC2475] and [RFC8100] all allow for the host to set DSCP 982 markings for end-to-end QoS treatment over IP networks. Therefore, 983 it is NOT RECOMMENDED that wireless access points trust Layer 2 984 [IEEE.802.11-2016] UP markings as set by wireless hosts and 985 subsequently perform a UP-to-DSCP mapping in the upstream direction, 986 but rather, if wireless host markings are to be trusted (as per 987 business requirements, technical constraints and administrative 988 policies), then it is RECOMMENDED to trust the Layer 3 DSCP markings 989 set by these wireless hosts instead, as is discussed in the next 990 section. 992 5.3. Upstream DSCP-Trust at the Wireless Access Point 994 It is NOT RECOMMENDED to trust DSCP markings from devices that are 995 not authenticated and authorized; these are considered untrusted 996 sources. 998 When business requirements and/or technical constraints and/or 999 administrative policies require a trust function at the wireless 1000 edge, then it is RECOMMENDED to trust DSCP (over [IEEE.802.11-2016] 1001 UP markings) markings in the upstream direction, for the following 1002 reasons: 1004 o [RFC2474], [RFC2475] and [RFC8100] all allow for hosts to set DSCP 1005 markings to achieve an end-to-end differentiated service 1007 o [IEEE.802.11-2016] does not specify that UP markings are to be 1008 used to affect QoS treatment over wired IP networks 1010 o Most wireless device operating systems generate UP values by the 1011 same method as described in Section 2.2 (i.e. by using the 3 MSB 1012 of the encapsulated 6-bit DSCP); then, at the access point, these 1013 3-bit markings are converted back into DSCP values, typically in 1014 the default manner described in Section 2.3; as such, information 1015 is lost in the translation from a 6-bit marking to a 3-bit marking 1016 (which is then subsequently translated back to a 6-bit marking); 1017 trusting the original (encapsulated) DSCP marking prevents such 1018 loss of information 1020 o A practical implementation benefit is also realized by trusting 1021 the DSCP set by wireless client devices, as enabling applications 1022 to mark DSCP is much more prevalent and accessible to programmers 1023 of applications running on wireless device platforms, vis-a-vis 1024 trying to explicitly set UP values, which requires special hooks 1025 into the wireless device operating system and/or hardware device 1026 drivers, many of which do not support such functionality 1028 5.4. Upstream DSCP Marking at the Wireless Access Point 1030 An alternative option to mapping is for the administrator to treat 1031 the wireless edge as the edge of the Diffserv domain and explicitly 1032 set (or reset) DSCP markings in the upstream direction according to 1033 administrative policy. This option is RECOMMENDED over mapping, as 1034 this typically is the most secure solution, as the network 1035 administrator directly enforces the Diffserv policy across the IP 1036 network (versus an application developer and/or the wireless endpoint 1037 device operating system developer, who may be functioning completely 1038 independently of the network administrator). 1040 6. Appendix: IEEE 802.11 QoS Overview 1042 QoS is enabled on wireless networks by means of the Hybrid 1043 Coordination Function (HCF). To give better context to the 1044 enhancements in HCF that enable QoS, it may be helpful to begin with 1045 a review of the original Distributed Coordination Function (DCF). 1047 6.1. Distributed Coordination Function (DCF) 1049 As has been noted, the Wi-Fi medium is a shared medium, with each 1050 station-including the wireless access point-contending for the medium 1051 on equal terms. As such, it shares the same challenge as any other 1052 shared medium in requiring a mechanism to prevent (or avoid) 1053 collisions which can occur when two (or more) stations attempt 1054 simultaneous transmission. 1056 The IEEE Ethernet working group solved this challenge by implementing 1057 a Carrier Sense Multiple Access/Collision Detection (CSMA/CD) 1058 mechanism that could detect collisions over the shared physical cable 1059 (as collisions could be detected as reflected energy pulses over the 1060 physical wire). Once a collision was detected, then a pre-defined 1061 set of rules was invoked that required stations to back off and wait 1062 random periods of time before re-attempting transmission. While 1063 CSMA/CD improved the usage of Ethernet as a shared medium, it should 1064 be noted the ultimate solution to solving Ethernet collisions was the 1065 advance of switching technologies, which treated each Ethernet cable 1066 as a dedicated collision domain. 1068 However, unlike Ethernet (which uses physical cables), collisions 1069 cannot be directly detected over the wireless medium, as RF energy is 1070 radiated over the air and colliding bursts are not necessarily 1071 reflected back to the transmitting stations. Therefore, a different 1072 mechanism is required for this medium. 1074 As such, the IEEE modified the CSMA/CD mechanism to adapt it to 1075 wireless networks to provide Carrier Sense Multiple Access/Collision 1076 Avoidance (CSMA/CA). The original CSMA/CA mechanism used in IEEE 1077 802.11 was the Distributed Coordination Function. DCF is a timer- 1078 based system that leverages three key sets of timers, the slot time, 1079 interframe spaces and contention windows. 1081 6.1.1. Slot Time 1083 The slot time is the basic unit of time measure for both DCF and HCF, 1084 on which all other timers are based. The slot time duration varies 1085 with the different generations of data-rates and performances 1086 described by the [IEEE.802.11-2016] standard. For example, the 1087 [IEEE.802.11-2016] standard specifies the slot time to be 20 us 1088 ([IEEE.802.11-2016] Table 15-5) for legacy implementations (such as 1089 IEEE 802.11b, supporting 1, 2, 5.5 and 11 Mbps data rates), while 1090 newer implementations (including IEEE 802.11g, 80.11a, 802.11n and 1091 802.11ac, supporting data rates from 500 Mbps to over 1 Gbps) define 1092 a shorter slot time of 9 us ([IEEE.802.11-2016], Section 17.4.4, 1093 Table 17-21). 1095 6.1.2. Interframe Spaces 1097 The time interval between frames that are transmitted over the air is 1098 called the Interframe Space (IFS). Several IFS are defined in 1099 [IEEE.802.11-2016], with the two most relevant to DCF being the Short 1100 Interframe Space (SIFS) and the DCF Interframe Space (DIFS). 1102 The SIFS is the amount of time in microseconds required for a 1103 wireless interface to process a received RF signal and its associated 1104 [IEEE.802.11-2016] frame and to generate a response frame. Like slot 1105 times, the SIFS can vary according to the performance implementation 1106 of the [IEEE.802.11-2016] standard. The SIFS for IEEE 802.11a, 1107 802.11n and 802.11ac (in 5 GHz) is 16 us ([IEEE.802.11-2016], 1108 Section 17.4.4, Table 17-21). 1110 Additionally, a station must sense the status of the wireless medium 1111 before transmitting. If it finds that the medium is continuously 1112 idle for the duration of a DIFS, then it is permitted to attempt 1113 transmission of a frame (after waiting an additional random backoff 1114 period, as will be discussed in the next section). If the channel is 1115 found busy during the DIFS interval, the station must defer its 1116 transmission until the medium is found idle for the duration of a 1117 DIFS interval. The DIFS is calculated as: 1119 DIFS = SIFS + (2 * Slot time) 1121 However, if all stations waited only a fixed amount of time before 1122 attempting transmission then collisions would be frequent. To offset 1123 this, each station must wait, not only a fixed amount of time (the 1124 DIFS), but also a random amount of time (the random backoff) prior to 1125 transmission. The range of the generated random backoff timer is 1126 bounded by the Contention Window. 1128 6.1.3. Contention Windows 1130 Contention windows bound the range of the generated random backoff 1131 timer that each station must wait (in addition to the DIFS) before 1132 attempting transmission. The initial range is set between 0 and the 1133 Contention Window minimum value (CWmin), inclusive. The CWmin for 1134 DCF (in 5 GHz) is specified as 15 slot times ([IEEE.802.11-2016], 1135 Section 17.4.4, Table 17-21). 1137 However, it is possible that two (or more) stations happen to pick 1138 the exact same random value within this range. If this happens then 1139 a collision may occur. At this point, the stations effectively begin 1140 the process again, waiting a DIFS and generate a new random backoff 1141 value. However, a key difference is that for this subsequent 1142 attempt, the Contention Window approximatively doubles in size (thus 1143 exponentially increasing the range of the random value). This 1144 process repeats as often as necessary if collisions continue to 1145 occur, until the maximum Contention Window size (CWmax) is reached. 1146 The CWmax for DCF is specified as 1023 slot times 1147 ([IEEE.802.11-2016], Section 17.4.4, Table 17-21). 1149 At this point, transmission attempts may still continue (until some 1150 other pre-defined limit is reached), but the Contention Window sizes 1151 are fixed at the CWmax value. 1153 Incidentally it may be observed that a significant amount of jitter 1154 can be introduced by this contention process for wireless 1155 transmission access. For example, the incremental transmission delay 1156 of 1023 slot times (CWmax) using 9 us slot times may be as high as 9 1157 ms of jitter per attempt. And, as previously noted, multiple 1158 attempts can be made at CWmax. 1160 6.2. Hybrid Coordination Function (HCF) 1162 Therefore, as can be seen from the preceding description of DCF, 1163 there is no preferential treatment of one station over another when 1164 contending for the shared wireless media; nor is there any 1165 preferential treatment of one type of traffic over another during the 1166 same contention process. To support the latter requirement, the IEEE 1167 enhanced DCF in 2005 to support QoS, specifying HCF in IEEE 802.11, 1168 which was integrated into the main IEEE 802.11 standard in 2007. 1170 6.2.1. User Priority (UP) 1172 One of the key changes to the [IEEE.802.11-2016] frame format is the 1173 inclusion of a QoS Control field, with 3 bits dedicated for QoS 1174 markings. These bits are referred to the User Priority (UP) bits and 1175 these support eight distinct marking values: 0-7, inclusive. 1177 While such markings allow for frame differentiation, these alone do 1178 not directly affect over-the-air treatment. Rather it is the non- 1179 configurable and standard-specified mapping of UP markings to 1180 [IEEE.802.11-2016] Access Categories (AC) that generate 1181 differentiated treatment over wireless media. 1183 6.2.2. Access Category (AC) 1185 Pairs of UP values are mapped to four defined access categories that 1186 correspondingly specify different treatments of frames over the air. 1187 These access categories (in order of relative priority from the top 1188 down) and their corresponding UP mappings are shown in Figure 2 1189 (adapted from [IEEE.802.11-2016], Section 10.2.4.2, Table 10-1). 1191 +-----------------------------------------+ 1192 | User | Access | Designative | 1193 | Priority | Category | (informative) | 1194 |===========+============+================| 1195 | 7 | AC_VO | Voice | 1196 +-----------+------------+----------------+ 1197 | 6 | AC_VO | Voice | 1198 +-----------+------------+----------------+ 1199 | 5 | AC_VI | Video | 1200 +-----------+------------+----------------+ 1201 | 4 | AC_VI | Video | 1202 +-----------+------------+----------------+ 1203 | 3 | AC_BE | Best Effort | 1204 +-----------+------------+----------------+ 1205 | 0 | AC_BE | Best Effort | 1206 +-----------+------------+----------------+ 1207 | 2 | AC_BK | Background | 1208 +-----------+------------+----------------+ 1209 | 1 | AC_BK | Background | 1210 +-----------------------------------------+ 1212 Figure 2: IEEE 802.11 Access Categories and User Priority Mappings 1214 The manner in which these four access categories achieve 1215 differentiated service over-the-air is primarily by tuning the fixed 1216 and random timers that stations have to wait before sending their 1217 respective types of traffic, as will be discussed next. 1219 6.2.3. Arbitration Inter-Frame Space (AIFS) 1221 As previously mentioned, each station must wait a fixed amount of 1222 time to ensure the medium is idle before attempting transmission. 1223 With DCF, the DIFS is constant for all types of traffic. However, 1224 with [IEEE.802.11-2016] the fixed amount of time that a station has 1225 to wait will depend on the access category and is referred to as an 1226 Arbitration Interframe Space (AIFS). AIFS are defined in slot times 1227 and the AIFS per access category are shown in Figure 3 (adapted from 1228 [IEEE.802.11-2016], Section 9.4.2.29, Table 9-137). 1230 +------------------------------------------+ 1231 | Access | Designative | AIFS | 1232 | Category | (informative) |(slot times)| 1233 |===========+=================+============| 1234 | AC_VO | Voice | 2 | 1235 +-----------+-----------------+------------+ 1236 | AC_VI | Video | 2 | 1237 +-----------+-----------------+------------+ 1238 | AC_BE | Best Effort | 3 | 1239 +-----------+-----------------+------------+ 1240 | AC_BK | Background | 7 | 1241 +-----------+-----------------+------------+ 1243 Figure 3: Arbitration Interframe Spaces by Access Category 1245 6.2.4. Access Category Contention Windows (CW) 1247 Not only is the fixed amount of time that a station has to wait 1248 skewed according to [IEEE.802.11-2016] access category, but so are 1249 the relative sizes of the Contention Windows that bound the random 1250 backoff timers, as shown in Figure 4 (adapted from 1251 [IEEE.802.11-2016], Section 9.4.2.29, Table 9-137). 1253 +-------------------------------------------------------+ 1254 | Access | Designative | CWmin | CWmax | 1255 | Category | (informative) |(slot times)|(slot times)| 1256 |===========+=================+============|============| 1257 | AC_VO | Voice | 3 | 7 | 1258 +-----------+-----------------+------------+------------+ 1259 | AC_VI | Video | 7 | 15 | 1260 +-----------+-----------------+------------+------------+ 1261 | AC_BE | Best Effort | 15 | 1023 | 1262 +-----------+-----------------+------------+------------+ 1263 | AC_BK | Background | 15 | 1023 | 1264 +-----------+-----------------+------------+------------+ 1266 Figure 4: Contention Window Sizes by Access Category 1268 When the fixed and randomly generated timers are added together on a 1269 per access category basis, then traffic assigned to the Voice Access 1270 Category (i.e. traffic marked to UP 6 or 7) will receive a 1271 statistically superior service relative to traffic assigned to the 1272 Video Access Category (i.e. traffic marked UP 5 and 4), which, in 1273 turn, will receive a statistically superior service relative to 1274 traffic assigned to the Best Effort Access Category traffic (i.e. 1275 traffic marked UP 3 and 0), which finally will receive a 1276 statistically superior service relative to traffic assigned to the 1277 Background Access Category traffic (i.e. traffic marked to UP 2 and 1278 1). 1280 6.3. IEEE 802.11u QoS Map Set 1282 IEEE 802.11u [IEEE.802-11u.2011] is an addendum that has now been 1283 included within the main [IEEE.802.11-2016] standard, and which 1284 includes, among other enhancements, a mechanism by which wireless 1285 access points can communicate DSCP to/from UP mappings that have been 1286 configured on the wired IP network. Specifically, a QoS Map Set 1287 information element (described in [IEEE.802.11-2016] Section 9.4.2.95 1288 and commonly referred to as the QoS Map element) is transmitted from 1289 an AP to a wireless endpoint device in an association / re- 1290 association Response frame (or within a special QoS Map Configure 1291 frame). 1293 The purpose of the QoS Map element is to provide the mapping of 1294 higher layer Quality of Service constructs (i.e. DSCP) to User 1295 Priorities. One intended effect of receiving such a map is for the 1296 wireless endpoint device (that supports this function and is 1297 administratively configured to enable it) to perform corresponding 1298 DSCP-to-UP mapping within the device (i.e. between applications and 1299 the operating system / wireless network interface hardware drivers) 1300 to align with what the APs are mapping in the downstream direction, 1301 so as to achieve consistent end-to-end QoS in both directions. 1303 The QoS Map element includes two key components: 1305 1) each of the eight UP values (0-7) are associated with a range of 1306 DSCP values, and 1308 2) (up to 21) exceptions from these range-based DSCP to/from UP 1309 mapping associations may be optionally and explicitly specified. 1311 In line with the recommendations put forward in this document, the 1312 following recommendations apply when the QoS Map element is enabled: 1314 1) each of the eight UP values (0-7) are RECOMMENDED to be mapped to 1315 DSCP 0 (as a baseline, so as to meet the recommendation made in 1316 Section 4.1.1 that packets marked to unused Diffserv Codepoints be 1317 remarked at the edge of the Diffserv domain), and 1319 2) (up to 21) exceptions from this baseline mapping are RECOMMENDED 1320 to be made in line with Section 4.3, to correspond to the Diffserv 1321 Codepoints that are in use over the IP network. 1323 It is important to note that the QoS Map element is intended to be 1324 transmitted from a wireless access point to a non-AP station. As 1325 such, the model where this element is used is that of a network where 1326 the AP is the edge of the Diffserv domain. Networks where the AP 1327 extends the Diffserv domain by connecting other APs and 1328 infrastructure devices through the IEEE 802.11 medium are not 1329 included in the cases covered by the presence of the QoS Map element, 1330 and therefore are not included in the present recommendation. 1332 7. IANA Considerations 1334 This memo asks the IANA for no new parameters. 1336 8. Security Considerations 1338 The recommendations put forward in this document do not present any 1339 additional security concerns that do not already exist in wired and 1340 wireless devices. In fact, several of the recommendations made in 1341 this document serve to mitigate and protect wired and wireless 1342 networks from potential abuse arising from existing vulnerabilities. 1344 For example, it may be possible for a wireless device, either a host 1345 or a network device, to mark packets in a manner that interferes with 1346 or degrades existing QoS policies. Similarly, it may be possible for 1347 a device to map L2/L3 markings in a manner that causes similar 1348 effects. Such marking or mapping may be done intentionally or 1349 unintentionally by the developers and/or users and/or administrators 1350 of such devices. To illustrate: A gaming application designed to run 1351 on a smart-phone or tablet may request that all its packets be marked 1352 DSCP EF and/or UP 6. However, if the traffic from such an 1353 application is trusted over a business network, then this could 1354 interfere with QoS policies intended to provide priority services for 1355 enterprise voice applications. To mitigate such attack vectors it is 1356 RECOMMENDED to implement security measures, such as policing EF 1357 marked packet flows, as detailed in [RFC2474] Section 7 and [RFC3246] 1358 Section 3. 1360 Furthermore, several recommendations have been made in this document 1361 to mitigate the potential for deliberate or inadvertent violations. 1362 Specifically the following recommendations have been made for 1363 primarily security reasons: 1365 Section 4.1.1 RECOMMENDED that all packets marked to Diffserv 1366 Codepoints not in use over the wireless network be dropped or 1367 remarked at the edge of the Diffserv domain. This recommendation 1368 may help mitigate a Denial-of-Service attack vector that exists at 1369 wired-to-wireless edges in the downstream direction. For example, 1370 consider a malicious user flooding traffic marked CS7 or CS6 DSCP 1371 toward the WLAN. These codepoints would map by default to UP 7 1372 and UP 6 (respectively), both of which would be assigned to the 1373 Voice Access Category (AC_VO). Such a flood could cause a Denial- 1374 of-Service to wireless voice applications. 1376 Section 5.3 made it clear that it is NOT RECOMMENDED to trust DSCP 1377 markings from devices that are not authenticated and authorized, 1378 as these are considered untrusted sources. This is especially 1379 relevant for IoT, as billions of devices are being connected to IP 1380 networks, many of which have little or no security. 1382 Section 5.4 RECOMMENDED that the administrator treat the wireless 1383 edge as the edge of the Diffserv domain and explicitly set (or 1384 reset) DSCP markings in the upstream direction according to 1385 administrative policy. UP-to-DSCP mapping was explicitly NOT 1386 RECOMMENDED in Section 5.2. Also DSCP-trust was heavily caveated 1387 in Section 5.3. These recommendations collectively serve to 1388 mitigate Denial-of-Service attacks in the upstream direction. For 1389 example, consider a malicious user flooding traffic from a 1390 wireless endpoint device marked DSCP 48 and/or UP 6. If default 1391 UP-to-DSCP mapping were enabled at the access-point, these flows 1392 would be mapped to DSCP 48, and could thus interfere with QoS 1393 policies intended to protect control plane protocols over the IP 1394 network, resulting in potential network instability; such could 1395 likewise happen if DSCP-trust were enabled in the same scenario. 1397 Furthermore, it should be noted that the recommendations put forward 1398 in this document are not intended to address all attack vectors 1399 leveraging QoS marking abuse. Mechanisms that may further help 1400 mitigate security risks include strong device- and/or user- 1401 authentication, access-control, rate limiting, control-plane 1402 policing, encryption and other techniques; however, the 1403 implementation recommendations for such mechanisms are beyond the 1404 scope of this document to address in detail. Suffice it to say that 1405 the security of the devices and networks implementing QoS, including 1406 QoS mapping between wired and wireless networks, SHOULD be considered 1407 in actual deployments. 1409 9. Acknowledgements 1411 The authors wish to thank David Black, Gorry Fairhurst, Ruediger 1412 Geib, Vincent Roca, Brian Carpenter, David Blake, Cullen Jennings, 1413 David Benham and the TSVWG. 1415 The authors also acknowledge a great many inputs, notably from David 1416 Kloper, Mark Montanez, Glen Lavers, Michael Fingleton, Sarav 1417 Radhakrishnan, Karthik Dakshinamoorthy, Simone Arena, Ranga Marathe, 1418 Ramachandra Murthy and many others. 1420 10. References 1422 10.1. Normative References 1424 [IEEE.802.11-2016] 1425 "Information technology - Telecommunications and 1426 information exchange between systems - Local and 1427 metropolitan area networks - Specific requirements - Part 1428 11: Wireless LAN Medium Access Control (MAC) and Physical 1429 Layer (PHY) specifications", IEEE Standard 802.11, 2016, 1430 . 1433 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1434 Requirement Levels", BCP 14, RFC 2119, 1435 DOI 10.17487/RFC2119, March 1997, 1436 . 1438 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1439 "Definition of the Differentiated Services Field (DS 1440 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1441 DOI 10.17487/RFC2474, December 1998, 1442 . 1444 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1445 and W. Weiss, "An Architecture for Differentiated 1446 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 1447 . 1449 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 1450 "Assured Forwarding PHB Group", RFC 2597, 1451 DOI 10.17487/RFC2597, June 1999, 1452 . 1454 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 1455 J., Courtney, W., Davari, S., Firoiu, V., and D. 1456 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 1457 Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002, 1458 . 1460 [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort 1461 Per-Domain Behavior (PDB) for Differentiated Services", 1462 RFC 3662, DOI 10.17487/RFC3662, December 2003, 1463 . 1465 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 1466 Guidelines for DiffServ Service Classes", RFC 4594, 1467 DOI 10.17487/RFC4594, August 2006, 1468 . 1470 [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of 1471 Diffserv Service Classes", RFC 5127, DOI 10.17487/RFC5127, 1472 February 2008, . 1474 [RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated 1475 Services Code Point (DSCP) for Capacity-Admitted Traffic", 1476 RFC 5865, DOI 10.17487/RFC5865, May 2010, 1477 . 1479 [RFC8100] Geib, R., Ed. and D. Black, "Diffserv-Interconnection 1480 Classes and Practice", RFC 8100, DOI 10.17487/RFC8100, 1481 March 2017, . 1483 10.2. Informative References 1485 [IEEE.802-11u.2011] 1486 "Information technology - Telecommunications and 1487 information exchange between systems - Local and 1488 metropolitan area networks - Specific requirements - Part 1489 11: Wireless LAN Medium Access Control (MAC) and Physical 1490 Layer (PHY) specifications", IEEE Standard 802.11, 2011, 1491 . 1494 [RFC7561] Kaippallimalil, J., Pazhyannur, R., and P. Yegani, 1495 "Mapping Quality of Service (QoS) Procedures of Proxy 1496 Mobile IPv6 (PMIPv6) and WLAN", RFC 7561, 1497 DOI 10.17487/RFC7561, June 2015, 1498 . 1500 Appendix A. Change Log 1502 Initial Version: July 2015 1504 Authors' Addresses 1506 Tim Szigeti 1507 Cisco Systems 1508 Vancouver, British Columbia V6K 3L4 1509 Canada 1511 Email: szigeti@cisco.com 1513 Jerome Henry 1514 Cisco Systems 1515 Research Triangle Park, North Carolina 27709 1516 USA 1518 Email: jerhenry@cisco.com 1520 Fred Baker 1521 Santa Barbara, California 93117 1522 USA 1524 Email: FredBaker.IETF@gmail.com