idnits 2.17.1 draft-ietf-tsvwg-ieee-802-11-00.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 (June 27, 2016) is 2854 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3662 (Obsoleted by RFC 8622) == Outdated reference: A later version (-14) exists of draft-ietf-tsvwg-diffserv-intercon-06 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Working Group T. Szigeti 3 Internet-Draft F. Baker 4 Intended status: Informational Cisco Systems 5 Expires: December 29, 2016 June 27, 2016 7 Guidelines for DiffServ to IEEE 802.11 Mapping 8 draft-ietf-tsvwg-ieee-802-11-00 10 Abstract 12 As internet traffic is increasingly sourced-from and destined-to 13 wireless endpoints, it is crucial that Quality of Service be aligned 14 between wired and wireless networks; however, this is not always the 15 case by default. This is due to the fact that two independent 16 standards bodies provide QoS guidance on wired and wireless networks: 17 specifically, the IETF specifies standards and design recommendations 18 for wired IP networks, while a separate and autonomous standards- 19 body, the IEEE, administers the standards for wireless 802.11 20 networks. The purpose of this document is to propose a set 21 Differentiated Services Code Point (DSCP) to IEEE 802.11 User 22 Priority (UP) mappings to reconcile the marking recommendations 23 offered by these two standards bodies, and, as such, to optimize 24 wired-and-wireless interconnect QoS. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on December 29, 2016. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Related work . . . . . . . . . . . . . . . . . . . . . . 3 62 1.2. Interaction with RFC 7561 . . . . . . . . . . . . . . . . 4 63 1.3. Applicability Statement . . . . . . . . . . . . . . . . . 4 64 1.4. Document Organization . . . . . . . . . . . . . . . . . . 5 65 1.5. Requirements Language . . . . . . . . . . . . . . . . . . 5 66 2. Comparison and Default Interoperation of DiffServ and IEEE 67 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 2.1. Default DSCP-to-UP Mappings and Conflicts . . . . . . . . 6 69 2.2. Default UP-to-DSCP Mappings and Conflicts . . . . . . . . 7 70 3. Wireless Device Marking and Mapping Capability 71 Recommendations . . . . . . . . . . . . . . . . . . . . . . . 8 72 4. DSCP-to-UP Mapping Recommendations . . . . . . . . . . . . . 9 73 4.1. Network Control Traffic . . . . . . . . . . . . . . . . . 9 74 4.1.1. Network Control Protocols . . . . . . . . . . . . . . 9 75 4.1.2. Operations Administration Management (OAM) . . . . . 10 76 4.2. User Traffic . . . . . . . . . . . . . . . . . . . . . . 10 77 4.2.1. Telephony . . . . . . . . . . . . . . . . . . . . . . 11 78 4.2.2. Signaling . . . . . . . . . . . . . . . . . . . . . . 11 79 4.2.3. Multimedia Conferencing . . . . . . . . . . . . . . . 12 80 4.2.4. Real-Time Interactive . . . . . . . . . . . . . . . . 12 81 4.2.5. Multimedia-Streaming . . . . . . . . . . . . . . . . 13 82 4.2.6. Broadcast Video . . . . . . . . . . . . . . . . . . . 13 83 4.2.7. Low-Latency Data . . . . . . . . . . . . . . . . . . 13 84 4.2.8. High-Throughput Data . . . . . . . . . . . . . . . . 14 85 4.2.9. Standard Service Class . . . . . . . . . . . . . . . 14 86 4.2.10. Low-Priority Data . . . . . . . . . . . . . . . . . . 14 87 4.3. DSCP-to-UP Mapping Recommendations Summary . . . . . . . 15 88 5. Upstream Mapping Recommendations . . . . . . . . . . . . . . 17 89 5.1. Upstream DSCP-to-UP Mapping within the Wireless Client 90 Operating System . . . . . . . . . . . . . . . . . . . . 17 91 5.2. UP-to-DSCP Mapping at the Wireless Access Point . . . . . 17 92 5.3. DSCP-Trust at the Wireless Access Point . . . . . . . . . 18 93 6. Appendix: IEEE 802.11 QoS Overview . . . . . . . . . . . . . 18 94 6.1. Distributed Coordination Function (DCF) . . . . . . . . . 19 95 6.1.1. Slot Time . . . . . . . . . . . . . . . . . . . . . . 19 96 6.1.2. Interframe Spaces . . . . . . . . . . . . . . . . . . 20 97 6.1.3. Contention Windows . . . . . . . . . . . . . . . . . 20 98 6.2. Hybrid Coordination Function (HCF) . . . . . . . . . . . 21 99 6.2.1. User Priority (UP) . . . . . . . . . . . . . . . . . 21 100 6.2.2. Access Category (AC) . . . . . . . . . . . . . . . . 21 101 6.2.3. Arbitration Inter-Frame Space (AIFS) . . . . . . . . 22 102 6.2.4. Access Category Contention Windows (CW) . . . . . . . 23 103 6.3. IEEE 802.11u QoS Map Set . . . . . . . . . . . . . . . . 24 104 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 105 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 106 8.1. Privacy Considerations . . . . . . . . . . . . . . . . . 25 107 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 108 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 109 10.1. Normative References . . . . . . . . . . . . . . . . . . 25 110 10.2. Informative References . . . . . . . . . . . . . . . . . 26 111 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 27 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 114 1. Introduction 116 Wireless has become the medium of choice for endpoints connecting to 117 business and private networks. However, the wireless medium defined 118 by IEEE 802.11 [IEEE.802-11.2012] presents several design challenges 119 for ensuring end-to-end quality of service. Some of these challenges 120 relate to the nature of 802.11 RF medium itself, being a half-duplex 121 and shared media, while other challenges relate to the fact that the 122 802.11 standard is not administered by the standards body that 123 administers the rest of the IP network. While the IEEE has developed 124 tools to enable QoS over wireless networks, little guidance exists on 125 how to optimally interconnect wired IP and wireless 802.11 networks, 126 which is the aim of this document. 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] details the Assured Forwarding (AF) PHB. 144 o [RFC3662] outlines a Lower Effort Per-Domain Behavior (PDB) 146 o [RFC4594] presents Configuration Guidelines for DiffServ Service 147 Classes 149 o [RFC5127] discusses the Aggregation of Diffserv Service Classes 151 o [RFC5865] introduces a DSCP for Capacity Admitted Traffic 153 This draft draws heavily on [RFC4594], [RFC5127], and 154 [I-D.ietf-tsvwg-diffserv-intercon]. 156 In turn, the relevant standard for wireless QoS is IEEE 802.11, which 157 is being progressively updated; the current version of which (at the 158 time of writing) is IEEE 802.11-2012. 160 1.2. Interaction with RFC 7561 162 There is also a recommendation from GSMA, Mapping Quality of Service 163 (QoS) Procedures of Proxy Mobile IPv6 (PMIPv6) and WLAN [RFC7561]. 164 The GSMA specification was developed without reference to the service 165 plan documented in Section 1.1, and conflicts both in the services 166 specified and the code points specified for them. As such, the two 167 plans cannot be normalized. Rather, as discussed in [RFC2474] 168 section 2, the two domains (802.11 and GSMA) are different 169 Differentiated Services Domains separated by a Differentiated 170 Services Boundary. At that boundary, code points from one domain are 171 translated to code points for the other, and maybe to Default (zero) 172 if there is no corresponding service to translate to. 174 1.3. Applicability Statement 176 This document is applicable to the use of Differentiated Services 177 that interconnect with IEEE 802.11 wireless LANs (referred to as Wi- 178 Fi, throughout this document, for simplicity). These guidelines are 179 applicable whether the wireless access points (APs) are deployed in 180 an autonomous manner, managed by (centralized or distributed) WLAN 181 controllers or some hybrid deployment option. This is because in all 182 these cases, the wireless access point is the bridge between wired 183 and wireless media. 185 This document primarily applies to wired IP networks that have 186 wireless access points at their edges, but can also be applied to Wi- 187 Fi backhaul, wireless mesh solutions or any other type of AP-to-AP 188 wireless network that serves to extend the IP network infrastructure. 190 1.4. Document Organization 192 This document is organized as follows: 194 o Section 1 outlines the abstract, related work, organization and 195 the requirements language of this document. 197 o Section 2 begins the discussion with a comparison of IETF DiffServ 198 QoS and Wi-Fi QoS standards and highlights discrepancies between 199 these that require reconciliation. 201 o Section 3 presents the marking and mapping capabilities that 202 wireless access points and wireless endpoint devices are 203 recommended to support. 205 o Section 4 presents DSCP-to-UP mapping recommendations for each of 206 the [RFC4594] traffic classes, which are primarily applicable in 207 the downstream (wired-to-wireless) direction. 209 o Section 5, in turn, considers upstream (wireless-to-wired) QoS 210 options, their respective merits and recommendations. 212 o Section 6 (in the form of an Appendix) presents a brief overview 213 of how QoS is achieved over IEEE 802.11 wireless networks, given 214 the shared, half-duplex nature of the wireless medium. 216 o Section 7 on notes IANA considerations, security considerations, 217 acknowledgements and references, respectively 219 1.5. Requirements Language 221 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 222 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL", and "NOT 223 RECOMMENDED" in this document are to be interpreted as described in 224 [RFC2119]. 226 2. Comparison and Default Interoperation of DiffServ and IEEE 802.11 228 (Section 6 provides a brief overview of IEEE 802.11 QoS.) 230 The following comparisons between IEEE 802.11 and DiffServ should be 231 noted: 233 o 802.11 does not support a [RFC3246] EF PHB service, as it is not 234 possible to guarantee that a given access category will be 235 serviced with strict priority over another (due to the random 236 element within the contention process) 238 o 802.11 does not support a [RFC2597] AF PHB service, again because 239 it is not possible to guarantee that a given access category will 240 be serviced with a minimum amount of assured bandwidth (due to the 241 non-deterministic nature of the contention process) 243 o 802.11 loosely supports a [RFC2474] Default Forwarding service via 244 the Best Effort Access Category (AC_BE) 246 o 802.11 loosely supports a [RFC3662] Lower PDB service via the 247 Background Access Category (AC_BK) 249 As such, these are high-level considerations that need to be kept in 250 mind when mapping from DiffServ to 802.11 (and vice-versa); however, 251 some additional marking-specific incompatibilities must also be 252 reconciled, as will be discussed next. 254 2.1. Default DSCP-to-UP Mappings and Conflicts 256 While no explicit guidance is offered in mapping (6-Bit) Layer 3 DSCP 257 values to (3-Bit) Layer 2 markings (such as IEEE 802.1D, 802.1p or 258 802.11e), a common practice in the networking industry is to map 259 these by what we will refer to as 'Default DSCP-to-UP Mapping' (for 260 lack of a better term), wherein the 3 Most Significant Bits (MSB) of 261 the DSCP are transcribed to generate the corresponding L2 markings. 263 Note: There are example mappings in IEEE 802.11 (in the Annex V 264 Tables V-1 and V2), but these mappings are provided as examples (vs. 265 as recommendations). Furthermore, some of these mappings do not 266 align with the intent and recommendations expressed in [RFC4594], as 267 will be discussed in the following section. 269 However, when this default DSCP-to-UP mapping method is applied to 270 packets marked per [RFC4594] recommendations and destined to 802.11 271 WLAN clients, it will yield a number of sub-optimal QoS mappings, 272 specifically: 274 o Voice (EF-101110) will be mapped to UP 5 (101), and treated in the 275 Video Access Category (AC_VI), rather than the Voice Access 276 Category (AC_VO), for which it is intended 278 o Multimedia Streaming (AF3-011xx0) will be mapped to UP3 (011) and 279 treated in the Best Effort Access Category (AC_BE), rather than 280 the Video Access Category (AC_VI), for which it is intended 282 o OAM traffic (CS2-010000) will be mapped to UP 2 (010) and treated 283 in the Background Access Category (AC_BK), which is not the intent 284 expressed in [RFC4594] for this traffic class 286 It should also be noted that while IEEE 802.11 defines an intended 287 use for each access category through the AC naming convention (for 288 example, UP 6 and UP 7 belong to AC_VO, the Voice Access Category), 289 802.11 does not: 291 o define how upper Layer markings (such as DSCP) should map to UPs 292 (and hence to ACs) 294 o define how UPs should translate to other medium Layer 2 QoS 295 markings 297 o strictly restrict each access category to applications reflected 298 in the AC name 300 2.2. Default UP-to-DSCP Mappings and Conflicts 302 In the opposite direction of flow (the upstream direction, that is, 303 from wireless-to-wired), many APs use what we will refer to as 304 'Default UP-to-DSCP Mapping' (for lack of a better term), wherein 305 DSCP values are derived from UP values by multiplying the UP values 306 by 8 (i.e. shifting the 3 UP bits to the left and adding three 307 additional zeros to generate a DSCP value). This derived DSCP value 308 is then used for QoS treatment between the wireless access point and 309 the nearest classification and marking policy enforcement point 310 (which may be the centralized wireless LAN controller, relatively 311 deep within the network). 313 It goes without saying that when 6 bits of marking granularity are 314 derived from 3, then information is lost in translation. Servicing 315 differentiation cannot be made for 12 classes of traffic (as 316 recommended in [RFC4594]), but for only 8 (with one of these classes 317 being reserved for future use (i.e. UP 7 which maps to DSCP CS7). 319 Such default upstream mapping can also yield several inconsistencies 320 with [RFC4594], including: 322 o Mapping UP 6 (Voice) to CS6, which [RFC4594] recommends for 323 Network Control 325 o Mapping UP 4 (Multimedia Conferencing and/or Real-Time 326 Interactive) to CS4, thus losing the ability to distinguish 327 between these two distinct traffic classes 329 o Mapping UP 3 (Multimedia Streaming and/or Broadcast Video) to CS3, 330 thus losing the ability to distinguish between these two distinct 331 traffic classes 333 o Mapping UP 2 (Low-Latency Data and/or OAM) to CS2, thus losing the 334 ability to distinguish between these two distinct traffic classes, 335 and possibly overwhelming the queues provisioned for OAM (which is 336 typically lower in capacity [being network control traffic], as 337 compared to Low-Latency Data queues [being user traffic]) 339 o Mapping UP 1 (High-Throughput Data and/or Low-Priority Data) to 340 CS1, thus losing the ability to distinguish between these two 341 distinct traffic classes and causing legitimate business-relevant 342 High-Throughput Data to receive a [RFC3662] Lower PDB, for which 343 it is not intended 345 Thus, the next sections of this draft seek to address these 346 limitations and concerns and reconcile the intents of [RFC4594] and 347 IEEE 802.11. First the downstream (wired-to-wireless) DSCP-to-UP 348 mappings will be aligned and then upstream (wireless-to-wired) models 349 will be addressed. 351 3. Wireless Device Marking and Mapping Capability Recommendations 353 This document assumes and RECOMMENDS that all wireless access points 354 (as the bridges between wired-and-wireless networks) support the 355 ability to: 357 o mark DSCP, per DiffServ standards 359 o mark UP, per the 802.11 standard 361 o support fully-configurable mappings between DSCP and UP 363 o trust the DSCP markings set by wireless endpoint devices (as 364 discussed in Section 5.3) 366 This document further assumes and RECOMMENDS that all wireless 367 endpoint devices support the ability to: 369 o mark DSCP, per DiffServ standards 371 o mark UP, per the 802.11 standard 373 o support fully-configurable mappings between DSCP (set by 374 applications in software) and UP (set by the operating system and/ 375 or wireless network interface hardware drivers) 377 Having made the assumptions and recommendations above, it bears 378 mentioning while the mappings presented in this document are 379 RECOMMENDED to replace the current common default practices (as 380 discussed in Section 2.1 and Section 2.2), these mapping 381 recommendations are not expected to fit every last deployment model, 382 and as such may be overridden by network administrators, as needed. 384 4. DSCP-to-UP Mapping Recommendations 386 The following section proposes downstream (wired-to-wireless) 387 mappings between [RFC4594] Configuration Guidelines for DiffServ 388 Service Classes and IEEE 802.11. As such, this section draws heavily 389 from [RFC4594], including traffic class definitions and 390 recommendations. 392 This section assumes wireless access points and/or WLAN controllers 393 that support customizable, non-default DSCP-to-UP mapping schemes. 395 4.1. Network Control Traffic 397 Network control traffic is defined as packet flows that are essential 398 for stable operation of the administered network. Network control 399 traffic is different from user application control (signaling) that 400 may be generated by some applications or services. Network Control 401 Traffic may be split into two service classes: 403 o Network Control, and 405 o Operations Administration and Management (OAM) 407 4.1.1. Network Control Protocols 409 The Network Control service class is used for transmitting packets 410 between network devices (routers) that require control (routing) 411 information to be exchanged between nodes within the administrative 412 domain as well as across a peering point between different 413 administrative domains. The RECOMMENDED DSCP marking for Network 414 Control is CS6. 416 Before discussing a mapping recommendation for Network Control 417 traffic marked CS6 DSCP, it is interesting to note a relevant 418 recommendation from [RFC4594] pertaining to traffic marked CS7 DSCP: 419 in [RFC4594] Section 3.1 it is RECOMMENDED that packets marked CS7 420 DSCP (a codepoint that SHOULD be reserved for future use) be dropped 421 or remarked at the edge of the DiffServ domain. 423 Following this recommendation, it is RECOMMENDED that all packets 424 marked to DiffServ Codepoints not in use over the wireless network be 425 dropped or remarked at the edge of the DiffServ domain. 427 It is important to note that the wired-to-wireless edge may or may 428 not equate to the edge of the DiffServ domain; as such, this 429 recommendation may or may not apply at the wired-to-wireless edge. 431 For example, in most commonly deployed models, the wireless access 432 point represents not only the edge of the DiffServ domain, but also 433 the edge of the network infrastructure itself. As such, and in line 434 with the above recommendation, traffic marked CS7 DSCP SHOULD be 435 dropped or remarked at this edge (as it is typically unused, as CS7 436 SHOULD be reserved for future use). So too SHOULD Network Control 437 traffic marked CS6 DSCP, considering that only client devices (and no 438 network infrastructure devices) are downstream from the wireless 439 access points in these deployment models. In such cases, no Network 440 Control traffic would be (legitimately) expected to be sent or 441 received from wireless client endpoint devices, and thus this 442 recommendation would apply. 444 Alternatively, in other deployment models, such as Wi-Fi backhaul, 445 wireless mesh infrastructures, or any other type of wireless AP-to-AP 446 deployments, the wireless access point extends the network 447 infrastructure and thus, typically, the DiffServ domain. In such 448 cases, the above recommendation would not apply, as the wired-to- 449 wireless edge does not represent the edge of the DiffServ domain. 450 Furthermore, as these deployment models require Network Control 451 traffic to be propagated across the wireless network, it is 452 RECOMMENDED to map Network Control traffic marked CS6 to UP 7 (per 453 IEEE 802.11-2012, Section 9.2.4.2, Table 9-1), thereby admitting it 454 to the Voice Access Category (AC_VO). 456 4.1.2. Operations Administration Management (OAM) 458 The OAM (Operations, Administration, and Management) service class is 459 RECOMMENDED for OAM&P (Operations, Administration, and Management and 460 Provisioning). The RECOMMENDED DSCP marking for OAM is CS2. 462 By default, packets marked DSCP CS2 will be mapped to UP 2 and 463 serviced with the Background Access Category (AC_BK). Such servicing 464 is a contradiction to the intent expressed in [RFC4594] Section 3.3. 465 As such, it is RECOMMENDED that a non-default mapping be applied to 466 OAM traffic, such that CS2 DSCP is mapped to UP 0, thereby admitting 467 it to the Best Effort Access Category (AC_BE). 469 4.2. User Traffic 471 User traffic is defined as packet flows between different users or 472 subscribers. It is the traffic that is sent to or from end-terminals 473 and that supports a very wide variety of applications and services. 474 Network administrators can categorize their applications according to 475 the type of behavior that they require and MAY choose to support all 476 or a subset of the defined service classes. 478 4.2.1. Telephony 480 The Telephony service class is RECOMMENDED for applications that 481 require real-time, very low delay, very low jitter, and very low 482 packet loss for relatively constant-rate traffic sources (inelastic 483 traffic sources). This service class SHOULD be used for IP telephony 484 service. The fundamental service offered to traffic in the Telephony 485 service class is minimum jitter, delay, and packet loss service up to 486 a specified upper bound. The RECOMMENDED DSCP marking for Telephony 487 is EF. 489 Traffic marked to DSCP EF will map by default to UP 5, and thus to 490 the Video Access Category (AC_VI), rather than to the Voice Access 491 Category (AC_VO), for which it is intended. Therefore, a non-default 492 DSCP-to-UP mapping is RECOMMENDED, such that EF DSCP is mapped to UP 493 6, thereby admitting it into the Voice Access Category (AC_VO). 495 Similarly, the [RFC5865] VOICE-ADMIT DSCP (44/101100) is RECOMMENDED 496 to be mapped to UP 6, thereby admitting it also into the Voice Access 497 Category (AC_VO). 499 4.2.2. Signaling 501 The Signaling service class is RECOMMENDED for delay-sensitive 502 client-server (traditional telephony) and peer-to-peer application 503 signaling. Telephony signaling includes signaling between IP phone 504 and soft-switch, soft-client and soft-switch, and media gateway and 505 soft-switch as well as peer-to-peer using various protocols. This 506 service class is intended to be used for control of sessions and 507 applications. The RECOMMENDED DSCP marking for Signaling is CS5. 509 While Signaling is RECOMMENDED to receive a superior level of service 510 relative to the default class (i.e. AC_BE), it does not require the 511 highest level of service (i.e. AC_VO). This leaves only the Video 512 Access Category (AC_VI), which it will map to by default. Therefore 513 it is RECOMMENDED to map Signaling traffic marked CS5 DSCP to UP 5, 514 thereby admitting it to the Video Access Category (AC_VI). 516 Note: Signaling traffic is not control plane traffic from the 517 perspective of the network (but rather is data plane traffic); as 518 such, it does not merit provisioning in the Network Control service 519 class (marked CS6 and mapped to UP 6). However, Signaling traffic is 520 control-plane traffic from the perspective of the voice/video 521 telephony overlay-infrastructure. As such, Signaling should be 522 treated with preferential servicing vs. other data plane flows. One 523 way this may be achieved in certain WLAN deployments is by mapping 524 Signaling traffic marked CS5 to UP 5 (as recommended above). To 525 illustrate: IEEE 802.11-2012 displays a reference implementation 526 model in Figure 9-19 which depicts four transmit queues, one per 527 access category. In practical implementation, however, it is common 528 for WLAN network equipment vendors to actually implement dedicated 529 transmit queues on a per-UP basis, which are then dequeued into their 530 associated access category in a preferred (or even strict priority 531 manner). For example, (and specific to this point): it is common for 532 vendors to dequeue UP 5 ahead of UP 4 to the hardware performing the 533 EDCA function (EDCAF) for the Video Access Category (AC_VI). As 534 such, Signaling traffic may benefit from such treatment vs. other 535 video flows in the same access category (as well as vs. data flows in 536 the Best Effort and Background Access Categories) due to this 537 differentiation in servicing under such implementations. 539 4.2.3. Multimedia Conferencing 541 The Multimedia Conferencing service class is RECOMMENDED for 542 applications that require real-time service for rate-adaptive 543 traffic. The RECOMMENDED DSCP markings for Multimedia Conferencing 544 are AF41, AF42 and AF43. 546 The primary media type typically carried within the Multimedia 547 Conferencing service class is video; as such, it is RECOMMENDED to 548 map this class into the Video Access Category (which it does by 549 default). Specifically, it is RECOMMENDED to map AF41, AF42 and AF43 550 to UP 4, thereby admitting Multimedia Conferencing into the Video 551 Access Category (AC_VI). 553 4.2.4. Real-Time Interactive 555 The Real-Time Interactive traffic class is RECOMMENDED for 556 applications that require low loss and jitter and very low delay for 557 variable rate inelastic traffic sources. Such applications may 558 include inelastic video-conferencing applications, but may also 559 include gaming applications (as pointed out in [RFC4594] Sections 2.1 560 through 2.3, and Section 4.4). The RECOMMENDED DSCP marking for 561 Real-Time Interactive traffic is CS4. 563 The primary media type typically carried within the Real-Time 564 Interactive service class is video; as such, it is RECOMMENDED to map 565 this class into the Video Access Category (which it does by default). 566 Specifically, it is RECOMMENDED to map CS4 to UP 4, thereby admitting 567 Real-Time Interactive traffic into the Video Access Category (AC_VI). 569 4.2.5. Multimedia-Streaming 571 The Multimedia Streaming service class is RECOMMENDED for 572 applications that require near-real-time packet forwarding of 573 variable rate elastic traffic sources. Typically these flows are 574 unidirectional. The RECOMMENDED DSCP markings for Multimedia 575 Streaming are AF31, AF32 and AF33. 577 The primary media type typically carried within the Multimedia 578 Streaming service class is video; as such, it is RECOMMENDED to map 579 this class into the Video Access Category. Specifically, it is 580 RECOMMENDED to map AF31, AF32 and AF33 to UP 4, thereby admitting 581 Multimedia Streaming into the Video Access Category (AC_VI). 583 4.2.6. Broadcast Video 585 The Broadcast Video service class is RECOMMENDED for applications 586 that require near-real-time packet forwarding with very low packet 587 loss of constant rate and variable rate inelastic traffic sources. 588 Typically these flows are unidirectional. The RECOMMENDED DSCP 589 marking for Broadcast Video is CS3. 591 As directly implied by the name, the primary media type typically 592 carried within the Broadcast Video service class is video; as such, 593 it is RECOMMENDED to map this class into the Video Access Category. 594 Specifically, it is RECOMMENDED to map CS4 to UP 4, thereby admitting 595 Broadcast Video into the Video Access Category (AC_VI). 597 4.2.7. Low-Latency Data 599 The Low-Latency Data service class is RECOMMENDED for elastic and 600 time-sensitive data applications, often of a transactional nature, 601 where a user is waiting for a response via the network in order to 602 continue with a task at hand. As such, these flows may be considered 603 foreground traffic, with delays or drops to such traffic directly 604 impacting user-productivity. The RECOMMENDED DSCP markings for Low- 605 Latency Data are AF21, AF22 and AF23. 607 In line with the recommendations made in Section 4.2.2, mapping Low- 608 Latency Data to UP 3 may allow such to receive a superior level of 609 service via transmit queues servicing the EDCAF hardware for the Best 610 Effort Access Category (AC_BE). Therefore it is RECOMMENDED to map 611 Low-Latency Data traffic marked AF2x DSCP to UP 3, thereby admitting 612 it to the Best Effort Access Category (AC_BE). 614 4.2.8. High-Throughput Data 616 The High-Throughput Data service class is RECOMMENDED for elastic 617 applications that require timely packet forwarding of variable rate 618 traffic sources and, more specifically, is configured to provide 619 efficient, yet constrained (when necessary) throughput for TCP 620 longer-lived flows. These flows are typically non-user-interactive. 621 Per [RFC4594]-Section 4.8, it can be assumed that this class will 622 consume any available bandwidth and that packets traversing congested 623 links may experience higher queuing delays or packet loss. It is 624 also assumed that this traffic is elastic and responds dynamically to 625 packet loss. The RECOMMENDED DSCP markings for High-Throughput Data 626 are AF11, AF12 and AF13. 628 Unfortunately, there really is no corresponding fit for the High- 629 Throughput Data traffic class within the constrained 4 Access 630 Category 802.11 model. If the High-Throughput Data traffic class is 631 assigned to the Best Effort Access Category (AC_BE), then it would 632 contend with Low-Latency Data (while [RFC4594] recommends a 633 distinction in servicing between these traffic classes) as well as 634 with the default traffic class; alternatively, if it is assigned to 635 the Background Access Category (AC_BK), then it would receive a less- 636 then-best-effort service and contend with Low-Priority Data (as 637 discussed in Section 4.2.10). 639 As such, since there is no directly corresponding fit for the High- 640 Throughout Data service class within the 802.11 model, it is 641 generally RECOMMENDED to map High-Throughput Data to UP 0, thereby 642 admitting it to the Best Effort Access Category (AC_BE). 644 4.2.9. Standard Service Class 646 The Standard service class is RECOMMENDED for traffic that has not 647 been classified into one of the other supported forwarding service 648 classes in the DiffServ network domain. This service class provides 649 the Internet's "best-effort" forwarding behavior. The RECOMMENDED 650 DSCP marking for the Standard Service Class is DF. 652 The Standard Service Class loosely corresponds to the 802.11 Best 653 Effort Access Category (AC_BK) and therefore it is RECOMMENDED to map 654 Standard Service Class traffic marked DF DSCP to UP 0, thereby 655 admitting it to the Best Effort Access Category (AC_BE). 657 4.2.10. Low-Priority Data 659 The Low-Priority Data service class serves applications that the user 660 is willing to accept service without guarantees. This service class 661 is specified in [RFC3662]. 663 The Low-Priority Data service class loosely corresponds to the 802.11 664 Background Access Category (AC_BK) and therefore it is RECOMMENDED to 665 map Low-Priority Data traffic marked CS1 DSCP to UP 1, thereby 666 admitting it to the Background Access Category (AC_BK). 668 4.3. DSCP-to-UP Mapping Recommendations Summary 670 Figure 1 summarizes the [RFC4594] DSCP marking recommendations mapped 671 to IEEE 802.11 UP and access categories applied in the downstream 672 direction (from wired-to-wireless networks). 674 +------------------------------------------------------------------+ 675 | IETF DiffServ | PHB |Reference| IEEE 802.11 | 676 | Service Class | | RFC |User Priority| Access Category | 677 |===============+======+=========+=============+===================| 678 |Network Control| CS6 | RFC2474 | (See Section 4.1.1) | 679 +---------------+------+---------+-------------+-------------------+ 680 | Telephony | EF | RFC3246 | 6 | AC_VO (Voice) | 681 +---------------+------+---------+-------------+-------------------+ 682 | VOICE-ADMIT |VOICE-| RFC5865 | 6 | AC_VO (Voice) | 683 | |ADMIT | | | | 684 +---------------+------+---------+-------------+-------------------+ 685 | Signaling | CS5 | RFC2474 | 5 | AC_VI (Video) | 686 +---------------+------+---------+-------------+-------------------+ 687 | Multimedia | AF41 | | | | 688 | Conferencing | AF42 | RFC2597 | 4 | AC_VI (Video) | 689 | | AF43 | | | | 690 +---------------+------+---------+-------------+-------------------+ 691 | Real-Time | CS4 | RFC2474 | 4 | AC_VI (Video) | 692 | Interactive | | | | | 693 +---------------+------+---------+-------------+-------------------+ 694 | Multimedia | AF31 | | | | 695 | Streaming | AF32 | RFC2597 | 4 | AC_VI (Video) | 696 | | AF33 | | | | 697 +---------------+------+---------+-------------+-------------------+ 698 |Broadcast Video| CS3 | RFC2474 | 4 | AC_VI (Video) | 699 +---------------+------+---------+-------------+-------------------+ 700 | Low- | AF21 | | | | 701 | Latency | AF22 | RFC2597 | 3 |AC_BE (Best Effort)| 702 | Data | AF23 | | | | 703 +---------------+------+---------+-------------+-------------------+ 704 | OAM | CS2 | RFC2474 | 0 |AC_BE (Best Effort)| 705 +---------------+------+---------+-------------+-------------------+ 706 | High- | AF11 | | | | 707 | Throughput | AF12 | RFC2597 | 0 |AC_BE (Best Effort)| 708 | Data | AF13 | | | | 709 +---------------+------+---------+-------------+-------------------+ 710 | Standard | DF | RFC2474 | 0 |AC_BE (Best Effort)| 711 +---------------+------+---------+-------------+-------------------+ 712 | Low-Priority | CS1 | RFC3662 | 1 | AC_BK (Background)| 713 | Data | | | | | 714 +------------------------------------------------------------------+ 716 Figure 1: Summary of Downstream DSCP to IEEE 802.11 UP and AC Mapping 717 Recommendations 719 5. Upstream Mapping Recommendations 721 In the upstream direction, there are three types of mapping that may 722 occur: 724 o DSCP-to-UP mapping within the wireless client operating system 726 o UP-to-DSCP mapping at the wireless access point 728 o DSCP-Trust at the wireless access point 730 5.1. Upstream DSCP-to-UP Mapping within the Wireless Client Operating 731 System 733 Some operating systems on wireless client devices utilize a similar 734 default DSCP-to-UP mapping scheme as described in Section 2.1. As 735 such, this can lead to the same conflicts as described in that 736 section, but in the upstream direction. 738 Therefore, to improve on these default mappings, and to achieve 739 parity and consistency with downstream QoS, it is RECOMMENDED that 740 such wireless client operating systems utilize instead the same DSCP- 741 to-UP mapping recommendations presented in Section 4 and/or fully 742 customizable UP markings. 744 5.2. UP-to-DSCP Mapping at the Wireless Access Point 746 UP-to-DSCP mapping generates a DSCP value for the IP packet (either 747 an unencapsulated IP packet or an IP packet encapsulated within a 748 tunneling protocol such as CAPWAP - and destined towards a wireless 749 LAN controller for decapsulation and forwarding) from the Layer 2 750 IEEE UP markings of the wireless frame. 752 It should be noted that any explicit remarking policy to be performed 753 on such a packet only takes place at the nearest classification and 754 marking policy enforcement point, which may be: 756 o At the wireless access point 758 o At the wired network switch port 760 o At the wireless LAN controller 762 As such, UP-to-DSCP mapping allows for wireless L2 markings to affect 763 the QoS treatment of a packet over the wired IP network (that is, 764 until the packet reaches the nearest classification and marking 765 policy enforcement point). 767 It should be noted that nowhere in the IEEE 802.11 specifications is 768 there an intent expressed for 802.11 UP to be used to influence QoS 769 treatment over wired IP networks. Furthermore, both [RFC2474] and 770 [RFC2475] allow for the host to set DSCP markings for QoS treatment 771 over IP networks. Therefore, it is NOT RECOMMENDED that wireless 772 access points trust UP markings as set by these hosts and 773 subsequently perform a UP-to-DSCP mapping in the upstream direction, 774 but rather, if wireless host markings are to be trusted (as per 775 business requirements, technical constraints and administrative 776 preference), then it is RECOMMENDED to trust the DSCP markings set by 777 these wireless hosts. 779 5.3. DSCP-Trust at the Wireless Access Point 781 On wireless access points that can trust DSCP markings of packets 782 encapsulated within wireless frames it is RECOMMENDED to trust DSCP 783 markings in the upstream direction, for the following reasons: 785 o [RFC2474] and [RFC2475] allow for hosts to set DSCP markings to 786 achieve and end-to-end differentiated service 788 o IEEE 802.11 does not specify that UP markings are to be used to 789 affect QoS treatment over wired IP networks 791 o Most wireless device operating systems generate UP values by the 792 same method as described in Section 3.1 (i.e. by using the 3 MSB 793 of the encapsulated 6-bit DSCP); then, at the access point, these 794 3-bit mappings are converted back into DSCP values, either by the 795 default operation described in Section 3.2 or by a customized 796 mapping as described in Section 4; in either case, information is 797 lost in the transitions from 6-bit marking to 3-bit marking and 798 then back to 6-bit marking; trusting the encapsulated DSCP 799 prevents this loss of information 801 o A practical implementation benefit is also realized by trusting 802 the DSCP set by wireless client devices, as enabling applications 803 to mark DSCP is much more prevalent and accessible to programmers 804 of wireless applications vis-a-vis trying to explicitly set UP 805 values, which requires special hooks into the wireless device 806 operating system and/or hardware device drivers, many of which (at 807 the time of writing) have little or no resources to support such 808 functionality 810 6. Appendix: IEEE 802.11 QoS Overview 812 QoS is enabled on wireless networks by means of the Hybrid 813 Coordination Function (HCF). To give better context to the 814 enhancements in HCF that enable QoS, it may be helpful to begin with 815 a review of the original Distributed Coordination Function (DCF). 817 6.1. Distributed Coordination Function (DCF) 819 As has been noted, the Wi-Fi medium is a shared medium, with each 820 station-including the wireless access point-contending for the medium 821 on equal terms. As such, it shares the same challenge as any other 822 shared medium in requiring a mechanism to prevent (or avoid) 823 collisions which can occur when two (or more) stations attempt 824 simultaneous transmission. 826 The IEEE Ethernet working group solved this challenge by implementing 827 a Carrier Sense Multiple Access/Collision Detection (CSMA/CD) 828 mechanism that could detect collisions over the shared physical cable 829 (as collisions could be detected as reflected energy pulses over the 830 physical wire). Once a collision was detected, then a pre-defined 831 set of rules was invoked that required stations to back off and wait 832 random periods of time before re-attempting transmission. While 833 CSMA/CD improved the usage of Ethernet as a shared medium, it should 834 be noted the ultimate solution to solving Ethernet collisions was the 835 advance of switching technologies, which treated each Ethernet cable 836 as a dedicated collision domain. 838 However, unlike Ethernet (which uses physical cables), collisions 839 cannot be directly detected over the wireless medium, as RF energy is 840 radiated over the air and colliding bursts are not necessarily 841 reflected back to the transmitting stations. Therefore, a different 842 mechanism is required for this medium. 844 As such, the IEEE modified the CSMA/CD mechanism to adapt it to 845 wireless networks to provide Carrier Sense Multiple Access/Collision 846 Avoidance (CSMA/CA). The original CSMA/CA mechanism used in 802.11 847 was the Distributed Coordination Function. DCF is a timer-based 848 system that leverages three key sets of timers, the slot time, 849 interframe spaces and contention windows. 851 6.1.1. Slot Time 853 The slot time is the basic unit of time measure for both DCF and HCF, 854 on which all other timers are based. The slot time duration varies 855 with the different generations of data-rates and performances 856 described by the 802.11 standard. For example, the IEEE 802.11-2012 857 standard specifies the slot time to be 20 us (IEEE 802.11-2012 858 Table 16-2) for legacy implementations (such as 802.11b, supporting 859 1, 2, 5.5 and 11 Mbps data rates), while newer implementations 860 (including 802.11g, 80.11a, 802.11n and 802.11ac, supporting data 861 rates from 500 Mbps to over 1 Gbps) define a shorter slot time of 9 862 us (IEEE 802.11-2012, Section 18.4.4, Table 18-17). 864 6.1.2. Interframe Spaces 866 The time interval between frames that are transmitted over the air is 867 called the Interframe Space (IFS). Several IFS are defined in 868 802.11, with the two most relevant to DCF being the Short Interframe 869 Space (SIFS) and the DCF Interframe Space (DIFS). 871 The SIFS is the amount of time in microseconds required for a 872 wireless interface to process a received RF signal and its associated 873 802.11 frame and to generate a response frame. Like slot times, the 874 SIFS can vary according to the performance implementation of the 875 802.11 standard. The SIFS for 802.11a, 802.11n and 802.11ac (in 5 876 Ghz) is 16 us (IEEE 802.11-2012, Section 18.4.4, Table 18-17). 878 Additionally, a station must sense the status of the wireless medium 879 before transmitting. If it finds that the medium is continuously 880 idle for the duration of a DIFS, then it is permitted to attempt 881 transmission of a frame (after waiting an additional random backoff 882 period, as will be discussed in the next section). If the channel is 883 found busy during the DIFS interval, the station must defer its 884 transmission until the medium is found idle for the duration of a 885 DIFS interval. The DIFS is calculated as: 887 DIFS = SIFS + (2 * Slot time) 889 However, if all stations waited only a fixed amount of time before 890 attempting transmission then collisions would be frequent. To offset 891 this, each station must wait, not only a fixed amount of time (the 892 DIFS) but also a random amount of time (the random backoff) prior to 893 transmission. The range of the generated random backoff timer is 894 bounded by the Contention Window. 896 6.1.3. Contention Windows 898 Contention windows bound the range of the generated random backoff 899 timer that each station must wait (in addition to the DIFS) before 900 attempting transmission. The initial range is set between 0 and the 901 Contention Window minimum value (CWmin), inclusive. The CWmin for 902 DCF (in 5 GHz) is specified as 15 slot times (IEEE 802.11- 2012, 903 Section 18.4.4, Table 18-17). 905 However, it is possible that two (or more) stations happen to pick 906 the exact same random value within this range. If this happens then 907 a collision will occur. At this point, the stations effectively 908 begin the process again, waiting a DIFS and generate a new random 909 backoff value. However, a key difference is that for this subsequent 910 attempt, the Contention Window approximatively doubles in size (thus 911 exponentially increasing the range of the random value). This 912 process repeats as often as necessary if collisions continue to 913 occur, until the maximum Contention Window size (CWmax) is reached. 914 The CWmax for DCF is specified as 1023 slot times (IEEE 802.11-2012, 915 Section 18.4.4, Table 18-17). 917 At this point, transmission attempts may still continue (until some 918 other pre-defined limit is reached), but the Contention Window sizes 919 are fixed at the CWmax value. 921 Incidentally it may be observed that a significant amount of jitter 922 can be introduced by this contention process for wireless 923 transmission access. For example, the incremental transmission delay 924 of 1023 slot times (CWmax) using 9 us slot times may be as high as 9 925 ms of jitter per attempt. And as previously noted, multiple attempts 926 can be made at CWmax. 928 6.2. Hybrid Coordination Function (HCF) 930 Therefore, as can be seen from the preceding description of DCF, 931 there is no preferential treatment of one station over another when 932 contending for the shared wireless media; nor is there any 933 preferential treatment of one type of traffic over another during the 934 same contention process. To support the latter requirement, the IEEE 935 enhanced DCF in 2005 to support QoS, specifying HCF in 802.11, which 936 was integrated into the main 802.11 standard in 2007. 938 6.2.1. User Priority (UP) 940 One of the key changes to the 802.11 frame format is the inclusion of 941 a QoS Control field, with 3 bits dedicated for QoS markings. These 942 bits are referred to the User Priority (UP) bits and these support 943 eight distinct marking values: 0-7, inclusive. 945 While such markings allow for frame differentiation, these alone do 946 not directly affect over-the-air treatment. Rather it is the non- 947 configurable and standard-specified mapping of UP markings to 802.11 948 Access Categories (AC) that generate differentiated treatment over 949 wireless media. 951 6.2.2. Access Category (AC) 953 Pairs of UP values are mapped to four defined access categories that 954 correspondingly specify different treatments of frames over the air. 955 These access categories (in order of relative priority from the top 956 down) and their corresponding UP mappings are shown in Figure 2 957 (adapted from IEEE 802.11-2012, Section 9.2.4.2, Table 9-1). 959 +-----------------------------------------+ 960 | User | Access | Designative | 961 | Priority | Category | (informative) | 962 |===========+============+================| 963 | 7 | AC_VO | Voice | 964 +-----------+------------+----------------+ 965 | 6 | AC_VO | Voice | 966 +-----------+------------+----------------+ 967 | 5 | AC_VI | Video | 968 +-----------+------------+----------------+ 969 | 4 | AC_VI | Video | 970 +-----------+------------+----------------+ 971 | 3 | AC_BE | Best Effort | 972 +-----------+------------+----------------+ 973 | 0 | AC_BE | Best Effort | 974 +-----------+------------+----------------+ 975 | 2 | AC_BK | Background | 976 +-----------+------------+----------------+ 977 | 1 | AC_BK | Background | 978 +-----------------------------------------+ 980 Figure 2: IEEE 802.11 Access Categories and User Priority Mappings 982 The manner in which these four access categories achieve 983 differentiated service over-the-air is primarily by tuning the fixed 984 and random timers that stations have to wait before sending their 985 respective types of traffic, as will be discussed next. 987 6.2.3. Arbitration Inter-Frame Space (AIFS) 989 As previously mentioned, each station must wait a fixed amount of 990 time to ensure the air is clear before attempting transmission. With 991 DCF, the DIFS is constant for all types of traffic. However, with 992 802.11 the fixed amount of time that a station has to wait will 993 depend on the access category and is referred to as an Arbitration 994 Interframe Space (AIFS). AIFS are defined in slot times and the AIFS 995 per access category are shown in Figure 3 (adapted from IEEE 996 802.11-2012, Section 8.4.2.31, Table 8-105). 998 +------------------------------------------+ 999 | Access | Designative | AIFS | 1000 | Category | (informative) |(slot times)| 1001 |===========+=================+============| 1002 | AC_VO | Voice | 2 | 1003 +-----------+-----------------+------------+ 1004 | AC_VI | Video | 2 | 1005 +-----------+-----------------+------------+ 1006 | AC_BE | Best Effort | 3 | 1007 +-----------+-----------------+------------+ 1008 | AC_BK | Background | 7 | 1009 +-----------+-----------------+------------+ 1011 Figure 3: Arbitration Interframe Spaces by Access Category 1013 6.2.4. Access Category Contention Windows (CW) 1015 Not only is the fixed amount of time that a station has to wait 1016 skewed according to 802.11 access category, but so are the relative 1017 sizes of the Contention Windows that bound the random backoff timers, 1018 as shown in Figure 4 (adapted from IEEE 802.11-2012, 1019 Section 8.4.2.31, Table 8-105). 1021 +-------------------------------------------------------+ 1022 | Access | Designative | CWmin | CWmax | 1023 | Category | (informative) |(slot times)|(slot times)| 1024 |===========+=================+============|============| 1025 | AC_VO | Voice | 3 | 7 | 1026 +-----------+-----------------+------------+------------+ 1027 | AC_VI | Video | 7 | 15 | 1028 +-----------+-----------------+------------+------------+ 1029 | AC_BE | Best Effort | 15 | 1023 | 1030 +-----------+-----------------+------------+------------+ 1031 | AC_BK | Background | 15 | 1023 | 1032 +-----------+-----------------+------------+------------+ 1034 Figure 4: Contention Window Sizes by Access Category 1036 When the fixed and randomly generated timers are added together on a 1037 per access category basis, then traffic assigned to the Voice Access 1038 Category (i.e. traffic marked to UP 6 or 7) will receive a 1039 statistically superior service relative to traffic assigned to the 1040 Video Access Category (i.e. traffic marked UP 5 and 4), which, in 1041 turn, will receive a statistically superior service relative to 1042 traffic assigned to the Best Effort Access Category traffic (i.e. 1044 traffic marked UP 3 and 0), which finally will receive a 1045 statistically superior service relative to traffic assigned to the 1046 Background Access Category traffic (i.e. traffic marked to UP 2 and 1047 1). 1049 6.3. IEEE 802.11u QoS Map Set 1051 IEEE 802.11u [IEEE.802-11u.2011] is proposed addendum to the IEEE 1052 802.11 standard which includes, among other enhancements, a mechanism 1053 by which wireless access points can communicate DSCP to/from UP 1054 mappings that have been configured on the wired IP network. 1055 Specifically, a QoS Map Set information element (described in IEEE 1056 802.11u-2011 Section 7.3.2.95) is transmitted from an AP to a 1057 wireless endpoint device in an association / re-association Response 1058 frame (or within a special QoS Map Configure frame). The purpose of 1059 the QoS Map Set information element is to provide the mapping of 1060 higher layer Quality of Service constructs (i.e. DSCP) to User 1061 Priorities so that a wireless endpoint device (that supports this 1062 function and is administratively configured to enable it) can perform 1063 corresponding DSCP-to-UP mapping within the device (i.e. between 1064 applications and the operating system / wireless network interface 1065 hardware drivers) to align with what the APs are mapping in the 1066 downstream direction, so as to achieve consistent end-to-end QoS. 1068 The QoS Map Set information element includes two key components: 1070 1) each of the eight UP values (0-7) are associated with a range of 1071 DSCP values, and 1073 2) (up to 21) exceptions from these range-based DSCP to/from UP 1074 mapping associations may be optionally and explicitly specified. 1076 In line with the recommendations put forward in this document, the 1077 following recommendations apply when the this QoS Map Set information 1078 element is enabled: 1080 1) each of the eight UP values (0-7) are RECOMMENDED to be mapped to 1081 DSCP 0 (as a baseline, so as to meet the recommendation made in 1082 Section 4.1.1 (that packets marked to unused DiffServ Codepoints be 1083 remarked at the edge of the DiffServ domain), and 1085 2) (up to 21) exceptions from this baseline mapping are RECOMMENDED 1086 to be make in line with Section 4.3, to correspond to the DiffServ 1087 Codepoints that are in use over the IP network. 1089 7. IANA Considerations 1091 This memo asks the IANA for no new parameters. 1093 8. Security Considerations 1095 The recommendation offered in Section 4.1.1 (of dropping or remarking 1096 packets marked with DiffServ Codepoints not in use at the edge of the 1097 DiffServ domain) is to address a Denial-of-Service attack vector that 1098 exists at wired-to-wireless edges due to the requirement of trusting 1099 traffic markings to ensure end-to-end QoS. For example, consider a 1100 malicious user flooding traffic marked CS7 or CS6 DSCP toward the 1101 WLAN. These codepoints would map by default to UP 7 and UP 6 1102 (respectively), both of which would be assigned to the Voice Access 1103 Category (AC_VO). Such a flood could cause a Denial-of-Service to 1104 wireless voice applications. 1106 8.1. Privacy Considerations 1108 9. Acknowledgements 1110 The authors wish to thank TSVWG reviewers. 1112 The authors acknowledge a great many inputs, notably from Jerome 1113 Henry, David Kloper, Mark Montanez, Glen Lavers, Michael Fingleton, 1114 Sarav Radhakrishnan, Karthik Dakshinamoorthy, Simone Arena, Ranga 1115 Marathe, Ramachandra Murthy and many others. 1117 10. References 1119 10.1. Normative References 1121 [IEEE.802-11.2012] 1122 "Information technology - Telecommunications and 1123 information exchange between systems - Local and 1124 metropolitan area networks - Specific requirements - Part 1125 11: Wireless LAN Medium Access Control (MAC) and Physical 1126 Layer (PHY) specifications", IEEE Standard 802.11, 2012, 1127 . 1130 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1131 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1132 RFC2119, March 1997, 1133 . 1135 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1136 "Definition of the Differentiated Services Field (DS 1137 Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 1138 10.17487/RFC2474, December 1998, 1139 . 1141 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1142 and W. Weiss, "An Architecture for Differentiated 1143 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 1144 . 1146 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 1147 "Assured Forwarding PHB Group", RFC 2597, DOI 10.17487/ 1148 RFC2597, June 1999, 1149 . 1151 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 1152 J., Courtney, W., Davari, S., Firoiu, V., and D. 1153 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 1154 Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002, 1155 . 1157 [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort 1158 Per-Domain Behavior (PDB) for Differentiated Services", 1159 RFC 3662, DOI 10.17487/RFC3662, December 2003, 1160 . 1162 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 1163 Guidelines for DiffServ Service Classes", RFC 4594, DOI 1164 10.17487/RFC4594, August 2006, 1165 . 1167 [RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated 1168 Services Code Point (DSCP) for Capacity-Admitted Traffic", 1169 RFC 5865, DOI 10.17487/RFC5865, May 2010, 1170 . 1172 10.2. Informative References 1174 [I-D.ietf-tsvwg-diffserv-intercon] 1175 Geib, R. and D. Black, "Diffserv-Interconnection classes 1176 and practice", draft-ietf-tsvwg-diffserv-intercon-06 (work 1177 in progress), June 2016. 1179 [IEEE.802-11u.2011] 1180 "Information technology - Telecommunications and 1181 information exchange between systems - Local and 1182 metropolitan area networks - Specific requirements - Part 1183 11: Wireless LAN Medium Access Control (MAC) and Physical 1184 Layer (PHY) specifications", IEEE Standard 802.11, 2011, 1185 . 1188 [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of 1189 Diffserv Service Classes", RFC 5127, DOI 10.17487/RFC5127, 1190 February 2008, . 1192 [RFC7561] Kaippallimalil, J., Pazhyannur, R., and P. Yegani, 1193 "Mapping Quality of Service (QoS) Procedures of Proxy 1194 Mobile IPv6 (PMIPv6) and WLAN", RFC 7561, DOI 10.17487/ 1195 RFC7561, June 2015, 1196 . 1198 Appendix A. Change Log 1200 Initial Version: July 2015 1202 Authors' Addresses 1204 Tim Szigeti 1205 Cisco Systems 1206 Vancouver, British Columbia V7X 1J1 1207 Canada 1209 Email: szigeti@cisco.com 1211 Fred Baker 1212 Cisco Systems 1213 Santa Barbara, California 93117 1214 USA 1216 Email: fred@cisco.com