idnits 2.17.1 draft-szigeti-tsvwg-ieee-802-11e-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (July 22, 2015) is 3200 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-02 -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 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 F. Baker 4 Intended status: Informational Cisco Systems 5 Expires: January 23, 2016 July 22, 2015 7 Guidelines for DiffServ to IEEE 802.11 Mapping 8 draft-szigeti-tsvwg-ieee-802-11e-01 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 January 23, 2016. 43 Copyright Notice 45 Copyright (c) 2015 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. Applicability Statement . . . . . . . . . . . . . . . . . 4 63 1.3. Document Organization . . . . . . . . . . . . . . . . . . 4 64 1.4. Requirements Language . . . . . . . . . . . . . . . . . . 4 65 2. IEEE 802.11e QoS Overview . . . . . . . . . . . . . . . . . . 4 66 2.1. Distributed Coordination Function (DCF) . . . . . . . . . 5 67 2.1.1. Slot Time . . . . . . . . . . . . . . . . . . . . . . 5 68 2.1.2. Interframe Spaces . . . . . . . . . . . . . . . . . . 6 69 2.1.3. Contention Windows . . . . . . . . . . . . . . . . . 6 70 2.2. Hybrid Coordination Function (HCF) . . . . . . . . . . . 7 71 2.2.1. User Priority (UP) . . . . . . . . . . . . . . . . . 7 72 2.2.2. Access Category (AC) . . . . . . . . . . . . . . . . 7 73 2.2.3. Arbitration Inter-Frame Space (AIFS) . . . . . . . . 8 74 2.2.4. Access Category Contention Windows (CW) . . . . . . . 9 75 3. Comparison and Default Interoperation of DiffServ and IEEE 76 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 3.1. Default Downstream DSCP-to-UP Mappings and Conflicts . . 10 78 3.2. Default Upstream UP-to-DSCP Mappings and Conflicts . . . 11 79 4. Downstream DSCP-to-UP Mapping Recommendations . . . . . . . . 12 80 4.1. Network Control Traffic . . . . . . . . . . . . . . . . . 12 81 4.1.1. Network Control Protocols . . . . . . . . . . . . . . 13 82 4.1.2. Operations Administration Management (OAM) . . . . . 14 83 4.2. User Traffic . . . . . . . . . . . . . . . . . . . . . . 14 84 4.2.1. Telephony . . . . . . . . . . . . . . . . . . . . . . 14 85 4.2.2. Signaling . . . . . . . . . . . . . . . . . . . . . . 15 86 4.2.3. Inelastic Video Classes . . . . . . . . . . . . . . . 15 87 4.2.4. Elastic Video Classes . . . . . . . . . . . . . . . . 16 88 4.2.5. Low-Latency Data . . . . . . . . . . . . . . . . . . 17 89 4.2.6. High-Throughput Data . . . . . . . . . . . . . . . . 17 90 4.2.7. Standard Service Class . . . . . . . . . . . . . . . 17 91 4.2.8. Low-Priority Data . . . . . . . . . . . . . . . . . . 18 92 4.3. Downstream DSCP-to-UP Mapping Summary . . . . . . . . . . 18 93 5. Upstream Mapping Recommendations . . . . . . . . . . . . . . 20 94 5.1. Upstream DSCP-to-UP Mapping within the Wireless Client 95 Operating System . . . . . . . . . . . . . . . . . . . . 20 97 5.2. UP-to-DSCP Mapping at the Wireless Access Point . . . . . 20 98 5.3. DSCP-Trust at the Wireless Access Point . . . . . . . . . 21 99 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 100 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 101 7.1. Privacy Considerations . . . . . . . . . . . . . . . . . 22 102 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 103 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 104 9.1. Normative References . . . . . . . . . . . . . . . . . . 22 105 9.2. Informative References . . . . . . . . . . . . . . . . . 23 106 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 23 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 109 1. Introduction 111 Wireless has become the medium of choice for endpoints connecting to 112 business and private networks. However, the wireless medium defined 113 by 802.11 presents several design challenges for ensuring end-to-end 114 quality of service. Some of these challenges relate to the nature of 115 802.11 RF medium itself, being a half-duplex and shared media, while 116 other challenges relate to the fact that the 802.11 standard is not 117 administered by the standards body that administers the rest of the 118 IP [RFC0791][RFC2460] network. While the IEEE has developed tools to 119 enable QoS over wireless networks, little guidance exists on how to 120 optimally interconnect wired IP and wireless 802.11 networks, which 121 is the aim of this draft. 123 1.1. Related work 125 Several RFCs outline DiffServ QoS recommendations over IP networks, 126 including: 128 o [RFC2474] specifies the DiffServ Codepoint Field. This RFC also 129 details Class Selectors, as well as the Default Forwarding (DF) 130 treatment. 132 o [RFC2475] defines a DiffServ architecture 134 o [RFC3246] specifies the Expedited Forwarding (EF) Per-Hop Behavior 135 (PHB) 137 o [RFC2597] details the Assured Forwarding (AF) PHB. 139 o [RFC3662] outlines a Lower Effort Per-Domain Behavior (PDB) 141 o [RFC4594] presents Configuration Guidelines for DiffServ Service 142 Classes 144 o [RFC5127] discusses the Aggregation of Diffserv Service Classes 145 o [RFC5865] introduces a DSCP for Capacity Admitted Traffic 147 This draft draws heavily on [RFC4594], [RFC5127], and 148 [I-D.ietf-tsvwg-diffserv-intercon]. 150 In turn, the relevant standard for wireless QoS is IEEE 802.11, which 151 has been progressively updated, the current version being IEEE 152 802.11-2012. 154 1.2. Applicability Statement 156 This document is applicable to the use of Differentiated Services 157 that interconnect with IEEE 802.11 wireless LANs (referred to as Wi- 158 Fi, throughout this document, for simplicity). These guidelines are 159 applicable whether the wireless access points (APs) are deployed in 160 an autonomous manner, managed by (centralized or distributed) WLAN 161 controllers or some hybrid deployment option. This is because in all 162 these cases, the wireless access point is the bridge between wired 163 and wireless media. 165 This document primarily applies to wired IP networks that have 166 wireless access points at their edges, but can also be applied to Wi- 167 Fi backhaul, wireless mesh solutions or any other type of AP-to-AP 168 wireless network that serves to extend the IP network infrastructure. 170 1.3. Document Organization 172 This document begins with a very brief overview of how QoS is 173 achieved over IEEE 802.11 wireless networks, given the shared, half- 174 duplex nature of the wireless medium. This discussion is followed by 175 Section 3 which compares DiffServ QoS with Wi-Fi QoS and highlights 176 discrepancies requiring reconciliation. Section 4 presents 177 downstream (wired-to-wireless) DSCP-to-UP mapping recommendations for 178 each of the [RFC4594] traffic classes. And finally, Section 5 179 considers upstream (wireless-to-wired) QoS options and their 180 respective merits. 182 1.4. Requirements Language 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 186 document are to be interpreted as described in [RFC2119]. 188 2. IEEE 802.11e QoS Overview 190 QoS is enabled on wireless networks by means of the Hybrid 191 Coordination Function (HCF). To give better context to the 192 enhancements in HCF that enable QoS, it may be helpful to begin with 193 a review of the original Distributed Coordination Function (DCF). 195 2.1. Distributed Coordination Function (DCF) 197 As has been noted, the Wi-Fi medium is a shared medium, with each 198 station-including the wireless access point-contending for the medium 199 on equal terms. As such, it shares the same challenge as any other 200 shared medium in requiring a mechanism to prevent (or avoid) 201 collisions which can occur when two (or more) stations attempt 202 simultaneous transmission. 204 The IEEE Ethernet working group solved this challenge by implementing 205 a Carrier Sense Multiple Access/Collision Detection (CSMA/CD) 206 mechanism that could detect collisions over the shared physical cable 207 (as collisions could be detected as reflected energy pulses over the 208 physical wire). Once a collision was detected, then a pre-defined 209 set of rules was invoked that required stations to back off and wait 210 random periods of time before re-attempting transmission. While CSMA 211 /CD improved the usage of Ethernet as a shared medium, it should be 212 noted the ultimate solution to solving Ethernet collisions was the 213 advance of switching technologies, which treated each Ethernet cable 214 as a dedicated collision domain. 216 However, unlike Ethernet (which uses physical cables), collisions 217 cannot be directly detected over the wireless medium, as RF energy is 218 radiated over the air and colliding bursts are not necessarily 219 reflected back to the transmitting stations. Therefore, a different 220 mechanism is required for this medium. 222 As such, the IEEE modified the CSMA/CD mechanism to adapt it to 223 wireless networks to provide Carrier Sense Multiple Access/Collision 224 Avoidance (CSMA/CA). The original CSMA/CA mechanism used in 802.11 225 was the Distributed Coordination Function. DCF is a timer-based 226 system that leverages three key sets of timers, the slot time, 227 interframe spaces and contention windows. 229 2.1.1. Slot Time 231 The slot time is the basic unit of time measure for both DCF and HCF, 232 on which all other timers are based. The slot time duration varies 233 with the different generations of data-rates and performances 234 described by the 802.11 standard. For example, the IEEE 802.11-2012 235 standard specifies the slot time to be 20 us (IEEE 802.11-2012 236 Table 16-2) for legacy implementations (such as 802.11b, supporting 237 1, 2, 5.5 and 11 Mbps data rates), while newer implementations 238 (including 802.11g, 80.11a, 802.11n and 802.11ac, supporting data 239 rates from 500 Mbps to over 1 Gbps) define a shorter slot time of 9 240 us (IEEE 802.11-2012, Section 18.4.4, Table 18-17). 242 2.1.2. Interframe Spaces 244 The time interval between frames that are transmitted over the air is 245 called the Interframe Space (IFS). Several IFS are defined in 246 802.11, with the two most relevant to DCF being the Short Interframe 247 Space (SIFS) and the DCF Interframe Space (DIFS). 249 The SIFS is the amount of time in microseconds required for a 250 wireless interface to process a received RF signal and its associated 251 802.11 frame and to generate a response frame. Like slot times, the 252 SIFS can vary according to the performance implementation of the 253 802.11 standard. The SIFS for 802.11a, 802.11n and 802.11ac (in 5 254 Ghz) is 16 us (IEEE 802.11-2012, Section 18.4.4, Table 18-17). 256 Additionally, a station must sense the status of the wireless medium 257 before transmitting. If it finds that the medium is continuously 258 idle for the duration of a DIFS, then it is permitted to attempt 259 transmission of a frame (after waiting an additional random backoff 260 period, as will be discussed in the next section). If the channel is 261 found busy during the DIFS interval, the station must defer its 262 transmission until the medium is found idle for the duration of a 263 DIFS interval. The DIFS is calculated as: 265 DIFS = SIFS + (2 * Slot time) 267 However, if all stations waited only a fixed amount of time before 268 attempting transmission then collisions would be frequent. To offset 269 this, each station must wait, not only a fixed amount of time (the 270 DIFS) but also a random amount of time (the random backoff) prior to 271 transmission. The range of the generated random backoff timer is 272 bounded by the Contention Window. 274 2.1.3. Contention Windows 276 Contention windows bound the range of the generated random backoff 277 timer that each station must wait (in addition to the DIFS) before 278 attempting transmission. The initial range is set between 0 and the 279 Contention Window minimum value (CWmin), inclusive. The CWmin for 280 DCF (in 5 GHz) is specified as 15 slot times (IEEE 802.11- 2012, 281 Section 18.4.4, Table 18-17). 283 However, it is possible that two (or more) stations happen to pick 284 the exact same random value within this range. If this happens then 285 a collision will occur. At this point, the stations effectively 286 begin the process again, waiting a DIFS and generate a new random 287 backoff value. However, a key difference is that for this subsequent 288 attempt, the Contention Window approximatively doubles in size (thus 289 exponentially increasing the range of the random value). This 290 process repeats as often as necessary if collisions continue to 291 occur, until the maximum Contention Window size (CWmax) is reached. 292 The CWmax for DCF is specified as 1023 slot times (IEEE 802.11-2012, 293 Section 18.4.4, Table 18-17). 295 At this point, transmission attempts may still continue (until some 296 other pre-defined limit is reached), but the Contention Window sizes 297 are fixed at the CWmax value. 299 Incidentally it may be observed that a significant amount of jitter 300 can be introduced by this contention process for wireless 301 transmission access. For example, the incremental transmission delay 302 of 1023 slot times (CWmax) using 9 us slot times may be as high as 9 303 ms of jitter per attempt. And as previously noted, multiple attempts 304 can be made at CWmax. 306 2.2. Hybrid Coordination Function (HCF) 308 Therefore, as can be seen from the preceding description of DCF, 309 there is no preferential treatment of one station over another when 310 contending for the shared wireless media; nor is there any 311 preferential treatment of one type of traffic over another during the 312 same contention process. To support the latter requirement, the IEEE 313 enhanced DCF in 2005 to support QoS, specifying HCF in 802.11e, which 314 was integrated into the main 802.11 standard in 2007. 316 2.2.1. User Priority (UP) 318 One of the key changes to the 802.11 frame format is the inclusion of 319 a QoS Control field, with 3 bits dedicated for QoS markings. These 320 bits are referred to the User Priority (UP) bits and these support 321 eight distinct marking values: 0-7, inclusive. 323 While such markings allow for frame differentiation, these alone do 324 not directly affect over-the-air treatment. Rather it is the non- 325 configurable and standard-specified mapping of UP markings to 802.11 326 Access Categories (AC) that generate differentiated treatment over 327 wireless media. 329 2.2.2. Access Category (AC) 331 Pairs of UP values are mapped to four defined access categories that 332 correspondingly specify different treatments of frames over the air. 333 These access categories (in order of relative priority from the top 334 down) and their corresponding UP mappings are shown in Figure 1 335 (adapted from IEEE 802.11-2012, Section 9.2.4.2, Table 9-1). 337 +-----------------------------------------+ 338 | User | Access | Designative | 339 | Priority | Category | (informative) | 340 |===========+============+================| 341 | 7 | AC_VO | Voice | 342 +-----------+------------+----------------+ 343 | 6 | AC_VO | Voice | 344 +-----------+------------+----------------+ 345 | 5 | AC_VI | Video | 346 +-----------+------------+----------------+ 347 | 4 | AC_VI | Video | 348 +-----------+------------+----------------+ 349 | 3 | AC_BE | Best Effort | 350 +-----------+------------+----------------+ 351 | 0 | AC_BE | Best Effort | 352 +-----------+------------+----------------+ 353 | 2 | AC_BK | Background | 354 +-----------+------------+----------------+ 355 | 1 | AC_BK | Background | 356 +-----------------------------------------+ 358 Figure 1: IEEE 802.11 Access Categories and User Priority Mappings 360 The manner in which these four access categories achieve 361 differentiated service over-the-air is primarily by tuning the fixed 362 and random timers that stations have to wait before sending their 363 respective types of traffic, as will be discussed next. 365 2.2.3. Arbitration Inter-Frame Space (AIFS) 367 As previously mentioned, each station must wait a fixed amount of 368 time to ensure the air is clear before attempting transmission. With 369 DCF, the DIFS is constant for all types of traffic. However, with 370 802.11 the fixed amount of time that a station has to wait will 371 depend on the access category and is referred to as an Arbitration 372 Interframe Space (AIFS). AIFS are defined in slot times and the AIFS 373 per access category are shown in Figure 2 (adapted from IEEE 374 802.11-2012, Section 8.4.2.31, Table 8-105). 376 +------------------------------------------+ 377 | Access | Designative | AIFS | 378 | Category | (informative) |(slot times)| 379 |===========+=================+============| 380 | AC_VO | Voice | 2 | 381 +-----------+-----------------+------------+ 382 | AC_VI | Video | 2 | 383 +-----------+-----------------+------------+ 384 | AC_BE | Best Effort | 3 | 385 +-----------+-----------------+------------+ 386 | AC_BK | Background | 7 | 387 +-----------+-----------------+------------+ 389 Figure 2: Arbitration Interframe Spaces by Access Category 391 2.2.4. Access Category Contention Windows (CW) 393 Not only is the fixed amount of time that a station has to wait 394 skewed according to 802.11 access category, but so are the relative 395 sizes of the Contention Windows that bound the random backoff timers, 396 as shown in Figure 3 (adapted from IEEE 802.11-2012, 397 Section 8.4.2.31, Table 8-105). 399 +-------------------------------------------------------+ 400 | Access | Designative | CWmin | CWmax | 401 | Category | (informative) |(slot times)|(slot times)| 402 |===========+=================+============|============| 403 | AC_VO | Voice | 3 | 7 | 404 +-----------+-----------------+------------+------------+ 405 | AC_VI | Video | 7 | 15 | 406 +-----------+-----------------+------------+------------+ 407 | AC_BE | Best Effort | 15 | 1023 | 408 +-----------+-----------------+------------+------------+ 409 | AC_BK | Background | 15 | 1023 | 410 +-----------+-----------------+------------+------------+ 412 Figure 3: Contention Window Sizes by Access Category 414 3. Comparison and Default Interoperation of DiffServ and IEEE 802.11 416 When the fixed and randomly generated timers are added together on a 417 per access category basis, then traffic assigned to the Voice Access 418 Category (i.e. traffic marked to UP 6 or 7) will receive a 419 statistically superior service relative to traffic assigned to the 420 Video Access Category (i.e. traffic marked UP 5 and 4), which, in 421 turn, will receive a statistically superior service relative to 422 traffic assigned to the Best Effort Access Category traffic (i.e. 423 traffic marked UP 3 and 0), which finally will receive a 424 statistically superior service relative to traffic assigned to the 425 Background Access Category traffic (i.e. traffic marked to UP 2 and 426 1). 428 However the following comparisons between IEEE 802.11 and DiffServ 429 should be noted: 431 o 802.11 does not support a [RFC3246] EF PHB service, as it is not 432 possible to guarantee that a given access category will be 433 serviced with strict priority over another (due to the random 434 element within the contention process) 436 o 802.11 does not support a [RFC2597] AF PHB service, again because 437 it is not possible to guarantee that a given access category will 438 be serviced with a minimum amount of assured bandwidth (due to the 439 non-deterministic nature of the contention process) 441 o 802.11 loosely supports a [RFC2474] Default Forwarding service via 442 the Best Effort Access Category (AC_BE) 444 o 802.11 loosely supports a [RFC3662] Lower PDB service via the 445 Background Access Category (AC_BK) 447 As such, these are high-level considerations that need to be kept in 448 mind when mapping from DiffServ to 802.11 (and vice-versa); however, 449 some additional marking-specific incompatibilities must also be 450 reconciled, as will be discussed next. 452 3.1. Default Downstream DSCP-to-UP Mappings and Conflicts 454 While no explicit guidance is offered in mapping (6-Bit) Layer 3 DSCP 455 values to (3-Bit) Layer 2 markings (such as IEEE 802.1D, 802.1p or 456 802.11e), the networking industry norm has been to map these using 457 the default method of transcribing the 3 Most Significant Bits (MSB) 458 of the DSCP to generate the corresponding L2 markings. 460 Note: There are example mappings in IEEE 802.11 (in the Annex V 461 Tables V-1 and V2), but these mappings are provided as examples (vs. 462 as recommendations). Furthermore, some of these mappings do not 463 align with the intent and recommendations expressed in [RFC4594], as 464 will be discussed in the following section. 466 However, when this default DSCP-to-UP mapping method is applied to 467 packets marked per [RFC4594] recommendations and destined to 802.11 468 WLAN clients, it will yield a number of sub-optimal QoS mappings, 469 specifically: 471 o Voice (EF-101110) will be mapped to UP 5 (101), and treated in the 472 Video Access Category (AC_VI), rather than the Voice Access 473 Category (AC_VO), for which it is intended 475 o Multimedia Streaming (AF3-011xx0) will be mapped to UP3 (011) and 476 treated in the Best Effort Access Category (AC_BE), rather than 477 the Video Access Category (AC_VI), for which it is intended 479 o OAM traffic (CS2-010000) will be mapped to UP 2 (010) and treated 480 in the Background Access Category (AC_BK), which is not the intent 481 expressed in [RFC4594] for this traffic class 483 It should also be noted that while IEEE 802.11 defines an intended 484 use for each access category through the AC naming convention (for 485 example, UP 6 and UP 7 belong to AC_VO, the Voice Access Category), 486 802.11 does not: 488 o define how upper Layer markings (such as DSCP) should map to UPs 489 (and hence to ACs) 491 o define how UPs should translate to other medium Layer 2 QoS 492 markings 494 o strictly restrict each access category to applications reflected 495 in the AC name 497 3.2. Default Upstream UP-to-DSCP Mappings and Conflicts 499 In the opposite direction of flow (the upstream direction, that is, 500 from wireless-to-wired), most APs use a default method of deriving 501 DSCP values from UP values by multiplying these by 8 (i.e. shifting 502 the 3 UP bits to the left and adding three additional zeros to 503 generate a DSCP value). This default-derived DSCP value is then used 504 for QoS treatment between the wireless access point and the nearest 505 classification and marking policy enforcement point (which may be the 506 centralized wireless LAN controller, relatively deep within the 507 network). 509 It goes without saying that when 6 bits of marking granularity are 510 derived from 3, then information is lost in translation. 511 Distinctions cannot be made for 12 classes of traffic (as recommended 512 in [RFC4594]), but for only 8 (with one of these classes being 513 reserved for future use (i.e. UP 7 which maps to DSCP CS7). 515 Such default upstream mapping can also yield several inconsistencies 516 with [RFC4594], including: 518 o Mapping UP 6 (Voice) to CS6, which [RFC4594] recommends for 519 Network Control 521 o Mapping UP 4 (Multimedia Conferencing and/or Real-Time 522 Interactive) to CS4, thus losing the ability to distinguish 523 between these two distinct traffic classes 525 o Mapping UP 3 (Multimedia Streaming and/or Broadcast Video) to CS3, 526 thus losing the ability to distinguish between these two distinct 527 traffic classes 529 o Mapping UP 2 (Low-Latency Data and/or OAM) to CS2, thus losing the 530 ability to distinguish between these two distinct traffic classes, 531 and possibly overwhelming the queues provisioned for OAM (which is 532 typically lower in capacity [being network control traffic], as 533 compared to Low-Latency Data queues [being user traffic]) 535 o Mapping UP 1 (High-Throughput Data and/or Low-Priority Data) to 536 CS1, thus losing the ability to distinguish between these two 537 distinct traffic classes and causing legitimate business-relevant 538 High-Throughput Data to receive a [RFC3662] Lower PDB, for which 539 it is not intended 541 Thus, the next sections of this draft seek to address these 542 limitations and concerns and reconcile the intents of [RFC4594] and 543 IEEE 802.11. First the downstream (wired-to-wireless) DSCP-to-UP 544 mappings will be aligned and then upstream (wireless-to-wired) models 545 will be addressed. 547 4. Downstream DSCP-to-UP Mapping Recommendations 549 The following section proposes downstream (wired-to-wireless) 550 mappings between [RFC4594] Configuration Guidelines for DiffServ 551 Service Classes and IEEE 802.11. As such, this section draws heavily 552 from [RFC4594], including traffic class definitions and 553 recommendations. 555 This section assumes wireless access points and/or WLAN controllers 556 that support customizable, non-default DSCP-to-UP mapping schemes. 558 4.1. Network Control Traffic 560 Network control traffic is defined as packet flows that are essential 561 for stable operation of the administered network. Network control 562 traffic is different from user application control (signaling) that 563 may be generated by some applications or services. Network Control 564 Traffic may be split into two service classes: 566 o Network Control, and 568 o Operations Administration and Management (OAM) 570 4.1.1. Network Control Protocols 572 The Network Control service class is used for transmitting packets 573 between network devices (routers) that require control (routing) 574 information to be exchanged between nodes within the administrative 575 domain as well as across a peering point between different 576 administrative domains. The RECOMMENDED DSCP marking for Network 577 Control is CS6. 579 Before discussing a mapping recommendation for Network Control 580 traffic marked CS6 DSCP, it is interesting to note a relevant 581 recommendation from [RFC4594] pertaining to traffic marked CS7 DSCP: 582 in [RFC4594] Section 3.1 it is RECOMMENDED that packets marked CS7 583 DSCP (a codepoint that SHOULD be reserved for future use) be dropped 584 or remarked at the edge of the DiffServ domain. 586 Following this recommendation, it is RECOMMENDED that all packets 587 marked to DiffServ Codepoints not in use over the wireless network be 588 dropped or remarked at the edge of the DiffServ domain. 590 It is important to note that the wired-to-wireless edge may or may 591 not equate to the edge of the DiffServ domain; as such, this 592 recommendation may or may not apply at the wired-to-wireless edge. 594 For example, in most commonly deployed models, the wireless access 595 point represents not only the edge of the DiffServ domain, but also 596 the edge of the network infrastructure itself. As such, and in line 597 with the above recommendation, traffic marked CS7 DSCP SHOULD be 598 dropped or remarked at this edge (as it is typically unused, as CS7 599 SHOULD be reserved for future use). So too SHOULD Network Control 600 traffic marked CS6 DSCP, considering that only client devices (and no 601 network infrastructure devices) are downstream from the wireless 602 access points in these deployment models. In such cases, no Network 603 Control traffic would be (legitimately) expected to be sent or 604 received from wireless client endpoint devices, and thus this 605 recommendation would apply. 607 Alternatively, in other deployment models, such as Wi-Fi backhaul, 608 wireless mesh infrastructures, or any other type of wireless AP-to-AP 609 deployments, the wireless access point extends the network 610 infrastructure and thus, typically, the DiffServ domain. In such 611 cases, the above recommendation would not apply, as the wired-to- 612 wireless edge does not represent the edge of the DiffServ domain. 613 Furthermore, as these deployment models require Network Control 614 traffic to be propagated across the wireless network, it is 615 RECOMMENDED to map Network Control traffic marked CS6 to UP 7 (per 616 IEEE 802.11e-2012, Section 9.2.4.2, Table 9-1), thereby admitting it 617 to the Voice Access Category (AC_VO). 619 4.1.2. Operations Administration Management (OAM) 621 The OAM (Operations, Administration, and Management) service class is 622 RECOMMENDED for OAM&P (Operations, Administration, and Management and 623 Provisioning). The RECOMMENDED DSCP marking for OAM is CS2. 625 By default, packets marked DSCP CS2 will be mapped to UP 2 and 626 serviced with the Background Access Category (AC_BK). Such servicing 627 is a contradiction to the intent expressed in [RFC4594] Section 3.3. 628 As such, it is RECOMMENDED that a non-default mapping be applied to 629 OAM traffic, such that CS2 DSCP is mapped to UP 0, thereby admitting 630 it to the Best Effort Access Category (AC_BE). 632 4.2. User Traffic 634 User traffic is defined as packet flows between different users or 635 subscribers. It is the traffic that is sent to or from end-terminals 636 and that supports a very wide variety of applications and services. 637 Network administrators can categorize their applications according to 638 the type of behavior that they require and MAY choose to support all 639 or a subset of the defined service classes. 641 4.2.1. Telephony 643 The Telephony service class is RECOMMENDED for applications that 644 require real-time, very low delay, very low jitter, and very low 645 packet loss for relatively constant-rate traffic sources (inelastic 646 traffic sources). This service class SHOULD be used for IP telephony 647 service. The fundamental service offered to traffic in the Telephony 648 service class is minimum jitter, delay, and packet loss service up to 649 a specified upper bound. The RECOMMENDED DSCP marking for Telephony 650 is EF. 652 As EF traffic will map by default to UP 5, and thus to the Video 653 Access Category (AC_VI), a non-default DSCP-to-UP mapping is 654 RECOMMENDED, such that EF DSCP is mapped to UP 6, thereby admitting 655 it into the Voice Access Category (AC_VO). 657 Similarly, the [RFC5865] VOICE-ADMIT DSCP (44/101100) is RECOMMENDED 658 to be mapped to UP 6, thereby admitting it also into the Voice Access 659 Category (AC_VO). 661 4.2.2. Signaling 663 The Signaling service class is RECOMMENDED for delay-sensitive 664 client-server (traditional telephony) and peer-to-peer application 665 signaling. Telephony signaling includes signaling between IP phone 666 and soft-switch, soft-client and soft-switch, and media gateway and 667 soft-switch as well as peer-to-peer using various protocols. This 668 service class is intended to be used for control of sessions and 669 applications. The RECOMMENDED DSCP marking for Signaling is CS5. 671 While signaling is RECOMMENDED to receive a superior level of service 672 relative to the default class (i.e. AC_BE), it does not require the 673 highest level of service (i.e. AC_VO). This leaves only the Video 674 Access Category (AC_VI), which it will map to by default. However, 675 to better distinguish inelastic video flows from elastic video and 676 signaling flows (as will be discussed next), it is RECOMMENDED to map 677 Signaling traffic marked CS5 DSCP to UP 4, thereby admitting it to 678 the Video Access Category (AC_VI). 680 4.2.3. Inelastic Video Classes 682 Both the Real-Time Interactive and Broadcast Video traffic classes 683 are considered to be inelastic, in that the traffic in these classes 684 does not have the ability (or the business requirement precludes the 685 use of the ability) to change encoding, resolution, frame or 686 transmission rates to dynamically adapt to network conditions such as 687 congestion and/or packet loss. The Real-Time Interactive and 688 Broadcast Video traffic classes are intended for bi-directional and 689 unidirectional inelastic video flows (respectively). 691 Specifically, the Real-Time Interactive traffic class is RECOMMENDED 692 for applications that require low loss and jitter and very low delay 693 for variable rate inelastic traffic sources. The RECOMMENDED DSCP 694 marking for Real-Time Interactive is CS4. 696 Similarly, the Broadcast Video service class is RECOMMENDED for 697 applications that require near-real-time packet forwarding with very 698 low packet loss of constant rate and variable rate inelastic traffic 699 sources. The RECOMMENDED DSCP marking for Broadcast Video is CS3. 701 While considering Table 1 it may seem superfluous to make a 702 distinction between inelastic video classes (by mapping these to UP 703 5) and elastic video classes (by mapping these to UP 4), as both are 704 destined to be serviced within the same Video Access Category 705 (AC_VI). However, a subtlety in implementation merits consideration 706 and provides the rationale behind this recommendation. 708 IEEE 802.11-2012 illustrates a reference implementation model in 709 Figure 9-19 which depicts four transmit queues, one per access 710 category. In practical implementation, however, it is common for 711 network vendors to actually implement dedicated transmit queues on a 712 per-UP basis, which are then dequeued into their associated access 713 category in a preferred (or even strict priority manner). For 714 example, (and specific to this example): it is common for network 715 vendors to dequeue UP 5 ahead of UP 4 to the hardware performing the 716 EDCA function (EDCAF) for the Video Access Category (AC_VI). As 717 such, inelastic video flows can benefit from this distinction in 718 servicing. 720 A corollary benefit may also be realized in the upstream direction, 721 for if inelastic video flows are marked to a separate UP from elastic 722 video (or signaling) flows, then these can easily be distinguished 723 from each other and serviced accordingly in the upstream direction. 725 For these reasons it is RECOMMENDED to map inelastic video traffic 726 marked CS4 and CS3 DSCP to UP 5, thereby admitting it to the Video 727 Access Category (AC_VI). 729 4.2.4. Elastic Video Classes 731 In contrast to Real-Time Interactive and Broadcast Video, the 732 Multimedia Conferencing and Multimedia Streaming traffic classes are 733 intended for bi-directional and unidirectional elastic video flows 734 (respectively). 736 Specifically, the Multimedia Conferencing service class is 737 RECOMMENDED for applications that require real-time service for rate- 738 adaptive traffic. The RECOMMENDED DSCP markings for Multimedia 739 Conferencing are AF41, AF42 and AF43. 741 Similarly, the Multimedia Streaming The Multimedia Streaming service 742 class is RECOMMENDED for applications that require near-real-time 743 packet forwarding of variable rate elastic traffic sources. The 744 RECOMMENDED DSCP markings for Multimedia Streaming are AF31, AF32 and 745 AF33. 747 In line with the recommendation made in the previous section, and to 748 preclude the default mapping of Multimedia Streaming to UP 3 (and 749 hence to AC_BE), it is RECOMMENDED to map inelastic video/multimedia 750 traffic classes marked AF4x and AF3x DSCP to UP 4, thereby admitting 751 these to the Video Access Category (AC_VI). 753 4.2.5. Low-Latency Data 755 The Low-Latency Data service class is RECOMMENDED for elastic and 756 time-sensitive data applications, often of a transactional nature, 757 where a user is waiting for a response via the network in order to 758 continue with a task at hand. As such, these flows may be considered 759 foreground traffic, with delays or drops to such traffic directly 760 impacting user-productivity. The RECOMMENDED DSCP markings for Low- 761 Latency Data are AF21, AF22 and AF23. 763 In line with the recommendations made in Section 4.2.3, mapping Low- 764 Latency Data to UP 3 may allow such to receive a superior level of 765 service via transmit queues servicing the EDCAF hardware for the Best 766 Effort Access Category (AC_BE), as well as providing for a 767 distinction between such traffic vs. Default Forwarding traffic in 768 the upstream direction. Therefore it is RECOMMENDED to map Low- 769 Latency Data traffic marked AF2x DSCP to UP 3, thereby admitting it 770 to the Best Effort Access Category (AC_BE). 772 4.2.6. High-Throughput Data 774 The High-Throughput Data service class is RECOMMENDED for elastic 775 applications that require timely packet forwarding of variable rate 776 traffic sources and, more specifically, is configured to provide 777 efficient, yet constrained (when necessary) throughput for TCP 778 longer-lived flows. These flows are typically non-user-interactive 779 and, as such, can be considered background traffic. It can also be 780 assumed that this class will consume any available bandwidth and that 781 packets traversing congested links may experience higher queuing 782 delays or packet loss, as well as that this traffic is elastic and 783 responds dynamically to packet loss. The RECOMMENDED DSCP markings 784 for High-Throughput Data are AF11, AF12 and AF13. 786 In line with the recommendations made in Section 4.2.3, mapping High- 787 Throughput Data to UP 2 may allow such to receive a superior level of 788 service via transmit queues servicing the EDCAF hardware for the 789 Background Access Category (AC_BK), as well as providing for a 790 distinction between such traffic vs. Low-Priority Data in the 791 upstream direction. Therefore it is RECOMMENDED to map High- 792 Throughput Data traffic marked AF1x DSCP to UP 2, thereby admitting 793 it to the Background Access Category (AC_BK). 795 4.2.7. Standard Service Class 797 The Standard service class is RECOMMENDED for traffic that has not 798 been classified into one of the other supported forwarding service 799 classes in the DiffServ network domain. This service class provides 800 the Internet's "best-effort" forwarding behavior. The RECOMMENDED 801 DSCP marking for the Standard Service Class is DF. 803 The Standard Service Class loosely corresponds to the 802.11 Best 804 Effort Access Category (AC_BK) and therefore it is RECOMMENDED to map 805 Standard Service Class traffic marked DF DSCP to UP 0, thereby 806 admitting it to the Best Effort Access Category (AC_BE). 808 4.2.8. Low-Priority Data 810 The Low-Priority Data service class serves applications that the user 811 is willing to accept service without guarantees. This service class 812 is specified in [RFC3662]. 814 The Low-Priority Data service class loosely corresponds to the 802.11 815 Background Access Category (AC_BK) and therefore it is RECOMMENDED to 816 map Low-Priority Data traffic marked CS1 DSCP to UP 1, thereby 817 admitting it to the Background Access Category (AC_BK). 819 4.3. Downstream DSCP-to-UP Mapping Summary 821 Figure 4 summarizes the [RFC4594] DSCP marking recommendations mapped 822 to IEEE 802.11 UP and access categories applied in the downstream 823 direction (from wired-to-wireless networks). 825 +------------------------------------------------------------------+ 826 | IETF DiffServ | DSCP | PHB | IEEE 802.11 | 827 | Service Class | | Used |User Priority| Access Category | 828 |===============+======+=========+=============+===================| 829 |Network Control| CS6 | RFC2474 | (See Section 4.1.1) | 830 +---------------+------+---------+-------------+-------------------+ 831 | Telephony | EF | RFC3246 | 6 | AC_VO (Voice) | 832 +---------------+------+---------+-------------+-------------------+ 833 | VOICE-ADMIT | 44 | RFC5865 | 6 | AC_VO (Voice) | 834 +---------------+------+---------+-------------+-------------------+ 835 | Signaling | CS5 | RFC2474 | 4 | AC_VI (Video) | 836 +---------------+------+---------+-------------+-------------------+ 837 | Multimedia | AF41 | | | | 838 | Conferencing | AF42 | RFC2597 | 4 | AC_VI (Video) | 839 | | AF43 | | | | 840 +---------------+------+---------+-------------+-------------------+ 841 | Real-Time | CS4 | RFC2474 | 5 | AC_VI (Video) | 842 | Interactive | | | | | 843 +---------------+------+---------+-------------+-------------------+ 844 | Multimedia | AF31 | | | | 845 | Streaming | AF32 | RFC2597 | 4 | AC_VI (Video) | 846 | | AF33 | | | | 847 +---------------+------+---------+-------------+-------------------+ 848 |Broadcast Video| CS3 | RFC2474 | 5 | AC_VI (Video) | 849 +---------------+------+---------+-------------+-------------------+ 850 | Low- | AF21 | | | | 851 | Latency | AF22 | RFC2597 | 3 |AC_BE (Best Effort)| 852 | Data | AF23 | | | | 853 +---------------+------+---------+-------------+-------------------+ 854 | OAM | CS2 | RFC2474 | 0 |AC_BE (Best Effort)| 855 +---------------+------+---------+-------------+-------------------+ 856 | High- | AF11 | | | | 857 | Throughput | AF12 | RFC2597 | 2 | AC_BK (Background)| 858 | Data | AF13 | | | | 859 +---------------+------+---------+-------------+-------------------+ 860 | Standard | DF | RFC2474 | 0 |AC_BE (Best Effort)| 861 +---------------+------+---------+-------------+-------------------+ 862 | Low-Priority | CS1 | RFC3662 | 1 | AC_BK (Background)| 863 | Data | | | | | 864 +------------------------------------------------------------------+ 866 Figure 4: Summary of Downstream DSCP to IEEE 802.11 UP and AC Mapping 867 Recommendations 869 5. Upstream Mapping Recommendations 871 In the upstream direction, there are three types of mapping that may 872 occur: 874 o DSCP-to-UP mapping within the wireless client operating system 876 o UP-to-DSCP mapping at the wireless access point 878 o DSCP-Trust at the wireless access point 880 5.1. Upstream DSCP-to-UP Mapping within the Wireless Client Operating 881 System 883 Some operating systems on wireless client devices utilize a similar 884 default DSCP-to-UP mapping scheme as described in Section 3.1. As 885 such, this can lead to the same conflicts as described in that 886 section, but in the upstream direction. 888 Therefore, to improve on these default mappings, and to acheive 889 parity and consistency with downstream QoS, it is RECOMMENDED that 890 such wireless client operating systems utilize instead the same DSCP- 891 to-UP mapping recommendations presented in Section 4 and/or fully 892 customizable UP markings. 894 5.2. UP-to-DSCP Mapping at the Wireless Access Point 896 UP-to-DSCP mapping generates a DSCP value for the IP packet (either 897 an unencapsulated IP packet or an IP packet encapsulated within a 898 tunneling protocol such as CAPWAP - and destined towards a wireless 899 LAN controller for decapsulation and forwarding) from the Layer 2 900 IEEE UP markings of the wireless frame. 902 It should be noted that any explicit remarking policy to be performed 903 on such a packet only takes place at the nearest classification and 904 marking policy enforcement point, which may be: 906 o At the wireless access point 908 o At the wired network switch port 910 o At the wireless LAN controller 912 As such, UP-to-DSCP mapping allows for wireless L2 markings to affect 913 the QoS treatment of a packet over the wired IP network (that is, 914 until the packet reaches the nearest classification and marking 915 policy enforcement point). 917 It should be noted that nowhere in the IEEE 802.11 specifications is 918 there an intent expressed for 802.11e UP to be used to influence QoS 919 treatment over wired IP networks. Furthermore, both [RFC2474] and 920 [RFC2475] allow for the host to set DSCP markings for QoS treatment 921 over IP networks. Therefore, it is NOT RECOMMENDED that wireless 922 access points trust UP markings as set by these hosts and 923 subsequently perform a UP-to-DSCP mapping in the upstream direction, 924 but rather, if wireless host markings are to be trusted (as per 925 business requirements, technical constraints and administrative 926 preference), then it is RECOMMENDED to trust the DSCP markings set by 927 these wireless hosts. 929 5.3. DSCP-Trust at the Wireless Access Point 931 On wireless access points that can trust DSCP markings of packets 932 encapsulated within wireless frames it is RECOMMENDED to trust DSCP 933 markings in the upstream direction, for the following reasons: 935 o [RFC2474] and [RFC2475] allow for hosts to set DSCP markings to 936 achieve and end-to-end differentiated service 938 o IEEE 802.11 does not specify that UP markings are to be used to 939 affect QoS treatment over wired IP networks 941 o Most wireless device operating systems generate UP values by the 942 same method as described in Section 3.1 (i.e. by using the 3 MSB 943 of the encapsulated 6-bit DSCP); then, at the access point, these 944 3-bit mappings are converted back into DSCP values, either by the 945 default operation described in Section 3.2 or by a customized 946 mapping as described in Section 4; in either case, information is 947 lost in the transitions from 6-bit marking to 3-bit marking and 948 then back to 6-bit marking; trusting the encapsulated DSCP 949 prevents this loss of information 951 o A practical implementation benefit is also realized by trusting 952 the DSCP set by wireless client devices, as enabling applications 953 to mark DSCP is much more prevalent and accessible to programmers 954 of wireless applications vis-a-vis trying to explicitly set UP 955 values, which requires special hooks into the wireless device 956 operating system and/or hardware device drivers, many of which (at 957 the time of writing) have little or no resources to support such 958 functionality 960 6. IANA Considerations 962 This memo asks the IANA for no new parameters. 964 7. Security Considerations 966 The recommendation offered in Section 4.1.1 (of dropping or remarking 967 packets marked with DiffServ Codepoints not in use at the edge of the 968 DiffServ domain) is to address a Denial-of-Service attack vector that 969 exists at wired-to-wireless edges due to the requirement of trusting 970 traffic markings to ensure end-to-end QoS. For example, consider a 971 malicious user flooding traffic marked CS7 or CS6 DSCP toward the 972 WLAN. These codepoints would map by default to UP 7 and UP 6 973 (respectively), both of which would be assigned to the Voice Access 974 Category (AC_VO). Such a flood could cause a Denial-of-Service to 975 wireless voice applications. 977 7.1. Privacy Considerations 979 8. Acknowledgements 981 The authors wish to thank TSVWG reviewers. 983 The authors acknowledge a great many inputs, notably from Jerome 984 Henry, David Kloper, Mark Montanez, Glen Lavers, Michael Fingleton, 985 Sarav Radhakrishnan, Karthik Dakshinamoorthy, Simone Arena, Ranga 986 Marathe, Ramachandra Murthy and many others. 988 9. References 990 9.1. Normative References 992 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 993 Requirement Levels", BCP 14, RFC 2119, March 1997. 995 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 996 "Definition of the Differentiated Services Field (DS 997 Field) in the IPv4 and IPv6 Headers", RFC 2474, December 998 1998. 1000 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1001 and W. Weiss, "An Architecture for Differentiated 1002 Services", RFC 2475, December 1998. 1004 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 1005 "Assured Forwarding PHB Group", RFC 2597, June 1999. 1007 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 1008 J., Courtney, W., Davari, S., Firoiu, V., and D. 1009 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 1010 Behavior)", RFC 3246, March 2002. 1012 [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort 1013 Per-Domain Behavior (PDB) for Differentiated Services", 1014 RFC 3662, December 2003. 1016 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 1017 Guidelines for DiffServ Service Classes", RFC 4594, August 1018 2006. 1020 [RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated 1021 Services Code Point (DSCP) for Capacity-Admitted Traffic", 1022 RFC 5865, DOI 10.17487/RFC5865, May 2010, 1023 . 1025 9.2. Informative References 1027 [I-D.ietf-tsvwg-diffserv-intercon] 1028 Geib, R. and D. Black, "Diffserv interconnection classes 1029 and practice", draft-ietf-tsvwg-diffserv-intercon-02 (work 1030 in progress), July 2015. 1032 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1033 1981. 1035 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1036 (IPv6) Specification", RFC 2460, December 1998. 1038 [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of 1039 Diffserv Service Classes", RFC 5127, February 2008. 1041 Appendix A. Change Log 1043 Initial Version: July 2015 1045 Authors' Addresses 1047 Tim Szigeti 1048 Cisco Systems 1049 Vancouver, British Columbia V7X 1J1 1050 Canada 1052 Email: szigeti@cisco.com 1053 Fred Baker 1054 Cisco Systems 1055 Santa Barbara, California 93117 1056 USA 1058 Email: fred@cisco.com