RFC 4126 - Max Allocation with Reservation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering & Performance Comparisons 日本語訳

URL : https://tools.ietf.org/html/rfc4126
タイトル : RFC 4126 - Diffservの対応のMPLSトラフィックエンジニアリング＆パフォーマンス比較のための予約帯域幅の制約モデルとの最大の割り当て
翻訳編集 : 自動生成

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

Diffservの対応の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.

このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。

著作権表示

著作権（C）インターネット協会（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を意識したMPLSトラフィックエンジニアリング（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

1. Introduction

1. はじめに

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の対応のMPLSトラフィックエンジニアリング（DSTE）の要件とプロトコルの拡張機能は、[DSTE - REQ、DSTE - プロト]で指定されています。 DS-TEの実装のための要件は、DS-TEで使用するための帯域幅制約モデルの仕様です。帯域幅の制約モデルは、個々のクラスタイプ（CTS）への帯域幅の割り当てをサポートするための「ルール」を提供します。 CTは、別々の帯域幅の割り当て、優先順位、およびQoSの目的を提供しているDS-TEモデルでのサービスクラスのグループです。いくつかの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）の帯域幅制約モデルで最大の割り当てのための機能仕様を与えることによってDSTE要件文書[DSTE-REQ]を補完することを意図しています。 MAR帯域幅の制約モデルの動作の例が提示されています。 MARのパフォーマンスは、自社のネットワークでモデルのユーザー実装にガイダンスを提供するために、帯域幅の制約モデルを選択するための判断基準と比較して分析されます。

Two other Bandwidth Constraints Models are being specified for use in DS-TE:

他の二つの帯域幅の制約モデルはDS-TEでの使用のために指定されています：

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と同様です。しかしながら、CTS、帯域予約および保護メカニズムの使用を介しては渋滞なしの条件下での帯域幅割り当てを超過が、過負荷及び輻輳が発生した場合、その割り当てられた帯域幅に復帰させます。

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.帯域幅の効率、すなわち、通常の過負荷状態の両方の下でのCTのうち、良好な帯域幅の共有、

3. bandwidth isolation, i.e., a CT cannot hog the bandwidth of another CT under overload conditions,

前記帯域分離、即ち、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.保護、高優先度の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は、同時に、帯域幅効率、帯域幅の単離、およびプリエンプションなしの品質劣化に対する保護を達成することが実証されています。

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節では、仮定と適用可能性を与えます。第3月4日帯域幅制約モデルの機能仕様。そして第5節では、我々はその動作の例を与えます。付録Aでは、MARのパフォーマンスは、自社のネットワークでモデルのユーザー実装にガイダンスを提供するために、帯域幅の制約モデルを選択するための判断基準と比較して分析されます。付録Bにおいて、経路計算のための帯域幅の予測について説明します。

1.1. Specification of Requirements

1.1. 要件の仕様

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]に記載されているように解釈されます。

2. Definitions

2.定義

For readability a number of definitions from [DSTE-REQ, DSTE-PROTO] are repeated here:

読みやすくするために[DSTE - REQ、DSTE - プロト]からの定義の数は、ここでは繰り返されています。

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).

トラフィックトランク：ラベルスイッチパス（LSP）の内側に配置される（即ち、DS-TEの観点から等価的に処理された）同じクラスのトラフィックフローの集合。

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.

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-クラス：一対の：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上のCTCの帯域幅制約=リンク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：CTCに属するすべての確立されたLSPによって予約された帯域幅の予約帯域進行中のCTCのリンクk上（0 <= C <= MaxCT-1）、RESERVED_BWck =合計金額。

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は： - 総和[RESERVED_BWck（0 <= C <= MaxCT-1）]リンクkに予約されていないリンク帯域幅はまだCT、UNRESERVED_BWk = MAX_RESERVABLE_BWkために予約されていない帯域幅の量を指定します。

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は： - delta0 / 1（CTck）* RBW-THRESkリンクk上のCTCに予約されていないリンク帯域幅がまだCTC、UNRESERVED_BWck = UNRESERVED_BWkために予約されていない帯域幅の量を指定します

                       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を横切って帯域幅を共有することによって帯域幅効率を高める例示的機構です。 RESERVED_BWckの概念は[DSTE-REQ]に導入する複数のLSPを横切って帯域幅共有のような概念と互換性があることを保証するために、[DSTE-REQ]で提供される定義の文言は、一般化されています。 DS-TEと共有メッシュ保護は共有メッシュ回復が各DS-TEクラスタイプ内で独立して動作するという仮定の下で、同時に動作できるように、この一般化して、定義が、[GMPLS-RECOV]で定義された共有メッシュ修復と互換性がありますそして、クラスタイプにわたって動作しません。例えば、CTCの主要LSPを保護するバックアップLSPはまた、CTCに属している必要があります。 CTCのバックアップのLSPと帯域幅を共有する過剰なトラフィックのLSPはまた、CTCに属している必要があります。

