diff options
Diffstat (limited to 'doc/rfc/rfc5160.txt')
| -rw-r--r-- | doc/rfc/rfc5160.txt | 1067 |
1 files changed, 1067 insertions, 0 deletions
diff --git a/doc/rfc/rfc5160.txt b/doc/rfc/rfc5160.txt new file mode 100644 index 0000000..611dabc --- /dev/null +++ b/doc/rfc/rfc5160.txt @@ -0,0 +1,1067 @@ + + + + + + +Network Working Group P. Levis +Request for Comments: 5160 M. Boucadair +Category: Informational France Telecom + March 2008 + + + Considerations of Provider-to-Provider Agreements + for Internet-Scale Quality of Service (QoS) + +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. + +IESG Note + + This RFC is not a candidate for any level of Internet Standard. The + IETF disclaims any knowledge of the fitness of this RFC for any + purpose and notes that the decision to publish is not based on IETF + review apart from IESG review for conflict with IETF work. The RFC + Editor has chosen to publish this document at its discretion. See + RFC 3932 for more information. + +Abstract + + This memo analyzes provider-to-provider Quality of Service (QoS) + agreements suitable for a global QoS-enabled Internet. It defines + terminology relevant to inter-domain QoS models. It proposes a new + concept denoted by Meta-QoS-Class (MQC). This concept could + potentially drive and federate the way QoS inter-domain relationships + are built between providers. It opens up new perspectives for a QoS- + enabled Internet that retains, as much as possible, the openness of + the existing best-effort Internet. + + + + + + + + + + + + + + + + + +Levis & Boucadair Informational [Page 1] + +RFC 5160 MQC and Provider QoS Agreements March 2008 + + +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 . . . . . . . . . . . . . . . . . . 16 + +1. Introduction + + Three different areas can be distinguished in IP QoS service + offerings. The first area is the single domain where a provider + delivers QoS services inside the boundaries of its own network. The + second area is multiple domains where a small set of providers, with + mutual business interests, cooperate to deliver QoS services inside + the boundaries of their network aggregate. The third area, which has + very seldom been put forward, is the Internet where QoS services can + be delivered from almost any source to any destination. Both + multiple domains and Internet areas deal with inter-domain aspects. + However, they differ significantly in many ways, such as the number + of domains and QoS paths involved, which are much higher and dynamic + for the Internet area. Multiple domains and Internet areas are + therefore likely to differ in their respective solutions. This memo + is an attempt to investigate the Internet area from the point of view + of provider-to-provider agreements. It provides a framework for + inter-domain QoS-enabled Internet. + + [MESCAL]provides a set of requirements to be met by any solution + aiming to solve inter-domain QoS issues. These requirements are not + reproduced within this memo. Readers are invited to refer to + [MESCAL] for more elaborated description on the requirements. + + + + + +Levis & Boucadair Informational [Page 2] + +RFC 5160 MQC and Provider QoS Agreements March 2008 + + + This memo shows that for the sake of scalability, providers need not + be concerned with what occurs 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 local QoS + capabilities and those of their direct neighbors. This analysis + leads us to define terminology relevant to inter-domain QoS models. + We also introduce a new concept denoted by Meta-QoS-Class (MQC) that + drives and federates the way QoS inter-domain relationships are built + between providers. The rationale for the MQC concept relies on a + universal and common understanding of QoS-sensitive applications + needs. Wherever end-users are connected, they experience the same + QoS difficulties and are likely to express very similar QoS + requirements to their respective providers. Globally confronted with + the same customer requirements, providers are likely to design and + operate similar network capabilities. + + MQC brings up a simplified view of the Internet QoS capabilities as a + set of MQC planes. This memo looks at whether the idea of MQC planes + can be helpful in certain well-known concrete inter-domain QoS + issues. The focus, however, is on the provider-to-provider QoS + agreement framework, and the intention is not to specify individual + solutions and protocols for a full inter-domain QoS system. For + discussion of a complete architecture based on the notion of parallel + Internets that extends and generalizes the notion of MQC planes, see + [AGAVE]. + + Note that this document does not specify any protocols or systems. + +2. Assumptions and Requirements + + To avoid a great deal of complexity and scalability issues, we assume + that provider-to-provider QoS agreements are negotiated only for two + adjacent domains that are directly accessible to each other. We also + assume, because they exchange traffic, that these neighbors are BGP + [RFC4271] peers. This pairwise peering is logical, therefore it can + be supported not only on physical point-to-point connections but also + on Internet exchange points (IXPs), where many operators connect to + each other using a layer 2 switch. + + The QoS solutions envisaged in this document are exclusively + solutions suitable for the global Internet. As far as Internet-wide + solutions are concerned, this document assumes that: + + o Any solutions should apply locally in order to be usable as soon + as deployed in a small set of domains. + + + + + + +Levis & Boucadair Informational [Page 3] + +RFC 5160 MQC and Provider QoS Agreements March 2008 + + + o Any solutions should be scalable in order to allow a global + deployment to almost all Internet domains, with the ability to + establish QoS communications between any and all end-users. + + o Any solutions should also maintain a best-effort service that + should remain the preeminent service as a consequence of the end- + to-end argument [E2E]. + + o If there is no path available within the requested QoS to reach a + destination, this destination must remain reachable through the + best-effort service. + + This memo does not place any specific requirements on the intra- + domain traffic engineering policies and the way they are enforced. A + provider may deploy any technique to ensure QoS inside its own + network. This memo assumes only that QoS capabilities inside a + provider's network can be represented as local-QoS-Classes (l-QCs). + When crossing a domain, traffic experiences conditions characterized + by the values of delay, jitter, and packet loss rate that correspond + to the l-QC selected for that traffic within that domain. + Capabilities can differ from one provider to another by the number of + deployed l-QCs, by their respective QoS characteristics, and also by + the way they have been implemented and engineered. + +3. Terminology + + (D, J, L) + + D: one-way transit delay [RFC2679], J: one-way transit delay + variation or jitter [RFC3393], and L: packet loss rate [RFC2680]. + + Domain + + A network infrastructure composed of one or several Autonomous + Systems (AS) managed by a single administrative entity. + + IP connectivity service + + 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 to get to the Destination. + + + + + + + + + + +Levis & Boucadair Informational [Page 4] + +RFC 5160 MQC and Provider QoS Agreements March 2008 + + + 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 + + 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 the support of a set of applications + that bear 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 simply referred to as 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 objective of this section is to show, by 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. + + We therefore analyze provider-to-provider QoS agreements based on + guarantees that span several domains and emphasize their + vulnerabilities. In this case, the basic service element that a + provider offers to its neighboring providers is called an IP + connectivity service. It uses the notion of SP chains. We first + define what an IP connectivity service is, and then we point out + + + +Levis & Boucadair Informational [Page 5] + +RFC 5160 MQC and Provider QoS Agreements March 2008 + + + several weaknesses of such an approach, especially the SP chain trap + problem that leads to the so-called Internet glaciation era. + +4.1. IP Connectivity Services + + An IP connectivity service is a (Destination, D, J, L) tuple where + Destination is a group of IP addresses reachable from the domain of + the provider offering the service, and (D, J, L) is the QoS + performance to get from this domain to Destination. Destination is + typically located 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 service + + In Figure 1, Provider SPn guarantees provider SPn+1 the level of QoS + for crossing the whole chain of providers' domains (SPn, SPn-1, + SPn-2, ...,SP1). SPi denotes a provider as well as its domain. The + top of the figure is the provider-oriented view; the ordered set of + providers (SPn, SPn-1, SPn-2, ...,SP1) is called 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 directly to provider-to-provider + agreements. Providers negotiate agreements to a destination because + they know customers are ready to pay for QoS guaranteed transfer to + this destination. As far as service scope is concerned, the + agreements between providers will resemble the agreements between + customers and providers. For instance, in Figure 1, SPn can sell to + its own customers the same IP connectivity service it sells to SPn+1. + There is no clear distinction between provider-to-provider agreements + and customer-to-provider agreements. + + In order to guarantee 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 the associated agreements. + + + +Levis & Boucadair Informational [Page 6] + +RFC 5160 MQC and Provider QoS Agreements March 2008 + + +4.3. Liability for Service Disruption + + In Figure 1, if SPn+1 sees a disruption in the IP connectivity + service, it can turn only against SPn, its legal partner in the + agreement. If SPn is not responsible, in the same way, it can only + complain to SPn-1, and so on, until the faulty provider is found and + eventually requested to pay for the service impairment. The claim is + then supposed to move back along the chain until SPn pays SPn+1. The + SP chain becomes a liability chain. + + Unfortunately, this process is prone to failure in many cases. In + the context of QoS solutions suited for the Internet, SP chains are + likely to be dynamic and involve a significant number of providers. + Providers (that do not all know each other) involved in the same SP + chain can be competitors in many fields; therefore, trust + relationships are very difficult to build. Many complex and critical + issues need to be resolved: how will SPn+1 prove to SPn that the QoS + level is not the level expected for a scope that can expand well + beyond SPn? How long will it take to find the guilty domain? Is SPn + ready to pay SPn+1 for something it does not control and is not + responsible for? + +4.4. SP Chain Trap Leading to Glaciation + + In Figure 1, SPn implicitly guarantees SPn+1 the level of QoS for the + crossing of distant domains like SPn-2. As we saw in Section 4.2, SP + chains will proliferate. A provider is, in this context, likely to + be part of numerous SP chains. It will see the level of QoS it + provides guaranteed by many providers it perhaps has never even heard + of. + + Any change in a given agreement is likely to have an impact on + numerous external agreements that make use of it. A provider sees + the degree of freedom to renegotiate, or terminate, one of its own + agreements being restricted by the large number of external (to its + domain) agreements that depend on it. This is what is referred to as + the "SP chain trap" issue. This solution is not appropriate for + worldwide QoS coverage, as it would lead to glaciation phenomena, + causing 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 above weaknesses and scalability problems and find + alternate schemes for provider-to-provider agreements. + + + + +Levis & Boucadair Informational [Page 7] + +RFC 5160 MQC and Provider QoS Agreements March 2008 + + +5.1. Single Domain Covering + + Due to 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, the + provider SPn guarantees the provider SPn+1 only the QoS performance + of the SPn domain. The remainder of this document will show that + this approach, bringing clarity and simplicity into inter-domain + relationships, is better suited for 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 agreement + + It is very important to note that the proposition to limit 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 do not 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 is controlled by all the + neighbors with whom it has a direct contract. + + + + + + + + + + + + + + + +Levis & Boucadair Informational [Page 8] + +RFC 5160 MQC and Provider QoS Agreements March 2008 + + +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. The 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 Binding + + If one l-QC were to be bound to two (or more) l-QCs, it would be very + difficult to know which l-QC the packets should select. This could + imply a flow classification at the border of the domains based on + granularity as fine as the application flows. For the sake of + scalability, we assume one l-QC should not be bound to several l-QCs + [Lev]. On the contrary, several l-QCs can be bound to the same l-QC, + in the way that l-QC23 and l-QC24 are 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 does not use any information related to what is happening more + than one domain away. + + Despite this one-hop, short-sighted approach, the consistency and the + coherency of the 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 experience 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 be stable along + any l-QC thread. For example, two providers should not bind two + l-QCs to minimize the delay whereas further on, on the same thread, + two other providers have bound two l-QCs to minimize errors. + + + +Levis & Boucadair Informational [Page 9] + +RFC 5160 MQC and Provider QoS Agreements March 2008 + + + Constraints should be put on l-QC QoS performance parameters to + confine their values to an acceptable and expected level on an l-QC + thread scale. These constraints should depend on domain size; for + example, restrictions on delay should authorize a bigger value for a + national domain than for a regional one. Some rules must therefore + be defined to establish in 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 + + An MQC provides the limits of the QoS parameters two l-QCs must + respect in order to be bound together. A provider goes through + several steps to extend its internal l-QCs through the binding + process. Firstly, it classifies its own l-QCs based on MQCs. An MQC + is used as a label that certifies the support of a set of + applications that bear similar network QoS requirements. It is a + means to make sure that an l-QC has the appropriate QoS + characteristics to convey the traffic of this set of applications. + Secondly, it learns about 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. Thirdly, it contracts an agreement with its + neighbor to send some traffic that will be handled according to the + agreed MQCs. + + The following attributes should be documented in any specification of + an MQC. This is not a closed list, other attributes can be added if + needed. + + o A set of applications (e.g., VoIP) the MQC is particularly suited + for. + + o 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. + + o Constraints on traffic (e.g., only TCP-friendly). + + o Constraints on the ratio: network resources for the class / + overall traffic using this class (e.g., less resources than peak + traffic). + + + + +Levis & Boucadair Informational [Page 10] + +RFC 5160 MQC and Provider QoS Agreements March 2008 + + + 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; 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 + + + +Levis & Boucadair Informational [Page 11] + +RFC 5160 MQC and Provider QoS Agreements March 2008 + + + 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 planes + + Figure 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; therefore, + the number of provider agreements is largely independent of the + + + +Levis & Boucadair Informational [Page 12] + +RFC 5160 MQC and Provider QoS Agreements March 2008 + + + 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 + + Building end-to-end QoS paths, for the purpose of QoS-guaranteed + communications between end-users, is going a step further in the QoS + process. The full description of customer-to-provider QoS + agreements, and the way they are enforced, is outside the scope of + this memo. However, in this section, we will list some important + issues and state whether MQC can help to find solutions. + + Route path selection within a selected MQC plane can be envisaged in + the same way as the traditional routing system used by Internet + routers. Thus, we can rely on the BGP protocol, basically one BGP + occurrence per MQC plane, for the inter-domain routing process. The + resilience of the IP routing system is preserved. If a QoS path + breaks somewhere, the routing protocol enables dynamic computation of + another QoS path, if available, in the proper MQC plane. This + provides a first level of QoS infrastructure that could be + conveniently named "best-effort QoS", even if this is an oxymoron. + + On this basis, features can be added in order to select and control + the QoS paths better. For example, BGP can be used to convey QoS- + related information, and to implement a process where Autonomous + Systems add their own QoS values (D, J, L) when they propagate an AS + path. Then, the AS path information is coupled with the information + on Delay, Jitter, and Loss, and the decision whether or not to use + the path selected by BGP can be made, based on numerical values. For + + + +Levis & Boucadair Informational [Page 13] + +RFC 5160 MQC and Provider QoS Agreements March 2008 + + + example, for destination N, an AS path (X, Y) is advertised to AS Z. + During the propagation of this AS path by BGP, X adds the information + concerning its own delay, say 30 ms, and Y adds the information + concerning its own delay, say 20 ms. Z receives the BGP + advertisement (X, Y, N, 50 ms). One of Z's customers requests 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 that it can use the AS path (X, Y). The + QoS value of an AS path could also be disconnected from BGP and + computed via an off-line process. + + If we use QoS routing, we can incorporate the (D, J, L) information + in the BGP decision process, but that raises the issue of composing + performance metrics in order to select appropriate paths [Chau]. + When confronted by multiple incompatible objectives, the local + decisions made to optimize the targeted parameters could give rise to + a set of incomparable paths, where no path is strictly superior to + the others. The existence of provider-to-provider agreements based + on MQC offers a homogenous view of the QoS parameters, and should + therefore bring coherency, and restrict the risk of such non-optimal + choices. + + A lot of end-to-end services are bi-directional, so one must measure + the composite performance in both directions. Many inter-domain + paths are asymmetric, and usually, some providers involved in the + forward path are not in the reverse path, and vice versa. That means + that no assumptions can be made about the reverse path. Although + MQC-based provider-to-provider agreements are likely to be negotiated + bi-directionally, they allow the inter-domain routing protocol to + compute the forward and the 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 be + a different MQC requirement in the reverse direction than in the + forward direction. To address this problem, we can use application- + level communication between the two parties (customers) involved in + order to specify the QoS requirements in both directions. + + We can go a step further in the control of the path to ensure the + stability of QoS parameters such as, e.g., enforcing an explicit + routing scheme, making use of RSVP-TE/MPLS-TE requests [RFC3209], + before injecting the traffic into an l-QC thread. However, + currently, several problems must be resolved before ready and + operational solutions for inter-domain route pinning, inter-domain + TE, fast failover, and so forth, are available. For example, see the + BGP slow convergence problem in [Kushman]. + + Multicast supports many applications such as audio and video + distribution (e.g., IPTV, streaming applications) with QoS + + + +Levis & Boucadair Informational [Page 14] + +RFC 5160 MQC and Provider QoS Agreements March 2008 + + + requirements. 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 be used to advertise MQC capabilities for multicast source + reachability. If an inter-domain tree that spans several domains + remains in the same MQC plane, it would be possible to benefit from + the consistency and the coherency conferred by MQC. + + Note that the use of some QoS parameters to drive the route selection + process within an MQC plane may induce QoS deterioration since the + best QoS-inferred path will be selected by all Autonomous System + Border Routers (ASBRs) involved in the inter-domain path computation + (i.e., no other available routes in the same MQC plane will have a + chance to be selected). This problem was called the QoS Attribute- + rush (QA-rush) in [Grif]. This drawback may be avoided if all + involved ASes in the QoS chain implement some out-of-band means to + control the inter-domain QoS path consistency (MQC compliance). + + To conclude this section, whatever the protocols we want to use, and + however tightly we want to control QoS paths, MQC is a concept that + can help to resolve problems [WIP], without prohibiting the use of + any particular mechanism or protocol at the data, control, or + management planes. + +8. Security Considerations + + This document describes a framework and not protocols or systems. + Potential risks and attacks will depend directly on the + implementation technology. Solutions to implement this proposal must + detail 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 the 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 are grateful to Brian Carpenter, Jon Crowcroft, and Juergen + Quittek for their helpful comments and suggestions for improving this + document. + + + + + +Levis & Boucadair Informational [Page 15] + +RFC 5160 MQC and Provider QoS Agreements March 2008 + + +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. + + + +Levis & Boucadair Informational [Page 16] + +RFC 5160 MQC and Provider QoS Agreements March 2008 + + + [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. + + + + + + + + + + + + + + + +Levis & Boucadair Informational [Page 17] + +RFC 5160 MQC and Provider QoS Agreements March 2008 + + +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.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Levis & Boucadair Informational [Page 18] + +RFC 5160 MQC and Provider QoS Agreements March 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 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 + + 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. + + + + + + + + + + + + +Levis & Boucadair Informational [Page 19] + |