idnits 2.17.1 draft-custura-tsvwg-dscp-considerations-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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 15, 2021) is 1137 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-22) exists of draft-ietf-tsvwg-nqb-03 -- Obsolete informational reference (is this intentional?): RFC 1349 (Obsoleted by RFC 2474) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TSVWG A. Custura 3 Internet-Draft G. Fairhurst 4 Intended status: Informational R. Secchi 5 Expires: September 16, 2021 University of Aberdeen 6 March 15, 2021 8 Considerations for Assigning a new receommended DiffServ Codepoint 9 (DCSP) 10 draft-custura-tsvwg-dscp-considerations-01 12 Abstract 14 This document discusses considerations for assigning a new 15 recommended DiffServ Code Point (DSCP). It considers the common 16 remarking behaviours that the Diffserv field might be subjected to 17 along an Internet path. It also notes some implications of using a 18 specific DSCP. 20 This individual draft aims to seek comments and contributions from 21 the TSVWG working group. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 16, 2021. 40 Copyright Notice 42 Copyright (c) 2021 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 59 3. Current usage of DSCPs . . . . . . . . . . . . . . . . . . . 3 60 3.1. IP-Layer Semantics . . . . . . . . . . . . . . . . . . . 3 61 3.2. Network Control Traffic . . . . . . . . . . . . . . . . . 4 62 4. Remarking the DSCP . . . . . . . . . . . . . . . . . . . . . 4 63 4.1. Bleaching the DSCP Field . . . . . . . . . . . . . . . . 5 64 4.2. IP Type of Service manipulations . . . . . . . . . . . . 5 65 4.2.1. Impact of ToS Precedence Bleaching . . . . . . . . . 6 66 4.2.2. Impact of ToS Precedence Remarking . . . . . . . . . 6 67 4.3. Remarking to a Particular DSCP . . . . . . . . . . . . . 7 68 5. Interpretation of the IP DSCP at Lower Layers . . . . . . . . 7 69 5.1. Mapping Specified for IEEE 802.11 . . . . . . . . . . . . 7 70 5.2. Mappings Specified for MPLS . . . . . . . . . . . . . . . 9 71 5.3. Mapping Specified for Mobile Networks . . . . . . . . . . 9 72 5.4. Mappings Specified for Carrier Ethernet . . . . . . . . . 9 73 5.5. Remarking as a Side-effect of Another Policy . . . . . . 10 74 6. Considerations for DSCP Selection . . . . . . . . . . . . . . 10 75 6.1. Effect of Bleaching . . . . . . . . . . . . . . . . . . . 10 76 6.2. Where the proposed DSCP > 0x07 (7) . . . . . . . . . . . 10 77 6.3. Where the proposed DSCP < 0x07 (7) . . . . . . . . . . . 10 78 6.4. Where the proposed DSCP&&0x07=0x01 . . . . . . . . . . . 11 79 6.5. Impact on deployed infrastructure . . . . . . . . . . . . 11 80 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 82 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 85 10.2. Informative References . . . . . . . . . . . . . . . . . 13 86 Appendix A. Revision Notes . . . . . . . . . . . . . . . . . . . 14 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 89 1. Introduction 91 The Differentiated Services (DiffServ) architecture has been deployed 92 in many networks. It provides differentiated traffic forwarding 93 based on the value of the Diffserv field [RFC2474] carried in the IP 94 packet header. 96 This document discusses considerations for assigning a new DiffServ 97 Code Point (DCSP). It considers some commonly observed DSCP 98 remarking behaviours that might be expected to be experienced along 99 an Internet path. It also notes some packet forwarding treatments 100 that a packet can receive when using a specific DSCP. 102 The document is motivated by new opportunities to use DiffServ end- 103 to-end across multiple domains, such as [I-D.ietf-tsvwg-nqb], 104 proposals to build mechanisms using DSCPs in other standards-setting 105 organisations, and the desire to use a common set of DSCPs across a 106 range of infrastructure (e.g., [I-D.learmonth-rfc1226-bis]). 108 2. Requirements Language 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [RFC2119]. 114 3. Current usage of DSCPs 116 This section describes current usage of DSCPs. 118 3.1. IP-Layer Semantics 120 The DiffServ architecture specifies use of the Diffserv field in the 121 IPv4 and IPv6 packet headers to carry one of 64 distinct DSCP values. 122 Within a given administrative boundary, each DSCP value can be mapped 123 to a distinct Per Hop Behavior (PHB)[RFC2474]. When a new PHB is 124 standardized, a recommended DSCP value among those 64 values is 125 normally reserved for that PHB. 127 The DSCP space is divided into three pools for the purpose of 128 assignment and management [DSCP-registry]. The pools are defined in 129 the following table (where 'x' refers to either a bit position with 130 value '0' or '1'). 132 DSCP Pool 1 A pool of 32 codepoints with a format 0bxxxxx0, to be 133 assigned by IANA Standards Action [RFC8126]. 135 DSCP Pool 2 A pool of 16 codepoints with a format 0bxxxx11, reserved 136 for experimental or local (private) use by network operators (see 137 sections 4.1 and 4.2 of [RFC8126]. 139 DSCP Pool 3 A pool of 16 codepoints with a 0bxxxx01. This was 140 initially available for experimental or local use, but which was 141 originally specified to be preferentially utilised for 142 standardized assignments if Pool 1 is ever exhausted. Pool 3 143 codepoints are now utilised for standardized assignments and are 144 no longer available for experimental or local use [RFC8436]. 146 The DiffServ architecture allows forwarding treatments to be 147 associated with each DSCP, and the RFC series describes some of these 148 as PHBs. Although DSCPs are intended to identify specific treatment 149 requirements. Multiple DSCPs might also be mapped (aggregated) to 150 the same forwarding treatment. Several IP standards map treatment 151 aggregates to DSCPs, that might result in remarking: RFC5160 152 [RFC5160] suggests Meta-QoS-Classes to help enable deployment of 153 standardized end-to-end QoS classes. 155 Note: A DSCP is sometimes referred to by name, such as "CS1", and 156 sometimes by a decimal, hex, or binary value [DSCP-registry]. 158 3.2. Network Control Traffic 160 Network Control Traffic is defined as packet flows that are essential 161 for stable operation of the administered network (see [RFC4594], 162 Section 3). This traffic is marked using a set of Class Selector 163 (CS) DSCPs. Such network control traffic is often a special case 164 within a provider network, and ingress traffic with these DSCP 165 markings can be remarked. 167 DSCP CS2 is recommended for the OAM (Operations, Administration, and 168 Maintenance) service class (see [RFC4594], Section 3.3). 170 The DCSP CS6 is recommended for local network control traffic. This 171 includes routing protocols and OAM traffic that are essential to 172 network operation administration, control and management. 173 Section 3.2 of RFC4594 [RFC4594] recommends that "CS6 marked packet 174 flows from untrusted sources (for example, end user devices) SHOULD 175 be dropped or remarked at ingress to the DiffServ network". 177 DSCP CS7 is reserved for future use by network control traffic. "CS7 178 marked packets SHOULD NOT be sent across peering points" [RFC4594]. 180 4. Remarking the DSCP 182 It is a feature of the DiffServ architecture that the Diffserv field 183 of packets can be remarked at domain boundaries (see section 2.3.4.2 184 of RFC2475 [RFC2475]). A DSCP can be remarked at the ingress of a 185 DiffServ domain. This can be with or without restoring the initial 186 DSCP marking at the egress of the same domain. The Diffserv field 187 can also be re-marked based upon common semantics and agreements 188 between providers at an exchange point. 190 If packets are received that are marked with an unknown or an 191 unexpected DSCP, RFC2474 [RFC2474] recommends forwarding the packet 192 using a default (best effort) treatment, but without changing the 193 DSCP. This seeks to support incremental DiffServ deployment in 194 existing networks as well as preserving DSCP markings by routers that 195 have not been configured to support DiffServ. (See also 196 Section 4.3). 198 Reports measuring existing deployments have categorised DSCP 199 remarking [Custura] [Barik] into the following six behaviours: 201 Bleach: bleaches all traffic (sets the DSCP to zero); 203 Bleach-ToS: sets the first three bits of the DCSP field to 0b000 204 (resets the 3 bits of the former ToS Precedence field) ; 206 Remark-ToS: sets the first three bits of the DCSP field to 0b001 207 (replace the 3 bits of the former ToS Precedence field); 209 Remark-ToS: sets the first three bits of the DCSP field to 0b010 210 (replace the 3 bits of the former ToS Precedence field); 212 Reset-low: sets the last three bits of the DCSP field to 0b000; 214 Reset-some-low: sets the last three bits of the DSCP field to 0b000, 215 unless the first two bits of the DSCP field are 0b11; 217 Remark: remarks all traffic to one or more particular (non-zero) 218 DSCP values. 220 4.1. Bleaching the DSCP Field 222 A specific form of remarking occurs when the DiffServ field is re- 223 assigned to the default treatment, CS0 (0x00). This results in 224 traffic being forwarded using the BE PHB. For example, AF31 (0x1a) 225 would be bleached to CS0. 227 Resetting all the bits of the DiffServ field to 0 is more prevalent 228 at the edge of the network, and rather less common in core networks 229 [Custura]. 231 4.2. IP Type of Service manipulations 233 The IETF defined ToS precedence field for IP packets in RFC1349 234 [RFC1349]. Since 1998, this practice has been deprecated by RFC2474 235 [RFC2474]. RFC 2474 defines codepoints 0x xxx000 as the Class 236 Selector codepoints, where PHBs selected by these codepoints MUST 237 meet the Class Selector PHB Requirements" described in Sec. 4.2.2.2 238 of that RFC. 240 However, practices based on ToS semantics have not yet been 241 eliminated from Internet, and these need to still currently be 242 considered when making new DCSP assignments. 244 4.2.1. Impact of ToS Precedence Bleaching 246 ToS precedence bleaching (/Bleach-ToS/) is a practice that resets to 247 zero the upper 3 bits of the DSCP field (the former ToS Precedence 248 field), leaving the lower bits unchanged. This behaviour is 249 distinctive of non-DiffServ aware routers and one of the more common 250 manipulations of the DiffServ field. 252 +-+-+-+-+-+-+ 253 |0 0 0|x x x| 254 +-+-+-+-+-+-+ 256 Figure showing the ToS bleaching pathology, based on Section 3 of 257 RFC1349 [RFC1349]. 259 If ToS precedence bleaching occurs, packets with a DSCP 'x' would be 260 remarked and then would be treated according to the PHB specified for 261 'x' & 0x07. For example, AF31 (0x1a) would be remarked to DSCP 2 262 (0x02). 264 A variation of this behaviour clears the top three bits of a DSCP, 265 unless these have values 0b110 or 0b111 (corresponding to CS6 and 266 CS7). As a result, a DSCP value greater than 48 decimal (0x30) is 267 less likely to be impacted by ToS precedence bleaching. 269 4.2.2. Impact of ToS Precedence Remarking 271 Practices based on ToS precedence RFC1349 [RFC1349] were deprecated 272 by RFC2474 [RFC2474]. These practices based on ToS semantics have 273 not yet been eliminated from Internet. 275 +-+-+-+-+-+-+ 276 |0 0 1|x x x| 277 +-+-+-+-+-+-+ 279 Figure showing the ToS remarking pathology, based on Section 3 of 280 RFC1349 [RFC1349]. 282 A less common behaviour, ToS precedence remarking /Remark-ToS/ sets 283 the upper three bits of the DSCP field to a non-zero value 284 corresponding to a CS PHB. This behaviour is distinctive of non- 285 DiffServ aware routers. 287 If remarking occurs, packets are treated using the PHB specified for 288 the resulting codepoint. For example, the AF31 DSCP (0x1a) could be 289 remarked to AF11 or AF21. 291 4.3. Remarking to a Particular DSCP 293 A network device might remark the Diffserv field of an IP packet 294 based on a local policy to avoid marking with a specific (set of) 295 DSCPs, /remark/. This is sometimes performed using a Multi-Field (MF) 296 classifier [RFC2475] [RFC3290] [RFC4594]. For example, a common 297 behaviour is to mark all traffic to a single DSCP, thus removing any 298 traffic differentiation (see Section 4.1). Bleaching (/Bleach/) is a 299 specific example of this. 301 In another example, some networks do not follow the recommendation in 302 RFC2475 [RFC2475], and instead remark packets with an unknown or 303 unexpected DSCP to the default class, CS0 (0x00) to ensure that 304 appropriate DSCPs are used within a DiffServ domain. (e.g., see 305 [RFC8100]). 307 5. Interpretation of the IP DSCP at Lower Layers 309 Transmission systems and subnetworks can, and do, utilise the 310 Diffserv field in an IP packet to select a lower layer forwarding 311 treatment. In many cases, this use is constrained by designs that 312 utilise fewer than 6 bits to express the service class, and therefore 313 infer mappings to a smaller L2 QoS field, for example, WiFi or Multi- 314 Protocol Label Switching (MPLS). 316 5.1. Mapping Specified for IEEE 802.11 318 << This section is currently incomplete. >> 320 A 3-bit Priority Code Point (PCP) is specified in the IEEE 802.1Q tag 321 to mark Ethernet frames to one of eight priority values. The value 322 zero indicates the default best effort treatment, and the value one 323 indicates a background traffic class. The remaining values indicate 324 increasing priority. Internet control traffic can be marked as six, 325 and network control is marked as seven. 327 Section 6 of RFC 8325 RFC 8325 [RFC8325] provides a brief overview of 328 IEEE 802.11 QoS. The IEEE 802.11 standards [IEEE-802-11] provides 329 MAC functions to support QoS in WLANs using Access Classes (AC). The 330 upstream User Priority (UP) in the 802.11 header has a 3-bit QoS 331 value. A DSCP can be mapped to the UP. Most existing WiFi 332 implementations [RFC8325] use a default mapping that utilises the 333 three most significant bits of the DiffServ Field to the 802.11 UP. 334 This is then in turn mapped to the four WiFi Multimedia (WMM) Access 335 Categories. 337 RFC 8325 [RFC8325] proposes several recommendations for mapping a 338 DSCP to an IEEE 802.11 UP for wired-to-wireless interconnection. The 339 DSCP value of a downstream IP packet can be used (e.g., the Control 340 And Provisioning of Wireless Access Points (CAPWAP) protocol, 341 RFC5415, maps an IP packet Diffserv field to the Diffserv field of 342 outer IP headier in a CAPWAP tunnel). 344 Some current constraints of WiFi mapping are discussed in section 2 345 of RFC 8325 [RFC8325]. A QoS profile can be used to limit the 346 maximum DSCP value used for the upstream and downstream traffic. 348 +-+-+-+-+-+-+ 349 |x x x|. . .| 350 +-+-+-+-+-+-+ 352 Figure showing the DSCP bits commonly mapped to the UP in 802.11. 354 This UP mapping can result in a specific DSCP remarking pathology. 355 In the upstream direction, some Access Points (APs) currently use a 356 default UP-to-DSCP mapping RFC8325 [RFC8325], wherein "DSCP values 357 are derived from the layer 2 UP values by multiplying the UP values 358 by eight (i.e., shifting the three UP bits to the left and adding 359 three additional zeros to generate a 6 bit DSCP value). This derived 360 DSCP value is then used for QoS treatment between the wireless AP and 361 the nearest classification and marking policy enforcement point 362 (which may be the centralized wireless LAN controller, relatively 363 deep within the network). Alternatively, in the case where there is 364 no other classification and marking policy enforcement point, then 365 this derived DSCP value will be used on the remainder of the Internet 366 path." This behaviour can result in remarking /Reset-low/. 368 RFC8325 [RFC8325] notes inconsistencies that can result from such 369 remarking, and recommends how to perform this remarking. 371 +-+-+-+-+-+-+ 372 |x x x|0 0 0| 373 +-+-+-+-+-+-+ 375 Figure showing the DSCP bits commonly mapped to the UP in 802.11. 377 5.2. Mappings Specified for MPLS 379 In MPLS there are eight MPLS Traffic Classes (TCs), which restricts 380 the number of different treatments (e.g., see [RFC5129]). RFC 5127 381 describes aggregation of DiffServ TCs [RFC5127], and introduces four 382 DiffServ Treatment Aggregates. Traffic marked with multiple DSCPs 383 can be forwarded in a single MPLS TC. 385 ITU-T Y.1566 [ITU-T-Y-1566] further defined a set of four common QoS 386 classes and four auxiliary classes to which a DSCP can be mapped when 387 interconnecting Ethernet, IP and MPLS networks. RFC8100 [RFC8100] 388 proposes four treatment aggregates for interconnection with four 389 defined DSCPs. This was motivated by the requirements of MPLS 390 network operators that use Short-Pipe tunnels, but can be applicable 391 to other networks, both MPLS and non-MPLS. 393 RFC8100 recommends preserving the notion of end-to-end service 394 classes, and recommends that the original DSCP marking is not changed 395 when treatment aggregates are used. The key requirement is that the 396 DSCP at the network ingress is restored at the network egress. This 397 is only feasible in general for a small number of DSCPs. In this 398 design, packets marked with other DSCPs can be re-marked (This can 399 result in the /Remark/ behaviour) or dealt with via an additional 400 agreement(s) among the operators of the interconnected networks. Use 401 of the MPLS Short Pipe Model favours re-marking unexpected DSCP 402 values to zero in the absence of an additional agreement(s), as 403 explained in RFC8100 [RFC8100]. This can result in the remarking: 404 /Bleach/. 406 5.3. Mapping Specified for Mobile Networks 408 << This section on Standardized 5QI to QoS characteristics mapping is 409 currently incomplete. >> 411 [SA-5G]. 413 The GSM Association (GSMA) defines four traffic classes and seven 414 associated DSCPs in their guidelines for IPX Provider networks GSMA 415 IR.34 [GSMA-IR-34]. This was previously specified as the Inter- 416 Service Provider IP Backbone Guidelines. 418 5.4. Mappings Specified for Carrier Ethernet 420 << This section on metro Ethernet Forum (MEF) mapping is currently 421 incomplete. >> 423 {{Ref to MEF23.1}} 425 5.5. Remarking as a Side-effect of Another Policy 427 The result of applying a QoS policy (such as matching the IP address, 428 or traffic reaching a rate limit) could also result in a packet being 429 remarked to a different DSCP when it is not admitted to a service. 430 Traffic marked with an EF and VA DSCP are often policed by such 431 policies. 433 Policies and L2 procedures can also result in remarking traffic as a 434 side-effect of other functions (e.g., in response to DDos). 436 6. Considerations for DSCP Selection 438 This section provides advice for the assignment of a new DSCP value. 440 Diffserv domains can use the codepoints in Pool 2 for local or 441 experimental use. 443 New IETF assignments are normally made in Pool 1, but can also be 444 made from Pool 3. 446 6.1. Effect of Bleaching 448 New DSCP assignments should consider the impact of bleaching, which 449 can limit the ability to provide the expected treatment end-to-end. 450 This is particularly important for cases where the codepoint is 451 intended to result in lower than best effort treatment, as was the 452 case when defining the LE PHB [RFC8622]. In this case, bleaching, or 453 remarking to "CS0" would result in elevating the lower effort traffic 454 to the default class. This is an example of priority inversion. 456 6.2. Where the proposed DSCP > 0x07 (7) 458 Although the IETF requires systems use DSCP marking semantics for the 459 former ToS field, the current recommendation is that any new 460 assignment where the codepoint is greater than 0x07 should consider 461 the semantics associated with the resulting DSCP when ToS precedence 462 bleaching is experienced. For example, it can be desirable to avoid 463 choosing a DSCP that could be remarked to LE, Lower Effort [RFC8622], 464 which could otherwise potentially result in a priority inversion in 465 the treatment. 467 6.3. Where the proposed DSCP < 0x07 (7) 469 ToS bleaching can unintentionally result in extra traffic aggregated 470 to the same DSCP. For example, after experiencing ToS bleaching, all 471 traffic marked AF11, AF21, AF31 and AF41 would be aggregated with 472 traffic marked with DSCP 2 (0x02), increasing the volume of traffic 473 which receives the treatment associated with DSCP 2. New DiffServ 474 codepoint assignments should consider unexpected consequences arising 475 from ToS bleaching. 477 6.4. Where the proposed DSCP&&0x07=0x01 479 As a consequence of assigning the LE PHB [RFC8622], the IETF 480 allocated the DSCP 000001b from Pool 3. 482 When making assignments where the DSCP has a format: xxx 001b, the 483 case of ToS Precedence Bleaching of a DSCP to a value of 0x01 needs 484 to be considered. ToS Precedence Bleaching will result in demoting 485 the traffic to the lower effort traffic class. Care should be taken 486 to consider the implications that a DSCP in this category could be 487 remarked as LE. 489 6.5. Impact on deployed infrastructure 491 Behaviour of deployed PHBs and conditioning treatments also needs to 492 be considered when assigning a new DSCP. In some domains, a network 493 operator can provide transparent transport of unknown or unassigned 494 DSCPs across their domain. In other domains, policing can ensure 495 that only traffic that matches a policy is permitted to use a 496 specific DSCP (e.g., as in MPLS TC). 498 7. Acknowledgments 500 The authors acknowledge the helpful discussions and analysis by Greg 501 White and Thomas Fossati in a draft concerning NQB. We look forward 502 to further comments and review. 504 8. IANA Considerations 506 This memo provides information to assist in considering new 507 assignments the IANA DSCP registry (https://www.iana.org/assignments/ 508 dscp-registry/dscp-registry.xhtml). 510 This memo includes no request to IANA. 512 9. Security Considerations 514 The security considerations are discussed in the security 515 considerations of each cited RFC. 517 10. References 519 10.1. Normative References 521 [DSCP-registry] 522 IANA, "Differentiated Services Field Codepoints (DSCP) 523 Registry". 525 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 526 Requirement Levels", BCP 14, RFC 2119, 527 DOI 10.17487/RFC2119, March 1997, 528 . 530 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 531 "Definition of the Differentiated Services Field (DS 532 Field) in the IPv4 and IPv6 Headers", RFC 2474, 533 DOI 10.17487/RFC2474, December 1998, 534 . 536 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 537 and W. Weiss, "An Architecture for Differentiated 538 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 539 . 541 [RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An 542 Informal Management Model for Diffserv Routers", RFC 3290, 543 DOI 10.17487/RFC3290, May 2002, 544 . 546 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 547 Guidelines for DiffServ Service Classes", RFC 4594, 548 DOI 10.17487/RFC4594, August 2006, 549 . 551 [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion 552 Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January 553 2008, . 555 [RFC8100] Geib, R., Ed. and D. Black, "Diffserv-Interconnection 556 Classes and Practice", RFC 8100, DOI 10.17487/RFC8100, 557 March 2017, . 559 [RFC8436] Fairhurst, G., "Update to IANA Registration Procedures for 560 Pool 3 Values in the Differentiated Services Field 561 Codepoints (DSCP) Registry", RFC 8436, 562 DOI 10.17487/RFC8436, August 2018, 563 . 565 10.2. Informative References 567 [Barik] Barik, R., Welzl, M., Elmokashfi, A., Dreibholz, T., and 568 S. Gjessing, "Can WebRTC QoS Work? A DSCP Measurement 569 Study", ITC 30, September 2018. 571 [Custura] Custura, A., Venne, A., and G. Fairhurst, "Exploring DSCP 572 modification pathologies in mobile edge networks", TMA , 573 2017. 575 [GSMA-IR-34] 576 GSM Association, "IR.34 Guidelines for IPX Provider 577 networks (Previously Inter-Service Provider IP Backbone 578 Guidelines)", IR 34, 2017. 580 [I-D.ietf-tsvwg-nqb] 581 White, G. and T. Fossati, "A Non-Queue-Building Per-Hop 582 Behavior (NQB PHB) for Differentiated Services", draft- 583 ietf-tsvwg-nqb-03 (work in progress), November 2020. 585 [I-D.learmonth-rfc1226-bis] 586 Learmonth, I., "Internet Protocol Encapsulation of AX.25 587 Frames", draft-learmonth-rfc1226-bis-03 (work in 588 progress), May 2020. 590 [IEEE-802-11] 591 IEEE, "Wireless LAN Medium Access Control (MAC) and 592 Physical Layer (PHY) Specifications", IEEE 802.11, 2007. 594 [ITU-T-Y-1566] 595 ITU-T, "Quality of Service Mapping and Interconnection 596 Between Ethernet, Internet Protocol and Multiprotocol 597 Label Switching Networks", ITU-T Y.1566, 2012. 599 [RFC1349] Almquist, P., "Type of Service in the Internet Protocol 600 Suite", RFC 1349, DOI 10.17487/RFC1349, July 1992, 601 . 603 [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of 604 Diffserv Service Classes", RFC 5127, DOI 10.17487/RFC5127, 605 February 2008, . 607 [RFC5160] Levis, P. and M. Boucadair, "Considerations of Provider- 608 to-Provider Agreements for Internet-Scale Quality of 609 Service (QoS)", RFC 5160, DOI 10.17487/RFC5160, March 610 2008, . 612 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 613 Writing an IANA Considerations Section in RFCs", BCP 26, 614 RFC 8126, DOI 10.17487/RFC8126, June 2017, 615 . 617 [RFC8325] Szigeti, T., Henry, J., and F. Baker, "Mapping Diffserv to 618 IEEE 802.11", RFC 8325, DOI 10.17487/RFC8325, February 619 2018, . 621 [RFC8622] Bless, R., "A Lower-Effort Per-Hop Behavior (LE PHB) for 622 Differentiated Services", RFC 8622, DOI 10.17487/RFC8622, 623 June 2019, . 625 [SA-5G] 3GPP, "System Architecture for 5G", TS 23.501, 2019. 627 Appendix A. Revision Notes 629 Note to RFC-Editor: please remove this entire section prior to 630 publication. 632 o Individual draft -00 634 o Individual draft -01; Comments from Martin Duke; Brian Carpenter; 635 Ruediger Geib, and revsisions to improve language consistency. 637 Authors' Addresses 639 Ana Custura 640 University of Aberdeen 641 School of Engineering 642 Fraser Noble Building 643 Aberdeen AB24 3UE 644 UK 646 Email: ana@erg.abdn.ac.uk 648 Godred Fairhurst 649 University of Aberdeen 650 School of Engineering 651 Fraser Noble Building 652 Aberdeen AB24 3UE 653 UK 655 Email: gorry@erg.abdn.ac.uk 656 Raffaello Secchi 657 University of Aberdeen 658 School of Engineering 659 Fraser Noble Building 660 Aberdeen AB24 3UE 661 UK 663 Email: r.secchi@abdn.ac.uk