Network Working Group F. Le Faucheur, Ed.
Request for Comments: 4127 Cisco Systems, Inc.
Category: Experimental June 2005
Russian Dolls Bandwidth Constraints Model for
Diffserv-aware MPLS Traffic Engineering
Status of This Memo
このメモのステータス
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
This document provides specifications for one Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering, which is referred to as the Russian Dolls Model.
この文書では、ロシアの人形モデルと呼ばれているのDiffservを意識したMPLSトラフィックエンジニアリングのための1つの帯域幅制約モデルの仕様を提供します。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Specification of Requirements ..............................2
2. Contributing Authors ............................................3
3. Definitions .....................................................4
4. Russian Dolls Model Definition ..................................5
5. Example Formulas for Computing "Unreserved TE-Class [i]" with
Russian Dolls Model .............................................7
6. Receiving Both Maximum Reservable Bandwidth and Bandwidth
Constraints sub-TLVs ............................................8
7. Security Considerations .........................................8
8. IANA Considerations .............................................8
9. Acknowledgements ................................................9
Appendix A: Addressing [DSTE-REQ] Scenarios .......................10
Normative References ..............................................11
Informative References ............................................12
[DSTE-REQ] presents the Service Providers requirements for support of Diffserv-aware MPLS Traffic Engineering (DS-TE). This includes the fundamental requirement to be able to enforce different Bandwidth Constraints for different classes of traffic.
[DSTE - REQ]のDiffservを意識したMPLSトラフィックエンジニアリング（DSTE）をサポートするためのサービスプロバイダの要件を提示します。これは、トラフィックの異なるクラスに対して異なる帯域幅の制約を強制することができるように基本的な要件が含まれています。
[DSTE-REQ] also defines the concept of Bandwidth Constraints Model for DS-TE and states that "The DS-TE technical solution MUST specify at least one Bandwidth Constraints Model and MAY specify multiple Bandwidth Constraints Models".
[DSTE-REQ]もDSTEための帯域幅制約モデルの概念を定義し、「DSTE技術的解決法は、少なくとも1つの帯域幅制約モデルを指定しなければならないし、複数の帯域幅制約モデルを指定する場合がある」と述べています。
This document provides a detailed description of one particular Bandwidth Constraints Model for DS-TE which is introduced in [DSTE-REQ] and called the Russian Dolls Model (RDM).
この文書では、[DSTE-REQ]で導入され、ロシア人形モデル（RDM）と呼ばれるDSTEための1つの特定の帯域幅制約モデルの詳細な説明を提供します。
[DSTE-PROTO] specifies the Interior Gateway Protocol (IGP) and RSVP-TE signaling extensions for support of DS-TE. These extensions support RDM.
[DSTE - プロト]はインテリアゲートウェイプロトコル（IGP）とDSTEのサポートのためのRSVP-TEシグナリング拡張を指定します。これらの拡張機能は、RDMをサポートしています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
This document was the collective work of several authors. The text and content were contributed by the editor and the co-authors listed below. (The contact information for the editor appears in the Editor's Address section.)
この文書では、数人の著者の集合的な仕事でした。テキストやコンテンツはエディタと以下のとおり共著者によって寄与されました。 （編集者の連絡先情報は、編集者のアドレス]セクションに表示されます。）
Jim Boyle Kireeti Kompella Protocol Driven Networks, Inc. Juniper Networks, Inc. 1381 Kildaire Farm Road #288 1194 N. Mathilda Ave. Cary, NC 27511, USA Sunnyvale, CA 94099
ジム・ボイルKireeti Kompellaプロトコルドリブンネットワークスジュニパーネットワークス株式会社1381 Kildaire農道＃288 1194 N.マチルダアベニュー。カリー、NC 27511、USAカリフォルニア州サニーベール94099
Phone: (919) 852-5160 EMail: kireeti@juniper.net EMail: jboyle@pdnets.com
電話：（919）852-5160 Eメール：kireeti@juniper.net Eメール：jboyle@pdnets.com
William Townsend Thomas D. Nadeau Tenor Networks Cisco Systems, Inc. 100 Nagog Park 250 Apollo Drive Acton, MA 01720 Chelmsford, MA 01824
ウィリアム・タウンゼント・トーマスD.ナドーテナーネットワークシスコシステムズ社100 Nagog公園250アポロドライブアクトン、MA 01720チェルムズフォード、MA 01824
Phone: +1-978-264-4900 Phone: +1-978-244-3051 EMail: btownsend@tenornetworks.com EMail: tnadeau@cisco.com
電話：+ 1-978-264-4900電話：+ 1-978-244-3051 Eメール：btownsend@tenornetworks.com Eメール：tnadeau@cisco.com
Darek Skalecki Nortel Networks 3500 Carling Ave, Nepean K2H 8E9
Darek Skalecki Nortel Networksの3500カーリングアベニュー、ネピアンK2H 8E9
Phone: +1-613-765-2252 EMail: dareks@nortelnetworks.com
電話：+ 1-613-765-2252 Eメール：dareks@nortelnetworks.com
For readability a number of definitions from [DSTE-REQ] are repeated here:
読みやすくするために[DSTE - REQ]からの定義の数は、ここでは繰り返されています。
Class-Type (CT): the set of Traffic Trunks crossing a link that is governed by a specific set of bandwidth constraints. CT is used for the purposes of link bandwidth allocation, constraint-based routing and admission control. A given Traffic Trunk belongs to the same CT on all links.
クラス型（CT）：帯域幅の制約の特定のセットによって支配され、リンクを通過するトラフィックトランクのセット。 CTは、リンク帯域幅割り当て、制約ベースのルーティングとアドミッション制御の目的のために使用されます。与えられたトラフィックトランクは、すべてのリンク上の同じCTに属します。
TE-Class: A pair of:
TE-クラス：対：
i. a Class-Type
私。クラスタイプ
ii. a preemption priority allowed for that Class-Type. This means that an LSP transporting a Traffic Trunk from that Class-Type can use that preemption priority as the setup priority, the holding priority, or both.
II。先取り優先順位は、そのクラス型を可能にしました。これは、そのクラス型からのトラフィックトランクを運ぶLSPがセットアップ優先順位、保持優先度、またはその両方としてその先取り優先順位を使用できることを意味します。
A number of recovery mechanisms under investigation or specification in the IETF take advantage of the concept of bandwidth sharing across particular sets of LSPs. "Shared Mesh Restoration" in [GMPLS-RECOV] and "Facility-based Computation Model" in [MPLS-BACKUP] are example mechanisms that increase bandwidth efficiency by sharing bandwidth across backup LSPs protecting against independent failures. To ensure that the notion of "Reserved (CTc)" introduced in [DSTE-REQ] is compatible with such a concept of bandwidth sharing across multiple LSPs, the wording of the "Reserved (CTc)" definition provided in [DSTE-REQ] is generalized into the following:
IETFでの調査や仕様の下で回復メカニズムの数は、LSPの特定のセットの間の帯域幅の共有の概念を活用します。 [GMPLS-RECOV]で「共有メッシュ修復」と[MPLS-BACKUP]中の「施設ベースの計算モデルは、」独立障害に対する保護のバックアップLSPを横切って帯域幅を共有することによって帯域幅効率を高める例示的機構です。概念「予約（CTC）は、」[DSTE-REQ]で導入されていることを保証するためには、「予約（CTC）」の文言が定義内に設けられた複数のLSPを横切って帯域幅共有のような概念と互換性がある[DSTE-REQ]以下に一般化されます。
Reserved (CTc): For a given Class-Type CTc ( 0 <= c <= MaxCT ), let us define "Reserved(CTc)" as the total amount of the bandwidth reserved by all the established LSPs which belong to CTc.
予約（CTC）：指定されたクラス型CTC（0 <= C <= MaxCT）のために、私たちはCTCに属するすべての確立のLSPによって予約された帯域幅の合計量として「予約（CTC）」を定義してみましょう。
With this generalization, the Russian Dolls Model definition provided in this document is compatible with Shared Mesh Restoration defined in [GMPLS-RECOV], so that DS-TE and Shared Mesh Protection can operate simultaneously. This assumes that Shared Mesh Restoration operates independently within each DS-TE Class-Type and does not operate across Class-Types (for example, backup LSPs protecting Primary LSPs of CTx also need to belong to CTx; Excess Traffic LSPs sharing bandwidth with Backup LSPs of CTx also need to belong to CTx).
DS-TEと共有メッシュの保護が同時に動作できるように、この一般化では、このドキュメントに記載されているロシアの人形モデルの定義は、[GMPLS-RECOV]で定義された共有メッシュ修復と互換性があります。これは、共有メッシュ修復は、各DS-TEクラス型の中に独立して動作し、（例えば、CTXのプライマリLSPを保護するバックアップLSPのもCTXに属している必要があり、クラスタイプにわたって動作しないことを前提として、バックアップのLSPとの過剰なトラフィックのLSP共有帯域幅CTXのも）CTXに属している必要があります。
We also introduce the following definition:
我々はまた、次の定義を紹介します：
Reserved(CTb,q): Let us define "Reserved(CTb,q)" as the total amount of the bandwidth reserved by all the established LSPs that belong to CTb and have a holding priority of q. Note that if q and CTb do not form one of the 8 possible configured TE-Classes, then there cannot be any established LSPs that belongs to CTb and has a holding priority of q; therefore, in this case, Reserved(CTb,q) = 0.
（CTB、Q）予約：私たちはCTbをに属しているとqの保持優先度を持つすべての確立のLSPによって予約された帯域幅の合計量として「予約（CTB、q）を」定義しよう。 qおよびCTbを8可能に構成TE-クラスのいずれかを形成しない場合、CTbをに属し、Qの保持優先度を有する任意の確立したLSPが存在しないことに注意してください。従って、この場合、リザーブ（CTB、Q）= 0。
RDM is defined in the following manner:
RDMは、次のように定義されています。
o Maximum Number of Bandwidth Constraints (MaxBC)=
Maximum Number of Class-Types (MaxCT) = 8
o for each value of b in the range 0 <= b <= (MaxCT - 1): SUM (Reserved (CTc)) <= BCb, where the SUM is across all values of c in the range b <= c <= (MaxCT - 1)
O範囲0 <= bにおけるBの各値のために<=（MaxCT - 1）：SUM（予約（CTC））<= BCB、SUMは、範囲bにおけるcの全ての値を横切っている。ここで、<= C <= （MaxCT - 1）
o BC0= Maximum Reservable Bandwidth, so that SUM (Reserved(CTc)) <= Max-Reservable-Bw, where the SUM is across all values of c in the range 0 <= c <= (MaxCT - 1)
BC0 O =最大予約可能帯域幅、その結果SUM SUM範囲におけるcの全ての値を横切ってある（予約（CTC））<=最大予約可能-Bwを、0 <= C <=（MaxCT - 1）
A DS-TE LSR implementing RDM MUST support enforcement of Bandwidth Constraints in compliance with this definition.
RDMを実装DS-TE LSRは、この定義に準拠した帯域幅の制約の施行をサポートしなければなりません。
Both preemption within a CT and across CTs is allowed.
CTのCT内および間の両方でプリエンプションが許可されています。
Where 8 CTs are active, the RDM Bandwidth Constraints can also be expressed in the following way:
8つのCTSがアクティブである場合、RDM帯域幅の制約は、以下のように表すことができます。
- All LSPs from CT7 use no more than BC7
- CT7からのすべてのLSPはBC7以下で使用しません
- All LSPs from CT6 and CT7 use no more than BC6
- CT6とCT7からのすべてのLSPはBC6以下で使用しません
- All LSPs from CT5, CT6 and CT7 use no more than BC5
- CT5、CT6とCT7からのすべてのLSPはBC5以下で使用しません
- etc.
- など
- All LSPs from CT0, CT1, ..., CT7 use no more than BC0 = "Maximum Reservable Bandwidth"
- CT0、CT1、からのすべてのLSPは...、CT7はBC0 =「最大予約可能帯域幅」以下で使用しません
Purely for illustration purposes, the diagram below represents the Russian Dolls Bandwidth Constraints Model in a pictorial manner when 3 Class-Types are active:
3クラスタイプがアクティブである場合、純粋に例示の目的のために、以下の図は、絵のようにロシア人形帯域幅の制約のモデルを表します。
I------------------------------------------------------I
I-------------------------------I I
I--------------I I I
I CT2 I CT2+CT1 I CT2+CT1+CT0 I
I--------------I I I
I-------------------------------I I
I------------------------------------------------------I
I-----BC2------>
I----------------------BC1------>
I------------------------------BC0=Max Reservable Bw--->
While simpler Bandwidth Constraints models or, conversely, more flexible/sophisticated Bandwidth Constraints models can be defined, the Russian Dolls Model is attractive in some DS-TE environments for the following reasons:
逆にシンプルな帯域幅の制約モデルや、一方で、より柔軟な/洗練された帯域幅の制約モデルを定義することができ、ロシアの人形のモデルは、次の理由のためにいくつかのDS-TEの環境で魅力的です。
- Although it is a little less intuitive than the Maximum Allocation Model (see [DSTE-MAM]), RDM is still a simple model to conceptualize.
- それは、最大割当モデルよりもやや少ない直感的ではあるが、RDMは、概念化するための単純なモデルがまだある（[DSTE-MAM]を参照）。
- RDM can be used simultaneously to ensure bandwidth efficiency and to protect against QoS degradation of all CTs, whether preemption is used or not.
- RDMは、プリエンプションが使用されているか否か、帯域幅効率を確保するために、すべてのCTの品質劣化から保護するために同時に使用することができます。
- RDM can be used in conjunction with preemption to simultaneously achieve (i) isolation across CTs (so that each CT is guaranteed its share of bandwidth no matter the level of contention by other classes), (ii) bandwidth efficiency, and (iii) protection against QoS degradation of all CTs.
- （各CTは、帯域幅のシェアに関係なく、他のクラスによる競合のレベルを保証されるように）RDMを同時にCTを横切る（I）の分離を達成するために、プリエンプションと組み合わせて使用することができ、（ii）の帯域幅効率、および（iii）すべてのCTのQoSの劣化に対する保護。
- RDM only requires limited protocol extensions such as the ones defined in [DSTE-PROTO].
- RDMのみような[DSTE - プロト]で定義されるものと限定されたプロトコルの拡張を必要とします。
RDM may not be attractive in some DS-TE environments for the following reasons:
RDMは、次の理由のためのいくつかのDS-TEの環境では、魅力的ではないかもしれません。
- if the usage of preemption is precluded for some administrative reason, while RDM can still ensure bandwidth efficiency and protection against QoS degradation of all CTs, RDM cannot guarantee isolation across Class-Types.
- RDMは、まだすべてのCTのQoSの劣化に対する帯域幅の効率性と保護を確保することができますしながら、プリエンプションの使用量は、いくつかの管理理由で除外されている場合、RDMは、クラス・タイプ間のアイソレーションを保証することはできません。
Additional considerations on the properties of RDM can be found in [BC-CONS] and [BC-MODEL].
RDMの性質に関する追加の考慮は[BC-CONS]および[BC-MODEL]で見つけることができます。
As a simple example usage of the "Russian Dolls" Bandwidth Constraints Model, a network administrator, using one CT for Voice (CT1) and one CT for data (CT0), might configure on a given link:
声のための1つのCT（CT1）とデータ（CT0）ごとに1つのCTを使用して「ロシア人形」帯域幅の制約モデル、ネットワーク管理者、の簡単な使用例としては、与えられたリンクの上に構成することができます：
- BC0 = Max-Reservable - Bw = 2.5 Gb/s (i.e., Voice + Data is limited to 2.5 Gb/s)
- BC0 =最大予約可能 - BWは2.5ギガビット/秒=（すなわち、音声+データは2.5 Gb /秒に制限されます）
- BC1 = 1.5 Gb/s (i.e., Voice is limited to 1.5 Gb/s).
- BC1 = 1.5ギガビット/秒（すなわち、音声は1.5 Gb /秒に制限されます）。
5. Example Formulas for Computing "Unreserved TE-Class [i]" with Russian Dolls Model
ロシアの人形のモデルと5例式コンピューティングのための「非予約TEクラス[i]を」
As specified in [DSTE-PROTO], formulas for computing "Unreserved TE-Class [i]" MUST reflect all of the Bandwidth Constraints relevant to the CT associated with TE-Class[i], and thus, depend on the Bandwidth Constraints Model. Thus, a DS-TE LSR implementing RDM MUST reflect the RDM Bandwidth Constraints defined in section 4 above when computing "Unreserved TE-Class [i]".
[DSTE - プロト]で指定されているように、計算するための式「非予約TEクラス[i]は」[i]のTE-クラスに関連付けられているCTに関連する帯域幅の制約のすべてを反映しなければなりませんし、したがって、帯域幅の制約モデルに依存します。したがって、RDMを実現DS-TE LSRは「未予約TEクラス[I]」を計算するときに上方セクション4で定義されたRDM帯域幅の制約を反映しなければなりません。
As explained in [DSTE-PROTO], the details of admission control algorithms, as well as formulas for computing "Unreserved TE-Class [i]", are outside the scope of the IETF work. Keeping that in mind, we provide in this section an example for illustration purposes, of how values for the unreserved bandwidth for TE-Class[i] might be computed with RDM. In the example, we assume the basic admission control algorithm, which simply deducts the exact bandwidth of any established LSP from all of the Bandwidth Constraints relevant to the CT associated with that LSP.
[DSTE - プロト]で説明したように、「未予約TEクラス[I]」を計算するためのアドミッション制御アルゴリズムの詳細、ならびに式は、IETF作業の範囲外です。心の中で、我々はTEクラス[i]のために予約されていない帯域幅の値がRDMで計算されるかもしれない方法で、説明のために、このセクションの例を提供することを維持します。例では、我々は単にそのLSPに関連したCTに関連する帯域幅の制約の全てから任意の確立LSPの正確な帯域幅が差し引かれ、基本的なアドミッション制御アルゴリズムを、想定しています。
We assume that:
我々はそれを前提としています。
TE-Class [i] <--> < CTc , preemption p>
TE-Classの[I] < - > <CTC、プリエンプションのp>
in the configured TE-Class mapping.
構成されたTE-クラスマッピングインチ
For readability, formulas are first shown assuming only 3 CTs are active. The formulas are then extended to cover the cases where more CTs are used.
読みやすくするために、式は最初のみ3 CTSがアクティブであると仮定すると示されています。式は、より多くのCTSが使用されている例をカバーするように拡張されています。
If CTc = CT0, then "Unreserved TE-Class [i]" = [ BC0 - SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b <= 2
qに対して<= pおよび0 <= B <= 2 - CTC = CT0、次いで、 "未予約TEクラス[i]が" = [（（CTB、Q）予約）SUM BC0]もし
If CTc = CT1, then "Unreserved TE-Class [i]" = MIN [ [ BC1 - SUM ( Reserved(CTb,q) ) ] for q <= p and 1 <= b <= 2, [ BC0 - SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b <= 2 ]
もしCTC = CT1、次いで、 "未予約TEクラス[I]" = MIN [BC1 - qに対してSUM（予約（CTB、Q））<= P 1 <= B <= 2、[BC0 - SUM（予約（CTB、Q））] Qについて<= pおよび0 <= bの<= 2]
If CTc = CT2, then "Unreserved TE-Class [i]" = MIN [ [ BC2 - SUM ( Reserved(CTb,q) ) ] for q <= p and 2 <= b <= 2, [ BC1 - SUM ( Reserved(CTb,q) ) ] for q <= p and 1 <= b <= 2, [ BC0 - SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b <= 2 ]
もしCTC = CT2、次いで、 "未予約TEクラス[I]" = MIN [BC2 - qに対してSUM（予約（CTB、Q））<= P 2 <= B <= 2、[BC1 - SUM（ qに対して（CTB、Q））]予約<= P 1 <= B <= 2、[BC0 - qに対してSUM（予約（CTB、Q））<= P 0 <= B <= 2]
The formula can be generalized to 8 active CTs and expressed in a more compact way in the following:
式8回の活性のCTに一般化し、以下でよりコンパクトな方法で表すことができます。
"Unreserved TE-Class [i]" = MIN [ [ BCc - SUM ( Reserved(CTb,q) ) ] for q <= p and c <= b <= 7, [ BC(c-1) - SUM ( Reserved(CTb,q) ) ] for q <= p and (c-1)<= b <= 7, . . . [ BC0 - SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b <= 7, ]
"未予約TEクラス[I]" = MIN [BCC - qに対してSUM（予約（CTB、Q））<= pおよびC <= bの<= 7、[BC（C-1） - SUM（予約済み（CTB、Q））] Qについて<= p及び（C-1）<= bの<= 7、。 。 。 Q用 - [BC0 SUM（予約（CTB、Q））<= P 0 <= B <= 7]
where:
どこ：
TE-Class [i] <--> < CTc , preemption p> in the configured TE-Class mapping.
TEクラス[I] < - > <CTC、プリエンプションP>構成TEクラスのマッピングです。
6. Receiving Both Maximum Reservable Bandwidth and Bandwidth Constraints sub-TLVs
最大予約可能帯域幅と帯域幅の制約サブTLVの両方を受信する6
[DSTE-PROTO] states that "A DS-TE LSR, which does advertise BCs, MUST use the new "Bandwidth Constraints" sub-TLV (in addition to the existing Maximum Reservable Bandwidth sub-TLV) to do so."
[DSTE - プロト]は、「そうするサブTLV（既存の予約可能な最大帯域幅サブTLVに加えて）。 『帯域幅の制約』のBCを宣伝しDSTE LSRは、新しいを使用しなければならない」と述べています
With RDM, BC0 is equal to the Maximum Reservable Bandwidth because they both represent the aggregate constraint across all CTs. Thus, a DS-TE LSR, receiving both the "Maximum Reservable Bw" sub-TLV and the new "Bandwidth Constraints" sub-TLV (which contains BC0) for a given link where the RDM model is used, MAY ignore the "Maximum Reservable Bw" sub-TLV.
どちらも全てのCT横切って集計制約を表すためRDMと、BC0は、最大予約可能帯域幅に等しいです。したがって、受信DS-TE LSR、両方の「最大予約Bwを」サブTLVとRDMモデルが使用され、所与のリンクのための新たな「帯域幅制約」（BC0を含む）のサブTLVは、「最大を無視してもよいです予約可能ベストウエスタン」サブTLV。
Security considerations related to the use of DS-TE are discussed in [DSTE-PROTO]. Those apply independently of the Bandwidth Constraints Model, including RDM specified in this document.
DSTEの使用に関連するセキュリティ上の考慮事項は、[DSTE - プロト]で議論されています。これらは、この文書で指定されたRDMを含め、帯域幅の制約モデルとは独立して適用されます。
[DSTE-PROTO] defines a new name space for "Bandwidth Constraints Model Id". The guidelines for allocation of values in that name space are detailed in section 13.1 of [DSTE-PROTO]. In accordance
[DSTE - プロト]は、「帯域幅の制約モデルID」の新しい名前空間を定義します。その名前空間内の値の割り当てのためのガイドラインは[DSTE - プロト]のセクション13.1に詳述されています。よると
with these guidelines, the IANA has assigned a Bandwidth Constraints Model Id for RDM from the range 0-239 (which is to be managed as per the "Specification Required" policy defined in [IANA-CONS]).
これらのガイドラインに、IANAは、（[IANA-CONS]で定義された「仕様必須」ポリシーに従って管理される）範囲0から239からRDMのための帯域幅制約モデルIDが割り当てられています。
Bandwidth Constraints Model Id 0 was allocated by IANA to RDM.
帯域幅の制約モデルIDが0をRDMにIANAによって割り当てられました。
We thank Martin Tatham for his key contribution in this work. Tatiana Renko is also warmly thanked for her instantiation of the Russian Doll.
私たちは、この作品で彼の主要な貢献のためのマーティンタサムに感謝します。タチアナ蓮子も暖かくロシア人形の彼女のインスタンス化のために感謝しています。
Appendix A: Addressing [DSTE-REQ] Scenarios
付録A：アドレッシング[DSTE - REQ]シナリオ
This appendix provides examples of how the Russian Dolls Bandwidth Constraints Model can be used to support each of the scenarios described in [DSTE-REQ].
この付録では、ロシアの人形帯域幅制約モデルは[DSTE-REQ]に記載の各シナリオをサポートするために使用することができる方法の例を提供します。
A.1. Scenario 1: Limiting Amount of Voice
A.1。シナリオ1：音声の量を制限します
By configuring on every link:
すべてのリンクを構成することにより：
- Bandwidth Constraint 1 (for CT1 = Voice) = "certain percentage" of link capacity
- リンク容量の帯域幅制約1（CT1 =ボイス用）=「一定の割合」
- BC0 (for CT1=Voice + CT0=Data) = link capacity
- BC0（CT1 =音声+ CT0 =データ用）=リンク容量
By configuring:
構成することにより：
- every CT1/Voice TE-LSP with preemption = 0
- 先取り= 0を持つすべてのCT1 /音声TE-LSP
- every CT0/Data TE-LSP with preemption = 1
- 先取り= 1毎CT0 /データTE-LSP
DS-TE with the Russian Dolls Model will address all the requirements:
ロシアの人形のモデルとDS-TEは、すべての要件に対処します：
- amount of Voice traffic limited to desired percentage on every link
- すべてのリンク上の所望の割合に制限され、音声トラフィックの量
- data traffic capable of using all remaining link capacity
- 残りのすべてのリンク容量を使用することができるデータトラフィック
- voice traffic capable of preempting other traffic
- 他のトラフィックを優先処理できる音声トラフィック
A.2. Scenario 2: Maintain Relative Proportion of Traffic Classes
A.2。シナリオ2：トラフィッククラスの相対的な割合を維持
By configuring on every link:
すべてのリンクを構成することにより：
- BC2 (for CT2) = e.g., 45%
- BC2（用CT2）=例えば、45％
- BC1 (for CT1+CT2) = e.g., 80%
- （CT1 + CT2用）BC1例えば= 80％
- BC0 (for CT0+CT1+CT2) = e.g., 100%
- （CT0 + CT1 + CT2用）BC0例えば= 100％
DS-TE with the RDM will ensure that the amount of traffic of each CT established on a link is within acceptable levels as compared to the resources allocated to the corresponding Diffserv Per Hop Behaviors (PHBs) regardless of which order the LSPs are routed in, regardless of which preemption priorities are used by which LSPs and regardless of failure situations.
RDMとDS-TEは、そのLSPのがでルーティングされる順序に関係なく、対応するDiffservの当たりホップビヘイビア（のPHB）に割り当てられたリソースに比べてリンクを確立し、各CTのトラフィック量が許容レベル内にあることを確実にしますかかわらず、優先順位がどのLSPをとにかかわらず、障害の状況によって使用されているプリエンプションの。
By also configuring:
また、構成することにより：
- every CT2/Voice TE-LSP with preemption = 0
- 先取り= 0を持つすべてのCT2 /音声TE-LSP
- every CT1/Premium Data TE-LSP with preemption = 1
- 先取り= 1を持つすべてのCT1 /プレミアムデータTE-LSP
- every CT0/Best-Effort TE-LSP with preemption = 2
- 先取り= 2を持つすべてのCT0 /ベストエフォートTE-LSP
DS-TE with the Russian Dolls Model will also ensure that:
ロシアの人形のモデルとDS-TEものことを確認します。
- CT2 Voice LSPs always have first preemption priority in order to use the CT2 capacity
- CT2音声LSPは常にCT2の容量を使用するために、最初の先取り優先権を持っています
- CT1 Premium Data LSPs always have second preemption priority in order to use the CT1 capacity
- CT1プレミアムデータLSPは常にCT1の容量を使用するために、第2の先取り優先権を持っています
- Best-Effort can use up to link capacity of what is left by CT2 and CT1.
- ベストエフォートはCT2とCT1で残っているものの容量をリンクするまで使用できます。
Optional automatic adjustment of Diffserv scheduling configuration could be used for maintaining very strict relationships between the amounts of established traffic of each Class Type and corresponding Diffserv resources.
Diffservのスケジューリング設定のオプションの自動調整は、各クラス型の確立トラフィックと対応するDiffservの資源の量との間に非常に厳格な関係を維持するために使用することができます。
A.3. Scenario 3: Guaranteed Bandwidth Services
A.3。シナリオ3：保証帯域幅サービス
By configuring on every link:
すべてのリンクを構成することにより：
- BC1 (for CT1) = "given" percentage of link bandwidth (appropriate to achieve the Guaranteed Bandwidth service's QoS objectives)
- BC1（CT1用）=「与えられた」リンク帯域幅の割合（適切な保証帯域幅サービスのQoS目標を達成するために）
- BC0 (for CT0+CT1) = 100% of link bandwidth
- （CT0 + CT1用）BC0 =リンク帯域幅の100％
DS-TE with the Russian Dolls Model will ensure that the amount of Guaranteed Bandwidth Traffic established on every link remains below the given percentage so that it will always meet its QoS objectives. At the same time, it will allow traffic engineering of the rest of the traffic such that links can be filled up.
ロシアの人形のモデルとDS-TEは、それは常にそのQoSの目標を達成するように、すべてのリンクを確立保証された帯域幅トラフィックの量が一定割合以下に留まることを保証します。同時に、それはリンクが埋めることができるように、トラフィックの残りのトラフィックエンジニアリングが可能になります。
Normative References
引用規格
[DSTE-REQ] Le Faucheur, F. and W. Lai, "Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering", RFC 3564, July 2003.
[DSTE - REQ]ルFaucheur、F.およびW.ライ、 "差別化サービスを意識したMPLSトラフィックエンジニアリングのサポートのための要件"、RFC 3564、2003年7月。
[DSTE-PROTO] Le Faucheur, F., Ed., "Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering", RFC 4124, June 2005.
[DSTE - プロト]ルFaucheur、F.、エド。、 "Diffservの認識MPLSトラフィックエンジニアリングのサポートのためのプロトコル拡張機能"、RFC 4124、2005年6月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[IANA-CONS] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[IANA-CONS] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
Informative References
参考文献
[BC-CONS] Le Faucheur, F., "Considerations on Bandwidth Constraints Model for DS-TE", Work in Progress, June 2002.
[BC-CONS]ルFaucheur、F.、 "DS-TEのための帯域幅制約モデルの検討"、進歩、2002年6月での作業。
[BC-MODEL] Lai, W., "Bandwidth Constraints Models for Differentiated Services (Diffserv)-aware MPLS Traffic Engineering: Performance Evaluation", RFC 4128, June 2005.
[BC-MODEL]ライ、W.、 "差別化サービス（DiffServ）のための帯域幅制約モデルの-aware MPLSトラフィックエンジニアリング：性能評価"、RFC 4128、2005年6月。
[DSTE-MAM] Le Faucheur, F. and W. Lai, "Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC 4125, June 2005.
[DSTE-MAM]ルFaucheur、F.およびW.ライ、 "Diffservの認識MPLSトラフィックエンジニアリングの最大割り当て帯域幅の制約モデル"、RFC 4125、2005年6月。
[GMPLS-RECOV] Lang, et al., "Generalized MPLS Recovery Functional Specification", Work in Progress.
[GMPLS-RECOV]ラングら、 "一般化MPLS回復機能的な仕様"、ProgressのWork。
[MPLS-BACKUP] Vasseur, et al., "MPLS Traffic Engineering Fast Reroute: Bypass Tunnel Path Computation for Bandwidth Protection", Work in Progress.
[MPLS-BACKUP] Vasseurら、「MPLSトラフィックエンジニアリング高速リルート：帯域幅保護のためのバイパストンネル経路計算」。、進行中の作業。
Editor's Address
編集者の住所
Francois Le Faucheur Cisco Systems, Inc. Village d'Entreprise Green Side - Batiment T3 400, Avenue de Roumanille 06410 Biot-Sophia Antipolis France
フランソワ・リーパーシスコシステムズ社コーポレート・ヴィレッジグリーンサイド - T3ビル400、アベニューRoumanille 06410ビオ・ソフィアアンティポリス、フランス
Phone: +33 4 97 23 26 19 EMail: flefauch@cisco.com
電話：+33 4 97 23 26 19 Eメール：flefauch@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。