path: root/doc/rfc/rfc8436.txt

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.












Fairhurst                    Standards Track                    [Page 1]
^L
RFC 8436      IANA Registration Procedures for DSCP Pool 3   August 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
   (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].



Fairhurst                    Standards Track                    [Page 2]
^L
RFC 8436      IANA Registration Procedures for DSCP Pool 3   August 2018


                  +------+-----------------+
                  | 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.



Fairhurst                    Standards Track                    [Page 3]
^L
RFC 8436      IANA Registration Procedures for DSCP Pool 3   August 2018


   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







Fairhurst                    Standards Track                    [Page 4]
^L
RFC 8436      IANA Registration Procedures for DSCP Pool 3   August 2018


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.



Fairhurst                    Standards Track                    [Page 5]
^L
RFC 8436      IANA Registration Procedures for DSCP Pool 3   August 2018


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).




Fairhurst                    Standards Track                    [Page 6]
^L
RFC 8436      IANA Registration Procedures for DSCP Pool 3   August 2018


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/








































Fairhurst                    Standards Track                    [Page 7]
^L