idnits 2.17.1 draft-ietf-diffserv-2836bis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 1) being 64 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. -- The abstract seems to indicate that this document obsoletes RFC2836, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2119' is mentioned on line 93, but not defined == Missing Reference: 'RFC 1812' is mentioned on line 175, but not defined == Unused Reference: 'RFC 2119' is defined on line 236, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2475 ** Obsolete normative reference: RFC 2836 (Obsoleted by RFC 3140) -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLS-DS' Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF D. Black 2 Internet Draft S. Brim 3 February 2001 B. Carpenter 4 Replaces RFC 2836 F. Le Faucheur 6 Per Hop Behavior Identification Codes 8 Copyright Notice 10 Copyright (C) The Internet Society (2001). All Rights Reserved. 12 Abstract 14 draft-ietf-diffserv-2836bis-01.txt 16 This document defines a 16 bit encoding mechanism for the identification 17 of differentiated services Per Hop Behaviors in protocol messages. 18 It replaces RFC 2836. 20 Status of this Memo 22 This document is an Internet-Draft and is in full conformance with 23 all provisions of Section 10 of RFC2026. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet- Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 Table of Contents: 43 Status of this Memo.............................................1 44 1. Introduction.................................................3 45 1.1. Usage Scenarios............................................3 46 2. Encoding.....................................................4 47 3. Signalling the Class Selector Codepoints.....................5 48 4. IANA Considerations..........................................5 49 5. Security Considerations......................................6 50 Changes from RFC 2836...........................................6 51 Acknowledgements................................................6 52 References......................................................6 53 Authors' Addresses..............................................7 54 Intellectual Property...........................................7 55 Full Copyright Statement........................................8 56 Acknowledgement.................................................8 58 1. Introduction 60 Differentiated Services [RFC 2474, RFC 2475] introduces the notion of 61 Per Hop Behaviors (PHBs) that define how traffic belonging to a 62 particular behavior aggregate is treated at an individual network 63 node. In IP packet headers, PHBs are not indicated as such; instead 64 Differentiated Services Codepoint (DSCP) values are used. There are 65 only 64 possible DSCP values, but there is no such limit on the 66 number of PHBs. In a given network domain, there is a locally defined 67 mapping between DSCP values and PHBs. Standardized PHBs recommend a 68 DSCP mapping, but network operators may choose alternative mappings. 70 In some cases it is necessary or desirable to identify a particular 71 PHB in a protocol message, such as a message negotiating bandwidth 72 management or path selection, especially when such messages pass 73 between management domains. Examples where work is in progress 74 include communication between bandwidth brokers, and MPLS support of 75 diffserv. 77 In certain cases, what needs to be identified is not an individual 78 PHB, but a set of PHBs. One example is a set of PHBs that must follow 79 the same physical path to prevent re-ordering. An instance of this 80 is the set of three PHBs belonging to a single Assured Forwarding 81 class, such as the PHBs AF11, AF12 and AF13 [RFC 2597]. 83 This document defines a binary encoding to uniquely identify PHBs 84 and/or sets of PHBs in protocol messages. This encoding MUST be used 85 when such identification is required. 87 This document replaces RFC 2836, which omitted considerations for the 88 Class Selector codepoints. 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [RFC2119]. 94 1.1. Usage Scenarios 96 Diffserv services are expected to be supported over various 97 underlying technologies which we broadly refer to as "link layers" 98 for the purpose of this discussion. For the transport of IP packets, 99 some of these link layers make use of connections or logical 100 connections where the forwarding behavior supported by each link 101 layer device is a property of the connection. In particular, within 102 the link layer domain, each link layer node will schedule traffic 103 depending on which connection the traffic is transported in. Examples 104 of such "link layers" include ATM and MPLS. 106 For efficient support of diffserv over these link layers, one model 107 is for different Behavior Aggregates (BAs) (or sets of Behavior 108 Aggregates) to be transported over different connections so that they 109 are granted different (and appropriate) forwarding behaviors inside 110 the link layer cloud. When those connections are dynamically 111 established for the transport of diffserv traffic, it is very useful 112 to communicate at connection establishment time what forwarding 113 behavior(s) is(are) to be granted to each connection by the link 114 layer device so that the BAs transported experience consistent 115 forwarding behavior inside the link layer cloud. This can be achieved 116 by including in the connection establishment signaling messages the 117 encoding of the corresponding PHB, or set of PHBs, as defined in this 118 document. Details on proposed usage of PHB encodings by some MPLS 119 label distribution protocols (RSVP and LDP) for support of Diff-Serv 120 over MPLS, can be found in [MPLS-DS]. 122 In another approach, the ATM Forum has a requirement to indicate 123 desired IP QOS treatments in ATM signaling, so that ATM switches can 124 be just as supportive of the desired service as are IP forwarders. 125 To do so the Forum is defining a new VC call setup information 126 element is which will carry PHB identification codes (although will 127 be generalized to do more if needed). 129 2. Encoding 131 PHBs and sets of PHBs are encoded in an unsigned 16 bit binary field. 133 The 16 bit field is arranged as follows: 135 Case 1: PHBs defined by standards action, as per [RFC 2474]. 137 The encoding for a single PHB is the recommended DSCP value for that 138 PHB, left-justified in the 16 bit field, with bits 6 through 15 set 139 to zero. Note that the recommended DSCP value MUST be used, even if 140 the network in question has chosen a different mapping. 142 The encoding for a set of PHBs is the numerically smallest of the set 143 of encodings for the various PHBs in the set, with bit 14 set to 1. 144 (Thus for the AF1x PHBs, the encoding is that of the AF11 PHB, with 145 bit 14 set to 1.) 147 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 148 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 149 | DSCP | 0 0 0 0 0 0 0 0 X 0 | 150 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 152 Case 2: PHBs not defined by standards action, i.e. experimental or 153 local use PHBs as allowed by [RFC 2474]. In this case an arbitrary 12 154 bit PHB identification code, assigned by the IANA, is placed left- 155 justified in the 16 bit field. Bit 15 is set to 1, and bit 14 is zero 156 for a single PHB or 1 for a set of PHBs. Bits 12 and 13 are zero. 158 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 159 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 160 | PHB id code | 0 0 X 1 | 161 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 163 Bits 12 and 13 are reserved either for expansion of the PHB 164 identification code, or for other use, at some point in the future. 166 3. Signalling the Class Selector Codepoints 168 [RFC 2474] defines the eight DS codepoint values of the form 'xxx000' 169 (where x may be '0' or '1') as the Class Selector Codepoints. 170 Codepoint 000000 is the recommended DSCP value for the Default PHB, 171 and hence the Case 1 PHBID constructed from that codepoint is used to 172 signal the Default PHB (see Section 2 above). 174 For convenience and consistent operation with networks that employ IP 175 Precedence [RFC 1812], the Case 1 format PHBIDs constructed from the 176 other seven Class Selector Codepoints may also be used to signal 177 PHBs. In each case, the PHB signaled by such a PHBID is the PHB to 178 which the embedded class selector codepoint (or IP Precedence value 179 that corresponds to it in non-diffserv domains) is mapped in the 180 recipient's network. Note that different networks will employ 181 different mappings; see Section 4 of [RFC 2474] for further 182 discussion. 184 Any specified use of PHBIDs SHOULD allow the use of the eight Case 1 185 PHBIDs constructed from the Class Selector Codepoints. 187 4. IANA Considerations 189 IANA is requested to create a new assignment registry for "Per-Hop 190 Behavior Identification Codes", initially allowing values in the 191 range 0 to 4095 decimal. 193 Assignment of values in this field require: 195 -the identity of the assignee 196 -a brief description of the new PHB, with enough detail to 197 distinguish it from existing standardized and non-standardized 198 PHBs. In the case of a set of PHBs, this description should cover 199 all PHBs in the set. 200 -a reference to a stable document describing the PHB in detail. 202 During the first year of existence of this registry, IANA is 203 requested to refer all requests to the IETF diffserv WG for review. 204 Subsequently, requests should be reviewed by the IETF Transport Area 205 Directors or by an expert that they designate. 207 If the number of assignments begins to approach 4096, the Transport 208 Area Directors should be alerted. 210 5. Security Considerations 212 This encoding in itself raises no security issues. However, users of 213 this encoding should consider that modifying a PHB identification 214 code may constitute theft or denial of service, so protocols using 215 this encoding must be adequately protected. 217 Just signalling a PHBID SHOULD NOT be sufficient to grant the sender 218 access to a PHB that it would otherwise not be able to use. In cases 219 where this is an issue, receivers SHOULD treat received PHBIDs as 220 requests for service, and use local policy to determine whether to 221 grant or deny such requests. 223 Changes from RFC 2836 225 [RFC 2836] did not consider the Class Selector code points, which are 226 covered by section 3 of the present document. The second paragraph of 227 section 5 has been added. 229 Acknowledgements 231 Useful comments were made by members of the IETF Diffserv working 232 group. 234 References 236 [RFC 2119] Key words for use in RFCs to Indicate Requirement Levels, 237 S. Bradner, RFC 2119, March 1997. 239 [RFC 2474] Definition of the Differentiated Services Field (DS Field) 240 in the IPv4 and IPv6 Headers. K. Nichols, S. Blake, F. Baker, D. 241 Black, RFC 2474, December 1998. 243 [RFC 2475] An Architecture for Differentiated Services. S. Blake, D. 244 Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, RFC 2475, December 245 1998. 247 [RFC 2597] Assured Forwarding PHB Group, J. Heinanen, F. Baker, W. 248 Weiss, J. Wroclawski, RFC 2597, June 1999. 250 [RFC 2836] Per Hop Behavior Identification Codes. S. Brim, B. 251 Carpenter, F. Le Faucheur, RFC 2836, May 2000. 253 [MPLS-DS] MPLS Support of Differentiated Services, , work in progress 256 Authors' Addresses 258 David L. Black 259 EMC Corporation 260 42 South St. 261 Hopkinton, MA 01748 263 E-mail: black_david@emc.com 265 Scott W. Brim 266 146 Honness Lane 267 Ithaca, NY 14850 268 USA 270 E-mail: sbrim@cisco.com 272 Brian E. Carpenter 273 IBM 274 c/o iCAIR 275 Suite 150 276 1890 Maple Avenue 277 Evanston, IL 60201 278 USA 280 E-mail: brian@icair.org 282 Francois Le Faucheur 283 Cisco Systems 284 Petra B - Les Lucioles 285 291, rue Albert Caquot 286 06560 Valbonne 287 France 289 E-mail: flefauch@cisco.com 291 Intellectual Property 293 The IETF takes no position regarding the validity or scope of any 294 intellectual property or other rights that might be claimed to 295 pertain to the implementation or use of the technology described in 296 this document or the extent to which any license under such rights 297 might or might not be available; neither does it represent that it 298 has made any effort to identify any such rights. Information on the 299 IETF's procedures with respect to rights in standards-track and 300 standards-related documentation can be found in BCP-11. Copies of 301 claims of rights made available for publication and any assurances of 302 licenses to be made available, or the result of an attempt made to 303 obtain a general license or permission for the use of such 304 proprietary rights by implementors or users of this specification can 305 be obtained from the IETF Secretariat. 307 The IETF invites any interested party to bring to its attention any 308 copyrights, patents or patent applications, or other proprietary 309 rights which may cover technology that may be required to practice 310 this standard. Please address the information to the IETF Executive 311 Director. 313 Full Copyright Statement 315 Copyright (C) The Internet Society (2001). All Rights Reserved. 317 This document and translations of it may be copied and furnished to 318 others, and derivative works that comment on or otherwise explain it 319 or assist in its implementation may be prepared, copied, published 320 and distributed, in whole or in part, without restriction of any 321 kind, provided that the above copyright notice and this paragraph are 322 included on all such copies and derivative works. However, this 323 document itself may not be modified in any way, such as by removing 324 the copyright notice or references to the Internet Society or other 325 Internet organizations, except as needed for the purpose of 326 developing Internet standards in which case the procedures for 327 copyrights defined in the Internet Standards process must be 328 followed, or as required to translate it into languages other than 329 English. 331 The limited permissions granted above are perpetual and will not be 332 revoked by the Internet Society or its successors or assigns. 334 This document and the information contained herein is provided on an 335 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 336 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 337 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 338 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 339 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 341 Acknowledgement 343 Funding for the RFC Editor function is currently provided by the 344 Internet Society.