RFC4124 日本語訳
4124 Protocol Extensions for Support of Diffserv-aware MPLS TrafficEngineering. F. Le Faucheur, Ed.. June 2005. (Format: TXT=79265 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group F. Le Faucheur, Ed. Request for Comments: 4124 Cisco Systems, Inc. Category: Standards Track June 2005
ワーキンググループF.Le Faucheur、エドをネットワークでつないでください。コメントのために以下を要求してください。 4124年のシスコシステムズInc.カテゴリ: 標準化過程2005年6月
Protocol Extensions for Support of
Diffserv-aware MPLS Traffic Engineering
Diffserv意識しているMPLS交通工学のサポートのためのプロトコル拡大
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This document specifies the protocol extensions for support of Diffserv-aware MPLS Traffic Engineering (DS-TE). This includes generalization of the semantics of a number of Interior Gateway Protocol (IGP) extensions already defined for existing MPLS Traffic Engineering in RFC 3630, RFC 3784, and additional IGP extensions beyond those. This also includes extensions to RSVP-TE signaling beyond those already specified in RFC 3209 for existing MPLS Traffic Engineering. These extensions address the requirements for DS-TE spelled out in RFC 3564.
このドキュメントはDiffserv意識しているMPLS Traffic Engineering(DS-TE)のサポートのためのプロトコル拡大を指定します。 それらを超えてこれはRFC3630、RFC3784、および追加IGP拡張子で既存のMPLS Traffic Engineeringのために既に定義された多くのInteriorゲートウェイプロトコル(IGP)拡大の意味論の一般化を含んでいます。 また、これはRFC3209で既に既存のMPLS Traffic Engineeringに指定されたものを超えて合図するRSVP-TEに拡大を含めます。 これらの拡大はRFC3564に詳しく説明されたDS-TEのための要件を記述します。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Specification of Requirements ..............................3
2. Contributing Authors ............................................4
3. Definitions .....................................................5
4. Configurable Parameters .........................................5
4.1. Link Parameters ............................................5
4.1.1. Bandwidth Constraints (BCs) .........................5
4.1.2. Overbooking .........................................6
4.2. LSR Parameters .............................................7
4.2.1. TE-Class Mapping ....................................7
4.3. LSP Parameters .............................................8
4.3.1. Class-Type ..........................................8
4.3.2. Setup and Holding Preemption Priorities .............8
4.3.3. Class-Type/Preemption Relationship ..................8
1. 序論…3 1.1. 要件の仕様…3 2. 作者を寄付します…4 3. 定義…5 4. 構成可能なパラメタ…5 4.1. パラメタをリンクしてください…5 4.1.1. 帯域幅規制(BCs)…5 4.1.2. オーバーブックします…6 4.2. LSRパラメタ…7 4.2.1. Teクラスマッピング…7 4.3. LSPパラメタ…8 4.3.1. クラスでタイプしてください…8 4.3.2. セットアップと把持先取りプライオリティ…8 4.3.3. クラスタイプ/先取り関係…8
Le Faucheur Standards Track [Page 1] RFC 4124 Protocols for Diffserv-aware TE June 2005
Le Faucheur規格は2005年6月にDiffserv意識しているTeのためにRFC4124プロトコルを追跡します[1ページ]。
4.4. Examples of Parameters Configuration .......................9
4.4.1. Example 1 ...........................................9
4.4.2. Example 2 ...........................................9
4.4.3. Example 3 ..........................................10
4.4.4. Example 4 ..........................................11
4.4.5. Example 5 ..........................................11
5. IGP Extensions for DS-TE .......................................12
5.1. Bandwidth Constraints .....................................12
5.2. Unreserved Bandwidth ......................................14
6. RSVP-TE Extensions for DS-TE ...................................15
6.1. DS-TE-Related RSVP Messages Format ........................15
6.1.1. Path Message Format ................................16
6.2. CLASSTYPE Object ..........................................16
6.2.1. CLASSTYPE object ...................................16
6.3. Handling CLASSTYPE Object .................................17
6.4. Non-support of the CLASSTYPE Object .......................20
6.5. Error Codes for Diffserv-aware TE .........................20
7. DS-TE Support with MPLS Extensions .............................21
7.1. DS-TE Support and References to Preemption Priority .......22
7.2. DS-TE Support and References to Maximum Reservable
Bandwidth .................................................22
8. Constraint-Based Routing .......................................22
9. Diffserv Scheduling ............................................23
10. Existing TE as a Particular Case of DS-TE .....................23
11. Computing "Unreserved TE-Class [i]" and Admission
Control Rules .................................................23
11.1. Computing "Unreserved TE-Class [i]" .....................23
11.2. Admission Control Rules .................................24
12. Security Considerations .......................................24
13. IANA Considerations ...........................................25
13.1. A New Name Space for Bandwidth Constraints Model
Identifiers .............................................25
13.2. A New Name Space for Error Values under the
"Diffserv-aware TE ......................................25
13.3. Assignments Made in This Document .......................26
13.3.1. Bandwidth Constraints sub-TLV for
OSPF Version 2 ..................................26
13.3.2. Bandwidth Constraints sub-TLV for ISIS ..........26
13.3.3. CLASSTYPE Object for RSVP .......................26
13.3.4. "Diffserv-aware TE Error" Error Code ............27
13.3.5. Error Values for "Diffserv-aware TE Error" ......27
14. Acknowledgements ..............................................28
Appendix A: Prediction for Multiple Path Computation ..............29
Appendix B: Solution Evaluation ...................................29
Appendix C: Interoperability with non DS-TE capable LSRs ..........31
Normative References ..............................................34
Informative References ............................................35
4.4. パラメタ構成に関する例…9 4.4.1. 例1…9 4.4.2. 例2…9 4.4.3. 例3…10 4.4.4. 例4…11 4.4.5. 例5…11 5. DS-TeのためのIGP拡張子…12 5.1. 帯域幅規制…12 5.2. 無遠慮な帯域幅…14 6. DS-TeのためのRSVP-Te拡大…15 6.1. DS Te関連のRSVPメッセージ形式…15 6.1.1. 経路メッセージ・フォーマット…16 6.2. CLASSTYPEは反対します…16 6.2.1. CLASSTYPEは反対します…16 6.3. 取り扱いCLASSTYPEは反対します…17 6.4. CLASSTYPE物の非サポート…20 6.5. Diffserv意識しているTeのための誤りコード…20 7. MPLS拡張子とのDS-Teサポート…21 7.1. 先取り優先権のDS-Teサポートと参照…22 7.2. 最大のReservable帯域幅のDS-Teサポートと参照…22 8. 規制ベースのルート設定…22 9. Diffservスケジューリング…23 10. DS-Teの特定のケースとしての既存のTe…23 11. 「無遠慮なTeクラス[i]」と入場コントロールを計算するのは統治されます…23 11.1. 「無遠慮なTeクラス[i]」を計算します…23 11.2. 入場コントロールは統治されます…24 12. セキュリティ問題…24 13. IANA問題…25 13.1. 帯域幅規制のための新しい名前スペースは識別子をモデル化します…25 13.2. 「Diffserv意識しているTe」の下における誤り値のための新しい名前スペース…25 13.3. 本書ではされた課題…26 13.3.1. OSPFバージョン2のためのサブTLVの帯域幅規制…26 13.3.2. イシスのためのサブTLVの帯域幅規制…26 13.3.3. CLASSTYPEはRSVPのために反対します…26 13.3.4. 「Diffserv意識しているTe誤り」エラーコード…27 13.3.5. 「Diffserv意識しているTe誤り」のための誤り値…27 14. 承認…28 付録A: 複数の経路計算のための予測…29 付録B: ソリューション評価…29 付録C: 非DS-TEのできるLSRsがある相互運用性…31 標準の参照…34 有益な参照…35
Le Faucheur Standards Track [Page 2] RFC 4124 Protocols for Diffserv-aware TE June 2005
Le Faucheur規格は2005年6月にDiffserv意識しているTeのためにRFC4124プロトコルを追跡します[2ページ]。
1. Introduction
1. 序論
[DSTE-REQ] presents the Service Provider requirements for support of Differentiated-Service (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]はDifferentiated-サービス(Diffserv)の意識しているMPLS Traffic Engineering(DS-TE)のサポートのためのService Provider要件を提示します。 これは異なったクラスの交通の異なった帯域幅規制を実施できるという基本的な要件を含んでいます。
This document specifies the IGP and RSVP-TE signaling extensions (beyond those already specified for existing MPLS Traffic Engineering [OSPF-TE][ISIS-TE][RSVP-TE]) for support of the DS-TE requirements spelled out in [DSTE-REQ] including environments relying on distributed Constraint-Based Routing (e.g., path computation involving head-end Label Switching Routers).
このドキュメントは環境を含んでいて、分配されたベースのConstraintルート設定(例えば、経路の計算の意味ありげなギヤエンドLabel Switching Routers)に依存しながら[DSTE-REQ]にスペルアウトされたDS-TE要件のサポートのために拡大に合図する(既に既存のMPLS Traffic Engineering[OSPF-TE][イシス-TE][RSVP-TE]に指定されたものを超えて)IGPとRSVP-TEを指定します。
[DSTE-REQ] provides a definition and examples of Bandwidth Constraints models. The present document does not specify nor assume a particular Bandwidth Constraints model. Specific Bandwidth Constraints models are outside the scope of this document. Although the extensions for DS-TE specified in this document may not be sufficient to support all the conceivable Bandwidth Constraints models, they do support the Russian Dolls Model specified in [DSTE-RDM], the Maximum Allocation Model specified in [DSTE-MAM], and the Maximum Allocation with Reservation Model specified in [DSTE-MAR].
[DSTE-REQ]はBandwidth Constraintsモデルに関する定義と例を提供します。 現在のドキュメントは、特定のBandwidth Constraintsモデルを指定して、就きません。 このドキュメントの範囲の外に特定のBandwidth Constraintsモデルがあります。 本書では指定されたDS-TEのための拡大は想像できるすべてのBandwidth Constraintsモデルをサポートするために十分でないかもしれませんが、彼らは[DSTE-RDM]で指定されたロシアのドールズModelを支持します、と予約Modelが[DSTE-3月]のときに指定されている状態で、Maximum Allocation Modelは[DSTE-MAM]、およびMaximum Allocationで指定しました。
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ルート設定を使用するためとそれがDiffservに加える入場コントロール能力のタイプので、DS-TEは交通へのDiffservが持っていない能力を持っています: Diffservは故意に先取りを示しませんが、DS-TEはClass-タイプのために複数のレベルの先取りについて説明します。 また、Diffservは明らかにオーバーブッキングを制御するどんな手段も支持しませんが、DS-TEはこれを許容します。 完全なサービスの質が環境であると考えるとき、DiffservルータとDS-TEがあるので、慎重にこれらの違いを考えるのは重要です。
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 Standards Track [Page 3] RFC 4124 Protocols for Diffserv-aware TE June 2005
Le Faucheur規格は2005年6月にDiffserv意識しているTeのためにRFC4124プロトコルを追跡します[3ページ]。
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 Standards Track [Page 4] RFC 4124 Protocols for Diffserv-aware TE June 2005
Le Faucheur規格は2005年6月にDiffserv意識しているTeのためにRFC4124プロトコルを追跡します[4ページ]。
3. Definitions
3. 定義
For readability, a number of definitions from [DSTE-REQ] are repeated here:
読み易さにおいて、[DSTE-REQ]からの多くの定義がここで繰り返されます:
Traffic Trunk: an aggregation of traffic flows of the same class
(i.e., treated equivalently from the DS-TE
perspective), which is placed inside a Label
Switched Path (LSP).
交通トランク: 同じクラス(すなわち、DS-TE見解から同等に扱われる)の交通の流れの集合。(クラスはLabel Switched Path(LSP)の中に置かれます)。
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:
i. a Class-Type
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.
Teクラス: 以下の1組 i. . 先取り優先あたり1Classタイプしているiiが、Classがタイプするように許容しました。 これは、そのClass-タイプからTraffic Trunkを輸送するLSPがセットアップ優先権、把持優先権、または両方としてその先取り優先権を使用できることを意味します。
Definitions for a number of MPLS terms are not repeated here. They can be found in [MPLS-ARCH].
多くのMPLSの期間の定義はここで繰り返されません。 [MPLS-ARCH]でそれらを見つけることができます。
4. Configurable Parameters
4. 構成可能なパラメタ
This section only discusses the differences with the configurable parameters supported for MPLS Traffic Engineering as per [TE-REQ], [ISIS-TE], [OSPF-TE], and [RSVP-TE]. All other parameters are unchanged.
このセクションは[TE-REQ]、[イシス-TE]、[OSPF-TE]、および[RSVP-TE]に従ってMPLS Traffic Engineeringのために支持される構成可能なパラメタに違いについて論ずるだけです。 他のすべてのパラメタが変わりがありません。
4.1. Link Parameters
4.1. リンクパラメータ
4.1.1. Bandwidth Constraints (BCs)
4.1.1. 帯域幅規制(BCs)
[DSTE-REQ] states that "Regardless of the Bandwidth Constraints Model, the DS-TE solution MUST allow support for up to 8 BCs."
「Bandwidth Constraints Modelにかかわらず、DS-TE解決策は8BCsまでサポートを許さなければなりません。」と、[DSTE-REQ]は述べます。
For DS-TE, the existing "Maximum Reservable link bandwidth" parameter is retained, but its semantics is generalized and interpreted as the aggregate bandwidth constraint across all Class-Types, so that, independently of the Bandwidth Constraints Model in use:
DS-TEに関しては、既存の「最大のReservableリンク帯域幅」パラメタが保有されますが、意味論は、集合帯域幅規制としてすべてのClass-タイプの向こう側に広められて、解釈されて、そうはそれです、使用中のBandwidth Constraints Modelの如何にかかわらず:
Le Faucheur Standards Track [Page 5] RFC 4124 Protocols for Diffserv-aware TE June 2005
Le Faucheur規格は2005年6月にDiffserv意識しているTeのためにRFC4124プロトコルを追跡します[5ページ]。
SUM (Reserved (CTc)) <= Max Reservable Bandwidth,
合計((CTc)を予約する)<はマックスReservable Bandwidthと等しいです。
where the SUM is across all values of "c" in the range 0 <= c <= 7.
SUMが範囲の「c」のすべての値のむこうにあるところでは、0<はc<=7と等しいです。
Additionally, on every link, a DS-TE implementation MUST provide for configuration of up to 8 additional link parameters which are the eight potential BCs, i.e., BC0, BC1, ... BC7. The LSR MUST interpret these BCs in accordance with the supported Bandwidth Constraints Model (i.e., what BC applies to what Class-Type, and how).
さらに、あらゆるリンクの上では、DS-TE実現は8潜在的BCsである最大8つの追加リンクパラメータの構成に備えなければなりません、すなわち、BC0、BC1… BC7。 支持されたBandwidth Constraints Model(すなわち、紀元前がどんなClass-タイプに適用するもの、およびどのように)によると、LSR MUSTはこれらのBCsを解釈するか。
Where the Bandwidth Constraints Model imposes some relationship among the values to be configured for these BCs, the LSR MUST enforce those at configuration time. For example, when the Russian Dolls Bandwidth Constraints Model ([DSTE-RDM]) is used, the LSR MUST ensure that BCi is configured smaller than or equal to BCj, where i is greater than j, and ensure that BC0 is equal to the Maximum Reservable Bandwidth. As another example, when the Maximum Allocation Model ([DSTE-MAM]) is used, the LSR MUST ensure that all BCi are configured smaller or equal to the Maximum Reservable Bandwidth.
Bandwidth Constraints ModelがこれらのBCsのために構成されるために値の中の何らかの関係を課すところでは、LSR MUSTは構成時にそれらを実施します。 ロシアのドールズBandwidth Constraints Model([DSTE-RDM])が使用されているとき、例えば、LSR MUSTが、BCiがそれほど構成されないのを確実にする、BCj、どこ、iはjよりすばらしく、BC0が確実にMaximum Reservable Bandwidthと等しくなるようにしてくださいか。 Maximum Allocation Model([DSTE-MAM])が使用されているとき、別の例として、LSR MUSTは、すべてのBCiがMaximum Reservable Bandwidthと、より小さいか、または等しい状態で構成されるのを確実にします。
4.1.2. Overbooking
4.1.2. オーバーブッキング
DS-TE enables a network administrator to apply different overbooking (or underbooking) ratios for different CTs.
DS-TEは、ネットワーク管理者が異なったCTsのために異なったオーバーブッキング(または、underbooking)比を適用するのを可能にします。
The principal methods to achieve this are the same as those historically used in existing TE deployment:
これを達成する主要な方法は既存のTE展開に歴史的に使用されるものと同じです:
(i) To take into account the overbooking/underbooking ratio
appropriate for the Ordered Aggregate (OA) or CT associated
with the considered LSP at the time of establishing the
bandwidth size of a given LSP. We refer to this method as the
"LSP Size Overbooking" method. AND/OR
(ii) To take into account the overbooking/underbooking ratio at the
time of configuring the Maximum Reservable Bandwidth/BCs and
use values that are larger (overbooking) or smaller
(underbooking) than those actually supported by the link. We
refer to this method as the "Link Size Overbooking" method.
(i) オーバーブッキング/underbooking比を考慮に入れるには、与えられたLSPの帯域幅サイズを確立する時点で、Ordered Aggregateのために(OA)か考えられたLSPに関連しているコネチカットを当ててください。 私たちは「LSPサイズオーバーブッキング」方法とこの方法を呼びます。 Maximum Reservable Bandwidth/BCsを構成する時点でオーバーブッキング/underbooking比を考慮に入れるAND/OR(ii)と、より大きい使用価値(オーバーブックする)か実際にリンクによって支持されたものより小さい(underbooking。) 私たちは「リンクサイズオーバーブッキング」方法とこの方法を呼びます。
The "LSP Size Overbooking" and "Link Size Overbooking" methods are expected to be sufficient in many DS-TE environments and require no additional configurable parameters. Other overbooking methods may involve such additional configurable parameters, but are beyond the scope of this document.
「LSPサイズオーバーブッキング」と「リンクサイズオーバーブッキング」方法は、多くのDS-TE環境で十分であり、どんな追加構成可能なパラメタも必要としないと予想されます。 他のオーバーブッキング方法は、そのような追加構成可能なパラメタにかかわるかもしれませんが、このドキュメントの範囲を超えています。
Le Faucheur Standards Track [Page 6] RFC 4124 Protocols for Diffserv-aware TE June 2005
Le Faucheur規格は2005年6月にDiffserv意識しているTeのためにRFC4124プロトコルを追跡します[6ページ]。
4.2. LSR Parameters
4.2. LSRパラメタ
4.2.1. TE-Class Mapping
4.2.1. Teクラスマッピング
In line with [DSTE-REQ], the preemption attributes defined in [TE-REQ] are retained with DS-TE and applicable within, and across, all CTs. The preemption attributes of setup priority and holding priority retain existing semantics, and in particular these semantics are not affected by the LSP CT. This means that if LSP1 contends with LSP2 for resources, LSP1 may preempt LSP2 if LSP1 has a higher setup preemption priority (i.e., lower numerical priority value) than LSP2 holding preemption priority, regardless of LSP1 CT and LSP2 CT.
[DSTE-REQ]に沿って、[TE-REQ]で定義された先取り属性は、CTsとすべてのCTsの向こう側にDS-TEと共に保有されていて適切です。 セットアップ優先権と把持優先権の先取り属性は既存の意味論を保有します、そして、特に、これらの意味論はLSP CTで影響を受けません。 これは、LSP1がリソースのためにLSP2を競争するなら、LSP1にLSP2より高いセットアップ先取り優先度(すなわち、下側の数字の優先順位の値)があるならLSP1が先取り優先権を保持しながらLSP2を先取りするかもしれないことを意味します、LSP1 CTとLSP2 CTにかかわらず。
DS-TE LSRs MUST allow configuration of a TE-Class mapping whereby the Class-Type and preemption level are configured for each of (up to) 8 TE-Classes.
DS-TE LSRsはClass-タイプと先取りレベルがそれぞれの(up to)8のTE-クラスのために構成されるTE-クラスマッピングの構成を許さなければなりません。
This mapping is referred to as :
このマッピングは以下と呼ばれます。
TE-Class[i] <--> < CTc , preemption p >
TEクラス[i]<--><CTc、先取りp>。
where 0 <= i <= 7, 0 <= c <= 7, 0 <= p <= 7
c7、0i0<=<=<=<がp<7、0<==7と等しいところ
Two TE-Classes MUST NOT be identical (i.e., have both the same Class-Type and the same preemption priority).
2つのTE-クラスが同じであるはずがありません(すなわち、同じClass-タイプと同じ先取り優先権の両方を持ってください)。
There are no other restrictions on how any of the 8 Class-Types can be paired up with any of the 8 preemption priorities to form a TE- Class. In particular, one given preemption priority can be paired up with two (or more) different Class-Types to form two (or more) TE- Classes. Similarly, one Class-Type can be paired up with two (or more) different preemption priorities to form two (or more) TE- Classes. Also, there is no mandatory ordering relationship between the TE-Class index (i.e., "i" above) and the Class-Type (i.e., "c" above) or the preemption priority (i.e., "p" above) of the TE-Class.
TEのクラスを形成するためにどう8つのClass-タイプのどれかを8つの先取りプライオリティのどれかと対にすることができるかに関する他の制限が全くありません。 1つの与えられた先取り優先権が特に、2つ(さらに)のTEのクラスを形成する2と対にされた(さらに)異なったClass-タイプであるかもしれません。 同様に、1つのClass-タイプが2つ(さらに)のTEのクラスを形成する2と対にされた(さらに)異なった先取りプライオリティであるかもしれません。 また、TE-クラスインデックス(すなわち、上の「i」)とClass-タイプ(すなわち、上の「c」)かTE-クラスの先取り優先権(すなわち、上の「p」)とのどんな義務的な注文関係もありません。
Where the network administrator uses less than 8 TE-Classes, the DS- TE LSR MUST allow remaining ones to be configured as "Unused". Note that configuring all the 8 TE-Classes as "Unused" effectively results in disabling TE/DS-TE since no TE/DS-TE LSP can be established (nor even configured, since as described in Section 4.3.3 below, the CT and preemption priorities configured for an LSP MUST form one of the configured TE-Classes).
ネットワーク管理者が8つ未満のTE-クラスを使用するところでは、DS- TE LSR MUSTは、「未使用」として構成されるためにもののままで残っているのを許容します。 「未使用」として有効にすべての8つのTE-クラスを構成するのがTE/DS-TE LSPを全く設立できないので(または、プライオリティがLSP MUSTのために構成したコネチカットと先取りがセクション4.3.3未満で説明されるように構成されたTE-クラスの1つを形成するので、構成さえされます)TE/DS-TEを無効にするのに結果として生じることに注意してください。
To ensure coherent DS-TE operation, the network administrator MUST configure exactly the same TE-Class mapping on all LSRs of the DS-TE domain.
一貫性を持っているDS-TE操作を確実にするために、ネットワーク管理者はDS-TEドメインのすべてのLSRsに関するまさに同じTE-クラスマッピングを構成しなければなりません。
Le Faucheur Standards Track [Page 7] RFC 4124 Protocols for Diffserv-aware TE June 2005
Le Faucheur規格は2005年6月にDiffserv意識しているTeのためにRFC4124プロトコルを追跡します[7ページ]。
When the TE-Class mapping needs to be modified in the DS-TE domain, care ought to be exercised during the transient period of reconfiguration during which some DS-TE LSRs may be configured with the new TE-Class mapping while others are still configured with the old TE-Class mapping. It is recommended that active tunnels do not use any of the TE-Classes that are being modified during such a transient reconfiguration period.
TE-クラスマッピングが、DS-TEドメインで変更される必要があるとき、注意が他のものが古いTE-クラスマッピングによってまだ構成されている間にいくつかのDS-TE LSRsが新しいTE-クラスマッピングによって構成されるかもしれない一時的な期間の再構成の間、行われるべきです。 アクティブなトンネルがそのような一時的な再構成の期間、変更されているTE-クラスのいずれも使用しないのは、お勧めです。
4.3. LSP Parameters
4.3. LSPパラメタ
4.3.1. Class-Type
4.3.1. クラスタイプ
With DS-TE, LSRs MUST support, for every LSP, an additional configurable parameter that indicates the Class-Type of the Traffic Trunk transported by the LSP.
DS-TEと共に、LSRsはあらゆるLSPのためにLSPによって輸送されたTraffic TrunkのClass-タイプを示す追加構成可能なパラメタを支持しなければなりません。
There is one and only one Class-Type configured per LSP.
LSP単位で構成された唯一無二の1つのClass-タイプがあります。
The configured Class-Type indicates, in accordance with the supported Bandwidth Constraints Model, the BCs that MUST be enforced for that LSP.
支持されたBandwidth Constraints Modelに従って、構成されたClass-タイプはそのLSPのために実施しなければならないBCsを示します。
4.3.2. Setup and Holding Preemption Priorities
4.3.2. セットアップと先取りプライオリティを保持すること。
As per existing TE, DS-TE LSRs MUST allow every DS-TE LSP to be configured with a setup and holding priority, each with a value between 0 and 7.
既存のTEに従って、DS-TE LSRsはあらゆるDS-TE LSPをセットアップによって構成されて、優位に立たせていなければなりません、それぞれ値0〜7で。
4.3.3. Class-Type/Preemption Relationship
4.3.3. クラスタイプ/先取り関係
With DS-TE, the preemption priority configured for the setup priority of a given LSP and the Class-Type configured for that LSP MUST be such that, together, they form one of the (up to) 8 TE-Classes configured in the TE-Class mapping specified in Section 4.2.1 above.
彼らが8つのTE-クラスが上のセクション4.2.1で指定されたTE-クラスマッピングで構成した(up to)の1つを一緒に、形成するようにDS-TE、与えられたLSPのセットアップ優先権のために構成された先取り優先権、およびそのLSP MUSTのために構成されたClass-タイプによるものになってください。
The preemption priority configured for the holding priority of a given LSP and the Class-Type configured for that LSP MUST also be such that, together, they form one of the (up to) 8 TE-Classes configured in the TE-Class mapping specified in Section 4.2.1 above.
与えられたLSPの把持優先権のために構成された先取り優先権とClass-タイプは、そのLSP MUSTのためにも彼らが8つのTE-クラスが上のセクション4.2.1で指定されたTE-クラスマッピングで構成した(up to)の1つを一緒に、形成するようにものであるように構成しました。
The LSR MUST enforce these two rules at configuration time.
LSR MUSTは構成時にこれらの2つの規則を実施します。
Le Faucheur Standards Track [Page 8] RFC 4124 Protocols for Diffserv-aware TE June 2005
Le Faucheur規格は2005年6月にDiffserv意識しているTeのためにRFC4124プロトコルを追跡します[8ページ]。
4.4. Examples of Parameters Configuration
4.4. パラメタ構成に関する例
For illustration purposes, we now present a few examples of how these configurable parameters may be used. All these examples assume that different BCs need to be enforced for different sets of Traffic Trunks (e.g., for Voice and for Data) so that two or more Class-Types need to be used.
イラスト目的のために、私たちは現在、これらの構成可能なパラメタがどう使用されるかもしれないかに関するいくつかの例を提示します。 これらのすべての例が、異なったBCsが、Traffic Trunks(例えば、VoiceとDataのための)の異なったセットのために実施される必要であると仮定するので、2つ以上のClass-タイプが、使用される必要があります。
4.4.1. Example 1
4.4.1. 例1
The network administrator of a first network using two CTs (CT1 for Voice and CT0 for Data) may elect to configure the following TE-Class mapping to ensure that Voice LSPs are never driven away from their shortest path because of Data LSPs:
2CTs(VoiceのためのCT1とDataのためのCT0)を使用する最初のネットワークのネットワーク管理者は、Voice LSPsがData LSPsのために彼らの最短パスから決して追い払われないのを保証するために以下のTE-クラスマッピングを構成するのを選ぶかもしれません:
TE-Class[0] <--> < CT1 , preemption 0 >
TE-Class[1] <--> < CT0 , preemption 1 >
TE-Class[i] <--> unused, for 2 <= i <= 7
TEクラス[0]<--><CT1、[1] 0>のTE-クラス<--><CT0、先取り1>TEクラス[i]<--2<における、未使用の先取り>はi<=7と等しいです。
Voice LSPs would then be configured with:
CT = CT1, setup priority = 0, holding priority = 0
そして、声のLSPsは以下によって構成されるでしょう。 コネチカット=CT1、セットアップ優先権=0、優位に立つ=0
Data LSPs would then be configured with:
CT = CT0, setup priority = 1, holding priority = 1
そして、データLSPsは以下によって構成されるでしょう。 コネチカット=CT0、セットアップ優先権=1、優位に立つ=1
A new Voice LSP would then be able to preempt an existing Data LSP in case they contend for resources. A Data LSP would never preempt a Voice LSP. A Voice LSP would never preempt another Voice LSP. A Data LSP would never preempt another Data LSP.
彼らがリソースを競争するといけないので、新しいVoice LSPはその時、既存のData LSPを先取りできるでしょう。 Data LSPはVoice LSPを決して先取りしません。 Voice LSPは別のVoice LSPを決して先取りしません。 Data LSPは別のData LSPを決して先取りしません。
4.4.2. Example 2
4.4.2. 例2
The network administrator of another network may elect to configure the following TE-Class mapping in order to optimize global network resource utilization by favoring placement of large LSPs closer to their shortest path:
別のネットワークのネットワーク管理者は、彼らの最短パスの、より近くで大きいLSPsのプレースメントを支持することによって世界的なネットワークリソース利用を最適化するために以下のTE-クラスマッピングを構成するのを選ぶかもしれません:
TE-Class[0] <--> < CT1 , preemption 0 >
TE-Class[1] <--> < CT0 , preemption 1 >
TE-Class[2] <--> < CT1 , preemption 2 >
TE-Class[3] <--> < CT0 , preemption 3 >
TE-Class[i] <--> unused, for 4 <= i <= 7
TEクラス[0]<--><CT1、[1] 0>のTE-クラス<--><CT0、先取り1>TEクラス[2]<--先取り><CT1、[3] 2>のTE-クラス<--><CT0、先取り3>TEクラス[i]<--4<における、未使用の先取り>はi<=7と等しいです。
Large-size Voice LSPs could be configured with:
CT = CT1, setup priority = 0, holding priority = 0
以下は大判Voice LSPsを構成できました。 コネチカット=CT1、セットアップ優先権=0、優位に立つ=0
Large-size Data LSPs could be configured with:
CT = CT0, setup priority = 1, holding priority = 1
以下は大判Data LSPsを構成できました。 コネチカット=CT0、セットアップ優先権=1、優位に立つ=1
Le Faucheur Standards Track [Page 9] RFC 4124 Protocols for Diffserv-aware TE June 2005
Le Faucheur規格は2005年6月にDiffserv意識しているTeのためにRFC4124プロトコルを追跡します[9ページ]。
Small-size Voice LSPs could be configured with:
CT = CT1, setup priority = 2, holding priority = 2
以下は小型Voice LSPsを構成できました。 コネチカット=CT1、セットアップ優先権=2、優位に立つ=2
Small-size Data LSPs could be configured with:
CT = CT0, setup priority = 3, holding priority = 3
以下は小型Data LSPsを構成できました。 コネチカット=CT0、セットアップ優先権=3、優位に立つ=3
A new large-size Voice LSP would then be able to preempt a small-size Voice LSP or any Data LSP in case they contend for resources. A new large-size Data LSP would then be able to preempt a small-size Data LSP or a small-size Voice LSP in case they contend for resources, but it would not be able to preempt a large-size Voice LSP.
彼らがリソースを競争するといけないので、新しい大判Voice LSPはその時、小型Voice LSPかどんなData LSPも先取りできるでしょう。 彼らがリソースを競争するといけないので、新しい大判Data LSPはその時、小型Data LSPか小型Voice LSPを先取りできるでしょうが、それは大判Voice LSPは先取りできないでしょう。
4.4.3. Example 3
4.4.3. 例3
The network administrator of another network may elect to configure the following TE-Class mapping in order to ensure that Voice LSPs are never driven away from their shortest path because of Data LSPs. This also achieves some optimization of global network resource utilization by favoring placement of large LSPs closer to their shortest path:
別のネットワークのネットワーク管理者は、Voice LSPsがData LSPsのために彼らの最短パスから決して追い払われないのを確実にするために以下のTE-クラスマッピングを構成するのを選ぶかもしれません。 また、これは大きいLSPsのプレースメントを支持することによって、世界的なネットワークリソース利用の何らかの最適化を彼らの最短パスの、より近くに達成します:
TE-Class[0] <--> < CT1 , preemption 0 >
TE-Class[1] <--> < CT1 , preemption 1 >
TE-Class[2] <--> < CT0 , preemption 2 >
TE-Class[3] <--> < CT0 , preemption 3 >
TE-Class[i] <--> unused, for 4 <= i <= 7
TEクラス[0]<--><CT1、[1] 0>のTE-クラス<--><CT1、先取り1>TEクラス[2]<--先取り><CT0、[3] 2>のTE-クラス<--><CT0、先取り3>TEクラス[i]<--4<における、未使用の先取り>はi<=7と等しいです。
Large-size Voice LSPs could be configured with:
CT = CT1, setup priority = 0, holding priority = 0.
以下は大判Voice LSPsを構成できました。 コネチカット=CT1、優先権=0を保持して、優先権=0をセットアップしてください。
Small-size Voice LSPs could be configured with:
CT = CT1, setup priority = 1, holding priority = 1.
以下は小型Voice LSPsを構成できました。 コネチカット=CT1、優先権=1を保持して、優先権=1をセットアップしてください。
Large-size Data LSPs could be configured with:
CT = CT0, setup priority = 2, holding priority = 2.
以下は大判Data LSPsを構成できました。 コネチカット=CT0、優先権=2を保持して、優先権=2をセットアップしてください。
Small-size Data LSPs could be configured with:
CT=CT0, setup priority = 3, holding priority = 3.
以下は小型Data LSPsを構成できました。 コネチカット=CT0、優先権=3を保持して、優先権=3をセットアップしてください。
A Voice LSP could preempt a Data LSP if they contend for resources. A Data LSP would never preempt a Voice LSP. A large-size Voice LSP could preempt a small-size Voice LSP if they contend for resources. A large-size Data LSP could preempt a small-size Data LSP if they contend for resources.
彼らがリソースを競争するなら、Voice LSPはData LSPを先取りするかもしれません。 Data LSPはVoice LSPを決して先取りしません。 彼らがリソースを競争するなら、大判Voice LSPは小型Voice LSPを先取りするかもしれません。 彼らがリソースを競争するなら、大判Data LSPは小型Data LSPを先取りするかもしれません。
Le Faucheur Standards Track [Page 10] RFC 4124 Protocols for Diffserv-aware TE June 2005
Le Faucheur規格は2005年6月にDiffserv意識しているTeのためにRFC4124プロトコルを追跡します[10ページ]。
4.4.4. Example 4
4.4.4. 例4
The network administrator of another network may elect to configure the following TE-Class mapping in order to ensure that no preemption occurs in the DS-TE domain:
別のネットワークのネットワーク管理者は、先取りが全くDS-TEドメインに起こらないのを確実にするために以下のTE-クラスマッピングを構成するのを選ぶかもしれません:
TE-Class[0] <--> < CT1 , preemption 0 >
TE-Class[1] <--> < CT0 , preemption 0 >
TE-Class[i] <--> unused, for 2 <= i <= 7
TEクラス[0]<--><CT1、[1] 0>のTE-クラス<--><CT0、先取り0>TEクラス[i]<--2<における、未使用の先取り>はi<=7と等しいです。
Voice LSPs would then be configured with:
CT = CT1, setup priority =0, holding priority = 0
そして、声のLSPsは以下によって構成されるでしょう。 コネチカット=CT1、セットアップ優先権=0、優位に立つ=0
Data LSPs would then be configured with:
CT = CT0, setup priority = 0, holding priority = 0
そして、データLSPsは以下によって構成されるでしょう。 コネチカット=CT0、セットアップ優先権=0、優位に立つ=0
No LSP would then be able to preempt any other LSP.
どんなLSPもその時、いかなる他のLSPも先取りできないでしょう。
4.4.5. Example 5
4.4.5. 例5
The network administrator of another network may elect to configure the following TE-Class mapping in view of increased network stability through a more limited use of preemption:
別のネットワークのネットワーク管理者は、先取りの、より限られた使用による増加するネットワークの安定性から見て以下のTE-クラスマッピングを構成するのを選ぶかもしれません:
TE-Class[0] <--> < CT1 , preemption 0 >
TE-Class[1] <--> < CT1 , preemption 1 >
TE-Class[2] <--> < CT0 , preemption 1 >
TE-Class[3] <--> < CT0 , preemption 2 >
TE-Class[i] <--> unused, for 4 <= i <= 7
TEクラス[0]<--><CT1、[1] 0>のTE-クラス<--><CT1、先取り1>TEクラス[2]<--先取り><CT0、[3] 先取り1>のTE-クラス<--><CT0、先取り2>TEクラス[i]<--4<における、未使用の>はi<=7と等しいです。
Large-size Voice LSPs could be configured with: CT = CT1, setup
priority = 0, holding priority = 0.
以下は大判Voice LSPsを構成できました。 コネチカット=CT1、優先権=0を保持して、優先権=0をセットアップしてください。
Small-size Voice LSPs could be configured with: CT = CT1, setup
priority = 1, holding priority = 0.
以下は小型Voice LSPsを構成できました。 コネチカット=CT1、優先権=0を保持して、優先権=1をセットアップしてください。
Large-size Data LSPs could be configured with: CT = CT0, setup
priority = 2, holding priority = 1.
以下は大判Data LSPsを構成できました。 コネチカット=CT0、優先権=1を保持して、優先権=2をセットアップしてください。
Small-size Data LSPs could be configured with: CT = CT0, setup
priority = 2, holding priority = 2.
以下は小型Data LSPsを構成できました。 コネチカット=CT0、優先権=2を保持して、優先権=2をセットアップしてください。
A new large-size Voice LSP would be able to preempt a Data LSP in case they contend for resources, but it would not be able to preempt any Voice LSP even a small-size Voice LSP.
彼らがリソースを競争するといけないので、新しい大判Voice LSPはData LSPを先取りできるでしょうが、それは小さいサイズVoice LSPにさえどんなVoice LSPも先取りできないでしょう。
Le Faucheur Standards Track [Page 11] RFC 4124 Protocols for Diffserv-aware TE June 2005
Le Faucheur規格は2005年6月にDiffserv意識しているTeのためにRFC4124プロトコルを追跡します[11ページ]。
A new small-size Voice LSP would be able to preempt a small-size Data LSP in case they contend for resources, but it would not be able to preempt a large-size Data LSP or any Voice LSP.
彼らがリソースを競争するといけないので、新しい小型Voice LSPは小型Data LSPを先取りできるでしょうが、それは大判Data LSPかどんなVoice LSPも先取りできないでしょう。
A Data LSP would not be able to preempt any other LSP.
Data LSPはいかなる他のLSPも先取りできないでしょう。
5. IGP Extensions for DS-TE
5. DS-TeのためのIGP拡張子
This section only discusses the differences with the IGP advertisement supported for (aggregate) MPLS Traffic Engineering as per [OSPF-TE] and [ISIS-TE]. The rest of the IGP advertisement is unchanged.
このセクションは[OSPF-TE]と[イシス-TE]に従って(集合)のMPLS Traffic Engineeringのために支持されるIGP広告に違いについて論ずるだけです。 IGP広告の残りは変わりがありません。
5.1. Bandwidth Constraints
5.1. 帯域幅規制
As detailed above in Section 4.1.1, up to 8 BCs (BCb, 0 <= b <= 7) are configurable on any given link.
上でセクション4.1.1で詳しく述べられるように、最大8BCs(BCb、b0<=<=7)がどんな与えられたリンクでも構成可能です。
With DS-TE, the existing "Maximum Reservable Bandwidth" sub-TLV ([OSPF-TE], [ISIS-TE]) is retained with a generalized semantics so that it MUST now be interpreted as the aggregate bandwidth constraint across all Class-Types; i.e., SUM (Reserved (CTc)) <= Max Reservable Bandwidth, independently of the Bandwidth Constraints Model.
DS-TEがあるので、既存の「最大のReservable帯域幅」サブTLV[OSPF-TE]、[イシス-TE)が一般化された意味論で保有されるので、現在集合帯域幅規制としてすべての向こう側にそれを解釈しなければならないのはClassタイプされます、。 すなわち、Bandwidth Constraints Modelの如何にかかわらずマックスSUM((CTc)を予約する)<=Reservable Bandwidth。
This document also defines the following new optional sub-TLV to advertise the eight potential BCs (BC0 to BC7):
また、このドキュメントは8潜在的BCs(BC7へのBC0)の広告を出すために以下の新しい任意のサブTLVを定義します:
"Bandwidth Constraints" sub-TLV:
「帯域幅規制」サブTLV:
- Bandwidth Constraints Model Id (1 octet)
- Reserved (3 octets)
- Bandwidth Constraints (N x 4 octets)
- (1つの八重奏)(予約されます(3つの八重奏))の帯域幅Constraints Model Id帯域幅Constraints(N x4つの八重奏)
Where:
- With OSPF, the sub-TLV is a sub-TLV of the "Link TLV" and its
sub-TLV type is 17.
どこ: - OSPFと共に、サブTLVは「リンクTLV」のサブTLVです、そして、サブTLVタイプは17歳です。
- With ISIS, the sub-TLV is a sub-TLV of the "extended IS
reachability TLV" and its sub-TLV type is 22.
- イシスと共に、サブTLVがサブTLVである、「広げられているのは、可到達性TLVです」とそのサブTLVタイプは22歳です。
- Bandwidth Constraints Model Id: a 1-octet identifier for the
Bandwidth Constraints Model currently in use by the LSR
initiating the IGP advertisement. See the IANA Considerations
section for assignment of values in this name space.
- 帯域幅規制はイドをモデル化します: 現在IGP広告を開始するLSRで使用中のBandwidth Constraints Modelのための1八重奏の識別子。 この名前スペースの値の課題に関してIANA Considerations部を見てください。
- Reserved: a 3-octet field. This field should be set to zero
by the LSR generating the sub-TLV and should be ignored by the
LSR receiving the sub-TLV.
- 予約される: 3八重奏の分野。 この分野は、サブTLVを発生させるLSRによってゼロに設定されるはずであり、サブTLVを受けるLSRによって無視されるはずです。
Le Faucheur Standards Track [Page 12] RFC 4124 Protocols for Diffserv-aware TE June 2005
Le Faucheur規格は2005年6月にDiffserv意識しているTeのためにRFC4124プロトコルを追跡します[12ページ]。
- Bandwidth Constraints: contains BC0, BC1,... BC(N-1). Each BC
is encoded on 32 bits in IEEE floating point format. The
units are bytes (not bits!) per second. Where the configured
TE-Class mapping and the Bandwidth Constraints model in use
are such that BCh+1, BCh+2, ...and BC7 are not relevant to any
of the Class-Types associated with a configured TE-Class, it
is RECOMMENDED that only the Bandwidth Constraints from BC0 to
BCh be advertised, in order to minimize the impact on IGP
scalability.
- 帯域幅規制: BC0、BC1を含んでいます… 紀元前(N-1)。 各紀元前はIEEE浮動小数点形式における32ビットの上でコード化されます。 ユニットは1秒あたりバイト(ビットでない!)です。 構成されたTE-クラスマッピングとBandwidth Constraintsがモデル化するところでは、使用中であるのが、そのBCh+1、そのようなBCh+2です…そして、BC7が構成されたTE-クラスに関連しているClass-タイプのいずれにも関連していない、BC0からBChまでのBandwidth Constraintsだけの広告を出すのは、RECOMMENDEDです、IGPスケーラビリティへの影響を最小にするために。
All relevant generic TLV encoding rules (including TLV format, padding and alignment, as well as IEEE floating point format encoding) defined in [OSPF-TE] and [ISIS-TE] are applicable to this new sub-TLV.
[OSPF-TE]と[イシス-TE]で定義されたすべての関連一般的なTLV符号化規則(TLV形式、詰め物、整列、およびIEEE浮動小数点形式コード化を含んでいる)がこの新しいサブTLVに適切です。
The "Bandwidth Constraints" sub-TLV format is illustrated below:
「帯域幅規制」サブTLV形式は以下で例証されます:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BC Model Id | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BC0 value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// . . . //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BCh value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 紀元前のモデルイド| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BC0値| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // . . . // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BCh値| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A DS-TE LSR MAY optionally advertise BCs.
DS-TE LSR MAYは任意にBCsの広告を出します。
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. For example, in the case where a service provider deploys DS-TE with TE-Classes associated with CT0 and CT1 only, and where the Bandwidth Constraints Model is such that only BC0 and BC1 are relevant to CT0 and CT1, a DS-TE LSR which does advertise BCs would include in the IGP advertisement the Maximum Reservable Bandwidth sub-TLV, as well as the "Bandwidth Constraints" sub-TLV. The former should contain the aggregate bandwidth constraint across all CTs, and the latter should contain BC0 and BC1.
DS-TE LSR(BCsの広告を出す)は、そうするのに、新しい「帯域幅規制」サブTLV(既存のMaximum Reservable BandwidthサブTLVに加えた)を使用しなければなりません。 例えば、サービスプロバイダーがCT0とCT1だけに関連しているTE-クラスと共にDS-TEを配備して、BC0とBC1だけがBandwidth Constraints ModelがそのようなものであるのでCT0とCT1に関連している場合では、BCsの広告を出すDS-TE LSRはIGP広告にMaximum Reservable BandwidthサブTLVを含んでいるでしょう、「帯域幅規制」サブTLVと同様に。 前者はすべてのCTsの向こう側に集合帯域幅規制を含むべきです、そして、後者はBC0とBC1を含むべきです。
A DS-TE LSR receiving the "Bandwidth Constraints" sub-TLV with a Bandwidth Constraints Model Id that does not match the Bandwidth Constraints Model it currently uses SHOULD generate a warning to the operator/management system, reporting the inconsistency between Bandwidth Constraints Models used on different links. Also, in that case, if the DS-TE LSR does not support the Bandwidth Constraints
異なったリンクの上に使用されるBandwidth Constraints Modelsの間の矛盾を報告して、それが現在使用するBandwidth Constraints Modelに合っていないBandwidth Constraints Model IdとサブTLV SHOULDがオペレータ/マネージメントシステムに警告を発生させるという「帯域幅規制」を受けるDS-TE LSR。 また、DS-TE LSRがそうしないなら、その場合、Bandwidth Constraintsを支持してください。
Le Faucheur Standards Track [Page 13] RFC 4124 Protocols for Diffserv-aware TE June 2005
Le Faucheur規格は2005年6月にDiffserv意識しているTeのためにRFC4124プロトコルを追跡します[13ページ]。
Model designated by the Bandwidth Constraints Model Id, or if the DS-TE LSR does not support operations with multiple simultaneous Bandwidth Constraints Models, the DS-TE LSR MAY discard the corresponding TLV. If the DS-TE LSR does support the Bandwidth Constraints Model designated by the Bandwidth Constraints Model Id, and if the DS-TE LSR does support operations with multiple simultaneous Bandwidth Constraints Models, the DS-TE LSR MAY accept the corresponding TLV and allow operations with different Bandwidth Constraints Models used in different parts of the DS-TE domain.
DS-TE LSRが複数の同時のBandwidth Constraints Modelsとの操作を支持しないならBandwidth Constraints Model Idによって任命されたモデル、DS-TE LSR MAYは対応するTLVを捨てます。 DS-TE LSRがBandwidth Constraints Model Idによって指定されたBandwidth Constraints Modelを支持して、DS-TE LSRが複数の同時のBandwidth Constraints Modelsとの操作を支持するなら、DS-TE LSR MAYは対応するTLVを受け入れて、異なったBandwidth Constraints ModelsがDS-TEドメインの異なった地域で使用されている状態で、操作を許します。
5.2. Unreserved Bandwidth
5.2. 無遠慮な帯域幅
With DS-TE, the existing "Unreserved Bandwidth" sub-TLV is retained as the only vehicle to advertise dynamic bandwidth information necessary for Constraint-Based Routing on head-ends, except that it is used with a generalized semantics. The Unreserved Bandwidth sub- TLV still carries eight bandwidth values, but they now correspond to the unreserved bandwidth for each of the TE-Classes (instead of for each preemption priority, as per existing TE).
DS-TEがあるので、既存の「無遠慮な帯域幅」サブTLVはギヤエンドでベースのConstraintルート設定に必要なダイナミックな帯域幅情報の広告を出すために唯一の乗り物として保有されます、それが一般化された意味論と共に使用されるのを除いて。 Unreserved BandwidthサブTLVはまだ8つの帯域幅値を運んでいますが、それらは現在、それぞれのTE-クラス(既存のTEに従ってそれぞれの先取り優先権の代わりに)に、無遠慮な帯域幅に対応します。
More precisely, a DS-TE LSR MUST support the Unreserved Bandwidth sub-TLV with a definition that is generalized into the following:
より正確に、DS-TE LSR MUSTは以下に一般化される定義によるサブTLVのUnreserved Bandwidthを支持します:
The Unreserved Bandwidth sub-TLV specifies the amount of bandwidth not yet reserved for each of the eight TE-Classes, in IEEE floating point format arranged in increasing order of TE-Class index. Unreserved bandwidth for TE-Class [0] occurs at the start of the sub-TLV, and unreserved bandwidth for TE-Class [7] at the end of the sub-TLV. The unreserved bandwidth value for TE-Class [i] ( 0 <= i <= 7) is referred to as "Unreserved TE-Class [i]". It indicates the bandwidth that is available, for reservation, to an LSP that:
Unreserved BandwidthサブTLVはそれぞれの8つのTE-クラスのためにまだ控えられていなかった帯域幅の量を指定します、TE-クラスインデックスの増加する注文に配置されたIEEE浮動小数点形式で。 TE-クラス[0]のための無遠慮な帯域幅はサブTLVの端にTE-クラス[7]のためのサブTLVの、そして、無遠慮な帯域幅の始めに起こります。 TE-クラス[i](0<はi<=7と等しい)のための無遠慮な帯域幅値は「無遠慮なTeクラス[i]」と呼ばれます。 それは以下のことというLSPへの条件に利用可能な帯域幅を示します。
- transports a Traffic Trunk from the Class-Type of TE-Class[i], and
- そしてTEクラス[i]のClass-タイプからTraffic Trunkを輸送する。
- has a setup priority corresponding to the preemption priority of
TE-Class[i].
- セットアップ優先をTEクラス[i]の先取り優先権に対応するようにします。
The units are bytes per second.
ユニットは1秒あたりバイトです。
Because the bandwidth values are now ordered by TE-class index and thus can relate to different CTs with different BCs and to any arbitrary preemption priority, a DS-TE LSR MUST NOT assume any ordered relationship among these bandwidth values.
その結果、帯域幅値が現在、TE-クラスインデックスによって命令されて、異なったBCsと共に異なったCTsに関連して、これらの帯域幅値の中でどんな任意の先取り優先権、DS-TE LSR MUST NOTにもどんな命令された関係も仮定できるので。
With existing TE, because all preemption priorities reflect the same (and only) BCs and bandwidth values are advertised in preemption priority order, the following relationship is always true, and is often assumed by TE implementations:
すべての先取りプライオリティが同じように(単に)BCsを反映して、帯域幅値が先取り優先順で広告に掲載されているので、以下の関係は、既存のTEと共に、いつも本当であり、TE実現でしばしば想定されます:
Le Faucheur Standards Track [Page 14] RFC 4124 Protocols for Diffserv-aware TE June 2005
Le Faucheur規格は2005年6月にDiffserv意識しているTeのためにRFC4124プロトコルを追跡します[14ページ]。
If i < j, then "Unreserved Bw [i]" >= "Unreserved Bw [j]"
i<j、次に、「予約していないBw[i]」>が「予約していないBw[j]」と等しいなら
With DS-TE, no relationship is to be assumed such that:
DS-TEと共にどんな関係も想定されたそのようなものでないことであるので:
If i < j, then any of the following relationships may be true:
"Unreserved TE-Class [i]" = "Unreserved TE-Class [j]"
OR
"Unreserved TE-Class [i]" > "Unreserved TE-Class [j]"
OR
"Unreserved TE-Class [i]" < "Unreserved TE-Class [j]".
i<jであるなら、以下の関係のどれかは本当であるかもしれません: 「無遠慮なTeクラス[j]」か「無遠慮なTeクラス[i]」>「無遠慮なTeクラス[j]」か「無遠慮なTeクラス[i]」<「無遠慮なTeクラス[i]」=「無遠慮なTeクラス[j]。」
Rules for computing "Unreserved TE-Class [i]" are specified in Section 11.
「無遠慮なTeクラス[i]」を計算するための規則はセクション11で指定されます。
If TE-Class[i] is unused, the value advertised by the IGP in "Unreserved TE-Class [i]" MUST be set to zero by the LSR generating the IGP advertisement, and MUST be ignored by the LSR receiving the IGP advertisement.
TEクラス[i]が未使用であるなら、「無遠慮なTeクラス[i]」のIGPによって広告に掲載された値を、IGP広告を作るLSRがゼロに設定しなければならなくて、IGP広告を受け取るLSRは無視しなければなりません。
6. RSVP-TE Extensions for DS-TE
6. DS-TeのためのRSVP-Te拡大
In this section, we describe extensions to RSVP-TE for support of Diffserv-aware MPLS Traffic Engineering. These extensions are in addition to the extensions to RSVP defined in [RSVP-TE] for support of (aggregate) MPLS Traffic Engineering and to the extensions to RSVP defined in [DIFF-MPLS] for support of Diffserv over MPLS.
このセクションで、私たちはDiffserv意識しているMPLS Traffic Engineeringのサポートのために拡大についてRSVP-TEに説明します。 これらの拡大は(集合)のMPLS Traffic Engineeringのサポートのために[RSVP-TE]で定義されたRSVPと、そして、拡大への拡大に加えてDiffservのサポートのためにMPLSの上で[DIFF-MPLS]で定義されたRSVPにいます。
6.1. DS-TE-Related RSVP Messages Format
6.1. DS Te関連のRSVPメッセージ形式
One new RSVP object is defined in this document: the CLASSTYPE object. Detailed description of this object is provided below. This new object is applicable to Path messages. This specification only defines the use of the CLASSTYPE object in Path messages used to establish LSP Tunnels in accordance with [RSVP-TE] and thus containing a session object with a CT equal to LSP_TUNNEL_IPv4 and containing a LABEL_REQUEST object.
ある新しいRSVP物が本書では定義されます: CLASSTYPEは反対します。 この物の詳述を以下に提供します。 この新しい物はPathメッセージに適切です。 この仕様はLSP_TUNNEL_IPv4と等しいコネチカットとLABEL_REQUEST物を含むのに[RSVP-TE]に従ってLSP Tunnelsを証明するのに使用されて、その結果セッション物を含むPathメッセージにおけるCLASSTYPE物の使用を定義するだけです。
Restrictions defined in [RSVP-TE] for support of establishment of LSP Tunnels via RSVP-TE are also applicable to the establishment of LSP Tunnels supporting DS-TE. For instance, only unicast LSPs are supported, and multicast LSPs are for further study.
また、LSP Tunnelsの設立のサポートのためにRSVP-TEを通して[RSVP-TE]で定義された制限もDS-TEを支持しているLSP Tunnelsの設立に適切です。 例えば、ユニキャストだけLSPsは支持されます、そして、さらなる研究にはマルチキャストLSPsがあります。
This new CLASSTYPE object is optional with respect to RSVP so that general RSVP implementations not concerned with MPLS LSP setup do not have to support this object.
この新しいCLASSTYPE物がRSVPに関して任意であるので、MPLS LSPセットアップに関しない一般的なRSVP実現はこの物を支える必要はありません。
An LSR supporting DS-TE MUST support the CLASSTYPE object.
DS-TE MUSTを支持するLSRはCLASSTYPE物を支えます。
Le Faucheur Standards Track [Page 15] RFC 4124 Protocols for Diffserv-aware TE June 2005
Le Faucheur規格は2005年6月にDiffserv意識しているTeのためにRFC4124プロトコルを追跡します[15ページ]。
6.1.1. Path Message Format
6.1.1. 経路メッセージ・フォーマット
The format of the Path message is as follows:
Pathメッセージの形式は以下の通りです:
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <SESSION_ATTRIBUTE> ]
[ <DIFFSERV> ]
[ <CLASSTYPE> ]
[ <POLICY_DATA> ... ]
[ <sender descriptor> ]
<経路メッセージ>:、:= <一般的なヘッダー>[<保全>]<><RSVP_ホップ><時間_セッションは>[<の明白な_ルート>]<ラベル_要求>[<セッション_属性>][<DIFFSERV>][<CLASSTYPE>][<方針_データ>…]を評価します。 [<送付者記述子>]
<sender descriptor> ::= <SENDER_TEMPLATE> [ <SENDER_TSPEC> ]
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
<送付者記述子>:、:= <送付者_テンプレート>[<送付者_TSPEC>][<ADSPEC>][<記録_ルート>]
6.2. CLASSTYPE Object
6.2. CLASSTYPE物
The CLASSTYPE object Class Name is CLASSTYPE. Its Class Number is 66. Currently, there is only one defined C-Type which is C-Type 1. The CLASSTYPE object format is shown below.
CLASSTYPE物のClass NameはCLASSTYPEです。 Class Numberは66歳です。 現在、1C-タイプ歳である1つの定義されたC-タイプしかありません。 CLASSTYPE物の書式は以下に示されます。
6.2.1. CLASSTYPE object
6.2.1. CLASSTYPE物
Class Number = 66 Class-Type = 1
66クラスクラス番号=タイプ=1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | CT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| コネチカット| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved: 29 bits
This field is reserved. It MUST be set to zero on transmission
and MUST be ignored on receipt.
予約される: Thisがさばく29ビットは予約されています。 それをトランスミッションのときにゼロに設定しなければならなくて、領収書の上で無視しなければなりません。
CT: 3 bits
Indicates the Class-Type. Values currently allowed are
1, 2, ... , 7. Value of 0 is Reserved.
コネチカット: 3ビットのIndicates Class-タイプ。 現在許容されている値は1、2です… , 7. 0の値はReservedです。
Le Faucheur Standards Track [Page 16] RFC 4124 Protocols for Diffserv-aware TE June 2005
Le Faucheur規格は2005年6月にDiffserv意識しているTeのためにRFC4124プロトコルを追跡します[16ページ]。
6.3. Handling CLASSTYPE Object
6.3. 取り扱いCLASSTYPE物
To establish an LSP tunnel with RSVP, the sender LSR creates a Path message with a session type of LSP_Tunnel_IPv4 and with a
RSVPと共にLSPトンネルを証明するために、送付者LSRはLSP_Tunnel_IPv4のセッションタイプとaでPathメッセージを作成します。
LABEL_REQUEST object as per [RSVP-TE]. The sender LSR may also include the DIFFSERV object as per [DIFF-MPLS].
LABEL_REQUESTは[RSVP-TE]に従って反対します。 また、送付者LSRは[DIFF-MPLS]に従ってDIFFSERV物を含むかもしれません。
If the LSP is associated with Class-Type 0, the sender LSR MUST NOT include the CLASSTYPE object in the Path message. This allows backward compatibility with non-DSTE-configured or non-DSTE-capable LSRs as discussed below in Section 10 and Appendix C.
LSPがClass-タイプ0に関連しているなら、送付者LSR MUST NOTはPathメッセージにCLASSTYPE物を含んでいます。 これはセクション10とAppendix Cで以下で議論するように構成された非DSTEかできる非DSTE LSRsとの後方の互換性を許容します。
If the LSP is associated with Class-Type N (1 <= N <=7), the sender LSR MUST include the CLASSTYPE object in the Path message with the Class-Type (CT) field set to N.
LSPがClass-タイプN(N1<=<=7)に関連しているなら、送付者LSR MUSTはPathメッセージでClass-タイプ(コネチカット)分野セットでCLASSTYPE物をNに含めます。
If a Path message contains multiple CLASSTYPE objects, only the first one is meaningful; subsequent CLASSTYPE object(s) MUST be ignored and MUST NOT be forwarded.
Pathメッセージが複数のCLASSTYPE物を含んでいるなら、最初の方だけが重要です。 その後のCLASSTYPE物を無視しなければならなくて、進めてはいけません。
Each LSR along the path MUST record the CLASSTYPE object, when it is present, in its path state block.
それが経路州のブロックに存在しているとき、経路に沿った各LSRはCLASSTYPE物を記録しなければなりません。
If the CLASSTYPE object is not present in the Path message, the LSR MUST associate the Class-Type 0 to the LSP.
CLASSTYPE物がPathメッセージに存在していないなら、LSR MUSTはClass-タイプ0をLSPに関連づけます。
The destination LSR responding to the Path message by sending a Resv message MUST NOT include a CLASSTYPE object in the Resv message (whether or not the Path message contained a CLASSTYPE object).
Resvメッセージを送ることによってPathメッセージに応じる目的地LSRはResvメッセージにCLASSTYPE物を含んではいけません(PathメッセージがCLASSTYPE物を含んだか否かに関係なく)。
During establishment of an LSP corresponding to the Class-Type N, the LSR MUST perform admission control over the bandwidth available for that particular Class-Type.
Class-タイプNに対応するLSPの設立の間、LSR MUSTはその特定のClass-タイプに利用可能な帯域幅の入場コントロールを実行します。
An LSR that recognizes the CLASSTYPE object and that receives a Path message that:
CLASSTYPE物とそれを認識するLSRは以下のことというPathメッセージを受け取ります。
- contains the CLASSTYPE object, but
- しかし、CLASSTYPE物を含んでいます。
- does not contain a LABEL_REQUEST object or does not have a
session type of LSP_Tunnel_IPv4,
- LABEL_REQUEST物を含んでいないか、またはLSP_Tunnel_IPv4のセッションタイプがありません。
MUST send a PathErr towards the sender with the error code "Diffserv-aware TE Error" and an error value of "Unexpected CLASSTYPE object". These codes are defined in Section 6.5.
エラーコード「Diffserv意識しているTe誤り」と「予期していなかったCLASSTYPEは反対する」誤り値をもっている送付者に向かってPathErrを送らなければなりません。 これらのコードはセクション6.5で定義されます。
Le Faucheur Standards Track [Page 17] RFC 4124 Protocols for Diffserv-aware TE June 2005
Le Faucheur規格は2005年6月にDiffserv意識しているTeのためにRFC4124プロトコルを追跡します[17ページ]。
An LSR receiving a Path message with the CLASSTYPE object that:
以下のことというCLASSTYPE物があるPathメッセージを受け取るLSR
- recognizes the CLASSTYPE object, but
- しかし、CLASSTYPEが反対すると認めます。
- does not support the particular Class-Type,
- 特定のClass-タイプを支持しません。
MUST send a PathErr towards the sender with the error code "Diffserv-aware TE Error" and an error value of "Unsupported Class- Type". These codes are defined in Section 6.5.
エラーコード「Diffserv意識しているTe誤り」と「サポートされないクラスタイプ」の誤り値をもっている送付者に向かってPathErrを送らなければなりません。 これらのコードはセクション6.5で定義されます。
An LSR receiving a Path message with the CLASSTYPE object that:
以下のことというCLASSTYPE物があるPathメッセージを受け取るLSR
- recognizes the CLASSTYPE object, but
- しかし、CLASSTYPEが反対すると認めます。
- determines that the Class-Type value is not valid (i.e.,
Class-Type value 0),
- Class-タイプ値が有効でないことを(すなわち、Class-タイプ値0)決定します。
MUST send a PathErr towards the sender with the error code "Diffserv-aware TE Error" and an error value of "Invalid Class-Type value". These codes are defined in Section 6.5.
エラーコード「Diffserv意識しているTe誤り」と「無効のClass-タイプ値」の誤り値をもっている送付者に向かってPathErrを送らなければなりません。 これらのコードはセクション6.5で定義されます。
An LSR receiving a Path message with the CLASSTYPE object, which:
CLASSTYPE物でPathメッセージを受け取るLSR、どれ、:
- recognizes the CLASSTYPE object and
- そしてCLASSTYPE物を認識する。
- supports the particular Class-Type, but
- しかし、特定のClass-タイプを支持します。
- determines that the tuple formed by (i) this Class-Type and
(ii) the setup priority signaled in the same Path message, is
not one of the eight TE-Classes configured in the TE-class
mapping,
- (i) このClass-タイプによって形成されたtupleと同じPathメッセージで合図された(ii)セットアップ優先権がTE-クラスマッピングで構成された8つのTE-クラスの1つでないことを決定します。
MUST send a PathErr towards the sender with the error code "Diffserv-aware TE Error" and an error value of "CT and setup priority do not form a configured TE-Class". These codes are defined in Section 6.5.
エラーコード「Diffserv意識しているTe誤り」と「コネチカットとセットアップ優先権は構成されたTE-クラスを形成しない」誤り値をもっている送付者に向かってPathErrを送らなければなりません。 これらのコードはセクション6.5で定義されます。
An LSR receiving a Path message with the CLASSTYPE object that:
以下のことというCLASSTYPE物があるPathメッセージを受け取るLSR
- recognizes the CLASSTYPE object and
- そしてCLASSTYPE物を認識する。
- supports the particular Class-Type, but
- しかし、特定のClass-タイプを支持します。
- determines that the tuple formed by (i) this Class-Type and
(ii) the holding priority signaled in the same Path message,
is not one of the eight TE-Classes configured in the TE-class
mapping,
- (i) このClass-タイプによって形成されたtupleと同じPathメッセージで合図された(ii)把持優先権がTE-クラスマッピングで構成された8つのTE-クラスの1つでないことを決定します。
Le Faucheur Standards Track [Page 18] RFC 4124 Protocols for Diffserv-aware TE June 2005
Le Faucheur規格は2005年6月にDiffserv意識しているTeのためにRFC4124プロトコルを追跡します[18ページ]。
MUST send a PathErr towards the sender with the error code "Diffserv-aware TE Error" and an error value of "CT and holding priority do not form a configured TE-Class". These codes are defined in Section 6.5.
エラーコード「Diffserv意識しているTe誤り」と「コネチカットと優先権を保持するのは構成されたTE-クラスを形成しない」誤り値をもっている送付者に向かってPathErrを送らなければなりません。 これらのコードはセクション6.5で定義されます。
An LSR receiving a Path message with the CLASSTYPE object that:
以下のことというCLASSTYPE物があるPathメッセージを受け取るLSR
- recognizes the CLASSTYPE object and
- そしてCLASSTYPE物を認識する。
- supports the particular Class-Type, but
- しかし、特定のClass-タイプを支持します。
- determines that the tuple formed by (i) this Class-Type and
(ii) the setup priority signaled in the same Path message, is
not one of the eight TE-Classes configured in the TE-class
mapping, AND
- tupleが(i) このClass-タイプで形成されて、(ii)セットアップ優先権が同じPathメッセージで合図したことを決定して、TE-クラスマッピングで構成された、8つのTE-クラスの1つ、ANDではありません。
- determines that the tuple formed by (i) this Class-Type and
(ii) the holding priority signaled in the same Path message,
is not one of the eight TE-Classes configured in the TE-class
mapping
- (i) このClass-タイプによって形成されたtupleと同じPathメッセージで合図された(ii)把持優先権がTE-クラスマッピングで構成された8つのTE-クラスの1つでないことを決定します。
MUST send a PathErr towards the sender with the error code "Diffserv-aware TE Error" and an error value of "CT and setup priority do not form a configured TE-Class AND CT and holding priority do not form a configured TE-Class". These codes are defined in Section 6.5.
エラーコード「Diffserv意識しているTe誤り」と「構成されたTE-クラスはコネチカットとセットアップ優先権は形成されません、そして、コネチカットと優先権を保持する場合、構成されたTE-クラスは形成されない」誤り値をもっている送付者に向かってPathErrを送らなければなりません。 これらのコードはセクション6.5で定義されます。
An LSR receiving a Path message with the CLASSTYPE object and with the DIFFSERV object for an L-LSP that:
以下のことというCLASSTYPE物とL-LSPのためのDIFFSERV物があるPathメッセージを受け取るLSR
- recognizes the CLASSTYPE object,
- CLASSTYPE物を認識します。
- has local knowledge of the relationship between Class-Types
and Per Hop Behavior (PHB) Scheduling Class, e.g., via
configuration, and
- そして例えば、構成でClassの計画をしながらClass-タイプとPer Hop Behavior(PHB)との関係に関する局所的知識を持っている。
- determines, based on this local knowledge, that the PHB
Scheduling Class (PSC) signaled in the DIFFSERV object is
inconsistent with the Class-Type signaled in the CLASSTYPE
object,
- この局所的知識に基づいて、DIFFSERV物で合図されたPHB Scheduling Class(PSC)がCLASSTYPE物で合図されるClass-タイプに矛盾していることを決定します。
MUST send a PathErr towards the sender with the error code "Diffserv-aware TE Error" and an error value of "Inconsistency between signaled PSC and signaled CT". These codes are defined below in Section 6.5.
エラーコード「Diffserv意識しているTe誤り」と「合図されたPSCと合図されたコネチカットの間の矛盾」の誤り値をもっている送付者に向かってPathErrを送らなければなりません。 これらのコードは以下でセクション6.5で定義されます。
Le Faucheur Standards Track [Page 19] RFC 4124 Protocols for Diffserv-aware TE June 2005
Le Faucheur規格は2005年6月にDiffserv意識しているTeのためにRFC4124プロトコルを追跡します[19ページ]。
An LSR receiving a Path message with the CLASSTYPE object and with the DIFFSERV object for an E-LSP that:
以下のことというE-LSPへのCLASSTYPE物とDIFFSERV物があるPathメッセージを受け取るLSR
- recognizes the CLASSTYPE object,
- CLASSTYPE物を認識します。
- has local knowledge of the relationship between Class-Types
and PHBs (e.g., via configuration)
- Class-タイプとPHBsとの関係に関する局所的知識を持っています。(例えば、構成を通した)
- determines, based on this local knowledge, that the PHBs
signaled in the MAP entries of the DIFFSERV object are
inconsistent with the Class-Type signaled in the CLASSTYPE
object,
- この局所的知識に基づいて、DIFFSERV物のMAPエントリーで合図されたPHBsがCLASSTYPE物で合図されるClass-タイプに矛盾していることを決定します。
MUST send a PathErr towards the sender with the error code "Diffserv-aware TE Error" and an error value of "Inconsistency between signaled PHBs and signaled CT". These codes are defined in Section 6.5.
エラーコード「Diffserv意識しているTe誤り」と「合図されたPHBsと合図されたコネチカットの間の矛盾」の誤り値をもっている送付者に向かってPathErrを送らなければなりません。 これらのコードはセクション6.5で定義されます。
An LSR MUST handle situations in which the LSP cannot be accepted for reasons other than those already discussed in this section, in accordance with [RSVP-TE] and [DIFF-MPLS] (e.g., a reservation is rejected by admission control, and a label cannot be associated).
[RSVP-TE]と[DIFF-MPLS]に従って既にこのセクションで議論したもの以外の理由でLSPを受け入れることができないLSR MUSTハンドル状況(入場コントロールで例えば予約を拒絶します、そして、ラベルを関連づけることができません)。
6.4. Non-support of the CLASSTYPE Object
6.4. CLASSTYPE物の非サポート
An LSR that does not recognize the CLASSTYPE object Class-Num MUST behave in accordance with the procedures specified in [RSVP] for an unknown Class-Num whose format is 0bbbbbbb (i.e., it MUST send a PathErr with the error code "Unknown object class" toward the sender).
手順によると、Class-ヌムが反応させなければならないCLASSTYPE物を認識しないLSRは、未知のClass-ヌムへの[RSVP]でだれの形式が0bbbbbbbであるかを指定しました(すなわち、それはエラーコード「未知の物のクラス」があるPathErrを送付者に向かって送らなければなりません)。
An LSR that recognizes the CLASSTYPE object Class-Num but that does not recognize the CLASSTYPE object C-Type, MUST behave in accordance with the procedures specified in [RSVP] for an unknown C-type (i.e., it MUST send a PathErr with the error code "Unknown object C-Type" toward the sender).
Class-ヌムにもかかわらず、それがするCLASSTYPE物を認識するLSRはCLASSTYPE物のC-タイプを見分けて、[RSVP]で未知のC-タイプに指定された手順によると、振る舞ってはいけません(すなわち、それはエラーコード「未知の物のC-タイプ」で送付者に向かってPathErrを送らなければなりません)。
Both of the above situations cause the path setup to fail. The sender SHOULD notify the operator/management system that an LSP cannot be established and might take action to retry reservation establishment without the CLASSTYPE object.
上の状況の両方が経路セットアップに失敗されます。 送付者SHOULDは、CLASSTYPE物なしで予約設立を再試行するためにLSPが設立できないで、行動を取るかもしれないようにオペレータ/マネージメントシステムに通知します。
6.5. Error Codes for Diffserv-aware TE
6.5. Diffserv意識しているTeのためのエラーコード
In the procedures described above, certain errors are reported as a "Diffserv-aware TE Error". The value of the "Diffserv-aware TE Error" error code is 28.
上で説明された手順で、ある誤りは「Diffserv意識しているTe誤り」として報告されます。 「Diffserv意識しているTe誤り」エラーコードの値は28です。
Le Faucheur Standards Track [Page 20] RFC 4124 Protocols for Diffserv-aware TE June 2005
Le Faucheur規格は2005年6月にDiffserv意識しているTeのためにRFC4124プロトコルを追跡します[20ページ]。
The following table defines error values for the Diffserv-aware TE Error:
以下のテーブルはDiffserv意識しているTE Errorのために誤り値を定義します:
Value Error
値の誤り
1 Unexpected CLASSTYPE object
2 Unsupported Class-Type
3 Invalid Class-Type value
4 Class-Type and setup priority do not form a configured
TE-Class
5 Class-Type and holding priority do not form a
configured TE-Class
6 Class-Type and setup priority do not form a configured
TE-Class AND Class-Type and holding priority do not form
a configured TE-Class
7 Inconsistency between signaled PSC and signaled
Class-Type
8 Inconsistency between signaled PHBs and signaled
Class-Type
1 構成されたTE-クラス5Class-タイプをどんなフォームにもしないで、構成されたTE-クラスが予期していなかったCLASSTYPEの2Unsupported Class-タイプ3Invalid Class-タイプ物の価値4のClass-タイプとセットアップ優先権によって構成されたTE-クラス6Class-タイプとセットアップ優先が形成しないフォームではなく、優先権がする把持に行われます、そして、Class-タイプと優先権を保持する場合、構成されたTE-クラス7Inconsistencyは合図されたPHBsと合図されたClass-タイプの間で合図されたPSCと合図されたClass-タイプ8Inconsistencyの間で形成されません。
See the IANA Considerations section for allocation of additional values.
加算値の配分に関してIANA Considerations部を見てください。
7. DS-TE Support with MPLS Extensions
7. MPLS拡張子とのDS-Teサポート
There are a number of extensions to the initial base specification for signaling [RSVP-TE] and IGP support for TE [OSPF-TE][ISIS-TE]. Those include enhancements for generalization ([GMPLS-SIG] and [GMPLS-ROUTE]), as well as for additional functionality, such as LSP hierarchy [HIERARCHY], link bundling [BUNDLE], and fast restoration [REROUTE]. These specifications may reference how to encode information associated with certain preemption priorities, how to treat LSPs at different preemption priorities, or they may otherwise specify encodings or behavior that have a different meaning for a DS-TE router.
シグナリングのための初期の基礎仕様[RSVP-TE]とTE[OSPF-TE]のIGPサポート[イシス-TE]への多くの拡大があります。 ものは一般化([GMPLS-SIG]と[GMPLS-ROUTE])のための増進を含んでいます、よく追加機能性のように、LSP階層構造[HIERARCHY]や、リンクバンドリング[BUNDLE]や、速い回復[REROUTE]などのように。 これらの仕様はどうある先取りプライオリティに関連している情報をコード化するかに参照をつけるかもしれません、異なった先取りプライオリティでどうLSPsを扱うか、そして、またはそれらが別の方法で異なった意味を持っているencodingsか振舞いをDS-TEルータに指定するかもしれません。
In order for an implementation to support both this specification for Diffserv-aware TE and a given MPLS enhancement, such as those listed above (but not limited to those), it MUST treat references to "preemption priority" and to "Maximum Reservable Bandwidth" in a generalized manner, i.e., the manner in which this specification uses those terms.
実現がDiffserv意識しているTEのためのこの仕様と与えられたMPLS増進の上に記載されたものなどの両方を支持する命令、(他、それら)、一般化された方法(すなわち、この仕様がそれらの用語を使用する方法)でそれは「先取り優先権」と「最大のReservable帯域幅」の参照を扱わなければなりません。
Additionally, current and future MPLS enhancements may include more precise specification for how they interact with Diffserv-aware TE.
さらに、現在の、そして、今後のMPLS増進はそれらがどうDiffserv意識しているTEと対話するかより正確な仕様を含むかもしれません。
Le Faucheur Standards Track [Page 21] RFC 4124 Protocols for Diffserv-aware TE June 2005
Le Faucheur規格は2005年6月にDiffserv意識しているTeのためにRFC4124プロトコルを追跡します[21ページ]。
7.1. DS-TE Support and References to Preemption Priority
7.1. 先取り優先権のDS-Teサポートと参照
When a router supports both Diffserv-aware TE and one of the MPLS protocol extensions such as those mentioned above, encoding of values of preemption priority in signaling or encoding of information associated with preemption priorities in IGP defined for the MPLS extension, MUST be considered an encoding of the same information for the corresponding TE-Class. For instance, if an MPLS enhancement specifies advertisement in IGP of a parameter for routing information at preemption priority N, in a DS-TE environment it MUST actually be interpreted as specifying advertisement of the same routing information but for TE-Class [N]. On receipt, DS-TE routers MUST also interpret it as such.
ルータがMPLS拡張子のために定義されたIGPでDiffserv意識しているTEと前記のようにそれらなどのMPLSプロトコル拡張子の1つか、シグナリングにおける、先取り優先権の値のコード化か先取りプライオリティに関連している情報のコード化の両方を支持したら考えなければならなくなってください。対応するTE-クラスのための同じ情報のコード化。 例えば、MPLS増進がルーティング情報のためのパラメタのIGPで先取り優先権Nで広告を指定するなら、DS-TE環境で、同じルーティング情報の広告を指定しますが、TE-クラス[N]のために実際にそれを解釈しなければなりません。 また、領収書の上では、DS-TEルータはそういうものとしてそれを解釈しなければなりません。
When there is discussion on how to comparatively treat LSPs of different preemption priority, a DS-TE LSR MUST treat the preemption priorities in this context as those associated with the TE-Classes of the LSPs in question.
いつに進行中の議論があるか、どのように、比較的、異なった先取り優先権(LSPsのTE-クラスがはっきりしていなくこのような関係においてはそれらとしての先取りプライオリティが関連づけたDS-TE LSR MUSTの御馳走)のLSPsを扱ってくださいか。
7.2. DS-TE Support and References to Maximum Reservable Bandwidth
7.2. 最大のReservable帯域幅のDS-Teサポートと参照
When a router supports both Diffserv-aware TE and MPLS protocol extensions such as those mentioned above, advertisements of Maximum Reservable Bandwidth MUST be done with the generalized interpretation defined in Section 4.1.1 as the aggregate bandwidth constraint across all Class-Types. It MAY also allow the optional advertisement of all BCs.
ルータがいつDiffserv意識しているTEとそれらなどのMPLSプロトコル拡張子の両方をサポートするかが上では、一般化された解釈がすべてのClass-タイプの向こう側にセクション4.1.1で集合帯域幅規制と定義されている状態でMaximum Reservable Bandwidthの広告をしなければならないと言及しました。 また、それはすべてのBCsの任意の広告を許すかもしれません。
8. Constraint-Based Routing
8. 規制ベースのルート設定
Let us consider the case where a path needs to be computed for an LSP whose Class-Type is configured to CTc and whose setup preemption priority is configured to p.
Let us consider the case where a path needs to be computed for an LSP whose Class-Type is configured to CTc and whose setup preemption priority is configured to p.
Then the pair of CTc and p will map to one of the TE-Classes defined in the TE-Class mapping. Let us refer to this TE-Class as TE- Class[i].
Then the pair of CTc and p will map to one of the TE-Classes defined in the TE-Class mapping. Let us refer to this TE-Class as TE- Class[i].
The Constraint-Based Routing algorithm of a DS-TE LSR is still only required to perform path computation satisfying a single BC which is to fit in "Unreserved TE-Class [i]" as advertised by the IGP for every link. Thus, no changes to the existing TE Constraint-Based Routing algorithm itself are required.
The Constraint-Based Routing algorithm of a DS-TE LSR is still only required to perform path computation satisfying a single BC which is to fit in "Unreserved TE-Class [i]" as advertised by the IGP for every link. Thus, no changes to the existing TE Constraint-Based Routing algorithm itself are required.
The Constraint-Based Routing algorithm MAY also take into account, when used, the optional additional information advertised in IGP such as the BCs and the Maximum Reservable Bandwidth. For example, the
The Constraint-Based Routing algorithm MAY also take into account, when used, the optional additional information advertised in IGP such as the BCs and the Maximum Reservable Bandwidth. For example, the
Le Faucheur Standards Track [Page 22] RFC 4124 Protocols for Diffserv-aware TE June 2005
Le Faucheur Standards Track [Page 22] RFC 4124 Protocols for Diffserv-aware TE June 2005
BCs MIGHT be used as tie-breaker criteria in situations where multiple paths, otherwise equally attractive, are possible.
BCs MIGHT be used as tie-breaker criteria in situations where multiple paths, otherwise equally attractive, are possible.
9. Diffserv Scheduling
9. Diffserv Scheduling
The Class-Type signaled at LSP establishment MAY optionally be used by DS-TE LSRs to dynamically adjust the resources allocated to the Class-Type by the Diffserv scheduler. In addition, the Diffserv information (i.e., the PSC) signaled by the TE-LSP signaling protocols as specified in [DIFF-MPLS], if used, MAY optionally be used by DS-TE LSRs to dynamically adjust the resources allocated by the Diffserv scheduler to a PSC/OA within a CT.
The Class-Type signaled at LSP establishment MAY optionally be used by DS-TE LSRs to dynamically adjust the resources allocated to the Class-Type by the Diffserv scheduler. In addition, the Diffserv information (i.e., the PSC) signaled by the TE-LSP signaling protocols as specified in [DIFF-MPLS], if used, MAY optionally be used by DS-TE LSRs to dynamically adjust the resources allocated by the Diffserv scheduler to a PSC/OA within a CT.
10. Existing TE as a Particular Case of DS-TE
10. Existing TE as a Particular Case of DS-TE
We observe that existing TE can be viewed as a particular case of DS-TE where:
We observe that existing TE can be viewed as a particular case of DS-TE where:
(i) a single Class-Type is used,
(ii) all 8 preemption priorities are allowed for that Class-Type,
and
(iii) the following TE-Class mapping is used:
TE-Class[i] <--> < CT0 , preemption i >
Where 0 <= i <= 7.
(i) a single Class-Type is used, (ii) all 8 preemption priorities are allowed for that Class-Type, and (iii) the following TE-Class mapping is used: TE-Class[i] <--> < CT0 , preemption i > Where 0 <= i <= 7.
In that case, DS-TE behaves as existing TE.
In that case, DS-TE behaves as existing TE.
As with existing TE, the IGP advertises:
- Unreserved Bandwidth for each of the 8 preemption priorities.
As with existing TE, the IGP advertises: - Unreserved Bandwidth for each of the 8 preemption priorities.
As with existing TE, the IGP may advertise:
- Maximum Reservable Bandwidth containing a BC applying across
all LSPs .
As with existing TE, the IGP may advertise: - Maximum Reservable Bandwidth containing a BC applying across all LSPs .
Because all LSPs transport traffic from CT0, RSVP-TE signaling is done without explicit signaling of the Class-Type (which is only used for Class-Types other than CT0, as explained in Section 6) as with existing TE.
Because all LSPs transport traffic from CT0, RSVP-TE signaling is done without explicit signaling of the Class-Type (which is only used for Class-Types other than CT0, as explained in Section 6) as with existing TE.
11. Computing "Unreserved TE-Class [i]" and Admission Control Rules
11. Computing "Unreserved TE-Class [i]" and Admission Control Rules
11.1. Computing "Unreserved TE-Class [i]"
11.1. Computing "Unreserved TE-Class [i]"
We first observe that, for existing TE, details on admission control algorithms for TE LSPs, and consequently details on formulas for computing the unreserved bandwidth, are outside the scope of the current IETF work. This is left for vendor differentiation. Note that this does not compromise interoperability across various
We first observe that, for existing TE, details on admission control algorithms for TE LSPs, and consequently details on formulas for computing the unreserved bandwidth, are outside the scope of the current IETF work. This is left for vendor differentiation. Note that this does not compromise interoperability across various
Le Faucheur Standards Track [Page 23] RFC 4124 Protocols for Diffserv-aware TE June 2005
Le Faucheur Standards Track [Page 23] RFC 4124 Protocols for Diffserv-aware TE June 2005
implementations because the TE schemes rely on LSRs to advertise their local view of the world in terms of Unreserved Bw to other LSRs. This way, regardless of the actual local admission control algorithm used on one given LSR, Constraint-Based Routing on other LSRs can rely on advertised information to determine whether an additional LSP will be accepted or rejected by the given LSR. The only requirement is that an LSR advertises unreserved bandwidth values that are consistent with its specific local admission control algorithm and take into account the holding preemption priority of established LSPs.
implementations because the TE schemes rely on LSRs to advertise their local view of the world in terms of Unreserved Bw to other LSRs. This way, regardless of the actual local admission control algorithm used on one given LSR, Constraint-Based Routing on other LSRs can rely on advertised information to determine whether an additional LSP will be accepted or rejected by the given LSR. The only requirement is that an LSR advertises unreserved bandwidth values that are consistent with its specific local admission control algorithm and take into account the holding preemption priority of established LSPs.
In the context of DS-TE, again, details on admission control algorithms are left for vendor differentiation, and formulas for computing the unreserved bandwidth for TE-Class[i] are outside the scope of this specification. However, DS-TE places the additional requirement on the LSR that the unreserved bandwidth values advertised MUST reflect all the BCs relevant to the CT associated with TE-Class[i] in accordance with the Bandwidth Constraints Model. Thus, formulas for computing "Unreserved TE-Class [i]" depend on the Bandwidth Constraints Model in use and MUST reflect how BCs apply to CTs. Example formulas for computing "Unreserved TE-Class [i]" Model are provided for the Russian Dolls Model and Maximum Allocation Model respectively in [DSTE-RDM] and [DSTE-MAM].
In the context of DS-TE, again, details on admission control algorithms are left for vendor differentiation, and formulas for computing the unreserved bandwidth for TE-Class[i] are outside the scope of this specification. However, DS-TE places the additional requirement on the LSR that the unreserved bandwidth values advertised MUST reflect all the BCs relevant to the CT associated with TE-Class[i] in accordance with the Bandwidth Constraints Model. Thus, formulas for computing "Unreserved TE-Class [i]" depend on the Bandwidth Constraints Model in use and MUST reflect how BCs apply to CTs. Example formulas for computing "Unreserved TE-Class [i]" Model are provided for the Russian Dolls Model and Maximum Allocation Model respectively in [DSTE-RDM] and [DSTE-MAM].
As with existing TE, DS-TE LSRs MUST consider the holding preemption priority of established LSPs (as opposed to their setup preemption priority) for the purpose of computing the unreserved bandwidth for TE-Class [i].
As with existing TE, DS-TE LSRs MUST consider the holding preemption priority of established LSPs (as opposed to their setup preemption priority) for the purpose of computing the unreserved bandwidth for TE-Class [i].
11.2. Admission Control Rules
11.2. Admission Control Rules
A DS-TE LSR MUST support the following admission control rule:
A DS-TE LSR MUST support the following admission control rule:
Regardless of how the admission control algorithm actually computes the unreserved bandwidth for TE-Class[i] for one of its local links, an LSP of bandwidth B, of setup preemption priority p and of Class- Type CTc is admissible on that link if, and only if,:
Regardless of how the admission control algorithm actually computes the unreserved bandwidth for TE-Class[i] for one of its local links, an LSP of bandwidth B, of setup preemption priority p and of Class- Type CTc is admissible on that link if, and only if,:
B <= Unreserved Bandwidth for TE-Class[i]
B <= Unreserved Bandwidth for TE-Class[i]
where TE-Class [i] maps to < CTc , p > in the TE-Class mapping configured on the LSR.
where TE-Class [i] maps to < CTc , p > in the TE-Class mapping configured on the LSR.
12. Security Considerations
12. Security Considerations
This document does not introduce additional security threats beyond those described for Diffserv ([DIFF-ARCH]) and MPLS Traffic Engineering ([TE-REQ], [RSVP-TE], [OSPF-TE], [ISIS-TE]) and the same
This document does not introduce additional security threats beyond those described for Diffserv ([DIFF-ARCH]) and MPLS Traffic Engineering ([TE-REQ], [RSVP-TE], [OSPF-TE], [ISIS-TE]) and the same
Le Faucheur Standards Track [Page 24] RFC 4124 Protocols for Diffserv-aware TE June 2005
Le Faucheur Standards Track [Page 24] RFC 4124 Protocols for Diffserv-aware TE June 2005
security measures and procedures described in these documents apply here. For example, the approach for defense against theft- and denial-of-service attacks discussed in [DIFF-ARCH], which consists of the combination of traffic conditioning at DS boundary nodes along with security and integrity of the network infrastructure within a Diffserv domain, may be followed when DS-TE is in use. Also, as stated in [TE-REQ], 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.
security measures and procedures described in these documents apply here. For example, the approach for defense against theft- and denial-of-service attacks discussed in [DIFF-ARCH], which consists of the combination of traffic conditioning at DS boundary nodes along with security and integrity of the network infrastructure within a Diffserv domain, may be followed when DS-TE is in use. Also, as stated in [TE-REQ], 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.
13. IANA Considerations
13. IANA Considerations
This document creates two new name spaces that are to be managed by IANA. Also, a number of assignments from existing name spaces have been made by IANA in this document. They are discussed below.
This document creates two new name spaces that are to be managed by IANA. Also, a number of assignments from existing name spaces have been made by IANA in this document. They are discussed below.
13.1. A New Name Space for Bandwidth Constraints Model Identifiers
13.1. A New Name Space for Bandwidth Constraints Model Identifiers
This document defines in Section 5.1 a "Bandwidth Constraints Model Id" field (name space) within the "Bandwidth Constraints" sub-TLV, both for OSPF and ISIS. The new name space has been created by the IANA and they will maintain this new name space. The field for this namespace is 1 octet, and IANA guidelines for assignments for this field are as follows:
This document defines in Section 5.1 a "Bandwidth Constraints Model Id" field (name space) within the "Bandwidth Constraints" sub-TLV, both for OSPF and ISIS. The new name space has been created by the IANA and they will maintain this new name space. The field for this namespace is 1 octet, and IANA guidelines for assignments for this field are as follows:
o values in the range 0-239 are to be assigned according to the
"Specification Required" policy defined in [IANA-CONS].
o values in the range 0-239 are to be assigned according to the "Specification Required" policy defined in [IANA-CONS].
o values in the range 240-255 are reserved for "Private Use" as
defined in [IANA-CONS].
o values in the range 240-255 are reserved for "Private Use" as defined in [IANA-CONS].
13.2. A New Name Space for Error Values under the "Diffserv-aware TE
Error"
13.2. A New Name Space for Error Values under the "Diffserv-aware TE Error"
An Error Code is an 8-bit quantity defined in [RSVP] that appears in an ERROR_SPEC object to define an error condition broadly. With each Error Code there may be a 16-bit Error Value (which depends on the Error Code) that further specifies the cause of the error.
An Error Code is an 8-bit quantity defined in [RSVP] that appears in an ERROR_SPEC object to define an error condition broadly. With each Error Code there may be a 16-bit Error Value (which depends on the Error Code) that further specifies the cause of the error.
This document defines in Section 6.5 a new RSVP error code, the "Diffserv-aware TE Error" (see Section 13.3.4). The Error Values for the "Diffserv-aware TE Error" constitute a new name space to be managed by IANA.
This document defines in Section 6.5 a new RSVP error code, the "Diffserv-aware TE Error" (see Section 13.3.4). The Error Values for the "Diffserv-aware TE Error" constitute a new name space to be managed by IANA.
This document defines, in Section 6.5, values 1 through 7 in that name space (see Section 13.3.5).
This document defines, in Section 6.5, values 1 through 7 in that name space (see Section 13.3.5).
Le Faucheur Standards Track [Page 25] RFC 4124 Protocols for Diffserv-aware TE June 2005
Le Faucheur Standards Track [Page 25] RFC 4124 Protocols for Diffserv-aware TE June 2005
Future allocations of values in this name space are to be assigned by IANA using the "Specification Required" policy defined in [IANA-CONS].
Future allocations of values in this name space are to be assigned by IANA using the "Specification Required" policy defined in [IANA-CONS].
13.3. Assignments Made in This Document
13.3. Assignments Made in This Document
13.3.1. Bandwidth Constraints sub-TLV for OSPF Version 2
13.3.1. Bandwidth Constraints sub-TLV for OSPF Version 2
[OSPF-TE] creates a name space for the sub-TLV types within the "Link TLV" of the Traffic Engineering Link State Advertisement (LSA) and rules for management of this name space by IANA.
[OSPF-TE] creates a name space for the sub-TLV types within the "Link TLV" of the Traffic Engineering Link State Advertisement (LSA) and rules for management of this name space by IANA.
This document defines in Section 5.1 a new sub-TLV, the "Bandwidth Constraints" sub-TLV, for the OSPF "Link" TLV. In accordance with the IANA considerations provided in [OSPF-TE], a sub-TLV type in the range 10 to 32767 was requested, and the value 17 has been assigned by IANA for the "Bandwidth Constraints" sub-TLV.
This document defines in Section 5.1 a new sub-TLV, the "Bandwidth Constraints" sub-TLV, for the OSPF "Link" TLV. In accordance with the IANA considerations provided in [OSPF-TE], a sub-TLV type in the range 10 to 32767 was requested, and the value 17 has been assigned by IANA for the "Bandwidth Constraints" sub-TLV.
13.3.2. Bandwidth Constraints sub-TLV for ISIS
13.3.2. Bandwidth Constraints sub-TLV for ISIS
[ISIS-TE] creates a name space for the sub-TLV types within the ISIS "Extended IS Reachability" TLV and rules for management of this name space by IANA.
[ISIS-TE] creates a name space for the sub-TLV types within the ISIS "Extended IS Reachability" TLV and rules for management of this name space by IANA.
This document defines in Section 5.1 a new sub-TLV, the "Bandwidth Constraints" sub-TLV, for the ISIS "Extended IS Reachability" TLV. In accordance with the IANA considerations provided in [ISIS-TE], a sub-TLV type was requested, and the value 22 has been assigned by IANA for the "Bandwidth Constraints" sub-TLV.
This document defines in Section 5.1 a new sub-TLV, the "Bandwidth Constraints" sub-TLV, for the ISIS "Extended IS Reachability" TLV. In accordance with the IANA considerations provided in [ISIS-TE], a sub-TLV type was requested, and the value 22 has been assigned by IANA for the "Bandwidth Constraints" sub-TLV.
13.3.3. CLASSTYPE Object for RSVP
13.3.3. CLASSTYPE Object for RSVP
[RSVP] defines the Class Number name space for RSVP object, which is managed by IANA. Currently allocated Class Numbers are listed at http://www.iana.org/assignments/rsvp-parameters.
[RSVP] defines the Class Number name space for RSVP object, which is managed by IANA. Currently allocated Class Numbers are listed at http://www.iana.org/assignments/rsvp-parameters.
This document defines in Section 6.2.1 a new RSVP object, the CLASSTYPE object. IANA has assigned a Class Number for this RSVP object from the range defined in Section 3.10 of [RSVP] for objects that, if not understood, cause the entire RSVP message to be rejected with an error code of "Unknown Object Class". Such objects are identified by a zero in the most significant bit of the class number (i.e., Class-Num = 0bbbbbbb).
This document defines in Section 6.2.1 a new RSVP object, the CLASSTYPE object. IANA has assigned a Class Number for this RSVP object from the range defined in Section 3.10 of [RSVP] for objects that, if not understood, cause the entire RSVP message to be rejected with an error code of "Unknown Object Class". Such objects are identified by a zero in the most significant bit of the class number (i.e., Class-Num = 0bbbbbbb).
IANA assigned Class-Number 66 to the CLASSTYPE object. C_Type 1 is defined in this document for the CLASSTYPE object.
IANA assigned Class-Number 66 to the CLASSTYPE object. C_Type 1 is defined in this document for the CLASSTYPE object.
Le Faucheur Standards Track [Page 26] RFC 4124 Protocols for Diffserv-aware TE June 2005
Le Faucheur Standards Track [Page 26] RFC 4124 Protocols for Diffserv-aware TE June 2005
13.3.4. "Diffserv-aware TE Error" Error Code
13.3.4. "Diffserv-aware TE Error" Error Code
[RSVP] defines the Error Code name space and rules for management of this name space by IANA. Currently allocated Error Codes are listed at http://www.iana.org/assignments/rsvp-parameters.
[RSVP] defines the Error Code name space and rules for management of this name space by IANA. Currently allocated Error Codes are listed at http://www.iana.org/assignments/rsvp-parameters.
This document defines in Section 6.5 a new RSVP Error Code, the "Diffserv-aware TE Error". In accordance with the IANA considerations provided in [RSVP], Error Code 28 was assigned by IANA to the "Diffserv-aware TE Error".
This document defines in Section 6.5 a new RSVP Error Code, the "Diffserv-aware TE Error". In accordance with the IANA considerations provided in [RSVP], Error Code 28 was assigned by IANA to the "Diffserv-aware TE Error".
13.3.5. Error Values for "Diffserv-aware TE Error"
13.3.5. Error Values for "Diffserv-aware TE Error"
An Error Code is an 8-bit quantity defined in [RSVP] that appears in an ERROR_SPEC object to define an error condition broadly. With each Error Code there may be a 16-bit Error Value (which depends on the Error Code) that further specifies the cause of the error.
An Error Code is an 8-bit quantity defined in [RSVP] that appears in an ERROR_SPEC object to define an error condition broadly. With each Error Code there may be a 16-bit Error Value (which depends on the Error Code) that further specifies the cause of the error.
This document defines in Section 6.5 a new RSVP error code, the "Diffserv-aware TE Error" (see Section 13.3.4). The Error Values for the "Diffserv-aware TE Error" constitute a new name space to be managed by IANA.
This document defines in Section 6.5 a new RSVP error code, the "Diffserv-aware TE Error" (see Section 13.3.4). The Error Values for the "Diffserv-aware TE Error" constitute a new name space to be managed by IANA.
This document defines, in Section 6.5, the following Error Values for the "Diffserv-aware TE Error":
This document defines, in Section 6.5, the following Error Values for the "Diffserv-aware TE Error":
Value Error
Value Error
1 Unexpected CLASSTYPE object
2 Unsupported Class-Type
3 Invalid Class-Type value
4 Class-Type and setup priority do not form a configured
TE-Class
5 Class-Type and holding priority do not form a configured
TE-Class
6 Class-Type and setup priority do not form a configured
TE-Class AND Class-Type and holding priority do not
form a configured TE-Class
7 Inconsistency between signaled PSC and signaled
Class-Type
8 Inconsistency between signaled PHBs and signaled
Class-Type
1 Unexpected CLASSTYPE object 2 Unsupported Class-Type 3 Invalid Class-Type value 4 Class-Type and setup priority do not form a configured TE-Class 5 Class-Type and holding priority do not form a configured TE-Class 6 Class-Type and setup priority do not form a configured TE-Class AND Class-Type and holding priority do not form a configured TE-Class 7 Inconsistency between signaled PSC and signaled Class-Type 8 Inconsistency between signaled PHBs and signaled Class-Type
See Section 13.2 for allocation of other values in that name space.
See Section 13.2 for allocation of other values in that name space.
Le Faucheur Standards Track [Page 27] RFC 4124 Protocols for Diffserv-aware TE June 2005
Le Faucheur Standards Track [Page 27] RFC 4124 Protocols for Diffserv-aware TE June 2005
14. Acknowledgements
14. Acknowledgements
We thank Martin Tatham, Angela Chiu, and Pete Hicks for their earlier contribution in this work. We also thank Sanjaya Choudhury for his thorough review and suggestions.
We thank Martin Tatham, Angela Chiu, and Pete Hicks for their earlier contribution in this work. We also thank Sanjaya Choudhury for his thorough review and suggestions.
Le Faucheur Standards Track [Page 28] RFC 4124 Protocols for Diffserv-aware TE June 2005
Le Faucheur Standards Track [Page 28] RFC 4124 Protocols for Diffserv-aware TE June 2005
Appendix A: Prediction for Multiple Path Computation
Appendix A: Prediction for Multiple Path Computation
There are situations where a head-end needs to compute paths for multiple LSPs over a short period of time. There are potential advantages for the head-end in trying to predict the impact of the n-th LSP on the unreserved bandwidth when computing the path for the (n+1)-th LSP, before receiving updated IGP information. For example, better load-distribution of the multiple LSPs would be performed across multiple paths. Also, when the (n+1)-th LSP would no longer fit on a link after establishment of the n-th LSP, the head-end would avoid Connection Admission Control (CAC) rejection. Although there are a number of conceivable scenarios where worse situations might result, doing such predictions is more likely to improve situations. As a matter of fact, a number of network administrators have elected to use such predictions when deploying existing TE.
There are situations where a head-end needs to compute paths for multiple LSPs over a short period of time. There are potential advantages for the head-end in trying to predict the impact of the n-th LSP on the unreserved bandwidth when computing the path for the (n+1)-th LSP, before receiving updated IGP information. For example, better load-distribution of the multiple LSPs would be performed across multiple paths. Also, when the (n+1)-th LSP would no longer fit on a link after establishment of the n-th LSP, the head-end would avoid Connection Admission Control (CAC) rejection. Although there are a number of conceivable scenarios where worse situations might result, doing such predictions is more likely to improve situations. As a matter of fact, a number of network administrators have elected to use such predictions when deploying existing TE.
Such predictions are local matters, are optional, and are outside the scope of this specification.
Such predictions are local matters, are optional, and are outside the scope of this specification.
Where such predictions are not used, the optional BC sub-TLV and the optional Maximum Reservable Bandwidth sub-TLV need not be advertised in IGP for the purpose of path computation, since the information contained in the Unreserved Bw sub-TLV is all that is required by Head-Ends to perform Constraint-Based Routing.
Where such predictions are not used, the optional BC sub-TLV and the optional Maximum Reservable Bandwidth sub-TLV need not be advertised in IGP for the purpose of path computation, since the information contained in the Unreserved Bw sub-TLV is all that is required by Head-Ends to perform Constraint-Based Routing.
Where such predictions are used on head-ends, the optional BCs sub- TLV and the optional Maximum Reservable Bandwidth sub-TLV MAY be advertised in IGP. This is in order for the head-ends to predict as accurately as possible how an LSP affects unreserved bandwidth values for subsequent LSPs.
Where such predictions are used on head-ends, the optional BCs sub- TLV and the optional Maximum Reservable Bandwidth sub-TLV MAY be advertised in IGP. This is in order for the head-ends to predict as accurately as possible how an LSP affects unreserved bandwidth values for subsequent LSPs.
Remembering that actual admission control algorithms are left for vendor differentiation, we observe that predictions can only be performed effectively when the head-end LSR predictions are based on the same (or a very close) admission control algorithm as that used by other LSRs.
Remembering that actual admission control algorithms are left for vendor differentiation, we observe that predictions can only be performed effectively when the head-end LSR predictions are based on the same (or a very close) admission control algorithm as that used by other LSRs.
Appendix B: Solution Evaluation
Appendix B: Solution Evaluation
B.1. Satisfying Detailed Requirements
B.1. Satisfying Detailed Requirements
This DS-TE Solution addresses all the scenarios presented in [DSTE-REQ].
This DS-TE Solution addresses all the scenarios presented in [DSTE-REQ].
It also satisfies all the detailed requirements presented in [DSTE-REQ].
It also satisfies all the detailed requirements presented in [DSTE-REQ].
Le Faucheur Standards Track [Page 29] RFC 4124 Protocols for Diffserv-aware TE June 2005
Le Faucheur Standards Track [Page 29] RFC 4124 Protocols for Diffserv-aware TE June 2005
The objective set out in the last paragraph of Section 4.7 of [DSTE-REQ], "Overbooking", is only partially addressed by this DS-TE solution. Through support of the "LSP size Overbooking" and "Link Size Overbooking" methods, this DS-TE solution effectively allows CTs to have different overbooking ratios and simultaneously allows overbooking to be tweaked differently (collectively across all CTs) on different links. But, in a general sense, it does not allow the effective overbooking ratio of every CT to be tweaked differently in different parts of the network independently of other CTs, while maintaining accurate bandwidth accounting of how different CTs mutually affect each other through shared BCs (such as the Maximum Reservable Bandwidth).
The objective set out in the last paragraph of Section 4.7 of [DSTE-REQ], "Overbooking", is only partially addressed by this DS-TE solution. Through support of the "LSP size Overbooking" and "Link Size Overbooking" methods, this DS-TE solution effectively allows CTs to have different overbooking ratios and simultaneously allows overbooking to be tweaked differently (collectively across all CTs) on different links. But, in a general sense, it does not allow the effective overbooking ratio of every CT to be tweaked differently in different parts of the network independently of other CTs, while maintaining accurate bandwidth accounting of how different CTs mutually affect each other through shared BCs (such as the Maximum Reservable Bandwidth).
B.2. Flexibility
B.2. Flexibility
This DS-TE solution supports 8 CTs. It is entirely flexible as to how Traffic Trunks are grouped together into a CT.
This DS-TE solution supports 8 CTs. It is entirely flexible as to how Traffic Trunks are grouped together into a CT.
B.3. Extendibility
B.3. Extendibility
A maximum of 8 CTs is considered more than comfortable by the authors of this document. A maximum of 8 TE-Classes is considered sufficient by the authors of this document. However, this solution could be extended to support more CTs or more TE-Classes if deemed necessary in the future; this would necessitate additional IGP extensions beyond those specified in this document.
A maximum of 8 CTs is considered more than comfortable by the authors of this document. A maximum of 8 TE-Classes is considered sufficient by the authors of this document. However, this solution could be extended to support more CTs or more TE-Classes if deemed necessary in the future; this would necessitate additional IGP extensions beyond those specified in this document.
Although the prime objective of this solution is support of Diffserv-aware Traffic Engineering, its mechanisms are not tightly coupled with Diffserv. This makes the solution amenable, or more easily extendable, for support of potential other future Traffic Engineering applications.
Although the prime objective of this solution is support of Diffserv-aware Traffic Engineering, its mechanisms are not tightly coupled with Diffserv. This makes the solution amenable, or more easily extendable, for support of potential other future Traffic Engineering applications.
B.4. Scalability
B.4. Scalability
This DS-TE solution is expected to have a very small scalability impact compared to that of existing TE.
This DS-TE solution is expected to have a very small scalability impact compared to that of existing TE.
From an IGP viewpoint, the amount of mandatory information to be advertised is identical to that of existing TE. One additional sub- TLV has been specified, but its use is optional, and it only contains a limited amount of static information (at most 8 BCs).
From an IGP viewpoint, the amount of mandatory information to be advertised is identical to that of existing TE. One additional sub- TLV has been specified, but its use is optional, and it only contains a limited amount of static information (at most 8 BCs).
We expect no noticeable impact on LSP Path computation because, as with existing TE, this solution only requires Constrained Shortest Path First (CSPF) to consider a single unreserved bandwidth value for any given LSP.
We expect no noticeable impact on LSP Path computation because, as with existing TE, this solution only requires Constrained Shortest Path First (CSPF) to consider a single unreserved bandwidth value for any given LSP.
Le Faucheur Standards Track [Page 30] RFC 4124 Protocols for Diffserv-aware TE June 2005
Le Faucheur Standards Track [Page 30] RFC 4124 Protocols for Diffserv-aware TE June 2005
From a signaling viewpoint, we expect no significant impact due to this solution because it only requires processing of one additional item of information (the Class-Type) and does not significantly increase the likelihood of CAC rejection. Note that DS-TE has some inherent impact on LSP signaling in that it assumes that different classes of traffic are split over different LSPs so that more LSPs need to be signaled. However, this is due to the DS-TE concept itself and not to the actual DS-TE solution discussed here.
From a signaling viewpoint, we expect no significant impact due to this solution because it only requires processing of one additional item of information (the Class-Type) and does not significantly increase the likelihood of CAC rejection. Note that DS-TE has some inherent impact on LSP signaling in that it assumes that different classes of traffic are split over different LSPs so that more LSPs need to be signaled. However, this is due to the DS-TE concept itself and not to the actual DS-TE solution discussed here.
B.5. Backward Compatibility/Migration
B.5. Backward Compatibility/Migration
This solution is expected to allow smooth migration from existing TE to DS-TE. This is because existing TE can be supported as a particular configuration of DS-TE. This means that an "upgraded" LSR with a DS-TE implementation can directly interwork with an "old" LSR supporting existing TE only.
This solution is expected to allow smooth migration from existing TE to DS-TE. This is because existing TE can be supported as a particular configuration of DS-TE. This means that an "upgraded" LSR with a DS-TE implementation can directly interwork with an "old" LSR supporting existing TE only.
This solution is expected to allow smooth migration when the number of CTs actually deployed is increased, as it only requires configuration changes. However, these changes need to be performed in a coordinated manner across the DS-TE domain.
This solution is expected to allow smooth migration when the number of CTs actually deployed is increased, as it only requires configuration changes. However, these changes need to be performed in a coordinated manner across the DS-TE domain.
Appendix C: Interoperability with Non-DS-TE Capable LSRs
Appendix C: Interoperability with Non-DS-TE Capable LSRs
This DSTE solution allows operations in a hybrid network where some LSRs are DS-TE capable and some are not, as may occur during migration phases. This appendix discusses the constraints and operations in such hybrid networks.
This DSTE solution allows operations in a hybrid network where some LSRs are DS-TE capable and some are not, as may occur during migration phases. This appendix discusses the constraints and operations in such hybrid networks.
We refer to the set of DS-TE-capable LSRs as the DS-TE domain. We refer to the set of non-DS-TE-capable (but TE-capable) LSRs as the TE-domain.
We refer to the set of DS-TE-capable LSRs as the DS-TE domain. We refer to the set of non-DS-TE-capable (but TE-capable) LSRs as the TE-domain.
Hybrid operations require that the TE-Class mapping in the DS-TE domain be configured so that:
Hybrid operations require that the TE-Class mapping in the DS-TE domain be configured so that:
- a TE-Class exists for CT0 for every preemption priority
actually used in the TE domain, and
- a TE-Class exists for CT0 for every preemption priority actually used in the TE domain, and
- the index in the TE-class mapping for each of these TE-
Classes is equal to the preemption priority.
- the index in the TE-class mapping for each of these TE- Classes is equal to the preemption priority.
Le Faucheur Standards Track [Page 31] RFC 4124 Protocols for Diffserv-aware TE June 2005
Le Faucheur Standards Track [Page 31] RFC 4124 Protocols for Diffserv-aware TE June 2005
For example, imagine the TE domain uses preemption 2 and 3. Then, DS-TE can be deployed in the same network by including the following TE-Classes in the TE-Class mapping:
For example, imagine the TE domain uses preemption 2 and 3. Then, DS-TE can be deployed in the same network by including the following TE-Classes in the TE-Class mapping:
i <---> CT preemption
====================================
2 CT0 2
3 CT0 3
i <---> CT preemption ==================================== 2 CT0 2 3 CT0 3
Another way to look at this is to say that although the whole TE- class mapping does not have to be consistent with the TE domain, the subset of this TE-Class mapping applicable to CT0 effectively has to be consistent with the TE domain.
Another way to look at this is to say that although the whole TE- class mapping does not have to be consistent with the TE domain, the subset of this TE-Class mapping applicable to CT0 effectively has to be consistent with the TE domain.
Hybrid operations also require that:
Hybrid operations also require that:
- non-DS-TE-capable LSRs be configured to advertise the Maximum
Reservable Bandwidth, and
- non-DS-TE-capable LSRs be configured to advertise the Maximum Reservable Bandwidth, and
- DS-TE-capable LSRs be configured to advertise BCs (using the
Max Reservable Bandwidth sub-TLV as well as the BCs sub-TLV,
as specified in Section 5.1).
- DS-TE-capable LSRs be configured to advertise BCs (using the Max Reservable Bandwidth sub-TLV as well as the BCs sub-TLV, as specified in Section 5.1).
This allows DS-TE-capable LSRs to identify non-DS-TE-capable LSRs unambiguously.
This allows DS-TE-capable LSRs to identify non-DS-TE-capable LSRs unambiguously.
Finally, hybrid operations require that non-DS-TE-capable LSRs be able to accept Unreserved Bw sub-TLVs containing non decreasing bandwidth values (i.e., with Unreserved [p] < Unreserved [q] with p < q).
Finally, hybrid operations require that non-DS-TE-capable LSRs be able to accept Unreserved Bw sub-TLVs containing non decreasing bandwidth values (i.e., with Unreserved [p] < Unreserved [q] with p < q).
In such hybrid networks, the following apply:
In such hybrid networks, the following apply:
- CT0 LSPs can be established by both DS-TE-capable LSRs and
non-DS-TE-capable LSRs.
- CT0 LSPs can be established by both DS-TE-capable LSRs and non-DS-TE-capable LSRs.
- CT0 LSPs can transit via (or terminate at) both DS-TE-capable
LSRs and non-DS-TE-capable LSRs.
- CT0 LSPs can transit via (or terminate at) both DS-TE-capable LSRs and non-DS-TE-capable LSRs.
- LSPs from other CTs can only be established by DS-TE-capable
LSRs.
- LSPs from other CTs can only be established by DS-TE-capable LSRs.
- LSPs from other CTs can only transit via (or terminate at)
DS-TE-capable LSRs.
- LSPs from other CTs can only transit via (or terminate at) DS-TE-capable LSRs.
Le Faucheur Standards Track [Page 32] RFC 4124 Protocols for Diffserv-aware TE June 2005
Le Faucheur Standards Track [Page 32] RFC 4124 Protocols for Diffserv-aware TE June 2005
Let us consider the following example to illustrate operations:
Let us consider the following example to illustrate operations:
LSR0--------LSR1----------LSR2
Link01 Link12
LSR0--------LSR1----------LSR2 Link01 Link12
where:
LSR0 is a non-DS-TE-capable LSR
LSR1 and LSR2 are DS-TE-capable LSRs
where: LSR0 is a non-DS-TE-capable LSR LSR1 and LSR2 are DS-TE-capable LSRs
Let's assume again that preemptions 2 and 3 are used in the TE-domain
and that the following TE-Class mapping is configured on LSR1 and
LSR2:
i <---> CT preemption
====================================
0 CT1 0
1 CT1 1
2 CT0 2
3 CT0 3
rest unused
Let's assume again that preemptions 2 and 3 are used in the TE-domain and that the following TE-Class mapping is configured on LSR1 and LSR2: i <---> CT preemption ==================================== 0 CT1 0 1 CT1 1 2 CT0 2 3 CT0 3 rest unused
LSR0 is configured with a Max Reservable Bandwidth = m01 for Link01. LSR1 is configured with a BC0 = x0, a BC1 = x1 (possibly = 0), and a Max Reservable Bandwidth = m10 (possibly = m01) for Link01.
LSR0 is configured with a Max Reservable Bandwidth = m01 for Link01. LSR1 is configured with a BC0 = x0, a BC1 = x1 (possibly = 0), and a Max Reservable Bandwidth = m10 (possibly = m01) for Link01.
In IGP for Link01, LSR0 will advertise:
In IGP for Link01, LSR0 will advertise:
- Max Reservable Bw sub-TLV = <m01>
- Max Reservable Bw sub-TLV = <m01>
- Unreserved Bw sub-TLV = <CT0/0, CT0/1, CT0/2, CT0/3, CT0/4,
CT0/5, CT0/6, CT0/7>
- Unreserved Bw sub-TLV = <CT0/0, CT0/1, CT0/2, CT0/3, CT0/4, CT0/5, CT0/6, CT0/7>
On receipt of such advertisement, LSR1 will:
On receipt of such advertisement, LSR1 will:
- understand that LSR0 is not DS-TE-capable because it
advertised a Max Reservable Bw sub-TLV and no Bandwidth
Constraints sub-TLV, and
- understand that LSR0 is not DS-TE-capable because it advertised a Max Reservable Bw sub-TLV and no Bandwidth Constraints sub-TLV, and
- conclude that only CT0 LSPs can transit via LSR0 and that
only the values CT0/2 and CT0/3 are meaningful in the
Unreserved Bw sub-TLV. LSR1 may effectively behave as if the
six other values contained in the Unreserved Bw sub-TLV were
set to zero.
- conclude that only CT0 LSPs can transit via LSR0 and that only the values CT0/2 and CT0/3 are meaningful in the Unreserved Bw sub-TLV. LSR1 may effectively behave as if the six other values contained in the Unreserved Bw sub-TLV were set to zero.
Le Faucheur Standards Track [Page 33] RFC 4124 Protocols for Diffserv-aware TE June 2005
Le Faucheur Standards Track [Page 33] RFC 4124 Protocols for Diffserv-aware TE June 2005
In IGP for Link01, LSR1 will advertise:
In IGP for Link01, LSR1 will advertise:
- Max Reservable Bw sub-TLV = <m10>
- Max Reservable Bw sub-TLV = <m10>
- Bandwidth Constraints sub-TLV = <BC Model ID, x0, x1>
- Bandwidth Constraints sub-TLV = <BC Model ID, x0, x1>
- Unreserved Bw sub-TLV =
<CT1/0, CT1/1, CT0/2, CT0/3, 0, 0, 0, 0>
- Unreserved Bw sub-TLV = <CT1/0, CT1/1, CT0/2, CT0/3, 0, 0, 0, 0>
On receipt of such advertisement, LSR0 will:
On receipt of such advertisement, LSR0 will:
- ignore the Bandwidth Constraints sub-TLV (unrecognized)
- ignore the Bandwidth Constraints sub-TLV (unrecognized)
- correctly process CT0/2 and CT0/3 in the Unreserved Bw sub-
TLV and use these values for CTO LSP establishment
- correctly process CT0/2 and CT0/3 in the Unreserved Bw sub- TLV and use these values for CTO LSP establishment
- incorrectly believe that the other values contained in the
Unreserved Bw sub-TLV relate to other preemption priorities
for CT0; but it will actually never use those since we assume
that only preemptions 2 and 3 are used in the TE domain.
- incorrectly believe that the other values contained in the Unreserved Bw sub-TLV relate to other preemption priorities for CT0; but it will actually never use those since we assume that only preemptions 2 and 3 are used in the TE domain.
Normative References
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. and W. Lai, "Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering", RFC 3564, July 2003.
[MPLS-ARCH] Rosen, E., Viswanathan, A. and R. Callon,
"Multiprotocol Label Switching Architecture", RFC 3031,
January 2001.
[MPLS-アーチ] ローゼンとE.とViswanathanとA.とR.Callon、「Multiprotocolラベル切り換え構造」、RFC3031、2001年1月。
[TE-REQ] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and
J. McManus, "Requirements for Traffic Engineering Over
MPLS", RFC 2702, September 1999.
[Te-REQ] AwducheとD.とマルコムとJ.とAgogbuaとJ.、オデルとM.とJ.マクマナス、「MPLSの上の交通工学のための要件」RFC2702(1999年9月)。
[OSPF-TE] Katz, D., Kompella, K. and D. Yeung, "Traffic
Engineering (TE) Extensions to OSPF Version 2", RFC
3630, September 2003.
[OSPF-Te] キャッツとD.とKompellaとK.とD.Yeung、「(Te)拡大をOSPFにバージョン2インチ設計する交通、RFC3630、2003年9月。」
[ISIS-TE] Smit, H. and T. Li, "Intermediate System to
Intermediate System (IS-IS) Extensions for Traffic
Engineering (TE)", RFC 3784, June 2004.
[イシス-Te] スミット、H.、およびT.李、「中間システムへの中間システム、(-、)、交通工学(Te)のための拡大、」、RFC3784(2004年6月)
[RSVP-TE] 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.
[RSVP-Te] Awduche、D.、バーガー、L.、ガン、D.、李、T.、Srinivasan、V.、およびG.が飲み込まれる、「RSVP-Te:」 「LSP TunnelsのためのRSVPへの拡大」、RFC3209、2001年12月。
Le Faucheur Standards Track [Page 34] RFC 4124 Protocols for Diffserv-aware TE June 2005
Le Faucheur規格は2005年6月にDiffserv意識しているTeのためにRFC4124プロトコルを追跡します[34ページ]。
[RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S. and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version
1 Functional Specification", RFC 2205, September 1997.
[RSVP] ブレーデン、R.、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、1997年9月。
[DIFF-MPLS] Le Faucheur, F., Wu, L., Davie, B., Davari, S.,
Vaananen, P., Krishnan, R., Cheval, P. and J. Heinanen,
"Multi-Protocol Label Switching (MPLS) Support of
Differentiated Services", RFC 3270, May 2002.
[デフ-MPLS]Le Faucheur、F.、ウー、L.、デイビー、B.、Davari、S.、バーナネン、P.、クリシュナン、R.、シェヴァル、P.、およびJ.Heinanen、「微分されたサービスのマルチプロトコルラベルスイッチング(MPLS)サポート」(RFC3270)は2002がそうするかもしれません。
[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
有益な参照
[DIFF-ARCH] Blake, S., Black, D., Carlson, M., Davies, E., Wang,
Z., and W. Weiss, "An Architecture for Differentiated
Service", RFC 2475, December 1998.
[デフアーチ] ブレーク、S.は黒くされます、D.、カールソン、M.、デイヴィース、E.、ワング、Z.とW.ウィス、「微分されたサービスのための構造」RFC2475、1998年12月。
[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日
[DSTE-MAM] Le Faucheur, F. and W. Lai, "Maximum Allocation
Bandwidth Constraints Model for Diffserv-aware Traffice
Engineering", RFC 4125, June 2005.
[DSTE-MAM] Le FaucheurとF.とW.レイ、「最大の配分帯域幅規制はDiffserv意識しているTraffice工学のためにモデル化する」RFC4125、2005年6月。
[DSTE-MAR] Ash, J., "Max Allocation with Reservation Bandwidth
Constraints Model for DiffServ-aware MPLS Traffic
Engineering & Performance Comparisons", RFC 4126, June
2005.
[DSTE-3月] 灰、J.、「DiffServ意識しているMPLS交通工学とパフォーマンス比較の予約帯域幅規制モデルとのマックスAllocation」、RFC4126(2005年6月)。
[GMPLS-SIG] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[GMPLS-SIG] バーガー、L.、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)のシグナリングの機能的な記述」、RFC3471、2003年1月。
[GMPLS-ROUTE] Kompella, et al., "Routing Extensions in Support of
Generalized MPLS", Work in Progress.
[GMPLS-ROUTE] Kompella、他、「一般化されたMPLSを支持したルート設定拡大」、ProgressのWork。
[BUNDLE] Kompella, Rekhter, Berger, "Link Bundling in MPLS
Traffic Engineering", Work in Progress.
Rekhter、バーガー、「MPLS交通工学におけるリンクバンドリング」という[バンドル]Kompellaは進行中で働いています。
[HIERARCHY] Kompella, Rekhter, "LSP Hierarchy with Generalized MPLS
TE", Work in Progress.
Rekhter、「一般化されたMPLS TeがあるLSP階層構造」という[階層構造]Kompellaは進行中で働いています。
Le Faucheur Standards Track [Page 35] RFC 4124 Protocols for Diffserv-aware TE June 2005
Le Faucheur規格は2005年6月にDiffserv意識しているTeのためにRFC4124プロトコルを追跡します[35ページ]。
[REROUTE] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May
2005.
[コースを変更します]なべ、P.、ツバメ、G.、およびA.Atlas(「LSP Tunnelsのために速くRSVP-Teに拡大を別ルートで送ってください」、RFC4090)は2005がそうするかもしれません。
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 Standards Track [Page 36] RFC 4124 Protocols for Diffserv-aware TE June 2005
Le Faucheur規格は2005年6月にDiffserv意識しているTeのためにRFC4124プロトコルを追跡します[36ページ]。
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 Standards Track [Page 37]
Le Faucheur標準化過程[37ページ]
一覧
スポンサーリンク
