idnits 2.17.1 draft-brim-diffserv-phbid-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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == 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. -- The document date (April 1999) is 9141 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) == Missing Reference: 'RFC2119' is mentioned on line 83, but not defined == Unused Reference: 'RFC 2119' is defined on line 161, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2475 Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF S. Brim 2 Internet Draft B. Carpenter 3 April 1999 5 Per Hop Behavior Identification Codes 7 Copyright Notice 9 Placeholder for ISOC copyright. 11 Abstract 13 draft-brim-diffserv-phbid-00.txt 15 This document defines a 16 bit encoding mechanism for the identification 16 of differentiated services Per Hop Behaviors in protocol messages. 18 Status of this Memo 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet- Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Table of Contents: 41 Status of this Memo.............................................1 42 1. Introduction.................................................3 43 2. Encoding.....................................................3 44 3. IANA Considerations..........................................4 45 4. Security considerations......................................5 46 Acknowledgements................................................5 47 References......................................................5 48 Authors' Addresses..............................................5 49 Intellectual Property...........................................6 50 Full Copyright Statement........................................6 52 1. Introduction 54 Differentiated Services [RFC 2474, RFC 2475] introduces the notion of 55 Per Hop Behaviors (PHBs) that define how traffic belonging to a 56 particular behavior aggregate is treated at an individual network 57 node. In IP packet headers, PHBs are not indicated as such; instead 58 Differentiated Services Codepoint (DSCP) values are used. There are 59 only 64 possible DSCP values, but there is no such limit on the 60 number of PHBs. In a given network domain, there is a locally defined 61 mapping between DSCP values and PHBs. Standardized PHBs recommend a 62 DSCP mapping, but network operators may choose alternative mappings. 64 In some cases it is necessary or desirable to identify a particular 65 PHB in a protocol message, such as a message negotiating bandwidth 66 management or path selection. Examples where work is in progress 67 include communication between bandwidth brokers, and MPLS support of 68 diffserv. 70 In certain cases, what needs to be identified is not an individual 71 PHB, but a set of PHBs. One example is a set of PHBs that must follow 72 the same physical path to prevent re-ordering. An instance of this 73 is the set of three PHBs belonging to a single Assured Forwarding 74 class, such as the PHBs AF11, AF12 and AF13 [Assured]. 76 This document defines a binary encoding to uniquely identify PHBs 77 and/or sets of PHBs in protocol messages. This encoding MUST be used 78 when such identification is required. 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in [RFC2119]. 84 2. Encoding 86 PHBs and sets of PHBs are encoded in an unsigned 16 bit binary field, 87 using the same encoding. It is determined by context whether the 88 encoding represents a PHB or a set of PHBs. 90 The 16 bit field is arranged as follows: 92 Case 1: PHBs defined by standards action, as per [RFC 2474]. 94 The encoding for a single PHB is the recommended DSCP value for that 95 PHB, left-justified in the 16 bit field, with bits 6 through 15 set 96 to zero. Note that the recommended DSCP value MUST be used, even if 97 the network in question has chosen a different mapping. 99 The encoding for a set of PHBs is the numerically smallest of the set 100 of encodings for the various PHBs in the set. (Thus for the AF1x 101 PHBs, the encoding is that of the AF11 PHB.) 102 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 103 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 104 | DSCP | 0 0 0 0 0 0 0 0 0 0 | 105 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 107 Case 2: PHBs not defined by standards action, i.e. experimental or 108 local use PHBs as allowed by [RFC 2474]. In this case an arbitrary 12 109 bit PHB identification code, assigned by the IANA, is placed left- 110 justified in the 16 bit field, and bits 12 through 15 contain the 111 value 0x1. 113 A set of non-standard PHBs is identified by a single PHB 114 identification code. 116 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 117 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 118 | PHB id code | 0 0 0 1 | 119 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 121 Bits 12 through 14 are reserved either for expansion of the PHB 122 identification code, or for other use such as distinguishing PHB 123 groups from individual PHBs, at some point in the future. 125 3. IANA Considerations 127 IANA is requested to create a new assignment registry for "Per-Hop 128 Behavior Identification Codes", initially allowing values in the 129 range 0 to 4095 decimal. 131 Assignment of values in this field require: 133 -the identity of the assignee 134 -a brief description of the new PHB, with enough detail to 135 distinguish it from existing standardized and non-standardized 136 PHBs. In the case of a set of PHBs, this description should cover 137 all PHBs in the set. 138 -a reference to a stable document describing the PHB in detail. 140 During the first year of existence of this registry, IANA is 141 requested to refer all requests to the IETF diffserv WG for review. 142 Subsequently, requests should be reviewed by the IETF Transport Area 143 Directors or by an expert that they designate. 145 If the number of assignments begins to approach 4096, the Transport 146 Area Directors should be alerted. 148 4. Security considerations 150 This encoding in itself raises no security issues. However, users of 151 this encoding should consider that modifying a PHB identification 152 code may constitute theft or denial of service, so protocols using 153 this encoding must be adequately protected. 155 Acknowledgements 157 Useful comments were made by Francois Le Faucheur and others. 159 References 161 [RFC 2119] Key words for use in RFCs to Indicate Requirement Levels, 162 S. Bradner, RFC 2119, March 1997. 164 [RFC 2474] Definition of the Differentiated Services Field (DS Field) 165 in the IPv4 and IPv6 Headers. K. Nichols, S. Blake, F. Baker, D. 166 Black, RFC 2474, December 1998. 168 [RFC 2475] An Architecture for Differentiated Services. S. Blake, D. 169 Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, RFC 2475, December 170 1998. 172 [Assured] Assured Forwarding PHB Group, J. Heinanen, F. Baker, W. 173 Weiss, J. Wroclawski, draft-ietf-diffserv-af-06.txt, work in 174 progress. 176 Authors' Addresses 178 Scott W. Brim 179 146 Honness Lane 180 Ithaca, NY 14850 181 USA 183 E-mail: swb@newbridge.com 185 Brian E. Carpenter 186 IBM United Kingdom Laboratories 187 MP 185, Hursley Park 188 Winchester, Hampshire SO21 2JN, UK 190 E-mail: brian@hursley.ibm.com 192 Intellectual Property 194 PLACEHOLDER for full IETF IPR Statement if needed. 196 Full Copyright Statement 198 PLACEHOLDER for full ISOC copyright Statement if needed.