RFC4125 日本語訳
4125 Maximum Allocation Bandwidth Constraints Model for Diffserv-awareMPLS Traffic Engineering. F. Le Faucheur, W. Lai. June 2005. (Format: TXT=22585 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group F. Le Faucheur
Request for Comments: 4125 Cisco Systems, Inc.
Category: Experimental W. Lai
AT&T Labs
June 2005
Le Faucheurがコメントのために要求するワーキンググループF.をネットワークでつないでください: 4125年のシスコシステムズInc.カテゴリ: 実験的なW.レイAT&T研究室2005年6月
Maximum Allocation 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 Maximum Allocation Model.
このドキュメントは1Bandwidth Constraints Modelのための仕様をDiffserv意識しているMPLS Traffic Engineeringに供給します。(MPLS Traffic EngineeringはMaximum Allocation Modelと呼ばれます)。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Specification of Requirements ..............................2
2. Definitions .....................................................2
3. Maximum Allocation Model Definition .............................3
4. Example Formulas for Computing "Unreserved TE-Class [i]" with
Maximum Allocation Model.........................................6
5. Security Considerations .........................................7
6. IANA Considerations .............................................7
7. Acknowledgements ................................................7
Appendix A: Addressing [DSTE-REQ] Scenarios.........................8
Normative References...............................................10
Informative References.............................................10
1. 序論…2 1.1. 要件の仕様…2 2. 定義…2 3. 最大の配分モデル定義…3 4. 最大の配分で「無遠慮なTeクラス[i]」を計算するための例の定石はモデル化されます…6 5. セキュリティ問題…7 6. IANA問題…7 7. 承認…7 付録A: [DSTE-REQ]シナリオを記述します…8 標準の参照…10 有益な参照…10
Le Faucheur & Lai Experimental [Page 1] RFC 4125 Maximum Allocation Model for DS-TE June 2005
Le Faucheurとレイ実験的な[1ページ]RFC4125の最大のAllocationは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 Maximum Allocation Model (MAM).
このドキュメントは1特定のBandwidth Constraints Modelの詳述をDS-TEに供給します。(DS-TEは[DSTE-REQ]で導入されて、Maximum Allocation Model(MAM)と呼ばれます)。
[DSTE-PROTO] specifies the IGP and RSVP-TE signaling extensions for support of DS-TE. These extensions support MAM.
[DSTE-プロト]はDS-TEのサポートのための拡大に合図するIGPとRSVP-TEを指定します。 これらの拡大はMAMを支持します。
1.1. Specification of Requirements
1.1. 要件の仕様
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. Definitions
2. 定義
For readability, a number of definitions from [DSTE-REQ] 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.
クラスタイプ(コネチカット): Bandwidth Constraintsの特定のセットによって治められるリンクを越える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 set-up priority, as the holding
priority or both.
ii先取り優先は、Classがタイプするように許容しました。 これは、そのClass-タイプからTraffic Trunkを輸送するLSPがセットアップ優先権としてその先取り優先権を使用できることを意味します、把持優先権か両方として。
Le Faucheur & Lai Experimental [Page 2] RFC 4125 Maximum Allocation Model for DS-TE June 2005
Le Faucheurとレイ実験的な[2ページ]RFC4125の最大のAllocationは2005年6月にDS-Teのためにモデル化されます。
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 Maximum Allocation 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).
この一般化について、本書では提供されたMaximum Allocation 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に属す必要があります)。
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。
3. Maximum Allocation Model Definition
3. 最大の配分モデル定義
MAM is defined in the following manner:
MAMは以下の方法で定義されます:
o Maximum Number of Bandwidth Constraints (MaxBC) =
Maximum Number of Class-Types (MaxCT) = 8
o 最大数の帯域幅規制(MaxBC)=最大数のクラスタイプ(MaxCT)=8
o for each value of c in the range 0 <= c <= (MaxCT - 1):
Reserved (CTc) <= BCc <= Max-Reservable-Bandwidth,
o 範囲のcの各値のために、0<はc<=(MaxCT--1)と等しいです: BCc予約された(CTc)<=<はマックスReservable Bandwidthと等しいです。
Le Faucheur & Lai Experimental [Page 3] RFC 4125 Maximum Allocation Model for DS-TE June 2005
Le Faucheurとレイ実験的な[3ページ]RFC4125の最大のAllocationは2005年6月にDS-Teのためにモデル化されます。
o SUM (Reserved(CTc)) <= Max-Reservable-Bandwidth
where the SUM is across all values of c in the range
0 <= c <= (MaxCT - 1)
o SUM((CTc)を予約する)<はSUMが範囲c0<=<=のcのすべての値のむこうにあるマックスReservable Bandwidthと等しいです。(MaxCT--1)
A DS-TE LSR implementing MAM MUST support enforcement of Bandwidth Constraints in compliance with this definition.
マム族を実行するDS-TE LSRはこの定義に従ってBandwidth Constraintsの実施を支持しなければなりません。
To increase the degree of bandwidth sharing among the different CTs, the sum of Bandwidth Constraints may exceed the Maximum Reservable Bandwidth, so that the following relationship may hold true:
異なったCTsの中で共有される帯域幅の度合いを増加させるように、Bandwidth Constraintsの合計はMaximum Reservable Bandwidthを超えるかもしれません、以下の関係が有効であることができるように:
o SUM (BCc) > Max-Reservable-Bandwidth,
where the SUM is across all values of c in the range
0 <= c <= (MaxCT - 1)
o SUM(BCc)>マックスReservable Bandwidth。(そこに、SUMが範囲c0<=<=のcのすべての値のむこうにあります)。(MaxCT--1)
The sum of Bandwidth Constraints may also be equal to (or below) the Maximum Reservable Bandwidth. In that case, the Maximum Reservable Bandwidth does not actually constrain CT bandwidth reservations (in other words, the 3rd bullet item of the MAM definition above will never effectively come into play). This is because the 2nd bullet item of the MAM definition above implies that:
また、Bandwidth Constraintsの合計はMaximum Reservable Bandwidthが(or below)と等しいことであるかもしれません。 その場合、Maximum Reservable Bandwidthは実際にコネチカットの帯域幅の予約を抑制しません(言い換えれば、事実上、上のMAM定義の第3弾丸の品目はプレーに決して入らないでしょう)。 上のMAM定義の第2弾丸の品目がそれを含意するので、これは以下の通りです。
SUM (reserved(CTc)) <= SUM (BCc)
合計((CTc)を予約する)<=合計(BCc)
and we assume here that
そして、私たちはここでそれを仮定します。
SUM (BCc) <= Maximum Reservable Bandwidth.
合計(BCc)<は最大のReservable帯域幅と等しいです。
Therefore, it will always be true that:
したがって、以下のことはいつも本当になるでしょう。
SUM (Reserved(CTc)) <= Max-Reservable-Bandwidth.
合計((CTc)を予約する)<はマックスReservable Bandwidthと等しいです。
Both preemption within a CT and across CTs is allowed.
ともに、コネチカットとCTsの向こう側の先取りは許されています。
Where 8 CTs are active, the MAM Bandwidth Constraints can also be expressed in the following way:
また、8CTsがアクティブであるところでは、以下の方法でMAM Bandwidth Constraintsを急送できます:
- All LSPs from CT7 use no more than BC7
- BC7ほど多くでないCT7使用からのすべてのLSPs
- All LSPs from CT6 use no more than BC6
- BC6ほど多くでないCT6使用からのすべてのLSPs
- All LSPs from CT5 use no more than BC5
- BC5ほど多くでないCT5使用からのすべてのLSPs
- etc.
- など
- All LSPs from CT0 use no more than BC0
- BC0ほど多くでないCT0使用からのすべてのLSPs
Le Faucheur & Lai Experimental [Page 4] RFC 4125 Maximum Allocation Model for DS-TE June 2005
Le Faucheurとレイ実験的な[4ページ]RFC4125の最大のAllocationは2005年6月にDS-Teのためにモデル化されます。
- All LSPs from all CTs collectively use no more than the Maximum
Reservable Bandwidth
- すべてのCTsからのすべてのLSPsがMaximum Reservable Bandwidthよりいいえをまとめて使用します。
Purely for illustration purposes, the diagram below represents MAM in a pictorial manner when 3 CTs are active:
3CTsがアクティブであるときに、純粋にイラスト目的のために、以下のダイヤグラムは絵の方法でMAMを表します:
I----------------------------I
<---BC0---> I
I---------I I
I I I
I CT0 I I
I I I
I---------I I
I I
I I
<-------BC1-------> I
I-----------------I I
I I I
I CT1 I I
I I I
I-----------------I I
I I
I I
<-----BC2-----> I
I-------------I I
I I I
I CT2 I I
I I I
I-------------I I
I I
I CT0+CT1+CT2 I
I I
I----------------------------I
I----------------------------I<。---BC0--->I I---------I I I I I I CT0I I I I I I---------I I I I I I<。-------BC1------->I I-----------------I I I I I I CT1I I I I I I-----------------I I I I I I<。-----BC2----->I I-------------I I I I I I CT2I I I I I I-------------I I I I I CT0+CT1+CT2I I I I----------------------------I
<--Max Reservable Bandwidth-->
<--マックスReservable Bandwidth-->。
(Note that, in this illustration, the sum BC0 + BC1 + BC2 exceeds the Max Reservable Bandwidth.)
(合計BC0+BC1+BC2がこのイラストでマックスReservable Bandwidthを超えていることに注意してください。)
While more flexible/sophisticated Bandwidth Constraints Models can be defined (and are indeed defined; see [DSTE-RDM]), the Maximum Allocation Model is attractive in some DS-TE environments for the following reasons:
フレキシブルであるか高性能のBandwidth Constraints Modelsを定義できる、(本当に、定義される、; 以下の理由で、Maximum Allocation ModelがいくつかのDS-TE環境で魅力的であることを見てください[DSTE-RDM):
- Network administrators generally find MAM simple and intuitive
- 一般に、ネットワーク管理者は、MAMが簡単であって、直感的であることがわかります。
Le Faucheur & Lai Experimental [Page 5] RFC 4125 Maximum Allocation Model for DS-TE June 2005
Le Faucheurとレイ実験的な[5ページ]RFC4125の最大のAllocationは2005年6月にDS-Teのためにモデル化されます。
- MAM matches simple bandwidth control policies that Network
Administrators may want to enforce, such as setting an
individual Bandwidth Constraint for a given type of traffic
(a.k.a. Class-Type) and simultaneously limit the aggregate of
reserved bandwidth across all types of traffic.
- MAMはNetwork Administratorsが与えられたタイプの交通への個々のBandwidth Constraintを設定するのなどように(通称Class-タイプ)を実施して、同時にすべてのタイプの交通の向こう側に予約された帯域幅の集合を制限したがっているかもしれない簡単な帯域幅コントロール方針に合っています。
- MAM can be used in a way which ensures isolation across Class-
Types, whether preemption is used or not.
- 先取りが使用されているか否かに関係なく、Classタイプの向こう側に孤立を確実にする方法でMAMを使用できます。
- MAM can simultaneously achieve isolation, bandwidth efficiency,
and protection against QoS degradation of the premium CT.
- MAMは同時に、プレミアムコネチカットのQoS退行に対する孤立、帯域幅効率、および保護を達成できます。
- MAM only requires limited protocol extensions such as the ones
defined in [DSTE-PROTO].
- MAMは[DSTE-プロト]で定義されたものなどの限られたプロトコル拡大を必要とするだけです。
MAM may not be attractive in some DS-TE environments because:
MAMがいくつかのDS-TE環境で魅力的でないかもしれない、:
- MAM cannot simultaneously achieve isolation, bandwidth
efficiency, and protection against QoS degradation of CTs other
than the Premium CT.
- MAMは同時に、Premiumコネチカット以外のCTsのQoS退行に対する孤立、帯域幅効率、および保護を達成できません。
Additional considerations on the properties of MAM, and its comparison with RDM, can be found in [BC-CONS] and [BC-MODEL].
[BCコンズ]と[紀元前-MODEL]でMAMの特性、およびRDMとのその比較での追加問題を見つけることができます。
As a very simple example of usage of MAM, a network administrator using one CT for Voice (CT1) and one CT for Data (CT0) might configure on a given 2.5 Gb/s link:
MAMの使用法の非常に簡単な例として、Voice(CT1)に1コネチカットを使用しているネットワーク管理者とData(CT0)のためのコネチカットが与えられた2.5Gb/sで構成するかもしれない1つはリンクされます:
- BC0 = 2 Gb/s (i.e., Data is limited to 2 Gb/s)
- BC0は2Gb/sと等しいです。(すなわち、Dataは2Gb/sに制限されます)
- BC1 = 1 Gb/s (i.e., Voice is limited to 1 Gb/s)
- BC1は1Gb/sと等しいです。(すなわち、Voiceは1Gb/sに制限されます)
- Maximum Reservable Bandwidth = 2.5 Gb/s (i.e., aggregate Data +
Voice is limited to 2.5 Gb/s)
- 最大のReservable帯域幅は2.5Gb/sと等しいです。(すなわち、集合Data+声は2.5Gb/sに制限されます)
4. Example Formulas for Computing "Unreserved TE-Class [i]" with
Maximum Allocation Model
4. 最大の配分モデルと共に「無遠慮な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 MAM MUST reflect the MAM Bandwidth Constraints defined in Section 3 when computing "Unreserved TE-Class [i]".
[DSTE-プロト]で指定されるように、「無遠慮なTeのクラス[i]」を計算するための定石は、TEクラス[i]に関連しているコネチカットに関連しているBandwidth Constraintsのすべてを反映して、その結果、Bandwidth Constraints Modelによらなければなりません。 したがって、マム族を実行するDS-TE LSRは「無遠慮なTeクラス[i]」を計算するときセクション3で定義されたMAM 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,
[DSTE-プロト]で説明されるように、IETF仕事の範囲の外に入場コントロールアルゴリズムの詳細、および「無遠慮なTeクラス[i]」を計算するための定石があります。 それを覚えておきます。
Le Faucheur & Lai Experimental [Page 6] RFC 4125 Maximum Allocation Model for DS-TE June 2005
Le Faucheurとレイ実験的な[6ページ]RFC4125の最大のAllocationは2005年6月にDS-Teのためにモデル化されます。
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 MAM. In the example, we assume the use of 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.
私たちはこのセクションに例を供給します、TEクラス[i]に、無遠慮な帯域幅への値がMAMと共にどう計算されるかもしれないかに関するイラスト目的のために。 例では、私たちは基本入場料コントロールアルゴリズムの使用を仮定します。(単に、アルゴリズムはそのLSPに関連しているコネチカットに関連しているBandwidth Constraintsのすべてからどんな確立したLSPの正確な帯域幅も差し引きます)。
Then:
その時:
"Unreserved TE-Class [i]" =
「無遠慮なTeクラス[i]」=
MIN [
[ BCc - SUM ( Reserved(CTc,q) ) ] for q <= p ,
[ Max-Res-Bw - SUM (Reserved(CTb,q)) ] for q <= p and 0 <= b <= 7,
]
分[BCc--、SUM、(予約、(CTc、q<のためのq]=p[マックス-Res-Bw--q<のためのSUM((CTb、q)を予約する]はpと等しく、0<はb<=7と等しいです]
where:
TE-Class [i] <--> < CTc , preemption p>
in the configured TE-Class mapping.
どこ: TE-クラス[i]<--><CTc、構成されたTE-クラスマッピングの先取りp>。
5. Security Considerations
5. セキュリティ問題
Security considerations related to the use of DS-TE are discussed in [DSTE-PROTO]. Those apply independently of the Bandwidth Constraints Model, including MAM specified in this document.
[DSTE-プロト]でDS-TEの使用に関連するセキュリティ問題について議論します。 それらは本書では指定されたMAMを含むBandwidth Constraints Modelの如何にかかわらず適用されます。
6. IANA Considerations
6. IANA問題
[DSTE-PROTO] defines a new name space for "Bandwidth Constraints Model Id". The guidelines for allocation of values in that name space are detailed in section 13.1 of [DSTE-PROTO]. In accordance with these guidelines, IANA has assigned a Bandwidth Constraints Model Id for MAM from the range 0-239 (which is to be managed as per the "Specification Required" policy defined in [IANA-CONS]).
[DSTE-プロト]は、「帯域幅規制はイドをモデル化する」ために新しい名前スペースを定義します。 その名前スペースでの値の配分のためのガイドラインは[DSTE-プロト]のセクション13.1で詳細です。 これらのガイドラインによると、IANAはMAMのために範囲0-239(「仕様が必要である」という[IANA-コンズ]で定義された方針に従って管理されることになっています)からBandwidth Constraints Model Idを割り当てました。
Bandwidth Constraints Model Id 1 was allocated by IANA to MAM.
帯域幅Constraints Model Id1はIANAによってMAMに割り当てられました。
7. Acknowledgements
7. 承認
A lot of the material in this document has been derived from ongoing discussions within the TEWG work. This involved many people including Jerry Ash and Dimitry Haskin.
TEWG仕事の中で現在行われている議論から多くの材料を本書では得ました。 これはジェリーAshとドミトリー・ハスキンを含む多くの人々にかかわりました。
Le Faucheur & Lai Experimental [Page 7] RFC 4125 Maximum Allocation Model for DS-TE June 2005
Le Faucheurとレイ実験的な[7ページ]RFC4125の最大のAllocationは2005年6月にDS-Teのためにモデル化されます。
Appendix A: Addressing [DSTE-REQ] Scenarios
付録A: [DSTE-REQ]シナリオを記述します。
This Appendix provides examples of how the Maximum Allocation Bandwidth Constraints Model can be used to support each of the scenarios described in [DSTE-REQ].
このAppendixは[DSTE-REQ]で説明されたそれぞれのシナリオを支持するのにどうMaximum Allocation 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=声のための)は「ある割合」のリンク容量と等しいです。
- Bandwidth Constraint 0 (for CT0 = Data) = link capacity (or a
constraint specific to data traffic)
- 帯域幅Constraint0(CT0=データのための)=リンク容量(または、データ通信量に特定の規制)
- Max Reservable Bandwidth = link capacity
- マックスReservable Bandwidthはリンク容量と等しいです。
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 Maximum Allocation Model will address all the requirements:
Maximum Allocation ModelとDS-TEはすべての要件を記述するでしょう:
- amount of Voice traffic limited to desired percentage on every
link
- あらゆるリンクの上に必要な割合に制限されたVoice交通の量
- data traffic capable of using all remaining link capacity (or up
to its own specific constraint)
- すべての残っているリンク容量を使用できるデータ通信量(またはそれ自身の特定の規制まで)
- 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% of link capacity
- BC2(CT2のための)は例えば、45%のリンク容量と等しいです。
- BC1 (for CT1) = e.g., 35% of link capacity
- BC1(CT1のための)は例えば、35%のリンク容量と等しいです。
- BC0 (for CT0) = e.g., 100% of link capacity
- BC0(CT0のための)は例えば、100%のリンク容量と等しいです。
- Max Reservable Bandwidth = link capacity
- マックスReservable Bandwidthはリンク容量と等しいです。
Le Faucheur & Lai Experimental [Page 8] RFC 4125 Maximum Allocation Model for DS-TE June 2005
Le Faucheurとレイ実験的な[8ページ]RFC4125の最大のAllocationは2005年6月にDS-Teのためにモデル化されます。
DS-TE with the Maximum Allocation Model 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.
Maximum Allocation ModelとDS-TEは、どの注文にかかわらず対応するDiffserv Per Hop Behaviors(PHBs)に割り当てられたリソースと比べて、LSPsが状況、どの先取りプライオリティがどのLSPsによって使用されるかにかかわらず失敗状況およびにかかわらず発送されるとき合格水準の中にリンクの上に確立されたそれぞれのコネチカットの交通の量があるのを確実にするでしょう。
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 Maximum Allocation Model will also ensure that:
また、Maximum Allocation 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 CT and corresponding Diffserv resources.
各コネチカットと対応する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 QoS objectives of the Guaranteed
Bandwidth service)
- BC1(CT1のための)は「与えられた」割合のリンク帯域幅と等しいです。(Guaranteed BandwidthサービスのQoS目的を達成する適切)です。
- BC0 (for CT0 = Data) = link capacity (or a constraint specific
to data traffic)
- BC0(CT0=データのための)はリンク容量と等しいです。(または、データ通信量に特定の規制)
- Max Reservable Bandwidth = link capacity
- マックスReservable Bandwidthはリンク容量と等しいです。
DS-TE with the Maximum Allocation 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
Maximum Allocation ModelとDS-TEは、あらゆるリンクの上に設立されたGuaranteed Bandwidth Trafficの量がいつもQoS目的を満たすように与えられた割合より下で残っているのを確実にするでしょう。 同時に、それは交通工学を許容するでしょう。
Le Faucheur & Lai Experimental [Page 9] RFC 4125 Maximum Allocation Model for DS-TE June 2005
Le Faucheurとレイ実験的な[9ページ]RFC4125の最大のAllocationは2005年6月にDS-Teのためにモデル化されます。
the rest of the traffic such that links can be filled up (or limited to the specific constraint for such traffic).
残り、交通では、リンクされるそのようなものは満たすことができます(または、そのような交通の特定の規制に制限されます)。
Normative References
引用規格
[DSTE-REQ] Le Faucheur, F. and W. Lai, "Requirements for Support
of Differentiated Services-aware MPLS Traffic
Engineering", RFC 3564, July 2003.
[DSTE-REQ] Le FaucheurとF.とW.レイ、「微分されたサービス意識しているMPLS交通工学のサポートのための要件」、RFC3564、2003年7月。
[DSTE-PROTO] Le Faucheur, F., Ed., "Protocol Extensions for Support
of Diffserv-aware MPLS Traffic Engineering", RFC 4124,
June 2005.
[DSTE-プロト] Le Faucheur、F.、エド「Diffserv意識しているMPLS交通のサポートのためのプロトコル拡大は設計すること」でのRFC4124、2005年6月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、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-RDM] Le Faucheur, F., Ed., "Russian Dolls Bandwidth
Constraints Model for Diffserv-aware MPLS Traffic
Engineering", RFC 4127, June 2005.
[DSTE-RDM] エドLe Faucheur、F.、RFC4127、「Diffserv意識しているMPLS交通へのロシア人のドールズ帯域幅規制モデルは設計すること」での6月2005日
[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 Traffic Engineering Fastはコースを変更します」。 「帯域幅保護のための迂回トンネル経路計算」、処理中の作業。
Le Faucheur & Lai Experimental [Page 10] RFC 4125 Maximum Allocation Model for DS-TE June 2005
Le Faucheurとレイ実験的な[10ページ]RFC4125の最大のAllocationは2005年6月にDS-Teのためにモデル化されます。
Authors' Addresses
作者のアドレス
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
Wai Sum Lai AT&T Labs 200 Laurel Avenue Middletown, New Jersey 07748, USA
Wai合計レイAT&T研究室200ローレルアベニューミドルタウン、ニュージャージー 07748、米国
Phone: (732) 420-3712 EMail: wlai@att.com
以下に電話をしてください。 (732) 420-3712 メールしてください: wlai@att.com
Le Faucheur & Lai Experimental [Page 11] RFC 4125 Maximum Allocation Model for DS-TE June 2005
Le Faucheurとレイ実験的な[11ページ]RFC4125の最大のAllocationは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 & Lai Experimental [Page 12]
Le FaucheurとレイExperimentalです。[12ページ]
一覧
スポンサーリンク
