Re-assignment of Pool 3 of the DSCP Registry to assignment by IETF Standards Action
draft-fairhurst-tsvwg-iana-dscp-registry-01

Transport Area Working Group                                G. Fairhurst
Internet-Draft                                    University of Aberdeen
Updates: RFC2474 (if approved)                         December 22, 2017
Intended status: Standards Track
Expires: June 23, 2018

   Re-assignment of Pool 3 of the DSCP Registry to assignment by IETF
                            Standards Action
              draft-fairhurst-tsvwg-iana-dscp-registry-01

Abstract

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

   This update to RFC2474 requests a change to the IANA assignment
   method for Pool 3 of the registry to change this to Standards Action
   assignment.  The update also removes permission for Local Use of the
   codepoints that form Pool 3 of the DSCP registry.

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 http://datatracker.ietf.org/drafts/current/.

   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 June 23, 2018.

Copyright Notice

   Copyright (c) 2017 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 (http://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

Fairhurst                Expires June 23, 2018                  [Page 1]
Internet-Draft                                             December 2017

   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  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  The update to RFC2474  . . . . . . . . . . . . . . . . . . . .  3
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  4
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  4
   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  5
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     7.1.  Normative References . . . . . . . . . . . . . . . . . . .  5
     7.2.  Informative References . . . . . . . . . . . . . . . . . .  5
   Appendix A. Revision Notes . . . . . . . . . . . . . . . . . . . .  5
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . .  6

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 DSField, 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 DSField 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], and Pool 3 comprises 16 codepoints [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 | Codepoint Space |
   +------+-----------------+
   |  1   |     xxxxx0      |
   +------+-----------------+
   |  2   |     xxxx11      |
   +------+-----------------+
   |  3   |     xxxx01      |
   +------+-----------------+
   
   Figure 1: Format of the DSField for Codepoints allocated in the
   three IANA pools (where 'x' refers to either '0' or '1').
   

Fairhurst                Expires June 23, 2018                  [Page 2]
Internet-Draft                                             December 2017

   At the time of writing this document, 23 of the 32 Pool 1 codepoints
   have currently been assigned.  Although Pool 1 has not yet been
   completely exhausted, this document requests IANA to change the use
   of Pool 3 to allow assignment to this pool.  The rationale for this
   request 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 codepoint for the Lower
   Effort (LE) per-hop behavior (PHB) [I-D.ietf-tsvwg-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, i.e., when resources become scarce, best-effort traffic
   has precedence over LE traffic and may preempt it.  The contunued
   presence of bleaching of the IP precedence field (the top three bits
   of the former ToS byte) by deployed networks motivates the desire for
   the LE PHB 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 probability of accidental re-mapping of other (higher
   assurance) traffic to the DSCP used for this PHB. Since there are no
   unassigned codepoints in Pool 1 that exhibit the required properties,
   this motivates the desire to allow the IETF to use a codepoint in
   Pool 3.

   To allow the IETF to utilise Pool 3 codepoints, this document
   requests IANA to manage Pool 3 and make assignments for DSCP
   codepoints in Pool 3 when requested by Standards Action.  This
   assignment method requires publication of a Standards Track RFC
   approved by the IESG.

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:

   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 RFC2474 relating to Pool 3:

Fairhurst                Expires June 23, 2018                  [Page 3]
Internet-Draft                                             December 2017

   DELETE: "(*) may be utilized for future Standards Action allocations
      as necessary"

   The new registry format is shown in Figure 2.

                 Pool        Codepoint 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 DSCPs are described in the
   RFCs that define their usage.  This document does not present new
   security considerations.

5.  IANA 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 [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 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"
   [RFC8126].  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 need to be explained in
   the IANA considerations requesting this assignment.

   IANA is requested to reference RFC3260 and this current document.

Fairhurst                Expires June 23, 2018                  [Page 4]
Internet-Draft                                             December 2017

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, <http://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, <http://www.rfc-
              editor.org/info/rfc2474>.

   [RFC3260]  Grossman, D., "New Terminology and Clarifications for
              Diffserv", RFC 3260, DOI 10.17487/RFC3260, April 2002,
              <http://www.rfc-editor.org/info/rfc3260>.

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.

   [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,
              <http://www.rfc-editor.org/info/rfc2475>.

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

   [Registry]
              IANA, "Differentiated Services Field Codepoints (DSCP),
              https://www.iana.org/assignments/dscp-registry/dscp-
              registry.xhtml", .

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

Fairhurst                Expires June 23, 2018                  [Page 5]
Internet-Draft                                             December 2017

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

Author's Address

   Godred Fairhurst
   University of Aberdeen
   Department of Engineering
   Fraser Noble Building
   Aberdeen, AB24 3UE
   Scotland
   
   Email: gorry@erg.abdn.ac.uk
   URI:   http://www.erg.abdn.ac.uk/

Fairhurst                Expires June 23, 2018                  [Page 6]