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