idnits 2.17.1 draft-ietf-diffserv-new-terms-04.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 60 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 168: '... which each DS Node MUST use to select...' RFC 2119 keyword, line 214: '...th an unrecognized codepoint SHOULD be...' RFC 2119 keyword, line 246: '... DS domain MUST strictly police al...' RFC 2119 keyword, line 249: '... negotiated rate MUST be dropped. If ...' RFC 2119 keyword, line 250: '...ownstream domain MUST use 0 as the rat...' 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...' == (4 more instances...) -- 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) -- Looks like a reference, but probably isn't: 'DSFIELD' on line 211 -- Looks like a reference, but probably isn't: 'RFC791' on line 277 -- Looks like a reference, but probably isn't: 'RFC1349' on line 278 -- Looks like a reference, but probably isn't: 'RFC1812' on line 279 -- Looks like a reference, but probably isn't: 'RFC2780' on line 280 == Unused Reference: '1' is defined on line 315, 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) Summary: 8 errors (**), 0 flaws (~~), 10 warnings (==), 7 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: September 2001 5 draft-ietf-diffserv-new-terms-04.txt 6 March, 2001 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 Specification (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 Per-hop behavior (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 2597 [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 Diffserv Codepoints (DSCPs). 113 RFC 2597 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 2597 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 "Currently Unused" (CU) bits of the DS 144 Field have not been assigned to Diffserv, and have been assigned an 145 experimental use for an explicit congestion notification scheme [4]. 146 In the current text, a DSCP is, depending on context, either an encoding 147 which selects a PHB or a sub-field in the DS field which contains that 148 encoding. 150 The present text is also inconsistent with the IANA allocation 151 guidelines [5]. The IPV4 Type-of-Service (TOS) field and the IPV6 152 traffic class field are superceded by the 6 bit DS field and a 2 bit CU 153 field. The IANA allocates values in the DS field following the IANA 154 considerations section in RFC 2474. Experimental uses of the CU field 155 are assigned after IESG approval processes. Permanent values in the CU 156 field are allocated following a Standards Action process. 158 The consensus of the DiffServ working group is that [5] correctly 159 restates the structure of the former TOS and traffic class fields. 161 Therefore, for use in future drafts, including the next update to RFC 162 2474, the following definitions should apply: 163 - the Differentiated Services Field (DSField) is the six most 164 significant bits of the (former) IPV4 TOS octet or the (former) 165 IPV6 Traffic Class octet. 167 - the Differentiated Services Codepoint (DSCP) is a value which is 168 encoded in the DS field, and which each DS Node MUST use to select 169 the PHB which is to be experienced by each packet it forwards. 171 The two least significant bits of the IPV4 TOS octet and the IPV6 172 Traffic Class octet are not presently used by Diffserv. 174 The update should also reference the IANA Allocation Guidelines, 175 assuming that they are published as an RFC. 177 5. Ordered Aggregates and PHB Scheduling Classes 179 Work on Diffserv support by MPLS Label Switched Routers (LSRs) led to 180 the realization that a concept was needed in Diffserv to capture the 181 notion of a set of BAs with a common ordering constraint. This 182 presently applies to AF behavior aggregates, since a DS node may not 183 reorder packets of the same microflow if they belong to the same AF 184 class. This would, for example, prevent an MPLS LSR which was also a 185 DS node from discriminating between packets of an AF Behavior 186 Agrregeate (BA) based on drop precedence and forwarding packets of 187 the same AF class but different drop precedence over different LSPs. 188 The following new terms are defined. 190 PHB Scheduling Class: A PHB group for which a common constraint is 191 that ordering of at least those packets belonging to the same 192 microflow must be preserved. 194 Ordered Aggregate (OA): A set of Behavior Aggregates that share an 195 ordering constraint. The set of PHBs that are applied to this set 196 of Behavior Aggregates constitutes a PHB scheduling class. 198 6. Unknown/Improperly Mapped DSCPs 200 Several implementors have pointed out ambiguities or conflicts in the 201 Diffserv RFCs concerning behavior when a DS-node recieves a packet 202 with a DSCP which it does not understand. 204 RFC 2475 states: 205 "Ingress nodes must condition all other inbound traffic to ensure 206 that the DS codepoints are acceptable; packets found to have 207 unacceptable codepoints must either be discarded or must have their 208 DS codepoints modified to acceptable values before being forwarded. 209 For example, an ingress node receiving traffic from a domain with 210 which no enhanced service agreement exists may reset the DS 211 codepoint to the Default PHB codepoint [DSFIELD]." 213 On the other hand, RFC 2474 states: 214 "Packets received with an unrecognized codepoint SHOULD be 215 forwarded as if they were marked for the Default behavior (see Sec. 216 4), and their codepoints should not be changed." 218 The intent in RFC 2474 principally concerned DS-interior nodes. 219 However, this behavior could also be performed in DS-ingress nodes 220 AFTER the traffic conditioning required by RFC 2475 (in which case, 221 an unrecognized DSCP would occur only in the case of 222 misconfiguration). If a packet arrives with a DSCP that hadn't been 223 explicitly mapped to a particular PHB, it should be treated the same 224 way as a packet marked for Default. The alternatives were to assign 225 it another PHB, which could result in misallocation of provisioned 226 resources, or to drop it. Those are the only alternatives within the 227 framework of 2474. Neither alternative was considered desirable. 228 There has been discussion of a PHB which receives worse service than 229 the default; this might be a better alternative. Hence the 230 imperitive was"SHOULD" rather than "SHALL". 232 The intent in RFC 2475 clearly concerns DS-ingress nodes, or to be 233 more precise, the ingress traffic conditioning function. This is 234 another context where the "SHOULD" in RFC 2474 gives the flexibility 235 to do what the group intended. Such tortured readings are not 236 desirable. 238 Therefore, the statement in RFC 2474 will be clarified to indicate 239 that it is not intended to apply at the ingress traffic conditioning 240 function at a DS-ingress node, and cross reference RFC 2475 for that 241 case. 243 There is a similar issue, which manifests itself with Expedited 244 Forwarding (EF). RFC 2598 states: 245 To protect itself against denial of service attacks, the edge of a 246 DS domain MUST strictly police all EF marked packets to a rate 247 negotiated with the adjacent upstream domain. (This rate must be 248 <= the EF PHB configured rate.) Packets in excess of the 249 negotiated rate MUST be dropped. If two adjacent domains have not 250 negotiated an EF rate, the downstream domain MUST use 0 as the rate 251 (i.e., drop all EF marked packets). 253 The problem arises in the case of misconfiguration or routing 254 problems. An egress DS-node at the edge of one DS-domain forwards 255 packets an ingress DS-node at the edge of another DS domain. These 256 packets are marked with a DSCP that the egress node understands to 257 map to EF, but which the ingress node does not recognize. The 258 statement in RFC 2475 would appear to apply to this case. This is 259 being covered in the (draft) update to RFC2598. 261 7. No Backward Compatibility With RFC 1349 263 It has been pointed out that that RFC 2474 should have stated a bit 264 more explicitly that the TOS bit usage described in RFC 1349 is 265 obsoleted. This useage was intended to interact with OSPF extensions 266 in RFC 1247, which were never widely deployed. The processing of the 267 TOS bits is described as a requirement in RFC 1812. Although this is 268 a direct implication of the following sentence in RFC 2474: 269 "No attempt is made to maintain backwards compatibility with 270 the "DTR" 271 or TOS bits of the IPv4 TOS octet, as defined in [RFC791]." 273 Further clarification is needed. The previous sentence should be 274 augmented as follows when RFC 2474 is updated: 275 "No attempt is made to maintain backwards compatibility with the 276 "DTR/MBZ" 277 or TOS bits of the IPv4 TOS octet, as defined in [RFC791] and 278 [RFC1349]. This implies that TOS bit processing as described in 279 sections 5.2.4.3 and 5.3.2 of [RFC1812] is also obsoleted by this 280 memo. Also see [RFC2780]." 282 8. Summary of Pending Changes 284 The following standards track RFCs are expected to be updated to 285 reflect the agreements captured in this memo. It is intended that 286 these updates occur when each specification progresses to Draft (or 287 if some issue arises that forces recycling at Proposed). 289 RFC 2474: revise definition of DS field. Clarify that the 290 suggested default forwarding in the event of an unrecognized DSCP 291 is not intended to apply to ingress conditioning in DS-ingress 292 nodes. Clarify effects on RFC1349 and RFC1812. 294 RFC 2475: revise definition of DS field. Add SLS and TCS 295 definitions. Update body of document to use SLS and TCS 296 appropriately. Add definitions of PHB scheduling class and ordered 297 aggregate. 299 RFC 2497: revise to reflect understanding that AF classes are 300 instances of the AF PHB group, and are not collectively a PHB 301 group. 303 RFC 2598: put reference to RFC 2475 in security considerations to 304 cover the case of a DS egress node receiving an unrecognized DSCP 305 which maps to EF in the DS ingress node. (done) 307 7. Security Considerations 309 Security considerations are addressed in RFC 2475. 311 Acknowledgements 313 References 315 [1] Nichols, Blake, Baker, Black, "Defintion of the Differentiated 316 Services Field (DS Field) in the IPv4 and IPv6 Headers" RFC 317 2474, December 1998. 319 [2] Blake, Black, Carlson, Davies, Wang and Weiss "An Architecture 320 for Differentiated Services", RFC 2475, December 1998. 322 [3] Heinanen, Baker, Weiss, Wrocklawski, "Assured Forwarding PHB 323 Group", RFC 2597 325 [4] Ramakrishnan and Floyd, "A proposal to add Explicit Congestion 326 Notification (ECN)" to IP, RFC 2481, January 1999 328 [5] Bradner and Paxon, "IANA Allocation Guidelines for Values in the 329 Internet Protocol and Related Headers", RFC2780, March 2000 331 Author's Address 333 Dan Grossman 334 Motorola, Inc. 335 20 Cabot Blvd. 337 Mansfield, MA 02048 338 Email: dan@dma.isg.mot.com 340 Full Copyright Statement 342 Copyright (C) The Internet Society (1999). All Rights Reserved. 344 This document and translations of it may be copied and furnished to 345 others, and derivative works that comment on or otherwise explain 346 itor assist in its implementation may be prepared, copied, published 347 and distributed, in whole or in part, without restriction of any 348 kind, provided that the above copyright notice and this paragraph are 349 included on all such copies and derivative works. However, this 350 document itself may not be modified in any way, such as by removing 351 the copyright notice or references to the Internet Society or other 352 Internet organizations, except as needed for the purpose of 353 developing Internet standards in which case the procedures for 354 copyrights defined in the Internet Standards process must be 355 followed, or as required to translate it into languages other than 356 English. 358 The limited permissions granted above are perpetual and will not be 359 revoked by the Internet Society or its successors or assigns. 361 This document and the information contained herein is provided on an 362 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 363 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 364 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 365 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 366 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.