3. Assumptions & Applicability

3.前提と適用性

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.

リンク帯域幅は、フロー/ LSP /トラフィックトランクのための指定されたパス上に排出される場合6、代替パスは、CT帯域幅割り当てを満足することを試みてもよいです。

Note that the above assumptions are not unique to MAR, but are generic, common assumptions for all BC Models.

上記の仮定は、MARに固有のものではなく、すべてのBCモデルのための一般的な、一般的な仮定であることに注意してください。

4. Functional Specification of the MAR Bandwidth Constraints Model

MAR帯域幅の制約モデルの4機能仕様

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）リンク帯域幅は、CTに割り当てることができるかどうかを決定するために、例えば、[RSVP-TE]帯域割当の変更、および使用が必要となります。個々のCTに割り当てられた帯域幅は、必要に応じて保護されますが、それ以外の場合は、共有されています。通常、非混雑したネットワーク条件の下では、すべてのCTS /サービスが完全にすべての利用可能な帯域幅を共有します。輻輳が特定のCTCのために発生した場合、帯域幅予約は、CTCのために割り当てられた容量を焼き付きから他のCTからのトラフィックを禁止します。

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関連付けられBCckは、帯域幅割り当ておよび保護を管理するために割り当てられた帯域幅の制約です。所与CTCは帯域使用中（RESERVED_BWck）その割り当てられた帯域幅の制約（BCck）以下を有する場合、リンク（RBW_THRESk）上の予約帯域幅にアクセスすることができます。 RESERVED_BWckがその割り当てられた帯域幅の制約（BCck）を超える場合は、次に予約帯域幅（RBW_THRESk）がアクセスできません。利用可能な場合はこの方法では、帯域幅が十分にCTの間で共有することができますが、そうでない場合は、帯域幅予約方法によって保護されています。

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リンクk上

For LSP on a high priority or normal priority CTc:

高い優先度または通常優先順位CTCのLSPの場合：

If RESERVED_BWck <= BCck: admit if DBW <= UNRESERVED_BWk If RESERVED_BWck > BCck: admit if DBW <= UNRESERVED_BWk - RBW_THRESk;

RESERVED_BWck場合は<= BCck：DBW <=予約されていない場合BWK認める - RBW_THRESk;：DBW RESERVED_BWck> BCckの<=予約されていないBWKがあれば認めます

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のキューイングは、利用可能なリンク帯域幅がある場合にのみ、パケットBE認めています。

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帯域幅の制約モデルに適用され、プリエンプションが有効になっている場合、クロスCTプリエンプションが許可されています。

The bandwidth allocation rules defined in Table 1 are illustrated with an example in Section 6 and simulation analysis in Appendix A.

表1で定義された帯域幅割当規則は、付録Aのセクション6とシミュレーション解析の例で示されています

5. Setting Bandwidth Constraints

5.設定帯域幅の制約

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上の帯域幅の制約BCckは予測またはリンク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

PROPORTIONAL_BWck = TRAF_LOAD_BWck / [和{TRAF_LOAD_BWck、C = 0、MaxCT-1}] X MAX_RESERVABLE_BWk

For normal priority CTc: BCck = PROPORTIONAL_BWck

通常の優先度CTCの場合：BCck = PROPORTIONAL_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

