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
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はインターネットStandardのどんなレベルの候補ではありません。 IETFは、いかなる目的のために、このRFCのフィットネスの知識を否認し、公開する決定がIETF仕事との競合のためのIESGレビューとは別にIETFレビューに基づいていないことを指摘しています。 RFC Editorはその裁量でこの文書を公開することを選択しました。詳細については、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（Quality of Service）を契約を分析します。これは、ドメイン間の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
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サービスを提供するために協働する複数のドメインです。めったに前方に置かれていない第3の領域は、QoSサービスは、任意の宛先まで、ほぼすべてのソースから配信することができ、インターネットです。複数のドメインとインターネット領域の両方は、ドメイン間の側面に対処します。しかし、彼らは、インターネット領域のはるかに高く、動的で関与するドメインおよびQoSパスの数などの多くの点で大きく異なります。複数のドメインとインターネット領域は、したがって、それぞれのソリューションが異なる可能性があります。このメモは、プロバイダ・ツー・プロバイダ契約の観点から、インターネット面積を調査しようとする試みです。これは、ドメイン間のQoS対応のインターネットのためのフレームワークを提供します。
[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.
[メスカル]はドメイン間のQoSの問題を解決することを目指してすべてのソリューションが満たすべき要件のセットを提供します。これらの要件は、このメモの中に再現されていません。読者は、要件の詳細精巧な説明については、[メスカル]を参照するために招待されています。
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）で示される新しい概念を導入します。 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は、MQCの平面の集合としてインターネットQoS機能の簡略図が表示されます。このメモはMQC面のアイデアは、特定のよく知られたコンクリートのドメイン間のQoSの問題に役立つことができるかどうかを調べます。焦点は、しかし、プロバイダ・ツー・プロバイダのQoS協定の枠組みの上にあり、かつ意図は、完全なドメイン間のQoSシステムのための個別のソリューションとプロトコルを指定することではありません。 MQCプレーンの概念を拡張し、一般化平行なインターネットの概念に基づいて、完全なアーキテクチャの議論については、[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契約のみが相互に直接アクセス可能な2つの隣接するドメインのために交渉していることを前提としています。彼らは、トラフィックを交換するので、我々はまた、これらの隣人は、BGP [RFC4271]ピアであることを、前提としています。このペアワイズピアリングは、したがって、それは物理的ポイントツーポイント接続ではなく、多くのオペレータは、レイヤ2スイッチを使用して相互に接続するインターネットエクスチェンジ（のIXP）、だけでなく支持することができる、論理的です。
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任意のソリューションは、あらゆるエンドユーザーの間での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.
宛先に到達するために要求されたQoS内で利用可能なパスがない場合は、O、この先はベストエフォート型のサービスを通じて到達可能でなければなりません。
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-のQC）のように表すことができる唯一のことを前提としています。ドメインを横断するとき、トラフィックの経験の条件は、そのドメイン内のそのトラフィックのために選択され、L-QCに対応する遅延、ジッタ、パケット損失率の値によって特徴付けられます。機能は、展開L-のQCの数によって、それぞれの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.
ネットワークインフラストラクチャは、単一の管理エンティティによって管理される1つのまたは複数の自律システム（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アドレスと（D、J、L）の基である（先、D、J、L）の組によって特徴付けIP転送能力は、宛先に到達するの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].
（D、J、L）で表されるQoSの性能パラメータのセットによって特徴付けられる単一ドメイン全体のQoS転送能力、。 Diffservの[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.
2つのプロバイダが他に1リットル-QCからのトラフィックを転送することに合意した後、隣接する二つのドメインから2つのLのQCは、一緒にバインドされています。
L-QC thread
L-QCのスレッド
Chain of neighboring bound l-QCs.
隣接する結合したL-のQCのチェーン。
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は、一緒に結合させるために尊重しなければならない2つの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.
インターネット接続を提供するエンティティ。この文書では、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 several weaknesses of such an approach, especially the SP chain trap problem that leads to the so-called Internet glaciation era.
したがって、我々はいくつかのドメインにまたがる、その脆弱性を強調保証に基づくプロバイダ・ツー・プロバイダのQoS契約を分析します。この場合、プロバイダはその隣接プロバイダに提供しています基本的なサービス要素は、IP接続サービスと呼ばれています。これは、SPチェーンの概念を使用しています。私たちは、最初のIP接続サービスとは何かを定義し、我々はこのようなアプローチ、いわゆるインターネットの氷河時代につながる特に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接続サービスは、宛先がIPのグループがサービスを提供するプロバイダのドメインから到達可能なアドレスであり、（D、J、L）をから取得するためのQoSの性能である（デスティネーション、D、J、L）のタプルであります先にこのドメイン。宛先は、通常、リモートドメインに位置しています。
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チェーンは、同じ目的地に到達するために形成されるべきです。 1つの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.
SPnの+ 1は、IP接続サービスの中断を見れば、図1では、それだけで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は、QoSレベルが十分SPnを超えて拡大することができる範囲に予想されるレベルではないことを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対応インターネットがあらゆる目的地へとから潜在的に利用可能な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
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.
責任問題は、1ホップの距離に制限されています。プロバイダは、独自のドメインに責任がある、それが直接契約している人とすべてのネイバーによって制御されます。
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（s）はこれに結合する、独自のドメイン内のどのリットル-QC（S）決定されます。 L-QC結合プロセスは、基本的なドメイン間プロセスになります。
Upstream Downstream
domain domain
l-QC21 -----> l-QC11
l-QC22 -----> l-QC12
l-QC23 ----->
l-QC13
l-QC24 ----->
Figure 3: l-QC Binding
図3：1- 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.
1リットル-QCは、2つ（またはそれ以上）、L-のQCにバインドするとしたら、パケットが選択すべきリットル-QC知ることは非常に困難であろう。これは、アプリケーション・フローのように細かい粒度に基づいてドメインの境界にフロー分類を意味することができます。スケーラビリティのために、我々は1リットル-QCは、いくつかのL-のQC [レフ]にバインドするべきではないと仮定します。逆に、いくつかのL-のQCは、L QC23およびL- QC24は、図3中のL- QC13に結合されているような方法で、同じL-QCに結合することができます。
A provider decides the best match between l-QCs based exclusively on:
プロバイダは、のみに基づいて、L-のQC間のベストマッチを決定します：
- What it knows about its own l-QCs;
- それは、独自のL-のQCについて知っていること。
- What it knows about its neighboring l-QCs.
- それはその隣接L-のQCについて知っている何を。
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.
この1ホップ、近視眼的なアプローチにもかかわらず、一貫性及びQoS処理のコヒーレンシは、隣接する結合したL字のQCによって形成されたL-QCスレッドで確保しなければなりません。彼らの最終的な宛先に外部ドメインを横断する際に与えられたL-QCを適用するドメインを出るパケットは、同様の治療を経験する必要があります。プロバイダは、最も近い性能を有し、隣接するL-QCとそのL-QCに結合するべきです。結合L-QCの基準は、任意のL-QC糸に沿って安定であるべきです。例えば、2つのプロバイダは、さらに上で、同じスレッド上で、二つの他のプロバイダがエラーを最小限にするために2つのLのQCに結合したのに対し、遅延を最小限にするために2つのLのQCに結合するべきではありません。
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スレッドスケールで許容され、期待されるレベルにまでその値を制限するために、L-QCのQoS性能パラメータに置くべきです。これらの制約は、ドメインの大きさに依存すべきです。例えば、遅延の制限は、地域1よりも国民のドメインのためのより大きな値を承認すべきです。いくつかのルールは、したがって、2リットル-のQCが一緒に結合され得る条件で確立することを定義する必要があります。これらのルールは、メタの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は、QoSの限界は、2つのLのQCが一緒に結合するために尊重しなければならないパラメータ提供します。プロバイダは、結合プロセスを通じて内部L-のQCを拡張するためにいくつかのステップを経ます。第一に、それはMQCsをもとに、独自のL-のQCを分類します。 MQCは、同様のネットワークQoS要件を負担するアプリケーションのセットのサポートを証明するラベルとして使用されています。 L-QCは、アプリケーションのこのセットのトラフィックを伝えるために、適切なQoS特性を持っていることを確認するための手段です。第二に、それはその隣人によって広告利用できるMQCsについて学習します。 MQCを宣伝するために、プロバイダは、少なくとも一つの対応リットル-QCを持っている必要がありますし、そこから隣接トラフィックの利益をできるように合意に達するために準備する必要があります。第三に、それは合意された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.
以下の属性は、MQCのいずれかの仕様で文書化されなければなりません。これは、閉じたリストではありません必要に応じて、他の属性を追加することができます。
o A set of applications (e.g., VoIP) the MQC is particularly suited for.
アプリケーションのセット（例えば、VoIPの）O MQCは特に適しています。
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.
2つのL-QCがあれば一緒にバインドすることができ、そして、彼らは同じ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に基づく契約を交渉2つのプロバイダは、MQCの定義の外にあるいくつかの他のパラメータに同意する必要があります。そのような明白なパラメータでは、帯域幅です。 2つのプロバイダは、QoSトラフィックの特定のレベルまで交換することに同意します。この帯域幅レベルは、さらに、エンドユーザーのQoS要求の増加を反映して、同じMQC協定の内側に、再交渉することができます。ドメイン間の契約の他の条項は、サービスの可用性、修理の時間などをカバーできます
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.
MQCsの階層は、サービスの特定の種類（：ビジネスのための住宅およびVoIPのためのVoIPの異なる品質を持つ例えば、VoIP）のために定義することができます。所定のL-QCは、（たとえ同じ階層の外側に）いくつかのMQCsに適し得ます。同じドメイン内のいくつかのL-QCは同じMQCに属するものとして分類することができます。 MQCは、ベストエフォート型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.
プロバイダー[RFC3387]の間のQoS契約を制御するために、標準化のいくつかのフォームが必要です。各プロバイダは、与えられた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 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は隣人との合意に到達するために（Diffservのまたは任意の他のプロトコルまたはメカニズムを介して、L-のQC）QoS機能を分類する方法です。 MQCsは唯一のプロバイダは、隣接プロバイダとの契約を交渉したいときに関与しています。 MQCは、ネットワークがあれば、MQCのQoS属性（例えば、（D、J、L））の値に達したとして操作されるように完全に無関心です。
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インターネットは、平行なインターネット又はMQC平面の集合と見なすことができます。各プレーンは、同じMQCに係るバインドされたすべてのL-のQCから成ります。 QoS機能は、すべてのインターネットドメインをカバーしていないので、MQC面は穴や孤立したドメインを持つことができます。 L-QCは、いくつかのMQCsにマップするとき、それはいくつかのプレーンに潜在的に属します。
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.
別のプロバイダとプロバイダ契約がMQCsの使用に基づいた場合、それは単に、対応するMQC面への論理リンクを追加します。これは、現在の伝統的なドメイン間の契約は、既存のインターネットのために何を意味するかは基本的です。図4a）フルメッシュ接続性を有する4つのドメインを含む、インターネットの画分の物理的なレイアウトを示しています。
+----+ +----+ +----+ +----+
|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.
図4のB）は、これらの4つのドメインが所定MQC面に関与している方法を示しています。 SP1、SP2、およびSP4このMQCのための少なくとも一つの対応L-QCを有します。 SP3は、または1つを持っていない可能性があります。双方向契約は、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 number of end-user requests and does not increase as dramatically as with SP chains.
MQCは、プロバイダ・プロバイダへと顧客への提供のQoS契約の間に明確な区別をもたらします。我々は2つの間の動的性の違いを大いに期待しています。エンドユーザーが動的にエンドツーエンドの保証を要求することができます前に、ほとんどのプロバイダ・ツー・プロバイダ契約は、交渉されている必要があり、安定したままにしてください。プロバイダ契約は、直接エンドユーザーのニーズをマップしません。そのため、プロバイダ契約数は、エンドユーザーの要求の数にほとんど依存しないと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ベースのインターネットでは、このソリューションは、結合MQCベースの場合にのみ動作します、主に受け入れられ、現在の練習になります。この制限は、サービス自体の性質、およびないMQCsの使用によるものです。私たちはグローバルなサービスを対象として、限り、我々はできるだけ多くのSPのドメインでQoSを提供するためにバインドされています。しかし、連結グラフを形成するインターネットの任意MQC対応部分は、QoS通信のために使用することができ、拡張することができます。したがって、増分の展開が可能となり、インクリメンタルな利益につながります。例えば、図4 B）に、できるだけ早くSP3は、MQC面に接続するように、SP1、SP2、およびSP4のQoS機能の恩恵を受けることができるであろう。
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.
インターネットは、異なるMQC面の分割として、インターネット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面内経路の経路選択は、インターネットルータによって使用される従来のルーティングシステムと同様に考えることができます。したがって、我々は、ドメイン間ルーティング処理のため、BGPプロトコル、MQC面あたり、基本的には、1つの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 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.
これに基づき、機能がより良いQoSのパスを選択し、制御するために追加することができます。例えば、BGPは、QoS関連情報を伝達するために、それらがAS経路を伝播するとき自律システムは、独自のQoS値（D、J、L）を追加プロセスを実施するために使用することができます。次に、ASパス情報は、遅延、ジッタ、および損失の情報と結合され、BGPによって選択されたパスを使用するかどうかの決定は、数値に基づいて、行うことができます。例えば、宛先Nのために、ASパス（X、Y）はBGPによって経路AS本の伝播中Zとに通知され、Xは、それ自身の遅延に関する情報を追加し、30ミリ秒と言う、そしてYがに関する情報を付加します独自の遅延は、20ミリ秒を言います。 Zは、BGP広告（X、Y、N、50ミリ秒）を受信します。 Zの顧客の一つがN Zは、この顧客のために独自の遅延を知って到達するために100ミリ秒の遅延を要求し、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ルーティングを使用する場合、我々は、BGP決定プロセスにおいて（D、J、L）情報を組み込むことができるが、それは適切なパス[チャウ]を選択するために構成するパフォーマンス・メトリックの問題を提起します。複数の互換性のない目的で直面したとき、対象のパラメータを最適化するために作られた地元の意思決定にはパスが他の人に厳密に優れていない比類のないパスのセットに上昇を与えることができます。 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.
1は、両方向の複合パフォーマンスを測定しなければならないので、エンドツーエンドのサービスの多くは、双方向です。多くのドメイン間のパスが非対称であり、通常は、フォワード経路に関与し、いくつかのプロバイダは逆の経路、およびその逆ではありません。それは何の仮定が逆の経路について行うことはできないことを意味します。 MQCベースのプロバイダからプロバイダ契約が双方向にネゴシエートされる可能性があるが、それらは、ドメイン間ルーティングプロトコルは、通常通り、別々に順方向および逆方向経路を計算することを可能にします。 MQCは、ルーティングに置く唯一の制約は、選択された経路が選択されたドメイン全体選ばMQCsを使用しなければならないということです。順方向よりも逆方向に異なるMQCの必要があるかもしれません。この問題に対処するために、我々は両方の方向でのQoS要件を指定するために関与する2つの当事者（顧客）との間にアプリケーションレベルの通信を使用することができます。
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].
私たちは、にトラフィックを注入する前に、RSVP-TE / MPLS-TE要求[RFC3209]を利用して、明示的なルーティング方式を実施する、例えば、などのQoSパラメータの安定性を確保するために、パスの制御にさらに一歩行くことができますL-QC糸。しかし、現在、いくつかの問題は、ドメイン間のルートピニング、ドメイン間TE、高速フェイルオーバーのための準備と運用ソリューション前に解決しなければならない、など、ご利用いただけます。たとえば、[Kushman]でBGP遅い収束の問題を参照してください。
Multicast supports many applications such as audio and video distribution (e.g., IPTV, streaming applications) with QoS 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.
マルチキャストは、QoS要件と、オーディオおよびビデオ配信（例えば、IPTV、ストリーミングアプリケーション）など、多くのアプリケーションをサポートしています。このような前方誤り訂正（FEC）、BGP-4 [RFC4760]のためのマルチプロトコル拡張を有するドメイン間マルチキャストルーティングプロトコルとしてIPまたはアプリケーションレベルでの解決策とともに、マルチキャストソースの到達可能性のための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).
（MQC平面内経路選択プロセスを駆動するために、いくつかのQoSパラメータの使用は、ドメイン間経路計算に関係するすべての自律システム境界ルータ（のASBR）によって選択される最良のQoS-推論パス以降のQoS劣化を引き起こす可能性がありますすなわち、同じMQC面には他の利用可能なルートが）選択する機会を持っていません。 [GRIF]でこの問題は、QoS属性ラッシュ（QA-ラッシュ）と呼ばれていました。 QoSのチェーンのすべての関与のASは、いくつかのアウトオブバンドを実装する場合は、この欠点を回避することができるドメイン間の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.
この作品は、メスカル（大型で、インターネット経由でエンドツーエンドサービス品質の管理）とAGAVE（生存エンドツーエンドのIPベースのQoSサービスのための軽量のアプローチの文脈の中で、欧州委員会によって資金を供給されます）プロジェクト。著者は、実りある議論のための他のすべてのパートナーに感謝したいと思います。
We are grateful to Brian Carpenter, Jon Crowcroft, and Juergen Quittek for their helpful comments and suggestions for improving this document.
私たちは、この文書を改善するための彼らの役に立つコメントと提案のためのブライアン・カーペンター、ジョンクロウクロフト、およびユルゲンQuittekに感謝しています。
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2679] Almes、G.、Kalidindi、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.、Kalidindi、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]デミチェリス、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.、エド。、李、T.、エド。、およびS.野兎、編、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 4271、2006年1月。
[AGAVE] Boucadair, et al., "Parallel Internets Framework", IST AGAVE project public deliverable D1.1, September 2006.
[AGAVE] Boucadairらは、 "パラレルインターネットの枠組み"、IST AGAVEプロジェクト公共成果のD1.1、2006年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.
[チャウ]チャウ、C.、「非厳格な好みにポリシーベースルーティング」、コンピュータ通信、ピサ、イタリア、頁387から398のためのアプリケーション、技術、アーキテクチャ、およびプロトコル上のACM SIGCOMM 2006会議議事録、9月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.
[E2E] Saltzer、J H.、リード、D P.、およびD D.クラーク、 "システム設計におけるエンド・ツー・エンドの引数"、コンピュータシステムズ、第2巻、ナンバー4、頁277-288、中ACM取引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]グリフィン、D.、スペンサー、J.、Griem、J.、Boucadair、M.、モラン、P.、ハワース、M.、王、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.
[Kushman] Kushman、N.、Kandula、S.、およびD. Katabiは、コンピュータとコミュニケーションレビューCCR、2007年11月のACMジャーナル "あなたはそれがBGPである必要がある！今私を聞くことができます"。
[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.
[レフ]リーバイス、P.、Asgari、H.、およびP. Trimintzios、 "ユートピアアプローチを通じてドメイン間のQoSおよびトラフィックエンジニアリングの問題についての一考察"、ICT-2004のサピア-2004ワークショップ、（C）シュプリンガー・フェアラーク、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.
[メスカル] Flegkas、ら、「ビジネスモデルの仕様とドメイン間のQoS配信のための機能アーキテクチャ」、ISTメスカルプロジェクト公共成果の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]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.、およびW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。
[RFC3086] Nichols, K. and B. Carpenter, "Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification", RFC 3086, April 2001.
[RFC3086]ニコルズ、K.とB.大工、「自分仕様のための差別化サービスドメイン単位の行動とルールの定義」、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.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：LSPトンネルのためのRSVPの拡張"、RFC 3209年12月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.
[RFC3387]エダー、M.、Chaskar、H.、およびS.ナグ、RFC 3387、2002年9月 "サービス品質IPネットワーク内（QoS）の上のサービス管理研究グループ（SMRG）からの注意事項"。
[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]アトキンソン、R.、エド。、フロイド、S.、エド。、およびインターネットアーキテクチャ委員会、 "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.、チャン、K.、およびF.ベイカー、 "DiffServのサービスクラスの設定時の注意事項"、RFC 4594、2006年8月。
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[RFC4760]ベイツ、T.、チャンドラ、R.、カッツ、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]ドゥルーズ、G.およびF.ガタリは、 "哲学とは何ですか？"、コロンビア大学出版ISBN：0231079893、1996年4月。
Authors' Addresses
著者のアドレス
Pierre Levis France Telecom 42 rue des Coutures BP 6243 Caen Cedex 4 14066 France
ピエール・リーバイスフランステレコムBP 42 RUEのCoutures 6243カーンセデックス4 14066フランス
EMail: pierre.levis@orange-ftgroup.com
メールアドレス：pierre.levis@orange-ftgroup.com
Mohamed Boucadair France Telecom 42 rue des Coutures BP 6243 Caen Cedex 4 14066 France
モハメド・BoucadairフランステレコムBP 42 RUEのCoutures 6243カーンセデックス4 14066フランス
EMail: mohamed.boucadair@orange-ftgroup.com
メールアドレス：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。