]> University of Aberdeen

Department of Engineering Fraser Noble Building Aberdeen AB24 3UE Scotland gorry@erg.abdn.ac.uk http://www.erg.abdn.ac.uk/

Transport Area Transport Area Working Group Diffserv DSCP The Differentiated Services (Diffserv) architecture specifies use of a field in the IPv4 and IPv6 packet headers to carry Diffserv Codepoint (DSCP) values. The Internet Assigned Numbers Authority (IANA) maintains a registry of assigned DSCP values. This update to RFC2474 changes the IANA assignment method 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.

The Differentiated Services (Diffserv) architecture (updated by ) provides scalable service differentiation in the Internet. Diffserv uses the six most significant bits of the former IPv4 Type of Service (TOS) octet or the former IPV6 Traffic Class octet to convey the field, which is used to carry the Diffserv Codepoint (DSCP). This DSCP value is used to select a Diffserv Per hop Behaviour, PHB. The six bit field is capable of conveying 64 distinct codepoints, and this codepoint space has been divided into three pools for the purpose of codepoint assignment and management (as shown in figure 1). Pool 1 comprises 32 codepoints . These are assigned by Standards Action, as defined in . Pool 2 comprises a pool of 16 codepoints reserved for experimental or Local Use (EXP/LU) as defined in , and Pool 3 comprises 16 codepoints, which were specified as "initially available for experimental or local use, but which should be preferentially utilized for standardized assignments if Pool 1 is ever exhausted" .

At the time of writing this document, 22 of the 32 Pool 1 codepoints have currently been assigned. Although Pool 1 has not yet been completely exhausted, this document changes the IANA registration policy of Pool 3 to assignment by Standards Action, i.e., values are assigned by Standards Track or Best Current Practice RFCs. The rationale for this update is a need to assign codepoints for particular PHBs that are unable to use any of the unassigned values in Pool 1. An example is the need to assign a suitable recommended default codepoint for the Lower Effort (LE) per-hop behavior (PHB) . The LE PHB is designed to protect best-effort (BE) traffic (packets forwarded with the default PHB) from LE traffic in congestion situations, i.e., when resources become scarce, best-effort traffic has precedence over LE traffic and may preempt it. The continued presence of bleaching of the IP precedence field, setting the first three bits of the former TOS byte to zero (i.e., zeroing the top three bits of the DSCP) in deployed networks motivates the desire for the LE PHB to use a DSCP with a zero value for the first three bits . At the same time, it is also important to reduce the likelihood of priority inversion caused by unintentional re-mapping of other (higher assurance) traffic to the DSCP used for this PHB. The absence of unassigned codepoints in Pool 1 that exhibit these important properties motivates assigning a Pool 3 codepoint as the default that is recommended for use with this PHB. To allow the IETF to utilise Pool 3 codepoints, this document requests IANA to to manage Pool 3 assignments for DSCP values in Pool 3 via the Standards Action policy . This assignment method requires publication of a Standards Track or Best Current Practice RFC.

This document assumes familiarity with the terminology used in updated by . 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 .

This document updates section 6 of , in the following ways. It updates the following text concerning the assignment method: which are initially available for experimental or local use, but which should be preferentially utilized for standardized assignments if Pool 1 is ever exhausted. which are utilized for standardized assignments (replacing the previous availability for experimental or local use). It removes the footnote in RFC2474 relating to Pool 3: "(*) may be utilized for future Standards Action allocations as necessary" The new registry contents are shown in Figure 2.

Security considerations for the use of DSCP values are described in the RFCs that define their usage. This document does not present new security considerations.

This section requests IANA to change the use of Pool 3 in the DSCP registry and to manage this pool using a Standards Action assignment method. This requests IANA to make the following changes to the Differentiated Services field Codepoints (DSCP) Registry, made available at . This update does not modify the IANA registry text for Pool 2. This pool continues to preserve the note shown in Figure 2. The previous registry text: 3 xxxx01 Experimental or Local Use May be utilized for future Standards Action allocations as necessary. is replaced with the following registry text: 3 xxxx01 Standards Action. To manage codepoints in Pool 3, IANA is requested to create and maintain a "Pool 3 Codepoints" entry. Pool 3 of the registry is to be created initially empty, with a format identical to that used for "Pool 1 Codepoints". The Registration Procedure for use of Pool 3 is "Standards Action" . IANA is expected to normally make assignments from Pool 1, until this Pool is exhausted, but MAY make assignments from Pool 3 where the format of the codepoint has properties that are needed for a specific PHB. The required characteristics for choosing the DSCP value MUST be explained in the IANA considerations of the document that requests any assignment from Pool 3 IANA is requested to reference RFC3260 and this current document.

G. Fairhurst received funding from the European Union's Horizon 2020 research and innovation program 2014-2018 under grant agreement No. 644334 (NEAT).

&RFC2119; &RFC2474; &RFC3260; &RFC8126; IANA &I-D.ietf-tsvwg-le-phb; &RFC2475;

Note to RFC-Editor: please remove this entire section prior to publication. Individual submission as draft -00. This is the initial version of the document. Advice in this rev. from Michelle Cotton on the IANA procedure. Thanks to Brian Carpenter for helpful inputs to this ID. Individual submission as draft -01. Thanks to Roland Bless for review comments. Individual submission as draft -02 (author requests adoption as a TSVWG WG draft). Thanks to David Black for review comments in preparing rev -02. Working Group submission as draft -00 Adopted by the TSVWG working group. Working Group submission as draft -01 Fixed exploded acronyms. Working Group submission as draft -02 Corrections after WGLC. Working Group submission as draft -03 Corrections after TSVWG Shepherd Review.