BCck = FACTOR X PROPORTIONAL_BWck：優先度の高いCTC用

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.

因子は、比例帯域幅の倍数に設定されている場合（例えば、FACTOR = 2または3が典型的です）。これは、最大予約可能帯域幅の一部の「過剰割り当て」になり、優先度の高いのCTを優先します。通常、高優先度の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

6. Example of MAR Operation

MAR操作の6例

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

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

これらの帯域幅の制約はのCTのいずれかがあれば少なくともRBW_THRES（リンク上の予約帯域幅の閾値）であり、その帯域幅の制約（BCC）を超えることが許され、MARのセクション5で説明したように、通常のトラフィック負荷に基づいています残りのスペアの帯域幅の単位。仮定してみましょう

RBW_THRES = 10

So under overload, if

だから、過負荷の下で、もし

RESERVED_BW0 = 50 RESERVED_BW1 = 30 RESERVED_BW2 = 10

Therefore, for this loading

したがって、このロード用

UNRESERVED_BW = 100 - 50 - 30 - 10 = 10

UNRESERVED_BW = 100 - 50から30 - = 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.

彼らは彼らのBC値を超えていると、そこにあるだけで=リンクに残された予備の帯域幅の10個の単位をRBW_THRESのでCT0とCT1は、もはや、リンク上での帯域幅を増やすことはできません。需要が到着した場合、それはそのBC値を下回っているので、しかし、CT2は、（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

のは、LSPがCT0は、帯域幅（すなわち、DBW = 5）の5つの単位を必要とするために到着したとしましょう。私たちは、このLSPを是認するかどうかを、表1に基づいて、決定する必要があります。 CT0のためので、

RESERVED_BW0 > BC0 (50 > 30), and DBW > UNRESERVED_BW - RBW_THRES (i.e., 5 > 10 - 10)

RESERVED_BW0> BC0（> 30 50）、及びDBW> UNRESERVED_BW - RBW_THRES（すなわち、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

それでは、CT2は、帯域幅の5つの単位（すなわち、DBW = 5）を必要とするためにLSPが到着したとしましょう。私たちは、このLSPを是認するかどうかを表1に基づいて決定する必要があります。 CT2のためので、

RESERVED_BW2 < BC2 (10 < 20), and DBW < UNRESERVED_BW (i.e., 5 < 10)

RESERVED_BW2 <BC2（10 <20）、及びDBW <UNRESERVED_BW（すなわち、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.

したがって彼らはBCC値を超えているので、上記の例では、リンクの現在の状態および現在のCT負荷において、CT0とCT1は、もはや、リンク上での帯域幅を増加させることができるのみが存在する= 10個の単位をRBW_THRES予備の帯域幅がリンクの上に残しました。需要が到着した場合、それはそのBCC値を下回っているので、しかし、CT2は、（10台まで）追加の帯域幅を取ることができます。

7. Summary

7.まとめ

The proposed MAR Bandwidth Constraints Model includes the following:

提案されたMAR帯域幅の制約モデルは、次のものが含まれます。

1. allocation of bandwidth to individual CTs,

個々のCTへの帯域幅の割り当て1.、

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に提示モデリング結果は、MARの帯域幅割り当ては、まだ品質劣化に対する帯域幅の単離および保護を提供しながら、帯域幅の共有に）より高い効率を達成し、そしてことを示す高優先度、通常優先度、ベストエフォート優先度B）サービスの差別サービスを提供しています。

8. Security Considerations

8.セキュリティの考慮事項

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.

DSTEの使用に関連するセキュリティ上の考慮事項は、[DSTE - プロト]で議論されています。彼らは、この文書で指定されたMARを含む、帯域幅の制約モデルとは独立して適用されます。

9. IANA Considerations

9. IANAの考慮事項

[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 - プロト]は、「帯域幅の制約モデルID」の新しい名前空間を定義します。その名前空間の値の配分のためのガイドラインは[DSTE - プロト]のセクション13.1で詳述されています。これらのガイドラインによれば、IANAは、（[IANA-CONS]で定義された「仕様必須」ポリシーに従って管理される）範囲0から239からMARのための帯域幅制約モデルIDが割り当てられています。

