idnits 2.17.1 draft-ietf-tsvwg-diffserv-class-aggr-00.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 on line 739. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 716. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 723. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 729. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 36 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** 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 RFC 3978 Section 5.4 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 (June 16, 2006) is 6524 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 623, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 626, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-ietf-tsvwg-diffserv-service-classes (ref. '5') ** Downref: Normative reference to an Informational RFC: RFC 1633 (ref. '6') ** Downref: Normative reference to an Informational RFC: RFC 2983 (ref. '7') ** Obsolete normative reference: RFC 2309 (ref. '9') (Obsoleted by RFC 7567) ** Downref: Normative reference to an Informational RFC: RFC 3247 (ref. '12') Summary: 10 errors (**), 0 flaws (~~), 5 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 Expires: December 18, 2006 Nortel Networks 5 F. Baker 6 Cisco Systems 7 June 16, 2006 9 Aggregation of DiffServ Service Classes 10 draft-ietf-tsvwg-diffserv-class-aggr-00 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 December 18, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 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 . . . . . . . . 5 64 4.1. Mapping Service Classes into Four Treatment Aggregates . . 6 65 4.1.1. Network Control Treatment Aggregate . . . . . . . . . 8 66 4.1.2. Real Time Treatment Aggregate . . . . . . . . . . . . 8 67 4.1.3. Assured Elastic Treatment Aggregate . . . . . . . . . 9 68 4.1.4. Elastic Treatment Aggregate . . . . . . . . . . . . . 10 69 5. Using MPLS for Treatment Aggregates . . . . . . . . . . . . . 11 70 5.1. Network Control Treatment Aggregate with E-LSP . . . . . . 13 71 5.2. Real Time Treatment Aggregate with E-LSP . . . . . . . . . 13 72 5.3. Assured Elastic Treatment Aggregate with E-LSP . . . . . . 13 73 5.4. Elastic Treatment Aggregate with E-LSP . . . . . . . . . . 13 74 5.5. Treatment Aggregates and L-LSP . . . . . . . . . . . . . . 14 75 6. Treatment Aggregates and Inter-Provider Relationships . . . . 14 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 78 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 79 10. Normative References . . . . . . . . . . . . . . . . . . . . . 15 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 81 Intellectual Property and Copyright Statements . . . . . . . . . . 18 83 1. Introduction 85 In the core of a high capacity network, it is common for the network 86 to be engineered in such a way that a major link, switch, or router 87 can fail and the result will be a routed network that still meets 88 ambient SLAs. The implication of this is that there is sufficient 89 capacity on any given link such that all SLAs sold can be 90 simultaneously supported at their respective maximum rates, and that 91 this remains true after re-routing (either IP re-routing or MPLS 92 protection-mode switching) has occurred. 94 It is frequently argued that such over provisioning meets the 95 requirements of all traffic without further QoS treatment, and from a 96 certain perspective that is true. However, as the process of network 97 convergence continues, certain services still have issues. While 98 delay and jitter are perfectly acceptable for elastic applications, 99 real-time applications are negatively affected, and in extreme cases 100 (such as some reported around the September 2001 attacks on the US 101 East Coast, or under extreme DOS load) such surges could disrupt 102 routing. 104 The document "Diffserv Service Classes" [5] defines the basic 105 diffserv classes from the points of view of the application requiring 106 specific end-to-end behaviors from the network. The service classes 107 are differentiated based on the traffic-payload's tolerance to packet 108 loss, delay, and delay variation (jitter). Different degrees of 109 these criterions form the foundation for supporting the needs of 110 real-time and elastic traffic. The Diffserv Service Classes [5] 111 document also provides recommendations for the treatment method of 112 these service classes. But, at some network segments of the end-to- 113 end path, the number of levels of network treatment differentiation 114 may be less than the number of service classes that the network 115 segment needs to support. In such a situation, that network segment 116 may use the same treatment to support more than one service class. 117 In this document we provide guidelines on how multiple service 118 classes may be aggregated into a forwarding treatment aggregate. 119 Note that in a given domain, we may recommend that the supported 120 service classes be aggregated into forwarding treatment aggregates; 121 however, this does not mean all service classes need to be supported 122 and hence not all forwarding treatment aggregates need to be 123 supported. Which service classes and which forwarding treatment 124 aggregates are supported by a domain is up to the domain 125 administration and may be influenced by business reasons. 127 In this document, we've provided: 129 o definitions for terminology we use in this document, 130 o requirements for performing this aggregation, 132 o an example of performing this aggregation over MPLS using E-LSP. 134 The treatment aggregate recommendations are designed to aggregate the 135 service classes [5] in such a manner as to protect real-time traffic 136 and routing, on the assumption that real-time sessions are protected 137 from each other by admission at the edge. 139 An example of aggregation over MPLS networks using E-LSP, EXP 140 Inferred PHB Scheduling Class (PSC) Label Switched Path (LSP), to 141 realize the treatment aggregates is provided. Note that the MPLS 142 E-LSP is just an example; this document does not exclude the use of 143 other methods. 145 1.1. Requirements Notation 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in RFC 2119 [3]. 151 2. Terminology 153 This document assumes the reader is familiar with the terms used in 154 differentiated services. This document provides the definitions for 155 new terms introduced by this document and referencing information for 156 existing none differentiated services terms defined in existing RFCs. 158 For new terms introduced by this document, we provide the definition 159 here: 161 o Treatment Aggregate. This term is used here to indicate the 162 aggregate of DiffServ service classes. This is different from 163 Behavior Aggregate and Traffic Aggregate because Treatment 164 Aggregate is only concerned with the treatment of the aggregated 165 traffic. It does not concern itself with how the aggregated 166 traffic is marked, and hence does not put a restriction on the 167 aggregated traffic having a single diffserv codepoint that have a 168 single PHB. 170 For terms from existing RFCs, we provide the reference to the 171 appropriate section of the relevant RFC that contain the definition: 173 o Real-Time and Elastic Applications and their traffic. Section 3.1 174 of RFC 1633 [6]. 176 o Diffserv Service Class. Section 1.3 of 177 draft-ietf-tsvwg-diffserv-service-classes-02.txt [5]. 179 o MPLS E-LSP, EXP Inferred PHB Scheduling Class (PSC) Label Switched 180 Path (LSP). Section 1.2 of RFC 3270 [8]. 182 o MPLS L-LSP, Label Only Inferred PHB Scheduling Class (PSC) Label 183 Switched Path (LSP). Section 1.3 of RFC 3270 [8]. 185 3. Overview of Service Class Aggregation 187 In diffserv domains where less granular traffic treatment 188 differentiation is provided, aggregation of the different service 189 classes [5] may be required. 191 These aggregations have the following requirements: 193 1. The end-to-end network performance characteristic required by the 194 application must be supported. This performance characteristic 195 is represented by the use of Diffserv Service Classes [5]. 197 2. The treatment aggregate must exhibit the strictest requirement of 198 its member service classes. 200 3. The treatment aggregate should only contain member service 201 classes with similar traffic characteristic and performance 202 requirements. 204 4. The notion of the individual end-to-end service classes must not 205 be destroyed when aggregation is performed. Each domain along 206 the end-to-end path may perform aggregation differently, based on 207 the original end-to-end service classes. We recommend an easy 208 way to accomplish this by not altering the DSCP used to indicate 209 the end-to-end service class. But some administrative domains 210 may require the use of their own marking; when this is needed, 211 the original end-to-end service class indication must be restored 212 upon exiting such administrative domains. 214 5. Each treatment aggregate has limited resources, hence traffic 215 conditioning and/or admission control must be performed for each 216 service class aggregated into the treatment aggregate. 218 4. Service Classes to Treatment Aggregate Mapping 220 The service class and DSCP selection in "Diffserv Service Classes" 221 [5] has been defined to allow, in many instances, mapping of two or 222 possibly more service classes into a single forwarding treatment 223 aggregate. Notice that there is a relationship/trade-off between 224 link speed, queue depth, delay, and jitter. The degree of 225 aggregation and hence the number of treatment aggregates will depend 226 on whether the speed of the links and scheduler behavior, being used 227 to implement the aggregation, can minimize the affects of mixing 228 traffic with different packet sizes and transmit rates on queue 229 depth. And their impacts on loss, delay, and jitter. A general 230 rule-of-thumb is that higher link speeds allow for more aggregation/ 231 smaller number of treatment aggregates. 233 4.1. Mapping Service Classes into Four Treatment Aggregates 235 This section explains one way of performing this aggregation by using 236 four treatment aggregates. The use of four treatment aggregates 237 assumes that the resources allocated to each treatment aggregate is 238 sufficient to honor the required behavior of each service class [5] 239 in each of the four treatment aggregates. We use the performance 240 requirement (tolerance to loss, delay, and jitter) from the 241 application/end-user as a guide on how to map the service classes 242 into treatment aggregates. We have also used Section 3.1 of RFC 1633 243 [6] to provide us with guidance on the definition of Real-Time and 244 Elastic applications. An overview of the mapping between service 245 classes and the four treatment aggregates is provided by Figure 1, 246 with the mapping being based on performance requirements. In Figure 247 1, the right side columns of "Service Class", "Tolerance to Loss/ 248 Delay/Jitter" are from Figure 2 of Diffserv Service Classes [5]. 250 It is recommended that certain service classes be mapped into 251 specific treatment aggregates. But this does not mean that all the 252 service classes recommended for that treatment aggregate need to be 253 supported. Hence, for a given domain, a treatment aggregate may 254 contain only a subset of the service classes recommended in this 255 document, they being the service classes supported by that domain. A 256 domain's treatment of non-supported service classes should be based 257 on the domain's local policy. This local policy may be influenced by 258 its agreement with its customers. Such treatment may use the Elastic 259 Treatment Aggregate, dropping the packets, or some other 260 arrangements. 262 --------------------------------------------------------------------- 263 |Treatment | Tolerance to ||Service Class | Tolerance to | 264 |Aggregate | Loss |Delay |Jitter|| | Loss |Delay |Jitter| 265 |==========+======+======+======++===============+======+======+======| 266 | Network | Low | Low | Yes || Network | Low | Low | Yes | 267 | Control | | | || Control | | | | 268 |==========+======+======+======++===============+======+======+======| 269 | Real | Very | Very | Very || Telephony | VLow | VLow | VLow | 270 | Time | Low | Low | Low ||---------------+------+------+------| 271 | | | | || Signaling | Low | Low | Yes | 272 | | | | ||---------------+------+------+------| 273 | | | | || Multimedia |Low - | Very | Low | 274 | | | | || Conferencing |Medium| Low | | 275 | | | | ||---------------+------+------+------| 276 | | | | || Real-time | Low | Very | Low | 277 | | | | || Interactive | | Low | | 278 | | | | ||---------------+------+------+------| 279 | | | | || Broadcast | Very |Medium| Low | 280 | | | | || Video | Low | | | 281 |==========+======+======+======++===============+======+======+======| 282 | Assured | Low |Low - | Yes || Multimedia |Low - |Medium| Yes | 283 | Elastic | |Medium| || Streaming |Medium| | | 284 | | | | ||---------------+------+------+------| 285 | | | | || Low Latency | Low |Low - | Yes | 286 | | | | || Data | |Medium| | 287 | | | | ||---------------+------+------+------| 288 | | | | || OAM | Low |Medium| Yes | 289 | | | | ||---------------+------+------+------| 290 | | | | ||High Throughput| Low |Medium| Yes | 291 | | | | || Data | |- High| | 292 |==========+======+======+======++===============+======+======+======| 293 | Elastic | Not Specified || Standard | Not Specified | 294 | | | | ||---------------+------+------+------| 295 | | | | || Low Priority | High | High | Yes | 296 | | | | || Data | | | | 297 --------------------------------------------------------------------- 299 Figure 1: Treatment Aggregate and Service Class Performance 300 Requirements 302 As we are recommending to preserve the notion of the individual end- 303 to-end service classes, we also recommend that the original DSCP 304 field marking not be changed when treatment aggregates are used. 305 Instead, classifiers that select packets based on the contents of the 306 DSCP field should be used to direct packets from the member DiffServ 307 Service Classes into the queue that handles each of the treatment 308 aggregates, without remarking the DSCP field of the packets. This is 309 summarized in Figure 2, which shows the behavior each Treatment 310 Aggregate should have, and the DSCP field marking of the packets that 311 should be classified into each of the treatment aggregates. 313 ------------------------------------------------------------ 314 |Treatment |Treatment || DSCP | 315 |Aggregate |Aggregate || | 316 | |Behavior || | 317 |==========+==========++=====================================| 318 | Network | CS || CS6 | 319 | Control |(RFC 2474)|| | 320 |==========+==========++=====================================| 321 | Real | EF || EF, CS5, AF41, AF42, AF43, CS4, CS3 | 322 | Time |(RFC 3246)|| | 323 |==========+==========++=====================================| 324 | Assured | AF || CS2, AF31, AF21, AF11 | 325 | Elastic |(RFC 2597)||-------------------------------------| 326 | | || AF32, AF22, AF12 | 327 | | ||-------------------------------------| 328 | | || AF33, AF23, AF13 | 329 |==========+==========++=====================================| 330 | Elastic | Default || Default, (CS0) | 331 | |(RFC 2474)||-------------------------------------| 332 | | || CS1 | 333 ------------------------------------------------------------ 335 Figure 2: Treatment Aggregate Behavior 337 4.1.1. Network Control Treatment Aggregate 339 The Network Control Treatment Aggregate aggregates all service 340 classes that are functionally necessary for the survival of a network 341 during a DOS attack or other high traffic load interval. The theory 342 is that whatever else is true, the network must protect itself. This 343 includes the traffic that "Diffserv Service Classes" [5] 344 characterizes as being included in the Network Control Service Class. 346 The DSCPs of the original service class remain an important 347 consideration and should be preserved during aggregation. Traffic in 348 the Network Control treatment aggregate should be carried in a common 349 queue or class with a PHB as described in RFC 2474 [4] section 350 4.2.2.2. This treatment aggregate should have a lower probability of 351 packet loss, bearing a relatively deep target mean queue depth (min- 352 threshold if RED is being used). 354 4.1.2. Real Time Treatment Aggregate 356 The Real Time Treatment Aggregate aggregates all real-time 357 (inelastic) service classes. The theory is that real-time traffic is 358 admitted under some model and controlled by a SLA managed at the edge 359 of the network prior to aggregation. As such, there is a predictable 360 and enforceable upper bound on the traffic that can enter such a 361 queue, and to provide predictable variation in delay it must be 362 protected from bursts of elastic traffic. 364 This treatment aggregate may include the following service classes 365 from the Diffserv Service Classes [5], in addition to other locally 366 defined classes: Telephony, Signaling, Multimedia Conferencing, Real- 367 time Interactive, Broadcast Video. 369 Traffic in each service class that is going to be aggregated into the 370 treatment aggregate should be conditioned prior to aggregation. It 371 is recommended that per service class admission control procedures be 372 used followed by per service class policing so that any individual 373 service class does not generate more than what it is allowed. 374 Furthermore, additional admission control and policing may be used on 375 the sum of all service classes aggregated. 377 The DSCPs of the original service classes remain an important 378 consideration and should be preserved during aggregation. Traffic 379 bearing these DSCPs is carried in a common queue or class with a PHB 380 as described in RFC 3246 [11] and RFC 3247 [12]. 382 4.1.3. Assured Elastic Treatment Aggregate 384 The Assured Elastic Treatment Aggregate aggregates all elastic 385 traffic that uses the Assured Forwarding model as described in RFC 386 2597 [10]. The premise of such a service is that a SLA is negotiated 387 which includes a "committed rate" and the ability to exceed that rate 388 (and perhaps a second "excess rate") in exchange for a higher 389 probability of loss using AQM [9] or ECN flagging [13] for the 390 portion of traffic deemed to be in excess. 392 This treatment aggregate may include the following service classes 393 from the Diffserv Service Classes [5], in addition to other locally 394 defined classes: Multimedia Streaming, Low Latency Data, OAM, High 395 Throughput Data. 397 The DSCP values belonging to the AF PHB group of the original service 398 classes remain an important consideration and should be preserved 399 during aggregation. This treatment aggregate should maintain the AF 400 PHB group marking of the original packet. For example, AF3x marked 401 packets should remain AF3x marked within this treatment aggregate. 402 Traffic bearing these DSCPs is carried in a common queue or class 403 with a PHB as described in RFC 2597 [10]. In effect, appropriate 404 target rate thresholds have been applied at the edge, dividing 405 traffic into AFn1 (committed, for any value of n), AFn2, and AFn3 406 (excess). The service should be engineered so that AFn1 marked 407 packet flows have sufficient bandwidth in the network to provide high 408 assurance of delivery. Since the traffic is elastic and responds 409 dynamically to packet loss, Active Queue Management [9] should be 410 used primarily to reduce the forwarding rate to the minimum assured 411 rate at congestion points. The probability of loss of AFn1 traffic 412 must not exceed the probability of loss of AFn2 traffic, which in 413 turn must not exceed the probability of loss of AFn3 traffic. 415 If RED [9] is used as an AQM algorithm, the min-threshold specifies a 416 target queue depth for each of AFn1, AFn2, AFn3, and the max- 417 threshold specifies the queue depth above which all traffic with such 418 a DSCP is dropped or ECN marked. Thus, in this Treatment Aggregate, 419 the following inequalities should hold in queue configurations: 421 o min-threshold AFn3 < max-threshold AFn3 423 o max-threshold AFn3 <= min-threshold AFn2 425 o min-threshold AFn2 < max-threshold AFn2 427 o max-threshold AFn2 <= min-threshold AFn1 429 o min-threshold AFn1 < max-threshold AFn1 431 o max-threshold AFn1 <= memory assigned to the queue 433 Note: This configuration tends to drop AFn3 traffic before AFn2 and 434 AFn2 before AFn1. Many other AQM algorithms exist and are used; they 435 should be configured to achieve a similar result. 437 4.1.4. Elastic Treatment Aggregate 439 The Elastic Treatment Aggregate aggregates all remaining elastic 440 traffic. The premise of such a service is that there is no intrinsic 441 SLA differentiation of traffic, but that AQM [9] or ECN flagging [13] 442 is appropriate for such traffic. 444 This treatment aggregate may include the following service classes 445 from the Diffserv Service Classes [5], in addition to other locally 446 defined classes: Standard, Low Priority Data. 448 The DSCPs of the original service classes remain an important 449 consideration and should be preserved during aggregation. Traffic 450 bearing these DSCPs is carried in a common queue or class with a PHB 451 as described in RFC 2474 [4] section 4.1: A Default PHB. The AQM 452 thresholds for Elastic traffic MAY be separately set, so that Low 453 Priority Data traffic is dropped before Standard traffic, but this is 454 not a requirement. 456 5. Using MPLS for Treatment Aggregates 458 RFC 2983 on DiffServ and Tunnels [7] and RFC 3270 on MPLS Support of 459 DiffServ [8] provide a very good background on this topic. This 460 document provides an example of using the E-LSP, EXP Inferred PHB 461 Scheduled Class (PSC) Label Switched Path (LSP), defined by MPLS 462 Support of DiffServ [8] for realizing the Treatment Aggregates. 464 When Treatment Aggregates are represented in MPLS using EXP Inferred 465 PSC LSP, we recommend the following usage of the MPLS EXP field for 466 Treatment Aggregates. 468 ------------------------------------------- 469 |Treatment || MPLS || DSCP | DSCP | 470 |Aggregate || EXP || name | value | 471 |==========++======++=========|=============| 472 | Network || 110 || CS6 | 110000 | 473 | Control || || | | 474 |==========++======++=========|=============| 475 | Real || 100 || EF | 101110 | 476 | Time || ||---------|-------------| 477 | || || CS5 | 101000 | 478 | || ||---------|-------------| 479 | || ||AF41,AF42|100010,100100| 480 | || || AF43 | 100110 | 481 | || ||---------|-------------| 482 | || || CS4 | 100000 | 483 | || ||---------|-------------| 484 | || || CS3 | 011000 | 485 |==========++======++=========|=============| 486 | Assured || 010* || CS2 | 010000 | 487 | Elastic || || AF31 | 011010 | 488 | || || AF21 | 010010 | 489 | || || AF11 | 001010 | 490 | ||------||---------|-------------| 491 | || 011* || AF32 | 011100 | 492 | || || AF22 | 010100 | 493 | || || AF12 | 001100 | 494 | || || AF33 | 011110 | 495 | || || AF23 | 010110 | 496 | || || AF13 | 001110 | 497 |==========++======++=========|=============| 498 | Elastic || 000* || Default | 000000 | 499 | || || (CS0) | | 500 | ||------||---------|-------------| 501 | || 001* || CS1 | 001000 | 502 ------------------------------------------- 504 Figure 3: Treatment Aggregate and MPLS EXP Field Usage 506 Notes *: For Assured Elastic (and Elastic) Treatment Aggregate, the 507 usage of 010 or 011 (000 or 001) as EXP field value depends on the 508 drop probability. Packets in the LSP with EXP field of 011 (001) 509 have a higher probability of being dropped than packets with an EXP 510 field of 010 (000). 512 The above table indicates the recommended usage of EXP fields for 513 Treatment Aggregates. Because many deployments of MPLS are on a per 514 domain basis, each domain has total control of its EXP usage and each 515 domain may use a different EXP field allocation for the domain's 516 supported Treatment Aggregates. 518 5.1. Network Control Treatment Aggregate with E-LSP 520 The usage of E-LSP for Network Control Treatment Aggregate needs to 521 adhere to the recommendations indicated in section 4.1.1 of this 522 document and section 3.2 of "Diffserv Service Classes" [5]. 523 Reinforcing these recommendations, there should be no drop precedence 524 associated with the MPLS PSC used for Network Control Treatment 525 Aggregate because dropping of Network Control Treatment Aggregate 526 traffic should be prevented. 528 5.2. Real Time Treatment Aggregate with E-LSP 530 In addition to the recommendations provided in section 4.1.2 of this 531 document and in member service classes' sections of "Diffserv Service 532 Classes" [5], we want to indicate that Real Time Treatment Aggregate 533 traffic should not be dropped, as some of the applications whose 534 traffic is carried in the Real Time Treatment Aggregate do not react 535 well to dropped packets. As indicated in section 4.1.2 of this 536 document, admission control should be performed on each Service Class 537 contributing to the Real Time Treatment Aggregate to prevent packet 538 loss due to insufficient resources allocated to Real Time Treatment 539 Aggregate. Further, admission control and policing may also be 540 applied on the sum of all traffic aggregated into this treatment 541 aggregate. 543 5.3. Assured Elastic Treatment Aggregate with E-LSP 545 EXP field markings of 010 and 011 are used for the Assured Elastic 546 Treatment Aggregate. The two encodings are used to provide two 547 levels of drop precedence indications, with 010 encoded traffic 548 having a lower probability of being dropped than 011 encoded traffic. 549 This provides for the mapping of CS2, AF31, AF21, and AF11 into EXP 550 010; and AF32, AF22, AF12 and AF33, AF23, AF13 into EXP 011. 552 5.4. Elastic Treatment Aggregate with E-LSP 554 EXP field markings of 000 and 001 are used for the Elastic Treatment 555 Aggregate. The two encodings are used to provide two levels of drop 556 precedence indications, with 000 encoded traffic having a lower 557 probability of being dropped than 001 encoded traffic. This provides 558 for the mapping of Default/CS0 into 000; and CS1 into 001. Notice 559 that with this mapping, during congestion, CS1 marked traffic may be 560 starved. 562 5.5. Treatment Aggregates and L-LSP 564 Because L-LSP (Label Only Inferred PSC LSP) supports a single PSC per 565 LSP, the support of each Treatment Aggregate is on a per LSP basis. 566 This document does not further specify any additional recommendation 567 (beyond what has been indicated in section 4 of this document) for 568 Treatment Aggregate to L-LSP mapping, leaving this to each individual 569 MPLS domain administrations. 571 6. Treatment Aggregates and Inter-Provider Relationships 573 When Treatment Aggregates are used at provider boundaries, we 574 recommend that the Inter-Provider Relationship be based on Diffserv 575 Service Classes [5]. This allows the admission control into each 576 Treatment Aggregate of a provider domain to be based on the admission 577 control of traffic into the supported Service Classes, as indicated 578 by the discussion in section 4 of this document. 580 If the Inter-Provider Relationship needs to be based on Treatment 581 Aggregates specified by this document, then the exact Treatment 582 Aggregate content and representation must be agreed to by the peering 583 providers. 585 7. Security Considerations 587 This document discusses the policy of using Differentiated Services 588 and its service classes. If implemented as described, it should 589 require that the network do nothing that the network has not already 590 allowed. If that is the case, no new security issues should arise 591 from the use of such a policy. 593 It is possible for the policy to be applied incorrectly, or for a 594 wrong policy to be applied in the network for the defined 595 aggregation. In that case, a policy issue exists that the network 596 must detect, assess, and deal with. This is a known security issue 597 in any network dependent on policy-directed behavior. 599 A well known flaw appears when bandwidth is reserved or enabled for a 600 service (for example, voice transport) and another service or an 601 attacking traffic stream uses it. This possibility is inherent in 602 DiffServ technology, which depends on appropriate packet markings. 603 When bandwidth reservation or a priority queuing system is used in a 604 vulnerable network, the use of authentication and flow admission is 605 recommended. To the best of the authors' knowledge, there is no 606 known technical way to respond to or act upon a data stream that has 607 been admitted for service but that it is not intended for 608 authenticated use. 610 8. IANA Considerations 612 This document does not request any IANA considerations. 614 9. Acknowledgements 616 This document have benefitted from discussions with numerous people, 617 especially Shane Amante and Brian Carpenter. This document have also 618 benefitted from David Black's comments and guidance. And 619 improvements from Marvin Krym's recommendations. 621 10. Normative References 623 [1] Postel, J., "Internet Protocol", STD 5, RFC 791, 624 September 1981. 626 [2] Bradner, S., "The Internet Standards Process -- Revision 3", 627 BCP 9, RFC 2026, October 1996. 629 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 630 Levels", BCP 14, RFC 2119, March 1997. 632 [4] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of 633 the Differentiated Services Field (DS Field) in the IPv4 and 634 IPv6 Headers", RFC 2474, December 1998. 636 [5] Babiarz, J., "Configuration Guidelines for DiffServ Service 637 Classes", draft-ietf-tsvwg-diffserv-service-classes-02 (work in 638 progress), February 2006. 640 [6] Braden, B., Clark, D., and S. Shenker, "Integrated Services in 641 the Internet Architecture: an Overview", RFC 1633, June 1994. 643 [7] Black, D., "Differentiated Services and Tunnels", RFC 2983, 644 October 2000. 646 [8] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., 647 Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol 648 Label Switching (MPLS) Support of Differentiated Services", 649 RFC 3270, May 2002. 651 [9] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., 652 Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, 653 C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, 654 J., and L. Zhang, "Recommendations on Queue Management and 655 Congestion Avoidance in the Internet", RFC 2309, April 1998. 657 [10] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured 658 Forwarding PHB Group", RFC 2597, June 1999. 660 [11] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., 661 Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An 662 Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, 663 March 2002. 665 [12] Charny, A., Bennet, J., Benson, K., Boudec, J., Chiu, A., 666 Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., and K. 667 Ramakrishnan, "Supplemental Information for the New Definition 668 of the EF PHB (Expedited Forwarding Per-Hop Behavior)", 669 RFC 3247, March 2002. 671 [13] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of 672 Explicit Congestion Notification (ECN) to IP", RFC 3168, 673 September 2001. 675 Authors' Addresses 677 Kwok Ho Chan 678 Nortel Networks 679 600 Technology Park Drive 680 Billerica, MA 01821 681 US 683 Phone: +1-978-288-8175 684 Fax: +1-978-288-8700 685 Email: khchan@nortel.com 687 Jozef Z. Babiarz 688 Nortel Networks 689 3500 Carling Avenue 690 Ottawa, Ont. K2H 8E9 691 Canada 693 Phone: +1-613-763-6098 694 Fax: +1-613-768-2231 695 Email: babiarz@nortel.com 697 Fred Baker 698 Cisco Systems 699 1121 Via Del Rey 700 Santa Barbara, CA 93117 701 US 703 Phone: +1-408-526-4257 704 Fax: +1-413-473-2403 705 Email: fred@cisco.com 707 Intellectual Property Statement 709 The IETF takes no position regarding the validity or scope of any 710 Intellectual Property Rights or other rights that might be claimed to 711 pertain to the implementation or use of the technology described in 712 this document or the extent to which any license under such rights 713 might or might not be available; nor does it represent that it has 714 made any independent effort to identify any such rights. Information 715 on the procedures with respect to rights in RFC documents can be 716 found in BCP 78 and BCP 79. 718 Copies of IPR disclosures made to the IETF Secretariat and any 719 assurances of licenses to be made available, or the result of an 720 attempt made to obtain a general license or permission for the use of 721 such proprietary rights by implementers or users of this 722 specification can be obtained from the IETF on-line IPR repository at 723 http://www.ietf.org/ipr. 725 The IETF invites any interested party to bring to its attention any 726 copyrights, patents or patent applications, or other proprietary 727 rights that may cover technology that may be required to implement 728 this standard. Please address the information to the IETF at 729 ietf-ipr@ietf.org. 731 Disclaimer of Validity 733 This document and the information contained herein are provided on an 734 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 735 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 736 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 737 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 738 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 739 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 741 Copyright Statement 743 Copyright (C) The Internet Society (2006). This document is subject 744 to the rights, licenses and restrictions contained in BCP 78, and 745 except as set forth therein, the authors retain all their rights. 747 Acknowledgment 749 Funding for the RFC Editor function is currently provided by the 750 Internet Society.