[要約] 要約：RFC 4126は、Diffserv-aware MPLS Traffic Engineeringにおける最大割り当てと予約帯域制約モデルについて説明しています。目的は、異なるトラフィックエンジニアリング手法の性能比較を行うことです。目的：Diffserv-aware MPLS Traffic Engineeringの最大割り当てと予約帯域制約モデルを説明し、性能比較を行う。
Network Working Group J. Ash
Request for Comments: 4126 AT&T
Category: Experimental June 2005
Max Allocation with Reservation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering & Performance Comparisons
予約帯域幅の制約付き最大割り当て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 complements the Diffserv-aware MPLS Traffic Engineering (DS-TE) requirements document by giving a functional specification for the Maximum Allocation with Reservation (MAR) Bandwidth Constraints Model. Assumptions, applicability, and examples of the operation of the MAR Bandwidth Constraints Model are presented. MAR performance is analyzed relative to the criteria for selecting a Bandwidth Constraints Model, in order to provide guidance to user implementation of the model in their networks.
このドキュメントは、予約（MAR）帯域幅制約モデルを備えた最大割り当てのための機能的仕様を提供することにより、DiffServ-Aware MPLS Traffic Engineering（DS-TE）要件ドキュメントを補完します。仮定、適用性、およびMAR帯域幅制約モデルの操作の例が提示されています。ネットワーク内のモデルのユーザー実装へのガイダンスを提供するために、MARパフォーマンスは、帯域幅制約モデルを選択するための基準と比較して分析されます。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Specification of Requirements ..............................3
2. Definitions .....................................................3
3. Assumptions & Applicability .....................................5
4. Functional Specification of the MAR Bandwidth
Constraints Model ...............................................6
5. Setting Bandwidth Constraints ...................................7
6. Example of MAR Operation ........................................8
7. Summary .........................................................9
8. Security Considerations ........................................10
9. IANA Considerations ............................................10
10. Acknowledgements ..............................................10
A. MAR Operation & Performance Analysis ..........................11
B. Bandwidth Prediction for Path Computation ......................19
Normative References ..............................................20
Informative References ............................................20
Diffserv-aware MPLS traffic engineering (DS-TE) requirements and protocol extensions are specified in [DSTE-REQ, DSTE-PROTO]. A requirement for DS-TE implementation is the specification of Bandwidth Constraints Models for use with DS-TE. The Bandwidth Constraints Model provides the 'rules' to support the allocation of bandwidth to individual class types (CTs). CTs are groupings of service classes in the DS-TE model, which are provided separate bandwidth allocations, priorities, and QoS objectives. Several CTs can share a common bandwidth pool on an integrated, multiservice MPLS/Diffserv network.
DiffServ-Aware MPLSトラフィックエンジニアリング（DS-TE）要件とプロトコル拡張は、[DSTE-REQ、DSTE-PROTO]で指定されています。DS-TE実装の要件は、DS-TEで使用する帯域幅制約モデルの仕様です。帯域幅の制約モデルは、個々のクラスタイプ（CTS）への帯域幅の割り当てをサポートする「ルール」を提供します。CTSは、DS-TEモデルのサービスクラスのグループ化であり、個別の帯域幅の割り当て、優先順位、およびQoS目標が提供されます。いくつかのCTは、統合されたマルチサービスMPLS/DiffServネットワークで共通の帯域幅プールを共有できます。
This document is intended to complement the DS-TE requirements document [DSTE-REQ] by giving a functional specification for the Maximum Allocation with Reservation (MAR) Bandwidth Constraints Model. Examples of the operation of the MAR Bandwidth Constraints Model are presented. MAR performance is analyzed relative to the criteria for selecting a Bandwidth Constraints Model, in order to provide guidance to user implementation of the model in their networks.
このドキュメントは、予約（MAR）帯域幅制約モデルを備えた最大割り当ての機能仕様を提供することにより、DS-TE要件ドキュメント[DSTE-REQ]を補完することを目的としています。MAR帯域幅制約モデルの操作の例が提示されています。ネットワーク内のモデルのユーザー実装へのガイダンスを提供するために、MARパフォーマンスは、帯域幅制約モデルを選択するための基準と比較して分析されます。
Two other Bandwidth Constraints Models are being specified for use in DS-TE:
DS-TEで使用するために、他の2つの帯域幅制約モデルが指定されています。
1. Maximum Allocation Model (MAM) [MAM] - the maximum allowable bandwidth usage of each CT is explicitly specified.
1. 最大割り当てモデル（MAM）[MAM] - 各CTの最大許容帯域幅使用法が明示的に指定されています。
2. Russian Doll Model (RDM) [RDM] - the maximum allowable bandwidth usage is done cumulatively by grouping successive CTs according to priority classes.
2. ロシアの人形モデル（RDM）[RDM] - 優先クラスに従って連続したCTをグループ化することにより、最大許容帯域幅の使用が累積的に行われます。
MAR is similar to MAM in that a maximum bandwidth allocation is given to each CT. However, through the use of bandwidth reservation and protection mechanisms, CTs are allowed to exceed their bandwidth allocations under conditions of no congestion but revert to their allocated bandwidths when overload and congestion occurs.
MARは、各CTに最大帯域幅割り当てが与えられるという点で、MAMに似ています。ただし、帯域幅の予約および保護メカニズムを使用することにより、CTは混雑のない条件下で帯域幅の割り当てを超えることが許可されていますが、過負荷と輻輳が発生したときに割り当てられた帯域幅に戻ります。
All Bandwidth Constraints Models should meet these objectives:
すべての帯域幅の制約モデルは、これらの目的を満たす必要があります。
1. applies equally when preemption is either enabled or disabled (when preemption is disabled, the model still works 'reasonably' well),
1. プリエンプションが有効または無効になっている場合（プリエンプションが無効になっている場合、モデルは「合理的に」機能する場合も同様に適用されます）、
2. bandwidth efficiency, i.e., good bandwidth sharing among CTs under both normal and overload conditions,
2. 帯域幅の効率、つまり、通常と過負荷条件の両方でCTS間の良好な帯域幅共有、
3. bandwidth isolation, i.e., a CT cannot hog the bandwidth of another CT under overload conditions,
3. 帯域幅の分離、つまり、CTは、過負荷条件下で別のCTの帯域幅をホグすることはできません。
4. protection against QoS degradation, at least of the high-priority CTs (e.g., high-priority voice, high-priority data, etc.), and
4. QoS劣化に対する保護、少なくとも優先順位CT（例えば、優先順位の音声、優先順位データなど）、および
5. reasonably simple, i.e., does not require additional IGP extensions and minimizes signaling load processing requirements.
5. 合理的にシンプル、つまり、追加のIGP拡張機能を必要とせず、シグナリング負荷処理要件を最小化します。
In Appendix A, modeling analysis is presented that shows the MAR Model meets all of these objectives and provides good network performance, relative to MAM and full-sharing models, under normal and abnormal operating conditions. It is demonstrated that MAR simultaneously achieves bandwidth efficiency, bandwidth isolation, and protection against QoS degradation without preemption.
付録Aでは、MARモデルがこれらの目的をすべて満たし、通常および異常な動作条件下でMAMおよびフルシェアリングモデルと比較して優れたネットワークパフォーマンスを提供することを示すモデリング分析が提示されています。MARは、帯域幅の効率、帯域幅分離、およびQoS分解に対する保護を同時に達成することが実証されています。
In Section 3 we give the assumptions and applicability; in Section 4 a functional specification of the MAR Bandwidth Constraints Model; and in Section 5 we give examples of its operation. In Appendix A, MAR performance is analyzed relative to the criteria for selecting a Bandwidth Constraints Model, in order to provide guidance to user implementation of the model in their networks. In Appendix B, bandwidth prediction for path computation is discussed.
セクション3では、仮定と適用性を示します。セクション4では、MAR帯域幅制約モデルの機能的仕様。セクション5では、その操作の例を示します。付録Aでは、ネットワーク内のモデルのユーザー実装へのガイダンスを提供するために、帯域幅制約モデルを選択するための基準に関連してMARパフォーマンスが分析されます。付録Bでは、パス計算の帯域幅予測について説明します。
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, DSTE-PROTO] are repeated here:
読みやすさのために、[dste-req、dste-proto]からの多くの定義がここで繰り返されます。
Traffic Trunk: an aggregation of traffic flows of the same class (i.e., treated equivalently from the DS-TE perspective), which is placed inside a Label Switched Path (LSP).
トラフィックトランク：同じクラスのトラフィックフローの集約（つまり、DS-TEの観点から同等に扱われます）。これは、ラベルスイッチ付きパス（LSP）内に配置されます。
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に属します。
Up to 8 CTs (MaxCT = 8) are supported. They are referred to as CTc, 0 <= c <= MaxCT-1 = 7. Each CT is assigned either a Bandwidth Constraint, or a set of Bandwidth Constraints. Up to 8 Bandwidth Constraints (MaxBC = 8) are supported and they are referred to as BCc, 0 <= c <= MaxBC-1 = 7.
最大8 cts（maxct = 8）がサポートされています。それらはCTC、0 <= c <= maxct-1 = 7と呼ばれます。各CTは、帯域幅の制約または帯域幅の制約のセットのいずれかを割り当てられます。最大8つの帯域幅の制約（MAXBC = 8）がサポートされており、BCC、0 <= C <= MAXBC-1 = 7と呼ばれます。
TE-Class: A pair of: a) a CT, and b) a preemption priority allowed for that CT. This means that an LSP, transporting a Traffic Trunk from that CT, can use that preemption priority as the set-up priority, the holding priority, or both.
TE-Class：A PATE：a）ct、およびb）そのCTに許可される先制の優先順位。これは、そのCTからトラフィックトランクを輸送するLSPが、その先制の優先順位をセットアップの優先順位、保持優先度、またはその両方として使用できることを意味します。
MAX_RESERVABLE_BWk: maximum reservable bandwidth on link k specifies the maximum bandwidth that may be reserved; this may be greater than the maximum link bandwidth, in which case the link may be oversubscribed [OSPF-TE].
MAX_RESERVABLE_BWK：リンクKの最大予約可能帯域幅は、予約される可能性のある最大帯域幅を指定します。これは、最大リンク帯域幅よりも大きい場合があります。この場合、リンクは[OSPF-TE]をオーバーサブスクライブする場合があります。
BCck: bandwidth constraint for CTc on link k = allocated (minimum guaranteed) bandwidth for CTc on link k (see Section 4).
BCCK：リンクk =リンクKのCTCの帯域幅の帯域幅の帯域幅の制約（セクション4を参照）。
RBW_THRESk: reservation bandwidth threshold for link k (see Section 4).
RBW_THRESK：リンクKの予約帯域幅のしきい値（セクション4を参照）。
RESERVED_BWck: reserved bandwidth-in-progress on CTc on link k (0 <= c <= MaxCT-1), RESERVED_BWck = total amount of the bandwidth reserved by all the established LSPs that belong to CTc.
RESERVED_BWCK：リンクK（0 <= C <= MAXCT-1）のCTC上の予約帯域幅帯域幅、予約_BWCK = CTCに属する確立されたすべてのLSPによって予約された帯域幅の合計量。
UNRESERVED_BWk: unreserved link bandwidth on link k specifies the amount of bandwidth not yet reserved for any CT, UNRESERVED_BWk = MAX_RESERVABLE_BWk - sum [RESERVED_BWck (0 <= c <= MaxCT-1)].
unreserved_bwk：リンクkの未返済リンク帯域幅は、CT、unserved_bwk = max_reservable_bwk -sum [reserved_bwck（0 <= c <= maxct -1）]にまだ予約されていない帯域幅の量を指定します。
UNRESERVED_BWck: unreserved link bandwidth on CTc on link k specifies the amount of bandwidth not yet reserved for CTc, UNRESERVED_BWck = UNRESERVED_BWk - delta0/1(CTck) * RBW-THRESk where
unreserved_bwck：リンクKのCTCの未返信リンク帯域幅は、CTCにまだ予約されていない帯域幅の量を指定します。
delta0/1(CTck) = 0 if RESERVED_BWck < BCck
delta0/1(CTck) = 1 if RESERVED_BWck >= BCck
A number of recovery mechanisms under investigation 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_BWck introduced in [DSTE-REQ] is compatible with such a concept of bandwidth sharing across multiple LSPs, the wording of the definition provided in [DSTE-REQ] is generalized. With this generalization, the definition is compatible with Shared Mesh Restoration defined in [GMPLS-RECOV], so that DS-TE and Shared Mesh Protection can operate simultaneously, under the assumption 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 CTc also need to belong to CTc; excess traffic LSPs that share bandwidth with backup LSPs of CTc also need to belong to CTc.
IETFで調査中の多くの回復メカニズムは、LSPの特定のセットにわたる帯域幅共有の概念を活用しています。[GMPLS-RECOV]の「共有メッシュ修復」と[MPLS-Backup]の「施設ベースの計算モデル」は、独立した障害から保護するバックアップLSP全体で帯域幅を共有することにより帯域幅の効率を高めるメカニズムの例です。[dste-req]で導入されたremerved_bwckの概念が、複数のLSPにわたる帯域幅共有の概念と互換性があることを確認するために、[dste-req]で提供される定義の文言が一般化されています。この一般化により、定義は[Gmpls-Recov]で定義された共有メッシュの復元と互換性があるため、DS-TEと共有メッシュ保護は同時に動作します。クラスタイプ全体で動作しません。たとえば、CTCの一次LSPを保護するバックアップLSPもCTCに属する必要があります。CTCのバックアップLSPと帯域幅を共有する過剰なトラフィックLSPもCTCに属する必要があります。
In general, DS-TE is a bandwidth allocation mechanism for different classes of traffic allocated to various CTs (e.g., voice, normal data, best-effort data). Network operation functions such as capacity design, bandwidth allocation, routing design, and network planning are normally based on traffic-measured load and forecast [ASH1].
一般に、DS-TEは、さまざまなCTに割り当てられたさまざまなクラスのトラフィック（音声、通常のデータ、ベストエフォートデータなど）の帯域幅割り当てメカニズムです。容量設計、帯域幅の割り当て、ルーティング設計、ネットワーク計画などのネットワーク操作機能は、通常、トラフィックで測定された負荷と予測[ASH1]に基づいています。
As such, the following assumptions are made according to the operation of MAR:
そのため、次の仮定は、MARの操作に従って行われます。
1. Connection admission control (CAC) allocates bandwidth for network flows/LSPs according to the traffic load assigned to each CT, based on traffic measurement and forecast.
1. 接続入場制御（CAC）は、トラフィックの測定と予測に基づいて、各CTに割り当てられたトラフィック負荷に従って、ネットワークフロー/LSPの帯域幅を割り当てます。
2. CAC could allocate bandwidth per flow, per LSP, per traffic trunk, or otherwise. That is, no specific assumption is made about a specific CAC method, except that CT bandwidth allocation is related to the measured/forecasted traffic load, as per assumption #1.
2. CACは、フローごと、LSPごと、トラフィックトランクごと、またはその他の帯域幅を割り当てることができます。つまり、CT帯域幅の割り当てが、仮定＃1に従って、測定/予測されたトラフィック負荷に関連していることを除いて、特定のCACメソッドについて特定の仮定は行われません。
3. CT bandwidth allocation is adjusted up or down according to measured/forecast traffic load. No specific time period is assumed for this adjustment, it could be short term (seconds, minutes, hours), daily, weekly, monthly, or otherwise.
3. CT帯域幅の割り当ては、測定/予測トラフィック負荷に従って上下に調整されます。この調整で特定の期間は想定されていません。短期（秒、分、時間）、毎日、毎週、毎月、またはその他の場合があります。
4. Capacity management and CT bandwidth allocation thresholds (e.g., BCc) are designed according to traffic load, and are based on traffic measurement and forecast. Again, no specific time period is assumed for this adjustment, it could be short term (hours), daily, weekly, monthly, or otherwise.
4. 容量管理とCT帯域幅の割り当てしきい値（BCCなど）は、トラフィックの負荷に応じて設計されており、トラフィックの測定と予測に基づいています。繰り返しますが、この調整で特定の期間は想定されていません。短期（時間）、毎日、毎週、毎月、またはその他の場合があります。
5. No assumption is made on the order in which traffic is allocated to various CTs; again traffic allocation is assumed to be based only on traffic load as it is measured and/or forecast.
5. トラフィックがさまざまなCTに割り当てられる順序には、仮定は行われません。繰り返しますが、トラフィックの割り当ては、測定されたトラフィック負荷および/または予測のみに基づいていると想定されています。
6. If link bandwidth is exhausted on a given path for a flow/LSP/traffic trunk, alternate paths may be attempted to satisfy CT bandwidth allocation.
6. Link帯域幅が流れ/LSP/トラフィックトランクの特定の経路で使い果たされている場合、CT帯域幅の割り当てを満たすために代替パスが試行される場合があります。
Note that the above assumptions are not unique to MAR, but are generic, common assumptions for all BC Models.
上記の仮定はMARに固有のものではなく、すべてのBCモデルの一般的で一般的な仮定であることに注意してください。
A DS-TE Label Switching Router (LSR) that implements MAR MUST support enforcement of bandwidth constraints, in compliance with the specifications in this section.
このセクションの仕様に準拠して、MARを実装するDS-TEラベルスイッチングルーター（LSR）は、帯域幅の制約の施行をサポートする必要があります。
In the MAR Bandwidth Constraints Model, the bandwidth allocation control for each CT is based on estimated bandwidth needs, bandwidth use, and status of links. The Label Edge Router (LER) makes needed bandwidth allocation changes, and uses [RSVP-TE], for example, to determine if link bandwidth can be allocated to a CT. Bandwidth allocated to individual CTs is protected as needed, but otherwise it is shared. Under normal, non-congested network conditions, all CTs/services fully share all available bandwidth. When congestion occurs for a particular CTc, bandwidth reservation prohibits traffic from other CTs from seizing the allocated capacity for CTc.
MAR帯域幅の制約モデルでは、各CTの帯域幅割り当て制御は、推定帯域幅のニーズ、帯域幅の使用、およびリンクのステータスに基づいています。ラベルエッジルーター（LER）は、必要な帯域幅の割り当ての変更を行い、たとえば[RSVP-TE]を使用して、リンク帯域幅をCTに割り当てることができるかどうかを判断します。個々のCTに割り当てられた帯域幅は必要に応じて保護されますが、それ以外の場合は共有されます。通常の非合成ネットワーク条件下では、すべてのCTS/サービスが利用可能なすべての帯域幅を完全に共有します。特定のCTCに対して輻輳が発生すると、帯域幅予約により、他のCTSからのトラフィックがCTCの割り当てられた容量の押収が禁止されています。
On a given link k, a small amount of bandwidth RBW_THRESk (the reservation bandwidth threshold for link k) is reserved and governs the admission control on link k. Also associated with each CTc on link k are the allocated bandwidth constraints BCck to govern bandwidth allocation and protection. The reservation bandwidth on a link (RBW_THRESk) can be accessed when a given CTc has bandwidth-in-use (RESERVED_BWck) below its allocated bandwidth constraint (BCck). However, if RESERVED_BWck exceeds its allocated bandwidth constraint (BCck), then the reservation bandwidth (RBW_THRESk) cannot be accessed. In this way, bandwidth can be fully shared among CTs if available, but is otherwise protected by bandwidth reservation methods.
特定のリンクkでは、少量の帯域幅rbw_thresk（リンクkの予約帯域幅のしきい値）が予約されており、リンクkの入場制御を管理します。また、リンクK上の各CTCに関連付けられているのは、帯域幅の割り当てと保護を支配するために、帯域幅の制約を割り当てられた帯域幅の制約です。リンク（RBW_Thresk）の予約帯域幅には、特定のCTCが割り当てられた帯域幅の制約（BCCK）の下に帯域幅（Reserved_BWCK）を持っている場合にアクセスできます。ただし、Reserved_BWCKが割り当てられた帯域幅制約（BCCK）を超えると、予約帯域幅（rbw_thresk）にアクセスできません。このようにして、帯域幅は、利用可能な場合はCTS間で完全に共有できますが、帯域幅の予約方法で保護されています。
Bandwidth can be accessed for a bandwidth request = DBW for CTc on a given link k based on the following rules:
帯域幅は、次のルールに基づいて、特定のリンクKでCTCの帯域幅要求= DBWにアクセスできます。
Table 1: Rules for Admitting LSP Bandwidth Request = DBW on Link k
表1：LSP帯域幅リクエストを認めるためのルール= dbw on link k
For LSP on a high priority or normal priority CTc:
優先度が高いまたは通常の優先度の高いLSPの場合：
If RESERVED_BWck <= BCck: admit if DBW <= UNRESERVED_BWk
If RESERVED_BWck > BCck: admit if DBW <= UNRESERVED_BWk - RBW_THRESk;
or, equivalently:
または、同等に：
If DBW <= UNRESERVED_BWck, admit the LSP.
dbw <= unreserved_bwckの場合、LSPを認めます。
For LSP on a best-effort priority CTc: allocated bandwidth BCck = 0; Diffserv queuing admits BE packets only if there is available link bandwidth.
最大の優先度CTCのLSPの場合：割り当てられた帯域幅bcck = 0;Diffserv Queuingは、利用可能なリンク帯域幅がある場合にのみパケットであることを認めています。
The normal semantics of setup and holding priority are applied in the MAR Bandwidth Constraints Model, and cross-CT preemption is permitted when preemption is enabled.
セットアップと保持優先度の通常のセマンティクスは、MAR帯域幅の制約モデルに適用され、先制が有効になっている場合にクロスクリエーションが許可されます。
The bandwidth allocation rules defined in Table 1 are illustrated with an example in Section 6 and simulation analysis in Appendix A.
表1に定義されている帯域幅割り当てルールは、セクション6の例と付録Aのシミュレーション分析を示しています。
For a normal priority CTc, the bandwidth constraints BCck on link k are set by allocating the maximum reservable bandwidth (MAX_RESERVABLE_BWk) in proportion to the forecast or measured traffic load bandwidth (TRAF_LOAD_BWck) for CTc on link k. That is:
通常の優先度のCTCの場合、リンクKの帯域幅制約は、リンクkのCTCの予測または測定されたトラフィック負荷帯域幅（TRAF_LOAD_BWCK）に比例して最大予約可能帯域幅（MAX_RESERVABLE_BWK）を割り当てることにより設定されます。あれは：
PROPORTIONAL_BWck = TRAF_LOAD_BWck/[sum {TRAF_LOAD_BWck, c=0, MaxCT-1}]
X MAX_RESERVABLE_BWk
For normal priority CTc: BCck = PROPORTIONAL_BWck
通常の優先度CTC：BCCK =比例_BWCK
For a high priority CT, the bandwidth constraint BCck is set to a multiple of the proportional bandwidth. That is:
優先度の高いCTの場合、帯域幅の制約BCCKは、比例帯域幅の倍数に設定されます。あれは：
For high priority CTc: BCck = FACTOR X PROPORTIONAL_BWck
優先度の高いCTCの場合：bcck = Factor x比例_bwck
where FACTOR is set to a multiple of the proportional bandwidth (e.g., FACTOR = 2 or 3 is typical). This results in some 'over-allocation' of the maximum reservable bandwidth, and gives priority to the high priority CTs. Normally the bandwidth allocated to high priority CTs should be a relatively small fraction of the total link bandwidth, with a maximum of 10-15 percent being a reasonable guideline.
因子が比例帯域幅の倍数に設定されている場合（例：因子= 2または3が一般的です）。これにより、最大予約可能な帯域幅の「過剰配分」が生じ、優先度の高いCTSが優先されます。通常、優先度の高いCTに割り当てられる帯域幅は、総リンク帯域幅の比較的わずかな割合でなければならず、最大10〜15％が合理的なガイドラインです。
As stated in Section 4, the bandwidth allocated to a best-effort priority CTc should be set to zero. That is:
セクション4で述べたように、最大の優先度CTCに割り当てられた帯域幅はゼロに設定する必要があります。あれは：
For best-effort priority CTc: BCck = 0
最優先事項の場合CTC：BCCK = 0
In the example, assume there are three class-types: CT0, CT1, CT2. We consider a particular link with
この例では、CT0、CT1、CT2の3つのクラスタイプがあると仮定します。との特定のリンクを検討します
MAX-RESERVABLE_BW = 100
And with the allocated bandwidth constraints set as follows:
また、帯域幅の制約が次のように設定されています。
BC0 = 30 BC1 = 20 BC2 = 20
BC0 = 30 BC1 = 20 BC2 = 20
These bandwidth constraints are based on the normal traffic loads, as discussed in Section 5. With MAR, any of the CTs is allowed to exceed its bandwidth constraint (BCc) as long a there are at least RBW_THRES (reservation bandwidth threshold on the link) units of spare bandwidth remaining. Let's assume
セクション5で説明したように、これらの帯域幅の制約は、通常のトラフィック負荷に基づいています。MARでは、CTSのいずれかが帯域幅の制約（BCC）を超えることが許可されています。残りの予備の帯域幅の単位。仮定しましょう
RBW_THRES = 10
So under overload, if
したがって、過負荷の下で、if
RESERVED_BW0 = 50 RESERVED_BW1 = 30 RESERVED_BW2 = 10
Reserved_bw0 = 50 Reserved_bw1 = 30 Reserved_bw2 = 10
Therefore, for this loading
したがって、この負荷のために
UNRESERVED_BW = 100 - 50 - 30 - 10 = 10
CT0 and CT1 can no longer increase their bandwidth on the link, because they are above their BC values and there is only RBW_THRES=10 units of spare bandwidth left on the link. But CT2 can take the additional bandwidth (up to 10 units) if the demand arrives, because it is below its BC value.
CT0とCT1は、リンクの帯域幅を増加させることができなくなります。これは、BC値を上回っており、リンクに残っているRBW_THRES = 10単位の予備帯域幅のみがあるためです。ただし、CT2は、BC値を下回っているため、需要が届くと追加の帯域幅（最大10単位）を取ることができます。
As also discussed in Section 4, if best effort traffic is present, it can always seize whatever spare bandwidth is available on the link at the moment, but is subject to being lost at the queues in favor of the higher priority traffic.
セクション4で説明したように、ベストエフェクショントラフィックが存在する場合、現時点ではリンクで利用可能な予備の帯域幅を常に押収できますが、優先度の高いトラフィックを支持してキューで失われる可能性があります。
Let's say an LSP arrives for CT0 needing 5 units of bandwidth (i.e., DBW = 5). We need to decide, based on Table 1, whether to admit this LSP or not. Since for CT0
5単位の帯域幅（つまり、DBW = 5）を必要とするCT0にLSPが到着したとしましょう。表1に基づいて、このLSPを認めるかどうかを決定する必要があります。CT0のため
RESERVED_BW0 > BC0 (50 > 30), and
DBW > UNRESERVED_BW - RBW_THRES (i.e., 5 > 10 - 10)
Table 1 says the LSP is rejected/blocked.
表1は、LSPが拒否/ブロックされていることを示しています。
Now let's say an LSP arrives for CT2 needing 5 units of bandwidth (i.e., DBW = 5). We need to decide based on Table 1 whether to admit this LSP or not. Since for CT2
ここで、5ユニットの帯域幅（つまり、DBW = 5）を必要とするCT2にLSPが到着したとしましょう。このLSPを認めるかどうかを表1に基づいて決定する必要があります。CT2のため
RESERVED_BW2 < BC2 (10 < 20), and
DBW < UNRESERVED_BW (i.e., 5 < 10)
Table 1 says to admit the LSP.
表1は、LSPを認めると述べています。
Hence, in the above example, in the current state of the link and in the current CT loading, CT0 and CT1 can no longer increase their bandwidth on the link, because they are above their BCc values and there is only RBW_THRES=10 units of spare bandwidth left on the link. But CT2 can take the additional bandwidth (up to 10 units) if the demand arrives, because it is below its BCc value.
したがって、上記の例では、リンクの現在の状態と現在のCTロードでは、CT0とCT1がリンク上の帯域幅を増やすことができなくなります。リンクに残っている予備の帯域幅。ただし、CT2は、BCC値を下回っているため、需要が届くと、追加の帯域幅（最大10単位）を取得できます。
The proposed MAR Bandwidth Constraints Model includes the following:
提案されているMAR帯域幅制約モデルには、以下が含まれます。
1. allocation of bandwidth to individual CTs,
1. 個々のCTに帯域幅の割り当て、
2. protection of allocated bandwidth by bandwidth reservation methods, as needed, but otherwise full sharing of bandwidth,
2. 必要に応じて帯域幅の予約方法による割り当てられた帯域幅の保護ですが、それ以外の場合は帯域幅の完全な共有、
3. differentiation between high-priority, normal-priority, and best-effort priority services, and
3. 優先順位、通常の優先度、最良の優先度サービスの区別、および
4. provision of admission control to reject connection requests, when needed, in order to meet performance objectives.
4. パフォーマンス目標を達成するために、必要に応じて接続要求を拒否するための入場管理の提供。
The modeling results presented in Appendix A show that MAR bandwidth allocation achieves a) greater efficiency in bandwidth sharing while still providing bandwidth isolation and protection against QoS degradation, and b) service differentiation for high-priority, normal-priority, and best-effort priority services.
付録Aのモデリング結果は、帯域幅の割り当てがa）帯域幅共有の効率を高めながら、帯域幅分離とQoS分解に対する保護を提供し、b）高優先度、通常の優先順位、および最高のエフォルトの優先度のためのサービスの差別化を提供することを示しています。サービス。
Security considerations related to the use of DS-TE are discussed in [DSTE-PROTO]. They apply independently of the Bandwidth Constraints Model, including the MAR specified in this document.
DS-TEの使用に関連するセキュリティ上の考慮事項は、[DSTE-Proto]で説明されています。これらは、このドキュメントで指定されたMARを含む帯域幅制約モデルとは独立して適用されます。
[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 MAR 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はMARの帯域幅制約モデルIDを0-239の範囲から割り当てました（[IANA-Cons]で定義された「必要な仕様」ポリシーに従って管理されます）。
Bandwidth Constraints Model Id 2 was allocated by IANA to MAR.
帯域幅の制約モデルID 2は、IANAによってMARに割り当てられました。
DS-TE and Bandwidth Constraints Models have been an active area of discussion in the TEWG. I would like to thank Wai Sum Lai for his support and review of this document. I also appreciate helpful discussions with Francois Le Faucheur.
DS-TEおよび帯域幅の制約モデルは、TEWGでのアクティブな議論の領域でした。この文書のサポートとレビューについて、Wai Sum Laiに感謝します。また、Francois Le Faucheurとの役立つ議論にも感謝しています。
Appendix A. MAR Operation & Performance Analysis
付録A. MAR運用とパフォーマンス分析
In the MAR Bandwidth Constraints Model, the bandwidth allocation control for each CT is based on estimated bandwidth needs, bandwidth use, and status of links. The LER makes needed bandwidth allocation changes, and uses [RSVP-TE], for example, to determine if link bandwidth can be allocated to a CT. Bandwidth allocated to individual CTs is protected as needed, but otherwise it is shared. Under normal, non-congested network conditions, all CTs/services fully share all available bandwidth. When congestion occurs for a particular CTc, bandwidth reservation acts to prohibit traffic from other CTs from seizing the allocated capacity for CTc. Associated with each CT is the allocated bandwidth constraint (BCc) which governs bandwidth allocation and protection; these parameters are illustrated with examples in this Appendix.
MAR帯域幅の制約モデルでは、各CTの帯域幅割り当て制御は、推定帯域幅のニーズ、帯域幅の使用、およびリンクのステータスに基づいています。LERは、必要な帯域幅の割り当ての変更を行い、たとえば[RSVP-TE]を使用して、リンク帯域幅をCTに割り当てることができるかどうかを判断します。個々のCTに割り当てられた帯域幅は必要に応じて保護されますが、それ以外の場合は共有されます。通常の非合成ネットワーク条件下では、すべてのCTS/サービスが利用可能なすべての帯域幅を完全に共有します。特定のCTCに対してうっ血が発生する場合、帯域幅予約は、他のCTSからのトラフィックがCTCの割り当てられた容量を押収することを禁止するようにします。各CTに関連付けられているのは、帯域幅の割り当てと保護を支配する割り当てられた帯域幅制約（BCC）です。これらのパラメーターは、この付録の例で示されています。
In performing MAR bandwidth allocation for a given flow/LSP, the LER first determines the egress LSR address, service-identity, and CT. The connection request is allocated an equivalent bandwidth to be routed on a particular CT. The LER then accesses the CT priority, QoS/traffic parameters, and routing table between the LER and egress LSR, and sets up the connection request using the MAR bandwidth allocation rules. The LER selects a first-choice path and determines if bandwidth can be allocated on the path based on the MAR bandwidth allocation rules given in Section 4. If the first choice path has insufficient bandwidth, the LER may then try alternate paths, and again applies the MAR bandwidth allocation rules now described.
特定のフロー/LSPのMAR帯域幅割り当ての実行で、LERは最初に出力LSRアドレス、サービスアイデンティティ、およびCTを決定します。接続要求には、特定のCTでルーティングされる同等の帯域幅が割り当てられます。次に、LERはCTの優先度、QOS/トラフィックパラメーター、およびLERとEgress LSRの間のルーティングテーブルにアクセスし、MAR帯域幅割り当てルールを使用して接続要求をセットアップします。LERは、第1選択パスを選択し、セクション4で与えられたMAR帯域幅割り当てルールに基づいてパスに帯域幅を割り当てることができるかどうかを判断します。最初の選択パスに帯域幅が不十分な場合、LERは代替パスを試し、再度適用できます。現在説明されているMar帯域幅の割り当てルール。
MAR bandwidth allocation is done on a per-CT basis, in which aggregated CT bandwidth is managed to meet the overall bandwidth requirements of CT service needs. Individual flows/LSPs are allocated bandwidth in the corresponding CT according to CT bandwidth availability. A fundamental principle applied in MAR bandwidth allocation methods is the use of bandwidth reservation techniques.
MAR帯域幅の割り当ては、CTごとにCT帯域幅の全体的な帯域幅要件を満たすために管理されているCTごとに行われます。個々のフロー/LSPは、CT帯域幅の可用性に従って、対応するCTで帯域幅を割り当てられます。MAR帯域幅の割り当て方法に適用される基本原則は、帯域幅予約技術の使用です。
Bandwidth reservation gives preference to the preferred traffic by allowing it to seize idle bandwidth on a link more easily than the non-preferred traffic. Burke [BUR] first analyzed bandwidth reservation behavior from the solution of the birth-death equations for the bandwidth reservation model. Burke's model showed the relative lost-traffic level for preferred traffic, which is not subject to bandwidth reservation restrictions, as compared to non-preferred traffic, which is subject to the restrictions. Bandwidth reservation protection is robust to traffic variations and provides significant dynamic protection of particular streams of traffic. It is widely used in large-scale network applications [ASH1, MUM, AKI, KRU, NAK].
帯域幅の予約は、非優先トラフィックよりもリンク上のアイドル帯域幅を簡単に押収できるようにすることにより、優先されるトラフィックを優先します。Burke [bur]は、帯域幅予約モデルの誕生死の方程式の溶液から帯域幅予約挙動を最初に分析しました。Burkeのモデルは、制限の対象となる非優先トラフィックと比較して、帯域幅の予約制限の対象ではない、優先トラフィックの相対的な失われたトラフィックレベルを示しました。帯域幅の予約保護は、トラフィックの変動に対して堅牢であり、トラフィックの特定のストリームの大幅な動的保護を提供します。大規模なネットワークアプリケーション[Ash1、Mum、Aki、Kru、Nak]で広く使用されています。
Bandwidth reservation is used in MAR bandwidth allocation to control sharing of link bandwidth across different CTs. On a given link, a small amount of bandwidth (RBW_THRES) is reserved (perhaps 1% of the total link bandwidth), and the reservation bandwidth can be accessed when a given CT has reserved bandwidth-in-progress (RESERVED_BW) below its allocated bandwidth (BC). That is, if the available link bandwidth (unreserved idle link bandwidth UNRESERVED_BW) exceeds RBW_THRES, then any CT is free to access the available bandwidth on the link. However, if UNRESERVED_BW is less than RBW_THRES, then the CT can utilize the available bandwidth only if its current bandwidth usage is below the allocated amount (BC). In this way, bandwidth can be fully shared among CTs if available, but it is protected by bandwidth reservation if below the reservation level.
帯域幅の予約は、3月の帯域幅の割り当てで使用され、さまざまなCTS間のリンク帯域幅の共有を制御します。特定のリンクでは、少量の帯域幅（RBW_THRES）が予約されています（おそらくリンク帯域幅の1％）。帯域幅（BC）。つまり、利用可能なリンク帯域幅（未リザーブルのアイドルリンク帯域幅vandwidth unreserved_bw）がrbw_thresを超える場合、CTはリンク上の利用可能な帯域幅に自由にアクセスできます。ただし、unserverved_bwがrbw_thres未満の場合、CTは、現在の帯域幅使用量が割り当てられた金額（BC）を下回っている場合にのみ、利用可能な帯域幅を利用できます。このようにして、利用可能な場合は帯域幅をCTS間で完全に共有できますが、予約レベルを下回る場合は帯域幅の予約によって保護されます。
Through the bandwidth reservation mechanism, MAR bandwidth allocation also gives preference to high-priority CTs, in comparison to normal-priority and best-effort priority CTs.
帯域幅の予約メカニズムを通じて、MAR帯域幅の割り当ては、通常の優先順位と最優秀優先度CTと比較して、優先度の高いCTを優先します。
Hence, bandwidth allocated to each CT is protected by bandwidth reservation methods, as needed, but otherwise shared. Each LER monitors CT bandwidth use on each CT, and determines if connection requests can be allocated to the CT bandwidth. For example, for a bandwidth request of DBW on a given flow/LSP, the LER determines the CT priority (high, normal, or best-effort), CT bandwidth-in-use, and CT bandwidth allocation thresholds, and uses these parameters to determine the allowed load state threshold to which capacity can be allocated. In allocating bandwidth DBW to a CT on given LSP (for example, A-B-E), each link in the path is checked for available bandwidth in comparison to the allowed load state. If bandwidth is unavailable on any link in path A-B-E, another LSP could be tried, such as A-C-D-E. Hence, determination of the link load state is necessary for MAR bandwidth allocation, and two link load states are distinguished: available (non-reserved) bandwidth (ABW_STATE), and reserved-bandwidth (RBW_STATE). Management of CT capacity uses the link state and the allowed load state threshold to determine if a bandwidth allocation request can be accepted on a given CT.
したがって、各CTに割り当てられた帯域幅は、必要に応じて帯域幅予約方法によって保護されますが、それ以外の場合は共有されます。各LERは、各CTでCT帯域幅の使用を監視し、接続要求をCT帯域幅に割り当てることができるかどうかを判断します。たとえば、特定のフロー/LSPでのDBWの帯域幅要求の場合、LERはCTの優先度（高、通常、または最高のエフォルト）、CT帯域幅の使用、およびCT帯域幅の割り当てのしきい値を決定し、これらのパラメーターを使用します。容量を割り当てることができる許可された負荷状態のしきい値を決定する。帯域幅DBWを指定されたLSP（たとえば、A-B-E）のCTに割り当てる際に、パス内の各リンクは、許可された負荷状態と比較して利用可能な帯域幅をチェックします。Path A-B-Eのリンクで帯域幅が利用できない場合、A-C-D-Eなどの別のLSPを試すことができます。したがって、MAR帯域幅の割り当てにはリンク負荷状態の決定が必要であり、2つのリンク負荷状態が区別されます。CT容量の管理は、リンク状態と許可された負荷状態のしきい値を使用して、特定のCTで帯域幅割り当て要求を受け入れることができるかどうかを判断します。
In this Appendix, modeling analysis is presented in which MAR bandwidth allocation is shown to provide good network performance, relative to full sharing models, under normal and abnormal operating conditions. A large-scale Diffserv-aware MPLS traffic engineering simulation model is used, in which several CTs with different priority classes share the pool of bandwidth on a multiservice, integrated voice/data network. MAR methods have also been analyzed in practice for networks that use time division multiplexing (i.e., TDM-based networks) [ASH1], and in modeling studies for IP-based networks [ASH2, ASH3, E.360].
この付録では、MAR帯域幅の割り当てが、正常および異常な動作条件の下で、完全な共有モデルと比較して良好なネットワークパフォーマンスを提供することが示されているモデリング分析が提示されています。大規模なDiffServに認識されたMPLSトラフィックエンジニアリングシミュレーションモデルが使用されます。このモデルでは、異なる優先度クラスを持ついくつかのCTSが、マルチサービスの統合された音声/データネットワーク上の帯域幅のプールを共有しています。MARメソッドは、時代分割多重化（つまり、TDMベースのネットワーク）[ASH1]を使用するネットワーク、およびIPベースのネットワークのモデリング研究[ASH2、ASH3、E.360]について実際に分析されています。
All Bandwidth Constraints Models should meet these objectives:
すべての帯域幅の制約モデルは、これらの目的を満たす必要があります。
1. applies equally when preemption is either enabled or disabled (when preemption is disabled, the model still works 'reasonably' well),
1. プリエンプションが有効または無効になっている場合（プリエンプションが無効になっている場合、モデルは「合理的に」機能する場合も同様に適用されます）、
2. bandwidth efficiency, i.e., good bandwidth sharing among CTs under both normal and overload conditions,
2. 帯域幅の効率、つまり、通常と過負荷条件の両方でCTS間の良好な帯域幅共有、
3. bandwidth isolation, i.e., a CT cannot hog the bandwidth of another CT under overload conditions,
3. 帯域幅の分離、つまり、CTは、過負荷条件下で別のCTの帯域幅をホグすることはできません。
4. protection against QoS degradation, at least of the high-priority CTs (e.g., high-priority voice, high-priority data, etc.), and
4. QoS劣化に対する保護、少なくとも優先順位CT（例えば、優先順位の音声、優先順位データなど）、および
5. reasonably simple, i.e., does not require additional IGP extensions and minimizes signaling load processing requirements.
5. 合理的にシンプル、つまり、追加のIGP拡張機能を必要とせず、シグナリング負荷処理要件を最小化します。
The use of any given Bandwidth Constraints Model has significant impacts on the performance of a network, as explained later. Therefore, the criteria used to select a model need to enable us to evaluate how a particular model delivers its performance, relative to other models. Lai [LAI, DSTE-PERF] has analyzed the MAM and RDM Models and provided valuable insights into the relative performance of these models under various network conditions.
後で説明するように、特定の帯域幅制約モデルの使用は、ネットワークのパフォーマンスに大きな影響を与えます。したがって、モデルを選択するために使用される基準は、特定のモデルが他のモデルと比較してパフォーマンスをどのように提供するかを評価できるようにする必要があります。LAI [LAI、DSTE-PERF]は、MAMおよびRDMモデルを分析し、さまざまなネットワーク条件下でこれらのモデルの相対的なパフォーマンスに関する貴重な洞察を提供しました。
In environments where preemption is not used, MAM is attractive because a) it is good at achieving isolation, and b) it achieves reasonable bandwidth efficiency with some QoS degradation of lower classes. When preemption is used, RDM is attractive because it can achieve bandwidth efficiency under normal load. However, RDM cannot provide service isolation under high load or when preemption is not used.
先制が使用されていない環境では、a）隔離を達成するのが得意であり、b）下位クラスのQoS分解により合理的な帯域幅効率を達成するため、MAMは魅力的です。プリエンプションを使用すると、RDMは通常の負荷の下で帯域幅効率を達成できるため魅力的です。ただし、RDMは、高負荷の下で、または先制が使用されていない場合、サービス分離を提供することはできません。
Our performance analysis of MAR bandwidth allocation methods is based on a full-scale, 135-node simulation model of a national network, combined with a multiservice traffic demand model to study various scenarios and tradeoffs [ASH3, E.360]. Three levels of traffic priority -- high, normal, and best effort -- are given across 5 CTs: normal priority voice, high priority voice, normal priority data, high priority data, and best effort data.
MAR帯域幅の割り当て方法のパフォーマンス分析は、全国ネットワークのフルスケールの135ノードシミュレーションモデルに基づいており、さまざまなシナリオとトレードオフ[ASH3、E.360]を研究するためのマルチサービストラフィック需要モデルと組み合わせています。3つのレベルのトラフィックの優先度 - 高い、通常、および最良の努力 - は、5つのCTSで与えられています：通常の優先順位音声、高優先度の音声、通常の優先度データ、高い優先度データ、および最良の努力データ。
The performance analyses for overloads and failures include a) the MAR Bandwidth Constraints Model, as specified in Section 4, b) the MAM Bandwidth Constraints Model, and c) the No-DSTE Bandwidth Constraints Model.
過負荷と障害のパフォーマンス分析には、a）セクション4、b）MAM帯域幅制約モデルで指定されているMAR帯域幅制約モデル、およびc）非DSTE帯域幅制約モデルが含まれます。
The allocated bandwidth constraints for MAR are described in Section 5 as:
MARの割り当てられた帯域幅の制約は、セクション5で次のように説明されています。
Normal priority CTs: BCck = PROPORTIONAL_BWk,
High priority CTs: BCck = FACTOR X PROPORTIONAL_BWk
Best-effort priority CTs: BCck = 0
In the MAM Bandwidth Constraints Model, the bandwidth constraints for each CT are set to a multiple of the proportional bandwidth allocation:
MAM帯域幅の制約モデルでは、各CTの帯域幅の制約は、比例帯域幅の割り当ての倍数に設定されます。
Normal priority CTs: BCck = FACTOR1 X PROPORTIONAL_BWk,
High priority CTs: BCck = FACTOR2 X PROPORTIONAL_BWk
Best-effort priority CTs: BCck = 0
Simulations show that for MAM, the sum (BCc) should exceed MAX_RESERVABLE_BWk for better efficiency, as follows:
シミュレーションでは、MAMの場合、合計（BCC）は次のように、より良い効率を得るためにMAX_RESERVABLE_BWKを超える必要があることが示されています。
1. The normal priority CTs and the BCc values need to be over-allocated to get reasonable performance. It was found that over-allocating by 100% (i.e., setting FACTOR1 = 2), gave reasonable performance.
1. 合理的なパフォーマンスを得るには、通常の優先度CTとBCC値を過剰に割り当てる必要があります。100％過剰転換（つまり、因子1 = 2の設定）が合理的なパフォーマンスを与えたことがわかった。
2. The high priority CTs can be over-allocated by a larger multiple FACTOR2 in MAM and this gives better performance.
2. 優先度の高いCTは、MAMでより大きな複数因子2によって過剰に割り当てられる可能性があり、これによりパフォーマンスが向上します。
The rather large amount of over-allocation improves efficiency, but somewhat defeats the 'bandwidth protection/isolation' needed with a BC Model, because one CT can now invade the bandwidth allocated to another CT. Each CT is restricted to its allocated bandwidth constraint BCck, which is the maximum level of bandwidth allocated to each CT on each link, as in normal operation of MAM.
かなり大量の過剰配分は効率を向上させますが、BCモデルで必要な「帯域幅保護/分離」をやや打ち負かします。これは、1つのCTが別のCTに割り当てられた帯域幅に侵入できるためです。各CTは、MAMの通常の動作と同様に、各リンクの各CTに割り当てられた帯域幅の最大レベルである割り当てられた帯域幅制約BCCKに制限されています。
In the No-DSTE Bandwidth Constraints Model, no reservation or protection of CT bandwidth is applied, and bandwidth allocation requests are admitted if bandwidth is available. Furthermore, no queuing priority is applied to any of the CTs in the No-DSTE Bandwidth Constraints Model.
非DSTE帯域幅の制約モデルでは、CT帯域幅の予約または保護は適用されず、帯域幅が利用可能な場合、帯域幅の割り当て要求が認められます。さらに、非DSTE帯域幅制約モデルのCTSのいずれにも優先順位は適用されません。
Table 2 gives performance results for a six-times overload on a single network node at Oakbrook, Illinois. The numbers given in the table are the total network percent lost (i.e., blocked) or delayed traffic. Note that in the focused overload scenario studied here, the percentage of lost/delayed traffic on the Oakbrook node is much higher than the network-wide average values given.
表2は、イリノイ州オークブルックにある単一のネットワークノードでの6倍の過負荷のパフォーマンス結果を示しています。テーブルに記載されている数値は、ネットワークの合計パーセントが失われる（つまり、ブロックされた）または遅延したトラフィックです。ここで調査した集中的な過負荷シナリオでは、オークブルックノードの失われた/遅延トラフィックの割合は、与えられたネットワーク全体の平均値よりもはるかに高いことに注意してください。
Table 2 Performance Comparison for MAR, MAM, & No-DSTE Bandwidth Constraints (BC) Models 6X Focused Overload on Oakbrook (Total Network % Lost/Delayed Traffic)
表2 MAR、MAM、およびNO-DSTE帯域幅の制約（BC）モデルのパフォーマンス比較6倍のオークブルックの焦点を絞った過負荷（合計ネットワーク％の失われた/遅延トラフィック）
Class Type MAR BC MAM BC No-DSTE BC
Model Model Model
NORMAL PRIORITY VOICE 0.00 1.97 10.30
HIGH PRIORITY VOICE 0.00 0.00 7.05
NORMAL PRIORITY DATA 0.00 6.63 13.30
HIGH PRIORITY DATA 0.00 0.00 7.05
BEST EFFORT PRIORITY DATA 12.33 11.92 9.65
Clearly the performance is better with MAR bandwidth allocation, and the results show that performance improves when bandwidth reservation is used. The reason for the poor performance of the No-DSTE Model, without bandwidth reservation, is due to the lack of protection of allocated bandwidth. If we add the bandwidth reservation mechanism, then performance of the network is greatly improved.
MAR帯域幅の割り当てにより、パフォーマンスは明らかに優れており、結果は、帯域幅の予約が使用されるとパフォーマンスが向上することを示しています。帯域幅の予約なしで、非DSTEモデルのパフォーマンスが低い理由は、割り当てられた帯域幅の保護がないためです。帯域幅の予約メカニズムを追加すると、ネットワークのパフォーマンスが大幅に改善されます。
The simulations showed that the performance of MAM is quite sensitive to the over-allocation factors discussed above. For example, if the BCc values are proportionally allocated with FACTOR1 = 1, then the results are much worse, as shown in Table 3:
シミュレーションは、MAMのパフォーマンスが上記の過剰配分因子に非常に敏感であることを示しました。たとえば、BCC値が因子1 = 1で比例して割り当てられている場合、表3に示すように、結果ははるかに悪いです。
Table 3 Performance Comparison for MAM Bandwidth Constraints Model with Different Over-allocation Factors 6X Focused Overload on Oakbrook (Total Network % Lost/Delayed Traffic)
表3異なる過剰配分因子を持つMAM帯域幅制約モデルのパフォーマンス比較6倍の焦点を絞ったOakbrook（合計ネットワーク％の失われた/遅延トラフィック）
Class Type (FACTOR1 = 1) (FACTOR1 = 2)
NORMAL PRIORITY VOICE 31.69 1.97
HIGH PRIORITY VOICE 0.00 0.00
NORMAL PRIORITY DATA 31.22 6.63
HIGH PRIORITY DATA 0.00 0.00
BEST EFFORT PRIORITY DATA 8.76 11.92
Table 4 illustrates the performance of the MAR, MAM, and No-DSTE
Bandwidth Constraints Models for a high-day network load pattern with
a 50% general overload. The numbers given in the table are the total
network percent lost (i.e., blocked) or delayed traffic.
Table 4 Performance Comparison for MAR, MAM, & No-DSTE Bandwidth Constraints (BC) Models 50% General Overload (Total Network % Lost/Delayed Traffic)
表4 MAR、ママ、および日付のない帯域幅制約（BC）モデル50％一般的な過負荷のパフォーマンス比較（合計ネットワーク％の失われ/遅延トラフィック）
Class Type MAR BC MAM BC No-DSTE BC
Model Model Model
NORMAL PRIORITY VOICE 0.02 0.13 7.98
HIGH PRIORITY VOICE 0.00 0.00 8.94
NORMAL PRIORITY DATA 0.00 0.26 6.93
HIGH PRIORITY DATA 0.00 0.00 8.94
BEST EFFORT PRIORITY DATA 10.41 10.39 8.40
Again, we can see the performance is always better when MAR bandwidth allocation and reservation is used.
繰り返しますが、MAR帯域幅の割り当てと予約が使用される場合、パフォーマンスが常に優れていることがわかります。
Table 5 illustrates the performance of the MAR, MAM, and No-DSTE Bandwidth Constraints Models for a single link failure scenario (3 OC-48). The numbers given in the table are the total network percent lost (blocked) or delayed traffic.
表5は、単一のリンク障害シナリオ（3 OC-48）のMAR、MAM、およびNO-DSTE帯域幅の制約モデルのパフォーマンスを示しています。テーブルに記載されている数値は、ネットワークの合計パーセントが失われ（ブロックされた）または遅延トラフィックです。
Table 5 Performance Comparison for MAR, MAM, & No-DSTE Bandwidth Constraints (BC) Models Single Link Failure (2 OC-48) (Total Network % Lost/Delayed Traffic)
表5 MAR、ママ、および日付のない帯域幅制約（BC）モデルの単一リンク障害（2 OC-48）のパフォーマンス比較（合計ネットワーク％の失われ/遅延トラフィック）
Class Type MAR BC MAM BC No-DSTE BC
Model Model Model
NORMAL PRIORITY VOICE 0.00 0.62 0.63
HIGH PRIORITY VOICE 0.00 0.31 0.32
NORMAL PRIORITY DATA 0.00 0.48 0.50
HIGH PRIORITY DATA 0.00 0.31 0.32
BEST EFFORT PRIORITY DATA 0.12 0.72 0.63
Again, we can see the performance is always better when MAR bandwidth allocation and reservation is used.
繰り返しますが、MAR帯域幅の割り当てと予約が使用される場合、パフォーマンスが常に優れていることがわかります。
Table 6 illustrates the performance of the MAR, MAM, and No-DSTE Bandwidth Constraints Models for a multiple link failure scenario (3 links with 3 OC-48, 3 OC-3, 4 OC-3 capacity, respectively). The numbers given in the table are the total network percent lost (blocked) or delayed traffic.
表6は、複数のリンク障害シナリオのMAR、MAM、およびNO-DSTE帯域幅の制約モデルのパフォーマンスを示しています（それぞれ3 OC-48、3 OC-3、4 OC-3容量を含む3リンク）。テーブルに記載されている数値は、ネットワークの合計パーセントが失われ（ブロックされた）または遅延トラフィックです。
Table 6 Performance Comparison for MAR, MAM, & No-DSTE Bandwidth Constraints (BC) Models Multiple Link Failure (3 Links with 2 OC-48, 2 OC-12, 1 OC-12, Respectively) (Total Network % Lost/Delayed Traffic)
表6 MAR、MAM、およびNO-DSTE帯域幅の制約（BC）のパフォーマンス比較（BC）は、複数のリンク障害（それぞれ2 OC-48、2 OC-12、1 OC-12の3つのリンク）（合計ネットワーク％の失われ/遅延）渋滞）
Class Type MAR BC MAM BC No-DSTE BC
Model Model Model
NORMAL PRIORITY VOICE 0.00 0.91 0.92
HIGH PRIORITY VOICE 0.00 0.44 0.44
NORMAL PRIORITY DATA 0.00 0.70 0.72
HIGH PRIORITY DATA 0.00 0.44 0.44
BEST EFFORT PRIORITY DATA 0.14 1.03 1.04
Again, we can see the performance is always better when MAR bandwidth allocation and reservation is used.
繰り返しますが、MAR帯域幅の割り当てと予約が使用される場合、パフォーマンスが常に優れていることがわかります。
Lai's results [LAI, DSTE-PERF] show the trade-off between bandwidth sharing and service protection/isolation, using an analytic model of a single link. He shows that RDM has a higher degree of sharing than MAM. Furthermore, for a single link, the overall loss probability is the smallest under full sharing and largest under MAM, with RDM being intermediate. Hence, on a single link, Lai shows that the full sharing model yields the highest link efficiency, while MAM yields the lowest; and that full sharing has the poorest service protection capability.
LAIの結果[LAI、DSTE-PERF]は、単一のリンクの分析モデルを使用して、帯域幅共有とサービス保護/分離のトレードオフを示しています。彼は、RDMがMAMよりも高い共有の程度を持っていることを示しています。さらに、単一のリンクの場合、全体的な損失確率は完全な共有下で最小であり、MAMの下で最大であり、RDMは中級です。したがって、単一のリンクで、LAIは完全な共有モデルが最高のリンク効率を生成し、MAMは最低のリンク効率を生成することを示しています。そして、その完全な共有には、最も貧しいサービス保護機能があります。
The results of the present study show that, when considering a network context in which there are many links and multiple-link routing paths are used, full sharing does not necessarily lead to maximum, network-wide bandwidth efficiency. In fact, the results in Table 4 show that the No-DSTE Model not only degrades total network throughput, but also degrades the performance of every CT that should be protected. Allowing more bandwidth sharing may improve performance up to a point, but it can severely degrade performance if care is not taken to protect allocated bandwidth under congestion.
本研究の結果は、多くのリンクと複数リンクルーティングパスが使用されるネットワークコンテキストを検討する場合、完全な共有が必ずしも最大のネットワーク全体の帯域幅効率につながるとは限らないことを示しています。実際、表4の結果は、非DSTEモデルが総ネットワークスループットを分解するだけでなく、保護する必要があるすべてのCTのパフォーマンスを低下させることを示しています。より多くの帯域幅の共有を許可すると、パフォーマンスがポイントまで向上する可能性がありますが、輻輳下で割り当てられた帯域幅を保護するために注意が払われない場合、パフォーマンスをひどく低下させる可能性があります。
Both Lai's study and this study show that increasing the degree of bandwidth sharing among the different CTs leads to a tighter coupling between CTs. Under normal loading conditions, there is adequate capacity for each CT, which minimizes the effect of such coupling.
LAIの研究とこの研究の両方は、異なるCTS間の帯域幅共有の程度を増やすことで、CT間のより緊密な結合につながることを示しています。通常の負荷条件下では、各CTに適切な容量があり、このような結合の効果を最小限に抑えます。
Under overload conditions, when there is a scarcity of capacity, such coupling can cause severe degradation of service, especially for the lower priority CTs.
過負荷条件下では、容量が不足している場合、このような結合は、特に優先度の低いCTの場合、サービスの深刻な劣化を引き起こす可能性があります。
Thus, the objective of maximizing efficient bandwidth usage, as stated in Bandwidth Constraints Model objectives, needs to be exercised with care. Due consideration also needs to be given to achieving bandwidth isolation under overload, in order to minimize the effect of interactions among the different CTs. The proper tradeoff of bandwidth sharing and bandwidth isolation needs to be achieved in the selection of a Bandwidth Constraints Model. Bandwidth reservation supports greater efficiency in bandwidth sharing, while still providing bandwidth isolation and protection against QoS degradation.
したがって、帯域幅の制約モデルの目標に記載されているように、効率的な帯域幅の使用を最大化する目的は、注意して行使する必要があります。異なるCTS間の相互作用の効果を最小限に抑えるために、過負荷の下で帯域幅分離を達成するためには、適切な考慮事項も与えられる必要があります。帯域幅の共有と帯域幅の分離の適切なトレードオフは、帯域幅の制約モデルの選択において達成する必要があります。帯域幅の予約は、帯域幅共有の効率を高め、帯域幅の分離とQoS分解に対する保護を提供します。
In summary, the proposed MAR Bandwidth Constraints Model includes the following: a) allocation of bandwidth to individual CTs, b) protection of allocated bandwidth by bandwidth reservation methods, as needed, but otherwise full sharing of bandwidth, c) differentiation between high-priority, normal-priority, and best-effort priority services, and d) provision of admission control to reject connection requests, when needed, in order to meet performance objectives.
要約すると、提案されているMAR帯域幅制約モデルには以下が含まれます。a）個々のCTSへの帯域幅の割り当て、b）必要に応じて帯域幅予約方法による割り当てられた帯域幅の保護、そうでなければ帯域幅の完全な共有、c）高優位性間の分化、通常の優先度、および最良の優先サービス、およびd）パフォーマンス目標を達成するために、必要に応じて接続要求を拒否する入場管理の提供。
In the modeling results, the MAR Bandwidth Constraints Model compares favorably with methods that do not use bandwidth reservation. In particular, some of the conclusions from the modeling are as follows:
モデリングの結果では、MAR帯域幅の制約モデルは、帯域幅の予約を使用しない方法と好意的に比較されます。特に、モデリングからの結論のいくつかは次のとおりです。
o MAR bandwidth allocation is effective in improving performance over methods that lack bandwidth reservation; this allows more bandwidth sharing under congestion.
o Mar帯域幅の割り当ては、帯域幅の予約を欠く方法よりもパフォーマンスを改善するのに効果的です。これにより、混雑の下でより多くの帯域幅共有が可能になります。
o MAR achieves service differentiation for high-priority, normal-priority, and best-effort priority services.
o MARは、優先順位、通常の優先度、および最高の優先度サービスのサービス差別化を達成します。
o Bandwidth reservation supports greater efficiency in bandwidth sharing while still providing bandwidth isolation and protection against QoS degradation, and is critical to stable and efficient network performance.
o 帯域幅の予約は、帯域幅共有の効率の向上をサポートしながら、帯域幅の分離とQoS分解に対する保護を提供し、安定した効率的なネットワークパフォーマンスにとって重要です。
As discussed in [DSTE-PROTO], there are potential advantages for a Head-end when predicting the impact of an LSP on the unreserved bandwidth for computing the path of the LSP. One example would be to perform better load-distribution of multiple LSPs across multiple paths. Another example would be to avoid CAC rejection when the LSP no longer fits on a link after establishment.
[DSTE-Proto]で説明したように、LSPの経路を計算するために、LSPの予約されていない帯域幅に対する影響を予測する場合、ヘッドエンドには潜在的な利点があります。1つの例は、複数のパスで複数のLSPのより良い負荷分布を実行することです。別の例は、LSPが設立後にリンクに適合しなくなったときにCACの拒絶を避けることです。
Where such predictions are used on Head-ends, the optional Bandwidth Constraints sub-TLV and the optional Maximum Reservable Bandwidth sub-TLV MAY be advertised in the IGP. This can be used by Head-ends to predict how an LSP affects unreserved bandwidth values. Such predictions can be made with MAR by using the unreserved bandwidth values advertised by the IGP, as discussed in Sections 2 and 4:
このような予測がヘッドエンドで使用される場合、オプションの帯域幅制約Sub-TLVとオプションの最大予約可能帯域幅サブTLVがIGPで宣伝される場合があります。これは、LSPが予約されていない帯域幅の値にどのように影響するかを予測するために、ヘッドエンドで使用できます。このような予測は、セクション2および4で説明するように、IGPによって宣伝されている予約されていない帯域幅値を使用することにより、MARで行うことができます。
UNRESERVED_BWck = MAX_RESERVABLE_BWk - UNRESERVED_BWk -
delta0/1(CTck) * RBW-THRESk
where
ただし
delta0/1(CTck) = 0 if RESERVED_BWck < BCck
delta0/1(CTck) = 1 if RESERVED_BWck >= BCck
Furthermore, the following estimate can be made for RBW_THRESk:
さらに、RBW_THRESKについては、次の推定値を作成できます。
RBW_THRESk = RBW_% * MAX_RESERVABLE_BWk,
rbw_thresk = rbw_％ * max_reservable_bwk、
where RBW_% is a locally configured variable, which could take on different values for different link speeds. This information could be used in conjunction with the BC sub-TLV, MAX_RESERVABLE_BW sub-TLV, and UNRESERVED_BW sub-TLV to make predictions of available bandwidth on each link for each CT. Because admission control algorithms are left for vendor differentiation, predictions can only be performed effectively when the Head-end LSR predictions are based on the same (or a very close) admission control algorithm used by other LSRs.
ここで、RBW_％はローカルで構成された変数であり、異なるリンク速度で異なる値を引き受ける可能性があります。この情報は、各CTの各リンクで利用可能な帯域幅を予測するために、BC SUB-TLV、MAX_RESERVABLE_BW SUB-TLV、およびUNRESSERVED_BW SUB-TLVと組み合わせて使用できます。ベンダーの差別化のために入場制御アルゴリズムは残されているため、ヘッドエンドのLSR予測が他のLSRが使用する同じ（または非常に近い）アドミスティングコントロールアルゴリズムに基づいている場合にのみ、予測を効果的に実行できます。
LSPs may occasionally be rejected when head-ends are establishing LSPs through a common link. As an example, consider some link L, and two head-ends H1 and H2. If only H1 or only H2 is establishing LSPs through L, then the prediction is accurate. But if both H1 and H2 are establishing LSPs through L at the same time, the prediction would not work perfectly. In other words, the CAC will occasionally run into a rejected LSP on a link with such 'race' conditions. Also, as mentioned in Appendix A, such a prediction is optional and outside the scope of the document.
ヘッドエンドが共通のリンクを介してLSPを確立している場合、LSPは時折拒否される可能性があります。例として、リンクLと2つのヘッドエンドH1とH2を考慮してください。H1またはH2のみがLを介してLSPを確立している場合、予測は正確です。しかし、H1とH2の両方が同時にLを介してLSPを確立している場合、予測は完全に機能しません。言い換えれば、CACは、そのような「人種」条件とのリンクで拒否されたLSPに時折遭遇します。また、付録Aで述べたように、このような予測はオプションであり、ドキュメントの範囲外です。
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
参考引用
[AKI] Akinpelu, J. M., "The Overload Performance of Engineered Networks with Nonhierarchical & Hierarchical Routing," BSTJ, Vol. 63, 1984.
[Aki] Akinpelu、J。M.、「非階層および階層ルーティングを備えたエンジニアリングネットワークの過負荷性能」、BSTJ、Vol。63、1984。
[ASH1] Ash, G. R., "Dynamic Routing in Telecommunications Networks," McGraw-Hill, 1998.
[Ash1] Ash、G。R.、「電気通信ネットワークの動的ルーティング」、McGraw-Hill、1998。
[ASH2] Ash, G. R., et al., "Routing Evolution in Multiservice Integrated Voice/Data Networks," Proceeding of ITC-16, Edinburgh, June 1999.
[Ash2] Ash、G。R.、et al。、「マルチサービス統合音声/データネットワークのルーティング進化」、ITC-16の進行、エディンバラ、1999年6月。
[ASH3] Ash, G. R., "Performance Evaluation of QoS-Routing Methods for IP-Based Multiservice Networks," Computer Communications Magazine, May 2003.
[Ash3] Ash、G。R.、「IPベースのマルチサービスネットワークのQoSルーティング方法のパフォーマンス評価」、Computer Communications Magazine、2003年5月。
[BUR] Burke, P. J., Blocking Probabilities Associated with Directional Reservation, unpublished memorandum, 1961.
[Bur] Burke、P。J.、方向予約に関連するブロック確率、未発表の覚書、1961。
[DSTE-PERF] Lai, W., "Bandwidth Constraints Models for Differentiated Services-aware MPLS Traffic Engineering: Performance Evaluation", RFC 4128, June 2005.
[DSTE-PERF] Lai、W。、「差別化されたサービス認識MPLSトラフィックエンジニアリングの帯域幅制約モデル：パフォーマンス評価」、RFC 4128、2005年6月。
[E.360] ITU-T Recommendations E.360.1 - E.360.7, "QoS Routing & Related Traffic Engineering Methods for Multiservice TDM-, ATM-, & IP-Based Networks".
[E.360] ITU-Tの推奨事項e.360.1-E.360.7、「QoSルーティングおよび関連する交通工学法のTDM、ATM、およびIPベースのネットワーク」。
[GMPLS-RECOV] Lang, J., et al., "Generalized MPLS Recovery Functional Specification", Work in Progress.
[Gmpls-Recov] Lang、J.、et al。、「一般化されたMPLS回復機能仕様」、進行中の作業。
[KRU] Krupp, R. S., "Stabilization of Alternate Routing Networks", Proceedings of ICC, Philadelphia, 1982.
[Kru] Krupp、R。S.、「代替ルーティングネットワークの安定化」、ICCの議事録、フィラデルフィア、1982年。
[LAI] Lai, W., "Traffic Engineering for MPLS, Internet Performance and Control of Network Systems III Conference", SPIE Proceedings Vol. 4865, pp. 256-267, Boston, Massachusetts, USA, 29 July-1 August 2002.
[Lai] Lai、W。、「MPLSのトラフィックエンジニアリング、インターネットパフォーマンス、ネットワークシステムIII会議の制御」、Spie Proceedings Vol。4865、pp。256-267、ボストン、マサチューセッツ州、米国、2002年7月1日1日。
[MAM] Le Faucheur, F., Lai, W., "Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC 4125, June 2005.
[Mam] Le Faucheur、F.、Lai、W。、「Diffserv-aware MPLSトラフィックエンジニアリングの最大割り当て帯域幅制約モデル」、RFC 4125、2005年6月。
[MPLS-BACKUP] Vasseur, J. P., et al., "MPLS Traffic Engineering Fast Reroute: Bypass Tunnel Path Computation for Bandwidth Protection", Work in Progress.
[MPLS-Backup] Vasseur、J。P.、et al。、「MPLS Traffic Engineering Fast Reroute：帯域幅保護のためのバイパストンネルパス計算」、進行中の作業。
[MUM] Mummert, V. S., "Network Management and Its Implementation on the No. 4ESS, International Switching Symposium", Japan, 1976.
[Mum] Mummert、V。S.、「ネットワーク管理とその実装、No。4ess、International Switching Symposium」、日本、1976年。
[NAK] Nakagome, Y., Mori, H., Flexible Routing in the Global Communication Network, Proceedings of ITC-7, Stockholm, 1973.
[Nak] Nakagome、Y.、Mori、H.、Global Communication Networkの柔軟なルーティング、ITC-7の議事録、1973年。
[OSPF-TE] Katz, D., Kompella, K. and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[OSPF-TE] Katz、D.、Kompella、K。、およびD. Yeung、「Traffic Engineering（TE）拡張機能への拡張」、RFC 3630、2003年9月。
[RDM] Le Faucheur, F., Ed., "Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC 4127, June 2005.
[RDM] Le Faucheur、F.、ed。、「Diffserv-aware MPLS Traffic Engineeringのロシア人形の帯域幅の制約モデル」、RFC 4127、2005年6月。
[RSVP-TE] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RSVP-TE] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：LSPトンネルのRSVPへの拡張」、RFC 3209、2001年12月。
Author's Address
著者の連絡先
Jerry Ash AT&T Room MT D5-2A01 200 Laurel Avenue Middletown, NJ 07748, USA
ジェリーアッシュAT＆TルームMT D5-2A01 200ローレルアベニューミドルタウン、ニュージャージー州07748、米国
Phone: +1 732-420-4578
EMail: gash@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エディター機能の資金は現在、インターネット協会によって提供されています。