Considerations for Assigning a New Recommended Differentiated Services Code Point (DSCP) University of Aberdeen
School of Engineering Fraser Noble Building Aberdeen AB24 3UE United Kingdom ana@erg.abdn.ac.uk
University of Aberdeen
School of Engineering Fraser Noble Building Aberdeen AB24 3UE United Kingdom gorry@erg.abdn.ac.uk
University of Aberdeen
School of Engineering Fraser Noble Building Aberdeen AB24 3UE United Kingdom r.secchi@abdn.ac.uk
tsv tsvwg DSCP Diffserv Codepoints This document discusses considerations for assigning a new recommended Differentiated Services Code Point (DSCP) for a standard Per-Hop Behavior (PHB). It considers the common observed re-marking behaviors that the Diffserv field might be subjected to along an Internet path. It also notes some implications of using a specific DSCP.
Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .
Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents () in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
Table of Contents
  • .  Introduction
  • .  Terminology
  • .  Current Usage of DSCPs
    • .  IP-Layer Semantics
    • .  DSCPs Used for Network Control Traffic
  • .  Re-marking the DSCP
    • .  Bleaching the DSCP Field
    • .  IP Type of Service Manipulations
      • .  Impact of ToS Precedence Bleaching
      • .  Impact of ToS Precedence Re-marking
    • .  Re-marking to a Particular DSCP
  • .  Interpretation of the IP DSCP at Lower Layers
    • .  Mapping Specified for IEEE 802
      • .  Mapping Specified for IEEE 802.1
      • .  Mapping Specified for IEEE 802.11
    • .  Diffserv and MPLS
      • .  Mapping Specified for MPLS
      • .  Mapping Specified for MPLS Short Pipe
    • .  Mapping Specified for Mobile Networks
    • .  Mapping Specified for Carrier Ethernet
    • .  Re-marking as a Side Effect of Another Policy
    • .  Summary
  • .  Considerations for DSCP Selection
    • .  Effect of Bleaching and Re-marking to a Single DSCP
    • .  Where the Proposed DSCP > 0x07 (7)
      • .  Where the Proposed DSCP&0x07=0x01
    • .  Where the Proposed DSCP <= 0x07 (7)
    • .  Impact on Deployed Infrastructure
    • .  Considerations to Guide the Discussion of a Proposed New DSCP
  • .  IANA Considerations
  • .  Security Considerations
  • .  References
    • .  Normative References
    • .  Informative References
  • Acknowledgements
  • Authors' Addresses
