idnits 2.17.1 draft-fairhurst-tsvwg-iana-dscp-registry-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 24, 2017) is 2315 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 3260 == Outdated reference: A later version (-10) exists of draft-ietf-tsvwg-le-phb-02 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Area Working Group G. Fairhurst 3 Internet-Draft University of Aberdeen 4 Updates: RFC2474 (if approved) December 24, 2017 5 Intended status: Standards Track 6 Expires: June 25, 2018 8 IANA Assignment of DSCP Pool 3 (xxxx01) Values to require Publication of 9 a Standards Track or Best Current Practice RFC 10 draft-fairhurst-tsvwg-iana-dscp-registry-02 12 Abstract 14 The Differentiated Services (Diffserv) architecture specifies use of 15 the DSField in the IPv4 and IPv6 packet header to carry the Diffserv 16 Codepoint (DSCP). The Internet Assigned Numbers Authority (IANA) 17 maintains a registry of assigned DSCP values. 19 This update to RFC2474 changes the IANA assignment method for Pool 3 20 of the registry (i.e., DSCPs of the form xxxx01) to Standards Action, 21 i.e., values are assigned through a Standards Track or Best Current 22 Practice RFC. The update also removes permission for experimental and 23 Local Use of the codepoints that form Pool 3 of the DSCP registry; 24 Pool 1 codepoints (i.e., DSCPs of the form xxxx11) remain available 25 for these purposes. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on June 25, 2018. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Simplified BSD License text 55 as described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. The update to RFC2474 . . . . . . . . . . . . . . . . . . . . 4 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 65 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5 68 7.2. Informative References . . . . . . . . . . . . . . . . . . 5 69 Appendix A. Revision Notes . . . . . . . . . . . . . . . . . . . . 6 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 1. Introduction 74 The Differentiated Services (Diffserv) [RFC2475] architecture 75 (updated by [RFC3260]) provides scalable service differentiation in 76 the Internet. Diffserv uses the six most significant bits of the 77 former IPv4 Type of Service (TOS) octet or the former IPV6 Traffic 78 Class octet to convey the DSField, which is used to carry the 79 Diffserv Codepoint (DSCP). This DSCP value is used to select a 80 Diffserv Per hop Behaviour, PHB. 82 The six bit DSField is capable of conveying 64 distinct codepoints, 83 and this codepoint space has been divided into three pools for the 84 purpose of codepoint assignment and management (as shown in figure 85 1). Pool 1 comprises 32 codepoints [RFC2474]. These are assigned by 86 Standards Action, as defined in [RFC8126]. Pool 2 comprises a pool 87 of 16 codepoints reserved for experimental or Local Use (EXP/LU) as 88 defined in [RFC2474], and Pool 3 comprises 16 codepoints [RFC2474], 89 which were initially "available for experimental or local use, but 90 which were indicated should be preferentially utilized for 91 standardized assignments if Pool 1 is ever exhausted." 92 +------+-----------------+ 93 | Pool | Codepoint Space | 94 +------+-----------------+ 95 | 1 | xxxxx0 | 96 +------+-----------------+ 97 | 2 | xxxx11 | 98 +------+-----------------+ 99 | 3 | xxxx01 | 100 +------+-----------------+ 102 Figure 1: Format of the DSField for Codepoints allocated in the 103 three IANA pools (where 'x' refers to either '0' or '1'). 105 At the time of writing this document, 23 of the 32 Pool 1 codepoints 106 have currently been assigned. 108 Although Pool 1 has not yet been completely exhausted, this document 109 changes the IANA registration policy of Pool 3 to assignment by 110 Standards Action, i.e., values are assigned by Standards Track or 111 Best Current Practice RFCs. The rationale for this update is a need 112 to assign codepoints for particular PHBs that are unable to use any 113 of the unassigned values in Pool 1. 115 An example is the need to assign a suitable recommended default 116 codepoint for the Lower Effort (LE) per-hop behavior (PHB) [I-D.ietf- 117 tsvwg-le-phb]. The LE PHB is designed to protect best-effort (BE) 118 traffic (packets forwarded with the default PHB) from LE traffic in 119 congestion situations, i.e., when resources become scarce, best- 120 effort traffic has precedence over LE traffic and may preempt it. 121 The continued presence of bleaching of the IP precedence field 122 (setting the top three bits of the former ToS byte to zero) in 123 deployed networks motivates the desire for the LE PHB to use a DSCP 124 with a zero value for the first three bits [I-D.ietf-tsvwg-le-phb]. 125 At the same time, it is also important to reduce the likelihood of 126 priority inversion caused by unintentional re-mapping of other 127 (higher assurance) traffic to the DSCP used for this PHB. The absence 128 of unassigned codepoints in Pool 1 that exhibit these important 129 properties motivates assigning a Pool 3 codepoint as the default that 130 is recommended for use with this PHB. 132 To allow the IETF to utilise Pool 3 codepoints, this document 133 requests IANA to manage Pool 3 and make assignments for DSCP 134 codepoints in Pool 3 when requested by Standards Action. This 135 assignment method requires publication of a Standards Track or Best 136 Current Practice RFC. 138 2. Terminology 140 This document assumes familiarity with the terminology used in 141 [RFC2475] updated by [RFC3260]. 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 145 "OPTIONAL" in this document are to be interpreted as described in 146 [RFC2119]. 148 3. The update to RFC2474 150 This document updates section 6 of [RFC2474], in the following ways. 152 It updates the following text concerning the assignment method: 154 OLD: which are initially available for experimental or local use, but 155 which should be preferentially utilized for standardized 156 assignments if Pool 1 is ever exhausted. 158 NEW: which are utilized for standardized assignments (replacing the 159 previous availability for experimental or local use)". 161 It removes the footnote in RFC2474 relating to Pool 3: 163 DELETE: "(*) may be utilized for future Standards Action allocations 164 as necessary" 166 The new registry contents are shown in Figure 2. 168 Pool Codepoint space Assignment Policy 169 ---- --------------- ----------------- 171 1 xxxxx0 Standards Action 172 2 xxxx11 EXP/LU 173 3 xxxx01 Standards Action 175 Figure 2: Updated Assignment Policy for the DSCP Registry 177 4. Security Considerations 179 Security considerations for the use of DSCPs are described in the 180 RFCs that define their usage. This document does not present new 181 security considerations. 183 5. IANA Considerations 185 This section requests IANA to change the use of Pool 3 in the DSCP 186 registry and to manage this Pool using a Standards Action assignment 187 method. 189 This requests IANA to make the following changes to the 190 Differentiated Services Field Codepoints (DSCP) Registry, made 191 available at [Registry]. 193 The previous registry text: 195 3 xxxx01 Experimental or Local Use May be utilized for future 196 Standards Action allocations as necessary. 198 is replaced with the following registry text: 200 3 xxxx01 Standards Action. 202 To manage codepoints in Pool 3, IANA is requested to create and 203 maintain a "Pool 3 Codepoints" entry. Pool 3 of the registry is to 204 be created initially empty, with a format identical to that used for 205 "Pool 1 Codepoints". 207 The Registration Procedure for use of Pool 3 is "Standards Action" 208 [RFC8126]. IANA is expected to normally make assignments from Pool 209 1, until this Pool is exhausted, but MAY make assignments from Pool 3 210 where the format of the codepoint has properties that are needed for 211 a specific PHB. The required characteristics for choosing the DSCP 212 value MUST be explained in the IANA considerations of the document 213 that requests any assignment from Pool 3 215 IANA is requested to reference RFC3260 and this current document. 217 6. Acknowledgments 219 G. Fairhurst received funding from the European Union's Horizon 2020 220 research and innovation program 2014-2018 under grant agreement No. 221 644334 (NEAT). 223 7. References 225 7.1. Normative References 227 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 228 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 229 RFC2119, March 1997, . 232 [RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, 233 "Definition of the Differentiated Services Field (DS 234 Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 235 10.17487/RFC2474, December 1998, . 238 [RFC3260] Grossman, D., "New Terminology and Clarifications for 239 Diffserv", RFC 3260, DOI 10.17487/RFC3260, April 2002, 240 . 242 7.2. Informative References 244 [I-D.ietf-tsvwg-le-phb] 245 Bless, R., "A Lower Effort Per-Hop Behavior (LE PHB)", 246 Internet-Draft draft-ietf-tsvwg-le-phb-02, June 2017. 248 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. 249 and W. Weiss, "An Architecture for Differentiated 250 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 251 . 253 [RFC8126] Cotton, M., Leiba, B. and T. Narten, "Guidelines for 254 Writing an IANA Considerations Section in RFCs", BCP 26, 255 RFC 8126, DOI 10.17487/RFC8126, June 2017, . 258 [Registry] 259 IANA, "Differentiated Services Field Codepoints (DSCP), 260 https://www.iana.org/assignments/dscp-registry/dscp- 261 registry.xhtml", . 263 Appendix A. Revision Notes 265 Note to RFC-Editor: please remove this entire section prior to 266 publication. 268 This document is an individual submission, seeking adoption by the 269 Transport and Services Working Group (TSVWG). 271 Individual submission as draft -00. 273 o This is the initial version of the document. 275 o Advice in this rev. from Michelle Cotton on the IANA procedure. 277 o Thanks to Brian Carpenter for helpful inputs to this ID. 279 Individual submission as draft -01. 281 o Thanks to Roland Bless for review comments. 283 Individual submission as draft -02 (author requests adoption as a 284 TSVWG WG draft). 286 o Thanks to David Black for review comments in preparing rev -02. 288 Author's Address 290 Godred Fairhurst 291 University of Aberdeen 292 Department of Engineering 293 Fraser Noble Building 294 Aberdeen, AB24 3UE 295 Scotland 297 Email: gorry@erg.abdn.ac.uk 298 URI: http://www.erg.abdn.ac.uk/