| Internet-Draft | Considerations for assigning a DSCPs | March 2023 |
| Custura, et al. | Expires 4 September 2023 | [Page] |
This document discusses considerations for assigning a new recommended DiffServ Code Point (DSCP) for a new 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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 4 September 2023.¶
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 (https://trustee.ietf.org/license-info) 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.¶
The Differentiated Services (DiffServ) architecture has been deployed in many networks. It provides differentiated traffic forwarding based on the DiffServ Code Point (DSCP) [RFC2474] carried in the DiffServ field [RFC2474] 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 [DSCP-registry].¶
DiffServ associates traffic with a service class [RFC4594] and categorises it into Behavior Aggregates [RFC4594]. Configuration guidelines for service classes are provided in RFC4594 [RFC4594]. Behavior aggregates are associated with a DiffServ Code Point (DSCP), which in turn maps to a Per Hop Behavior (PHB). Treatment differentiation can be achieved using a variety of schedulers and queues, and also by algorithms that implement access to the physical media.¶
Within a DiffServ domain, operators can set service level specifications [RFC3086], 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 Behavior Aggregates (BAs) as the packets pass through a DiffServ domain, and whether the packets are re-marked as they are forwarded (i.e., changing the DSCP of a packet [RFC2475]).¶
Application -> Service
Traffic Class
|
Behavior -> DiffServ -> Per Hop
Aggregate Codepoint Behavior
|
Schedule,
Queue, Drop
¶
Figure showing the role of DSCPs in classifying IP traffic for differential network treatment by a DiffServ Node.¶
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 [I-D.ietf-tsvwg-nqb], proposals to build mechanisms using DSCPs in other standards-setting organisations, and the desire to use a common set of DSCPs across a range of infrastructure (e.g., [RFC8622], [I-D.ietf-tsvwg-nqb], [I-D.learmonth-rfc1226-bis]).¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
DSCPs are specified in the IANA registry [DSCP-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.¶
This section describes the current usage of DSCPs.¶
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 [RFC2474]. 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 [RFC2474] 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 [DSCP-registry]. A summary of the pools is provided in a table (where 'x' refers to a bit position with value either '0' or '1').¶
Note that [RFC4594] previously recommended a local use of DSCP values 0x01, 0x03, 0x05 and 0x07 (codepoints with the format of 0b000xx1), until updated by [RFC8436].¶
The DSCP space is shown in the following table.¶
+---------+------+---------+-----+---------+-----+---------+----+ | 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 | +---------+------+---------+-----+---------+-----+---------+----+¶
Table showing the currently assigned DSCPs and their assigned PHBs.¶
+-----+-----------------------+-----------+ | CS | Class Selector | RFC 2474 | +-----+-----------------------+-----------+ | BE | Best Effort (CS0) | RFC 2474 | +-----+-----------------------+-----------+ | AF | Assured Forwarding | RFC 2597 | +-----+-----------------------+-----------+ | EF | Expedited Forwarding | RFC 3246 | +-----+-----------------------+-----------+ | VA | Voice Admit | RFC 5865 | +-----+-----------------------+-----------+ | LE | Lower Effort | RFC 8622 | +-----+-----------------------+-----------+¶
Table showing the summary of the DSCP abbreviations used in published RFCs.¶
The above table summarises the DSCP abbreviations used in currently published RFCs [RFC2474] [RFC2597] [RFC3246] [RFC5865] [RFC8622], as described in the IANA registry [DSCP-registry]. BE, also known as CS0, describes the default forwarding treatment.¶
NOTE: [RFC4594] specified a now deprecated use of Class Selector 1 (CS1) as the codepoint for the Lower Effort PHB. [RFC8622] updated [RFC4594] and [RFC8325], and obsoleted [RFC3662], 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 that might result in re-marking (e.g., RFC5160 [RFC5160] suggests Meta-QoS-Classes to help enable deployment of standard end-to-end QoS classes)¶
Network Control Traffic is defined as packet flows that are essential for stable operation of the administered network (see [RFC4594], Section 3). 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 Class Selector (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 [RFC4594], Section 3.3).¶
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. Section 3.2 of RFC4594 [RFC4594] recommends that "CS6 marked packet flows from untrusted sources (for example, end-user devices) SHOULD be dropped or re-marked 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" [RFC4594].¶
RFC2474 recommends PHBs selected by CS6 and CS7 "MUST give packets preferential forwarding treatment by comparison to the PHB selected by codepoint '000000'"[RFC2474].¶
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 [IETF115-IEPG]. 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 Section 4.2.1 of this document).¶
It is a feature of the DiffServ architecture that the DiffServ field of packets can be re-marked at the Diffserv domain boundaries (see Section 2.3.4.2 of [RFC2475]). 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 an exchange point. Furthermore, [RFC2474] states that re-marking must occur when there is a possibility of theft or denial-of-service attack.¶
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, [RFC2474] 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 Section 4.3). [RFC3260] clarifies that this re-marking specified by RFC2474 is intended for interior nodes within a DiffServ domain. For DiffServ ingress nodes the traffic conditioning required by RFC 2475 applies first.¶
Reports measuring existing deployments have defined a set of categories for DSCP re-marking [Cus17] [Bar18] into the following seven observed re-marking behaviors:¶
These behaviours 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[Cus17]. IPv6 routers were found to perform all the types of re-marking described above to a lesser extent than IPv4 ones.¶
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 [Cus17].¶
The IETF first defined ToS precedence for IP packets in [RFC0791], and updated it to be part of the ToS Field in [RFC1349]. Since 1998, this practice has been deprecated by [RFC2474]. RFC 2474 defines DSCPs 0bxxx000 as the Class Selector codepoints, where PHBs selected by these codepoints MUST meet the Class Selector PHB Requirements" described in Sec. 4.2.2.2 of that RFC.¶
However, 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 [Cus17].¶
Bleaching of the ToS Precedence field (Bleach-ToS-Precedence (Section 4)) resets the first three bits of the DSCP field to zero (the former ToS Precedence field), leaving the last three bits unchanged (see Section 4.2.1 of [RFC2474]). 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 [RFC0791]). At the time of writing, this is a common manipulation of the DiffServ field. The following Figure depicts this re-marking.¶
+-+-+-+-+-+-+ |0 0 0|x x x| +-+-+-+-+-+-+¶
Figure showing bleaching of the ToS Precedence (Bleach-ToS-Precedence (Section 4)), based on Section 3 of [RFC1349]. The bit positions marked "x" are not changed.¶
+--------+------+---------+----+---------+----+---------+----+ | 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 | +========+======+=========+====+=========+====+=========+====+¶
Table of DSCP values. 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 [IETF115-IEPG].¶
+=======+======+=============+====+======+===+=========+====+ | 0/CS0 | 1/LE | 2 | 3 | 4 | 5 | 6 | 7 | +=======+======+=============+====+======+===+=========+====+ |Assigned |Re-marked |EXP/| * | |Re-marked|EXP/| | |from AF11..41|LU | | |from |LU | | | | | | |AF13..EF | | +==============+=============+====+======+===+=========+====+¶
Table showing 0b000xxx DSCPs. This highlights any current assignments and whether they are affected by any known re-marking behaviors, such as ToS Precdence bleaching. * DSCP 4 has been historically used by the SSH application. [Kol10].¶
DSCPs of the form 0b000xxx can be impacted by known re-marking behaviours of other assigned DSCPs. For example, ToS Precedence Bleaching of popular DSCPs AF11, AF21, AF31, AF41 would result in traffic being re-marked with DSCP 2 in the Internet core. The Lower-Effort Per-Hop Behavior PHB (LE) uses a DSCP of 1. The DSCP value of 4 has been historically used by the SSH application, following semantics that precede DiffServ [Kol10].¶
Bleach-ToS-Precedence (Section 4) of packets with a DSCP 'x' result 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.¶
[RFC2474] 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 (Re-mark-ToS (Section 4)) [RFC1349]. These practices based on ToS semantics have not yet been eliminated from deployed networks.¶
+-+-+-+-+-+-+ |0 0 1|x x x| +-+-+-+-+-+-+¶
Figure showing the ToS Precedence Re-marking (Re-mark-ToS (Section 4)) observed behavior, based on Section 3 of [RFC1349]. 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.¶
A network device might re-mark the DiffServ field of an IP packet based on a local policy with a specific (set of) DSCPs (Re-mark-DSCP (Section 4)).¶
Section 3 of [RFC2474] 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 [RFC2475] [RFC3290] [RFC4594].¶
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 (Bleach-DSCP (Section 4)) is a specific example of this observed re-marking behavior that re-marks to CS0 (0x00) - see Section 4.1.¶
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 PCP field in an IEEE Ethernet 802.1Q header, the 3-bit UP field or the 3-bit Traffic Class field of Multi-Protocol Label Switching (MPLS). A Treatment Aggregate (TA) [RFC5127] is an optional intermediary mapping groups of BAs to PHBs.¶
The IEEE specifies standards that include mappings for DSCPs to lower layer elements.¶
IEEE 802.1Q specified a 3-bit Priority Code Point (PCP) field, which includes a tag that allows Ethernet frames to be marked as one of eight priority values [IEEE-802-1Q]. Use of this field is described by various documents, including IEEE P802.1p, and IEEE 802.1D.¶
The mapping specified in [IEEE-802-1Q] revises a previous standard [IEEE-802-1D], in an effort to align with DiffServ practice [RFC4594]. 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 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. This aligned with the now deprecated use of CS1 as the codepoint for the lower effort service, as previously specified in [RFC4594]. 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 [IEEE-802-1D] 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.¶
Section 6 of [RFC8325] provides a brief overview of IEEE 802.11 QoS. The IEEE 802.11 standards [IEEE-802-11] provide MAC functions to support QoS in WLANs using Access Classes (AC). The upstream User Priority (UP) in the 802.11 header has a 3-bit QoS value. A DSCP can be mapped to the UP. [RFC8622] added mapping for the LE DSCP, mapping this 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 RFC8325 and provides functions at an AP to re-mark packets as well as a QoS Map that maps each DSCP to an AC [WIFI-ALLIANCE].¶
+-+-+-+-+-+-+ |x x x|. . .| +-+-+-+-+-+-+¶
Figure showing the DSCP bits commonly mapped to the UP in 802.11. The bit positions marked "x" are mapped to the 3-bit UP value, while the ones marked "." are ignored.¶
RFC8325 [RFC8325] 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 Section 5.1.2 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 (Section 4.1).¶
For other UPs, RFC8325 recommends a mapping in the upstream direction that derives the DSCP from the value of the UP multiplied by 8. This mapping can result in a specific DSCP re-marking behavior.¶
In the upstream direction (wireless-to-wired interconnections), this mapping can result in a specific DSCP re-marking behavior. Some Access Points (APs) currently use a default UP-to-DSCP mapping [RFC8325], wherein "DSCP values are derived from the layer 2 UP values by multiplying the UP values by eight (i.e., shifting the three UP bits to the left and adding three additional zeros to generate a 6-bit DSCP value). This derived DSCP value is used for QoS treatment between the wireless AP and the nearest classification and marking policy enforcement point (which may be a central 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 (Section 4).¶
+-+-+-+-+-+-+ |x x x|0 0 0| +-+-+-+-+-+-+¶
Figure showing the observed re-marking behavior resulting from deriving from UP-to-DSCP mapping in some 802.11 networks.¶
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, RFC5415 [RFC5415], 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 Section 2 of [RFC8325]. A QoS profile can be used to limit the maximum DSCP value used for the upstream and downstream traffic.¶
Multi-Protocol Label Switching (MPLS) specified eight MPLS Traffic Classes (TCs), which restrict the number of different treatments [RFC5129]. RFC 5127 describes the aggregation of DiffServ TCs [RFC5127] and introduces four DiffServ Treatment Aggregates. Traffic marked with multiple DSCPs can be forwarded in a single MPLS TC.¶
There are three Label-Switched Router (LSR) models: the Pipe, the Short Pipe and the Uniform Model [RFC3270]. 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.¶
RFC3270 [RFC3270] 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 Section 4.2 of [RFC3270].¶
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 (Section 2.5.2 of [RFC3270]).¶
The Short Pipe Model is an optional variation of the Pipe Model [RFC3270].¶
ITU-T Y.1566 [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. [RFC8100] describes four treatment aggregates 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.¶
RFC8100 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 RFC8100 limits the number of DSCPs to 6 and 3 more are suggested for extension. RFC8100 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 RFC8100 codepoint scheme are treated as unexpected and will possibly be re-marked (a Re-mark-DSCP (Section 4) behavior) or dealt with via an additional agreement(s) among the operators of the interconnected networks. RFC8100 can be extended to support up to 32 DSCPs by future standards. RFC8100 is operated by at least one Tier 1 backbone provider. Use of the MPLS Short Pipe Model favours re-marking unexpected DSCP values to zero in the absence of an additional agreement(s), as explained in [RFC8100]. This can result in bleaching (Bleach-DSCP (Section 4)).¶
+--------------------------------------+--------+ | RFC8100 | DSCP | | Agg. Class | | +--------------------------------------+--------+ |Telephony Service Treatment Aggregate | EF | | | VA | +--------------------------------------+--------+ |Bulk Real-Time Treatment Aggregate | AF41 | | May be added | (AF42) | | May be added | (AF43) | +--------------------------------------+--------+ |Assured Elastic Treatment Aggregate | AF31 | | | AF32 | | Reserved for the extension of PHBs| (AF33) | +--------------------------------------+--------+ |Default / Elastic Treatment Aggregate | BE/CS0 | +--------------------------------------+--------+ |Network Control: Local Use (LU) | CS6 | +--------------------------------------+--------+¶
Table: The short-pipe MPLS mapping from RFC 8100.¶
Mobile LTE and 5G standards have evolved from older UMTS standards, and support DiffServ. LTE (4G) and 5G standards [SA-5G] 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 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 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 IPX Provider networks [GSMA-IR-34]. 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 which situation the IPX Provider can re-mark the DSCP value to a static default value.¶
+---------------+-------+ | GSMA IR.34 | PHB | | Agg. Class | | +---------------+-------+ |Conversational | EF | +---------------+-------+ | Streaming | AF41 | +---------------+-------+ | Interactive | AF31 | + +-------+ | (ordered by | AF32 | + priority, +-------+ | AF3 highest) | AF21 | + +-------+ | | AF11 | +---------------+-------+ | Background | CS0 | +---------------+-------+¶
Table showing the PHB mapping recommended in the guidelines recommended in [GSMA-IR-34].¶
Metro Ethernet Forum (MEF) provides a mapping of DSCPs at the IP layer to quality of service markings in the Ethernet frame headers [MEF23.1].¶
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).¶
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 - MPLS - IP - Ethernet - Wi-Fi).¶
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. The section identifies known issues that might influence the finally assigned DSCP, and provides a summary of considerations for assignment of a new DSCP.¶
Section 4 describes re-marking of the DSCP. New DSCP assignments should consider the impact of bleaching (Bleach-DSCP (Section 4)) or re-marking (Re-mark-DSCP (Section 4)) 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 [RFC8622]. Forwarding LE using the default PHB is in line with RFC8622, 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 (Section 4) and Bleach-some-low (Section 4)), 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.¶
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 (Section 4) and Bleach-some-ToS (Section 4)) or ToS Precedence Re-marking (Re-mark-ToS (Section 4)) is experienced. For example, it can be desirable to avoid choosing a DSCP that could be re-marked to LE, Lower Effort [RFC8622], which could otherwise potentially result in a priority inversion in the treatment.¶
As a consequence of assigning the LE PHB [RFC8622], 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 (Section 4) 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 traffic class. Care should be taken to consider the implications of re-marking when choosing to assign a DSCP with this format.¶
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 which receives the treatment associated with DSCP 2. New DSCP assignments should consider unexpected consequences arising from this observed re-marking behavior.¶
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:¶
The DSCP re-marking corresponding to the Bleach-ToS-Precedence (Section 4) observed behavior described in Section 4 can arise for various reasons, one of which is old equipment which 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.¶
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:¶
The authors acknowledge the helpful discussions and analysis by Greg White and Thomas Fossati in a draft concerning NQB. Ruediger Geib and Brian Carpenter contributed comments, along with other members of the TSVWG.¶
IANA is requested to append the page for the Differentiated Services Field Codepoints (DSCP) registry at: https://www.iana.org/assignments/dscp-registry/dscp-registry.xhtml. This request is to add the following separate paragraph to the Note at the top of the registry page: "See [RFC-to-be] for considerations when assigning a new codepoint from the DSCP registry."¶
The security considerations are discussed in the security considerations of each cited RFC.¶
Note to RFC-Editor: please remove this entire section prior to publication.¶
Working Group -02:¶
Working Group -03¶
Working Group -04¶
Working Group -05¶
Working Group -06¶
Working Group -07¶
Working Group -08¶
Working Group -09¶
Working Group -10¶
Working Group -11¶
Working Group -12¶
Working Group -13¶