Bandwidth Constraints Model Id 2 was allocated by IANA to MAR.

帯域幅の制約モデル同上2は、MARにIANAによって割り当てられました。

10. Acknowledgements

10.謝辞

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での議論の活性領域となっています。私は彼のサポートとこのドキュメントのレビューのためにワイ合計ライに感謝したいと思います。私はまた、フランソワ・ルFaucheurで役立つ議論を感謝しています。

Appendix A. MAR Operation & Performance Analysis

付録A. MARオペレーション＆パフォーマンスの分析

A.1. MAR Operation

A.1。 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は、リンク帯域幅がCTに割り当てることができるかどうかを決定するために、例えば、必要な帯域幅の割り当ての変更、および使用[RSVP-TE]を、作ります。個々のCTに割り当てられた帯域幅は、必要に応じて保護されますが、それ以外の場合は、共有されています。通常、非混雑したネットワーク条件の下では、すべてのCTS /サービスが完全にすべての利用可能な帯域幅を共有します。輻輳が特定のCTCのために発生した場合、帯域幅予約は、CTCのために割り当てられた容量を焼き付きから他のCTからのトラフィックを禁止するように作用します。各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は、次いで、LERと出口LSR間のCT優先順位と、QoS /トラフィックパラメータ、およびルーティングテーブルをアクセスし、MAR帯域割当規則を使用して接続要求を設定します。 LERは、第一選択のパスを選択し、帯域幅が再び適用される最初の選択パスが不十分な帯域幅がある場合、LERは、次いで代替パスを試みることができる第4項で与えられたMAR帯域割り当てルールに基づいて、経路上に配置することができ、かどうかを判断します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].

帯域幅の予約は、非優先トラフィックよりも簡単にリンクに空き帯域をつかむできるようにすることで、優先トラフィックを優先します。バーク[BUR]は最初の帯域予約モデルの出生、死亡方程式の解から帯域予約の動作を分析しました。バークのモデルは制限を受けている非優先トラフィックに比べて、帯域幅予約の制限を受けないが、好ましいトラフィックに対する相対失われたトラフィックのレベルを示しました。帯域予約保護は、トラフィック変動に対してロバストであり、トラフィックの特定のストリームの有意な動的な保護を提供します。これは、広く[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.

帯域幅予約が異なるCTを横切るリンク帯域幅の共有を制御するために、MARの帯域割当に使用されています。所与のリンク上で、帯域幅（RBW_THRES）の少量（全リンク帯域幅のおそらく1％）予約されており、所定のCTは、その割り当てを下回る帯域幅進行中（RESERVED_BW）を予約した場合、予約帯域幅にアクセスすることができます帯域幅（BC）。これは、利用可能なリンク帯域幅（予約されていないアイドル状態のリンク帯域幅UNRESERVED_BW）がRBW_THRESを超えた場合、その後、任意のCTは、リンク上で利用可能な帯域幅を利用して自由である、です。 UNRESERVED_BWがRBW_THRES未満である場合は、その後、CTは、現在の帯域幅使用量が割り当て量（BC）を下回っている場合にのみ利用可能な帯域幅を利用することができます。利用可能な場合はこの方法では、帯域幅が十分にCTの間で共有することができますが、それがあれば、予約レベル以下の帯域予約により保護されています。

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帯域幅を割り当てることができるかどうかを決定します。例えば、所与のフローにDBWの帯域幅要求の/ LSPは、LERは（高い正常、またはベストエフォート）、CTの使用中の帯域幅、およびCT帯域割当閾値をCT優先順位を決定し、これらのパラメータを使用します容量が割り当て可能な許容負荷状態閾値を決定します。与えられたLSP（例えば、A-B-E）にCTに帯域幅DBWを割り当てることで、経路内の各リンクは、許容負荷状態に比べて、利用可能な帯域幅のためにチェックされます。帯域幅は、パスA-B-Eの任意のリンクを使用できない場合、別のLSPは、-C-D-Eのように、試すことができました。したがって、リンク負荷状態の決意は、MARの帯域割当のために必要であり、2つのリンク負荷状態が区別される：使用可能な（未予約）帯域幅（ABW_STATE）、及び予約帯域幅（RBW_STATE）。 CT容量の管理は、帯域割り当て要求が与えられたCTで受け入れられるかどうかを判断するために、リンク状態と許さ負荷状態のしきい値を使用しています。

A.2. Analysis of MAR Performance

A.2。 MARパフォーマンスの分析

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トラフィックエンジニアリング・シミュレーション・モデルは、ここで異なる優先度クラスを持ついくつかのCTは、マルチサービス、音声/データ統合ネットワークの帯域幅のプールを共有し、使用されています。 MARの方法はまた、時分割多重（すなわち、TDMベースのネットワーク）[ASH1]を使用するネットワークのために実際に分析し、IPベースのネットワーク[ASH2、AsH 3、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),

2. bandwidth efficiency, i.e., good bandwidth sharing among CTs under both normal and overload conditions,

2.帯域幅の効率、すなわち、通常の過負荷状態の両方の下でのCTのうち、良好な帯域幅の共有、

3. bandwidth isolation, i.e., a CT cannot hog the bandwidth of another CT under overload conditions,

前記帯域分離、即ち、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.保護、高優先度の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、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）は、分離を達成することにおいて良好であるため、MAMは魅力的であり、そしてb）それが低いクラスのいくつかの品質劣化との合理的な帯域幅効率を達成します。プリエンプションを使用する場合、それは通常の負荷の下で、帯域幅の効率を達成することができますので、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帯域割り当て方法の私達のパフォーマンス分析は、様々なシナリオとトレードオフ[AsH 3、E.360]を勉強するマルチサービストラフィック需要モデルと組み合わせた全国ネットワークのフルスケール、135ノードのシミュレーションモデルに基づいています。通常の優先順位の声、優先度の高い音声、通常の優先度データ、優先度の高いデータ、およびベストエフォートデータ：トラフィックの優先順位3つのレベル - - 高、標準、およびベストエフォートは5回のCTの間で与えられています。

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.

過負荷および障害が）MAR帯域幅制約モデルを含むための第4、b）は、MAM帯域幅制約モデル、および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

通常の優先度のCT：BCck = PROPORTIONAL_BWk、優先度の高いのCT：BCck = FACTOR X PROPORTIONAL_BWkベストエフォート優先順位のCT：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

通常の優先度のCT：BCck =因数X PROPORTIONAL_BWk、優先度の高いのCT：BCck =因子2 X PROPORTIONAL_BWkベストエフォート優先順位のCT：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の値が過剰に割り当てられた合理的なパフォーマンスを得るためにする必要があります。これは、過剰割り当て（すなわち、因数= 2を設定）100％を、妥当な性能を与えたことが見出されました。

2. The high priority CTs can be over-allocated by a larger multiple FACTOR2 in MAM and this gives better performance.

2.高優先度は、CTSが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.

1 CTは現在、別のCTに割り当てられた帯域幅に侵入することができますので、過剰割り当てのかなり大きな量は、効率が改善されますが、多少のBCモデルに必要な「帯域幅保護/隔離」を破ります。各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帯域幅制約モデルでのCTのいずれにも適用されません。

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)

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

クラスタイプMAR BC MAM BC無DSTE BCモデルモデルモデルNORMAL優先VOICE 0.00 1.97 10.30 HIGH PRIORITY VOICE 0.00 0.00 7.05 NORMAL優先度データ0.00 6.63 13.30 HIGH優先順位データ0.00 0.00 7.05ベストエフォート優先順位データ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が割り当てられている場合は表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)

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

クラスタイプ（因数= 1）（因数= 2）通常優先VOICE 31.69 1.97 HIGH PRIORITY VOICE 0.00 0.00通常優先DATA 31.22 6.63高優先度データ0.00 0.00ベストエフォート優先度データ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.

