Network Working Group P. Levis
Request for Comments: 5160 M. Boucadair
Category: Informational France Telecom
March 2008
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)
互联网规模服务质量（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
IESG注释
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.
本RFC不适用于任何级别的互联网标准。IETF不承认任何关于本RFC适用于任何目的的知识，并指出，除了IESG审查与IETF工作的冲突外，发布决定并非基于IETF审查。RFC编辑已自行决定发布本文件。有关更多信息，请参阅RFC 3932。
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.
本备忘录分析了适用于全球支持QoS的互联网的提供商间服务质量（QoS）协议。它定义了与域间QoS模型相关的术语。它提出了一个用元QoS类（MQC）表示的新概念。这一概念可能会推动和联合提供商之间建立QoS域间关系的方式。它为支持QoS的互联网开辟了新的前景，尽可能保持现有尽力而为互联网的开放性。
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 . . . . . . . . . . . . . . . . . . . . . . . . . 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
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.
在IP QoS服务产品中可以区分三个不同的领域。第一个领域是单个域，提供商在其自己的网络边界内提供QoS服务。第二个领域是多个领域，在这些领域中，一小部分具有共同商业利益的提供商合作在其网络聚合的边界内提供QoS服务。第三个很少被提出的领域是因特网，在因特网上，几乎可以从任何来源向任何目的地提供QoS服务。多个域和Internet区域都处理域间方面的问题。然而，它们在许多方面存在显著差异，例如涉及的域数和QoS路径，这对于Internet领域来说是更高和动态的。因此，多个域和互联网领域可能在各自的解决方案中有所不同。本备忘录试图从供应商对供应商协议的角度调查互联网领域。它为支持域间QoS的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.
[MESCAL]提供了一组旨在解决域间QoS问题的解决方案需要满足的要求。这些要求不在本备忘录中复制。请读者参考[MESCAL]，了解有关要求的详细说明。
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.
此备忘录表明，为了可伸缩性，提供商在协商域间QoS协议时，不必关心距离（自治系统）一跳以上的情况。他们应该将协议建立在本地QoS能力和直接邻居的QoS能力之上。该分析引导我们定义与域间QoS模型相关的术语。我们还引入了一个由元QoS类（MQC）表示的新概念，它驱动并联合了在提供者之间建立QoS域间关系的方式。MQC概念的基本原理依赖于对QoS敏感应用程序需求的普遍理解。无论最终用户连接到哪里，他们都会遇到相同的QoS困难，并且可能会向各自的提供商表达非常相似的QoS需求。在全球范围内，面对相同的客户需求，提供商可能会设计和运行类似的网络功能。
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].
MQC将Internet QoS功能简化为一组MQC平面。本备忘录着眼于MQC平面的思想是否有助于解决某些众所周知的具体域间QoS问题。然而，重点是提供商到提供商的QoS协议框架，目的不是为完整的域间QoS系统指定单独的解决方案和协议。有关扩展和概括MQC平面概念的基于并行Internet概念的完整体系结构的讨论，请参阅[AGAVE]。
Note that this document does not specify any protocols or systems.
请注意，本文件未规定任何协议或系统。
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.
为了避免大量的复杂性和可伸缩性问题，我们假设提供者到提供者的QoS协议只针对彼此直接可访问的两个相邻域进行协商。我们还假设，因为它们交换流量，所以这些邻居是BGP[RFC4271]对等方。这种成对对等是合乎逻辑的，因此不仅在物理点到点连接上，而且在Internet交换点（IXP）上也可以支持这种对等，其中许多运营商使用第2层交换机相互连接。
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:
本文件中设想的QoS解决方案是专门适用于全球互联网的解决方案。就互联网范围的解决方案而言，本文件假设：
o Any solutions should apply locally in order to be usable as soon as deployed in a small set of domains.
o 任何解决方案都应该在本地应用，以便在部署到一小部分域后立即可用。
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 任何解决方案都应该是可扩展的，以便允许全球部署到几乎所有的Internet域，并能够在任何和所有最终用户之间建立QoS通信。
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 任何解决方案还应保持尽力而为的服务，由于端到端参数[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.
o 如果请求的QoS中没有路径可用于到达目的地，则必须通过尽力而为服务保持此目的地的可访问性。
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.
本备忘录未对域内流量工程策略及其实施方式提出任何具体要求。提供商可以部署任何技术来确保其自身网络内的QoS。本备忘录仅假设提供商网络内的QoS功能可以表示为本地QoS类（l-QCs）。当穿越一个域时，流量会经历以延迟、抖动和丢包率值为特征的条件，这些值对应于为该域内的流量选择的l-QC。不同供应商的能力可能因部署的l-QCs数量、各自的QoS特征以及实施和设计的方式而有所不同。
(D, J, L)
（D、J、L）
D: one-way transit delay [RFC2679], J: one-way transit delay variation or jitter [RFC3393], and L: packet loss rate [RFC2680].
D：单向传输延迟[RFC2679]，J：单向传输延迟变化或抖动[RFC3393]，L：丢包率[RFC2680]。
Domain
领域
A network infrastructure composed of one or several Autonomous Systems (AS) managed by a single administrative entity.
由单个管理实体管理的一个或多个自治系统（AS）组成的网络基础设施。
IP connectivity service
IP连接服务
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.
IP传输能力以（Destination，D，J，L）元组为特征，其中Destination是一组IP地址，（D，J，L）是到达目的地的QoS性能。
Local-QoS-Class (l-QC)
本地QoS等级（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].
跨单个域的QoS传输能力，其特征是一组由（D，J，L）表示的QoS性能参数。从区分服务[RFC2475]的角度来看，l-QC是每域行为（PDB）[RFC3086]的出现。
L-QC binding
L-QC结合
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传输到另一个l-QC，来自两个相邻域的两个l-QC将绑定在一起。
L-QC thread
L-QC螺纹
Chain of neighboring bound l-QCs.
相邻束缚l-QCs链。
Meta-QoS-Class (MQC)
元QoS类（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.
MQC提供两个l-QC必须遵守的QoS参数值限制，以便绑定在一起。MQC用作证明支持一组具有类似网络QoS要求的应用程序的标签。
Service Provider (SP)
服务提供商（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.
提供Internet连接的实体。本文档假定SP拥有并管理一个称为域的IP网络。有时简称为提供者。
SP chain
SP链
The chain of Service Providers whose domains are used to convey packets for a given IP connectivity service.
服务提供者链，其域用于传送给定IP连接服务的数据包。
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.
本节的目的是通过一种简化和荒谬的证明表明，在互联网服务范围内，提供商对提供商的QoS协议应基于跨单个域的保证。
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
因此，我们基于跨多个域的保证来分析提供商到提供商的QoS协议，并强调其漏洞。在这种情况下，提供商向其相邻提供商提供的基本服务元素称为IP连接服务。它使用SP链的概念。我们首先定义什么是IP连接服务，然后指出
several weaknesses of such an approach, especially the SP chain trap problem that leads to the so-called Internet glaciation era.
这种方法有几个弱点，特别是导致所谓互联网冰川时代的SP链陷阱问题。
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.
IP连接服务是（Destination，D，J，L）元组，其中Destination是一组可从提供服务的提供商的域访问的IP地址，（D，J，L）是从该域到目标的QoS性能。目标通常位于远程域中。
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 --------->
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
图1:IP连接服务
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.
在图1中，提供者SPn为提供者SPn+1提供跨越整个提供者域链（SPn、SPn-1、SPn-2、…、SP1）的QoS级别。SPi表示提供者及其域。图的顶部是面向提供者的视图；有序的提供程序集（SPn、SPn-1、SPn-2、…、SP1）称为SP链。图的底部是面向域的视图。
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.
这种方法将最终用户的需求直接映射到提供商之间的协议。提供商与目的地协商协议，因为他们知道客户已准备好支付到该目的地的QoS保证传输费用。就服务范围而言，供应商之间的协议将类似于客户和供应商之间的协议。例如，在图1中，SPn可以向自己的客户销售它向SPn+1销售的相同IP连接服务。提供商对提供商协议和客户对提供商协议之间没有明确的区别。
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.
为了保证稳定的服务，应形成冗余SP链以到达相同的目的地。当一条SP链不可用时，应选择另一条SP链。在全球QoS互联网的背景下，这将导致大量SP链以及相关协议。
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.
在图1中，如果SPn+1发现IP连接服务中断，它只能针对协议中的法律合作伙伴SPn。如果SPn不承担责任，同样，它只能向SPn-1投诉，以此类推，直到发现有故障的供应商并最终要求其支付服务损失。然后，索赔应该沿着链向后移动，直到SPn支付SPn+1。SP链成为一个责任链。
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?
不幸的是，这一过程在许多情况下容易失败。在适用于互联网的QoS解决方案环境中，SP链可能是动态的，并且涉及大量提供商。参与同一SP链的提供商（彼此并不完全了解）可能在许多领域都是竞争对手；因此，建立信任关系非常困难。许多复杂而关键的问题需要解决：SPn+1将如何向SPn证明QoS级别不是可以扩展到SPn之外的范围的预期级别？找到有罪的域名需要多长时间？SPn是否准备为其不控制且不负责的事情向SPn+1付款？
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.
在图1中，SPn隐式地保证了SPn+1跨越像SPn-2这样的远程域的QoS水平。正如我们在第4.2节中看到的，SP链将增殖。在这种情况下，提供商很可能是众多SP链的一部分。它将看到它所提供的QoS水平得到许多它可能从未听说过的提供商的保证。
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.
给定协议中的任何变更都可能对使用该协议的众多外部协议产生影响。提供商认为，重新谈判或终止其自身协议的自由度受到依赖于它的大量外部（其领域）协议的限制。这就是所谓的“SP链陷阱”问题。此解决方案不适用于全球QoS覆盖，因为它会导致冰川现象，导致QoS基础设施完全僵化，没有人可以重新协商任何协议。
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.
如果支持QoS的Internet被认为是可取的，并且QoS服务可能可从任何目的地或从任何目的地获得，则任何解决方案都必须解决上述弱点和可伸缩性问题，并为提供商对提供商协议找到替代方案。
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.
由于SP链方法的漏洞，我们假设提供商到提供商的QoS协议应基于覆盖单个域的保证。提供者仅保证其邻居具有其自己域的交叉性能。在图2中，提供者SPn仅向提供者SPn+1保证SPn域的QoS性能。本文档的其余部分将说明，这种方法使域间关系更加清晰和简单，比基于SP链的方法更适合于全球QoS互联网。
Provider-
oriented
view /--Agreement--\
+----+ +----+
|SP +-------+SP +
|n+1 | |n |
+----+ +----+
Domain- -----> packet flow
oriented <---->
view Guarantee Scope
Provider-
oriented
view /--Agreement--\
+----+ +----+
|SP +-------+SP +
|n+1 | |n |
+----+ +----+
Domain- -----> packet flow
oriented <---->
view Guarantee Scope
Figure 2: provider-to-provider QoS agreement
图2：提供商到提供商的QoS协议
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.
SP链不存在的简单事实使AS链陷阱问题和相关的冰川威胁消失。
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.
责任问题仅限于一跳距离。提供商仅对其自己的域负责，并由与其有直接合同的所有邻居控制。
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.
当供应商希望与另一供应商签订合同时，主要考虑的是确定其自己域中的哪些l-QC将绑定到相邻下游域中的哪些l-QC。l-QC结合过程成为基本的域间过程。
Upstream Downstream domain domain
上下游域
l-QC21 -----> l-QC11
l-QC21 -----> l-QC11
l-QC22 -----> l-QC12
l-QC22 -----> l-QC12
l-QC23 ----->
l-QC13
l-QC24 ----->
l-QC23 ----->
l-QC13
l-QC24 ----->
Figure 3: l-QC Binding
图3：l-QC绑定
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.
如果一个l-QC绑定到两个（或更多）l-QC，则很难知道数据包应选择哪个l-QC。这可能意味着基于与应用程序流一样精细的粒度在域边界进行流分类。为了可伸缩性，我们假设一个l-QC不应绑定到多个l-QC[Lev]。相反，几个l-QCs可以绑定到同一个l-QC，就像图3中的l-QC23和l-QC24绑定到l-QC13一样。
A provider decides the best match between l-QCs based exclusively on:
供应商完全基于以下因素决定l-QCs之间的最佳匹配：
- What it knows about its own l-QCs;
- 它对自己的l-QCs了解多少；
- What it knows about its neighboring l-QCs.
- 它对邻近的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.
尽管这种单跳、短视的方法，QoS处理的一致性和一致性必须在由相邻绑定的l-QCs形成的l-QC线程上得到保证。离开应用给定l-QC的域的数据包在跨越外部域到达其最终目的地时应经历类似的处理。供应商应将其l-QC与性能最接近的相邻l-QC绑定。l-QC结合标准应沿任何l-QC螺纹稳定。例如，两个提供程序不应绑定两个l-QCs以最小化延迟，而在同一线程上，另外两个提供程序绑定了两个l-QCs以最小化错误。
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).
应对l-QC QoS性能参数施加约束，以将其值限制在l-QC线程规模上可接受和预期的水平。这些约束应取决于域大小；例如，对延迟的限制应该授权一个国家域比一个区域域具有更大的价值。因此，必须定义一些规则，以确定两个l-QCs可以绑定在一起的条件。这些规则由元QoS类（MQC）的概念提供。
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.
MQC提供两个l-QC必须遵守的QoS参数限制，以便绑定在一起。提供者通过绑定过程通过几个步骤扩展其内部l-QCs。首先，它根据MQC对自己的l-QCs进行分类。MQC用作证明支持一组具有类似网络QoS要求的应用程序的标签。这是一种确保l-QC具有适当的QoS特征以传输这组应用程序的流量的方法。其次，它了解其邻居发布的可用MQC。要公布MQC，提供程序必须至少有一个兼容的l-QC，并且应该准备好达成协议，让邻居流量从中受益。第三，它与邻居签订协议，发送一些流量，这些流量将根据商定的MQC进行处理。
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.
以下属性应记录在MQC的任何规范中。这不是一个封闭列表，如果需要，可以添加其他属性。
o A set of applications (e.g., VoIP) the MQC is particularly suited for.
o MQC特别适合的一组应用程序（如VoIP）。
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 需要时，一组QoS性能属性的边界或间隔。为了便于说明，我们建议在本文档中使用属性（D，J，L）3元组。MQC可以专注于单个参数（例如，适用于传输延迟敏感流量）。还可以根据网络提供商的大小指定几个级别；例如，与大型域（例如国家域）相比，小型域（例如区域域）需要更低的延迟来匹配给定的MQC。
o Constraints on traffic (e.g., only TCP-friendly).
o 流量限制（例如，仅TCP友好）。
o Constraints on the ratio: network resources for the class / overall traffic using this class (e.g., less resources than peak traffic).
o 比率限制：使用该类别的类别/总流量的网络资源（例如，资源少于峰值流量）。
Two l-QCs can be bound together if, and only if, they conform to the same MQC.
当且仅当两个l-QCs符合相同的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.
根据MQC协商协议的两个提供商必须就MQC定义之外的几个其他参数达成一致。其中一个明显的参数是带宽。两个提供商同意交换高达给定级别的QoS流量。然后可以在同一MQC协议内进一步重新协商该带宽级别，以反映最终用户QoS请求的增加。域间协议的其他条款可能包括服务的可用性、维修时间等。
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.
可以为给定类型的服务定义MQC的层次结构（例如，具有不同质量的VoIP：住宅VoIP和商业VoIP）。给定的l-QC可以适用于多个MQC（即使在同一层次结构之外）。同一域中的多个l-QCs可归类为属于同一MQC。有一个没有特定约束的MQC称为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.
需要某种形式的标准化来控制提供商之间的QoS协议[RFC3387]。每个提供程序必须对给定的MQC有相同的理解。我们需要一套MQC标准的全球协议。要定义的类的数量必须保持非常小，以避免过于复杂。我们还需要一种方法来证明供应商的l-QC分类符合MQC标准。因此，标准化工作应该伴随着对一致性测试需求的调查。
The three notions of PDB, Service Class [RFC4594], and MQC are related; what MQC brings is the inter-domain aspect:
PDB、服务类[RFC4594]和MQC的三个概念是相关的；MQC带来的是域间方面：
- PDB is how to engineer a network;
- PDB是如何设计网络；
- Service Class is a set of traffic with specific QoS requests;
- 服务类是一组具有特定QoS请求的流量；
- 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
- MQC是一种对QoS能力进行分类的方法（l-QCs，通过Diffserv或任何其他协议或机制），以便与邻居达成协议。只有当提供程序
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.
希望与邻近供应商协商协议。只要达到MQC QoS属性（例如，（D，J，L））值，MQC就完全不关心网络的设计方式。
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.
由此产生的QoS Internet可以看作是一组并行Internet或MQC平面。每个平面由根据相同MQC绑定的所有l-QCs组成。MQC平面可以有洞和隔离的域，因为QoS功能并不覆盖所有Internet域。当l-QC映射到多个MQC时，它可能属于多个平面。
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.
当一个提供程序基于MQC的使用与另一个提供程序签订合同时，它只是向相应的MQC平面添加一个逻辑链接。这基本上就是当前传统的域间协议对现有互联网的意义。图4a）描述了部分互联网的物理布局，包括四个具有全网状连接的域。
+----+ +----+ +----+ +----+
|SP +----+SP | |SP +----+SP |
|1 | |2 | |1 | |2 |
+-+--+ +--+-+ +-+--+ +----+
| \ / | | /
| \/ | | /
| /\ | | /
| / \ | | /
+-+--+ +--+-+ +-+--+ +----+
|SP +----+SP | |SP | |SP |
|4 | |3 | |4 | |3 |
+----+ +----+ +----+ +----+
a) physical configuration b) an MQC plane
+----+ +----+ +----+ +----+
|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
图4:MQC平面
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.
图4b）描述了这四个域如何参与给定的MQC平面。SP1、SP2和SP4对此MQC至少有一个兼容的l-QC；SP3可能有也可能没有。SP1和SP2、SP1和SP4、SP2和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
MQC明确区分了提供者到提供者和客户到提供者的QoS协议。我们预计两者在活力上会有很大的不同。在最终用户可以动态请求端到端担保之前，大多数提供商到提供商协议都应该经过协商，并且应该保持稳定。供应商协议不直接反映最终用户的需求；因此，提供商协议的数量在很大程度上独立于
number of end-user requests and does not increase as dramatically as with SP chains.
最终用户请求的数量不会像SP链那样急剧增加。
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.
对于基于QoS的全局Internet，只有当基于MQC的绑定被广泛接受并成为当前的做法时，此解决方案才会起作用。此限制是由于服务本身的性质，而不是MQC的使用。就我们的目标全球服务而言，我们必须在尽可能多的SP域中提供QoS。但是，Internet上任何支持MQC的组成连接图的部分都可以用于QoS通信，并且可以扩展。因此，增量部署是可能的，并带来增量好处。例如，在图4b）中，只要SP3连接到MQC平面，它就能够从SP1、SP2和SP4QoS功能中获益。
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.
Internet作为不同MQC平面的一部分，提供了Internet QoS功能的有序和简化视图。最终用户可以选择最接近其需要的MQC平面，只要目标有可用的路径。应用MQC概念的主要结果之一是，它减轻了域间关系的复杂性和管理负担。
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.
为了最终用户之间的QoS保证通信，构建端到端QoS路径是QoS过程中的又一步。客户到提供商的QoS协议及其实施方式的完整描述不在本备忘录的范围内。但是，在本节中，我们将列出一些重要问题，并说明MQC是否有助于找到解决方案。
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.
所选MQC平面内的路由路径选择可以设想为与Internet路由器使用的传统路由系统相同的方式。因此，对于域间路由过程，我们可以依赖BGP协议，基本上每个MQC平面出现一个BGP。IP路由系统的弹性得以保持。如果某个QoS路径在某个地方中断，则路由协议支持在适当的MQC平面中动态计算另一个QoS路径（如果可用）。这提供了一个第一级的QoS基础设施，可以方便地命名为“尽力而为的QoS”，即使这是一个矛盾修饰法。
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
在此基础上，可以添加特征，以便更好地选择和控制QoS路径。例如，BGP可用于传送QoS相关信息，并实现自治系统在传播AS路径时添加其自己的QoS值（D、J、L）的过程。然后，AS路径信息与关于延迟、抖动和损耗的信息耦合，并且可以基于数值做出是否使用BGP选择的路径的决定。对于
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.
例如，对于目的地N，AS路径（X，Y）被播发到AS Z。在BGP传播该AS路径期间，X添加关于其自身延迟的信息，例如30ms，Y添加关于其自身延迟的信息，例如20ms。Z接收BGP播发（X，Y，N，50ms）。Z的一个客户请求延迟100毫秒到达N。Z知道该客户自己的延迟，比如20毫秒。Z计算了客户到N:70毫秒的预期最大延迟，并得出结论，它可以使用AS路径（X，Y）。AS路径的QoS值也可以从BGP断开，并通过离线过程计算。
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.
如果我们使用QoS路由，我们可以将（D，J，L）信息合并到BGP决策过程中，但这就提出了组合性能指标的问题，以便选择合适的路径[Chau]。当面对多个不兼容的目标时，为优化目标参数而做出的局部决策可能会产生一组不兼容的路径，其中没有一条路径严格优于其他路径。基于MQC的提供者到提供者协议的存在提供了QoS参数的同质视图，因此应该带来一致性，并限制此类非最佳选择的风险。
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.
许多端到端服务是双向的，因此必须在两个方向上测量组合性能。许多域间路径是不对称的，通常，前向路径中涉及的一些提供者不在反向路径中，反之亦然。这意味着不能对反向路径进行任何假设。尽管基于MQC的提供者到提供者协议可能是双向协商的，但它们允许域间路由协议像往常一样分别计算正向和反向路径。MQC对路由设置的唯一约束是，所选路径必须在整个所选域中使用所选MQC。相反方向的MQC需求可能与正向不同。为了解决这个问题，我们可以在涉及的双方（客户）之间使用应用程序级通信，以便在两个方向上指定QoS需求。
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].
我们可以进一步控制路径，以确保QoS参数的稳定性，例如，在将流量注入l-QC线程之前，实施显式路由方案，利用RSVP-TE/MPLS-TE请求[RFC3209]。但是，目前，在提供域间路由固定、域间TE、快速故障切换等就绪且可操作的解决方案之前，必须解决几个问题。例如，参见[Kushman]中的BGP缓慢收敛问题。
Multicast supports many applications such as audio and video distribution (e.g., IPTV, streaming applications) with QoS
多播支持许多具有QoS的应用，如音频和视频分发（例如IPTV、流媒体应用）
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.
要求。与IP或应用程序级别的解决方案（如前向纠错（FEC））一起，具有BGP-4[RFC4760]多协议扩展的域间多播路由协议可用于宣传多播源可达性的MQC功能。如果跨多个域的域间树保持在同一MQC平面中，则可以受益于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).
注意，使用一些QoS参数来驱动MQC平面内的路由选择过程可能导致QoS恶化，因为参与域间路径计算的所有自治系统边界路由器（asbr）将选择最佳QoS推断路径（即，同一MQC平面中没有其他可用路由有机会被选择）。此问题在[Grif]中称为QoS属性rush（QA rush）。如果QoS链中所有涉及的ASE都实现一些带外方法来控制域间QoS路径一致性（MQC符合性），则可以避免此缺点。
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.
在本节结束时，无论我们希望使用何种协议，也不管我们希望如何严格控制QoS路径，MQC都是一个可以帮助解决问题[WIP]的概念，而不禁止在数据、控制或管理平面上使用任何特定的机制或协议。
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].
应特别注意仅允许授权通信量访问MQC资源。当网络资源过度使用时，未经授权的访问可能导致拒绝服务[RFC3869]。
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.
这项工作由欧盟委员会在MESCAL（整个互联网的端到端服务质量管理）和AGAVE（可行的基于IP的端到端QoS服务的轻量级方法）项目的背景下资助。作者要感谢所有其他合作伙伴的富有成果的讨论。
We are grateful to Brian Carpenter, Jon Crowcroft, and Juergen Quittek for their helpful comments and suggestions for improving this document.
我们感谢Brian Carpenter、Jon Crowcroft和Juergen Quitek对改进本文件提出的有用意见和建议。
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2679]Almes，G.，Kalidini，S.，和M.Zekauskas，“IPPM的单向延迟度量”，RFC 2679，1999年9月。
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999.
[RFC2680]Almes，G.，Kalidini，S.，和M.Zekauskas，“IPPM的单向数据包丢失度量”，RFC 2680，1999年9月。
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002.
[RFC3393]Demichelis，C.和P.Chimento，“IP性能度量的IP数据包延迟变化度量（IPPM）”，RFC 3393，2002年11月。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271]Rekhter，Y.，Ed.，Li，T.，Ed.，和S.Hares，Ed.，“边境网关协议4（BGP-4）”，RFC 42712006年1月。
[AGAVE] Boucadair, et al., "Parallel Internets Framework", IST AGAVE project public deliverable D1.1, September 2006.
[AGAVE]Boucadair等人，“平行互联网框架”，IST AGAVE项目公共交付成果D1.12006年9月。
[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.
[Chau]Chau，C.，“具有非严格偏好的基于策略的路由”，ACM SIGCOMM 2006计算机通信应用、技术、架构和协议会议记录，意大利比萨，第387-398页，2006年9月。
[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.
[E2E]Saltzer，J H.，Reed，D P.，和D D.Clark，“系统设计中的端到端参数”，《计算机系统中的ACM交易》，第2卷，第4期，第277-288页，1984年11月。
[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.
[Grif]Griffin，D.，Spencer，J.，Griem，J.，Boucadair，M.，Morand，P.，Howarth，M.，Wang，N.，Pavlou，G.，Asgari，A.，和P.Georgatsos，“通过QoS类平面的域间路由[异构网络基于服务质量的路由算法]”，IEEE通信杂志，第45卷，第2期，第88-95页，2007年2月。
[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.
[库什曼]库什曼，N.，坎杜拉，S.，和D.卡塔比，“你现在能听到我说话吗？一定是BGP”，ACM计算机与通信评论杂志CCR，2007年11月。
[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.
[Lev]Levis，P.，Asgari，H.，和P.Trimintzios，“通过乌托邦方法考虑域间QoS和流量工程问题”，ICT-2004的SAPIR-2004研讨会，（C）Springer Verlag，2004年8月。
[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.
[MESCAL]Flegkas等人，“域间QoS交付的业务模型和功能架构规范”，IST MESCAL项目公共交付成果D1.1，2003年5月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.，和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[RFC3086] Nichols, K. and B. Carpenter, "Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification", RFC 3086, April 2001.
[RFC3086]Nichols，K.和B.Carpenter，“每域区分服务行为的定义及其规范规则”，RFC 3086，2001年4月。
[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.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[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.
[RFC3387]Eder，M.，Chaskar，H.，和S.Nag，“服务管理研究小组（SMRG）对IP网络服务质量（QoS）的考虑”，RFC 3387，2002年9月。
[RFC3869] Atkinson, R., Ed., Floyd, S., Ed., and Internet Architecture Board, "IAB Concerns and Recommendations Regarding Internet Research and Evolution", RFC 3869, August 2004.
[RFC3869]Atkinson，R.，Ed.，Floyd，S.，Ed.，和互联网架构委员会，“IAB对互联网研究和发展的关注和建议”，RFC 3869，2004年8月。
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, August 2006.
[RFC4594]Babiarz，J.，Chan，K.，和F.Baker，“区分服务服务类的配置指南”，RFC 45942006年8月。
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[RFC4760]Bates，T.，Chandra，R.，Katz，D.，和Y.Rekhter，“BGP-4的多协议扩展”，RFC 4760，2007年1月。
[WIP] Deleuze, G. and F. Guattari, "What Is Philosophy?", Columbia University Press ISBN: 0231079893, April 1996.
[WIP]Deleuze，G.和F.Guattari，“什么是哲学？”，哥伦比亚大学出版社ISBN:0231079893，1996年4月。
Authors' Addresses
作者地址
Pierre Levis France Telecom 42 rue des Coutures BP 6243 Caen Cedex 4 14066 France
Pierre Levis法国电信公司42 rue des Coutures BP 6243 Caen Cedex 4 14066法国
EMail: pierre.levis@orange-ftgroup.com
EMail: pierre.levis@orange-ftgroup.com
Mohamed Boucadair France Telecom 42 rue des Coutures BP 6243 Caen Cedex 4 14066 France
Mohamed Boucadair法国电信公司（42 rue des Coutures BP 6243 Caen Cedex 4 14066法国）
EMail: mohamed.boucadair@orange-ftgroup.com
EMail: mohamed.boucadair@orange-ftgroup.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（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.
本文件受BCP 78和http://www.rfc-editor.org/copyright.html，除本协议另有规定外，提交人保留其所有权利。
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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.