RFC5160 日本語訳
5160 Considerations of Provider-to-Provider Agreements forInternet-Scale Quality of Service (QoS). P. Levis, M. Boucadair. March 2008. (Format: TXT=44317 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Levis
Request for Comments: 5160 M. Boucadair
Category: Informational France Telecom
March 2008
コメントを求めるワーキンググループP.レビーの要求をネットワークでつないでください: 5160年のM.Boucadairカテゴリ: 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はインターネットStandardのどんなレベルの候補ではありません。 IETFはどんな目的と発行するという決定がIETF仕事との闘争のためのIESGレビューは別としてIETFレビューに基づいていないというメモのためにもこのRFCのフィットネスに関するどんな知識も放棄します。 RFC Editorは、自己判断でこのドキュメントを発表するのを選びました。 詳しい情報に関してRFC3932を見てください。
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によって可能にされたインターネットに適したService(QoS)協定のプロバイダーからプロバイダーへのQualityを分析します。 それは相互ドメインQoSモデルに関連している用語を定義します。 それはMeta-QoS-クラス(MQC)によって指示された新しい概念を提案します。 この概念は、潜在的にQoS相互ドメイン関係がプロバイダーの間で築き上げられる方法を運転して、連邦化するかもしれません。 それは既存のベストエフォート型インターネットの開放性をできるだけ保有するQoSの可能にされたインターネットに新しい見解を開けます。
Levis & Boucadair Informational [Page 1] RFC 5160 MQC and Provider QoS Agreements March 2008
レビー、Boucadairの情報[1ページ]のRFC5160MQC、および2008年のプロバイダーQoS協定行進
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Assumptions and Requirements . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Weaknesses of Provider-to-Provider QoS Agreements Based on
SP Chains . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. IP Connectivity Services . . . . . . . . . . . . . . . . . 6
4.2. Similarity between Provider and Customer Agreements . . . 6
4.3. Liability for Service Disruption . . . . . . . . . . . . . 7
4.4. SP Chain Trap Leading to Glaciation . . . . . . . . . . . 7
5. Provider-to-Provider Agreements Based on Meta-QoS-Class . . . 7
5.1. Single Domain Covering . . . . . . . . . . . . . . . . . . 8
5.2. Binding l-QCs . . . . . . . . . . . . . . . . . . . . . . 9
5.3. MQC-Based Binding Process . . . . . . . . . . . . . . . . 10
6. The Internet as MQC Planes . . . . . . . . . . . . . . . . . . 12
7. Towards End-to-End QoS Services . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . . 16
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 仮定と要件. . . . . . . . . . . . . . . . . 3 3。 用語. . . . . . . . . . . . . . . . . . . . . . . . . 4 4。 プロバイダーからプロバイダーへのQoS協定の弱点はチェインズ. . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1をSPに基礎づけました。 IP接続性サービス. . . . . . . . . . . . . . . . . 6 4.2。 プロバイダーと顧客協定. . . 6 4.3の間の類似性。 サービスの崩壊. . . . . . . . . . . . . 7 4.4のための責任。 SPは氷河作用. . . . . . . . . . . 7 5に罠先導を束縛します。 プロバイダーからプロバイダーへの協定はメタQoSのクラス.75.1を基礎づけました。 単一領域覆い. . . . . . . . . . . . . . . . . . 8 5.2。 l-QCs.95.3を縛ります。 MQCベースの拘束力がある過程. . . . . . . . . . . . . . . . 10 6。 MQC飛行機. . . . . . . . . . . . . . . . . . 12 7としてのインターネット。 終わりから終わりに対するQoSサービス. . . . . . . . . . . . . . . 13 8に向かって。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 15 9。 承認. . . . . . . . . . . . . . . . . . . . . . . 15 10。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 16 10.1。 引用規格. . . . . . . . . . . . . . . . . . . 16 10.2。 有益な参照. . . . . . . . . . . . . . . . . . 16
1. Introduction
1. 序論
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ははるかに高くて、ダイナミックです)。 したがって、複数のドメインとインターネット地域は彼らのそれぞれの解決策において異なりそうです。 このメモはプロバイダーからプロバイダーへの協定の観点からインターネット地域を調査する試みです。 それは相互ドメインの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問題を解決することを目指すどんな解決策によっても会われるという1セットの要件を提供します。 これらの要件はこのメモの中で再生しません。 読者が要件でさらに練られた記述について[MESCAL]を参照するよう誘われています。
Levis & Boucadair Informational [Page 2] RFC 5160 MQC and Provider QoS Agreements March 2008
レビー、Boucadairの情報[2ページ]のRFC5160MQC、および2008年のプロバイダー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協定を交渉するときワンバウンドであるより遠く(それらのAutonomous Systemから)に起こることに関係がある必要はないのを示します。 彼らは自分達の協定を彼らのダイレクト隣人の地元のQoS能力とものだけに基礎づけるべきです。 この分析は、私たちが相互ドメインQoSモデルに関連している用語を定義するように導きます。 また、私たちはQoS相互ドメイン関係がプロバイダーの間で築き上げられる方法を運転して、連邦化するMeta-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は1セットのMQC飛行機としてインターネットQoS能力の簡易型の視点を持って来ます。 このメモはMQC飛行機の考えに、ある周知の具体的な相互ドメインQoS問題で役立っている場合があるかどうか見ます。 しかしながら、焦点がプロバイダーからプロバイダーへのQoS協定枠組みにあります、そして、意志は完全な相互ドメインQoSシステムに個々の解決とプロトコルを指定しないことです。 MQC飛行機の概念を敷衍していて、広める平行なInternetsの概念に基づく完全な構造の議論に関しては、[AGAVE]を見てください。
Note that this document does not specify any protocols or systems.
このドキュメントがどんなプロトコルやシステムも指定しないことに注意してください。
2. Assumptions and Requirements
2. 仮定と要件
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 どんな解決策も、小さいセットのドメインで配備されるとき使用可能になるように局所的に申し込まれるべきです。
Levis & Boucadair Informational [Page 3] RFC 5160 MQC and Provider QoS Agreements March 2008
レビー、Boucadairの情報[3ページ]のRFC5160MQC、および2008年のプロバイダーQoS協定行進
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 また、どんな解決策も終わりまでの終わりの主張[2EのE]の結果として抜群のサービスのままで残るべきであるベストエフォート型サービスを維持するべきです。
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が属するように(l-QCs)プロバイダーのネットワークにおけるQoS能力を表すことができるだけであると仮定します。 ドメインに交差するとき、交通はそのドメインの中のそれのために選択されたl-QC交通に対応する遅れの値によって特徴付けられた状態、ジター、およびパケット損失率になります。 能力は彼らのそれぞれのQoSの特性による配備されたl-QCsの数とそれらを実行されて、設計してある方法でも1つのプロバイダーから別のプロバイダーまで異なることができます。
3. Terminology
3. 用語
(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で構成されたか、または数個のAutonomous Systems(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.
DestinationがIPアドレスのグループであり、(D、J、L)がDestinationを始めるQoS性能である(目的地、D、J、L)tupleによって特徴付けられたIP転送能力。
Levis & Boucadair Informational [Page 4] RFC 5160 MQC and Provider QoS Agreements March 2008
レビー、Boucadairの情報[4ページ]のRFC5160MQC、および2008年のプロバイダーQoS協定行進
Local-QoS-Class (l-QC)
地方のQoSのクラス(l-QC)
A QoS transfer capability across a single domain, characterized by
a set of QoS performance parameters denoted by (D, J, L). From a
Diffserv [RFC2475] perspective, an l-QC is an occurrence of a Per
Domain Behavior (PDB) [RFC3086].
QoSは(D、J、L)によって指示された1セットのQoS性能パラメタによって特徴付けられた単一領域の向こう側に能力を移します。 Diffserv[RFC2475]見解から、l-QCはPer Domain Behavior(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つのプロバイダーが、1l-QCからもう片方までの交通を移すのにいったん同意すると、2つの隣接しているドメインからの2l-QCsが一緒に制限されています。
L-QC thread
L-QC糸
Chain of neighboring bound l-QCs.
近所付き合いのチェーンはl-QCsを縛りました。
Meta-QoS-Class (MQC)
メタQoSのクラス(MQC)
An MQC provides the limits of the QoS parameter values that two
l-QCs must respect in order to be bound together. An MQC is used
as a label that certifies the support of a set of applications
that bear similar network QoS requirements.
MQCは2l-QCsが制限されているために尊敬しなければならないQoSパラメタ値の限界を一緒に提供します。 MQCは同様のネットワークQoS要件に堪える1セットのアプリケーションのサポートを公認するラベルとして使用されます。
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接続性サービスのためにパケットを運ぶのに使用されるService Providersのチェーン。
4. Weaknesses of Provider-to-Provider QoS Agreements Based on SP Chains
4. プロバイダーからプロバイダーへのQoS SPチェインズに基づく協定の弱点
The objective of this section is to show, by a sort of reductio ad absurdum proof, that within the scope of Internet services, provider- to-provider QoS agreements should be based on guarantees that span a single domain.
このセクションの目的は目立つことです、インターネットのサービスの範囲の中では、プロバイダーへのプロバイダーQoS協定が単一領域にかかる保証に基づくべきであるという一種の背理法証拠で。
We therefore analyze provider-to-provider QoS agreements based on guarantees that span several domains and emphasize their vulnerabilities. In this case, the basic service element that a provider offers to its neighboring providers is called an IP connectivity service. It uses the notion of SP chains. We first define what an IP connectivity service is, and then we point out
したがって、私たちはプロバイダーからプロバイダーへのQoSいくつかのドメインにかかっていて、それらの脆弱性を強調する保証に基づく協定を分析します。 この場合、プロバイダーが隣接しているプロバイダーに提供する基本サービス要素はIP接続性サービスと呼ばれます。 それはSPチェーンの概念を使用します。 私たちは最初に、IP接続性サービスが何であるか、そして、指摘するその時を定義します。
Levis & Boucadair Informational [Page 5] RFC 5160 MQC and Provider QoS Agreements March 2008
レビー、Boucadairの情報[5ページ]のRFC5160MQC、および2008年のプロバイダーQoS協定行進
several weaknesses of such an approach, especially the SP chain trap problem that leads to the so-called Internet glaciation era.
そのようなアプローチ、特にいわゆるインターネット氷河作用時代に通じるSPチェーン罠問題のいくつかの弱点。
4.1. IP Connectivity Services
4.1. IP接続性サービス
An IP connectivity service is a (Destination, D, J, L) tuple where Destination is a group of IP addresses reachable from the domain of the provider offering the service, and (D, J, L) is the QoS performance to get from this domain to Destination. Destination is typically located in a remote domain.
IP接続性サービスはDestinationがサービスを提供するプロバイダーのドメインから届いているIPアドレスのグループである(目的地、D、J、L)tupleです、そして、(D、J、L)はこのドメインからDestinationまで手に入れる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 --------->
プロバイダー/--------------SPチェーン---------------\は視点/--協定--\+を適応させました。----+ +----+ +----+ +----+ +----+ |SP+-------+ SP+----+ SP+----+ SP+… -+ SP| |n+1| |n| |n-1| |n-2| |1 | +----+ +----+ +----+ +----+ +----+ ドメイン----->パケット流動/指向のDestination視点<。----------- 保証範囲--------->。
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では、Provider SPnは、プロバイダーのドメイン(SPn、SPn-1、SPn-2、…、SP1)の全体のチェーンに交差するようにプロバイダーSPn+1にQoSのレベルを保証します。 SPiはドメインと同様にプロバイダーを指示します。 図の先端はプロバイダー指向の視点です。 プロバイダー(SPn、SPn-1、SPn-2、…、SP1)の順序集合はSPチェーンと呼ばれます。 図の下部はドメイン指向の視点です。
4.2. Similarity between Provider and Customer Agreements
4.2. プロバイダーと顧客協定の間の類似性
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チェーンに通じるでしょう。
Levis & Boucadair Informational [Page 6] RFC 5160 MQC and Provider QoS Agreements March 2008
レビー、Boucadairの情報[6ページ]のRFC5160MQC、および2008年のプロバイダーQoS協定行進
4.3. Liability for Service Disruption
4.3. サービスの崩壊のための責任
In Figure 1, if SPn+1 sees a disruption in the IP connectivity service, it can turn only against SPn, its legal partner in the agreement. If SPn is not responsible, in the same way, it can only complain to SPn-1, and so on, until the faulty provider is found and eventually requested to pay for the service impairment. The claim is then supposed to move back along the chain until SPn pays SPn+1. The SP chain becomes a liability chain.
図1では、SPn+1がIP接続性サービスで分裂を見るなら、それはSPn(合意における法的なパートナー)だけに対してターンできます。 SPnは責任がないなら、同様に、SPn-1などに不平を言うことができるだけです、不完全なプロバイダーが見つけられて、結局サービス損傷の代価を払うよう要求されるまで。 そして、SPnがSPn+1を支払うまで、クレームはチェーンに沿って戻るべきです。 SPチェーンは責任チェーンになります。
Unfortunately, this process is prone to failure in many cases. In the context of QoS solutions suited for the Internet, SP chains are likely to be dynamic and involve a significant number of providers. Providers (that do not all know each other) involved in the same SP chain can be competitors in many fields; therefore, trust relationships are very difficult to build. Many complex and critical issues need to be resolved: how will SPn+1 prove to SPn that the QoS level is not the level expected for a scope that can expand well beyond SPn? How long will it take to find the guilty domain? Is SPn ready to pay SPn+1 for something it does not control and is not responsible for?
残念ながら、多くの場合、この過程は失敗の傾向があります。 インターネットに合うQoS解決策の文脈では、SPチェーンは、ダイナミックであり、多くのプロバイダーにかかわりそうです。 同じSPチェーンにかかわるプロバイダー(それは互いをすべて知らない)は多方面に競争相手であるかもしれません。 したがって、信用関係は建てるのが非常に難しいです。 多くの複雑で批判的な問題が、決議される必要があります: SPn+1は、QoSレベルがSPnによく広がることができる範囲に予想されたレベルでないとどのようにSPnに立証するでしょうか? 有罪のドメインを見つけるにはどれくらいかかるでしょうか? 支払う準備ができているSPnはそれが制御しないで、また責任がない何かのためのSPn+1ですか?
4.4. SP Chain Trap Leading to Glaciation
4.4. SPは罠先導を氷河作用に束縛します。
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-2のような遠方のドメインの横断のためにそれとなくSPn+1に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インフラストラクチャ(だれもどんな協定も再交渉できなかった)を引き起こして。
5. Provider-to-Provider Agreements Based on Meta-QoS-Class
5. プロバイダーからプロバイダーへのメタ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サービスが潜在的に利用可能な状態で目的地とどんな目的地からも望ましいと考えられるなら、どんな解決策も、上の弱点とスケーラビリティ問題を解決して、プロバイダーからプロバイダーへの協定の交互の計画を見つけなければなりません。
Levis & Boucadair Informational [Page 7] RFC 5160 MQC and Provider QoS Agreements March 2008
レビー、Boucadairの情報[7ページ]のRFC5160MQC、および2008年のプロバイダーQoS協定行進
5.1. Single Domain Covering
5.1. 単一領域覆い
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ドメインのQoS性能だけをプロバイダーSPn+1に保証します。 このドキュメントの残りは、相互ドメイン関係に明快と簡単さを運び込んで、このアプローチに1つがチェーンをSPに基礎づけたより一層グローバルなQoSインターネットに合っているのを示すでしょう。
Provider-
oriented
view /--Agreement--\
+----+ +----+
|SP +-------+SP +
|n+1 | |n |
+----+ +----+
Domain- -----> packet flow
oriented <---->
view Guarantee Scope
プロバイダーの指向の視点/--協定--\+----+ +----+ |SP+-------+ SP+|n+1| |n| +----+ +----+ ドメイン----->パケット流動は<を適応させました。---->視点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.
責任問題はワンバウンドの距離に制限されます。 プロバイダーは、それ自身のドメインだけに責任があって、それがダイレクト契約を持っているすべての隣人によって制御されます。
Levis & Boucadair Informational [Page 8] RFC 5160 MQC and Provider QoS Agreements March 2008
レビー、Boucadairの情報[8ページ]のRFC5160MQC、および2008年のプロバイダーQoS協定行進
5.2. Binding l-QCs
5.2. 拘束力があるl-QCs
When a provider wants to contract with another provider, the main concern is deciding which l-QC(s) in its own domain it will bind to which l-QC(s) in the neighboring downstream domain. The l-QC binding process becomes the basic inter-domain process.
プロバイダーが別のプロバイダーと契約したがっているとき、主な関心事は、それが隣接している川下のドメインのどのl-QC(s)にそれ自身のドメインのどのl-QC(s)を縛るかを決めています。 l-QCの拘束力がある過程は基本的な相互ドメインの過程になります。
Upstream Downstream
domain domain
上流のDownstreamドメインドメイン
l-QC21 -----> l-QC11
l-QC21----->l-QC11
l-QC22 -----> l-QC12
l-QC22----->l-QC12
l-QC23 ----->
l-QC13
l-QC24 ----->
l-QC23----->l-QC13l-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.
1l-QCが2(さらに)l-QCsまで縛られることになっているなら、パケットがどのl-QCを選択するはずであるかを知るのは非常に難しいでしょうに。 これはアプリケーションが流れるのと同じくらいきめ細かに粒状に基づくドメインの境界で流れ分類を含意するかもしれません。 スケーラビリティのために、私たちは、1l-QCが数個のl-QCs[レフ]に縛られるべきでないと思います。 これに反して、同じl-QCに数個のl-QCsを縛ることができます、l-QC23とl-QC24が図3でl-QC13に縛られる方法で。
A provider decides the best match between l-QCs based exclusively on:
プロバイダーは排他的に以下に基づいたl-QCsの間の最も良いマッチについて決めます。
- What it knows about its own l-QCs;
- それがそれ自身のl-QCsに関して知っていること。
- What it knows about its neighboring l-QCs.
- それが隣接しているl-QCsに関して知っていること。
It does not use any information related to what is happening more than one domain away.
それは1つ以上のドメイン遠くで起こっていることに話された少しの情報も使用しません。
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.
このワンバウンドの、そして、近視のアプローチにもかかわらず、隣接している制限されたl-QCsによって形成されたl-QC糸の上にQoS処理の一貫性と一貫性を確実にしなければなりません。 外部のドメインにそれらの最終的な目的地まで交差するとき、与えられたl-QCを適用するドメインを出るパケットは同様の処理を経験するはずです。 プロバイダーは最も厳密な性能を持っている隣接しているl-QCと共にl-QCを縛るべきです。 l-QC結合の評価基準はどんなl-QC糸に沿っても安定しているべきです。 例えば、遅れを最小にしますが、誤りを最小にする2l-QCsが同じ糸の上に他の2つのプロバイダーで、より遠くに付いたように、2つのプロバイダーは2l-QCsを縛るべきではありません。
Levis & Boucadair Informational [Page 9] RFC 5160 MQC and Provider QoS Agreements March 2008
レビー、Boucadairの情報[9ページ]のRFC5160MQC、および2008年のプロバイダーQoS協定行進
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性能パラメタに載せられるべきです。 これらの規制をドメインサイズに依存するべきです。 例えば、遅れにおける制限は地方のものより大きい値を国家のドメインに認可するべきです。 したがって、どの状態twoでl-QCsを一緒に縛ることができるかを証明するためにいくつかの規則を定義しなければなりません。 Meta-QoS-クラス(MQC)の概念はこれらの規則を提供します。
5.3. MQC-Based Binding Process
5.3. 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は2l-QCsが制限されているために尊敬しなければならないQoSパラメタの限界を一緒に提供します。 プロバイダーは、拘束力がある過程で内部のl-QCsを広げるためにいくつかの階段を通ります。 まず第一に、それはMQCsに基づくそれ自身のl-QCsを分類します。 MQCは同様のネットワークQoS要件に堪える1セットのアプリケーションのサポートを公認するラベルとして使用されます。 それはこのセットのアプリケーションの交通を伝えるためにl-QCには適切なQoSの特性があるのを確実にする手段です。 第二に、それは隣人によって広告に掲載された利用可能なMQCsに関して学びます。 プロバイダーは、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 MQCが特に合っている1セットのアプリケーション(例えば、VoIP)。
o Boundaries or intervals of a set of QoS performance attributes
whenever required. For illustration purposes, we propose to use
in this document attribute (D, J, L) 3-tuple. An MQC could be
focused on a single parameter (e.g., suitable to convey delay
sensitive traffic). Several levels could also be specified
depending on the size of the network provider; for instance, a
small domain (e.g., regional) needs lower delay than a large
domain (e.g., national) to match a given MQC.
o 境界か必要であり1セットのQoS性能属性の間隔。 イラスト目的のために、私たちは、本書では属性(D、J、L)3-tupleを使用するよう提案します。 ただ一つのパラメタに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 比率における規制: このクラス(例えば、ピーク交通より少ないリソース)を使用するクラス/総合的な交通のためのネットワーク資源。
Levis & Boucadair Informational [Page 10] RFC 5160 MQC and Provider QoS Agreements March 2008
レビー、Boucadairの情報[10ページ]のRFC5160MQC、および2008年のプロバイダーQoS協定行進
Two l-QCs can be bound together if, and only if, they conform to the same MQC.
2l-QCsを一緒に縛ることができる、唯一、彼らは同じMQCに従います。
Provider-to-provider agreements, as defined here, are uni- directional. They are established for transporting traffic in a given direction. However, from a business perspective, it is likely that reverse agreements will also be negotiated for transporting traffic in the opposite direction. Note that uni-directional provider-to-provider agreements do not preclude having end-to-end services with bi-directional guarantees, when you consider the two directions of the traffic separately.
プロバイダーからプロバイダーへのここで定義される協定はuni方向上です。 それらは、与えられた方向に交通を輸送するために設立されます。 しかしながら、ビジネス見解から、また、逆の協定は、逆方向の交通を輸送しながら、交渉されそうでしょう。 プロバイダーからプロバイダーへのuni方向の協定が、終わりから終わりに対する双方向の保証によるサービスを持っているのを排除しないことに注意してください、あなたが別々に交通の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に基づく協定を交渉するとMQCの定義の外である他のいくつかのパラメタで同意しなければならない2つのプロバイダー。 そのようなパラメタの明白な1つは帯域幅です。 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(同じ階層構造さえの外における)に適当である場合があります。 同じMQCに属すとして同じドメインの数個のl-QCsを分類できます。 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規格の1セットのグローバルな協定を必要とします。 定義されるべきクラスの数は圧倒的な複雑さを避けるために非常に小さいままで残らなければなりません。 また、私たちはプロバイダーによってされたl-QC分類がMQC規格に従うのを公認する手段を必要とします。 それで、調査で標準化の努力は順応テスト要件によって伴われるべきです。
The three notions of PDB, Service Class [RFC4594], and MQC are related; what MQC brings is the inter-domain aspect:
PDB、Service Class[RFC4594]、およびMQCの3つの概念が関係づけられます。 MQCがもたらすことは相互ドメイン局面です:
- PDB is how to engineer a network;
- PDBはどうネットワークを設計するかということです。
- Service Class is a set of traffic with specific QoS requests;
- 特定のQoS要求でサービスClassは1セットの交通です。
- MQC is a way to classify the QoS capabilities (l-QCs, through
Diffserv or any other protocols or mechanisms) in order to reach
agreements with neighbors. MQCs are only involved when a provider
- MQCは隣人との合意に達するように、QoS能力(いかなる他のDiffservを通したl-QCs、プロトコルまたはメカニズムも)を分類する方法です。 プロバイダーであるときにだけ、MQCsはかかわります。
Levis & Boucadair Informational [Page 11] RFC 5160 MQC and Provider QoS Agreements March 2008
レビー、Boucadairの情報[11ページ]のRFC5160MQC、および2008年のプロバイダーQoS協定行進
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はMQC QoS属性(例えば、(D、J、L))値に達している限り、ネットワークが設計される方法へのどこふく風です。
6. The Internet as MQC Planes
6. MQC飛行機としてのインターネット
The resulting QoS Internet can be viewed as a set of parallel Internets or MQC planes. Each plane consists of all the l-QCs bound according to the same MQC. An MQC plane can have holes and isolated domains because QoS capabilities do not cover all Internet domains. When an l-QC maps to several MQCs, it belongs potentially to several planes.
1セットの平行なInternetsかMQC飛行機として結果として起こるQoSインターネットを見なすことができます。 同じMQCによると、各飛行機はすべてのl-QCsバウンドから成ります。 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飛行機に論理的なリンクを加えます。 これは基本的にどんな現在の伝統的な相互ドメイン協定が存在のためにインターネットを意味するかということです。 完全なメッシュの接続性で4つのドメインを包括して、図4a)はインターネットの部分の物理的なレイアウトについて表現します。
+----+ +----+ +----+ +----+
|SP +----+SP | |SP +----+SP |
|1 | |2 | |1 | |2 |
+-+--+ +--+-+ +-+--+ +----+
| \ / | | /
| \/ | | /
| /\ | | /
| / \ | | /
+-+--+ +--+-+ +-+--+ +----+
|SP +----+SP | |SP | |SP |
|4 | |3 | |4 | |3 |
+----+ +----+ +----+ +----+
a) physical configuration b) an MQC plane
+----+ +----+ +----+ +----+ |SP+----+ SP| |SP+----+ SP| |1 | |2 | |1 | |2 | +-+--+ +--+-+ +-+--+ +----+ | \ / | | / | \/ | | / | /\ | | / | / \ | | / +-+--+ +--+-+ +-+--+ +----+ |SP+----+ SP| |SP| |SP| |4 | |3 | |4 | |3 | +----+ +----+ +----+ +----+ a)の物理的な構成b) MQC飛行機
Figure 4: MQC planes
図4: MQC飛行機
Figure 4 b) depicts how these four domains are involved in a given MQC plane. SP1, SP2, and SP4 have at least one compliant l-QC for this MQC; SP3 may or may not have one. A bi-directional agreement exists between SP1 and SP2, SP1 and SP4, SP2 and SP4.
図4b)はこれらの4つのドメインがどう与えられたMQC飛行機にかかわるかを表現します。 SP1、SP2、およびSP4には、このMQCのための少なくとも1言いなりになっているl-QCがあります。 SP3には、1つがあるかもしれません。 SP1とSP4、SP2とSP4、双方向の協定はSP1とSP2の間に存在しています。
MQC brings a clear distinction between provider-to-provider and customer-to-provider QoS agreements. We expect a great deal of difference in dynamicity between the two. Most provider-to-provider agreements should have been negotiated, and should remain stable, before end-users can dynamically request end-to-end guarantees. Provider agreements do not directly map end-users' needs; therefore, the number of provider agreements is largely independent of the
MQCはプロバイダーからプロバイダーと顧客からプロバイダーへのQoS協定の明らかな区別をもたらします。 私たちは2つの間でdynamicityで多くの違いを予想します。 エンドユーザがダイナミックに終わりから終わりへの保証を要求できる前に、プロバイダーからプロバイダーへのほとんどの協定が、交渉されるべきであり、安定した状態を保つべきです。 プロバイダー協定は直接エンドユーザの必要性を写像しません。 したがって、プロバイダー協定の数は主に独立しています。
Levis & Boucadair Informational [Page 12] RFC 5160 MQC and Provider QoS Agreements March 2008
レビー、Boucadairの情報[12ページ]のRFC5160MQC、および2008年のプロバイダーQoS協定行進
number of end-user requests and does not increase as dramatically as with SP chains.
エンドユーザの数は、チェーンを要求して、SP劇的に増加させません。
For a global QoS-based Internet, this solution will work only if MQC- based binding is largely accepted and becomes a current practice. This limitation is due to the nature of the service itself, and not to the use of MQCs. Insofar as we target global services, we are bound to provide QoS in as many SP domains as possible. However, any MQC-enabled part of the Internet that forms a connected graph can be used for QoS communications and can be extended. Therefore, incremental deployment is possible, and leads to incremental benefits. For example, in Figure 4 b), as soon as SP3 connects to the MQC plane it will be able to benefit from the SP1, SP2, and SP4 QoS capabilities.
グローバルなQoSベースのインターネットと、MQCのベースの結合が主に受け入れられて、現在の習慣になる場合にだけ、この解決策は取り組むでしょう。 この制限はMQCsの使用ではなく、サービス自体の本質のためです。 グローバルなサービスを狙う限り、私たちは必ずできるだけ多くのSPドメインにQoSを提供するつもりです。 しかしながら、接続グラフを形成するインターネットのどんなMQCによって可能にされた地域もQoSコミュニケーションに使用できて、広げることができます。 したがって、増加の展開は、可能であり、増加の利益につながります。 例えば、図4b)では、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つは相互ドメイン関係の複雑さと管理負担を軽減するということです。
7. Towards End-to-End QoS Services
7. 終わりから終わりに対するQoSサービスに向かって
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経路がどこかで壊れるなら、ルーティング・プロトコルは別のQoS経路の力学計算を可能にします、利用可能であるなら、適切なMQC飛行機で。 これは便利に「ベストエフォート型QoS」と命名できた最初のレベルのQoSインフラストラクチャを提供します、これが撞着語法であっても。
On this basis, features can be added in order to select and control the QoS paths better. For example, BGP can be used to convey QoS- related information, and to implement a process where Autonomous Systems add their own QoS values (D, J, L) when they propagate an AS path. Then, the AS path information is coupled with the information on Delay, Jitter, and Loss, and the decision whether or not to use the path selected by BGP can be made, based on numerical values. For
このベースでは、QoS経路をよりよく選択して、制御するために特徴を加えることができます。 例えば、QoSの関連する情報を伝えて、AS経路を伝播するときAutonomous Systemsがそれら自身のQoS値(D、J、L)を加える過程を実行するのにBGPを使用できます。 次に、Delay、Jitter、およびLossの情報にAS経路情報を結びつけます、そして、BGPによって選択された経路を使用するかどうかという決定をすることができます、数値に基づいて。 for
Levis & Boucadair Informational [Page 13] RFC 5160 MQC and Provider QoS Agreements March 2008
レビー、Boucadairの情報[13ページ]のRFC5160MQC、および2008年のプロバイダーQoS協定行進
example, for destination N, an AS path (X, Y) is advertised to AS Z. During the propagation of this AS path by BGP, X adds the information concerning its own delay, say 30 ms, and Y adds the information concerning its own delay, say 20 ms. Z receives the BGP advertisement (X, Y, N, 50 ms). One of Z's customers requests a delay of 100 ms to reach N. Z knows its own delay for this customer, say 20 ms. Z computes the expected maximum delay from its customer to N: 70 ms, and concludes that it can use the AS path (X, Y). The QoS value of an AS path could also be disconnected from BGP and computed via an off-line process.
例、目的地Nに関して、AS経路(X、Y)のAS Z.Duringに広告を出します。BGPによるこのAS経路の伝播、Xはそれ自身の遅れに関して情報を加えます、と30msが言います、そして、Yはそれ自身の遅れに関して情報を言い足します、そして、20原稿ZがBGP広告(X、Y、N、50ms)を受け取ると言ってください。 Zの顧客のひとりは自分自身のがこの顧客のために遅らせるZが、知っているN.に達するように100msの遅れを要求して、20原稿Zが顧客からNまで予想された最大の遅れを計算すると言ってください: 70 AS経路(X、Y)を使用できるとmsして、結論づけます。 また、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]を選択するために構成している性能測定基準の問題を提起します。 複数の両立しない目的によって立ち向かわれていると、狙っているパラメタを最適化するのがされたローカルの決定は1セットの比較にならないほど経路をもたらすかもしれません。そこでは、経路がないのが他のものより厳密に優れています。 プロバイダーからプロバイダーへの協定の存在は、QoSパラメタの均質の視点をMQC申し出に基礎づけて、したがって、一貫性をもたらして、そのような非最適選択の危険を制限するべきです。
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ベースの協定は2方向に交渉されそうですが、彼らは相互ドメインルーティング・プロトコルに別々に前進の経路と逆の経路を計算させます、通常通りです。 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]が要求されるl-QC糸に交通を注ぐ前にQoSパラメタの安定性にそのようなものを確実にするために経路のコントロールで一歩先まで踏み込むことができます。 しかしながら、現在、相互ドメインルートのピンで止めることの準備ができて操作上の解決策(相互ドメインTE、速いフェイルオーバーなど)が利用可能になる前にいくつかの問題を解決しなければなりません。 例えば、[Kushman]にBGPの遅い集合問題を認めてください。
Multicast supports many applications such as audio and video distribution (e.g., IPTV, streaming applications) with QoS
マルチキャストはQoSとのオーディオやビデオ分配(例えば、IPTV、ストリーミング・アプリケーション)などの多くの応用を支持します。
Levis & Boucadair Informational [Page 14] RFC 5160 MQC and Provider QoS Agreements March 2008
レビー、Boucadairの情報[14ページ]のRFC5160MQC、および2008年のプロバイダー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.
要件。 IPかApplicationの解決策と共に、マルチキャストソースの可到達性のためにMQC能力の広告を出すのに、Forward Error Correctionなどのレベル(FEC)(BGP-4[RFC4760]のためのMultiprotocol Extensionsとの相互ドメインマルチキャストルーティング・プロトコル)を使用できました。 いくつかのドメインにかかる相互ドメイン木が同じMQC飛行機に残っているなら、MQCによって与えられた一貫性と一貫性の利益を得るのは可能でしょう。
Note that the use of some QoS parameters to drive the route selection process within an MQC plane may induce QoS deterioration since the best QoS-inferred path will be selected by all Autonomous System Border Routers (ASBRs) involved in the inter-domain path computation (i.e., no other available routes in the same MQC plane will have a chance to be selected). This problem was called the QoS Attribute- rush (QA-rush) in [Grif]. This drawback may be avoided if all involved ASes in the QoS chain implement some out-of-band means to control the inter-domain QoS path consistency (MQC compliance).
最も良いQoSによって推論された経路が相互ドメイン経路計算にかかわるすべてのAutonomous System Border Routers(ASBRs)によって選択されるので(すなわち、同じMQC飛行機で他のどんな利用可能なルートにも、選択されるべき機会がないでしょう)MQC飛行機の中にルート選択の過程を追い立てるいくつかのQoSパラメタの使用がQoS劣化を引き起こすかもしれないことに注意してください。 この問題は[Grif]にQoS Attribute突進(QA-突進)と呼ばれました。 QoSチェーンにおけるかかわったASesがバンドの外でいくつか実行するすべてが、相互ドメイン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]を解決するのを助けることができる概念です、データ、コントロール、または管理飛行機でのどんな特定のメカニズムやプロトコルの使用も禁止しないで。
8. Security Considerations
8. セキュリティ問題
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]、不正アクセスはサービスの否定につながることができます。
9. Acknowledgements
9. 承認
This work is funded by the European Commission, within the context of the MESCAL (Management of End-to-End Quality of Service Across the Internet At Large) and AGAVE (A liGhtweight Approach for Viable End- to-end IP-based QoS Services) projects. The authors would like to thank all the other partners for the fruitful discussions.
この仕事は欧州委員会によって資金を供給されます、MESCAL(Service AcrossインターネットAt LargeのEndから終わりへのQualityの管理)とAGAVE(終わりまでのViable EndのIPベースのQoS ServicesのためのliGhtweight Approach)プロジェクトの文脈の中で。 作者は有意義な論議について他のすべてのパートナーに感謝したがっています。
We are grateful to Brian Carpenter, Jon Crowcroft, and Juergen Quittek for their helpful comments and suggestions for improving this document.
私たちはブライアンCarpenter、ジョン・クロウクロフト、およびユルゲンQuittekにこのドキュメントを改良するための彼らの役に立つコメントと提案に感謝しています。
Levis & Boucadair Informational [Page 15] RFC 5160 MQC and Provider QoS Agreements March 2008
レビー、Boucadairの情報[15ページ]のRFC5160MQC、および2008年のプロバイダーQoS協定行進
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[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における、メートル法のA One-道の遅れ」、RFC2679、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における、メートル法のA One-道のパケット損失」、RFC2680、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パフォーマンス測定基準(IPPM)における、メートル法のIPパケット遅れ変化」、RFC3393、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)について議定書の中で述べます」、RFC4271、2006年1月。
10.2. Informative References
10.2. 有益な参照
[AGAVE] Boucadair, et al., "Parallel Internets Framework", IST
AGAVE project public deliverable D1.1, September 2006.
IST AGAVEは、[AGAVE]Boucadair(他)が「インターネット枠組みに沿う」と公共の提出物の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] コンピュータCommunications、ピサ、イタリア、pp387-398(2006年9月)のためのChau、C.、「非厳しい好みがある方針ベースのルーティング」、Applicationsの上の2006年のACM SIGCOMMコンファレンスのProceedings、Technologies、Architectures、およびプロトコル。
[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.
[2EのE]Saltzer、J H.、リード、D P.、およびD D.クラーク、「システム設計における終わりから終わりへの議論」、コンピュータシステムズ、Vol2、Number4、pp277-288(1984年11月)におけるACM Transactions。
[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.、グリーム、J.、Boucadair、M.、モラン、P.、ホワース、M.、ワング、N.、Pavlou、G.、Asgari、A.、およびP.Georgatsos、「QoS-クラス飛行機[Heterogeneous Networksのための基づくサービスの品質ルート設定Algorithms]を通したInterdomainルーティング」、IEEE Communications Magazine、Vol45、Issue2、pp88-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ジャーナルが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.
[レフ]レビー、P.、Asgari、H.、およびP.Trimintzios、「Inter-ドメインQoSとTraffic Engineeringにおける考慮はThroughにUtopian Approachを発行します」、ICT-2004のサピア-2004ワークショップ、(C)追出石-Verlag、2004年8月。
Levis & Boucadair Informational [Page 16] RFC 5160 MQC and Provider QoS Agreements March 2008
レビー、Boucadairの情報[16ページ]のRFC5160MQC、および2008年のプロバイダーQoS協定行進
[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、他、IST MESCALは「相互ドメインQoS配送のためのビジネスモデルの仕様と機能的な建築」と公共の提出物の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.ウィス、「微分されたサービスのための構造」RFC2475、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.Carpenter、「彼らのSpecificationのためのDifferentiated Services Per Domain BehaviorsとRulesの定義」RFC3086(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.、Srinivasan、V.、およびG.が飲み込まれる、「RSVP-Te:」 「LSP TunnelsのためのRSVPへの拡大」、RFC3209、2001年12月。
[RFC3387] Eder, M., Chaskar, H., and S. Nag, "Considerations from
the Service Management Research Group (SMRG) on Quality of
Service (QoS) in the IP Network", RFC 3387,
September 2002.
[RFC3387] 「IPネットワークにおけるサービスの質(QoS)に関するサービス管理研究グループ(SMRG)からの問題」と、エーダー、M.、Chaskar、H.、およびS.は口喧しく言います、RFC3387、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]アトキンソン、R.(エド)、フロイド、S.(エド)、インターネット・アーキテクチャ委員会、および「インターネット研究と発展に関するIAB心配と推薦」、RFC3869(2004年8月)
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
Guidelines for DiffServ Service Classes", RFC 4594,
August 2006.
2006年8月の[RFC4594]BabiarzとJ.とチェン、K.とF.ベイカー、「DiffServサービスのクラスのための構成ガイドライン」RFC4594。
[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インチのためのMultiprotocol拡張子、RFC4760、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月。
Levis & Boucadair Informational [Page 17] RFC 5160 MQC and Provider QoS Agreements March 2008
レビー、Boucadairの情報[17ページ]のRFC5160MQC、および2008年のプロバイダーQoS協定行進
Authors' Addresses
作者のアドレス
Pierre Levis France Telecom 42 rue des Coutures BP 6243 Caen Cedex 4 14066 France
ピアーレビーフランステレコム42悔悟des Coutures BP6243カーンCedex4 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フランステレコム42悔悟des Coutures BP6243カーンCedex4 14066・フランス
EMail: mohamed.boucadair@orange-ftgroup.com
メール: mohamed.boucadair@orange-ftgroup.com
Levis & Boucadair Informational [Page 18] RFC 5160 MQC and Provider QoS Agreements March 2008
レビー、Boucadairの情報[18ページ]のRFC5160MQC、および2008年のプロバイダーQoS協定行進
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78と 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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を記述してください。
Levis & Boucadair Informational [Page 19]
レビーとBoucadair情報です。[19ページ]
一覧
スポンサーリンク
