RFC 5160
Considerations of Provider-to-Provider Agreements for Internet-Scale Quality of Service (QoS)
RFC 5160: Considerations of Provider-to-Provider Agreements for Internet-Scale Quality of Service (QoS) 🎀
Okay bestie, the title block first! 💖 This one comes from the Network Working Group and was written by P. Levis and M. Boucadair, both at France Telecom. It's Informational, dated March 2008, and the header doesn't list anything it obsoletes or updates. ✨
Status of This Memo 🦋
This memo gives information to the Internet community. It is not a spec for any kind of Internet standard, and it can be distributed freely. 💅
IESG Note 🌸
This RFC is not a candidate for any level of Internet Standard. The IETF doesn't vouch for whether this RFC is fit for any purpose, and publishing it wasn't based on IETF review, except for the IESG check for conflicts with IETF work. The RFC Editor picked to publish it at their own discretion. For more info, see RFC 3932. 🙈
Abstract 💜
This memo looks at provider-to-provider Quality of Service (QoS) agreements that could work for a global QoS-enabled Internet. It defines terminology for inter-domain QoS models and introduces a new concept called Meta-QoS-Class (MQC). ✨ MQC could potentially drive and bring together the way QoS inter-domain relationships get built between providers. It opens up new possibilities for a QoS-enabled Internet that keeps, as much as possible, the openness of today's best-effort Internet. 🌈
Table of Contents 🧚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Assumptions and Requirements . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Weaknesses of Provider-to-Provider QoS Agreements Based on
SP Chains . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. IP Connectivity Services . . . . . . . . . . . . . . . . . 6
4.2. Similarity between Provider and Customer Agreements . . . 6
4.3. Liability for Service Disruption . . . . . . . . . . . . . 7
4.4. SP Chain Trap Leading to Glaciation . . . . . . . . . . . 7
5. Provider-to-Provider Agreements Based on Meta-QoS-Class . . . 7
5.1. Single Domain Covering . . . . . . . . . . . . . . . . . . 8
5.2. Binding l-QCs . . . . . . . . . . . . . . . . . . . . . . 9
5.3. MQC-Based Binding Process . . . . . . . . . . . . . . . . 10
6. The Internet as MQC Planes . . . . . . . . . . . . . . . . . . 12
7. Towards End-to-End QoS Services . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . . 161. Introduction ✨
Okay so there are three areas in IP QoS service offerings, and they're all different vibes. 💅 First up is the single domain, where a provider delivers QoS services inside the edges of its own network. Next is multiple domains, where a small group of providers with shared business interests team up to deliver QoS services inside the edges of their combined network aggregate. Then there's the third area, which almost nobody talks about: the Internet, where QoS services can be delivered from almost any source to any destination. 🌸
Both the multiple domains and Internet areas deal with inter-domain stuff, but they're literally so different. The number of domains and QoS paths is way higher and more dynamic for the Internet area, so they're probably going to need different solutions. 🦋 This memo is our attempt to dig into the Internet area from the point of view of provider-to-provider agreements. It gives a framework for an inter-domain QoS-enabled Internet. 🎀
[MESCAL] lays out a set of requirements that any solution trying to fix inter-domain QoS issues has to meet. We're not copying those requirements here, so go read [MESCAL] if you want the full deets. 🧚
Here's the big idea: for the sake of scalability, providers don't need to care about what happens more than one hop away from their Autonomous System when they negotiate inter-domain QoS agreements. 🙌 They should base their agreements on nothing but their own local QoS capabilities and those of their direct neighbors. This analysis is why we define terminology for inter-domain QoS models. We also introduce Meta-QoS-Class (MQC), which drives and brings together the way QoS inter-domain relationships get built between providers. 💜 The reasoning behind MQC is a universal, shared understanding of what QoS-sensitive apps need. Wherever end-users are connected, they run into the same QoS difficulties and are likely to ask their providers for very similar QoS requirements. Since providers are all getting the same customer requirements, they're likely to design and run similar network capabilities. 🔥
MQC gives us a simplified view of Internet QoS capabilities as a set of MQC planes. This memo checks whether the idea of MQC planes can help with some well-known, concrete inter-domain QoS issues. ✨ The focus, though, is the provider-to-provider QoS agreement framework. The point is not to specify individual solutions and protocols for a full inter-domain QoS system. If you want a complete architecture based on the notion of parallel Internets that extends and generalizes MQC planes, check out [AGAVE]. 👑
Note: this document does not specify any protocols or systems. 🫶
2. Assumptions and Requirements 💖
To avoid a whole mess of complexity and scalability problems, we assume that provider-to-provider QoS agreements are only negotiated between two adjacent domains that can directly reach each other. We also assume that, because they exchange traffic, these neighbors are BGP [RFC4271] peers. This pairwise peering is a logical thing, so it can run not only over physical point-to-point connections but also over Internet exchange points (IXPs), where lots of operators connect to each other using a layer 2 switch. 🦋
The QoS solutions in this document are exclusively solutions that work for the global Internet. For Internet-wide solutions, this document assumes that:
- Any solutions should apply locally, so they're usable as soon as they're deployed in a small set of domains. 🌈
- Any solutions should be scalable, so they can be deployed globally to almost all Internet domains, with the ability to set up QoS communications between any and all end-users. 💅
- Any solutions should also keep a best-effort service, which should stay the preeminent service because of the end-to-end argument [E2E]. 🧚
- If there's no path available within the requested QoS to reach a destination, that destination must remain reachable through the best-effort service. 🫶
This memo doesn't place any specific requirements on intra-domain traffic engineering policies or how they get enforced. A provider can use any technique it wants to ensure QoS inside its own network. ✨ This memo only assumes that QoS capabilities inside a provider's network can be represented as local-QoS-Classes (l-QCs). When traffic crosses a domain, it experiences conditions characterized by the values of delay, jitter, and packet loss rate that match the l-QC selected for that traffic within that domain. 🎀 Capabilities can differ from one provider to another by the number of l-QCs deployed, by their QoS characteristics, and by how they've been implemented and engineered. 🌸
3. Terminology 🌷
Here's the glossary, bestie. The core trio is (D, J, L):
D is the one-way transit delay [RFC2679], J is the one-way transit delay variation or jitter [RFC3393], and L is the packet loss rate [RFC2680]. 📏
Domain
A network infrastructure made up of one or several Autonomous Systems (AS), managed by a single administrative entity. 🏠
IP connectivity service
An IP transfer capability characterized by a (Destination, D, J, L) tuple, where Destination is a group of IP addresses and (D, J, L) is the QoS performance needed to get to the Destination. 🛣️
Local-QoS-Class (l-QC)
A QoS transfer capability across a single domain, characterized by a set of QoS performance parameters denoted by (D, J, L). From a Diffserv [RFC2475] perspective, an l-QC is an occurrence of a Per Domain Behavior (PDB) [RFC3086]. 🎀
L-QC binding
Two l-QCs from two neighboring domains are bound together once the two providers have agreed to transfer traffic from one l-QC to the other. 🔗
L-QC thread
A chain of neighboring bound l-QCs. 🧵
Meta-QoS-Class (MQC)
An MQC provides the limits of the QoS parameter values that two l-QCs must respect in order to be bound together. An MQC is used as a label that certifies support for a set of applications that have similar network QoS requirements. 🏷️
Service Provider (SP)
An entity that provides Internet connectivity. This document assumes that an SP owns and administers an IP network called a domain. Sometimes it's simply called a provider. 💼
SP chain
The chain of Service Providers whose domains are used to convey packets for a given IP connectivity service. ⛓️
4. Weaknesses of Provider-to-Provider QoS Agreements Based on SP Chains 💀
The goal of this section is to show, with a sort of reductio ad absurdum proof, that within the scope of Internet services, provider-to-provider QoS agreements should be based on guarantees that span a single domain. 🙈
So we analyze provider-to-provider QoS agreements based on guarantees that span several domains, and we point out their vulnerabilities. In this case, the basic service element that a provider offers to its neighboring providers is called an IP connectivity service, and it uses the notion of SP chains. 🫠 We'll first define what an IP connectivity service is, and then call out several weaknesses of this approach. The big one is the SP chain trap problem, which leads to the so-called Internet glaciation era. ❄️✨
4.1. IP Connectivity Services ✨
okay so an IP connectivity service is a (Destination, D, J, L) tuple 💅 Destination is a group of IP addresses you can reach from the provider's domain, and (D, J, L) is the QoS performance you get going from that domain to Destination. Destination usually lives in a remote domain 🌍
Provider- /--------------SP chain---------------\
oriented
view /--Agreement--\
+----+ +----+ +----+ +----+ +----+
|SP +-------+SP +----+SP +----+SP +- ... -+SP |
|n+1 | |n | |n-1 | |n-2 | |1 |
+----+ +----+ +----+ +----+ +----+
Domain- -----> packet flow /
oriented Destination
view <----------- Guarantee Scope --------->
Figure 1: IP connectivity serviceIn Figure 1, provider SPn guarantees provider SPn+1 a level of QoS for crossing the whole chain of provider domains (SPn, SPn-1, SPn-2, ...,SP1) 🔗 SPi refers to a provider and its domain at the same time. The top of the figure is the provider-oriented view, and the ordered set of providers (SPn, SPn-1, SPn-2, ...,SP1) is what we call an SP chain. The bottom of the figure is the domain-oriented view 🦋
4.2. Similarity between Provider and Customer Agreements 🌸
This approach maps end-users' needs straight onto provider-to-provider agreements. Providers negotiate agreements to a destination because they know customers are ready to pay for QoS-guaranteed transfer to that destination 💸 When it comes to service scope, the agreements between providers look a lot like the agreements between customers and providers. For instance, in Figure 1, SPn can sell its own customers the same IP connectivity service it sells to SPn+1. Honestly there's no clear line between provider-to-provider agreements and customer-to-provider agreements 🫠
To keep a stable service, redundant SP chains should be formed to reach the same destination. When one SP chain becomes unavailable, an alternative SP chain should be selected. In the context of a global QoS Internet, that would lead to an enormous number of SP chains, along with all the agreements that come with them 😭
4.3. Liability for Service Disruption ⚖️
In Figure 1, if SPn+1 sees a disruption in the IP connectivity service, it can only turn against SPn, its legal partner in the agreement. If SPn isn't responsible, it can in the same way only complain to SPn-1, and so on, until the faulty provider is found and eventually asked to pay for the service impairment. The claim is then supposed to move back along the chain until SPn pays SPn+1. So the SP chain becomes a liability chain 🔗
Unfortunately this process fails a lot. For QoS solutions suited to the Internet, SP chains are likely to be dynamic and involve a significant number of providers. Providers that don't all know each other and are involved in the same SP chain can be competitors in many fields, so trust relationships are super hard to build 🥲 There are also many complex, critical issues to sort out: how will SPn+1 prove to SPn that the QoS level isn't the level expected for a scope that can expand well beyond SPn? How long will it take to find the guilty domain? And is SPn ready to pay SPn+1 for something it doesn't control and isn't responsible for? 🙃
4.4. SP Chain Trap Leading to Glaciation 🧊
In Figure 1, SPn implicitly guarantees SPn+1 a level of QoS for crossing distant domains like SPn-2. As we saw in Section 4.2, SP chains will proliferate. In this context, a provider is likely to be part of numerous SP chains, and it will see the QoS level it provides being guaranteed by many providers it maybe has never even heard of 👀
Any change in a given agreement is likely to affect numerous external agreements that make use of it. A provider finds its freedom to renegotiate, or terminate, one of its own agreements restricted by the large number of external (to its domain) agreements that depend on it. This is what's referred to as the "SP chain trap" issue. This solution isn't appropriate for worldwide QoS coverage, because it would lead to glaciation phenomena, a completely petrified QoS infrastructure where nobody could renegotiate any agreement 🥶🪦
5. Provider-to-Provider Agreements Based on Meta-QoS-Class 👑
If a QoS-enabled Internet is deemed desirable, with QoS services potentially available to and from any destination, any solution must resolve the weaknesses and scalability problems above and find alternate schemes for provider-to-provider agreements 🚀
5.1. Single Domain Covering 🎯
Because of the vulnerabilities of the SP chain approach, we assume provider-to-provider QoS agreements should be based on guarantees covering a single domain. A provider guarantees its neighbors only the crossing performance of its own domain. In Figure 2, provider SPn guarantees provider SPn+1 only the QoS performance of the SPn domain. The rest of this document will show that this approach, which brings clarity and simplicity into inter-domain relationships, is better suited to a global QoS Internet than one based on SP chains 💖
Provider-
oriented
view /--Agreement--\
+----+ +----+
|SP +-------+SP +
|n+1 | |n |
+----+ +----+
Domain- -----> packet flow
oriented <---->
view Guarantee Scope
Figure 2: provider-to-provider QoS agreementIt's super important to note that limiting guarantees to only one domain hop applies exclusively to provider-to-provider agreements. It does not in any way preclude end-to-end guarantees for communications 🧚
The simple fact that SP chains don't exist makes the AS chain trap problem and the associated glaciation threat vanish 🫧
The liability issue is restricted to a one-hop distance. A provider is responsible for its own domain only, and it's controlled by all the neighbors it has a direct contract with 🤝
5.2. Binding l-QCs 🦋
When a provider wants to contract with another provider, the main concern is deciding which l-QC(s) in its own domain it will bind to which l-QC(s) in the neighboring downstream domain. This l-QC binding process becomes the basic inter-domain process 🎀
Upstream Downstream
domain domain
l-QC21 -----> l-QC11
l-QC22 -----> l-QC12
l-QC23 ----->
l-QC13
l-QC24 ----->
Figure 3: l-QC BindingIf one l-QC were bound to two (or more) l-QCs, it would be very hard to know which l-QC the packets should select. This could mean flow classification at the border of the domains, at a granularity as fine as application flows 😵💫 For the sake of scalability, we assume one l-QC should not be bound to several l-QCs [Lev]. On the other hand, several l-QCs can be bound to the same l-QC, like l-QC23 and l-QC24 being bound to l-QC13 in Figure 3 ✨
A provider decides the best match between l-QCs based exclusively on:
- What it knows about its own l-QCs;
- What it knows about its neighboring l-QCs.
It doesn't use any information about what's happening more than one domain away 👁️
Even with this one-hop, short-sighted approach, the consistency and coherency of QoS treatment must be ensured on an l-QC thread formed by neighboring bound l-QCs. Packets leaving a domain that applies a given l-QC should get similar treatment when crossing external domains up to their final destination. A provider should bind its l-QC with the neighboring l-QC that has the closest performance. The criteria for l-QC binding should stay stable along any l-QC thread. For example, two providers should not bind two l-QCs to minimize delay while, further along the same thread, two other providers have bound two l-QCs to minimize errors. That's a no-go 🙅♀️
Constraints should be put on l-QC QoS performance parameters, so their values stay within an acceptable and expected level on an l-QC thread scale. These constraints should depend on domain size. For example, restrictions on delay should allow a bigger value for a national domain than for a regional one. So some rules must be defined to establish under which conditions two l-QCs can be bound together. These rules are provided by the notion of Meta-QoS-Class (MQC) 💜
5.3. MQC-Based Binding Process
okay so an MQC is basically the rulebook that sets the limits on the QoS parameters two l-QCs have to respect before they can get bound together 🎀 A provider goes through several steps to extend its internal l-QCs through the binding process. First, it classifies its own l-QCs based on MQCs. An MQC works like a label that certifies a set of applications with similar network QoS requirements is supported 💅 It's how you make sure an l-QC actually has the right QoS vibes to carry traffic for that group of apps. Second, it learns about the available MQCs advertised by its neighbors ✨ To advertise an MQC, a provider must have at least one compliant l-QC and should be ready to reach agreements to let neighbor traffic benefit from it. Third, it contracts an agreement with its neighbor to send some traffic that gets handled according to the agreed MQCs 🦋
The following attributes should be documented in any specification of an MQC 📝 This is not a closed list, so other attributes can be added if needed.
- A set of applications (e.g., VoIP) the MQC is particularly suited for.
- Boundaries or intervals of a set of QoS performance attributes whenever required. For illustration purposes, we propose to use in this document attribute
(D, J, L)3-tuple. An MQC could be focused on a single parameter (e.g., suitable to convey delay sensitive traffic). Several levels could also be specified depending on the size of the network provider. For instance, a small domain (e.g., regional) needs lower delay than a large domain (e.g., national) to match a given MQC 🌸 - Constraints on traffic (e.g., only TCP-friendly).
- Constraints on the ratio: network resources for the class / overall traffic using this class (e.g., less resources than peak traffic).
Two l-QCs can be bound together if, and only if, they conform to the same MQC 💜
Provider-to-provider agreements, as defined here, are uni-directional 🌈 They are established for transporting traffic in a given direction. However, from a business perspective, it is likely that reverse agreements will also be negotiated for transporting traffic in the opposite direction. Note that uni-directional provider-to-provider agreements do not preclude having end-to-end services with bi-directional guarantees, when you consider the two directions of the traffic separately 🙈
Two providers negotiating an agreement based on MQC will have to agree on several other parameters that are outside the definition of MQC. One such obvious parameter is bandwidth. The two providers agree to exchange up to a given level of QoS traffic. This bandwidth level can then be further renegotiated, inside the same MQC agreement, to reflect an increase in the end-user QoS requests. Other clauses of inter-domain agreements could cover availability of the service, time of repair, etc. 🍓
A hierarchy of MQCs can be defined for a given type of service (e.g., VoIP with different qualities: VoIP for residential and VoIP for business) 👑 A given l-QC can be suitable for several MQCs (even outside the same hierarchy). Several l-QCs in the same domain can be classified as belonging to the same MQC. There is an MQC with no specific constraints called the best-effort MQC.
There is a need for some form of standardization to control QoS agreements between providers [RFC3387]. Each provider must have the same understanding of what a given MQC is about. We need a global agreement on a set of MQC standards. The number of classes to be defined must remain very small to avoid overwhelming complexity. We also need a means to certify that the l-QC classification made by a provider conforms to the MQC standards. So the standardization effort should be accompanied by investigations on conformance testing requirements 🧚
The three notions of PDB, Service Class [RFC4594], and MQC are related, but what MQC brings is the inter-domain aspect 💖
- PDB is how to engineer a network;
- Service Class is a set of traffic with specific QoS requests;
- MQC is a way to classify the QoS capabilities (l-QCs, through Diffserv or any other protocols or mechanisms) in order to reach agreements with neighbors. MQCs are only involved when a provider wants to negotiate an agreement with a neighboring provider. MQC is completely indifferent to the way networks are engineered as long as the MQC QoS attribute (e.g., (D, J, L)) values are reached 🔥
6. The Internet as MQC Planes ✨
The resulting QoS Internet can be viewed as a set of parallel Internets or MQC planes 🌌 Each plane consists of all the l-QCs bound according to the same MQC. An MQC plane can have holes and isolated domains because QoS capabilities do not cover all Internet domains. When an l-QC maps to several MQCs, it belongs potentially to several planes.
When a provider contracts with another provider based on the use of MQCs, it simply adds a logical link to the corresponding MQC plane. This is basically what current traditional inter-domain agreements mean for the existing Internet. Figure 4a) depicts the physical layout of a fraction of the Internet, comprising four domains with full-mesh connectivity 🦋
+----+ +----+ +----+ +----+
|SP +----+SP | |SP +----+SP |
|1 | |2 | |1 | |2 |
+-+--+ +--+-+ +-+--+ +----+
| \ / | | /
| \/ | | /
| /\ | | /
| / \ | | /
+-+--+ +--+-+ +-+--+ +----+
|SP +----+SP | |SP | |SP |
|4 | |3 | |4 | |3 |
+----+ +----+ +----+ +----+
a) physical configuration b) an MQC plane
Figure 4: MQC planesFigure 4 b) depicts how these four domains are involved in a given MQC plane. SP1, SP2, and SP4 have at least one compliant l-QC for this MQC; SP3 may or may not have one. A bi-directional agreement exists between SP1 and SP2, SP1 and SP4, SP2 and SP4 🫶
MQC brings a clear distinction between provider-to-provider and customer-to-provider QoS agreements. We expect a great deal of difference in dynamicity between the two. Most provider-to-provider agreements should have been negotiated, and should remain stable, before end-users can dynamically request end-to-end guarantees. Provider agreements do not directly map end-users' needs, so the number of provider agreements is largely independent of the number of end-user requests and does not increase as dramatically as with SP chains 📈
For a global QoS-based Internet, this solution will work only if MQC-based binding is largely accepted and becomes a current practice. This limitation is due to the nature of the service itself, and not to the use of MQCs. Insofar as we target global services, we are bound to provide QoS in as many SP domains as possible. However, any MQC-enabled part of the Internet that forms a connected graph can be used for QoS communications and can be extended. Therefore, incremental deployment is possible, and leads to incremental benefits. For example, in Figure 4 b), as soon as SP3 connects to the MQC plane it will be able to benefit from the SP1, SP2, and SP4 QoS capabilities 🌈
The Internet, as a split of different MQC planes, offers an ordered and simplified view of the Internet QoS capabilities. End-users can select the MQC plane that is the closest to their needs, as long as there is a path available for the destination. One of the main outcomes of applying the MQC concept is that it alleviates the complexity and the management burden of inter-domain relationships 💅
7. Towards End-to-End QoS Services ✨
okay so now we're getting to the really fun part 🦋 building end-to-end QoS paths so end-users can get QoS-guaranteed communications with each other is a whole next level 💅 the full story of customer-to-provider QoS agreements and how they get enforced is out of scope for this memo, so we won't go deep on that 🙈 but this section lists some important issues and says whether MQC can help solve them 💖
route path selection inside a chosen MQC plane works basically the same way as the regular routing system that Internet routers use 🌸 so we can rely on BGP, basically one BGP instance per MQC plane, for inter-domain routing. the resilience of the IP routing system stays intact 🫶 if a QoS path breaks somewhere, the routing protocol can dynamically work out another QoS path, if one exists, in the right MQC plane. this gives you a first level of QoS infrastructure that we could cutely call "best-effort QoS", even though that's kind of an oxymoron 💀
on top of that, we can add features to pick and control QoS paths better ✨ for example, BGP can carry QoS-related information, and Autonomous Systems can each add their own QoS values (D, J, L) as they propagate an AS path. then the AS path info gets paired with Delay, Jitter, and Loss, and the choice of whether to use the path BGP picked can be made using numbers 🔥 here's an example: for destination N, an AS path (X, Y) is advertised to AS Z. while the AS path goes through BGP, X adds its own delay, say 30 ms, and Y adds its own delay, say 20 ms. Z receives the BGP advertisement (X, Y, N, 50 ms). one of Z's customers asks for a delay of 100 ms to reach N. Z knows its own delay for this customer, say 20 ms. Z computes the expected maximum delay from its customer to N: 70 ms, and concludes it can use the AS path (X, Y) 👑 the QoS value of an AS path could also be split off from BGP and computed through an off-line process, too 🧚
if we use QoS routing, we can put the (D, J, L) info into the BGP decision process, but that brings up the problem of composing performance metrics so you can pick good paths [Chau] 😭 when you're juggling multiple incompatible objectives, the local choices made to optimize each targeted parameter can produce a set of incomparable paths, where no path is strictly better than the others 💀 provider-to-provider agreements based on MQC give everyone a homogeneous view of the QoS parameters, so they should bring coherency and reduce the risk of those non-optimal choices 💜
a lot of end-to-end services are bi-directional, so you have to measure the composite performance in both directions 🎀 many inter-domain paths are asymmetric, and usually some providers on the forward path aren't on the reverse path, and the other way around too 🙈 that means no assumptions can be made about the reverse path 💅 MQC-based provider-to-provider agreements are likely to be negotiated bi-directionally, but they still let the inter-domain routing protocol compute the forward and reverse paths separately, as usual ✨ the only constraint MQC puts on routing is that the selected paths must use the chosen MQCs throughout the selected domains 🌈 there might also be a different MQC requirement in the reverse direction than in the forward direction, so to handle this, we can use application-level communication between the two parties (customers) to specify the QoS requirements in both directions 🫶
we can take things even further and control the path to keep QoS parameters stable, for example by enforcing an explicit routing scheme with RSVP-TE/MPLS-TE requests [RFC3209] before injecting traffic into an l-QC thread 🦋 but right now, several problems still need solving before ready and operational solutions exist for inter-domain route pinning, inter-domain TE, fast failover, and so forth 😭 see the BGP slow convergence problem in [Kushman] for an example 🙈
multicast powers lots of apps with QoS needs, like audio and video distribution (e.g., IPTV, streaming apps) 🍓 along with solutions at the IP or Application level, such as Forward Error Correction (FEC), the inter-domain multicast routing protocol with Multiprotocol Extensions for BGP-4 [RFC4760] could advertise MQC capabilities for multicast source reachability 🔥 if an inter-domain tree spanning several domains stays in the same MQC plane, it would be possible to benefit from the consistency and coherency MQC provides 💖
heads up, though, because using some QoS parameters to drive route selection inside an MQC plane can cause QoS deterioration 😭 the best QoS-inferred path gets selected by every Autonomous System Border Router (ASBR) involved in the inter-domain path computation, which means no other available routes in the same MQC plane get a chance to be picked 💀 this problem was called the QoS Attribute-rush (QA-rush) in [Grif] 🥀 this drawback may be avoided if all the ASes involved in the QoS chain implement some out-of-band means to control inter-domain QoS path consistency (MQC compliance) ✨
to wrap up this section: whatever protocols we want to use, and however tightly we want to control QoS paths, MQC is a concept that can help resolve problems [WIP], without prohibiting any particular mechanism or protocol at the data, control, or management planes 👑💜
8. Security Considerations 🔐
this document describes a framework, not protocols or systems 🫶 so potential risks and attacks depend directly on the implementation technology 💅 solutions that implement this proposal must detail their security issues in the relevant protocol documentation 📝
particular attention should be paid to giving access to MQC resources only to authorized traffic 🚨 unauthorized access can lead to denial of service when network resources get overused [RFC3869] 😭💀
9. Acknowledgements 🎀
this work is funded by the European Commission, within the context of the MESCAL (Management of End-to-End Quality of Service Across the Internet At Large) and AGAVE (A liGhtweight Approach for Viable End-to-end IP-based QoS Services) projects 🇪🇺 the authors would like to thank all the other partners for the fruitful discussions 🫶
we're also grateful to Brian Carpenter, Jon Crowcroft, and Juergen Quittek for their helpful comments and suggestions for improving this document 💖✨
10. References 📚
10.1. Normative References
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Packet Loss Metric for IPPM", RFC 2680, September 1999.
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
Metric for IP Performance Metrics (IPPM)", RFC 3393,
November 2002.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
January 2006.10.2. Informative References
[AGAVE] Boucadair, et al., "Parallel Internets Framework", IST
AGAVE project public deliverable D1.1, September 2006.
[Chau] Chau, C., "Policy-based routing with non-strict
preferences", Proceedings of the ACM SIGCOMM 2006
Conference on Applications, Technologies, Architectures,
and Protocols for Computer Communications, Pisa, Italy, pp
387-398, September 2006.
[E2E] Saltzer, J H., Reed, D P., and D D. Clark, "End-To-End
Arguments in System Design", ACM Transactions in Computer
Systems, Vol 2, Number 4, pp 277-288, November 1984.
[Grif] Griffin, D., Spencer, J., Griem, J., Boucadair, M.,
Morand, P., Howarth, M., Wang, N., Pavlou, G., Asgari, A.,
and P. Georgatsos, "Interdomain routing through QoS-class
planes [Quality-of-Service-Based Routing Algorithms for
Heterogeneous Networks]", IEEE Communications
Magazine, Vol 45, Issue 2, pp 88-95, February 2007.
[Kushman] Kushman, N., Kandula, S., and D. Katabi, "Can You Hear Me
Now?! It Must Be BGP", ACM Journal of Computer and
Communication Review CCR, November 2007.
[Lev] Levis, P., Asgari, H., and P. Trimintzios, "Consideration
on Inter-domain QoS and Traffic Engineering issues Through
a Utopian Approach", SAPIR-2004 workshop of ICT-2004, (C)
Springer-Verlag, August 2004.
[MESCAL] Flegkas, et al., "Specification of Business Models and a
Functional Architecture for Inter-domain QoS Delivery",
IST MESCAL project public deliverable D1.1, May 2003.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC3086] Nichols, K. and B. Carpenter, "Definition of
Differentiated Services Per Domain Behaviors and Rules for
their Specification", RFC 3086, April 2001.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3387] Eder, M., Chaskar, H., and S. Nag, "Considerations from
the Service Management Research Group (SMRG) on Quality of
Service (QoS) in the IP Network", RFC 3387,
September 2002.
[RFC3869] Atkinson, R., Ed., Floyd, S., Ed., and Internet
Architecture Board, "IAB Concerns and Recommendations
Regarding Internet Research and Evolution", RFC 3869,
August 2004.
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
Guidelines for DiffServ Service Classes", RFC 4594,
August 2006.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760,
January 2007.
[WIP] Deleuze, G. and F. Guattari, "What Is Philosophy?",
Columbia University Press ISBN: 0231079893, April 1996.Authors' Addresses 🧚
Pierre Levis
France Telecom
42 rue des Coutures
BP 6243
Caen Cedex 4 14066
France
EMail: pierre.levis@orange-ftgroup.com
Mohamed Boucadair
France Telecom
42 rue des Coutures
BP 6243
Caen Cedex 4 14066
France
EMail: mohamed.boucadair@orange-ftgroup.comFull Copyright Statement ⚖️
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78 and at http://www.rfc-editor.org/copyright.html,
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 💅
okay so this bit is the legal stuff, but bestie it still matters 🫶 The IETF takes no position on whether any Intellectual Property Rights or other rights that might be claimed for the technology in this document are valid or in scope. It also doesn't say whether any license under those rights might or might not be available. And no, it hasn't made any independent effort to find out whether such rights exist 🙈 If you want the rules on rights in RFC documents, they live in BCP 78 and BCP 79.
Copies of IPR disclosures sent to the IETF Secretariat are kept in the IETF on-line IPR repository at http://www.ietf.org/ipr. You'll also find any assurances of licenses that have been offered there. The same goes for the results of any attempt to get a general license or permission for implementers or users of this specification to use those proprietary rights. ✨
The IETF also invites anyone who's interested to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 📬 It's giving open-door policy, no cap 🌈
📦 where this page comes from
- ietf: rfc5160 2008-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms