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トラフィックエンジニアリングを-aware：性能評価
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).
著作権（C）インターネット協会（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の内容（具体的情報RFCとして文書に問題を有していないTE-WGワーキンググループで）IETFによって考えられているので、それは進行または公開されたIETF作業における現在のIETF仕事似ていてもよいです。しかし、この文書では、個々の提出とないインターネットStandardのどんなレベルの候補です。 IETFは、いかなる目的のために、それはセキュリティ、輻輳制御または展開されたプロトコルとの不適切な相互作用のようなもののための完全なIETFレビューを受けていない特定のノートに、このRFCのフィットネスの知識を負いません。 RFC Editorはその裁量でこの文書を公開することを選択しました。この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には、帯域幅の制約モデルの要件と選択基準を指定します。二つのそのようなモデル、最大割り当てとロシアの人形は、そこに記載されています。通常の負荷、過負荷、プリエンプションが完全または部分的に有効な、純粋なブロック、または完全な共有：この文書では、さまざまな動作条件の下でこれら二つのモデルの性能評価の結果を提示することによって、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）の-aware 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は、異なるクラスの異なる帯域幅の制約（BCS）を適用します。参照[1]は、個々のクラスに帯域幅を割り当てるために帯域幅制約モデル（のBCM）の要件と選択基準を指定します。
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）の第2のシナリオに対処する[1]
(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]。種々の動作条件の下で上記の二つの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でのDiffservで得られました。 DS-TEは、制約ベースのルーティングを使用しているため、それがDiffservのに追加アドミッション制御機能のタイプのため、DS-TEは、Diffservのがないトラフィックのための機能を備えています。 DS-TEは、そのクラスタイプのプリエンプションの複数のレベルを説明し、一方、DiffServは、意図により、プリエンプションを示すものではありません。 DS-TEがこれを可能にしながら、また、DiffServは、明示的にオーバーブッキング制御のいずれかの手段をサポートしていません。 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.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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]で定義されている用語のClass-Typeと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
本文書の目的のため、上記仮定トラフィックの三つのクラスがクラス1（最優先）、クラス2、クラス3（最低の優先順位）で表されると仮定する。プリエンプションが有効になっている場合、これらは、プリエンプションの優先順位です。上記の仮定に基づいて、当社の分析の目的のためのBCMのジェネリッククラスを定義するには、聞かせて
Nmax = link capacity; i.e., the maximum number of simultaneously established LSPs for all classes together
Nmaxは=リンク容量。即ち、一緒にすべてのクラスのために同時に確立されたLSPの最大数
Nc = the number of simultaneously established class c LSPs, for c = 1, 2, and 3, respectively.
NCは、それぞれ、C = 1の場合、同時に確立クラスC LSPの数= 2、及び3。
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
NC <= Bcの<= Nmaxで、C = 1、2、及び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
同時に確立されたクラス1 LSPのB1 =最大数
B2 = maximum number of simultaneously established LSPs for classes 1 and 2 together
一緒にクラス1および2のために同時に確立されたLSPのB2 =最大数
B3 = maximum number of simultaneously established LSPs for classes 1, 2, and 3 together
B3 =最大クラス1、2について同時に確立されたLSPの数、と一緒に3
Then, we have the following relationships:
その後、我々は次のような関係を持っています：
N1 <= B1 N1 + N2 <= B2 N1 + N2 + N3 <= B3 B1 < B2 < B3 = Nmax
H1 <= B1 H1 + H2 <H1 + B2 = H2 + NC <= KB B1 <B2 <BZ = Nmaks
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]のBCMの一般的なクラスを分析するために3級マルコフ連鎖性能モデルを提示します。解析することができるの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]におけるモデルは、それぞれのBCに応じて、異なるクラスののLSPにリンク帯域幅を割り当てるためのアドミッション制御を使用することを想定しています。したがって、モデルは、入力として、異なるクラスからリンク容量及びオファードロードを受け付けます。異なるのBCの下で異なるクラスのためのブロッキングおよびプリエンプション確率が出力として生成されます。従って、サービスプロバイダの観点から、ブロッキング及びプリエンプション性能の所望のレベルを考えると、このモデルはの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の規則に従って、異なるクラスの確立のBCを強制することによって品質劣化を最小限に抑えることができます。つまり、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のは、さまざまな長所と短所を持っています。所与の負荷のために選択されたのBCに応じて、BCMは、別に一つの動作領域と不十分でよく実行することができます。サービスプロバイダは、彼らの運用上のニーズを満たすためにBCMのユーティリティを使用して、主に懸念しています。かかわらず展開されるBCMの、一番の考慮事項は、BCMは、そのようなLSPは確率をブロックするためのサービスレベル目標を実現する機能として、設計負荷の下でうまく機能していることです。また、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.
クラス1から2.7アーラン、クラス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:
私たちは今、三つのクラスのためのブロッキング/プリエンプションパフォーマンス目標は、（他のシナリオは、後のセクションで説明します）、通常の条件下では同等であることが望まれている請求項のシナリオを検討してください。次のように上に与えられた負荷の下で、このサービスの要件を満たすために、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.
一緒にすべての3つのクラスのクラス1および2の11件の同時のLSPまで一緒に単独でクラス1の6は同時のLSP、最大、および最大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.
次のようにBCを上記の一連のための直感的な「説明は」であってもよいです。クラス1つのBCは、プリエンプションのいずれかのモデルの下で同じ（6）両方のモデルのために、クラス1として扱われるのと同じ方法です。しかし、MAMおよびRDMは根本的に異なる方法で動作し、低先取優先順位を持つクラスに異なる処理を与えます。 RDMが異なるのBCの厳密な順序付け（B1 <B2 <B3）及びハード境界（B3 = Nmaxに）課すものの、MAMは柔らかい境界（B1 + B2 + B3> = Nmaxに）使用すること部2から見ることができますなし特定の順序を持ちます。 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、+ 7 6、6 + 7 + 15）のMAMのBCに対応すると考えることができます。 （ここでの意図は、ちょうど彼らが異なる動作をするように2つのBCMのための設計パラメータは、異なる必要があることを指摘することであり、厳密に言えば、数値の対応は間違っています）もちろん、両方の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.
上記の例で選択されたのBCは、任意のサービスプロバイダによって使用される典型的な値とみなすことを意図するものではありません。彼らは、例示的な目的のために主にここで使用されています。我々は分析のために使用される方法は、容易に、入力としてパラメータ値の別のセットを収容することができます。
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.
上記の例では、選択されたのBCに基づいて二つのBCMの通常の条件下で、LSP設定要求ブロッキングとプリエンプション確率は表1に与えられているのBCが提供するサービス要求に対処するために、このシナリオのために選択されていることに注意してください三つのクラスで同等のブロッキング/プリエンプションの目標。
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
クラス1 PB2のPB1 =ブロッキング確率=クラス2 PB3のブロッキング確率=クラス3のブロッキング確率
PP2 = preemption probability of class 2 PP3 = preemption probability of class 3
PP2は、クラス3のクラス2 PP3 =プリエンプション確率のプリエンプション確率=
PB2+PP2 = combined blocking/preemption probability of class 2 PB3+PP3 = combined blocking/preemption probability of class 3
クラス2 PB3 + PP3のPB2 + PP2 =組み合わさブロッキング/プリエンプション確率クラス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）の値は互いに非常に類似している1。これは、（3クラスで同等のブロッキング/プリエンプション目標の）サービス要件は両方のBCMのために満たされていることを確認します。
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.
その後、我々は（PB1、PB2 + PP2、PB3 + PP3）はMAMの値が非常によく似ていることを観察（PB1、PB2 + PP2、PB3 + PP3）RDMの値。これは、このシナリオでは、両方の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まで割り当てるので、これは明白です。 RDMでのカスケード接続の帯域幅の分離が効果的クラス3に優先度の高いクラスによってプリエンプトさからの保護のいくつかのフォームを与えるので、これは、約来て、表1に最後の2列で示すように、わずかに良い結果が、RDMから得られます。
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.
また、MAM用のBCは、クラス1の帯域幅、そのクラス1つのニーズのいずれかのクラス2を先取りしていたことがないように選択されていることが起こるという理由だけで、PP2は、この特定のケースではゼロであることに注意してください。 （クラス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.
単一のクラスの場合のもので、これらの結果を比較することは興味深いです。アーラン損失式に基づいて、15台のサーバの容量は、0.0364969のブロッキング確率で10のアーランのオファードロードをサポートすることができます。 3クラスのBCMの合計負荷は2.7 + 3.5 + 3.5 = 9.7アーランと小さいのに対し、ブロッキング/プリエンプションの確率が高くなります。従って、原因、それによってより少ない共有その結果、異なるトラフィッククラスに適応するように区画されたリンク帯域幅効率のいくらかの損失があります。この局面は、完全な共有の第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倍に正常にその通常の負荷の半分から増加する性能のためです。クラス2とクラス3負荷が対応して増加している場合も同様に、次の4点の最後のセットがあります。
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.
クラス1は、常に他人を先取りすることができるので、2クラス1の性能は、いずれかのクラス2又はクラス3トラフィックの変化（増加または減少）に影響されません。
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のトラフィックの変化の影響は、二つの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.
MAMが使用される場合、クラス1のトラフィックが正常以下であるとき1クラス2は、性能にほとんど改善（この特定の例ではない改善）を見ているが、それは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のトラフィックが正常を上回っている性能の低下を見ません。この例では、BCの6 + 7 <15、クラス1およびクラス2のトラフィックと効果的に別々のプールによってサービス提供されています。したがって、クラス2にはプリエンプションを見ず、必要に応じてのみ、クラス3がプリエンプトされます。この事実は、アーラン損失式によって確認された：6台のサーバに提供される2.7アーランの負荷が0.03692ブロッキングを見て、そして7台のサーバーに提供3.5アーランの負荷が0.03961ブロッキングを見ています。 MAMためPB1とPB2：これらのブロッキング確率は、正確に、表1の対応するエントリと同じです。
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によってプリエンプトするために二つの効果の非ゼロです。 （1）カスケード接続された帯域幅構成により、クラス3は、プリエンプションから多少保護されています。 （2）クラス2トラフィックは、結果としてクラス1、クラス2被るクラス1のトラフィックが増加してBCを共有しています。
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の性能を維持しながら、我々は今、サービス要求は、クラス3よりもクラス2へのより良好なブロッキング/プリエンプション性能を与えることであるシナリオを考えます。 （クラス3の最小決定論的保証の使用は、次のセクションで考慮されるべきである。）指定されたクラス2パフォーマンス目標を満たすことができるようにするために、クラス2 BCを適宜増加されます。一例として、のBC（6、9、15）についてRDM（6、13、15）MAMのために使用され、。双方のBCMのために、クラス1の性能は変わらないが、図1bisと2bisに示すように、クラス2は今より良い性能を受け取り、クラス3の犠牲にこれは、クラス3を超えるクラス2によって帯域幅の増加にアクセスすることはもちろんです表2に示すように、通常の条件下では、2つのBCMの性能は、LSP設定要求のためのそれらのブロックとプリエンプション確率の点で類似しています。
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.05195
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.
図1bisと2bisに示すように、過負荷の下では、2つのBCM間の一般的な挙動の違いについて、4.1節での観測はまだ適用されます。
The following are two frequently asked questions about the operation of BCMs.
以下の二つは、しばしばのBCMの動作についての質問をしました。
(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つのBC及び9のクラス2 BCは、クラス3の総ロックアウトの可能性でMAM結果にでしょうか？
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およびクラス2つの9 LSP要求に）RDMを合わせクラス1および2のための13のBCを有するが、拒否されるクラス2つのLSPをもたらすであろうと、クラス3のロックアウトを引き起こすことはありません。クラス2トラフィックはクラス3トラフィックよりも比較的重要と考えられた場合、RDM（6、9、15）ののBCとのMAMと比較して非常に乏しい行うことになります。
(2) Should MAM with BCs of (6, 7, 15) be used instead so as to make the performance of RDM look comparable?
RDMのパフォーマンスが同等に見えるようにするために、（2）（6、7、15）ののBCとMAMべきは、代わりに使用できますか？
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節で述べたように、三つのクラスのために（2.7、3.5、3.5）とすると上記のシナリオは非常に現実的ではないということです。通常の動作条件として（X、6,9）のオーバーロードを処理して異なるクラスから必要な帯域幅に応じてのBCのエンジニアリングと互換性がありません。指定されたクラスは、その設計帯域幅レベルよりもそんなに多くを必要とすることはまれだろう。クラスがなかった場合でも、デザイン、通常のトラフィックの変動に基づいて期待は、このクラスはすぐに他のクラスのために帯域幅を解放し、その設計レベルに向かって不要な帯域幅を解放するだろうということです。
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.
運用実際には、負荷測定と予測は異なるクラスからのトラフィックがそれに応じて再配布することができるように、のBCを校正し、微調整するために有用であろう。 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内の異なるクラス間で共有の高度は、のBCの数値がMAMのものよりも相対的に小さくなる可能性があることを意味します。私たちは今、次のシナリオを考慮することにより、より詳細にこの側面を検討します。我々は、（1）両方のBCMのために、同じ値をクラス1に使用されるように、のBCを設定（2）クラス3のための帯域幅の同じ最小決定論的な保証は、両方のBCMによって提供され、そして（3）ブロッキング/プリエンプション確率クラス2のために最小化された私たちは、これが選択のBCウェイ・サービス・プロバイダではないかもしれないことを強調したいです。このような決定論的メカニズムの統計的挙動を調査するためにここで行われています。
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.
説明のために、我々は、RDMのためにMAMのためのBC（6、7、15）、および（6、13、15）を使用します。この場合、双方のBCMは、一緒にクラス1および2のための帯域幅の13個の単位を有し、そしてクラス3のみによる使用のために帯域幅の2つの単位を捧げます。通常の条件の下に2つのBCMの性能は、（6、13、15）とRDMを強く好むのに対し、（6、7、15）とのMAMは三つのクラスを横切るかなり匹敵する性能目標を与えることは明らかである。表3に示します。クラス3の犠牲にクラス2は、したがって、これらは、異なるサービス要件に応えます。
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.05195
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および図2bisを比較することにより、のBCの同じセットにさらされたときに、RDMは、クラス3がごくわずかに悪化された状態で、MAMよりクラス2はるかに良好な性能を与えることがわかります。
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のためのBCの数値はMAMのものよりも相対的に小さくすることができます。これは、MAMハード境界ソフト境界に対するRDMで（B3 = Nmax個）（B1 + B2 + B3> = Nmax個）の観点から驚くべきことではありません。 BC（B1 <B2 <B3）の厳密な順序付けは、RDMを異なるクラス間で共有のより高い程度の利点を与えます。すなわち、必要に応じて、優先度の低いものに優先度の高いクラスの未使用の帯域幅を再割り当てする能力。したがって、これは、上記例示した通りのBCの同じセットを使用するより良い性能をもたらします。共有のようなより高い程度がプリエンプションから、優先順位の低いトラフィックのためのいくつかの保護を提供するために最小決定論的帯域幅保証を使用する必要があります。 MAM中のBCの順序を明示的に不足し、そのソフトの境界は、共有の程度は低いがある場合には、優先度の低いクラスの最小決定論的保証の使用を強制する必要はないかもしれないことを示唆しています。これはMAMのためのBC（6、9、15）のセクション4.2の例により実証されます。
For illustration, Table 4 shows the performance under normal conditions of RDM with BCs (6, 15, 15).
説明のために、表4のBC（6、15、15）とRDMの通常の条件下での性能を示しています。
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は、リンク容量の同じ集計制約によって制限されています。 4.2節で説明したように、また、双方のBCMに、帯域幅アクセス保証は、必ずしも、トラフィック変動の統計的に達成されます。 （その結果、サービスレベル目標は、典型的には、統計的な保証はなく、決定論的保証の使用の下で、毎月の平均として規定されている。）したがって、2つのBCM（ソフト境界に対するハード発注）の基本的に異なる動作原理を与え、 1つのBCMの寸法は、他のために設計するために採用されるべきではありません。むしろ、それはおそらくもBCMののBCが選択されている方法を駆動するために使用されるサービス・プロバイダの運用上のニーズ、サービスの要件である、と。
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及び2はpreemptor対応している、完全にクラス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
プリエンプションモードのpreemptor対応のプリエンプト
"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
"3に1 + 2"（図3,6）クラス1、 "3に1" クラス2、クラス3（図4,7）クラス1、クラス3 "1 3 + 2の"（図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 5に図3で、それぞれMAM 8〜図6に示されています。これらの図の全てにおいて、3.2節のBCSが説明のために使用されます。即ち、MAM（6、7、15）とRDM（6、11、15）。 BCは、セクション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はプリエンプタブルであるかどうかに応じて、ある：（1）3及び4のみクラス3はプリエンプタブル2つのモードのために、二つのモードのために、前のセクションと図5の（2）図2図両方のクラス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によって占有任意のそのような領域を再利用することができません。クラス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.)
それは、クラス1、クラス2は、（クラス3のために直列に4点の最後のセットを参照してください先取りすることはできませんクラス1、でより頻繁に横取りされているとして2クラス3はまた、独自の負荷が増大し、より高いブロック/プリエンプションを見て図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.)
それはクラス1によってプリエンプトされていないので、3クラス2ブロッキング/プリエンプションは（比較した場合、図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はpreemptor有効であるかどうかに関係しています。クラス3の負荷が増大すると、クラス2はpreemptor、有効になっていない。この場合において、クラス2ブロッキング/プリエンプションが増加します。両方のクラス2及び3は、現在のリソースのために互いに独立して競合しているためである（図2及び3と比較した場合、図4及び図5に示すクラス2に対する一連の4つの点の最後のセットを参照）。
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負荷が増大した場合。 （図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の負荷が増加した場合。これはRDMと類似している（図1及び図6と比較した場合、図7および図8に示すクラス2に対する一連の4つの点の最後のセットを参照）。すなわち、クラス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は、（完全に有効プリエンプションの場合）8を介して（部分的に有効プリエンプションの場合）、図6と比較したとき、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）" のBC：
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.
一緒にすべての3つのクラスのクラス1および2の11件の同時のLSPまで一緒に単独でクラス1の6は同時のLSP、最大、および最大15件の同時のLSP。
"Russian Dolls (2)" BCs:
"ロシアの人形（2）" のBC：
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つのクラスのクラス3及び2のための14件の同時のLSPまで一緒に単独でクラス3の9つの同時のLSP、最大、および最大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.
「ロシア人形（2）」クラスの逆順に配列された帯域幅のカスケードを有しているのに対し、「ロシア人形（1）」のBCの設定されていることに注意することは、以前にプリエンプションで有効と同じです。
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節で観察されたように、カスケード接続の帯域幅の配置は、優先順位の低いトラフィックに高い優先順位トラフィックによってプリエンプションからいくつかの保護を提供することを目的としています。これは、飢餓を避けるためです。純粋なブロッキング環境では、このような保護はもはや必要ではありません。図9に示すように、実際に反対の、望ましくない効果を生じる：より高い優先度のトラフィックは、より低い優先度のトラフィックよりも高いブロッキングを見ています。ノー先取りして、優先度の高いトラフィックが、それは時に高負荷を介して取得できることを保証するために、代わりに保護する必要があります。逆カスケードは「ロシア人形（2）」で使用される場合、この特定の例では、図10に示すように、優先度の高いトラフィックブロッキング下部の要求性能が、達成される実際、パフォーマンスの間でほとんど差があります3つのシリーズのそれぞれの最初の8つのデータ点における三つのクラスの。しかし、BCSが大きな差別化を得るために調整することができます。
For MAM, we also consider two different settings:
MAMのために、我々はまた、2つの異なる設定を考えてみます。
"Exp. Max. Alloc. (1)" BCs:
"。経験最大のAlloc（1）。" のBC：
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.
最大7つの同時クラス1のLSP、クラス2のための8つの同時のLSPまで、およびクラス3 8つの同時のLSPまで。
"Exp. Max. Alloc. (2)" BCs:
"。経験最大のAlloc（2）" のBC：
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.
個人クラス2、クラス3のための8つの同時のLSPまで8つの同時のLSPまで予約1 LSPのための追加の帯域幅クラスのための1まで7つの同時の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つのセットの間の唯一の違いは、「経験。最大のAllocは、（2）」アルゴリズムは、クラス1にクラス保護のための1台のサーバーのプライベートプールを与えることです。結果として、クラス1は、比較的低いクラス2及び3トラフィックのブロッキングのわずかな増加と、当然のことながら、これは付属図11と図12を比較することによって分かるように、そのトラフィックは、正常より上である場合は特に、ブロッキングを有しています。
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.
図11または12にMAMと図10の「ロシア人形（2）」を比較する場合、それらの行動と関連する説明との差は再びプリエンプションを用いた場合と同様です。 RDMのカスケード接続の帯域幅の配置の共有度が高いが、過負荷の下で、トラフィックの異なるクラス間の緊密な結合につながります。その性能は、従って、いずれかのクラスの負荷が増加したとき一緒に劣化する傾向があります。個別に各クラスに明示的な最大帯域幅使用量を課すことによって、より良いクラス分離が達成されます。トレードオフは、一般に、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の場合、これはBCのは、最大15件の同時のLSPは、任意のクラスのために許可されているようなものであることを意味しています。
Similarly, for RDM, the BCs are
同様に、RDMのために、BCSがあります
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.
一緒にすべての3つのクラスのクラス1および2のための15件の同時のLSPまで一緒にそれ自体でクラス1のための15件の同時のLSP、まで、最大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を差し替えることができるので、いずれかのクラス1負荷または独自の負荷が正常より上である場合、クラス2は、いくつかのブロッキングおよび/またはプリエンプションを見ます。そうでなければ、クラス2、クラス3負荷の増加による影響を受けません。リンクがいっぱいになったとき、優先度の高いクラスは常にクラス3を先取りしたよう任意のクラスから任意の負荷増加があった場合、クラス3は、高いブロッキング/プリエンプションで、最も苦しんでいます。図1、図2、及び両方のクラス1及び2の性能が完全共有下ではるかに優れているが、図13の比較は、クラス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は、単一のリンクのために、全体的な損失確率がRDM下その中間であると、MAM下完全共有下の最小および最大であることを示しています。別の表現を、完全な共有は、最も高いリンク効率とMAM最低を生み出します。アーラン損失式によって計算さ実際のところ、完全な共有の全体的な損失確率は、単一のクラスの損失確率と同じです。まだ完全で共有は最貧クラスの保護機能を備えています。 （なお、多くのリンクと複数のリンクルーティングパスを持つネットワークでは、[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のは、経路計算とDiffservのQoSのパフォーマンスを最大化できるように、トラフィックの異なるクラスごとに異なるのBCを実施することにより、LSPのアドミッション制御のためのDS-TEに使用されています。したがって、様々な動作条件下でのLSPブロッキング/プリエンプション確率によってBCMの性能を測定するために重要です。これに基づいて、LSPの確立のためにRDM及びMAMの性能を分析し、比較しました。具体的には、3つの異なるシナリオが検討されている：（1）すべての3つのクラスは、クラス2、クラス3の費用でより良い性能を与えている（2）LSPブロッキング/通常の条件下でプリエンプションの点で匹敵する性能目標を有し、そして（3 ）クラス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]を超えて追加のセキュリティ上の脅威を導入しないと、それらの文書で説明したのと同じセキュリティ対策と手順が適用されます。例えば、Diffservのドメイン内のネットワークインフラストラクチャのセキュリティと完全性と共にDiffservの境界ノードでトラフィックコンディショニングの組み合わせからなるtheft-及び[10]で説明したサービス拒否攻撃に対する防御のためのアプローチは、月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に関連するものとして）管理設定可能なパラメータの操作が許可されたエンティティによって安全な方法で実行することが、具体的には重要です。プリエンプションが管理設定可能なパラメータであるように、例えば、その値がネットワーク全体に適切に設定することが重要です。任意のラベルスイッチ内の任意の設定ミスがブロックされるか、不必要に既に確立されたLSPを先取りするか、新たな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.
ジェリー・アッシュ、ジム・ボイル、アンナCharny、サンジャヤチョードリー、ドミトリーHaskin、フランソワ・ルFaucheur、ヴィシャル・シャルマ、そしてジンシェンからの入力ははるかに高く評価されています。
[1] Le Faucheur, F. and W. Lai, "Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering", RFC 3564, July 2003.
[1]ルFaucheur、F.およびW.ライ、 "差別化サービスを意識した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]ルFaucheur、F.、エド。、 "Diffservの認識MPLSトラフィックエンジニアリングのサポートのためのプロトコル拡張機能"、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]ボイル、J.、ギル、V.、阪南、A.、クーパー、D.、Awduche、D.、クリスチャン、B.、およびW.ライ、 "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]ルFaucheur、F.およびW.ライ、 "Diffservの認識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]ルFaucheur、F.、エド。、 "Diffservの認識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.
、RFC 4126、2005年6月[6]アッシュ、J.、 "MPLS / DiffServのTE＆パフォーマンスの比較のために予約の帯域幅制約モデルとの最大の割り当て"。
[7] F. Le Faucheur, "Considerations on Bandwidth Constraints Models for DS-TE", Work in Progress.
[7] F.ル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.ライ、「MPLSトラフィックエンジニアリングのための、」インターネットのパフォーマンスとネットワークシステムIII会議のコントロール、SPIE予稿集。 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.ライ、「寸法およびIPネットワークの制御のためのトラフィック測定、」インターネットのパフォーマンスとネットワークシステムII会議、SPIE予稿集のコントロール。 4523、デンバー、コロラド州、アメリカ、2001年8月21〜22頁。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]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.、およびW.ワイス、 "差別化サービスのためのアーキテクチャ"、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.、マルコム、J.、Agogbua、J.、オデル、M.、およびJ.マクマナス、 "トラフィック過剰性能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.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：ExtensionsがLSPトンネルのためのRSVPする"、RFC 3209年12月2001。
[13] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[13]カッツ、D.、Kompella、K.、およびD.ヨン、 "OSPFバージョン2へのトラフィックエンジニアリング（TE）拡張機能"、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]スミット、H.、およびT.李、 "トラフィックエンジニアリング（TE）のための中間システム中間システム（IS-IS）への拡張"、RFC 3784、2004年6月。
Author's Address
著者のアドレス
Wai Sum Lai AT&T Labs Room D5-3D18 200 Laurel Avenue Middletown, NJ 07748 USA
ワイ合計ライAT＆T LabsのルームD5-3D18 200ローレルアベニューミドルタウン、NJ 07748 USA
Phone: +1 732-420-3712 EMail: wlai@att.com
電話：+1 732-420-3712電子メール：wlai@att.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。