idnits 2.17.1 draft-ietf-diffserv-new-terms-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: ---------------------------------------------------------------------------- ** 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? == There is 1 instance of lines with non-ascii characters in the document. == 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 5 pages 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 148: '... 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 55 has weird spacing: '...ding of the a...' == Line 66 has weird spacing: '...t least in pa...' == Line 73 has weird spacing: '...r other busin...' == Line 74 has weird spacing: '...re also could...' == Line 92 has weird spacing: '...ain) or it ca...' -- 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) ** Downref: Normative reference to an Informational RFC: RFC 2475 (ref. '2') Summary: 7 errors (**), 0 flaws (~~), 9 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: April 2000 draft-ietf-diffserv-new-terms-00.txt 4 October, 1999 6 New Terminology for Diffserv 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of section 10 of RFC2026. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as ``work in progress.'' 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 To learn the current status of any Internet-Draft, please check the 28 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 29 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 30 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 31 ftp.isi.edu (US West Coast). 33 Abstract 35 This memo captures Diffserv working group agreements concerning new 36 and improved terminology. It is intended as a living document for 37 use by the Diffserv working group, and especially for use of authors 38 of Diffserv drafts. It is expected that the terminology in this memo 39 will be incorporated into the existing Diffserv RFCs when they are 40 updated. 42 Copyright Notice 44 Copyright (C) The Internet Society (1999). All Rights Reserved. 46 1. Introduction As the Diffserv work has evolved, there have been 47 several cases where terminology has needed to be created or the 48 definitions in [1] and [2] have needed to be refined. This memo was 49 created to capture and test group agreements on terminology, rather 50 than attempting to revise the base RFCs and recycle them at proposed 51 standard. Diffserv authors are encouraged to use the new terminology 52 whereever appropriate. 54 [Author's note: the following represents in part the Author's 55 understanding of the agreements. However, in some cases, the Author 56 found it necessary to elaborate or expand. The Author has also 57 polled the Diffserv chairs and incorporated their recollection into 58 this memo. Every attempt will be made to refine this memo based on 59 comments from the group. No claim is made that the �00 version of 60 this memo represents a group consensus.) 62 2. Terminology related to Service Level Agreements (SLAs) The Diffserv 63 Architecture [2] uses the term "Service Level Agreement" (SLA) to 64 describe the "service contract... that specifies the forwarding 65 service a customer should receive". The SLA may include traffic 66 conditioning rules which (at least in part) constitute a Traffic 67 Conditioning Agreement (TCA). A TCA is "an agreement specifying 68 classifier rules and any corresponding traffic profiles and metering, 69 marking, discarding and/or shaping rules which are to apply...." 71 As work progressed in Diffserv, it came to be believed that the 72 notion of an "agreement" implied considerations that were of a 73 pricing, contractual or other business nature, as well as those that 74 were strictly technical. There also could be other technical 75 considerations in such an agreement (e.g., service availability) 76 which are not addressed by Diffserv. It was therefore agreed that 77 the notions of SLAs and TCAs would be taken to represent the broader 78 context, and that new terminology would be used to describe those 79 elements of service and traffic conditioning that are addressed by 80 Diffserv. 82 - A Service Level Specfication (SLS) is a set of parameters and 83 their values which together define the service offered to a traffic 84 stream by a DS domain. 86 - A Traffic Conditioning Specification (TCS) is a set of parameters 87 and their values which together specify a set of classfier rules 88 and a traffic profile. A TCS is an integral element of an SLS. 90 Note that the definition of "Traffic stream" is unchanged from RFC 2475. 91 A traffic stream can be an individual microflow or a group of microflows 92 (i.e., in a source or destination DS domain) or it can be a BA. Thus, 93 an SLS may apply in the source or destination DS domain to a single 94 microflow or group of microflows, as well as to a BA in any DS domain. 96 2. PHB Group RFC 2475 deines a PHB group to be: 97 "a set of one or more PHBs that can only be meaningfully specified 98 and implemented simultaneously, due to a common constraint applying 99 to all PHBs in the set such as a queue servicing or queue 100 management policy. A PHB group provides a service building block 101 that allows a set of related forwarding behaviors to be specified 102 together (e.g., four dropping priorities). A single PHB is a 103 special case of a PHB group." 105 RFC 2497 [3] is entitled "Assured Forwarding PHB Group", and uses the 106 term AF PHB group consistently in discussing the set of twelve AF PHBs. 107 However, this usage is not consistent with RFC 2475. There is no common 108 constraint which applies to BAs having different AF classes. Indeed, 109 packets having different AF classes must be forwarded independently. 110 Therefore, each of the four AF classes constitutes a separate PHB 111 group, each having three PHBs corresponding to three drop precedences. 113 A new definition is thus needed to describe a set of related PHB groups. 115 PHB Group Family: a set of two or more PHB groups which are 116 specified together and have similar relationships among their 117 constituent PHBs, but which lack any common constraint. A PHB 118 group family provides a service building block that allows a set of 119 related PHB groups to be specified together (e.g., three classes of 120 PHB groups). 122 3. Definition of the DS Field Diffserv uses six bits of the IPV4 or IPV6 123 header to convey the Diffserv Codepoint (DSCP), which selects a PHB. 124 RFC 2474 attempts to rename the TOS octet of the IPV4 header, and 125 Traffic Class octet of the IPV6 header, respectively, to the DS field. 126 The DS Field has a six bit Diffserv Codepoint and two "currently unused 127 bits". 129 Several participants in the Diffserv working group have pointed out that 130 this leads to inconsistencies. In particular, the CU bits of the DS 131 Field have not been assigned to Diffserv (and in fact are being used by 132 RFC 2481 [] for explicit congestion notification). A DSCP is, 133 depending on context, either an encoding which selects a PHB or a sub- 134 field in the DS field which contains that encoding. 136 [Author's note: there was no working group consensus on this subject. 137 This is my attempt at an intellectually satisfying solution, albeit one 138 that will require readers to switch between two sets of terminology 139 until RFC 2474 can be updated] 141 For use in future drafts, including the next update to RFC 2474, the 142 following definitions should apply: 143 - the Differentiated Services Field (DSField) is the six most 144 significant bits of either the IPV4 TOS octet or the IPV6 Traffic 145 Class octet. 147 - the Differentiated Services Codepoint (DSCP) is a value which is 148 encoded in the DS field, and which each DS Node MUST use to select 149 the PHB which is to be experienced by each packet it forwards. 151 The two least significant bits of the IPV4 TOS octet and the IPV6 152 Traffic Class octet are not presently used by Diffserv. 154 4. Ordered aggregates and PHB scheduling classes 156 Work on Diffserv support by MPLS LSRs led to the realization that a 157 concept was needed in Diffserv to capture the notion of a set of BAs 158 with a common ordering constraint. This presently applies to AF 159 behavior aggregates, since a DS node may not reorder packets of the same 160 microflow if they belong to the same AF class. This would, for example, 161 prevent an MPLS LSR which was also a DS node from discriminating between 162 packets of an AF BA based on drop precedence and forwarding packets of 163 the same AF class but different drop precedence over different LSPs. 164 The following new terms are defined. 166 PHB Scheduling Class: A PHB group for which a common constraint is 167 that ordering of packets must be preserved 169 Ordered Aggregate (OA): A set of Behavior Aggregates that share an 170 ordering constraint. All of the packets of an OA are members of the 171 same PHB scheduling class. 173 5. Security Considerations Security considerations are addressed in RFC 174 2475. 176 Acknowledgements 178 References 180 [1] RFC 2474. 182 [2] Blake, Black, Carlson, Davies, Wang and Weiss "An Architecture 183 for Differentiated Services", RFC 2475, December 1998. 185 [3] Heinanen and Guerin, "Assured Forwarding PHB Group", RFC 2497 187 Author's Address 188 Dan Grossman 189 Motorola, Inc. 190 20 Cabot Blvd. 191 Mansfield, MA 02048 192 Email: dan@dma.isg.mot.com 194 Full Copyright Statement 196 Copyright (C) The Internet Society (1999). All Rights Reserved. 198 This document and translations of it may be copied and furnished to 199 others, and derivative works that comment on or otherwise explain 200 itor assist in its implementation may be prepared, copied, published 201 and distributed, in whole or in part, without restriction of any 202 kind, provided that the above copyright notice and this paragraph are 203 included on all such copies and derivative works. However, this 204 document itself may not be modified in any way, such as by removing 205 the copyright notice or references to the Internet Society or other 206 Internet organizations, except as needed for the purpose of 207 developing Internet standards in which case the procedures for 208 copyrights defined in the Internet Standards process must be 209 followed, or as required to translate it into languages other than 210 English. 212 The limited permissions granted above are perpetual and will not be 213 revoked by the Internet Society or its successors or assigns. 215 This document and the information contained herein is provided on an 216 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 217 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 218 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 219 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 220 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.