draft-ietf-tsvwg-iana-dscp-registry-08.txt   rfc8436.txt 
Transport Area Working Group G. Fairhurst Internet Engineering Task Force (IETF) G. Fairhurst
Internet-Draft University of Aberdeen Request for Comments: 8436 University of Aberdeen
Updates: 2474 (if approved) June 07, 2018 Updates: 2474 August 2018
Intended status: Standards Track Category: Standards Track
Expires: December 07, 2018 ISSN: 2070-1721
IANA Assignment of DSCP Pool 3 (xxxx01) Values to require Publication of Update to IANA Registration Procedures for Pool 3 Values in the
a Standards Track or Best Current Practice RFC Differentiated Services Field Codepoints (DSCP) Registry
draft-ietf-tsvwg-iana-dscp-registry-08
Abstract Abstract
The Differentiated Services (Diffserv) architecture specifies use of The Differentiated Services (Diffserv) architecture specifies use of
a field in the IPv4 and IPv6 packet headers to carry Diffserv the DS field in the IPv4 and IPv6 packet headers to carry one of 64
Codepoint (DSCP) values. The Internet Assigned Numbers Authority distinct differentiated services field codepoint (DSCP) values. The
(IANA) maintains a registry of assigned DSCP values. Internet Assigned Numbers Authority (IANA) maintains a registry of
assigned DSCP values.
This update to RFC2474 changes the IANA assignment policy for Pool 3 This update to RFC 2474 changes the IANA registration policy for Pool
of the registry (i.e., DSCP values of the form xxxx01) to Standards 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 Action, i.e., values are assigned through a Standards Track or Best
Current Practice RFC. The update also removes permission for Current Practice RFC. The update also removes permission for
experimental and Local Use of the Codepoints that form Pool 3 of the 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 DSCP registry; Pool 2 Codepoints (i.e., DSCP values of the form
xxxx11) remain available for these purposes. xxxx11) remain available for these purposes.
Status of this Memo Status of This Memo
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 This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on December 07, 2018. 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 Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (http://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Simplified BSD License text to this document. Code Components extracted from this document must
as described in Section 4.e of the Trust Legal Provisions and are include Simplified BSD License text as described in Section 4.e of
provided without warranty as described in the Simplified BSD License. the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The update to RFC2474 . . . . . . . . . . . . . . . . . . . . 4 3. The Updates to RFC 2474 . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.1. Normative References . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 6.2. Informative References . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . . 6 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 6
Appendix A. Revision Notes . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction 1. Introduction
The Differentiated Services (Diffserv) [RFC2475] architecture The Differentiated Services (Diffserv) [RFC2475] architecture
(updated by [RFC3260]) provides scalable service differentiation in (updated by [RFC3260]) provides scalable service differentiation in
the Internet. Diffserv uses the six most significant bits of the the Internet. Diffserv uses the six most significant bits of the
former IPv4 Type of Service (TOS) octet or the former IPv6 Traffic 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 Class octet to convey the field, which is used to carry the DSCP.
Codepoint (DSCP). This DSCP value is used to select a Diffserv Per This DSCP value is used to select a Diffserv per-hop behavior (PHB).
hop Behaviour, PHB.
The six bit field is capable of conveying 64 distinct codepoints, and The six-bit field is capable of conveying 64 distinct codepoints, and
this codepoint space has been divided into three pools for the this codepoint space has been divided into three pools for the
purpose of codepoint assignment and management (as shown in figure purpose of codepoint assignment and management (as shown in
1). Pool 1 comprises 32 codepoints [RFC2474]. These are assigned by Figure 1). Pool 1 comprises 32 codepoints [RFC2474]. These are
Standards Action, as defined in [RFC8126]. Pool 2 comprises a pool assigned by Standards Action, as defined in [RFC8126]. Pool 2
of 16 codepoints reserved for experimental or Local Use (EXP/LU) as comprises a pool of 16 codepoints reserved for Experimental or Local
defined in [RFC2474], and Pool 3 comprises 16 codepoints, which were Use (EXP/LU) as defined in [RFC2474]. Pool 3 comprises 16
specified as "initially available for experimental or local use, but codepoints, which were originally specified as "initially available
which should be preferentially utilized for standardized assignments for experimental or local use, but which should be preferentially
if Pool 1 is ever exhausted" [RFC2474]. utilized for standardized assignments if Pool 1 is ever exhausted" by
[RFC2474].
+------+-----------------+ +------+-----------------+
| Pool | Codepoint Space | | Pool | Codepoint Space |
+------+-----------------+ +------+-----------------+
| 1 | xxxxx0 | | 1 | xxxxx0 |
+------+-----------------+ +------+-----------------+
| 2 | xxxx11 | | 2 | xxxx11 |
+------+-----------------+ +------+-----------------+
| 3 | xxxx01 | | 3 | xxxx01 |
+------+-----------------+ +------+-----------------+
Figure 1: Format of the field for codepoints allocated in the Figure 1: Format of the Field for Codepoints Allocated in the Three
three IANA pools (where 'x' refers to either '0' or '1'). IANA Pools (Where "x" Refers to Either "0" or "1")
At the time of writing this document, 22 of the 32 Pool 1 codepoints At the time of writing this document, 22 of the 32 Pool 1 codepoints
have currently been assigned. have been assigned.
Although Pool 1 has not yet been completely exhausted, there is a Although Pool 1 has not yet been completely exhausted, there is a
need to assign codepoints for particular PHBs that are unable to use need to assign codepoints for particular PHBs that are unable to use
any of the unassigned values in Pool 1. This document changes the any of the unassigned values in Pool 1. This document changes the
IANA registration policy of Pool 3 to assignment by Standards Action IANA registration policy of Pool 3 to assignment by Standards Action.
(Section 4.9 of [RFC8126] defines this as "assigned only through (Section 4.9 of [RFC8126] defines this as "assigned only through
Standards Track or Best Current Practice RFCs in the IETF Stream"). Standards Track or Best Current Practice RFCs in the IETF Stream".)
An example is the need to assign a suitable recommended default An example is the need to assign a suitable recommended default
codepoint for the Lower Effort (LE) per-hop behavior (PHB) [I-D.ietf- codepoint for the Lower Effort (LE) PHB [LE-PHB]. The LE PHB is
tsvwg-le-phb]. The LE PHB is designed to protect best-effort (BE) designed to protect best-effort (BE) traffic (packets forwarded with
traffic (packets forwarded with the default PHB) from LE traffic in the default PHB) from LE traffic in congestion situations (when
congestion situations (i.e., when resources become scarce, best- resources become scarce, best-effort traffic has precedence over LE
effort traffic has precedence over LE traffic and is allowed to traffic and is allowed to preempt it). In deployed networks,
preempt it). In deployed networks, there is continued use of bleaching (i.e. intentionally setting to zero) of the IP Precedence
bleaching (i.e. intentionally setting to zero) of the IP precedence field continues to be used. (Setting the IP Precedence field to zero
field. (Setting the IP Precedence field to zero disables any class- disables any class-based flow management by routers configured with
based flow management by routers configured with TOS-based packet TOS-based packet processing.) This causes the first three bits of
processing). This causes the first three bits of the former TOS byte the former TOS byte (now the upper part of the DSCP field) to become
(now the upper part of the DSCP field) to become zero. There is zero. Therefore, there is a need to avoid this remapping of the DSCP
therefore a need to avoid this remapping of the DSCP for the LE PHB for the LE PHB by assigning a codepoint that already has a zero value
by assigning a codepoint that already has a zero value in the first in the first three bits [LE-PHB].
three bits [I-D.ietf-tsvwg-le-phb].
Furthermore, if the LE PHB were to have been assigned one of the 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 currently unused Pool 1 codepoints with a zero value in the first
three bits, any bleaching of the IP precedence field would result in three bits, any bleaching of the IP Precedence field would result in
other (higher assurance) traffic being also remapped to the assigned other (higher assurance) traffic being also remapped to the assigned
DSCP. This remapping could then cause diffserv-marked traffic to DSCP. This remapping could then cause Diffserv-marked traffic to
receive an unintentional LE treatment for the remainder of the receive an unintentional LE treatment for the remainder of the
Internet path. It is therefore important to avoid the resulting Internet path. Therefore, it is important to avoid the resulting
priority inversion. The absence of unassigned codepoints in Pool 1 priority inversion. The absence of unassigned codepoints in Pool 1
that exhibit these important properties motivates assigning a Pool 3 that exhibit these important properties motivates assigning a Pool 3
codepoint as the default that is recommended for use with this PHB. codepoint as the default that is recommended for use with this PHB.
To allow the IETF to utilise Pool 3 codepoints, this document To allow the IETF to utilize Pool 3 codepoints, this document
requests IANA to to manage Pool 3 assignments for DSCP values in Pool requests IANA to manage Pool 3 assignments for DSCP values in Pool 3
3 via the Standards Action policy [RFC8126]. via the Standards Action policy [RFC8126].
2. Terminology 2. Terminology
This document assumes familiarity with the terminology used in This document assumes familiarity with the terminology used in
[RFC2475] updated by [RFC3260]. [RFC2475] updated by [RFC3260].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. The update to RFC2474 3. The Updates to RFC 2474
This document updates section 6 of [RFC2474], in the following ways. This document updates Section 6 of [RFC2474] in the following ways.
It updates the following text concerning the assignment policy: It updates the following text concerning the assignment policy:
OLD: which are initially available for experimental or local use, but OLD: which are initially available for experimental or local use,
which should be preferentially utilized for standardized but which should be preferentially utilized for standardized
assignments if Pool 1 is ever exhausted. assignments if Pool 1 is ever exhausted.
NEW: which are utilized for standardized assignments (replacing the NEW: which are utilized for standardized assignments (replacing the
previous availability for experimental or local use). previous availability for experimental or local use).
It removes the footnote in RFC2474 relating to Pool 3: It removes the footnote in RFC 2474 relating to Pool 3:
DELETE: "(*) may be utilized for future Standards Action allocations DELETE: "(*) may be utilized for future Standards Action allocations
as necessary" as necessary"
The new registry assignment policy is shown in Figure 2. The new registry assignment policy is shown in Figure 2.
Pool Codepoint space Assignment Policy Pool Codepoint Space Assignment Policy
---- --------------- ------------------ ---- --------------- ------------------
1 xxxxx0 Standards Action 1 xxxxx0 Standards Action
2 xxxx11 EXP/LU 2 xxxx11 EXP/LU
3 xxxx01 Standards Action 3 xxxx01 Standards Action
Note for Pool 2: "Reserved for experimental or Local Use" Note for Pool 2: "Reserved for Experimental or Local Use"
Figure 2: Updated Assignment Policy for the DSCP Registry Figure 2: Updated Assignment Policy for the DSCP Registry
4. Security Considerations 4. Security Considerations
Security considerations for the use of DSCP values are described in Security considerations for the use of DSCP values are described in
the RFCs that define their usage. This document does not present new the RFCs that define their usage. This document does not present new
security considerations. security considerations.
5. IANA Considerations 5. IANA Considerations
This section requests IANA to change the use of Pool 3 in the DSCP IANA has changed the use of Pool 3 in the "Differentiated Services
registry and to manage this pool using Standards Action, as defined Field Codepoints (DSCP)" registry and will manage this pool using
as Section 4.9 of [RFC8126]. Standards Action, as defined as Section 4.9 of [RFC8126].
This requests IANA to make the following changes to the IANA has made the following changes to the "Differentiated Services
Differentiated Services field Codepoints (DSCP) Registry, made Field Codepoints (DSCP)" registry, made available at [Registry].
available at [Registry].
IANA is requested to reference RFC2474 and Section 4 of RFC3260 for IANA has referenced RFC 2474 and Section 4 of RFC 3260 for the
the overall format of the DSCP registry. overall format of this registry.
IANA is requested to reference RFC2474 and Section 4 of RFC3260 for IANA has referenced RFC 2474 and Section 4 of RFC 3260 for Pool 1.
Pool 1.
This update does not modify the IANA registry text for Pool 2. This This document does not modify the IANA registry text for Pool 2.
pool continues to preserve the note shown in Figure 2. This pool continues to preserve the note shown in Figure 2.
The previous registry text: The previous registry text for Pool 3:
3 xxxx01 Experimental or Local Use May be utilized for future 3 xxxx01 Experimental or local use may be utilized for future
Standards Action allocations as necessary. Standards Action allocations as necessary.
is replaced with the following registry text: is replaced with the following registry text:
3 xxxx01 Standards Action. 3 xxxx01 Standards Action.
To manage codepoints in Pool 3, IANA is requested to create and To manage codepoints in Pool 3, IANA has created and will maintain
maintain a "Pool 3 Codepoints" subregistry. Pool 3 of the registry the "DSCP Pool 3 Codepoints" subregistry. Pool 3 of the registry has
is to be created initially empty, with a format identical to that been created initially empty, with a format identical to that used
used for "Pool 1 Codepoints". for "DSCP Pool 1 Codepoints".
IANA is requested to reference RFC2474, Section 4 of RFC3260, and the IANA has referenced RFC 2474, Section 4 of RFC 3260, and the current
current document for Pool 3. document for Pool 3.
The Registration Procedure for use of Pool 3 is Standards Action, as The registration procedure for use of Pool 3 is Standards Action, as
defined as Section 4.9 of [RFC8126]. IANA is expected to normally defined as Section 4.9 of [RFC8126]. IANA is expected to normally
make assignments from Pool 1, until this Pool is exhausted, but MAY make assignments from Pool 1, until this Pool is exhausted, but it
make assignments from Pool 3 where the format of the codepoint has MAY make assignments from Pool 3 when the format of the codepoint has
properties that are needed for a specific PHB. The required properties that are needed for a specific PHB. The required
characteristics for choosing a requested DSCP value MUST be explained characteristics for choosing a requested DSCP value MUST be explained
in the IANA considerations of the document that requests any in the IANA Considerations section of the document that requests any
assignment from Pool 3. assignment from Pool 3.
6. Acknowledgments 6. References
G. Fairhurst received funding from the European Union's Horizon 2020 6.1. Normative References
research and innovation program 2014-2018 under grant agreement No.
644334 (NEAT).
7. References [Registry]
7.1. Normative References IANA, "Differentiated Services Field Codepoints (DSCP)",
<https://www.iana.org/assignments/dscp-registry/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, <http://www.rfc-editor.org/info/ DOI 10.17487/RFC2119, March 1997,
rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI Field) in the IPv4 and IPv6 Headers", RFC 2474,
10.17487/RFC2474, December 1998, <http://www.rfc- DOI 10.17487/RFC2474, December 1998,
editor.org/info/rfc2474>. <https://www.rfc-editor.org/info/rfc2474>.
[RFC3260] Grossman, D., "New Terminology and Clarifications for [RFC3260] Grossman, D., "New Terminology and Clarifications for
Diffserv", RFC 3260, DOI 10.17487/RFC3260, April 2002, Diffserv", RFC 3260, DOI 10.17487/RFC3260, April 2002,
<http://www.rfc-editor.org/info/rfc3260>. <https://www.rfc-editor.org/info/rfc3260>.
[RFC8126] Cotton, M., Leiba, B. and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www RFC 8126, DOI 10.17487/RFC8126, June 2017,
.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[Registry] [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
IANA, "Differentiated Services Field Codepoints (DSCP), 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
https://www.iana.org/assignments/dscp-registry/dscp- May 2017, <https://www.rfc-editor.org/info/rfc8174>.
registry.xhtml", .
7.2. Informative References 6.2. Informative References
[I-D.ietf-tsvwg-le-phb] [LE-PHB] Bless, R., "A Lower Effort Per-Hop Behavior (LE PHB)",
Bless, R., "A Lower Effort Per-Hop Behavior (LE PHB)", Work in Progress, draft-ietf-tsvwg-le-phb-05, July 2018.
Internet-Draft draft-ietf-tsvwg-le-phb-02, June 2017.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<http://www.rfc-editor.org/info/rfc2475>. <https://www.rfc-editor.org/info/rfc2475>.
Appendix A. Revision Notes
Note to RFC-Editor: please remove this entire section prior to
publication.
Individual submission as draft -00.
o This is the initial version of the document.
o Advice in this rev. from Michelle Cotton on the IANA procedure.
o Thanks to Brian Carpenter for helpful inputs to this ID.
Individual submission as draft -01.
o Thanks to Roland Bless for review comments.
Individual submission as draft -02 (author requests adoption as a
TSVWG WG draft).
o Thanks to David Black for review comments in preparing rev -02.
Working Group submission as draft -00
o Adopted by the TSVWG working group.
Working Group submission as draft -01
o Fixed exploded acronyms.
Working Group submission as draft -02
o Corrections after WGLC.
Working Group submission as draft -03
o Corrections after TSVWG Shepherd Review.
Working Group submission as draft -04
o Added RFC 3260 as a necessary downref, with IANA asked to
reference this.
Working Group submission as draft -05
o Corrections following AD review.
o Expansion of explanation about why the proposed change will help
in assignment of a suitable DSCP for the LE PHB.
Working Group submission as draft -06
o GenART feedback to changed assignment method to assignment
policy,.
o Correction to the IANA reference documents.
Working Group submission as draft -07
o Revised after IESG feedback - Assignment Policy changed final para
text; Figure 2 reference changed; bleaching defined; definition of
standards action aligned with actual IANA policy.
Working Group submission as draft -08 Acknowledgments
o Revised after AD feedback - definition of standards action. 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 Author's Address
Godred Fairhurst Godred Fairhurst
University of Aberdeen University of Aberdeen
Department of Engineering Department of Engineering
Fraser Noble Building Fraser Noble Building
Aberdeen, AB24 3UE Aberdeen AB24 3UE
Scotland United Kingdom
Email: gorry@erg.abdn.ac.uk Email: gorry@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.uk/ URI: http://www.erg.abdn.ac.uk/
 End of changes. 64 change blocks. 
215 lines changed or deleted 146 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/