idnits 2.17.1 draft-ietf-tsvwg-diffserv-class-aggr-07.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 811. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 822. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 829. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 835. 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 : ---------------------------------------------------------------------------- No issues found here. 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 (November 6, 2007) is 5978 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2309 (ref. '7') (Obsoleted by RFC 7567) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 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: May 9, 2008 F. Baker 6 Cisco Systems 7 November 6, 2007 9 Aggregation of DiffServ Service Classes 10 draft-ietf-tsvwg-diffserv-class-aggr-07 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 May 9, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 In the core of a high capacity network, service differentiation may 44 still be 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. However, some 48 network segments may be configured in such a way that a single 49 forwarding treatment may satisfy the traffic characteristics and 50 performance requirements of two or more service classes. In these 51 cases, it may be desirable to aggregate two or more diffserv service 52 classes into a single forwarding treatment. This document provides 53 guidelines for the aggregation of diffserv service classes into 54 forwarding treatments. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Overview of Service Class Aggregation . . . . . . . . . . . . 5 62 4. Service Classes to Treatment Aggregate Mapping . . . . . . . . 6 63 4.1. Mapping Service Classes into Four Treatment Aggregates . . 7 64 4.1.1. Network Control Treatment Aggregate . . . . . . . . . 9 65 4.1.2. Real Time Treatment Aggregate . . . . . . . . . . . . 10 66 4.1.3. Assured Elastic Treatment Aggregate . . . . . . . . . 10 67 4.1.4. Elastic Treatment Aggregate . . . . . . . . . . . . . 12 68 5. Treatment Aggregates and Inter-Provider Relationships . . . . 12 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 72 Appendix A. Using MPLS for Treatment Aggregates . . . . . . . . 13 73 Appendix A.1. Network Control Treatment Aggregate with E-LSP . . . 15 74 Appendix A.2. Real Time Treatment Aggregate with E-LSP . . . . . . 15 75 Appendix A.3. Assured Elastic Treatment Aggregate with E-LSP . . . 15 76 Appendix A.4. Elastic Treatment Aggregate with E-LSP . . . . . . . 15 77 Appendix A.5. Treatment Aggregates and L-LSP . . . . . . . . . . . 16 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 80 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 82 Intellectual Property and Copyright Statements . . . . . . . . . . 19 84 1. Introduction 86 In the core of a high capacity network, it is common for the network 87 to be engineered in such a way that a major link, switch, or router 88 can fail and the result will be a routed network that still meets 89 ambient SLAs (Service Level Agreements). The implication of this is 90 that there is sufficient capacity on any given link such that all 91 SLAs sold can be simultaneously supported at their respective maximum 92 rates, and that this remains true after re-routing (either IP re- 93 routing or MPLS (Multi Protocol Label Switching) protection-mode 94 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 may still have issues. Delay, 101 jitter, and occasional loss are perfectly acceptable for elastic 102 applications. However, sub-second surges that occur in the best- 103 designed of networks [12] affect real-time applications. Moreover, 104 DOS loads, worms, and network disruptions such as that of 11 105 September 2001 affect routing [13]. 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" [3] defines a set of 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 application payload's tolerance to 114 packet loss, delay, and delay variation (jitter). Different degrees 115 of these criteria form the foundation for supporting the needs of 116 real-time and elastic traffic. The "Diffserv Service Classes" [3] 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 Having the IP traffic belonging to service classes, expressed using 126 the DSCP (DiffServ Code Point), as described by "Diffserv Service 127 Classes" [3]. Note that in a given domain, we may recommend that the 128 supported service classes be aggregated into forwarding treatment 129 aggregates; however, this does not mean all service classes need to 130 be supported and hence not all forwarding treatment aggregates need 131 to be supported. A domain may support fewer or greater number of 132 forwarding treatment aggregates. Which service classes and which 133 forwarding treatment aggregates are supported by a domain is up to 134 the domain administration and may be influenced by business reasons 135 or other reasons (e.g. operational considerations). 137 In this document, we've provided: 139 o definitions for terminology we use in this document, 141 o requirements for performing this aggregation, 143 o an example of performing the aggregation when four treatment 144 aggregates are used, 146 o an example (in the appendix) of performing this aggregation over 147 MPLS using E-LSP, EXP Inferred PHB Scheduling Class (PSC) Label 148 Switched Path (LSP). 150 The treatment aggregate recommendations are designed to aggregate the 151 service classes [3] in such a manner as to protect real-time traffic 152 and routing, on the assumption that real-time sessions are protected 153 from each other by admission at the edge. The recommendation given 154 is one possible way of performing the aggregation, there may be other 155 way of aggregation, for example into fewer treatment aggregates or 156 more treatment aggregates. 158 In the appendix, an example of aggregation over MPLS networks using 159 E-LSP to realize the treatment aggregates is provided. Note that the 160 MPLS E-LSP is just an example; this document does not exclude the use 161 of other methods. This example only considers aggregation of IP 162 traffic into E-LSP. The use of E-LSP by none-IP traffic is not 163 discussed. 165 1.1. Requirements Notation 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 169 document are to be interpreted as described in RFC 2119 [1]. 171 2. Terminology 173 This document assumes the reader is familiar with the terms used in 174 differentiated services. This document provides the definitions for 175 new terms introduced by this document and references information 176 defined in RFCs for existing terms not commonly used in 177 differentiated services. 179 For new terms introduced by this document, we provide the definition 180 here: 182 o Treatment Aggregate. This term is defined as the aggregate of 183 DiffServ service classes [3]. A Treatment Aggregate is concerned 184 only with the forwarding treatment of the aggregated traffic, 185 which may be marked with multiple DSCPs. A Treatment Aggregate 186 differs from Behavior Aggregate [2] and Traffic Aggregate [14], 187 each of which indicate the aggregated traffic having a single 188 diffserv codepoint and utilizing a single PHB. 190 For terms from existing RFCs, we provide the reference to the 191 appropriate section of the relevant RFC that contain the definition: 193 o Real-Time and Elastic Applications and their traffic. Section 3.1 194 of RFC 1633 [4]. 196 o Diffserv Service Class. Section 1.3 of RFC 4594 [3]. 198 o MPLS E-LSP, EXP Inferred PHB Scheduling Class (PSC) Label Switched 199 Path (LSP). Section 1.2 of RFC 3270 [6]. 201 o MPLS L-LSP, Label Only Inferred PHB Scheduling Class (PSC) Label 202 Switched Path (LSP). Section 1.3 of RFC 3270 [6]. 204 3. Overview of Service Class Aggregation 206 In diffserv domains where less fine-grained traffic treatment 207 differentiation is provided, aggregation of the different service 208 classes [3] may be required. 210 These aggregations have the following requirements: 212 1. The end-to-end network performance characteristic required by the 213 application MUST be supported. This performance characteristic 214 is represented by the use of Diffserv Service Classes [3]. 216 2. The treatment aggregate MUST meet the strictest requirements of 217 its member service classes. 219 3. The treatment aggregate SHOULD only contain member service 220 classes with similar traffic characteristic and performance 221 requirements. 223 4. The notion of the individual end-to-end service classes MUST NOT 224 be destroyed when aggregation is performed. Each domain along 225 the end-to-end path may perform aggregation differently, based on 226 the original end-to-end service classes. We recommend an easy 227 way to accomplish this by not altering the DSCP used to indicate 228 the end-to-end service class. But some administrative domains 229 may require the use of their own marking; when this is needed, 230 the original end-to-end service class indication must be restored 231 upon exiting such administrative domains. One possible way of 232 achieving this is with the use of tunnels to encapsulate the end- 233 to-end traffic. 235 5. Each treatment aggregate has limited resources, hence traffic 236 conditioning and/or admission control SHOULD be performed for 237 each service class aggregated into the treatment aggregate. 238 Additional admission control and policing may be used on the sum 239 of all traffic aggregated into the treatment aggregate. 241 In addition to the above requirements, we have the following 242 suggestions: 244 1. The treatment aggregate and assigned resources may consider 245 historical traffic patterns and the variability of these 246 patterns. For example, a point-point service (e.g., pseudowire) 247 may have a very predictable pattern, while a multipoint service 248 (e.g., VPLS, Virtual Private LAN Service) may have a much less 249 predictable pattern. 251 2. In addition to Diffserv, other controls are available to 252 influence the traffic level offered to a particular traffic 253 aggregate. These include adjustment of routing metrics, usage of 254 MPLS-based traffic engineering techniques. 256 This document only describes the aggregation of IP traffic based on 257 the use of Diffserv Service Classes [3]. 259 4. Service Classes to Treatment Aggregate Mapping 261 The service class and DSCP selection in "Diffserv Service Classes" 262 [3] has been defined to allow, in many instances, mapping of two or 263 possibly more service classes into a single forwarding treatment 264 aggregate. Notice that there is a relationship/trade-off between 265 link speed, queue depth, delay, and jitter. The degree of 266 aggregation and hence the number of treatment aggregates will depend 267 on whether the speed of the links and scheduler behavior, being used 268 to implement the aggregation, can minimize the effects of mixing 269 traffic with different packet sizes and transmit rates on queue 270 depth, and their impacts on loss, delay, and jitter. A general rule- 271 of-thumb is that higher link speeds allow for more aggregation/ 272 smaller number of treatment aggregates, assuming link utilization is 273 within the engineered level. 275 4.1. Mapping Service Classes into Four Treatment Aggregates 277 This section provides an example of mapping all the service classes 278 defined in RFC 4594 [3] into four treatment aggregates. The use of 279 four treatment aggregates assumes that the resources allocated to 280 each treatment aggregate are sufficient to honor the required 281 behavior of each service class [3] in each of the four treatment 282 aggregates. We use the performance requirement (tolerance to loss, 283 delay, and jitter) from the application/end-user as a guide on how to 284 map the service classes into treatment aggregates. We have also used 285 Section 3.1 of RFC 1633 [4] to provide us with guidance on the 286 definition of Real-Time and Elastic applications. An overview of the 287 mapping between service classes and the four treatment aggregates is 288 provided by Figure 1, with the mapping being based on performance 289 requirements. In Figure 1, the right side columns of "Service 290 Class", "Tolerance to Loss/Delay/Jitter" are from Figure 2 of 291 Diffserv Service Classes [3]. 293 It is recommended that certain service classes be mapped into 294 specific treatment aggregates. But this does not mean that all the 295 service classes recommended for that treatment aggregate need to be 296 supported. Hence, for a given domain, a treatment aggregate may 297 contain only a subset of the service classes recommended in this 298 document, they being the service classes supported by that domain. A 299 domain's treatment of non-supported service classes should be based 300 on the domain's local policy. This local policy may be influenced by 301 its agreement with its customers. Such treatment may use the Elastic 302 Treatment Aggregate, dropping the packets, or some other 303 arrangements. 305 Our example of four treatment aggregates is based on the basic 306 differences in performance requirement from the application/end-user 307 perspective. A domain may choose to support more or fewer treatment 308 aggregates. For example, only supporting three treatment aggregates, 309 and with mapping any network control traffic into the Assured Elastic 310 treatment aggregate. This is a choice the administrative domain has. 311 Hence this example of four treatment aggregates does not represent a 312 minimum required set of treatment aggregates one must implement; nor 313 does it represent the maximum set of treatment aggregates one can 314 implement. 316 --------------------------------------------------------------------- 317 |Treatment | Tolerance to ||Service Class | Tolerance to | 318 |Aggregate | Loss |Delay |Jitter|| | Loss |Delay |Jitter| 319 |==========+======+======+======++===============+======+======+======| 320 | Network | Low | Low | Yes || Network | Low | Low | Yes | 321 | Control | | | || Control | | | | 322 |==========+======+======+======++===============+======+======+======| 323 | Real | Very | Very | Very || Telephony | VLow | VLow | VLow | 324 | Time | Low | Low | Low ||---------------+------+------+------| 325 | | | | || Signaling | Low | Low | Yes | 326 | | | | ||---------------+------+------+------| 327 | | | | || Multimedia |Low - | Very | Low | 328 | | | | || Conferencing |Medium| Low | | 329 | | | | ||---------------+------+------+------| 330 | | | | || Real-time | Low | Very | Low | 331 | | | | || Interactive | | Low | | 332 | | | | ||---------------+------+------+------| 333 | | | | || Broadcast | Very |Medium| Low | 334 | | | | || Video | Low | | | 335 |==========+======+======+======++===============+======+======+======| 336 | Assured | Low |Low - | Yes || Multimedia |Low - |Medium| Yes | 337 | Elastic | |Medium| || Streaming |Medium| | | 338 | | | | ||---------------+------+------+------| 339 | | | | || Low Latency | Low |Low - | Yes | 340 | | | | || Data | |Medium| | 341 | | | | ||---------------+------+------+------| 342 | | | | || OAM | Low |Medium| Yes | 343 | | | | ||---------------+------+------+------| 344 | | | | ||High Throughput| Low |Medium| Yes | 345 | | | | || Data | |- High| | 346 |==========+======+======+======++===============+======+======+======| 347 | Elastic | Not Specified || Standard | Not Specified | 348 | | | | ||---------------+------+------+------| 349 | | | | || Low Priority | High | High | Yes | 350 | | | | || Data | | | | 351 --------------------------------------------------------------------- 353 Figure 1: Treatment Aggregate and Service Class Performance 354 Requirements 356 As we are recommending to preserve the notion of the individual end- 357 to-end service classes, we also recommend that the original DSCP 358 field marking not be changed when treatment aggregates are used. 359 Instead, classifiers that select packets based on the contents of the 360 DSCP field should be used to direct packets from the member DiffServ 361 Service Classes into the queue that handles each of the treatment 362 aggregates, without remarking the DSCP field of the packets. This is 363 summarized in Figure 2, which shows the behavior each Treatment 364 Aggregate should have, and the DSCP field marking of the packets that 365 should be classified into each of the treatment aggregates. 367 ------------------------------------------------------------ 368 |Treatment |Treatment || DSCP | 369 |Aggregate |Aggregate || | 370 | |Behavior || | 371 |==========+==========++=====================================| 372 | Network | CS || CS6 | 373 | Control |(RFC 2474)|| | 374 |==========+==========++=====================================| 375 | Real | EF || EF, CS5, AF41, AF42, AF43, CS4, CS3 | 376 | Time |(RFC 3246)|| | 377 |==========+==========++=====================================| 378 | Assured | AF || CS2, AF31, AF21, AF11 | 379 | Elastic |(RFC 2597)||-------------------------------------| 380 | | || AF32, AF22, AF12 | 381 | | ||-------------------------------------| 382 | | || AF33, AF23, AF13 | 383 |==========+==========++=====================================| 384 | Elastic | Default || Default, (CS0) | 385 | |(RFC 2474)||-------------------------------------| 386 | | || CS1 | 387 ------------------------------------------------------------ 389 Figure 2: Treatment Aggregate Behavior 391 Notes for Figure 2: For Assured Elastic and Elastic Treatment 392 Aggregates, please see sections 4.1.3 and 4.1.4, respectively, for 393 details on additional priority within the Treatment Aggregate. 395 4.1.1. Network Control Treatment Aggregate 397 The Network Control Treatment Aggregate aggregates all service 398 classes that are functionally necessary for the survival of a network 399 during a DOS attack or other high traffic load interval. The theory 400 is that whatever else is true, the network must protect itself. This 401 includes the traffic that "Diffserv Service Classes" [3] 402 characterizes as being included in the Network Control Service Class. 404 Traffic in the Network Control treatment aggregate should be carried 405 in a common queue or class with a PHB as described in RFC 2474 [2] 406 section 4.2.2.2 for Class Selector (CS). This treatment aggregate 407 should have a lower probability of packet loss, bearing a relatively 408 deep target mean queue depth (min-threshold if RED (Random Early 409 Detection) is being used). 411 Please notice this Network Control Treatment Aggregate is meant to be 412 used for the customer's network control traffic. The provider may 413 choose to treat its own network control traffic differently, perhaps 414 in its own service class that is not aggregated with the customer's 415 network control traffic. 417 4.1.2. Real Time Treatment Aggregate 419 The Real Time Treatment Aggregate aggregates all real-time 420 (inelastic) service classes. The theory is that real-time traffic is 421 admitted under some model and controlled by a SLA managed at the edge 422 of the network prior to aggregation. As such, there is a predictable 423 and enforceable upper bound on the traffic that can enter such a 424 queue, and to provide predictable variation in delay it must be 425 protected from bursts of elastic traffic. The predictability of 426 traffic level may be based upon admission control for a well known 427 community of interest (e.g., a point-point service) and/or based upon 428 historical measurements. 430 This treatment aggregate may include the following service classes 431 from the Diffserv Service Classes [3], in addition to other locally 432 defined classes: Telephony, Signaling, Multimedia Conferencing, Real- 433 time Interactive, Broadcast Video. 435 Traffic in each service class that is going to be aggregated into the 436 treatment aggregate should be conditioned prior to aggregation. It 437 is recommended that per service class admission control procedures be 438 used followed by per service class policing so that any individual 439 service class does not generate more than what it is allowed. 440 Furthermore, additional admission control and policing may be used on 441 the sum of all traffic aggregated into this treatment aggregate. 443 Traffic in the Real Time treatment aggregate should be carried in a 444 common queue or class with a PHB (Per Hop Behavior) as described in 445 RFC 3246 [9] and RFC 3247 [10]. 447 4.1.3. Assured Elastic Treatment Aggregate 449 The Assured Elastic Treatment Aggregate aggregates all elastic 450 traffic that uses the Assured Forwarding model as described in RFC 451 2597 [8]. The premise of such a service is that a SLA is negotiated 452 which includes a "committed rate" and the ability to exceed that rate 453 (and perhaps a second "excess rate") in exchange for a higher 454 probability of loss using Active Queue Management (AQM) [7] or 455 Explicit Congestion Notification (ECN) marking [11] for the portion 456 of traffic deemed to be in excess. 458 This treatment aggregate may include the following service classes 459 from the Diffserv Service Classes [3], in addition to other locally 460 defined classes: Multimedia Streaming, Low Latency Data, OAM, High 461 Throughput Data. 463 The DSCP values belonging to the AF PHB group and class selector of 464 the original service classes remain an important consideration and 465 should be preserved during aggregation. This treatment aggregate 466 should maintain the AF PHB group marking of the original packet. For 467 example, AF3x marked packets should remain AF3x marked within this 468 treatment aggregate. In addition, the class selector DSCP value 469 should not be changed. Traffic bearing these DSCPs is carried in a 470 common queue or class with a PHB as described in RFC 2597 [8]. In 471 effect, appropriate target rate thresholds have been applied at the 472 edge, dividing traffic into AFn1 (committed, for any value of n), 473 AFn2, and AFn3 (excess). The service should be engineered so that 474 AFn1 and CS2 marked packet flows have sufficient bandwidth in the 475 network to provide high assurance of delivery. Since the traffic is 476 elastic and responds dynamically to packet loss, Active Queue 477 Management [7] should be used primarily to reduce the forwarding rate 478 to the minimum assured rate at congestion points. The probability of 479 loss of AFn1 and CS2 traffic must not exceed the probability of loss 480 of AFn2 traffic, which in turn must not exceed the probability of 481 loss of AFn3 traffic. 483 If RED [7] is used as an AQM algorithm, the min-threshold specifies a 484 target queue depth for each of AFn1+CS2, AFn2, AFn3, and the max- 485 threshold specifies the queue depth above which all traffic with such 486 a DSCP is dropped or ECN marked. Thus, in this Treatment Aggregate, 487 the following inequalities SHOULD hold in queue configurations: 489 o min-threshold AFn3 < max-threshold AFn3 491 o max-threshold AFn3 <= min-threshold AFn2 493 o min-threshold AFn2 < max-threshold AFn2 495 o max-threshold AFn2 <= min-threshold AFn1+CS2 497 o min-threshold AFn1+CS2 < max-threshold AFn1+CS2 499 o max-threshold AFn1+CS2 <= memory assigned to the queue 501 Note: This configuration tends to drop AFn3 traffic before AFn2 and 502 AFn2 before AFn1 and CS2. Many other AQM algorithms exist and are 503 used; they should be configured to achieve a similar result. 505 4.1.4. Elastic Treatment Aggregate 507 The Elastic Treatment Aggregate aggregates all remaining elastic 508 traffic. The premise of such a service is that there is no intrinsic 509 SLA differentiation of traffic, but that AQM [7] or ECN flagging [11] 510 is appropriate for such traffic. 512 This treatment aggregate may include the following service classes 513 from the Diffserv Service Classes [3], in addition to other locally 514 defined classes: Standard, Low Priority Data. 516 Treatment aggregates should be well specified, each indicating the 517 service classes it will handle. But in cases where unspecified or 518 unknown service classes are encountered, they may be dropped or be 519 treated using the Elastic Treatment Aggregate. The choice of how to 520 treat unspecified service classes should be well defined, based on 521 some agreements. 523 Traffic in the Elastic treatment aggregate should be carried in a 524 common queue or class with a PHB as described in RFC 2474 [2] section 525 4.1: A Default PHB. The AQM thresholds for Elastic traffic MAY be 526 separately set, so that Low Priority Data traffic is dropped before 527 Standard traffic, but this is not a requirement. 529 5. Treatment Aggregates and Inter-Provider Relationships 531 When Treatment Aggregates are used at provider boundaries, we 532 recommend that the Inter-Provider Relationship be based on Diffserv 533 Service Classes [3]. This allows the admission control into each 534 Treatment Aggregate of a provider domain to be based on the admission 535 control of traffic into the supported Service Classes, as indicated 536 by the discussion in section 4 of this document. 538 If the Inter-Provider Relationship needs to be based on Treatment 539 Aggregates specified by this document, then the exact Treatment 540 Aggregate content and representation must be agreed to by the peering 541 providers. 543 Some additional work on Inter-Provider Relationships is provided by 544 Inter-provider QoS [15], where details on supporting realtime 545 services between service providers are discussed. Some related work 546 in ITU-T provided by Appendix VI of Y.1541 [16] may also help with 547 inter-provider relationships, especially with international 548 providers. 550 6. Security Considerations 552 This document discusses the policy of using Differentiated Services 553 and its service classes. If implemented as described, it should 554 require that the network do nothing that the network has not already 555 allowed. If that is the case, no new security issues should arise 556 from the use of such a policy. 558 As this document is based on Diffserv Service Classes [3], the 559 Security Consideration discussion of no new security issues indicated 560 by Diffserv Service Classes [3] also applies to treatment aggregates 561 of this document. 563 7. IANA Considerations 565 This document does not request any IANA considerations. 567 8. Acknowledgements 569 This document has benefited from discussions with numerous people, 570 especially Shane Amante, Brian Carpenter, and Dave McDysan. It has 571 also benefited from detailed reviews by David Black, Marvin Krym, 572 Bruce Davie, Fil Dickinson, and Julie Ann Connary. 574 Appendix A. Using MPLS for Treatment Aggregates 576 RFC 2983 on DiffServ and Tunnels [5] and RFC 3270 on MPLS Support of 577 DiffServ [6] provide a very good background on this topic. This 578 document provides an example of using the E-LSP, EXP Inferred PHB 579 Scheduled Class (PSC) Label Switched Path (LSP), defined by MPLS 580 Support of DiffServ [6] for realizing the Treatment Aggregates. 582 When Treatment Aggregates are represented in MPLS using EXP Inferred 583 PSC LSP, we recommend the following usage of the MPLS EXP field for 584 Treatment Aggregates. 586 ------------------------------------------- 587 |Treatment || MPLS || DSCP | DSCP | 588 |Aggregate || EXP || name | value | 589 |==========++======++=========|=============| 590 | Network || 110 || CS6 | 110000 | 591 | Control || || | | 592 |==========++======++=========|=============| 593 | Real || 100 || EF | 101110 | 594 | Time || ||---------|-------------| 595 | || || CS5 | 101000 | 596 | || ||---------|-------------| 597 | || ||AF41,AF42|100010,100100| 598 | || || AF43 | 100110 | 599 | || ||---------|-------------| 600 | || || CS4 | 100000 | 601 | || ||---------|-------------| 602 | || || CS3 | 011000 | 603 |==========++======++=========|=============| 604 | Assured || 010* || CS2 | 010000 | 605 | Elastic || || AF31 | 011010 | 606 | || || AF21 | 010010 | 607 | || || AF11 | 001010 | 608 | ||------||---------|-------------| 609 | || 011* || AF32 | 011100 | 610 | || || AF22 | 010100 | 611 | || || AF12 | 001100 | 612 | || || AF33 | 011110 | 613 | || || AF23 | 010110 | 614 | || || AF13 | 001110 | 615 |==========++======++=========|=============| 616 | Elastic || 000* || Default | 000000 | 617 | || || (CS0) | | 618 | ||------||---------|-------------| 619 | || 001* || CS1 | 001000 | 620 ------------------------------------------- 622 Figure 3: Treatment Aggregate and MPLS EXP Field Usage 624 Notes *: For Assured Elastic (and Elastic) Treatment Aggregate, the 625 usage of 010 or 011 (000 or 001) as EXP field value depends on the 626 drop probability. Packets in the LSP with EXP field of 011 (001) 627 have a higher probability of being dropped than packets with an EXP 628 field of 010 (000). 630 The above table indicates the recommended usage of EXP fields for 631 Treatment Aggregates. Because many deployments of MPLS are on a per 632 domain basis, each domain has total control of its EXP usage and each 633 domain may use a different EXP field allocation for the domain's 634 supported Treatment Aggregates. 636 Appendix A.1. Network Control Treatment Aggregate with E-LSP 638 The usage of E-LSP for Network Control Treatment Aggregate needs to 639 adhere to the recommendations indicated in section 4.1.1 of this 640 document and section 3.2 of "Diffserv Service Classes" [3]. 641 Reinforcing these recommendations, there should be no drop precedence 642 associated with the MPLS PSC used for Network Control Treatment 643 Aggregate because dropping of Network Control Treatment Aggregate 644 traffic should be prevented. 646 Appendix A.2. Real Time Treatment Aggregate with E-LSP 648 In addition to the recommendations provided in section 4.1.2 of this 649 document and in member service classes' sections of "Diffserv Service 650 Classes" [3], we want to indicate that Real Time Treatment Aggregate 651 traffic should not be dropped, as some of the applications whose 652 traffic is carried in the Real Time Treatment Aggregate do not react 653 well to dropped packets. As indicated in section 4.1.2 of this 654 document, admission control should be performed on each Service Class 655 contributing to the Real Time Treatment Aggregate to prevent packet 656 loss due to insufficient resources allocated to Real Time Treatment 657 Aggregate. Further, admission control and policing may also be 658 applied on the sum of all traffic aggregated into this treatment 659 aggregate. 661 Appendix A.3. Assured Elastic Treatment Aggregate with E-LSP 663 EXP field markings of 010 and 011 are used for the Assured Elastic 664 Treatment Aggregate. The two encodings are used to provide two 665 levels of drop precedence indications, with 010 encoded traffic 666 having a lower probability of being dropped than 011 encoded traffic. 667 This provides for the mapping of CS2, AF31, AF21, and AF11 into EXP 668 010; and AF32, AF22, AF12 and AF33, AF23, AF13 into EXP 011. If the 669 domain chooses to support only one drop precedence for this treatment 670 aggregate, we recommend the use of 010 for EXP field marking. 672 Appendix A.4. Elastic Treatment Aggregate with E-LSP 674 EXP field markings of 000 and 001 are used for the Elastic Treatment 675 Aggregate. The two encodings are used to provide two levels of drop 676 precedence indications, with 000 encoded traffic having a lower 677 probability of being dropped than 001 encoded traffic. This provides 678 for the mapping of Default/CS0 into 000; and CS1 into 001. Notice 679 that with this mapping, during congestion, CS1 marked traffic may be 680 starved. If the domain chooses to support only one drop precedence 681 for this treatment aggregate, we recommend the use of 000 for EXP 682 field marking. 684 Appendix A.5. Treatment Aggregates and L-LSP 686 Because L-LSP (Label Only Inferred PSC LSP) supports a single PSC per 687 LSP, the support of each Treatment Aggregate is on a per LSP basis. 688 This document does not further specify any additional recommendation 689 (beyond what has been indicated in section 4 of this document) for 690 Treatment Aggregate to L-LSP mapping, leaving this to each individual 691 MPLS domain administrations. 693 9. References 695 9.1. Normative References 697 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 698 Levels", BCP 14, RFC 2119, March 1997. 700 [2] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of 701 the Differentiated Services Field (DS Field) in the IPv4 and 702 IPv6 Headers", RFC 2474, December 1998. 704 [3] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines 705 for DiffServ Service Classes", RFC 4594, August 2006. 707 [4] Braden, B., Clark, D., and S. Shenker, "Integrated Services in 708 the Internet Architecture: an Overview", RFC 1633, June 1994. 710 [5] Black, D., "Differentiated Services and Tunnels", RFC 2983, 711 October 2000. 713 [6] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., 714 Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol 715 Label Switching (MPLS) Support of Differentiated Services", 716 RFC 3270, May 2002. 718 [7] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., 719 Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, 720 C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, 721 J., and L. Zhang, "Recommendations on Queue Management and 722 Congestion Avoidance in the Internet", RFC 2309, April 1998. 724 [8] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured 725 Forwarding PHB Group", RFC 2597, June 1999. 727 [9] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., 728 Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An 729 Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, 730 March 2002. 732 [10] Charny, A., Bennet, J., Benson, K., Boudec, J., Chiu, A., 733 Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., and K. 734 Ramakrishnan, "Supplemental Information for the New Definition 735 of the EF PHB (Expedited Forwarding Per-Hop Behavior)", 736 RFC 3247, March 2002. 738 [11] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of 739 Explicit Congestion Notification (ECN) to IP", RFC 3168, 740 September 2001. 742 9.2. Informative References 744 [12] Choi, B., Moon, S., Zhang, Z., Papagiannaki, K., and C. Diot, 745 "Analysis of Point-To-Point Packet Delay in an Operational 746 Network", INFOCOMM 2004, March 2004, 747 . 749 [13] Ogielski, A. and J. Cowie, "Internet Routing Behavior on 9/11", 750 March 2002, . 753 [14] Nichols, K. and B. Carpenter, "Definition of Differentiated 754 Services Per Domain Behaviors and Rules for their 755 Specification", RFC 3086, April 2001. 757 [15] MIT Communications Futures Program, "Inter-provider Quality of 758 Service", November 2006, < 759 http://cfp.mit.edu/resources/papers/Interprovider QoS 760 MIT_CFP_WP_9_14_06.pdf>. 762 [16] International Telecommunications Union, "Network performance 763 objectives for IP-based services", February 2006. 765 Authors' Addresses 767 Kwok Ho Chan 768 Nortel 769 600 Technology Park Drive 770 Billerica, MA 01821 771 US 773 Phone: +1-978-288-8175 774 Fax: +1-978-288-8700 775 Email: khchan@nortel.com 777 Jozef Z. Babiarz 778 Nortel 779 3500 Carling Avenue 780 Ottawa, Ont. K2H 8E9 781 Canada 783 Phone: +1-613-763-6098 784 Fax: +1-613-768-2231 785 Email: babiarz@nortel.com 787 Fred Baker 788 Cisco Systems 789 1121 Via Del Rey 790 Santa Barbara, CA 93117 791 US 793 Phone: +1-408-526-4257 794 Fax: +1-413-473-2403 795 Email: fred@cisco.com 797 Full Copyright Statement 799 Copyright (C) The IETF Trust (2007). 801 This document is subject to the rights, licenses and restrictions 802 contained in BCP 78, and except as set forth therein, the authors 803 retain all their rights. 805 This document and the information contained herein are provided on an 806 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 807 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 808 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 809 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 810 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 811 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 813 Intellectual Property 815 The IETF takes no position regarding the validity or scope of any 816 Intellectual Property Rights or other rights that might be claimed to 817 pertain to the implementation or use of the technology described in 818 this document or the extent to which any license under such rights 819 might or might not be available; nor does it represent that it has 820 made any independent effort to identify any such rights. Information 821 on the procedures with respect to rights in RFC documents can be 822 found in BCP 78 and BCP 79. 824 Copies of IPR disclosures made to the IETF Secretariat and any 825 assurances of licenses to be made available, or the result of an 826 attempt made to obtain a general license or permission for the use of 827 such proprietary rights by implementers or users of this 828 specification can be obtained from the IETF on-line IPR repository at 829 http://www.ietf.org/ipr. 831 The IETF invites any interested party to bring to its attention any 832 copyrights, patents or patent applications, or other proprietary 833 rights that may cover technology that may be required to implement 834 this standard. Please address the information to the IETF at 835 ietf-ipr@ietf.org. 837 Acknowledgment 839 Funding for the RFC Editor function is provided by the IETF 840 Administrative Support Activity (IASA).