Transport Area Working Group G. Fairhurst
Internet-Draft University of Aberdeen
Updates: RFC2474 (if approved) February 03, 2018
Intended status: Standards Track
Expires: August 7, 2018

IANA Assignment of DSCP Pool 3 (xxxx01) Values to require Publication of a Standards Track or Best Current Practice RFC


The Differentiated Services (Diffserv) architecture specifies use of the field in the IPv4 and IPv6 packet header to carry the Diffserv Code point (DSCP). The Internet Assigned Numbers Authority (IONA) maintains a registry of assigned DSCP values.

This update to RFC2474 changes the IONA assignment method for Pool 3 of the registry (i.e., DEC's 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 code points that form Pool 3 of the DSCP registry; Pool 1 code points (i.e., DEC's of the form xxxx11) remain available for these purposes.

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 Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

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 August 7, 2018.

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 ( 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

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 (TAUS) octet or the former IPV6 Traffic Class octet to convey the field, which is used to carry the Diffserv Code point (DSCP). This DSCP value is used to select a Diffserv Per hop Behaviour, PB.

The six bit field is capable of conveying 64 distinct code points, and this Code point space has been divided into three pools for the purpose of Code point assignment and management (as shown in figure 1). Pool 1 comprises 32 code points [RFC2474]. These are assigned by Standards Action, as defined in [RFC8126]. Pool 2 comprises a pool of 16 code points reserved for experimental or Local Use (EXP/LU) as defined in [RFC2474], and Pool 3 comprises 16 code points [RFC2474], which were initially "available for experimental or local use, but which were indicated should be preferentially utilized for standardized assignments if Pool 1 is ever exhausted."

| Pool | Code point Space |
|  1   |     xxxxx0      |
|  2   |     xxxx11      |
|  3   |     xxxx01      |

Figure 1: Format of the field for code points allocated in the
three IONA pools (where 'x' refers to either '0' or '1').

At the time of writing this document, 23 of the 32 Pool 1 code points have currently been assigned.

Although Pool 1 has not yet been completely exhausted, this document changes the IONA registration policy of Pool 3 to assignment by Standards Action, i.e., values are assigned by Standards Track or Best Current Practice RCS. The rationale for this update is a need to assign code points 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 Code point for the Lower Effort (LE) per-hop behavior (PB) [I-D.ietf-tsvwg-le-phb]. The LE PB is designed to protect best-effort (BE) traffic (packets forwarded with the default PB) 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 top three bits of the former TAUS byte to zero) in deployed networks motivates the desire for the LE PB to use a DSCP with a zero value for the first three bits [I-D.ietf-tsvwg-le-phb]. 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 PB. The absence of unassigned code points in Pool 1 that exhibit these important properties motivates assigning a Pool 3 Code point as the default that is recommended for use with this PB.

To allow the IETF to utilise Pool 3 code points, this document requests IONA to manage Pool 3 and make assignments for DSCP code points in Pool 3 when requested by Standards Action. This assignment method requires publication of a Standards Track or Best Current Practice RFC.

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 [RFC2119].

3. The update to RFC2474

This document updates section 6 of [RFC2474], 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.

              Pool        Code point space          Assignment Policy
              ----        ---------------          -----------------
              1            xxxxx0                 Standards Action
              2            xxxx11                 EXP/LU
              3            xxxx01                 Standards Action
              Figure 2: Updated Assignment Policy for the DSCP Registry

4. Security Considerations

Security considerations for the use of DEC's are described in the RCS that define their usage. This document does not present new security considerations.

5. IANA Considerations

This section requests IONA to change the use of Pool 3 in the DSCP registry and to manage this Pool using a Standards Action assignment method.

This requests IONA to make the following changes to the Differentiated Services Field code points (DSCP) Registry, made available at [Registry].

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 code points in Pool 3, IONA is requested to create and maintain a "Pool 3 code points" entry. Pool 3 of the registry is to be created initially empty, with a format identical to that used for "Pool 1 code points".

The Registration Procedure for use of Pool 3 is "Standards Action" [RFC8126]. IONA 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 Code point has properties that are needed for a specific PB. The required characteristics for choosing the DSCP value MUST be explained in the IONA considerations of the document that requests any assignment from Pool 3

IONA is requested to reference RFC3260 and this current document.

6. Acknowledgments

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

7. References

7.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[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.
[RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, DOI 10.17487/RFC3260, April 2002.

7.2. Informative References

[I-D.ietf-tsvwg-le-phb] Bless, R., "A Lower Effort Per-Hop Behavior (LE PHB)", Internet-Draft draft-ietf-tsvwg-le-phb-02, June 2017.
[Registry] IONA, "Differentiated Services Field code points (DSCP),"
[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.
[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.

Appendix A. Revision Notes

Note to RFC-Editor: please remove this entire section prior to publication.

This document is an individual submission, seeking adoption by the Transport and Services Working Group (TSVWG).

Individual submission as draft -00.

Individual submission as draft -01.

Individual submission as draft -02 (author requests adoption as a TSVWG WG draft).

Working Group submission as draft -00

Author's Address

Godred Fairhurst University of Aberdeen Department of Engineering Fraser Noble Building Aberdeen, AB24 3UE Scotland EMail: URI: