RFC 5127
Aggregation of Diffserv Service Classes
RFC 5127 🎀 is titled "Aggregation of Diffserv Service Classes" and was published as part of the Network Working Group series in February 2008 🌸. It's an Informational doc, written by K. Chan and J. Babiarz (both from Nortel) and F. Baker (from Cisco Systems) 🧚. The title block doesn't list anything it obsoletes or updates.
Status of This Memo ✨
This memo is here to give information to the Internet community 💖. It does not specify an Internet standard of any kind, so don't go treating it like one 🙈. Distribution of this memo is unlimited, so share it with everyone 🫶.
Abstract 🦋
Okay so picture the core of a high-capacity network 🌈. Apps with similar traffic needs and performance goals get sorted into Diffserv service classes based on what they need from end-to-end behavior 💅. But here's the tea: some network segments are set up so one single forwarding treatment can cover the traffic needs of two or more service classes ✨. In those cases it can be really useful to aggregate two or more Diffserv service classes into one single forwarding treatment 💜. This document gives you the guidelines for doing exactly that 👑.
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 . . . . . . . . . . . . . . 181. Introduction 🌷
Let's talk about the core of a high-capacity network 🚀. It's super common for these networks to be engineered so that a major link, switch, or router can fail, and the network still keeps meeting its ambient Service Level Agreements (SLAs) 🫶. What that implies is there's enough capacity on any link so that every SLA sold can be supported at the same time at their max rates, and that stays true even after re-routing (either IP re-routing or Multiprotocol Label Switching (MPLS) protection-mode switching) happens 🔥.
Over-provisioning is generally seen as enough to handle all traffic without any extra quality of service (QoS) treatment, and most of the time that's true in high-capacity backbones 💅. But as network convergence keeps going, and access networks keep getting faster, certain services can still run into problems 😭. Delay, jitter, and occasional loss are totally fine for elastic applications 🍓. However, sub-second surges that happen in even the best-designed networks [12] do affect real-time applications 💀. Plus, denial of service (DoS) loads, worms, and network disruptions like the one on 11 September 2001 affect routing [13] 🙈. Our goal is to stop disruption to routing (which affects every service) and to protect real-time, jitter-sensitive services, all while keeping loss and delay for sensitive elastic traffic as low as possible 👑.
RFC 4594 [3] defines a set of basic Diffserv classes from the point of view of the application that needs specific end-to-end behaviors from the network 🧚. The service classes are differentiated based on how well the application payload tolerates packet loss, delay, and delay variation (jitter) 💖. Different levels of these criteria form the foundation for supporting the needs of real-time and elastic traffic 🌈. RFC 4594 [3] also gives recommendations for how to treat these service classes ✨. But at some network segments along the end-to-end path, the number of levels of network treatment differentiation may be less than the number of service classes that segment needs to support 😩. In that situation, the segment may use the same treatment to support more than one service class 🦋. In this document, we give guidelines on how multiple service classes can be aggregated into a forwarding treatment aggregate 💜. This involves 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 so not all forwarding treatment aggregates need to be supported either 🙃. A domain may support a fewer or greater number of forwarding treatment aggregates than this document recommends 💅. Which service classes and which forwarding treatment aggregates a domain supports is up to the domain administration, and it may be influenced by business reasons or other reasons (e.g., operational considerations) 💼.
In this document, we've provided:
- definitions for terminology we use in this document,
- requirements for performing this aggregation,
- an example of performing the aggregation when four treatment aggregates are used, and
- 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 a way that protects 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 doing the aggregation; there may be other ways, for example, into fewer treatment aggregates or more treatment aggregates ✨.
In the appendix, there's an example of aggregation over MPLS networks using E-LSP to realize the treatment aggregates 🧚. Note that 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 already knows the terms used in differentiated services 🫶. It gives the definitions for new terms introduced by this document, and it references information defined in RFCs for existing terms that aren't commonly used in differentiated services 🍓.
For new terms introduced by this document, here's the definition 🦋:
- 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, here's where to find the definition in the relevant RFC 👑:
- Real-Time and Elastic Applications and their traffic. Section 3.1 of RFC 1633 [4].
- Diffserv Service Class. Section 1.3 of RFC 4594 [3].
- MPLS E-LSP, EXP Inferred PHB Scheduling Class (PSC) Label Switched Path (LSP). Section 1.2 of RFC 3270 [6].
- 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 ✨
okay so, in Diffserv domains that don't do super fine-grained traffic treatment, you might need to aggregate the different service classes [3] together 🫶
these aggregations come with some requirements (no cap, they're kind of strict 💅):
- The end-to-end network performance characteristic the application needs MUST be supported. This performance characteristic is represented by the use of Diffserv service classes [3]. 🔥
- The treatment aggregate MUST meet the strictest requirements of its member service classes. 👑
- The treatment aggregate SHOULD only contain member service classes with similar traffic characteristics and performance requirements. 🌸
- 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 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. 🦋
- 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 (these are just vibes, not rules 🙈):
- 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. 💜
- 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]. Just IP traffic, bestie, that's the scope 🎀
4. Service Classes to Treatment Aggregate Mapping ✨
the service class and DSCP selection in RFC 4594 [3] was defined so that, in lots of cases, two or possibly more service classes can get mapped into a single forwarding treatment aggregate 🍓 but notice there's a relationship (aka a trade-off 👀) between link speed, queue depth, delay, and jitter. how many aggregates you end up with depends on how the aggregation hits loss, delay, and jitter. that depends on whether the link speeds and scheduler behavior used to do the aggregation can keep the effects of mixing traffic with different packet sizes and transmit rates on queue depth under control. a general rule of thumb: higher link speeds allow for more aggregation (aka fewer treatment aggregates), as long as link utilization stays within the engineered level ⚡
4.1. Mapping Service Classes into Four Treatment Aggregates
this section gives an example of mapping all the service classes defined in RFC 4594 [3] into four treatment aggregates 🦄 using four treatment aggregates assumes that the resources given to each one are enough to honor the required behavior of each service class [3]. we use the performance requirements (tolerance to loss, delay, and jitter) from the application or end user as a guide for how to map service classes into treatment aggregates. we also used section 3.1 of RFC 1633 [4] for guidance on defining Real-Time and Elastic applications. Figure 1 gives an overview of the mapping between service classes and the four treatment aggregates, based on performance requirements. in Figure 1, the right side columns of "Service Class" and "Tolerance to Loss/Delay/Jitter" come from Figure 2 of RFC 4594 [3].
it is recommended that certain service classes be mapped into specific treatment aggregates. but that doesn't mean every service class recommended for a treatment aggregate has to be supported 🤏 so 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 that domain supports. how a domain treats unsupported service classes should be based on the domain's local policy. that local policy may be shaped by its agreements with its customers. that treatment might use the Elastic Treatment Aggregate, dropping the packets, or some other arrangement 💅
our four-treatment-aggregate example is based on the basic differences in performance requirements from the application or end-user point of view. a domain may choose to support more or fewer treatment aggregates than the four recommended. for example, a domain might support only three treatment aggregates and map any network control traffic into the Assured Elastic treatment aggregate. that's the administrative domain's call 🎀 so this example of four treatment aggregates is NOT a minimum set you must implement, and it's NOT a maximum set you can implement either ✨
---------------------------------------------------------------------
|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
Requirementsas we're recommending that the notion of the individual end-to-end service classes be preserved, 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 treatment aggregate, without remarking the DSCP field of the packets. Figure 2 sums this up: it shows the behavior each treatment aggregate should have, and the DSCP field markings of the packets that should be classified into each one 🧚
------------------------------------------------------------
|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 BehaviorNotes for Figure 2: for the Assured Elastic and Elastic Treatment Aggregates, check out sections 4.1.3 and 4.1.4, respectively, for the details on the extra priority inside each treatment aggregate 👑
4.1.1. Network Control Treatment Aggregate 🛡️
okay so this is the bodyguard bucket 🛡️ it gathers up every service class that the network needs to survive a DoS attack or any other high-traffic moment. the whole logic is protect yourself first 💅 whatever else is going on, the network has to protect itself. this includes the traffic that RFC 4594 [3] puts 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 bucket 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). 🌊
Please notice this Network Control Treatment Aggregate is meant 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 gathers up all real-time (inelastic) service classes. the vibe here is predictable and enforceable ✨ real-time traffic is admitted under some model and kept in check by an SLA managed at the edge, before it gets aggregated. so there is a predictable, enforceable upper bound on what can enter that queue. to keep delay predictable, it has to be shielded from bursts of elastic traffic 🛡️ the predictability can come from admission control for a well-known community of interest (e.g., a point-point service) and/or from 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 gathers up all elastic traffic that uses the Assured Forwarding model as described in RFC 2597 [8]. the premise is giving committed rate energy 💖 the SLA that gets negotiated includes a "committed rate" and the ability to go over 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. 🫣
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: 🧠
min-threshold AFn3 < max-threshold AFn3max-threshold AFn3 <= min-threshold AFn2min-threshold AFn2 < max-threshold AFn2max-threshold AFn2 <= min-threshold AFn1+CS2min-threshold AFn1+CS2 < max-threshold AFn1+CS2max-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. 🍓
4.1.4. Elastic Treatment Aggregate 🧁
The Elastic Treatment Aggregate gathers up all remaining elastic traffic. the premise is that there is no intrinsic SLA differentiation of traffic, but AQM [7] or ECN flagging [11] is appropriate for it. it's giving easygoing 🌈
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. 🌍
6. Security Considerations 🔐
Serious security business, bestie 🚨 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.
- [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,
<http://www.ieee-infocom.org/2004/Papers/37_4.PDF>. - [13] Ogielski, A. and J. Cowie, "Internet Routing Behavior on 9/11", March 2002, as published at:
<http://www.renesys.com/tech/presentations/pdf/
renesys-030502-NRC-911.pdf>- [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, as published at:
<
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.
Appendix A. Using MPLS for Treatment Aggregates ✨
RFC 2983 on Diffserv and Tunnels [5] and RFC 3270 on MPLS Support of Diffserv [6] are a very good background on this topic 📚💖. This appendix shows how to use the E-LSP, which is the EXP Inferred PSC Label Switched Path (LSP) defined by MPLS Support of Diffserv [6], to realize the Treatment Aggregates 🦋.
When treatment aggregates are represented in MPLS using the EXP Inferred PSC LSP, we recommend the following usage of the MPLS EXP field for treatment aggregates 🎀.
-------------------------------------------
|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).The table above shows the recommended usage of EXP fields for treatment aggregates 💅. Because many MPLS deployments are per-domain, each domain has total control of its EXP usage, and each domain may use a different EXP field allocation for the treatment aggregates it supports 🌈✨.
A.1. Network Control Treatment Aggregate with E-LSP
Using E-LSP for Network Control Treatment Aggregate needs to adhere to the recommendations in section 4.1.1 of this document and section 3.2 of RFC 4594 [3] 🫶. To reinforce those recommendations, there should be no drop precedence associated with the MPLS PSC used for Network Control Treatment Aggregate, because dropping Network Control Treatment Aggregate traffic should be prevented 🛡️. Protect that traffic, bestie! 👑
A.2. Real-Time Treatment Aggregate with E-LSP
On top of the recommendations in section 4.1.2 of this document and in the member service classes' sections of RFC 4594 [3], we want to point out that Real-Time Treatment Aggregate traffic should not be dropped 😭. Some of the applications carried in this aggregate do not react well to dropped packets, so it's a whole vibe to avoid that 🙈. As section 4.1.2 of this document says, admission control should be performed on each service class contributing to the Real-Time Treatment Aggregate, so that packet loss due to insufficient resources allocated to the Real-Time Treatment Aggregate is prevented 🎀. 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 give two levels of drop precedence: 010-encoded traffic has a lower probability of being dropped than 011-encoded traffic 💜. This maps CS2, AF31, AF21, and AF11 into EXP 010, and it maps AF32, AF22, AF12, AF33, AF23, and AF13 into EXP 011 🍓. If the domain chooses to support only one drop precedence for this treatment aggregate, we recommend using 010 for the 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 🦋. These two encodings give two levels of drop precedence: 000-encoded traffic has a lower probability of being dropped than 001-encoded traffic 🌈. This maps Default/CS0 into 000, and it maps CS1 into 001 🍭. Notice 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 using 000 for the EXP field marking 💅.
Heads up: with this mapping, CS1-marked traffic can get starved during congestion. Plan around it, bestie! 🙈
A.5. Treatment Aggregates and L-LSP
L-LSP (Label Only Inferred PSC LSP) supports a single PSC per LSP, so each treatment aggregate is supported on a per-LSP basis 🧚♀️. This document does not specify any further recommendation (beyond what is indicated in section 4 of this document) for treatment aggregate to L-LSP mapping. That part is left 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.comJozef Z. Babiarz
Nortel
3500 Carling Avenue
Ottawa, Ont. K2H 8E9
Canada
Phone: +1-613-763-6098
Fax: +1-613-768-2231
EMail: babiarz@nortel.comFred 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.comFull 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. 🫶✨
📦 where this page comes from
- ietf: rfc5127 2008-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms