Network Working Group F. Le Faucheur
Request for Comments: 4125 Cisco Systems, Inc.
Category: Experimental W. Lai
AT&T Labs
June 2005
Maximum Allocation 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 Maximum Allocation Model.
この文書では、最大配分モデルと呼ばれているのDiffservを意識したMPLSトラフィックエンジニアリングのための1つの帯域幅制約モデルの仕様を提供します。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Specification of Requirements ..............................2
2. Definitions .....................................................2
3. Maximum Allocation Model Definition .............................3
4. Example Formulas for Computing "Unreserved TE-Class [i]" with
Maximum Allocation Model.........................................6
5. Security Considerations .........................................7
6. IANA Considerations .............................................7
7. Acknowledgements ................................................7
Appendix A: Addressing [DSTE-REQ] Scenarios.........................8
Normative References...............................................10
Informative References.............................................10
[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 Maximum Allocation Model (MAM).
この文書では、[DSTE-REQ]に導入し、最大割り当てモデル（MAM）と呼ばれるDSTE、のための1つの特定の帯域幅制約モデルの詳細な説明を提供します。
[DSTE-PROTO] specifies the IGP and RSVP-TE signaling extensions for support of DS-TE. These extensions support MAM.
[DSTE - プロト]はIGPとRSVP-TEはDSTEのサポートのための拡張シグナリング指定します。これらの拡張機能は、MAMをサポートしています。
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]に記載されているように解釈されます。
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 set-up priority, as 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 Maximum Allocation 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。
MAM is defined in the following manner:
MAMは、次のように定義されています。
o Maximum Number of Bandwidth Constraints (MaxBC) =
Maximum Number of Class-Types (MaxCT) = 8
o for each value of c in the range 0 <= c <= (MaxCT - 1): Reserved (CTc) <= BCc <= Max-Reservable-Bandwidth,
O範囲0 <= C <=（MaxCT - 1）におけるcの値ごとに：予約（CTC）<= BCC <=最大予約可能帯域幅、
o SUM (Reserved(CTc)) <= Max-Reservable-Bandwidth where the SUM is across all values of c in the range 0 <= c <= (MaxCT - 1)
入出力SUM（予約（CTC））<= SUM範囲におけるcの全ての値を横切っている最大予約可能帯域幅0 <= C <=（MaxCT - 1）
A DS-TE LSR implementing MAM MUST support enforcement of Bandwidth Constraints in compliance with this definition.
MAMを実装DS-TE LSRは、この定義に準拠した帯域幅の制約の施行をサポートしなければなりません。
To increase the degree of bandwidth sharing among the different CTs, the sum of Bandwidth Constraints may exceed the Maximum Reservable Bandwidth, so that the following relationship may hold true:
以下の関係が成立することができるように、異なるCTの間で帯域幅共有の程度を増加させるために、帯域幅の制約の和が、最大予約可能帯域幅を超えてもよいです。
o SUM (BCc) > Max-Reservable-Bandwidth,
where the SUM is across all values of c in the range
0 <= c <= (MaxCT - 1)
The sum of Bandwidth Constraints may also be equal to (or below) the Maximum Reservable Bandwidth. In that case, the Maximum Reservable Bandwidth does not actually constrain CT bandwidth reservations (in other words, the 3rd bullet item of the MAM definition above will never effectively come into play). This is because the 2nd bullet item of the MAM definition above implies that:
帯域幅の制約の和は、（以下）最大予約可能帯域幅に等しくてもよいです。その場合には、最大予約可能帯域幅は、実際に（つまり、上記MAM定義の第三箇条書き項目が効果的に遊びに来たことがないだろう）CT帯域幅の予約を制限しません。上記MAM定義の第二箇条書き項目があることを意味するからです。
SUM (reserved(CTc)) <= SUM (BCc)
SUM（予約（CTC））<= SUM（BCC）
and we assume here that
そして、私たちはここにいると仮定します
SUM (BCc) <= Maximum Reservable Bandwidth.
SUM（BCC）<=最大予約可能帯域幅。
Therefore, it will always be true that:
したがって、それは常にその真になります。
SUM (Reserved(CTc)) <= Max-Reservable-Bandwidth.
SUM（予約済み（CTC））<=マックス・予約可能帯域幅。
Both preemption within a CT and across CTs is allowed.
CTのCT内および間の両方でプリエンプションが許可されています。
Where 8 CTs are active, the MAM Bandwidth Constraints can also be expressed in the following way:
8つのCTSがアクティブである場合、MAMの帯域幅の制約は、以下のように表すことができます。
- All LSPs from CT7 use no more than BC7
- CT7からのすべてのLSPはBC7以下で使用しません
- All LSPs from CT6 use no more than BC6
- CT6からのすべてのLSPはBC6以下で使用しません
- All LSPs from CT5 use no more than BC5
- CT5からのすべてのLSPはBC5以下で使用しません
- etc.
- など
- All LSPs from CT0 use no more than BC0
- CT0からのすべてのLSPはBC0以下で使用しません
- All LSPs from all CTs collectively use no more than the Maximum Reservable Bandwidth
- すべてのCTからのすべてのLSPは、総称して、最大予約可能帯域幅よりも多くを使用していません
Purely for illustration purposes, the diagram below represents MAM in a pictorial manner when 3 CTs are active:
3つのCTSがアクティブである場合、純粋に例示の目的のために、以下の図は、絵のようにしてMAMを表します。
I----------------------------I
<---BC0---> I
I---------I I
I I I
I CT0 I I
I I I
I---------I I
I I
I I
<-------BC1-------> I
I-----------------I I
I I I
I CT1 I I
I I I
I-----------------I I
I I
I I
<-----BC2-----> I
I-------------I I
I I I
I CT2 I I
I I I
I-------------I I
I I
I CT0+CT1+CT2 I
I I
I----------------------------I
<--Max Reservable Bandwidth-->
< - 最大予約可能帯域幅 - >
(Note that, in this illustration, the sum BC0 + BC1 + BC2 exceeds the Max Reservable Bandwidth.)
（なお、この図では、和BC0 + 1 BC1 + BC2は、最大予約可能帯域幅を超えています。）
While more flexible/sophisticated Bandwidth Constraints Models can be defined (and are indeed defined; see [DSTE-RDM]), the Maximum Allocation Model is attractive in some DS-TE environments for the following reasons:
より柔軟な/洗練された帯域幅制約モデルを定義することができる（実際に定義されている。[DSTE-RDM]参照）しながら、最大割り当てモデルは、次の理由のためにいくつかのDSTE環境において魅力的です。
- Network administrators generally find MAM simple and intuitive
- ネットワーク管理者は、一般的にMAMは、シンプルで直感的な発見します
- MAM matches simple bandwidth control policies that Network Administrators may want to enforce, such as setting an individual Bandwidth Constraint for a given type of traffic (a.k.a. Class-Type) and simultaneously limit the aggregate of reserved bandwidth across all types of traffic.
- MAMは、このようなトラフィックの特定のタイプ（別称、クラス型）のために、個々の帯域幅の制約を設定すると同時に、すべてのタイプのトラフィック全体で確保された帯域幅の集約を制限するなどのネットワーク管理者は、強制することがあり、単純な帯域制御ポリシーを、一致しました。
- MAM can be used in a way which ensures isolation across Class-Types, whether preemption is used or not.
- MAMは、プリエンプションが使用されているか否かを、クラスタイプ間の分離を確実にするように使用することができます。
- MAM can simultaneously achieve isolation, bandwidth efficiency, and protection against QoS degradation of the premium CT.
- MAMは同時に分離、帯域幅の効率化、およびプレミアムCTのQoSの劣化に対する保護を達成することができます。
- MAM only requires limited protocol extensions such as the ones defined in [DSTE-PROTO].
- MAMのみような[DSTE - プロト]で定義されるものと限定されたプロトコルの拡張を必要とします。
MAM may not be attractive in some DS-TE environments because:
MAMはので、いくつかのDS-TEの環境では、魅力的ではないかもしれません。
- MAM cannot simultaneously achieve isolation, bandwidth efficiency, and protection against QoS degradation of CTs other than the Premium CT.
- MAMは同時に分離、帯域幅の効率化、およびプレミアムCT以外のCTSのQoS劣化に対する保護を達成することはできません。
Additional considerations on the properties of MAM, and its comparison with RDM, can be found in [BC-CONS] and [BC-MODEL].
追加MAMの特性に配慮し、RDMとの比較は、[BC-CONS]および[BC-MODEL]で見つけることができます。
As a very simple example of usage of MAM, a network administrator using one CT for Voice (CT1) and one CT for Data (CT0) might configure on a given 2.5 Gb/s link:
MAM、1ボイスのCT（CT1）とデータ用CT（CT0）が与えられた2.5 Gb /秒のリンクを設定する可能性があるものを使用して、ネットワーク管理者の使用の非常に簡単な例として：
- BC0 = 2 Gb/s (i.e., Data is limited to 2 Gb/s)
- BC0 = 2 Gb /秒（すなわち、データは、2 Gb /秒に制限されています）
- BC1 = 1 Gb/s (i.e., Voice is limited to 1 Gb/s)
- BC1 = 1 Gb /秒（すなわち、音声が1 Gb /秒に制限されています）
- Maximum Reservable Bandwidth = 2.5 Gb/s (i.e., aggregate Data + Voice is limited to 2.5 Gb/s)
- 最大予約可能帯域幅= 2.5ギガビット/秒（すなわち、集約データ+ボイス2.5 Gb /秒に制限されます）
4. Example Formulas for Computing "Unreserved TE-Class [i]" with Maximum Allocation Model
最大割当モデルによるコンピューティングのための4例式「非予約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 MAM MUST reflect the MAM Bandwidth Constraints defined in Section 3 when computing "Unreserved TE-Class [i]".
[DSTE - プロト]で指定されているように、計算するための式「非予約TEクラス[i]は」[i]のTE-クラスに関連付けられているCTに関連する帯域幅の制約のすべてを反映しなければなりませんし、したがって、帯域幅の制約モデルに依存します。したがって、DS-TE LSR実施MAM「は、未予約TEクラス[I]」を計算するときに、セクション3で定義されたMAMの帯域幅の制約を反映しなければなりません。
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 MAM. In the example, we assume the use of 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]のために予約されていない帯域幅の値がMAMで計算されるかもしれない方法で、例示の目的のために、このセクションの例を提供することを維持します。例では、我々は単にそのLSPに関連したCTに関連する帯域幅の制約の全てから任意の確立LSPの正確な帯域幅が差し引かれ、基本的なアドミッション制御アルゴリズムの使用を前提としています。
Then:
その後：
"Unreserved TE-Class [i]" =
"非予約TEクラス[i]を" =
MIN [ [ BCc - SUM ( Reserved(CTc,q) ) ] for q <= p , [ Max-Res-Bw - SUM (Reserved(CTb,q)) ] for q <= p and 0 <= b <= 7, ]
MIN [BCC - qに対してSUM（予約（CTC、Q））<= P、[マックス-RES-幅Bw - SUM qに対して（（CTB、q）は予約済み）<= P 0 <= B <= 7、 ]
where: TE-Class [i] <--> < CTc , preemption p> in the configured TE-Class mapping.
ここで、TEクラス[I] < - > <CTC、プリエンプションP>構成TEクラスのマッピングです。
Security considerations related to the use of DS-TE are discussed in [DSTE-PROTO]. Those apply independently of the Bandwidth Constraints Model, including MAM specified in this document.
DSTEの使用に関連するセキュリティ上の考慮事項は、[DSTE - プロト]で議論されています。これらは、この文書で指定されたMAMを含む、帯域幅の制約モデルとは独立して適用されます。
[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, IANA has assigned a Bandwidth Constraints Model Id for MAM from the range 0-239 (which is to be managed as per the "Specification Required" policy defined in [IANA-CONS]).
[DSTE - プロト]は、「帯域幅の制約モデルID」の新しい名前空間を定義します。その名前空間内の値の割り当てのためのガイドラインは[DSTE - プロト]のセクション13.1に詳述されています。これらのガイドラインによれば、IANAは、（[IANA-CONS]で定義された「仕様必須」ポリシーに従って管理される）範囲0から239からMAMの帯域幅制約モデルIDが割り当てられています。
Bandwidth Constraints Model Id 1 was allocated by IANA to MAM.
帯域幅の制約モデル同上1は、MAMにIANAによって割り当てられました。
A lot of the material in this document has been derived from ongoing discussions within the TEWG work. This involved many people including Jerry Ash and Dimitry Haskin.
この文書に記載されている材料の多くはTEWG作業中、進行中の議論に由来しています。これは、ジェリー・アッシュとのDimitry Haskinを含む多くの人々が関与しました。
Appendix A: Addressing [DSTE-REQ] Scenarios
付録A：アドレッシング[DSTE - REQ]シナリオ
This Appendix provides examples of how the Maximum Allocation 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 =ボイス用）=「一定の割合」
- Bandwidth Constraint 0 (for CT0 = Data) = link capacity (or a constraint specific to data traffic)
- 帯域幅制約0 =リンク容量（またはデータトラフィックに固有の制約）（CT0 =データ用）
- Max Reservable Bandwidth = link capacity
- 最大予約可能帯域幅=リンク容量
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 Maximum Allocation 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 (or up to its own specific constraint)
- 残りのすべてのリンク容量を使用することが可能なデータトラフィック（またはその固有の制約まで）
- 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% of link capacity
- リンク容量のBC2（用CT2）=例えば、45％
- BC1 (for CT1) = e.g., 35% of link capacity
- リンク容量のBC1（用CT1）=例えば、35％
- BC0 (for CT0) = e.g., 100% of link capacity
- リンク容量のBC0（用CT0）=例えば、100％
- Max Reservable Bandwidth = link capacity
- 最大予約可能帯域幅=リンク容量
DS-TE with the Maximum Allocation Model 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.
最大配分モデルを用いたDS-TEリンクを確立し、各CTのトラフィックの量は、対応するDiffservの当たりホップビヘイビア（のPHB）に割り当てられたリソースと比較して、許容できるレベルの範囲内であることを確実にするには関係なく、LSPを注文そのルーティングされますかかわらず、でその先取り優先順位は、どのの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 Maximum Allocation 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 CT and corresponding Diffserv resources.
Diffservのスケジューリング設定のオプションの自動調整は、各CTの確立トラフィックと対応する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 QoS objectives of the Guaranteed Bandwidth service)
- BC1（CT1用）=「与えられた」リンク帯域幅の割合（適切な保証帯域幅サービスのQoS目標を達成するために）
- BC0 (for CT0 = Data) = link capacity (or a constraint specific to data traffic)
- BC0（CT0 =データ用）=リンク容量（またはデータトラフィックに固有の制約）
- Max Reservable Bandwidth = link capacity
- 最大予約可能帯域幅=リンク容量
DS-TE with the Maximum Allocation 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 (or limited to the specific constraint for such traffic).
最大配分モデルと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-RDM] Le Faucheur, F., Ed., "Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC 4127, June 2005.
[DSTE - RDM]ルFaucheur、F.、エド。、 "Diffservの認識MPLSトラフィックエンジニアリングのためのロシア人形の帯域幅制約モデル"、RFC 4127、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トラフィックエンジニアリング高速リルート：帯域幅保護のためのバイパストンネル経路計算」が進行中で働いています。
Authors' Addresses
著者のアドレス
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
Wai Sum Lai AT&T Labs 200 Laurel Avenue Middletown, New Jersey 07748, USA
ワイ合計ライAT＆T Labsの200ローレルアベニューミドルタウン、ニュージャージー州07748、USA
Phone: (732) 420-3712 EMail: wlai@att.com
電話：（732）420-3712 Eメール：wlai@att.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機能のための基金は現在、インターネット協会によって提供されます。