表4は、50％の一般的な過負荷を有する高日間ネットワーク負荷パターンのMAR、MAM、及び無DSTE帯域幅制約モデルのパフォーマンスを示しています。表に示す数値は、総ネットワーク％が失われた（すなわち、ブロック）またはトラフィックを遅延されます。

                                   Table 4
               Performance Comparison for MAR, MAM, & No-DSTE
                      Bandwidth Constraints (BC) Models
        50% General Overload (Total Network % Lost/Delayed Traffic)

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

クラスタイプMAR BC MAM BC無DSTE BCモデルモデルモデルNORMAL優先VOICE 0.02 0.13 7.98 HIGH PRIORITY VOICE 0.00 0.00 8.94 NORMAL優先度データ0.00 0.26 6.93 HIGH優先順位データ0.00 0.00 8.94ベストエフォート優先順位データ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、及び無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)

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

クラスタイプMAR BC MAM BC無DSTE BCモデルモデルモデルNORMAL優先VOICE 0.00 0.62 0.63 HIGH PRIORITY VOICE 0.00 0.31 0.32 NORMAL優先度データ0.00 0.48 0.50 HIGH優先順位データ0.00 0.31 0.32ベストエフォート優先順位データ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の性能、無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)

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

クラスタイプMAR BC MAM BC無DSTE BCモデルモデルモデルNORMAL優先VOICE 0.00 0.91 0.92 HIGH PRIORITY VOICE 0.00 0.44 0.44 NORMAL優先度データ0.00 0.70 0.72 HIGH優先順位データ0.00 0.44 0.44ベストエフォート優先順位データ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、DSTE-PERF]は単一のリンクの解析モデルを用いて、帯域幅共有およびサービス保護/単離の間のトレードオフを示しています。彼は、RDMがMAMより共有度が高いことを示しています。さらに、単一のリンクについて、全体的な損失確率は、RDMが中間であると、MAM下フル共有下に最小および最大です。したがって、単一のリンク上で、ライは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.

多くのリンクと複数のリンクルーティング経路が存在するネットワークコンテキストを考慮が使用される場合、完全な共有は必ずしも最大、ネットワーク全体の帯域幅効率をもたらさない、本研究の結果。実際には、無DSTEモデルは、ネットワーク全体のスループットを低下させるだけでなく、保護されるべきすべてのCTのパフォーマンスが低下するだけでなく、表4の結果が示します。より多くの帯域幅の共有を許可するとポイントにパフォーマンスアップを改善するかもしれませんが、注意が輻輳の下で割り当てられた帯域幅を保護するために取られていない場合には、パフォーマンスが著しく低下することができます。

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.

ライの研究と異なるCTの間の帯域幅共有の度合いを大きくすると、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.

このように、帯域幅の制約モデルの目的で述べたように、効率的な帯域幅の使用を最大の目的は、注意して行使する必要があります。考慮はまた、異なるCTの間の相互作用の影響を最小限にするために、過負荷の下で帯域幅分離を達成するに付与する必要があります。帯域幅共有および帯域幅の分離の適切なトレードオフは、帯域幅の制約モデルの選択で達成する必要があります。まだ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の劣化に対する帯域幅の分離と保護を提供しながら、帯域幅の共有の効率化をサポートし、安定的かつ効率的なネットワークのパフォーマンスにとって非常に重要です。

Appendix B. Bandwidth Prediction for Path Computation

経路計算のための付録B.帯域幅の予測

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 - プロト]で議論するようにLSPの経路を計算するために予約されていない帯域幅にLSPの影響を予測する際に、ヘッドエンドのための潜在的な利点があります。一例では、複数のパス間で複数の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:

そのような予測は、ヘッドエンドで使用される場合、オプションの帯域幅制約サブTLVと任意最大予約可能帯域幅サブTLVは、IGPでアドバタイズされるかもしれません。これは、LSPが予約されていない帯域幅の値にどのように影響するかを予測するために、ヘッドエンドで使用することができます。セクション2と4で説明したように、このような予測は、IGPによって通知予約されていない帯域幅の値を使用して、MARを用いて作製することができます。

UNRESERVED_BWck = MAX_RESERVABLE_BWk - UNRESERVED_BWk - delta0/1(CTck) * RBW-THRESk

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

