idnits 2.17.1 draft-ietf-tsvwg-iana-dscp-registry-08.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC2474, but the abstract doesn't seem to directly say this. It does mention RFC2474 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2474, updated by this document, for RFC5378 checks: 1998-05-12) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 07, 2018) is 2147 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 -- Possible downref: Non-RFC (?) normative reference: ref. 'Registry' == Outdated reference: A later version (-10) exists of draft-ietf-tsvwg-le-phb-02 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). 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: 2474 (if approved) June 07, 2018 5 Intended status: Standards Track 6 Expires: December 07, 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-ietf-tsvwg-iana-dscp-registry-08 12 Abstract 14 The Differentiated Services (Diffserv) architecture specifies use of 15 a field in the IPv4 and IPv6 packet headers to carry Diffserv 16 Codepoint (DSCP) values. The Internet Assigned Numbers Authority 17 (IANA) maintains a registry of assigned DSCP values. 19 This update to RFC2474 changes the IANA assignment policy for Pool 3 20 of the registry (i.e., DSCP values of the form xxxx01) to Standards 21 Action, i.e., values are assigned through a Standards Track or Best 22 Current Practice RFC. The update also removes permission for 23 experimental and Local Use of the Codepoints that form Pool 3 of the 24 DSCP registry; Pool 2 Codepoints (i.e., DSCP values of the form 25 xxxx11) remain available 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 December 07, 2018. 44 Copyright Notice 46 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. The update to RFC2474 . . . . . . . . . . . . . . . . . . . . 4 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 65 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 68 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 69 Appendix A. Revision Notes . . . . . . . . . . . . . . . . . . . . 6 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 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 field, which is used to carry the Diffserv 79 Codepoint (DSCP). This DSCP value is used to select a Diffserv Per 80 hop Behaviour, PHB. 82 The six bit field is capable of conveying 64 distinct codepoints, and 83 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, which were 89 specified as "initially available for experimental or local use, but 90 which should be preferentially utilized for standardized assignments 91 if Pool 1 is ever exhausted" [RFC2474]. 93 +------+-----------------+ 94 | Pool | Codepoint Space | 95 +------+-----------------+ 96 | 1 | xxxxx0 | 97 +------+-----------------+ 98 | 2 | xxxx11 | 99 +------+-----------------+ 100 | 3 | xxxx01 | 101 +------+-----------------+ 103 Figure 1: Format of the field for codepoints allocated in the 104 three IANA pools (where 'x' refers to either '0' or '1'). 106 At the time of writing this document, 22 of the 32 Pool 1 codepoints 107 have currently been assigned. 109 Although Pool 1 has not yet been completely exhausted, there is a 110 need to assign codepoints for particular PHBs that are unable to use 111 any of the unassigned values in Pool 1. This document changes the 112 IANA registration policy of Pool 3 to assignment by Standards Action 113 (Section 4.9 of [RFC8126] defines this as "assigned only through 114 Standards Track or Best Current Practice RFCs in the IETF Stream"). 116 An example is the need to assign a suitable recommended default 117 codepoint for the Lower Effort (LE) per-hop behavior (PHB) [I-D.ietf- 118 tsvwg-le-phb]. The LE PHB is designed to protect best-effort (BE) 119 traffic (packets forwarded with the default PHB) from LE traffic in 120 congestion situations (i.e., when resources become scarce, best- 121 effort traffic has precedence over LE traffic and is allowed to 122 preempt it). In deployed networks, there is continued use of 123 bleaching (i.e. intentionally setting to zero) of the IP precedence 124 field. (Setting the IP Precedence field to zero disables any class- 125 based flow management by routers configured with TOS-based packet 126 processing). This causes the first three bits of the former TOS byte 127 (now the upper part of the DSCP field) to become zero. There is 128 therefore a need to avoid this remapping of the DSCP for the LE PHB 129 by assigning a codepoint that already has a zero value in the first 130 three bits [I-D.ietf-tsvwg-le-phb]. 132 Furthermore, if the LE PHB were to have been assigned one of the 133 currently unused Pool 1 codepoints with a zero value in the first 134 three bits, any bleaching of the IP precedence field would result in 135 other (higher assurance) traffic being also remapped to the assigned 136 DSCP. This remapping could then cause diffserv-marked traffic to 137 receive an unintentional LE treatment for the remainder of the 138 Internet path. It is therefore important to avoid the resulting 139 priority inversion. The absence of unassigned codepoints in Pool 1 140 that exhibit these important properties motivates assigning a Pool 3 141 codepoint as the default that is recommended for use with this PHB. 143 To allow the IETF to utilise Pool 3 codepoints, this document 144 requests IANA to to manage Pool 3 assignments for DSCP values in Pool 145 3 via the Standards Action policy [RFC8126]. 147 2. Terminology 149 This document assumes familiarity with the terminology used in 150 [RFC2475] updated by [RFC3260]. 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 154 "OPTIONAL" in this document are to be interpreted as described in 155 [RFC2119]. 157 3. The update to RFC2474 159 This document updates section 6 of [RFC2474], in the following ways. 161 It updates the following text concerning the assignment policy: 163 OLD: which are initially available for experimental or local use, but 164 which should be preferentially utilized for standardized 165 assignments if Pool 1 is ever exhausted. 167 NEW: which are utilized for standardized assignments (replacing the 168 previous availability for experimental or local use). 170 It removes the footnote in RFC2474 relating to Pool 3: 172 DELETE: "(*) may be utilized for future Standards Action allocations 173 as necessary" 175 The new registry assignment policy is shown in Figure 2. 177 Pool Codepoint space Assignment Policy 178 ---- --------------- ------------------ 180 1 xxxxx0 Standards Action 181 2 xxxx11 EXP/LU 182 3 xxxx01 Standards Action 184 Note for Pool 2: "Reserved for experimental or Local Use" 186 Figure 2: Updated Assignment Policy for the DSCP Registry 188 4. Security Considerations 190 Security considerations for the use of DSCP values are described in 191 the RFCs that define their usage. This document does not present new 192 security considerations. 194 5. IANA Considerations 196 This section requests IANA to change the use of Pool 3 in the DSCP 197 registry and to manage this pool using Standards Action, as defined 198 as Section 4.9 of [RFC8126]. 200 This requests IANA to make the following changes to the 201 Differentiated Services field Codepoints (DSCP) Registry, made 202 available at [Registry]. 204 IANA is requested to reference RFC2474 and Section 4 of RFC3260 for 205 the overall format of the DSCP registry. 207 IANA is requested to reference RFC2474 and Section 4 of RFC3260 for 208 Pool 1. 210 This update does not modify the IANA registry text for Pool 2. This 211 pool continues to preserve the note shown in Figure 2. 213 The previous registry text: 215 3 xxxx01 Experimental or Local Use May be utilized for future 216 Standards Action allocations as necessary. 218 is replaced with the following registry text: 220 3 xxxx01 Standards Action. 222 To manage codepoints in Pool 3, IANA is requested to create and 223 maintain a "Pool 3 Codepoints" subregistry. Pool 3 of the registry 224 is to be created initially empty, with a format identical to that 225 used for "Pool 1 Codepoints". 227 IANA is requested to reference RFC2474, Section 4 of RFC3260, and the 228 current document for Pool 3. 230 The Registration Procedure for use of Pool 3 is Standards Action, as 231 defined as Section 4.9 of [RFC8126]. IANA is expected to normally 232 make assignments from Pool 1, until this Pool is exhausted, but MAY 233 make assignments from Pool 3 where the format of the codepoint has 234 properties that are needed for a specific PHB. The required 235 characteristics for choosing a requested DSCP value MUST be explained 236 in the IANA considerations of the document that requests any 237 assignment from Pool 3. 239 6. Acknowledgments 241 G. Fairhurst received funding from the European Union's Horizon 2020 242 research and innovation program 2014-2018 under grant agreement No. 243 644334 (NEAT). 245 7. References 246 7.1. Normative References 248 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 249 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 250 RFC2119, March 1997, . 253 [RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, 254 "Definition of the Differentiated Services Field (DS 255 Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 256 10.17487/RFC2474, December 1998, . 259 [RFC3260] Grossman, D., "New Terminology and Clarifications for 260 Diffserv", RFC 3260, DOI 10.17487/RFC3260, April 2002, 261 . 263 [RFC8126] Cotton, M., Leiba, B. and T. Narten, "Guidelines for 264 Writing an IANA Considerations Section in RFCs", BCP 26, 265 RFC 8126, DOI 10.17487/RFC8126, June 2017, . 268 [Registry] 269 IANA, "Differentiated Services Field Codepoints (DSCP), 270 https://www.iana.org/assignments/dscp-registry/dscp- 271 registry.xhtml", . 273 7.2. Informative References 275 [I-D.ietf-tsvwg-le-phb] 276 Bless, R., "A Lower Effort Per-Hop Behavior (LE PHB)", 277 Internet-Draft draft-ietf-tsvwg-le-phb-02, June 2017. 279 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. 280 and W. Weiss, "An Architecture for Differentiated 281 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 282 . 284 Appendix A. Revision Notes 286 Note to RFC-Editor: please remove this entire section prior to 287 publication. 289 Individual submission as draft -00. 291 o This is the initial version of the document. 293 o Advice in this rev. from Michelle Cotton on the IANA procedure. 295 o Thanks to Brian Carpenter for helpful inputs to this ID. 297 Individual submission as draft -01. 299 o Thanks to Roland Bless for review comments. 301 Individual submission as draft -02 (author requests adoption as a 302 TSVWG WG draft). 304 o Thanks to David Black for review comments in preparing rev -02. 306 Working Group submission as draft -00 308 o Adopted by the TSVWG working group. 310 Working Group submission as draft -01 312 o Fixed exploded acronyms. 314 Working Group submission as draft -02 316 o Corrections after WGLC. 318 Working Group submission as draft -03 320 o Corrections after TSVWG Shepherd Review. 322 Working Group submission as draft -04 324 o Added RFC 3260 as a necessary downref, with IANA asked to 325 reference this. 327 Working Group submission as draft -05 329 o Corrections following AD review. 331 o Expansion of explanation about why the proposed change will help 332 in assignment of a suitable DSCP for the LE PHB. 334 Working Group submission as draft -06 336 o GenART feedback to changed assignment method to assignment 337 policy,. 339 o Correction to the IANA reference documents. 341 Working Group submission as draft -07 343 o Revised after IESG feedback - Assignment Policy changed final para 344 text; Figure 2 reference changed; bleaching defined; definition of 345 standards action aligned with actual IANA policy. 347 Working Group submission as draft -08 349 o Revised after AD feedback - definition of standards action. 351 Author's Address 352 Godred Fairhurst 353 University of Aberdeen 354 Department of Engineering 355 Fraser Noble Building 356 Aberdeen, AB24 3UE 357 Scotland 359 Email: gorry@erg.abdn.ac.uk 360 URI: http://www.erg.abdn.ac.uk/