DSCP Pool 3: Update to IANA Registration Procedures for Pool 3 Values in the Differentiated Services Field Codepoints (DSCP) Registry
A small policy change that lets the IETF hand out Pool 3 Diffserv codepoints through Standards Action.
Fairhurst, G., "Update to IANA Registration Procedures for Pool 3 Values in the Differentiated Services Field Codepoints (DSCP) Registry", RFC 8436, DOI 10.17487/RFC8436, August 2018, <https://www.rfc-editor.org/info/rfc8436>.
@misc{rfc8436,
series = {Request for Comments},
number = 8436,
howpublished = {RFC 8436},
publisher = {RFC Editor},
doi = {10.17487/RFC8436},
url = {https://www.rfc-editor.org/info/rfc8436},
author = {G. Fairhurst},
title = {{Update to IANA Registration Procedures for Pool 3 Values in the Differentiated Services Field Codepoints (DSCP) Registry}},
pagetotal = 7,
year = 2018,
month = aug,
} RFC text
Contents
Internet Engineering Task Force (IETF) G. Fairhurst
Request for Comments: 8436 University of Aberdeen
Updates: 2474 August 2018
Category: Standards Track
ISSN: 2070-1721
Update to IANA Registration Procedures for Pool 3 Values in the
Differentiated Services Field Codepoints (DSCP) Registry
Abstract
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.
Status of This Memo
This is an Internet Standards Track document.
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). Further information on
Internet Standards is available in 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
https://www.rfc-editor.org/info/rfc8436.
Copyright Notice
Copyright (c) 2018 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 Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The Updates to RFC 2474 . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Normative References . . . . . . . . . . . . . . . . . . 6
6.2. Informative References . . . . . . . . . . . . . . . . . 6
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
The Differentiated Services (Diffserv) [RFC2475] architecture
(updated by [RFC3260]) 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 DSCP.
This DSCP value is used to select a Diffserv per-hop behavior (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 [RFC2474]. These are
assigned by Standards Action, as defined in [RFC8126]. Pool 2
comprises a pool of 16 codepoints reserved for Experimental or Local
Use (EXP/LU) as defined in [RFC2474]. Pool 3 comprises 16
codepoints, which were originally specified as "initially available
for experimental or local use, but which should be preferentially
utilized for standardized assignments if Pool 1 is ever exhausted" by
[RFC2474].
+------+-----------------+
| Pool | Codepoint Space |
+------+-----------------+
| 1 | xxxxx0 |
+------+-----------------+
| 2 | xxxx11 |
+------+-----------------+
| 3 | xxxx01 |
+------+-----------------+
Figure 1: Format of the Field for Codepoints Allocated in the Three
IANA Pools (Where "x" Refers to Either "0" or "1")
At the time of writing this document, 22 of the 32 Pool 1 codepoints
have been assigned.
Although Pool 1 has not yet been completely exhausted, there is a
need to assign codepoints for particular PHBs that are unable to use
any of the unassigned values in Pool 1. This document changes the
IANA registration policy of Pool 3 to assignment by Standards Action.
(Section 4.9 of [RFC8126] defines this as "assigned only through
Standards Track or Best Current Practice RFCs in the IETF Stream".)
An example is the need to assign a suitable recommended default
codepoint for the Lower Effort (LE) PHB [LE-PHB]. The LE PHB is
designed to protect best-effort (BE) traffic (packets forwarded with
the default PHB) from LE traffic in congestion situations (when
resources become scarce, best-effort traffic has precedence over LE
traffic and is allowed to preempt it). In deployed networks,
bleaching (i.e. intentionally setting to zero) of the IP Precedence
field continues to be used. (Setting the IP Precedence field to zero
disables any class-based flow management by routers configured with
TOS-based packet processing.) This causes the first three bits of
the former TOS byte (now the upper part of the DSCP field) to become
zero. Therefore, there is a need to avoid this remapping of the DSCP
for the LE PHB by assigning a codepoint that already has a zero value
in the first three bits [LE-PHB].
Furthermore, if the LE PHB were to have been assigned one of the
currently unused Pool 1 codepoints with a zero value in the first
three bits, any bleaching of the IP Precedence field would result in
other (higher assurance) traffic being also remapped to the assigned
DSCP. This remapping could then cause Diffserv-marked traffic to
receive an unintentional LE treatment for the remainder of the
Internet path. Therefore, it is important to avoid the resulting
priority inversion. 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 utilize Pool 3 codepoints, this document
requests IANA to manage Pool 3 assignments for DSCP values in Pool 3
via the Standards Action policy [RFC8126].
2. Terminology
This document assumes familiarity with the terminology used in
[RFC2475] updated by [RFC3260].
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.
3. The Updates to RFC 2474
This document updates Section 6 of [RFC2474] in the following ways.
It updates the following text concerning the assignment policy:
OLD: which are initially available for experimental or local use,
but which should be preferentially utilized for standardized
assignments if Pool 1 is ever exhausted.
NEW: which are utilized for standardized assignments (replacing the
previous availability for experimental or local use).
It removes the footnote in RFC 2474 relating to Pool 3:
DELETE: "(*) may be utilized for future Standards Action allocations
as necessary"
The new registry assignment policy is shown in Figure 2.
Pool Codepoint Space Assignment Policy
---- --------------- ------------------
1 xxxxx0 Standards Action
2 xxxx11 EXP/LU
3 xxxx01 Standards Action
Note for Pool 2: "Reserved for Experimental or Local Use"
Figure 2: Updated Assignment Policy for the DSCP Registry
4. Security Considerations
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.
5. IANA Considerations
IANA has changed the use of Pool 3 in the "Differentiated Services
Field Codepoints (DSCP)" registry and will manage this pool using
Standards Action, as defined as Section 4.9 of [RFC8126].
IANA has made the following changes to the "Differentiated Services
Field Codepoints (DSCP)" registry, made available at [Registry].
IANA has referenced RFC 2474 and Section 4 of RFC 3260 for the
overall format of this registry.
IANA has referenced RFC 2474 and Section 4 of RFC 3260 for Pool 1.
This document 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 for Pool 3:
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 has created and will maintain
the "DSCP Pool 3 Codepoints" subregistry. Pool 3 of the registry has
been created initially empty, with a format identical to that used
for "DSCP Pool 1 Codepoints".
IANA has referenced RFC 2474, Section 4 of RFC 3260, and the current
document for Pool 3.
The registration procedure for use of Pool 3 is Standards Action, as
defined as Section 4.9 of [RFC8126]. IANA is expected to normally
make assignments from Pool 1, until this Pool is exhausted, but it
MAY make assignments from Pool 3 when the format of the codepoint has
properties that are needed for a specific PHB. The required
characteristics for choosing a requested DSCP value MUST be explained
in the IANA Considerations section of the document that requests any
assignment from Pool 3.
6. References
6.1. Normative References
[Registry]
IANA, "Differentiated Services Field Codepoints (DSCP)",
<https://www.iana.org/assignments/dscp-registry/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>.
[RFC3260] Grossman, D., "New Terminology and Clarifications for
Diffserv", RFC 3260, DOI 10.17487/RFC3260, April 2002,
<https://www.rfc-editor.org/info/rfc3260>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
6.2. Informative References
[LE-PHB] Bless, R., "A Lower Effort Per-Hop Behavior (LE PHB)",
Work in Progress, draft-ietf-tsvwg-le-phb-05, July 2018.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<https://www.rfc-editor.org/info/rfc2475>.
Acknowledgments
Godred Fairhurst received funding from the European Union's Horizon
2020 research and innovation program 2014-2018 under grant agreement
No. 644334 (NEAT).
Author's Address
Godred Fairhurst
University of Aberdeen
Department of Engineering
Fraser Noble Building
Aberdeen AB24 3UE
United Kingdom
Email: gorry@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.uk/
AI ELI5
On this page
§1What the RFC Changes
Differentiated Services (Diffserv) uses the six most significant bits of the former IPv4 Type of Service octet, or the former IPv6 Traffic Class octet, to carry a DSCP. The DSCP value selects a per-hop behavior (PHB).
RFC 8436 is a short administrative update to RFC 2474. It changes the IANA registration policy for Pool 3 of the DSCP registry to Standards Action, and it removes the permission to use Pool 3 codepoints for experimental or local purposes.
This note changes the rule about who may hand out one group of packet labels. Before, anyone could try them out. Now they are kept for official uses.
§2The Three Codepoint Pools
The six-bit field can convey 64 distinct codepoints. The codepoint space is divided into three pools for assignment and management.
- Pool 1: 32 codepoints of the form
xxxxx0, assigned by Standards Action as defined in RFC 8126. - Pool 2: 16 codepoints of the form
xxxx11, reserved for Experimental or Local Use (EXP/LU). - Pool 3: 16 codepoints of the form
xxxx01. RFC 2474 described them as initially available for experimental or local use, but to be used preferentially for standardized assignments if Pool 1 is ever exhausted.
At the time of writing, 22 of the 32 Pool 1 codepoints had been assigned.
Imagine 64 sticker designs split into three boxes. One box is for official stickers, one is for doodling, and the third was a spare box that could be used for either.
§3Why Pool 1 Is Not Enough
Pool 1 is not yet exhausted, but some PHBs cannot use any of its unassigned values. The RFC's example is the Lower Effort (LE) PHB. It is designed to protect best-effort traffic from LE traffic in congestion: when resources become scarce, best-effort traffic has precedence over LE traffic.
In deployed networks, bleaching of the IP Precedence field (intentionally setting it to zero) continues to be used. That makes the first three bits of the old TOS byte zero. To avoid the LE codepoint being remapped, it needs a value whose first three bits are already zero.
If LE had been given an unused Pool 1 value with that property, bleaching would also remap other, higher assurance traffic onto the same DSCP. Diffserv-marked traffic could then get unintentional LE treatment for the rest of its path, a priority inversion. No unassigned Pool 1 codepoints have the needed properties, which motivates using a Pool 3 codepoint.
Some network gear wipes the first part of the label to zero. A label for low-priority traffic must survive that wiping, or important packets might get mistaken for unimportant ones. The unused official labels did not fit, so the spare box is needed.
§4The Update to RFC 2474
The RFC updates Section 6 of RFC 2474. The old text said the Pool 3 codepoints were initially available for experimental or local use, but should be preferentially used for standardized assignments if Pool 1 is ever exhausted. The new text says they are utilized for standardized assignments, replacing the previous availability for experimental or local use.
It also deletes the footnote in RFC 2474 that said Pool 3 may be utilized for future Standards Action allocations as necessary.
The resulting policy is Standards Action for Pool 1, EXP/LU for Pool 2 and Standards Action for Pool 3.
The spare box used to be open for doodling. Now it is closed to doodling and only for official stickers. The doodle box stays open.
| Pool | Codepoint space | Assignment policy |
|---|---|---|
| 1 | xxxxx0 | Standards Action |
| 2 | xxxx11 | EXP/LU |
| 3 THIS RFC | xxxx01 | Standards Action |
§5What IANA Does
IANA changed the use of Pool 3 in the Differentiated Services Field Codepoints (DSCP) registry and manages it with Standards Action, which RFC 8126 defines as assignment only through Standards Track or Best Current Practice RFCs in the IETF Stream. Pool 2 is not modified.
IANA created a "DSCP Pool 3 Codepoints" subregistry, initially empty and formatted like the Pool 1 subregistry.
IANA is expected to normally assign from Pool 1 until it is exhausted, but it MAY assign from Pool 3 when the codepoint format has properties needed for a specific PHB. The document requesting such an assignment MUST explain the required characteristics in its IANA Considerations section.
The keeper of the list starts with an empty page for the spare box. Anyone asking for one of its labels must explain why that exact label is needed.
§6Security Considerations
The RFC says that security considerations for the use of DSCP values are described in the RFCs that define their usage. It does not present new security considerations.
This note only changes who may give out labels, so it adds no new safety worries. Each label's own rulebook covers those.