[要約] 要約：RFC 4127は、Diffserv-aware MPLS Traffic Engineeringにおけるロシア人人形帯域制約モデルについての技術仕様です。 目的：このRFCの目的は、MPLSネットワークでのトラフィックエンジニアリングにおいて、帯域制約を効果的に管理するためのモデルを提供することです。
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
diffserv-aware MPLSトラフィックエンジニアリングのためのロシアの人形帯域幅の制約モデル
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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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-Aware 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-Aware MPLSトラフィックエンジニアリング（DS-TE）のサポートに関するサービスプロバイダーの要件を提示します。これには、さまざまなクラスのトラフィックに異なる帯域幅の制約を実施できるための基本的な要件が含まれます。
[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]は、DS-TEの帯域幅制約モデルの概念を定義し、「DS-TE技術ソリューションは少なくとも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）と呼ばれるDS-TEの特定の帯域幅制約モデルの詳細な説明を提供します。
[DSTE-PROTO] specifies the Interior Gateway Protocol (IGP) and RSVP-TE signaling extensions for support of DS-TE. These extensions support RDM.
[DSTE-PROTO] DS-TEのサポートのために、インテリアゲートウェイプロトコル（IGP）および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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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
Phone: (919) 852-5160 EMail: kireeti@juniper.net
EMail: 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
Phone: +1-978-264-4900 Phone: +1-978-244-3051
EMail: btownsend@tenornetworks.com EMail: tnadeau@cisco.com
Darek Skalecki Nortel Networks 3500 Carling Ave, Nepean K2H 8E9
Darek Skalecki Nortel Networks 3500 Carling Ave、Nepean K2H 8E9
Phone: +1-613-765-2252
EMail: 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-Class：1ペア：
i. a Class-Type
i. クラスタイプ
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全体で帯域幅を共有することにより帯域幅の効率を高めるメカニズムの例です。[dste-req]で導入された「予約済み（CTC）」の概念が、複数のLSPにわたる帯域幅共有の概念と互換性があることを確認するために、[dste-req]で提供される「予約済み（CTC）」定義の言葉遣いは以下に一般化されています。
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).
この一般化により、このドキュメントで提供されるロシアの人形モデルの定義は、[GMPLS-Recov]で定義された共有メッシュの復元と互換性があるため、DS-TEと共有メッシュ保護は同時に動作できます。これは、共有メッシュの復元が各DS-TEクラスタイプ内で独立して動作し、クラスタイプ全体で動作しないことを前提としています（たとえば、CTXのプライマリLSPを保護するバックアップLSPもCTXに属する必要があります。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に属するすべての確立されたLSPによって予約され、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 帯域幅の制約の最大数（MAXBC）=クラスタイプの最大数（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 範囲内のbの各値について0 <= b <=（maxct -1）：sum（reserved（ctc））<= bcb。ここで、範囲b <= 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)
o BC0 =最大予約可能な帯域幅、その合計（予約済み（CTC））<= MAX-RESERVABLE-BW。
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つのCTがアクティブな場合、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、...、CT7からのすべてのLSPSは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.
- 最大割り当てモデルよりも少し直感的ではありませんが（[dste-mam]を参照）、RDMは概念化する簡単なモデルです。
- 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のQOS分解から保護できます。
- 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.
- RDMは、（i）CTS全体での分離を同時に達成するために先制と組み合わせて使用できます（そのため、各CTは他のクラスによる競合レベルに関係なく帯域幅のシェアを保証します）、（ii）帯域幅効率、および（iii）保護すべてのCTのQoS分解に対して。
- RDM only requires limited protocol extensions such as the ones defined in [DSTE-PROTO].
- RDMは、[dste-proto]で定義されているような限られたプロトコル拡張機能のみを必要とします。
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はすべてのCTSの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）に1つのCTを使用し、データに1つのCT（CT0）を使用して、ネットワーク管理者が特定のリンクで構成される場合があります。
- BC0 = Max-Reservable - Bw = 2.5 Gb/s (i.e., Voice + Data is limited to 2.5 Gb/s)
- bc0 = max -reservable -bw = 2.5 gb/s（つまり、音声データは2.5 gb/sに制限されています）
- BC1 = 1.5 Gb/s (i.e., Voice is limited to 1.5 Gb/s).
- BC1 = 1.5 gb/s（つまり、音声は1.5 gb/sに制限されています）。
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-Proto]で指定されているように、「予約されていないTEクラス[i]」を計算するための式は、TEクラス[i]に関連する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-proto]で説明されているように、Andiming Control Algorithmsの詳細と、「予約されていないTE-Class [i]」を計算するための式は、IETF作業の範囲外です。それを念頭に置いて、このセクションでは、TEクラスの予約されていない帯域幅の値[i]がRDMで計算される方法のイラストの目的の例を提供します。この例では、基本的な入場制御アルゴリズムを想定しています。これは、そのLSPに関連するCTに関連するすべての帯域幅の制約から、確立されたLSPの正確な帯域幅を単純に差し引くだけです。
We assume that:
私たちはそれを想定しています：
TE-Class [i] <--> < CTc , preemption 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つのCTのみがアクティブであると仮定して、式が最初に示されています。次に、式が拡張され、より多くのCTが使用される場合をカバーします。
If CTc = CT0, then "Unreserved TE-Class [i]" =
[ BC0 - SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b <= 2
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
]
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
]
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,
]
where:
ただし：
TE-Class [i] <--> < CTc , preemption p> in the configured TE-Class mapping.
te-class [i] < - > <ctc、構成されたTEクラスマッピングのプリエンプションP>。
[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-Proto]は、「BCSを宣伝するDS-TE 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.
RDMを使用すると、BC0は、すべてのCTにわたる凝集制約を表すため、最大予約可能な帯域幅に等しくなります。したがって、DS-TE LSRは、RDMモデルが使用される特定のリンクの「最大予約可能なBW」Sub-TLVと新しい「帯域幅制約」Sub-TLV（BC0を含む）の両方を受信しますが、「最大最大値を無視する可能性があります。予約可能なBW "sub-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.
DS-TEの使用に関連するセキュリティ上の考慮事項は、[DSTE-Proto]で説明されています。これらは、このドキュメントで指定された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 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]).
[dste-proto]「帯域幅制約モデルID」の新しい名前空間を定義します。その名前空間における値の割り当てのガイドラインは、[dste-proto]のセクション13.1に詳述されています。これらのガイドラインに従って、IANAは範囲0-239（[IANA-Cons]で定義された「必要な」ポリシーに従って管理される）からRDMの帯域幅制約モデルIDを割り当てました。
Bandwidth Constraints Model Id 0 was allocated by IANA to RDM.
帯域幅の制約モデルID 0は、IANAによってRDMに割り当てられました。
We thank Martin Tatham for his key contribution in this work. Tatiana Renko is also warmly thanked for her instantiation of the Russian Doll.
マーティン・タタムは、この作業で重要な貢献をしてくれたことに感謝します。Tatiana Renkoは、ロシアの人形のインスタンス化にも温かく感謝しています。
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]で説明されている各シナリオをサポートするために、ロシアの人形帯域幅の制約モデルを使用する方法の例を示しています。
By configuring on every link:
すべてのリンクで構成することにより：
- Bandwidth Constraint 1 (for CT1 = Voice) = "certain percentage" of link capacity
- 帯域幅の制約1（CT1 = Voiceの場合）=リンク容量の「特定の割合」
- BC0 (for CT1=Voice + CT0=Data) = link capacity
- bc0（ct1 = voice ct0 = data）= link容量
By configuring:
設定：
- every CT1/Voice TE-LSP with preemption = 0
- すべてのCT1/Voice TE-LSPがプリエンプション= 0です
- every CT0/Data TE-LSP with preemption = 1
- すべてのCT0/データTE-LSPがプリエンプション= 1
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
- 他のトラフィックを先取りできる音声トラフィック
By configuring on every link:
すべてのリンクで構成することにより：
- BC2 (for CT2) = e.g., 45%
- BC2（CT2用）=たとえば、45％
- BC1 (for CT1+CT2) = e.g., 80%
- BC1（CT1 CT2の場合）=たとえば、80％
- BC0 (for CT0+CT1+CT2) = e.g., 100%
- BC0（CT0 CT1 CT2の場合）=たとえば、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は、リンクで確立された各CTのトラフィックの量が、LSPがどの順序でルーティングされるかに関係なく、対応するDiffserv PER HOP Beevior（PHB）に割り当てられたリソースと比較して、許容レベル内にあることを保証します。どのLSPによって使用されるかに関係なく、障害状況に関係なく。
By also configuring:
また、構成することによって：
- every CT2/Voice TE-LSP with preemption = 0
- すべてのCT2/Voice TE-LSPがプリエンプション= 0です
- every CT1/Premium Data TE-LSP with preemption = 1
- すべてのCT1/プレミアムデータTE-LSPがプリエンプション= 1
- every CT0/Best-Effort TE-LSP with preemption = 2
- すべてのCT0/Best-Effort TE-LSPがプリエンプション= 2
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.
- Best-Effortは、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リソースの間の非常に厳しい関係を維持するために使用できます。
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
- BC0（CT0 CT1用）=リンク帯域幅の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] Le Faucheur、F。およびW. Lai、「差別化されたサービス認識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-Proto] Le Faucheur、F.、ed。、「Diffserv-aware 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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Le 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] Lai、W。、「差別化されたサービスの帯域幅制約モデル（DIFFSERV） - アウェア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] Le Faucheur、F。およびW. Lai、「Diffserv-aware MPLSトラフィックエンジニアリングの最大割り当て帯域幅制約モデル」、RFC 4125、2005年6月。
[GMPLS-RECOV] Lang, et al., "Generalized MPLS Recovery Functional Specification", Work in Progress.
[Gmpls-Recov] Lang、et al。、「一般化されたMPLS回復機能仕様」、進行中の作業。
[MPLS-BACKUP] Vasseur, et al., "MPLS Traffic Engineering Fast Reroute: Bypass Tunnel Path Computation for Bandwidth Protection", Work in Progress.
[MPLS-Backup] Vasseur、et al。、「MPLS Traffic Engineering Fast Reroute：帯域幅保護のためのバイパストンネルパス計算」、進行中の作業。
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
Francois Le Faucheur Cisco Systems、Inc。Village D'Entreprise Green Side -Batiment T3 400、Avenue de Roumanille 06410 Biot -Sophia Antipolis France
Phone: +33 4 97 23 26 19
EMail: flefauch@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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への情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。