idnits 2.17.1 draft-ietf-diffserv-2836bis-00.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 92, but not defined == Missing Reference: 'RFC 1812' is mentioned on line 174, but not defined == Unused Reference: 'RFC 2119' is defined on line 229, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2475 -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLS-DS' Summary: 7 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 January 2001 B. Carpenter 4 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-00.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 Acknowledgements................................................6 51 References......................................................6 52 Authors' Addresses..............................................6 53 Intellectual Property...........................................7 54 Full Copyright Statement........................................7 55 Acknowledgement.................................................8 57 1. Introduction 59 Differentiated Services [RFC 2474, RFC 2475] introduces the notion of 60 Per Hop Behaviors (PHBs) that define how traffic belonging to a 61 particular behavior aggregate is treated at an individual network 62 node. In IP packet headers, PHBs are not indicated as such; instead 63 Differentiated Services Codepoint (DSCP) values are used. There are 64 only 64 possible DSCP values, but there is no such limit on the 65 number of PHBs. In a given network domain, there is a locally defined 66 mapping between DSCP values and PHBs. Standardized PHBs recommend a 67 DSCP mapping, but network operators may choose alternative mappings. 69 In some cases it is necessary or desirable to identify a particular 70 PHB in a protocol message, such as a message negotiating bandwidth 71 management or path selection, especially when such messages pass 72 between management domains. Examples where work is in progress 73 include communication between bandwidth brokers, and MPLS support of 74 diffserv. 76 In certain cases, what needs to be identified is not an individual 77 PHB, but a set of PHBs. One example is a set of PHBs that must follow 78 the same physical path to prevent re-ordering. An instance of this 79 is the set of three PHBs belonging to a single Assured Forwarding 80 class, such as the PHBs AF11, AF12 and AF13 [RFC 2597]. 82 This document defines a binary encoding to uniquely identify PHBs 83 and/or sets of PHBs in protocol messages. This encoding MUST be used 84 when such identification is required. 86 This document replaces RFC 2836, which omitted considerations for the 87 Class Selector codepoints. 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119]. 93 1.1. Usage Scenarios 95 Diffserv services are expected to be supported over various 96 underlying technologies which we broadly refer to as "link layers" 97 for the purpose of this discussion. For the transport of IP packets, 98 some of these link layers make use of connections or logical 99 connections where the forwarding behavior supported by each link 100 layer device is a property of the connection. In particular, within 101 the link layer domain, each link layer node will schedule traffic 102 depending on which connection the traffic is transported in. Examples 103 of such "link layers" include ATM and MPLS. 105 For efficient support of diffserv over these link layers, one model 106 is for different Behavior Aggregates (BAs) (or sets of Behavior 107 Aggregates) to be transported over different connections so that they 108 are granted different (and appropriate) forwarding behaviors inside 109 the link layer cloud. When those connections are dynamically 110 established for the transport of diffserv traffic, it is very useful 111 to communicate at connection establishment time what forwarding 112 behavior(s) is(are) to be granted to each connection by the link 113 layer device so that the BAs transported experience consistent 114 forwarding behavior inside the link layer cloud. This can be achieved 115 by including in the connection establishment signaling messages the 116 encoding of the corresponding PHB, or set of PHBs, as defined in this 117 document. Details on proposed usage of PHB encodings by some MPLS 118 label distribution protocols (RSVP and LDP) for support of Diff-Serv 119 over MPLS, can be found in [MPLS-DS]. 121 In another approach, the ATM Forum has a requirement to indicate 122 desired IP QOS treatments in ATM signaling, so that ATM switches can 123 be just as supportive of the desired service as are IP forwarders. 124 To do so the Forum is defining a new VC call setup information 125 element is which will carry PHB identification codes (although will 126 be generalized to do more if needed). 128 2. Encoding 130 PHBs and sets of PHBs are encoded in an unsigned 16 bit binary field. 132 The 16 bit field is arranged as follows: 134 Case 1: PHBs defined by standards action, as per [RFC 2474]. 136 The encoding for a single PHB is the recommended DSCP value for that 137 PHB, left-justified in the 16 bit field, with bits 6 through 15 set 138 to zero. Note that the recommended DSCP value MUST be used, even if 139 the network in question has chosen a different mapping. 141 The encoding for a set of PHBs is the numerically smallest of the set 142 of encodings for the various PHBs in the set, with bit 14 set to 1. 143 (Thus for the AF1x PHBs, the encoding is that of the AF11 PHB, with 144 bit 14 set to 1.) 146 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 147 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 148 | DSCP | 0 0 0 0 0 0 0 0 X 0 | 149 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 151 Case 2: PHBs not defined by standards action, i.e. experimental or 152 local use PHBs as allowed by [RFC 2474]. In this case an arbitrary 12 153 bit PHB identification code, assigned by the IANA, is placed left- 154 justified in the 16 bit field. Bit 15 is set to 1, and bit 14 is zero 155 for a single PHB or 1 for a set of PHBs. Bits 12 and 13 are zero. 157 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 158 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 159 | PHB id code | 0 0 X 1 | 160 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 162 Bits 12 and 13 are reserved either for expansion of the PHB 163 identification code, or for other use, at some point in the future. 165 3. Signalling the Class Selector Codepoints 167 [RFC 2474] defines the eight DS codepoint values of the form 'xxx000' 168 (where x may be '0' or '1') as the Class Selector Codepoints. 169 Codepoint 000000 is the recommended DSCP value for the Default PHB, 170 and hence the Case 1 PHBID constructed from that codepoint is used to 171 signal the Default PHB (see Section 2 above). 173 For convenience and consistent operation with networks that employ IP 174 Precedence [RFC 1812], the Case 1 format PHBIDs constructed from the 175 other seven Class Selector Codepoints may also be used to signal 176 PHBs. In each case, the PHB signaled by such a PHBID is the PHB to 177 which the embedded class selector codepoint (or IP Precedence value 178 that corresponds to it in non-diffserv domains) is mapped in the 179 recipient's network. Note that different networks will employ 180 different mappings; see Section 4 of [RFC 2474] for further 181 discussion. 183 Any specified use of PHBIDs SHOULD allow the use of the eight Case 1 184 PHBIDs constructed from the Class Selector Codepoints. 186 4. IANA Considerations 188 IANA is requested to create a new assignment registry for "Per-Hop 189 Behavior Identification Codes", initially allowing values in the 190 range 0 to 4095 decimal. 192 Assignment of values in this field require: 194 -the identity of the assignee 195 -a brief description of the new PHB, with enough detail to 196 distinguish it from existing standardized and non-standardized 197 PHBs. In the case of a set of PHBs, this description should cover 198 all PHBs in the set. 199 -a reference to a stable document describing the PHB in detail. 201 During the first year of existence of this registry, IANA is 202 requested to refer all requests to the IETF diffserv WG for review. 203 Subsequently, requests should be reviewed by the IETF Transport Area 204 Directors or by an expert that they designate. 206 If the number of assignments begins to approach 4096, the Transport 207 Area Directors should be alerted. 209 5. Security considerations 211 This encoding in itself raises no security issues. However, users of 212 this encoding should consider that modifying a PHB identification 213 code may constitute theft or denial of service, so protocols using 214 this encoding must be adequately protected. 216 Just signalling a PHBID SHOULD NOT be sufficient to grant the sender 217 access to a PHB that it would otherwise not be able to use. In cases 218 where this is an issue, receivers SHOULD treat received PHBIDs as 219 requests for service, and use local policy to determine whether to 220 grant or deny such requests. 222 Acknowledgements 224 Useful comments were made by members of the IETF Diffserv working 225 group. 227 References 229 [RFC 2119] Key words for use in RFCs to Indicate Requirement Levels, 230 S. Bradner, RFC 2119, March 1997. 232 [RFC 2474] Definition of the Differentiated Services Field (DS Field) 233 in the IPv4 and IPv6 Headers. K. Nichols, S. Blake, F. Baker, D. 234 Black, RFC 2474, December 1998. 236 [RFC 2475] An Architecture for Differentiated Services. S. Blake, D. 237 Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, RFC 2475, December 238 1998. 240 [RFC 2597] Assured Forwarding PHB Group, J. Heinanen, F. Baker, W. 241 Weiss, J. Wroclawski, RFC 2597, June 1999. 243 [MPLS-DS] , work in progress 245 Authors' Addresses 247 David L. Black 248 EMC Corporation 249 42 South St. 250 Hopkinton, MA 01748 252 E-mail: black_david@emc.com 254 Scott W. Brim 255 146 Honness Lane 256 Ithaca, NY 14850 257 USA 258 E-mail: sbrim@cisco.com 260 Brian E. Carpenter 261 IBM 262 c/o iCAIR 263 Suite 150 264 1890 Maple Avenue 265 Evanston, IL 60201 266 USA 268 E-mail: brian@icair.org 270 Francois Le Faucheur 271 Cisco Systems 272 Petra B - Les Lucioles 273 291, rue Albert Caquot 274 06560 Valbonne 275 France 277 E-mail: flefauch@cisco.com 279 Intellectual Property 281 The IETF takes no position regarding the validity or scope of any 282 intellectual property or other rights that might be claimed to 283 pertain to the implementation or use of the technology described in 284 this document or the extent to which any license under such rights 285 might or might not be available; neither does it represent that it 286 has made any effort to identify any such rights. Information on the 287 IETF's procedures with respect to rights in standards-track and 288 standards-related documentation can be found in BCP-11. Copies of 289 claims of rights made available for publication and any assurances of 290 licenses to be made available, or the result of an attempt made to 291 obtain a general license or permission for the use of such 292 proprietary rights by implementors or users of this specification can 293 be obtained from the IETF Secretariat. 295 The IETF invites any interested party to bring to its attention any 296 copyrights, patents or patent applications, or other proprietary 297 rights which may cover technology that may be required to practice 298 this standard. Please address the information to the IETF Executive 299 Director. 301 Full Copyright Statement 303 Copyright (C) The Internet Society (2001). All Rights Reserved. 305 This document and translations of it may be copied and furnished to 306 others, and derivative works that comment on or otherwise explain it 307 or assist in its implementation may be prepared, copied, published 308 and distributed, in whole or in part, without restriction of any 309 kind, provided that the above copyright notice and this paragraph are 310 included on all such copies and derivative works. However, this 311 document itself may not be modified in any way, such as by removing 312 the copyright notice or references to the Internet Society or other 313 Internet organizations, except as needed for the purpose of 314 developing Internet standards in which case the procedures for 315 copyrights defined in the Internet Standards process must be 316 followed, or as required to translate it into languages other than 317 English. 319 The limited permissions granted above are perpetual and will not be 320 revoked by the Internet Society or its successors or assigns. 322 This document and the information contained herein is provided on an 323 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 324 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 325 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 326 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 327 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 329 Acknowledgement 331 Funding for the RFC Editor function is currently provided by the 332 Internet Society.