RFC4126 日本語訳
4126 Max Allocation with Reservation Bandwidth Constraints Model forDiffserv-aware MPLS Traffic Engineering & Performance Comparisons. J.Ash. June 2005. (Format: TXT=51232 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Ash Request for Comments: 4126 AT&T Category: Experimental June 2005
コメントを求めるワーキンググループJ.灰の要求をネットワークでつないでください: 4126年のAT&Tカテゴリ: 実験的な2005年6月
Max Allocation with Reservation Bandwidth Constraints Model for
Diffserv-aware MPLS Traffic Engineering & Performance Comparisons
Diffserv意識しているMPLS交通工学とパフォーマンス比較の予約帯域幅規制モデルとのマックスAllocation
Status of This Memo
このメモの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントは、予約(3月)帯域幅Constraints Modelと共にMaximum Allocationのための機能的な仕様を与えることによって、Diffserv意識しているMPLS Traffic Engineering(DS-TE)要件ドキュメントの補足となります。 3月のBandwidth Constraints Modelの操作に関する仮定、適用性、および例は提示されます。 3月の性能はBandwidth Constraints Modelを選択する評価基準に比例して分析されます、それらのネットワークにおける、モデルのユーザ実現に指導を提供するために。
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. 序論…2 1.1. 要件の仕様…3 2. 定義…3 3. 仮定と適用性…5 4. 3月の帯域幅規制モデルの機能的な仕様…6 5. 帯域幅規制を設定します…7 6. 3月の操作に関する例…8 7. 概要…9 8. セキュリティ問題…10 9. IANA問題…10 10. 承認…10 A.3月操作と機能解析…11 経路計算のためのB.帯域幅予測…19 標準の参照…20 有益な参照…20
Ash Experimental [Page 1] RFC 4126 MAR Bandwidth Constraints Model for DS-TE June 2005
実験的な[1ページ]RFC4126 3月の帯域幅規制が2005年6月にDS-Teのためにモデル化する灰
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交通工学(DS-TE)要件とプロトコル拡大は[DSTE-REQ、DSTE-プロト]で指定されます。 DS-TE実現のための要件はDS-TEとの使用のためのBandwidth Constraints Modelsの仕様です。 Bandwidth Constraints Modelは、独特のクラスタイプ(CTs)への帯域幅の配分を支持するために'規則'を提供します。 CTsはDS-TEモデルで、サービスのクラスの組分けです。(別々の帯域幅配分、プライオリティ、およびQoS目的はその組分けに提供されます)。 数個のCTsが統合multiservice 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.
このドキュメントが予約(3月)帯域幅Constraints Modelと共にMaximum Allocationのための機能的な仕様を与えることによってDS-TE要件ドキュメント[DSTE-REQ]の補足となることを意図します。 3月のBandwidth Constraints Modelの操作に関する例は提示されます。 3月の性能はBandwidth Constraints Modelを選択する評価基準に比例して分析されます、それらのネットワークにおける、モデルのユーザ実現に指導を提供するために。
Two other Bandwidth Constraints Models are being specified for use in DS-TE:
他の2Bandwidth Constraints ModelsがDS-TEにおける使用に指定されています:
1. Maximum Allocation Model (MAM) [MAM] - the maximum allowable
bandwidth usage of each CT is explicitly specified.
1. 最大のAllocation Model(MAM)[MAM]--それぞれのコネチカットの最大の許容できる帯域幅用法は明らかに指定されます。
2. Russian Doll Model (RDM) [RDM] - the maximum allowable bandwidth
usage is done cumulatively by grouping successive CTs according to
priority classes.
2. ロシアのDoll Model(RDM)[RDM]--優先権のクラスによると、連続したCTsを分類することによって、累積的に最大の許容できる帯域幅用法をします。
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.
3月は最大の帯域幅配分を各コネチカットに与えるという点においてMAMと同様です。 しかしながら、帯域幅の予約と保護メカニズムの使用で、混雑がない条件のもとで彼らの帯域幅配分を超えていますが、オーバーロードと混雑が起こるとき、CTsはそれらの割り当てられた帯域幅に戻ることができます。
All Bandwidth Constraints Models should meet these objectives:
すべてのBandwidth Constraints Modelsがこれらの目的を満たすはずです:
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の中で共有される良い帯域幅
Ash Experimental [Page 2] RFC 4126 MAR Bandwidth Constraints Model for DS-TE June 2005
実験的な[2ページ]RFC4126 3月の帯域幅規制が2005年6月にDS-Teのためにモデル化する灰
3. bandwidth isolation, i.e., a CT cannot hog the bandwidth of
another CT under overload conditions,
3. すなわち、帯域幅孤立、コネチカットは過負荷条件の下で別のコネチカットの帯域幅をむさぼることができません。
4. protection against QoS degradation, at least of the high-priority
CTs (e.g., high-priority voice, high-priority data, etc.), and
そして4. 少なくとも高優先度CTsのQoS退行(例えば、高い優先権声、高優先度データなど)に対する保護。
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.
Appendix Aでは、Modelがこれらの目的のすべてに会って、良いネットワーク性能を提供するのを3月に示すモデル分析が提示されます、MAMといっぱいに共有しているモデルに比例して、正常で異常な運転条件の下で。 3月が同時に先取りなしで帯域幅効率、帯域幅孤立、および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の3月のBandwidth Constraints Modelの機能的な仕様。 そして、セクション5では、私たちは操作に関する例を出します。 Appendix Aでは、3月の性能はBandwidth Constraints Modelを選択する評価基準に比例して分析されます、それらのネットワークにおける、モデルのユーザ実現に指導を提供するために。 Appendix 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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[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).
交通トランク: 同じクラス(すなわち、DS-TE見解から同等に扱われる)の交通の流れの集合。(クラスはLabel Switched Path(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.
クラスタイプ(コネチカット): 特定の帯域幅規制で治められるリンクを越えるTraffic Trunksのセット。 コネチカットはリンク帯域幅配分、規制ベースのルーティング、および入場コントロールの目的に使用されます。 与えられたTraffic Trunkはすべてのリンクの上の同じコネチカットに属します。
Ash Experimental [Page 3] RFC 4126 MAR Bandwidth Constraints Model for DS-TE June 2005
実験的な[3ページ]RFC4126 3月の帯域幅規制が2005年6月にDS-Teのためにモデル化する灰
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.
最大8CTs(MaxCT=8)が支持されます。 それらはCTcと呼ばれて、c0<=<はMaxCT-1=7と等しいです。 各コネチカットはBandwidth ConstraintかBandwidth Constraintsの1セットのどちらかに配属されます。 最大8Bandwidth Constraints(MaxBC=8)が支持されます、そして、彼らはBCcと呼ばれます、MaxBC-1c0<=<==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クラス: 以下の1組 a) 先取り優先がそのコネチカットに許容したコネチカット、およびb)。 これは、そのコネチカットからTraffic Trunkを輸送して、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].
マックス_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.
予約された_BWck: リンクk(c0<=<はMaxCT-1と等しいです)の上のCTcにおける予約された進行中の帯域幅、RESERVED_BWckはCTcに属すすべての確立したLSPsによって控えられた帯域幅の総量と等しいです。
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)].
予約していない_BWk: リンクkにおける無遠慮なリンク帯域幅はまだどんなコネチカットにも控えられていなかった帯域幅の量を指定します、マックス_RESERVABLE_UNRESERVED_BWk=BWk--[RESERVED_BWck(c0<=<は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
予約していない_BWck: リンクkの上のCTcにおける無遠慮なリンク帯域幅はCTcのためにまだ控えられていなかった帯域幅の量を指定します、UNRESERVED_BWck=UNRESERVED_BWk--delta0/1(CTck)*RBW-THRESk、どこ
delta0/1(CTck) = 0 if RESERVED_BWck < BCck
delta0/1(CTck) = 1 if RESERVED_BWck >= BCck
delta0/1(CTck)=0は予約された_BWck<BCck delta0/1(CTck)であるなら予約された_BWck>がBCckと等しいなら1と等しいです。
Ash Experimental [Page 4] RFC 4126 MAR Bandwidth Constraints Model for DS-TE June 2005
実験的な[4ページ]RFC4126 3月の帯域幅規制が2005年6月にDS-Teのためにモデル化する灰
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の調査中の多くの回収機構がLSPsの特定のセットの向こう側に共有される帯域幅の概念を利用します。 [GMPLS-RECOV]の「共有されたMesh王政復古」と[MPLS-BACKUP]の「施設のベースのComputation Model」は独立している失敗から守るバックアップLSPsの向こう側に帯域幅を共有することによって帯域幅効率を増加させる例のメカニズムです。 [DSTE-REQ]で導入されたRESERVED_BWckの概念は複数のLSPsの向こう側に共有される帯域幅のそのような概念と互換性があるのを保証するために、[DSTE-REQ]に提供された定義の言葉遣いは広められます。 この一般化について、定義は[GMPLS-RECOV]で定義されるShared Mesh王政復古と互換性があります、DS-TEとShared Mesh Protectionが同時に作動できるように、Shared Mesh王政復古は各DS-TE Class-タイプの中で独自に作動して、Class-タイプの向こう側に作動しないという仮定で。 例えば、また、CTcの第一のLSPsを保護するバックアップLSPsは、CTcに属す必要があります。 また、CTcのバックアップLSPsと帯域幅を共有する過剰交通LSPsは、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は様々なCTs(例えば、声、正常なデータ、ベストエフォート型データ)に割り当てられた異なったクラスの交通への帯域幅配分メカニズムです。 容量デザインや、帯域幅配分や、ルーティングデザインや、ネットワーク計画などのネットワーク操作機能は、通常、交通で測定された負荷に基づいていて、予測されます[ASH1]。
As such, the following assumptions are made according to the operation of MAR:
そういうものとして、3月の操作に従って、以下の仮定はされます:
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)はネットワーク流れ/LSPsのために帯域幅を割り当てます、トラフィック測定と予測に基づいて。
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単位で1流れあたりの帯域幅を割り当てることができるでしょう。 すなわち、どんな特定の仮定も特定のCAC方法に関してされません、コネチカットの帯域幅配分が測定されたか予測されたトラヒック負荷に関連するのを除いて、仮定#1に従って。
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. コネチカットの帯域幅配分は、トラヒック負荷を調整されるか、測定されるのに従って倒すか、または予測します。 それは、どんな特定の期間もこの調整のために想定されないか、短い期間(秒、数分、何時間も)、毎日、毎週月毎である、またはそうでないかもしれません。
Ash Experimental [Page 5] RFC 4126 MAR Bandwidth Constraints Model for DS-TE June 2005
実験的な[5ページ]RFC4126 3月の帯域幅規制が2005年6月にDS-Teのためにモデル化する灰
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. 容量管理とコネチカット帯域幅配分敷居(例えば、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. 仮定は全く交通が様々なCTsに割り当てられるオーダーのときにされません。 一方、それが測定される、そして/または、予測されるので交通配分によってトラヒック負荷だけに基礎づけられると思われます。
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. リンク帯域幅が流れ/LSP/交通トランクのための与えられた経路で消耗しているなら、代替パスは、コネチカットの帯域幅配分を満たすために試みられるかもしれません。
Note that the above assumptions are not unique to MAR, but are generic, common assumptions for all BC Models.
上の仮定が3月にユニークではありませんが、すべての紀元前Modelsのための一般的で、一般的な仮定であることに注意してください。
4. Functional Specification of the MAR Bandwidth Constraints Model
4. 3月の帯域幅規制モデルの機能的な仕様
A DS-TE Label Switching Router (LSR) that implements MAR MUST support enforcement of bandwidth constraints, in compliance with the specifications in this section.
3月を実行するDS-TE Label Switching Router(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.
3月のBandwidth Constraints Modelでは、各コネチカットへの帯域幅配分コントロールはリンクのおよそ帯域幅の必要性、帯域幅使用、および状態に基づいています。 (LER)が作るLabel Edge Routerは、リンク帯域幅をコネチカットに割り当てることができるかどうか決定するのに帯域幅配分変化を必要として、例えば、[RSVP-TE]を使用します。 個々のCTsに割り当てられた帯域幅は必要に応じて保護されますが、さもなければ、それは共有されます。 正常で、非混雑しているネットワーク条件のもとでは、すべてのCTs/サービスがすべての利用可能な帯域幅を完全に共有します。 混雑が特定のCTcのために起こると、帯域幅の予約は、CTcのために割り当てられた容量を捕らえるので、他のCTsから交通を禁じます。
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が割り当てられた帯域幅規制(BCck)の下で中の帯域幅使用(RESERVED_BWck)を持っていると、リンク(RBW_THRESk)における予約帯域幅にアクセスできます。 しかしながら、RESERVED_BWckが割り当てられた帯域幅規制(BCck)を超えているなら、予約帯域幅(RBW_THRESk)にアクセスできません。 このように、帯域幅は、CTsの中で完全に共有されていますが、利用可能である場合がありますが、別の方法で帯域幅予約方法で保護されます。
Ash Experimental [Page 6] RFC 4126 MAR Bandwidth Constraints Model for DS-TE June 2005
実験的な[6ページ]RFC4126 3月の帯域幅規制が2005年6月にDS-Teのためにモデル化する灰
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: Admitting LSP Bandwidth Requestのための規則はLink kでDBWと等しいです。
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;
_予約されるなら、BWck<はBCckと等しいです: DBW<がUNRESERVED_BWk If RESERVED_BWck>BCckと等しいなら、認めてください: 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は利用可能なリンク帯域幅です。
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.
セットアップの正常な意味論と優位に立つのは3月のBandwidth Constraints Modelで適用されます、そして、先取りが可能にされるとき、交差しているコネチカットの先取りは受入れられます。
The bandwidth allocation rules defined in Table 1 are illustrated with an example in Section 6 and simulation analysis in Appendix A.
例がセクション6にあって、シミュレーション分析がAppendix Aにある状態で、Table1で定義された帯域幅配分規則は例証されます。
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)に比例して最大の予約可能帯域幅(マックス_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マックス_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:
高優先度コネチカット、帯域幅規制BCckには、比例している帯域幅の倍数へのセットがあります。 それは以下の通りです。
For high priority CTc: BCck = FACTOR X PROPORTIONAL_BWck
高優先度CTcのために: BCckは要素の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
FACTORが比例している帯域幅の倍数に用意ができている(例えば、FACTOR=2か3は典型的です)ところ。 これは、最大の予約可能帯域幅のいくつかの'過剰配分'をもたらして、優先的に取り扱います。
Ash Experimental [Page 7] RFC 4126 MAR Bandwidth Constraints Model for DS-TE June 2005
実験的な[7ページ]RFC4126 3月の帯域幅規制が2005年6月にDS-Teのためにモデル化する灰
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.
高優先度CTsに。 通常、高優先度CTsに割り当てられた帯域幅は総リンク帯域幅の比較的わずかな部分であるはずです、妥当なガイドラインである最大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
6. 3月の操作に関する例
In the example, assume there are three class-types: CT0, CT1, CT2. We consider a particular link with
例では、3つのクラスタイプがあると仮定してください: CT0、CT1、CT2。 私たちは、事項がリンクすると考えます。
MAX-RESERVABLE_BW = 100
マックスRESERVABLE_BW=100
And with the allocated bandwidth constraints set as follows:
そして、割り当てられた帯域幅で、規制は以下の通りセットしました:
BC0 = 30 BC1 = 20 BC2 = 20
20 30BC0=BC1=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で議論するように正常なトラヒック負荷に基づいています。 3月と共に、CTsのいずれも少なくともRBW_THRES(リンクの予約帯域幅敷居)ユニットの予備帯域幅の残りである長いaとして帯域幅規制(BCc)を超えることができます。 仮定になろう
RBW_THRES = 10
RBW_THRES=10
So under overload, if
したがって、オーバーロードの下で
RESERVED_BW0 = 50 RESERVED_BW1 = 30 RESERVED_BW2 = 10
予約された_BW0=50は30の予約された__BW1=BW2=10を予約しました。
Therefore, for this loading
したがって、このローディング
UNRESERVED_BW = 100 - 50 - 30 - 10 = 10
無遠慮な_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はもうリンクにおけるそれらの帯域幅を増加させることができません、彼らがそれらの紀元前の値を超えていて、RBW_THRES=10ユニットの予備帯域幅だけがリンクの上に残っているので。 しかし、需要が到着するなら、CT2は追加帯域幅(最大10ユニット)を取ることができます、それが紀元前の値の下にあるので。
Ash Experimental [Page 8] RFC 4126 MAR Bandwidth Constraints Model for DS-TE June 2005
実験的な[8ページ]RFC4126 3月の帯域幅規制が2005年6月にDS-Teのためにモデル化する灰
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が5つの帯域幅(すなわち、DBW=5)を必要とするCT0のために到着すると言いましょう。 私たちは、Table1に基づいてこのLSPを認めるかどうか決める必要があります。 CT0のために
RESERVED_BW0 > BC0 (50 > 30), and DBW > UNRESERVED_BW - RBW_THRES (i.e., 5 > 10 - 10)
_BW0>BC0(50>30)、およびDBWの>の予約していない_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
今、LSPが5つの帯域幅(すなわち、DBW=5)を必要とするCT2のために到着すると言いましょう。 私たちは、Table1に基づいてこのLSPを認めるかどうか決める必要があります。 CT2のために
RESERVED_BW2 < BC2 (10 < 20), and DBW < UNRESERVED_BW (i.e., 5 < 10)
予約された_BW2<BC2(10<20)、およびDBWの<の予約していない_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.
したがって、上記の例、リンクの現状、および現在のコネチカットのローディングでは、CT0とCT1はもうリンクにおけるそれらの帯域幅を増加させることができません、彼らがそれらのBCc値を超えていて、RBW_THRES=10ユニットの予備帯域幅だけがリンクの上に残っているので。 しかし、需要が到着するなら、CT2は追加帯域幅(最大10ユニット)を取ることができます、それがBCc値の下にあるので。
7. Summary
7. 概要
The proposed MAR Bandwidth Constraints Model includes the following:
提案された3月のBandwidth Constraints Modelは以下を含んでいます:
1. allocation of bandwidth to individual CTs,
1. 個々のCTsへの帯域幅の配分
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
Appendix Aに提示されたモデル結果は、3月の帯域幅配分がまだQoSに対する帯域幅孤立と保護を提供している間、共有しながら帯域幅にa)の、より大きい効率を実現するのを示します。
Ash Experimental [Page 9] RFC 4126 MAR Bandwidth Constraints Model for DS-TE June 2005
実験的な[9ページ]RFC4126 3月の帯域幅規制が2005年6月にDS-Teのためにモデル化する灰
degradation, and b) service differentiation for high-priority, normal-priority, and best-effort priority services.
退行、および高い優先度、正常な優先権、およびベストエフォート型優先サービスのための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-プロト]でDS-TEの使用に関連するセキュリティ問題について議論します。 彼らは本書では指定された3月を含むBandwidth Constraints Modelの如何にかかわらず適用します。
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-プロト]は、「帯域幅規制はイドをモデル化する」ために新しい名前スペースを定義します。 その名前スペースでの値の配分のためのガイドラインは[DSTE-プロト]のセクション13.1で詳細です。 これらのガイドラインによると、IANAは範囲0-239(「仕様が必要である」という[IANA-コンズ]で定義された方針に従って管理されることになっています)からの3月にBandwidth Constraints Model Idを割り当てました。
Bandwidth Constraints Model Id 2 was allocated by IANA to MAR.
帯域幅Constraints Model Id2は3月まで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とBandwidth Constraints ModelsはTEWGでの議論の活動領域です。 彼のこのドキュメントのサポートとレビューについてWai Sumレイに感謝申し上げます。 また、私はフランソアLe Faucheurとの役立つ議論に感謝します。
Ash Experimental [Page 10] RFC 4126 MAR Bandwidth Constraints Model for DS-TE June 2005
実験的な[10ページ]RFC4126 3月の帯域幅規制が2005年6月にDS-Teのためにモデル化する灰
Appendix A. MAR Operation & Performance Analysis
付録A.3月の操作と機能解析
A.1. MAR Operation
A.1。 3月の操作
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.
3月のBandwidth Constraints Modelでは、各コネチカットへの帯域幅配分コントロールはリンクのおよそ帯域幅の必要性、帯域幅使用、および状態に基づいています。 LERは、リンク帯域幅をコネチカットに割り当てることができるかどうか決定するのに必要な帯域幅配分変更を行って、例えば、[RSVP-TE]を使用します。 個々のCTsに割り当てられた帯域幅は必要に応じて保護されますが、さもなければ、それは共有されます。 正常で、非混雑しているネットワーク条件のもとでは、すべてのCTs/サービスがすべての利用可能な帯域幅を完全に共有します。 混雑が特定のCTcのために起こると、帯域幅の予約は、CTcのために割り当てられた容量を捕らえるので他のCTsから交通を禁じるために行動します。 各コネチカットに関連づけられているのは、帯域幅配分と保護を治める割り当てられた帯域幅規制(BCc)です。 例がこのAppendixにある状態で、これらのパラメタは例証されます。
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のために3月の帯域幅配分を実行する際に、LERは最初に、出口LSRアドレス、サービスアイデンティティ、およびコネチカットを決定します。 特定のコネチカットで発送されるために同等な帯域幅を接続要求に割り当てます。 LERは、次に、LERと出口LSRの間でコネチカット優先権、QoS/交通パラメタ、および経路指定テーブルにアクセスして、3月の帯域幅配分規則を使用することで接続要求をセットアップします。 LERは、最初に、選択経路を選択して、セクション4で与えられた3月の帯域幅配分規則に基づく経路に帯域幅を割り当てることができるかどうか決定します。 最初の特選している経路に不十分な帯域幅があるなら、LERは次に、代替パスを試みるかもしれなくて、再び現在説明されている3月の帯域幅配分規則を適用します。
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.
総合的なコネチカットのサービスの帯域幅要件が必要とする1コネチカットあたり1個のベースで3月の帯域幅配分をします。(集められたコネチカット帯域幅は、会うためにそれで管理されます)。 コネチカット帯域幅の有用性に応じて、個々の流れ/LSPsに対応するコネチカットの帯域幅を割り当てます。 3月の帯域幅配分方法で適用された原理は帯域幅予約のテクニックの使用です。
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
非都合のよい交通より容易にリンクにおける活動していない帯域幅を差押えるのを許容することによって、帯域幅の予約は都合のよい交通に優先を与えます。 バーク[BUR]は最初に、帯域幅予約モデルのために出生死亡方程式の解決から帯域幅予約の振舞いを分析しました。 バークのモデルは相対的な無くなっている交通レベルを都合のよい交通に案内しました、非都合のよい交通(制限を受けることがある)と比べて。(交通は帯域幅予約制限を受けることがありません)。 帯域幅予約保護は、交通変化に強健であり、提供されます。
Ash Experimental [Page 11] RFC 4126 MAR Bandwidth Constraints Model for DS-TE June 2005
実験的な[11ページ]RFC4126 3月の帯域幅規制が2005年6月にDS-Teのためにモデル化する灰
significant dynamic protection of particular streams of traffic. It is widely used in large-scale network applications [ASH1, MUM, AKI, KRU, NAK].
交通の特定の流れの重要なダイナミックな保護。 それは大規模なネットワーク応用[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.
帯域幅の予約は、異なったCTsの向こう側にリンク帯域幅を共有しながら制御するのに3月の帯域幅配分に使用されます。 与えられたリンクでは、少量の帯域幅(RBW_THRES)が予約されています、そして、(総リンク帯域幅の恐らく1%)与えられたコネチカットが割り当てられた帯域幅(紀元前)の下の進行中の帯域幅(RESERVED_BW)を控えたとき、予約帯域幅にアクセスできます。 すなわち、利用可能なリンク帯域幅(無遠慮な活動していないリンク帯域幅UNRESERVED_BW)がRBW_THRESを超えているなら、どんなコネチカットも自由にリンクにおける利用可能な帯域幅にアクセスできます。 しかしながら、UNRESERVED_BWがRBW_THRES以下であるなら、現在の帯域幅用法が割り当てられた量(紀元前)を下回っている場合にだけ、コネチカットは利用可能な帯域幅を利用できます。 予約レベルの下でこのように、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.
また、帯域幅予約メカニズムを通して、3月の帯域幅配分は正常な優先権とベストエフォート型優先権CTsとの比較で高優先度CTsに優先を与えます。
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.
したがって、各コネチカットに割り当てられた帯域幅は、必要に応じて帯域幅予約方法で保護されますが、別の方法で共有されます。 各LERは、各コネチカットでコネチカットの帯域幅使用をモニターして、コネチカット帯域幅に接続要求を割り当てることができるかどうか決定します。 例えば、与えられた流れ/LSPにおけるDBWの帯域幅要求のためのLERは、コネチカット優先権(高いか、正常であるか、またはベストエフォート型の)、使用中のコネチカット帯域幅、およびコネチカット帯域幅配分敷居を決定して、容量を割り当てることができる許容負荷州の敷居を決定するのにこれらのパラメタを使用します。 与えられたLSP(例えば、A B E)に帯域幅DBWをコネチカットに割り当てる際に、経路の各リンクは比較における利用可能な帯域幅がないかどうか許容負荷状態にチェックされます。 帯域幅がどんなリンクでも経路A B Eで入手できないなら、別のLSPはA C D Eなどのように試みられるかもしれません。 したがって、リンク・ロード状態の決断が3月の帯域幅配分に必要です、そして、2つのリンク・ロード州が顕著です: 利用可能な(非予約された)帯域幅(ABW_州)、および予約された帯域幅(RBW_州)。 コネチカットの管理容量は、与えられたコネチカットで帯域幅配分要求を受け入れることができるかどうか決定するのにリンク状態と許容負荷州の敷居を使用します。
A.2. Analysis of MAR Performance
A.2。 3月のパフォーマンスの分析
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
このAppendixでは、どの3月の帯域幅配分が良いネットワーク性能を提供するために示されるかでモデル分析は提示されます、完全な共有しているモデルに比例して、正常で異常な運転条件の下で。 大規模なDiffserv意識しているMPLS交通工学シミュレーションモデルはどの数個のCTsで異なることで使用されるか。
Ash Experimental [Page 12] RFC 4126 MAR Bandwidth Constraints Model for DS-TE June 2005
実験的な[12ページ]RFC4126 3月の帯域幅規制が2005年6月にDS-Teのためにモデル化する灰
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].
優先権のクラスはマルチサービスにおける帯域幅のプール、統合声/データ網を共有します。 また、3月の方法は時分割多重化(すなわち、TDMを拠点とするネットワーク)[ASH1]を使用するネットワークのための習慣と、IP接続を基本にしたネットワーク[ASH2、ASH3、E.360]のために研究をモデル化する際に分析されました。
All Bandwidth Constraints Models should meet these objectives:
すべてのBandwidth Constraints Modelsがこれらの目的を満たすはずです:
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. すなわち、帯域幅孤立、コネチカットは過負荷条件の下で別のコネチカットの帯域幅をむさぼることができません。
4. protection against QoS degradation, at least of the high-priority
CTs (e.g., high-priority voice, high-priority data, etc.), and
そして4. 少なくとも高優先度CTsのQoS退行(例えば、高い優先権声、高優先度データなど)に対する保護。
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.
どんな与えられたBandwidth Constraints Modelの使用も後で説明されるように重要な影響をネットワークの性能に与えます。 したがって、評価基準は以前はよく私たちが特定のモデルがどう性能を提供するかを評価するのを可能にするモデルの必要性を選択していました、他のモデルに比例して。 レイ[レイ、DSTE-PERF]は、MAMとRDM Modelsを分析して、様々なネットワーク条件のもとでこれらのモデルの相対的パフォーマンスに貴重な洞察を提供しました。
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) それは労働者階級のいくらかのQoS退行を伴う妥当な帯域幅効率を達成します。 先取りが使用されているとき、正常な負荷の下で帯域幅効率を達成できるので、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.
私たちの3月の帯域幅配分方法の機能解析は様々なシナリオと見返り[ASH3、E.360]を研究するためにマルチサービス交通需要モデルに合併された全国的なネットワークの実物大の、そして、135ノードのシミュレーションモデルに基づいています。 5CTsの向こう側に3つのレベルの交通優先(高いのと、正常で、ベストエフォート型である)を与えます: 標準の優先権声、高い優先権声、正常な優先権データ、高い優先権データ、およびベストエフォート型データ。
Ash Experimental [Page 13] RFC 4126 MAR Bandwidth Constraints Model for DS-TE June 2005
実験的な[13ページ]RFC4126 3月の帯域幅規制が2005年6月にDS-Teのためにモデル化する灰
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) 3月のBandwidth Constraints Modelを含んでいます、b) MAM Bandwidth Constraints Modelにもかかわらず、c) セクション4、どんなDSTE Bandwidth Constraints Modelでも指定されないように。
The allocated bandwidth constraints for MAR are described in Section 5 as:
3月の割り当てられた帯域幅規制はセクション5で以下と説明されます。
Normal priority CTs: BCck = PROPORTIONAL_BWk, High priority CTs: BCck = FACTOR X PROPORTIONAL_BWk Best-effort priority CTs: BCck = 0
正常な優先権CTs: BCckはPROPORTIONAL_BWk、High優先権CTsと等しいです: BCckはFACTOR XのPROPORTIONAL_BWk Best-努力優先権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 Bandwidth Constraints Modelでは、それぞれのコネチカットの帯域幅規制は比例している帯域幅配分の倍数に設定されます:
Normal priority CTs: BCck = FACTOR1 X PROPORTIONAL_BWk, High priority CTs: BCck = FACTOR2 X PROPORTIONAL_BWk Best-effort priority CTs: BCck = 0
正常な優先権CTs: BCckはFACTOR1X PROPORTIONAL_BWk、High優先権CTsと等しいです: BCckはFACTOR2XのPROPORTIONAL_BWk Best-努力優先権CTsと等しいです: BCck=0
Simulations show that for MAM, the sum (BCc) should exceed MAX_RESERVABLE_BWk for better efficiency, as follows:
シミュレーションは、MAMに関して、合計(BCc)が、より良い効率のために以下の通りマックス_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. 正常な優先権CTsとBCc値は、妥当な性能を得るために割り当てられ過ぎる必要があります。 それは、そんなに割り当て過ぎるのが100%によって見つけられて(すなわち、FACTOR1=2を設定します)、妥当な性能を与えました。
2. The high priority CTs can be over-allocated by a larger multiple
FACTOR2 in MAM and this gives better performance.
2. MAMとこれのFACTOR2が、より良いパフォーマンスを行うより大きい倍数で高優先度CTsを割り当て過ぎることができます。
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.
かなり多量の過剰配分が、能率を増進しますが、紀元前で必要である'帯域幅保護/孤立'Modelをいくらか破ります、1コネチカットが今別のコネチカットに割り当てられた帯域幅に侵入できるので。 各コネチカットは割り当てられた帯域幅規制BCckに制限されます、MAMの通常の操作のように。(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 Bandwidth Constraints Modelでも、コネチカット帯域幅の予約でない保護がないのが適用されていません、そして、帯域幅が利用可能であるなら、帯域幅配分要求は認められます。 その上、優先権を列に並ばせるのはDSTE Bandwidth Constraints Modelでないところの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
テーブル2は6回のオーバーロードのためにOakbrook、イリノイのただ一つのネットワーク・ノードで性能結果を与えます。 テーブルで与えられた数はパーセントが失ったか(すなわち、妨げられます)、または遅らせた総ネットワークです。
Ash Experimental [Page 14] RFC 4126 MAR Bandwidth Constraints Model for DS-TE June 2005
実験的な[14ページ]RFC4126 3月の帯域幅規制が2005年6月にDS-Teのためにモデル化する灰
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.
交通。 ここで研究された集中しているオーバーロードシナリオではOakbrookノードにおける無くなっているか遅れた交通の百分率が与えられたネットワーク全体の平均値よりはるかに高いことに注意してください。
Table 2
Performance Comparison for MAR, MAM, & No-DSTE
Bandwidth Constraints (BC) Models
6X Focused Overload on Oakbrook
(Total Network % Lost/Delayed Traffic)
テーブル2 3月、MAM、およびDSTEがない帯域幅規制(紀元前)のためのパフォーマンス比較は6Xの集中しているオーバーロードをOakbrookに似せます。(総ネットワーク%は、交通を失ったか、または遅らせました)
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
高高クラスのモデルのモデルのモデルの標準の優先権タイプ3月の紀元前のMAM紀元前のDSTEがない紀元前の声0.00 1.97 10.30の優先権声0.00 0.00 7.05の正常な優先権データ0.00 6.63 13.30優先権データ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.
明確に、性能は3月の帯域幅配分によって良いです、そして、結果は帯域幅の予約が使用されているとき、性能が向上するのを示します。 DSTE Modelがない不十分な性能の理由は割り当てられた帯域幅の保護の不足の帯域幅の予約がなければためです。 私たちが帯域幅予約メカニズムを加えるなら、ネットワークの性能は大いに向上します。
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の性能が上で議論した過剰割当係数にかなり敏感であることを示しました。 例えば、FACTOR1=1と共にBCc値を比例して割り当てるなら、結果ははるかに悪いです、Table3に示されるように:
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帯域幅規制が異なった過剰割当係数6Xと共にモデル化されるので、パフォーマンス比較は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
クラスは高高標準の優先権声31.69 1.97の優先権声0.00 0.00の正常な優先権データ31.22 6.63優先権データ0.00 0.00のベストエフォート型優先権データ8.76 11.92をタイプします(FACTOR1=1)(FACTOR1=2)。
Ash Experimental [Page 15] RFC 4126 MAR Bandwidth Constraints Model for DS-TE June 2005
実験的な[15ページ]RFC4126 3月の帯域幅規制が2005年6月にDS-Teのためにモデル化する灰
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%の一般的なオーバーロードでMAMにもかかわらず、3月、DSTE Bandwidth Constraints Modelsがない性能を例証します。 テーブルで与えられた数は総ネットワークパーセントが交通を失ったか(すなわち、妨げられます)、または遅らせたということです。
Table 4
Performance Comparison for MAR, MAM, & No-DSTE
Bandwidth Constraints (BC) Models
50% General Overload (Total Network % Lost/Delayed Traffic)
テーブル4 3月、MAM、およびDSTEがない帯域幅規制(紀元前)のためのパフォーマンス比較は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
高高クラスのモデルのモデルのモデルの標準の優先権タイプ3月の紀元前のMAM紀元前のDSTEがない紀元前の声0.02 0.13 7.98の優先権声0.00 0.00 8.94の正常な優先権データ0.00 0.26 6.93優先権データ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.
一方、私たちは、3月の帯域幅配分であるときに、性能がいつもより良いのを見ることができます、そして、予約は使用されています。
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はただ一つのリンク失敗シナリオ(3OC-48)のためにMAMにもかかわらず、3月、DSTE Bandwidth Constraints Modelsがない性能を例証します。 テーブルで与えられた数は総ネットワークパーセントが交通を失ったか(妨げられます)、または遅らせたということです。
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 3月、MAM、およびDSTEがない帯域幅規制(紀元前)のためのパフォーマンス比較はただ一つのリンクの故障(2OC-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
高高クラスのモデルのモデルのモデルの標準の優先権タイプ3月の紀元前のMAM紀元前のDSTEがない紀元前の声0.00 0.62 0.63の優先権声0.00 0.31 0.32の正常な優先権データ0.00 0.48 0.50優先権データ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.
一方、私たちは、3月の帯域幅配分であるときに、性能がいつもより良いのを見ることができます、そして、予約は使用されています。
Ash Experimental [Page 16] RFC 4126 MAR Bandwidth Constraints Model for DS-TE June 2005
実験的な[16ページ]RFC4126 3月の帯域幅規制が2005年6月にDS-Teのためにモデル化する灰
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は3月の性能を例証します、MAMにもかかわらず、倍数のためのDSTE Bandwidth Constraints Modelsがないリンク失敗シナリオ(それぞれ3OC-48、3OC-3、4OC-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 3月、MAM、およびDSTEがない帯域幅規制(紀元前)のためのパフォーマンス比較は複数のリンクの故障(それぞれ2OC-48、2OC-12、1OC-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
高高クラスのモデルのモデルのモデルの標準の優先権タイプ3月の紀元前のMAM紀元前のDSTEがない紀元前の声0.00 0.91 0.92の優先権声0.00 0.44 0.44の正常な優先権データ0.00 0.70 0.72優先権データ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.
一方、私たちは、3月の帯域幅配分であるときに、性能がいつもより良いのを見ることができます、そして、予約は使用されています。
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.
レイの結果[レイ、DSTE-PERF]は帯域幅共有とサービス保護/孤立の間のトレードオフを示しています、単一のリンクの分析的なモデルを使用して。 彼は、RDMにはMAMより高度の共有があるのを示します。 その上、単一のリンクに関して、総合損失確率は、完全な共有で最もわずかであって、MAMの下で最も大きいです、RDMが中間的に。 したがって、単一のリンクの上では、レイは、完全な共有しているモデルが最も高いリンク効率をもたらすのを示します、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.
現在の研究の結果は、多くのリンクがあるネットワーク背景と複数のリンクルーティング経路が使用されていると考えるとき、完全な共有が必ず最大の、そして、ネットワーク全体の帯域幅効率に通じるというわけではないのを示します。 事実上、Table4の結果は、どんなDSTE Modelも総ネットワークスループットを下げるだけではなく、保護されるべきであるあらゆるコネチカットの性能を下げもしないのを示します。 より多くの帯域幅共有を許すと、性能はある程度向上するかもしれませんが、混雑の下の割り当てられた帯域幅を保護するために注意しないなら、それは厳しく性能を下げることができます。
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.
レイの研究とこの研究の両方が、異なったCTsの中で共有される帯域幅の度合いを増加させるのがCTsの間の、よりきついカップリングに通じるのを示します。 正常な荷重条件で、各コネチカットには適切な容量があります。(それは、そのようなカップリングの効果を最小にします)。
Ash Experimental [Page 17] RFC 4126 MAR Bandwidth Constraints Model for DS-TE June 2005
実験的な[17ページ]RFC4126 3月の帯域幅規制が2005年6月にDS-Teのためにモデル化する灰
Under overload conditions, when there is a scarcity of capacity, such coupling can cause severe degradation of service, especially for the lower priority CTs.
容量への不足があるとき、過負荷条件の下では、そのようなカップリングは厳しいサービスの退行を引き起こす場合があります、特に低優先度CTsのために。
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.
したがって、Bandwidth Constraints Model目的で述べられているように効率的な帯域幅用法を最大にする目的は、慎重に運動させられる必要があります。 また、当然の考慮は、オーバーロードの下で帯域幅孤立を達成するのに与えられている必要があります、異なったCTsの中で相互作用の効果を最小にするために。 帯域幅共有と帯域幅孤立の適切な見返りは、Bandwidth Constraints Modelの選択で達成される必要があります。 帯域幅の予約はまだ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.
概要では、提案された3月のBandwidth Constraints Modelは以下を含んでいます: a) 必要に応じて、しかし、そうでなければ、いっぱいに、帯域幅の共有、高い優先度と、正常な優先権と、最も良い努力優先サービスの間のc)分化、および入場のd)支給は接続要求を拒絶するために制御されます、必要であると、個々のCTsへの帯域幅の配分、帯域幅予約方法による割り当てられた帯域幅のb)保護、パフォーマンス目標を満たすために。
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:
モデル結果では、3月のBandwidth Constraints Modelは帯域幅の予約を使用しない方法で勝るとも劣らないです。 モデルからの結論のいくつかは特に、以下の通りです:
o MAR bandwidth allocation is effective in improving performance over
methods that lack bandwidth reservation; this allows more bandwidth
sharing under congestion.
o 3月の帯域幅配分は帯域幅の予約を欠いている方法の上の性能を向上させるのにおいて有効です。 これは混雑で共有されるより多くの帯域幅を許容します。
o MAR achieves service differentiation for high-priority, normal-
priority, and best-effort priority services.
o 3月は高い優先度、正常な優先権、およびベストエフォート型優先サービスのためのサービス分化を達成します。
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退行に対して、より大きい効率を支持して、安定して効率的なネットワーク性能に重要です。
Ash Experimental [Page 18] RFC 4126 MAR Bandwidth Constraints Model for DS-TE June 2005
実験的な[18ページ]RFC4126 3月の帯域幅規制が2005年6月にDS-Teのためにモデル化する灰
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.
LSPの経路を計算するために無遠慮な帯域幅でLSPの衝撃を予測するとき、[DSTE-プロト]で議論するように、潜在的利点がHead-終わりの間、あります。 1つの例は複数の経路の向こう側に複数のLSPsの、より良い負荷分配を実行するだろうことです。 別の例は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:
そのような予測がHead-終わり、任意のBandwidth ConstraintsサブTLV、および任意のMaximum Reservable BandwidthサブTLV MAYで使用されるところでは、IGPに広告を出してください。 LSPがどう無遠慮な帯域幅値に影響するかを予測するのにHead-終わりでこれを使用できます。 3月と共にIGPによって広告に掲載された無遠慮な帯域幅値を使用することによって、そのような予測をすることができます、セクション2と4で議論するように:
UNRESERVED_BWck = MAX_RESERVABLE_BWk - UNRESERVED_BWk -
delta0/1(CTck) * RBW-THRESk
無遠慮な_BWck=マックス_RESERVABLE_BWk--予約していない_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は予約された_BWck<BCck delta0/1(CTck)であるなら予約された_BWck>がBCckと等しいなら1と等しいです。
Furthermore, the following estimate can be made for RBW_THRESk:
その上、RBW_THRESkのために以下の見積りをすることができます:
RBW_THRESk = RBW_% * MAX_RESERVABLE_BWk,
RBW_THRESkはRBW_% *マックス_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_%が異なったリンク速度のために異価を呈することができた局所的に構成された変数であるところ。 マックス_RESERVABLE_BWサブTLV、紀元前サブTLVに関連してこの情報を使用できました、そして、それぞれにおける利用可能な帯域幅の予測をするためにはサブTLVのUNRESERVED_BWは各コネチカットにリンクします。 入場コントロールアルゴリズムが業者分化に残されるので、Head-終わりのLSR予測が他のLSRsによって使用された同じ(または、まさしくその閉鎖)入場コントロールアルゴリズムに基づいているときだけ、有効に予測を実行できます。
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.
ギヤエンドが普通リンクを通してLSPsを設立しているとき、LSPsは時折拒絶されるかもしれません。 例として、あるリンクL、および2個のギヤエンドがH1とH2であると考えてください。 H1だけかH2だけがLを通してLSPsを設立しているなら、予測は正確です。 しかし、H1とH2の両方が同時にLを通してLSPsを設立するなら、予測は完全に働いていないでしょう。 言い換えれば、CACは時折そのような'レース'状態とのリンクの上の拒絶されたLSPを出くわすでしょう。 また、Appendix Aで言及されるように、そのような予測も、任意であり、ドキュメントの範囲の外で言及されます。
Ash Experimental [Page 19] RFC 4126 MAR Bandwidth Constraints Model for DS-TE June 2005
実験的な[19ページ]RFC4126 3月の帯域幅規制が2005年6月にDS-Teのためにモデル化する灰
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.レイ、「微分されたサービス意識しているMPLS交通工学のサポートのための要件」、RFC3564、2003年7月。
[DSTE-PROTO] Le Faucheur, F., Ed., "Protocol Extensions for Support
of Diffserv-aware MPLS Traffic Engineering," RFC 4124,
June 2005.
[DSTE-プロト] Le Faucheur、F.、エド「Diffserv意識しているMPLS交通のサポートのためのプロトコル拡大は設計すること」でのRFC4124、2005年6月。
[RFC2119] Bradner, S., "Key words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsのUseのためのキーワード」、BCP14、RFC2119、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-まやかし]Narten、T.、およびH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」、BCP26、RFC2434(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.、「Nonhierarchicalと階層型ルーティングとの設計されたネットワークのオーバーロードパフォーマンス」、BSTJ、Vol.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.、他が「Multiserviceの統合声/データ網での発展を発送すること」でのITC-16のProceeding、エディンバラ1999年6月。
[ASH3] Ash, G. R., "Performance Evaluation of QoS-Routing
Methods for IP-Based Multiservice Networks," Computer
Communications Magazine, May 2003.
[ASH3]灰(G.R.、「IPを拠点とするMultiserviceネットワークのためのQoS-ルーティング方式の業績評価」、コンピュータコミュニケーション雑誌)は2003がそうするかもしれません。
[BUR] Burke, P. J., Blocking Probabilities Associated with
Directional Reservation, unpublished memorandum, 1961.
[BUR]バーク、P.J.、Directional予約があるBlocking Probabilities Associated、未発表のメモ、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交通への以下を設計する帯域幅規制モデル」 「業績評価」、RFC4128、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と、「Multiservice TDM、気圧、およびIPを拠点とするネットワークのためのQoSルート設定と関連交通工学方法。」
[GMPLS-RECOV] Lang, J., et al., "Generalized MPLS Recovery Functional
Specification", Work in Progress.
[GMPLS-RECOV] ラング、J.、他、「一般化されたMPLS回復機能的な仕様」、ProgressのWork。
Ash Experimental [Page 20] RFC 4126 MAR Bandwidth Constraints Model for DS-TE June 2005
実験的な[20ページ]RFC4126 3月の帯域幅規制が2005年6月にDS-Teのためにモデル化する灰
[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.
[LAI] レイ、W.、「ネットワーク・システムIIIコンファレンスのMPLS、インターネットパフォーマンス、およびコントロールのための交通工学」、SPIE Proceedings Vol.4865、ページ 256-267 ボストン(マサチューセッツ)(米国)29 7月-2002年8月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.、レイ、w.、「最大の配分帯域幅規制はDiffserv意識しているMPLS交通工学のためにモデル化する」RFC4125、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交通工学は速くコースを変更します」。 「帯域幅保護のための迂回トンネル経路計算」、処理中の作業。
[MUM] Mummert, V. S., "Network Management and Its
Implementation on the No. 4ESS, International Switching
Symposium", Japan, 1976.
[キク] S.とMummert、対「ネットワークマネージメントとNo.4ESSにおける実現、国際切り換えシンポジウム」日本、1976。
[NAK] Nakagome, Y., Mori, H., Flexible Routing in the Global
Communication Network, Proceedings of ITC-7, Stockholm,
1973.
[NAK] 中込、Y.、モリ、H.、グローバル通信ネットワークにおけるフレキシブルなルート設定、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] キャッツとD.とKompellaとK.とD.Yeung、「(Te)拡大をOSPFにバージョン2インチ設計する交通、RFC3630、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.、RFC4127、「Diffserv意識しているMPLS交通へのロシア人のドールズ帯域幅規制モデルは設計すること」での6月2005日
[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.、Srinivasan、V.、およびG.が飲み込まれる、「RSVP-Te:」 「LSP TunnelsのためのRSVPへの拡大」、RFC3209、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
以下に電話をしてください。 +1 732-420-4578 メールしてください: gash@att.com
Ash Experimental [Page 21] RFC 4126 MAR Bandwidth Constraints Model for DS-TE June 2005
実験的な[21ページ]RFC4126 3月の帯域幅規制が2005年6月にDS-Teのためにモデル化する灰
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Ash Experimental [Page 22]
灰の実験的です。[22ページ]
一覧
スポンサーリンク
