[要約] 要約：RFC 5160は、インターネット規模のサービス品質（QoS）のためのプロバイダ間契約に関する考慮事項を提供しています。 目的：このRFCの目的は、インターネットサービスプロバイダ間の契約におけるQoSの実装に関するガイドラインを提供することです。
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のフィットネスに関する知識を放棄し、公開する決定はIETFワークとの競合に関するIESGレビューとは別に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モデルに関連する用語を定義します。Meta-Qos-Class（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サービスの提供では、3つの異なる領域を区別できます。最初の領域は、プロバイダーが独自のネットワークの境界内にQoSサービスを提供する単一のドメインです。2番目の領域は複数のドメインで、相互のビジネス上の利益を備えた小さなプロバイダーが、ネットワークの境界内に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.
[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契約を交渉する際に（自律システムから）1つ以上のホップアウェイが発生することに関心がないことを示しています。彼らは、地元の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]ピアであると仮定します。このペアワイズピアリングは論理的であるため、物理的なポイントツーポイント接続だけでなく、インターネット交換ポイント（IXPS）でもサポートできます。そこでは、多くの演算子がレイヤー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 あらゆるエンドユーザー間で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-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アドレスのグループであるA（宛先、D、J、L）タプルを特徴とする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].
（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つの隣接するドメインからの2つのL-QCは、2つのプロバイダーが1つのL-QCから他のL-QCにトラフィックを転送することに同意すると、結合されます。
L-QC thread
L-QCスレッド
Chain of neighboring bound l-QCs.
隣接する結合L-QCのチェーン。
Meta-QoS-Class (MQC)
Meta-Qos-Class（MQC）
An MQC provides the limits of the QoS parameter values that two l-QCs must respect in order to be bound together. An MQC is used as a label that certifies the support of a set of applications that bear similar network QoS requirements.
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）は、（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 --------->
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を保証します。プロバイダーのドメインのチェーン全体を横切るためのQoSレベル（SPN、SPN-1、SPN-2、...、SP1）。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.
図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チェーンに関与するプロバイダー（すべてを知っているわけではありません）は、多くの分野で競合他社になる可能性があります。したがって、信頼関係を構築することは非常に困難です。多くの複雑で重要な問題を解決する必要があります。SPN1は、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.
特定の契約の変更は、それを利用する多数の外部契約に影響を与える可能性があります。プロバイダーは、それに依存する多数の外部（ドメイン）契約によって制限されている独自の契約の1つを再交渉または終了する自由度を見ています。これは、「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.
保証を1つのドメインホップのみに制限するという命題は、プロバイダー間契約にのみ適用されることに注意することが非常に重要です。それは決してコミュニケーションのエンドツーエンドの保証を排除するものではありません。
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がどのL-QC（S）にどのL-QCがバインドされるかを決定することです。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：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.
1つのL-QCが2つ（またはそれ以上）のL-QCにバインドされた場合、パケットが選択するL-QCを知ることは非常に困難です。これは、アプリケーションが流れるほど粒度に基づいて、ドメインの境界線でのフロー分類を意味する可能性があります。スケーラビリティのために、1つのL-QCを複数のL-QC [LEV]に拘束しないでください。それどころか、図3のL-QC23およびL-QC24がL-QC13に結合するように、いくつかのL-QCを同じL-QCに結合することができます。
A provider decides the best match between l-QCs based exclusively on:
プロバイダーは、以下に基づいてL-QCS間の最高の一致を決定します。
- 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.
このワンホップ、近視のアプローチにもかかわらず、QOS処理の一貫性と一貫性は、隣接する結合されたL-QCによって形成されたL-QCスレッドで確保されなければなりません。特定のL-QCを適用するドメインを離れるパケットは、外部ドメインを最終目的地まで交差させるときに同様の治療を経験するはずです。プロバイダーは、最も近いパフォーマンスを持つ隣接L-QCにL-QCをバインドする必要があります。L-QC結合の基準は、任意のL-QCスレッドに沿って安定している必要があります。たとえば、2つのプロバイダーは2つのL-QCをバインドして遅延を最小限に抑える必要はありませんが、同じスレッドでさらに2つの他のプロバイダーがエラーを最小限に抑えるために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パフォーマンスパラメーターに制約を掲載する必要があります。これらの制約は、ドメインサイズに依存する必要があります。たとえば、遅延の制限は、地域のドメインよりも国家ドメインのより大きな価値を承認する必要があります。したがって、2つのL-QCをどの条件で結合できるかを確立するために、いくつかのルールを定義する必要があります。これらのルールは、Meta-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は、2つのL-QCが結合するために尊重しなければならないQOSパラメーターの制限を提供します。プロバイダーは、いくつかのステップを経て、内部L-QCをバインディングプロセスを通じて拡張します。まず、MQCSに基づいて独自のL-QCを分類します。MQCは、同様のネットワークQoS要件を担当する一連のアプリケーションのサポートを証明するラベルとして使用されます。これは、L-QCがこの一連のアプリケーションのトラフィックを伝えるための適切なQoS特性を持っていることを確認する手段です。第二に、隣人によって宣伝されている利用可能なMQCについて学びます。MQCを宣伝するには、プロバイダーが少なくとも1つの準拠したL-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.
o 一連のアプリケーション（VOIPなど）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.
ここで定義されているプロバイダーとプロバイダーへの契約は、一方向です。それらは、特定の方向にトラフィックを輸送するために確立されています。ただし、ビジネスの観点からは、逆合意も反対方向にトラフィックを輸送するために交渉される可能性があります。トラフィックの2つの方向を個別に考慮した場合、ユニ方向プロバイダーとプロバイダーへの契約は、双方向保証でエンドツーエンドサービスを受けることを妨げないことに注意してください。
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の定義の外側にある他のいくつかのパラメーターに同意する必要があります。そのような明らかなパラメーターの1つは帯域幅です。2つのプロバイダーは、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.
MQCSの階層は、特定のタイプのサービスに対して定義できます（例：異なる品質のVoIP：VoIP for Residential、VoIPはビジネス用VoIP）。与えられたL-QCは、いくつかのMQCに適しています（同じ階層の外側でも）。同じドメイン内のいくつかのL-QCは、同じMQCに属すると分類できます。Best-Effort 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.
プロバイダー間の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の3つの概念が関連しています。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は、近隣との合意に達するために、QoS機能（L-QCS、DiffServまたはその他のプロトコルまたはメカニズムを介して）を分類する方法です。MQCは、プロバイダーが近隣のプロバイダーとの契約を交渉したい場合にのみ関与します。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が複数の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）は、フルメッシュ接続の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に少なくとも1つの準拠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 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コンセプトを適用する主な結果の1つは、ドメイン間関係の複雑さと管理負担を軽減することです。
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平面内のルートパス選択は、インターネットルーターが使用する従来のルーティングシステムと同じ方法で想定できます。したがって、ドメイン間ルーティングプロセスのために、基本的にMQC平面ごとに1つのBGP発生、BGPプロトコルに依存することができます。IPルーティングシステムの回復力は保存されています。QoSパスがどこかで壊れた場合、ルーティングプロトコルは、適切なMQCプレーンで別のQoSパスの動的計算を可能にします。これは、たとえこれが矛盾したものであっても、「Best-Effort 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 As Path（x、y）はZに宣伝されます。BGPによるパスとしてのこの伝播中に、xは独自の遅延に関する情報を追加します。たとえば20ミリ秒など、独自の遅延。zはBGP広告（x、y、n、50 ms）を受け取ります。Zの顧客の1人は、N Nに到達するために100ミリ秒の遅延を要求します。Zは、20ミリ秒など、この顧客にとって独自の遅延を知っています。Zは、顧客からN：70ミリ秒への予想される最大遅延を計算し、As Path（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）情報を組み込むことができますが、適切なパス[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要件を指定するために、関与する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）などのIPまたはアプリケーションレベルでのソリューションとともに、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).
MQCプレーン内でルート選択プロセスを駆動するためにいくつかのQoSパラメーターを使用すると、最適な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.
この作業は、メスカル（インターネット全体でエンドツーエンドのサービス品質の管理）とアガベ（実行可能なエンドツーエンド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] Demichelis、C。およびP. Chimento、「IPパフォーマンスメトリック（IPPM）のIPパケット遅延変動メトリック」、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。、「A Border Gateway Protocol 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、et al。、「Parallel Internets Framework」、IST Agave Project Public Fardyable 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.
[Chau] Chau、C。、「非厳格な選好を備えたポリシーベースのルーティング」、ACM Sigcomm 2006コンピューター通信のためのアプリケーション、テクノロジー、アーキテクチャ、およびプロトコルに関する議事録、PISA、イタリア、PP 387-398、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.、Reed、D P.、およびD D. Clark、「システム設計におけるエンドツーエンドの引数」、コンピューターシステムのACMトランザクション、Vol 2、番号4、pp 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。、およびPGeorgatsos、「QoSクラスの飛行機を介したドメイン間ルーティング[不均一ネットワーク用のサービス品質ベースのルーティングアルゴリズム]」、IEEE Communications Magazine、Vol 45、Issue 2、PP 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、「今私を聞くことができますか？！それはBGPに違いない」、ACM Journal of Computer and Communication Review 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、et al。、「ビジネスモデルの仕様とドメイン間QoS配信のための機能アーキテクチャ」、IST Mescal Project Public Fardyable 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 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] 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、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] Eder、M.、Chaskar、H。、およびS. Nag、「IPネットワークのサービス品質（QOS）に関するサービス管理研究グループ（SMRG）からの考慮事項」、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。、およびInternet Architecture Board、「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、「Diffserv Service Classeの構成ガイドライン」、RFC 4594、2006年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
ピエール・レビス・フランス・テレコム42 rue des coutures bp 6243 caen cedex 4 14066フランス
EMail: pierre.levis@orange-ftgroup.com
Mohamed Boucadair France Telecom 42 rue des Coutures BP 6243 Caen Cedex 4 14066 France
Mohamed Boucadair France Telecom 42 Rue des Coutures BP 6243 Caen Cedex 4 14066 France
EMail: mohamed.boucadair@orange-ftgroup.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at http://www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
この文書は、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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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への情報をお問い合わせください。