RFC4128 日本語訳
4128 Bandwidth Constraints Models for Differentiated Services(Diffserv)-aware MPLS Traffic Engineering: Performance Evaluation. W.Lai. June 2005. (Format: TXT=58691, PDF=201138 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group W. Lai Request for Comments: 4128 AT&T Labs Category: Informational June 2005
コメントを求めるワーキンググループW.レイ要求をネットワークでつないでください: 4128年のAT&T研究室カテゴリ: 情報の2005年6月
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)インターネット協会(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(特にInformational RFCとして公表に関する問題を全く持っていないTE-WGワーキンググループにおける)によって考えられました、そして、したがって、それは進行中の現在のIETF仕事か発行されたIETF仕事に類似するかもしれません。 しかしながら、このドキュメントはどんなレベルの候補ではなく、インターネットStandardの個々の服従です。 IETFはどんな目的、およびそれには配備されたプロトコルとのセキュリティのようなもののための完全なIETFレビュー、輻輳制御または不適当な相互作用がないという特定のメモでもこのRFCのフィットネスに関するどんな知識も放棄します。 RFC Editorは、自己判断でこのドキュメントを発表するのを選びました。 このRFCの読者は実現と展開のために値を評価する際に警戒するべきです。 詳しい情報に関してRFC3932を見てください。
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.
「微分されたServices(Diffserv)の意識しているMPLS Traffic Engineering Requirements」(RFC3564)はBandwidth Constraints Modelsの要件と選択評価基準を指定します。 そのような2つのモデル(Maximum Allocationとロシアのドールズ)が、そこに説明されます。 このドキュメントは様々な稼動状況の下でこれらの2つのモデルの業績評価の結果を提示することによって、RFC3564の補足となります: 正常な負荷、オーバーロード、完全か部分的に可能にされた先取り、純粋なブロッキング、または完全な共有。
Lai Standards Track [Page 1] RFC 4128 BC Models for Diffserv-aware MPLS TE June 2005
レイStandardsはTe2005年6月にDiffserv意識しているMPLSのためにRFC4128紀元前のモデルを追跡します[1ページ]。
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
1. 序論…3 1.1. このドキュメントで中古のコンベンション…4 2. 帯域幅規制モデル…4 3. パフォーマンスモデル…5 3.1. LSPブロッキングと先取り…6 3.2. 例のリンク交通モデル…8 3.3. 正常な負荷の下でのパフォーマンス…9 4. オーバーロードの下におけるパフォーマンス…10 4.1. 孤立に対して共有される帯域幅…10 4.2. クラス3を犠牲にしてクラス2性能を向上させます…12 4.3. 異なったモデルの帯域幅規制を比較します…13 5. 部分的な先取りでのパフォーマンス…15 5.1. ロシアのドールズはモデル化されます…16 5.2. 最大の配分モデル…16 6. 純粋なブロッキングでのパフォーマンス…17 6.1. ロシアのドールズはモデル化されます…17 6.2. 最大の配分モデル…18 7. 完全な共有でのパフォーマンス…19 8. パフォーマンス基準に関する含意…20 9. 結論…21 10. セキュリティ問題…22 11. 承認…22 12. 参照…22 12.1. 標準の参照…22 12.2. 有益な参照…22
Lai Standards Track [Page 2] RFC 4128 BC Models for Diffserv-aware MPLS TE June 2005
レイStandardsはTe2005年6月にDiffserv意識しているMPLSのためにRFC4128紀元前のモデルを追跡します[2ページ]。
1. Introduction
1. 序論
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.
微分されたServices(Diffserv)の意識しているMPLS Traffic Engineering(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.
1クラスあたりの交通工学を達成するために、むしろ、DS-TEはすべてのクラスの向こう側の集合ベースと異なったBandwidth Constraints(BCs)に異なったクラスに押しつけます。 参照[1]はBandwidth Constraints Models(BCMs)の要件と選択評価基準を個々のクラスに帯域幅を割り当てる目的に指定します。
This document presents a performance analysis for the two BCMs described in [1]:
このドキュメントは[1]で説明された2BCMsのために機能解析を提示します:
(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)の最大のAllocation Model(MAM)--それぞれのクラスの最大の許容できる帯域幅使用法であり、指定されて、すべての向こう側の集合用法と共に、クラスは明らかにそうです。
(2) Russian Dolls Model (RDM) - specification of maximum allowable
usage is done cumulatively by grouping successive priority
classes recursively.
(2)、ロシアのドールズModel(RDM)--連続した優先権のクラスを再帰的に分類することによって、累積的に最大の許容できる用法の仕様をします。
The following criteria are also listed in [1] for investigating the performance and trade-offs of different operational aspects of BCMs:
また、以下の評価基準はBCMsの異なった操作上の局面の性能とトレードオフを調査するための[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
どんな与えられたBCMの使用もネットワークが異なったクラスの交通のための保護を提供する能力に重要な影響を与えて、特に高値の下では、[3]は、パフォーマンス目標を満たすことができるようにロードされています。 このドキュメントは様々な稼動状況の下で上の2BCMsの業績評価の結果を提示することによって、[1]の補足となります: 正常な負荷、オーバーロード、完全か部分的に可能にされた先取り、純粋なブロッキング、または完全な共有。 そして、したがって、私たちの焦点が性能指向の評価基準だけにある、それら
Lai Standards Track [Page 3] RFC 4128 BC Models for Diffserv-aware MPLS TE June 2005
レイStandardsはTe2005年6月にDiffserv意識しているMPLSのためにRFC4128紀元前のモデルを追跡します[3ページ]。
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).
ネットワーク実現のための含意。 言い換えれば、私たちは評価基準(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
ロシア人がめかす紀元前の帯域幅規制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のないDiffservとDS-TEと共に言い表されて、得られたサービスの質の間には、違いがあるかもしれません。 DS-TEがConstraint Basedルート設定を使用するためとそれがDiffservに加える入場コントロール能力のタイプので、DS-TEは交通へのDiffservが持っていない能力を持っています。 Diffservは故意に先取りを示しませんが、DS-TEはClass-タイプのために複数のレベルの先取りについて説明します。 また、Diffservは明らかにオーバーブッキングを制御するどんな手段も支持しませんが、DS-TEはこれを許容します。 完全なサービスの質が環境であると考えるとき、DiffservルータとDS-TEがあるので、慎重にこれらの違いを考えるのは重要です。
1.1. Conventions used in this document
1.1. 本書では使用されるコンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119で説明されるように本書では解釈されることであるべきです。
2. Bandwidth Constraints Models
2. 帯域幅規制モデル
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.
私たちのプレゼンテーションを簡素化するために、私たちは用語の「交通のクラス」がClassタイプする非公式の名前と[1]で定義されたTE-クラスを使用します。 私たちは、(1) 交通の3つのクラスしかなくて、(2) すべてのラベルで切り換えられた経路(LSPs)がクラスにかかわらず同じ量の帯域幅を必要とすると思います。 その上、焦点が与えられた容量との個々のリンクの帯域幅使用法にあります。 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つの帯域幅を設立の後に割り当てられると思います。 これで、私たちは単に同時に確立したLSPsの数に関してリンク帯域幅用法を言い表すことができます。 そして、すべての向こう側の帯域幅用法における集合規制が属するようにリンク容量を使用できます。
Lai Standards Track [Page 4] RFC 4128 BC Models for Diffserv-aware MPLS TE June 2005
レイStandardsはTe2005年6月にDiffserv意識しているMPLSのためにRFC4128紀元前のモデルを追跡します[4ページ]。
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(最も低い優先度)によって指示されると仮定してください。 先取りが可能にされるとき、これらは先取りプライオリティです。 貸されて、上の仮定に従って私たちの分析の目的のためにBCMsの一般的なクラスを定義するために
Nmax = link capacity; i.e., the maximum number of simultaneously
established LSPs for all classes together
Nmaxはリンク容量と等しいです。 すなわち、同時の最大数はすべてのクラスのためにLSPsを一緒に設立しました。
Nc = the number of simultaneously established class c LSPs,
for c = 1, 2, and 3, respectively.
同時のNc=数はc=1、2、および3のためにそれぞれクラスc LSPsを設立しました。
For MAM, let
MAMのためにさせる。
Bc = maximum number of simultaneously established class c LSPs.
同時のBc=最大数はクラスc LSPsを設立しました。
Then, Bc is the Bandwidth Constraint for class c, and we have
次に、BcはクラスcのためのBandwidth Constraintです、そして、私たちはBandwidth Constraintであったこと。
Nc <= Bc <= Nmax, for c = 1, 2, and 3
N1 + N2 + N3 <= Nmax
B1 + B2 + B3 >= Nmax
Nc<はBc<=Nmaxと等しいです、Nmax B1+B2+B3c=1、2、および3N1+N2+N3<=>=Nmaxのために
For RDM, the BCs are specified as:
RDMにおいて、BCsは以下として指定されます。
B1 = maximum number of simultaneously established class 1 LSPs
同時のB1=最大数はクラス1LSPsを設立しました。
B2 = maximum number of simultaneously established LSPs for classes
1 and 2 together
同時のB2=最大数はクラス1と2のためにLSPsを一緒に設立しました。
B3 = maximum number of simultaneously established LSPs for classes
1, 2, and 3 together
同時のB3=最大数はクラス1、2、および3のためにLSPsを一緒に設立しました。
Then, we have the following relationships:
次に、私たちには、以下の関係があります:
N1 <= B1
N1 + N2 <= B2
N1 + N2 + N3 <= B3
B1 < B2 < B3 = Nmax
B3 B1<B2<B2 N1+N2+N3B1 N1+N2N1<=<=<=B3はNmaxと等しいです。
3. Performance Model
3. パフォーマンスモデル
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]は、BCMsの一般的なクラスを分析するために3クラスのマルコフ連鎖性能モデルを提示します。分析できるBCMsはMAMとRDM以外に他のクラスが先取りできない個人的に予約された帯域幅があるBCMsを含んでいます。
Lai Standards Track [Page 5] RFC 4128 BC Models for Diffserv-aware MPLS TE June 2005
レイStandardsはTe2005年6月にDiffserv意識しているMPLSのためにRFC4128紀元前のモデルを追跡します[5ページ]。
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の性能が評価される時の間、説明されるべきです。 すべてのBCMsに、効果は一般的でしょう、したがって、私たちが異なったBCMsの相対的パフォーマンスの比較分析における簡単さのためにそれを無視します。原則として、適当に選ばれたhyperexponential分配は、こってりのテールのいくつかの局面を得るのに使用されるかもしれません。 しかしながら、これは[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に応じて異なったクラスのLSPsにリンク帯域幅を割り当てるために入場コントロールの使用を仮定します。 したがって、リンク容量を入力して、異なったクラスから負荷を提供するとき、モデルは受け入れます。 異なったBCsの下の異なったクラスのためのブロッキングと先取り確率は出力されるように発生します。 したがって、サービスプロバイダーの見解から、必要なレベルのブロッキングと先取り性能を考えて、BCsの対応するセットを決定するのにモデルを繰り返しに使用できます。
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).
Introductionセクションで評価基準(2)、(3)、および(5)を使用する含意がBCMを選択するのを理解するために、私たちは[8]の分析のいくつかの計算結果を提示します。 これが起こることができる問題の議論を容易にすることを意図します。 主要なパフォーマンス目標は帯域幅共有の必要性(増加する帯域幅効率のための)と帯域幅孤立の必要性(異なったクラスによる帯域幅アクセスを保護するための)の間のバランスを獲得することです。
3.1. LSP Blocking and Preemption
3.1. LSPブロッキングと先取り
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
各クラスはLSP要求の到着率とLSPの平均寿命で表されるネットワークに交通の負荷を提供します。 そのような負荷のユニットはアーランです。 パケットを拠点とするネットワークでは、通常、交通量は、バイト数、そして/または、測定の期間、インタフェースの上に送るか、または受け取るパケットを数えることによって、測定されます。(ここで、私たちは関係があるだけです。
Lai Standards Track [Page 6] RFC 4128 BC Models for Diffserv-aware MPLS TE June 2005
レイStandardsはTe2005年6月にDiffserv意識しているMPLSのためにRFC4128紀元前のモデルを追跡します[6ページ]。
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レベルにおける帯域幅配分と用法で。 したがって、リンク速度の独立している方法によるリソース利用の手段として、アーランは私たちの目的[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退行を防ぐために、与えられたクラスのための確立したLSPsの予想された数は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レベルにおける入場コントロールの使用は、異なったクラスのために設立されたBCsを実施することによってQoS退行を最小にするのを助けます、採用されたBCMの規則に従って。 すなわち、BCsは、同時に異なったクラスのために様々な稼動状況の下で設立できるLSPsの数を測定するのに使用されます。 異なったクラスから認められたLSPsの数を制御することによって、これは、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目的の実施が当然のことであると仮定する場合、LSPブロッキングと先取り確率でBCMの性能を言い表すことができます。
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.
異なったBCMsには、異なった長所と短所があります。 与えられた負荷に選ばれたBCsによって、BCMは別のもので1つの操作領域と不十分によく振る舞うかもしれません。 彼らの操作上の需要を満たすことをBCMに関するユーティリティにサービスプロバイダーを主に心配させます。 どのBCMが配布されるかにかかわらず、最前の考慮はBCMが設計された負荷の下でうまくいくということです、確率を妨げるLSPのためにサービスレベル目的を提供する能力などのように。 また、BCMが「合理的に」オーバーロードをよく扱うと予想されます。 したがって、比較のために、私たちがBCMsに選ぶ一般的な操作ポイントは彼らが与えられた正常な負荷の下でのブロッキング/先取りで指定されたパフォーマンス目標を満たすということです。 そして、私たちは彼らの性能がオーバーロードの下においてどう異なるかを観測します。 以上は後でセクション4.2でこの局面に関して言われるでしょう。
Lai Standards Track [Page 7] RFC 4128 BC Models for Diffserv-aware MPLS TE June 2005
レイStandardsはTe2005年6月にDiffserv意識しているMPLSのためにRFC4128紀元前のモデルを追跡します[7ページ]。
3.2. Example Link Traffic Model
3.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
例えば、異なったクラスから最大15LSPsを許容する容量とのリンクが同時に設立されると考えてください。 すべてのLSPsには1タイム・ユニットの平均寿命があると思われます。 このリンクが提供することにされるのであるとaがロードする仮定してください。
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:
私たちは現在、3つのクラスのためのブロッキング/先取りパフォーマンス目標が正常な状況では匹敵していることが望まれている(他のシナリオは後のセクションでカバーされています)シナリオを考えます。 上の与えられた負荷の下でこのサービス必要条件を満たすために、BCsは以下の通り選択されます:
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同時のLSPs、クラス2のための最大7同時のLSPs、およびクラス3のための最大15同時のLSPs。
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同時のLSPs、クラス1と2のための一緒に最大11同時のLSPs、およびすべての3つのクラスのための一緒に最大15同時のLSPs。
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の如何にかかわらずドライバーがサービス要件であることに注意してください。 上のBCsは任意に選ばれません。 ブロッキング/先取り(次のセクションで詳細な)でそれらは、特定のパフォーマンス目標を満たすために選ばれています。
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はこれで異なったクラスでの、より高度合いの共有を持つことができます。 より高度合いのMAMには、BCsの数値が標準の下で与えられた性能必要条件を満たすためにそれらより比較的小さい場合があるくらいのカップリング手段はロードされます。
Lai Standards Track [Page 8] RFC 4128 BC Models for Diffserv-aware MPLS TE June 2005
レイStandardsはTe2005年6月にDiffserv意識しているMPLSのためにRFC4128紀元前のモデルを追跡します[8ページ]。
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が同じくらいおよそMAM BCsに対応するという上記の例では、考えであるかもしれない、(6 6 +7 6 +7 +15) (ここの意図は2BCMsのためのデザインパラメタが、異なる必要であるとまさしく指摘することです、彼らが異なって作動するとき; 厳密に言うと、数字の通信は不正確です。) もちろん、両方のBCMsはリンク容量(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が見なされることを意図しません。 それらは主に説明に役立った目的にここで使用されます。 私たちが分析に使用したメソッドは入力されるように容易にもう1セットのパラメタ値を収容できます。
3.3. Performance under Normal Load
3.3. 正常な負荷の下でのパフォーマンス
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に基づいた上記の例では、Table1で正常な状況では2BCMsを求めるLSPセットアップ要求のためのブロッキングと先取り確率を与えます。 BCsがこのシナリオが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
マム族0.03692 0.03961 0.02384 0 0.02275 0.03961 0.04659RDM0.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は2PB3がクラス3の確率を妨げるのと等しいというクラスの確率を妨げるクラス1PB2=の確率を妨げるのと等しいです。
PP2 = preemption probability of class 2 PP3 = preemption probability of class 3
PP2はクラス3の先取りクラス2PP3=確率の先取り確率と等しいです。
PB2+PP2 = combined blocking/preemption probability of class 2 PB3+PP3 = combined blocking/preemption probability of class 3
PB2+PP2はクラス3の結合したブロッキング/先取りクラス2PB3+PP3=確率の結合したブロッキング/先取り確率と等しいです。
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)のための値がそうであることを観測します。別のものへの非常に同様のもの。 これは、両方のBCMsのためにサービス必要条件(3つのクラスのための匹敵するブロッキング/先取り目的の)を満たしてあると確認します。
Lai Standards Track [Page 9] RFC 4128 BC Models for Diffserv-aware MPLS TE June 2005
レイStandardsはTe2005年6月にDiffserv意識しているMPLSのためにRFC4128紀元前のモデルを追跡します[9ページ]。
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.
そして、私たちは、RDMに、MAMのための(PB1、PB2+PP2、PB3+PP3)値が(PB1、PB2+PP2、PB3+PP3)値と非常に同様であることを観測します。 これは、両方のBCMsがこのシナリオで非常に同様の正常な負荷の下での性能を提供するのを示します。
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.
Table1に関するコラム2から、クラス1が両方のBCMsの下でまさに同じブロッキングを見るのを見ることができます。両方がクラス1だけによる使用のために最大6同時のLSPsを割り当てるので、これは明白であるべきです。 Table1における最後の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が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.
1つのクラスに関するケースのためにこれらの結果をそれらと比べるのはおもしろいです。 Erlang損失公式に基づいて、15のサーバの容量は0.0364969のブロッキング確率で10のアーランの提供された荷重をサポートすることができます。 3クラスのBCMのための総合負荷は2.7+3.5+3.5 = 9.7のアーランで、より少ないのですが、ブロッキング/先取りの確率は、より高いです。 したがって、効率のいくらかの減退が異なったトラフィックのためにクラスを収容するために仕切られるリンク帯域幅のためにあります、その結果、より少ない共有をもたらします。 この局面はさらに詳細に後でComplete Sharingでセクション7で調べられるでしょう。
4. Performance under Overload
4. オーバーロードの下におけるパフォーマンス
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.
システムの上のトラフィックがシステムのトラフィック容量よりすばらしいときに、オーバーロードは起こります。 過負荷条件の下で性能を調査するために、それぞれのクラスの荷重は別々に変えられます。 ブロッキングと先取り確率は各ケースのために別々に示されません。 それらは、結合したブロッキング/先取り確率をもたらすために合計されます。
4.1. Bandwidth Sharing versus Isolation
4.1. 分離に対して共有される帯域幅
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,
数字1と2は、セクション3.2に関する例のそれぞれのクラスの荷重がいつ別々に変えられるかを相対的パフォーマンスに示します。 それぞれそれぞれのこれらの数字の3つのシリーズに関するデータがあります。
Lai Standards Track [Page 10] RFC 4128 BC Models for Diffserv-aware MPLS TE June 2005
レイStandardsはTe2005年6月にDiffserv意識しているMPLSのためにRFC4128紀元前のモデルを追跡します[10ページ]。
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").
確率(「クラス1B」)、クラス2ブロッキング/先取り確率(「クラス2B+P」)、およびクラス3ブロッキング/先取り確率(「クラス3B+P」)を妨げるクラス1。
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.
クラス1荷重が正常な負荷の半分〜二度増強されるとき、それぞれのこれらのシリーズ、4ポイントの第一セットに、標準は性能のためのものです。 同様に、4ポイントの次と最後のセットはクラス2とクラス3荷重が対応する増強される時です。
The following observations apply to both BCMs:
以下の観測は両方のBCMsに適用されます:
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の性能はどんな変化でもクラス2かクラス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トラフィックのどちらかが(above)標準の下でいつであるか正常動作よりよく(より悪い)わかります。
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.
対照的に、2BCMsにおいて、クラス2性能のクラス1トラフィックにおける変化の影響は異なっています: それは、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は、クラス1トラフィックであるときに、MAMが使用されているとき、性能における改良(この特定の例における改良がない)がほとんど標準の下にないのがわかりますが、それは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. MAMが使用されているとき、クラス2は、クラス1トラフィックが上にあるときの性能におけるどんな退行も通常でないのを見ます。 この例には、BCs6+7<15、クラス1、およびクラス2トラフィックと共に、事実上、別々のプールのそばで役立たれるのがあります。 したがって、クラス2は先取りを全く見ません、そして、必要であるときはいつも、クラス3だけが先取りされています。 この事実はErlang損失公式によって確認されます: 6つのサーバまで提供された2.7のアーランの荷重は、0.03692が立ち塞がっているのを見ます、そして、7つのサーバまで提供された3.5のアーランの荷重は0.03961が立ち塞がっているのを見ます。 確率を妨げるこれらはまさにTable1で対応するエントリーと同じです: MAMのための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
3. これはRDMのそうではありません。 ここで、クラス2がクラス1によって先取りされる確率は2つの効果のために非零です。 (1) どっと落している帯域幅アレンジメントで、クラス3は保護されます。
Lai Standards Track [Page 11] RFC 4128 BC Models for Diffserv-aware MPLS TE June 2005
レイStandardsはTe2005年6月にDiffserv意識しているMPLSのためにRFC4128紀元前のモデルを追跡します[11ページ]。
somewhat from preemption. (2) Class 2 traffic is sharing a BC
with class 1. Consequently, class 2 suffers when class 1 traffic
increases.
いくらか先取りから。 (2) クラス2トラフィックはクラス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をする結果として起こる帯域幅が正常な状況ではうまくいきますが、そのような相互作用でクラス分離を過負荷条件の下に提供するのが、より有効でなくなるように見えます。
4.2. Improving Class 2 Performance at the Expense of Class 3
4.2. クラス3を犠牲にしてクラス2性能を向上させます。
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へのクラス3より良いブロッキング/先取り性能を与えるサービス要件がことであるシナリオを考えます。 (最小の決定論的な保証のクラス3の使用は次のセクションで考えられることです。) それで、指定されたクラス2パフォーマンス目標を満たすことができて、クラス2が紀元前であることは適切に増強されます。 例として、BCs(6、9、15)は現在、MAM、およびRDMのための(6、13、15)に使用されます。 両方のBCMsに関しては、クラス2は現在クラス1性能が変わりがありませんが、図の1bisと2bisに示されるように、より良い性能を受け取ります、クラス3を犠牲にして。 クラス3の上にこれはクラス2による帯域幅の増強されたアクセスのためにもちろんあります。 正常な状況では、LSPセットアップ要求には、2BCMsの性能は彼らのブロッキングと先取り確率において同様です、Table2に示されるように。
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
マム族0.03692 0.00658 0.02733 0 0.02709 0.00658 0.05441RDM0.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.
オーバーロードの下では、2BCMsの間の一般的な振舞いの違いに関するセクション4.1における観測はまだ適用されています、図の1bisと2bisに示されるように。
The following are two frequently asked questions about the operation of BCMs.
↓これはBCMsの操作に関する2つのFAQです。
(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のリンク容量のために、aは6の紀元前1年を分類するでしょう、そして、aはクラス3のために総ロックアウトの可能性におけるMAM結果における9の紀元前2年を分類しますか?
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
同時に設立される6クラス1と9クラス2LSPsがあるとき、確かに、これはそうになるでしょう。 そのような提供された負荷(6クラス1と9クラス2LSP要求がある)はしかしクラス1と2のための13の紀元前を結合させるRDMとのクラス3のロックアウトを引き起こさないでしょう。
Lai Standards Track [Page 12] RFC 4128 BC Models for Diffserv-aware MPLS TE June 2005
レイStandardsはTe2005年6月にDiffserv意識しているMPLSのためにRFC4128紀元前のモデルを追跡します[12ページ]。
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).
拒絶されるクラス2LSPsをもたらすでしょう。 クラス2トラフィックがクラス3トラフィックより比較的重要であると考えられるなら、(6、9、15)のBCsと共にMAMと非常に不十分に比べて、RDMは働くでしょうに。
(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.7、3.5、3.5)と思われるとき、上のシナリオがそれほど現実的でないということです、セクション3.2に述べられているように。 異なったクラスからの必要な帯域幅に従って正常動作条件がBCsの工学と両立しないので、(6、9、x)のオーバーロードを扱います。 与えられたクラスに、それはしたがって、設計された帯域幅レベルよりはるかに多くの必要性にまれでしょう。 しかし、クラスがそうしたなら、デザインと通常の交通変動に基づく期待はこのクラスがすばやく設計されたレベルに向かって不要な帯域幅をリリースするだろうということです、他のクラスのために帯域幅を開けて。
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.
サービスプロバイダーはネットワーク・コンフィギュレーションと必要な容量を測定するために交通映像に基づくそれらのネットワークを設計します。 すべてのBCMsが、現実的なネットワーク条件のもとで作動するように設計されるべきです。 したがって、どんなBCMも適切に働くように、それぞれのクラスの映し出された帯域幅の必要性に基づいたBCM自身の帯域幅配分規則の上に異なったBCsのための値の品揃えはあるに違いありません。 これは、BCMが意図している設計条件の下で予想されるように働いているのを保証するためのものです。 稼働中であり、実際の負荷はたぶんデザインのものと異なると判明するでしょう。 したがって、オーバーロードの下におけるBCMの性能の査定は、BCMが交通大波かネットワーク失敗をどれくらいよく切り抜けることができるかを確認するのに不可欠です。 この視点を反映して、2BCMsの比較の基準は彼らが正常な状態と、彼らがどうオーバーロードに耐えるかの下の同じであるか同様の性能必要条件を満たすということです。
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を較正して、微調整するために役に立つでしょう。 また、QoS退行を最小にするのにDiffservスケジューラの動態的調整を使用できました。
4.3. Comparing Bandwidth Constraints of Different Models
4.3. 異なったモデルの帯域幅規制を比較します。
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
セクション3.2で指摘されるように、RDMの異なったクラスでの、より高度の共有は、BCsの数値がMAMのためのそれらより比較的小さいかもしれないことを意味します。 私たちは、現在、さらに詳細に以下のシナリオを考えることによって、この局面を調べます。 (1) 私たちがBCsを設定するので、同じ値はクラス1に両方のBCMsに関して使用されます、クラス3のための帯域幅の同じ最小の決定論的な保証が(3) BCMsとブロッキング/先取りの両方によって提供される(2)
Lai Standards Track [Page 13] RFC 4128 BC Models for Diffserv-aware MPLS TE June 2005
レイStandardsはTe2005年6月にDiffserv意識しているMPLSのためにRFC4128紀元前のモデルを追跡します[13ページ]。
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.
確率はクラス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のためのBCs(6、7、15)、およびRDMのための(6、13、15)を使用します。 この場合、両方のBCMsはクラス1と2のために13の帯域幅を一緒に持って、クラス3だけによる使用のために2つの帯域幅を捧げます。 2BCMsの性能はTable3に正常な状況では示されます。 (6、7、15)があるMAMが3つのクラスの向こう側に匹敵するパフォーマンス目標を公正に与えるのが、明確ですが、(6、13、15)があるRDMは強くクラス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
マム族0.03692 0.03961 0.02384 0 0.02275 0.03961 0.04659RDM0.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を比較することによって、BCsの同じセットにかけられると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.
これは正常な状態の同じサービス要件が会われることであるときにRDMのためのBCsの数値がMAMのためのそれらより比較的小さい場合があるというセクション3.2における観測を確認します。 これはMAMでRDMで困難な境界から見て軟境界に対して驚くべきものであるべきではありません(B3はNmaxと等しいです)(B1+B2+B3>はNmaxと等しいです)。 BCs(B1<B2<B3)の厳しい注文は異なったクラスでの、より高度の共有の利点をRDMに与えます。 必要であるなら、より高い優先度の未使用の帯域幅を再割当てするすなわち、能力は低優先度ものに属します。 BCsの同じセットが上で例示されるように使用されているとき、その結果、これは、より良い性能に通じます。 そのようなより高程度の共有は低優先度交通のために先取りから何らかの保護を提供する最小の決定論的な帯域幅保証の使用を必要とするかもしれません。 より少ない度の共有があるとき、最小の決定論的な保証の下側の優先権のクラスの使用は実施される必要はないつもりであるかもしれませんMAMでBCsを注文する明白な不足とその軟境界が。 これはMAMのためにBCs(6、9、15)があるセクション4.2の例によって示されます。
For illustration, Table 4 shows the performance under normal conditions of RDM with BCs (6, 15, 15).
イラストに関しては、Table4はBCs(6、15、15)との正常な状況ではRDMの性能を示しています。
Lai Standards Track [Page 14] RFC 4128 BC Models for Diffserv-aware MPLS TE June 2005
レイStandardsはTe2005年6月にDiffserv意識しているMPLSのためにRFC4128紀元前のモデルを追跡します[14ページ]。
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
RDM0.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.
リンク容量の同じ集合規制で決定論的な保証が使用されていて、両方のBCMsは境界があるということであるかどうかにかかわらず。 また、両方のBCMsでは、帯域幅アクセス保証は交通変動で必ずセクション4.2で説明されるように統計的に達成されます。 (その結果、サービスレベル目的は月平均として通常指定されます、決定論的な保証よりむしろ統計的な保証の使用で。) (軟境界に対して注文し、困難)の2BCMsの基本的に異なった操作本質をこのようにして考えて、もう片方のために1BCMの寸法をデザインに採用するべきではありません。 むしろ、それは、BCMのBCsがどう選択されるかを運転するのに使用されるべきであるサービスプロバイダーのサービス要件と、恐らくまた、操作上の必要性です。
5. Performance under Partial Preemption
5. 部分的な先取りでのパフォーマンス
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を先取りできます。 すなわち両方のクラス1と2は先買権所有者によって可能にされますが、クラス2と3は先取り可能です。 先買権所有者によって可能にされたクラスはクラスが任じた低優先度先取り可能を先取りできます。 いかなる他のクラスも相対的なプライオリティにかかわらず先取り可能として指定されなかったクラスを先取りできません。
We now consider the three cases shown in Table 5, in which preemption is only partially enabled.
私たちは現在、Table5で見せられた3つのケースを考えます。そこでは、先取りが部分的に可能にされるだけです。
Table 5. Partial preemption modes
5を見送ってください。 部分的な先取りモード
preemption modes preemptor-enabled 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 3インチ(図3、6)のクラス1では、2クラス3を分類してください、「3インチ(図4、7)の1つのクラスクラス3の1、「2に関する1、+3 」 1つのクラスクラス3、(図5、8)クラス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,
このセクションでは、私たちはこれらの先取りモードがどう特定のBCMの性能に影響するかを評価します。 したがって、私たちは先取りが部分的に可能にされるとき、BCMがどれくらい同じように働くかに対して先取りが完全に可能にされるとき、与えられたBCMがどう働くかを比較しています。 これらの先取りモードの性能はRDMのための図3〜5、およびMAMのための図6〜8にそれぞれ示されます。 これらの数字のすべてで
Lai Standards Track [Page 15] RFC 4128 BC Models for Diffserv-aware MPLS TE June 2005
レイStandardsはTe2005年6月にDiffserv意識しているMPLSのためにRFC4128紀元前のモデルを追跡します[15ページ]。
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.
セクション3.2のBCsはイラストに使用されます。 すなわち(6、7、15)、MAM、およびRDMのための(6、11、15)のために。 しかしながら、BCsがセクション4.2と4.3でそれらに変わるとき、一般的な振舞いは同様です。 すなわち、(6、9、15、)および(6、13、15)、それぞれ。
5.1. Russian Dolls Model
5.1. ロシア人のドールズモデル
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) 両方のクラス2と3が先取り可能なときに、2つのモードクラス3だけがいつ先取り可能であるか、そして、(2)のための数字3と4は2つのモードのために前項と図5で2について計算します。 これらの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スペースとして、紀元前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.)
2. また、それ自身の負荷が増加されているとき、クラス3は、より高いブロッキング/先取りを見ます、それが、より頻繁にクラス1によって先取りされているとき、クラス1がクラス2を先取りできないとき。 (図2と5と比較するとき、クラス3のためのシリーズにおける4ポイントの最後のセットが図3と4で見せられるのを見てください。)
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によって先取りされていないので。 (図2と5と比較するとき、クラス2のためのシリーズにおける4ポイントの中央セットが図3と4で見せられるのを見てください。)
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セットの結果は関連します。 クラス2が可能にされた先買権所有者でないときに、クラス3荷重がこの場合増加されているとき、クラス2ブロッキング/先取りは増加されています。 (図2と3と比較するとき、クラス2のためのシリーズにおける4ポイントの最後のセットが図4と5で見せられるのを見てください。) これは両方のクラス2と3が現在リソースのために独自に互いと競争しているからです。
5.2. Maximum Allocation Model
5.2. 最大の配分モデル
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つの状況を増やすことを引き起こします。
Lai Standards Track [Page 16] RFC 4128 BC Models for Diffserv-aware MPLS TE June 2005
レイStandardsはTe2005年6月にDiffserv意識しているMPLSのためにRFC4128紀元前のモデルを追跡します[16ページ]。
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と比較するとき、クラス2のためのシリーズにおける4ポイントの第一セットが図7と8に示されるのを見てください。)
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がいつロードされるかは、増加されています。 (図1と6と比較するとき、クラス2のためのシリーズにおける4ポイントの最後のセットが図7と8で見せられるのを見てください。) これは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と比べています。RDMの振舞いは使用中の先取りモードにより依存しています。
6. Performance under Pure Blocking
6. 純粋なブロッキングでのパフォーマンス
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.
このセクションは先取りが完全に無効にされる場合をカバーします。 私たちは前項で同じリンク容量で使用して、負荷を提供する数字の例で、続きます。
6.1. Russian Dolls Model
6.1. ロシア人のドールズモデル
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同時のLSPs、クラス1と2のための一緒に最大11同時のLSPs、およびすべての3つのクラスのための一緒に最大15同時のLSPs。
"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同時のLSPs、クラス3と2のための一緒に最大14同時のLSPs、およびすべての3つのクラスのための一緒に最大15同時のLSPs。
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.
先取りが可能にされている状態でBCsの「ロシアのドールズ(1)」セットが同じくらい以前に、同じですが、「ロシアのドールズ(2)」が帯域幅の連続発生をクラスの逆順でアレンジさせることに注意してください。
Lai Standards Track [Page 17] RFC 4128 BC Models for Diffserv-aware MPLS TE June 2005
レイStandardsはTe2005年6月にDiffserv意識しているMPLSのためにRFC4128紀元前のモデルを追跡します[17ページ]。
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データポイントの3つのクラスの性能の中に非常に少ない違いがあります。 しかしながら、より大きい分化を得るためにBCsを調整できます。
6.2. Maximum Allocation Model
6.2. 最大の配分モデル
For MAM, we also consider two different settings:
また、MAMに関しては、私たちは2つの異なった設定を考えます:
"Exp. Max. Alloc. (1)" BCs:
"Exp"。 マックス。 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同時のLSPs、クラス2のための最大8同時のLSPs、およびクラス3のための最大8同時のLSPs。
"Exp. Max. Alloc. (2)" BCs:
"Exp"。 マックス。 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.
1LSPのために個人的に最大8同時のLSPsがクラス2のために予約されて、最大8同時のLSPsがクラス3のために予約された追加帯域幅でのクラス1のための最大7同時のLSPs。
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.
これらのBCsが選ばれているので、ブロッキング性能は正常な状況では前のすべてのシナリオと同様です。 これらの2セットの値の唯一の違いがその"Exp"です。 マックス。 Alloc。 (2)「アルゴリズムはクラス保護のための1つのサーバの個人的なプールをクラス1に与えます。」 その結果、特に交通が標準を超えているとき、クラス1には、比較的低いブロッキングがあります、図11と12を比較することによって見ることができるように。 これはもちろんクラス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
図10の中にMAMがある「ロシアのドールズ(2)」を比較するとき、先取りが再び使用されているとき、彼らの振舞いと関連説明の図11か12、違いがケースと同様です。 オーバーロードの下にあるとき、より高度についてRDMのどっと落している帯域幅アレンジメントを分担するのは交通の異なったクラスの間の、よりきついカップリングに通じます。 したがって彼らの性能。
Lai Standards Track [Page 18] RFC 4128 BC Models for Diffserv-aware MPLS TE June 2005
レイStandardsはTe2005年6月にDiffserv意識しているMPLSのためにRFC4128紀元前のモデルを追跡します[18ページ]。
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.
どんなクラスの荷重も増加されているとき、一緒に退行する傾向があります。 個別に明白な最大の帯域幅用法を各クラスに課すことによって、より良いクラス孤立は達成されます。 貿易オフであるのは、一般に、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の比較からいくつかの注目に値する違いを観測できます。 先取りが使用されているなら、より高い優先度交通は、他のクラスの積みすぎにもかかわらず、性能を維持できる傾向があります。 したがって、先取りが許されていないなら、これはそうではありません。 トレードオフは先取りがあるだろうより可能にされるとき、先取りが障害があるなら一般に、積みすぎられたクラスが比較的高いブロッキング/先取りを見るということです。
7. Performance under Complete Sharing
7. 完全な共有でのパフォーマンス
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の終わりに向かって観測されるように、異なった交通のクラスによるアクセスのために帯域幅容量の仕切りは、達成可能な最高のリンク効率を減少させる傾向があります。 私たちは現在そのような仕切りがないケースを考えます、その結果、すべてのクラスで総帯域幅を共有しながら、すべてなります。 これはComplete Sharing Modelと呼ばれます。
For MAM, this means that the BCs are such that up to 15 simultaneous LSPs are allowed for any class.
MAMに関しては、これは、最大15同時のLSPsがBCsがそのようなものであるのでどんなクラスのためにも許容されていることを意味します。
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.
それ自体でクラス1のための最大15同時のLSPs、クラス1と2のための一緒に最大15同時のLSPs、およびすべての3つのクラスのための一緒に最大15同時のLSPs。
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は、Complete Sharingの下の帯域幅をリンクするためにいつ、すべてのクラスには同等のアクセスがあるかを性能に示します。
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
先取りが完全に可能にされている状態で、クラス1はリンクに関する荷重条件にかかわらず実際には妨げるのを見ません。 クラス2がクラス3を先取りできるだけであるので、クラス2は、クラス1荷重かそれ自身の負荷のどちらかが上にあるときの何らかのブロッキング、そして/または、先取りが通常であるのを見ます。 さもなければ、クラス2はクラス3荷重の増加で影響を受けないです。 リンクであるときに、クラスがいつも先取りするより高い優先度として、クラス3が完全である、クラス3に最も苦しみます、どんなクラスからのどんな負荷増加もあるときの高いブロッキング/先取りで。 図1、2、および13の比較は、両方のクラス1と2の性能がComplete Sharingの下ではるかに優れていますが、クラス3性能が多くであるのを示します。
Lai Standards Track [Page 19] RFC 4128 BC Models for Diffserv-aware MPLS TE June 2005
レイStandardsはTe2005年6月にDiffserv意識しているMPLSのためにRFC4128紀元前のモデルを追跡します[19ページ]。
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.
MAMかRDMのどちらかの下では、より暮らし向きが良いです。 Complete Sharingの下で交通のノー・プロテクションを提供しているとき、ある意味で、オーバーロードの下にクラス3を飢えさせます。
8. Implications on Performance Criteria
8. パフォーマンス基準に関する含意
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.
前の結果に基づいて、一般的なテーマは、帯域幅共有とクラス保護/孤立の間のトレードオフになるように示されます。 この以上を示しているために、具体的に、総合損失確率に関して異なったBCMsを比較しましょう。 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より高度の共有がありますが、前項で注意されるように、それぞれのそれらを分担する度が増加されているのに従って、両方が結局、Complete Sharing Modelに一点に集まります。 図14は、総合損失確率は、Complete Sharingの下で最もわずかであって、MAMの下で最も大きいです、RDMの下のそれが中間的に単一のリンクに関して示します。 異なって言い表されて、Complete Sharingは最も低く最も高いリンク効率とMAMをもたらします。 実は、Erlang損失公式によって計算されるようにComplete Sharingの総合損失確率は1つのクラスの呼損率と同じです。 しかし、Complete Sharingには、最も貧しいクラス保護能力があります。 ([6]での分析が、Complete Sharingが必ず最高のネットワーク全体の帯域幅効率に通じるというわけではないのを多くのリンクと複数のリンクルーティング経路があるネットワークで示したことに注意してください。)
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)における、述べられるとしてリンク用法を最大にする目的を運動させなければなりません、異なったクラスでの相互作用の効果への当然の考慮で。 さもなければ、この評価基準の使用だけがComplete Sharing Modelの選択につながるでしょう、図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
異なったBCMsの有効性を判断することにおける、評価基準(2)の意志は彼らが、ネットワークが予想された性能を実現するのをどう助けるかを評価することです。 様々な荷重条件の下で異なったクラスによって見られるようにブロッキング、そして/または、先取りの振舞いでこれを言い表すことができます。 例えば、BCMの相対的な強さはそうすることができます。
Lai Standards Track [Page 20] RFC 4128 BC Models for Diffserv-aware MPLS TE June 2005
レイStandardsはTe2005年6月にDiffserv意識しているMPLSのためにRFC4128紀元前のモデルを追跡します[20ページ]。
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.
正常な負荷の下でオーバーロードの下における1クラスあたりのブロッキングか先取り確率が何回対応する確率より悪いかを調べることによって、示されてください。
9. Conclusions
9. 結論
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.
BCMsは、LSPsの経路計算と入場コントロールにDS-TEでDiffserv QoS性能を最大にすることができるように異なったクラスの交通に異なったBCsを実施することによって、使用されます。 したがって、様々な稼動状況の下でLSPブロッキング/先取り確率に従ったBCMの性能を測定するのは興味があります。 これに基づいて、LSP設立のためのRDMとMAMの性能を、分析されて、比較してあります。 特に、3つの異なったシナリオが調べられました: (1) (3) すべての3つのクラスには、匹敵するパフォーマンス目標が正常な状況ではLSPブロッキング/先取りであります、そして、(2) クラス3を犠牲にして、より良い性能をクラス2に与えます、そして、クラス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:
一般的なテーマは正常な状況ではより大きい効率を達成して、オーバーロードの下で体力を要しているクラス保護/孤立を達成するために共有される帯域幅の間のトレードオフです。 2BCMsの一般的な特性は以下の通りです:
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
マム族
- 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.
一般に、先取りの使用は他のクラスの積みすぎへのいくらかの免疫をより高い優先度交通に与えます。 これは積みすぎられたクラスには、純粋なブロッキング環境におけるそれより高いブロッキング/先取りをもたらします。
Lai Standards Track [Page 21] RFC 4128 BC Models for Diffserv-aware MPLS TE June 2005
レイStandardsはTe2005年6月にDiffserv意識しているMPLSのためにRFC4128紀元前のモデルを追跡します[21ページ]。
10. Security Considerations
10. セキュリティ問題
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 Traffic Engineering[11、12、13、14]のために説明されたものを超えて追加担保の脅威を導入しません、そして、同じ安全策とそれらのドキュメントで説明された手順はここに当てはまります。 DS-TEが使用中であるときに、例えば、窃盗と[10]で議論したサービス不能攻撃に対するディフェンスのためのアプローチは続かれるかもしれません。(ディフェンスはDiffservドメインの中でネットワークインフラのセキュリティと保全に伴うDiffserv境界ノードで交通調節の組み合わせから成ります)。
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 LSPsに関連するものなどの)の操作が権限のある機関によって安全な方法で実行されるのも、明確に重要です。 例えば、先取りが行政上構成可能なパラメタであるので、値がネットワーク中に適切に設定されるのは、批判的です。 どんなラベルスイッチのどんなmisconfigurationも、妨げられるか、または不必要に既に設立されたLSPsを先取りするために新しいLSPセットアップ要求を引き起こすかもしれません。 同様に、適切にLSPセットアップ要求の先取り値を構成しなければなりません。 さもなければ、それらは既存のLSPsの操作に影響するかもしれません。
11. Acknowledgements
11. 承認
Inputs from Jerry Ash, Jim Boyle, Anna Charny, Sanjaya Choudhury, Dimitry Haskin, Francois Le Faucheur, Vishal Sharma, and Jing Shen are much appreciated.
ジェリーAsh、ジム・ボイル、アンナ・シャルニー、Sanjayaチョウドリ、ドミトリー・ハスキン、フランソアLe Faucheur、Vishalシャルマ、およびジン・シンからの入力に非常に感謝します。
12. References
12. 参照
12.1. Normative References
12.1. 引用規格
[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.レイ、「微分されたサービス意識しているMPLS交通工学のサポートのための要件」、RFC3564、2003年7月。
12.2. Informative References
12.2. 有益な参照
[2] Le Faucheur, F., Ed., "Protocol Extensions for Support of
Diffserv-aware MPLS Traffic Engineering", RFC 4124, June 2005.
[2]Le Faucheur、F.、エド「Diffserv意識しているMPLS交通のサポートのためのプロトコル拡大は設計すること」でのRFC4124、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との交通工学のための適用性証明」、RFC3346(2002年8月)。
Lai Standards Track [Page 22] RFC 4128 BC Models for Diffserv-aware MPLS TE June 2005
レイStandardsはTe2005年6月にDiffserv意識しているMPLSのためにRFC4128紀元前のモデルを追跡します[22ページ]。
[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.レイ、「最大の配分帯域幅規制はDiffserv意識しているMPLS交通工学のためにモデル化します」、RFC4125、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.、RFC4127、「Diffserv意識しているMPLS交通へのロシア人のドールズ帯域幅規制モデルは設計すること」での6月2005日
[6] Ash, J., "Max Allocation with Reservation Bandwidth Constraint
Model for MPLS/DiffServ TE & Performance Comparisons", RFC 4126,
June 2005.
[6] 灰、J.、「MPLS/DiffServ Teとパフォーマンス比較のための予約帯域幅規制モデルとのマックスAllocation」、RFC4126、2005年6月。
[7] F. Le Faucheur, "Considerations on Bandwidth Constraints Models
for DS-TE", Work in Progress.
[7] 「DS-Teのための帯域幅規制モデルの上の問題」というF.Le Faucheurは進行中で働いています。
[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] 南西レイと「MPLSのための交通工学」とインターネットパフォーマンスとNetwork Systems IIIコンファレンス、SPIE Proceedings Vol.4865のControl、ボストン(マサチューセッツ)米国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] 南西レイと「IPネットワークの寸法決定とコントロールのためのトラフィック測定」とインターネットパフォーマンスとNetwork Systems IIコンファレンス、SPIE Proceedings Vol.4523のControl、デンバー(コロラド)米国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.ウィス、「微分されたサービスのための構造」RFC2475、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の上の交通工学のための要件」RFC2702(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.、Srinivasan、V.、およびG.が飲み込まれる、「RSVP-Te:」 「LSP TunnelsのためのRSVPへの拡大」、RFC3209、2001年12月。
[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.Yeung、「(Te)拡大をOSPFにバージョン2インチ設計する交通、RFC3630、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)のための拡大、」、RFC3784(2004年6月)
Lai Standards Track [Page 23] RFC 4128 BC Models for Diffserv-aware MPLS TE June 2005
レイStandardsはTe2005年6月にDiffserv意識しているMPLSのためにRFC4128紀元前のモデルを追跡します[23ページ]。
Author's Address
作者のアドレス
Wai Sum Lai AT&T Labs Room D5-3D18 200 Laurel Avenue Middletown, NJ 07748 USA
余地のD5-3D18 200ローレルアベニューミドルタウン、Wai合計レイAT&T研究室ニュージャージー07748米国
Phone: +1 732-420-3712 EMail: wlai@att.com
以下に電話をしてください。 +1 732-420-3712 メールしてください: wlai@att.com
Lai Standards Track [Page 24] RFC 4128 BC Models for Diffserv-aware MPLS TE June 2005
レイStandardsはTe2005年6月にDiffserv意識しているMPLSのためにRFC4128紀元前のモデルを追跡します[24ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78と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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Lai Standards Track [Page 25]
レイ標準化過程[25ページ]
一覧
スポンサーリンク
