[要約] RFC 4124は、Diffserv-aware MPLS Traffic Engineeringのサポートのためのプロトコル拡張に関するものです。その目的は、MPLSネットワークでのトラフィックエンジニアリングにおいて、Diffserv（Differentiated Services）の要件を満たすための拡張を提供することです。
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
Diffserv-Aware MPLSトラフィックエンジニアリングをサポートするためのプロトコル拡張
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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）をサポートするためのプロトコル拡張機能を指定します。これには、RFC 3630、RFC 3784、およびそれらを超えた追加のIGP拡張機能の既存のMPLSトラフィックエンジニアリング用に既に定義されている多くのインテリアゲートウェイプロトコル（IGP）拡張のセマンティクスの一般化が含まれます。これには、既存のMPLSトラフィックエンジニアリングについてRFC 3209ですでに指定されているものを超えたRSVP-TEシグナル伝達への拡張も含まれます。これらの拡張機能は、RFC 3564で説明されているDS-TEの要件に対応しています。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Specification of Requirements ..............................3
2. Contributing Authors ............................................4
3. Definitions .....................................................5
4. Configurable Parameters .........................................5
4.1. Link Parameters ............................................5
4.1.1. Bandwidth Constraints (BCs) .........................5
4.1.2. Overbooking .........................................6
4.2. LSR Parameters .............................................7
4.2.1. TE-Class Mapping ....................................7
4.3. LSP Parameters .............................................8
4.3.1. Class-Type ..........................................8
4.3.2. Setup and Holding Preemption Priorities .............8
4.3.3. Class-Type/Preemption Relationship ..................8
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）のサポートに関するサービスプロバイダーの要件を提示します。これには、さまざまなクラスのトラフィックに異なる帯域幅の制約を実施できるための基本的な要件が含まれます。
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]に既に指定されているものを超えて）を指定しています。-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]は、帯域幅制約モデルの定義と例を提供します。現在のドキュメントでは、特定の帯域幅の制約モデルを指定したり、想定したりしません。特定の帯域幅の制約モデルは、このドキュメントの範囲外です。このドキュメントで指定されたDS-TEの拡張は、考えられるすべての帯域幅制約モデルをサポートするのに十分ではないかもしれませんが、[DSTE-MAM]で指定された最大割り当てモデルである[DSTE-RDM]で指定されたロシアの人形モデルをサポートしています。、および[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で発現および取得されたサービスの品質には違いがあるかもしれません。DS-TEは制約ベースのルーティングを使用しているため、およびDiffServに追加される入学制御機能の種類のために、DS-TEはDiffservがそうではないトラフィックの機能を持っています。Diffservは、意図的に先制を示すものではありませんが、DS-TEは説明します。クラスタイプの複数のレベルの先制。また、DiffServはオーバーブッキングを明示的に制御する手段をサポートしていませんが、DS-TEはこれを許可します。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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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
Phone: (919) 852-5160 EMail: kireeti@juniper.net
EMail: 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
Phone: +1-978-264-4900 Phone: +1-978-244-3051
EMail: btownsend@tenornetworks.com EMail: tnadeau@cisco.com
Darek Skalecki Nortel Networks 3500 Carling Ave, Nepean K2H 8E9
Darek Skalecki Nortel Networks 3500 Carling Ave、Nepean K2H 8E9
Phone: +1-613-765-2252
EMail: 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).
トラフィックトランク：同じクラスのトラフィックフローの集約（つまり、DS-TEの観点から同等に扱われます）。これは、ラベルスイッチ付きパス（LSP）内に配置されます。
Class-Type (CT): the set of Traffic Trunks crossing a link that is governed by a specific set of bandwidth constraints. CT is used for the purposes of link bandwidth allocation, constraint-based routing and admission control. A given Traffic Trunk belongs to the same CT on all links.
クラスタイプ（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.
このセクションでは、[TE-REQ]、[ISIS-TE]、[OSPF-TE]、および[RSVP-TE]に従って、MPLSトラフィックエンジニアリングにサポートされている構成可能なパラメーターとの違いについてのみ説明します。他のすべてのパラメーターは変更されていません。
[DSTE-REQ] states that "Regardless of the Bandwidth Constraints Model, the DS-TE solution MUST allow support for up to 8 BCs."
[DSTE-REQ]は、「帯域幅の制約モデルに関係なく、DS-TEソリューションは最大8 BCSのサポートを許可する必要がある」と述べています。
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.
ここで、範囲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.
帯域幅の制約モデルがこれらのBCSに対して構成される値に何らかの関係を課す場合、LSRは構成時間にそれらを強制する必要があります。たとえば、ロシアの人形帯域幅の制約モデル（[DSTE-RDM]）を使用する場合、LSRはBCIがBCJ以下のBCJよりも小さく構成されていることを確認する必要があります。最大予約可能帯域幅。別の例として、最大割り当てモデル（[DSTE-MAM]）が使用される場合、LSRはすべてのBCIが最大予約可能帯域幅に小さくまたは等しく構成されていることを確認する必要があります。
DS-TE enables a network administrator to apply different overbooking (or underbooking) ratios for different CTs.
DS-TEを使用すると、ネットワーク管理者は、異なるCTSに異なるオーバーブッキング（またはアンダーブッキング）比を適用できます。
The principal methods to achieve this are the same as those historically used in existing TE deployment:
これを達成するための主要な方法は、既存の展開で歴史的に使用されている方法と同じです。
(i) To take into account the overbooking/underbooking ratio appropriate for the Ordered Aggregate (OA) or CT associated with the considered LSP at the time of establishing the bandwidth size of a given LSP. We refer to this method as the "LSP Size Overbooking" method. AND/OR (ii) To take into account the overbooking/underbooking ratio at the time of configuring the Maximum Reservable Bandwidth/BCs and use values that are larger (overbooking) or smaller (underbooking) than those actually supported by the link. We refer to this method as the "Link Size Overbooking" method.
(i) 特定のLSPの帯域幅サイズを確立した時点で、考慮されたLSPに関連する順序付けられた集合体（OA）またはCTに適したオーバーブッキング/アンダーブッキング比を考慮します。この方法は、「LSPサイズのオーバーブッキング」メソッドと呼びます。および/または（ii）最大予約可能な帯域幅/BCSを構成した時点でオーバーブッキング/アンダーブッキング比を考慮し、実際にリンクでサポートされているものよりも大きい（オーバーブッキング）またはより小さい（アンダーブッキング）値を使用します。この方法は、「リンクサイズのオーバーブッキング」メソッドと呼びます。
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サイズのオーバーブッキング」および「リンクサイズのオーバーブッキング」メソッドは、多くのDSTE環境で十分であると予想され、追加の構成可能なパラメーターは必要ありません。他のオーバーブッキング方法には、このような追加の構成可能なパラメーターが含まれる場合がありますが、このドキュメントの範囲を超えています。
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]で定義されている先制属性はDS-TEで保持され、すべてのCTで適用されます。セットアップの優先順位と保持優先度の先制属性は、既存のセマンティクスを保持します。特に、これらのセマンティクスはLSP CTの影響を受けません。これは、LSP1がリソースに対してLSP2と競合する場合、LSP1がLSP1 CTおよびLSP2 CTに関係なく、LSP2を保持する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は、Class-TypeおよびPreemptionレベルが（最大）8つのTEクラスのそれぞれに対して構成されるため、TEクラスマッピングの構成を許可する必要があります。
This mapping is referred to as :
このマッピングは次のように呼ばれます。
TE-Class[i] <--> < CTc , preemption p >
where 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).
2つの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つのクラスタイプのいずれかを、8つの先制優先順位のいずれかとどのようにペアにしてTEクラスを形成できるかについて、他の制限はありません。特に、1つはプリエンプションの優先度を与えられた場合、2つ（またはそれ以上）のクラスタイプとペアにして、2つ（またはそれ以上）のTEクラスを形成できます。同様に、1つのクラスタイプを2つ（またはそれ以上）の異なる先制優先順位とペアにして、2つ（またはそれ以上）のTEクラスを形成できます。また、TEクラスのインデックス（つまり、上記の「I」）とクラスタイプ（つまり、上記の「C」）またはTEの先制の優先順位（つまり、上記の「P」）との間に必須の順序関係はありません。-クラス。
Where the network administrator uses less than 8 TE-Classes, the DS-TE LSR MUST allow remaining ones to be configured as "Unused". Note that configuring all the 8 TE-Classes as "Unused" effectively results in disabling TE/DS-TE since no TE/DS-TE LSP can be established (nor even configured, since as described in Section 4.3.3 below, the CT and preemption priorities configured for an LSP MUST form one of the configured TE-Classes).
ネットワーク管理者が8個未満のTEクラスを使用する場合、DS-TE LSRは残りのLSRを「未使用」として構成することを許可する必要があります。すべての8つのTEクラスを「未使用」として構成すると、TE/DS-TE LSPが確立できないため、TE/DS-TEを無効にすることになることに注意してください（以下のセクション4.3.3で説明したように、CTはCTを設定します。LSP用に構成されたプリエンプション優先順位は、構成されたTEクラスの1つを形成する必要があります）。
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クラスマッピングを構成する必要があります。
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クラスマッピングで構成されている間に構成されている間に、一部のDS-TE LSRがまだ構成されている再構成期間中に注意を払う必要があります古い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ごとに構成されたクラスタイプの1つだけがあります。
The configured Class-Type indicates, in accordance with the supported Bandwidth Constraints Model, the BCs that MUST be enforced for that LSP.
構成されたクラスタイプは、サポートされている帯域幅制約モデルに従って、そのLSPに対して施行する必要があるBCSを示します。
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クラスの1つを形成するようなものでなければなりません。 - 上記のセクション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クラスの1つを形成するようなものでなければなりません上記のセクション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.
イラストのために、これらの構成可能なパラメーターをどのように使用するかについてのいくつかの例を示します。これらのすべての例は、2つ以上のクラスタイプを使用する必要があるため、さまざまな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つのCTSを使用した最初のネットワークのネットワーク管理者（Voice for Voice、およびデータのCT0）を使用すると、データ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
Data LSPs would then be configured with:
CT = CT0, setup priority = 1, holding priority = 1
A new Voice LSP would then be able to preempt an existing Data LSP in case they contend for resources. A Data LSP would never preempt a Voice LSP. A Voice LSP would never preempt another Voice LSP. A Data LSP would never preempt another Data LSP.
新しい音声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
Large-size Data LSPs could be configured with:
CT = CT0, setup priority = 1, holding priority = 1
Small-size Voice LSPs could be configured with:
CT = CT1, setup priority = 2, holding priority = 2
Small-size Data LSPs could be configured with:
CT = CT0, setup priority = 3, holding priority = 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.
大規模な音声LSPは、ct = ct1、セットアップ優先度= 0、優先度= 0で構成できます。
Small-size Voice LSPs could be configured with: CT = CT1, setup priority = 1, holding priority = 1.
小型音声LSPは、ct = ct1、setup priority = 1、[優先度= 1]で構成できます。
Large-size Data LSPs could be configured with: CT = CT0, setup priority = 2, holding priority = 2.
大規模なデータLSPは、ct = ct0、setup priority = 2、保持優先度= 2で構成できます。
Small-size Data LSPs could be configured with: CT=CT0, setup priority = 3, holding priority = 3.
小型データLSPは、ct = ct0、setup priority = 3、保持優先度= 3で構成できます。
A Voice LSP could preempt a Data LSP if they contend for resources. A Data LSP would never preempt a Voice LSP. A large-size Voice LSP could preempt a small-size Voice LSP if they contend for resources. A large-size Data LSP could preempt a small-size Data LSP if they contend for resources.
音声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
Data LSPs would then be configured with:
CT = CT0, setup priority = 0, holding priority = 0
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.
大規模な音声LSPは、ct = ct1、セットアップ優先度= 0、優先度= 0で構成できます。
Small-size Voice LSPs could be configured with: CT = CT1, setup priority = 1, holding priority = 0.
小型音声LSPは、ct = ct1、setup priority = 1、[優先度を保持] = 0で構成できます。
Large-size Data LSPs could be configured with: CT = CT0, setup priority = 2, holding priority = 1.
大規模なデータLSPは、ct = ct0、setup priority = 2、保持優先度= 1で構成できます。
Small-size Data LSPs could be configured with: CT = CT0, setup priority = 2, holding priority = 2.
小型データLSPは、ct = ct0、setup priority = 2、保持優先度= 2で構成できます。
A new large-size Voice LSP would be able to preempt a Data LSP in case they contend for resources, but it would not be able to preempt any Voice LSP even a small-size Voice LSP.
新しい大規模な音声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またはVoice 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.
上記のセクション4.1.1で詳細に記載されているように、最大8 BC（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を使用すると、既存の「最大予約可能帯域幅」Sub-TLV（[OSPF-TE]、[ISIS-TE]）が一般化されたセマンティクスで保持されるため、すべてのクラスにわたって凝集帯域幅の制約として解釈する必要があります。種類;すなわち、合計（予約済み（CTC））<=帯域幅の制約モデルとは無関係に、最大予約可能帯域幅。
This document also defines the following new optional sub-TLV to advertise the eight potential BCs (BC0 to BC7):
このドキュメントでは、次の新しいオプションのサブTLVを定義して、8つの潜在的なBC（BC0からBC7）を宣伝します。
"Bandwidth Constraints" sub-TLV:
「帯域幅の制約」sub-tlv：
- Bandwidth Constraints Model Id (1 octet) - Reserved (3 octets) - Bandwidth Constraints (N x 4 octets)
- 帯域幅の制約モデルID（1オクテット） - 予約（3オクテット） - 帯域幅の制約（n x 4オクテット）
Where: - With OSPF, the sub-TLV is a sub-TLV of the "Link TLV" and its sub-TLV type is 17.
WHERE：-OSPFを使用すると、Sub-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.
- ISISを使用すると、Sub-TLVは「拡張性が到達可能なTLV」のサブTLVであり、そのサブTLVタイプは22です。
- Bandwidth Constraints Model Id: a 1-octet identifier for the Bandwidth Constraints Model currently in use by the LSR initiating the IGP advertisement. See the IANA Considerations section for assignment of values in this name space.
- 帯域幅制約モデルID：IGP広告を開始するLSRによって現在使用されている帯域幅制約モデルの1-OCTET識別子。この名前空間での値の割り当てについては、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オクテットフィールド。このフィールドは、Sub-TLVを生成するLSRによってゼロに設定され、Sub-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ビットでエンコードされています。ユニットは1秒あたりのバイト（ビットではありません！）です。構成されたTEクラスマッピングと使用中の帯域幅制約モデルは、BCH 1、BCH 2、...、およびBC7が構成されたTEクラスに関連付けられたクラスタイプのいずれにも関連していない場合、それが推奨されることをお勧めします。IGPスケーラビリティへの影響を最小限に抑えるために、BC0からBCHへの帯域幅の制約のみを宣伝します。
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エンコードルール（TLV形式、パディング、アライメント、およびIEEEフローティングポイント形式エンコードを含む）は、この新しいサブTLVに適用されます。
The "Bandwidth Constraints" sub-TLV format is illustrated below:
「帯域幅の制約」サブTLV形式を以下に示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BC Model Id | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BC0 value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// . . . //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BCh value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A DS-TE LSR MAY optionally advertise BCs.
DS-TE LSRは、オプションでBCSを宣伝する場合があります。
A DS-TE LSR, which does advertise BCs, MUST use the new "Bandwidth Constraints" sub-TLV (in addition to the existing Maximum Reservable Bandwidth sub-TLV) to do so. For example, in the case where a service provider deploys DS-TE with TE-Classes associated with CT0 and CT1 only, and where the Bandwidth Constraints Model is such that only BC0 and BC1 are relevant to CT0 and CT1, a DS-TE LSR which does advertise BCs would include in the IGP advertisement the Maximum Reservable Bandwidth sub-TLV, as well as the "Bandwidth Constraints" sub-TLV. The former should contain the aggregate bandwidth constraint across all CTs, and the latter should contain BC0 and BC1.
BCSを宣伝するDS-TE LSRは、新しい「帯域幅の制約」Sub-TLVを使用して（既存の最大予約可能帯域幅サブTLVに加えて）、そうする必要があります。たとえば、サービスプロバイダーがCT0およびCT1のみに関連付けられたTEクラスでDS-TEを展開する場合、および帯域幅の制約モデルは、BC0とBC1のみがCT0およびCT1に関連するようなものである場合、DS-TE LSRBCSの広告には、IGP広告に最大予約可能な帯域幅サブTLV、および「帯域幅の制約」サブTLVが含まれます。前者には、すべての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 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を使用して「帯域幅制約」サブTLVを受信するDS-TE LSRは、オペレーター/管理システムに警告を生成し、使用される帯域幅制約モデル間の不整合を報告するはずですさまざまなリンクで。また、その場合、DS-TE LSRが帯域幅制約モデル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:
より正確には、DS-TE LSRは、以下に一般化された定義を使用して、予約されていない帯域幅サブTLVをサポートする必要があります。
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の開始時に発生し、サブTLVの終了時にTEクラス[7]の帯域幅が予約されていない帯域幅が発生します。TEクラス[i]（0 <= i <= 7）の予約されていない帯域幅値は、「未返信TEクラス[i]」と呼ばれます。これは、予約のために利用可能な帯域幅を、次のことを示しています。
- transports a Traffic Trunk from the Class-Type of TE-Class[i], and
- TEクラスのクラスタイプからトラフィックトランクを輸送します[i]、および
- has a setup priority corresponding to the preemption priority of TE-Class[i].
- TEクラスの先制優先度に対応するセットアップの優先度があります[i]。
The units are bytes per second.
ユニットは1秒あたりのバイトです。
Because the bandwidth values are now ordered by TE-class index and thus can relate to different CTs with different BCs and to any arbitrary preemption priority, a DS-TE LSR MUST NOT assume any ordered relationship among these bandwidth values.
帯域幅の値はTEクラスインデックスによって順序付けられているため、異なるBCを持つ異なるCTSおよび任意の先制の優先順位に関連する可能性があるため、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:
既存のTEでは、すべての先制優先順位が同じ（およびのみ）BCと帯域幅の値が先制優先順位で宣伝されているため、次の関係は常に真実であり、TEの実装によって想定されることがよくあります。
If i < j, then "Unreserved Bw [i]" >= "Unreserved Bw [j]"
With DS-TE, no relationship is to be assumed such that:
DS-TEでは、次のような関係はありません。
If i < j, then any of the following relationships may be true: "Unreserved TE-Class [i]" = "Unreserved TE-Class [j]" OR "Unreserved TE-Class [i]" > "Unreserved TE-Class [j]" OR "Unreserved TE-Class [i]" < "Unreserved TE-Class [j]".
i <jの場合、次の関係のいずれかが真実である場合があります： "unreserved te-class [i]" = "unreserved te-class [j]"または "unreserved te-class [i]"> "[j] "または「予約されていないTe-class [i]」<" unressive te-class [j] "。
Rules for computing "Unreserved TE-Class [i]" are specified in Section 11.
「予約されていないTE-Class [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]が使用されていない場合、IGPによって宣伝されている「Unleserved TE-Class [i]」で宣伝されている値は、IGP広告を生成するLSRによってゼロに設定する必要があり、IGP広告を受信するLSRによって無視する必要があります。。
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-Aware MPLSトラフィックエンジニアリングのサポートについては、RSVP-TEの拡張について説明します。これらの拡張機能は、（集計）MPLSトラフィックエンジニアリングのサポートのために[RSVP-TE]で定義されているRSVPへの拡張機能と、MPLS上のDIFSERVのサポートのために[DIFF-MPLS]で定義された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.
このドキュメントでは、1つの新しいRSVPオブジェクトが定義されています。Classtypeオブジェクトです。このオブジェクトの詳細な説明を以下に示します。この新しいオブジェクトは、パスメッセージに適用できます。この仕様は、[RSVP-TE]に従ってLSPトンネルを確立するために使用されるPATHメッセージでのClasStypeオブジェクトの使用のみを定義し、したがって、LSP_Tunnel_Ipv4に等しくlabel_requestオブジェクトを含むCTを持つセッションオブジェクトを含む。
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オブジェクトは、RSVPに関してオプションであるため、MPLS LSPセットアップに関係のない一般的なRSVP実装では、このオブジェクトをサポートする必要がありません。
An LSR supporting DS-TE MUST support the CLASSTYPE object.
DS-TEをサポートするLSRは、ClasStypeオブジェクトをサポートする必要があります。
The format of the Path message is as follows:
パスメッセージの形式は次のとおりです。
<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です。そのクラス番号は66です。現在、Cタイプ1である定義済みのCタイプは1つだけです。
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、...、7です。0の値は予約されています。
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のセッションタイプとを使用してパスメッセージを作成します。
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はパスメッセージに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は、クラスタイプ（CT）フィールドがNに設定されたパスメッセージに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.
パスメッセージに複数の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オブジェクトがパスメッセージに存在しない場合、LSRはクラスタイプ0をLSPに関連付ける必要があります。
The destination LSR responding to the Path message by sending a Resv message MUST NOT include a CLASSTYPE object in the Resv message (whether or not the Path message contained a CLASSTYPE object).
RESVメッセージを送信してパスメッセージに応答する宛先LSRは、RESVメッセージにclasStypeオブジェクトを含めてはなりません（パスメッセージに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オブジェクトを認識し、次のパスメッセージを受信する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-aware teエラー」と「予期しないclasstypeオブジェクト」のエラー値を使用して、送信者にpatherrを送信する必要があります。これらのコードは、セクション6.5で定義されています。
An LSR receiving a Path message with the CLASSTYPE object that:
clasStypeオブジェクトを使用してパスメッセージを受信するLSRは次のとおりです。
- 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-Aware TEエラー」と「サポートされていないクラスタイプ」のエラー値を使用して、送信者にPatherrを送信する必要があります。これらのコードは、セクション6.5で定義されています。
An LSR receiving a Path message with the CLASSTYPE object that:
clasStypeオブジェクトを使用してパスメッセージを受信するLSRは次のとおりです。
- 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-aware teエラー」と「無効なクラスタイプ値」のエラー値を使用して、送信者にpatherrを送信する必要があります。これらのコードは、セクション6.5で定義されています。
An LSR receiving a Path message with the CLASSTYPE object, which:
ClasStypeオブジェクトでパスメッセージを受信するLSRは次のとおりです。
- 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クラスの1つではないと判断します。
MUST send a PathErr towards the sender with the error code "Diffserv-aware TE Error" and an error value of "CT and setup priority do not form a configured TE-Class". These codes are defined in Section 6.5.
エラーコード「diffserv-aware TEエラー」と「CTとセットアップの優先度のエラー値が設定されたTEクラスを形成しない」というエラーコードを送信者に送信する必要があります。これらのコードは、セクション6.5で定義されています。
An LSR receiving a Path message with the CLASSTYPE object that:
clasStypeオブジェクトを使用してパスメッセージを受信するLSRは次のとおりです。
- 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）このクラスタイプによって形成されたタプルと（ii）同じパスメッセージで信号を送られた保持優先度は、TEクラスマッピングで構成されている8つのTEクラスの1つではないと判断します。
MUST send a PathErr towards the sender with the error code "Diffserv-aware TE Error" and an error value of "CT and holding priority do not form a configured TE-Class". These codes are defined in Section 6.5.
エラーコード「diffserv-aware TEエラー」と「CTと保持優先度のエラー値が設定されたTEクラスを形成しない」というエラーコードを送信者に送信する必要があります。これらのコードは、セクション6.5で定義されています。
An LSR receiving a Path message with the CLASSTYPE object that:
clasStypeオブジェクトを使用してパスメッセージを受信するLSRは次のとおりです。
- 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クラスの1つではなく、
- 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）このクラスタイプによって形成されたタプル、および（ii）同じパスメッセージで信号を送信した保持優先度は、TEクラスマッピングで構成されている8つのTEクラスの1つではないと判断します
MUST send a PathErr towards the sender with the error code "Diffserv-aware TE Error" and an error value of "CT and setup priority do not form a configured TE-Class AND CT and holding priority do not form a configured TE-Class". These codes are defined in Section 6.5.
エラーコード「diffserv-aware TEエラー」と「CTとセットアップの優先順位のエラー値が設定されたTEクラスとCTを形成せず、優先度を保持するエラー値が設定されていない場合は設定されたTEクラスを形成しない」というエラーコードを送信者に送信する必要があります。。これらのコードは、セクション6.5で定義されています。
An LSR receiving a Path message with the CLASSTYPE object and with the DIFFSERV object for an L-LSP that:
Classtypeオブジェクトとl-lspのdiffservオブジェクトを使用してパスメッセージを受信するLSRは次のとおりです。
- recognizes the CLASSTYPE object,
- classtypeオブジェクトを認識します。
- has local knowledge of the relationship between Class-Types and Per Hop Behavior (PHB) Scheduling Class, e.g., via configuration, and
- クラスタイプとホップごとの行動（PHB）のスケジューリングクラスとの関係に関するローカルな知識があります。たとえば、構成を介して、および
- determines, based on this local knowledge, that the PHB Scheduling Class (PSC) signaled in the DIFFSERV object is inconsistent with the Class-Type signaled in the CLASSTYPE object,
- このローカルな知識に基づいて、diffservオブジェクトで信号を送られたPHBスケジューリングクラス（PSC）は、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-aware 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:
classtypeオブジェクトとe-lspのdiffservオブジェクトを使用してパスメッセージを受信するLSRは次のとおりです。
- 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,
- このローカルな知識に基づいて、DiffServオブジェクトのマップエントリでシグナルが表示されているPHBは、ClasStypeオブジェクトで信号を送信したクラスタイプと矛盾していると判断します。
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-aware 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]および[diff-mpls]に従って、このセクションですでに議論されている理由以外の理由でLSPを受け入れることができない状況を処理する必要があります（たとえば、入学管理によって予約が拒否されます。ラベルを関連付けることはできません）。
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).
ClasStypeオブジェクトクラス-Numを認識しないLSRは、形式が0bbbbbbbである未知のクラスNumの[RSVP]で指定された手順に従って動作する必要があります（つまり、エラーコード "不明なオブジェクトクラス"「送信者に向かって）。
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は、未知のCタイプの[RSVP]で指定された手順に従って動作する必要があります（つまり、Patherrを送信する必要があります。送信者に対する「不明なオブジェクト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-aware TEエラー」として報告されています。「diffserv-aware teエラー」エラーコードの値は28です。
The following table defines error values for the Diffserv-aware TE Error:
次の表は、diffserv-aware 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クラスとクラスタイプを形成せず、優先順位を保持することは、シグナル付きPSCとシグナル付きのクラスタイプ8のシグナル付きPHBとシグナル付きクラスタイプの間の構成されたTEクラス7の矛盾を形成しません
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サポートには多くの拡張があります。これらには、一般化のための拡張機能（[gmpls-sig]および[gmpls-route]）、およびLSP階層[階層]、リンクバンドリング[バンドル]、高速回復[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-aware TEのこの仕様と、上記のような特定のMPLS強化の両方のこの仕様の両方をサポートするために（ただし、それらに限定されない）、「先制の優先順位」と「最大留置可能な帯域幅」への言及を扱う必要があります。一般化された方法で、つまり、この仕様がそれらの用語を使用する方法。
Additionally, current and future MPLS enhancements may include more precise specification for how they interact with Diffserv-aware TE.
さらに、現在および将来のMPLS強化には、Diffserv-Aware 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プロトコル拡張の1つをサポートする場合、MPLS拡張に定義されたIGPの先制優先事項に関連する情報のシグナル伝達またはエンコードにおける先制優先値の値のエンコーディングは、MPLS拡張に定義されたIGPの優先順位をエンコードする必要があります。対応するTEクラスの同じ情報のエンコード。たとえば、MPLS拡張機能が、Preemption Priority Nのルーティング情報のパラメーターのIGPで広告を指定している場合、DS-TE環境では、同じルーティング情報の広告を指定すると解釈する必要がありますが、TE-Class [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-akeare 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クラス[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によって宣伝されている「予約されていないTEクラス[i]」に適合する単一の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 BCs MIGHT be used as tie-breaker criteria in situations where multiple paths, otherwise equally attractive, are possible.
制約ベースのルーティングアルゴリズムは、使用すると、BCSや最大予約可能帯域幅などのIGPで宣伝されているオプションの追加情報を考慮することもできます。たとえば、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.
LSP施設で合図されたクラスタイプは、DS-TE LSRSによってオプションで使用され、DiffServスケジューラによってクラスタイプに割り当てられたリソースを動的に調整できます。さらに、[diff-mpls]で指定されているTE-LSPシグナル伝達プロトコルによってシグナル化されたdiffserv情報（すなわち、PSC）は、DS-TE LSRによってオプションで使用され、DIFServによって割り当てられたリソースを動的に調整することができます。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つの8つの先制優先順位が許可され、（iii）次のTEクラスマッピングが使用されます：TE-Class [i] < - > <ct0、preemptioni>ここで、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は次のことを宣伝できます。
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.
すべてのLSPはCT0からのトラフィックトラフィックを輸送するため、RSVP-TEシグナル伝達は、既存のTEと同様に、クラスタイプの明示的なシグナル（セクション6以外のクラスタイプにのみ使用される）なしで行われます。
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に予約されていないBWの観点から世界の地元の見方を宣伝するため、これはさまざまな実装間で相互運用性を損なうことはないことに注意してください。このように、与えられた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はLSRに追加の要件を配置し、宣伝されている予約されていない帯域幅の値が、帯域幅の制約モデルに従ってTEクラスに関連するCTに関連するすべてのBCSを反映する必要があります。したがって、「予約されていないTEクラス[i]」を計算するための式は、使用中の帯域幅制約モデルに依存し、BCがCTSに適用する方法を反映する必要があります。[DSTE-RDM]および[DSTE-MAM]でそれぞれロシアの人形モデルと最大割り当てモデルに「予約されていないTEクラス[i]」モデルを計算するための式の例が提供されます。
As with existing TE, DS-TE LSRs MUST consider the holding preemption priority of established LSPs (as opposed to their setup preemption priority) for the purpose of computing the unreserved bandwidth for TE-Class [i].
既存のTEと同様に、DS-TE LSRは、TEクラスの予定されていない帯域幅を計算する目的で、確立されたLSPの保持先制優先度（セットアップの先制の優先事項とは対照的に）を考慮する必要があります[i]。
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クラス[i]の予約されていない帯域幅、帯域幅BのLSPを実際に計算するかに関係なくそして、場合にのみ、
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.
LSRで構成されたTEクラスマッピングのTEクラス[i]が<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 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（[diff-arch]）およびmplsトラフィックエンジニアリング（[te-req]、[rsvp-te]、[ospf-te]、[isis-te]）について説明されているものを超えて追加のセキュリティ脅威を導入しません。これらのドキュメントで説明されているのと同じセキュリティ対策と手順がここに適用されます。たとえば、[Diff-arch]で議論された盗難およびサービス拒否攻撃に対する防御のアプローチは、DS境界ノードでのトラフィックコンディショニングの組み合わせと、DiffServドメイン内のネットワークインフラストラクチャのセキュリティと整合性で構成されています。、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:
このドキュメントは、セクション5.1で、OSPFとISISの両方で「帯域幅制約」Sub-TLV内の「帯域幅制約モデル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 範囲0-239の値は、[IANA-CON]で定義された「必要な仕様」ポリシーに従って割り当てられます。
o values in the range 240-255 are reserved for "Private Use" as defined in [IANA-CONS].
o 範囲240-255の値は、[Iana-Cons]で定義されている「プライベート使用」のために予約されています。
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.
エラーコードは、[RSVP]で定義された8ビット数量で、エラー条件を広く定義するためにERROR_SPECオブジェクトに表示されます。各エラーコードでは、エラーの原因をさらに指定する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-Aware TEエラー」を定義しています（セクション13.3.4を参照）。「diffserv-aware 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）の「リンクTLV」内のサブTLVタイプの名前空間と、IANAによるこの名前スペースの管理の規則を作成します。
This document defines in Section 5.1 a new sub-TLV, the "Bandwidth Constraints" sub-TLV, for the OSPF "Link" TLV. In accordance with the IANA considerations provided in [OSPF-TE], a sub-TLV type in the range 10 to 32767 was requested, and the value 17 has been assigned by IANA for the "Bandwidth Constraints" sub-TLV.
このドキュメントでは、セクション5.1で、OSPF "リンク" TLVの新しいサブTLV、「帯域幅制約」サブTLVを定義しています。[OSPF-TE]で提供されたIANAの考慮事項に従って、10〜32767の範囲のサブTLVタイプが要求され、値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タイプの名前空間を作成します。
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.
このドキュメントでは、セクション5.1で新しいサブTLV、「帯域幅の制約」サブTLVを定義します。ISISの「拡張性は到達可能性」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]のセクション3.10で定義されている範囲から、このRSVPオブジェクトのクラス番号を、理解していない場合、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はクラス番号66をClasStypeオブジェクトに割り当てました。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-Aware TEエラー」を定義しています。[RSVP]で提供されているIANAの考慮事項に従って、IANAによってエラーコード28が「Diffserv-Aware 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.
エラーコードは、[RSVP]で定義された8ビット数量で、エラー条件を広く定義するためにERROR_SPECオブジェクトに表示されます。各エラーコードでは、エラーの原因をさらに指定する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-Aware TEエラー」を定義しています（セクション13.3.4を参照）。「diffserv-aware teエラー」のエラー値は、IANAが管理する新しい名前スペースを構成します。
This document defines, in Section 6.5, the following Error Values for the "Diffserv-aware TE Error":
このドキュメントは、セクション6.5で、「Diffserv-Aware 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クラスとクラスタイプを形成せず、優先順位を保持することは、シグナル付きPSCとシグナル付きのクラスタイプ8のシグナル付きPHBとシグナル付きクラスタイプの間の構成されたTEクラス7の矛盾を形成しません
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.
この作品での以前の貢献について、マーティン・タタム、アンジェラ・チウ、ピート・ヒックスに感謝します。また、徹底的なレビューと提案をしてくれたSanjaya Choudhuryにも感謝します。
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情報を受信する前に（n 1）-th LSPのパスを計算する際に、予約されていない帯域幅に対するN-Th LSPの影響を予測しようとすることには、ヘッドエンドには潜在的な利点があります。たとえば、複数のLSPのより良い負荷分布は、複数のパスで実行されます。また、（n 1）-LSPがN-Th 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 Sub-TLVとオプションの最大予約可能帯域幅Sub-TLVは、予約されていないBW Sub-TLVに含まれる情報がすべてであるため、PATH計算のために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.
このような予測がヘッドエンドで使用されている場合、オプションのBCS Sub-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：ソリューション評価
This DS-TE Solution addresses all the scenarios presented in [DSTE-REQ].
このDS-TEソリューションは、[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-REQ]のセクション4.7の最後の段落「オーバーブッキング」は、このDS-TEソリューションによって部分的にしか扱われていません。「LSPサイズのオーバーブッキング」および「リンクサイズのオーバーブッキング」メソッドのサポートを通じて、このDS-TEソリューションにより、CTSが異なるオーバーブッキング比を効果的に持つことができ、同時にオーバーブッキングを異なるリンクで異なる（まとめてすべてのCTSで）微調整することができます。しかし、一般的な意味では、すべてのCTの効果的なオーバーブッキング比を他のCTとは無関係にネットワークの異なる部分で異なる方法で調整することはできませんが、共有BCを通じて異なるCTが相互にどのように影響するかの正確な帯域幅を維持することはできません（最大予約可能帯域幅など）。
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つのCTSをサポートしています。交通トランクがどのようにグループ化されているかについて、完全に柔軟です。
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つのCTSが快適以上と見なされます。このドキュメントの著者によっては、最大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-Aware Traffic Engineeringのサポートですが、そのメカニズムはDiffServと密接に結びついていません。これにより、潜在的な将来の交通工学アプリケーションをサポートするために、ソリューションを適切に、またはより簡単に拡張できます。
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時）。
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.
シグナル伝達の観点からは、1つの追加情報（クラスタイプ）の処理のみが必要であり、CAC拒絶の可能性を大幅に増加させないため、このソリューションのために大きな影響がないと予想されます。DS-TEは、LSPシグナル伝達に固有の影響を与えることに注意してください。これは、異なるクラスのトラフィックが異なるLSPで分割されていることを想定しているため、より多くのLSPを信号する必要があることに注意してください。ただし、これはDS-TEの概念自体によるものであり、ここで説明する実際のDS-TEソリューションによるものではありません。
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がDS-TEの有能であり、移動段階で発生する可能性のあるハイブリッドネットワークでの操作が可能になります。この付録では、このようなハイブリッドネットワークでの制約と操作について説明します。
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対応LSRのセットをDS-TEドメインと呼びます。非DS-TE-Capable（ただし、TE対応）LSRのセットをTEドメインと呼びます。
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
- TEドメインで実際に使用されているすべての先制優先度ごとにCT0にTEクラスが存在し、
- 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ドメインがPreemption 2および3を使用することを想像してください。次に、TEクラスマッピングに次のTEクラスを含めることにより、DS-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対応LSRは、最大予約可能帯域幅を宣伝するように構成されています。
- DS-TE-capable LSRs be configured to advertise BCs (using the Max Reservable Bandwidth sub-TLV as well as the BCs sub-TLV, as specified in Section 5.1).
- DS-TE-Capable LSRは、BCSを宣伝するように構成されています（セクション5.1で指定されているように、BCS Sub-TLVと同様に、最大保留可能な帯域幅サブTLVを使用）。
This allows DS-TE-capable LSRs to identify non-DS-TE-capable LSRs unambiguously.
これにより、DS-TE対応LSRSは、非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が、非減少帯域幅の値を含む非予約されていないBWサブTLVを受け入れることができます（つまり、P <Qを使用して保証されていない[P] <QUNSERFERT [Q]）。
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 LSPは、DS-TE対応LSRと非DS-TE-担当LSRの両方によって確立できます。
- 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.
- 他のCTSからのLSPは、DS-TE対応LSRによってのみ確立できます。
- LSPs from other CTs can only transit via (or terminate at) DS-TE-capable LSRs.
- 他のCTSからの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
WHERE：LSR0は非DS-TE対応LSR LSR1およびLSR2はDS-TE-担当LSRSです
Let's assume again that preemptions 2 and 3 are used in the TE-domain
and that the following TE-Class mapping is configured on LSR1 and
LSR2:
i <---> CT preemption
====================================
0 CT1 0
1 CT1 1
2 CT0 2
3 CT0 3
rest unused
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は、BC0 = X0、BC1 = X1（おそらく= 0）、およびLINK01の最大予約可能帯域幅= M10（おそらく= M01）で構成されています。
In IGP for Link01, LSR0 will advertise:
Link01のIGPでは、LSR0が宣伝します。
- Max Reservable Bw sub-TLV = <m01>
- 最大予約可能BW Sub-TLV = <M01>
- Unreserved Bw sub-TLV = <CT0/0, CT0/1, CT0/2, CT0/3, CT0/4, CT0/5, CT0/6, CT0/7>
- 予約されていないBW SUB-TLV = <CT0/0、CT0/1、CT0/2、CT0/3、CT0/4、CT0/5、CT0/6、CT0/7>
On receipt of such advertisement, LSR1 will:
そのような広告を受け取ったとき、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
- LSR0は、最大予約可能なBW Sub-TLVを宣伝し、帯域幅の制約Sub-TLVを宣伝したため、DS-TE対応ではないことを理解してください。
- 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.
- CT0 LSPのみがLSR0を介して輸送できると結論付けており、値CT0/2とCT0/3のみが予約されていないBW Sub-TLVで意味があると結論付けています。LSR1は、予約されていないBWサブTLVに含まれる他の6つの値がゼロに設定されているかのように効果的に動作する場合があります。
In IGP for Link01, LSR1 will advertise:
Link01のIGPでは、LSR1が宣伝します。
- Max Reservable Bw sub-TLV = <m10>
- 最大予約可能BW Sub-TLV = <M10>
- Bandwidth Constraints sub-TLV = <BC Model ID, x0, x1>
- 帯域幅の制約sub-tlv = <bcモデルid、x0、x1>
- Unreserved Bw sub-TLV = <CT1/0, CT1/1, CT0/2, CT0/3, 0, 0, 0, 0>
- 予約されていないBW SUB-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
- 予約されていないBW Sub-TLVでCT0/2と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 Sub-TLVに含まれる他の値は、CT0の他の先制優先事項に関連していると誤って信じています。しかし、TEドメインではプリエンプション2と3のみが使用されていると想定しているため、実際にはそれらを使用することはありません。
Normative References
引用文献
[DSTE-REQ] Le Faucheur, F. and W. Lai, "Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering", RFC 3564, July 2003.
[DSTE-REQ] Le Faucheur、F。およびW. Lai、「差別化されたサービス認識MPLSトラフィックエンジニアリングのサポートの要件」、RFC 3564、2003年7月。
[MPLS-ARCH] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[MPLS-ARCH] Rosen、E.、Viswanathan、A。and R. Callon、「Multiprotocol Label Switching Architecture」、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.、Malcolm、J.、Agogbua、J.、O'Dell、M.、J。McManus、「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.
[OSPF-TE] Katz、D.、Kompella、K。、およびD. Yeung、「Traffic Engineering（TE）拡張機能への拡張」、RFC 3630、2003年9月。
[ISIS-TE] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004.
[ISIS-TE] Smit、H。およびT. Li、「トラフィックエンジニアリングの中間システム（IS-IS）拡張（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.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：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] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（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] Le Faucheur、F.、Wu、L.、Davie、B.、Davari、S.、Vaananen、P.、Krishnan、R.、Cheval、P。and J. Heinanen、 "Multi-Protocol Label差別化されたサービスの切り替え（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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z。、およびW. Weiss、「差別化されたサービスのアーキテクチャ」、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] Le Faucheur、f。、ed。、「Diffserv-aware 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] Le Faucheur、F。およびW. Lai、「Diffserv-Aware Traffice Engineeringの最大割り当て帯域幅制約モデル」、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] Ash、J。、「Diffserv-akeare MPLSトラフィックエンジニアリングとパフォーマンスの比較のための予約帯域幅制約モデルによる最大割り当て」、RFC 4126、2005年6月。
[GMPLS-SIG] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[GMPLS-SIG] Berger、L。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナル伝達機能説明」、RFC 3471、2003年1月。
[GMPLS-ROUTE] Kompella, et al., "Routing Extensions in Support of Generalized MPLS", Work in Progress.
[Gmpls-route] Kompella、et al。、「一般化されたMPLSをサポートするルーティング拡張機能」、進行中の作業。
[BUNDLE] Kompella, Rekhter, Berger, "Link Bundling in MPLS Traffic Engineering", Work in Progress.
[バンドル] Kompella、Rekhter、Berger、「MPLS Traffic Engineeringのリンクバンドリング」、進行中の作業。
[HIERARCHY] Kompella, Rekhter, "LSP Hierarchy with Generalized MPLS TE", Work in Progress.
[階層] Kompella、Rekhter、「一般化されたMPLS TEを備えたLSP階層」、進行中の作業。
[REROUTE] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[Reroute] Pan、P.、Swallow、G。、およびA. Atlas、「LSPトンネルのRSVP-TEへの高速拡張式」、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
Francois Le Faucheur Cisco Systems、Inc。Village D'Entreprise Green Side -Batiment T3 400、Avenue de Roumanille 06410 Biot -Sophia Antipolis France
Phone: +33 4 97 23 26 19
EMail: flefauch@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。