idnits 2.17.1 draft-ietf-tsvwg-dscp-considerations-02.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 (12 May 2022) is 715 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: 13 November 2022 University of Aberdeen 6 12 May 2022 8 Considerations for Assigning a new Recommended DiffServ Codepoint (DSCP) 9 draft-ietf-tsvwg-dscp-considerations-02 11 Abstract 13 This document discusses considerations for assigning a new 14 recommended DiffServ Code Point (DSCP). It considers the common 15 remarking pathologies 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 13 November 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 6 58 4.1. Bleaching the DSCP Field . . . . . . . . . . . . . . . . 7 59 4.2. IP Type of Service manipulations . . . . . . . . . . . . 7 60 4.2.1. Impact of ToS Precedence Bleaching . . . . . . . . . 7 61 4.2.2. Impact of ToS Precedence Remarking . . . . . . . . . 9 62 4.3. Remarking to a Particular DSCP . . . . . . . . . . . . . 9 63 5. Interpretation of the IP DSCP at Lower Layers . . . . . . . . 10 64 5.1. Mapping Specified for IEEE 802 . . . . . . . . . . . . . 10 65 5.1.1. Mapping Specified for IEEE 802.1 . . . . . . . . . . 10 66 5.1.2. Mapping Specified for IEEE 802.11 . . . . . . . . . . 10 67 5.2. DiffServ and MPLS . . . . . . . . . . . . . . . . . . . . 12 68 5.2.1. Mapping Specified for MPLS . . . . . . . . . . . . . 12 69 5.2.2. Mapping Specified for MPLS Short Pipe . . . . . . . . 12 70 5.3. Mapping Specified for Mobile Networks . . . . . . . . . . 13 71 5.4. Mapping Specified for Carrier Ethernet . . . . . . . . . 14 72 5.5. Remarking as a Side-effect of Another Policy . . . . . . 14 73 5.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 15 74 6. Considerations for DSCP Selection . . . . . . . . . . . . . . 15 75 6.1. Effect of Bleaching . . . . . . . . . . . . . . . . . . . 15 76 6.2. Where the proposed DSCP > 0x07 (7) . . . . . . . . . . . 15 77 6.3. Where the proposed DSCP < 0x07 (7) . . . . . . . . . . . 15 78 6.3.1. Where the proposed DSCP&0x07=0x01 . . . . . . . . . . 15 79 6.4. Impact on deployed infrastructure . . . . . . . . . . . . 16 80 6.5. Questions to guide discussion of a proposed new DSCP . . 17 81 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 83 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 85 10.1. Normative References . . . . . . . . . . . . . . . . . . 18 86 10.2. Informative References . . . . . . . . . . . . . . . . . 19 87 Appendix A. Revision Notes . . . . . . . . . . . . . . . . . . . 21 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 90 1. Introduction 92 The Differentiated Services (DiffServ) architecture has been deployed 93 in many networks. It provides differentiated traffic forwarding 94 based on the DiffServ Code Point (DSCP) [RFC2474] carried in the 95 DiffServ field [RFC2474] of the IP packet header. 97 Internet traffic can be associated with a service class, and 98 categorised into Behavior Aggregates [RFC4594]. In IP networks, 99 these are associated with a DSCP. Each DSCP is mapped to a Per Hop 100 Behaviour (PHB). A treatment aggregate is concerned only with the 101 forwarding treatment of the aggregated traffic, which could be mapped 102 from a set of DSCP values [RFC5127]. Treatment differentiation can 103 be realised using a variety of schedulers and queues, and also by 104 algorithms that implement access to the physical media. 106 Application -> Service 107 Traffic Class 108 | 109 Behavior -> DiffServ -> Per Hop 110 Aggregate Codepoint Behavior 111 | 112 Treatment -> Schedule 113 Aggregate Queue, Drop 115 Figure showing the role of DSCPs in classifying IP traffic for 116 differential network treatment. 118 This document discusses considerations for assigning a new DSCP. It 119 considers some commonly observed DSCP remarking pathologies that 120 might be experienced along an Internet path. It also describes some 121 packet forwarding treatments that a packet with a specific DSCP can 122 expect to receive when forwarded across a link or subnetwork. 124 The document is motivated by new opportunities to use DiffServ end- 125 to-end across multiple domains, such as [I-D.ietf-tsvwg-nqb], 126 proposals to build mechanisms using DSCPs in other standards-setting 127 organisations, and the desire to use a common set of DSCPs across a 128 range of infrastructure (e.g., [RFC8622], [I-D.ietf-tsvwg-nqb], 129 [I-D.learmonth-rfc1226-bis]). 131 2. Terminology 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in RFC 2119 [RFC2119]. 137 DSCPs are specified in the IANA registry [DSCP-registry] where a 138 variety of different formats are described. A DSCP can sometimes 139 referred to by name, such as "CS1", and sometimes by a decimal, hex, 140 or binary value. Hex values will be represented in text using prefix 141 0x. Binary values will use prefix 0b. 143 3. Current usage of DSCPs 145 This section describes current usage of DSCPs. 147 3.1. IP-Layer Semantics 149 The DiffServ architecture specifies use of the DiffServ field in the 150 IPv4 and IPv6 packet headers to carry one of 64 distinct DSCP values. 151 Within a given administrative boundary, each DSCP value can be mapped 152 to a distinct PHB [RFC2474]. When a new PHB is standardized, a 153 recommended DSCP value among those 64 values is normally reserved for 154 that PHB, and is assigned by IANA. 156 The DSCP space is divided into three pools for the purpose of 157 assignment and management [DSCP-registry]. This use of the pools can 158 be summnarised in a table (where 'x' refers to either a bit position 159 with value '0' or '1'). 161 DSCP Pool 1: A pool of 32 codepoints with a format 0bxxxxx0, to be 162 assigned by IANA Standards Action [RFC8126]. 164 DSCP Pool 2: A pool of 16 codepoints with a format 0bxxxx11, 165 reserved for experimental or local (private) use by network 166 operators (see sections 4.1 and 4.2 of [RFC8126]. 168 DSCP Pool 3: A pool of 16 codepoints with a 0bxxxx01. This was 169 initially available for experimental or local use, but which was 170 originally specified to be preferentially utilised for 171 standardized assignments if Pool 1 is ever exhausted. Pool 3 172 codepoints are now utilised for standardized assignments and are 173 no longer available for experimental or local use [RFC8436]. 175 The DSCP space is shown in the following Figure. 177 +---------+-------+----------+-----+----------+-----+----------+-----+ 178 | 56/CS7 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 179 +---------+-------+----------+-----+----------+-----+----------+-----+ 180 | 48/CS6 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 181 +---------+-------+----------+-----+----------+-----+----------+-----+ 182 | 40/CS5 | 41 | 42 | 43 | 44/VA | 45 | 46/EF | 47 | 183 +---------+-------+----------+-----+----------+-----+----------+-----+ 184 | 32/CS4 | 33 | 34/AF41 | 35 | 36/AF42 | 37 | 38/AF43 | 39 | 185 +---------+-------+----------+-----+----------+-----+----------+-----+ 186 | 24/CS3 | 25 | 26/AF31 | 27 | 28/AF32 | 29 | 30/AF33 | 31 | 187 +---------+-------+----------+-----+----------+-----+----------+-----+ 188 | 16/CS2 | 17 | 18/AF21 | 19 | 20/AF22 | 21 | 22/AF23 | 23 | 189 +---------+-------+----------+-----+----------+-----+----------+-----+ 190 | 8/CS1 | 9 | 10/AF11 | 11 | 12/AF12 | 13 | 14/AF13 | 15 | 191 +---------+-------+----------+-----+----------+-----+----------+-----+ 192 | 0/CS0 | 1/LE | 2 | 3 | 4 | 5 | 6 | 7 | 193 +---------+-------+----------+-----+----------+-----+----------+-----+ 195 Figure showing the current list of assigned DSCPs and their assigned 196 PHBs. 198 The DiffServ architecture allows forwarding treatments to be 199 associated with each DSCP, and the RFC series describes some of these 200 as PHBs. Although DSCPs are intended to identify specific treatment 201 requirements, multiple DSCPs might also be mapped (aggregated) to the 202 same forwarding treatment. Several IP standards map treatment 203 aggregates to DSCPs, that might result in remarking: RFC5160 204 [RFC5160] suggests Meta-QoS-Classes to help enable deployment of 205 standardized end-to-end QoS classes. 207 3.2. Network Control Traffic 209 Network Control Traffic is defined as packet flows that are essential 210 for stable operation of the administered network (see [RFC4594], 211 Section 3). This traffic is marked with a value from a set of Class 212 Selector (CS) DSCPs. This traffic is often a special case within a 213 provider network, and ingress traffic with these DSCP markings can be 214 remarked. 216 DSCP CS2 is recommended for the OAM (Operations, Administration, and 217 Maintenance) service class (see [RFC4594], Section 3.3). 219 DSCP CS6 is recommended for local network control traffic. This 220 includes routing protocols and OAM traffic that are essential to 221 network operation administration, control and management. 222 Section 3.2 of RFC4594 [RFC4594] recommends that "CS6 marked packet 223 flows from untrusted sources (for example, end user devices) SHOULD 224 be dropped or remarked at ingress to the DiffServ network". 226 DSCP CS7 is reserved for future use by network control traffic. "CS7 227 marked packets SHOULD NOT be sent across peering points" [RFC4594]. 229 At the time of writing, there is evidence to suggest CS6 is actively 230 used by network operators for control traffic. A study of traffic at 231 a large Internet Exchange showed around 40% of ICMP traffic carried 232 this mark [IETF113DSCP]. Similarly, another study found many routers 233 remark all traffic except those packets with a DSCP that sets the 234 higher order bits to 0b11 (see Section 4 of this document). 236 4. Remarking the DSCP 238 It is a feature of the DiffServ architecture that the DiffServ field 239 of packets can be remarked at domain boundaries (see section 2.3.4.2 240 of RFC2475 [RFC2475]). A DSCP can be remarked at the ingress of a 241 DiffServ domain. This remarking can change the DSCP value used on 242 the remainder of an IP path, or the network can restore the initial 243 DSCP marking at the egress of the domain. The DiffServ field can 244 also be remarked based upon common semantics and agreements between 245 providers at an exchange point. Furthermore, RFC 2475 states that 246 remarking must occur when there is a possibility of theft/denial-of- 247 service attack. 249 If packets are received that are marked with an unknown or an 250 unexpected DSCP, RFC2474 [RFC2474] recommends forwarding the packet 251 using a default (best effort) treatment, but without changing the 252 DSCP. This seeks to support incremental DiffServ deployment in 253 existing networks as well as preserve DSCP markings by routers that 254 have not been configured to support DiffServ. (See also 255 Section 4.3). RFC3260 [RFC3260] clarifies that this remarking 256 specified by RFC2474 is intended for interior nodes within a DiffServ 257 domain. For DiffServ ingress nodes the traffic conditioning required 258 by RFC 2475 applies first. 260 Reports measuring existing deployments have categorised DSCP 261 remarking [Custura] [Barik] into the following seven remarking 262 pathologies: 264 Bleach: bleaches all traffic (sets the DSCP to zero); 266 Bleach-ToS-Precedence: set the first three bits of the DSCP field to 267 0b000 (reset the 3 bits of the former ToS Precedence field) ; 269 Bleach-some-ToS: set the first three bits of the DSCP field to 0b000 270 (reset the 3 bits of the former ToS Precedence field), unless the 271 first two bits of the DSCP field are 0b11; 273 Remark-ToS: set the first three bits of the DSCP field to any value 274 different than 0b000 (replace the 3 bits of the former ToS 275 Precedence field); 277 Bleach-low: set the last three bits of the DSCP field to 0b000; 279 Bleach-some-low: set the last three bits of the DSCP field to 0b000, 280 unless the first two bits of the DSCP field are 0b11; 282 Remark: remarks all traffic to one or more particular (non-zero) 283 DSCP values. 285 4.1. Bleaching the DSCP Field 287 A specific form of remarking occurs when the DiffServ field is re- 288 assigned to the default treatment, CS0 (0x00). This results in 289 traffic being forwarded using the BE PHB. For example, AF31 (0x1a) 290 would be bleached to CS0. 292 A survey reported that resetting all the bits of the DiffServ field 293 to 0 was seen to be more prevalent at the edge of the network, and 294 rather less common in core networks [Custura]. 296 4.2. IP Type of Service manipulations 298 The IETF first defined ToS precedence for IP packets [RFC0791], 299 updated by specification as a part of the ToS Field RFC1349 300 [RFC1349]. Since 1998, this practice has been deprecated by RFC2474 301 [RFC2474]. RFC 2474 defines DSCPs 0bxxx000 as the Class Selector 302 codepoints, where PHBs selected by these codepoints MUST meet the 303 Class Selector PHB Requirements" described in Sec. 4.2.2.2 of that 304 RFC. 306 However, a recent survey reports practices based on ToS semantics 307 have not yet been eliminated from Internet, and need to still be 308 considered when making new DSCP assignments [Custura]. 310 4.2.1. Impact of ToS Precedence Bleaching 312 ToS Precedence Bleaching (/Bleach-ToS-Precedence/) is a practice that 313 resets the first three bits of the DSCP field to zero (the former ToS 314 Precedence field), leaving the last three bits unchanged (see section 315 4.2.1 of RFC2474 [RFC2474]). This remarking is distinctive of non- 316 DiffServ aware routers and a common manipulation of the DiffServ 317 field. The following Figure provides details. 319 +-+-+-+-+-+-+ 320 |0 0 0|x x x| 321 +-+-+-+-+-+-+ 323 Figure showing the ToS Precedence Bleaching (/Bleach-ToS-Precedence/) 324 pathology, based on Section 3 of RFC1349 [RFC1349]. 326 +---------+-------+----------+-----+----------+-----+----------+-----+ 327 | 56/CS7 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 328 +---------+-------+----------+-----+----------+-----+----------+-----+ 329 | 48/CS6 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 330 +---------+-------+----------+-----+----------+-----+----------+-----+ 331 | 40/CS5 | 41 | 42 | 43 | 44/VA | 45 | 46/EF | 47 | 332 +---------+-------+----------+-----+----------+-----+----------+-----+ 333 | 32/CS4 | 33 | 34/AF41 | 35 | 36/AF42 | 37 | 38/AF43 | 39 | 334 +---------+-------+----------+-----+----------+-----+----------+-----+ 335 | 24/CS3 | 25 | 26/AF31 | 27 | 28/AF32 | 29 | 30/AF33 | 31 | 336 +---------+-------+----------+-----+----------+-----+----------+-----+ 337 | 16/CS2 | 17 | 18/AF21 | 19 | 20/AF22 | 21 | 22/AF23 | 23 | 338 +---------+-------+----------+-----+----------+-----+----------+-----+ 339 | 8/CS1 | 9 | 10/AF11 | 11 | 12/AF12 | 13 | 14/AF13 | 15 | 340 +=========+=======+==========+=====+==========+=====+==========+=====+ 341 | 0/CS0 | 1/LE | 2 | 3 | 4 | 5 | 6 | 7 | 342 +=========+=======+==========+=====+==========+=====+==========+=====+ 344 As a result of ToS Precedence Bleaching, all the DSCPs in each column 345 are remarked to the smallest DSCP in that column. The DSCPs in the 346 bottom row therefore have a higher survivability across an end-to-end 347 Internet path. 349 +=========+=======+============+====+======+======+============+====+ 350 | 0/CS0 | 1/LE | 2 | 3 | 4 | 5 | 6 | 7 | 351 +=========+=======+============+====+======+======+============+====+ 352 |Assigned |ToS Prec Bl.|EXP/|Used |Future|ToS Prec Bl.|Exp/| 353 | |of AF11..41 |LU |by SSH|NQB |of AF13..EF |LU | 354 +=================+============+====+======+======+============+====+ 356 Figure showing 0b000xxx DSCPs, highlighting any current assignments 357 and whether they are affected by any known pathologies. For example, 358 ToS Precedence Bleaching of popular DSCPs AF11,21,31,41 would result 359 in traffic being remarked with DSCP 2 in the Internet core. DSCP 4 360 has been historically used by the SSH application, following 361 semantics which precede DiffServ[DSCP4]. 363 If ToS Precedence Bleaching occurs, packets with a DSCP 'x' would be 364 remarked to 'x' & 0x07and then would be treated according to the 365 corresponding PHB. 367 A variation of this pathology clears the top three bits of a DSCP, 368 unless these have values 0b110 or 0b111 (corresponding to the CS6 and 369 CS7 DSCPs). As a result, a DSCP value greater than 48 decimal (0x30) 370 is less likely to be impacted by ToS Precedence Bleaching. 372 4.2.2. Impact of ToS Precedence Remarking 374 Practices based on ToS Precedence Remarking (/Remark-ToS/) RFC1349 375 [RFC1349] were deprecated by RFC2474 [RFC2474]. These practices 376 based on ToS semantics have not yet been eliminated from deployed 377 networks. 379 +-+-+-+-+-+-+ 380 |0 0 1|x x x| 381 +-+-+-+-+-+-+ 383 Figure showing ToS Precedence Remarking (/Remark-ToS/) pathology, 384 based on Section 3 of RFC1349 [RFC1349]. 386 A less common remarking, ToS Precedence Remarking sets the first 387 three bits of the DSCP to a non-zero value corresponding to a CS PHB. 388 This remarking is distinctive of non-DiffServ aware routers. 390 If remarking occurs, packets are forwarded using the PHB specified 391 for the resulting DSCP. For example, the AF31 DSCP (0x1a) could be 392 remarked to either AF11 or AF21. 394 4.3. Remarking to a Particular DSCP 396 A network device might remark the DiffServ field of an IP packet 397 based on a local policy with a specific (set of) DSCPs, /Remark/. 398 This is sometimes performed using a Multi-Field (MF) classifier 399 [RFC2475] [RFC3290] [RFC4594]. For example, a common remarking is to 400 remark all traffic to a single DSCP, thus removing any traffic 401 differentiation (see Section 4.1). Bleaching (/Bleach/) is a 402 specific example of this pathology that remarks to CS0 (0x00). 404 In another example, some networks do not follow the recommendation in 405 RFC2475 [RFC2475], and instead remark packets with an unknown or 406 unexpected DSCP to the default class, CS0 (0x00) to ensure that 407 appropriate DSCPs are used within a DiffServ domain. (e.g., see 408 [RFC8100]). 410 5. Interpretation of the IP DSCP at Lower Layers 412 Transmission systems and subnetworks can, and do, utilise the 413 DiffServ field in an IP packet to select a lower layer forwarding 414 treatment. In many cases, this use is constrained by designs that 415 utilise fewer than 6 bits to express the service class, and therefore 416 infer mapping to a smaller L2 QoS field, for example, WiFi or Multi- 417 Protocol Label Switching (MPLS). 419 5.1. Mapping Specified for IEEE 802 421 The IEEE specifies standards that include mappings for DSCPs to lower 422 layer elements. 424 5.1.1. Mapping Specified for IEEE 802.1 426 A 3-bit Priority Code Point (PCP) is specified in the IEEE 802.1Q tag 427 to mark Ethernet frames to one of eight priority values 428 [IEEE-802-1Q]. The value zero indicates the default best effort 429 treatment, and the value one indicates a background traffic class. 430 The remaining values indicate increasing priority. Internet control 431 traffic can be marked as six, and network control is marked as seven. 433 The mapping specified in [IEEE-802-1Q] revises a previous standard 434 [IEEE-802-1D], in an effort to align with DiffServ practice: the 435 traffic types are specified to match the first three bits of a 436 suitable DSCP (e.g., the first three bits of the EF DSCP is mapped to 437 a PCP of 5). However, [IEEE-802-1D] maps both PCP1 (Background) and 438 PCP2 (Spare) to indicate lower priority than PCP0, RFC8622. 439 Therefore, different remarking pathologies are expected depending on 440 the age of deployed devices. 442 5.1.2. Mapping Specified for IEEE 802.11 444 Section 6 of RFC 8325 [RFC8325] provides a brief overview of IEEE 445 802.11 QoS. The IEEE 802.11 standards [IEEE-802-11] provide MAC 446 functions to support QoS in WLANs using Access Classes (AC). The 447 upstream User Priority (UP) in the 802.11 header has a 3-bit QoS 448 value. A DSCP can be mapped to the UP. 450 Most existing WiFi implementations [RFC8325] use a default mapping 451 that maps the first three bits of the DSCP to the 802.11 UP value. 452 This is then in turn mapped to the four WiFi Multimedia (WMM) Access 453 Categories. The Wi-Fi Alliance has also specified a more flexible 454 mapping that follows RFC8325 and provides functions at an AP to 455 remark packets as well as a QoS Map that maps each DSCP to an AC 456 [WIFI-ALLIANCE]. 458 +-+-+-+-+-+-+ 459 |x x x|. . .| 460 +-+-+-+-+-+-+ 462 Figure showing the DSCP bits commonly mapped to the UP in 802.11. 464 RFC8325 [RFC8325] notes inconsistencies that can result from such 465 remarking, and recommends how to perform this remarking. It proposes 466 several recommendations for mapping a DSCP to an IEEE 802.11 UP for 467 wired-to-wireless interconnection. The recommendation includes 468 mapping network control traffic CS6 and CS7, as well unassigned 469 DSCPs, to UP 0. 471 In the upstream direction (wireless-to-wired interconnections, this 472 mapping can result in a specific DSCP remarking pathology. Some 473 Access Points (APs) currently use a default UP-to-DSCP mapping 474 RFC8325 [RFC8325], wherein "DSCP values are derived from the layer 2 475 UP values by multiplying the UP values by eight (i.e., shifting the 476 three UP bits to the left and adding three additional zeros to 477 generate a 6-bit DSCP value). This derived DSCP value is used for 478 QoS treatment between the wireless AP and the nearest classification 479 and marking policy enforcement point (which may be the centralized 480 wireless LAN controller, relatively deep within the network). 481 Alternatively, in the case where there is no other classification and 482 marking policy enforcement point, then this derived DSCP value will 483 be used on the remainder of the Internet path." This can result in 484 remarking /Reset-low/. 486 +-+-+-+-+-+-+ 487 |x x x|0 0 0| 488 +-+-+-+-+-+-+ 490 Figure showing the pathology resulting from deriving from UP-to-DSCP 491 mapping in some 802.11 networks. 493 An alternative to UP-to-DSCP remapping uses the DSCP value of a 494 downstream IP packet (e.g., the Control And Provisioning of Wireless 495 Access Points (CAPWAP) protocol, RFC5415, maps an IP packet DiffServ 496 field to the DiffServ field of outer IP header in a CAPWAP tunnel). 498 Some current constraints of WiFi mapping are discussed in section 2 499 of [RFC8325]. A QoS profile can be used to limit the maximum DSCP 500 value used for the upstream and downstream traffic. 502 5.2. DiffServ and MPLS 504 Multi-Protocol Label Switching (MPLS) specified eight MPLS Traffic 505 Classes (TCs), which restricts the number of different treatments 506 [RFC5129]. RFC 5127 describes aggregation of DiffServ TCs [RFC5127], 507 and introduces four DiffServ Treatment Aggregates. Traffic marked 508 with multiple DSCPs can be forwarded in a single MPLS TC. 510 There are three Label-Switched Router (LSR) behaviors: the Pipe, the 511 Short Pipe and the Uniform Model [RFC3270]. These only differ when a 512 LSP performs a push or a pop. 514 5.2.1. Mapping Specified for MPLS 516 RFC3270 [RFC3270] defines a flexible solution for support of DiffServ 517 over MPLS networks. This allows an MPLS network administrator to 518 select how BAs (marked by DSCPs) are mapped onto Label Switched Paths 519 (LSPs) to best match the DiffServ, Traffic Engineering and protection 520 objectives within their particular network. 522 Mapping from the IP DSCP to the MPLS header are defined in 523 Section 4.2 of [RFC3270]. 525 The Pipe Model conveys the "LSP Diff-Serv Information" to the LSP 526 Egress so that its forwarding treatment can be based on the IP DSCP. 528 When Penultimate Hop Popping (PHP) is used, the Penultimate LSR needs 529 to be aware of the encapsulation mapping for a PHB to the label 530 corresponding to the exposed header to perform DiffServ Information 531 Encoding (Section 2.5.2 of RFC3270 [RFC3270]). 533 5.2.2. Mapping Specified for MPLS Short Pipe 535 The Short Pipe Model is an optional variation of the Pipe Model 536 [RFC3270]. 538 ITU-T Y.1566 [ITU-T-Y-1566] further defined a set of four common QoS 539 classes and four auxiliary classes to which a DSCP can be mapped when 540 interconnecting Ethernet, IP and MPLS networks. RFC8100 [RFC8100] 541 proposes four treatment aggregates for interconnection with four 542 defined DSCPs. This was motivated by the requirements of MPLS 543 network operators that use Short-Pipe tunnels, but can be applicable 544 to other networks, both MPLS and non-MPLS. 546 RFC8100 recommends preserving the notion of end-to-end service 547 classes, and recommends that the original DSCP marking is not changed 548 when treatment aggregates are used. The key requirement is that the 549 DSCP at the network ingress is restored at the network egress. This 550 is only feasible in general for a small number of DSCPs. In this 551 design, packets marked with other DSCPs can be remarked (a /Remark/ 552 pathology) or dealt with via an additional agreement(s) among the 553 operators of the interconnected networks. Use of the MPLS Short Pipe 554 Model favours remarking unexpected DSCP values to zero in the absence 555 of an additional agreement(s), as explained in RFC8100 [RFC8100]. 556 This can result in bleaching (/Bleach/). 558 +--------------------------------------+--------+ 559 | RFC8100 | DSCP | 560 | Agg. Class | | 561 +--------------------------------------+--------+ 562 |Telephony Service Treatment Aggregate | EF | 563 | | VA | 564 +--------------------------------------+--------+ 565 |Bulk Real-Time Treatment Aggregate | AF41 | 566 | May be added | (AF42) | 567 | May be added | (AF43) | 568 +--------------------------------------+--------+ 569 |Assured Elastic Treatment Aggregate | AF31 | 570 | | AF32 | 571 | Reserved for the extension of PHBs| (AF33) | 572 +--------------------------------------+--------+ 573 |Default / Elastic Treatment Aggregate | BE/CS0 | 574 +--------------------------------------+--------+ 575 |Network Control: Local Use | CS6 | 576 +--------------------------------------+--------+ 578 The short-pipe MPLS mapping from RFC 8100. 580 5.3. Mapping Specified for Mobile Networks 582 Mobile LTE and 5G standards have evolved from older UMTS standards, 583 and are DiffServ aware. LTE (4G) and 5G standards [SA-5G] identify 584 traffic classes at the interface between User Equipment (UE) and the 585 mobile Packet Core network by QCI (QoS Class Identifiers) and 5QI (5G 586 QoS Identifier). The 3GPP standards do not define or recommend any 587 specific mapping between each QCI or 5QI and DiffServ (and mobile 588 QCIs are based on several criteria service class definitions). The 589 way packets are mapped at the Packet Gateway (P-GW) boundary is 590 determined by operators. However, TS 23.107 (version 16.0.0, applies 591 to LTE and below) mandates that Differentiated Services, defined by 592 IETF, shall be used to interoperate with IP backbone networks. 594 The GSM Association (GSMA) has defined four aggregated classes and 595 seven associated PHBs in their guidelines for IPX Provider networks 596 GSMA IR.34 [GSMA-IR-34]. This was previously specified as the Inter- 597 Service Provider IP Backbone Guidelines, and provides a mobile ISP to 598 ISP QoS mapping mechanism, and interconnection with other IP networks 599 in the general Internet. This describes the case where the DSCP 600 marking from a Service Provider cannot be trusted (depending on the 601 agreement between the Service Provider and its IPX Provider), 602 allowing the IPX Provider to remark the DSCP value to a static 603 default value. 605 +---------------+-------+ 606 | GSMA IR.34 | PHB | 607 | Agg. Class | | 608 +---------------+-------+ 609 |Conversational | EF | 610 +---------------+-------+ 611 | Streaming | AF41 | 612 +---------------+-------+ 613 | Interactive | AF31 | 614 + +-------+ 615 | (ordered by | AF32 | 616 + priority, +-------+ 617 | AF3 highest) | AF21 | 618 + +-------+ 619 | | AF11 | 620 +---------------+-------+ 621 | Background | CS0 | 622 +---------------+-------+ 624 Figure showing the PHB mapping recommended in the guidelines proposed 625 in GSMA IR.34 [GSMA-IR-34]. 627 5.4. Mapping Specified for Carrier Ethernet 629 Metro Ethernet Forum (MEF) provides a mapping of DSCPs at the IP 630 layer to quality of service markings in the Ethernet frame headers 631 MEF 23.1 [MEF23.1]. 633 5.5. Remarking as a Side-effect of Another Policy 635 The result of applying a QoS policy (such as matching the IP address, 636 or traffic reaching a rate limit) could also result in a packet being 637 remarked to a different DSCP (/Remark/) when it is not admitted to a 638 service. Traffic marked with an EF and VA DSCP are often policed by 639 such policies. 641 Policies and L2 procedures can also result in remarking traffic as a 642 side-effect of other functions (e.g., in response to DDos). 644 5.6. Summary 646 This section has discussed the various ways in which DSCP remarking 647 pathologies can arise from interactions with lower layers. 649 6. Considerations for DSCP Selection 651 This section provides advic e for the assignment of a new DSCP value. 652 It identifies known issues that might influence the finally assigned 653 DSCP, followed by a summary of considerations for assignment of a new 654 DSCP. 656 6.1. Effect of Bleaching 658 New DSCP assignments should consider the impact of bleaching, which 659 can limit the ability to provide the expected treatment end-to-end. 660 This is particularly important for cases where the codepoint is 661 intended to result in lower than best effort treatment, as was the 662 case when defining the LE PHB [RFC8622]. In this case, bleaching, or 663 remarking to "CS0" would result in elevating the lower effort traffic 664 to the default class. This is an example of priority inversion. 666 6.2. Where the proposed DSCP > 0x07 (7) 668 Although the IETF specifications require systems to use DSCP marking 669 semantics in place of methods based on the former ToS field, the 670 current recommendation is that any new assignment where the DSCP is 671 greater than 0x07 should consider the semantics associated with the 672 resulting DSCP when ToS Precedence Bleaching is experienced. For 673 example, it can be desirable to avoid choosing a DSCP that could be 674 remarked to LE, Lower Effort [RFC8622], which could otherwise 675 potentially result in a priority inversion in the treatment. 677 6.3. Where the proposed DSCP < 0x07 (7) 679 ToS Precedence Bleaching can unintentionally result in extra traffic 680 aggregated to the same DSCP. For example, after experiencing ToS 681 Precedence Bleaching, all traffic marked AF11, AF21, AF31 and AF41 682 would be aggregated with traffic marked with DSCP 2 (0x02), 683 increasing the volume of traffic which receives the treatment 684 associated with DSCP 2. New DiffServ Codepoint assignments should 685 consider unexpected consequences arising from this pathology. 687 6.3.1. Where the proposed DSCP&0x07=0x01 689 As a consequence of assigning the LE PHB [RFC8622], the IETF 690 allocated the DSCP 0b000001 from Pool 3. 692 When making assignments where the DSCP has a format: 0bxxx001, the 693 case of ToS Precedence Bleaching (/Bleach-ToS-Precedence/) of a DSCP 694 to a value of 0x01 needs to be considered. ToS Precedence Bleaching 695 will result in demoting the traffic to the lower effort traffic 696 class. Care should be taken to consider the implications of 697 remarking when shooing to assign a DSCP with tyhis format. 699 6.4. Impact on deployed infrastructure 701 Behaviour of deployed PHBs and conditioning treatments also needs to 702 be considered when assigning a new DSCP. Network operators have 703 choices when it comes to configuring DiffServ support within their 704 domains, and the pathologies described in the previous section can 705 result from different configurations and approaches: 707 Networks not remarking DiffServ: A network that implements one or 708 more PHBs, and does not remark DSCPs. Operators in this category 709 pass all DSCPs transparently. 711 Networks that condition the DSCP: A network that implements more 712 than one PHB and enforces SLAs with its peers. Operators in this 713 category use conditioning to ensure that only traffic that matches 714 a policy is permitted to use a specific DSCP (see RFC8100 715 [RFC8100]). This requires operators to choose to support or 716 remark a new DSCP assignment. 718 Networks that remark in some other way , which includes: 720 1. Networks containing misconfigured devices that do not comply 721 with the relevent RFCs. 723 2. Networks containing devices that implement an obsolete 724 specification or contain software bugs. 726 3. Networks containing devices that remark the DSCP as a result 727 of lower layer interactions. 729 For example, the ToS Precedence Bleaching (/Bleach-ToS-Precedence/) 730 pathology cannot arise in the case of networks not remarking 731 DiffServ, but can arise as a result of traffic conditioning at 732 operator boundaries. It can also arise in the case of 733 misconfiguration or in netwroks using old equipment which precedes 734 DiffServ. 736 6.5. Questions to guide discussion of a proposed new DSCP 738 A series of questions emerge that need to be answered when 739 considering a proposal to the IETF that requests a new assignment. 740 These questions include: 742 * Is the request for local use within a DiffServ domain that does 743 not require interconnection with other DiffServ domains? This can 744 use DSCPs in Pool 2 for local or experimental use, without any 745 IETF specification for the DSCP or associated PHB. 747 * How is the proposed service class characterised? What are the 748 characteristics of the traffic to be carried? What are the 749 expectations for treatment? 751 * Service Classes that can utilise existing PHBs should use assigned 752 DSCPs to mark their traffic: Could the request be met by using an 753 existing IETF DSCP? The proposed new treatement be used to map 754 traffic to a new or existing PHB. 756 * Does the service class request assigning new DSCP? Specification 757 of a new recommended DSCP requires Standards Action. RFC2474 758 states: "Each standardized PHB MUST have an associated RECOMMENDED 759 codepoint". If approved, new IETF assignments are normally made 760 by IANA in Pool 1, but the IETF can request assignments to be made 761 from Pool 3 [RFC8436]. 763 * Many What are the effects of treatment aggregation on the proposed 764 method? Section 5.2 describes examples of treatment aggregation. 766 * What are the implications of using the proposed DSCP on the 767 expected lower layers over which the traffic may be forwarded? 768 Section 5 describes some observed treatments by layers below IP. 770 * If a new DSCP is needed for an end-to-end service, then what is 771 the expected effect of currently-deployed remarking on the end-to- 772 end service? Section 4 describes some observed remarking 773 pathologies, and Section 6.4 identifies root causes for why these 774 remarking pathologies are observed. 776 7. Acknowledgments 778 The authors acknowledge the helpful discussions and analysis by Greg 779 White and Thomas Fossati in a draft concerning NQB. Ruediger Geib, 780 and Brian Carpenter contributed comments, along with other memebers 781 of the TSVWG. 783 8. IANA Considerations 785 This memo provides information to assist in considering new 786 assignments to the IANA DSCP registry 787 (https://www.iana.org/assignments/dscp-registry/dscp-registry.xhtml). 789 This memo includes no request to IANA, or update to the IANA 790 procedures. 792 9. Security Considerations 794 The security considerations are discussed in the security 795 considerations of each cited RFC. 797 10. References 799 10.1. Normative References 801 [DSCP-registry] 802 IANA, "Differentiated Services Field Codepoints (DSCP) 803 Registry". 805 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 806 Requirement Levels", BCP 14, RFC 2119, 807 DOI 10.17487/RFC2119, March 1997, 808 . 810 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 811 "Definition of the Differentiated Services Field (DS 812 Field) in the IPv4 and IPv6 Headers", RFC 2474, 813 DOI 10.17487/RFC2474, December 1998, 814 . 816 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 817 and W. Weiss, "An Architecture for Differentiated 818 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 819 . 821 [RFC3260] Grossman, D., "New Terminology and Clarifications for 822 Diffserv", RFC 3260, DOI 10.17487/RFC3260, April 2002, 823 . 825 [RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An 826 Informal Management Model for Diffserv Routers", RFC 3290, 827 DOI 10.17487/RFC3290, May 2002, 828 . 830 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 831 Guidelines for DiffServ Service Classes", RFC 4594, 832 DOI 10.17487/RFC4594, August 2006, 833 . 835 [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion 836 Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January 837 2008, . 839 [RFC8100] Geib, R., Ed. and D. Black, "Diffserv-Interconnection 840 Classes and Practice", RFC 8100, DOI 10.17487/RFC8100, 841 March 2017, . 843 [RFC8436] Fairhurst, G., "Update to IANA Registration Procedures for 844 Pool 3 Values in the Differentiated Services Field 845 Codepoints (DSCP) Registry", RFC 8436, 846 DOI 10.17487/RFC8436, August 2018, 847 . 849 10.2. Informative References 851 [Barik] Barik, R., Welzl, M., Elmokashfi, A., Dreibholz, T., and 852 S. Gjessing, "Can WebRTC QoS Work? A DSCP Measurement 853 Study", ITC 30, September 2018. 855 [Custura] Custura, A., Venne, A., and G. Fairhurst, "Exploring DSCP 856 modification pathologies in mobile edge networks", TMA , 857 2017. 859 [DSCP4] Kolu, A., "Bogus DSCP value for SSH", online 860 https://lists.freebsd.org/pipermail/freebsd- 861 stable/2010-July/057710.html, 2010. 863 [GSMA-IR-34] 864 GSM Association, "IR.34 Guidelines for IPX Provider 865 networks (Previously Inter-Service Provider IP Backbone 866 Guidelines)", IR 34, 2017. 868 [I-D.ietf-tsvwg-nqb] 869 White, G. and T. Fossati, "A Non-Queue-Building Per-Hop 870 Behavior (NQB PHB) for Differentiated Services", Work in 871 Progress, Internet-Draft, draft-ietf-tsvwg-nqb-03, 2 872 November 2020, . 875 [I-D.learmonth-rfc1226-bis] 876 Learmonth, I., "Internet Protocol Encapsulation of AX.25 877 Frames", Work in Progress, Internet-Draft, draft- 878 learmonth-rfc1226-bis-03, 19 May 2020, 879 . 882 [IEEE-802-11] 883 IEEE, "Wireless LAN Medium Access Control (MAC) and 884 Physical Layer (PHY) Specifications", IEEE 802.11, 2007. 886 [IEEE-802-1D] 887 IEEE, "IEEE Standard for Local and Metropolitan Area 888 Network-- Media Access Control (MAC) Bridges", 889 IEEE 802.1D, 2004. 891 [IEEE-802-1Q] 892 IEEE, "IEEE Standard for Local and Metropolitan Area 893 Network-- Bridges and Bridged Networks", IEEE 802.1Q, 894 2018. 896 [IETF113DSCP] 897 Custura, A. and G. Fairhurst, "Considerations for 898 assigning DSCPs", IETF 113 Proceedings 899 https://datatracker.ietf.org/meeting/113/materials/slides- 900 113-tsvwg-61-dscp-considerations-07, 2022. 902 [ITU-T-Y-1566] 903 ITU-T, "Quality of Service Mapping and Interconnection 904 Between Ethernet, Internet Protocol and Multiprotocol 905 Label Switching Networks", ITU-T Y.1566, 2012. 907 [MEF23.1] MEF, "MEF Technical Specification MEF 23.1-- Carrier 908 Ethernet Class of Service ? Phase 2", MEF 23.1, 2012. 910 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 911 DOI 10.17487/RFC0791, September 1981, 912 . 914 [RFC1349] Almquist, P., "Type of Service in the Internet Protocol 915 Suite", RFC 1349, DOI 10.17487/RFC1349, July 1992, 916 . 918 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 919 P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- 920 Protocol Label Switching (MPLS) Support of Differentiated 921 Services", RFC 3270, DOI 10.17487/RFC3270, May 2002, 922 . 924 [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of 925 Diffserv Service Classes", RFC 5127, DOI 10.17487/RFC5127, 926 February 2008, . 928 [RFC5160] Levis, P. and M. Boucadair, "Considerations of Provider- 929 to-Provider Agreements for Internet-Scale Quality of 930 Service (QoS)", RFC 5160, DOI 10.17487/RFC5160, March 931 2008, . 933 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 934 Writing an IANA Considerations Section in RFCs", BCP 26, 935 RFC 8126, DOI 10.17487/RFC8126, June 2017, 936 . 938 [RFC8325] Szigeti, T., Henry, J., and F. Baker, "Mapping Diffserv to 939 IEEE 802.11", RFC 8325, DOI 10.17487/RFC8325, February 940 2018, . 942 [RFC8622] Bless, R., "A Lower-Effort Per-Hop Behavior (LE PHB) for 943 Differentiated Services", RFC 8622, DOI 10.17487/RFC8622, 944 June 2019, . 946 [SA-5G] 3GPP, "System Architecture for 5G", TS 23.501, 2019. 948 [WIFI-ALLIANCE] 949 Wi-Fi Alliance, "Wi-Fi QoS Management Specification 950 Version 2.0", Wi-Fi QoS Management Specification 951 Version 2.0, 2021. 953 Appendix A. Revision Notes 955 Note to RFC-Editor: please remove this entire section prior to 956 publication. 958 * Individual draft -00, initial document. 960 * Individual draft -01, address comments from Martin Duke; Brian 961 Carpenter; Ruediger Geib, and revisions to improve language 962 consistency. 964 * Individual draft -02, revise to improve language consistency. 966 * Working Group -00, replace individual draft. 968 * Working Group -01, address feedback in preparation for IETF 113 969 Vienna. 971 * Working Group -02: 973 Consolidate terminology after IETF 113 Vienna. 975 Add clarification to RFC2474 and RFC2475 addressed in RFC3260 976 (Comments from Ruediger Geib). 978 Include figures to show the full list of codepoints, their 979 assigned PHBs & impact of ToS Precedence Bleaching. 981 Add network categories that differentiate between network 982 operator approaches to DiffServ. 984 Add Terminology section to clarify representations of DSCPs. 986 Authors' Addresses 988 Ana Custura 989 University of Aberdeen 990 School of Engineering 991 Fraser Noble Building 992 Aberdeen 993 AB24 3UE 994 United Kingdom 995 Email: ana@erg.abdn.ac.uk 997 Godred Fairhurst 998 University of Aberdeen 999 School of Engineering 1000 Fraser Noble Building 1001 Aberdeen 1002 AB24 3UE 1003 United Kingdom 1004 Email: gorry@erg.abdn.ac.uk 1006 Raffaello Secchi 1007 University of Aberdeen 1008 School of Engineering 1009 Fraser Noble Building 1010 Aberdeen 1011 AB24 3UE 1012 United Kingdom 1013 Email: r.secchi@abdn.ac.uk