idnits 2.17.1 draft-ietf-diffserv-new-terms-06.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 65 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 184: '... which each DS Node MUST use to select...' RFC 2119 keyword, line 230: '...th an unrecognized codepoint SHOULD be...' RFC 2119 keyword, line 262: '... DS domain MUST strictly police al...' RFC 2119 keyword, line 265: '... negotiated rate MUST be dropped. If ...' RFC 2119 keyword, line 266: '...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 67 has weird spacing: '...t least in pa...' == Line 75 has weird spacing: '...r other busin...' == Line 76 has weird spacing: '...re also could...' == Line 94 has weird spacing: '...ain) or it ca...' == Line 139 has weird spacing: '... exists for h...' == (3 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 227 -- Looks like a reference, but probably isn't: 'RFC791' on line 293 -- Looks like a reference, but probably isn't: 'RFC1349' on line 294 -- Looks like a reference, but probably isn't: 'RFC1812' on line 295 -- Looks like a reference, but probably isn't: 'RFC2780' on line 296 == Unused Reference: '1' is defined on line 342, 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. -------------------------------------------------------------------------------- 2 Diffserv Working Group Dan Grossman 3 Internet Draft Motorola, Inc. 4 Expires: May 2002 6 draft-ietf-diffserv-new-terms-06.txt 7 November, 2001 9 New Terminology for Diffserv 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of section 10 of RFC2026. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as ``work in progress.'' 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/1id-abstracts.html 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 To learn the current status of any Internet-Draft, please check the 31 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 32 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 33 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 34 ftp.isi.edu (US West Coast). 36 Abstract 38 This memo captures Diffserv working group agreements concerning new 39 and improved terminology, and also provides minor technical 40 clarifications. It is intended to update RFC 2474, RFC 2475 and RFC 41 2597. When RFCs 2474 and 2597 advance on the standards track, and 42 RFC 2475 is updated, it is intended that the revisions in this memo 43 will be incorporated, and that this memo will be obsoleted by the new 44 RFCs. 46 Copyright Notice 48 Copyright (C) The Internet Society (1999, 2001). All Rights 49 Reserved. 51 1. Introduction 52 As the Diffserv work has evolved, there have been several cases where 53 terminology has needed to be created or the definitions in Diffserv 54 standards track RFCs have needed to be refined. Some minor technical 55 clarifications were also found to be needed. This memo was created 56 to capture group agreements, rather than attempting to revise the 57 base RFCs and recycle them at proposed standard. It updates in part 58 RFC 2474, RFC 2475 and RFC 2597. RFC 2598 has been updated by RFC 59 XXXX (draft-ietf-diffserv-rfc2598bis), and clarifications agreed by 60 the group were incorporated in that update. 62 2. Terminology Related to Service Level Agreements (SLAs) 64 The Diffserv Architecture [2] uses the term "Service Level Agreement" 65 (SLA) to describe the "service contract... that specifies the 66 forwarding service a customer should receive". The SLA may include 67 traffic conditioning rules which (at least in part) constitute a 68 Traffic Conditioning Agreement (TCA). A TCA is "an agreement 69 specifying classifier rules and any corresponding traffic profiles 70 and metering, marking, discarding and/or shaping rules which are to 71 apply...." 73 As work progressed in Diffserv, it came to be believed that the 74 notion of an "agreement" implied considerations that were of a 75 pricing, contractual or other business nature, as well as those that 76 were strictly technical. There also could be other technical 77 considerations in such an agreement (e.g., service availability) 78 which are not addressed by Diffserv. It was therefore agreed that 79 the notions of SLAs and TCAs would be taken to represent the broader 80 context, and that new terminology would be used to describe those 81 elements of service and traffic conditioning that are addressed by 82 Diffserv. 84 - A Service Level Specification (SLS) is a set of parameters and 85 their values which together define the service offered to a traffic 86 stream by a DS domain. 88 - A Traffic Conditioning Specification (TCS) is a set of parameters 89 and their values which together specify a set of classfier rules 90 and a traffic profile. A TCS is an integral element of an SLS. 92 Note that the definition of "Traffic stream" is unchanged from RFC 93 2475. A traffic stream can be an individual microflow or a group of 94 microflows (i.e., in a source or destination DS domain) or it can 95 be a BA. Thus, an SLS may apply in the source or destination DS 96 domain to a single microflow or group of microflows, as well as to a 97 BA in any DS domain. 99 Also note that the definition of a "Service Provisioning Policy" is 100 unchanged from RFC 2475. RFC 2475 defines a "Service Provisioning 101 Policy as "a policy which defines how traffic conditioners are 102 configured on DS boundary nodes and how traffic streams are mapped to 103 DS behavior aggregates to achieve a range of services." According to 104 one definition currently used by the POLICY working group, a policy 105 is "...a set of rules to administer, manage, and control access to 106 network resources". Therefore, the relationship between an SLS and a 107 service provisioning policy is that the latter is, in part, the set 108 of rules that define the parameters and range of values that may be 109 in the former. 111 3. Usage of PHB Group 113 RFC 2475 defines a Per-hop behavior (PHB) group to be: 115 "a set of one or more PHBs that can only be meaningfully specified 116 and implemented simultaneously, due to a common constraint applying 117 to all PHBs in the set such as a queue servicing or queue 118 management policy. A PHB group provides a service building block 119 that allows a set of related forwarding behaviors to be specified 120 together (e.g., four dropping priorities). A single PHB is a 121 special case of a PHB group." 123 One standards track PHB Group is defined in RFC 2597 [3], "Assured 124 Forwarding PHB Group". Assured Forwarding (AF) is a type of forwarding 125 behavior with some assigned level of queuing resources and three drop 126 precedences. An AF PHB Group consists of three PHBs, and uses three 127 Diffserv Codepoints (DSCPs). 129 RFC 2597 defines twelve DSCPs, corresponding to four independent AF 130 classes. The AF classes are referred to as AF1x, AF2x, AF3x, and AF4x 131 (where 'x' is 1, 2, or 3 to represent drop precedence). Each AF class 132 is one instance of an AF PHB Group. 134 There has been confusion expressed that RFC 2597 refers to all four AF 135 classes with their three drop precedences as being part of a single PHB 136 Group. However, since each AF class operates entirely independently of 137 the others, (and thus there is no common constraint among AF classes as 138 there is among drop precedences within an AF class) this usage is 139 inconsistent with RFC 2475. The inconsistency exists for historical 140 reasons and will be removed in future revisions of the AF specification. 141 It should now be understood that AF is a _type_ of PHB group, and each 142 AF class is an _instance_ of the AF type. 144 Authors of new PHB specifications should be careful to adhere to the RFC 145 2475 definition of PHB Group. RFC 2475 does not prohibit new PHB 146 specifications from assigning enough DSCPs to represent multiple 147 independent instances of their PHB Group. However, such a set of DSCPs 148 must not be referred to as a single PHB Group. 150 4. Definition of the DS Field 152 Diffserv uses six bits of the IPV4 or IPV6 header to convey the Diffserv 153 Codepoint (DSCP), which selects a PHB. RFC 2474 attempts to rename the 154 TOS octet of the IPV4 header, and Traffic Class octet of the IPV6 155 header, respectively, to the DS field. The DS Field has a six bit 156 Diffserv Codepoint and two "currently unused bits". 158 It has been pointed out that this leads to inconsistencies and 159 ambiguities. In particular, the "Currently Unused" (CU) bits of the DS 160 Field have not been assigned to Diffserv, and have been assigned an 161 experimental use for an explicit congestion notification scheme [4]. In 162 the current text, a DSCP is, depending on context, either an encoding 163 which selects a PHB or a sub-field in the DS field which contains that 164 encoding. 166 The present text is also inconsistent with the IANA allocation 167 guidelines [5]. The IPV4 Type-of-Service (TOS) field and the IPV6 168 traffic class field are superceded by the 6 bit DS field and a 2 bit CU 169 field. The IANA allocates values in the DS field following the IANA 170 considerations section in RFC 2474. Experimental uses of the CU field 171 are assigned after IESG approval processes. Permanent values in the CU 172 field are allocated following a Standards Action process. 174 The consensus of the DiffServ working group is that [5] correctly 175 restates the structure of the former TOS and traffic class fields. 177 Therefore, for use in future drafts, including the next update to RFC 178 2474, the following definitions should apply: 179 - the Differentiated Services Field (DSField) is the six most 180 significant bits of the (former) IPV4 TOS octet or the (former) 181 IPV6 Traffic Class octet. 183 - the Differentiated Services Codepoint (DSCP) is a value which is 184 encoded in the DS field, and which each DS Node MUST use to select 185 the PHB which is to be experienced by each packet it forwards. 187 The two least significant bits of the IPV4 TOS octet and the IPV6 188 Traffic Class octet are not presently used by Diffserv. 190 The update should also reference the IANA Allocation Guidelines, 191 assuming that they are published as an RFC. 193 5. Ordered Aggregates and PHB Scheduling Classes 195 Work on Diffserv support by MPLS Label Switched Routers (LSRs) led to 196 the realization that a concept was needed in Diffserv to capture the 197 notion of a set of BAs with a common ordering constraint. This 198 presently applies to AF behavior aggregates, since a DS node may not 199 reorder packets of the same microflow if they belong to the same AF 200 class. This would, for example, prevent an MPLS LSR which was also a 201 DS node from discriminating between packets of an AF Behavior 202 Agrregeate (BA) based on drop precedence and forwarding packets of 203 the same AF class but different drop precedence over different LSPs. 204 The following new terms are defined. 206 PHB Scheduling Class: A PHB group for which a common constraint is 207 that ordering of at least those packets belonging to the same 208 microflow must be preserved. 210 Ordered Aggregate (OA): A set of Behavior Aggregates that share an 211 ordering constraint. The set of PHBs that are applied to this set 212 of Behavior Aggregates constitutes a PHB scheduling class. 214 6. Unknown/Improperly Mapped DSCPs 216 Several implementors have pointed out ambiguities or conflicts in the 217 Diffserv RFCs concerning behavior when a DS-node recieves a packet 218 with a DSCP which it does not understand. 220 RFC 2475 states: 221 "Ingress nodes must condition all other inbound traffic to ensure 222 that the DS codepoints are acceptable; packets found to have 223 unacceptable codepoints must either be discarded or must have their 224 DS codepoints modified to acceptable values before being forwarded. 225 For example, an ingress node receiving traffic from a domain with 226 which no enhanced service agreement exists may reset the DS 227 codepoint to the Default PHB codepoint [DSFIELD]." 229 On the other hand, RFC 2474 states: 230 "Packets received with an unrecognized codepoint SHOULD be 231 forwarded as if they were marked for the Default behavior (see Sec. 232 4), and their codepoints should not be changed." 234 The intent in RFC 2474 principally concerned DS-interior nodes. 235 However, this behavior could also be performed in DS-ingress nodes 236 AFTER the traffic conditioning required by RFC 2475 (in which case, 237 an unrecognized DSCP would occur only in the case of 238 misconfiguration). If a packet arrives with a DSCP that hadn't been 239 explicitly mapped to a particular PHB, it should be treated the same 240 way as a packet marked for Default. The alternatives were to assign 241 it another PHB, which could result in misallocation of provisioned 242 resources, or to drop it. Those are the only alternatives within the 243 framework of 2474. Neither alternative was considered desirable. 244 There has been discussion of a PHB which receives worse service than 245 the default; this might be a better alternative. Hence the 246 imperitive was"SHOULD" rather than "SHALL". 248 The intent in RFC 2475 clearly concerns DS-ingress nodes, or to be 249 more precise, the ingress traffic conditioning function. This is 250 another context where the "SHOULD" in RFC 2474 gives the flexibility 251 to do what the group intended. Such tortured readings are not 252 desirable. 254 Therefore, the statement in RFC 2474 will be clarified to indicate 255 that it is not intended to apply at the ingress traffic conditioning 256 function at a DS-ingress node, and cross reference RFC 2475 for that 257 case. 259 There was a similar issue, which manifested itself with the first 260 incarnation of Expedited Forwarding (EF). RFC 2598 states: 261 To protect itself against denial of service attacks, the edge of a 262 DS domain MUST strictly police all EF marked packets to a rate 263 negotiated with the adjacent upstream domain. (This rate must be 264 <= the EF PHB configured rate.) Packets in excess of the 265 negotiated rate MUST be dropped. If two adjacent domains have not 266 negotiated an EF rate, the downstream domain MUST use 0 as the rate 267 (i.e., drop all EF marked packets). 269 The problem arose in the case of misconfiguration or routing 270 problems. An egress DS-node at the edge of one DS-domain forwards 271 packets an ingress DS-node at the edge of another DS domain. These 272 packets are marked with a DSCP that the egress node understands to 273 map to EF, but which the ingress node does not recognize. The 274 statement in RFC 2475 would appear to apply to this case. RFC XXXX 275 (draft-ietf-diffserv-rfc2598bis) clarifies this point. 277 7. No Backward Compatibility With RFC 1349 279 At least one implementor has expressed confusion about the 280 relationship of the DSField defined in RFC 2474 to the use of the TOS 281 bits described in RFC 1349. This useage was intended to interact 282 with OSPF extensions in RFC 1247, which were never widely deployed. 283 The processing of the TOS bits is described as a requirement in RFC 284 1812. RFC 2474 states: 285 "No attempt is made to maintain backwards compatibility with 286 the "DTR" 287 or TOS bits of the IPv4 TOS octet, as defined in [RFC791].", 289 In addition, RFC 2474 obsoletes RFC 1349 by IESG action. For 290 completeness, when RFC 2474 is updated, the sentence should read: 291 "No attempt is made to maintain backwards compatibility with the 292 "DTR/MBZ" 293 or TOS bits of the IPv4 TOS octet, as defined in [RFC791] and 294 [RFC1349]. This implies that TOS bit processing as described in 295 sections 5.2.4.3 and 5.3.2 of [RFC1812] is also obsoleted by this 296 memo. Also see [RFC2780]." 298 8. Summary of Pending Changes 300 The following standards track and informational RFCs are expected to 301 be updated to reflect the agreements captured in this memo. It is 302 intended that these updates occur when each standards track RFC 303 progresses to Draft (or if some issue arises that forces recycling at 304 Proposed). RFC 2475 is expected to be updated at about the same time 305 as RFC 2474. These updates will also obsolete this memo. 307 RFC 2474: revise definition of DS field. Clarify that the 308 suggested default forwarding in the event of an unrecognized DSCP 309 is not intended to apply to ingress conditioning in DS-ingress 310 nodes. Clarify effects on RFC1349 and RFC1812. 312 RFC 2475: revise definition of DS field. Add SLS and TCS 313 definitions. Update body of document to use SLS and TCS 314 appropriately. Add definitions of PHB scheduling class and ordered 315 aggregate. 317 RFC 2497: revise to reflect understanding that AF classes are 318 instances of the AF PHB group, and are not collectively a PHB 319 group. 321 In addition, RFCXXXX (draft-ietf-diffserv-rfc2598bis) put a reference to 322 RFC 2475 in the security considerations section to cover the case of a 323 DS egress node receiving an unrecognized DSCP which maps to EF in the DS 324 ingress node. 326 7. Security Considerations 328 Security considerations are addressed in RFC 2475. 330 Acknowledgements This memo captures agreements of the Diffserv working 331 group. Many individuals contributed to the discussions on the Diffserv 332 list and in the meetings. The Diffserv chairs were Brian Carpenter and 333 Kathie Nichols. Among many who participated actively in these 334 discussions were Lloyd Wood, Juha Heinanen, Grenville Armitage, Scott 335 Brim, Sharam Davari, David Black, Gerard Gastaud, Joel Halpern, John 336 Schnizlein, Francois Le Faucheur, and Fred Baker [Author's note: who 337 have I forgotten? Please respond privately]. Mike Ayers provided 338 valuable editorial comments. 340 References 342 [1] Nichols, Blake, Baker, Black, "Defintion of the Differentiated 343 Services Field (DS Field) in the IPv4 and IPv6 Headers" RFC 344 2474, December 1998. 346 [2] Blake, Black, Carlson, Davies, Wang and Weiss "An Architecture 347 for Differentiated Services", RFC 2475, December 1998. 349 [3] Heinanen, Baker, Weiss, Wrocklawski, "Assured Forwarding PHB 350 Group", RFC 2597 352 [4] Ramakrishnan and Floyd, "A proposal to add Explicit Congestion 353 Notification (ECN)" to IP, RFC 2481, January 1999 355 [5] Bradner and Paxon, "IANA Allocation Guidelines for Values in the 356 Internet Protocol and Related Headers", RFC2780, March 2000 358 Author's Address 360 Dan Grossman 361 Motorola, Inc. 362 20 Cabot Blvd. 363 Mansfield, MA 02048 364 Email: dan@dma.isg.mot.com 366 Full Copyright Statement 368 Copyright (C) The Internet Society (1999, 2001). All Rights 369 Reserved. 371 This document and translations of it may be copied and furnished to 372 others, and derivative works that comment on or otherwise explain 373 itor assist in its implementation may be prepared, copied, published 374 and distributed, in whole or in part, without restriction of any 375 kind, provided that the above copyright notice and this paragraph are 376 included on all such copies and derivative works. However, this 377 document itself may not be modified in any way, such as by removing 378 the copyright notice or references to the Internet Society or other 379 Internet organizations, except as needed for the purpose of 380 developing Internet standards in which case the procedures for 381 copyrights defined in the Internet Standards process must be 382 followed, or as required to translate it into languages other than 383 English. 385 The limited permissions granted above are perpetual and will not be 386 revoked by the Internet Society or its successors or assigns. 388 This document and the information contained herein is provided on an 389 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 390 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 391 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 392 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 393 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.