[要約] RFC 4125は、Diffserv-aware MPLS Traffic Engineeringにおける最大割り当て帯域制約モデルに関する規格です。このRFCの目的は、ネットワークエンジニアがMPLSネットワークで帯域幅を効果的に制御するためのガイドラインを提供することです。
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
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 Maximum Allocation Model.
このドキュメントは、最大割り当てモデルと呼ばれるDiffServ-Aware 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-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 Maximum Allocation Model (MAM).
このドキュメントは、[DSTE-REQ]で導入され、最大割り当てモデル（MAM）と呼ばれるDS-TEの1つの特定の帯域幅制約モデルの詳細な説明を提供します。
[DSTE-PROTO] specifies the IGP and RSVP-TE signaling extensions for support of DS-TE. These extensions support MAM.
[DSTE-PROTO] DS-TEのサポートのためにIGPおよびRSVP-TEシグナル伝達拡張機能を指定します。これらの拡張機能は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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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-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 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全体で帯域幅を共有することにより帯域幅の効率を高めるメカニズムの例です。[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 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).
この一般化により、このドキュメントで提供される最大割り当てモデル定義は、[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。
MAM is defined in the following manner:
MAMは次の方法で定義されています。
o Maximum Number of Bandwidth Constraints (MaxBC) = Maximum Number of Class-Types (MaxCT) = 8
o 帯域幅の制約の最大数（MAXBC）=クラスタイプの最大数（MAXCT）= 8
o for each value of c in the range 0 <= c <= (MaxCT - 1): Reserved (CTc) <= BCc <= Max-Reservable-Bandwidth,
o 範囲内のcの各値について0 <= c <=（maxct-1）：予約済み（ctc）<= bcc <= max-reservable-bandwidth、
o SUM (Reserved(CTc)) <= Max-Reservable-Bandwidth where the SUM is across all values of c in the range 0 <= c <= (MaxCT - 1)
o sum（予約済み（ctc））<=範囲0 <= c <=（maxct-1）のcのすべての値にわたって合計がある場合、max-reservable bandwidth
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:
異なるCTS間の帯域幅共有の程度を増やすために、帯域幅の制約の合計は最大予約可能な帯域幅を超える可能性があります。
o SUM (BCc) > Max-Reservable-Bandwidth, where the SUM is across all values of c in the range 0 <= c <= (MaxCT - 1)
o sum（bcc）> max-reservable-bandwidth、ここで、範囲0 <= c <=（maxct-1）のcのすべての値にわたって合計があります。
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:
帯域幅の制約の合計は、最大予約可能帯域幅に等しい（またはそれ以下）にもなります。その場合、最大予約可能な帯域幅は実際にCT帯域幅の予約を制限しません（つまり、上記のMAM定義の3番目の弾丸項目は、効果的に機能することはありません）。これは、上記のMAM定義の2番目の弾丸項目が次のことを暗示しているためです。
SUM (reserved(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））<= max-reservable-bandwidth。
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つのCTがアクティブな場合、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つのCTがアクティブである場合の絵画的な方法で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 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]を参照）、最大割り当てモデルは、以下の理由でDS-TE環境で魅力的です。
- 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-Proto]で定義されているような限られたプロトコル拡張機能のみを必要とします。
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以外のCTの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の使用の非常に簡単な例として、Voiceに1つのCT（CT1）に1つのCTを使用し、データ用の1つのCT（CT0）を使用して、特定の2.5 GB/sリンクで構成される可能性があります。
- BC0 = 2 Gb/s (i.e., Data is limited to 2 Gb/s)
- BC0 = 2 GB/s（つまり、データは2 GB/sに制限されています）
- BC1 = 1 Gb/s (i.e., Voice is limited to 1 Gb/s)
- bc1 = 1 gb/s（つまり、音声は1 gb/sに制限されています）
- Maximum Reservable Bandwidth = 2.5 Gb/s (i.e., aggregate Data + Voice is limited to 2.5 Gb/s)
- 最大予約可能帯域幅= 2.5 gb/s（つまり、集計データ音声は2.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 MAM MUST reflect the MAM Bandwidth Constraints defined in Section 3 when computing "Unreserved TE-Class [i]".
[DSTE-Proto]で指定されているように、「予約されていないTEクラス[i]」を計算するための式は、TEクラス[i]に関連するCTに関連するすべての帯域幅の制約を反映する必要があります。。したがって、MAMを実装するDS-TE LSRは、「予約されていない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-proto]で説明されているように、Andiming Control Algorithmsの詳細と、「予約されていないTE-Class [i]」を計算するための式は、IETF作業の範囲外です。これを念頭に置いて、このセクションでは、TE-Class [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,
]
where: TE-Class [i] <--> < CTc , preemption p> in the configured TE-Class mapping.
WHERE：TE-Class [i] < - > <CTC、Preemption 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.
DS-TEの使用に関連するセキュリティ上の考慮事項は、[DSTE-Proto]で説明されています。これらは、このドキュメントで指定された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-proto]「帯域幅制約モデルID」の新しい名前空間を定義します。その名前空間における値の割り当てのガイドラインは、[dste-proto]のセクション13.1に詳述されています。これらのガイドラインに従って、IANAは範囲0-239からMAMの帯域幅制約モデルIDを割り当てました（[IANA-Cons]で定義された「必要な仕様」ポリシーに従って管理されます）。
Bandwidth Constraints Model Id 1 was allocated by IANA to MAM.
帯域幅の制約モデルID 1は、IANAからMAMに割り当てられました。
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作業内の進行中の議論から派生しています。これには、Jerry Ashや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]で説明されている各シナリオをサポートするために、最大割り当て帯域幅の制約モデルを使用する方法の例を示します。
By configuring on every link:
すべてのリンクで構成することにより：
- Bandwidth Constraint 1 (for CT1 = Voice) = "certain percentage" of link capacity
- 帯域幅の制約1（CT1 = Voiceの場合）=リンク容量の「特定の割合」
- 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
- すべてのCT1/Voice TE-LSPがプリエンプション= 0です
- every CT0/Data TE-LSP with preemption = 1
- すべてのCT0/データTE-LSPがプリエンプション= 1
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
- 他のトラフィックを先取りできる音声トラフィック
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のトラフィックの量が、LSPがルーティングされる順序に関係なく、対応するDIFFSERV（ホップあたりの行動）に割り当てられたリソースと比較して、許容レベル内にあることを保証します。で、どの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 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.
- 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 CT and corresponding Diffserv resources.
DiffServスケジューリング構成のオプションの自動調整は、各CTの確立されたトラフィックの量と対応するDiffServリソースの間の非常に厳しい関係を維持するために使用できます。
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] 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-RDM] Le Faucheur, F., Ed., "Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC 4127, June 2005.
[DSTE-RDM] Le Faucheur、F.、ed。、「Diffserv-aware MPLSトラフィックエンジニアリングのロシア人形帯域幅の制約モデル」、RFC 4127、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：帯域幅保護のためのバイパストンネルパス計算」、進行中の作業。
Authors' Addresses
著者のアドレス
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
Wai Sum Lai AT&T Labs 200 Laurel Avenue Middletown, New Jersey 07748, USA
Wai Sum Lai AT＆T Labs 200 Laurel Avenue Middletown、ニュージャージー07748、米国
Phone: (732) 420-3712 EMail: wlai@att.com
電話：（732）420-3712メール：wlai@att.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エディター機能の資金は現在、インターネット協会によって提供されています。