[要約] 要約： RFC 4128は、Diffserv対応のMPLSトラフィックエンジニアリングにおける帯域制約モデルに関するパフォーマンス評価について述べています。目的： このRFCの目的は、Diffserv対応のMPLSトラフィックエンジニアリングにおける帯域制約モデルのパフォーマンスを評価し、ネットワークの効率性と品質を向上させることです。
Network Working Group W. Lai
Request for Comments: 4128 AT&T Labs
Category: Informational June 2005
Bandwidth Constraints Models for Differentiated Services (Diffserv)-aware MPLS Traffic Engineering: Performance Evaluation
差別化されたサービスの帯域幅制約モデル（DIFFSERV） - アウェアMPLSトラフィックエンジニアリング：パフォーマンス評価
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
IESG Note
IESGノート
The content of this RFC has been considered by the IETF (specifically in the TE-WG working group, which has no problem with publication as an Informational RFC), and therefore it may resemble a current IETF work in progress or a published IETF work. However, this document is an individual submission and not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose, and in particular notes that it has not had complete IETF review for such things as security, congestion control or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this RFC should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information.
このRFCの内容は、IETFによって検討されています（特に、情報RFCとしての公開に問題はないTE-WGワーキンググループで）ため、現在のIETF作業または公開されているIETF作業に似ている可能性があります。ただし、このドキュメントは個別の提出物であり、インターネット標準のレベルの候補者ではありません。IETFは、あらゆる目的のためにこのRFCのフィットネスに関する知識を放棄します。特に、セキュリティ、輻輳制御、または展開プロトコルとの不適切な相互作用などについて完全なIETFレビューはなかったことに注意してください。RFCエディターは、その裁量でこのドキュメントを公開することを選択しました。このRFCの読者は、実装と展開の価値を評価する際に注意する必要があります。詳細については、RFC 3932を参照してください。
Abstract
概要
"Differentiated Services (Diffserv)-aware MPLS Traffic Engineering Requirements", RFC 3564, specifies the requirements and selection criteria for Bandwidth Constraints Models. Two such models, the Maximum Allocation and the Russian Dolls, are described therein. This document complements RFC 3564 by presenting the results of a performance evaluation of these two models under various operational conditions: normal load, overload, preemption fully or partially enabled, pure blocking, or complete sharing.
「差別化されたサービス（DIFFSERV） - AWARE MPLSトラフィックエンジニアリング要件」、RFC 3564は、帯域幅制約モデルの要件と選択基準を指定します。そのような2つのモデル、最大割り当てとロシアの人形については、そこに記載されています。このドキュメントは、通常の負荷、過負荷、完全または部分的に有効化された、純粋なブロッキング、または完全な共有のさまざまな動作条件下で、これら2つのモデルのパフォーマンス評価の結果を提示することにより、RFC 3564を補完します。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Conventions used in this document ..........................4
2. Bandwidth Constraints Models ....................................4
3. Performance Model ...............................................5
3.1. LSP Blocking and Preemption ................................6
3.2. Example Link Traffic Model .................................8
3.3. Performance under Normal Load ..............................9
4. Performance under Overload .....................................10
4.1. Bandwidth Sharing versus Isolation ........................10
4.2. Improving Class 2 Performance at the Expense of Class 3 ...12
4.3. Comparing Bandwidth Constraints of Different Models .......13
5. Performance under Partial Preemption ...........................15
5.1. Russian Dolls Model .......................................16
5.2. Maximum Allocation Model ..................................16
6. Performance under Pure Blocking ................................17
6.1. Russian Dolls Model .......................................17
6.2. Maximum Allocation Model ..................................18
7. Performance under Complete Sharing .............................19
8. Implications on Performance Criteria ...........................20
9. Conclusions ....................................................21
10. Security Considerations .......................................22
11. Acknowledgements ..............................................22
12. References ....................................................22
12.1. Normative References ....................................22
12.2. Informative References ..................................22
Differentiated Services (Diffserv)-aware MPLS Traffic Engineering (DS-TE) mechanisms operate on the basis of different Diffserv classes of traffic to improve network performance. Requirements for DS-TE and the associated protocol extensions are specified in references [1] and [2] respectively.
差別化されたサービス（DIFFSERV） - アウェアMPLSトラフィックエンジニアリング（DS-TE）メカニズムは、さまざまなDIFFSERVクラスのトラフィックに基づいて動作し、ネットワークパフォーマンスを向上させます。DS-TEおよび関連するプロトコル拡張の要件は、それぞれ参照[1]および[2]で指定されています。
To achieve per-class traffic engineering, rather than on an aggregate basis across all classes, DS-TE enforces different Bandwidth Constraints (BCs) on different classes. Reference [1] specifies the requirements and selection criteria for Bandwidth Constraints Models (BCMs) for the purpose of allocating bandwidth to individual classes.
DS-TEは、すべてのクラスで総合的なベースではなく、クラスごとの交通工学を達成するために、さまざまなクラスで異なる帯域幅の制約（BC）を実施します。参照[1]は、個々のクラスに帯域幅を割り当てる目的で、帯域幅制約モデル（BCMS）の要件と選択基準を指定します。
This document presents a performance analysis for the two BCMs described in [1]:
このドキュメントでは、[1]で説明されている2つのBCMのパフォーマンス分析を提示します。
(1) Maximum Allocation Model (MAM) - the maximum allowable bandwidth usage of each class, together with the aggregate usage across all classes, are explicitly specified.
(1) 最大割り当てモデル（MAM） - 各クラスの最大許容帯域幅の使用と、すべてのクラスでの集計使用が明示的に指定されています。
(2) Russian Dolls Model (RDM) - specification of maximum allowable usage is done cumulatively by grouping successive priority classes recursively.
(2) ロシアの人形モデル（RDM） - 連続した優先度クラスを再帰的にグループ化することにより、最大許容使用量の仕様は累積的に行われます。
The following criteria are also listed in [1] for investigating the performance and trade-offs of different operational aspects of BCMs:
BCMのさまざまな運用面のパフォーマンスとトレードオフを調査するために、次の基準も[1]にリストされています。
(1) addresses the scenarios in Section 2 of [1]
(1) [1]のセクション2のシナリオに対応します
(2) works well under both normal and overload conditions
(2) 通常の条件と過負荷条件の両方でうまく機能します
(3) applies equally when preemption is either enabled or disabled
(3) プリエンプションが有効または無効になっている場合、等しく適用されます
(4) minimizes signaling load processing requirements
(4) シグナリングの負荷処理要件を最小化します
(5) maximizes efficient use of the network
(5) ネットワークの効率的な使用を最大化します
(6) minimizes implementation and deployment complexity
(6) 実装と展開の複雑さを最小限に抑えます
The use of any given BCM has significant impacts on the capability of a network to provide protection for different classes of traffic, particularly under high load, so that performance objectives can be met [3]. This document complements [1] by presenting the results of a performance evaluation of the above two BCMs under various operational conditions: normal load, overload, preemption fully or partially enabled, pure blocking, or complete sharing. Thus, our focus is only on the performance-oriented criteria and their implications for a network implementation. In other words, we are only concerned with criteria (2), (3), and (5); we will not address criteria (1), (4), or (6).
特定のBCMの使用は、特に高負荷の下でさまざまなクラスのトラフィックを保護するためのネットワークの能力に大きな影響を与え、パフォーマンス目標を満たすことができます[3]。このドキュメントは、通常の負荷、過負荷、完全または部分的に有効になっている、純粋なブロッキング、または完全な共有など、さまざまな運用条件の下で上記の2つのBCMのパフォーマンス評価の結果を提示することにより、[1]を補完します。したがって、私たちの焦点は、パフォーマンス指向の基準とネットワーク実装に対するそれらの意味のみにのみです。言い換えれば、基準（2）、（3）、および（5）のみに関心があります。基準（1）、（4）、または（6）には対処しません。
Related documents in this area include [4], [5], [6], [7], and [8].
この分野の関連文書には、[4]、[5]、[6]、[7]、および[8]が含まれます。
In the rest of this document, the following DS-TE acronyms are used:
このドキュメントの残りの部分では、次のDS-TEの頭字語が使用されます。
BC Bandwidth Constraint BCM Bandwidth Constraints Model MAM Maximum Allocation Model RDM Russian Dolls Model
BC帯域幅の制約BCM帯域幅制約モデルMAM最大割り当てモデルRDMロシア人形モデル
There may be differences between the quality of service expressed and obtained with Diffserv without DS-TE and with DS-TE. Because DS-TE uses Constraint Based Routing, and because of the type of admission control capabilities it adds to Diffserv, DS-TE has capabilities for traffic that Diffserv does not. Diffserv does not indicate preemption, by intent, whereas DS-TE describes multiple levels of preemption for its Class-Types. Also, Diffserv does not support any means of explicitly controlling overbooking, while DS-TE allows this. When considering a complete quality of service environment, with Diffserv routers and DS-TE, it is important to consider these differences carefully.
DS-TEなしおよびDS-TEで発現および取得されたサービスの品質には違いがあるかもしれません。DS-TEは制約ベースのルーティングを使用しているため、入場制御機能の種類がDiffServに追加されるため、DS-TEにはDiffServにはないトラフィックの機能があります。Diffservは、意図的に先制を示すものではありませんが、DS-TEはクラスタイプの複数のレベルの先制を説明しています。また、DiffServはオーバーブッキングを明示的に制御する手段をサポートしていませんが、DS-TEはこれを許可します。DiffServルーターとDS-TEを備えた完全なサービス環境を検討する場合、これらの違いを慎重に考慮することが重要です。
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 RFC 2119.
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119に記載されているとおりに解釈されます。
To simplify our presentation, we use the informal name "class of traffic" for the terms Class-Type and TE-Class, defined in [1]. We assume that (1) there are only three classes of traffic, and that (2) all label-switched paths (LSPs), regardless of class, require the same amount of bandwidth. Furthermore, the focus is on the bandwidth usage of an individual link with a given capacity; routing aspects of LSP setup are not considered.
プレゼンテーションを簡素化するために、[1]で定義されているクラスタイプとTEクラスという用語の非公式名「トラフィックのクラス」を使用します。（1）トラフィックには3つのクラスのみがあり、（2）クラスに関係なく、すべてのラベルスイッチパス（LSP）が同じ量の帯域幅を必要とすると想定しています。さらに、焦点は、特定の容量との個々のリンクの帯域幅の使用にあります。LSPセットアップのルーティングの側面は考慮されません。
The concept of reserved bandwidth is also defined in [1] to account for the possible use of overbooking. Rather than get into these details, we assume that each LSP is allocated 1 unit of bandwidth on a given link after establishment. This allows us to express link bandwidth usage simply in terms of the number of simultaneously established LSPs. Link capacity can then be used as the aggregate constraint on bandwidth usage across all classes.
予約された帯域幅の概念は、オーバーブッキングの使用の可能性を説明するために[1]で定義されています。これらの詳細に入るのではなく、各LSPに、設立後に特定のリンクに帯域幅の1単位が割り当てられていると想定しています。これにより、同時に確立されたLSPの数の観点から、リンク帯域幅の使用を表現することができます。リンク容量は、すべてのクラスで帯域幅の使用に関する集約制約として使用できます。
Suppose that the three classes of traffic assumed above for the purposes of this document are denoted by class 1 (highest priority), class 2, and class 3 (lowest priority). When preemption is enabled, these are the preemption priorities. To define a generic class of BCMs for the purpose of our analysis in accordance with the above assumptions, let
このドキュメントの目的のために上記の3つのクラスのトラフィックが、クラス1（最優先事項）、クラス2、クラス3（最低優先順位）で示されているとします。先制が有効になっている場合、これらは先制優先度です。上記の仮定に従って分析の目的でBCMの一般的なクラスを定義するには、
Nmax = link capacity; i.e., the maximum number of simultaneously established LSPs for all classes together
nmax = link容量;つまり、すべてのクラスに合わせて同時に確立されたLSPの最大数
Nc = the number of simultaneously established class c LSPs, for c = 1, 2, and 3, respectively.
NC =それぞれC = 1、2、および3のクラスC LSPを同時に確立した数。
For MAM, let
MAMの場合は、
Bc = maximum number of simultaneously established class c LSPs.
BC =同時に確立されたクラスC LSPの最大数。
Then, Bc is the Bandwidth Constraint for class c, and we have
次に、BCはクラスCの帯域幅の制約であり、私たちは持っています
Nc <= Bc <= Nmax, for c = 1, 2, and 3
N1 + N2 + N3 <= Nmax
B1 + B2 + B3 >= Nmax
For RDM, the BCs are specified as:
RDMの場合、BCは次のように指定されています。
B1 = maximum number of simultaneously established class 1 LSPs
B1 =同時に確立されたクラス1 LSPの最大数
B2 = maximum number of simultaneously established LSPs for classes 1 and 2 together
B2 =クラス1と2の同時に確立されたLSPの最大数
B3 = maximum number of simultaneously established LSPs for classes 1, 2, and 3 together
B3 =クラス1、2、および3の同時に確立されたLSPの最大数
Then, we have the following relationships:
次に、次の関係があります。
N1 <= B1
N1 + N2 <= B2
N1 + N2 + N3 <= B3
B1 < B2 < B3 = Nmax
Reference [8] presents a 3-class Markov-chain performance model to analyze a general class of BCMs. The BCMs that can be analyzed include, besides MAM and RDM, BCMs with privately reserved bandwidth that cannot be preempted by other classes.
参照[8]は、3クラスのマルコフチェーンパフォーマンスモデルを提示して、BCMの一般的なクラスを分析します。分析できるBCMには、MAMおよびRDM以外に、他のクラスでは先制できない個人的に予約された帯域幅を備えたBCMが含まれます。
The Markov-chain performance model in [8] assumes Poisson arrivals for LSP requests with exponentially distributed lifetime. The Poisson assumption for LSP requests is relevant since we are not dealing with the arrivals of individual packets within an LSP. Also, LSP lifetime may exhibit heavy-tail characteristics. This effect should be accounted for when the performance of a particular BCM by itself is evaluated. As the effect would be common for all BCMs, we ignore it for simplicity in the comparative analysis of the relative performance of different BCMs. In principle, a suitably chosen hyperexponential distribution may be used to capture some aspects of heavy tail. However, this will significantly increase the complexity of the non-product-form preemption model in [8].
[8]のマルコフチェーンパフォーマンスモデルは、指数関数的に分散した寿命を伴うLSP要求のポアソンの到着を想定しています。LSPリクエストのポアソンの仮定は、LSP内の個々のパケットの到着を扱っていないため、関連しています。また、LSP寿命は重尾の特性を示す可能性があります。この効果は、特定のBCMのパフォーマンス自体が評価される場合を説明する必要があります。効果はすべてのBCMで一般的であるため、異なるBCMの相対パフォーマンスの比較分析を簡単にするためにそれを無視します。原則として、適切に選択されたハイエクスポン論的分布を使用して、重い尾のいくつかの側面をキャプチャすることができます。ただし、これにより、[8]の非製品形式の先制モデルの複雑さが大幅に増加します。
The model in [8] assumes the use of admission control to allocate link bandwidth to LSPs of different classes in accordance with their respective BCs. Thus, the model accepts as input the link capacity and offered load from different classes. The blocking and preemption probabilities for different classes under different BCs are generated as output. Thus, from a service provider's perspective, given the desired level of blocking and preemption performance, the model can be used iteratively to determine the corresponding set of BCs.
[8]のモデルは、それぞれのBCSに従ってリンク帯域幅を異なるクラスのLSPに割り当てるための入場制御の使用を想定しています。したがって、モデルはリンク容量を入力として受け入れ、異なるクラスからの負荷を提供します。異なるBCSの下での異なるクラスのブロッキングおよび先制確率は、出力として生成されます。したがって、サービスプロバイダーの観点からは、ブロッキングと先制パフォーマンスの望ましいレベルを考えると、モデルを繰り返し使用して、BCの対応するセットを決定できます。
To understand the implications of using criteria (2), (3), and (5) in the Introduction Section to select a BCM, we present some numerical results of the analysis in [8]. This is intended to facilitate discussion of the issues that can arise. The major performance objective is to achieve a balance between the need for bandwidth sharing (for increasing bandwidth efficiency) and the need for bandwidth isolation (for protecting bandwidth access by different classes).
基準（2）、（3）、および（5）を使用することの意味を理解するために、BCMを選択するための紹介セクションでは、[8]で分析の数値結果を示します。これは、発生する可能性のある問題の議論を促進することを目的としています。主なパフォーマンスの目的は、帯域幅共有の必要性（帯域幅効率の向上）と帯域幅分離の必要性（さまざまなクラスによる帯域幅アクセスを保護するため）とのバランスをとることです。
As described in Section 2, the three classes of traffic used as an example are class 1 (highest priority), class 2, and class 3 (lowest priority). Preemption may or may not be used, and we will examine the performance of each scenario. When preemption is used, the priorities are the preemption priorities. We consider cross-class preemption only, with no within-class preemption. In other words, preemption is enabled so that, when necessary, class 1 can preempt class 3 or class 2 (in that order), and class 2 can preempt class 3.
セクション2で説明されているように、例として使用されるトラフィックの3つのクラスは、クラス1（最優先事項）、クラス2、クラス3（最低優先度）です。先制が使用される場合と使用されない場合があります。各シナリオのパフォーマンスを調べます。先制が使用される場合、優先順位は先制優先度です。クロスクラスの先制のみを考慮し、クラス内の先制はありません。言い換えれば、必要に応じてクラス1がクラス3またはクラス2（その順序で）を先取りできるように、クラス2がクラス3を先取りできるように、先制が有効になっています。
Each class offers a load of traffic to the network that is expressed in terms of the arrival rate of its LSP requests and the average lifetime of an LSP. A unit of such a load is an erlang. (In packet-based networks, traffic volume is usually measured by counting the number of bytes and/or packets that are sent or received over an interface during a measurement period. Here we are only concerned with bandwidth allocation and usage at the LSP level. Therefore, as a measure of resource utilization in a link-speed independent manner, the erlang is an appropriate unit for our purpose [9].)
各クラスは、LSP要求の到着率とLSPの平均寿命の観点から表されるネットワークへのトラフィックの負荷を提供します。そのような負荷の単位はエルランです。（パケットベースのネットワークでは、通常、測定期間中にインターフェイスで送信または受信されるバイトおよび/または受信されるバイトおよび/またはパケットの数をカウントすることにより、トラフィック量が測定されます。ここでは、LSPレベルでの帯域幅の割り当てと使用にのみ関心があります。したがって、リンク速度独立した方法でのリソース利用の尺度として、エルランは私たちの目的のための適切な単位です[9]。
To prevent Diffserv QoS degradation at the packet level, the expected number of established LSPs for a given class should be kept in line with the average service rate that the Diffserv scheduler can provide to that class. Because of the use of overbooking, the actual traffic carried by a link may be higher than expected, and hence QoS degradation may not be totally avoidable.
パケットレベルでのdiffserv QoS分解を防ぐために、特定のクラスの確立されたLSPの予想数は、DiffServスケジューラがそのクラスに提供できる平均サービスレートに沿って保持する必要があります。オーバーブッキングの使用により、リンクによって運ばれる実際のトラフィックは予想よりも高くなる可能性があるため、QoSの劣化は完全に回避できない場合があります。
However, the use of admission control at the LSP level helps minimize QoS degradation by enforcing the BCs established for the different classes, according to the rules of the BCM adopted. That is, the BCs are used to determine the number of LSPs that can be simultaneously established for different classes under various operational conditions. By controlling the number of LSPs admitted from different classes, this in turn ensures that the amount of traffic submitted to the Diffserv scheduler is compatible with the targeted packet-level QoS objectives.
ただし、LSPレベルでの入場制御を使用すると、採用されたBCMのルールに従って、さまざまなクラスに確立されたBCSを実施することにより、QoSの劣化を最小限に抑えることができます。つまり、BCSは、さまざまな運用条件下で異なるクラスに対して同時に確立できるLSPの数を決定するために使用されます。さまざまなクラスから認められたLSPの数を制御することにより、これにより、DiffServスケジューラに提出されたトラフィックの量が、ターゲットを絞ったパケットレベルのQoS目標と互換性があることが保証されます。
The performance of a BCM can therefore be measured by how well the given BCM handles the offered traffic, under normal or overload conditions, while maintaining packet-level service objectives. Thus, assuming that the enforcement of Diffserv QoS objectives by admission control is a given, the performance of a BCM can be expressed in terms of LSP blocking and preemption probabilities.
したがって、BCMのパフォーマンスは、特定のBCMが、パケットレベルのサービス目標を維持しながら、通常または過負荷条件下で提供されるトラフィックをどれだけうまく処理するかによって測定できます。したがって、入場制御によるDiffServ QOS目標の施行が特定のものであると仮定すると、BCMのパフォーマンスは、LSPブロッキングと先制確率の観点から表現できます。
Different BCMs have different strengths and weaknesses. Depending on the BCs chosen for a given load, a BCM may perform well in one operating region and poorly in another. Service providers are mainly concerned with the utility of a BCM to meet their operational needs. Regardless of which BCM is deployed, the foremost consideration is that the BCM works well under the engineered load, such as the ability to deliver service-level objectives for LSP blocking probabilities. It is also expected that the BCM handles overload "reasonably" well. Thus, for comparison, the common operating point we choose for BCMs is that they meet specified performance objectives in terms of blocking/preemption under given normal load. We then observe how their performance varies under overload. More will be said about this aspect later in Section 4.2.
異なるBCMには、長所と短所が異なります。特定の負荷に対して選択されたBCSに応じて、BCMは1つの動作領域でうまく機能し、別の操作地域では不十分です。サービスプロバイダーは、主に運用上のニーズを満たすためにBCMの有用性に関心があります。どのBCMが展開されているかにかかわらず、最も重要な検討は、LSPブロッキング確率にサービスレベルの目標を提供する機能など、設計された負荷の下でBCMがうまく機能することです。また、BCMはオーバーロードを「合理的に」よく処理することも期待されています。したがって、比較のために、BCMに選択する共通の動作点は、特定の通常の負荷の下でのブロッキング/プリエンプションの観点から、指定されたパフォーマンス目標を満たしていることです。次に、過負荷の下でパフォーマンスがどのように変化するかを観察します。この側面については、セクション4.2の後半で詳しく説明します。
For example, consider a link with a capacity that allows a maximum of 15 LSPs from different classes to be established simultaneously. All LSPs are assumed to have an average lifetime of 1 time unit. Suppose that this link is being offered a load of
たとえば、異なるクラスから最大15のLSPを同時に確立できるようにする容量を持つリンクを検討してください。すべてのLSPは、平均寿命が1時間単位であると想定されています。このリンクが提供されていると仮定します
2.7 erlangs from class 1, 3.5 erlangs from class 2, and 3.5 erlangs from class 3.
2.7 クラス1のerlangs、クラス2の3.5エルラン、クラス3の3.5エルラン。
We now consider a scenario wherein the blocking/preemption performance objectives for the three classes are desired to be comparable under normal conditions (other scenarios are covered in later sections). To meet this service requirement under the above given load, the BCs are selected as follows:
ここで、3つのクラスのブロッキング/先制のパフォーマンス目標が通常の条件下で匹敵することが望まれるシナリオを検討します（他のシナリオは後のセクションでカバーされています）。上記の指定された負荷の下でこのサービス要件を満たすために、BCは次のように選択されます。
For MAM:
MAMの場合：
up to 6 simultaneous LSPs for class 1, up to 7 simultaneous LSPs for class 2, and up to 15 simultaneous LSPs for class 3.
クラス1で最大6つの同時LSP、クラス2で最大7つの同時LSP、クラス3で最大15の同時LSP。
For RDM:
RDMの場合：
up to 6 simultaneous LSPs for class 1 by itself, up to 11 simultaneous LSPs for classes 1 and 2 together, and up to 15 simultaneous LSPs for all three classes together.
クラス1自体で最大6つの同時LSP、クラス1と2で最大11の同時LSP、3つのクラスすべてで最大15の同時LSP。
Note that the driver is service requirement, independent of BCM. The above BCs are not picked arbitrarily; they are chosen to meet specific performance objectives in terms of blocking/preemption (detailed in the next section).
ドライバーは、BCMとは独立したサービス要件であることに注意してください。上記のBCは任意に選ばれていません。これらは、ブロッキング/プリエンプションの観点から特定のパフォーマンス目標を満たすために選択されています（次のセクションで詳しく説明しています）。
An intuitive "explanation" for the above set of BCs may be as follows. Class 1 BC is the same (6) for both models, as class 1 is treated the same way under either model with preemption. However, MAM and RDM operate in fundamentally different ways and give different treatments to classes with lower preemption priorities. It can be seen from Section 2 that although RDM imposes a strict ordering of the different BCs (B1 < B2 < B3) and a hard boundary (B3 = Nmax), MAM uses a soft boundary (B1+B2+B3 >= Nmax) with no specific ordering. As will be explained in Section 4.3, this allows RDM to have a higher degree of sharing among different classes. Such a higher degree of coupling means that the numerical values of the BCs can be relatively smaller than those for MAM, to meet given performance requirements under normal load.
上記のBCSセットの直感的な「説明」は次のとおりです。クラス1は両方のモデルで同じ（6）と同じです。クラス1は、いずれのモデルでも先制の下で同じ方法で扱われます。ただし、MAMとRDMは根本的に異なる方法で動作し、先制の優先順位が低いクラスに異なる治療を行います。セクション2から、RDMは異なるBCS（B1 <B2 <B3）と硬い境界（B3 = NMAX）の厳格な順序を課しているが、MAMはソフト境界（B1 B2 B3> = NMAX）を使用していないことがわかります。特定の注文。セクション4.3で説明するように、これにより、RDMは異なるクラス間でより高い程度の共有を持つことができます。このような高度なカップリングは、通常の負荷の下で与えられたパフォーマンス要件を満たすために、BCの数値がMAMの数値よりも比較的小さくなる可能性があることを意味します。
Thus, in the above example, the RDM BCs of (6, 11, 15) may be thought of as roughly corresponding to the MAM BCs of (6, 6+7, 6+7+15). (The intent here is just to point out that the design parameters for the two BCMs need to be different, as they operate differently; strictly speaking, the numerical correspondence is incorrect.) Of course, both BCMs are bounded by the same aggregate constraint of the link capacity (15).
したがって、上記の例では、（6、11、15）のRDM BCSは、（6、6 7、6 7 15）のMAM BCにほぼ対応するものと考えられる可能性があります。（ここでの意図は、2つのBCMの設計パラメーターが異なって動作するため、異なる必要があることを指摘することです。厳密に言えば、数値対応は間違っています。）リンク容量（15）。
The BCs chosen in the above example are not intended to be regarded as typical values used by any service provider. They are used here mainly for illustrative purposes. The method we used for analysis can easily accommodate another set of parameter values as input.
上記の例で選択されたBCSは、サービスプロバイダーが使用する典型的な値と見なされることを意図したものではありません。ここでは、主に説明のために使用されます。分析に使用した方法は、入力としてパラメーター値の別のセットに簡単に対応できます。
In the example above, based on the BCs chosen, the blocking and preemption probabilities for LSP setup requests under normal conditions for the two BCMs are given in Table 1. Remember that the BCs have been selected for this scenario to address the service requirement to offer comparable blocking/preemption objectives for the three classes.
上記の例では、選択したBCSに基づいて、2つのBCMの通常の条件下でのLSPセットアップリクエストのブロッキングと先制の確率を表1に示します。3つのクラスの同等のブロッキング/プリエンプション目標。
Table 1. Blocking and preemption probabilities
表1.ブロッキングと先制確率
BCM PB1 PB2 PB3 PP2 PP3 PB2+PP2 PB3+PP3
BCM PB1 PB2 PB3 PP2 PP3 PB2 PP2 PB3 PP3
MAM 0.03692 0.03961 0.02384 0 0.02275 0.03961 0.04659 RDM 0.03692 0.02296 0.02402 0.01578 0.01611 0.03874 0.04013
MAM 0.03692 0.03961 0.02384 0 0.02275 0.03961 0.04659 RDM 0.03692 0.02296 0.02402 0.01578 0.01611 0.03874 0.04013
In the above table, the following apply:
上記の表では、次のものが適用されます。
PB1 = blocking probability of class 1 PB2 = blocking probability of class 2 PB3 = blocking probability of class 3
PB1 =クラス1のブロッキング確率PB2 =クラス2のブロッキング確率PB3 =クラス3のブロッキング確率
PP2 = preemption probability of class 2 PP3 = preemption probability of class 3
pp2 =クラス2の先行予測確率pp3 =クラス3の先制確率
PB2+PP2 = combined blocking/preemption probability of class 2
PB3+PP3 = combined blocking/preemption probability of class 3
First, we observe that, indeed, the values for (PB1, PB2+PP2, PB3+PP3) are very similar one to another. This confirms that the service requirement (of comparable blocking/preemption objectives for the three classes) has been met for both BCMs.
まず、実際、（PB1、PB2 PP2、PB3 PP3）の値は非常に似ていることがわかります。これは、両方のBCMで（3つのクラスの匹敵するブロッキング/プリエンプション目標の）サービス要件が満たされていることを確認しています。
Then, we observe that the (PB1, PB2+PP2, PB3+PP3) values for MAM are very similar to the (PB1, PB2+PP2, PB3+PP3) values for RDM. This indicates that, in this scenario, both BCMs offer very similar performance under normal load.
次に、MAMの（PB1、PB2 PP2、PB3 PP3）値は、RDMの（PB1、PB2 PP2、PB3 PP3）値に非常に類似していることがわかります。これは、このシナリオでは、両方のBCMが通常の負荷で非常に似たパフォーマンスを提供することを示しています。
From column 2 of Table 1, it can be seen that class 1 sees exactly the same blocking under both BCMs. This should be obvious since both allocate up to 6 simultaneous LSPs for use by class 1 only. Slightly better results are obtained from RDM, as shown by the last two columns in Table 1. This comes about because the cascaded bandwidth separation in RDM effectively gives class 3 some form of protection from being preempted by higher-priority classes.
表1の列2から、クラス1は両方のBCMの下でまったく同じブロッキングを見ていることがわかります。クラス1のみで使用するために最大6つの同時LSPを割り当てるため、これは明らかであるはずです。表1の最後の2つの列に示されているように、RDMからわずかに優れた結果が得られます。これは、RDMのカスケード帯域幅分離により、クラス3がより優先度の高いクラスによって先取りされることから何らかの形の保護を効果的に提供するためです。
Also, note that PP2 is zero in this particular case, simply because the BCs for MAM happen to have been chosen in such a way that class 1 never has to preempt class 2 for any of the bandwidth that class 1 needs. (This is because class 1 can, in the worst case, get all the bandwidth it needs simply by preempting class 3 alone.) In general, this will not be the case.
また、この特定のケースでは、PP2がゼロであることに注意してください。これは、MAMのBCSがクラス1が必要とする帯域幅のいずれにおいてもクラス2を先取りする必要がないような方法で選択されたからです。（これは、クラス1が最悪の場合、クラス3だけを先取りするだけで必要なすべての帯域幅を取得できるためです。）一般的に、これは当てはまりません。
It is interesting to compare these results with those for the case of a single class. Based on the Erlang loss formula, a capacity of 15 servers can support an offered load of 10 erlangs with a blocking probability of 0.0364969. Whereas the total load for the 3-class BCM is less with 2.7 + 3.5 + 3.5 = 9.7 erlangs, the probabilities of blocking/preemption are higher. Thus, there is some loss of efficiency due to the link bandwidth being partitioned to accommodate for different traffic classes, thereby resulting in less sharing. This aspect will be examined in more detail later, in Section 7 on Complete Sharing.
これらの結果を単一のクラスの場合の結果と比較することは興味深いです。Erlangの損失式に基づいて、15のサーバーの容量は、0.0364969のブロッキング確率で提供される10個のErlangの負荷をサポートできます。3クラスのBCMの総負荷は2.7 3.5 3.5 = 9.7 Erlangsで少ないのに対し、ブロッキング/先制の確率は高くなります。したがって、さまざまなトラフィッククラスに対応するためにリンク帯域幅が分割されているため、効率の低下があり、それにより共有が少なくなります。この側面については、完全な共有に関するセクション7で、後で詳しく説明します。
Overload occurs when the traffic on a system is greater than the traffic capacity of the system. To investigate the performance under overload conditions, the load of each class is varied separately. Blocking and preemption probabilities are not shown separately for each case; they are added together to yield a combined blocking/preemption probability.
システム上のトラフィックがシステムのトラフィック容量よりも大きい場合、過負荷が発生します。過負荷条件下でのパフォーマンスを調査するために、各クラスの負荷は個別に変化します。ブロッキングと先制確率は、各ケースについて個別に表示されません。それらを組み合わせて、ブロッキング/先制確率を組み合わせます。
Figures 1 and 2 show the relative performance when the load of each class in the example of Section 3.2 is varied separately. The three series of data in each of these figures are, respectively, class 1 blocking probability ("Class 1 B"), class 2 blocking/preemption probability ("Class 2 B+P"), and class 3 blocking/preemption probability ("Class 3 B+P").
図1と2は、セクション3.2の例の各クラスの負荷が個別に変化する場合の相対パフォーマンスを示しています。これらの各図の3つの一連のデータは、それぞれクラス1ブロッキング確率（「クラス1 B」）、クラス2ブロッキング/プリエンプション確率（「クラス2 B P」）、およびクラス3ブロッキング/プリエンプション確率（「クラス」です。3 b p "）。
For each of these series, the first set of four points is for the performance when class 1 load is increased from half of its normal load to twice its normal. Similarly, the next and the last sets of four points are when class 2 and class 3 loads are increased correspondingly.
これらのシリーズのそれぞれについて、4つのポイントの最初のセットは、クラス1の負荷が通常の負荷の半分から通常の2倍に増加する場合のパフォーマンスのためです。同様に、4つのポイントの次と最後のセットは、クラス2とクラス3の負荷がそれに応じて増加する場合です。
The following observations apply to both BCMs:
次の観察結果は両方のBCMに適用されます。
1. The performance of any class generally degrades as its load increases.
1. クラスのパフォーマンスは、一般に、負荷が増加するにつれて劣化します。
2. The performance of class 1 is not affected by any changes (increases or decreases) in either class 2 or class 3 traffic, because class 1 can always preempt others.
2. クラス1のパフォーマンスは、クラス1またはクラス3のトラフィックの変化（増加または減少）の影響を受けません。クラス1は常に他のものを先取りできるためです。
3. Similarly, the performance of class 2 is not affected by any changes in class 3 traffic.
3. 同様に、クラス2のパフォーマンスは、クラス3トラフィックの変化の影響を受けません。
4. Class 3 sees better (worse) than normal performance when either class 1 or class 2 traffic is below (above) normal.
4. クラス3は、クラス1またはクラス2のトラフィックが通常（上記）を下回っている場合、通常のパフォーマンスよりも優れている（悪い）と見なされます。
In contrast, the impact of the changes in class 1 traffic on class 2 performance is different for the two BCMs: It is negligible in MAM and significant in RDM.
対照的に、クラス2のパフォーマンスに対するクラス1トラフィックの変化の影響は、2つのBCMで異なります。MAMでは無視でき、RDMで重要です。
1. Although class 2 sees little improvement (no improvement in this particular example) in performance when class 1 traffic is below normal when MAM is used, it sees better than normal performance under RDM.
1. クラス2では、MAMを使用するとクラス1のトラフィックが通常を下回っている場合、パフォーマンスはほとんど改善されていません（この特定の例には改善はありません）が、RDMの下での通常のパフォーマンスよりも優れていると考えています。
2. Class 2 sees no degradation in performance when class 1 traffic is above normal when MAM is used. In this example, with BCs 6 + 7 < 15, class 1 and class 2 traffic is effectively being served by separate pools. Therefore, class 2 sees no preemption, and only class 3 is being preempted whenever necessary. This fact is confirmed by the Erlang loss formula: a load of 2.7 erlangs offered to 6 servers sees a 0.03692 blocking, and a load of 3.5 erlangs offered to 7 servers sees a 0.03961 blocking. These blocking probabilities are exactly the same as the corresponding entries in Table 1: PB1 and PB2 for MAM.
2. クラス2では、MAMが使用されている場合、クラス1のトラフィックが通常を上回っている場合、パフォーマンスの劣化は見られません。この例では、BCS 6 7 <15、クラス1、クラス2のトラフィックが、別々のプールで事実上提供されています。したがって、クラス2では先制は見られず、必要に応じてクラス3のみが先制されています。この事実は、Erlang損失式によって確認されています。6つのサーバーに提供される2.7のErlangsの負荷は0.03692のブロッキングを見て、7つのサーバーに提供される3.5のErlangが0.03961のブロックをします。これらのブロッキング確率は、MAMの表1：PB1およびPB2の対応するエントリとまったく同じです。
3. This is not the case in RDM. Here, the probability for class 2 to be preempted by class 1 is nonzero because of two effects. (1) Through the cascaded bandwidth arrangement, class 3 is protected somewhat from preemption. (2) Class 2 traffic is sharing a BC with class 1. Consequently, class 2 suffers when class 1 traffic increases.
3. これはRDMには当てはまりません。ここでは、クラス2がクラス1で先取りする確率は、2つの効果のためにゼロではありません。（1）カスケードされた帯域幅の配置を通じて、クラス3は先制から多少保護されています。（2）クラス2のトラフィックは、BCをクラス1と共有しています。その結果、クラス1のトラフィックが増加すると、クラス2は苦しみます。
Thus, it appears that although the cascaded bandwidth arrangement and the resulting bandwidth sharing makes RDM work better under normal conditions, such interaction makes it less effective to provide class isolation under overload conditions.
したがって、カスケードの帯域幅の配置と結果として生じる帯域幅共有により、RDMは通常の条件下でうまく機能するようになっているように見えますが、そのような相互作用により、過負荷条件下でクラスの分離を提供するのは効果が低下します。
We now consider a scenario in which the service requirement is to give better blocking/preemption performance to class 2 than to class 3, while maintaining class 1 performance at the same level as in the previous scenario. (The use of minimum deterministic guarantee for class 3 is to be considered in the next section.) So that the specified class 2 performance objective can be met, class 2 BC is increased appropriately. As an example, BCs (6, 9, 15) are now used for MAM, and (6, 13, 15) for RDM. For both BCMs, as shown in Figures 1bis and 2bis, although class 1 performance remains unchanged, class 2 now receives better performance, at the expense of class 3. This is of course due to the increased access of bandwidth by class 2 over class 3. Under normal conditions, the performance of the two BCMs is similar in terms of their blocking and preemption probabilities for LSP setup requests, as shown in Table 2.
現在、サービスの要件は、クラス1よりもクラス2よりもブロッキング/プリエンプションのパフォーマンスを向上させることであるシナリオを検討し、以前のシナリオと同じレベルでクラス1のパフォーマンスを維持します。（クラス3の最小決定論的保証の使用は、次のセクションで考慮されます。）指定されたクラス2パフォーマンス目標を満たすことができるように、クラス2の紀元前は適切に増加します。例として、BCS（6、9、15）がMAMに使用され、（6、13、15）がRDMに使用されています。図1BIと2BIに示すように、両方のBCMSの場合、クラス1のパフォーマンスは変更されていませんが、クラス2を犠牲にしてクラス2のパフォーマンスが向上しました。通常の条件下では、表2に示すように、LSPセットアップリクエストのブロッキングと先制確率の点で、2つのBCMのパフォーマンスが類似しています。
Table 2. Blocking and preemption probabilities
表2.ブロッキングと先制確率
BCM PB1 PB2 PB3 PP2 PP3 PB2+PP2 PB3+PP3
BCM PB1 PB2 PB3 PP2 PP3 PB2 PP2 PB3 PP3
MAM 0.03692 0.00658 0.02733 0 0.02709 0.00658 0.05441 RDM 0.03692 0.00449 0.02759 0.00272 0.02436 0.00721 0.05195
MAM 0.03692 0.00658 0.02733 0 0.02709 0.00658 0.05441 RDM 0.03692 0.00449 0.02759 0.00272 0.02436 0.00721 0.051955
Under overload, the observations in Section 4.1 regarding the difference in the general behavior between the two BCMs still apply, as shown in Figures 1bis and 2bis.
過負荷の下で、図1BIと2BIに示すように、2つのBCM間の一般的な挙動の違いに関するセクション4.1の観察結果。
The following are two frequently asked questions about the operation of BCMs.
以下は、BCMSの操作に関する2つのよくある質問です。
(1) For a link capacity of 15, would a class 1 BC of 6 and a class 2 BC of 9 in MAM result in the possibility of a total lockout for class 3?
(1) 15のリンク容量の場合、紀元前6のクラス1とMAMのクラス2の紀元前9の場合、クラス3のトータルロックアウトが可能になりますか？
This will certainly be the case when there are 6 class 1 and 9 class 2 LSPs being established simultaneously. Such an offered load (with 6 class 1 and 9 class 2 LSP requests) will not cause a lockout of class 3 with RDM having a BC of 13 for classes 1 and 2 combined, but will result in class 2 LSPs being rejected. If class 2 traffic were considered relatively more important than class 3 traffic, then RDM would perform very poorly compared to MAM with BCs of (6, 9, 15).
これは、6つのクラス1と9のクラス2 LSPが同時に確立されている場合、確かに当てはまります。このような提供された負荷（6クラス1および9クラス2 LSPリクエストを含む）では、クラス3とクラス1と2のBCが13のロックアウトを引き起こすことはありませんが、クラス2 LSPが拒否されます。クラス2のトラフィックがクラス3のトラフィックよりも比較的重要であると考えられていた場合、RDMはBCS（6、9、15）のMAMと比較して非常に低いパフォーマンスを発揮します。
(2) Should MAM with BCs of (6, 7, 15) be used instead so as to make the performance of RDM look comparable?
(2) （6、7、15）のBCSを使用したMAMは、RDMのパフォーマンスを同等に見せるために代わりに使用する必要がありますか？
The answer is that the above scenario is not very realistic when the offered load is assumed to be (2.7, 3.5, 3.5) for the three classes, as stated in Section 3.2. Treating an overload of (6, 9, x) as a normal operating condition is incompatible with the engineering of BCs according to needed bandwidth from different classes. It would be rare for a given class to need so much more than its engineered bandwidth level. But if the class did, the expectation based on design and normal traffic fluctuations is that this class would quickly release unneeded bandwidth toward its engineered level, freeing up bandwidth for other classes.
答えは、セクション3.2に記載されているように、3つのクラスの提供された負荷が（2.7、3.5、3.5）と想定される場合、上記のシナリオはそれほど現実的ではないということです。（6、9、x）の過負荷を通常の動作条件として扱うことは、異なるクラスの必要な帯域幅に従ってBCSのエンジニアリングと互換性がありません。特定のクラスが、その設計された帯域幅レベルよりもはるかに多くを必要とすることはまれです。しかし、クラスが行った場合、設計と通常のトラフィックの変動に基づく期待は、このクラスがエンジニアリングレベルに向けて不要な帯域幅を迅速に解放し、他のクラスの帯域幅を解放することです。
Service providers engineer their networks based on traffic projections to determine network configurations and needed capacity. All BCMs should be designed to operate under realistic network conditions. For any BCM to work properly, the selection of values for different BCs must therefore be based on the projected bandwidth needs of each class, as well as on the bandwidth allocation rules of the BCM itself. This is to ensure that the BCM works as expected under the intended design conditions. In operation, the actual load may well turn out to be different from that of the design. Thus, an assessment of the performance of a BCM under overload is essential to see how well the BCM can cope with traffic surges or network failures. Reflecting this view, the basis for comparison of two BCMs is that they meet the same or similar performance requirements under normal conditions, and how they withstand overload.
サービスプロバイダーは、トラフィックの予測に基づいてネットワークをエンジニアリングして、ネットワーク構成と必要な容量を決定します。すべてのBCMは、現実的なネットワーク条件下で動作するように設計する必要があります。したがって、BCMが適切に機能するためには、さまざまなBCの値の選択は、各クラスの予測される帯域幅のニーズ、およびBCM自体の帯域幅割り当てルールに基づいている必要があります。これは、BCMが意図した設計条件下で予想どおりに機能するようにするためです。動作中、実際の負荷は設計の負荷とは異なることが判明する可能性があります。したがって、BCMが交通量の急増またはネットワークの障害にどれだけ適しているかを確認するには、過負荷でのBCMのパフォーマンスの評価が不可欠です。この見解を反映して、2つのBCMの比較の基礎は、通常の条件下で同じまたは同様のパフォーマンス要件を満たしていることと、過負荷に耐える方法です。
In operational practice, load measurement and forecast would be useful to calibrate and fine-tune the BCs so that traffic from different classes could be redistributed accordingly. Dynamic adjustment of the Diffserv scheduler could also be used to minimize QoS degradation.
運用慣行では、ロード測定と予測は、異なるクラスからのトラフィックをそれに応じて再配布できるように、BCSを調整および微調整するのに役立ちます。DiffServスケジューラの動的調整も使用して、QoS分解を最小限に抑えることもできます。
As is pointed out in Section 3.2, the higher degree of sharing among the different classes in RDM means that the numerical values of the BCs could be relatively smaller than those for MAM. We now examine this aspect in more detail by considering the following scenario. We set the BCs so that (1) for both BCMs, the same value is used for class 1, (2) the same minimum deterministic guarantee of bandwidth for class 3 is offered by both BCMs, and (3) the blocking/preemption probability is minimized for class 2. We want to emphasize that this may not be the way service providers select BCs. It is done here to investigate the statistical behavior of such a deterministic mechanism.
セクション3.2で指摘されているように、RDMのさまざまなクラスの間で共有の高い度合いは、BCSの数値がMAMの数値よりも比較的小さくなる可能性があることを意味します。次のシナリオを検討することにより、この側面をより詳細に検討します。（1）両方のBCMSで同じ値がクラス1に使用されるようにBCSを設定します。クラス2で最小化されます。これは、サービスプロバイダーがBCSを選択する方法ではないことを強調したいと考えています。このような決定論的メカニズムの統計的挙動を調査するためにここで行われます。
For illustration, we use BCs (6, 7, 15) for MAM, and (6, 13, 15) for RDM. In this case, both BCMs have 13 units of bandwidth for classes 1 and 2 together, and dedicate 2 units of bandwidth for use by class 3 only. The performance of the two BCMs under normal conditions is shown in Table 3. It is clear that MAM with (6, 7, 15) gives fairly comparable performance objectives across the three classes, whereas RDM with (6, 13, 15) strongly favors class 2 at the expense of class 3. They therefore cater to different service requirements.
図には、MAMにはBC（6、7、15）、RDMには（6、13、15）を使用します。この場合、両方のBCMには、クラス1と2で13単位の帯域幅があり、クラス3のみで使用するために2ユニットの帯域幅を専用しています。通常の条件下での2つのBCMSのパフォーマンスを表3に示します。したがって、クラス2はクラス3を犠牲にして、さまざまなサービス要件に対応します。
Table 3. Blocking and preemption probabilities
表3.ブロッキングおよび先制確率
BCM PB1 PB2 PB3 PP2 PP3 PB2+PP2 PB3+PP3
BCM PB1 PB2 PB3 PP2 PP3 PB2 PP2 PB3 PP3
MAM 0.03692 0.03961 0.02384 0 0.02275 0.03961 0.04659 RDM 0.03692 0.00449 0.02759 0.00272 0.02436 0.00721 0.05195
MAM 0.03692 0.03961 0.02384 0 0.02275 0.03961 0.04659 RDM 0.03692 0.00449 0.02759 0.00272 0.02436 0.00721 0.051955
By comparing Figures 1 and 2bis, it can be seen that, when being subjected to the same set of BCs, RDM gives class 2 much better performance than MAM, with class 3 being only slightly worse.
図1と2BIを比較することで、同じBCSのセットにさらされると、RDMがMAMよりもはるかに優れたパフォーマンスを提供することがわかります。クラス3はわずかに悪いだけです。
This confirms the observation in Section 3.2 that, when the same service requirements under normal conditions are to be met, the numerical values of the BCs for RDM can be relatively smaller than those for MAM. This should not be surprising in view of the hard boundary (B3 = Nmax) in RDM versus the soft boundary (B1+B2+B3 >= Nmax) in MAM. The strict ordering of BCs (B1 < B2 < B3) gives RDM the advantage of a higher degree of sharing among the different classes; i.e., the ability to reallocate the unused bandwidth of higher-priority classes to lower-priority ones, if needed. Consequently, this leads to better performance when an identical set of BCs is used as exemplified above. Such a higher degree of sharing may necessitate the use of minimum deterministic bandwidth guarantee to offer some protection for lower-priority traffic from preemption. The explicit lack of ordering of BCs in MAM and its soft boundary imply that the use of minimum deterministic guarantees for lower-priority classes may not need to be enforced when there is a lesser degree of sharing. This is demonstrated by the example in Section 4.2 with BCs (6, 9, 15) for MAM.
これにより、セクション3.2の観察結果が確認されています。通常の条件下で同じサービス要件が満たされる場合、RDMのBCSの数値はMAMの数値よりも比較的小さくなる可能性があります。これは、MAMのソフト境界（B1 B2 B3> = NMAX）に対して、RDMの硬い境界（B3 = NMAX）を考慮して驚くべきことではありません。BCS（B1 <B2 <B3）の厳格な順序は、RDMに異なるクラス間でより高い程度の共有の利点を与えます。すなわち、必要に応じて、より優先度クラスの未使用の帯域幅をより低い帯域に再配置する能力。その結果、上記の例として同一のBCSセットが使用されると、これはパフォーマンスが向上します。このような高度な共有は、先制からのより低い優先度のトラフィックをある程度保護するために、最小決定論的帯域幅保証を使用する必要がある場合があります。MAMでのBCの明示的な注文の欠如とそのソフト境界は、より低い程度の共有がある場合、より低い優先度クラスの最小決定論的保証の使用を実施する必要がないことを意味します。これは、MAMのBCS（6、9、15）を含むセクション4.2の例で実証されています。
For illustration, Table 4 shows the performance under normal conditions of RDM with BCs (6, 15, 15).
図の場合、表4は、BCSを使用したRDMの通常の条件下でのパフォーマンスを示しています（6、15、15）。
Table 4. Blocking and preemption probabilities
表4.ブロッキングと先制確率
BCM PB1 PB2 PB3 PP2 PP3 PB2+PP2 PB3+PP3
BCM PB1 PB2 PB3 PP2 PP3 PB2 PP2 PB3 PP3
RDM 0.03692 0.00060 0.02800 0.00032 0.02740 0.00092 0.05540
RDM 0.03692 0.00060 0.02800 0.00032 0.02740 0.00092 0.05540
Regardless of whether deterministic guarantees are used, both BCMs are bounded by the same aggregate constraint of the link capacity. Also, in both BCMs, bandwidth access guarantees are necessarily achieved statistically because of traffic fluctuations, as explained in Section 4.2. (As a result, service-level objectives are typically specified as monthly averages, under the use of statistical guarantees rather than deterministic guarantees.) Thus, given the fundamentally different operating principles of the two BCMs (ordering, hard versus soft boundary), the dimensions of one BCM should not be adopted to design for the other. Rather, it is the service requirements, and perhaps also the operational needs, of a service provider that should be used to drive how the BCs of a BCM are selected.
決定論的保証が使用されるかどうかに関係なく、両方のBCMはリンク容量の同じ集計制約によって制限されます。また、両方のBCMで、セクション4.2で説明されているように、トラフィックの変動のために帯域幅アクセス保証が必然的に統計的に達成されます。（その結果、サービスレベルの目標は、通常、決定論的保証ではなく統計的保証の使用に基づいて、毎月の平均として指定されます。）したがって、2つのBCMS（順序、ハード境界）の根本的に異なる動作原則を考えると、1つのBCMの寸法は、もう1つのBCMの設計に採用しないでください。むしろ、BCMのBCSの選択方法を駆動するために使用する必要があるのは、サービスプロバイダーのサービス要件、およびおそらく運用上のニーズでもあります。
In the previous two sections, preemption is fully enabled in the sense that class 1 can preempt class 3 or class 2 (in that order), and class 2 can preempt class 3. That is, both classes 1 and 2 are preemptor-enabled, whereas classes 2 and 3 are preemptable. A class that is preemptor-enabled can preempt lower-priority classes designated as preemptable. A class not designated as preemptable cannot be preempted by any other classes, regardless of relative priorities.
前の2つのセクションでは、クラス1がクラス3またはクラス2（その順序で）を先取りできるという意味で、先制が完全に有効になり、クラス2はクラス3を先取りできます。一方、クラス2と3は先制的です。Preemptor対応のクラスは、先制として指定されたより低い優先度クラスを先取りできます。先制として指定されていないクラスは、相対的な優先事項に関係なく、他のクラスで先取りすることはできません。
We now consider the three cases shown in Table 5, in which preemption is only partially enabled.
現在、表5に示す3つのケースを検討します。このケースでは、プリエンプションが部分的にしか有効になっていません。
Table 5. Partial preemption modes
表5.部分的な先制モード
preemption modes preemptor-enabled preemptable
Preemption Modes Preemptor対応のPreemptable
"1+2 on 3" (Fig. 3, 6) class 1, class 2 class 3 "1 on 3" (Fig. 4, 7) class 1 class 3 "1 on 2+3" (Fig. 5, 8) class 1 class 3, class 2
"1 2 on 3"（図3、6）クラス1、クラス2クラス3 "1 on 3"（図4、7）クラス1クラス3 "1 on 2 3"（図5、8）クラス1クラス3、クラス2
In this section, we evaluate how these preemption modes affect the performance of a particular BCM. Thus, we are comparing how a given BCM performs when preemption is fully enabled versus how the same BCM performs when preemption is partially enabled. The performance of these preemption modes is shown in Figures 3 to 5 for RDM, and in Figures 6 through 8 for MAM, respectively. In all of these figures, the BCs of Section 3.2 are used for illustration; i.e., (6, 7, 15) for MAM and (6, 11, 15) for RDM. However, the general behavior is similar when the BCs are changed to those in Sections 4.2 and 4.3; i.e., (6, 9, 15) and (6, 13, 15), respectively.
このセクションでは、これらの先制モードが特定のBCMのパフォーマンスにどのように影響するかを評価します。したがって、特定のBCMのパフォーマンスが完全に有効になっている場合と、プリエンプションが部分的に有効になっている場合と同じBCMがどのように機能するかについて比較しています。これらの先制モードのパフォーマンスは、RDMの図3から5に、それぞれ図6から8にMAMで示されています。これらすべての数値では、セクション3.2のBCSが図に使用されます。つまり、MAMの場合（6、7、15）、RDMの場合（6、11、15）。ただし、BCSがセクション4.2および4.3の動作に変更された場合、一般的な動作は類似しています。すなわち、（6、9、15）および（6、13、15）。
Let us first examine the performance under RDM. There are two sets of results, depending on whether class 2 is preemptable: (1) Figures 3 and 4 for the two modes when only class 3 is preemptable, and (2) Figure 2 in the previous section and Figure 5 for the two modes when both classes 2 and 3 are preemptable. By comparing these two sets of results, the following impacts can be observed. Specifically, when class 2 is non-preemptable, the behavior of each class is as follows:
最初にRDMの下でのパフォーマンスを調べてみましょう。クラス2が先制的かどうかに応じて、2つの結果があります。（1）クラス3のみが先制的な2つのモードの図3と4、（2）前のセクションの図2、2つのモードの図5クラス2と3の両方が先制的な場合。これらの2つの結果を比較することにより、次の影響を観察できます。具体的には、クラス2が非償還可能な場合、各クラスの動作は次のとおりです。
1. Class 1 generally sees a higher blocking probability. As the class 1 space allocated by the class 1 BC is shared with class 2, which is now non-preemptable, class 1 cannot reclaim any such space occupied by class 2 when needed. Also, class 1 has less opportunity to preempt, as it is able to preempt class 3 only.
1. クラス1では、通常、ブロッキング確率が高いことがわかります。クラス1 BCによって割り当てられたクラス1のスペースはクラス2と共有されているため、現在は非償還不可能であるため、クラス1は、必要に応じてクラス2が占めるそのようなスペースを取り戻すことはできません。また、クラス1のみがクラス3のみを先取りできるため、クラス1には先制する機会が少ないです。
2. Class 3 also sees higher blocking/preemption when its own load is increased, as it is being preempted more frequently by class 1, when class 1 cannot preempt class 2. (See the last set of four points in the series for class 3 shown in Figures 3 and 4, when comparing with Figures 2 and 5.)
2. クラス3は、クラス1がクラス2を先取りできない場合に、クラス1がクラス1の最後のセットを参照してください。クラス3の4つのポイントの最後のセットを参照してください。図3と4、図2および5と比較するとき。）
3. Class 2 blocking/preemption is reduced even when its own load is increased, since it is not being preempted by class 1. (See the middle set of four points in the series for class 2 shown in Figures 3 and 4, when comparing with Figures 2 and 5.)
3. クラス2は、クラス1で先制されていないため、自体の負荷が増加している場合でも削減されます（図3および4に示すクラス2のシリーズの4つのポイントの中央セットを参照してください。2と5。）
Another two sets of results are related to whether class 2 is preemptor-enabled. In this case, when class 2 is not preemptor-enabled, class 2 blocking/preemption is increased when class 3 load is increased. (See the last set of four points in the series for class 2 shown in Figures 4 and 5, when comparing with Figures 2 and 3.) This is because both classes 2 and 3 are now competing independently with each other for resources.
別の2セットの結果は、クラス2がPreemptor対応であるかどうかに関連しています。この場合、クラス2がプリエンプター対応にならない場合、クラス3の負荷が増加すると、クラス2のブロッキング/プリエンプションが増加します。（図4および5と比較して、図4および5に示すクラス2のシリーズの4つのポイントの最後のセットを参照してください。これは、クラス2と3の両方がリソースのために互いに独立して競合しているためです。
Turning now to MAM, the significant impact appears to be only on class 2, when it cannot preempt class 3, thereby causing its blocking/preemption to increase in two situations.
今すぐMAMに目を向けると、重要な影響はクラス2でのみクラス3であるように見えます。これにより、2つの状況でブロッキング/先制が増加します。
1. When class 1 load is increased. (See the first set of four points in the series for class 2 shown in Figures 7 and 8, when comparing with Figures 1 and 6.)
1. クラス1の負荷が増加した場合。（図7と8の図1と6と比較する場合、図7と8に示すクラス2のシリーズの4つのポイントの最初のセットを参照してください。）
2. When class 3 load is increased. (See the last set of four points in the series for class 2 shown in Figures 7 and 8, when comparing with Figures 1 and 6.) This is similar to RDM; i.e., class 2 and class 3 are now competing with each other.
2. クラス3の負荷が増加した場合。（図7および8に示すクラス2のシリーズの4つのポイントの最後のセットを参照してください。図1および6と比較してください。）これはRDMに似ています。つまり、クラス2とクラス3が互いに競合しています。
When Figure 1 (for the case of fully enabled preemption) is compared to Figures 6 through 8 (for partially enabled preemption), it can be seen that the performance of MAM is relatively insensitive to the different preemption modes. This is because when each class has its own bandwidth access limits, the degree of interference among the different classes is reduced.
図1（完全に有効になった先制の場合）が図6〜8（部分的に有効にされた先制の場合）と比較されると、MAMの性能は異なる先制モードに比較的鈍感であることがわかります。これは、各クラスに独自の帯域幅アクセス制限がある場合、異なるクラス間の干渉の程度が減少するためです。
This is in contrast with RDM, whose behavior is more dependent on the preemption mode in use.
これは、その動作が使用中の先制モードにより依存しているRDMとは対照的です。
This section covers the case in which preemption is completely disabled. We continue with the numerical example used in the previous sections, with the same link capacity and offered load.
このセクションでは、先制が完全に無効になっているケースについて説明します。前のセクションで使用した数値の例を続けて、同じリンク容量と荷重を提供します。
For RDM, we consider two different settings:
RDMの場合、2つの異なる設定を検討します。
"Russian Dolls (1)" BCs:
「ロシアの人形（1）」BCS：
up to 6 simultaneous LSPs for class 1 by itself, up to 11 simultaneous LSPs for classes 1 and 2 together, and up to 15 simultaneous LSPs for all three classes together.
クラス1自体で最大6つの同時LSP、クラス1と2で最大11の同時LSP、3つのクラスすべてで最大15の同時LSP。
"Russian Dolls (2)" BCs:
「ロシア人形（2）」BCS：
up to 9 simultaneous LSPs for class 3 by itself, up to 14 simultaneous LSPs for classes 3 and 2 together, and up to 15 simultaneous LSPs for all three classes together.
クラス3の最大9回の同時LSP自体、クラス3と2で最大14の同時LSP、3つのクラスすべてで最大15の同時LSP。
Note that the "Russian Dolls (1)" set of BCs is the same as previously with preemption enabled, whereas the "Russian Dolls (2)" has the cascade of bandwidth arranged in reverse order of the classes.
「ロシアの人形（1）」のBCSセットは、先制が有効になっている以前と同じであるのに対し、「ロシアの人形（2）」には帯域幅のカスケードがクラスの逆順に配置されていることに注意してください。
As observed in Section 4, the cascaded bandwidth arrangement is intended to offer lower-priority traffic some protection from preemption by higher-priority traffic. This is to avoid starvation. In a pure blocking environment, such protection is no longer necessary. As depicted in Figure 9, it actually produces the opposite, undesirable effect: higher-priority traffic sees higher blocking than lower-priority traffic. With no preemption, higher-priority traffic should be protected instead to ensure that it could get through when under high load. Indeed, when the reverse cascade is used in "Russian Dolls (2)", the required performance of lower blocking for higher-priority traffic is achieved, as shown in Figure 10. In this specific example, there is very little difference among the performance of the three classes in the first eight data points for each of the three series. However, the BCs can be tuned to get a bigger differentiation.
セクション4で観察されたように、カスケードされた帯域幅の配置は、より優先順位のトラフィックによるより低い優先順位のトラフィックに何らかの保護を提供することを目的としています。これは飢starを避けるためです。純粋なブロッキング環境では、そのような保護はもはや必要ありません。図9に示されているように、実際には反対の望ましくない効果が生じます。優先順位のトラフィックは、優先順位のトラフィックよりも高いブロッキングを見ています。先制がない場合、高負荷の下にあるときに通過できるように、代わりに優先順位のトラフィックを保護する必要があります。実際、図10に示すように、「ロシアの人形（2）」で逆カスケードを使用すると、より優先順位のトラフィックに必要なパフォーマンスがより優先順位のために必要なパフォーマンスが達成されます。3つのシリーズのそれぞれの最初の8つのデータポイントの3つのクラスのうち。ただし、BCSを調整して、より大きな差別化を得ることができます。
For MAM, we also consider two different settings:
MAMについては、2つの異なる設定も検討します。
"Exp. Max. Alloc. (1)" BCs:
"exp。max。alloc。（1）" bcs：
up to 7 simultaneous LSPs for class 1, up to 8 simultaneous LSPs for class 2, and up to 8 simultaneous LSPs for class 3.
クラス1で最大7つの同時LSP、クラス2で最大8つの同時LSP、クラス3で最大8つの同時LSP。
"Exp. Max. Alloc. (2)" BCs:
"exp。max。alloc。（2）" bcs：
up to 7 simultaneous LSPs for class 1, with additional bandwidth for 1 LSP privately reserved up to 8 simultaneous LSPs for class 2, and up to 8 simultaneous LSPs for class 3.
クラス1の最大7つの同時LSP、1つのLSPの追加の帯域幅は、クラス2で最大8つの同時LSP、クラス3で最大8つの同時LSPを備えています。
These BCs are chosen so that, under normal conditions, the blocking performance is similar to all the previous scenarios. The only difference between these two sets of values is that the "Exp. Max. Alloc. (2)" algorithm gives class 1 a private pool of 1 server for class protection. As a result, class 1 has a relatively lower blocking especially when its traffic is above normal, as can be seen by comparing Figures 11 and 12. This comes, of course, with a slight increase in the blocking of classes 2 and 3 traffic.
これらのBCは、通常の条件下で、ブロッキングパフォーマンスが以前のすべてのシナリオに似ているように選択されます。これらの2つの値のセットの唯一の違いは、「Exp。max。Alloc。（2）」アルゴリズムがクラス1にクラス保護のための1つのサーバーのプライベートプールを提供することです。その結果、図11と12を比較することで見られるように、クラス1は、特にトラフィックが正常を上回る場合、比較的低いブロッキングをします。これは、もちろん、クラス2と3のトラフィックのブロックがわずかに増加します。
When comparing the "Russian Dolls (2)" in Figure 10 with MAM in Figures 11 or 12, the difference between their behavior and the associated explanation are again similar to the case when preemption is used. The higher degree of sharing in the cascaded bandwidth arrangement of RDM leads to a tighter coupling between the different classes of traffic when under overload. Their performance therefore tends to degrade together when the load of any one class is increased. By imposing explicit maximum bandwidth usage on each class individually, better class isolation is achieved. The trade-off is that, generally, blocking performance in MAM is somewhat higher than in RDM, because of reduced sharing.
図10の「ロシアの人形（2）」を図11または12のMAMと比較すると、その行動と関連する説明の違いは、先制が使用される場合の場合と同様です。RDMのカスケードされた帯域幅の配置でのより高い共有の程度は、過負荷の場合のさまざまなクラスのトラフィック間のより緊密な結合につながります。したがって、それらのパフォーマンスは、1つのクラスの負荷が増加すると、一緒に劣化する傾向があります。各クラスに個別に明示的な最大帯域幅の使用を課すことにより、より良いクラスの分離が達成されます。トレードオフは、一般に、MAMでのブロッキングパフォーマンスは、共有の減少のためにRDMよりもやや高いことです。
The difference in the behavior of RDM with or without preemption has already been discussed at the beginning of this section. For MAM, some notable differences can also be observed from a comparison of Figures 1 and 11. If preemption is used, higher-priority traffic tends to be able to maintain its performance despite the overloading of other classes. This is not so if preemption is not allowed. The trade-off is that, generally, the overloaded class sees a relatively higher blocking/preemption when preemption is enabled than there would be if preemption is disabled.
このセクションの冒頭で、先制の有無にかかわらずRDMの動作の違いについてすでに議論されています。MAMの場合、図1と11の比較からも顕著な違いが観察されます。先制が使用される場合、他のクラスの過負荷にもかかわらず、より優先順位のトラフィックはパフォーマンスを維持できる傾向があります。先制が許可されていない場合、これはそうではありません。トレードオフは、一般に、過負荷のクラスでは、先制が無効になっている場合よりもプリエンプションが有効になっている場合、比較的高いブロッキング/プリエンプションが見られることです。
As observed towards the end of Section 3, the partitioning of bandwidth capacity for access by different traffic classes tends to reduce the maximum link efficiency achievable. We now consider the case where there is no such partitioning, thereby resulting in full sharing of the total bandwidth among all the classes. This is referred to as the Complete Sharing Model.
セクション3の終わりに向けて観察されたように、さまざまなトラフィッククラスによるアクセスのための帯域幅容量の分割は、達成可能な最大リンク効率を低下させる傾向があります。ここで、そのようなパーティションがない場合を検討し、それにより、すべてのクラスの総帯域幅を完全に共有します。これは完全な共有モデルと呼ばれます。
For MAM, this means that the BCs are such that up to 15 simultaneous LSPs are allowed for any class.
MAMの場合、これはBCSがクラスに最大15の同時LSPが許可されるようなものであることを意味します。
Similarly, for RDM, the BCs are
同様に、RDMの場合、BCはそうです
up to 15 simultaneous LSPs for class 1 by itself, up to 15 simultaneous LSPs for classes 1 and 2 together, and up to 15 simultaneous LSPs for all three classes together.
クラス1自体で最大15の同時LSP、クラス1と2で最大15の同時LSP、3つのクラスすべてで最大15の同時LSP。
Effectively, there is now no distinction between MAM and RDM. Figure 13 shows the performance when all classes have equal access to link bandwidth under Complete Sharing.
事実上、MAMとRDMの区別はありません。図13は、すべてのクラスが完全な共有下でリンク帯域幅に平等にアクセスできるときのパフォーマンスを示しています。
With preemption being fully enabled, class 1 sees virtually no blocking, regardless of the loading conditions of the link. Since class 2 can only preempt class 3, class 2 sees some blocking and/or preemption when either class 1 load or its own load is above normal; otherwise, class 2 is unaffected by increases of class 3 load. As higher priority classes always preempt class 3 when the link is full, class 3 suffers the most, with high blocking/preemption when there is any load increase from any class. A comparison of Figures 1, 2, and 13 shows that, although the performance of both classes 1 and 2 is far superior under Complete Sharing, class 3 performance is much better off under either MAM or RDM. In a sense, class 3 is starved under overload as no protection of its traffic is being provided under Complete Sharing.
プリエンプションが完全に有効になっているため、クラス1では、リンクの負荷条件に関係なく、実質的にブロックがないと考えています。クラス2はクラス3を先制することができるため、クラス2の負荷または自己負荷のいずれかが正常を上回ると、クラス2では、ブロッキングおよび/または先制が表示されます。それ以外の場合、クラス2はクラス3の負荷の増加によって影響を受けません。より高い優先クラスは常にクラス3を先取りするため、リンクがいっぱいになると、クラス3が最も苦しみ、クラスから負荷が増加すると高いブロッキング/プリエンプションがあります。図1、2、および13の比較は、クラス1と2の両方のパフォーマンスは完全な共有下ではるかに優れているが、クラス3のパフォーマンスはMAMまたはRDMのいずれかではるかに優れていることを示しています。ある意味では、クラス3は完全な共有の下でトラフィックの保護が提供されていないため、過負荷に飢えています。
Based on the previous results, a general theme is shown to be the trade-off between bandwidth sharing and class protection/isolation. To show this more concretely, let us compare the different BCMs in terms of the overall loss probability. This quantity is defined as the long-term proportion of LSP requests from all classes combined that are lost as a result of either blocking or preemption, for a given level of offered load.
以前の結果に基づいて、一般的なテーマは、帯域幅共有とクラスの保護/分離の間のトレードオフであることが示されています。これをより具体的に示すために、全体的な損失確率の観点から異なるBCMを比較しましょう。この数量は、与えられたレベルの提供された負荷に対して、ブロッキングまたは先制のいずれかの結果として失われるすべてのクラスからのLSP要求の長期的な割合として定義されます。
As noted in the previous sections, although RDM has a higher degree of sharing than MAM, both ultimately converge to the Complete Sharing Model as the degree of sharing in each of them is increased. Figure 14 shows that, for a single link, the overall loss probability is the smallest under Complete Sharing and the largest under MAM, with that under RDM being intermediate. Expressed differently, Complete Sharing yields the highest link efficiency and MAM the lowest. As a matter of fact, the overall loss probability of Complete Sharing is identical to the loss probability of a single class as computed by the Erlang loss formula. Yet Complete Sharing has the poorest class protection capability. (Note that, in a network with many links and multiple-link routing paths, analysis in [6] showed that Complete Sharing does not necessarily lead to maximum network-wide bandwidth efficiency.)
前のセクションで述べたように、RDMはMAMよりも高い共有の程度を持っていますが、それぞれの共有の程度が増加するにつれて、最終的には完全な共有モデルに収束します。図14は、単一のリンクの場合、全体的な損失確率が完全な共有下で最小であり、MAMの下で最大であり、RDMの下では中級であることを示しています。異なる表現、完全な共有は最高のリンク効率をもたらし、最低のリンク効率をもたらします。実際のところ、完全な共有の全体的な損失確率は、Erlang損失式で計算された単一クラスの損失確率と同一です。しかし、完全な共有には、最も貧しいクラス保護機能があります。（多くのリンクと複数リンクルーティングパスを備えたネットワークでは、[6]の分析により、完全な共有が必ずしもネットワーク全体の帯域幅効率につながるとは限らないことを示したことに注意してください。）
Increasing the degree of bandwidth sharing among the different traffic classes helps increase link efficiency. Such increase, however, will lead to a tighter coupling between different classes. Under normal loading conditions, proper dimensioning of the link so that there is adequate capacity for each class can minimize the effect of such coupling. Under overload conditions, when there is a scarcity of capacity, such coupling will be unavoidable and can cause severe degradation of service to the lower-priority classes. Thus, the objective of maximizing link usage as stated in criterion (5) of Section 1 must be exercised with care, with due consideration to the effect of interactions among the different classes. Otherwise, use of this criterion alone will lead to the selection of the Complete Sharing Model, as shown in Figure 14.
さまざまなトラフィッククラス間で帯域幅共有の程度を増やすと、リンクの効率が向上します。ただし、このような増加は、異なるクラス間のより緊密な結合につながります。通常の荷重条件下では、各クラスに適切な容量があるようにリンクの適切な寸法は、そのような結合の効果を最小限に抑えることができます。過負荷条件下では、容量が不足している場合、そのような結合は避けられず、低優先度クラスへのサービスの深刻な劣化を引き起こす可能性があります。したがって、セクション1の基準（5）に記載されているように、リンクの使用量を最大化する目的は、異なるクラス間の相互作用の影響を十分に考慮して、注意して行使する必要があります。それ以外の場合、図14に示すように、この基準のみを使用するだけで、完全な共有モデルが選択されます。
The intention of criterion (2) in judging the effectiveness of different BCMs is to evaluate how they help the network achieve the expected performance. This can be expressed in terms of the blocking and/or preemption behavior as seen by different classes under various loading conditions. For example, the relative strength of a BCM can be demonstrated by examining how many times the per-class blocking or preemption probability under overload is worse than the corresponding probability under normal load.
異なるBCMの有効性を判断する際の基準（2）の意図は、ネットワークが期待されるパフォーマンスを達成するのにどのように役立つかを評価することです。これは、さまざまな負荷条件下でさまざまなクラスで見られるように、ブロッキングおよび/または先制挙動の観点から表現できます。たとえば、BCMの相対強度は、過負荷の下での一人当たりのブロックまたは先制確率の回数が通常の負荷での対応する確率よりも悪いことを調べることで実証できます。
BCMs are used in DS-TE for path computation and admission control of LSPs by enforcing different BCs for different classes of traffic so that Diffserv QoS performance can be maximized. Therefore, it is of interest to measure the performance of a BCM by the LSP blocking/preemption probabilities under various operational conditions. Based on this, the performance of RDM and MAM for LSP establishment has been analyzed and compared. In particular, three different scenarios have been examined: (1) all three classes have comparable performance objectives in terms of LSP blocking/preemption under normal conditions, (2) class 2 is given better performance at the expense of class 3, and (3) class 3 receives some minimum deterministic guarantee.
BCMは、異なるクラスのトラフィックに異なるBCを実施することにより、LSPのパス計算と入場制御のためにDS-TEで使用され、DiffServ QOSパフォーマンスを最大化できます。したがって、さまざまな運用条件下でのLSPブロッキング/先制確率によってBCMのパフォーマンスを測定することが興味深いです。これに基づいて、LSP施設のRDMとMAMのパフォーマンスが分析され、比較されました。特に、3つの異なるシナリオが検討されています。（1）3つのクラスはすべて、通常の条件下でのLSPブロッキング/プリエンプションという点で同等のパフォーマンス目標を持っています。）クラス3は、最小限の決定論的保証を受け取ります。
A general theme is the trade-off between bandwidth sharing to achieve greater efficiency under normal conditions, and to achieve robust class protection/isolation under overload. The general properties of the two BCMs are as follows:
一般的なテーマは、通常の条件下での効率を高めるための帯域幅共有のトレードオフと、過負荷での堅牢なクラス保護/分離を達成することです。2つのBCMの一般的な特性は次のとおりです。
RDM
RDM
- allows greater sharing of bandwidth among different classes
- さまざまなクラス間で帯域幅のより大きな共有を可能にします
- performs somewhat better under normal conditions
- 通常の条件下ではやや優れた性能を発揮します
- works well when preemption is fully enabled; under partial preemption, not all preemption modes work equally well
- プリエンプションが完全に有効になっている場合、うまく機能します。部分的な先制では、すべての先制モードが等しくうまく機能するわけではありません
MAM
mam
- does not depend on the use of preemption
- 先制の使用に依存しません
- is relatively insensitive to the different preemption modes when preemption is used
- 先制が使用されている場合、異なる先制モードに比較的鈍感です
- provides more robust class isolation under overload
- 過負荷の下で、より堅牢なクラスの分離を提供します
Generally, the use of preemption gives higher-priority traffic some degree of immunity to the overloading of other classes. This results in a higher blocking/preemption for the overloaded class than that in a pure blocking environment.
一般的に、先制の使用は、他のクラスの過負荷に対して、より優先順位のトラフィックにある程度の免疫を与えます。これにより、純粋なブロッキング環境よりも、過負荷のクラスのブロッキング/先制が高くなります。
This document does not introduce additional security threats beyond those described for Diffserv [10] and MPLS Traffic Engineering [11, 12, 13, 14], and the same security measures and procedures described in those documents apply here. For example, the approach for defense against theft- and denial-of-service attacks discussed in [10], which consists of the combination of traffic conditioning at Diffserv boundary nodes along with security and integrity of the network infrastructure within a Diffserv domain, may be followed when DS-TE is in use.
このドキュメントでは、DiffServ [10]およびMPLSトラフィックエンジニアリング[11、12、13、14]について説明したものを超えて追加のセキュリティ脅威を導入しておらず、これらのドキュメントで説明されている同じセキュリティ対策と手順はここに適用されます。たとえば、[10]で議論された盗難およびサービス拒否攻撃に対する防御のアプローチは、Diffserv境界ノードでのトラフィックコンディショニングの組み合わせと、Diffservドメイン内のネットワークインフラストラクチャのセキュリティと整合性で構成されています。DS-TEが使用されているときに追跡されます。
Also, as stated in [11], it is specifically important that manipulation of administratively configurable parameters (such as those related to DS-TE LSPs) be executed in a secure manner by authorized entities. For example, as preemption is an administratively configurable parameter, it is critical that its values be set properly throughout the network. Any misconfiguration in any label switch may cause new LSP setup requests either to be blocked or to unnecessarily preempt LSPs already established. Similarly, the preemption values of LSP setup requests must be configured properly; otherwise, they may affect the operation of existing LSPs.
また、[11]で述べたように、管理上構成可能なパラメーター（DS-TE LSPに関連するものなど）の操作を、認定エンティティによって安全な方法で実行することが特に重要です。たとえば、Preemptionは管理上構成可能なパラメーターであるため、ネットワーク全体でその値を適切に設定することが重要です。任意のラベルスイッチの誤解により、新しいLSPセットアップリクエストがブロックされるか、不必要にPreempt LSPが既に確立される可能性があります。同様に、LSPセットアップ要求の先制値を適切に構成する必要があります。それ以外の場合、それらは既存のLSPの動作に影響を与える可能性があります。
Inputs from Jerry Ash, Jim Boyle, Anna Charny, Sanjaya Choudhury, Dimitry Haskin, Francois Le Faucheur, Vishal Sharma, and Jing Shen are much appreciated.
Jerry Ash、Jim Boyle、Anna Charny、Sanjaya Choudhury、Dimitry Haskin、Francois Le Faucheur、Vishal Sharma、Jing Shenからのインプットは大歓迎です。
[1] Le Faucheur, F. and W. Lai, "Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering", RFC 3564, July 2003.
[1] Le Faucheur、F。およびW. Lai、「差別化されたサービス認識MPLSトラフィックエンジニアリングのサポートの要件」、RFC 3564、2003年7月。
[2] Le Faucheur, F., Ed., "Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering", RFC 4124, June 2005.
[2] Le Faucheur、F.、ed。、「Diffserv-Aware MPLS Traffic Engineeringのサポートのためのプロトコル拡張」、RFC 4124、2005年6月。
[3] Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche, D., Christian, B., and W. Lai, "Applicability Statement for Traffic Engineering with MPLS", RFC 3346, August 2002.
[3] Boyle、J.、Gill、V.、Hannan、A.、Cooper、D.、Awduche、D.、Christian、B。、およびW. Lai、「MPLSを使用した交通工学のアプリケーションステートメント」、RFC 3346、2002年8月。
[4] Le Faucheur, F. and W. Lai, "Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC 4125, June 2005.
[4] Le Faucheur、F。およびW. Lai、「Diffserv-Aware MPLSトラフィックエンジニアリングの最大割り当て帯域幅制約モデル」、RFC 4125、2005年6月。
[5] Le Faucheur, F., Ed., "Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC 4127, June 2005.
[5] Le Faucheur、F.、ed。、「Diffserv-Aware MPLSトラフィックエンジニアリングのロシア人形の帯域幅の制約モデル」、RFC 4127、2005年6月。
[6] Ash, J., "Max Allocation with Reservation Bandwidth Constraint Model for MPLS/DiffServ TE & Performance Comparisons", RFC 4126, June 2005.
[6] Ash、J。、「MPLS/DIFFSERV TE＆Performance比較の予約帯域幅制約モデルによる最大割り当て」、RFC 4126、2005年6月。
[7] F. Le Faucheur, "Considerations on Bandwidth Constraints Models for DS-TE", Work in Progress.
[7] F. Le Faucheur、「DS-TEの帯域幅制約モデルに関する考慮事項」、進行中の作業。
[8] W.S. Lai, "Traffic Engineering for MPLS," Internet Performance and Control of Network Systems III Conference, SPIE Proceedings Vol. 4865, Boston, Massachusetts, USA, 30-31 July 2002, pp. 256-267.
[8] W.S.LAI、「MPLSのトラフィックエンジニアリング」、ネットワークシステムIII会議のインターネットパフォーマンスと制御、SPIE Proceedings Vol。4865、マサチューセッツ州ボストン、米国、2002年7月30〜31日、256-267ページ。
[9] W.S. Lai, "Traffic Measurement for Dimensioning and Control of IP Networks," Internet Performance and Control of Network Systems II Conference, SPIE Proceedings Vol. 4523, Denver, Colorado, USA, 21-22 August 2001, pp. 359-367.
[9] W.S.LAI、「IPネットワークの寸法と制御のためのトラフィック測定」、インターネットパフォーマンスとネットワークシステムII Conferenceの制御、SPIE Proceedings Vol。4523、デンバー、コロラド、米国、2001年8月21〜22日、pp。359-367。
[10] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.
[10] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z。、およびW. Weiss、「差別化されたサービスの建築」、RFC 2475、1998年12月。
[11] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
[11] Awduche、D.、Malcolm、J.、Agogbua、J.、O'Dell、M。、およびJ. McManus、「MPLS上の交通工学要件」、RFC 2702、1999年9月。
[12] 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.
[12] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：LSPトンネルのRSVPへの拡張」、RFC 3209、2001年12月。
[13] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[13] Katz、D.、Kompella、K。、およびD. Yeung、「Traffic Engineering（TE）Extensions to OSPFバージョン2」、RFC 3630、2003年9月。
[14] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004.
[14] Smit、H。およびT. Li、「交通工学のための中間システム（IS-IS）拡張（TE）」、RFC 3784、2004年6月。
Author's Address
著者の連絡先
Wai Sum Lai AT&T Labs Room D5-3D18 200 Laurel Avenue Middletown, NJ 07748 USA
WAI SUM LAI AT＆T LABSルームD5-3D18 200ローレルアベニューミドルタウン、ニュージャージー07748 USA
Phone: +1 732-420-3712
EMail: wlai@att.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78およびwww.rfc-editor.org/copyright.htmlに含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。