delta0 / 1（CTck）= 0の場合RESERVED_BWck <BCck delta0 / 1（CTck）= 1の場合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サブTLV、MAX_RESERVABLE_BWサブTLV、およびUNRESERVED_BWサブ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]ル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

参考文献

[AKI] Akinpelu, J. M., "The Overload Performance of Engineered Networks with Nonhierarchical & Hierarchical Routing," BSTJ, Vol. 63, 1984.

[AKI] Akinpelu、J. M.、 "非階層型＆階層ルーティングで操作ネットワークの過負荷性能、" BSTJ、巻。 63、1984。

[ASH1] Ash, G. R., "Dynamic Routing in Telecommunications Networks," McGraw-Hill, 1998.

[ASH1]アッシュ、G. R.、 "電気通信ネットワークにおけるダイナミックルーティング、" マグロウヒル、1998。

[ASH2] Ash, G. R., et al., "Routing Evolution in Multiservice Integrated Voice/Data Networks," Proceeding of ITC-16, Edinburgh, June 1999.

【ASH2]アッシュ、G. R.、ら。、 "マルチサービス統合音声/データネットワークにおけるルーティングの進化、" ITC-16、エジンバラ、1999年6月の進行。

[ASH3] Ash, G. R., "Performance Evaluation of QoS-Routing Methods for IP-Based Multiservice Networks," Computer Communications Magazine, May 2003.

[AsH 3]アッシュ、G. R.、「IPベースのマルチサービスネットワークにおけるQoSルーティング方式の性能評価、」コンピュータ通信誌、2003年5月。

[BUR] Burke, P. J., Blocking Probabilities Associated with Directional Reservation, unpublished memorandum, 1961.

【BUR】バーク、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]ライ、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]ラング、J.、ら、 "一般化MPLS回復機能的な仕様"、ProgressのWork。

[KRU] Krupp, R. S., "Stabilization of Alternate Routing Networks", Proceedings of ICC, Philadelphia, 1982.

[KRU]クルップ、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.

「MPLS、インターネットのパフォーマンスとネットワークシステムIII会議の制御のためのトラフィック・エンジニアリング」[LAI]ライ、W.、SPIE予稿集。 4865、頁256から267まで、ボストン、マサチューセッツ州、アメリカ、2002年7月29日から8月1日まで。

[MAM] Le Faucheur, F., Lai, W., "Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC 4125, June 2005.

[MAM]ルFaucheur、F.、ライ、W.、 "Diffservの認識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.ら、 "MPLSトラフィックエンジニアリング高速リルート：帯域幅保護用バイパストンネル経路計算"、ProgressのWork。

[MUM] Mummert, V. S., "Network Management and Its Implementation on the No. 4ESS, International Switching Symposium", Japan, 1976.

[MUM] Mummert、V. S.、 "ネットワーク管理および第4ESSにその実現、国際スイッチングシンポジウム"、日本、1976年。

[NAK] Nakagome, Y., Mori, H., Flexible Routing in the Global Communication Network, Proceedings of ITC-7, Stockholm, 1973.

グローバル通信ネットワーク、ITC-7の議事録、ストックホルム、1973年[NAK]中込、Y.、森、H.、柔軟なルーティング。

[OSPF-TE] Katz, D., Kompella, K. and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.

、RFC 3630、2003年9月[OSPF-TE]カッツ、D.、Kompella、K.、およびD.ヨン、 "OSPFバージョン2へのトラフィックエンジニアリング（TE）の拡張"。

[RDM] Le Faucheur, F., Ed., "Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC 4127, June 2005.

[RDM]ルFaucheur、F.、エド。、 "Diffservの認識MPLSトラフィックエンジニアリングのためのロシア人形の帯域幅制約モデル"、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.、バーガー、L.、ガン、D.、李、T.、スリニバサン、V.およびG.ツバメ、 "RSVP-TE：Extensionsが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ローレルアベニューミドルタウン、NJ 07748、USA

Phone: +1 732-420-4578 EMail: gash@att.com

電話：+1 732-420-4578電子メール：gash@att.com

Full Copyright Statement

完全な著作権声明

著作権（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機能のための基金は現在、インターネット協会によって提供されます。