idnits 2.17.1 draft-ietf-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 (24 January 2022) is 823 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: 28 July 2022 University of Aberdeen 6 24 January 2022 8 Considerations for Assigning a new Recommended DiffServ Codepoint (DSCP) 9 draft-ietf-tsvwg-dscp-considerations-01 11 Abstract 13 This document discusses considerations for assigning a new 14 recommended DiffServ Code Point (DSCP). It considers the common 15 remarking behaviours that the Diffserv field might be subjected to 16 along an Internet path. It also notes some implications of using a 17 specific DSCP. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 28 July 2022. 36 Copyright Notice 38 Copyright (c) 2022 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Revised BSD License text as 47 described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Revised BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 54 3. Current usage of DSCPs . . . . . . . . . . . . . . . . . . . 4 55 3.1. IP-Layer Semantics . . . . . . . . . . . . . . . . . . . 4 56 3.2. Network Control Traffic . . . . . . . . . . . . . . . . . 5 57 4. Remarking the DSCP . . . . . . . . . . . . . . . . . . . . . 5 58 4.1. Bleaching the DSCP Field . . . . . . . . . . . . . . . . 6 59 4.2. IP Type of Service manipulations . . . . . . . . . . . . 6 60 4.2.1. Impact of ToS Precedence Bleaching . . . . . . . . . 7 61 4.2.2. Impact of ToS Precedence Remarking . . . . . . . . . 7 62 4.3. Remarking to a Particular DSCP . . . . . . . . . . . . . 8 63 5. Interpretation of the IP DSCP at Lower Layers . . . . . . . . 8 64 5.1. Mapping Specified for IEEE 802 . . . . . . . . . . . . . 8 65 5.1.1. Mapping Specified for IEEE 802.1 . . . . . . . . . . 8 66 5.1.2. Mapping Specified for IEEE 802.11 . . . . . . . . . . 9 67 5.2. Mappings Specified for MPLS . . . . . . . . . . . . . . . 10 68 5.2.1. Mappings Specified for MPLS . . . . . . . . . . . . . 11 69 5.2.2. Mappings Specified for MPLS Short Pipe . . . . . . . 11 70 5.3. Mapping Specified for Mobile Networks . . . . . . . . . . 12 71 5.4. Mappings Specified for Carrier Ethernet . . . . . . . . . 13 72 5.5. Remarking as a Side-effect of Another Policy . . . . . . 13 73 5.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 6. Considerations for DSCP Selection . . . . . . . . . . . . . . 14 75 6.1. Effect of Bleaching . . . . . . . . . . . . . . . . . . . 14 76 6.2. Where the proposed DSCP > 0x07 (7) . . . . . . . . . . . 14 77 6.3. Where the proposed DSCP < 0x07 (7) . . . . . . . . . . . 14 78 6.3.1. Where the proposed DSCP&&0x07=0x01 . . . . . . . . . 14 79 6.4. Impact on deployed infrastructure . . . . . . . . . . . . 15 80 6.5. Questions to guide discussion of a proposed new DSCP . . 15 81 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 83 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 85 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 86 10.2. Informative References . . . . . . . . . . . . . . . . . 17 87 Appendix A. Revision Notes . . . . . . . . . . . . . . . . . . . 19 88 Appendix B. Table of DSCP Values . . . . . . . . . . . . . . . . 20 89 Appendix C. Example of operational practice and operator 90 requirements. . . . . . . . . . . . . . . . . . . . . . . 20 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 93 1. Introduction 95 The Differentiated Services (DiffServ) architecture has been deployed 96 in many networks. It provides differentiated traffic forwarding 97 based on the value of the Diffserv field [RFC2474] carried in the IP 98 packet header. 100 Internet traffic can be associated with a service class, and 101 categorised into Behavior Aggregates [RFC4594]. In IP networks, 102 these are associated with a DiffServ Code Point (DSCP) [RFC2474]. 103 Each DSCP is mapped to a Per Hop Behaviour (PHB). A treatment 104 aggregate is concerned only with the forwarding treatment of the 105 aggregated traffic, which could be marked with multiple DSCPs 106 [RFC5127]. Treatment differentiation can be realised using a variety 107 of schedulers and queues, and also by algorithms that implement 108 access to the physical media. 110 Application -> Service 111 Traffic Class 112 | 113 Behavior -> DiffServ -> Per Hop 114 Aggregate Codepoint Behavior 115 | 116 Treatment -> Schedule 117 Aggregate Queue, Drop 119 Figure showing the role of DSCPs in classifying IP traffic for 120 differential network treatment. 122 This document discusses considerations for assigning a new DSCP. It 123 considers some commonly observed DSCP remarking behaviours that might 124 be experienced along an Internet path. It also describes some packet 125 forwarding treatments that a packet with a specific DSCP can expect 126 to receive when forwarded across a link or subnetwork. 128 The document is motivated by new opportunities to use DiffServ end- 129 to-end across multiple domains, such as [I-D.ietf-tsvwg-nqb], 130 proposals to build mechanisms using DSCPs in other standards-setting 131 organisations, and the desire to use a common set of DSCPs across a 132 range of infrastructure (e.g., [RFC8622], [I-D.ietf-tsvwg-nqb], 133 [I-D.learmonth-rfc1226-bis]). 135 2. Requirements Language 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in RFC 2119 [RFC2119]. 141 3. Current usage of DSCPs 143 This section describes current usage of DSCPs. 145 3.1. IP-Layer Semantics 147 The DiffServ architecture specifies use of the Diffserv field in the 148 IPv4 and IPv6 packet headers to carry one of 64 distinct DSCP values. 149 Within a given administrative boundary, each DSCP value can be mapped 150 to a distinct PHB[RFC2474]. When a new PHB is standardized, a 151 recommended DSCP value among those 64 values is normally reserved for 152 that PHB. 154 The DSCP space is divided into three pools for the purpose of 155 assignment and management [DSCP-registry]. The pools are defined in 156 the following table (where 'x' refers to either a bit position with 157 value '0' or '1'). 159 DSCP Pool 1 A pool of 32 codepoints with a format 0bxxxxx0, to be 160 assigned by IANA Standards Action [RFC8126]. 162 DSCP Pool 2 A pool of 16 codepoints with a format 0bxxxx11, reserved 163 for experimental or local (private) use by network operators (see 164 sections 4.1 and 4.2 of [RFC8126]. 166 DSCP Pool 3 A pool of 16 codepoints with a 0bxxxx01. This was 167 initially available for experimental or local use, but which was 168 originally specified to be preferentially utilised for 169 standardized assignments if Pool 1 is ever exhausted. Pool 3 170 codepoints are now utilised for standardized assignments and are 171 no longer available for experimental or local use [RFC8436]. 173 The DiffServ architecture allows forwarding treatments to be 174 associated with each DSCP, and the RFC series describes some of these 175 as PHBs. Although DSCPs are intended to identify specific treatment 176 requirements, multiple DSCPs might also be mapped (aggregated) to the 177 same forwarding treatment. Several IP standards map treatment 178 aggregates to DSCPs, that might result in remarking: RFC5160 179 [RFC5160] suggests Meta-QoS-Classes to help enable deployment of 180 standardized end-to-end QoS classes. 182 Note: A DSCP is sometimes referred to by name, such as "CS1", and 183 sometimes by a decimal, hex, or binary value [DSCP-registry]. 185 3.2. Network Control Traffic 187 Network Control Traffic is defined as packet flows that are essential 188 for stable operation of the administered network (see [RFC4594], 189 Section 3). This traffic is marked using a set of Class Selector 190 (CS) DSCPs. Such network control traffic is often a special case 191 within a provider network, and ingress traffic with these DSCP 192 markings can be remarked. 194 DSCP CS2 is recommended for the OAM (Operations, Administration, and 195 Maintenance) service class (see [RFC4594], Section 3.3). 197 The DSCP CS6 is recommended for local network control traffic. This 198 includes routing protocols and OAM traffic that are essential to 199 network operation administration, control and management. 200 Section 3.2 of RFC4594 [RFC4594] recommends that "CS6 marked packet 201 flows from untrusted sources (for example, end user devices) SHOULD 202 be dropped or remarked at ingress to the DiffServ network". 204 DSCP CS7 is reserved for future use by network control traffic. "CS7 205 marked packets SHOULD NOT be sent across peering points" [RFC4594]. 207 4. Remarking the DSCP 209 It is a feature of the DiffServ architecture that the Diffserv field 210 of packets can be remarked at domain boundaries (see section 2.3.4.2 211 of RFC2475 [RFC2475]). A DSCP can be remarked at the ingress of a 212 DiffServ domain. This can be with or without restoring the initial 213 DSCP marking at the egress of the same domain. The Diffserv field 214 can also be re-marked based upon common semantics and agreements 215 between providers at an exchange point. 217 If packets are received that are marked with an unknown or an 218 unexpected DSCP, RFC2474 [RFC2474] recommends forwarding the packet 219 using a default (best effort) treatment, but without changing the 220 DSCP. This seeks to support incremental DiffServ deployment in 221 existing networks as well as preserving DSCP markings by routers that 222 have not been configured to support DiffServ. (See also 223 Section 4.3). 225 Reports measuring existing deployments have categorised DSCP 226 remarking [Custura] [Barik] into the following five behaviours: 228 Bleach: bleaches all traffic (sets the DSCP to zero); 230 Bleach-ToS-Precedence: set the first three bits of the DSCP field to 231 0b000 (reset the 3 bits of the former ToS Precedence field) ; 233 Bleach-some-ToS: set the first three bits of the DSCP field to 0b000 234 (reset the 3 bits of the former ToS Precedence field), unless the 235 first two bits of the DSCP field are 0b11; 237 Remark-ToS: set the first three bits of the DSCP field to any value 238 different than 0b000 (replace the 3 bits of the former ToS 239 Precedence field); 241 Bleach-low: set the last three bits of the DSCP field to 0b000; 243 Bleach-some-low: set the last three bits of the DSCP field to 0b000, 244 unless the first two bits of the DSCP field are 0b11; 246 Remark: remarks all traffic to one or more particular (non-zero) 247 DSCP values. 249 4.1. Bleaching the DSCP Field 251 A specific form of remarking occurs when the DiffServ field is re- 252 assigned to the default treatment, CS0 (0x00). This results in 253 traffic being forwarded using the BE PHB. For example, AF31 (0x1a) 254 would be bleached to CS0. 256 Resetting all the bits of the DiffServ field to 0 is more prevalent 257 at the edge of the network, and rather less common in core networks 258 [Custura]. 260 4.2. IP Type of Service manipulations 262 The IETF first defined ToS precedence for IP packets [RFC0791], 263 updated by specification as a part of the ToS Field RFC1349 264 [RFC1349]. Since 1998, this practice has been deprecated by RFC2474 265 [RFC2474]. RFC 2474 defines codepoints 0x xxx000 as the Class 266 Selector codepoints, where PHBs selected by these codepoints MUST 267 meet the Class Selector PHB Requirements" described in Sec. 4.2.2.2 268 of that RFC. 270 However, practices based on ToS semantics have not yet been 271 eliminated from Internet, and need to still be considered when making 272 new DSCP assignments. 274 4.2.1. Impact of ToS Precedence Bleaching 276 ToS Precedence Bleaching (/Bleach-ToS-Precedence/) is a practice that 277 resets to zero the upper 3 bits of the DSCP field (the former ToS 278 Precedence field), leaving the lower bits unchanged (see section 279 4.2.1 of RFC2474 [RFC2474]). This behaviour is distinctive of non- 280 DiffServ aware routers and one of the more common manipulations of 281 the DiffServ field. 283 +-+-+-+-+-+-+ 284 |0 0 0|x x x| 285 +-+-+-+-+-+-+ 287 Figure showing the ToS Precedence Bleaching (/Bleach-ToS-Precedence/) 288 pathology, based on Section 3 of RFC1349 [RFC1349]. 290 If ToS Precedence Bleaching occurs, packets with a DSCP 'x' would be 291 remarked and then would be treated according to the PHB specified for 292 'x' & 0x07. For example, AF31 (0x1a) would be remarked to DSCP 2 293 (0x02). 295 A variation of this behaviour clears the top three bits of a DSCP, 296 unless these have values 0b110 or 0b111 (corresponding to the CS6 and 297 CS7 codepoints). As a result, a DSCP value greater than 48 decimal 298 (0x30) is less likely to be impacted by ToS Precedence Bleaching. 300 4.2.2. Impact of ToS Precedence Remarking 302 Practices based on ToS Precedence Remarking (/Remark-ToS/) RFC1349 303 [RFC1349] were deprecated by RFC2474 [RFC2474]. These practices 304 based on ToS semantics have not yet been eliminated from deployed 305 networks. 307 +-+-+-+-+-+-+ 308 |0 0 1|x x x| 309 +-+-+-+-+-+-+ 311 Figure showing an example of ToS Remarking (/Remark/) pathology, 312 based on Section 3 of RFC1349 [RFC1349]. 314 A less common behaviour, ToS precedence remarking sets the upper 315 three bits of the DSCP field to a non-zero value corresponding to a 316 CS PHB. This behaviour is distinctive of non-DiffServ aware routers. 318 If remarking occurs, packets are treated using the PHB specified for 319 the resulting codepoint. For example, the AF31 DSCP (0x1a) could be 320 remarked to either AF11 or AF21. 322 4.3. Remarking to a Particular DSCP 324 A network device might remark the Diffserv field of an IP packet 325 based on a local policy with a specific (set of) DSCPs, /Remark/. 326 This is sometimes performed using a Multi-Field (MF) classifier 327 [RFC2475] [RFC3290] [RFC4594]. For example, a common behaviour is to 328 mark all traffic to a single DSCP, thus removing any traffic 329 differentiation (see Section 4.1). Bleaching (/Bleach/) is a 330 specific example of this that remarks to CS0 (0x00). 332 In another example, some networks do not follow the recommendation in 333 RFC2475 [RFC2475], and instead remark packets with an unknown or 334 unexpected DSCP to the default class, CS0 (0x00) to ensure that 335 appropriate DSCPs are used within a DiffServ domain. (e.g., see 336 [RFC8100]). 338 5. Interpretation of the IP DSCP at Lower Layers 340 Transmission systems and subnetworks can, and do, utilise the 341 Diffserv field in an IP packet to select a lower layer forwarding 342 treatment. In many cases, this use is constrained by designs that 343 utilise fewer than 6 bits to express the service class, and therefore 344 infer mappings to a smaller L2 QoS field, for example, WiFi or Multi- 345 Protocol Label Switching (MPLS). 347 5.1. Mapping Specified for IEEE 802 349 << This section is currently seeking more input. >> 351 5.1.1. Mapping Specified for IEEE 802.1 353 A 3-bit Priority Code Point (PCP) is specified in the IEEE 802.1Q tag 354 to mark Ethernet frames to one of eight priority values 355 [IEEE-802-1Q]. The value zero indicates the default best effort 356 treatment, and the value one indicates a background traffic class. 357 The remaining values indicate increasing priority. Internet control 358 traffic can be marked as six, and network control is marked as seven. 360 The mapping specified in [IEEE-802-1Q] revises a previous standard 361 [IEEE-802-1D], in an effort to align with Diffserv practice: the 362 traffic types are specified to match the first three bits of a 363 suitable DSCP (for example, Voice, which has PCP value 5, matches the 364 first three bits of EF). However, [IEEE-802-1D] maps both PCP1 365 (Background) and PCP2 (Spare) to indicate lower priority than PCP0, 366 RFC 8622. Therefore, different behaviour is expected depending on 367 the age of deployed devices. 369 5.1.2. Mapping Specified for IEEE 802.11 371 Section 6 of RFC 8325 [RFC8325] provides a brief overview of IEEE 372 802.11 QoS. The IEEE 802.11 standards [IEEE-802-11] provide MAC 373 functions to support QoS in WLANs using Access Classes (AC). The 374 upstream User Priority (UP) in the 802.11 header has a 3-bit QoS 375 value. A DSCP can be mapped to the UP. Most existing WiFi 376 implementations [RFC8325] use a default mapping that utilises the 377 three most significant bits of the DiffServ Field to the 802.11 UP. 378 This is then in turn mapped to the four WiFi Multimedia (WMM) Access 379 Categories. 381 +-+-+-+-+-+-+ 382 |x x x|. . .| 383 +-+-+-+-+-+-+ 385 Figure showing the DSCP bits commonly mapped to the UP in 802.11. 387 RFC8325 [RFC8325] notes inconsistencies that can result from such 388 remarking, and recommends how to perform this remarking. It proposes 389 several recommendations for mapping a DSCP to an IEEE 802.11 UP for 390 wired-to-wireless interconnection. The recommendation includes 391 mapping network control traffic CS6 and CS7, as well unassigned 392 codepoints, to UP 0. 394 In the upstream direction (wireless-to-wired interconnections, this 395 mapping can result in a specific DSCP remarking pathology. Some 396 Access Points (APs) currently use a default UP-to-DSCP mapping 397 RFC8325 [RFC8325], wherein "DSCP values are derived from the layer 2 398 UP values by multiplying the UP values by eight (i.e., shifting the 399 three UP bits to the left and adding three additional zeros to 400 generate a 6 bit DSCP value). This derived DSCP value is then used 401 for QoS treatment between the wireless AP and the nearest 402 classification and marking policy enforcement point (which may be the 403 centralized wireless LAN controller, relatively deep within the 404 network). Alternatively, in the case where there is no other 405 classification and marking policy enforcement point, then this 406 derived DSCP value will be used on the remainder of the Internet 407 path." This behaviour can result in remarking /Reset-low/. 409 +-+-+-+-+-+-+ 410 |x x x|0 0 0| 411 +-+-+-+-+-+-+ 413 Figure showing the pathology resulting from deriving from UP-to-DSCP 414 mapping in some 802.11 networks. 416 An alternative to UP-to-DSCP remapping is using the DSCP value of a 417 downstream IP packet (e.g., the Control And Provisioning of Wireless 418 Access Points (CAPWAP) protocol, RFC5415, maps an IP packet Diffserv 419 field to the Diffserv field of outer IP headier in a CAPWAP tunnel). 421 Some current constraints of WiFi mapping are discussed in section 2 422 of [RFC8325]. A QoS profile can be used to limit the maximum DSCP 423 value used for the upstream and downstream traffic. 425 5.2. Mappings Specified for MPLS 427 << This section is currently seeking more input. >> 429 Multi-Protocol Label Switching (MPLS) specified eight MPLS Traffic 430 Classes (TCs), which restricts the number of different treatments 431 (e.g., see [RFC5129]). RFC 5127 describes aggregation of DiffServ 432 TCs [RFC5127], and introduces four DiffServ Treatment Aggregates. 433 Traffic marked with multiple DSCPs can be forwarded in a single MPLS 434 TC. 436 There are three Label-Switched Router (LSR) behaviors: the Pipe, the 437 Short Pipe and the Uniform Model [RFC3270]. These only differ when a 438 LSP performs a push or a pop. 440 5.2.1. Mappings Specified for MPLS 442 RFC3270 [RFC3270] defines a flexible solution for support of DiffServ 443 over MPLS networks. This allows an MPLS network administrator to 444 select how BAs (marked by DSCPs) are mapped onto Label Switched Paths 445 (LSPs) to best match the DiffServ, Traffic Engineering and protection 446 objectives within their particular network. 448 Mappings from the IP DSCP to the MPLS header are defined in 449 Section 4.2 of [RFC3270]. 451 Using the Pipe Model, the "LSP Diff-Serv Information" is conveyed to 452 the LSP Egress so that its forwarding treatment can be based on the 453 IP DSCP. 455 When Penultimate Hop Popping (PHP) is used, the Penultimate LSR needs 456 to be aware of the set of PHB to encapsulation mappings for the label 457 corresponding to the exposed header to perform DiffServ Information 458 Encoding (Section 2.5.2 of RFC3270 [RFC3270]). 460 5.2.2. Mappings Specified for MPLS Short Pipe 462 << This section is currently seeking more input. >> 464 The Short Pipe Model is an optional variation of the Pipe Model 465 [RFC3270]. 467 ITU-T Y.1566 [ITU-T-Y-1566] further defined a set of four common QoS 468 classes and four auxiliary classes to which a DSCP can be mapped when 469 interconnecting Ethernet, IP and MPLS networks. RFC8100 [RFC8100] 470 proposes four treatment aggregates for interconnection with four 471 defined DSCPs. This was motivated by the requirements of MPLS 472 network operators that use Short-Pipe tunnels, but can be applicable 473 to other networks, both MPLS and non-MPLS. 475 RFC8100 recommends preserving the notion of end-to-end service 476 classes, and recommends that the original DSCP marking is not changed 477 when treatment aggregates are used. The key requirement is that the 478 DSCP at the network ingress is restored at the network egress. This 479 is only feasible in general for a small number of DSCPs. In this 480 design, packets marked with other DSCPs can be re-marked (This can 481 result in the /Remark/ behaviour) or dealt with via an additional 482 agreement(s) among the operators of the interconnected networks. Use 483 of the MPLS Short Pipe Model favours re-marking unexpected DSCP 484 values to zero in the absence of an additional agreement(s), as 485 explained in RFC8100 [RFC8100]. This can result in bleaching 486 (/Bleach/). 488 +--------------------------------------+--------+ 489 | RFC8100 | DSCP | 490 | Agg. Class | | 491 +--------------------------------------+--------+ 492 |Telephony Service Treatment Aggregate | EF | 493 | | VA | 494 +--------------------------------------+--------+ 495 |Bulk Real-Time Treatment Aggregate | AF41 | 496 | May be added | (AF42) | 497 | May be added | (AF43) | 498 +--------------------------------------+--------+ 499 |Assured Elastic Treatment Aggregate | AF31 | 500 | | AF32 | 501 | Reserved for the extension of PHBs| (AF33) | 502 +--------------------------------------+--------+ 503 |Default / Elastic Treatment Aggregate | BE/CS0 | 504 +--------------------------------------+--------+ 505 |Network Control: Local Use | CS6 | 506 +--------------------------------------+--------+ 508 Figure showing the short-pipe MPLS mapping from RFC 8100. 510 5.3. Mapping Specified for Mobile Networks 512 << This section is currently seeking more input. >> 514 Mobile LTE and 5G standards have evolved from older UMTS standards, 515 and are Diffserv aware. LTE (4G) and 5G standards [SA-5G] identify 516 traffic classes at the interface between User Equipment (UE) and the 517 mobile Packet Core network by QCI (QoS Class Identifiers) and 5QI (5G 518 QoS Identifier). The 3GPP standards do not define or recommend any 519 specific mappings between each QCI or 5QI and Diffserv (and mobile 520 QCIs are based on several criteria service class definitions). The 521 way packets are mapped at the Packet Gateway (P-GW) boundary is 522 determined by operators. However, TS 23.107 (version 16.0.0, applies 523 to LTE and below) mandates that Differentiated Services, defined by 524 IETF, shall be used to interoperate with IP backbone networks. 526 The GSM Association (GSMA) has defined four aggregated classes and 527 seven associated PHBs in their guidelines for IPX Provider networks 528 GSMA IR.34 [GSMA-IR-34]. This was previously specified as the Inter- 529 Service Provider IP Backbone Guidelines, and provides a mobile ISP to 530 ISP QoS mapping mechanism, and interconnection with other IP networks 531 in the general Internet. This describes the case where the DSCP 532 marking from a Service Provider cannot be trusted (depending on the 533 agreement between the Service Provider and its IPX Provider), 534 allowing the IPX Provider to correct the DSCP value to a static 535 default value. 537 +---------------+-------+ 538 | GSMA IR.34 | PHB | 539 | Agg. Class | | 540 +---------------+-------+ 541 |Conversational | EF | 542 +---------------+-------+ 543 | Streaming | AF41 | 544 +---------------+-------+ 545 | Interactive | AF31 | 546 + +-------+ 547 | (ordered by | AF32 | 548 + priority, +-------+ 549 | AF3 highest) | AF21 | 550 + +-------+ 551 | | AF11 | 552 +---------------+-------+ 553 | Background | CS0 | 554 +---------------+-------+ 556 Figure showing the PHB mapping from GSMA IR.34 [GSMA-IR-34]. 558 5.4. Mappings Specified for Carrier Ethernet 560 << This section is currently seeking more input. >> 562 Metro Ethernet Forum (MEF) provides mappings of DSCP codepoints at 563 the IP layer to quality of service markings in the Ethernet frame 564 headers MEF 23.1 [MEF23.1]. 566 5.5. Remarking as a Side-effect of Another Policy 568 The result of applying a QoS policy (such as matching the IP address, 569 or traffic reaching a rate limit) could also result in a packet being 570 remarked to a different DSCP (/Remark/) when it is not admitted to a 571 service. Traffic marked with an EF and VA DSCP are often policed by 572 such policies. 574 Policies and L2 procedures can also result in remarking traffic as a 575 side-effect of other functions (e.g., in response to DDos). 577 5.6. Summary 579 << This section might contain a summary table >> 581 6. Considerations for DSCP Selection 583 This section provides advice for the assignment of a new DSCP value. 584 It identifies known issues that might influence the finally assigned 585 DSCP, followed by a summary of considerations for assignment of a new 586 DSCP. 588 6.1. Effect of Bleaching 590 New DSCP assignments should consider the impact of bleaching, which 591 can limit the ability to provide the expected treatment end-to-end. 592 This is particularly important for cases where the codepoint is 593 intended to result in lower than best effort treatment, as was the 594 case when defining the LE PHB [RFC8622]. In this case, bleaching, or 595 remarking to "CS0" would result in elevating the lower effort traffic 596 to the default class. This is an example of priority inversion. 598 6.2. Where the proposed DSCP > 0x07 (7) 600 Although the IETF specifications require systems to use DSCP marking 601 semantics in place of methods based on the former ToS field, the 602 current recommendation is that any new assignment where the codepoint 603 is greater than 0x07 should consider the semantics associated with 604 the resulting DSCP when ToS precedence bleaching is experienced. For 605 example, it can be desirable to avoid choosing a DSCP that could be 606 remarked to LE, Lower Effort [RFC8622], which could otherwise 607 potentially result in a priority inversion in the treatment. 609 6.3. Where the proposed DSCP < 0x07 (7) 611 ToS bleaching can unintentionally result in extra traffic aggregated 612 to the same DSCP. For example, after experiencing ToS Bleaching, all 613 traffic marked AF11, AF21, AF31 and AF41 would be aggregated with 614 traffic marked with DSCP 2 (0x02), increasing the volume of traffic 615 which receives the treatment associated with DSCP 2. New DiffServ 616 codepoint assignments should consider unexpected consequences arising 617 from ToS bleaching. 619 6.3.1. Where the proposed DSCP&&0x07=0x01 621 As a consequence of assigning the LE PHB [RFC8622], the IETF 622 allocated the DSCP 000001b from Pool 3. 624 When making assignments where the DSCP has a format: xxx 001b, the 625 case of ToS Precedence Bleaching (/Bleach-ToS-Precedence/) of a DSCP 626 to a value of 0x01 needs to be considered. ToS Precedence Bleaching 627 will result in demoting the traffic to the lower effort traffic 628 class. Care should be taken to consider the implications that a DSCP 629 in this category could be remarked as LE. 631 6.4. Impact on deployed infrastructure 633 Behaviour of deployed PHBs and conditioning treatments also needs to 634 be considered when assigning a new DSCP. In some domains, a network 635 operator can provide transparent transport of unknown or unassigned 636 DSCPs across their domain. In other domains, policing can ensure 637 that only traffic that matches a policy is permitted to use a 638 specific DSCP (e.g., as in MPLS TC). 640 6.5. Questions to guide discussion of a proposed new DSCP 642 A series of questions emerge that need to be answered when 643 considering a proposal to the IETF that requests a new assignment. 644 These questions include: 646 * How is the proposed service class characterised? - What are the 647 characteristics of the traffic to be carried? What are the 648 expectations for treatment? 650 * Service Classes that can utilise existing PHBs should use assigned 651 DSCPs to mark their traffic: Could the request be met by using an 652 existing IETF DSCP? How would the proposed new DSCP be used to 653 map traffic to a new or existing PHB? 655 * Diffserv domains can use the codepoints in Pool 2 for local or 656 experimental use, without any IETF specification for the DSCP or 657 associated PHB: Could the request be met by using a DSCP chosen 658 from Pool 2? Or is the DSCP intended to be used at network 659 interconnections? 661 * This documents describes some observed marking behaviors (see also 662 below): What is the expected effect of currently-deployed 663 remarking on the end-to-end service? 665 * Many DiffServ domains support only a small number of treatment 666 aggregates: What are the effects of treatment aggregation on the 667 proposed method? 669 * This documents describes some observed treatments by layers below 670 IP: What are the implications of using the proposed DSCP on the 671 expected lower layers over which the traffic may be forwarded? 673 Specification of a new recommended DSCP requires Standards Action. 674 RFC2474 states: "Each standardized PHB MUST have an associated 675 RECOMMENDED codepoint". If approved, new IETF assignments are 676 normally made by IANA in Pool 1, but the IETF can request assignments 677 to be made from Pool 3 [RFC8436]. 679 7. Acknowledgments 681 The authors acknowledge the helpful discussions and analysis by Greg 682 White and Thomas Fossati in a draft concerning NQB. We look forward 683 to further comments and review. 685 8. IANA Considerations 687 This memo provides information to assist in considering new 688 assignments to the IANA DSCP registry 689 (https://www.iana.org/assignments/dscp-registry/dscp-registry.xhtml). 691 This memo includes no request to IANA, or update to the IANA 692 procedures. 694 9. Security Considerations 696 The security considerations are discussed in the security 697 considerations of each cited RFC. 699 10. References 701 10.1. Normative References 703 [DSCP-registry] 704 IANA, "Differentiated Services Field Codepoints (DSCP) 705 Registry". 707 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 708 Requirement Levels", BCP 14, RFC 2119, 709 DOI 10.17487/RFC2119, March 1997, 710 . 712 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 713 "Definition of the Differentiated Services Field (DS 714 Field) in the IPv4 and IPv6 Headers", RFC 2474, 715 DOI 10.17487/RFC2474, December 1998, 716 . 718 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 719 and W. Weiss, "An Architecture for Differentiated 720 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 721 . 723 [RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An 724 Informal Management Model for Diffserv Routers", RFC 3290, 725 DOI 10.17487/RFC3290, May 2002, 726 . 728 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 729 Guidelines for DiffServ Service Classes", RFC 4594, 730 DOI 10.17487/RFC4594, August 2006, 731 . 733 [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion 734 Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January 735 2008, . 737 [RFC8100] Geib, R., Ed. and D. Black, "Diffserv-Interconnection 738 Classes and Practice", RFC 8100, DOI 10.17487/RFC8100, 739 March 2017, . 741 [RFC8436] Fairhurst, G., "Update to IANA Registration Procedures for 742 Pool 3 Values in the Differentiated Services Field 743 Codepoints (DSCP) Registry", RFC 8436, 744 DOI 10.17487/RFC8436, August 2018, 745 . 747 10.2. Informative References 749 [Barik] Barik, R., Welzl, M., Elmokashfi, A., Dreibholz, T., and 750 S. Gjessing, "Can WebRTC QoS Work? A DSCP Measurement 751 Study", ITC 30, September 2018. 753 [Custura] Custura, A., Venne, A., and G. Fairhurst, "Exploring DSCP 754 modification pathologies in mobile edge networks", TMA , 755 2017. 757 [GSMA-IR-34] 758 GSM Association, "IR.34 Guidelines for IPX Provider 759 networks (Previously Inter-Service Provider IP Backbone 760 Guidelines)", IR 34, 2017. 762 [I-D.ietf-tsvwg-nqb] 763 White, G. and T. Fossati, "A Non-Queue-Building Per-Hop 764 Behavior (NQB PHB) for Differentiated Services", Work in 765 Progress, Internet-Draft, draft-ietf-tsvwg-nqb-03, 2 766 November 2020, . 769 [I-D.learmonth-rfc1226-bis] 770 Learmonth, I., "Internet Protocol Encapsulation of AX.25 771 Frames", Work in Progress, Internet-Draft, draft- 772 learmonth-rfc1226-bis-03, 19 May 2020, 773 . 776 [IEEE-802-11] 777 IEEE, "Wireless LAN Medium Access Control (MAC) and 778 Physical Layer (PHY) Specifications", IEEE 802.11, 2007. 780 [IEEE-802-1D] 781 IEEE, "IEEE Standard for Local and Metropolitan Area 782 Network-- Media Access Control (MAC) Bridges", 783 IEEE 802.1D, 2004. 785 [IEEE-802-1Q] 786 IEEE, "IEEE Standard for Local and Metropolitan Area 787 Network-- Bridges and Bridged Networks", IEEE 802.1Q, 788 2018. 790 [ITU-T-Y-1566] 791 ITU-T, "Quality of Service Mapping and Interconnection 792 Between Ethernet, Internet Protocol and Multiprotocol 793 Label Switching Networks", ITU-T Y.1566, 2012. 795 [MEF23.1] MEF, "MEF Technical Specification MEF 23.1-- Carrier 796 Ethernet Class of Service ? Phase 2", MEF 23.1, 2012. 798 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 799 DOI 10.17487/RFC0791, September 1981, 800 . 802 [RFC1349] Almquist, P., "Type of Service in the Internet Protocol 803 Suite", RFC 1349, DOI 10.17487/RFC1349, July 1992, 804 . 806 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 807 P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- 808 Protocol Label Switching (MPLS) Support of Differentiated 809 Services", RFC 3270, DOI 10.17487/RFC3270, May 2002, 810 . 812 [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of 813 Diffserv Service Classes", RFC 5127, DOI 10.17487/RFC5127, 814 February 2008, . 816 [RFC5160] Levis, P. and M. Boucadair, "Considerations of Provider- 817 to-Provider Agreements for Internet-Scale Quality of 818 Service (QoS)", RFC 5160, DOI 10.17487/RFC5160, March 819 2008, . 821 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 822 Writing an IANA Considerations Section in RFCs", BCP 26, 823 RFC 8126, DOI 10.17487/RFC8126, June 2017, 824 . 826 [RFC8325] Szigeti, T., Henry, J., and F. Baker, "Mapping Diffserv to 827 IEEE 802.11", RFC 8325, DOI 10.17487/RFC8325, February 828 2018, . 830 [RFC8622] Bless, R., "A Lower-Effort Per-Hop Behavior (LE PHB) for 831 Differentiated Services", RFC 8622, DOI 10.17487/RFC8622, 832 June 2019, . 834 [SA-5G] 3GPP, "System Architecture for 5G", TS 23.501, 2019. 836 Appendix A. Revision Notes 838 Note to RFC-Editor: please remove this entire section prior to 839 publication. 841 * Individual draft -00 843 * Individual draft -01; Comments from Martin Duke; Brian Carpenter; 844 Ruediger Geib, and revisions to improve language consistency. 846 * Individual draft -02; Revisions to improve language consistency. 848 * Working Group -00, replacing draft-ietf-tsvwg-dscp-considerations- 849 02. 851 Appendix B. Table of DSCP Values 853 This table may help in the discussion of DSCP remarking. The current 854 assignments are at: Section 8. 856 +-------+------+------+------+------+------+------+------+------+ 857 |Hi \ Lo|0b 000|0b 001|0b 010|0b 011|0b 100|0b 101|0b 110|0b 111| 858 +-------+------+------+------+------+------+------+------+------+ 859 | 0b 000|BE/DE |LE | CU |Pool 3| CU | CU | CU |Pool 3| 860 | | CSO | | |LU/EXP| | | |LU/EXP| 861 +-------+------+------+------+------+------+------+------+------+ 862 | 0b 001|CS1 | CU |AF11 |LU/EXP|AF12 | CU |AF13 |LU/EXP| 863 +-------+------+------+------+------+------+------+------+------+ 864 | 0b 010|CS2 | CU |AF21 |LU/EXP|AF22 | CU |AF23 |LU/EXP| 865 +-------+------+------+------+------+------+------+------+------+ 866 | 0b 011|CS3 | CU |AF31 |LU/EXP|AF32 | CU |AF33 |LU/EXP| 867 +-------+------+------+------+------+------+------+------+------+ 868 | 0b 100|CS4 | CU |AF41 |LU/EXP|AF42 | CU |AF43 |LU/EXP| 869 +-------+------+------+------+------+------+------+------+------+ 870 | 0b 101|CS5 | CU | CU |LU/EXP|VA | CU |EF |LU/EXP| 871 +-------+------+------+------+------+------+------+------+------+ 872 | 0b 110|CS6 | CU | CU |LU/EXP| CU | CU | CU |LU/EXP| 873 +-------+------+------+------+------+------+------+------+------+ 874 | 0b 111|CS7 | CU | CU |LU/EXP| CU | CU | CU |LU/EXP| 875 +-------+------+------+------+------+------+------+------+------+ 877 LU/EXP - Local or Experimental Use 878 CU - Currently Unassigned (reserved for IANA allocation) 880 Table: Summary of Currently Assigned DSCP Values 882 Appendix C. Example of operational practice and operator requirements. 884 RFC5127 backbone networks are often over provisioned under stable 885 operating conditions. Operating and maintaining a plethora of 886 differentiated, DSCP based service differentiations can be 887 operationally difficult. Network Operations staff might not be happy 888 to reconfigure all or a majority of the backbone routers in response 889 to frequent DSCP-to-PHB mapping table configuration changes. 891 Instead, operational practice might prefer a simple to configure and 892 operate, comprehensible with limited expertise for monitoring and 893 debugging. 895 - For discussion: 897 There are a set of different expectations of traffic sources and 898 sinks that set DSCP markings: 900 * Is the setting behaviour intended to enable a local or sectional 901 differential treatment, without expecting end-to-end service 902 differentiation? 904 Example: A sender domain that sets DSCPs to influence stream 905 playout priorities in receiver browsers, or any/many unknown 906 intentions when setting DSCPs. 908 * Is the setting behaviour intended to enable a local or sectional 909 differential treatment, without expecting end-to-end service 910 differentiation? 912 Example: A sender domain that sets DSCPs to influence stream 913 playout priorities in receiver browsers, or any/many unknown 914 intentions when setting a DSCP. 916 * Is the setting behaviour intended to enable end-to-end service 917 differentiation with an expectation of interconnection agreements 918 in place? 920 Example: Provider interconnection agreements, e.g., for the 921 public telephony service. 923 * Is the setting behaviour intended to enable end-to-end service 924 differentiation without an expectation of interconnection 925 agreements in place? 927 Example: The Non-Queue-Building or Lower Effort PHBs. 929 Authors' Addresses 931 Ana Custura 932 University of Aberdeen 933 School of Engineering 934 Fraser Noble Building 935 Aberdeen 936 AB24 3UE 937 United Kingdom 939 Email: ana@erg.abdn.ac.uk 940 Godred Fairhurst 941 University of Aberdeen 942 School of Engineering 943 Fraser Noble Building 944 Aberdeen 945 AB24 3UE 946 United Kingdom 948 Email: gorry@erg.abdn.ac.uk 950 Raffaello Secchi 951 University of Aberdeen 952 School of Engineering 953 Fraser Noble Building 954 Aberdeen 955 AB24 3UE 956 United Kingdom 958 Email: r.secchi@abdn.ac.uk