idnits 2.17.1 draft-ietf-diffserv-new-terms-07.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. == 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 481 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 181: '... which each DS Node MUST use to select...' RFC 2119 keyword, line 226: '...th an unrecognized codepoint SHOULD be...' RFC 2119 keyword, line 258: '... DS domain MUST strictly police al...' RFC 2119 keyword, line 261: '... negotiated rate MUST be dropped. If ...' RFC 2119 keyword, line 262: '...ownstream domain MUST use 0 as the rat...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 61 has weird spacing: '...t least in pa...' == Line 69 has weird spacing: '...r other busin...' == Line 88 has weird spacing: '...ain) or it ca...' == Line 135 has weird spacing: '... exists for h...' == Line 137 has weird spacing: '... should now b...' == (2 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 223 -- Looks like a reference, but probably isn't: 'RFC791' on line 290 -- Looks like a reference, but probably isn't: 'RFC1349' on line 290 -- Looks like a reference, but probably isn't: 'RFC1812' on line 291 -- Looks like a reference, but probably isn't: 'RFC1122' on line 291 -- Looks like a reference, but probably isn't: 'RFC1123' on line 291 -- Looks like a reference, but probably isn't: 'RFC2780' on line 292 == Unused Reference: '1' is defined on line 350, 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) ** Downref: Normative reference to an Informational RFC: RFC 3198 (ref. '6') ** Obsolete normative reference: RFC 2598 (ref. '7') (Obsoleted by RFC 3246) Summary: 7 errors (**), 0 flaws (~~), 10 warnings (==), 9 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: June, 2002 5 draft-ietf-diffserv-new-terms-07.txt 6 December, 2001 8 New Terminology and Clarifications 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/1id-abstracts.html 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html 29 Abstract 31 This memo captures Diffserv working group agreements concerning new 32 and improved terminology, and also provides minor technical 33 clarifications. It is intended to update RFC 2474, RFC 2475 and RFC 34 2597. When RFCs 2474 and 2597 advance on the standards track, and 35 RFC 2475 is updated, it is intended that the revisions in this memo 36 will be incorporated, and that this memo will be obsoleted by the new 37 RFCs. 39 Copyright Notice 41 Copyright (C) The Internet Society (1999, 2001). All Rights 42 Reserved. 44 1. Introduction 46 As the Diffserv work has evolved, there have been several cases where 47 terminology has needed to be created or the definitions in Diffserv 48 standards track RFCs have needed to be refined. Some minor technical 49 clarifications were also found to be needed. This memo was created 50 to capture group agreements, rather than attempting to revise the 51 base RFCs and recycle them at proposed standard. It updates in part 52 RFC 2474, RFC 2475 and RFC 2597. RFC 2598 has been updated by RFC 53 XXXX (draft-ietf-diffserv-rfc2598bis), and clarifications agreed by 54 the group were incorporated in that update. 56 2. Terminology Related to Service Level Agreements (SLAs) 58 The Diffserv Architecture [2] uses the term "Service Level Agreement" 59 (SLA) to describe the "service contract... that specifies the 60 forwarding service a customer should receive". The SLA may include 61 traffic conditioning rules which (at least in part) constitute a 62 Traffic Conditioning Agreement (TCA). A TCA is "an agreement 63 specifying classifier rules and any corresponding traffic profiles 64 and metering, marking, discarding and/or shaping rules which are to 65 apply...." 67 As work progressed in Diffserv (as well as in the Policy WG [6]), it 68 came to be believed that the notion of an "agreement" implied 69 considerations that were of a pricing, contractual or other business 70 nature, as well as those that were strictly technical. There also 71 could be other technical considerations in such an agreement (e.g., 72 service availability) which are not addressed by Diffserv. It was 73 therefore agreed that the notions of SLAs and TCAs would be taken to 74 represent the broader context, and that new terminology would be used 75 to describe those elements of service and traffic conditioning that 76 are addressed by Diffserv. 78 - A Service Level Specification (SLS) is a set of parameters and 79 their values which together define the service offered to a traffic 80 stream by a DS domain. 82 - A Traffic Conditioning Specification (TCS) is a set of parameters 83 and their values which together specify a set of classfier rules 84 and a traffic profile. A TCS is an integral element of an SLS. 86 Note that the definition of "Traffic stream" is unchanged from RFC 87 2475. A traffic stream can be an individual microflow or a group of 88 microflows (i.e., in a source or destination DS domain) or it can 89 be a BA. Thus, an SLS may apply in the source or destination DS 90 domain to a single microflow or group of microflows, as well as to a 91 BA in any DS domain. 93 Also note that the definition of a "Service Provisioning Policy" is 94 unchanged from RFC 2475. RFC 2475 defines a "Service Provisioning 95 Policy as "a policy which defines how traffic conditioners are 96 configured on DS boundary nodes and how traffic streams are mapped to 97 DS behavior aggregates to achieve a range of services." According to 98 one definition given in RFC 3198 [6], a policy is "...a set of rules 99 to administer, manage, and control access to network resources". 100 Therefore, the relationship between an SLS and a service provisioning 101 policy is that the latter is, in part, the set of rules that express 102 the parameters and range of values that may be in the former. 104 Further note that this definition is more restrictive than that in 105 RFC 3198. 107 3. Usage of PHB Group 109 RFC 2475 defines a Per-hop behavior (PHB) group to be: 111 "a set of one or more PHBs that can only be meaningfully specified 112 and implemented simultaneously, due to a common constraint applying 113 to all PHBs in the set such as a queue servicing or queue 114 management policy. A PHB group provides a service building block 115 that allows a set of related forwarding behaviors to be specified 116 together (e.g., four dropping priorities). A single PHB is a 117 special case of a PHB group." 119 One standards track PHB Group is defined in RFC 2597 [3], "Assured 120 Forwarding PHB Group". Assured Forwarding (AF) is a type of forwarding 121 behavior with some assigned level of queuing resources and three drop 122 precedences. An AF PHB Group consists of three PHBs, and uses three 123 Diffserv Codepoints (DSCPs). 125 RFC 2597 defines twelve DSCPs, corresponding to four independent AF 126 classes. The AF classes are referred to as AF1x, AF2x, AF3x, and AF4x 127 (where 'x' is 1, 2, or 3 to represent drop precedence). Each AF class 128 is one instance of an AF PHB Group. 130 There has been confusion expressed that RFC 2597 refers to all four AF 131 classes with their three drop precedences as being part of a single PHB 132 Group. However, since each AF class operates entirely independently of 133 the others, (and thus there is no common constraint among AF classes as 134 there is among drop precedences within an AF class) this usage is 135 inconsistent with RFC 2475. The inconsistency exists for historical 136 reasons and will be removed in future revisions of the AF specification. 137 It should now be understood that AF is a _type_ of PHB group, and each 138 AF class is an _instance_ of the AF type. 140 Authors of new PHB specifications should be careful to adhere to the RFC 141 2475 definition of PHB Group. RFC 2475 does not prohibit new PHB 142 specifications from assigning enough DSCPs to represent multiple 143 independent instances of their PHB Group. However, such a set of DSCPs 144 must not be referred to as a single PHB Group. 146 4. Definition of the DS Field 148 Diffserv uses six bits of the IPV4 or IPV6 header to convey the Diffserv 149 Codepoint (DSCP), which selects a PHB. RFC 2474 attempts to rename the 150 TOS octet of the IPV4 header, and Traffic Class octet of the IPV6 151 header, respectively, to the DS field. The DS Field has a six bit 152 Diffserv Codepoint and two "currently unused bits". 154 It has been pointed out that this leads to inconsistencies and 155 ambiguities. In particular, the "Currently Unused" (CU) bits of the DS 156 Field have not been assigned to Diffserv, and have been assigned an 157 experimental use for an explicit congestion notification scheme [4]. 158 In the current text, a DSCP is, depending on context, either an encoding 159 which selects a PHB or a sub-field in the DS field which contains that 160 encoding. 162 The present text is also inconsistent with BCP0037, IANA Allocation 163 Guidelines for Values in the Internet Protocol and Related Headers [5]. 164 The IPV4 Type-of-Service (TOS) field and the IPV6 traffic class field 165 are superceded by the 6 bit DS field and a 2 bit CU field. The IANA 166 allocates values in the DS field following the IANA considerations 167 section in RFC 2474. Experimental uses of the CU field are assigned 168 after IESG approval processes. Permanent values in the CU field are 169 allocated following a Standards Action process. 171 The consensus of the DiffServ working group is that [5] correctly 172 restates the structure of the former TOS and traffic class fields. 174 Therefore, for use in future drafts, including the next update to RFC 175 2474, the following definitions should apply: 176 - the Differentiated Services Field (DSField) is the six most 177 significant bits of the (former) IPV4 TOS octet or the (former) 178 IPV6 Traffic Class octet. 180 - the Differentiated Services Codepoint (DSCP) is a value which is 181 encoded in the DS field, and which each DS Node MUST use to select 182 the PHB which is to be experienced by each packet it forwards. 184 The two least significant bits of the IPV4 TOS octet and the IPV6 185 Traffic Class octet are not presently used by Diffserv. 187 The update should also reference BCP0037. 189 5. Ordered Aggregates and PHB Scheduling Classes 191 Work on Diffserv support by MPLS Label Switched Routers (LSRs) led to 192 the realization that a concept was needed in Diffserv to capture the 193 notion of a set of BAs with a common ordering constraint. This 194 presently applies to AF behavior aggregates, since a DS node may not 195 reorder packets of the same microflow if they belong to the same AF 196 class. This would, for example, prevent an MPLS LSR which was also a 197 DS node from discriminating between packets of an AF Behavior 198 Agrregeate (BA) based on drop precedence and forwarding packets of 199 the same AF class but different drop precedence over different LSPs. 200 The following new terms are defined. 202 PHB Scheduling Class: A PHB group for which a common constraint is 203 that ordering of at least those packets belonging to the same 204 microflow must be preserved. 206 Ordered Aggregate (OA): A set of Behavior Aggregates that share an 207 ordering constraint. The set of PHBs that are applied to this set 208 of Behavior Aggregates constitutes a PHB scheduling class. 210 6. Unknown/Improperly Mapped DSCPs 212 Several implementors have pointed out ambiguities or conflicts in the 213 Diffserv RFCs concerning behavior when a DS-node recieves a packet 214 with a DSCP which it does not understand. 216 RFC 2475 states: 217 "Ingress nodes must condition all other inbound traffic to ensure 218 that the DS codepoints are acceptable; packets found to have 219 unacceptable codepoints must either be discarded or must have their 220 DS codepoints modified to acceptable values before being forwarded. 221 For example, an ingress node receiving traffic from a domain with 222 which no enhanced service agreement exists may reset the DS 223 codepoint to the Default PHB codepoint [DSFIELD]." 225 On the other hand, RFC 2474 states: 226 "Packets received with an unrecognized codepoint SHOULD be 227 forwarded as if they were marked for the Default behavior (see Sec. 228 4), and their codepoints should not be changed." 230 The intent in RFC 2474 principally concerned DS-interior nodes. 231 However, this behavior could also be performed in DS-ingress nodes 232 AFTER the traffic conditioning required by RFC 2475 (in which case, 233 an unrecognized DSCP would occur only in the case of 234 misconfiguration). If a packet arrives with a DSCP that hadn't been 235 explicitly mapped to a particular PHB, it should be treated the same 236 way as a packet marked for Default. The alternatives were to assign 237 it another PHB, which could result in misallocation of provisioned 238 resources, or to drop it. Those are the only alternatives within the 239 framework of 2474. Neither alternative was considered desirable. 240 There has been discussion of a PHB which receives worse service than 241 the default; this might be a better alternative. Hence the 242 imperative was "SHOULD" rather than "SHALL". 244 The intent in RFC 2475 clearly concerns DS-ingress nodes, or to be 245 more precise, the ingress traffic conditioning function. This is 246 another context where the "SHOULD" in RFC 2474 gives the flexibility 247 to do what the group intended. Such tortured readings are not 248 desirable. 250 Therefore, the statement in RFC 2474 will be clarified to indicate 251 that it is not intended to apply at the ingress traffic conditioning 252 function at a DS-ingress node, and cross reference RFC 2475 for that 253 case. 255 There was a similar issue, which manifested itself with the first 256 incarnation of Expedited Forwarding (EF). RFC 2598 states: 257 To protect itself against denial of service attacks, the edge of a 258 DS domain MUST strictly police all EF marked packets to a rate 259 negotiated with the adjacent upstream domain. (This rate must be 260 <= the EF PHB configured rate.) Packets in excess of the 261 negotiated rate MUST be dropped. If two adjacent domains have not 262 negotiated an EF rate, the downstream domain MUST use 0 as the rate 263 (i.e., drop all EF marked packets). 265 The problem arose in the case of misconfiguration or routing 266 problems. An egress DS-node at the edge of one DS-domain forwards 267 packets to an ingress DS-node at the edge of another DS domain. 268 These packets are marked with a DSCP that the egress node understands 269 to map to EF, but which the ingress node does not recognize. The 270 statement in RFC 2475 would appear to apply to this case. RFC XXXX 271 [7] (draft-ietf-diffserv-rfc2598bis) clarifies this point. 273 7. No Backward Compatibility With RFC 1349 275 At least one implementor has expressed confusion about the 276 relationship of the DSField, as defined in RFC 2474, to the use of 277 the TOS bits, as described in RFC 1349. The RFC 1349 useage was 278 intended to interact with OSPF extensions in RFC 1247, which were 279 never widely deployed. The processing of the TOS bits is described 280 as a requirement in RFC 1812 [8], RFC 1122 [9] and RFC 1123 [10]. 281 RFC 2474 states: 282 "No attempt is made to maintain backwards compatibility with 283 the "DTR" 284 or TOS bits of the IPv4 TOS octet, as defined in [RFC791].", 286 In addition, RFC 2474 obsoletes RFC 1349 by IESG action. For 287 completeness, when RFC 2474 is updated, the sentence should read: 288 "No attempt is made to maintain backwards compatibility with the 289 "DTR/MBZ" or TOS bits of the IPv4 TOS octet, as defined in 290 [RFC791] and [RFC1349]. This implies that TOS bit processing as 291 described in [RFC1812], [RFC1122] and [RFC1123] is also obsoleted 292 by this memo. Also see [RFC2780]." 294 8. IANA Considerations 296 IANA has requested clarification of a point in RFC 2474, concerning 297 registration of experimental/local use DSCPs. When RFC 2474 is 298 revised, the following should be added to Section 6: 299 IANA is requested to maintain a registry of RECOMMENDED DSCP 300 values assigned by standards action. EXP/LU values are not to be 301 registered. 303 9. Summary of Pending Changes 305 The following standards track and informational RFCs are expected to 306 be updated to reflect the agreements captured in this memo. It is 307 intended that these updates occur when each standards track RFC 308 progresses to Draft (or if some issue arises that forces recycling at 309 Proposed). RFC 2475 is expected to be updated at about the same time 310 as RFC 2474. Those updates will also obsolete this memo. 312 RFC 2474: revise definition of DS field. Clarify that the 313 suggested default forwarding in the event of an unrecognized DSCP 314 is not intended to apply to ingress conditioning in DS-ingress 315 nodes. Clarify effects on RFC1349 and RFC1812. Clarify that only 316 RECOMMENDED DSCPs assigned by standards action are to be registered 317 by IANA. 319 RFC 2475: revise definition of DS field. Add SLS and TCS 320 definitions. Update body of document to use SLS and TCS 321 appropriately. Add definitions of PHB scheduling class and ordered 322 aggregate. 324 RFC 2497: revise to reflect understanding that AF classes are 325 instances of the AF PHB group, and are not collectively a PHB 326 group. 328 In addition, RFCXXXX [7] (draft-ietf-diffserv-rfc2598bis) put a 329 reference to RFC 2475 in the security considerations section to cover 330 the case of a DS egress node receiving an unrecognized DSCP which maps 331 to EF in the DS ingress node. 333 10. Security Considerations 335 Security considerations are addressed in RFC 2475. 337 Acknowledgements 339 This memo captures agreements of the Diffserv working group. Many 340 individuals contributed to the discussions on the Diffserv list and in 341 the meetings. The Diffserv chairs were Brian Carpenter and Kathie 342 Nichols. Among many who participated actively in these discussions 343 were Lloyd Wood, Juha Heinanen, Grenville Armitage, Scott Brim, Sharam 344 Davari, David Black, Gerard Gastaud, Joel Halpern, John Schnizlein, 345 Francois Le Faucheur, and Fred Baker. Mike Ayers, Mike Heard and Andrea 346 Westerinen provided valuable editorial comments. 348 Normative References 350 [1] Nichols, Blake, Baker, Black, "Defintion of the Differentiated 351 Services Field (DS Field) in the IPv4 and IPv6 Headers" RFC 352 2474, December 1998. 354 [2] Blake, Black, Carlson, Davies, Wang and Weiss "An Architecture 355 for Differentiated Services", RFC 2475, December 1998. 357 [3] Heinanen, Baker, Weiss, Wrocklawski, "Assured Forwarding PHB 358 Group", RFC 2597 360 [4] Ramakrishnan and Floyd, "A proposal to add Explicit Congestion 361 Notification (ECN)" to IP, RFC 2481, January 1999 363 [5] Bradner and Paxon, "IANA Allocation Guidelines for Values in the 364 Internet Protocol and Related Headers", BCP0037/RFC2780, March 365 2000 367 [6] Westerinen et al, "Terminology for Policy Based Management", RFC 368 3198 370 [7] Davie et al, "An Expedited Forwarding PHB", RFC XXXX (ex-draft- 371 ietf-rfc2598bis-02.txt) 373 [8] Baker, "Requirements for IP Version 4 Routers", RFC 1812 375 [9] Braden, "Requirements for Internet Hosts -- Communications 376 Layers", RFC1122/STD003 378 [10] Braden, "Requirements for Internet Hosts -- Application and 379 Support", RFC1123/STD003 381 Author's Address 383 Dan Grossman 384 Motorola, Inc. 385 20 Cabot Blvd. 386 Mansfield, MA 02048 387 Email: dan@dma.isg.mot.com 389 Full Copyright Statement 391 Copyright (C) The Internet Society (1999, 2001). All Rights 392 Reserved. 394 This document and translations of it may be copied and furnished to 395 others, and derivative works that comment on or otherwise explain 396 itor assist in its implementation may be prepared, copied, published 397 and distributed, in whole or in part, without restriction of any 398 kind, provided that the above copyright notice and this paragraph are 399 included on all such copies and derivative works. However, this 400 document itself may not be modified in any way, such as by removing 401 the copyright notice or references to the Internet Society or other 402 Internet organizations, except as needed for the purpose of 403 developing Internet standards in which case the procedures for 404 copyrights defined in the Internet Standards process must be 405 followed, or as required to translate it into languages other than 406 English. 408 The limited permissions granted above are perpetual and will not be 409 revoked by the Internet Society or its successors or assigns. 411 This document and the information contained herein is provided on an 412 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 413 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 414 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 415 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 416 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.