From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5127.txt | 1067 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1067 insertions(+) create mode 100644 doc/rfc/rfc5127.txt (limited to 'doc/rfc/rfc5127.txt') diff --git a/doc/rfc/rfc5127.txt b/doc/rfc/rfc5127.txt new file mode 100644 index 0000000..4f4e7b5 --- /dev/null +++ b/doc/rfc/rfc5127.txt @@ -0,0 +1,1067 @@ + + + + + + +Network Working Group K. Chan +Request for Comments: 5127 J. Babiarz +Category: Informational Nortel + F. Baker + Cisco Systems + February 2008 + + + Aggregation of Diffserv Service Classes + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Abstract + + In the core of a high-capacity network, service differentiation may + still be needed to support applications' utilization of the network. + Applications with similar traffic characteristics and performance + requirements are mapped into Diffserv service classes based on end- + to-end behavior requirements of the applications. However, some + network segments may be configured in such a way that a single + forwarding treatment may satisfy the traffic characteristics and + performance requirements of two or more service classes. In these + cases, it may be desirable to aggregate two or more Diffserv service + classes into a single forwarding treatment. This document provides + guidelines for the aggregation of Diffserv service classes into + forwarding treatments. + + + + + + + + + + + + + + + + + + + + + +Chan, et al. Informational [Page 1] + +RFC 5127 Aggregation of Diffserv Service Classes February 2008 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Overview of Service Class Aggregation . . . . . . . . . . . . 5 + 4. Service Classes to Treatment Aggregate Mapping . . . . . . . . 6 + 4.1. Mapping Service Classes into Four Treatment Aggregates . . 7 + 4.1.1. Network Control Treatment Aggregate . . . . . . . . . 9 + 4.1.2. Real-Time Treatment Aggregate . . . . . . . . . . . . 10 + 4.1.3. Assured Elastic Treatment Aggregate . . . . . . . . . 10 + 4.1.4. Elastic Treatment Aggregate . . . . . . . . . . . . . 12 + 5. Treatment Aggregates and Inter-Provider Relationships . . . . 12 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 + 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 + Appendix A. Using MPLS for Treatment Aggregates . . . . . . . . 15 + A.1. Network Control Treatment Aggregate with E-LSP . . . . . . 17 + A.2. Real-Time Treatment Aggregate with E-LSP . . . . . . . . . 17 + A.3. Assured Elastic Treatment Aggregate with E-LSP . . . . . . 17 + A.4. Elastic Treatment Aggregate with E-LSP . . . . . . . . . . 17 + A.5. Treatment Aggregates and L-LSP . . . . . . . . . . . . . . 18 + + + + + + + + + + + + + + + + + + + + + + + + + + + +Chan, et al. Informational [Page 2] + +RFC 5127 Aggregation of Diffserv Service Classes February 2008 + + +1. Introduction + + In the core of a high capacity network, it is common for the network + to be engineered in such a way that a major link, switch, or router + can fail, and the result will be a routed network that still meets + ambient Service Level Agreements (SLAs). The implications are that + there is sufficient capacity on any given link such that all SLAs + sold can be simultaneously supported at their respective maximum + rates, and that this remains true after re-routing (either IP re- + routing or Multiprotocol Label Switching (MPLS) protection-mode + switching) has occurred. + + Over-provisioning is generally considered to meet the requirements of + all traffic without further quality of service (QoS) treatment, and + in the general case, that is true in high-capacity backbones. + However, as the process of network convergence continues, and with + the increasing speed of the access networks, certain services may + still have issues. Delay, jitter, and occasional loss are perfectly + acceptable for elastic applications. However, sub-second surges that + occur in the best-designed of networks [12] affect real-time + applications. Moreover, denial of service (DoS) loads, worms, and + network disruptions such as that of 11 September 2001 affect routing + [13]. Our objective is to prevent disruption to routing (which in + turn affects all services) and to protect real-time jitter-sensitive + services, while minimizing loss and delay of sensitive elastic + traffic. + + RFC 4594 [3] defines a set of basic Diffserv classes from the points + of view of the application requiring specific end-to-end behaviors + from the network. The service classes are differentiated based on + the application payload's tolerance to packet loss, delay, and delay + variation (jitter). Different degrees of these criteria form the + foundation for supporting the needs of real-time and elastic traffic. + RFC 4594 [3] also provides recommendations for the treatment method + of these service classes. But, at some network segments of the end- + to-end path, the number of levels of network treatment + differentiation may be less than the number of service classes that + the network segment needs to support. In such a situation, that + network segment may use the same treatment to support more than one + service class. In this document, we provide guidelines on how + multiple service classes may be aggregated into a forwarding + treatment aggregate. This entails having the IP traffic belonging to + service classes, expressed using the DSCP (Differentiated Services + Code Point), as described by RFC 4594 [3]. Note that in a given + domain, we may recommend that the supported service classes be + aggregated into forwarding treatment aggregates; however, this does + not mean all service classes need to be supported, and hence not all + forwarding treatment aggregates need to be supported. A domain may + + + +Chan, et al. Informational [Page 3] + +RFC 5127 Aggregation of Diffserv Service Classes February 2008 + + + support a fewer or greater number of forwarding treatment aggregates + than recommended by this document. Which service classes and which + forwarding treatment aggregates are supported by a domain is up to + the domain administration and may be influenced by business reasons + or other reasons (e.g., operational considerations). + + In this document, we've provided: + + o definitions for terminology we use in this document, + + o requirements for performing this aggregation, + + o an example of performing the aggregation when four treatment + aggregates are used, and + + o an example (in the appendix) of performing this aggregation over + MPLS using E-LSP, EXP Inferred PHB Scheduling Class (PSC) Label + Switched Path (LSP). + + The treatment aggregate recommendations are designed to aggregate the + service classes [3] in such a manner as to protect real-time traffic + and routing, on the assumption that real-time sessions are protected + from each other by admission at the edge. The recommendation given + is one possible way of performing the aggregation; there may be other + ways of aggregation, for example, into fewer treatment aggregates or + more treatment aggregates. + + In the appendix, an example of aggregation over MPLS networks using + E-LSP to realize the treatment aggregates is provided. Note that the + MPLS E-LSP is just an example; this document does not exclude the use + of other methods. This example only considers aggregation of IP + traffic into E-LSP. The use of E-LSP by non-IP traffic is not + discussed. + +1.1. Requirements Notation + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [1]. + +2. Terminology + + This document assumes the reader is familiar with the terms used in + differentiated services. This document provides the definitions for + new terms introduced by this document and references information + defined in RFCs for existing terms not commonly used in + differentiated services. + + + + +Chan, et al. Informational [Page 4] + +RFC 5127 Aggregation of Diffserv Service Classes February 2008 + + + For new terms introduced by this document, we provide the definition + here: + + o Treatment Aggregate. This term is defined as the aggregate of + Diffserv service classes [3]. A treatment aggregate is concerned + only with the forwarding treatment of the aggregated traffic, + which may be marked with multiple DSCPs. A treatment aggregate + differs from Behavior Aggregate [2] and Traffic Aggregate [14], + each of which indicate the aggregated traffic having a single + Diffserv codepoint and utilizing a single Per Hop Behavior (PHB). + + For terms from existing RFCs, we provide the reference to the + appropriate section of the relevant RFC that contain the definition: + + o Real-Time and Elastic Applications and their traffic. Section 3.1 + of RFC 1633 [4]. + + o Diffserv Service Class. Section 1.3 of RFC 4594 [3]. + + o MPLS E-LSP, EXP Inferred PHB Scheduling Class (PSC) Label Switched + Path (LSP). Section 1.2 of RFC 3270 [6]. + + o MPLS L-LSP, Label Only Inferred PHB Scheduling Class (PSC) Label + Switched Path (LSP). Section 1.3 of RFC 3270 [6]. + +3. Overview of Service Class Aggregation + + In Diffserv domains where less fine-grained traffic treatment + differentiation is provided, aggregation of the different service + classes [3] may be required. + + These aggregations have the following requirements: + + 1. The end-to-end network performance characteristic required by the + application MUST be supported. This performance characteristic + is represented by the use of Diffserv service classes [3]. + + 2. The treatment aggregate MUST meet the strictest requirements of + its member service classes. + + 3. The treatment aggregate SHOULD only contain member service + classes with similar traffic characteristic and performance + requirements. + + 4. The notion of the individual end-to-end service classes MUST NOT + be destroyed when aggregation is performed. Each domain along + the end-to-end path may perform aggregation differently, based on + the original end-to-end service classes. We recommend an easy + + + +Chan, et al. Informational [Page 5] + +RFC 5127 Aggregation of Diffserv Service Classes February 2008 + + + way to accomplish this by not altering the DSCP used to indicate + the end-to-end service class. But some administrative domains + may require the use of their own marking; when this is needed, + the original end-to-end service class indication must be restored + upon exiting such administrative domains. One possible way of + achieving this is with the use of tunnels to encapsulate the end- + to-end traffic. + + 5. Each treatment aggregate has limited resources; hence, traffic + conditioning and/or admission control SHOULD be performed for + each service class aggregated into the treatment aggregate. + Additional admission control and policing may be used on the sum + of all traffic aggregated into the treatment aggregate. + + In addition to the above requirements, we have the following + suggestions: + + 1. The treatment aggregate and assigned resources may consider + historical traffic patterns and the variability of these + patterns. For example, a point-point service (e.g., pseudowire) + may have a very predictable pattern, while a multipoint service + (e.g., VPLS, Virtual Private LAN Service) may have a much less + predictable pattern. + + 2. In addition to Diffserv, other controls are available to + influence the traffic level offered to a particular traffic + aggregate. These include adjustment of routing metrics, and + usage of MPLS-based traffic engineering techniques. + + This document only describes the aggregation of IP traffic based on + the use of Diffserv service classes [3]. + +4. Service Classes to Treatment Aggregate Mapping + + The service class and DSCP selection in RFC 4594 [3] has been defined + to allow, in many instances, mapping of two or possibly more service + classes into a single forwarding treatment aggregate. Notice that + there is a relationship/trade-off between link speed, queue depth, + delay, and jitter. The degree of aggregation and hence the number of + treatment aggregates will depend on the aggregation's impacts on + loss, delay, and jitter. This depends on whether the speed of the + links and scheduler behavior, being used to implement the + aggregation, can minimize the effects of mixing traffic with + different packet sizes and transmit rates on queue depth. A general + rule-of-thumb is that higher link speeds allow for more aggregation/ + smaller number of treatment aggregates, assuming link utilization is + within the engineered level. + + + + +Chan, et al. Informational [Page 6] + +RFC 5127 Aggregation of Diffserv Service Classes February 2008 + + +4.1. Mapping Service Classes into Four Treatment Aggregates + + This section provides an example of mapping all the service classes + defined in RFC 4594 [3] into four treatment aggregates. The use of + four treatment aggregates assumes that the resources allocated to + each treatment aggregate are sufficient to honor the required + behavior of each service class [3]. We use the performance + requirement (tolerance to loss, delay, and jitter) from the + application/end-user as a guide on how to map the service classes + into treatment aggregates. We have also used section 3.1 of RFC 1633 + [4] to provide us with guidance on the definition of Real-Time and + Elastic applications. An overview of the mapping between service + classes and the four treatment aggregates is provided by Figure 1, + with the mapping being based on performance requirements. In Figure + 1, the right side columns of "Service Class" and "Tolerance to Loss/ + Delay/Jitter" are from Figure 2 of RFC 4594 [3]. + + It is recommended that certain service classes be mapped into + specific treatment aggregates. But this does not mean that all the + service classes recommended for that treatment aggregate need to be + supported. Hence, for a given domain, a treatment aggregate may + contain only a subset of the service classes recommended in this + document, i.e., the service classes supported by that domain. A + domain's treatment of non-supported service classes should be based + on the domain's local policy. This local policy may be influenced by + its agreement with its customers. Such treatment may use the Elastic + Treatment Aggregate, dropping the packets, or some other + arrangements. + + Our example of four treatment aggregates is based on the basic + differences in performance requirement from the application/end-user + perspective. A domain may choose to support more or fewer treatment + aggregates than the four recommended. For example, a domain may + support only three treatment aggregates and map any network control + traffic into the Assured Elastic treatment aggregate. This is a + choice the administrative domain has. Hence, this example of four + treatment aggregates does not represent a minimum required set of + treatment aggregates one must implement; nor does it represent the + maximum set of treatment aggregates one can implement. + + + + + + + + + + + + +Chan, et al. Informational [Page 7] + +RFC 5127 Aggregation of Diffserv Service Classes February 2008 + + + --------------------------------------------------------------------- + |Treatment | Tolerance to ||Service Class | Tolerance to | + |Aggregate | Loss |Delay |Jitter|| | Loss |Delay |Jitter| + |==========+======+======+======++===============+======+======+======| + | Network | Low | Low | Yes || Network | Low | Low | Yes | + | Control | | | || Control | | | | + |==========+======+======+======++===============+======+======+======| + | Real- | Very | Very | Very || Telephony | VLow | VLow | VLow | + | Time | Low | Low | Low ||---------------+------+------+------| + | | | | || Signaling | Low | Low | Yes | + | | | | ||---------------+------+------+------| + | | | | || Multimedia |Low - | Very | Low | + | | | | || Conferencing |Medium| Low | | + | | | | ||---------------+------+------+------| + | | | | || Real-time | Low | Very | Low | + | | | | || Interactive | | Low | | + | | | | ||---------------+------+------+------| + | | | | || Broadcast | Very |Medium| Low | + | | | | || Video | Low | | | + |==========+======+======+======++===============+======+======+======| + | Assured | Low |Low - | Yes || Multimedia |Low - |Medium| Yes | + | Elastic | |Medium| || Streaming |Medium| | | + | | | | ||---------------+------+------+------| + | | | | || Low-Latency | Low |Low - | Yes | + | | | | || Data | |Medium| | + | | | | ||---------------+------+------+------| + | | | | || OAM | Low |Medium| Yes | + | | | | ||---------------+------+------+------| + | | | | ||High-Throughput| Low |Medium| Yes | + | | | | || Data | |- High| | + |==========+======+======+======++===============+======+======+======| + | Elastic | Not Specified || Standard | Not Specified | + | | | | ||---------------+------+------+------| + | | | | || Low-Priority | High | High | Yes | + | | | | || Data | | | | + --------------------------------------------------------------------- + + Figure 1: Treatment Aggregate and Service Class Performance + Requirements + + As we are recommending to preserve the notion of the individual end- + to-end service classes, we also recommend that the original DSCP + field marking not be changed when treatment aggregates are used. + Instead, classifiers that select packets based on the contents of the + DSCP field should be used to direct packets from the member Diffserv + service classes into the queue that handles each of the treatment + aggregates, without remarking the DSCP field of the packets. This is + + + + +Chan, et al. Informational [Page 8] + +RFC 5127 Aggregation of Diffserv Service Classes February 2008 + + + summarized in Figure 2, which shows the behavior each treatment + aggregate should have, and the DSCP field marking of the packets that + should be classified into each of the treatment aggregates. + + ------------------------------------------------------------ + |Treatment |Treatment || DSCP | + |Aggregate |Aggregate || | + | |Behavior || | + |==========+==========++=====================================| + | Network | CS || CS6 | + | Control |(RFC 2474)|| | + |==========+==========++=====================================| + | Real- | EF || EF, CS5, AF41, AF42, AF43, CS4, CS3 | + | Time |(RFC 3246)|| | + |==========+==========++=====================================| + | Assured | AF || CS2, AF31, AF21, AF11 | + | Elastic |(RFC 2597)||-------------------------------------| + | | || AF32, AF22, AF12 | + | | ||-------------------------------------| + | | || AF33, AF23, AF13 | + |==========+==========++=====================================| + | Elastic | Default || Default, (CS0) | + | |(RFC 2474)||-------------------------------------| + | | || CS1 | + ------------------------------------------------------------ + + Figure 2: Treatment Aggregate Behavior + + Notes for Figure 2: For Assured Elastic and Elastic Treatment + Aggregates, please see sections 4.1.3 and 4.1.4, respectively, for + details on additional priority within the treatment aggregate. + +4.1.1. Network Control Treatment Aggregate + + The Network Control Treatment Aggregate aggregates all service + classes that are functionally necessary for the survival of a network + during a DoS attack or other high-traffic load interval. The theory + is that whatever else is true, the network must protect itself. This + includes the traffic that RFC 4594 [3] characterizes as being + included in the Network Control service class. + + Traffic in the Network Control Treatment Aggregate should be carried + in a common queue or class with a PHB as described in RFC 2474 [2], + section 4.2.2.2 for Class Selector (CS). This treatment aggregate + should have a lower probability of packet loss and bear a relatively + deep target mean queue depth (min-threshold if RED (Random Early + Detection) is being used). + + + + +Chan, et al. Informational [Page 9] + +RFC 5127 Aggregation of Diffserv Service Classes February 2008 + + + Please notice this Network Control Treatment Aggregate is meant to be + used for the customer's network control traffic. The provider may + choose to treat its own network control traffic differently, perhaps + in its own service class that is not aggregated with the customer's + network control traffic. + +4.1.2. Real-Time Treatment Aggregate + + The Real-Time Treatment Aggregate aggregates all real-time + (inelastic) service classes. The theory is that real-time traffic is + admitted under some model and controlled by an SLA managed at the + edge of the network prior to aggregation. As such, there is a + predictable and enforceable upper bound on the traffic that can enter + such a queue, and to provide predictable variation in delay it must + be protected from bursts of elastic traffic. The predictability of + traffic level may be based upon admission control for a well-known + community of interest (e.g., a point-point service) and/or based upon + historical measurements. + + This treatment aggregate may include the following service classes + from the Diffserv service classes [3], in addition to other locally + defined classes: Telephony, Signaling, Multimedia Conferencing, Real- + time Interactive, and Broadcast Video. + + Traffic in each service class that is going to be aggregated into the + treatment aggregate should be conditioned prior to aggregation. It + is recommended that per-service-class admission control procedures be + used, followed by per-service-class policing so that any individual + service class does not generate more than what it is allowed. + Furthermore, additional admission control and policing may be used on + the sum of all traffic aggregated into this treatment aggregate. + + Traffic in the Real-Time Treatment Aggregate should be carried in a + common queue or class with a PHB (Per Hop Behavior) as described in + RFC 3246 [9] and RFC 3247 [10]. + +4.1.3. Assured Elastic Treatment Aggregate + + The Assured Elastic Treatment Aggregate aggregates all elastic + traffic that uses the Assured Forwarding model as described in RFC + 2597 [8]. The premise of such a service is that an SLA that is + negotiated includes a "committed rate" and the ability to exceed that + rate (and perhaps a second "excess rate") in exchange for a higher + probability of loss using Active Queue Management (AQM) [7] or + Explicit Congestion Notification (ECN) marking [11] for the portion + of traffic deemed to be in excess. + + + + + +Chan, et al. Informational [Page 10] + +RFC 5127 Aggregation of Diffserv Service Classes February 2008 + + + This treatment aggregate may include the following service classes + from the Diffserv service classes [3], in addition to other locally + defined classes: Multimedia Streaming, Low Latency Data, OAM, and + High-Throughput Data. + + The DSCP values belonging to the Assured Forwarding (AF) PHB group + and class selector of the original service classes remain an + important consideration and should be preserved during aggregation. + This treatment aggregate should maintain the AF PHB group marking of + the original packet. For example, AF3x marked packets should remain + AF3x marked within this treatment aggregate. In addition, the class + selector DSCP value should not be changed. Traffic bearing these + DSCPs is carried in a common queue or class with a PHB as described + in RFC 2597 [8]. In effect, appropriate target rate thresholds have + been applied at the edge, dividing traffic into AFn1 (committed, for + any value of n), AFn2, and AFn3 (excess). The service should be + engineered so that AFn1 and CS2 marked packet flows have sufficient + bandwidth in the network to provide high assurance of delivery. + Since the traffic is elastic and responds dynamically to packet loss, + Active Queue Management [7] should be used primarily to reduce the + forwarding rate to the minimum assured rate at congestion points. + The probability of loss of AFn1 and CS2 traffic must not exceed the + probability of loss of AFn2 traffic, which in turn must not exceed + the probability of loss of AFn3 traffic. + + If RED [7] is used as an AQM algorithm, the min-threshold specifies a + target queue depth for each of AFn1+CS2, AFn2, and AFn3, and the max- + threshold specifies the queue depth above which all traffic with such + a DSCP is dropped or ECN marked. Thus, in this treatment aggregate, + the following inequalities SHOULD hold in queue configurations: + + o min-threshold AFn3 < max-threshold AFn3 + + o max-threshold AFn3 <= min-threshold AFn2 + + o min-threshold AFn2 < max-threshold AFn2 + + o max-threshold AFn2 <= min-threshold AFn1+CS2 + + o min-threshold AFn1+CS2 < max-threshold AFn1+CS2 + + o max-threshold AFn1+CS2 <= memory assigned to the queue + + Note: This configuration tends to drop AFn3 traffic before AFn2, and + AFn2 before AFn1 and CS2. Many other AQM algorithms exist and are + used; they should be configured to achieve a similar result. + + + + + +Chan, et al. Informational [Page 11] + +RFC 5127 Aggregation of Diffserv Service Classes February 2008 + + +4.1.4. Elastic Treatment Aggregate + + The Elastic Treatment Aggregate aggregates all remaining elastic + traffic. The premise of such a service is that there is no intrinsic + SLA differentiation of traffic, but that AQM [7] or ECN flagging [11] + is appropriate for such traffic. + + This treatment aggregate may include the following service classes + from the Diffserv service classes [3], in addition to other locally + defined classes: Standard and Low-Priority Data. + + Treatment aggregates should be well specified, each indicating the + service classes it will handle. But in cases where unspecified or + unknown service classes are encountered, they may be dropped or be + treated using the Elastic Treatment Aggregate. The choice of how to + treat unspecified service classes should be well defined, based on + some agreements. + + Traffic in the Elastic Treatment Aggregate should be carried in a + common queue or class with a PHB as described in RFC 2474 [2], + section 4.1, "A Default PHB". The AQM thresholds for Elastic traffic + MAY be separately set, so that Low Priority Data traffic is dropped + before Standard traffic, but this is not a requirement. + +5. Treatment Aggregates and Inter-Provider Relationships + + When treatment aggregates are used at provider boundaries, we + recommend that the inter-provider relationship be based on Diffserv + service classes [3]. This allows the admission control into each + treatment aggregate of a provider domain to be based on the admission + control of traffic into the supported service classes, as indicated + by the discussion in section 4 of this document. + + If the inter-provider relationship needs to be based on treatment + aggregates specified by this document, then the exact treatment + aggregate content and representation must be agreed to by the peering + providers. + + Some additional work on inter-provider relationships is provided by + inter-provider QoS [15], where details on supporting real-time + services between service providers are discussed. Some related work + in ITU-T provided by Appendix VI of Y.1541 [16] may also help with + inter-provider relationships, especially with international + providers. + + + + + + + +Chan, et al. Informational [Page 12] + +RFC 5127 Aggregation of Diffserv Service Classes February 2008 + + +6. Security Considerations + + This document discusses the policy of using Differentiated Services + and its service classes. If implemented as described, it should + require that the network do nothing that the network has not already + allowed. If that is the case, no new security issues should arise + from the use of such a policy. + + As this document is based on RFC 4594 [3], the Security Consideration + discussion of no new security issues indicated by RFC 4594 [3] also + applies to treatment aggregates of this document. + +7. Acknowledgements + + This document has benefited from discussions with numerous people, + especially Shane Amante, Brian Carpenter, and Dave McDysan. It has + also benefited from detailed reviews by David Black, Marvin Krym, + Bruce Davie, Fil Dickinson, and Julie Ann Connary. + +8. References + +8.1. Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of + the Differentiated Services Field (DS Field) in the IPv4 and + IPv6 Headers", RFC 2474, December 1998. + + [3] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines + for DiffServ Service Classes", RFC 4594, August 2006. + + [4] Braden, B., Clark, D., and S. Shenker, "Integrated Services in + the Internet Architecture: an Overview", RFC 1633, June 1994. + + [5] Black, D., "Differentiated Services and Tunnels", RFC 2983, + October 2000. + + [6] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., + Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol + Label Switching (MPLS) Support of Differentiated Services", + RFC 3270, May 2002. + + + + + + + + +Chan, et al. Informational [Page 13] + +RFC 5127 Aggregation of Diffserv Service Classes February 2008 + + + [7] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., + Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, + C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, + J., and L. Zhang, "Recommendations on Queue Management and + Congestion Avoidance in the Internet", RFC 2309, April 1998. + + [8] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured + Forwarding PHB Group", RFC 2597, June 1999. + + [9] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., + Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An + Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, + March 2002. + + [10] Charny, A., Bennet, J., Benson, K., Boudec, J., Chiu, A., + Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., and K. + Ramakrishnan, "Supplemental Information for the New Definition + of the EF PHB (Expedited Forwarding Per-Hop Behavior)", + RFC 3247, March 2002. + + [11] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of + Explicit Congestion Notification (ECN) to IP", RFC 3168, + September 2001. + +8.2. Informative References + + [12] Choi, B., Moon, S., Zhang, Z., Papagiannaki, K., and C. Diot, + "Analysis of Point-To-Point Packet Delay in an Operational + Network", INFOCOMM 2004, March 2004, + . + + [13] Ogielski, A. and J. Cowie, "Internet Routing Behavior on 9/11", + March 2002, . + + [14] Nichols, K. and B. Carpenter, "Definition of Differentiated + Services Per Domain Behaviors and Rules for their + Specification", RFC 3086, April 2001. + + [15] MIT Communications Futures Program, "Inter-provider Quality of + Service", November 2006, < + http://cfp.mit.edu/resources/papers/Interprovider QoS + MIT_CFP_WP_9_14_06.pdf>. + + [16] International Telecommunications Union, "Network Performance + Objectives for IP-Based Services", Recommendation Y.1541, + February 2006. + + + + +Chan, et al. Informational [Page 14] + +RFC 5127 Aggregation of Diffserv Service Classes February 2008 + + +Appendix A. Using MPLS for Treatment Aggregates + + RFC 2983 on Diffserv and Tunnels [5] and RFC 3270 on MPLS Support of + Diffserv [6] provide a very good background on this topic. This + document provides an example of using the E-LSP, EXP Inferred PHB + Scheduled Class (PSC) Label Switched Path (LSP), defined by MPLS + Support of Diffserv [6] for realizing the Treatment Aggregates. + + When treatment aggregates are represented in MPLS using EXP Inferred + PSC LSP, we recommend the following usage of the MPLS EXP field for + treatment aggregates. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Chan, et al. Informational [Page 15] + +RFC 5127 Aggregation of Diffserv Service Classes February 2008 + + + ------------------------------------------- + |Treatment || MPLS || DSCP | DSCP | + |Aggregate || EXP || name | value | + |==========++======++=========|=============| + | Network || 110 || CS6 | 110000 | + | Control || || | | + |==========++======++=========|=============| + | Real- || 100 || EF | 101110 | + | Time || ||---------|-------------| + | || || CS5 | 101000 | + | || ||---------|-------------| + | || ||AF41,AF42|100010,100100| + | || || AF43 | 100110 | + | || ||---------|-------------| + | || || CS4 | 100000 | + | || ||---------|-------------| + | || || CS3 | 011000 | + |==========++======++=========|=============| + | Assured || 010* || CS2 | 010000 | + | Elastic || || AF31 | 011010 | + | || || AF21 | 010010 | + | || || AF11 | 001010 | + | ||------||---------|-------------| + | || 011* || AF32 | 011100 | + | || || AF22 | 010100 | + | || || AF12 | 001100 | + | || || AF33 | 011110 | + | || || AF23 | 010110 | + | || || AF13 | 001110 | + |==========++======++=========|=============| + | Elastic || 000* || Default | 000000 | + | || || (CS0) | | + | ||------||---------|-------------| + | || 001* || CS1 | 001000 | + ------------------------------------------- + + Figure 3: Treatment Aggregate and MPLS EXP Field Usage + + * Note: For Assured Elastic (and Elastic) Treatment Aggregate, the + usage of 010 or 011 (000 or 001) as EXP field value depends on the + drop probability. Packets in the LSP with EXP field of 011 (001) + have a higher probability of being dropped than packets with an + EXP field of 010 (000). + + + + + + + + +Chan, et al. Informational [Page 16] + +RFC 5127 Aggregation of Diffserv Service Classes February 2008 + + + The above table indicates the recommended usage of EXP fields for + treatment aggregates. Because many deployments of MPLS are on a per- + domain basis, each domain has total control of its EXP usage and each + domain may use a different EXP field allocation for the domain's + supported treatment aggregates. + +A.1. Network Control Treatment Aggregate with E-LSP + + The usage of E-LSP for Network Control Treatment Aggregate needs to + adhere to the recommendations indicated in section 4.1.1 of this + document and section 3.2 of RFC 4594 [3]. Reinforcing these + recommendations, there should be no drop precedence associated with + the MPLS PSC used for Network Control Treatment Aggregate because + dropping of Network Control Treatment Aggregate traffic should be + prevented. + +A.2. Real-Time Treatment Aggregate with E-LSP + + In addition to the recommendations provided in section 4.1.2 of this + document and in member service classes' sections of RFC 4594 [3], we + want to indicate that Real-Time Treatment Aggregate traffic should + not be dropped, as some of the applications whose traffic is carried + in the Real-Time Treatment Aggregate do not react well to dropped + packets. As indicated in section 4.1.2 of this document, admission + control should be performed on each service class contributing to the + Real-Time Treatment Aggregate to prevent packet loss due to + insufficient resources allocated to Real-Time Treatment Aggregate. + Further, admission control and policing may also be applied on the + sum of all traffic aggregated into this treatment aggregate. + +A.3. Assured Elastic Treatment Aggregate with E-LSP + + EXP field markings of 010 and 011 are used for the Assured Elastic + Treatment Aggregate. The two encodings are used to provide two + levels of drop precedence indications, with 010 encoded traffic + having a lower probability of being dropped than 011 encoded traffic. + This provides for the mapping of CS2, AF31, AF21, and AF11 into EXP + 010; and AF32, AF22, AF12 and AF33, AF23, AF13 into EXP 011. If the + domain chooses to support only one drop precedence for this treatment + aggregate, we recommend the use of 010 for EXP field marking. + +A.4. Elastic Treatment Aggregate with E-LSP + + EXP field markings of 000 and 001 are used for the Elastic Treatment + Aggregate. The two encodings are used to provide two levels of drop + precedence indications, with 000 encoded traffic having a lower + probability of being dropped than 001 encoded traffic. This provides + for the mapping of Default/CS0 into 000; and CS1 into 001. Notice + + + +Chan, et al. Informational [Page 17] + +RFC 5127 Aggregation of Diffserv Service Classes February 2008 + + + that with this mapping, during congestion, CS1-marked traffic may be + starved. If the domain chooses to support only one drop precedence + for this treatment aggregate, we recommend the use of 000 for EXP + field marking. + +A.5. Treatment Aggregates and L-LSP + + Because L-LSP (Label Only Inferred PSC LSP) supports a single PSC per + LSP, the support of each treatment aggregate is on a per-LSP basis. + This document does not further specify any additional recommendation + (beyond what has been indicated in section 4 of this document) for + treatment aggregate to L-LSP mapping, leaving this to each individual + MPLS domain administration. + +Authors' Addresses + + Kwok Ho Chan + Nortel + 600 Technology Park Drive + Billerica, MA 01821 + US + + Phone: +1-978-288-8175 + Fax: +1-978-288-8700 + EMail: khchan@nortel.com + + + Jozef Z. Babiarz + Nortel + 3500 Carling Avenue + Ottawa, Ont. K2H 8E9 + Canada + + Phone: +1-613-763-6098 + Fax: +1-613-768-2231 + EMail: babiarz@nortel.com + + + Fred Baker + Cisco Systems + 1121 Via Del Rey + Santa Barbara, CA 93117 + US + + Phone: +1-408-526-4257 + Fax: +1-413-473-2403 + EMail: fred@cisco.com + + + + +Chan, et al. Informational [Page 18] + +RFC 5127 Aggregation of Diffserv Service Classes February 2008 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2008). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + + + + + + + + + + + +Chan, et al. Informational [Page 19] + -- cgit v1.2.3