Introduction The Differentiated Services (Diffserv) architecture has been deployed in many networks. It provides differentiated traffic forwarding based on the DSCP carried in the Diffserv field of the IP packet header . A common set of DSCPs are defined for both IPv4 and IPv6, and both network protocols use a common IANA registry . Diffserv associates traffic with a service class and categorizes it into Behavior Aggregates (BAs) . Configuration guidelines for service classes are provided in . BAs are associated with a DSCP, which in turn maps to a Per-Hop Behavior (PHB). Treatment differentiation can be achieved by using a variety of schedulers and queues and also algorithms that implement access to the physical media. Within a Diffserv domain, operators can set Service Level Specifications , each of which maps to a particular Per-Domain Behavior (PDB) that is based on one or more PHBs. The PDB defines which PHB (or set of PHBs) and, hence, for a specific operator, which DSCP (or set of DSCPs) will be associated with specific BAs as the packets pass through a Diffserv domain. It also defines whether the packets are re-marked as they are forwarded (i.e., changing the DSCP of a packet ).
The Role of DSCPs in Classifying IP Traffic for Differential Network Treatment by a Diffserv Node Application -> Service Traffic Class | Behavior -> Diffserv -> Per Hop Aggregate Codepoint Behavior | Schedule, Queue, Drop
This document discusses considerations for assigning a new DSCP for a standard PHB. It considers some commonly observed DSCP re-marking behaviors that might be experienced along an Internet path. It also describes some packet forwarding treatments that a packet with a specific DSCP can expect to receive when forwarded across a link or subnetwork. The document is motivated by new opportunities to use Diffserv end-to-end across multiple domains, such as , proposals to build mechanisms using DSCPs in other standards-setting organizations, and the desire to use a common set of DSCPs across a range of infrastructure (e.g., , , ).
Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. DSCPs are specified in the IANA registry , where a variety of different formats are described. A DSCP can sometimes be referred to by name, such as "CS1", and sometimes by a decimal, hex, or binary value. Hex values are represented in text using prefix "0x". Binary values use prefix "0b". In this document, the symbol "&" denotes a bitwise AND of two unsigned values.
Current Usage of DSCPs This section describes the current usage of DSCPs.
IP-Layer Semantics The Diffserv architecture specifies the use of the Diffserv field in the IPv4 and IPv6 packet headers to carry one of 64 distinct DSCP values. Within a given administrative boundary, each DSCP value can be mapped to a distinct PHB . When a new PHB is specified, a recommended DSCP value among those 64 values is normally reserved for that PHB and is assigned by IANA. An operator is not formally required to use the recommended value; indeed, states that "the mapping of codepoints to PHBs MUST be configurable." However, use of the recommended value is usually convenient and avoids confusion. The DSCP space is divided into three pools for the purpose of assignment and management . A summary of the pools is provided in a table (where 'x' refers to a bit position with value either '0' or '1').
DSCP Pool 1:
A pool of 32 codepoints with a format of 0bxxxxx0, to be assigned by IANA Standards Action .
DSCP Pool 2:
A pool of 16 codepoints with a format of 0bxxxx11, reserved for Experimental or Local (Private) Use by network operators (see Sections and of .
DSCP Pool 3:
A pool of 16 codepoints with a format of 0bxxxx01. This was initially available for Experimental (EXP) Use or Local Use (LU) but was originally specified to be "preferentially utilized for standardized assignments if Pool 1 is ever exhausted" . Pool 3 codepoints are now "utilized for standardized assignments (replacing the previous availability for experimental or local use)" . assigned 0x01 from this pool and consequentially updated . Any future request to assign 0x05 would be expected to similarly update .
Note that previously recommended a Local Use of DSCP values 0x01, 0x03, 0x05, and 0x07 (codepoints with the format of 0b000xx1), until this was updated by . The DSCP space is shown in the following table. Each row corresponds to one setting of the first three bits of the DSCP field, and each column to one setting of the last three bits of the DSCP field. Currently Assigned DSCPs and Their Assigned PHBs
56/CS7 57 58 59 60 61 62 63
48/CS6 49 50 51 52 53 54 55
40/CS5 41 42 43 44/VA 45 46/EF 47
32/CS4 33 34/AF41 35 36/AF42 37 38/AF43 39
24/CS3 25 26/AF31 27 28/AF32 29 30/AF33 31
16/CS2 17 18/AF21 19 20/AF22 21 22/AF23 23
8/CS1 9 10/AF11 11 12/AF12 13 14/AF13 15
0/CS0 1/LE 2 3 4 5 6 7
Abbreviations for DSCPs and PHB Groups
CS Class Selector
BE Best Effort (CS0)
AF Assured Forwarding
EF Expedited Forwarding
VA Voice Admit
LE Lower Effort
summarizes the DSCP abbreviations used in currently published RFCs, , as described in the IANA registry . The Default PHB is defined in . This provides Best Effort (BE) forwarding, and the recommended DSCP of '000000' (). This is the lowest value in the set of Class Selector (CS) DSCPs, and hence is also known as "CS0" . NOTE: specified a now deprecated use of Class Selector 1 (CS1) as the codepoint for the Lower Effort PHB. updated and and obsoleted , assigning the LE DSCP codepoint to the Lower Effort PHB. The Diffserv architecture allows forwarding treatments to be associated with each DSCP, and the RFC series describes some of these as PHBs. Although DSCPs are intended to identify specific treatment requirements, multiple DSCPs might also be mapped (aggregated) to the same forwarding treatment. DSCPs can be mapped to Treatment Aggregates (TAs) that might result in re-marking (e.g., suggests Meta-QoS-Classes to help enable deployment of standard end-to-end QoS classes).
DSCPs Used for Network Control Traffic Network control traffic is defined as packet flows that are essential for stable operation of the administered network (see ). The traffic consists of the network control service class and the OAM service class. This traffic is marked with a value from a set of CS DSCPs. This traffic is often a special case within a provider network, and ingress traffic with these DSCP markings can be re-marked. DSCP CS2 is recommended for the OAM (Operations, Administration, and Maintenance) service class (see ). DSCP CS6 is recommended for local network control traffic. This includes routing protocols and OAM traffic that are essential to network operation administration, control, and management. recommends that "CS6 marked packet flows from untrusted sources (for example, end user devices) SHOULD be dropped or remarked at ingress to the Diffserv network". DSCP CS7 is reserved for future use by network control traffic. "CS7 marked packets SHOULD NOT be sent across peering points" . recommends PHBs selected by CS6 and CS7 "MUST give packets a preferential forwarding treatment by comparison to the PHB selected by codepoint '000000'". At the time of writing, there is evidence to suggest CS6 is actively used by network operators for control traffic. A study of traffic at a large Internet Exchange showed around 40% of ICMP traffic carried this mark . Similarly, another study found many routers re-mark all traffic, except for packets carrying a DSCP with the format 0b11xxxx (i.e., setting the higher order bits to 0b11, see of this document).
Re-marking the DSCP It is a feature of the Diffserv architecture that the Diffserv field of packets can be re-marked at the Diffserv domain boundaries (see ). A DSCP can be re-marked at the ingress of a domain. This re-marking can change the DSCP value used on the remainder of an IP path, or the network can restore the initial DSCP marking at the egress of the domain. The Diffserv field can also be re-marked based on common semantics and agreements between providers at a Diffserv domain boundary. Furthermore, states that re-marking must occur when there is a possibility of theft or denial-of-service attack. A packet that arrives with a DSCP that is not associated with a PHB, results in an "unknown DSCP." A node could receive a packet with an "unexpected DSCP" due to misconfiguration, or because there is no consistent policy in place. The treatment of packets that are marked with an unknown or an unexpected DSCP at Diffserv domain boundaries is determined by the policy for a Diffserv domain. If packets are received that are marked with an unknown or an unexpected DSCP by a Diffserv domain interior node, recommends forwarding the packet using a default (Best Effort) treatment but without changing the DSCP. This seeks to support incremental Diffserv deployment in existing networks as well as preserve DSCP markings by routers that have not been configured to support Diffserv (see also ). clarifies that this re-marking specified by is intended for interior nodes within a Diffserv domain. For Diffserv ingress nodes, the traffic conditioning required by applies first. Reports measuring existing deployments have defined a set of categories for DSCP re-marking in the following seven observed re-marking behaviors:
Bleach-DSCP:
bleaches all traffic (sets the DSCP to zero)
Bleach-ToS-Precedence:
set the first three bits of the DSCP field to 0b000 (reset the three bits of the former ToS Precedence field, defined in and clarified in )
Bleach-some-ToS:
set the first three bits of the DSCP field to 0b000 (reset the three bits of the former ToS Precedence field), unless the first two bits of the DSCP field are 0b11
Re-mark-ToS:
set the first three bits of the DSCP field to any value different from 0b000 (replace the three bits of the former ToS Precedence field)
Bleach-low:
set the last three bits of the DSCP field to 0b000
Bleach-some-low:
set the last three bits of the DSCP field to 0b000, unless the first two bits of the DSCP field are 0b11
Re-mark-DSCP:
re-marks all traffic to one or more particular (non-zero) DSCP values
These behaviors are explained in the following subsections and cross-referenced in the remainder of the document. The network nodes forming a particular path might or might not have supported Diffserv. It is not generally possible for an external observer to determine which mechanism results in a specific re-marking solely from the change in an observed DSCP value. NOTE: More than one mechanism could result in the same DSCP re-marking (see below). These behaviors were measured on both IPv4 and IPv6 Internet paths between 2017 and 2021 . IPv6 routers were found to perform all the types of re-marking described above to a lesser extent than IPv4 ones.
Bleaching the DSCP Field A specific form of re-marking occurs when the Diffserv field is re-assigned to the default treatment: CS0 (0x00). This results in traffic being forwarded using the BE PHB. For example, AF31 (0x1a) would be bleached to CS0. A survey reported that resetting all the bits of the Diffserv field to 0 was seen to be more prevalent at the edge of the network and rather less common in core networks .
IP Type of Service Manipulations The IETF first defined ToS precedence for IP packets in and updated it to be part of the ToS field in . Since 1998, this practice has been deprecated by . defines DSCPs 0bxxx000 as the Class Selector codepoints, where PHBs selected by these codepoints MUST meet the "Class Selector PHB Requirements" described in . A recent survey reports practices based on ToS semantics have not yet been eliminated from the Internet and need to still be considered when making new DSCP assignments .
Impact of ToS Precedence Bleaching Bleaching of the ToS Precedence field (see ) resets the first three bits of the DSCP field to zero (the former ToS Precedence field), leaving the last three bits unchanged (see ). A Diffserv node can be configured in a way that results in this re-marking. This re-marking can also occur when packets are processed by a router that is not configured with Diffserv (e.g., configured to operate on the former ToS Precedence field ). At the time of writing, this is a common manipulation of the Diffserv field. The following Figure depicts this re-marking.
Bits in the Diffserv Field Modified by Bleaching of the ToS Precedence +-+-+-+-+-+-+ |5|4|3|2|1|0| +-+-+-+-+-+-+ |0 0 0|x x x| +-+-+-+-+-+-+
shows bleaching of the ToS Precedence (see ), based on . The bit positions marked 'x' are not changed. DSCP Values
56/CS7 57 58 59 60 61 62 63
48/CS6 49 50 51 52 53 54 55
40/CS5 41 42 43 44/VA 45 46/EF 47
32/CS4 33 34/AF41 35 36/AF42 37 38/AF43 39
24/CS3 25 26/AF31 27 28/AF32 29 30/AF33 31
16/CS2 17 18/AF21 19 20/AF22 21 22/AF23 23
8/CS1 9 10/AF11 11 12/AF12 13 14/AF13 15
0/CS0 1/LE 2 3 4 5 6 7
As a result of ToS Precedence Bleaching, each of the DSCPs in a column are re-marked to the smallest DSCP in that column. Therefore, the DSCPs in the bottom row have higher survivability across an end-to-end Internet path. Data on the observed re-marking at the time of writing was presented in . 0b000xxx DSCPs
0/⁠CS0 1/⁠LE 2 3 4 5 6 7
Assigned Re-marked from AF11..41 EXP/LU * Re-marked from AF13..EF EXP/LU
*
DSCP 4 has been historically used by the SSH application
shows 0b000xxx DSCPs. This highlights any current assignments and whether they are affected by any known re-marking behaviors, such as ToS Precedence Bleaching. DSCPs of the form 0b000xxx can be impacted by known re-marking behaviors of other assigned DSCPs. For example, ToS Precedence Bleaching of popular DSCPs AF11, AF21, AF31, and AF41 would result in traffic being re-marked with DSCP 2 in the Internet core. The Lower Effort (LE) Per-Hop Behavior PHB uses a DSCP of 1. The DSCP value of 4 has been historically used by the SSH application, following semantics that precede Diffserv . Bleach-ToS-Precedence (see ) of packets with a DSCP 'x' results in the DSCP being re-marked to 'x' & 0x07 and then forwarded using the PHB specified for the resulting DSCP in that Diffserv domain. In subsequent networks, the packet will receive treatment as specified by the domain's operator corresponding to the re-marked codepoint. A variation of this observed re-marking behavior clears the top three bits of a DSCP, unless these have values 0b110 or 0b111 (corresponding to the CS6 and CS7 DSCPs). As a result, a DSCP value greater than 48 decimal (0x30) is less likely to be impacted by ToS Precedence Bleaching.
Impact of ToS Precedence Re-marking states:
Implementors should note that the DSCP field is six bits wide. DS-compliant nodes MUST select PHBs by matching against the entire 6-bit DSCP field, e.g., by treating the value of the field as a table index which is used to select a particular packet handling mechanism which has been implemented in that device.
This replaced re-marking according to ToS precedence (see ) . These practices based on ToS semantics have not yet been eliminated from deployed networks.
Bits in the Diffserv Field Modified by ToS Precedence Re-marking +-+-+-+-+-+-+ |5|4|3|2|1|0| +-+-+-+-+-+-+ |0 0 1|x x x| +-+-+-+-+-+-+
shows the ToS Precedence Re-marking (see ) observed behavior, based on . The bit positions marked 'x' remain unchanged. A less common re-marking, ToS Precedence Re-marking sets the first three bits of the DSCP to a non-zero value corresponding to a CS PHB. This re-marking occurs when routers are not configured to perform Diffserv re-marking. If ToS Precedence Re-marking occurs, packets are forwarded using the PHB specified for the resulting DSCP in that domain. For example, the AF31 DSCP (0x1a) could be re-marked to either AF11 or AF21. If such a re-marked packet further traverses other Diffserv domains, it would receive treatment as specified by each domain's operator corresponding to the re-marked codepoint.
Re-marking to a Particular DSCP A network device might re-mark the Diffserv field of an IP packet based on a local policy with a specific set of DSCPs (see ). recommends: "Packets received with an unrecognized codepoint SHOULD be forwarded as if they were marked for the Default behavior, and their codepoints should not be changed." Some networks might not follow this recommendation and instead re-mark packets with these codepoints to the default class: CS0 (0x00). This re-marking is sometimes performed using a Multi-Field (MF) classifier . If re-marking occurs, packets are forwarded using the PHB specified for the resulting DSCP in that domain. As an example, re-marking traffic AF31, AF32, and AF33 all to a single DSCP, e.g., AF11, stops any drop probability differentiation, which may have been expressed by these three DSCPs. If such a re-marked packet further traverses other domains, it would receive treatment as specified by the domain's operator corresponding to the re-marked codepoint. Bleaching (see ) is a specific example of this observed re-marking behavior that re-marks to CS0 (0x00) (see ).
Interpretation of the IP DSCP at Lower Layers Transmission systems and subnetworks can, and do, utilize the Diffserv field in an IP packet to set a QoS-related field or function at the lower layer. A lower layer could also implement a traffic-conditioning function that could re-mark the DSCP used at the IP layer. This function is constrained by designs that utilize fewer than 6 bits to express the service class and, therefore, infer a mapping to a smaller L2 QoS field, for example, the 3-bit Priority Code Point (PCP) field in an IEEE Ethernet 802.1Q header, the 3-bit User Priority (UP) field, or the 3-bit Traffic Class field of Multi-Protocol Label Switching (MPLS). A Treatment Aggregate (TA) is an optional intermediary mapping group of BAs to PHBs.
Mapping Specified for IEEE 802 The IEEE specifies standards that include mappings for DSCPs to lower layer elements.
Mapping Specified for IEEE 802.1 IEEE 802.1Q specified a 3-bit PCP field, which includes a tag that allows Ethernet frames to be marked as one of eight priority values . Use of this field is described by various documents, including IEEE P802.1p and IEEE 802.1D. The mapping specified in revises a previous standard, , in an effort to align with Diffserv practice . In 802.1Q, the traffic types are specified to match the first three bits of a suitable DSCP (e.g., the first three bits of the Expedited Forwarding (EF) DSCP are mapped to a PCP of 5). In this mapping, PCP0 is used to indicate the default Best Effort treatment, and PCP1 indicates a background traffic class. The remaining PCP values indicate increasing priority. Internet control traffic can be marked as CS6, and network control is marked as CS7. Other re-marking behaviors have also been implemented in Ethernet equipment. Historically, a previous standard, , used both PCP1 (Background) and PCP2 (Spare) to indicate lower priority than PCP0, and some other devices do not assign a lower priority to PCP1.
Mapping Specified for IEEE 802.11 provides a brief overview of IEEE 802.11 QoS. The IEEE 802.11 standards provide Media Access Control (MAC) functions to support QoS in WLANs using Access Categories (ACs). The upstream UP in the 802.11 header has a 3-bit QoS value. A DSCP can be mapped to the UP. added a mapping for the LE DSCP to AC_BK (Background). Most current Wi-Fi implementations use a default mapping that maps the first three bits of the DSCP to the 802.11 UP value. This is an example of equipment still classifying on ToS Precedence (which could be seen as a simple method to map IP layer Diffserv to layers offering only 3-bit QoS codepoints). Then, in turn, this is mapped to the four Wi-Fi Multimedia (WMM) Access Categories. The Wi-Fi Alliance has also specified a more flexible mapping that follows and provides functions at an Access Point (AP) to re-mark packets as well as a QoS Map that maps each DSCP to an AC .
DSCP Bits Commonly Mapped to the UP in 802.11 +-+-+-+-+-+-+ |5|4|3|2|1|0| +-+-+-+-+-+-+ |x x x|. . .| +-+-+-+-+-+-+
The bit positions marked 'x' are mapped to the 3-bit UP value, while the ones marked '.' are ignored. notes inconsistencies that can result from such re-marking and recommends a different mapping to perform this re-marking, dependent on the direction in which a packet is forwarded. It provides recommendations for mapping a DSCP to an IEEE 802.11 UP for interconnection between wired and wireless networks. The recommendation in maps network control traffic, CS6 and CS7, as well as unassigned DSCPs, to UP 0 when forwarding in the upstream direction (wireless-to-wired). It also recommends mapping CS6 and CS7 traffic to UP 7 when forwarding in the downstream direction (). For other UPs, recommends a mapping in the upstream direction (wireless-to-wired interconnections) that derives the DSCP from the value of the UP multiplied by 8. This mapping, currently used by some Access Points (APs), can result in a specific DSCP re-marking behavior:
wherein DSCP values are derived from UP values by multiplying the UP values by 8 (i.e., shifting the three UP bits to the left and adding three additional zeros to generate a DSCP value). This derived DSCP value is then used for QoS treatment between the wireless AP and the nearest classification and marking policy enforcement point (which may be the centralized wireless LAN controller, relatively deep within the network). Alternatively, in the case where there is no other classification and marking policy enforcement point, then this derived DSCP value will be used on the remainder of the Internet path.
This can result in re-marking by Bleach-low (see ).
Bits in the Diffserv Field Modified by Re-marking Observed as a Result of UP-to-DSCP Mapping in Some 802.11 Networks +-+-+-+-+-+-+ |5|4|3|2|1|0| +-+-+-+-+-+-+ |x x x|0 0 0| +-+-+-+-+-+-+
An alternative to UP-to-DSCP remapping uses the DSCP value of a downstream IP packet (e.g., the Control and Provisioning of Wireless Access Points, CAPWAP, protocol maps an IP packet Diffserv field to the Diffserv field of the outer IP header in a CAPWAP tunnel). Some current constraints of Wi-Fi mapping are discussed in . A QoS profile can be used to limit the maximum DSCP value used for the upstream and downstream traffic.
Diffserv and MPLS Multi-Protocol Label Switching (MPLS) specified eight MPLS Traffic Classes (TCs), which restrict the number of different treatments . describes the aggregation of Diffserv service classes and introduces four Diffserv TAs. Traffic marked with multiple DSCPs can be forwarded in a single MPLS TC. There are three Label Switching Router (LSR) models: the Pipe, the Short Pipe, and the Uniform Model . In the Uniform and Pipe models, the egress MPLS router forwards traffic based on the received MPLS TC. The Uniform Model includes an egress DSCP rewrite. With the Short Pipe Model, the egress MPLS router forwards traffic based on the Diffserv DSCP as present at the egress router. If the domain supports IP and MPLS QoS differentiation, controlled behavior requires the DSCP of an (outer) IP header to be assigned or re-written by all domain ingress routers to conform with the domain's internal Diffserv deployment. Note that the Short Pipe Model is prevalent in MPLS domains.
Mapping Specified for MPLS defines a flexible solution for support of Diffserv over MPLS networks. This allows an MPLS network administrator to select how BAs (marked by DSCPs) are mapped onto Label Switched Paths (LSPs) to best match the Diffserv, Traffic Engineering, and protection objectives within their particular network. Mappings from the IP DSCP to the MPLS header are defined in . The Pipe Model conveys the "LSP Diff-Serv Information" to the LSP Egress so that its forwarding treatment can be based on the IP DSCP. When Penultimate Hop Popping (PHP) is used, the Penultimate LSR needs to be aware of the encapsulation mapping for a PHB to the label corresponding to the exposed header to perform Diffserv Information Encoding ().
Mapping Specified for MPLS Short Pipe The Short Pipe Model is an optional variation of the Pipe Model . ITU-T Y.1566 further defined a set of four common QoS classes and four auxiliary classes to which a DSCP can be mapped when interconnecting Ethernet, IP, and MPLS networks. describes four TAs for interconnection with four defined DSCPs. This was motivated by the requirements of MPLS network operators that use Short Pipe tunnels but can be applicable to other networks, both MPLS and non-MPLS. recommends preserving the notion of end-to-end service classes and recommends a set of standard DSCPs mapped to a small set of standard PHBs at interconnection. The key requirement is that the DSCP at the network ingress is restored at the network egress. The current version of limits the number of DSCPs to 6, and 3 more are suggested for extension. respects the deployment of PHB groups for DS domain-internal use, which limits the number of acceptable external DSCPs (and possibilities for their transparent transport or restoration at network boundaries). In this design, packets marked with DSCPs not part of the codepoint scheme are treated as unexpected and will possibly be re-marked (a Re-mark-DSCP, see behavior) or dealt with via additional agreements among the operators of the interconnected networks. can be extended to support up to 32 DSCPs by future standards. is operated by at least one Tier 1 backbone provider. Use of the MPLS Short Pipe Model favors re-marking unexpected DSCP values to zero in the absence of additional agreements, as explained in . This can result in bleaching (see ). The Short Pipe MPLS Mapping from
Treatment Aggregate DSCP
Telephony Service Treatment Aggregate EF
VA
Bulk Real-Time Treatment Aggregate AF41
(AF42)*
(AF43)*
Assured Elastic Treatment Aggregate AF31
AF32
(AF33)**
Default / Elastic Treatment Aggregate BE/CS0
Network Control: Local Use (LU) CS6
*
May be added
**
Reserved for the extension of PHBs
Mapping Specified for Mobile Networks Mobile LTE and 5G standards have evolved from older Universal Mobile Telecommunications System (UMTS) standards and support Diffserv. LTE (4G) and 5G standards identify traffic classes at the interface between User Equipment (UE) and the mobile Packet Core network by QCI (QoS Class Identifiers) and 5QI (5G QoS Identifier). The 3GPP standards do not define or recommend any specific mapping between each QCI or 5QI and Diffserv (and mobile QCIs are based on several criteria service class definitions). The way packets are mapped at the Packet Data Network Gateway (P-GW) boundary is determined by network operators. However, TS 23.107 (version 16.0.0, applies to LTE and below) mandates that Differentiated Services, defined by the IETF, shall be used to interoperate with IP backbone networks. The GSM Association (GSMA) has defined four aggregated classes and seven associated PHBs in their guidelines for IP Packet eXchange (IPX) Provider networks . This was previously specified as the "Inter-Service Provider IP Backbone Guidelines" and provides a mobile ISP to ISP QoS mapping mechanism and interconnection with other IP networks in the general Internet. If provided an IP VPN, the operator is free to apply its DS domain-internal codepoint scheme at outer headers and inner IPX DSCPs may be transported transparently. The guidelines also describe a case where the DSCP marking from a Service Provider cannot be trusted (depending on the agreement between the Service Provider and its IPX Provider). In this situation, the IPX Provider can re-mark the DSCP value to a static default value. The PHB Mapping Recommended in the Guidelines Recommended in
QoS Class in PHB
Conversational EF
Streaming AF41
Interactive (ordered by priority, AF3 highest) AF31
AF32
AF21
AF11
Background CS0
Mapping Specified for Carrier Ethernet MEF Forum (MEF) provides a mapping of DSCPs at the IP layer to quality of service markings in the Ethernet frame headers .
Re-marking as a Side Effect of Another Policy This includes any other re-marking that does not happen as a result of traffic conditioning, such as policies and L2 procedures that result in re-marking traffic as a side effect of other functions (e.g., in response to Distributed Denial of Service, DDoS).
Summary This section has discussed the various ways in which DSCP re-marking behaviors can arise from interactions with lower layers. A provider service path may consist of sections where multiple and changing layers use their own code points to determine differentiated forwarding (e.g., IP to MPLS to IP to Ethernet to Wi-Fi).
Considerations for DSCP Selection This section provides advice for the assignment of a new DSCP value. It is intended to aid the IETF and IESG in considering a request for a new DSCP. This section identifies known issues that might influence the finally assigned DSCP and provides a summary of considerations for assignment of a new DSCP.
Effect of Bleaching and Re-marking to a Single DSCP describes re-marking of the DSCP. New DSCP assignments should consider the impact of bleaching or re-marking (see ) to a single DSCP, which can limit the ability to provide the expected treatment end-to-end. This is particularly important for cases where the codepoint is intended to result in lower than Best Effort treatment, as was the case when defining the LE PHB . Forwarding LE using the default PHB is in line with , but it is recommended to maintain the distinct LE DSCP codepoint end-to-end to allow for differentiated treatment by domains supporting LE. Rewriting the LE DSCP to the default class (CS0) results in an undesired promotion of the priority for LE traffic in such a domain. Bleaching the lower three bits of the DSCP (both Bleach-low and Bleach-some-low in ), as well as re-marking to a particular DSCP, can result in similar changes of priority relative to traffic that is marked with other DSCPs.
Where the Proposed DSCP > 0x07 (7) This considers a proposed DSCP with a codepoint larger than 7. Although the IETF specifications require systems to use DSCP marking semantics in place of methods based on the former ToS field, the current recommendation is that any new assignment where the DSCP is greater than 0x07 should consider the semantics associated with the resulting DSCP when the ToS Precedence is bleached (Bleach-ToS-Precedence and Bleach-some-ToS, ) or ToS Precedence Re-marking (Re-mark-ToS, ) is experienced. For example, it can be desirable to avoid choosing a DSCP that could be re-marked to LE, Lower Effort, which could otherwise potentially result in a priority inversion in the treatment.
Where the Proposed DSCP&0x07=0x01 This considers a proposed DSCP where the least significant 3 bits together represent a value of 1 (i.e., 0b001). As a consequence of assigning the LE PHB , the IETF allocated the DSCP 0b000001 from Pool 3. When making assignments where the DSCP has a format "0bxxx001", the case of Bleach-ToS-Precedence () of a DSCP to a value of 0x01 needs to be considered. ToS Precedence Bleaching will result in demoting the traffic to the Lower Effort PHB. Care should be taken to consider the implications of re-marking when choosing to assign a DSCP with this format.
Where the Proposed DSCP <= 0x07 (7) This considers a proposed DSCP where the DSCP is less than or equal to 7. ToS Precedence Bleaching or ToS Precedence Re-marking can unintentionally result in extra traffic aggregated to the same DSCP. For example, after experiencing ToS Precedence Bleaching, all traffic marked AF11, AF21, AF31, and AF41 would be aggregated with traffic marked with DSCP 2 (0x02), increasing the volume of traffic that receives the treatment associated with DSCP 2. New DSCP assignments should consider unexpected consequences arising from this observed re-marking behavior.
Impact on Deployed Infrastructure Behavior of deployed PHBs and conditioning treatments also needs to be considered when assigning a new DSCP. Network operators have choices when it comes to configuring Diffserv support within their domains, and the observed re-marking behaviors described in the previous section can result from different configurations and approaches:
Networks not re-marking Diffserv:
A network that either does not implement PHBs or implements one or more PHBs while restoring the DSCP field at network egress with the value at network ingress. Operators in this category pass all DSCPs transparently.
Networks that condition the DSCP:
A network that implements more than one PHB and enforces Service Level Agreements (SLAs) with its peers. Operators in this category use conditioning to ensure that only traffic that matches a policy is permitted to use a specific DSCP (see ). Operators need to classify the received traffic, assign it to a corresponding PHB, and could re-mark the DSCP to a value that is appropriate for the domain's deployed Diffserv infrastructure.
Networks that re-mark in some other way, which includes:
  1. Networks containing misconfigured devices that do not comply with the relevant RFCs.
  2. Networks containing devices that implement an obsolete specification or contain software bugs.
  3. Networks containing devices that re-mark the DSCP as a result of lower layer interactions.
The DSCP re-marking corresponding to the Bleach-ToS-Precedence () observed behavior can arise for various reasons, one of which is old equipment that precedes Diffserv. The same re-marking can also arise in some cases when traffic conditioning is provided by Diffserv routers at operator boundaries or as a result of misconfiguration.
Considerations to Guide the Discussion of a Proposed New DSCP A series of questions emerge that need to be answered when considering a proposal to the IETF that requests a new assignment. These questions include:
  • Is the request for Local Use within a Diffserv domain that does not require interconnection with other Diffserv domains? This request can use DSCPs in Pool 2 for Local or Experimental Use, without any IETF specification for the DSCP or associated PHB.
  • What are the characteristics of the proposed service class? What are the characteristics of the traffic to be carried? What are the expectations for treatment?
  • Service classes that can utilize existing PHBs should use assigned DSCPs to mark their traffic: Could the request be met by using an existing IETF DSCP?
  • Specification of a new recommended DSCP requires Standards Action. states: "Each standardized PHB MUST have an associated RECOMMENDED codepoint". If approved, new IETF assignments are normally made by IANA in Pool 1, but the IETF can request assignments to be made from Pool 3 . Does the Internet Draft contain an appropriate request to IANA?
  • The value selected for a new DSCP can impact the ability of an operator to apply logical functions (e.g., a bitwise mask) to related codepoints when configuring Diffserv. A suitable value can simplify configurations by aggregating classification on a range of DSCPs. This classification based on DSCP ranges can increase the comprehensibility of documenting forwarding differentiation.
  • describes examples of treatment aggregation. What are the effects of treatment aggregation on the proposed DSCP?
  • describes some observed treatments by layers below IP. What are the implications of the treatments and mapping described in on the proposed DSCP?
  • DSCPs are assigned to PHBs and can be used to enable nodes along an end-to-end path to classify the packet for a suitable PHB. describes some observed re-marking behavior, and identifies root causes for why this re-marking is observed. What is the expected effect of currently-deployed re-marking on the service, end-to-end or otherwise?
IANA Considerations IANA has added the following text as a note at the top of the "Differentiated Services Field Codepoints (DSCP)" registry : "See RFC 9435 for considerations when assigning a new codepoint from the DSCP registry."
Security Considerations The security considerations are discussed in the security considerations of each cited RFC.
References Normative References Differentiated Services Field Codepoints (DSCP) IANA Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers This document defines the IP header field, called the DS (for differentiated services) field. [STANDARDS-TRACK] An Architecture for Differentiated Services This document defines an architecture for implementing scalable service differentiation in the Internet. This memo provides information for the Internet community. New Terminology and Clarifications for Diffserv This memo captures Diffserv working group agreements concerning new and improved terminology, and provides minor technical clarifications. It is intended to update RFC 2474, RFC 2475 and RFC 2597. When RFCs 2474 and 2597 advance on the standards track, and RFC 2475 is updated, it is intended that the revisions in this memo will be incorporated, and that this memo will be obsoleted by the new RFCs. This memo provides information for the Internet community. An Informal Management Model for Diffserv Routers This document proposes an informal management model of Differentiated Services (Diffserv) routers for use in their management and configuration. This model defines functional datapath elements (e.g., classifiers, meters, actions, marking, absolute dropping, counting, multiplexing), algorithmic droppers, queues and schedulers. It describes possible configuration parameters for these elements and how they might be interconnected to realize the range of traffic conditioning and per-hop behavior (PHB) functionalities described in the Diffserv Architecture. This memo provides information for the Internet community. Configuration Guidelines for DiffServ Service Classes This document describes service classes configured with Diffserv and recommends how they can be used and how to construct them using Differentiated Services Code Points (DSCPs), traffic conditioners, Per-Hop Behaviors (PHBs), and Active Queue Management (AQM) mechanisms. There is no intrinsic requirement that particular DSCPs, traffic conditioners, PHBs, and AQM be used for a certain service class, but as a policy and for interoperability it is useful to apply them consistently. This memo provides information for the Internet community. Explicit Congestion Marking in MPLS RFC 3270 defines how to support the Diffserv architecture in MPLS networks, including how to encode Diffserv Code Points (DSCPs) in an MPLS header. DSCPs may be encoded in the EXP field, while other uses of that field are not precluded. RFC 3270 makes no statement about how Explicit Congestion Notification (ECN) marking might be encoded in the MPLS header. This document defines how an operator might define some of the EXP codepoints for explicit congestion notification, without precluding other uses. [STANDARDS-TRACK] Diffserv-Interconnection Classes and Practice This document defines a limited common set of Diffserv Per-Hop Behaviors (PHBs) and Diffserv Codepoints (DSCPs) to be applied at (inter)connections of two separately administered and operated networks, and it explains how this approach can simplify network configuration and operation. Many network providers operate Multiprotocol Label Switching (MPLS) using Treatment Aggregates for traffic marked with different Diffserv Per-Hop Behaviors and use MPLS for interconnection with other networks. This document offers a simple interconnection approach that may simplify operation of Diffserv for network interconnection among providers that use MPLS and apply the Short Pipe Model. While motivated by the requirements of MPLS network operators that use Short Pipe Model tunnels, this document is applicable to other networks, both MPLS and non-MPLS. Update to IANA Registration Procedures for Pool 3 Values in the Differentiated Services Field Codepoints (DSCP) Registry The Differentiated Services (Diffserv) architecture specifies use of the DS field in the IPv4 and IPv6 packet headers to carry one of 64 distinct differentiated services field codepoint (DSCP) values. The Internet Assigned Numbers Authority (IANA) maintains a registry of assigned DSCP values. This update to RFC 2474 changes the IANA registration policy for Pool 3 of the registry (i.e., DSCP values of the form xxxx01) to Standards Action, i.e., values are assigned through a Standards Track or Best Current Practice RFC. The update also removes permission for experimental and local use of the codepoints that form Pool 3 of the DSCP registry; Pool 2 Codepoints (i.e., DSCP values of the form xxxx11) remain available for these purposes. Informative References Internet Protocol Encapsulation of AX.25 Frames HamBSD This document describes a method for the encapsulation of AX.25 Link Access Protocol for Amateur Packet Radio frames within IPv4 and IPv6 packets. Obsoletes RFC1226. Note Comments are solicited and should be addressed to the author(s). The sources for this draft are at: https://github.com/irl/draft-rfc1226-bis Work in Progress Can WebRTC QoS Work? A DSCP Measurement Study 2018 30th International Teletraffic Congress (ITC 30) Exploring DSCP modification pathologies in mobile edge networks 2017 Network Traffic Measurement and Analysis Conference (TMA) Guidelines for IPX Provider networks (Previously Inter-Service Provider IP Backbone Guidelines) GSM Association Version 17.0, IR.34 IEEE Standard for Information Technology - Telecommunications and Information Exchange Between Systems - Local and Metropolitan Area Networks - Specific Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications IEEE IEEE Standard for Local and metropolitan area network--Media Access Control (MAC) Bridges IEEE IEEE Standard for Local and Metropolitan Area Network--Bridges and Bridged Networks IEEE Real-world DSCP Traversal Measurements University of Aberdeen, UK Quality of service mapping and interconnection between Ethernet, Internet Protocol and multiprotocol label switching networks ITU-T Recommendation Subject: bogus DSCP value for ssh message to the freebsd-stable mailing list Implementation Agreement MEF 23.1 Carrier Ethernet Class of Service - Phase 2 MEF A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated Services CableLabs ARM This document specifies properties and characteristics of a Non- Queue-Building Per-Hop Behavior (NQB PHB). The NQB PHB provides a shallow-buffered, best-effort service as a complement to a Default deep-buffered best-effort service for Internet services. The purpose of this NQB PHB is to provide a separate queue that enables smooth (i.e. non-bursty), low-data-rate, application-limited traffic flows, which would ordinarily share a queue with bursty and capacity-seeking traffic, to avoid the latency, latency variation and loss caused by such traffic. This PHB is implemented without prioritization and can be implemented without rate policing, making it suitable for environments where the use of these features is restricted. The NQB PHB has been developed primarily for use by access network segments, where queuing delays and queuing loss caused by Queue-Building protocols are manifested, but its use is not limited to such segments. In particular, applications to cable broadband links, Wi- Fi links, and mobile network radio and core segments are discussed. This document recommends a specific Differentiated Services Code Point (DSCP) to identify Non-Queue-Building flows. [NOTE (to be removed by RFC-Editor): This document references an ISE submission draft (I-D.briscoe-docsis-q-protection) that is approved for publication as an RFC. This draft should be held for publication until the queue protection RFC can be referenced.] Work in Progress Internet Protocol Requirements for Internet Hosts - Communication Layers This RFC is an official specification for the Internet community. It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. [STANDARDS-TRACK] Type of Service in the Internet Protocol Suite This memo changes and clarifies some aspects of the semantics of the Type of Service octet in the Internet Protocol (IP) header. [STANDARDS-TRACK] Assured Forwarding PHB Group This document defines a general use Differentiated Services (DS) Per-Hop-Behavior (PHB) Group called Assured Forwarding (AF). [STANDARDS-TRACK] Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification This document defines and discusses Per-Domain Behaviors in detail and lays out the format and required content for contributions to the Diffserv WG on PDBs and the procedure that will be applied for individual PDB specifications to advance as WG products. This format is specified to expedite working group review of PDB submissions. This memo provides information for the Internet community. An Expedited Forwarding PHB (Per-Hop Behavior) This document defines a PHB (per-hop behavior) called Expedited Forwarding (EF). The PHB is a basic building block in the Differentiated Services architecture. EF is intended to provide a building block for low delay, low jitter and low loss services by ensuring that the EF aggregate is served at a certain configured rate. This document obsoletes RFC 2598. [STANDARDS-TRACK] Multi-Protocol Label Switching (MPLS) Support of Differentiated Services A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services This document proposes a differentiated services per-domain behavior (PDB) whose traffic may be "starved" (although starvation is not strictly required) in a properly functioning network. This is in contrast to the Internet's "best-effort" or "normal Internet traffic" model, where prolonged starvation indicates network problems. In this sense, the proposed PDB's traffic is forwarded with a "lower" priority than the normal "best-effort" Internet traffic, thus the PDB is called "Lower Effort" (LE). Use of this PDB permits a network operator to strictly limit the effect of its traffic on "best-effort"/"normal" or all other Internet traffic. This document gives some example uses, but does not propose constraining the PDB's use to any particular type of traffic. Aggregation of Diffserv Service Classes In the core of a high-capacity network, service differentiation may still be needed to support applications' utilization of the network. Applications with similar traffic characteristics and performance requirements are mapped into Diffserv service classes based on end- to-end behavior requirements of the applications. However, some network segments may be configured in such a way that a single forwarding treatment may satisfy the traffic characteristics and performance requirements of two or more service classes. In these cases, it may be desirable to aggregate two or more Diffserv service classes into a single forwarding treatment. This document provides guidelines for the aggregation of Diffserv service classes into forwarding treatments. This memo provides information for the Internet community. Considerations of Provider-to-Provider Agreements for Internet-Scale Quality of Service (QoS) This memo analyzes provider-to-provider Quality of Service (QoS) agreements suitable for a global QoS-enabled Internet. It defines terminology relevant to inter-domain QoS models. It proposes a new concept denoted by Meta-QoS-Class (MQC). This concept could potentially drive and federate the way QoS inter-domain relationships are built between providers. It opens up new perspectives for a QoS- enabled Internet that retains, as much as possible, the openness of the existing best-effort Internet. This memo provides information for the Internet community. Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification This specification defines the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol, meeting the objectives defined by the CAPWAP Working Group in RFC 4564. The CAPWAP protocol is designed to be flexible, allowing it to be used for a variety of wireless technologies. This document describes the base CAPWAP protocol, while separate binding extensions will enable its use with additional wireless technologies. [STANDARDS-TRACK] A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic This document requests one Differentiated Services Code Point (DSCP) from the Internet Assigned Numbers Authority (IANA) for a class of real-time traffic. This traffic class conforms to the Expedited Forwarding Per-Hop Behavior. This traffic is also admitted by the network using a Call Admission Control (CAC) procedure involving authentication, authorization, and capacity admission. This differs from a real-time traffic class that conforms to the Expedited Forwarding Per-Hop Behavior but is not subject to capacity admission or subject to very coarse capacity admission. [STANDARDS-TRACK] Guidelines for Writing an IANA Considerations Section in RFCs Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Mapping Diffserv to IEEE 802.11 As Internet traffic is increasingly sourced from and destined to wireless endpoints, it is crucial that Quality of Service (QoS) be aligned between wired and wireless networks; however, this is not always the case by default. This document specifies a set of mappings from Differentiated Services Code Point (DSCP) to IEEE 802.11 User Priority (UP) to reconcile the marking recommendations offered by the IETF and the IEEE so as to maintain consistent QoS treatment between wired and IEEE 802.11 wireless networks. A Lower-Effort Per-Hop Behavior (LE PHB) for Differentiated Services This document specifies properties and characteristics of a Lower- Effort Per-Hop Behavior (LE PHB). The primary objective of this LE PHB is to protect Best-Effort (BE) traffic (packets forwarded with the default PHB) from LE traffic in congestion situations, i.e., when resources become scarce, BE traffic has precedence over LE traffic and may preempt it. Alternatively, packets forwarded by the LE PHB can be associated with a scavenger service class, i.e., they scavenge otherwise-unused resources only. There are numerous uses for this PHB, e.g., for background traffic of low precedence, such as bulk data transfers with low priority in time, non-time-critical backups, larger software updates, web search engines while gathering information from web servers and so on. This document recommends a standard Differentiated Services Code Point (DSCP) value for the LE PHB. This specification obsoletes RFC 3662 and updates the DSCP recommended in RFCs 4594 and 8325 to use the DSCP assigned in this specification. System architecture for the 5G System (5GS) 3GPP Wi-Fi QoS Management Specification Version 2.0 Wi-Fi Alliance
Acknowledgements The authors acknowledge the helpful discussions and analysis by and in a draft concerning NQB. and contributed comments, along with other members of the TSVWG.
Authors' Addresses University of Aberdeen
School of Engineering Fraser Noble Building Aberdeen AB24 3UE United Kingdom ana@erg.abdn.ac.uk
University of Aberdeen
School of Engineering Fraser Noble Building Aberdeen AB24 3UE United Kingdom gorry@erg.abdn.ac.uk
University of Aberdeen
School of Engineering Fraser Noble Building Aberdeen AB24 3UE United Kingdom r.secchi@abdn.ac.uk