idnits 2.17.1 draft-ietf-tsvwg-diffserv-class-aggr-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 816. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 827. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 834. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 840. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([5]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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.) -- The document date (July 9, 2007) is 6136 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '1' is defined on line 696, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 699, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2309 (ref. '9') (Obsoleted by RFC 7567) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TSVWG K. Chan 3 Internet-Draft J. Babiarz 4 Intended status: Informational Nortel 5 Expires: January 10, 2008 F. Baker 6 Cisco Systems 7 July 9, 2007 9 Aggregation of DiffServ Service Classes 10 draft-ietf-tsvwg-diffserv-class-aggr-03 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 10, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 In the core of a high capacity network, service differentiation is 44 still needed to support applications' utilization of the network. 45 Applications with similar traffic characteristics and performance 46 requirements are mapped into diffserv service classes based on end- 47 to-end behavior requirements of the applications as indicated by 48 Diffserv Service Classes [5]. However, some network segments may be 49 configured in such a way that a single forwarding treatment may 50 satisfy the traffic characteristics and performance requirements of 51 two or more service classes. In these cases, it may be desirable to 52 aggregate two or more Diffserv Service Classes [5] into a single 53 forwarding treatment. This document provides guidelines for the 54 aggregation of Diffserv Service Classes [5] into forwarding 55 treatments. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Overview of Service Class Aggregation . . . . . . . . . . . . 5 63 4. Service Classes to Treatment Aggregate Mapping . . . . . . . . 6 64 4.1. Mapping Service Classes into Four Treatment Aggregates . . 6 65 4.1.1. Network Control Treatment Aggregate . . . . . . . . . 9 66 4.1.2. Real Time Treatment Aggregate . . . . . . . . . . . . 10 67 4.1.3. Assured Elastic Treatment Aggregate . . . . . . . . . 10 68 4.1.4. Elastic Treatment Aggregate . . . . . . . . . . . . . 11 69 5. Treatment Aggregates and Inter-Provider Relationships . . . . 12 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 72 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 73 Appendix A. Using MPLS for Treatment Aggregates . . . . . . . . 13 74 Appendix A.1. Network Control Treatment Aggregate with E-LSP . . . 15 75 Appendix A.2. Real Time Treatment Aggregate with E-LSP . . . . . . 15 76 Appendix A.3. Assured Elastic Treatment Aggregate with E-LSP . . . 15 77 Appendix A.4. Elastic Treatment Aggregate with E-LSP . . . . . . . 15 78 Appendix A.5. Treatment Aggregates and L-LSP . . . . . . . . . . . 16 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 80 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 81 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 83 Intellectual Property and Copyright Statements . . . . . . . . . . 19 85 1. Introduction 87 In the core of a high capacity network, it is common for the network 88 to be engineered in such a way that a major link, switch, or router 89 can fail and the result will be a routed network that still meets 90 ambient SLAs. The implication of this is that there is sufficient 91 capacity on any given link such that all SLAs sold can be 92 simultaneously supported at their respective maximum rates, and that 93 this remains true after re-routing (either IP re-routing or MPLS 94 protection-mode switching) has occurred. 96 Over-provisioning is generally considered to meet the requirements of 97 all traffic without further QoS treatment, and in the general case 98 that is true in high capacity backbones. However, as the process of 99 network convergence continues, and with the increasing speed of the 100 access networks, certain services still have issues. Delay, jitter, 101 and occasional loss are perfectly acceptable for elastic 102 applications. However, sub-second surges that occur in the best- 103 designed of networks [14] affect real-time applications. Moreover, 104 DOS loads, worms, and network disruptions such as that of 11 105 September 2001 affect routing [15]. Our objective is to prevent 106 disruption to routing (which in turn affects all services), protect 107 real-time jitter-sensitive services, while minimizing loss and delay 108 of sensitive elastic traffic. 110 The document "Diffserv Service Classes" [5] defines the basic 111 diffserv classes from the points of view of the application requiring 112 specific end-to-end behaviors from the network. The service classes 113 are differentiated based on the traffic-payload's tolerance to packet 114 loss, delay, and delay variation (jitter). Different degrees of 115 these criteria form the foundation for supporting the needs of real- 116 time and elastic traffic. The "Diffserv Service Classes" [5] 117 document also provides recommendations for the treatment method of 118 these service classes. But, at some network segments of the end-to- 119 end path, the number of levels of network treatment differentiation 120 may be less than the number of service classes that the network 121 segment needs to support. In such a situation, that network segment 122 may use the same treatment to support more than one service class. 123 In this document we provide guidelines on how multiple service 124 classes may be aggregated into a forwarding treatment aggregate. 125 With the IP traffic belonging to service classes, expressed using the 126 DSCP, as described by "Diffserv Service Classes" [5]. Note that in a 127 given domain, we may recommend that the supported service classes be 128 aggregated into forwarding treatment aggregates; however, this does 129 not mean all service classes need to be supported and hence not all 130 forwarding treatment aggregates need to be supported. A domain may 131 support fewer or greater number of forwarding treatment aggregates. 132 Which service classes and which forwarding treatment aggregates are 133 supported by a domain is up to the domain administration and may be 134 influenced by business reasons. 136 In this document, we've provided: 138 o definitions for terminology we use in this document, 140 o requirements for performing this aggregation, 142 o an example of performing this aggregation over MPLS using E-LSP. 144 The treatment aggregate recommendations are designed to aggregate the 145 service classes [5] in such a manner as to protect real-time traffic 146 and routing, on the assumption that real-time sessions are protected 147 from each other by admission at the edge. 149 In the appendix, an example of aggregation over MPLS networks using 150 E-LSP, EXP Inferred PHB Scheduling Class (PSC) Label Switched Path 151 (LSP), to realize the treatment aggregates is provided. Note that 152 the MPLS E-LSP is just an example; this document does not exclude the 153 use of other methods. This example only considers aggregation of IP 154 traffic into E-LSP. The use of E-LSP by none-IP traffic is not 155 discussed. 157 1.1. Requirements Notation 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in RFC 2119 [3]. 163 2. Terminology 165 This document assumes the reader is familiar with the terms used in 166 differentiated services. This document provides the definitions for 167 new terms introduced by this document and referencing information for 168 existing none differentiated services terms defined in existing RFCs. 170 For new terms introduced by this document, we provide the definition 171 here: 173 o Treatment Aggregate. This term is defined as the aggregate of 174 DiffServ service classes [5]. A Treatment Aggregate is concerned 175 only with the forwarding treatment of the aggregated traffic, 176 which may be marked with multiple DSCPs. A Treatment Aggregate 177 differs from Behavior Aggregate [4] and Traffic Aggregate [16], 178 each of which indicate the aggregated traffic having a single 179 diffserv codepoint and utilizing a single PHB. 181 For terms from existing RFCs, we provide the reference to the 182 appropriate section of the relevant RFC that contain the definition: 184 o Real-Time and Elastic Applications and their traffic. Section 3.1 185 of RFC 1633 [6]. 187 o Diffserv Service Class. Section 1.3 of RFC 4594 [5]. 189 o MPLS E-LSP, EXP Inferred PHB Scheduling Class (PSC) Label Switched 190 Path (LSP). Section 1.2 of RFC 3270 [8]. 192 o MPLS L-LSP, Label Only Inferred PHB Scheduling Class (PSC) Label 193 Switched Path (LSP). Section 1.3 of RFC 3270 [8]. 195 3. Overview of Service Class Aggregation 197 In diffserv domains where less granular traffic treatment 198 differentiation is provided, aggregation of the different service 199 classes [5] may be required. 201 These aggregations have the following requirements: 203 1. The end-to-end network performance characteristic required by the 204 application must be supported. This performance characteristic 205 is represented by the use of Diffserv Service Classes [5]. 207 2. The treatment aggregate must exhibit the strictest requirement of 208 its member service classes. 210 3. The treatment aggregate should only contain member service 211 classes with similar traffic characteristic and performance 212 requirements. 214 4. The notion of the individual end-to-end service classes must not 215 be destroyed when aggregation is performed. Each domain along 216 the end-to-end path may perform aggregation differently, based on 217 the original end-to-end service classes. We recommend an easy 218 way to accomplish this by not altering the DSCP used to indicate 219 the end-to-end service class. But some administrative domains 220 may require the use of their own marking; when this is needed, 221 the original end-to-end service class indication must be restored 222 upon exiting such administrative domains. 224 5. Each treatment aggregate has limited resources, hence traffic 225 conditioning and/or admission control should be performed for 226 each service class aggregated into the treatment aggregate. 227 Additional admission control and policing may be used on the sum 228 of all traffic aggregated into the treatment aggregate. 230 with the following suggestions: 232 1. The treatment aggregate and assigned resources may consider 233 historical traffic patterns and the variability of these 234 patterns. For example, a point-point service (e.g., pseudowire) 235 may have a very predictable pattern, while a multipoint service 236 (e.g., VPLS) may have a much less predictable pattern. Even the 237 traffic patterns within the Internet may vary widely. 239 2. In addition to Diffserv, other controls are available to 240 influence the traffic level offered to a particular traffic 241 aggregate. These include adjustment of routing metrics, usage of 242 MPLS-based traffic engineering techniques. 244 This document only describes the aggregation of IP traffic based on 245 the use of Diffserv Service Classes [5]. 247 4. Service Classes to Treatment Aggregate Mapping 249 The service class and DSCP selection in "Diffserv Service Classes" 250 [5] has been defined to allow, in many instances, mapping of two or 251 possibly more service classes into a single forwarding treatment 252 aggregate. Notice that there is a relationship/trade-off between 253 link speed, queue depth, delay, and jitter. The degree of 254 aggregation and hence the number of treatment aggregates will depend 255 on whether the speed of the links and scheduler behavior, being used 256 to implement the aggregation, can minimize the affects of mixing 257 traffic with different packet sizes and transmit rates on queue 258 depth. And their impacts on loss, delay, and jitter. A general 259 rule-of-thumb is that higher link speeds allow for more aggregation/ 260 smaller number of treatment aggregates. Assuming link utilization is 261 within the engineered level. 263 4.1. Mapping Service Classes into Four Treatment Aggregates 265 This section provides an example of mapping all the service classes 266 defined in RFC 4594 [5] into four treatment aggregates. The use of 267 four treatment aggregates assumes that the resources allocated to 268 each treatment aggregate is sufficient to honor the required behavior 269 of each service class [5] in each of the four treatment aggregates. 270 We use the performance requirement (tolerance to loss, delay, and 271 jitter) from the application/end-user as a guide on how to map the 272 service classes into treatment aggregates. We have also used Section 273 3.1 of RFC 1633 [6] to provide us with guidance on the definition of 274 Real-Time and Elastic applications. An overview of the mapping 275 between service classes and the four treatment aggregates is provided 276 by Figure 1, with the mapping being based on performance 277 requirements. In Figure 1, the right side columns of "Service 278 Class", "Tolerance to Loss/Delay/Jitter" are from Figure 2 of 279 Diffserv Service Classes [5]. 281 It is recommended that certain service classes be mapped into 282 specific treatment aggregates. But this does not mean that all the 283 service classes recommended for that treatment aggregate need to be 284 supported. Hence, for a given domain, a treatment aggregate may 285 contain only a subset of the service classes recommended in this 286 document, they being the service classes supported by that domain. A 287 domain's treatment of non-supported service classes should be based 288 on the domain's local policy. This local policy may be influenced by 289 its agreement with its customers. Such treatment may use the Elastic 290 Treatment Aggregate, dropping the packets, or some other 291 arrangements. 293 Our example of four treatment aggregates is based on the basic 294 differences in performance requirement from the application/end-user 295 perspective. A domain may choose to support more or less treatment 296 aggregates. For example, only supporting three treatment aggregates, 297 and with mapping any network control traffic into the Assured Elastic 298 treatment aggregate. This is a choice the administrative domain has. 299 Hence this example of four treatment aggregates does not represent a 300 minimum required set of treatment aggregates one must implement; nor 301 does it represent the maximum set of treatment aggregates one can 302 implement. 304 --------------------------------------------------------------------- 305 |Treatment | Tolerance to ||Service Class | Tolerance to | 306 |Aggregate | Loss |Delay |Jitter|| | Loss |Delay |Jitter| 307 |==========+======+======+======++===============+======+======+======| 308 | Network | Low | Low | Yes || Network | Low | Low | Yes | 309 | Control | | | || Control | | | | 310 |==========+======+======+======++===============+======+======+======| 311 | Real | Very | Very | Very || Telephony | VLow | VLow | VLow | 312 | Time | Low | Low | Low ||---------------+------+------+------| 313 | | | | || Signaling | Low | Low | Yes | 314 | | | | ||---------------+------+------+------| 315 | | | | || Multimedia |Low - | Very | Low | 316 | | | | || Conferencing |Medium| Low | | 317 | | | | ||---------------+------+------+------| 318 | | | | || Real-time | Low | Very | Low | 319 | | | | || Interactive | | Low | | 320 | | | | ||---------------+------+------+------| 321 | | | | || Broadcast | Very |Medium| Low | 322 | | | | || Video | Low | | | 323 |==========+======+======+======++===============+======+======+======| 324 | Assured | Low |Low - | Yes || Multimedia |Low - |Medium| Yes | 325 | Elastic | |Medium| || Streaming |Medium| | | 326 | | | | ||---------------+------+------+------| 327 | | | | || Low Latency | Low |Low - | Yes | 328 | | | | || Data | |Medium| | 329 | | | | ||---------------+------+------+------| 330 | | | | || OAM | Low |Medium| Yes | 331 | | | | ||---------------+------+------+------| 332 | | | | ||High Throughput| Low |Medium| Yes | 333 | | | | || Data | |- High| | 334 |==========+======+======+======++===============+======+======+======| 335 | Elastic | Not Specified || Standard | Not Specified | 336 | | | | ||---------------+------+------+------| 337 | | | | || Low Priority | High | High | Yes | 338 | | | | || Data | | | | 339 --------------------------------------------------------------------- 341 Figure 1: Treatment Aggregate and Service Class Performance 342 Requirements 344 As we are recommending to preserve the notion of the individual end- 345 to-end service classes, we also recommend that the original DSCP 346 field marking not be changed when treatment aggregates are used. 347 Instead, classifiers that select packets based on the contents of the 348 DSCP field should be used to direct packets from the member DiffServ 349 Service Classes into the queue that handles each of the treatment 350 aggregates, without remarking the DSCP field of the packets. This is 351 summarized in Figure 2, which shows the behavior each Treatment 352 Aggregate should have, and the DSCP field marking of the packets that 353 should be classified into each of the treatment aggregates. 355 ------------------------------------------------------------ 356 |Treatment |Treatment || DSCP | 357 |Aggregate |Aggregate || | 358 | |Behavior || | 359 |==========+==========++=====================================| 360 | Network | CS || CS6 | 361 | Control |(RFC 2474)|| | 362 |==========+==========++=====================================| 363 | Real | EF || EF, CS5, AF41, AF42, AF43, CS4, CS3 | 364 | Time |(RFC 3246)|| | 365 |==========+==========++=====================================| 366 | Assured | AF || CS2, AF31, AF21, AF11 | 367 | Elastic |(RFC 2597)||-------------------------------------| 368 | | || AF32, AF22, AF12 | 369 | | ||-------------------------------------| 370 | | || AF33, AF23, AF13 | 371 |==========+==========++=====================================| 372 | Elastic | Default || Default, (CS0) | 373 | |(RFC 2474)||-------------------------------------| 374 | | || CS1 | 375 ------------------------------------------------------------ 377 Figure 2: Treatment Aggregate Behavior 379 4.1.1. Network Control Treatment Aggregate 381 The Network Control Treatment Aggregate aggregates all service 382 classes that are functionally necessary for the survival of a network 383 during a DOS attack or other high traffic load interval. The theory 384 is that whatever else is true, the network must protect itself. This 385 includes the traffic that "Diffserv Service Classes" [5] 386 characterizes as being included in the Network Control Service Class. 388 The DSCPs of the original service class remain an important 389 consideration and should be preserved during aggregation. Traffic in 390 the Network Control treatment aggregate should be carried in a common 391 queue or class with a PHB as described in RFC 2474 [4] section 392 4.2.2.2. This treatment aggregate should have a lower probability of 393 packet loss, bearing a relatively deep target mean queue depth (min- 394 threshold if RED is being used). 396 Please notice this Network Control Treatment Aggregate is meant to be 397 used for the customer's network control traffic. The provider may 398 choose to treat its own network control traffic differently, perhaps 399 in its own service class that is not aggregated with the customer's 400 network control traffic. 402 4.1.2. Real Time Treatment Aggregate 404 The Real Time Treatment Aggregate aggregates all real-time 405 (inelastic) service classes. The theory is that real-time traffic is 406 admitted under some model and controlled by a SLA managed at the edge 407 of the network prior to aggregation. As such, there is a predictable 408 and enforceable upper bound on the traffic that can enter such a 409 queue, and to provide predictable variation in delay it must be 410 protected from bursts of elastic traffic. The predictability of 411 traffic level may be based upon admission control for a well known 412 community of interest (e.g., a point-point service) and/or based upon 413 historical measurements. 415 This treatment aggregate may include the following service classes 416 from the Diffserv Service Classes [5], in addition to other locally 417 defined classes: Telephony, Signaling, Multimedia Conferencing, Real- 418 time Interactive, Broadcast Video. 420 Traffic in each service class that is going to be aggregated into the 421 treatment aggregate should be conditioned prior to aggregation. It 422 is recommended that per service class admission control procedures be 423 used followed by per service class policing so that any individual 424 service class does not generate more than what it is allowed. 425 Furthermore, additional admission control and policing may be used on 426 the sum of all traffic aggregated into this treatment aggregate. 428 The DSCPs of the original service classes remain an important 429 consideration and should be preserved during aggregation. Traffic 430 bearing these DSCPs is carried in a common queue or class with a PHB 431 as described in RFC 3246 [11] and RFC 3247 [12]. 433 4.1.3. Assured Elastic Treatment Aggregate 435 The Assured Elastic Treatment Aggregate aggregates all elastic 436 traffic that uses the Assured Forwarding model as described in RFC 437 2597 [10]. The premise of such a service is that a SLA is negotiated 438 which includes a "committed rate" and the ability to exceed that rate 439 (and perhaps a second "excess rate") in exchange for a higher 440 probability of loss using AQM [9] or ECN flagging [13] for the 441 portion of traffic deemed to be in excess. 443 This treatment aggregate may include the following service classes 444 from the Diffserv Service Classes [5], in addition to other locally 445 defined classes: Multimedia Streaming, Low Latency Data, OAM, High 446 Throughput Data. 448 The DSCP values belonging to the AF PHB group and class selector of 449 the original service classes remain an important consideration and 450 should be preserved during aggregation. This treatment aggregate 451 should maintain the AF PHB group marking of the original packet. For 452 example, AF3x marked packets should remain AF3x marked within this 453 treatment aggregate. In addition, the class selector DSCP value 454 should not be changed. Traffic bearing these DSCPs is carried in a 455 common queue or class with a PHB as described in RFC 2597 [10]. In 456 effect, appropriate target rate thresholds have been applied at the 457 edge, dividing traffic into AFn1 (committed, for any value of n), 458 AFn2, and AFn3 (excess). The service should be engineered so that 459 AFn1 and CS2 marked packet flows have sufficient bandwidth in the 460 network to provide high assurance of delivery. Since the traffic is 461 elastic and responds dynamically to packet loss, Active Queue 462 Management [9] should be used primarily to reduce the forwarding rate 463 to the minimum assured rate at congestion points. The probability of 464 loss of AFn1 and CS2 traffic must not exceed the probability of loss 465 of AFn2 traffic, which in turn must not exceed the probability of 466 loss of AFn3 traffic. 468 If RED [9] is used as an AQM algorithm, the min-threshold specifies a 469 target queue depth for each of AFn1+CS2, AFn2, AFn3, and the max- 470 threshold specifies the queue depth above which all traffic with such 471 a DSCP is dropped or ECN marked. Thus, in this Treatment Aggregate, 472 the following inequalities should hold in queue configurations: 474 o min-threshold AFn3 < max-threshold AFn3 476 o max-threshold AFn3 <= min-threshold AFn2 478 o min-threshold AFn2 < max-threshold AFn2 480 o max-threshold AFn2 <= min-threshold AFn1+CS2 482 o min-threshold AFn1+CS2 < max-threshold AFn1+CS2 484 o max-threshold AFn1+CS2 <= memory assigned to the queue 486 Note: This configuration tends to drop AFn3 traffic before AFn2 and 487 AFn2 before AFn1 and CS2. Many other AQM algorithms exist and are 488 used; they should be configured to achieve a similar result. 490 4.1.4. Elastic Treatment Aggregate 492 The Elastic Treatment Aggregate aggregates all remaining elastic 493 traffic. The premise of such a service is that there is no intrinsic 494 SLA differentiation of traffic, but that AQM [9] or ECN flagging [13] 495 is appropriate for such traffic. 497 This treatment aggregate may include the following service classes 498 from the Diffserv Service Classes [5], in addition to other locally 499 defined classes: Standard, Low Priority Data. 501 Treatment aggregates should be well specified, each indicating the 502 service classes it will handle. But in cases where unspecified or 503 unknown service classes are encountered, they may be dropped or be 504 treated using the Elastic Treatment Aggregate. The choice of how to 505 treat unspecified service classes should be well defined, based on 506 some agreements. 508 The DSCPs of the original service classes remain an important 509 consideration and should be preserved during aggregation. Traffic 510 bearing these DSCPs is carried in a common queue or class with a PHB 511 as described in RFC 2474 [4] section 4.1: A Default PHB. The AQM 512 thresholds for Elastic traffic MAY be separately set, so that Low 513 Priority Data traffic is dropped before Standard traffic, but this is 514 not a requirement. 516 5. Treatment Aggregates and Inter-Provider Relationships 518 When Treatment Aggregates are used at provider boundaries, we 519 recommend that the Inter-Provider Relationship be based on Diffserv 520 Service Classes [5]. This allows the admission control into each 521 Treatment Aggregate of a provider domain to be based on the admission 522 control of traffic into the supported Service Classes, as indicated 523 by the discussion in section 4 of this document. 525 If the Inter-Provider Relationship needs to be based on Treatment 526 Aggregates specified by this document, then the exact Treatment 527 Aggregate content and representation must be agreed to by the peering 528 providers. 530 Some additional work on Inter-Provider Relationships is provided by 531 Inter-provider QoS [17], where details on supporting realtime 532 services between service providers are discussed. Some related work 533 in ITU-T provided by Appendix VI of Y.1541 [18] may also help with 534 inter-provider relationships, especially with international 535 providers. 537 6. Security Considerations 539 This document discusses the policy of using Differentiated Services 540 and its service classes. If implemented as described, it should 541 require that the network do nothing that the network has not already 542 allowed. If that is the case, no new security issues should arise 543 from the use of such a policy. 545 It is possible for the policy to be applied incorrectly, or for a 546 wrong policy to be applied in the network for the defined 547 aggregation. In that case, a policy issue exists that the network 548 must detect, assess, and deal with. This is a known security issue 549 in any network dependent on policy-directed behavior. 551 A well known flaw appears when bandwidth is reserved or enabled for a 552 service (for example, voice transport) and another service or an 553 attacking traffic stream uses it. This possibility is inherent in 554 DiffServ technology, which depends on appropriate packet markings. 555 When bandwidth reservation or a priority queuing system is used in a 556 vulnerable network, the use of authentication and flow admission is 557 recommended. To the best of the authors' knowledge, there is no 558 known technical way to respond to or act upon a data stream that has 559 been admitted for service but that it is not intended for 560 authenticated use. 562 7. IANA Considerations 564 This document does not request any IANA considerations. 566 8. Acknowledgements 568 This document has benefited from discussions with numerous people, 569 especially Shane Amante, Brian Carpenter, and Dave McDysan. It has 570 also benefited from detailed reviews by David Black, Marvin Krym, 571 Bruce Davies, Fil Dickinson, and Julie Ann Connary. 573 Appendix A. Using MPLS for Treatment Aggregates 575 RFC 2983 on DiffServ and Tunnels [7] and RFC 3270 on MPLS Support of 576 DiffServ [8] provide a very good background on this topic. This 577 document provides an example of using the E-LSP, EXP Inferred PHB 578 Scheduled Class (PSC) Label Switched Path (LSP), defined by MPLS 579 Support of DiffServ [8] for realizing the Treatment Aggregates. 581 When Treatment Aggregates are represented in MPLS using EXP Inferred 582 PSC LSP, we recommend the following usage of the MPLS EXP field for 583 Treatment Aggregates. 585 ------------------------------------------- 586 |Treatment || MPLS || DSCP | DSCP | 587 |Aggregate || EXP || name | value | 588 |==========++======++=========|=============| 589 | Network || 110 || CS6 | 110000 | 590 | Control || || | | 591 |==========++======++=========|=============| 592 | Real || 100 || EF | 101110 | 593 | Time || ||---------|-------------| 594 | || || CS5 | 101000 | 595 | || ||---------|-------------| 596 | || ||AF41,AF42|100010,100100| 597 | || || AF43 | 100110 | 598 | || ||---------|-------------| 599 | || || CS4 | 100000 | 600 | || ||---------|-------------| 601 | || || CS3 | 011000 | 602 |==========++======++=========|=============| 603 | Assured || 010* || CS2 | 010000 | 604 | Elastic || || AF31 | 011010 | 605 | || || AF21 | 010010 | 606 | || || AF11 | 001010 | 607 | ||------||---------|-------------| 608 | || 011* || AF32 | 011100 | 609 | || || AF22 | 010100 | 610 | || || AF12 | 001100 | 611 | || || AF33 | 011110 | 612 | || || AF23 | 010110 | 613 | || || AF13 | 001110 | 614 |==========++======++=========|=============| 615 | Elastic || 000* || Default | 000000 | 616 | || || (CS0) | | 617 | ||------||---------|-------------| 618 | || 001* || CS1 | 001000 | 619 ------------------------------------------- 621 Figure 3: Treatment Aggregate and MPLS EXP Field Usage 623 Notes *: For Assured Elastic (and Elastic) Treatment Aggregate, the 624 usage of 010 or 011 (000 or 001) as EXP field value depends on the 625 drop probability. Packets in the LSP with EXP field of 011 (001) 626 have a higher probability of being dropped than packets with an EXP 627 field of 010 (000). 629 The above table indicates the recommended usage of EXP fields for 630 Treatment Aggregates. Because many deployments of MPLS are on a per 631 domain basis, each domain has total control of its EXP usage and each 632 domain may use a different EXP field allocation for the domain's 633 supported Treatment Aggregates. 635 Appendix A.1. Network Control Treatment Aggregate with E-LSP 637 The usage of E-LSP for Network Control Treatment Aggregate needs to 638 adhere to the recommendations indicated in section 4.1.1 of this 639 document and section 3.2 of "Diffserv Service Classes" [5]. 640 Reinforcing these recommendations, there should be no drop precedence 641 associated with the MPLS PSC used for Network Control Treatment 642 Aggregate because dropping of Network Control Treatment Aggregate 643 traffic should be prevented. 645 Appendix A.2. Real Time Treatment Aggregate with E-LSP 647 In addition to the recommendations provided in section 4.1.2 of this 648 document and in member service classes' sections of "Diffserv Service 649 Classes" [5], we want to indicate that Real Time Treatment Aggregate 650 traffic should not be dropped, as some of the applications whose 651 traffic is carried in the Real Time Treatment Aggregate do not react 652 well to dropped packets. As indicated in section 4.1.2 of this 653 document, admission control should be performed on each Service Class 654 contributing to the Real Time Treatment Aggregate to prevent packet 655 loss due to insufficient resources allocated to Real Time Treatment 656 Aggregate. Further, admission control and policing may also be 657 applied on the sum of all traffic aggregated into this treatment 658 aggregate. 660 Appendix A.3. Assured Elastic Treatment Aggregate with E-LSP 662 EXP field markings of 010 and 011 are used for the Assured Elastic 663 Treatment Aggregate. The two encodings are used to provide two 664 levels of drop precedence indications, with 010 encoded traffic 665 having a lower probability of being dropped than 011 encoded traffic. 666 This provides for the mapping of CS2, AF31, AF21, and AF11 into EXP 667 010; and AF32, AF22, AF12 and AF33, AF23, AF13 into EXP 011. If the 668 domain chooses to support only one drop precedence for this treatment 669 aggregate, we recommend the use of 010 for EXP field marking. 671 Appendix A.4. Elastic Treatment Aggregate with E-LSP 673 EXP field markings of 000 and 001 are used for the Elastic Treatment 674 Aggregate. The two encodings are used to provide two levels of drop 675 precedence indications, with 000 encoded traffic having a lower 676 probability of being dropped than 001 encoded traffic. This provides 677 for the mapping of Default/CS0 into 000; and CS1 into 001. Notice 678 that with this mapping, during congestion, CS1 marked traffic may be 679 starved. If the domain chooses to support only one drop precedence 680 for this treatment aggregate, we recommend the use of 000 for EXP 681 field marking. 683 Appendix A.5. Treatment Aggregates and L-LSP 685 Because L-LSP (Label Only Inferred PSC LSP) supports a single PSC per 686 LSP, the support of each Treatment Aggregate is on a per LSP basis. 687 This document does not further specify any additional recommendation 688 (beyond what has been indicated in section 4 of this document) for 689 Treatment Aggregate to L-LSP mapping, leaving this to each individual 690 MPLS domain administrations. 692 9. References 694 9.1. Normative References 696 [1] Postel, J., "Internet Protocol", STD 5, RFC 791, 697 September 1981. 699 [2] Bradner, S., "The Internet Standards Process -- Revision 3", 700 BCP 9, RFC 2026, October 1996. 702 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 703 Levels", BCP 14, RFC 2119, March 1997. 705 [4] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of 706 the Differentiated Services Field (DS Field) in the IPv4 and 707 IPv6 Headers", RFC 2474, December 1998. 709 [5] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines 710 for DiffServ Service Classes", RFC 4594, August 2006. 712 [6] Braden, B., Clark, D., and S. Shenker, "Integrated Services in 713 the Internet Architecture: an Overview", RFC 1633, June 1994. 715 [7] Black, D., "Differentiated Services and Tunnels", RFC 2983, 716 October 2000. 718 [8] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., 719 Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol 720 Label Switching (MPLS) Support of Differentiated Services", 721 RFC 3270, May 2002. 723 [9] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., 724 Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, 725 C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, 726 J., and L. Zhang, "Recommendations on Queue Management and 727 Congestion Avoidance in the Internet", RFC 2309, April 1998. 729 [10] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured 730 Forwarding PHB Group", RFC 2597, June 1999. 732 [11] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., 733 Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An 734 Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, 735 March 2002. 737 [12] Charny, A., Bennet, J., Benson, K., Boudec, J., Chiu, A., 738 Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., and K. 739 Ramakrishnan, "Supplemental Information for the New Definition 740 of the EF PHB (Expedited Forwarding Per-Hop Behavior)", 741 RFC 3247, March 2002. 743 [13] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of 744 Explicit Congestion Notification (ECN) to IP", RFC 3168, 745 September 2001. 747 9.2. Informative References 749 [14] Choi, B., Moon, S., Zhang, Z., Papagiannaki, K., and C. Diot, 750 "Analysis of Point-To-Point Packet Delay in an Operational 751 Network", INFOCOMM 2004, March 2004, 752 . 754 [15] Ogielski, A. and J. Cowie, "Internet Routing Behavior on 9/11", 755 March 2002, . 758 [16] Nichols, K. and B. Carpenter, "Definition of Differentiated 759 Services Per Domain Behaviors and Rules for their 760 Specification", RFC 3086, April 2001. 762 [17] MIT Communications Futures Program, "Inter-provider Quality of 763 Service", November 2006, < 764 http://cfp.mit.edu/resources/papers/Interprovider QoS 765 MIT_CFP_WP_9_14_06.pdf>. 767 [18] International Telecommunications Union, "Network performance 768 objectives for IP-based services", February 2006. 770 Authors' Addresses 772 Kwok Ho Chan 773 Nortel 774 600 Technology Park Drive 775 Billerica, MA 01821 776 US 778 Phone: +1-978-288-8175 779 Fax: +1-978-288-8700 780 Email: khchan@nortel.com 782 Jozef Z. Babiarz 783 Nortel 784 3500 Carling Avenue 785 Ottawa, Ont. K2H 8E9 786 Canada 788 Phone: +1-613-763-6098 789 Fax: +1-613-768-2231 790 Email: babiarz@nortel.com 792 Fred Baker 793 Cisco Systems 794 1121 Via Del Rey 795 Santa Barbara, CA 93117 796 US 798 Phone: +1-408-526-4257 799 Fax: +1-413-473-2403 800 Email: fred@cisco.com 802 Full Copyright Statement 804 Copyright (C) The IETF Trust (2007). 806 This document is subject to the rights, licenses and restrictions 807 contained in BCP 78, and except as set forth therein, the authors 808 retain all their rights. 810 This document and the information contained herein are provided on an 811 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 812 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 813 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 814 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 815 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 816 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 818 Intellectual Property 820 The IETF takes no position regarding the validity or scope of any 821 Intellectual Property Rights or other rights that might be claimed to 822 pertain to the implementation or use of the technology described in 823 this document or the extent to which any license under such rights 824 might or might not be available; nor does it represent that it has 825 made any independent effort to identify any such rights. Information 826 on the procedures with respect to rights in RFC documents can be 827 found in BCP 78 and BCP 79. 829 Copies of IPR disclosures made to the IETF Secretariat and any 830 assurances of licenses to be made available, or the result of an 831 attempt made to obtain a general license or permission for the use of 832 such proprietary rights by implementers or users of this 833 specification can be obtained from the IETF on-line IPR repository at 834 http://www.ietf.org/ipr. 836 The IETF invites any interested party to bring to its attention any 837 copyrights, patents or patent applications, or other proprietary 838 rights that may cover technology that may be required to implement 839 this standard. Please address the information to the IETF at 840 ietf-ipr@ietf.org. 842 Acknowledgment 844 Funding for the RFC Editor function is provided by the IETF 845 Administrative Support Activity (IASA).