Network Working Group F. Le Faucheur, Ed.
Request for Comments: 4124 Cisco Systems, Inc.
Category: Standards Track June 2005
Protocol Extensions for Support of
Diffserv-aware MPLS Traffic Engineering
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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（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トラフィックエンジニアリング（DS-TE）をサポートするためのプロトコルの拡張機能を指定します。これは、内部ゲートウェイプロトコル（IGP）すでにRFC 3630、RFC 3784でMPLSトラフィックエンジニアリングを既存のために定義された拡張機能、およびそれらを超える追加IGPの拡張機能の数の意味論の一般化が含まれます。また、これは、RSVP-TEをするMPLSトラフィックエンジニアリングを既存の既にRFC 3209で指定されたものを超えて、シグナリングの拡張機能が含まれています。これらの拡張機能は、DS-TEのための要件は、RFC 3564で綴ら取り組みます。
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
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
[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]差別・サービス（DiffServ）のサポートのためのサービスプロバイダーの要件を提示は、MPLSトラフィックエンジニアリング（DSTE）を-aware。これは、トラフィックの異なるクラスに対して異なる帯域幅の制約を強制することができるように基本的な要件が含まれています。
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).
この文書では、IGPとRSVP-TEシグナリングの拡張子を指定します（既存のために指定されたものを超えてMPLSトラフィックエンジニアリング[OSPF-TE] [ISIS-TE] [RSVP-TE]）[DSTEで綴らDSTE要件をサポートするための-REQ]分散制約ベースのルーティングに頼る含めた環境（例えば、スイッチングルータヘッドエンドラベルを含む経路計算）。
[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]は帯域幅制約モデルの定義と例を提供します。本書では、特定の帯域幅の制約モデルを指定しても負いません。特定の帯域幅の制約モデルは、この文書の範囲外です。この文書で指定されたDSTEの拡張子は、考えられるすべての帯域幅の制約モデルをサポートするのに十分ではないかもしれないが、彼らは[DSTE - RDM]、[DSTE-MAM]で指定された最大割当モデルに指定されたロシアの人形のモデルをサポートしています、および[DSTE-MAR]で指定された予約モデルでの最大配分。
There may be differences between the quality of service expressed and obtained with Diffserv without DS-TE and with DS-TE. Because DS-TE uses Constraint-Based Routing, and because of the type of admission control capabilities it adds to Diffserv, DS-TE has capabilities for traffic that Diffserv does not: Diffserv does not indicate preemption, by intent, whereas DS-TE describes multiple levels of preemption for its Class-Types. Also, Diffserv does not support any means of explicitly controlling overbooking, while DS-TE allows this. When considering a complete quality of service environment, with Diffserv routers and DS-TE, it is important to consider these differences carefully.
サービスの品質との違いがあるかもしれない表現とDS-TEなしとDS-TEでのDiffservで得られました。 DS-TEを説明する一方で、Diffservのは意図によって、プリエンプションを示すものではありません：DS-TEは、制約ベースのルーティング、およびので、それはDiffservのに追加アドミッション制御機能の種類を使用しているため、DS-TEは、Diffservのがないトラフィックのための機能を備えていますそのクラスタイプのプリエンプションの複数のレベル。 DS-TEがこれを可能にしながら、また、DiffServは、明示的にオーバーブッキング制御のいずれかの手段をサポートしていません。 DiffservルータとDS-TEと、サービス環境の完全な品質を考えるとき、慎重にこれらの違いを考慮することが重要です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
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.)
この文書では、数人の著者の集合的な仕事でした。テキストやコンテンツはエディタと以下のとおり共著者によって寄与されました。 （編集者の連絡先情報は、編集者のアドレス]セクションに表示されます。）
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プロトコルドリブンネットワークスジュニパーネットワークス株式会社1381 Kildaire農道＃288 1194 N.マチルダアベニュー。カリー、NC 27511、USAカリフォルニア州サニーベール94099
Phone: (919) 852-5160 EMail: kireeti@juniper.net EMail: jboyle@pdnets.com
電話：（919）852-5160 Eメール：kireeti@juniper.net Eメール：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.ナドーテナーネットワークシスコシステムズ社100 Nagog公園250アポロドライブアクトン、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 Eメール：btownsend@tenornetworks.com Eメール：tnadeau@cisco.com
Darek Skalecki Nortel Networks 3500 Carling Ave, Nepean K2H 8E9
Darek Skalecki Nortel Networksの3500カーリングアベニュー、ネピアンK2H 8E9
Phone: +1-613-765-2252 EMail: dareks@nortelnetworks.com
電話：+ 1-613-765-2252 Eメール：dareks@nortelnetworks.com
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).
トラフィックトランク：ラベルスイッチパス（LSP）の内側に配置される（即ち、DS-TEの観点から等価的に処理された）同じクラスのトラフィックフローの集合。
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.
クラス型（CT）：帯域幅の制約の特定のセットによって支配され、リンクを通過するトラフィックトランクのセット。 CTは、リンク帯域幅割り当て、制約ベースのルーティングとアドミッション制御の目的のために使用されます。与えられたトラフィックトランクは、すべてのリンク上の同じCTに属します。
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-クラス：I：のペア。クラスII型。先取り優先順位は、そのクラス型を可能にしました。これは、そのクラス型からのトラフィックトランクを運ぶLSPがセットアップ優先順位、保持優先度、またはその両方としてその先取り優先順位を使用できることを意味します。
Definitions for a number of MPLS terms are not repeated here. They can be found in [MPLS-ARCH].
MPLS用語の数の定義はここでは繰り返しません。彼らは[MPLS-ARCH]で見つけることができます。
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.
このセクションでは、[OSPF-TE]、[ISIS-TE]、[TE-REQ]ごとにMPLSトラフィックエンジニアリングのためのサポート、設定可能なパラメータとの違いについて説明し、[RSVP-TE]。他のすべてのパラメータは変更されません。
[DSTE-REQ] states that "Regardless of the Bandwidth Constraints Model, the DS-TE solution MUST allow support for up to 8 BCs."
[DSTE - REQ]「は関係なく、帯域幅の制約モデルの、DSTEソリューションは、最大8つのBCのサポートを許容しなければなりません。」と述べています
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の場合は、既存の「最大予約リンク帯域幅」パラメータが保持されますが、そのように、その意味は、独立して、使用中の帯域幅の制約モデルの、すべてのクラスタイプで一般化し、総帯域幅の制約として解釈されます。
SUM (Reserved (CTc)) <= Max Reservable Bandwidth,
SUM（予約済み（CTC））<=最大予約可能帯域幅、
where the SUM is across all values of "c" in the range 0 <= c <= 7.
ここで、SUMは、範囲0 <= C <= 7中の「C」のすべての値を横切っています。
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つの可能性のBC、すなわち、BC0、BC1、... BC7ある最大8つの追加のリンクパラメータの設定のために提供しなければなりません。 LSRは、サポートされている帯域幅の制約モデル（すなわち、どのようなBCどのようなクラス型に適用され、どのように）に従い、これらのBCを解釈しなければなりません。
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.
帯域幅の制約モデルは、これらのBCのために設定される値のうちのいくつかの関係を課した場合、LSRは、設定時とを施行しなければなりません。ロシア人形帯域幅制約モデル（[DSTE-RDM]）が使用される場合、例えば、LSRは、BCIがより小さいまたはI Jよりも大きいBCJ、に等しく設定されていることを確認し、そのBC0に等しいであることを確認しなければなりません最大予約可能帯域幅。最大割り当てモデル（[DSTE-MAM]）が使用されているときに、別の例として、LSRは、全てのBCIが小さいか又は最大予約可能帯域幅に等しく設定されていることを確認しなければなりません。
DS-TE enables a network administrator to apply different overbooking (or underbooking) ratios for different CTs.
DS-TEは、異なるCTのための異なるオーバーブッキング（又は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.
アカウントに与えられたLSPの帯域幅サイズを確立する時に考慮さLSPに関連付けられた順序集合（OA）又はCT用のオーバーブッキング/ underbooking比の適切なを取る（I）。私たちは、「LSPサイズオーバーブッキング」の方法として、この方法を参照してください。 AND / OR（II）のアカウントに実際にリンクでサポートされているものよりも大きい（オーバーブッキング）または（underbooking）小さい最大予約可能帯域幅/のBCと使用値を設定する際のオーバーブッキング/ 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の環境で十分なものとは追加の設定可能なパラメータを必要としないことが予想されます。他のオーバーブッキングの方法は、そのような追加の設定可能なパラメータを伴うが、このドキュメントの範囲を超えています。
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]で定義されたプリエンプション属性は、全体のすべてのCTをDSTEで保持し、適用中、及びれます。セットアップの優先順位と保持優先度のプリエンプション属性は、既存のセマンティクスを保持し、特にこれらのセマンティクスは、LSP CTの影響を受けません。これは、LSP1がリソースをLSP2と競合場合LSP1にかかわらずLSP1 CTおよびLSP2 CTの、LSP2保持先取り優先順位よりも高く設定先取り優先順位（すなわち、より低いプライオリティ値）を有する場合、LSP1はLSP2を先取りすることができることを意味します。
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のLSRは、TEクラスのマッピングのコンフィグレーションとなるクラス型およびプリエンプトレベル許容しなければなりません8 TE-クラス（まで）のそれぞれのために構成されています。
This mapping is referred to as :
このマッピングは、と呼ばれています。
TE-Class[i] <--> < CTc , preemption p >
TE-Classの[I] < - > <CTC、プリエンプションのp>
where 0 <= i <= 7, 0 <= c <= 7, 0 <= p <= 7
ここで、0 <= I <= 7,0 <= C <= 7、0 <= p <= 7
Two TE-Classes MUST NOT be identical (i.e., have both the same Class-Type and the same preemption priority).
二つのTE-クラスが同じであるはずがありません（すなわち、同じクラス型と同じ先取り優先順位の両方を有します）。
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.
8クラスタイプのいずれかがTE-クラスを形成するために、8つの先取り優先順位のいずれかと対にすることができる方法には他の制限はありません。具体的には、1つの所与の先取り優先順位は、2つ（またはそれ以上）TE-クラスを形成するために、2つ（またはそれ以上）の異なるクラスタイプと対にすることができます。同様に、一つのクラスタイプは、2つ（またはそれ以上）TE-クラスを形成するために、2つ（またはそれ以上）の異なる先取優先度と対にすることができます。また、TE-Classのインデックス（すなわち、「I」上）とTEの（上記すなわち、「P」）、クラス型（上記すなわち、「C」）または先取り優先順位の間には必須の順序関係はありません-クラス。
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は、残りのものは「未使用」として設定することを許可する必要があります。以下のセクション4.3.3、CTに記載ので、「未使用」効果なしTE / DS-TE LSPを確立することができないので、TE / DS-TEを無効になるように、すべての8 TE-クラスを構成する（さえも、設定されていることに注意してくださいそしてLSPのために構成さプリエンプション優先度が設定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ドメインのすべてのLSRにまったく同じTE-Classのマッピングを設定する必要があります。
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のドメインに変更する必要がある場合には、注意が他の人がまだ設定されている間、いくつかのDS-TEのLSRが新しいTE-クラスのマッピングを構成することができる間、再構成の過渡期間中に行使されるべきです古いTE-クラスのマッピングを持ちます。アクティブなトンネルは、このような過渡的再構成期間中に変更されているTE-クラスのいずれかを使用しないことをお勧めします。
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では、LSRには、すべてのLSP、LSPによって運ば交通トランクのクラスの型を示し、追加の設定可能なパラメータのために、サポートしなければなりません。
There is one and only one Class-Type configured per LSP.
LSPごとに設定、唯一のクラスタイプがあります。
The configured Class-Type indicates, in accordance with the supported Bandwidth Constraints Model, the BCs that MUST be enforced for that LSP.
設定されたクラス型は、サポートされている帯域幅制約モデル、そのLSPのために実施されなければならないのBCに応じて、示します。
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のLSRは、すべてのDS-TE LSPセットアップおよび保持優先順位、0と7の間の値を持つそれぞれで設定することを可能にしなければなりません。
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.
DS-TEを用いて、そのLSPのために設定された所定のLSPおよびクラス型のセットアップ優先順位のために構成さ先取り優先順位は、一緒になって、それらが（まで）のいずれかを形成するようなものでなければならないTEに構成8 TE-クラス上記セクション4.2.1で指定されたマッピング級。
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のために設定された所定のLSPおよびクラス型の保持優先度のために構成さ先取り優先順位も一緒に、彼らは（まで）のいずれかを形成するようなものでなければならない指定されたTE-クラスマッピングに構成8 TE-クラス上記セクション4.2.1インチ
The LSR MUST enforce these two rules at configuration time.
LSRは、構成時にこれらの2つのルールを施行しなければなりません。
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.
説明のために、我々は今、これらの設定可能なパラメータを使用することができる方法のいくつかの例を提示します。すべてのこれらの例を使用する必要が二つ以上のクラスタイプとなるように異なるのBCは、（例えば、音声用とデータ用）交通トランクスの異なるセットのために施行する必要があることを前提としています。
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:
2回のCT（データの音声およびCT0のためCT1）を使用して、最初のネットワークのネットワーク管理者は、音声のLSPがあるため、データLSPの彼らの最短経路から追い出されることはありませんことを保証するために、次のTE-クラスのマッピングを設定することを選択することがあります。
TE-Class[0] <--> < CT1 , preemption 0 >
TE-Class[1] <--> < CT0 , preemption 1 >
TE-Class[i] <--> unused, for 2 <= i <= 7
Voice LSPs would then be configured with: CT = CT1, setup priority = 0, holding priority = 0
音声LSPは、その後で構成されます：CT = CT1、セットアップ優先= 0、保持優先= 0
Data LSPs would then be configured with: CT = CT0, setup priority = 1, holding priority = 1
優先順位= 1を保持し、CT = CT0、セットアップ優先順位= 1：データLSPは、その後で構成されます
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.
新しい音声LSPは、彼らがリソースを争う場合には、既存のデータLSPを先取りすることができるだろう。データLSPは、音声LSPを先取りすることはありません。音声LSPは別の声LSPを先取りすることはありません。データLSPは別のデータLSPを先取りすることはありません。
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:
別のネットワークのネットワーク管理者は、その最短経路に近い大LSPの配置を好むことにより、グローバルなネットワークリソースの使用率を最適化するために、以下の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
Large-size Voice LSPs could be configured with: CT = CT1, setup priority = 0, holding priority = 0
音声のLSPを用いて構成することができ、大サイズ：CT = CT1、セットアップ優先= 0、= 0の優先度を保持します
Large-size Data LSPs could be configured with: CT = CT0, setup priority = 1, holding priority = 1
大型データLSPは、で構成することができますCT = CT0、セットアップ優先順位= 1、= 1の優先度を保持します
Small-size Voice LSPs could be configured with: CT = CT1, setup priority = 2, holding priority = 2
小型の声LSPはして構成することができますCT = CT1、セットアップ優先順位= 2、保持優先= 2
Small-size Data LSPs could be configured with: CT = CT0, setup priority = 3, holding priority = 3
小さなサイズのデータLSPはで構成することができますCT = 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.
新しい大型声LSPは、彼らがリソースを争う場合には、小型の声LSPまたは任意のデータLSPを先取りすることができるだろう。新しい大型データLSPは、小さなサイズのデータLSPまたは彼らがリソースを争う場合は小型の声LSPを先取りすることができるだろうが、大型の声LSPを先取りすることができません。
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:
別のネットワークのネットワーク管理者は、音声のLSPがあるため、データLSPの彼らの最短経路から追い出されることはありませんことを保証するために、以下のTE-クラスのマッピングを設定することを選択することができます。また、これは彼らの最短経路に近い大LSPの配置を好むことにより、グローバルなネットワークリソース活用のいくつかの最適化を実現します。
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
Large-size Voice LSPs could be configured with: CT = CT1, setup priority = 0, holding priority = 0.
CT = CT1、セットアップ優先= 0、保持優先= 0：大型声LSPは、で構成することができます。
Small-size Voice LSPs could be configured with: CT = CT1, setup priority = 1, holding priority = 1.
CT = CT1、セットアップ優先順位= 1、保持優先順位= 1：小サイズの音声LSPは、で構成することができます。
Large-size Data LSPs could be configured with: CT = CT0, setup priority = 2, holding priority = 2.
優先順位= 2を保持し、CT = CT0、セットアップ優先= 2：大規模データのLSPを用いて構成することができます。
Small-size Data LSPs could be configured with: CT=CT0, setup priority = 3, holding priority = 3.
優先順位= 3を保持し、CT = CT0、セットアップ優先= 3：小型サイズのデータLSPはで構成することができます。
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.
彼らがリソースを争う場合の音声LSPはデータLSPを先取りできます。データLSPは、音声LSPを先取りすることはありません。彼らがリソースを争う場合には大型の声LSPは、小型の声LSPを先取りできます。彼らがリソースを争う場合には大型のデータLSPは、小サイズのデータLSPを先取りできます。
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
Voice LSPs would then be configured with: CT = CT1, setup priority =0, holding priority = 0
音声LSPは、その後で構成されます：CT = CT1、セットアップ優先= 0、保持優先= 0
Data LSPs would then be configured with: CT = CT0, setup priority = 0, holding priority = 0
優先順位= 0を保持し、CT = CT0、セットアップ優先= 0：データLSPは、その後で構成されます
No LSP would then be able to preempt any other LSP.
何LSPは、その後、他のLSPを先取りすることはできないだろう。
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
Large-size Voice LSPs could be configured with: CT = CT1, setup priority = 0, holding priority = 0.
CT = CT1、セットアップ優先= 0、保持優先= 0：大型声LSPは、で構成することができます。
Small-size Voice LSPs could be configured with: CT = CT1, setup priority = 1, holding priority = 0.
CT = CT1、セットアップ優先順位= 1、保持優先= 0：小サイズの音声LSPは、で構成することができます。
Large-size Data LSPs could be configured with: CT = CT0, setup priority = 2, holding priority = 1.
優先順位= 1を保持し、CT = CT0、設定優先度= 2：大型データのLSPを用いて構成することができます。
Small-size Data LSPs could be configured with: CT = CT0, setup priority = 2, holding priority = 2.
優先順位= 2を保持し、CT = CT0、セットアップ優先= 2：小型データLSPはで構成することができます。
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.
新しい大型声LSPは、彼らがリソースを争う場合には、データLSPを先取りすることができるだろうが、小さなサイズの声LSPを任意の音声LSPを先取りすることができません。
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.
新しい小型の声LSPは、彼らがリソースを争う場合には、小さなサイズのデータLSPを先取りすることができるだろうが、大きなサイズのデータLSPまたは任意の音声LSPを先取りすることができません。
A Data LSP would not be able to preempt any other LSP.
データLSPは、他のLSPを先取りすることができません。
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]と[ISIS-TE]ごとに（集約）MPLSトラフィックエンジニアリングのためにサポートIGP広告との違いについて説明します。 IGP広告の残りの部分は変更されません。
As detailed above in Section 4.1.1, up to 8 BCs (BCb, 0 <= b <= 7) are configurable on any given link.
8つのBCまで、セクション4.1.1に上記で詳述したように（BCB、0 <= B <= 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、既存の「最大予約可能帯域幅」サブTLV（[OSPF-TE]、[ISIS-TE]）は一般的なセマンティクスで保持されるとタイプ;すなわち、SUM（予約（CTC））<=最大予約可能帯域幅、独立して、帯域幅制約モデル。
This document also defines the following new optional sub-TLV to advertise the eight potential BCs (BC0 to BC7):
また、このドキュメントでは、8つの可能性のBC（BC7にBC0）を宣伝するために、次の新しいオプションのサブTLVを定義しています。
"Bandwidth Constraints" sub-TLV:
「帯域幅の制約」サブTLV：
- Bandwidth Constraints Model Id (1 octet)
- Reserved (3 octets)
- Bandwidth Constraints (N x 4 octets)
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.
- 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によって使用されている現在の帯域幅の制約モデルの1オクテットの識別子。この名前空間の値の割り当てのためのIANAの考慮事項のセクションを参照してください。
- 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によって無視されるべきです。
- 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、... BC（N-1）が含まれています。各BCは、IEEE浮動小数点フォーマットで32ビットに符号化されます。単位はバイト（ビットではない！）毎秒です。使用中に構成されたTE-クラスマッピング及び帯域幅制約モデルは、BCH + 1、BCH + 2、...及びBC7が設定TEクラスに関連付けられたクラス・タイプのいずれかに関連していない、それがあるようなものである場合BC0からBCHにのみ帯域幅の制約が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]と[ISIS-TE]で定義されたすべての関連する一般的な（TLVフォーマット、パディングおよびアラインメントなど、ならびにIEEE浮動小数点形式のエンコード）TLVエンコーディング規則は、この新しいサブ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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A DS-TE LSR MAY optionally advertise BCs.
DS-TE LSRは、オプションのBCを広告するかもしれません。
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.
BCを宣伝しDS-TE LSRは、これを行うために、新しい「帯域幅の制約」サブTLV（既存の予約可能な最大帯域幅サブTLVに加えて）を使用する必要があります。例えば、サービスプロバイダは、帯域幅制約モデルのみBC0およびBC1がCT0とCT1、DS-TEのLSRに関連しているようなものであるCT0とCT1のみ、および関連付けられたTE-クラスとDS-TEを展開する場合にIGP広告の最大予約可能帯域幅サブTLVに含めるだけでなく、「帯域幅の制約」のサブTLVしまうのBCを宣伝しています。前者はすべてのCTにわたる総帯域幅の制約が含まれている必要があり、後者は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
使用帯域幅の制約モデル間の矛盾を報告し、それが現在のオペレータ/管理システムへの警告を生成する必要があります使用する帯域幅の制約モデルと一致していない帯域幅の制約モデルIDで「帯域幅の制約」のサブTLVを受けDS-TE LSR異なるリンク上。また、その場合には、DS-TE LSRは、帯域幅の制約をサポートしていない場合
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.
モデルは、帯域幅の制約モデルIdで指定された、またはDS-TE LSRは、同時に複数の帯域幅の制約モデルと操作をサポートしていない場合、DS-TE LSRは、対応するTLVを捨てるかもしれ。 DS-TE LSRは、帯域幅の制約モデルIdで指定された帯域幅の制約モデルをサポートし、及びDS-TE LSRは、同時に複数の帯域幅の制約モデルとサポート業務を行う場合には、DS-TE LSRは、対応するTLVを受け入れ、操作を許可する可能性がある場合DS-TEドメインのさまざまな部分で使用される異なる帯域幅の制約モデルと。
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は、それが一般的なセマンティクスで使用されることを除いて、ヘッドエンド上の制約ベースのルーティングに必要な動的帯域幅情報をアドバタイズするだけ車両として保持されます。未予約帯域幅サブ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:
より正確には、次のように一般化された定義に予約されていない帯域幅サブTLVをサポートしなければならないDS-TEのLSR：
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:
未予約帯域幅サブTLVは、TE-クラスインデックスの昇順に配列されたIEEE浮動小数点形式で、まだ8 TE-クラスの各々に対する予約帯域幅の量を指定します。 TE-クラスの予約されていない帯域幅が[0]のサブTLVの終わりに[7]のTE-クラスのサブTLVの開始、及び非予約帯域幅で発生します。 TE-クラスの未予約帯域値[I]（0 <= I <= 7）、 "未予約TEクラス[I]" と呼ばれます。そのLSPに、予約のために、利用できる帯域幅を示しています。
- transports a Traffic Trunk from the Class-Type of TE-Class[i], and
- [I] - クラスのクラス型のトラフィックトランクを輸送、及び
- has a setup priority corresponding to the preemption priority of TE-Class[i].
- [I] TEクラスの先取り優先順位に対応する設定の優先順位を有しています。
The units are bytes per second.
単位は秒あたりのバイト数です。
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-クラスインデックスによって順序付けされ、従って、異なるのBCと異なるのCTに関連することができ、任意の先取優先度に、DS-TE LSRはこれらの帯域幅の値のうちいずれかの注文の関係を仮定してはいけませんので。
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:
すべての先取優先順位が同じ（とのみ）のBCと帯域幅の値を反映するため、先取り優先順位で宣伝されている既存のTEでは、以下の関係が常に真である、と多くの場合、TEの実装が想定されます。
If i < j, then "Unreserved Bw [i]" >= "Unreserved Bw [j]"
私は場合は、<jは、その後、 "アンリザーブBWは[i]は"> = "非予約ベストウエスタン[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]".
私は場合は、<jは、次の関係のいずれかが真であり、 "非予約TEクラス[i]を" = "非予約TEクラス[j]は" OR "非予約TEクラス[i]を">「非予約TE-クラス[j]は」OR "非予約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広告を生成するLSRによってゼロに設定しなければなりません、そしてIGP広告を受信LSRによって無視されなければならないでIGPによってアドバタイズ値。
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トラフィックエンジニアリングのサポートのため-TEをRSVPへの拡張を記述します。これらの拡張は、MPLS上のDiffservのサポートのために[DIFF-MPLS]で定義されたRSVPに（集約）MPLSトラフィックエンジニアリングをサポートするための[RSVP-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.
ClassTypeオブジェクト：一つの新しいRSVPオブジェクトは、この文書で定義されています。このオブジェクトの詳細な説明は以下に提供されます。この新しいオブジェクトは、Pathメッセージに適用されます。この仕様は、このようにして、[RSVP-TE]とLSP_TUNNEL_IPv4に等しいCTとのセッションオブジェクトを含むとLABEL_REQUESTオブジェクトを含むに従ってLSPトンネルを確立するために使用される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.
RSVP-TEを介してLSPトンネルの確立をサポートするための[RSVP-TE]で定義された制約はまたDS-TEをサポートするLSPトンネルの確立に適用可能です。例えば、唯一のユニキャストのLSPがサポートされ、およびマルチキャストのLSPは、今後の検討課題です。
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オブジェクトは、MPLS LSP設定に関係ない一般的なRSVPの実装は、このオブジェクトをサポートする必要がないようにRSVPに関しては省略可能です。
An LSR supporting DS-TE MUST support the CLASSTYPE object.
LSRサポートDS-TEは、ClassTypeのオブジェクトをサポートしなければなりません。
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> ]
<sender descriptor> ::= <SENDER_TEMPLATE> [ <SENDER_TSPEC> ]
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
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オブジェクトクラス名のClassTypeです。そのクラス番号はするClassTypeオブジェクトフォーマットは以下に示されるCタイプ1である唯一の定義C-Typeがあり、現在は66です。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved: 29 bits This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt.
予約：このフィールドは予約されている29ビット。これは、送信時にゼロに設定しなければならなくて、領収書の上で無視しなければなりません。
CT: 3 bits Indicates the Class-Type. Values currently allowed are 1, 2, ... , 7. Value of 0 is Reserved.
CT：3ビットクラスの型を示します。現在、許可される値は1、2、...、0の7値が予約されています。
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のセッション・タイプとを有するPathメッセージを作成し
LABEL_REQUEST object as per [RSVP-TE]. The sender LSR may also include the DIFFSERV object as per [DIFF-MPLS].
[RSVP-TE]の通りLABEL_REQUESTオブジェクト。送信者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は、クラスタイプ0に関連付けられている場合、送信者のLSRはPathメッセージ内のClassTypeオブジェクトを含めることはできません。セクション10および付録Cに後述するように、これは、非DSTE構成または非DSTE対応のLSRとの下位互換性を可能にします
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は、クラスタイプNに関連付けられている場合（1 <= N <= 7）、送信元LSRはNに設定され、クラスタイプ（CT）フィールドを有するPathメッセージにするClassTypeオブジェクトを含まなければなりません
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は、LSPにクラスタイプ0を関連付ける必要があります。
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は（PathメッセージがするClassTypeオブジェクトを含んでいたか否か）をResvメッセージにする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.
クラスタイプNに対応するLSPの確立中に、LSRは、その特定のクラスタイプのための利用可能な帯域幅にわたってアドミッション制御を実行する必要があります。
An LSR that recognizes the CLASSTYPE object and that receives a Path message that:
：のClassTypeオブジェクトを認識し、それはPathメッセージ受信LSR
- 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で定義されています。
An LSR receiving a Path message with the CLASSTYPE object that:
LSRがあることのClassTypeオブジェクトにPathメッセージを受信：
- recognizes the CLASSTYPE object, but
- のClassTypeオブジェクトを認識しますが、
- does not support the particular Class-Type,
- 特定のクラス型をサポートしていません、
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:
LSRがあることのClassTypeオブジェクトにPathメッセージを受信：
- recognizes the CLASSTYPE object, but
- のClassTypeオブジェクトを認識しますが、
- determines that the Class-Type value is not valid (i.e., Class-Type value 0),
- クラス型の値が有効でないと判断し（すなわち、クラス型の値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エラー」と「無効なクラス-Type値」のエラー値を送信者に向けてのPathErrを送らなければなりません。これらのコードは、セクション6.5で定義されています。
An LSR receiving a Path message with the CLASSTYPE object, which:
LSRはするClassTypeオブジェクトとPathメッセージを受信します。
- recognizes the CLASSTYPE object and
- のClassTypeオブジェクトを認識し、
- supports the particular Class-Type, but
- 特定のクラス型をサポートしていますが、
- 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）このクラス型によって形成され、および（ii）同じパスメッセージでシグナリング設定の優先順位は、TEクラスのマッピングで構成された8 TE-クラスのものではないと判断します
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.
「構成されたTE-クラスを形成しないCTおよびセットアップ優先順位」エラーコード「のDiffservを意識したTEエラー」とのエラー値を送信者に向けてのPathErrを送らなければなりません。これらのコードは、セクション6.5で定義されています。
An LSR receiving a Path message with the CLASSTYPE object that:
LSRがあることのClassTypeオブジェクトにPathメッセージを受信：
- recognizes the CLASSTYPE object and
- のClassTypeオブジェクトを認識し、
- supports the particular Class-Type, but
- 特定のクラス型をサポートしていますが、
- 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）このクラスの型と同一のPathメッセージでシグナリング（ii）の保持優先的に形成されたと判断し、TEクラスのマッピングで構成された8 TE-クラスの一つではありません
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エラー」とのエラー値「CTおよび構成されたTE-クラスを形成しない優先順位を保持している」と、送信者に向けたPathErrを送らなければなりません。これらのコードは、セクション6.5で定義されています。
An LSR receiving a Path message with the CLASSTYPE object that:
LSRがあることのClassTypeオブジェクトにPathメッセージを受信：
- recognizes the CLASSTYPE object and
- のClassTypeオブジェクトを認識し、
- supports the particular Class-Type, but
- 特定のクラス型をサポートしていますが、
- 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
- タプルは、（i）このクラス型によって形成され、および（ii）同じパスメッセージでシグナリング設定の優先順位は、TEクラスのマッピングで構成された8 TE-クラスのものではないと判断し、
- 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
- 同一のPathメッセージでシグナリング（I）は、このクラス型及び（ii）保持優先的に形成されたタプルは、TEクラスのマッピングで構成された8 TE-クラスのものではないと判断します
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.
「構成されたTE-クラスを形成しないTE-クラスとCTを構成し、保持優先順位を形成しないCTとセットアップ優先」のエラーコード「のDiffservを意識したTEエラー」とのエラー値を持つ送信者に向けたPathErrを送らなければなりません。これらのコードは、セクション6.5で定義されています。
An LSR receiving a Path message with the CLASSTYPE object and with the DIFFSERV object for an L-LSP that:
LSRがするClassTypeオブジェクトとし、L-LSPそのためのDiffServオブジェクトとPathメッセージを受信します。
- 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
- 、クラスタイプとパーホップの動作（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,
- 決定し、このローカル知識に基づいて、PHBスケジューリングクラス（PSC）はDIFFSERVオブジェクトにシグナリングすることを、するClassTypeオブジェクト内シグナリングクラスタイプと矛盾しています
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間とCTを合図矛盾」のエラー値を送信者に向けてのPathErrを送らなければなりません。これらのコードは6.5節で以下に定義されています。
An LSR receiving a Path message with the CLASSTYPE object and with the DIFFSERV object for an E-LSP that:
LSRがそのするClassTypeオブジェクトに及びE-LSPのためのDiffServオブジェクトとPathメッセージを受信します。
- recognizes the CLASSTYPE object,
- のClassTypeオブジェクトを認識し、
- has local knowledge of the relationship between Class-Types and PHBs (e.g., via configuration)
- （コンフィギュレーションを介して、例えば）クラスタイプとのPHBとの間の関係のローカル知識を有します
- 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,
- 、するClassTypeオブジェクト内シグナリングクラスタイプと矛盾しているのPHBはDIFFSERVオブジェクトのマップエントリにシグナリングされ、このローカル知識に基づいて、決定します
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エラー」と「のPHBを合図し、CTを合図間の矛盾」のエラー値を送信者に向けての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).
LSRは、[RSVP-TE]とに応じて、LSPが既にこのセクションで説明した以外の理由で受け入れできない状況を処理しなければならない[DIFF-MPLS（例えば、予約受付制御によって拒否され、そしてラベル）を関連付けることができません。
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).
クラスのNumは不明その形式0bbbbbbbはある（すなわち、それはエラーコードでのPathErrを送らなければなりませんクラスのNum「未知のオブジェクトクラスの[RSVP]で指定された手順に従って振る舞うしなければならないのClassTypeオブジェクトを認識しないLSR "）送信者に向けました。
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).
ClassTypeオブジェクトのクラスのNumを認識するが、それはするClassTypeオブジェクトC-タイプを認識しないLSRは、と（すなわち、それはのPathErrを送らなければなりません不明なC型用の[RSVP]で指定された手順に従って振る舞うなければなりません。送信者に向けて、エラーコード「未知のオブジェクトのC型」）。
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.
上記の両方の状況は、パス設定が失敗する原因。送信者は、LSPを確立することができないとのClassTypeオブジェクトなしで予約の確立を再試行する行動を取る可能性があるオペレータ/管理システムに通知する必要があります。
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です。
The following table defines error values for the Diffserv-aware TE Error:
次の表は、Diffservの認識TEエラーのエラー値を定義します。
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つの予期するClassTypeオブジェクト2サポートされていないクラスタイプ3無効なクラスタイプ値4構成TEクラス6クラス型を形成しない構成TEクラス5クラス型及び保持優先順位を形成しないクラスタイプおよび設定の優先順位とセットアッププライオリティが設定TEクラスとクラスタイプを形成し、優先順位を保持していないシグナリングPSC間の構成TEクラス7矛盾を形成し、シグナリングのPHBの間のクラスタイプ8矛盾をシグナリングおよびクラス型を合図していません
See the IANA Considerations section for allocation of additional values.
付加価値の配分のためのIANAの考慮事項のセクションを参照してください。
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] [ISIS-TE]のためのIGPサポートをシグナリングするための初期の基本仕様の拡張の数があります。それらは、LSPの階層として一般化（[GMPLS-SIG]および[GMPLS-ROUTE]）のため、ならびに追加の機能のための機能強化、[HIERARCHY]、[バンドル]バンドルリンク、および高速復元[REROUTE]を含みます。これらの仕様は異なる先取優先順位でLSPを治療するための方法を、特定の先取優先事項に関連する情報をエンコードする方法を参照したり、彼らはそれ以外の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増強、の両方をサポートするように実装するためのためには、「先取り優先」への参照を扱い、「最大予約可能帯域幅」にしなければなりません一般的に、すなわち、この仕様は、それらの用語を使用する方法。
Additionally, current and future MPLS enhancements may include more precise specification for how they interact with Diffserv-aware TE.
また、現在および将来のMPLSの機能強化は、彼らがDiffservの認識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.
ルータは、diffserv対応TE及びそのようなシグナリングまたはMPLSの拡張のために定義されたIGPにおける先取り優先順位に関連付けられた情報の符号化に、上記のもの、先取り優先順位の値の符号化としてMPLSプロトコル拡張の両方をサポートする場合、考慮されなければなりません対応TE-クラスの同じ情報の符号化。 MPLS増強は先取り優先順位Nで情報をルーティングするためのパラメータのIGPで広告を指定した場合、例えば、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.
比較的異なる先取り優先順位のLSPを扱う方法についての議論があった場合には、DS-TE LSRは、問題のLSPの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プロトコル拡張の両方をサポートしている場合、最大予約可能帯域幅の広告は、すべてのクラス・タイプにわたって総帯域幅の制約として4.1.1項で定義されている一般的な解釈を行わなければなりません。また、すべてのBCのオプションの広告を可能にすることができます。
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.
私たちは、パスがそのクラス型CTCに設定されており、そのセットアップ先取り優先順位のpに設定されているLSPのために計算する必要がありますケースを考えてみましょう。
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].
そして、CTCのペアとpはTE-クラスマッピングに定義されたTE-クラスの1つにマップされます。私たちは、TE-クラスとして、この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.
DS-TE LSRの制約ベースのルーティングアルゴリズムは、まだのみすべてのリンクのためのIGPによってアドバタイズとして「[i]は非予約TE-クラス」に適合することで、単一BCを満たす経路計算を行う必要があります。したがって、既存のTE制約に基づくルーティングアルゴリズム自体を変更する必要はありません。
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
使用時に制約ベースのルーティングアルゴリズムはまた、BCのと最大予約可能帯域幅として、考慮にIGPで広告オプションの追加情報がかかる場合があります。たとえば、
BCs MIGHT be used as tie-breaker criteria in situations where multiple paths, otherwise equally attractive, are possible.
BCSが、複数のパス状況でタイブレーカの基準として使用されるそれ以外の場合も同様に魅力、可能であるかもしれません。
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.
クラス・タイプは、必要に応じて動的にDiffservのスケジューラによってクラスタイプに割り当てられたリソースを調整するためにDS-TEのLSRによって使用されるかもしれLSPの確立に合図しました。また、シグナリングプロトコルTE-LSPによって信号Diffservの情報（すなわち、PSC）を[DIFF-MPLS]で指定されるように、使用される場合、必要に応じて動的のDiffservによって割り当てられたリソースを調整するためにDS-TEのLSRによって使用されるかもしれませんCT内のPSC / OAへのスケジューラ。
We observe that existing TE can be viewed as a particular case of DS-TE where:
私たちは、既存のTEがどこDS-TEの特定のケースと見なすことができることを守ってください。
(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）単一のクラスタイプが使用され、（ii）の全8つの先取り優先順位は、そのクラスタイプのために許可されている、および（iii）次のTEクラスのマッピングが使用される：TEクラス[I] < - > < CT0、プリエンプションI> 0 <= I <= 7。
In that case, DS-TE behaves as existing TE.
その場合には、DS-TEは、既存のTEとして動作します。
As with existing TE, the IGP advertises: - Unreserved Bandwidth for each of the 8 preemption priorities.
既存のTEと同様に、IGPは、アドバタイズ： - 8つの先取り優先度のそれぞれについて未予約帯域幅。
As with existing TE, the IGP may advertise: - Maximum Reservable Bandwidth containing a BC applying across all LSPs .
既存のTEと同じように、IGPは宣伝可能性があります - 最大予約可能帯域幅は、すべてのLSP間で適用BCを含みます。
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.
CT0からすべてのLSP輸送トラフィックので、RSVP-TEシグナリングは、既存のTEと同様に（セクション6で説明したようにのみ、CT0以外のクラスタイプに使用される）は、クラス型の明示的なシグナリングなしに行われます。
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 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.
私たちは最初、TEを既存ため、TE LSPのためのアドミッション制御アルゴリズムの詳細を説明しているを観察し、その結果として予約されていない帯域幅を計算するための式の詳細については、現在IETF仕事の範囲外です。これは、ベンダーの差別化のために残されています。 TEスキームが他のLSRに非予約ベストウエスタンの面で世界の彼らのローカルビューを宣伝するためのLSRに依存しているので、これは様々な実装間の相互運用性を損なわないことに注意してください。このようにかかわらず、1つの所与のLSRに使用される実際のローカルアドミッション制御アルゴリズムの、他のLSRに制約ベースのルーティングは、追加のLSPが所与のLSRによって承認または拒否されるかどうかを決定するためにアドバタイズ情報に頼ることができます。唯一の要件は、LSRは、その特定のローカルアドミッション制御アルゴリズムと一致している未予約帯域値をアドバタイズし、アカウントに確立されたLSPの保持先取り優先順位を取ることです。
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].
DS-TEの文脈において、再度、アドミッション制御アルゴリズムの詳細については、ベンダの分化のために残されており、TEクラスのために予約されていない帯域幅を計算するための式[I]本明細書の範囲外です。しかし、DS-TEは、帯域幅の制約モデルに従って、[i]が公示予約されていない帯域幅の値は、TE-クラスに関連付けられているCTに関連するすべてのBCを反映しなければならないことをLSR上の追加の要件を課します。このように、コンピューティングのための式「非予約TEクラス[i]には、」使用中の帯域幅の制約モデルに依存してのBCは、CTのにどのように適用されるかを反映しなければなりません。 「未予約TEクラス[i]が」モデル計算するための例示的な式は、ロシア人形モデルと最大割り当てモデルそれぞれ[DSTE-RDM]および[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].
既存のTEと同じように、DS-TEのLSR [i]はTE-Classのために予約されていない帯域幅を計算する目的のために（そのセットアップ先取り優先順位ではなく）設立LSPの保持先取り優先順位を考慮しなければなりません。
A DS-TE LSR MUST support the following admission control rule:
DS-TE LSRは、次のアドミッション制御ルールをサポートしなければなりません：
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,:
かかわらず、アドミッション制御アルゴリズムは、実際にTE-Classのため予約されていない帯域幅を計算する方法の[i]はそのローカルリンクのいずれか、帯域幅BのLSPのために、セットアップ先取り優先度pのとクラス型CTCの、あればそのリンク上許容されますそして場合のみ,:
B <= Unreserved Bandwidth for TE-Class[i]
B <= TE-クラスの未予約帯域[I]
where TE-Class [i] maps to < CTc , p > in the TE-Class mapping configured on the LSR.
TEクラス[i]はLSRに構成TEクラスマッピングに<CTC、P>にマップあります。
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
この文書は、（[DIFF-ARCH]）およびMPLSトラフィックエンジニアリング（[TE-REQ]、[RSVP-TE]、[OSPF-TE]、[ISIS-TE]）Diffservのために記載されているもの以外の追加のセキュリティ上の脅威を導入しないと同じ
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.
これらの文献に記載されたセキュリティ対策と手順が適用されます。例えば、Diffservのドメイン内のセキュリティとネットワークインフラストラクチャの完全性と共にDSの境界ノードにおけるトラフィック調整の組み合わせからなる[DIFF-ARCH]で議論theft-とサービス拒否攻撃に対する防御のためのアプローチDS-TEを使用している場合には、続いてもよいです。 [TE-REQ]で述べたように、また、（例えば、DS-TEのLSPに関連するものとして）管理設定可能なパラメータの操作が許可エンティティによって安全な方法で実行することが、具体的には重要です。
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.
この文書は、IANAによって管理される2つの新しい名前空間を作成します。また、既存の名前空間からの割り当て数は、本文書にIANAによって行われています。彼らは、以下で議論されています。
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:
この文書では、OSPFやISISの両方に、「帯域幅の制約」のサブTLV内のセクション5.1「帯域幅の制約モデルID」フィールド（名前空間）で定義されています。新しい名前空間はIANAによって作成されていて、彼らはこの新しい名前空間を維持します。この名前空間のためのフィールドは1つのオクテットであり、次のようにこのフィールドの割り当てのIANAガイドラインは以下のとおりです。
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].
[IANA-CONS]で定義されるように、O範囲240から255の値が「私用」のために予約されています。
13.2. A New Name Space for Error Values under the "Diffserv-aware TE Error"
13.2. 「Diffservの認識TEエラー」の下のエラー値の新しい名前空間
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.
エラーコードは、広く、エラー状態を定義するERROR_SPECオブジェクトに表示される[RSVP]で定義された8ビットの量です。各エラーコードを使用して、さらに、エラーの原因を指定する16ビットのエラー（エラーコードによって異なります）の値があるかもしれません。
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.
この文書は、セクション6.5で新しいRSVPエラーコード、「Diffservの認識TEのエラー」（項13.3.4を参照）を定義します。 「Diffservの認識TEエラー」のエラー値は、IANAが管理する新しい名前空間を構成しています。
This document defines, in Section 6.5, values 1 through 7 in that name space (see Section 13.3.5).
このドキュメントは、セクション6.5で定義され、その名前空間内の1〜7の値（セクション13.3.5を参照）。
Future allocations of values in this name space are to be assigned by IANA using the "Specification Required" policy defined in [IANA-CONS].
この名前空間の値の将来の割り当ては、[IANA-CONS]で定義された「仕様が必要である」というポリシーを使用して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.
[OSPF-TE]はトラフィックエンジニアリングリンクステートアドバタイズメント（LSA）とIANAによってこの名前空間の管理のためのルールの「リンクTLV」内のサブ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.
この文書は、セクション5.1で新しいサブTLV、「帯域幅の制約」OSPF「リンク」TLVのためのサブTLVを定義します。 32767に[OSPF-TE]、範囲10内のサブTLVのタイプに設けられたIANAの考慮事項に応じて要求された、値17が「帯域幅制約」サブTLVのための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.
[ISIS-TE]はISIS内のサブTLVのタイプの名前空間を作成TLVと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.
このドキュメントは、ISISは「拡張到達可能性IS」のために、セクション5.1で新しいサブTLV、「帯域幅の制約」サブTLVを定義するTLV。 [ISIS-TE]に設けられたIANAの考慮事項に応じて、サブTLVのタイプを要求し、そして値22が「帯域幅制約」サブTLVのためのIANAによって割り当てられています。
[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]はIANAによって管理されているRSVPオブジェクトのためのクラス数の名前空間を定義します。現在割り当てられたクラス番号が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).
この文書は、セクション6.2.1で新しいRSVPオブジェクト、ClassTypeのオブジェクトを定義します。 IANAは、理解されていない場合、全体のRSVPメッセージは、「未知のオブジェクトクラス」のエラーコードで拒否させるオブジェクトの[RSVP]のセクション3.10で定義された範囲から、このRSVPオブジェクトのクラス番号を割り当てました。そのようなオブジェクトは、クラスの数（すなわち、クラスのNum = 0bbbbbbbは）の最上位ビットにゼロによって識別されます。
IANA assigned Class-Number 66 to the CLASSTYPE object. C_Type 1 is defined in this document for the CLASSTYPE object.
IANAはのClassTypeオブジェクトにクラス番号66を割り当てました。 C_Type 1は、ClassTypeのオブジェクトについては、このドキュメントで定義されています。
[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]はエラーコードネームスペースとIANAによってこの名前空間の管理のためのルールを定義します。現在割り当てられているエラーコードを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".
この文書では、6.5節新しいRSVPエラーコード、「Diffservの認識TEエラー」で定義します。 [RSVP]で提供IANAの考慮事項に従い、エラーコード28が「Diffservの認識TEエラー」にIANAによって割り当てられました。
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.
エラーコードは、広く、エラー状態を定義するERROR_SPECオブジェクトに表示される[RSVP]で定義された8ビットの量です。各エラーコードを使用して、さらに、エラーの原因を指定する16ビットのエラー（エラーコードによって異なります）の値があるかもしれません。
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.
この文書は、セクション6.5で新しいRSVPエラーコード、「Diffservの認識TEのエラー」（項13.3.4を参照）を定義します。 「Diffservの認識TEエラー」のエラー値は、IANAが管理する新しい名前空間を構成しています。
This document defines, in Section 6.5, the following Error Values for the "Diffserv-aware TE Error":
この文書では、6.5項で、「Diffservの認識TEエラー」のために、次のエラー値を定義します。
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つの予期するClassTypeオブジェクト2サポートされていないクラスタイプ3無効なクラスタイプ値4構成TEクラス6クラス型を形成しない構成TEクラス5クラス型及び保持優先順位を形成しないクラスタイプおよび設定の優先順位とセットアッププライオリティが設定TEクラスとクラスタイプを形成し、優先順位を保持していないシグナリングPSC間の構成TEクラス7矛盾を形成し、シグナリングのPHBの間のクラスタイプ8矛盾をシグナリングおよびクラス型を合図していません
See Section 13.2 for allocation of other values in that name space.
その名前空間内の他の値の割り当てについては、セクション13.2を参照してください。
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.
私たちは、この作品で彼らの以前の貢献のためにマーティンタサム、アンジェラ・チウ、そしてピートヒックスに感謝します。我々はまた、彼の徹底的な見直しと提案のためのサンジャヤチョードリーに感謝します。
Appendix A: Prediction for Multiple Path Computation
付録A：複数の経路計算のための予測
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.
ヘッドエンドは、短期間に複数のLSPのパスを計算するために必要な状況があります。更新されたIGP情報を受信する前に、LSP番目（N + 1）のパスを計算するときに予約されていない帯域幅にn番目のLSPの影響を予測しようとする際にヘッドエンドのための潜在的な利点があります。例えば、複数のLSPのより良好な負荷分散は、複数のパス間で実行されます。また、（N + 1）番目の場合LSPは、もはやフィットn番目のLSPの確立後リンク上、ヘッドエンドは、接続アドミッション制御（CAC）拒絶反応を回避しないことになるであろう。さらに悪い状況が生じ得る考えられるシナリオの数がありますが、このような予測を行うと、状況を改善する可能性が高いです。実際のところ、ネットワーク管理者の数は、既存のTEを展開する際に、このような予測を使用することを選択しています。
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.
このような予測が使用されない場合、任意BCサブTLVと任意最大予約可能帯域幅サブTLVは、未予約のBWサブTLVに含まれる情報は、すべてのことがあるているため、経路計算の目的のためにIGPにアドバタイズする必要はありません制約ベースのルーティングを実行するためにヘッドエンドで必要とされます。
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.
そのような予測は、ヘッドエンドで使用される場合、任意のBCサブTLVと任意最大予約可能帯域幅サブTLVは、IGPでアドバタイズされるかもしれません。これは、ヘッドエンドは、LSPは、後続のLSPのために予約されていない帯域幅の値にどのように影響するかをできるだけ正確に予測するためにあります。
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.
実際のアドミッション制御アルゴリズムは、ベンダーの分化のために残されていることを思い出して、我々は、ヘッドエンドLSR予測は、同じ（又は非常に近い）他のLSRによって使用されるようなアドミッション制御アルゴリズムに基づいている場合、予測にのみ効果的に行うことができることを確認します。
Appendix B: Solution Evaluation
付録B：ソリューションの評価
B.1. Satisfying Detailed Requirements
B.1。詳細な要件を満たします
This DS-TE Solution addresses all the scenarios presented in [DSTE-REQ].
このDSTEソリューション[DSTE - REQ]で提示されたすべてのシナリオに対応しています。
It also satisfies all the detailed requirements presented in [DSTE-REQ].
また、[DSTE - REQ]で提示されたすべての詳細な要件を満たしています。
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).
目的は、部分的にしかこのDSTEソリューションによって対処され、「オーバーブッキング」、[DSTE - REQ]の4.7節の最後の段落に着手しました。 「LSPサイズオーバーブッキング」と「リンク・サイズオーバーブッキング」メソッドのサポートを通じて、このDS-TEのソリューションは、効果的にCTSが異なるオーバーブッキング比を有することを可能にすると同時に異なるリンク上（総称して、すべてのCTを越えて）別々に微調整することがオーバーブッキングできます。しかし、一般的な意味で、それが相互に共有のBC（を介して相互にどのような影響を与えるか異なるのCTの正確な帯域幅の会計を維持しながら、すべてのCTの効果的なオーバーブッキング比率は、互いに独立のCTのネットワークのさまざまな部分で異なって微調整することはできません。そのような）最大予約可能帯域幅として。
B.2. Flexibility
B.2。柔軟性
This DS-TE solution supports 8 CTs. It is entirely flexible as to how Traffic Trunks are grouped together into a CT.
このDS-TEのソリューションは、8回のCTをサポートしています。これは、トラフィックトランクがCTにグループ化されている方法と全く柔軟です。
B.3. Extendibility
B.3。拡張性
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.
8回のCTの最大は、この文書の著者によって快適よりも考えられています。 8 TE-クラスの最大値は、この文書の著者によって十分であると考えられます。将来的に必要と認められる場合は、この解決策は、より多くのCT以上TE-クラスをサポートするように拡張することができ、これは、この文書で指定されたもの以外の追加IGPの拡張が必要となります。
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.
このソリューションの主な目的は、Diffservの対応のトラフィックエンジニアリングのサポートですが、そのメカニズムはしっかりDiffservのと結合されていません。これは、潜在的な将来の他のトラフィックエンジニアリングアプリケーションのサポートのため、ソリューションが適し、以上簡単に拡張できます。
B.4. Scalability
B.4。スケーラビリティ
This DS-TE solution is expected to have a very small scalability impact compared to that of existing TE.
このDS-TEのソリューションは、既存の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).
IGP観点から、アドバタイズすべき必須の情報の量は、既存のTEのものと同一です。一つの追加のサブTLVが指定されているが、その使用は任意であり、そしてそれだけで静的な情報（最大で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.
既存のTEと同じように、このソリューションは唯一の任意のLSPのために予約されていない、単一の帯域幅の値を考慮するように制約最短パスファースト（CSPF）が必要、ので、私たちはLSPの経路計算上の顕著な影響を期待していません。
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.
それが唯一の情報の一つの追加項目（クラス型）の処理を必要とし、大幅CAC拒絶反応の可能性を増加させないため、シグナリングの観点から、我々は原因をこの溶液に有意な影響を期待していません。 DS-TEはそれがより多くのLSPを通知する必要があるように、トラフィックの異なるクラスが異なるのLSPに分割されていることを前提としていることで、シグナリングLSP上のいくつかの固有影響を与えていることに注意してください。しかし、これはDS-TEのコンセプト自体にではなく、ここで議論し、実際のDS-TEソリューションによるものです。
B.5. Backward Compatibility/Migration
B.5。下位互換性/移行
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.
このソリューションは、既存のTEからのDS-TEへのスムーズな移行を可能にするために期待されています。既存のTEは、DS-TEの特定の構成としてサポートすることができるからです。これは、DS-TEの実装と、「アップグレード」LSRは直接のみ、既存のTEをサポートする「古い」LSRと相互作用できることを意味します。
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.
このソリューションは、実際に展開CTの数が増加した場合には、設定の変更が必要となるだけのように、スムーズな移行を可能にするために期待されています。しかし、これらの変更は、DS-TEドメイン間で協調して実行する必要があります。
Appendix C: Interoperability with Non-DS-TE Capable LSRs
付録C：非DS-TE対応のLSRとの相互運用性
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.
このDSTE溶液は、いくつかのLSRがDSTE可能であり、移行フェーズ中に発生し得るようにいくつかは、ないハイブリッドネットワークの動作を可能にします。この付録では、このようなハイブリッドネットワークの制約や操作について説明します。
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.
私たちは、DS-TEドメインとしてDS-TE対応のLSRのセットを参照してください。私たちは、TE-ドメインなどの非DS-TE-可能（ただし、TE-可能）のLSRのセットを参照してください。
Hybrid operations require that the TE-Class mapping in the DS-TE domain be configured so that:
ハイブリッド操作はDS-TEドメイン内のTE-クラスのマッピングがするように構成されていることが必要です。
- 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.
- これらのTE-クラスの各々に対するTEクラスのマッピングのインデックスは、先取り優先順位に等しいです。
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:
例えば、TEドメインはその後、プリエンプション2と3を使用して、DS-TEはTE-クラスのマッピングで、次のTE-クラスを含むことにより、同一ネットワーク内に展開することができます想像。
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.
これを見てする別の方法は、全体のTEクラスのマッピングはTEドメインと一致している必要はありませんが、CT0に適用このTE-クラスマッピングのサブセットが効果的にTEドメインと一致しなければならないということです。
Hybrid operations also require that:
ハイブリッド操作はまた、が必要です。
- 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対応のLSRは、のBC（セクション5.1で指定されるように、最大予約可能帯域幅サブTLVを使用して同様のBCサブTLV）をアドバタイズするように構成すること。
This allows DS-TE-capable LSRs to identify non-DS-TE-capable LSRs unambiguously.
これは、DS-TE対応のLSRが明確に非DS-TE対応のLSRを識別することができます。
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).
最後に、ハイブリッド動作は、非DS-TE対応のLSRが（P <Qと、すなわち、未予約と[P] <未予約[Q]）非減少帯域幅値を含む未予約のBWサブTLVを受け入れることができることを必要とします。
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 transit via (or terminate at) both DS-TE-capable LSRs and non-DS-TE-capable LSRs.
- CT0のLSP（またはで終端）DS-TE対応のLSRと非DS-TE対応のLSRの両方を介して遷移します。
- LSPs from other CTs can only be established by DS-TE-capable LSRs.
- 他のCTからのLSPは、DS-TE対応のLSRによって確立することができます。
- LSPs from other CTs can only transit via (or terminate at) DS-TE-capable LSRs.
- 他のCTからのLSPができる唯一のトランジットを介して（またはで終端）DS-TE対応のLSR。
Let us consider the following example to illustrate operations:
私たちは、操作を説明するために、次の例を考えてみましょう：
LSR0--------LSR1----------LSR2
Link01 Link12
where: LSR0 is a non-DS-TE-capable LSR LSR1 and LSR2 are DS-TE-capable LSRs
LSR0は非DS-TE対応LSR LSR1とLSR2はDS-TE対応のLSRあります。ここで、
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はLink01ための最大予約可能帯域幅= M01で構成されています。 LSR1はLink01ためBC0 = X0、BC1 = X1（おそらく= 0）、および最大予約可能帯域幅= M10（おそらく= M01）で構成されています。
In IGP for Link01, LSR0 will advertise:
Link01のためのIGPで、LSR0はアドバタイズします。
- Max Reservable Bw sub-TLV = <m01>
- 最大予約可能のBWサブTLV = <M01>
- Unreserved Bw sub-TLV = <CT0/0, CT0/1, CT0/2, CT0/3, CT0/4, CT0/5, CT0/6, CT0/7>
- 非予約のBWサブTLV = <CT0 / 0、CT0 / 1、CT0 / 2、CT0 / 3、CT0 / 4、CT0 / 5、CT0 / 6、CT0 / 7>
On receipt of such advertisement, LSR1 will:
そのような広告を受信すると、LSR1は以下となります。
- 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.
- LSR0介してのみ値CT0 / 2およびCT0 / 3未予約BwをサブTLVに意味のあることだけCT0のLSPできトランジットと結論づけます未予約BwをサブTLVに含まれている他の6つの値がゼロに設定されたかのようにLSR1を効果的に動作することができます。
In IGP for Link01, LSR1 will advertise:
Link01のためのIGPでは、LSR1はアドバタイズします。
- Max Reservable Bw sub-TLV = <m10>
- 最大予約可能のBWサブTLV = <M10>
- Bandwidth Constraints sub-TLV = <BC Model ID, x0, x1>
- 帯域幅の制約サブTLV = <BCモデルID、X0、X1>
- Unreserved Bw sub-TLV = <CT1/0, CT1/1, CT0/2, CT0/3, 0, 0, 0, 0>
- 非予約のBWサブTLV = <CT1 / 0、CT1 / 1、CT0 / 2、CT0 / 3、0、0、0、0>
On receipt of such advertisement, LSR0 will:
そのような広告を受信すると、LSR0以下となります。
- ignore the Bandwidth Constraints sub-TLV (unrecognized)
- 帯域幅の制約を無視サブTLV（認識できません）
- correctly process CT0/2 and CT0/3 in the Unreserved Bw sub-TLV and use these values for CTO LSP establishment
- 正しく処理CT0 / 2及び非予約BwをサブTLVでCT0 / 3及びCTO LSPの確立のためにこれらの値を使用
- 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.
- 誤って未予約BwをサブTLVに含まれる他の値は、CT0のための他の先取優先度に関連すると考えています。我々は唯一のプリエンプション2と3は、TEドメインで使用されていることを前提とするので、それは実際にそれらを使用することはありません。
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]ルFaucheur、F.およびW.ライ、 "差別化サービスを意識したMPLSトラフィックエンジニアリングのサポートのための要件"、RFC 3564、2003年7月。
[MPLS-ARCH] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[MPLS-ARCH]ローゼン、E.、Viswanathanの、A.とR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、RFC 3031、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のための要件"、RFC 2702、1999年9月。
[OSPF-TE] Katz, D., Kompella, K. and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
、RFC 3630、2003年9月[OSPF-TE]カッツ、D.、Kompella、K.、およびD.ヨン、 "OSPFバージョン2へのトラフィックエンジニアリング（TE）の拡張"。
[ISIS-TE] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004.
[ISIS-TE]スミット、H.、およびT.李、 "トラフィックエンジニアリングのための中間システム（ISIS）拡張機能（TE）への中間システム"、RFC 3784、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.、スリニバサン、V.およびG.ツバメ、 "RSVP-TE：ExtensionsがLSPトンネルのためのRSVPする"、RFC 3209、 2001年12月。
[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の機能的な仕様"、RFC 2205、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.
[DIFF-MPLS]ルFaucheur、F.、ウー、L.、デイビー、B.、Davari、S.、Vaananen、P.、クリシュナン、R.、シュヴァル、P.及びJ. Heinanen、「マルチプロトコルラベル差別化サービスの（MPLS）サポート」、RFC 3270、2002年5月を切り替えます。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、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-CONS] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、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.
[DIFF-ARCH]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.、およびW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、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]ルFaucheur、F。、エド。、 "Diffservの認識MPLSトラフィックエンジニアリングのためのロシア人形の帯域幅制約モデル"、RFC 4127、2005年6月。
[DSTE-MAM] Le Faucheur, F. and W. Lai, "Maximum Allocation Bandwidth Constraints Model for Diffserv-aware Traffice Engineering", RFC 4125, June 2005.
[DSTE-MAM]ルFaucheur、F.およびW.ライ、 "Diffservの認識Trafficeエンジニアリングの最大割り当て帯域幅の制約モデル"、RFC 4125、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-MAR]アッシュ、J.、RFC 4126 "のDiffServを意識したMPLSトラフィックエンジニアリング＆パフォーマンス比較のための予約帯域幅の制約モデルによる最大配分"、2005年6月。
[GMPLS-SIG] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[GMPLS-SIG]バーガー、L.、 "一般化されたマルチプロトコルラベルスイッチング（GMPLS）機能説明シグナリング"、RFC 3471、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.
[BUNDLE] Kompella、Rekhter、バーガー、 "MPLSトラフィックエンジニアリングでのリンクバンドル" が進行中で働いています。
[HIERARCHY] Kompella, Rekhter, "LSP Hierarchy with Generalized MPLS TE", Work in Progress.
[HIERARCHY] Kompella、Rekhter、 "一般化MPLS TE LSPと階層"、ProgressのWork。
[REROUTE] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[REROUTE]パン、P.、ツバメ、G.、およびA.アトラス、 "高速リルート機能拡張LSPトンネルのための-TEをRSVPする"、RFC 4090、2005年5月。
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
フランソワ・リーパーシスコシステムズ社コーポレート・ヴィレッジグリーンサイド - T3ビル400、アベニューRoumanille 06410ビオ・ソフィアアンティポリス、フランス
Phone: +33 4 97 23 26 19 EMail: flefauch@cisco.com
電話：+33 4 97 23 26 19 Eメール：flefauch@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。