idnits 2.17.1 draft-ietf-diffserv-new-terms-02.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** 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? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 167: '... which each DS Node MUST use to select...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 63 has weird spacing: '...t least in pa...' == Line 71 has weird spacing: '...r other busin...' == Line 72 has weird spacing: '...re also could...' == Line 90 has weird spacing: '...ain) or it ca...' == Line 123 has weird spacing: '... exists for h...' == (1 more instance...) -- 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.) -- 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) == Unused Reference: '1' is defined on line 220, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2475 (ref. '2') ** Obsolete normative reference: RFC 2481 (ref. '4') (Obsoleted by RFC 3168) == Outdated reference: A later version (-04) exists of draft-bradner-iana-allocation-02 Summary: 8 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Diffserv Working Group Dan Grossman 2 Internet Draft Motorola, Inc. 3 Expires: May 2000 5 draft-ietf-diffserv-new-terms-02.txt 6 November, 1999 8 New Terminology for Diffserv 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of section 10 of RFC2026. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as ``work in progress.'' 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 To learn the current status of any Internet-Draft, please check the 30 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 31 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 32 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 33 ftp.isi.edu (US West Coast). 35 Abstract 37 This memo captures Diffserv working group agreements concerning new 38 and improved terminology. It is intended as a living document for 39 use by the Diffserv working group, and especially for use of authors 40 of Diffserv drafts. It is expected that the terminology in this memo 41 will be incorporated into the existing Diffserv RFCs when they are 42 updated. 44 Copyright Notice 46 Copyright (C) The Internet Society (1999). All Rights Reserved. 48 1. Introduction 50 As the Diffserv work has evolved, there have been several cases where 51 terminology has needed to be created or the definitions in Diffserv 52 standards track RFCs have needed to be refined. This memo was 53 created to capture and test group agreements on terminology, rather 54 than attempting to revise the base RFCs and recycle them at proposed 55 standard. Diffserv authors are encouraged to use the new terminology 56 whereever appropriate. 58 2. Terminology related to Service Level Agreements (SLAs) 60 The Diffserv Architecture [2] uses the term "Service Level Agreement" 61 (SLA) to describe the "service contract... that specifies the 62 forwarding service a customer should receive". The SLA may include 63 traffic conditioning rules which (at least in part) constitute a 64 Traffic Conditioning Agreement (TCA). A TCA is "an agreement 65 specifying classifier rules and any corresponding traffic profiles 66 and metering, marking, discarding and/or shaping rules which are to 67 apply...." 69 As work progressed in Diffserv, it came to be believed that the 70 notion of an "agreement" implied considerations that were of a 71 pricing, contractual or other business nature, as well as those that 72 were strictly technical. There also could be other technical 73 considerations in such an agreement (e.g., service availability) 74 which are not addressed by Diffserv. It was therefore agreed that 75 the notions of SLAs and TCAs would be taken to represent the broader 76 context, and that new terminology would be used to describe those 77 elements of service and traffic conditioning that are addressed by 78 Diffserv. 80 - A Service Level Specfication (SLS) is a set of parameters and 81 their values which together define the service offered to a traffic 82 stream by a DS domain. 84 - A Traffic Conditioning Specification (TCS) is a set of parameters 85 and their values which together specify a set of classfier rules 86 and a traffic profile. A TCS is an integral element of an SLS. 88 Note that the definition of "Traffic stream" is unchanged from RFC 89 2475. A traffic stream can be an individual microflow or a group of 90 microflows (i.e., in a source or destination DS domain) or it can 91 be a BA. Thus, an SLS may apply in the source or destination DS 92 domain to a single microflow or group of microflows, as well as to a 93 BA in any DS domain. 95 3. Usage of PHB Group 97 RFC 2475 defines a PHB group to be: 99 "a set of one or more PHBs that can only be meaningfully specified 100 and implemented simultaneously, due to a common constraint applying 101 to all PHBs in the set such as a queue servicing or queue 102 management policy. A PHB group provides a service building block 103 that allows a set of related forwarding behaviors to be specified 104 together (e.g., four dropping priorities). A single PHB is a 105 special case of a PHB group." 107 One standards track PHB Group is defined in RFC 2497 [3], "Assured 108 Forwarding PHB Group". Assured Forwarding (AF) is a type of forwarding 109 behavior with some assigned level of queuing resources and three drop 110 precedences. An AF PHB Group consists of three PHBs, and uses three 111 DSCPs. 113 RFC 2497 defines twelve DSCPs, corresponding to four independent AF 114 classes. The AF classes are referred to as AF1x, AF2x, AF3x, and AF4x 115 (where 'x' is 1, 2, or 3 to represent drop precedence). Each AF class 116 is one instance of an AF PHB Group. 118 There has been confusion expressed that RFC 2497 refers to all four AF 119 classes with their three drop precedences as being part of a single PHB 120 Group. However, since each AF class operates entirely independently of 121 the others, (and thus there is no common constraint among AF classes as 122 there is among drop precedences within an AF class) this usage is 123 inconsistent with RFC 2475. The inconsistency exists for historical 124 reasons and will be removed in future revisions of the AF specification. 125 It should now be understood that AF is a _type_ of PHB group, and each 126 AF class is an _instance_ of the AF type. 128 Authors of new PHB specifications should be careful to adhere to the RFC 129 2475 definition of PHB Group. RFC 2475 does not prohibit new PHB 130 specifications from assigning enough DSCPs to represent multiple 131 independent instances of their PHB Group. However, such a set of DSCPs 132 must not be referred to as a single PHB Group. 134 4. Definition of the DS Field 136 Diffserv uses six bits of the IPV4 or IPV6 header to convey the Diffserv 137 Codepoint (DSCP), which selects a PHB. RFC 2474 attempts to rename the 138 TOS octet of the IPV4 header, and Traffic Class octet of the IPV6 139 header, respectively, to the DS field. The DS Field has a six bit 140 Diffserv Codepoint and two "currently unused bits". 142 It has been pointed out that this leads to inconsistencies and 143 ambiguities. In particular, the CU bits of the DS Field have not been 144 assigned to Diffserv, and have been assigned an experimental use for an 145 explicit congestion notification scheme [4]. In the current text, a 146 DSCP is, depending on context, either an encoding which selects a PHB or 147 a sub-field in the DS field which contains that encoding. 149 The present text is also inconsistent with the IANA allocation 150 guidelines draft [5]. In that draft, the IPV4 TOS field and the IPV6 151 traffic class field are superceded by the 6 bit DS field and a 2 bit CU 152 field. The IANA allocates values in the DS field following the IANA 153 considerations section in RFC 2474. Experimental uses of the CU field 154 are assigned after IESG approval processes. Permanent values in the CU 155 field are allocated following a Standards Action process. 157 The consensus of the DiffServ working group is that [5] correctly 158 restates the structure of the former TOS and traffic class fields. 160 Therefore, for use in future drafts, including the next update to RFC 161 2474, the following definitions should apply: 162 - the Differentiated Services Field (DSField) is the six most 163 significant bits of the (former) IPV4 TOS octet or the (former) 164 IPV6 Traffic Class octet. 166 - the Differentiated Services Codepoint (DSCP) is a value which is 167 encoded in the DS field, and which each DS Node MUST use to select 168 the PHB which is to be experienced by each packet it forwards. 170 The two least significant bits of the IPV4 TOS octet and the IPV6 171 Traffic Class octet are not presently used by Diffserv. 173 The update should also reference the IANA Allocation Guidelines, 174 assuming that they are published as an RFC. 176 5. Ordered aggregates and PHB scheduling classes 178 Work on Diffserv support by MPLS LSRs led to the realization that a 179 concept was needed in Diffserv to capture the notion of a set of BAs 180 with a common ordering constraint. This presently applies to AF 181 behavior aggregates, since a DS node may not reorder packets of the 182 same microflow if they belong to the same AF class. This would, for 183 example, prevent an MPLS LSR which was also a DS node from 184 discriminating between packets of an AF BA based on drop precedence 185 and forwarding packets of the same AF class but different drop 186 precedence over different LSPs. The following new terms are defined. 188 PHB Scheduling Class: A PHB group for which a common constraint is 189 that ordering of packets must be preserved 191 Ordered Aggregate (OA): A set of Behavior Aggregates that share an 192 ordering constraint. The set of PHBs that are applied to this set 193 of Behavior Aggregates constitutes a PHB scheduling class. 195 6. Summary of pending changes 197 The following standards track RFCs are expected to be updated to 198 reflect the agreements captured in this memo. It is intended that 199 these updates occur when each specification progresses to Draft (or 200 if some issue arises that forces recycling at Proposed). 202 RFC 2474: revise definition of DS field 204 RFC 2475: revise definition of DS field. Add SLS and TCS 205 definitions. Update body of document to use SLS and TCS 206 appropriately. Add definitions of PHB scheduling class and ordered 207 aggregate. 209 RFC 2497: revise to reflect understanding that AF classes are 210 instances of the AF PHB group, and are not collectively a PHB 211 group. 213 7. Security Considerations Security considerations are addressed in RFC 214 2475. 216 Acknowledgements 218 References 220 [1] Nichols, Blake, Baker, Black, "Defintion of the Differentiated 221 Services Field (DS Field) in the IPv4 and IPv6 Headers" RFC 222 2474, December 1998. 224 [2] Blake, Black, Carlson, Davies, Wang and Weiss "An Architecture 225 for Differentiated Services", RFC 2475, December 1998. 227 [3] Heinanen, Baker, Weiss, Wrocklawski, "Assured Forwarding PHB 228 Group", RFC 2597 230 [4] Ramakrishnan and Floyd, "A proposal to add Explicit Congestion 231 Notification (ECN)" to IP, RFC 2481, January 1999 233 [5] Bradner and Paxon, IANA Allocation Guidelines for Values in the 234 Internet Protocol and Related Headers, draft-bradner-iana- 235 allocation-02.txt, October 1999, work in progress 237 Author's Address 239 Dan Grossman 240 Motorola, Inc. 241 20 Cabot Blvd. 242 Mansfield, MA 02048 243 Email: dan@dma.isg.mot.com 245 Full Copyright Statement 247 Copyright (C) The Internet Society (1999). All Rights Reserved. 249 This document and translations of it may be copied and furnished to 250 others, and derivative works that comment on or otherwise explain 251 itor assist in its implementation may be prepared, copied, published 252 and distributed, in whole or in part, without restriction of any 253 kind, provided that the above copyright notice and this paragraph are 254 included on all such copies and derivative works. However, this 255 document itself may not be modified in any way, such as by removing 256 the copyright notice or references to the Internet Society or other 257 Internet organizations, except as needed for the purpose of 258 developing Internet standards in which case the procedures for 259 copyrights defined in the Internet Standards process must be 260 followed, or as required to translate it into languages other than 261 English. 263 The limited permissions granted above are perpetual and will not be 264 revoked by the Internet Society or its successors or assigns. 266 This document and the information contained herein is provided on an 267 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 268 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 269 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 270 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 271 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.