idnits 2.17.1 draft-ietf-tsvwg-ieee-802-11-04.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 (July 3, 2017) is 2482 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 == Outdated reference: A later version (-10) exists of draft-ietf-tsvwg-le-phb-02 Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Working Group T. Szigeti 3 Internet-Draft J. Henry 4 Intended status: Standards Track Cisco Systems 5 Expires: January 4, 2018 F. Baker 6 July 3, 2017 8 Diffserv to IEEE 802.11 Mapping 9 draft-ietf-tsvwg-ieee-802-11-04 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 January 4, 2018. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Related work . . . . . . . . . . . . . . . . . . . . . . 3 58 1.2. Interaction with RFC 7561 . . . . . . . . . . . . . . . . 4 59 1.3. Applicability Statement . . . . . . . . . . . . . . . . . 4 60 1.4. Document Organization . . . . . . . . . . . . . . . . . . 5 61 1.5. Requirements Language . . . . . . . . . . . . . . . . . . 5 62 1.6. Terminology Used in this Document . . . . . . . . . . . . 6 63 2. Service Comparison and Default Interoperation of Diffserv and 64 IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 2.1. Diffserv Domain Boundaries . . . . . . . . . . . . . . . 9 66 2.2. Default DSCP-to-UP Mappings and Conflicts . . . . . . . . 10 67 2.3. Default UP-to-DSCP Mappings and Conflicts . . . . . . . . 11 68 3. Wireless Device Marking and Mapping Capability 69 Recommendations . . . . . . . . . . . . . . . . . . . . . . . 12 70 4. DSCP-to-UP Mapping Recommendations . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . 16 80 4.2.6. Broadcast Video . . . . . . . . . . . . . . . . . . . 17 81 4.2.7. Low-Latency Data . . . . . . . . . . . . . . . . . . 17 82 4.2.8. High-Throughput Data . . . . . . . . . . . . . . . . 17 83 4.2.9. Standard Service Class . . . . . . . . . . . . . . . 18 84 4.2.10. Low-Priority Data . . . . . . . . . . . . . . . . . . 18 85 4.3. DSCP-to-UP Mapping Recommendations Summary . . . . . . . 18 86 5. Upstream Mapping and Marking Recommendations . . . . . . . . 20 87 5.1. Upstream DSCP-to-UP Mapping within the Wireless Client 88 Operating System . . . . . . . . . . . . . . . . . . . . 20 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 . . . . 21 91 5.4. Upstream DSCP Marking at the Wireless Access Point . . . 22 92 6. Appendix: IEEE 802.11 QoS Overview . . . . . . . . . . . . . 22 93 6.1. Distributed Coordination Function (DCF) . . . . . . . . . 23 94 6.1.1. Slot Time . . . . . . . . . . . . . . . . . . . . . . 23 95 6.1.2. Interframe Spaces . . . . . . . . . . . . . . . . . . 24 96 6.1.3. Contention Windows . . . . . . . . . . . . . . . . . 24 98 6.2. Hybrid Coordination Function (HCF) . . . . . . . . . . . 25 99 6.2.1. User Priority (UP) . . . . . . . . . . . . . . . . . 25 100 6.2.2. Access Category (AC) . . . . . . . . . . . . . . . . 25 101 6.2.3. Arbitration Inter-Frame Space (AIFS) . . . . . . . . 26 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 8.1. General QoS Security Recommendations . . . . . . . . . . 29 107 8.2. WLAN QoS Security Recommendations . . . . . . . . . . . . 30 108 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 109 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 110 10.1. Normative References . . . . . . . . . . . . . . . . . . 31 111 10.2. Informative References . . . . . . . . . . . . . . . . . 33 112 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 33 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 115 1. Introduction 117 Wireless has become the preferred medium for endpoints connecting to 118 business and private networks. However, the wireless medium defined 119 by IEEE 802.11 [IEEE.802.11-2016] presents several design challenges 120 for ensuring end-to-end quality of service. Some of these challenges 121 relate to the nature of the IEEE 802.11 RF medium itself, being a 122 half-duplex and shared medium, while other challenges relate to the 123 fact that the IEEE 802.11 standard is not administered by the same 124 standards body as IP networking standards. While the IEEE has 125 developed tools to enable QoS over wireless networks, little guidance 126 exists on how to maintain consistency of QoS treatment between wired 127 IP and wireless IEEE 802.11 networks. The purpose of this document 128 is to provide such guidance. 130 1.1. Related work 132 Several RFCs outline Diffserv QoS recommendations over IP networks, 133 including: 135 o [RFC2474] specifies the Diffserv Codepoint Field. This RFC also 136 details Class Selectors, as well as the Default Forwarding (DF) 137 treatment. 139 o [RFC2475] defines a Diffserv architecture 141 o [RFC3246] specifies the Expedited Forwarding (EF) Per-Hop Behavior 142 (PHB) 144 o [RFC2597] specifies the Assured Forwarding (AF) PHB. 146 o [RFC3662] specifies a Lower Effort Per-Domain Behavior (PDB) 148 o [RFC4594] presents Configuration Guidelines for Diffserv Service 149 Classes 151 o [RFC5127] presents the Aggregation of Diffserv Service Classes 153 o [RFC5865] specifies a DSCP for Capacity Admitted Traffic 155 Note: [RFC4594] is intended to be viewed as a set of "project plans" 156 for building all the (diffserv) furniture that one might want. Thus, 157 it describes different types of traffic expected in IP networks and 158 provides guidance as to what DSCP marking(s) should be associated 159 with each traffic type. As such, this document draws heavily on 160 [RFC4594], [RFC5127], and [RFC8100]. 162 In turn, the relevant standard for wireless QoS is IEEE 802.11, which 163 is being progressively updated; the current version of which (at the 164 time of writing) is [IEEE.802.11-2016]. 166 1.2. Interaction with RFC 7561 168 There is also a recommendation from the GSMA, Mapping Quality of 169 Service (QoS) Procedures of Proxy Mobile IPv6 (PMIPv6) and WLAN 170 [RFC7561]. The GSMA specification was developed without reference to 171 existing IETF specifications for various services, referenced in 172 Section 1.1. Thus, [RFC7561] conflicts with the overall Diffserv 173 traffic-conditioning service plan, both in the services specified and 174 the code points specified for them. As such, these two plans cannot 175 be normalized. Rather, as discussed in [RFC2474] Section 2, the two 176 domains (IEEE 802.11 and GSMA) are different Differentiated Services 177 Domains separated by a Differentiated Services Boundary. At that 178 boundary, code points from one domain are translated to code points 179 for the other, and maybe to Default (zero) if there is no 180 corresponding service to translate to. 182 1.3. Applicability Statement 184 This document is applicable to the use of Differentiated Services 185 that interconnect with IEEE 802.11 wireless LANs (referred to as Wi- 186 Fi, throughout this document, for simplicity). These guidelines are 187 applicable whether the wireless access points (APs) are deployed in 188 an autonomous manner, managed by (centralized or distributed) WLAN 189 controllers or some hybrid deployment option. This is because in all 190 these cases, the wireless access point is the bridge between wired 191 and wireless media. 193 This document applies to IP networks using WiFi infrastructure at the 194 link layer. Such networks typically include wired LANs with wireless 195 access points at their edges, however, such networks can also include 196 Wi-Fi backhaul, wireless mesh solutions or any other type of AP-to-AP 197 wireless network that extends the wired network infrastructure. 199 1.4. Document Organization 201 This document is organized as follows: 203 o Section 1 introduces the wired-to-wireless QoS challenge, 204 references related work, outlines the organization of the 205 document, and specifies both the requirements language and the 206 terminology used in this document. 208 o Section 2 begins the discussion with a comparison of IETF Diffserv 209 QoS and Wi-Fi QoS standards and highlights discrepancies between 210 these that require reconciliation. 212 o Section 3 presents the marking and mapping capabilities that 213 wireless access points and wireless endpoint devices are 214 recommended to support. 216 o Section 4 presents DSCP-to-UP mapping recommendations for each of 217 the [RFC4594] service classes, which are primarily applicable in 218 the downstream (wired-to-wireless) direction. 220 o Section 5, in turn, considers upstream (wireless-to-wired) QoS 221 options, their respective merits and recommendations. 223 o Section 6 (in the form of an Appendix) presents a brief overview 224 of how QoS is achieved over IEEE 802.11 wireless networks, given 225 the shared, half-duplex nature of the wireless medium. 227 o Section 7 on notes IANA considerations, security considerations, 228 acknowledgements and references, respectively 230 1.5. Requirements Language 232 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 233 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL", and "NOT 234 RECOMMENDED" in this document are to be interpreted as described in 235 [RFC2119]. 237 1.6. Terminology Used in this Document 239 Key terminology used in this document includes: 241 AC: Access Category. A label for the common set of enhanced 242 distributed channel access (EDCA) parameters that are used by a 243 quality-of-service (QoS) station (STA) to contend for the channel 244 in order to transmit medium access control (MAC) service data 245 units (MSDUs) with certain priorities. [IEEE.802.11-2016] 246 Section 3.2. 248 AIFS: Arbitration Interframe Space. Interframe space used by QoS 249 stations before transmission of data and other frame types defined 250 by [IEEE.802.11-2016] Section 10.3.2.3.6. 252 AP: Access Point. An entity that contains one station (STA) and 253 provides access to the distribution services, via the wireless 254 medium (WM) for associated STAs. An AP comprises a STA and a 255 distribution system access function (DSAF) [IEEE.802.11-2016] 256 Section 3.1. 258 BSS: Basic Service Set. Informally, a wireless cell; formally, a 259 set of stations that have successfully synchronized using the JOIN 260 service primitives and one STA that has used the START primitive. 261 Alternatively, a set of STAs that have used the START primitive 262 specifying matching mesh profiles where the match of the mesh 263 profiles has been verified via the scanning procedure. Membership 264 in a BSS does not imply that wireless communication with all other 265 members of the BSS is possible. Defined in [IEEE.802.11-2016] 266 Section 3.1. 268 Contention Window: See CW. 270 CSMA/CA: Carrier Sense Multiple Access with Collision Avoidance. 271 A media access control method in which carrier sensing is used, 272 but nodes attempt to avoid collisions by transmitting only when 273 the channel is sensed to be "idle". When these do transmit, nodes 274 transmit their packet data in its entirety. 276 CSMA/CD: Carrier Sense Multiple Access with Collision Detection. 277 A media access control method (used most notably in early Ethernet 278 technology) for local area networking. It uses a carrier-sensing 279 scheme in which a transmitting station detects collisions by 280 sensing transmissions from other stations while transmitting a 281 frame. When this collision condition is detected, the station 282 stops transmitting that frame, transmits a jam signal, and then 283 waits for a random time interval before trying to resend the 284 frame. 286 CW: Contention Window. Limits a CWMin and CWMax, from which a 287 random backoff is computed. 289 CWMax: Contention Window Maximum. The maximum value (in unit of 290 Slot Time) that a contention window can take. 292 CWMin: Contention Window Minimum. The minimum value that a 293 contention window can take. 295 DCF: Distributed Coordinated Function. A class of coordination 296 function where the same coordination function logic is active in 297 every station (STA) in the basic service set (BSS) whenever the 298 network is in operation. 300 DIFS: Distributed (Coordination Function) Interframe Space. A 301 unit of time during which the medium has to be detected as idle 302 before a station should attempt to send frames, as per 303 [IEEE.802.11-2016] Section 10.3.2.3.5. 305 DSCP: Differentiated Service Code Point [RFC2474] and [RFC2475]. 307 HCF: Hybrid Coordination Function A coordination function that 308 combines and enhances aspects of the contention based and 309 contention free access methods to provide quality-of-service (QoS) 310 stations (STAs) with prioritized and parameterized QoS access to 311 the wireless medium (WM), while continuing to support non-QoS STAs 312 for best-effort transfer. [IEEE.802.11-2016] Section 3.1. 314 IFS: Interframe Space. Period of silence between transmissions 315 over 802.11 networks. [IEEE.802.11-2016] describes several types 316 of Interframe Spaces. 318 Random Backoff Timer: A pseudorandom integer period of time (in 319 units of Slot Time) over the interval (0,CW), where CWmin is-less- 320 than-or-equal-to CW, which in turn is less-than-or-equal-to CWMax. 321 Stations desiring to initiate transfer of data frames and-or 322 Management frames using the DCF shall invoke the carrier sense 323 mechanism to determine the busy-or-idle state of the medium. If 324 the medium is busy, the STA shall defer until the medium is 325 determined to be idle without interruption for a period of time 326 equal to DIFS when the last frame detected on the medium was 327 received correctly, or after the medium is determined to be idle 328 without interruption for a period of time equal to EIFS when the 329 last frame detected on the medium was not received correctly. 330 After this DIFS or EIFS medium idle time, the STA shall then 331 generate a random backoff period for an additional deferral time 332 before transmitting. [IEEE.802.11-2016] Section 10.3.3. 334 RF: Radio Frequency. 336 SIFS: Short Interframe Space. An IFS used before transmission of 337 specific frames as defined in [IEEE.802.11-2016] 338 Section 10.3.2.3.3. 340 Slot Time: A unit of time used to count time intervals in 802.11 341 networks, and defined in [IEEE.802.11-2016] Section 10.3.2.13. 343 Trust: From a QoS-perspective, trust refers to the accepting of 344 the QoS markings of a packet by a network device. Trust is 345 typically extended at Layer 3 (by accepting the DSCP), but may 346 also be extended at lower layers, such as at Layer 2 by accepting 347 User Priority markings. For example, if an access point is 348 configured to trust DSCP markings and it receives a packet marked 349 EF, then it would treat the packet with the Expedite Forwarding 350 PHB and propagate the EF marking value (DSCP 46) as it transmits 351 the packet. Alternatively, if a network device is configured to 352 operate in an untrusted manner, then it would remark packets as 353 these entered the device, typically to DF (or to a different 354 marking value at the network administrator's preference). Note: 355 The terms "trusted" and "untrusted" are used extensively in RFC 356 4594. 358 UP: User Priority. A value associated with a medium access 359 control (MAC) service data unit (MSDU) that indicates how the MSDU 360 is to be handled. The UP is assigned to an MSDU in the layers 361 above the MAC [IEEE.802.11-2016] Section 3.1. The UP defines a 362 level of priority for the associated frame, on a scale of 0 to 7. 364 Wi-Fi: An interoperability certification defined by the Wi-Fi 365 Alliance. However, this term is commonly used, including in the 366 present document, to be the equivalent of IEEE 802.11. 368 2. Service Comparison and Default Interoperation of Diffserv and IEEE 369 802.11 371 (Section 6 provides a brief overview of IEEE 802.11 QoS.) 373 The following comparisons between IEEE 802.11 and Diffserv services 374 should be noted: 376 o [IEEE.802.11-2016] does not support an EF PHB service [RFC3246], 377 as it is not possible to assure that a given access category will 378 be serviced with strict priority over another (due to the random 379 element within the contention process) 381 o [IEEE.802.11-2016] does not support an AF PHB service [RFC2597], 382 again because it is not possible to assure that a given access 383 category will be serviced with a minimum amount of assured 384 bandwidth (due to the non-deterministic nature of the contention 385 process) 387 o [IEEE.802.11-2016] loosely supports a [RFC2474] Default Forwarding 388 service via the Best Effort Access Category (AC_BE) 390 o [IEEE.802.11-2016] loosely supports a [RFC3662] Lower Effort PDB 391 service via the Background Access Category (AC_BK) 393 As such, these high-level considerations should be kept in mind when 394 mapping from Diffserv to [IEEE.802.11-2016] (and vice-versa); 395 however, access points may or may not always be positioned at 396 Diffserv domain boundaries, as will be discussed next. 398 2.1. Diffserv Domain Boundaries 400 It is important to recognize that the wired-to-wireless edge may or 401 may not equate to the edge of the Diffserv domain. 403 In most commonly-deployed WLAN models, the wireless access point 404 represents not only the edge of the Diffserv domain, but also the 405 edge of the network infrastructure itself. As such, only client 406 endpoint devices (and no infrastructure devices) are downstream from 407 the access points in these deployment models. Note: security 408 considerations and recommendations for hardening such Wifi-at-the- 409 edge deployment models are detailed in Section 8. 411 Alternatively, in other deployment models, such as Wi-Fi backhaul, 412 wireless mesh infrastructures, wireless AP-to-AP deployments, or in 413 cases where a Wi-Fi link connects to a device providing service via 414 another technology (e.g. Wi-Fi to Bluetooth or Zigbee router), the 415 wireless access point extends the network infrastructure and thus, 416 typically, the Diffserv domain. In such deployments, both client 417 devices and infrastructure devices may be expected downstream from 418 the access points. 420 Thus the QoS treatment of packets at the access point will depend on 421 the position of the AP in the network infrastructure and on the WLAN 422 deployment model. 424 However, regardless of the access point being at the Diffserv 425 boundary or not, Diffserv to [IEEE.802.11-2016] (and vice-versa) 426 marking-specific incompatibilities exist that must be reconciled, as 427 will be discussed next. 429 2.2. Default DSCP-to-UP Mappings and Conflicts 431 While no explicit guidance is offered in mapping (6-Bit) Layer 3 DSCP 432 values to (3-Bit) Layer 2 markings (such as IEEE 802.1D, 802.1p or 433 802.11e), a common practice in the networking industry is to map 434 these by what we will refer to as 'Default DSCP-to-UP Mapping' (for 435 lack of a better term), wherein the 3 Most Significant Bits (MSB) of 436 the DSCP are used as the corresponding L2 markings. 438 Note: There are mappings provided in [IEEE.802.11-2016] Annex V 439 Tables V-1 and V2, but it bears mentioning that these mappings are 440 provided as examples (as opposed to explicit recommendations). 441 Furthermore, some of these mappings do not align with the intent and 442 recommendations expressed in [RFC4594], as will be discussed in this 443 and the following section (Section 2.3). 445 However, when this default DSCP-to-UP mapping method is applied to 446 packets marked per [RFC4594] recommendations and destined to 802.11 447 WLAN clients, it will yield a number of inconsistent QoS mappings, 448 specifically: 450 o Voice (EF-101110) will be mapped to UP 5 (101), and treated in the 451 Video Access Category (AC_VI), rather than the Voice Access 452 Category (AC_VO), for which it is intended 454 o Multimedia Streaming (AF3-011xx0) will be mapped to UP3 (011) and 455 treated in the Best Effort Access Category (AC_BE), rather than 456 the Video Access Category (AC_VI), for which it is intended 458 o OAM traffic (CS2-010000) will be mapped to UP 2 (010) and treated 459 in the Background Access Category (AC_BK), which is not the intent 460 expressed in [RFC4594] for this service class 462 It should also be noted that while [IEEE.802.11-2016] defines an 463 intended use for each access category through the AC naming 464 convention (for example, UP 6 and UP 7 belong to AC_VO, the Voice 465 Access Category), [IEEE.802.11-2016] does not: 467 o define how upper layer markings (such as DSCP) should map to UPs 468 (and hence to ACs) 470 o define how UPs should translate to other medium Layer 2 QoS 471 markings 473 o strictly restrict each access category to applications reflected 474 in the AC name 476 2.3. Default UP-to-DSCP Mappings and Conflicts 478 In the opposite direction of flow (the upstream direction, that is, 479 from wireless-to-wired), many APs use what we will refer to as 480 'Default UP-to-DSCP Mapping' (for lack of a better term), wherein 481 DSCP values are derived from UP values by multiplying the UP values 482 by 8 (i.e. shifting the 3 UP bits to the left and adding three 483 additional zeros to generate a DSCP value). This derived DSCP value 484 is then used for QoS treatment between the wireless access point and 485 the nearest classification and marking policy enforcement point 486 (which may be the centralized wireless LAN controller, relatively 487 deep within the network). Alternatively, in the case where there is 488 no other classification and marking policy enforcement point, then 489 this derived DSCP value will be used on the remainder of the Internet 490 path. 492 It goes without saying that when 6 bits of marking granularity are 493 derived from 3, then information is lost in translation. Servicing 494 differentiation cannot be made for 12 classes of traffic (as 495 recommended in [RFC4594]), but for only 8 (with one of these classes 496 being reserved for future use (i.e. UP 7 which maps to DSCP CS7). 498 Such default upstream mapping can also yield several inconsistencies 499 with [RFC4594], including: 501 o Mapping UP 6 ([RFC4594] Voice) to CS6, which [RFC4594] recommends 502 for Network Control 504 o Mapping UP 4 ([RFC4594] Multimedia Conferencing and/or Real-Time 505 Interactive) to CS4, thus losing the ability to differentiate 506 between these two distinct service classes, as recommended in 507 [RFC4594] Sections 4.3 and 4.4 509 o Mapping UP 3 ([RFC4594] Multimedia Streaming and/or Broadcast 510 Video) to CS3, thus losing the ability to differentiate between 511 these two distinct service classes, as recommended in [RFC4594] 512 Sections 4.5 and 4.6 514 o Mapping UP 2 ([RFC4594] Low-Latency Data and/or OAM) to CS2, thus 515 losing the ability to differentiate between these two distinct 516 service classes, as recommended in [RFC4594] Sections 4.7 and 3.3, 517 and possibly overwhelming the queues provisioned for OAM (which is 518 typically lower in capacity [being network control traffic], as 519 compared to Low-Latency Data queues [being user traffic]) 521 o Mapping UP 1 ([RFC4594] High-Throughput Data and/or Low-Priority 522 Data) to CS1, thus losing the ability to differentiate between 523 these two distinct service classes, as recommended in [RFC4594] 524 Sections 4.8 and 4.10, and causing legitimate business-relevant 525 High-Throughput Data to receive a [RFC3662] Lower Effort PDB, for 526 which it is not intended 528 The following sections address these limitations and concerns in 529 order to reconcile [RFC4594] and [IEEE.802.11-2016]. First 530 downstream (wired-to-wireless) DSCP-to-UP mappings will be aligned 531 and then upstream (wireless-to-wired) models will be addressed. 533 3. Wireless Device Marking and Mapping Capability Recommendations 535 This document assumes and RECOMMENDS that all wireless access points 536 (as the bridges between wired-and-wireless networks) support the 537 ability to: 539 o mark DSCP, per Diffserv standards 541 o mark UP, per the [IEEE.802.11-2016] standard 543 o support fully-configurable mappings between DSCP and UP 545 o trust DSCP markings set by wireless endpoint devices 547 This document further assumes and RECOMMENDS that all wireless 548 endpoint devices support the ability to: 550 o mark DSCP, per Diffserv standards 552 o mark UP, per the [IEEE.802.11-2016] standard 554 o support fully-configurable mappings between DSCP (set by 555 applications in software) and UP (set by the operating system and/ 556 or wireless network interface hardware drivers) 558 Having made the assumptions and recommendations above, it bears 559 mentioning while the mappings presented in this document are 560 RECOMMENDED to replace the current common default practices (as 561 discussed in Section 2.2 and Section 2.3), these mapping 562 recommendations are not expected to fit every last deployment model, 563 and as such MAY be overridden by network administrators, as needed. 565 4. DSCP-to-UP Mapping Recommendations 567 The following section specifies downstream (wired-to-wireless) 568 mappings between [RFC4594] Configuration Guidelines for Diffserv 569 Service Classes and [IEEE.802.11-2016]. As such, this section draws 570 heavily from [RFC4594], including service class definitions and 571 recommendations. 573 This section assumes [IEEE.802.11-2016] wireless access points and/or 574 WLAN controllers that support customizable, non-default DSCP-to-UP 575 mapping schemes. 577 This section also assumes that [IEEE.802.11-2016] access points and 578 endpoint devices differentiate UP markings with corresponding queuing 579 and dequeuing treatments. To illustrate, [IEEE.802.11-2016] displays 580 a reference implementation model in Figure 10-24 which depicts four 581 transmit queues, one per access category. In practical 582 implementations, however, it is common for WLAN network equipment 583 vendors to implement dedicated transmit queues on a per-UP (versus a 584 per access category) basis, which are then dequeued into their 585 associated access category in a preferred (or even in a strict 586 priority manner). For example, it is common for vendors to dequeue 587 UP 5 ahead of UP 4 to the hardware performing the EDCA function 588 (EDCAF) for the Video Access Category (AC_VI). As such, Signaling 589 traffic (marked UP 5, per the recommendations made in Section 4.2.2) 590 may benefit from such a treatment versus other video flows in the 591 same access category which are marked to UP 4 (in addition to a 592 preferred treatment over flows in the Best Effort and Background 593 access categories). 595 4.1. Network Control Traffic 597 Network control traffic is defined as packet flows that are essential 598 for stable operation of the administered network [RFC4594] Section 3. 599 Network control traffic is different from user application control 600 (signaling) that may be generated by some applications or services. 601 Network control traffic MAY be split into two service classes: 603 o Network Control, and 605 o Operations Administration and Management (OAM) 607 4.1.1. Network Control Protocols 609 The Network Control service class is used for transmitting packets 610 between network devices (e.g. routers) that require control (routing) 611 information to be exchanged between nodes within the administrative 612 domain, as well as across a peering point between different 613 administrative domains. 615 The RECOMMENDED DSCP marking for Network Control is CS6, per 616 [RFC4594] Section 3.2; additionally, CS7 DSCP value SHOULD be 617 reserved for future use, potentially for future routing or control 618 protocols, again, per [RFC4594] Section 3.2. 620 By default, packets marked DSCP CS7 will be mapped to UP 7 and 621 serviced within the Voice Access Category (AC_VO). This represents 622 the RECOMMENDED mapping for CS7, that is, packets marked to CS7 DSCP 623 are RECOMMENDED to be mapped to UP 7. 625 However, by default, packets marked DSCP CS6 will be mapped to UP 6 626 and serviced within the Voice Access Category (AC_VO); such mapping 627 and servicing is a contradiction to the intent expressed in [RFC 628 4594] section 3.2. As such, it is RECOMMENDED to map Network Control 629 traffic marked CS6 to UP 7 (per [IEEE.802.11-2016] Section 10.2.4.2, 630 Table 10-1), thereby admitting it to the Voice Access Category 631 (AC_VO), albeit with a marking distinguishing it from (data-plane) 632 voice traffic. 634 It should be noted that encapsulated routing protocols for 635 encapsulated or overlay networks (e.g., VPN, NVO3) are not network 636 control traffic for any physical network at the AP, and hence SHOULD 637 NOT be marked with CS6 in the first place. 639 Addtionally, and as previously noted, the Security Considerations 640 section (Section 8) contains additional recommendations for hardening 641 Wifi-at-the-edge deployment models, where, for example, network 642 control protocols are not expected to be sent nor recevied between 643 APs and downstream endpoint client devices. 645 4.1.2. Operations Administration Management (OAM) 647 The OAM (Operations, Administration, and Management) service class is 648 RECOMMENDED for OAM&P (Operations, Administration, and Management and 649 Provisioning). The RECOMMENDED DSCP marking for OAM is CS2, per 650 [RFC4594] Section 3.3. 652 By default, packets marked DSCP CS2 will be mapped to UP 2 and 653 serviced with the Background Access Category (AC_BK). Such servicing 654 is a contradiction to the intent expressed in [RFC4594] Section 3.3. 655 As such, it is RECOMMENDED that a non-default mapping be applied to 656 OAM traffic, such that CS2 DSCP is mapped to UP 0, thereby admitting 657 it to the Best Effort Access Category (AC_BE). 659 4.2. User Traffic 661 User traffic is defined as packet flows between different users or 662 subscribers. It is the traffic that is sent to or from end-terminals 663 and that supports a very wide variety of applications and services 664 [RFC4594] Section 4. 666 Network administrators can categorize their applications according to 667 the type of behavior that they require and MAY choose to support all 668 or a subset of the defined service classes. 670 4.2.1. Telephony 672 The Telephony service class is RECOMMENDED for applications that 673 require real-time, very low delay, very low jitter, and very low 674 packet loss for relatively constant-rate traffic sources (inelastic 675 traffic sources). This service class SHOULD be used for IP telephony 676 service. The fundamental service offered to traffic in the Telephony 677 service class is minimum jitter, delay, and packet loss service up to 678 a specified upper bound. The RECOMMENDED DSCP marking for Telephony 679 is EF ([RFC4594] Section 4.1). 681 Traffic marked to DSCP EF will map by default to UP 5, and thus to 682 the Video Access Category (AC_VI), rather than to the Voice Access 683 Category (AC_VO), for which it is intended. Therefore, a non-default 684 DSCP-to-UP mapping is RECOMMENDED, such that EF DSCP is mapped to UP 685 6, thereby admitting it into the Voice Access Category (AC_VO). 687 Similarly, the [RFC5865] VOICE-ADMIT DSCP (44/101100) is RECOMMENDED 688 to be mapped to UP 6, thereby admitting it also into the Voice Access 689 Category (AC_VO). 691 4.2.2. Signaling 693 The Signaling service class is RECOMMENDED for delay-sensitive 694 client-server (e.g. traditional telephony) and peer-to-peer 695 application signaling. Telephony signaling includes signaling 696 between IP phone and soft-switch, soft-client and soft-switch, and 697 media gateway and soft-switch as well as peer-to-peer using various 698 protocols. This service class is intended to be used for control of 699 sessions and applications. The RECOMMENDED DSCP marking for 700 Signaling is CS5 ([RFC4594] Section 4.2). 702 While Signaling is RECOMMENDED to receive a superior level of service 703 relative to the default class (i.e. AC_BE), it does not require the 704 highest level of service (i.e. AC_VO). This leaves only the Video 705 Access Category (AC_VI), which it will map to by default. Therefore 706 it is RECOMMENDED to map Signaling traffic marked CS5 DSCP to UP 5, 707 thereby admitting it to the Video Access Category (AC_VI). 709 Note: Signaling traffic is not control plane traffic from the 710 perspective of the network (but rather is data plane traffic); as 711 such, it does not merit provisioning in the Network Control service 712 class (marked CS6 and mapped to UP 6). However, Signaling traffic is 713 control-plane traffic from the perspective of the voice/video 714 telephony overlay-infrastructure. As such, Signaling should be 715 treated with preferential servicing vs. other data plane flows. One 716 way this may be achieved in certain WLAN deployments is by mapping 717 Signaling traffic marked CS5 to UP 5 (as recommended above and 718 following the EDCAF treatment logic described in Section 4. 720 4.2.3. Multimedia Conferencing 722 The Multimedia Conferencing service class is RECOMMENDED for 723 applications that require real-time service for rate-adaptive 724 traffic. The RECOMMENDED DSCP markings for Multimedia Conferencing 725 are AF41, AF42 and AF43 ([RFC4594] Section 4.3). 727 The primary media type typically carried within the Multimedia 728 Conferencing service class is video; as such, it is RECOMMENDED to 729 map this class into the Video Access Category (which it does by 730 default). Specifically, it is RECOMMENDED to map AF41, AF42 and AF43 731 to UP 4, thereby admitting Multimedia Conferencing into the Video 732 Access Category (AC_VI). 734 4.2.4. Real-Time Interactive 736 The Real-Time Interactive service class is RECOMMENDED for 737 applications that require low loss and jitter and very low delay for 738 variable rate inelastic traffic sources. Such applications may 739 include inelastic video-conferencing applications, but may also 740 include gaming applications (as pointed out in [RFC4594] Sections 2.1 741 through 2.3, and Section 4.4). The RECOMMENDED DSCP marking for 742 Real-Time Interactive traffic is CS4 ([RFC4594] Section 4.4). 744 The primary media type typically carried within the Real-Time 745 Interactive service class is video; as such, it is RECOMMENDED to map 746 this class into the Video Access Category (which it does by default). 747 Specifically, it is RECOMMENDED to map CS4 to UP 4, thereby admitting 748 Real-Time Interactive traffic into the Video Access Category (AC_VI). 750 4.2.5. Multimedia-Streaming 752 The Multimedia Streaming service class is RECOMMENDED for 753 applications that require near-real-time packet forwarding of 754 variable rate elastic traffic sources. Typically these flows are 755 unidirectional. The RECOMMENDED DSCP markings for Multimedia 756 Streaming are AF31, AF32 and AF33 ([RFC4594] Section 4.5). 758 The primary media type typically carried within the Multimedia 759 Streaming service class is video; as such, it is RECOMMENDED to map 760 this class into the Video Access Category. Specifically, it is 761 RECOMMENDED to map AF31, AF32 and AF33 to UP 4, thereby admitting 762 Multimedia Streaming into the Video Access Category (AC_VI). 764 4.2.6. Broadcast Video 766 The Broadcast Video service class is RECOMMENDED for applications 767 that require near-real-time packet forwarding with very low packet 768 loss of constant rate and variable rate inelastic traffic sources. 769 Typically these flows are unidirectional. The RECOMMENDED DSCP 770 marking for Broadcast Video is CS3 ([RFC4594] Section 4.6). 772 As directly implied by the name, the primary media type typically 773 carried within the Broadcast Video service class is video; as such, 774 it is RECOMMENDED to map this class into the Video Access Category. 775 Specifically, it is RECOMMENDED to map CS4 to UP 4, thereby admitting 776 Broadcast Video into the Video Access Category (AC_VI). 778 4.2.7. Low-Latency Data 780 The Low-Latency Data service class is RECOMMENDED for elastic and 781 time-sensitive data applications, often of a transactional nature, 782 where a user is waiting for a response via the network in order to 783 continue with a task at hand. As such, these flows are considered 784 foreground traffic, with delays or drops to such traffic directly 785 impacting user-productivity. The RECOMMENDED DSCP markings for Low- 786 Latency Data are AF21, AF22 and AF23 ([RFC4594] Section 4.7). 788 In line with the assumption made in Section 4, mapping Low-Latency 789 Data to UP 3 may allow such to receive a superior level of service 790 via transmit queues servicing the EDCAF hardware for the Best Effort 791 Access Category (AC_BE). Therefore it is RECOMMENDED to map Low- 792 Latency Data traffic marked AF2x DSCP to UP 3, thereby admitting it 793 to the Best Effort Access Category (AC_BE). 795 4.2.8. High-Throughput Data 797 The High-Throughput Data service class is RECOMMENDED for elastic 798 applications that require timely packet forwarding of variable rate 799 traffic sources and, more specifically, is configured to provide 800 efficient, yet constrained (when necessary) throughput for TCP 801 longer-lived flows. These flows are typically non-user-interactive. 802 Per [RFC4594]-Section 4.8, it can be assumed that this class will 803 consume any available bandwidth and that packets traversing congested 804 links may experience higher queuing delays or packet loss. It is 805 also assumed that this traffic is elastic and responds dynamically to 806 packet loss. The RECOMMENDED DSCP markings for High-Throughput Data 807 are AF11, AF12 and AF13 ([RFC4594] Section 4.8). 809 Unfortunately, there really is no corresponding fit for the High- 810 Throughput Data service class within the constrained 4 Access 811 Category [IEEE.802.11-2016] model. If the High-Throughput Data 812 service class is assigned to the Best Effort Access Category (AC_BE), 813 then it would contend with Low-Latency Data (while [RFC4594] 814 recommends a distinction in servicing between these service classes) 815 as well as with the default service class; alternatively, if it is 816 assigned to the Background Access Category (AC_BK), then it would 817 receive a less-then-best-effort service and contend with Low-Priority 818 Data (as discussed in Section 4.2.10). 820 As such, since there is no directly corresponding fit for the High- 821 Throughout Data service class within the [IEEE.802.11-2016] model, it 822 is generally RECOMMENDED to map High-Throughput Data to UP 0, thereby 823 admitting it to the Best Effort Access Category (AC_BE). 825 4.2.9. Standard Service Class 827 The Standard service class is RECOMMENDED for traffic that has not 828 been classified into one of the other supported forwarding service 829 classes in the Diffserv network domain. This service class provides 830 the Internet's "best-effort" forwarding behavior. The RECOMMENDED 831 DSCP marking for the Standard Service Class is DF. ([RFC4594] 832 Section 4.9) 834 The Standard Service Class loosely corresponds to the 835 [IEEE.802.11-2016] Best Effort Access Category (AC_BK) and therefore 836 it is RECOMMENDED to map Standard Service Class traffic marked DF 837 DSCP to UP 0, thereby admitting it to the Best Effort Access Category 838 (AC_BE). 840 4.2.10. Low-Priority Data 842 The Low-Priority Data service class serves applications that the user 843 is willing to accept without service assurances. This service class 844 is specified in [RFC3662] and [I-D.ietf-tsvwg-le-phb]. 846 The Low-Priority Data service class loosely corresponds to the 847 [IEEE.802.11-2016] Background Access Category (AC_BK) and therefore 848 it is RECOMMENDED to map Low-Priority Data traffic marked CS1 DSCP to 849 UP 1, thereby admitting it to the Background Access Category (AC_BK). 851 4.3. DSCP-to-UP Mapping Recommendations Summary 853 Figure 1 summarizes the [RFC4594] DSCP marking recommendations mapped 854 to [IEEE.802.11-2016] UP and access categories applied in the 855 downstream direction (i.e. from wired-to-wireless networks). 857 +------------------------------------------------------------------+ 858 | IETF Diffserv | PHB |Reference| IEEE 802.11 | 859 | Service Class | | RFC |User Priority| Access Category | 860 |===============+======+=========+=============+====================| 861 | | | | 7 | AC_VO (Voice) | 862 |Network Control| CS7 | RFC2474 | OR | 863 |(reserved for | | | 0 | AC_BE (Best Effort)| 864 | future use) | | |See Security Considerations-Sec.8)| 865 +---------------+------+---------+-------------+--------------------+ 866 | | | | 7 | AC_VO (Voice) | 867 |Network Control| CS6 | RFC2474 | OR | 868 | | | | 0 | AC_BE (Best Effort)| 869 | | | |See Security Considerations-Sec.8)| 870 +---------------+------+---------+-------------+--------------------+ 871 | Telephony | EF | RFC3246 | 6 | AC_VO (Voice) | 872 +---------------+------+---------+-------------+--------------------+ 873 | VOICE-ADMIT |VOICE-| RFC5865 | 6 | AC_VO (Voice) | 874 | |ADMIT | | | | 875 +---------------+------+---------+-------------+--------------------+ 876 | Signaling | CS5 | RFC2474 | 5 | AC_VI (Video) | 877 +---------------+------+---------+-------------+--------------------+ 878 | Multimedia | AF41 | | | | 879 | Conferencing | AF42 | RFC2597 | 4 | AC_VI (Video) | 880 | | AF43 | | | | 881 +---------------+------+---------+-------------+--------------------+ 882 | Real-Time | CS4 | RFC2474 | 4 | AC_VI (Video) | 883 | Interactive | | | | | 884 +---------------+------+---------+-------------+--------------------+ 885 | Multimedia | AF31 | | | | 886 | Streaming | AF32 | RFC2597 | 4 | AC_VI (Video) | 887 | | AF33 | | | | 888 +---------------+------+---------+-------------+--------------------+ 889 |Broadcast Video| CS3 | RFC2474 | 4 | AC_VI (Video) | 890 +---------------+------+---------+-------------+--------------------+ 891 | Low- | AF21 | | | | 892 | Latency | AF22 | RFC2597 | 3 | AC_BE (Best Effort)| 893 | Data | AF23 | | | | 894 +---------------+------+---------+-------------+--------------------+ 895 | OAM | CS2 | RFC2474 | 0 | AC_BE (Best Effort)| 896 +---------------+------+---------+-------------+--------------------+ 897 | High- | AF11 | | | | 898 | Throughput | AF12 | RFC2597 | 0 | AC_BE (Best Effort)| 899 | Data | AF13 | | | | 900 +---------------+------+---------+-------------+--------------------+ 901 | Standard | DF | RFC2474 | 0 | AC_BE (Best Effort)| 902 +---------------+------+---------+-------------+--------------------+ 903 | Low-Priority | CS1 | RFC3662 | 1 | AC_BK (Background) | 904 | Data | | | | | 905 +-------------------------------------------------------------------+ 907 Note: All unusued codepoints are recommended to be mapped to UP 0 908 (See Security Considerations Section - Section 8) 910 Figure 1: Summary of Downstream DSCP to IEEE 802.11 UP and AC Mapping 911 Recommendations 913 5. Upstream Mapping and Marking Recommendations 915 In the upstream direction (i.e. wireless-to-wired), there are three 916 types of mapping that MAY be implemented: 918 o DSCP-to-UP mapping within the wireless client operating system 920 o UP-to-DSCP mapping at the wireless access point 922 o DSCP-Trust at the wireless access point (effectively a 1:1 DSCP- 923 to-DSCP mapping) 925 Alternatively, the network administrator MAY choose to use the 926 wireless-to-wired edge as a Diffserv boundary and explicitly set (or 927 reset) DSCP markings according to administrative policy, thus making 928 the wireless edge a Diffserv policy enforcement point. 930 Each of these options will now be considered. 932 5.1. Upstream DSCP-to-UP Mapping within the Wireless Client Operating 933 System 935 Some operating systems on wireless client devices utilize a similar 936 default DSCP-to-UP mapping scheme as described in Section 2.2. As 937 such, this can lead to the same conflicts as described in that 938 section, but in the upstream direction. 940 Therefore, to improve on these default mappings, and to achieve 941 parity and consistency with downstream QoS, it is RECOMMENDED that 942 wireless client operating systems utilize instead the same DSCP-to-UP 943 mapping recommendations presented in Section 4, with the explicit 944 RECOMMENDATION that packets requesting a marking of CS6 or CS7 DSCP 945 SHOULD be mapped to UP 0 (and not to UP 7). Furthermore, in such 946 cases the wireless client operating system SHOULD remark such packets 947 to DSCP 0. This is because CS6 and CS7 DSCP, as well as UP 7 948 markings, are intended for network control protocols and these SHOULD 949 NOT be sourced from wireless client endpoint devices. This 950 recommendation is detailed in the Security Considerations section 951 (Section 8). 953 5.2. Upstream UP-to-DSCP Mapping at the Wireless Access Point 955 UP-to-DSCP mapping generates a DSCP value for the IP packet (either 956 an unencapsulated IP packet or an IP packet encapsulated within a 957 tunneling protocol such as CAPWAP - and destined towards a wireless 958 LAN controller for decapsulation and forwarding) from the Layer 2 959 [IEEE.802.11-2016] UP marking. This is typically done in the manner 960 described in Section 2.3. 962 It should be noted that any explicit remarking policy to be performed 963 on such a packet only takes place at the nearest classification and 964 marking policy enforcement point, which may be: 966 o At the wireless access point 968 o At the wired network switch port 970 o At the wireless LAN controller 972 As such, UP-to-DSCP mapping allows for wireless L2 markings to affect 973 the QoS treatment of a packet over the wired IP network (that is, 974 until the packet reaches the nearest classification and marking 975 policy enforcement point). 977 It should be further noted that nowhere in the [IEEE.802.11-2016] 978 specifications is there an intent expressed for UP markings to be 979 used to influence QoS treatment over wired IP networks. Furthermore, 980 [RFC2474], [RFC2475] and [RFC8100] all allow for the host to set DSCP 981 markings for end-to-end QoS treatment over IP networks. Therefore, 982 it is NOT RECOMMENDED that wireless access points trust Layer 2 983 [IEEE.802.11-2016] UP markings as set by wireless hosts and 984 subsequently perform a UP-to-DSCP mapping in the upstream direction, 985 but rather, if wireless host markings are to be trusted (as per 986 business requirements, technical constraints and administrative 987 policies), then it is RECOMMENDED to trust the Layer 3 DSCP markings 988 set by these wireless hosts instead, as is discussed in the next 989 section. 991 5.3. Upstream DSCP-Trust at the Wireless Access Point 993 It is generally NOT RECOMMENDED to trust DSCP markings from 994 unauthenticated and unauthorized devices, as these are typically 995 considered untrusted sources. 997 When business requirements and/or technical constraints and/or 998 administrative policies require a trust function at the wireless 999 edge, then it is RECOMMENDED to trust DSCP (over [IEEE.802.11-2016] 1000 UP markings) markings in the upstream direction, for the following 1001 reasons: 1003 o [RFC2474], [RFC2475] and [RFC8100] all allow for hosts to set DSCP 1004 markings to achieve an end-to-end differentiated service 1006 o [IEEE.802.11-2016] does not specify that UP markings are to be 1007 used to affect QoS treatment over wired IP networks 1009 o Most present wireless device operating systems generate UP values 1010 by the same method as described in Section 2.2 (i.e. by using the 1011 3 MSB of the encapsulated 6-bit DSCP); then, at the access point, 1012 these 3-bit markings are converted back into DSCP values, 1013 typically in the default manner described in Section 2.3; as such, 1014 information is lost in the translation from a 6-bit marking to a 1015 3-bit marking (which is then subsequently translated back to a 1016 6-bit marking); trusting the original (encapsulated) DSCP marking 1017 prevents such loss of information 1019 o A practical implementation benefit is also realized by trusting 1020 the DSCP set by wireless client devices, as enabling applications 1021 to mark DSCP is much more prevalent and accessible to programmers 1022 of applications running on wireless device platforms, vis-a-vis 1023 trying to explicitly set UP values, which requires special hooks 1024 into the wireless device operating system and/or hardware device 1025 drivers, many of which do not support such functionality 1027 5.4. Upstream DSCP Marking at the Wireless Access Point 1029 An alternative option to mapping is for the administrator to treat 1030 the wireless edge as the edge of the Diffserv domain and explicitly 1031 set (or reset) DSCP markings in the upstream direction according to 1032 administrative policy. This option is RECOMMENDED over mapping, as 1033 this typically is the most secure solution, as the network 1034 administrator directly enforces the Diffserv policy across the IP 1035 network (versus an application developer and/or the wireless endpoint 1036 device operating system developer, who may be functioning completely 1037 independently of the network administrator). 1039 6. Appendix: IEEE 802.11 QoS Overview 1041 QoS is enabled on wireless networks by means of the Hybrid 1042 Coordination Function (HCF). To give better context to the 1043 enhancements in HCF that enable QoS, it may be helpful to begin with 1044 a review of the original Distributed Coordination Function (DCF). 1046 6.1. Distributed Coordination Function (DCF) 1048 As has been noted, the Wi-Fi medium is a shared medium, with each 1049 station-including the wireless access point-contending for the medium 1050 on equal terms. As such, it shares the same challenge as any other 1051 shared medium in requiring a mechanism to prevent (or avoid) 1052 collisions which can occur when two (or more) stations attempt 1053 simultaneous transmission. 1055 The IEEE Ethernet working group solved this challenge by implementing 1056 a Carrier Sense Multiple Access/Collision Detection (CSMA/CD) 1057 mechanism that could detect collisions over the shared physical cable 1058 (as collisions could be detected as reflected energy pulses over the 1059 physical wire). Once a collision was detected, then a pre-defined 1060 set of rules was invoked that required stations to back off and wait 1061 random periods of time before re-attempting transmission. While 1062 CSMA/CD improved the usage of Ethernet as a shared medium, it should 1063 be noted the ultimate solution to solving Ethernet collisions was the 1064 advance of switching technologies, which treated each Ethernet cable 1065 as a dedicated collision domain. 1067 However, unlike Ethernet (which uses physical cables), collisions 1068 cannot be directly detected over the wireless medium, as RF energy is 1069 radiated over the air and colliding bursts are not necessarily 1070 reflected back to the transmitting stations. Therefore, a different 1071 mechanism is required for this medium. 1073 As such, the IEEE modified the CSMA/CD mechanism to adapt it to 1074 wireless networks to provide Carrier Sense Multiple Access/Collision 1075 Avoidance (CSMA/CA). The original CSMA/CA mechanism used in IEEE 1076 802.11 was the Distributed Coordination Function. DCF is a timer- 1077 based system that leverages three key sets of timers, the slot time, 1078 interframe spaces and contention windows. 1080 6.1.1. Slot Time 1082 The slot time is the basic unit of time measure for both DCF and HCF, 1083 on which all other timers are based. The slot time duration varies 1084 with the different generations of data-rates and performances 1085 described by the [IEEE.802.11-2016] standard. For example, the 1086 [IEEE.802.11-2016] standard specifies the slot time to be 20 us 1087 ([IEEE.802.11-2016] Table 15-5) for legacy implementations (such as 1088 IEEE 802.11b, supporting 1, 2, 5.5 and 11 Mbps data rates), while 1089 newer implementations (including IEEE 802.11g, 802.11a, 802.11n and 1090 802.11ac, supporting data rates from 6.5 Mbps to over 2 Gbps per 1091 spatial stream) define a shorter slot time of 9 us 1092 ([IEEE.802.11-2016], Section 17.4.4, Table 17-21). 1094 6.1.2. Interframe Spaces 1096 The time interval between frames that are transmitted over the air is 1097 called the Interframe Space (IFS). Several IFS are defined in 1098 [IEEE.802.11-2016], with the two most relevant to DCF being the Short 1099 Interframe Space (SIFS) and the DCF Interframe Space (DIFS). 1101 The SIFS is the amount of time in microseconds required for a 1102 wireless interface to process a received RF signal and its associated 1103 [IEEE.802.11-2016] frame and to generate a response frame. Like slot 1104 times, the SIFS can vary according to the performance implementation 1105 of the [IEEE.802.11-2016] standard. The SIFS for IEEE 802.11a, 1106 802.11n and 802.11ac (in 5 GHz) is 16 us ([IEEE.802.11-2016], 1107 Section 17.4.4, Table 17-21). 1109 Additionally, a station must sense the status of the wireless medium 1110 before transmitting. If it finds that the medium is continuously 1111 idle for the duration of a DIFS, then it is permitted to attempt 1112 transmission of a frame (after waiting an additional random backoff 1113 period, as will be discussed in the next section). If the channel is 1114 found busy during the DIFS interval, the station must defer its 1115 transmission until the medium is found idle for the duration of a 1116 DIFS interval. The DIFS is calculated as: 1118 DIFS = SIFS + (2 * Slot time) 1120 However, if all stations waited only a fixed amount of time before 1121 attempting transmission then collisions would be frequent. To offset 1122 this, each station must wait, not only a fixed amount of time (the 1123 DIFS), but also a random amount of time (the random backoff) prior to 1124 transmission. The range of the generated random backoff timer is 1125 bounded by the Contention Window. 1127 6.1.3. Contention Windows 1129 Contention windows bound the range of the generated random backoff 1130 timer that each station must wait (in addition to the DIFS) before 1131 attempting transmission. The initial range is set between 0 and the 1132 Contention Window minimum value (CWmin), inclusive. The CWmin for 1133 DCF (in 5 GHz) is specified as 15 slot times ([IEEE.802.11-2016], 1134 Section 17.4.4, Table 17-21). 1136 However, it is possible that two (or more) stations happen to pick 1137 the exact same random value within this range. If this happens then 1138 a collision may occur. At this point, the stations effectively begin 1139 the process again, waiting a DIFS and generate a new random backoff 1140 value. However, a key difference is that for this subsequent 1141 attempt, the Contention Window approximatively doubles in size (thus 1142 exponentially increasing the range of the random value). This 1143 process repeats as often as necessary if collisions continue to 1144 occur, until the maximum Contention Window size (CWmax) is reached. 1145 The CWmax for DCF is specified as 1023 slot times 1146 ([IEEE.802.11-2016], Section 17.4.4, Table 17-21). 1148 At this point, transmission attempts may still continue (until some 1149 other pre-defined limit is reached), but the Contention Window sizes 1150 are fixed at the CWmax value. 1152 Incidentally it may be observed that a significant amount of jitter 1153 can be introduced by this contention process for wireless 1154 transmission access. For example, the incremental transmission delay 1155 of 1023 slot times (CWmax) using 9 us slot times may be as high as 9 1156 ms of jitter per attempt. And, as previously noted, multiple 1157 attempts can be made at CWmax. 1159 6.2. Hybrid Coordination Function (HCF) 1161 Therefore, as can be seen from the preceding description of DCF, 1162 there is no preferential treatment of one station over another when 1163 contending for the shared wireless media; nor is there any 1164 preferential treatment of one type of traffic over another during the 1165 same contention process. To support the latter requirement, the IEEE 1166 enhanced DCF in 2005 to support QoS, specifying HCF in IEEE 802.11, 1167 which was integrated into the main IEEE 802.11 standard in 2007. 1169 6.2.1. User Priority (UP) 1171 One of the key changes to the [IEEE.802.11-2016] frame format is the 1172 inclusion of a QoS Control field, with 3 bits dedicated for QoS 1173 markings. These bits are referred to the User Priority (UP) bits and 1174 these support eight distinct marking values: 0-7, inclusive. 1176 While such markings allow for frame differentiation, these alone do 1177 not directly affect over-the-air treatment. Rather it is the non- 1178 configurable and standard-specified mapping of UP markings to 1179 [IEEE.802.11-2016] Access Categories (AC) that generate 1180 differentiated treatment over wireless media. 1182 6.2.2. Access Category (AC) 1184 Pairs of UP values are mapped to four defined access categories that 1185 correspondingly specify different treatments of frames over the air. 1186 These access categories (in order of relative priority from the top 1187 down) and their corresponding UP mappings are shown in Figure 2 1188 (adapted from [IEEE.802.11-2016], Section 10.2.4.2, Table 10-1). 1190 +-----------------------------------------+ 1191 | User | Access | Designative | 1192 | Priority | Category | (informative) | 1193 |===========+============+================| 1194 | 7 | AC_VO | Voice | 1195 +-----------+------------+----------------+ 1196 | 6 | AC_VO | Voice | 1197 +-----------+------------+----------------+ 1198 | 5 | AC_VI | Video | 1199 +-----------+------------+----------------+ 1200 | 4 | AC_VI | Video | 1201 +-----------+------------+----------------+ 1202 | 3 | AC_BE | Best Effort | 1203 +-----------+------------+----------------+ 1204 | 0 | AC_BE | Best Effort | 1205 +-----------+------------+----------------+ 1206 | 2 | AC_BK | Background | 1207 +-----------+------------+----------------+ 1208 | 1 | AC_BK | Background | 1209 +-----------------------------------------+ 1211 Figure 2: IEEE 802.11 Access Categories and User Priority Mappings 1213 The manner in which these four access categories achieve 1214 differentiated service over-the-air is primarily by tuning the fixed 1215 and random timers that stations have to wait before sending their 1216 respective types of traffic, as will be discussed next. 1218 6.2.3. Arbitration Inter-Frame Space (AIFS) 1220 As previously mentioned, each station must wait a fixed amount of 1221 time to ensure the medium is idle before attempting transmission. 1222 With DCF, the DIFS is constant for all types of traffic. However, 1223 with [IEEE.802.11-2016] the fixed amount of time that a station has 1224 to wait will depend on the access category and is referred to as an 1225 Arbitration Interframe Space (AIFS). AIFS are defined in slot times 1226 and the AIFS per access category are shown in Figure 3 (adapted from 1227 [IEEE.802.11-2016], Section 9.4.2.29, Table 9-137). 1229 +------------------------------------------+ 1230 | Access | Designative | AIFS | 1231 | Category | (informative) |(slot times)| 1232 |===========+=================+============| 1233 | AC_VO | Voice | 2 | 1234 +-----------+-----------------+------------+ 1235 | AC_VI | Video | 2 | 1236 +-----------+-----------------+------------+ 1237 | AC_BE | Best Effort | 3 | 1238 +-----------+-----------------+------------+ 1239 | AC_BK | Background | 7 | 1240 +-----------+-----------------+------------+ 1242 Figure 3: Arbitration Interframe Spaces by Access Category 1244 6.2.4. Access Category Contention Windows (CW) 1246 Not only is the fixed amount of time that a station has to wait 1247 skewed according to [IEEE.802.11-2016] access category, but so are 1248 the relative sizes of the Contention Windows that bound the random 1249 backoff timers, as shown in Figure 4 (adapted from 1250 [IEEE.802.11-2016], Section 9.4.2.29, Table 9-137). 1252 +-------------------------------------------------------+ 1253 | Access | Designative | CWmin | CWmax | 1254 | Category | (informative) |(slot times)|(slot times)| 1255 |===========+=================+============|============| 1256 | AC_VO | Voice | 3 | 7 | 1257 +-----------+-----------------+------------+------------+ 1258 | AC_VI | Video | 7 | 15 | 1259 +-----------+-----------------+------------+------------+ 1260 | AC_BE | Best Effort | 15 | 1023 | 1261 +-----------+-----------------+------------+------------+ 1262 | AC_BK | Background | 15 | 1023 | 1263 +-----------+-----------------+------------+------------+ 1265 Figure 4: Contention Window Sizes by Access Category 1267 When the fixed and randomly generated timers are added together on a 1268 per access category basis, then traffic assigned to the Voice Access 1269 Category (i.e. traffic marked to UP 6 or 7) will receive a 1270 statistically superior service relative to traffic assigned to the 1271 Video Access Category (i.e. traffic marked UP 5 and 4), which, in 1272 turn, will receive a statistically superior service relative to 1273 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 8.2 1318 2) (up to 21) exceptions from this baseline mapping are RECOMMENDED 1319 to be made in line with Section 4.3, to correspond to the Diffserv 1320 Codepoints that are in use over the IP network. 1322 It is important to note that the QoS Map element is intended to be 1323 transmitted from a wireless access point to a non-AP station. As 1324 such, the model where this element is used is that of a network where 1325 the AP is the edge of the Diffserv domain. Networks where the AP 1326 extends the Diffserv domain by connecting other APs and 1327 infrastructure devices through the IEEE 802.11 medium are not 1328 included in the cases covered by the presence of the QoS Map element, 1329 and therefore are not included in the present recommendation. 1331 7. IANA Considerations 1333 This memo asks the IANA for no new parameters. 1335 8. Security Considerations 1337 The recommendations put forward in this document do not present any 1338 additional security concerns that do not already exist in wired and 1339 wireless devices. In fact, several of the recommendations made in 1340 this document serve to mitigate and protect wired and wireless 1341 networks from potential abuse arising from existing vulnerabilities. 1343 8.1. General QoS Security Recommendations 1345 It may be possible for a wired or wireless device (which could be 1346 either a host or a network device) to mark packets (or map packet 1347 markings) in a manner that interferes with or degrades existing QoS 1348 policies. Such marking or mapping may be done intentionally or 1349 unintentionally by developers and/or users and/or administrators of 1350 such devices. 1352 To illustrate: A gaming application designed to run on a smart-phone 1353 or tablet may request that all its packets be marked DSCP EF and/or 1354 UP 6. However, if the traffic from such an application is trusted 1355 over a business network, then this could interfere with QoS policies 1356 intended to provide priority services for business voice 1357 applications. 1359 To mitigate such scenarios it is RECOMMENDED to implement general QoS 1360 security measures, including: 1362 Setting a trust boundary reflective of business objectives and 1363 policy, such that traffic from authorized users and/or 1364 applications and/or endpoints will be accepted by the network; 1365 otherwise packet markings will be "bleached" (i.e. remarked to 1366 DSCP DF and/or UP 0). Additionally, Section 5.3 made it clear 1367 that it is generally NOT RECOMMENDED to trust DSCP markings from 1368 unauthorized and/or unauthenticated devices, as these are 1369 typically considered untrusted sources. This is especially 1370 relevant for IoT deployments, where tens-of-billions of devices 1371 are being connected to IP networks, many of which have little or 1372 no security. 1374 Policing EF marked packet flows, as detailed in [RFC2474] 1375 Section 7 and [RFC3246] Section 3. 1377 In addition to these general QoS security recommendations, WLAN- 1378 specific QoS security recommendations can serve to further mitigate 1379 attacks and potential network abuse. 1381 8.2. WLAN QoS Security Recommendations 1383 The wireless LAN presents a unique DoS attack vector, as endpoint 1384 devices contend for the shared media on a completely egalitarian 1385 basis with the network (as represented by the AP). This means that 1386 any wireless client could potentially monopolize the air by sending 1387 packets marked to preferred UP values (i.e. UP values 4-7) in the 1388 upstream direction. Similarly, airtime could be monopolized if 1389 excessive amounts of downstream traffic were marked/mapped to these 1390 same preferred UP values. As such, the ability to mark/map to these 1391 preferred UP values (of UP 4-7) should be controlled. 1393 If such marking/mapping were not controlled, then, for example, a 1394 malicious user could cause WLAN DoS by flooding traffic marked CS7 1395 DSCP downstream. This codepoint would map by default to UP 7 and 1396 would be assigned to the Voice Access Category (AC_VO). Such a flood 1397 could cause Denial-of-Service to not only wireless voice 1398 applications, but also to all other traffic classes. 1400 Therefore, to mitigate such an attack, it is RECOMMENDED that all 1401 packets marked to Diffserv Codepoints not in use over the wireless 1402 network be mapped to UP 0. 1404 Such a policy of mapping unused codepoints to UP 0 would also prevent 1405 an attack where non-standard codepoints were used to cause WLAN DoS. 1406 Consider the case where codepoints are mapped to UP values using a 1407 range function (e.g. DSCP values 48-55 all map to UP 6), then an 1408 attacker could flood packets marked, for example to DSCP 49, in 1409 either the upstream or downstream direction over the WLAN, causing 1410 DoS to all other traffic classes in the process. 1412 It should be strongly noted that in the wireless deployment model 1413 where the AP represents not only the edge of the Diffserv domain, but 1414 also the edge of the network infrastructure itselt, then CS6 and CS7 1415 also fall into the category of codepoints that are not in use over 1416 the wireless LAN. This is because only wireless endpoint client 1417 devices are downstream from the AP in this model, and as such, these 1418 devices do not (legitimately) participate in network control protocol 1419 exchanges. As such, it is RECOMMENDED that CS6 and CS7 DSCP be 1420 mapped to UP 0 in these Wifi-at-the-edge deployment models. 1421 Otherwise, it would be easy for a malicious developer, or even an 1422 inadvertently poorly-programmed IoT device, to cause WLAN DoS and 1423 even wired IP network instability by flooding traffic marked CS6 1424 DSCP, which would (by default) be mapped to UP 6, causing all other 1425 traffic classes on the WLAN to be starved, as well hijacking queues 1426 on the wired IP network that are intended for the servicing of 1427 routing protocols. To this point, it was also recommended in 1428 Section 5.1 that packets requesting a marking of CS6 or CS7 DSCP 1429 SHOULD be remarked to DSCP 0 and mapped to UP 0 by the wireless 1430 client operating system. 1432 Finally, it should be noted that the recommendations put forward in 1433 this document are not intended to address all attack vectors 1434 leveraging QoS marking abuse. Mechanisms that may further help 1435 mitigate security risks include strong device- and/or user- 1436 authentication, access-control, rate limiting, control-plane 1437 policing, encryption and other techniques; however, the 1438 implementation recommendations for such mechanisms are beyond the 1439 scope of this document to address in detail. Suffice it to say that 1440 the security of the devices and networks implementing QoS, including 1441 QoS mapping between wired and wireless networks, SHOULD be considered 1442 in actual deployments. 1444 9. Acknowledgements 1446 The authors wish to thank David Black, Gorry Fairhurst, Ruediger 1447 Geib, Vincent Roca, Brian Carpenter, David Blake, Cullen Jennings, 1448 David Benham and the TSVWG. 1450 The authors also acknowledge a great many inputs, notably from David 1451 Kloper, Mark Montanez, Glen Lavers, Michael Fingleton, Sarav 1452 Radhakrishnan, Karthik Dakshinamoorthy, Simone Arena, Ranga Marathe, 1453 Ramachandra Murthy and many others. 1455 10. References 1457 10.1. Normative References 1459 [IEEE.802.11-2016] 1460 "Information technology - Telecommunications and 1461 information exchange between systems - Local and 1462 metropolitan area networks - Specific requirements - Part 1463 11: Wireless LAN Medium Access Control (MAC) and Physical 1464 Layer (PHY) specifications", IEEE Standard 802.11, 2016, 1465 . 1468 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1469 Requirement Levels", BCP 14, RFC 2119, 1470 DOI 10.17487/RFC2119, March 1997, 1471 . 1473 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1474 "Definition of the Differentiated Services Field (DS 1475 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1476 DOI 10.17487/RFC2474, December 1998, 1477 . 1479 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1480 and W. Weiss, "An Architecture for Differentiated 1481 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 1482 . 1484 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 1485 "Assured Forwarding PHB Group", RFC 2597, 1486 DOI 10.17487/RFC2597, June 1999, 1487 . 1489 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 1490 J., Courtney, W., Davari, S., Firoiu, V., and D. 1491 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 1492 Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002, 1493 . 1495 [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort 1496 Per-Domain Behavior (PDB) for Differentiated Services", 1497 RFC 3662, DOI 10.17487/RFC3662, December 2003, 1498 . 1500 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 1501 Guidelines for DiffServ Service Classes", RFC 4594, 1502 DOI 10.17487/RFC4594, August 2006, 1503 . 1505 [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of 1506 Diffserv Service Classes", RFC 5127, DOI 10.17487/RFC5127, 1507 February 2008, . 1509 [RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated 1510 Services Code Point (DSCP) for Capacity-Admitted Traffic", 1511 RFC 5865, DOI 10.17487/RFC5865, May 2010, 1512 . 1514 [RFC8100] Geib, R., Ed. and D. Black, "Diffserv-Interconnection 1515 Classes and Practice", RFC 8100, DOI 10.17487/RFC8100, 1516 March 2017, . 1518 10.2. Informative References 1520 [I-D.ietf-tsvwg-le-phb] 1521 Bless, R., "A Lower Effort Per-Hop Behavior (LE PHB)", 1522 draft-ietf-tsvwg-le-phb-02 (work in progress), June 2017. 1524 [IEEE.802-11u.2011] 1525 "Information technology - Telecommunications and 1526 information exchange between systems - Local and 1527 metropolitan area networks - Specific requirements - Part 1528 11: Wireless LAN Medium Access Control (MAC) and Physical 1529 Layer (PHY) specifications", IEEE Standard 802.11, 2011, 1530 . 1533 [RFC7561] Kaippallimalil, J., Pazhyannur, R., and P. Yegani, 1534 "Mapping Quality of Service (QoS) Procedures of Proxy 1535 Mobile IPv6 (PMIPv6) and WLAN", RFC 7561, 1536 DOI 10.17487/RFC7561, June 2015, 1537 . 1539 Appendix A. Change Log 1541 Initial Version: July 2015 1543 Authors' Addresses 1545 Tim Szigeti 1546 Cisco Systems 1547 Vancouver, British Columbia V6K 3L4 1548 Canada 1550 Email: szigeti@cisco.com 1551 Jerome Henry 1552 Cisco Systems 1553 Research Triangle Park, North Carolina 27709 1554 USA 1556 Email: jerhenry@cisco.com 1558 Fred Baker 1559 Santa Barbara, California 93117 1560 USA 1562 Email: FredBaker.IETF@gmail.com