RFC4127 日本語訳
4127 Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLSTraffic Engineering. F. Le Faucheur, Ed.. June 2005. (Format: TXT=23694 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group F. Le Faucheur, Ed. Request for Comments: 4127 Cisco Systems, Inc. Category: Experimental June 2005
ワーキンググループF.Le Faucheur、エドをネットワークでつないでください。コメントのために以下を要求してください。 4127年のシスコシステムズInc.カテゴリ: 実験的な2005年6月
Russian Dolls Bandwidth Constraints Model for
Diffserv-aware MPLS Traffic Engineering
ロシアのドールズ帯域幅規制はDiffserv意識しているMPLS交通工学のためにモデル化されます。
Status of This Memo
このメモの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This document provides specifications for one Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering, which is referred to as the Russian Dolls Model.
このドキュメントは1Bandwidth Constraints Modelのための仕様をDiffserv意識しているMPLS Traffic Engineeringに供給します。(MPLS Traffic EngineeringはロシアのドールズModelと呼ばれます)。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Specification of Requirements ..............................2
2. Contributing Authors ............................................3
3. Definitions .....................................................4
4. Russian Dolls Model Definition ..................................5
5. Example Formulas for Computing "Unreserved TE-Class [i]" with
Russian Dolls Model .............................................7
6. Receiving Both Maximum Reservable Bandwidth and Bandwidth
Constraints sub-TLVs ............................................8
7. Security Considerations .........................................8
8. IANA Considerations .............................................8
9. Acknowledgements ................................................9
Appendix A: Addressing [DSTE-REQ] Scenarios .......................10
Normative References ..............................................11
Informative References ............................................12
1. 序論…2 1.1. 要件の仕様…2 2. 作者を寄付します…3 3. 定義…4 4. ロシア人はモデル定義とめかします…5 5. ロシアのドールズで「無遠慮なTeクラス[i]」を計算するための例の定石はモデル化されます…7 6. 最大のReservable帯域幅と帯域幅規制サブTLVsの両方を受けます…8 7. セキュリティ問題…8 8. IANA問題…8 9. 承認…9 付録A: [DSTE-REQ]シナリオを記述します…10 標準の参照…11 有益な参照…12
Le Faucheur Experimental [Page 1] RFC 4127 Russian Dolls Model for DS-TE June 2005
Le Faucheurの実験的な[1ページ]RFC4127のロシアのドールズは2005年6月にDS-Teのためにモデル化されます。
1. Introduction
1. 序論
[DSTE-REQ] presents the Service Providers requirements for support of Diffserv-aware MPLS Traffic Engineering (DS-TE). This includes the fundamental requirement to be able to enforce different Bandwidth Constraints for different classes of traffic.
[DSTE-REQ]はDiffserv意識しているMPLS Traffic Engineering(DS-TE)のサポートのためのService Providers要件を提示します。 これは異なったクラスの交通に異なったBandwidth Constraintsを実施できるという基本的な要件を含んでいます。
[DSTE-REQ] also defines the concept of Bandwidth Constraints Model for DS-TE and states that "The DS-TE technical solution MUST specify at least one Bandwidth Constraints Model and MAY specify multiple Bandwidth Constraints Models".
[DSTE-REQ]は、また、DS-TEのためにBandwidth Constraints Modelの概念を定義して、「DS-TE技術的解決法は、少なくとも1Bandwidth Constraints Modelを指定しなければならなくて、複数のBandwidth Constraints Modelsを指定するかもしれません。」と述べます。
This document provides a detailed description of one particular Bandwidth Constraints Model for DS-TE which is introduced in [DSTE-REQ] and called the Russian Dolls Model (RDM).
このドキュメントは[DSTE-REQ]で導入されて、ロシアのドールズModel(RDM)と呼ばれるDS-TEに1特定のBandwidth Constraints Modelの詳述を供給します。
[DSTE-PROTO] specifies the Interior Gateway Protocol (IGP) and RSVP- TE signaling extensions for support of DS-TE. These extensions support RDM.
[DSTE-プロト]はDS-TEのサポートのためのInteriorゲートウェイプロトコル(IGP)とRSVP- TEシグナリング拡張子を指定します。 これらの拡大はRDMを支持します。
1.1. Specification of Requirements
1.1. 要件の仕様
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Le Faucheur Experimental [Page 2] RFC 4127 Russian Dolls Model for DS-TE June 2005
Le Faucheurの実験的な[2ページ]RFC4127のロシアのドールズは2005年6月にDS-Teのためにモデル化されます。
2. Contributing Authors
2. 作者を寄付します。
This document was the collective work of several authors. The text and content were contributed by the editor and the co-authors listed below. (The contact information for the editor appears in the Editor's Address section.)
このドキュメントは数人の作者の集合著作物でした。 テキストと内容はエディタと以下に記載された共著者によって寄付されました。 (エディタへの問い合わせ先はEditorのAddress部に現れます。)
Jim Boyle Kireeti Kompella Protocol Driven Networks, Inc. Juniper Networks, Inc. 1381 Kildaire Farm Road #288 1194 N. Mathilda Ave. Cary, NC 27511, USA Sunnyvale, CA 94099
ジムボイルKireeti Kompellaは駆動ネットワークInc.について議定書の中で述べます。杜松はInc.1381Kildaire農道#288 1194N.マチルダAveをネットワークでつなぎます。 ケーリー、NC 27511、米国サニーベル、カリフォルニア 94099
Phone: (919) 852-5160 EMail: kireeti@juniper.net EMail: jboyle@pdnets.com
以下に電話をしてください。 (919) 852-5160 メールしてください: kireeti@juniper.net メール: jboyle@pdnets.com
William Townsend Thomas D. Nadeau Tenor Networks Cisco Systems, Inc. 100 Nagog Park 250 Apollo Drive Acton, MA 01720 Chelmsford, MA 01824
ウィリアムタウンゼンドトーマスD.ナドーテノールはシスコシステムズInc.100Nagog公園250アポロDriveアクトン(MA)01720チェルムズフォード(MA)01824をネットワークでつなぎます。
Phone: +1-978-264-4900 Phone: +1-978-244-3051 EMail: btownsend@tenornetworks.com EMail: tnadeau@cisco.com
以下に電話をしてください。 +1-978-264-4900 以下に電話をしてください。 +1-978-244-3051 メールしてください: btownsend@tenornetworks.com メール: tnadeau@cisco.com
Darek Skalecki Nortel Networks 3500 Carling Ave, Nepean K2H 8E9
Darek Skaleckiノーテルは3500縦梁Ave、ネピアンK2H8E9をネットワークでつなぎます。
Phone: +1-613-765-2252 EMail: dareks@nortelnetworks.com
以下に電話をしてください。 +1-613-765-2252 メールしてください: dareks@nortelnetworks.com
Le Faucheur Experimental [Page 3] RFC 4127 Russian Dolls Model for DS-TE June 2005
Le Faucheurの実験的な[3ページ]RFC4127のロシアのドールズは2005年6月にDS-Teのためにモデル化されます。
3. Definitions
3. 定義
For readability a number of definitions from [DSTE-REQ] are repeated here:
読み易さにおいて、[DSTE-REQ]からの多くの定義がここで繰り返されます:
Class-Type (CT): the set of Traffic Trunks crossing a link that is
governed by a specific set of bandwidth constraints.
CT is used for the purposes of link bandwidth
allocation, constraint-based routing and admission
control. A given Traffic Trunk belongs to the same
CT on all links.
クラスタイプ(コネチカット): 特定の帯域幅規制で治められるリンクを越えるTraffic Trunksのセット。 コネチカットはリンク帯域幅配分、規制ベースのルーティング、および入場コントロールの目的に使用されます。 与えられたTraffic Trunkはすべてのリンクの上の同じコネチカットに属します。
TE-Class: A pair of:
Teクラス: 以下の1組
i. a Class-Type
i. Class-タイプ
ii. a preemption priority allowed for that Class-
Type. This means that an LSP transporting a Traffic
Trunk from that Class-Type can use that preemption
priority as the setup priority, the holding
priority, or both.
ii先取り優先は、Classがタイプするように許容しました。 これは、そのClass-タイプからTraffic Trunkを輸送するLSPがセットアップ優先権、把持優先権、または両方としてその先取り優先権を使用できることを意味します。
A number of recovery mechanisms under investigation or specification in the IETF take advantage of the concept of bandwidth sharing across particular sets of LSPs. "Shared Mesh Restoration" in [GMPLS-RECOV] and "Facility-based Computation Model" in [MPLS-BACKUP] are example mechanisms that increase bandwidth efficiency by sharing bandwidth across backup LSPs protecting against independent failures. To ensure that the notion of "Reserved (CTc)" introduced in [DSTE-REQ] is compatible with such a concept of bandwidth sharing across multiple LSPs, the wording of the "Reserved (CTc)" definition provided in [DSTE-REQ] is generalized into the following:
IETFの調査中の多くの回収機構か仕様がLSPsの特定のセットの向こう側に共有される帯域幅の概念を利用します。 [GMPLS-RECOV]の「共有されたMesh王政復古」と[MPLS-BACKUP]の「施設ベースの計算モデル」は独立している失敗から守るバックアップLSPsの向こう側に帯域幅を共有することによって帯域幅効率を増加させる例のメカニズムです。 [DSTE-REQ]で導入された「予約された(CTc)」の概念は複数のLSPsの向こう側に共有される帯域幅のそのような概念と互換性があるのを保証するために、[DSTE-REQ]に提供された「予約された(CTc)」定義の言葉遣いは以下に広められます:
Reserved (CTc): For a given Class-Type CTc ( 0 <= c <= MaxCT ), let
us define "Reserved(CTc)" as the total amount of the
bandwidth reserved by all the established LSPs which
belong to CTc.
予約された(CTc): 与えられたClass-タイプCTc(c0<=<はMaxCTと等しい)のために、CTcに属すすべての確立したLSPsによって控えられた帯域幅の総量と「予約された(CTc)」を定義しましょう。
With this generalization, the Russian Dolls Model definition provided in this document is compatible with Shared Mesh Restoration defined in [GMPLS-RECOV], so that DS-TE and Shared Mesh Protection can operate simultaneously. This assumes that Shared Mesh Restoration operates independently within each DS-TE Class-Type and does not operate across Class-Types (for example, backup LSPs protecting Primary LSPs of CTx also need to belong to CTx; Excess Traffic LSPs sharing bandwidth with Backup LSPs of CTx also need to belong to CTx).
この一般化について、本書では提供されたロシアのドールズModel定義は[GMPLS-RECOV]で定義されるShared Mesh王政復古と互換性があります、DS-TEとShared Mesh Protectionが同時に作動できるように。 これはShared Mesh王政復古は各DS-TE Class-タイプの中で独自に作動して、Class-タイプの向こう側に作動しないと仮定します(例えば、また、CTxのPrimary LSPsを保護するバックアップLSPsは、CTxに属す必要があります; また、CTxのBackup LSPsと帯域幅を共有する過剰Traffic LSPsは、CTxに属す必要があります)。
Le Faucheur Experimental [Page 4] RFC 4127 Russian Dolls Model for DS-TE June 2005
Le Faucheurの実験的な[4ページ]RFC4127のロシアのドールズは2005年6月にDS-Teのためにモデル化されます。
We also introduce the following definition:
また、私たちは以下の定義を導入します:
Reserved(CTb,q): Let us define "Reserved(CTb,q)" as the total amount
of the bandwidth reserved by all the established
LSPs that belong to CTb and have a holding priority
of q. Note that if q and CTb do not form one of the
8 possible configured TE-Classes, then there cannot
be any established LSPs that belongs to CTb and has
a holding priority of q; therefore, in this case,
Reserved(CTb,q) = 0.
予約(CTb、q): qのCTbに属して、把持を持っているすべての確立したLSPsによって控えられた帯域幅の総量として「予約(CTb、q)にされた」優先権を定義しましょう。 qとCTbが8つの可能な構成されたTE-クラスの1つを形成しないならCTbに属して、qの把持優先を持っている少しの確立したLSPsもあるはずがないことに注意してください。 したがって、この場合Reserved(CTb、q)=0。
4. Russian Dolls Model Definition
4. ロシア人はモデル定義とめかします。
RDM is defined in the following manner:
RDMは以下の方法で定義されます:
o Maximum Number of Bandwidth Constraints (MaxBC)=
Maximum Number of Class-Types (MaxCT) = 8
o 最大数の帯域幅規制(MaxBC)=最大数のクラスタイプ(MaxCT)=8
o for each value of b in the range 0 <= b <= (MaxCT - 1):
SUM (Reserved (CTc)) <= BCb,
where the SUM is across all values of c in the
range b <= c <= (MaxCT - 1)
o 範囲のbの各値のために、0<はb<=(MaxCT--1)と等しいです: SUM((CTc)を予約する)<=BCb。(そこに、SUMがc範囲b<=<=のcのすべての値のむこうにあります)。(MaxCT--1)
o BC0= Maximum Reservable Bandwidth, so that
SUM (Reserved(CTc)) <= Max-Reservable-Bw,
where the SUM is across all values of c in the
range 0 <= c <= (MaxCT - 1)
o BC0は最大のReservable Bandwidthと等しいです、SUM((CTc)を予約する)<がマックス-Reservable-Bw(SUMが範囲c0<=<=のcのすべての値のむこうにある)と等しいように(MaxCT--1)
A DS-TE LSR implementing RDM MUST support enforcement of Bandwidth Constraints in compliance with this definition.
この定義に従ってBandwidth ConstraintsのRDM MUSTサポート実施を実行するDS-TE LSR。
Both preemption within a CT and across CTs is allowed.
ともに、コネチカットとCTsの向こう側の先取りは許されています。
Where 8 CTs are active, the RDM Bandwidth Constraints can also be expressed in the following way:
また、8CTsがアクティブであるところでは、以下の方法でRDM Bandwidth Constraintsを急送できます:
- All LSPs from CT7 use no more than BC7
- BC7ほど多くでないCT7使用からのすべてのLSPs
- All LSPs from CT6 and CT7 use no more than BC6
- CT6からのすべてのLSPsとBC6ほど多くでないCT7使用
- All LSPs from CT5, CT6 and CT7 use no more than BC5
- BC5ほど多くでないCT5、CT6、およびCT7使用からのすべてのLSPs
- etc.
- など
- All LSPs from CT0, CT1, ..., CT7 use no more than BC0 = "Maximum
Reservable Bandwidth"
- CT0、CT1からのすべてのLSPs…, CT7はBC0=「最大のReservable帯域幅」だけ、を使用します。
Le Faucheur Experimental [Page 5] RFC 4127 Russian Dolls Model for DS-TE June 2005
Le Faucheurの実験的な[5ページ]RFC4127のロシアのドールズは2005年6月にDS-Teのためにモデル化されます。
Purely for illustration purposes, the diagram below represents the Russian Dolls Bandwidth Constraints Model in a pictorial manner when 3 Class-Types are active:
3つのClass-タイプが活発であるときに、純粋にイラスト目的のために、以下のダイヤグラムは絵の方法でロシアのドールズBandwidth Constraints Modelを表します:
I------------------------------------------------------I I-------------------------------I I I--------------I I I I CT2 I CT2+CT1 I CT2+CT1+CT0 I I--------------I I I I-------------------------------I I I------------------------------------------------------I
I------------------------------------------------------I I-------------------------------I I I--------------I I I I CT2I CT2+CT1I CT2+CT1+CT0I I--------------I I I I-------------------------------I I I------------------------------------------------------I
I-----BC2------> I----------------------BC1------> I------------------------------BC0=Max Reservable Bw--->
I-----BC2------>I----------------------BC1------>I------------------------------BC0はマックスReservable Bwと等しいです。--->。
While simpler Bandwidth Constraints models or, conversely, more flexible/sophisticated Bandwidth Constraints models can be defined, the Russian Dolls Model is attractive in some DS-TE environments for the following reasons:
より簡単なBandwidth Constraintsモデルか逆にフレキシブルであるか精巧なBandwidth Constraintsモデルを定義できますが、ロシアのドールズModelは以下の理由でいくつかのDS-TE環境で魅力的です:
- Although it is a little less intuitive than the Maximum
Allocation Model (see [DSTE-MAM]), RDM is still a simple model
to conceptualize.
- それはMaximum Allocation Modelほど直感的ではありませんが([DSTE-MAM]を見てください)、RDMはそれでも概念化する単純モデルです。
- RDM can be used simultaneously to ensure bandwidth efficiency
and to protect against QoS degradation of all CTs, whether
preemption is used or not.
- 同時に帯域幅効率を確実にして、すべてのCTsのQoS退行から守るのにRDMを使用できます、先取りが使用されているか否かに関係なく。
- RDM can be used in conjunction with preemption to simultaneously
achieve (i) isolation across CTs (so that each CT is guaranteed
its share of bandwidth no matter the level of contention by
other classes), (ii) bandwidth efficiency, and (iii) protection
against QoS degradation of all CTs.
- 同時にCTs(帯域幅のシェアが各コネチカットに保証されるように、他による主張のレベルが属するのは、問題でない)、(ii)帯域幅効率、およびすべてのCTsのQoS退行に対する(iii)保護の向こう側に(i) 孤立を達成するのに先取りに関連してRDMを使用できます。
- RDM only requires limited protocol extensions such as the ones
defined in [DSTE-PROTO].
- RDMは[DSTE-プロト]で定義されたものなどの限られたプロトコル拡大を必要とするだけです。
RDM may not be attractive in some DS-TE environments for the following reasons:
以下の理由で、RDMはいくつかのDS-TE環境で魅力的でないかもしれません:
- if the usage of preemption is precluded for some administrative
reason, while RDM can still ensure bandwidth efficiency and
protection against QoS degradation of all CTs, RDM cannot
guarantee isolation across Class-Types.
- 先取りの用法が何らかの管理理由で排除されるなら、RDMがすべてのCTsのQoS退行から帯域幅効率と保護をまだ守ることができる間、RDMはClass-タイプの向こう側に孤立を保証できません。
Additional considerations on the properties of RDM can be found in [BC-CONS] and [BC-MODEL].
[BCコンズ]と[紀元前-MODEL]でRDMの所有地の上の追加問題を見つけることができます。
Le Faucheur Experimental [Page 6] RFC 4127 Russian Dolls Model for DS-TE June 2005
Le Faucheurの実験的な[6ページ]RFC4127のロシアのドールズは2005年6月にDS-Teのためにモデル化されます。
As a simple example usage of the "Russian Dolls" Bandwidth Constraints Model, a network administrator, using one CT for Voice (CT1) and one CT for data (CT0), might configure on a given link:
「ロシアのドールズ」Bandwidth Constraints Modelの簡単な例の使用法として、Voiceのための1コネチカット(CT1)とデータのための1コネチカット(CT0)を使用して、ネットワーク管理者は与えられたリンクの上に以下を構成するかもしれません。
- BC0 = Max-Reservable - Bw = 2.5 Gb/s (i.e., Voice + Data is
limited to 2.5 Gb/s)
- BC0はマックス-Reservableと等しいです--Bwは2.5Gb/sと等しいです。(すなわち、Voice+データは2.5Gb/sに制限されます)
- BC1 = 1.5 Gb/s (i.e., Voice is limited to 1.5 Gb/s).
- BC1は1.5Gb/sと等しいです(すなわち、Voiceは1.5Gb/sに制限されます)。
5. Example Formulas for Computing "Unreserved TE-Class [i]" with
Russian Dolls Model
5. ロシアのドールズで「無遠慮なTeクラス[i]」を計算するための例の定石はモデル化されます。
As specified in [DSTE-PROTO], formulas for computing "Unreserved TE- Class [i]" MUST reflect all of the Bandwidth Constraints relevant to the CT associated with TE-Class[i], and thus, depend on the Bandwidth Constraints Model. Thus, a DS-TE LSR implementing RDM MUST reflect the RDM Bandwidth Constraints defined in section 4 above when computing "Unreserved TE-Class [i]".
[DSTE-プロト]で指定されるように、「無遠慮なTeのクラス[i]」を計算するための定石は、TEクラス[i]に関連しているコネチカットに関連しているBandwidth Constraintsのすべてを反映して、その結果、Bandwidth Constraints Modelによらなければなりません。 したがって、RDM MUSTを実行するDS-TE LSRは「無遠慮なTeクラス[i]」を計算しながらいつの上でセクション4で定義されたRDM Bandwidth Constraintsを反映します。
As explained in [DSTE-PROTO], the details of admission control algorithms, as well as formulas for computing "Unreserved TE-Class [i]", are outside the scope of the IETF work. Keeping that in mind, we provide in this section an example for illustration purposes, of how values for the unreserved bandwidth for TE-Class[i] might be computed with RDM. In the example, we assume the basic admission control algorithm, which simply deducts the exact bandwidth of any established LSP from all of the Bandwidth Constraints relevant to the CT associated with that LSP.
[DSTE-プロト]で説明されるように、IETF仕事の範囲の外に入場コントロールアルゴリズムの詳細、および「無遠慮なTeクラス[i]」を計算するための定石があります。 それを覚えておいて、私たちはTEクラス[i]に、無遠慮な帯域幅への値がRDMと共にどう計算されるかもしれないかに関するイラスト目的のための例をこのセクションに供給します。 例では、私たちは基本入場料コントロールアルゴリズムを仮定します。(単に、それは、そのLSPに関連しているコネチカットに関連しているBandwidth Constraintsのすべてからどんな確立したLSPの正確な帯域幅も差し引きます)。
We assume that:
私たちは、以下のことと思います。
TE-Class [i] <--> < CTc , preemption p>
TE-クラス[i]<--><CTc、先取りp>。
in the configured TE-Class mapping.
構成されたTE-クラスマッピングで。
For readability, formulas are first shown assuming only 3 CTs are active. The formulas are then extended to cover the cases where more CTs are used.
読み易さにおいて、定石は最初に、3CTsだけがアクティブであると仮定するのが示されます。 そして、定石は、より多くのCTsが使用されているケースをカバーするために広げられます。
If CTc = CT0, then "Unreserved TE-Class [i]" =
[ BC0 - SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b <= 2
CTcがCT0と等しいなら、q<のための「無遠慮なTeクラス[i]」=[BC0--SUM((CTb、q)を予約する)]はpと等しいです、そして、0<はb<=2と等しいです。
If CTc = CT1, then "Unreserved TE-Class [i]" =
MIN [
[ BC1 - SUM ( Reserved(CTb,q) ) ] for q <= p and 1 <= b <= 2,
[ BC0 - SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b <= 2
]
CTcがCT1と等しいなら、「無遠慮なTeクラス[i]」はMINと等しいです。[BC1--、SUM、(予約、(CTb、q<=pと1<=b<=2のためのq][BC0--q<=pと0<=b<=2のためのSUM((CTb、q)を予約します]]
Le Faucheur Experimental [Page 7] RFC 4127 Russian Dolls Model for DS-TE June 2005
Le Faucheurの実験的な[7ページ]RFC4127のロシアのドールズは2005年6月にDS-Teのためにモデル化されます。
If CTc = CT2, then "Unreserved TE-Class [i]" =
MIN [
[ BC2 - SUM ( Reserved(CTb,q) ) ] for q <= p and 2 <= b <= 2,
[ BC1 - SUM ( Reserved(CTb,q) ) ] for q <= p and 1 <= b <= 2,
[ BC0 - SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b <= 2
]
CTcがCT2と等しいなら、「無遠慮なTeクラス[i]」はMINと等しいです。q<のためのSUM((CTb、q)を予約する]はpと等しいです、そして、2<はb<=と等しいです。[BC2--、2 [BC1--SUM((CTb、q)を予約する)] qに関しては、<がpと等しく、1<がb<=2と等しい、[BC0--q<=pと0<=b<=2のためのSUM((CTb、q)を予約します]]
The formula can be generalized to 8 active CTs and expressed in a more compact way in the following:
公式を8アクティブなCTsに広めて、以下によりコンパクトな方法で表すことができます:
"Unreserved TE-Class [i]" =
MIN [
[ BCc - SUM ( Reserved(CTb,q) ) ] for q <= p and c <= b <= 7,
[ BC(c-1) - SUM ( Reserved(CTb,q) ) ] for q <= p and (c-1)<= b <= 7,
. . .
[ BC0 - SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b <= 7,
]
「無遠慮なTeクラス[i]」=分q<のためのSUM((CTb、q)を予約する]はpと等しいです、そして、c<はb<=と等しいです。[BCc--、7 [紀元前(c-1)--q<=pと(c-1)<=b<=7のためのSUM((CTb、q)を予約する]… [BC0--SUM((CTb、q)を予約する)] qに関して、<はpと等しく、0<はb<=7と等しいです]
where:
どこ:
TE-Class [i] <--> < CTc , preemption p>
in the configured TE-Class mapping.
TE-クラス[i]<--><CTc、構成されたTE-クラスマッピングの先取りp>。
6. Receiving Both Maximum Reservable Bandwidth and Bandwidth
Constraints sub-TLVs
6. 最大のReservable帯域幅と帯域幅規制サブTLVsの両方を受けます。
[DSTE-PROTO] states that "A DS-TE LSR, which does advertise BCs, MUST use the new "Bandwidth Constraints" sub-TLV (in addition to the existing Maximum Reservable Bandwidth sub-TLV) to do so."
「DS-TE LSR(BCsの広告を出す)はそうするのに、新しい「帯域幅規制」サブTLV(既存のMaximum Reservable BandwidthサブTLVに加えた)を使用しなければなりません。」と、[DSTE-プロト]は述べます。
With RDM, BC0 is equal to the Maximum Reservable Bandwidth because they both represent the aggregate constraint across all CTs. Thus, a DS-TE LSR, receiving both the "Maximum Reservable Bw" sub-TLV and the new "Bandwidth Constraints" sub-TLV (which contains BC0) for a given link where the RDM model is used, MAY ignore the "Maximum Reservable Bw" sub-TLV.
それらの両方がすべてのCTsの向こう側に集合規制を表すので、RDMについて、BC0はMaximum Reservable Bandwidthと等しいです。 したがって、「最大のReservable Bw」サブTLVと新しい「帯域幅規制」サブTLV(BC0を含む)の両方をRDMモデルが使用されている与えられたリンクに受けて、DS-TE LSRは「最大のReservable Bw」サブTLVを無視するかもしれません。
7. Security Considerations
7. セキュリティ問題
Security considerations related to the use of DS-TE are discussed in [DSTE-PROTO]. Those apply independently of the Bandwidth Constraints Model, including RDM specified in this document.
[DSTE-プロト]でDS-TEの使用に関連するセキュリティ問題について議論します。 それらは本書では指定されたRDMを含むBandwidth Constraints Modelの如何にかかわらず適用されます。
8. IANA Considerations
8. IANA問題
[DSTE-PROTO] defines a new name space for "Bandwidth Constraints Model Id". The guidelines for allocation of values in that name space are detailed in section 13.1 of [DSTE-PROTO]. In accordance
[DSTE-プロト]は、「帯域幅規制はイドをモデル化する」ために新しい名前スペースを定義します。 その名前スペースでの値の配分のためのガイドラインは[DSTE-プロト]のセクション13.1で詳細です。 一致で
Le Faucheur Experimental [Page 8] RFC 4127 Russian Dolls Model for DS-TE June 2005
Le Faucheurの実験的な[8ページ]RFC4127のロシアのドールズは2005年6月にDS-Teのためにモデル化されます。
with these guidelines, the IANA has assigned a Bandwidth Constraints Model Id for RDM from the range 0-239 (which is to be managed as per the "Specification Required" policy defined in [IANA-CONS]).
これらのガイドラインで、IANAはRDMのために範囲0-239(「仕様が必要である」という[IANA-コンズ]で定義された方針に従って管理されることになっています)からBandwidth Constraints Model Idを割り当てました。
Bandwidth Constraints Model Id 0 was allocated by IANA to RDM.
帯域幅Constraints Model Id0はIANAによってRDMに割り当てられました。
9. Acknowledgements
9. 承認
We thank Martin Tatham for his key contribution in this work. Tatiana Renko is also warmly thanked for her instantiation of the Russian Doll.
私たちはこの仕事における彼の主要な貢献についてマーチンTathamに感謝します。 また、タチアナRenkoは彼女のロシアのDollの具体化について暖かく感謝されます。
Le Faucheur Experimental [Page 9] RFC 4127 Russian Dolls Model for DS-TE June 2005
Le Faucheurの実験的な[9ページ]RFC4127のロシアのドールズは2005年6月にDS-Teのためにモデル化されます。
Appendix A: Addressing [DSTE-REQ] Scenarios
付録A: [DSTE-REQ]シナリオを記述します。
This appendix provides examples of how the Russian Dolls Bandwidth Constraints Model can be used to support each of the scenarios described in [DSTE-REQ].
この付録は[DSTE-REQ]で説明されたそれぞれのシナリオを支持するのにどうロシアのドールズBandwidth Constraints Modelを使用できるかに関する例を提供します。
A.1. Scenario 1: Limiting Amount of Voice
A.1。 シナリオ1: 声の量を制限します。
By configuring on every link:
あらゆるリンクの上に構成することによって:
- Bandwidth Constraint 1 (for CT1 = Voice) = "certain percentage"
of link capacity
- 帯域幅Constraint1(CT1=声のための)は「ある割合」のリンク容量と等しいです。
- BC0 (for CT1=Voice + CT0=Data) = link capacity
- BC0(CT1=声+CT0=データのための)はリンク容量と等しいです。
By configuring:
構成することによって:
- every CT1/Voice TE-LSP with preemption = 0
- 先取り=0があるあらゆるCT1/声のTE-LSP
- every CT0/Data TE-LSP with preemption = 1
- 先取り=1があるあらゆるCT0/データTE-LSP
DS-TE with the Russian Dolls Model will address all the requirements:
ロシアのドールズModelとDS-TEはすべての要件を記述するでしょう:
- amount of Voice traffic limited to desired percentage on every
link
- あらゆるリンクの上に必要な割合に制限されたVoice交通の量
- data traffic capable of using all remaining link capacity
- すべての残っているリンク容量を使用できるデータ通信量
- voice traffic capable of preempting other traffic
- 他の交通を先取りできる音声トラヒック
A.2. Scenario 2: Maintain Relative Proportion of Traffic Classes
A.2。 シナリオ2: 交通のクラスの相対的比率を維持してください。
By configuring on every link:
あらゆるリンクの上に構成することによって:
- BC2 (for CT2) = e.g., 45%
- 例えば、45BC2(CT2のための)=%
- BC1 (for CT1+CT2) = e.g., 80%
- 例えば、80BC1(CT1+CT2のための)=%
- BC0 (for CT0+CT1+CT2) = e.g., 100%
- 例えば、100BC0(CT0+CT1+CT2のための)=%
DS-TE with the RDM will ensure that the amount of traffic of each CT established on a link is within acceptable levels as compared to the resources allocated to the corresponding Diffserv Per Hop Behaviors (PHBs) regardless of which order the LSPs are routed in, regardless of which preemption priorities are used by which LSPs and regardless of failure situations.
RDMとDS-TEは、どの注文にかかわらず対応するDiffserv Per Hop Behaviors(PHBs)に割り当てられたリソースと比べて、LSPsが状況、どの先取りプライオリティがどのLSPsによって使用されるかにかかわらず失敗状況およびにかかわらず発送されるとき合格水準の中にリンクの上に確立されたそれぞれのコネチカットの交通の量があるのを確実にするでしょう。
Le Faucheur Experimental [Page 10] RFC 4127 Russian Dolls Model for DS-TE June 2005
Le Faucheurの実験的な[10ページ]RFC4127のロシアのドールズは2005年6月にDS-Teのためにモデル化されます。
By also configuring:
また、構成することによって:
- every CT2/Voice TE-LSP with preemption = 0
- 先取り=0があるあらゆるCT2/声のTE-LSP
- every CT1/Premium Data TE-LSP with preemption = 1
- 先取り=1があるあらゆるCT1/プレミアムData TE-LSP
- every CT0/Best-Effort TE-LSP with preemption = 2
- 先取り=2があるあらゆる最も良いCT0/努力TE-LSP
DS-TE with the Russian Dolls Model will also ensure that:
また、ロシアのドールズModelとDS-TEは、以下のことを確実にするでしょう。
- CT2 Voice LSPs always have first preemption priority in order to
use the CT2 capacity
- CT2 Voice LSPsには、最初の先取り優先権が、CT2容量を使用するためにいつもあります。
- CT1 Premium Data LSPs always have second preemption priority in
order to use the CT1 capacity
- CT1 Premium Data LSPsには、2番目の先取り優先権が、CT1容量を使用するためにいつもあります。
- Best-Effort can use up to link capacity of what is left by CT2
and CT1.
- 最も良い努力は、CT2とCT1によって残されるものに関する容量をリンクするのに使いきられることができます。
Optional automatic adjustment of Diffserv scheduling configuration could be used for maintaining very strict relationships between the amounts of established traffic of each Class Type and corresponding Diffserv resources.
各Class Typeと対応するDiffservリソースの確立した交通の量の間の非常に厳しい関係を維持するのにDiffservスケジューリング構成の任意の自動調整を使用できました。
A.3. Scenario 3: Guaranteed Bandwidth Services
A.3。 シナリオ3: 保証された帯域幅サービス
By configuring on every link:
あらゆるリンクの上に構成することによって:
- BC1 (for CT1) = "given" percentage of link bandwidth
(appropriate to achieve the Guaranteed Bandwidth service's QoS
objectives)
- BC1(CT1のための)は「与えられた」割合のリンク帯域幅と等しいです。(Guaranteed BandwidthサービスのQoS目的を達成する適切)です。
- BC0 (for CT0+CT1) = 100% of link bandwidth
- BC0(CT0+CT1のための)は100%のリンク帯域幅と等しいです。
DS-TE with the Russian Dolls Model will ensure that the amount of Guaranteed Bandwidth Traffic established on every link remains below the given percentage so that it will always meet its QoS objectives. At the same time, it will allow traffic engineering of the rest of the traffic such that links can be filled up.
ロシアのドールズModelとDS-TEは、あらゆるリンクの上に設立されたGuaranteed Bandwidth Trafficの量がいつもQoS目的を満たすように与えられた割合より下で残っているのを確実にするでしょう。 同時に、それは、リンクを満たすことができるように交通の残りの交通工学を許容するでしょう。
Normative References
引用規格
[DSTE-REQ] Le Faucheur, F. and W. Lai, "Requirements for Support
of Differentiated Services-aware MPLS Traffic
Engineering", RFC 3564, July 2003.
[DSTE-REQ] Le FaucheurとF.とW.レイ、「微分されたサービス意識しているMPLS交通工学のサポートのための要件」、RFC3564、2003年7月。
Le Faucheur Experimental [Page 11] RFC 4127 Russian Dolls Model for DS-TE June 2005
Le Faucheurの実験的な[11ページ]RFC4127のロシアのドールズは2005年6月にDS-Teのためにモデル化されます。
[DSTE-PROTO] Le Faucheur, F., Ed., "Protocol Extensions for Support
of Diffserv-aware MPLS Traffic Engineering", RFC 4124,
June 2005.
[DSTE-プロト] Le Faucheur、F.、エド「Diffserv意識しているMPLS交通のサポートのためのプロトコル拡大は設計すること」でのRFC4124、2005年6月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[IANA-CONS] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26, RFC
2434, October 1998.
[IANA-まやかし]Narten、T.、およびH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」、BCP26、RFC2434(1998年10月)。
Informative References
有益な参照
[BC-CONS] Le Faucheur, F., "Considerations on Bandwidth
Constraints Model for DS-TE", Work in Progress, June
2002.
F.、「帯域幅規制での問題はDS-Teのためにモデル化する」という[BCコンズ]Le Faucheurは進歩、2002年6月に働いています。
[BC-MODEL] Lai, W., "Bandwidth Constraints Models for
Differentiated Services (Diffserv)-aware MPLS Traffic
Engineering: Performance Evaluation", RFC 4128, June
2005.
[紀元前モデル]レイ、W.、「微分されたサービス(Diffserv)の意識しているMPLS交通への以下を設計する帯域幅規制モデル」 「業績評価」、RFC4128、2005年6月。
[DSTE-MAM] Le Faucheur, F. and W. Lai, "Maximum Allocation
Bandwidth Constraints Model for Diffserv-aware MPLS
Traffic Engineering", RFC 4125, June 2005.
[DSTE-MAM] Le Faucheur、F.、およびW.レイ、「最大の配分帯域幅規制はDiffserv意識しているMPLS交通工学のためにモデル化します」、RFC4125、2005年6月。
[GMPLS-RECOV] Lang, et al., "Generalized MPLS Recovery Functional
Specification", Work in Progress.
[GMPLS-RECOV] ラング、他、「一般化されたMPLS回復機能的な仕様」、ProgressのWork。
[MPLS-BACKUP] Vasseur, et al., "MPLS Traffic Engineering Fast
Reroute: Bypass Tunnel Path Computation for Bandwidth
Protection", Work in Progress.
[MPLS-BACKUP] Vasseur、他、「MPLS交通工学は速くコースを変更します」。 「帯域幅保護のための迂回トンネル経路計算」、処理中の作業。
Editor's Address
エディタのアドレス
Francois Le Faucheur Cisco Systems, Inc. Village d'Entreprise Green Side - Batiment T3 400, Avenue de Roumanille 06410 Biot-Sophia Antipolis France
フランソアLe FaucheurシスコシステムズInc.Village d'EntrepriseグリーンSide--Batiment T3 400、アベニューdeルーマニーユ06410・Biot-ソフィア・Antipolisフランス
Phone: +33 4 97 23 26 19 EMail: flefauch@cisco.com
以下に電話をしてください。 +33 4 97 23 26 19はメールされます: flefauch@cisco.com
Le Faucheur Experimental [Page 12] RFC 4127 Russian Dolls Model for DS-TE June 2005
Le Faucheurの実験的な[12ページ]RFC4127のロシアのドールズは2005年6月にDS-Teのためにモデル化されます。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Le Faucheur Experimental [Page 13]
Le Faucheur実験的です。[13ページ]
一覧
スポンサーリンク
