Networking Working Group JP. Vasseur, Ed.
Request for Comments: 5152 Cisco Systems, Inc.
Category: Standards Track A. Ayyangar, Ed.
Juniper Networks
R. Zhang
BT
February 2008
A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)
ドメイン間トラフィックエンジニアリング（TE）ラベルを確立するためのドメイン単位のパス計算方法は、スイッチパス（LSP）
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）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
This document specifies a per-domain path computation technique for establishing inter-domain Traffic Engineering (TE) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths (LSPs). In this document, a domain refers to a collection of network elements within a common sphere of address management or path computational responsibility such as Interior Gateway Protocol (IGP) areas and Autonomous Systems.
この文書では、ドメイン間トラフィックエンジニアリング（TE）マルチプロトコルラベルスイッチング（MPLS）と一般化MPLS（GMPLS）をラベル（LSPを）パスを確立するためのスイッチドメインごとの経路計算手法を指定します。この文書では、ドメインは、内部ゲートウェイプロトコル（IGP）領域と自律システム、アドレス管理や経路計算責任の共通球体内のネットワーク要素の集合を指します。
Per-domain computation applies where the full path of an inter-domain TE LSP cannot be or is not determined at the ingress node of the TE LSP, and is not signaled across domain boundaries. This is most likely to arise owing to TE visibility limitations. The signaling message indicates the destination and nodes up to the next domain boundary. It may also indicate further domain boundaries or domain identifiers. The path through each domain, possibly including the choice of exit point from the domain, must be determined within the domain.
ドメイン間のTE LSPのフルパスができないか、またはTE LSPの入口ノードで決定されておらず、ドメインの境界を越えてシグナリングされない場合あたりドメイン計算が適用されます。これは、TEの可視性の制限のために発生する可能性が最も高いです。シグナリングメッセージは、宛先を示し、次のドメインの境界ノードまで。また、さらにドメイン境界またはドメイン識別子を示すかもしれません。各ドメインを通る経路は、おそらくドメインからの出口点の選択を含む、ドメイン内で決定されなければなりません。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................3
2.1. Requirements Language ......................................4
3. General Assumptions .............................................4
3.1. Common Assumptions .........................................4
3.2. Example of Topology for the Inter-Area TE Case .............6
3.3. Example of Topology for the Inter-AS TE Case ...............7
4. Per-Domain Path Computation Procedures ..........................8
4.1. Example with an Inter-Area TE LSP .........................11
4.1.1. Case 1: T0 Is a Contiguous TE LSP ..................11
4.1.2. Case 2: T0 Is a Stitched or Nested TE LSP ..........12
4.2. Example with an Inter-AS TE LSP ...........................13
4.2.1. Case 1: T1 Is a Contiguous TE LSP ..................13
4.2.2. Case 2: T1 Is a Stitched or Nested TE LSP ..........14
5. Path Optimality/Diversity ......................................14
6. Reoptimization of an Inter-Domain TE LSP .......................15
6.1. Contiguous TE LSPs ........................................15
6.2. Stitched or Nested (non-contiguous) TE LSPs ...............16
6.3. Path Characteristics after Reoptimization .................17
7. Security Considerations ........................................17
8. Acknowledgements ...............................................18
9. References .....................................................18
9.1. Normative References ......................................18
9.2. Informative References ....................................18
The requirements for inter-domain Traffic Engineering (inter-area and inter-AS TE) have been developed by the Traffic Engineering Working Group and have been stated in [RFC4105] and [RFC4216]. The framework for inter-domain MPLS Traffic Engineering has been provided in [RFC4726].
ドメイン間トラフィックエンジニアリング（エリア間および相互AS TE）のための要件は、トラフィックエンジニアリングワーキンググループによって開発され、[RFC4105]と[RFC4216]に記載されています。ドメイン間MPLSトラフィックエンジニアリングのためのフレームワークは、[RFC4726]で提供されています。
Some of the mechanisms used to establish and maintain inter-domain TE LSPs are specified in [RFC5151] and [RFC5150].
ドメイン間TE LSPを確立し、維持するために使用されるメカニズムの一部は、[RFC5151]と[RFC5150]で指定されています。
This document exclusively focuses on the path computation aspects and defines a method for establishing inter-domain TE LSPs where each node in charge of computing a section of an inter-domain TE LSP path is always along the path of such a TE LSP.
この文書では、排他的に経路計算の側面に焦点を当て、ドメイン間のTE LSPパスの部分を計算する担当の各ノードは、TE LSPの経路に沿って常にドメイン間のTE LSPを確立するための方法を定義します。
When the visibility of an end-to-end complete path spanning multiple domains is not available at the Head-end LSR (the LSR that initiated the TE LSP), one approach described in this document consists of using a per-domain path computation technique during LSP setup to determine the inter-domain TE LSP as it traverses multiple domains.
複数のドメインにまたがるエンド・ツー・エンドの完全なパスの視認性がヘッドエンドLSR（TE LSPを開始LSR）で利用可能でない場合、本文書に記載の一つのアプローチはあたりドメイン経路計算技術を使用することからなりますそれは複数のドメインを横断するようにLSPセットアップ時にドメイン間TE LSPを決定します。
The mechanisms proposed in this document are also applicable to MPLS TE domains other than IGP areas and ASs.
この文書で提案されているメカニズムもIGP領域とお尻以外のMPLS TEドメインに適用可能です。
The solution described in this document does not attempt to address all the requirements specified in [RFC4105] and [RFC4216]. This is acceptable according to [RFC4216], which indicates that a solution may be developed to address a particular deployment scenario and might, therefore, not meet all requirements for other deployment scenarios.
この文書で説明するソリューションは、[RFC4105]と[RFC4216]で指定されたすべての要件に対処しようとしません。これは、溶液は、特定の展開シナリオに対処するために開発されてもよく、したがって、他の展開シナリオのためのすべての要件を満たしていない可能性があることを示している[RFC4216]に記載の許容されます。
It must be pointed out that the inter-domain path computation technique proposed in this document is one among many others. The choice of the appropriate technique must be driven by the set of requirements for the path attributes and the applicability to a particular technique with respect to the deployment scenario. For example, if the requirement is to get an end-to-end constraint-based shortest path across multiple domains, then a mechanism using one or more distributed PCEs could be used to compute the shortest path across different domains (see [RFC4655]). Other off-line mechanisms for path computation are not precluded either. Note also that a Service Provider may elect to use different inter-domain path computation techniques for different TE LSP types.
この文書で提案されているドメイン間経路計算手法は、他の多くの中の1つであることを指摘しなければなりません。適切な技術の選択は、パス属性と展開シナリオに関して特定の技術への適用のための要件のセットによって駆動されなければなりません。要求が複数のドメインにわたるエンドツーエンドの制約ベースの最短パスを取得する場合、例えば、1つのまたは複数の分散のPCEを用いた機構は、異なるドメイン間の最短経路を計算するために使用することができる（[RFC4655]を参照） 。経路計算のための他のオフライン機構は、いずれかの除外されません。サービスプロバイダは、異なるTE LSPタイプの異なるドメイン間経路計算技術を使用することを選択することができることにも留意されたいです。
Terminology used in this document:
このドキュメントで使用される用語：
AS: Autonomous System.
AS：自律システム。
ABR: Area Border Router, a router used to connect two IGP areas (areas in OSPF or levels in Intermediate System to Intermediate System (IS-IS)).
ABR：エリア境界ルータ、（中間システム（IS-IS）に中間システムにOSPF内の領域またはレベル）2 IGP領域を接続するために使用されるルータ。
ASBR: Autonomous System Border Router, a router used to connect together ASs of a different or the same Service Provider via one or more inter-AS links.
ASBR：自律システム境界ルータ、一つ以上のAS間リンクを介して異なるまたは同じサービスプロバイダーのお尻一緒に接続するために使用されるルータ。
Boundary LSR: A boundary LSR is either an ABR in the context of inter-area TE or an ASBR in the context of inter-AS TE.
境界LSR：境界LSRは、エリア間TEの文脈におけるABRまたはインターAS TEの文脈でASBRのいずれかです。
ERO: Explicit Route Object.
ERO：明示的なルートオブジェクト。
IGP: Interior Gateway Protocol.
IGP：インテリアゲートウェイプロトコル。
Inter-AS TE LSP: A TE LSP that crosses an AS boundary.
インターAS TE LSP：TE LSP AS境界を越えます。
Inter-area TE LSP: A TE LSP that crosses an IGP area.
インターエリアTE LSP：TE LSP IGPエリアを横切ります。
LSR: Label Switching Router.
LSR：ラベルスイッチングルータ。
LSP: Label Switched Path.
LSP：ラベルスイッチパス。
TE LSP: Traffic Engineering Label Switched Path.
TE LSP：トラフィックエンジニアリングラベルスイッチパス。
PCE: Path Computation Element, an entity (component, application, or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints.
PCE：パス計算エレメント、ネットワークグラフに基づいてネットワークパスまたはルートを計算し、計算上の制約を適用することが可能なエンティティ（コンポーネント、アプリケーション、またはネットワークノード）。
TED: Traffic Engineering Database.
TED：トラフィックエンジニアリングデータベース。
The notion of contiguous, stitched, and nested TE LSPs is defined in [RFC4726] and will not be repeated here.
、連続したステッチ、およびネストされたTE LSPの概念は、[RFC4726]で定義され、ここでは繰り返しません。
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 RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
- Each domain in all the examples below is assumed to be capable of doing Traffic Engineering (i.e., running OSPF-TE or ISIS-TE and RSVP-TE (Resource Reservation Protocol Traffic Engineering)). A domain may itself comprise multiple other domains, e.g., an AS may itself be composed of several other sub-ASs (BGP confederations) or areas/levels. In this case, the path computation technique described for inter-area and inter-AS MPLS Traffic Engineering applies recursively.
- 以下トラヒックエンジニアリングを行うことができることが想定されるすべての実施例の各ドメイン（すなわち、OSPF-TEまたはISIS-TEおよびRSVP-TE（リソース予約プロトコル・トラフィック・エンジニアリング）を実行しています）。ドメイン自体はAS自体がいくつかの他のサブのAS（BGPの連合）または領域/レベルで構成することができる、例えば、他の複数のドメインを含むことができます。この場合、経路計算技術がインター領域と相互AS MPLSトラフィックエンジニアリングのために記載を再帰的に適用されます。
- The inter-domain TE LSPs are signaled using RSVP-TE ([RFC3209] and [RFC3473]).
- ドメイン間TE LSPは、RSVP-TE（[RFC3209]及び[RFC3473]）を使用してシグナリングされます。
- The path (specified by an ERO (Explicit Route Object) in an RSVP-TE Path message) for an inter-domain TE LSP may be signaled as a set of (loose and/or strict) hops.
- （ルーズ及び/又は厳密）のセットはホップとしてドメイン間TE LSPのための（RSVP-TE PathメッセージにERO（明示的経路オブジェクト）によって指定された）パスをシグナリングすることができます。
- The hops may identify:
- ホップが識別することができます。
* The complete strict path end-to-end across different domains
*完全な厳密なパスは、エンドツーエンドの異なるドメイン間
* The complete strict path in the source domain followed by boundary LSRs (or domain identifiers, e.g., AS numbers)
（例えば、数値として、またはドメイン識別子）境界のLSR続いてソースドメイン内*完全厳密パス
* The complete list of boundary LSRs along the path
*パスに沿った境界のLSRの完全なリスト
* The current boundary LSR and the LSP destination
*現在の境界LSRとLSP先
The set of (loose or strict) hops can be either statically configured on the Head-end LSR or dynamically computed. A per-domain path computation method is defined in this document with an optional auto-discovery mechanism (e.g., based on IGP, BGP, policy routing information) yielding the next-hop boundary node (domain exit point, such as an Area Border Router (ABR) or an Autonomous System Border Router (ASBR)) along the path as the TE LSP is being signaled, along with potential crankback mechanisms. Alternatively, the domain exit points may be statically configured on the Head-end LSR, in which case next-hop boundary node auto-discovery would not be required.
（ルーズ又は厳密）のセットは、静的ヘッドエンドLSRに構成されるか、または動的に計算することができるホップ。毎ドメイン経路計算方法は、オプションの自動検出機構と、この文書で定義されている（例えば、IGP、BGP、ポリシールーティング情報に基づいて）、そのようなエリア境界ルータとしてネクストホップ境界ノードを得た（ドメインの出口点、 TE LSPとして、パスに沿って（ABR）または自律システム境界ルータ（ASBR））は、潜在的なクランクバック機構と共に、シグナリングされています。あるいは、ドメインの出口点は、静的ネクストホップ境界ノード自動検出が必要とされないであろうその場合、ヘッドエンドLSR、上に構成されてもよいです。
- Boundary LSRs are assumed to be capable of performing local path computation for expansion of a loose next hop in the signaled ERO if the path is not signaled by the Head-end LSR as a set of strict hops or if the strict hop is an abstract node (e.g., an AS). In any case, no topology or resource information needs to be distributed between domains (as mandated per [RFC4105] and [RFC4216]), which is critical to preserve IGP/BGP scalability and confidentiality in the case of TE LSPs spanning multiple routing domains.
- 厳密ホップが抽象である場合は、パスを厳密ホップのセットとしてヘッドエンドLSRによって合図されているかどうか境界のLSRは、シグナリングEROに緩い次のホップの拡張のために局所経路計算を行うことが可能であると仮定されていますノード（例えば、AS）。複数のルーティングドメインにまたがるのTE LSPの場合にIGP / BGPの拡張性と機密性を維持することが重要である、（[RFC4105]及び[RFC4216]あたりの義務として）いずれの場合においても、いかなるトポロジーまたはリソース情報は、ドメイン間に分布する必要はありません。
- The paths for the intra-domain Hierarchical LSP (H-LSP) or Stitched LSP (S-LSP) or for a contiguous TE LSP within the domain may be pre-configured or computed dynamically based on the arriving inter-domain LSP setup request (depending on the requirements of the transit domain). Note that this capability is explicitly specified as a requirement in [RFC4216]. When the paths for the H-LSP/S-LSP are pre-configured, the constraints as well as other parameters like a local protection scheme for the intra-domain H-LSP/S-LSP are also pre-configured.
- ドメイン内LSP階層（H-LSP）またはステッチLSP（S-LSP）またはドメイン内の連続TE LSPのためのパスが事前構成または計算することができる動的到着ドメイン間LSP設定要求に基づいて（トランジットドメインの要件に応じて）。この機能を明示的に[RFC4216]で要件として指定されていることに注意してください。 H-LSP / S-LSPのためのパスが事前に設定されている場合、制約ならびにドメイン内H-LSP / S-LSPのローカル保護スキームのような他のパラメータもまた、事前に設定されています。
- While certain constraints like bandwidth can be used across different domains, certain other TE constraints like resource affinity, color, metric, etc. as listed in [RFC2702] may need to be translated at domain boundaries. If required, it is assumed that, at the domain boundary LSRs, there will exist some sort of local mapping based on policy agreement in order to translate such constraints across domain boundaries. It is expected that such an assumption particularly applies to inter-AS TE: for example, the local mapping would be similar to the inter-AS TE agreement enforcement polices stated in [RFC4216].
- [RFC2702]に記載されている帯域幅のような特定の制約が異なるドメインなどのリソース親和性、色、メトリック、のような他の特定のTE制約にまたがって使用することができるが、ドメイン境界で換算する必要があるかもしれません。必要な場合は、ドメイン境界のLSRで、ドメインの境界を越えて、このような制約を翻訳するための政策合意に基づくローカルマッピングのいくつかの並べ替えが存在するだろう、と仮定されます。このような仮定は、特にインターAS TEに適用されることが期待されている：例えば、ローカルマッピングは、[RFC4216]に記載されている間AS TE契約執行ポリシーと同様です。
- The procedures defined in this document are applicable to any node (not just a boundary node) that receives a Path message with an ERO that constrains a loose hop or an abstract node that is not a simple abstract node (that is, an abstract node that identifies more than one LSR).
- 本文書で定義された手順は、ルーズホップまたは単純な抽象ノード（すなわち、抽象ノードではない抽象ノードを制約EROとPathメッセージを受信する任意のノード（だけでなく、境界ノード）に適用可能ですそれは）複数のLSRを識別します。
The following example will be used for the inter-area TE case in this document.
次の例では、この文書に記載されている間領域TEの場合に使用されます。
<-area 1-><-- area 0 --><--- area 2 --->
------ABR1------------ABR3-------
| / | | \ |
R0--X1 | | X2---X3--R1
| | | / |
------ABR2-----------ABR4--------
<=========== Inter-area TE LSP =======>
Figure 1 - Example of topology for the inter-area TE case
図1 - インターエリアTEの場合のトポロジーの例
Description of Figure 1:
図1の説明：
- ABR1, ABR2, ABR3, and ABR4 are ABRs. - X1 is an LSR in area 1. - X2 and X3 are LSRs in area 2. - An inter-area TE LSP T0 originated at R0 in area 1 and terminated at R1 in area 2.
- ABR1、ABR2、ABR3、およびABR4はのABRです。 - X1は、LSRは、エリア1にあり - X2及びX3は領域2でのLSRである - インターエリアTE LSP T0が領域1にR0で発生し、領域2においてR1で終了します。
Notes:
ノート：
- The terminology used in the example above corresponds to OSPF, but the path computation technique proposed in this document equally applies to the case of an IS-IS multi-level network.
- 実施例で使用される用語は、上記OSPFに対応するが、本文書で提案されている経路計算技術は、均等IS-ISマルチレベルネットワークの場合に適用されます。
- Just a few routers in each area are depicted in the diagram above for the sake of simplicity.
- 各領域におけるわずか数ルータは、簡略化のため、上記の図に示されています。
- The example depicted in Figure 1 shows the case where the Head-end and Tail-end areas are connected by means of area 0. The case of an inter-area TE LSP between two IGP areas that does not transit through area 0 is not precluded.
- 図1に示す例では、ヘッドエンドとテールエンド領域はエリア0の領域を通って遷移しない2つのIGP領域間の相互領域TE LSPの場合により連結されている場合を示して0ではありません排除。
We consider the following general case, built on a superset of the various scenarios defined in [RFC4216]:
私たちは、[RFC4216]で定義された様々なシナリオのスーパーセット上に構築され、以下の一般的なケースを考えてみます。
<-- AS1 ----> <------- AS2 ------><--- AS3 ----->
<---BGP---> <---BGP-->
CE1---R0---X1-ASBR1-----ASBR4--R3---ASBR7----ASBR9----R6
|\ \ | / | / | / | | |
| \ ASBR2---/ ASBR5 | -- | | |
| \ | | |/ | | |
R1-R2---ASBR3-----ASBR6--R4---ASBR8----ASBR10---R7---CE2
<======= Inter-AS TE LSP (LSR to LSR)===========>
or
<======== Inter-AS TE LSP (CE to ASBR) =>
<========インターAS TE LSP（ASBRにCE）=>
or
または
<================= Inter-AS TE LSP (CE to CE)===============>
Figure 2 - Example of topology for the inter-AS TE case
図2 - インターAS TEの場合のトポロジーの例
The diagram depicted in Figure 2 covers all the inter-AS TE deployment cases described in [RFC4216].
図2に示す図は、[RFC4216]に記載されているすべてのインターAS TE展開ケースをカバーします。
Description of Figure 2:
図2の説明：
- Three interconnected ASs, respectively AS1, AS2, and AS3. Note that in some scenarios described in [RFC4216] AS1=AS3.
- 三つの相互接続されたASの、それぞれAS1、AS2、およびAS3。いくつかのシナリオでは[RFC4216] AS1 = AS3に記載ことに留意されたいです。
- The ASBRs in different ASs are BGP peers. There is usually no IGP running on the single hop links interconnecting the ASBRs and also referred to as inter-ASBR links.
- 異なるAS内のASBRは、BGPピアです。 ASBRを相互接続し、またインターASBRリンクと呼ばれる単一ホップのリンク上で実行中のIGPは、通常はありません。
- Each AS runs an IGP (IS-IS or OSPF) with the required IGP TE extensions (see [RFC3630], [RFC3784], [RFC4203] and [RFC4205]). In other words, the ASs are TE enabled.
- 必要な各IGP TE拡張子を持つIGP（IS-ISまたはOSPF）を実行すると（参照[RFC3630]、[RFC3784]、[RFC4203]及び[RFC4205]）。つまり、お尻TEが有効になっています。
- CE: Customer Edge router.
- CE：カスタマーのエッジルータ。
- Each AS can be made of several IGP areas. The path computation technique described in this document applies to the case of a single AS made of multiple IGP areas, multiple ASs made of a single IGP area, or any combination of the above. For the sake of simplicity, each routing domain will be considered as a single area in this document. The case of an inter-AS TE LSP spanning multiple ASs where some of those ASs are themselves made of multiple IGP areas can be easily derived from the examples above: the per-domain path computation technique described in this document is applied recursively in this case.
- 各ASは、複数のIGP領域で構成することができます。複数のIGP領域、単一のIGP領域、または上記の任意の組み合わせからなる複数のASからなるこのドキュメントに記載さ経路計算技術は、単一のケースにも適用されます。簡略化のため、各ルーティングドメインは、この文書に記載されている単一の領域として考えます。それらのASのいくつかは、それ自体が容易に、上記実施例から導出することができる複数のIGP領域で形成されている複数のASにまたがるインターAS TE LSPの場合：この文書に記載さ当たりドメイン経路計算手法は、この場合、再帰的に適用されます。
- An inter-AS TE LSP T1 originated at R0 in AS1 and terminated at R6 in AS3.
- 相互AS TE LSP T1は、AS1にR0で発生し、AS3でR6で終了します。
The mechanisms for inter-domain TE LSP computation as described in this document can be used regardless of the nature of the inter-domain TE LSP (contiguous, stitched, or nested).
この文書に記載されているようにドメイン間TE LSP計算のための機構に関係なく、ドメイン間TE LSP（連続縫合、またはネストされた）の性質を用いることができます。
Note that any path can be defined as a set of loose and strict hops. In other words, in some cases, it might be desirable to rely on the dynamic path computation in some domains, and exert a strict control on the path in other domains (defining strict hops).
いずれかのパスが緩いと厳密ホップのセットとして定義することができることに留意されたいです。換言すれば、いくつかのケースでは、いくつかのドメインにおける動的経路計算に依存して、および（厳密ホップを規定する）は、他のドメイン内経路上の厳密な制御を発揮することが望ましいかもしれません。
When an LSR that is a boundary node such as an ABR/ASBR receives a Path message with an ERO that contains a strict node, the procedures specified in [RFC3209] apply and no further action is needed.
このようなABR / ASBRとして境界ノードであるLSRが厳密ノードを含むEROとPathメッセージを受信した場合、[RFC3209]で指定された手順が適用され、それ以上のアクションは必要ありません。
When an LSR that is a boundary node such as an ABR/ASBR receives a Path message with an ERO that contains a loose hop or an abstract node that is not a simple abstract node (that is, an abstract node that identifies more than one LSR), then it MUST follow the procedures as described in [RFC5151].
このようなABR / ASBRとして境界ノードであるLSRが緩んホップまたは単純な抽象ノード（つまり、複数のLSRを識別する抽象ノードではない抽象ノードを含むEROとPathメッセージを受信した場合[RFC5151]に記載されているように）、それは手順に従わなければなりません。
In addition, the following procedures describe the path computation procedures that SHOULD be carried out on the LSR:
また、次の手順では、LSRに行うべき経路計算手順について説明します。
1) If the next hop is not present in the TED, the two following conditions MUST be checked:
次ホップがTEDに存在しない場合1）、次の二つの条件をチェックしなければなりません。
o Whether the IP address of the next-hop boundary LSR is outside of the current domain
O LSR境界ネクストホップのIPアドレスは、現在のドメインの外にあるかどうか
o Whether the next-hop domain is PSC (Packet Switch Capable) and uses in-band control channel
ネクストホップドメインは、PSC（パケットは対応スイッチ）であり、インバンド制御チャネルを使用するかどうか、O
If the two conditions above are satisfied, then the boundary LSR SHOULD check if the next hop has IP reachability (via IGP or BGP). If the next hop is not reachable, then a signaling failure occurs and the LSR SHOULD send back an RSVP PathErr message upstream with error code=24 ("Routing Problem") and error subcode as described in section 4.3.4 of [RFC3209]. If the available routing information indicates
上記2つの条件が満たされている場合、次のホップが（IGPまたはBGPを介して）IP到達可能性を持っている場合、境界LSRが確認する必要があります。ネクストホップが到達可能でない場合、シグナリング障害が発生し、[RFC3209]のセクション4.3.4に記載したようにLSRは、エラーコード= 24（「ルーティング問題」）、エラーサブコード上流のRSVPのPathErrメッセージを返すべきです。利用可能なルーティング情報を示している場合
that next hop is reachable, the selected route will be expected to pass through a domain boundary via a domain boundary LSR. The determination of domain boundary point based on routing information is what we term as "auto-discovery" in this document. In the absence of such an auto-discovery mechanism, a) the ABR in the case of inter-area TE or the ASBR in the next-hop AS in the case of inter-AS TE should be the signaled loose next hop in the ERO and hence should be accessible via the TED, or b) there needs to be an alternate scheme that provides the domain exit points. Otherwise, the path computation for the inter-domain TE LSP will fail.
ネクストホップが到達可能であることを、選択されたルートは、ドメイン境界LSRを介してドメイン境界を通過することが予想されるであろう。ルーティング情報に基づいてドメイン境界点の決意があり、この文書の「自動検出」として私たち用語。このような自動検出メカニズムの非存在下で、a）はインターAS TEの場合のように次のホップで相互領域TEまたはASBRの場合のABRは、EROにおけるシグナリング緩いネクストホップであるべきですしたがってTEDを介してアクセスすること、またはb）ドメイン出口ポイントを提供する代替案が必要であるべきです。それ以外の場合は、ドメイン間TE LSPのための経路計算が失敗します。
An implementation MAY support the ability to disable such an IP reachability fall-back option should the next-hop boundary LSR not be present in the TED. In other words, an implementation MAY support the possibility to trigger a signaling failure whenever the next hop is not present in the TED.
ネクストホップ境界LSRがTEDに存在してはならない実装では、IP到達可能性フォールバックオプションを無効にする機能をサポートするかもしれません。換言すれば、実装は次のホップがTEDに存在しないときはいつでもシグナリング障害を誘発する可能性をサポートするかもしれません。
2) Once the next-hop boundary LSR has been determined (according to the procedure described in 1)) or if the next-hop boundary is present in the TED:
2）いったん次ホップ境界LSRは、1）に記載の手順に従って、（決定された）、またはネクストホップ境界は、TED中に存在する場合：
o Case of a contiguous TE LSP. Unless not allowed by policy, the boundary LSR that processes the ERO SHOULD perform an ERO expansion (a process consisting of computing the constrained path up to the next loose hop and adding the list of hops as strict nodes in the ERO). If no path satisfying the set of constraints can be found, then this is treated as a path computation and signaling failure and an RSVP PathErr message SHOULD be sent for the inter-domain TE LSP based on section 4.3.4 of [RFC3209].
連続したTE LSPのOケース。ポリシーで許可されていない場合を除き、EROを処理する境界LSRはERO拡張（次のルーズホップに制約パスを計算し、EROに厳密ノードとしてホップのリストを追加することからなるプロセス）を実行しなければなりません。制約のセットを満足するパスが見つからない場合、これは経路計算として処理し、不良とのRSVPのPathErrメッセージをシグナリングされる[RFC3209]のセクション4.3.4に基づいてドメイン間TE LSPのために送信されるべきです。
o Case of a stitched or nested TE LSP
ステッチまたはネストされたTE LSPのoケース
* If the boundary LSR is a candidate LSR for intra-area H-LSP/ S-LSP setup (the boundary has local policy for nesting or stitching), the TE LSP is a candidate for hierarchy/nesting (the "Contiguous LSP" bit defined in [RFC5151] is not set), and if there is no H-LSP/S-LSP from this LSR to the next-hop boundary LSR that satisfies the constraints, it SHOULD signal an H-LSP/S-LSP to the next-hop boundary LSR. If a pre-configured H-LSP(s) or S-LSP(s) already exists, then it will try to select from among those intra-domain LSPs. Depending on local policy, it MAY signal a new H-LSP/S-LSP if this selection fails. If the H-LSP/S-LSP is successfully signaled or selected, it propagates the inter-domain Path message to the next hop following the procedures described in [RFC5151]. If for some reason the dynamic H-LSP/S-LSP setup to the next-hop boundary LSR fails, then this SHOULD be treated as a path computation and signaling failure and an RSVP PathErr message SHOULD be sent upstream for the inter-domain LSP. Similarly, if selection of a pre-configured H-LSP/S-LSP fails and local policy prevents dynamic H-LSP/S, this SHOULD be treated as a path computation and signaling failure and an RSVP PathErr message SHOULD be sent upstream for the inter-domain TE LSP. In both of these cases, procedures described in section 4.3.4 of [RFC3209] SHOULD be followed to handle the failure.
*境界LSRがイントラ領域H-LSP / S-LSPセットアップの候補LSR（境界がネストまたは縫合するためのローカルポリシーを持っている）である場合、TE LSPは（「連続LSP」ビットをネスト/階層の候補であります[RFC5151]に設定されていない）で定義され、およびNO H-LSP / S-LSPこのLSRからの制約を満足するネクストホップ境界LSRには存在しない場合、それはにH-LSP / S-LSPを通知すべきですネクストホップ境界LSR。事前に設定H-LSP（S）又はS-LSP（s）が既に存在する場合、それは、それらのドメイン内のLSPの中から選択するように試みます。この選択が失敗した場合、ローカルポリシーに応じて、それは新しいH-LSP / S-LSPをシグナリングすることができます。 H-LSP / S-LSPが正常にシグナリング、または選択された場合、それは[RFC5151]に記載の手順の次のホップへのドメイン間のPathメッセージを伝播します。何らかの理由でLSRが失敗境界ネクストホップへの動的H-LSP / S-LSPセットアップは、これが経路計算とシグナリング障害とのRSVPのPathErrメッセージとして扱われるべきである場合、ドメイン間LSPのために上流送ってください。事前に設定H-LSP / S-LSPの選択は失敗し、ローカルポリシーが動的H-LSP / Sできない場合同様に、これは、アップストリーム送信されるべきである経路計算とシグナリング障害とのRSVPのPathErrメッセージとして扱われるべきですドメイン間TE LSP。これらの場合の両方において、[RFC3209]のセクション4.3.4に記載された手順は、障害を処理するために従うことべきです。
* If, however, the boundary LSR is not a candidate for intra-domain H-LSP/S-LSP (the boundary LSR does not have local policy for nesting or stitching) or the TE LSP is not a candidate for hierarchy/nesting (the "Contiguous LSP" bit defined in [RFC5151] is set), then it SHOULD apply the same procedure as for the contiguous case.
*しかし、境界LSRのための候補者ではない場合、ドメイン内H-LSP / S-LSP（境界LSRがネストまたは縫合するためのローカルポリシーを持っていない）またはTE LSPは、階層/ネストの候補ではありません（ [RFC5151]で定義される「連続LSP」ビットが設定されている）、それは連続した場合と同様の手順を適用すべきです。
The ERO of an inter-domain TE LSP may comprise abstract nodes such as ASs. In such a case, upon receiving the ERO whose next hop is an AS, the boundary LSR has to determine the next-hop boundary LSR, which may be determined based on the auto-discovery process mentioned above. If multiple ASBR candidates exist, the boundary LSR may apply some policies based on peering contracts that may have been pre-negotiated. Once the next-hop boundary LSR has been determined, a similar procedure as the one described above is followed.
ドメイン間のTE LSPのEROは、のASとして抽象ノードを含んでもよいです。このような場合には、その次ホップとしてあるEROを受信すると、境界LSRは、上述した自動検出プロセスに基づいて決定することができるLSR境界次のホップを決定しなければなりません。複数のASBR候補が存在する場合は、境界LSRは、事前に交渉していたかもしれ契約をピアリングに基づいて、いくつかのポリシーを適用することができます。 LSR境界次のホップが決定されると、上述したものと同様の手順に従います。
Note the following related to the inter-AS TE case:
相互AS TEケースに関連する次の点に注意してください：
In terms of computation of an inter-AS TE LSP path, an interesting optimization technique consists of allowing the ASBRs to flood the TE information related to the inter-ASBR link(s) although no IGP TE is enabled over those links (and so there is no IGP adjacency over the inter-ASBR links). This of course implies that the inter-ASBR links be TE-enabled although no IGP is running on those links.
インターAS TE LSPパスの計算の観点から、興味深い最適化手法にはIGP TEがそうそここれらのリンク上有効いない（としているが相互ASBRリンク（複数可）に関連するTE情報をフラッディングするのASBRを可能にするから成り）間ASBRリンク上で何のIGP隣接関係ではありません。もちろん、これは何のIGPは、それらのリンク上で実行されていないが、インターASBRリンクがTE-有効であることを意味します。
<-- AS1 ----> <------- AS2 ------><--- AS3 ----->
<---BGP---> <---BGP-->
CE1---R0---X1-ASBR1-----ASBR4--R3---ASBR7----ASBR9----R6
|\ \ | / | / | / | | |
| \ ASBR2---/ ASBR5 | -- | | |
| \ | | |/ | | |
R1-R2---ASBR3-----ASBR6--R4---ASBR8----ASBR10---R7---CE2
Figure 3 - Flooding of the TE-related information for the inter-ASBR links
図3 - インターASBRリンクのTE関連情報の洪水
Referring to Figure 3, ASBR1 for example would advertise in its OSPF Link State Advertisement (LSA)/IS-IS LSP the Traffic Engineering TLVs related to the link ASBR1-ASBR4.
図3を参照すると、例えばASBR1は、そのOSPFリンクステートアドバタイズメント（LSA）に広告を出すでしょう/リンクASBR1-ASBR4に関連するLSPトラフィックエンジニアリングのTLV-ISがIS。
This allows an LSR (could be the entry ASBR) in the previous AS to make a more appropriate route selection up to the entry ASBR in the immediately downstream AS taking into account the constraints associated with the inter-ASBR links. This reduces the risk of call setup failure due to inter-ASBR links not satisfying the inter-AS TE LSP set of constraints. Note that the TE information is only related to the inter-ASBR links: the TE LSA/LSP flooded by the ASBR includes not only the TE-enabled links contained in the AS but also the inter-ASBR links.
アカウントにインターASBRリンクに関連付けられた制約を取っASすぐ下流でのエントリーASBRへのより適切な経路選択アップをするために、これはLSRは以前に（エントリーASBRすることができる）ことができます。これは、制約の相互AS TE LSPセットを満たさない間ASBRリンクにコールセットアップの失敗のリスクを低減します。 TE情報のみ間ASBRリンクに関連していることに注意してください：ASBRによって浸水TE LSA / LSPはASに含まれるTE-有効リンクだけでなく、間ASBRリンクだけでなく、。
Note that no summarized TE information is leaked between ASs, which is compliant with the requirements listed in [RFC4105] and [RFC4216].
何の要約TE情報は、[RFC4105]と[RFC4216]に記載されている要件に準拠しているのASの間に漏洩しないことに注意してください。
For example, consider the diagram depicted in Figure 2: when ASBR1 floods its IGP TE LSA ((opaque LSA for OSPF)/LSP (TLV 22 for IS-IS)) in its routing domain, it reflects the reservation states and TE properties of the following links: X1-ASBR1, ASBR1-ASBR2, and ASBR1-ASBR4.
例えば、図2に示すダイアグラムを考える：ASBR1がルーティングドメインにそのIGP TE LSA（OSPF用（オペークLSA）/ LSP（IS-ISのためのTLV 22））をフラッディングするとき、それは予約状態とのTEの特性を反映しています以下のリンク：X1-ASBR1、ASBR1 - ASBR2、およびASBR1-ASBR4。
Thanks to such an optimization, the inter-ASBR TE link information corresponding to the links originated by the ASBR is made available in the TED of other LSRs in the same domain to which the ASBR belongs. Consequently, the path computation for an inter-AS TE LSP path can also take into account the inter-ASBR link(s). This will improve the chance of successful signaling along the next AS in case of resource shortage or unsatisfied constraints on inter-ASBR links, and it potentially reduces one level of crankback. Note that no topology information is flooded, and these links are not used in IGP SPF computations. Only the TE information for the outgoing links directly connected to the ASBR is advertised.
このような最適化のおかげで、ASBRによって発信リンクに対応する間ASBR TEリンク情報がASBRが属する同じドメイン内の他のLSRのTEDで利用できるようになります。したがって、インターAS TE LSPパスの経路計算をも考慮間ASBRリンク（単数または複数）をとることができます。これは、リソース不足またはインターASBRリンク上の不満制約の場合には次のASに沿って成功したシグナリングのチャンスを向上させる、それが潜在的にクランクバックの1つのレベルを低下させます。何のトポロジ情報があふれていないことに注意してください、そしてこれらのリンクは、IGP SPFの計算に使用されていません。直接ASBRに接続されている出力リンクのための唯一のTE情報が通知されます。
Note that an operator may decide to operate a stitched segment or 1-hop hierarchical LSP for the inter-ASBR link.
オペレータがインターASBRリンクのステッチセグメントまたは1ホップ階層LSPを動作することを決定することができることに留意されたいです。
The following example uses Figure 1 as a reference.
次の例は、参考として図1を使用します。
The Head-end LSR (R0) first determines the next-hop ABR (which could be manually configured by the user or dynamically determined by using the auto-discovery mechanism). R0 then computes the path to reach the selected next-hop ABR (ABR1) and signals the Path message. When the Path message reaches ABR1, it first determines the next-hop ABR from its area 0 along the LSP path (say, ABR3), either directly from the ERO (if for example the next-hop ABR is specified as a loose hop in the ERO) or by using the auto-discovery mechanism specified above.
ヘッドエンドLSR（R0）は、最初の（ユーザが手動で設定するか、動的に自動検出機構を使用することによって決定することができる）ネクストホップABRを決定します。 R0は、選択されたネクストホップABR（ABR1）に到達する経路を計算し、Pathメッセージを知らせます。 Pathメッセージは、ABR1に到達すると、それはまず、直接的ERO（例えばネクストホップABRはルーズホップのように指定されている場合のLSPパスに沿って、そのエリア0からネクストホップABR（例えば、ABR3）を決定しますERO）または上記で特定自動検出メカニズムを使用して。
- Example 1 (set of loose hops): R0-ABR1(loose)-ABR3(loose)-R1(loose)
- 実施例1（ルーズホップのセット）：R0-ABR1（ルーズ）-ABR3（ルース）-R1（ルース）
- Example 2 (mix of strict and loose hops): R0-X1-ABR1-ABR3(loose)-X2-X3-R1
- 実施例2（厳密及びルーズホップのミックス）：R0-X1-ABR1-ABR3（ルーズ）-X2-X3-R1
Note that a set of paths can be configured on the Head-end LSR, ordered by priority. Each priority path can be associated with a different set of constraints. It may be desirable to systematically have a last-resort option with no constraint to ensure that the inter-area TE LSP could always be set up if at least a TE path exists between the inter-area TE LSP source and destination. In case of setup failure or when an RSVP PathErr is received indicating that the TE LSP has suffered a failure, an implementation might support the possibility of retrying a particular path option a configurable amount of times (optionally with dynamic intervals between each trial) before trying a lower-priority path option.
パスのセットは、優先順位順に並べられ、ヘッドエンドLSRに構成することができることに留意されたいです。各優先経路は、制約の異なるセットに関連付けることができます。体系的に、少なくともTEパスは、エリア間TE LSPの送信元と宛先の間に存在する場合には、エリア間TE LSPを常に設定することができることを確保するための制約なしで最後の手段のオプションを有することが望ましいです。 TE LSPが故障したことを示すセットアップの失敗時やRSVPののPathErrを受信した場合に、実装はしようとする前に（必要に応じて、各試験の間の動的な間隔で）特定の経路オプションを時間の設定量を再試行の可能性をサポートするかもしれません優先順位の低いパスオプション。
Once it has computed the path up to the next-hop ABR (ABR3), ABR1 sends the Path message along the computed path. Upon receiving the Path message, ABR3 then repeats a similar procedure. If ABR3 cannot find a path obeying the set of constraints for the inter-area TE LSP, the signaling process stops and ABR3 sends a PathErr message to ABR1. Then ABR1 can in turn trigger a new path computation by selecting another egress boundary LSR (ABR4 in the example above) if crankback is allowed for this inter-area TE LSP (see [RFC4920]). If crankback is not allowed for that inter-area TE LSP or if ABR1 has been configured not to perform crankback, then ABR1 MUST stop the signaling process and MUST forward a PathErr up to the Head-end LSR (R0) without trying to select another ABR.
それは次のホップABR（ABR3）へのパスを計算した後、ABR1は、計算された経路に沿ってPathメッセージを送信します。 Pathメッセージを受信すると、ABR3は、同様の手順を繰り返します。 ABR3がインターエリアTE LSPの制約のセットに従うパスが見つからない場合、シグナリング処理が停止し、ABR3はABR1へのPathErrメッセージを送信します。次いでABR1は、次にクランクバックこの相互領域TE LSP（[RFC4920]を参照）のために許可されている場合、別の出口境界LSR（上記の例でABR4）を選択して、新しい経路計算をトリガすることができます。クランクバックがそのエリア間TE LSPのために許可されていない場合、またはABR1はクランクバックを実行しないように構成されている場合、ABR1は、シグナリングプロセスを停止する必要がありそして別のものを選択しようとすることなく、ヘッドエンドLSR（R0）へのPathErrを転送しなければなりませんABR。
The Head-end LSR (R0) first determines the next-hop ABR (which could be manually configured by the user or dynamically determined by using the auto-discovery mechanism). R0 then computes the path to reach the selected next-hop ABR and signals the Path message. When the Path message reaches ABR1, it first determines the next-hop ABR from its area 0 along the LSP path (say ABR3), either directly from the ERO (if for example the next-hop ABR is specified as a loose hop in the ERO) or by using an auto-discovery mechanism, specified above.
ヘッドエンドLSR（R0）は、最初の（ユーザが手動で設定するか、動的に自動検出機構を使用することによって決定することができる）ネクストホップABRを決定します。 R0は、選択されたネクストホップABRに到達する経路を計算し、Pathメッセージを知らせます。 Pathメッセージは、ABR1に到達すると、それはまず、直接的ERO（例えばネクストホップABRはルーズホップとして指定されている場合のLSPパス（ABR3を言う）に沿ってそのエリア0からネクストホップABRを決定しますERO）または上記で特定自動検出機構を使用することによって。
ABR1 then checks whether it has an H-LSP or S-LSP to ABR3 matching the constraints carried in the inter-area TE LSP Path message. If not, ABR1 computes the path for an H-LSP or S-LSP from ABR1 to ABR3 satisfying the constraint and sets it up accordingly. Note that the H-LSP or S-LSP could have also been pre-configured.
ABR1は、それが相互領域TE LSPのPathメッセージで運ばれた制約に一致ABR3にH-LSPまたはS-LSPを持っているかどうかをチェックします。そうでない場合、ABR1は、制約を満たすABR3へABR1からH-LSPまたはS-LSPのためのパスを計算し、それに応じて設定します。 H-LSPまたはS-LSPも、事前に設定されていることに留意されたいです。
Once ABR1 has selected the H-LSP/S-LSP for the inter-area LSP, using the signaling procedures described in [RFC5151], ABR1 sends the Path message for the inter-area TE LSP to ABR3. Note that irrespective of whether ABR1 does nesting or stitching, the Path message for the inter-area TE LSP is always forwarded to ABR3. ABR3 then repeats the exact same procedures. If ABR3 cannot find a path obeying the set of constraints for the inter-area TE LSP, ABR3 sends a PathErr message to ABR1. Then ABR1 can in turn either select another H-LSP/S-LSP to ABR3 if such an LSP exists or select another egress boundary LSR (ABR4 in the example above) if crankback is allowed for this inter-area TE LSP (see [RFC4920]). If crankback is not allowed for that inter-area TE LSP or if ABR1 has been configured not to perform crankback, then ABR1 forwards the PathErr up to the inter-area Head-end LSR (R0) without trying to select another egress LSR.
ABR1は、エリア間LSPのためのH-LSP / S-LSPを選択した後、[RFC5151]に記載のシグナリング手順を用いて、ABR1はABR3に相互領域TE LSPのためのPathメッセージを送信します。 ABR1ネスティング又はステッチ、エリア間TE LSPのためのPathメッセージが常にABR3に転送されないかどうかのかかわらずに注意してください。 ABR3は、まったく同じ処理を繰り返します。 ABR3は、エリア間TE LSPのための一連の制約に従う道を見つけることができない場合は、ABR3はABR1へのPathErrメッセージを送信します。次いでABR1は、順番に、そのようなLSPが存在する場合ABR3に別のH-LSP / S-LSPを選択するか、またはクランクバックこの相互領域TE LSPのために許可されている場合、別の出口境界LSR（上記の例でABR4）を選択するか（参照[RFC4920 ]）。クランクバックがそのエリア間TE LSPのためか、ABR1は、クランクバックを実行しないように設定されている場合は許可されていない場合は、ABR1は、別の出口LSRを選択しようとせずに、エリア間のヘッドエンドLSR（R0）へのPathErrを転送します。
The following example uses Figure 2 as a reference.
次の例は、参考として図2を用いています。
The path computation procedures for establishing an inter-AS TE LSP are very similar to those of an inter-area TE LSP described above. The main difference is related to the presence of inter-ASBR link(s).
インターAS TE LSPを確立するための経路計算手順は、TE LSPは、上述したエリア間のものと非常に類似しています。主な違いは、インターASBRリンク（単数または複数）の存在に関連しています。
The inter-AS TE path may be configured on the Head-end LSR as a set of strict hops, loose hops, or a combination of both.
インターAS TEパスは厳密ホップのセット、ルーズホップ、または両方の組み合わせとしてヘッドエンドLSRに構成されてもよいです。
- Example 1 (set of loose hops): ASBR4(loose)-ASBR9(loose)-R6(loose)
- 実施例1（ルーズホップのセット）：ASBR4（緩い）-ASBR9（ルース）-R 6（ルース）
- Example 2 (mix of strict and loose hops): R2-ASBR3-ASBR2-ASBR1-ASBR4-ASBR10(loose)-ASBR9-R6
- 実施例2（厳密及びルーズホップのミックス）：R2-ASBR3-ASBR2-ASBR1-ASBR4-ASBR10（ルーズ）-ASBR9-R6
In example 1 above, a per-AS path computation is performed, respectively on R0 for AS1, ASBR4 for AS2, and ASBR9 for AS3. Note that when an LSR has to perform an ERO expansion, the next hop either must belong to the same AS or must be the ASBR directly connected to the next hop AS. In this latter case, the ASBR reachability is announced in the IGP TE LSA/LSP originated by its neighboring ASBR. In example 1 above, the TE LSP path is defined as: ASBR4(loose)- ASBR9(loose)-R6(loose). This implies that R0 must compute the path from R0 to ASBR4, hence the need for R0 to get the TE reservation state related to the ASBR1-ASBR4 link (flooded in AS1 by ASBR1). In addition, ASBR1 must also announce the IP address of ASBR4 specified in T1's path configuration.
上記実施例1において、当たり-AS経路計算はASBR4 AS2ため、AS1のためにそれぞれR0に、実行され、およびAS3のためASBR9。 LSRはERO拡張を実行する必要がある場合、次のホップが同じASに属していなければならないか、または直接AS次のホップに接続されたASBRのいずれかでなければならないことに留意されたいです。この後者の場合では、ASBRの到達可能性は、その隣接ASBRによって発信IGP TE LSA / LSPに発表されています。 - ASBR9（緩い）-R 6（ルース）ASBR4（ルース）：上記実施例1において、TE LSPパスは以下のように定義されます。これは、R0は（ASBR1でAS1に浸水）ASBR1-ASBR4リンクに関連したTEの予約状態を取得するためにR0は、ASBR4にそれ故に必要性をR0からのパスを計算しなければならないことを意味します。また、ASBR1もT1のパス設定で指定ASBR4のIPアドレスを告知しなければなりません。
Once it has computed the path up to the next-hop ASBR, ASBR1 sends the Path message for the inter-area TE LSP to ASBR4 (supposing that ASBR4 is the selected next-hop ASBR). ASBR4 then repeats the exact same procedures. If ASBR4 cannot find a path obeying the set of constraints for the inter-AS TE LSP, then ASBR4 sends a PathErr message to ASBR1. Then ASBR1 can in turn either select another ASBR (ASBR5 in the example above) if crankback is allowed for this inter-AS TE LSP (see [RFC4920]), or if crankback is not allowed for that inter-AS TE LSP or if ASBR1 has been configured not to perform crankback, ABR1 stops the signaling process and forwards a PathErr up to the Head-end LSR (R0) without trying to select another egress LSR. In this case, the Head-end LSR can in turn select another sequence of loose hops, if configured. Alternatively, the Head-end LSR may decide to retry the same path; this can be useful in case of setup failure due to an outdated IGP TE database in some downstream AS. An alternative could also be for the Head-end LSR to retry the same sequence of loose hops after having relaxed some constraint(s).
それはネクストホップASBRへの経路を計算した後、ASBR1は（ASBR4が選択された次のホップASBRであると仮定）ASBR4に相互領域TE LSPのためのPathメッセージを送信します。 ASBR4は、まったく同じ処理を繰り返します。 ASBR4は相互AS TE LSPのための一連の制約に従う道を見つけることができない場合は、ASBR4はASBR1へのPathErrメッセージを送信します。クランクバックは、（[RFC4920]を参照）、この相互AS TE LSPのために許可されている場合、またはクランクバックがその相互AS TE LSPまたはASBR1場合に許可されていない場合、ASBR1は、次に別のASBR（上記の例でASBR5）を選択しますかクランクバックを実行しないように構成されている、ABR1は、シグナリングプロセスを停止し、別の出口LSRを選択しようとすることなく、ヘッドエンドLSR（R0）へのPathErrを転送します。設定されている場合この場合、ヘッドエンドLSRは、順番に、ルーズホップの別のシーケンスを選択することができます。代替的に、ヘッドエンドLSRは、同じ経路を再試行することを決定することができます。これは、いくつかの下流ASで時代遅れのIGP TEデータベースへのセットアップに失敗した場合に有用であることができます。代替案は、また、いくつかの制約（複数可）を緩和した後ルーズホップの同じシーケンスを再試行するヘッドエンドLSRのためであってもよいです。
The path computation procedures are very similar to the inter-area LSP setup case described earlier. In this case, the H-LSPs or S-LSPs are originated by the ASBRs at the entry to the AS.
経路計算手順は、前述したエリア間LSPセットアップ場合と非常に類似しています。この場合には、H-のLSPまたはS-LSPは、ASへの入口でのASBRによって発信されます。
Since the inter-domain TE LSP is computed on a per-domain (area, AS) basis, one cannot guarantee that the optimal inter-domain path can be found.
ドメイン間TE LSPはあたりドメイン（領域など）に基づいて算出されるので、一つは、最適なドメイン間経路を見つけることができることを保証することができません。
Moreover, computing two diverse paths using a per-domain path computation approach may not be possible in some topologies (due to the well-known "trapping" problem).
また、毎ドメイン経路計算手法を使用して2つの多様な経路を計算する（これは周知の「トラッピング」問題に）いくつかのトポロジでは可能ではないかもしれません。
For example, consider the following simple topology:
たとえば、次のような単純なトポロジを考慮してください。
+-------+
/ \
A----B-----C------D
\ /
+---------+
Figure 4 - Example of the "trapping" problem
図4 - 「トラップ」の問題の例
In the simple topology depicted in Figure 4, with a serialized approach using the per-domain path computation technique specified in this document, a first TE LSP may be computed following the path A-B-C-D, in which case no diverse path could be found although two diverse paths actually exist: A-C-D and A-B-D. The aim of that simple example that can easily be extended to the inter-domain case is to illustrate the potential issue of not being able to find diverse paths using the per-domain path computation approach when diverse paths exist.
図4に示された単純なトポロジでは、この文書で指定された単位のドメイン経路計算技術を使用して直列化アプローチと、第1のTE LSPは、二つの多様化がない多様な経路が見つかりませんでした場合にパスABCD、下記計算することができます。パスが実際に存在します。ACDとABDを。簡単にドメイン間の場合に拡張することができる簡単な例の目的は、多様な経路が存在する場合ごとドメイン経路計算手法を用いて、多様な経路を見つけることができないという潜在的な問題を示すことです。
As already pointed out, the required path computation method can be selected by the Service Provider on a per-LSP basis.
既に指摘したように、必要な経路計算方法はあたり-LSPに基づいて、サービス・プロバイダによって選択することができます。
If the per-domain path computation technique does not meet the set of requirements for a particular TE LSP (e.g., path optimality, requirements for a set of diversely routed TE LSPs), other techniques such as PCE-based path computation techniques may be used (see [RFC4655]).
毎ドメイン経路計算手法は、特定のTE LSP（例えば、経路の最適多様ルーティングTE LSPのセットについて、要件）のための一連の要件を満たしていない場合、そのようなPCEベースの経路計算技術のような他の技術が使用されてもよいです（[RFC4655]を参照）。
As stated in [RFC4216] and [RFC4105], the ability to reoptimize an already established inter-domain TE LSP constitutes a requirement. The reoptimization process significantly differs based upon the nature of the TE LSP and the mechanism in use for the TE LSP computation.
[RFC4216]及び[RFC4105]に記載されているように、既に確立されたドメイン間TE LSPを再最適化する能力は必要となります。再最適化プロセスを大幅TE LSPの性質及びTE LSP計算のために使用されているメカニズムに基づいて異なります。
The following mechanisms can be used for reoptimization and are dependent on the nature of the inter-domain TE LSP.
次のメカニズムが再最適化のために使用され、ドメイン間のTE LSPの性質に依存することができます。
After an inter-domain TE LSP has been set up, a better route might appear within any traversed domain. Then in this case, it is desirable to get the ability to reroute an inter-domain TE LSP in a non-disruptive fashion (making use of the so-called Make-Before-Break procedure) to follow a better path. This is a known as a TE LSP reoptimization procedure.
ドメイン間TE LSPが設定された後に、より良いルートは任意の横断ドメイン内で表示される場合があります。そして、この場合には、より良い道をたどるために無停止の方法で、ドメイン間TE LSPを再ルーティングする機能（いわゆるメイク・ビフォアブレーク手続きを利用すること）を取得することが望ましいです。これは、TE LSPの再最適化手順として知られています。
[RFC4736] proposes a mechanism that allows the Head-end LSR to be notified of the existence of a more optimal path in a downstream domain. The Head-end LSR may then decide to gracefully reroute the TE LSP using the Make-Before-Break procedure. In case of a contiguous LSP, the reoptimization process is strictly controlled by the Head-end LSR that triggers the Make-Before-Break procedure as defined in [RFC3209], regardless of the location of the better path.
[RFC4736]はヘッドエンドLSRは、下流領域で、より最適な経路の存在を通知することを可能にするメカニズムを提案します。ヘッドエンドLSRは、優雅メイク・ビフォアブレークの手順を使用してTE LSPを再ルーティングするように決定することができます。連続LSPの場合に、再最適化プロセスは、厳密に[RFC3209]で定義されるようにかかわらず、より良いパスの位置の、メイク・ビフォア・ブレーク手順をトリガするヘッドエンドLSRによって制御されます。
In the case of a stitched or nested inter-domain TE LSP, the reoptimization process is treated as a local matter to any domain. The main reason is that the inter-domain TE LSP is a different LSP (and therefore different RSVP session) from the intra-domain S-LSP or H-LSP in an area or an AS. Therefore, reoptimization in a domain is done by locally reoptimizing the intra-domain H-LSP or S-LSP. Since the inter-domain TE LSPs are transported using S-LSP or H-LSP across each domain, optimality of the inter-domain TE LSP in a domain is dependent on the optimality of the corresponding S-LSP or H-LSP. If after an inter-domain LSP is set up a more optimal path is available within a domain, the corresponding S-LSP or H-LSP will be reoptimized using Make-Before-Break techniques discussed in [RFC3209]. Reoptimization of the H-LSP or S-LSP automatically reoptimizes the inter-domain TE LSPs that the H-LSP or S-LSP transports. Reoptimization parameters like frequency of reoptimization, criteria for reoptimization like metric or bandwidth availability, etc. can vary from one domain to another and can be configured as required, per intra-domain TE S-LSP or H-LSP if it is pre-configured or based on some global policy within the domain.
ステッチまたはネストされたドメイン間TE LSPの場合に、再最適化プロセスは、任意のドメインにローカルの問題として扱われます。主な理由は、ドメイン間のTE LSPは、領域またはASにおけるドメイン内S-LSPまたはH-LSP異なるLSP（したがって異なるRSVPセッション）であることです。したがって、ドメインの再最適化は、ローカルドメイン内H-LSPまたはS-LSPをreoptimizingことによって行われます。ドメイン間TE LSPを各ドメインを横切ってS-LSPまたはH-LSPを使用して輸送されるため、ドメイン内のドメイン間のTE LSPの最適性は、対応するS-LSPまたはH-LSPの最適性に依存しています。ドメイン間LSP後、ドメイン内の利用可能な、より最適な経路である設定されている場合、対応するS-LSPまたはH-LSPは、メイク・ビフォア・ブレーク[RFC3209]で説明した技術を使用して再最適化されるであろう。 H-LSPまたはS-LSPの再最適化を自動的にH-LSPまたはS-LSPが輸送するドメイン間TE LSPを再最適化。等再最適化の頻度、メトリックまたは帯域幅の可用性など再最適化するための基準、のような再最適化パラメータは、あるドメインから別のドメインに変えることができ、必要に応じて、それが予め設定されている場合、ドメイン内TE S-LSPまたはH-LSPごとに、構成することができますまたはドメイン内のいくつかのグローバルポリシーに基づきます。
Hence, in this scheme, since each domain takes care of reoptimizing its own S-LSPs or H-LSPs, and therefore the corresponding inter-domain TE LSPs, the Make-Before-Break can happen locally and is not triggered by the Head-end LSR for the inter-domain LSP. So, no additional RSVP signaling is required for LSP reoptimization, and reoptimization is transparent to the Head-end LSR of the inter-domain TE LSP.
したがって、この方式では、各ドメイン以来、S-のLSPまたはH-LSPを、独自のreoptimizingの世話をするので、対応するドメイン間のTE LSPは、メイク・ビフォアブレークは、局所的に発生する可能性がありますし、頭部によってトリガされていませんドメイン間LSPの終了LSR。だから、追加のRSVPシグナリングは、LSPの再最適化のために必要としない、と再最適化は、ドメイン間TE LSPのヘッドエンドLSRに透過的です。
If, however, an operator desires to manually trigger reoptimization at the Head-end LSR for the inter-domain TE LSP, then this solution does not prevent that. A manual trigger for reoptimization at the Head-end LSR SHOULD force a reoptimization thereby signaling a "new" path for the same LSP (along the more optimal path) making use of the Make-Before-Break procedure. In response to this new setup request, the boundary LSR either may initiate new S-LSP setup, in case the inter-domain TE LSP is being stitched to the intra-domain S-LSP, or it may select an existing or new H-LSP, in case of nesting. When the LSP setup along the current path is complete, the Head-end LSR should switch over the traffic onto that path, and the old path is eventually torn down. Note that the Head-end LSR does not know a priori whether a more optimal path exists. Such a manual trigger from the Head-end LSR of the inter-domain TE LSP is, however, not considered to be a frequent occurrence.
しかし、オペレータが手動でドメイン間TE LSPのためのヘッドエンドLSRで再最適化をトリガすることを望む場合、この溶液はそれを妨げるものではありません。ヘッドエンドLSRで再最適化のための手動トリガは、それによってメイク・ビフォア・ブレーク手順を利用すること（より最適な経路に沿って）同じLSPのための「新しい」シグナリングパス再最適化を強制すべきです。この新しい設定要求に応答して、境界LSRのいずれかは、ドメイン間のTE LSPはドメイン内S-LSPに縫合されている場合には、新しいS-LSPセットアップを開始することができる、またはそれは、既存または新規H-を選択することができます。ネスティングの場合のLSP、。現在のパスに沿ってLSP設定が完了すると、ヘッドエンドLSRは、そのパス上にトラフィックを切り替える必要があり、古いパスが最終的に取り壊されます。ヘッドエンドLSRは、より最適なパスが存在するかどうかを先験的に知っていないことに注意してください。ドメイン間のTE LSPのヘッドエンドLSRからこのような手動トリガは、しかし、頻繁に起こるとは考えられません。
Procedures described in [RFC4736] MUST be used if the operator does not desire local reoptimization of certain inter-domain LSPs. In this case, any reoptimization event within the domain MUST be reported to the Head-end node. This SHOULD be a configurable policy.
オペレータが特定のドメイン間LSPの局所的な再最適化を希望しない場合は、[RFC4736]に記載の手順を使用しなければなりません。この場合、ドメイン内の任意の再最適化イベントは、ヘッドエンドノードに報告しなければなりません。これは、設定ポリシーであるべきです。
Note that in the case of loose hop reoptimization of contiguous inter-domain TE LSP or local reoptimization of stitched/nested S-LSP where boundary LSRs are specified as loose hops, the TE LSP may follow a preferable path within one or more domain(s) but would still traverse the same set of boundary LSRs. In contrast, in the case of PCE-based path computation techniques, because the end-to-end optimal path is computed, the reoptimization process may lead to following a completely different inter-domain path (including a different set of boundary LSRs).
隣接ドメイン間のTE LSPのルーズホップ再最適化又は境界のLSRがルーズホップとして指定され/ステッチネストされたS-LSPの局所再最適化の場合には、TE LSPは、1つまたは複数のドメイン内に好ましい経路をたどることができることに注意してください（複数可）それでも、境界のLSRの同じセットを横断します。エンドツーエンド最適経路を計算するために対照的に、PCEベースの経路計算技術の場合には、再最適化プロセスは、（境界のLSRの異なるセットを含む）完全に異なるドメイン間経路を以下につながる可能性があります。
Signaling of inter-domain TE LSPs raises security issues (discussed in section 7 of [RFC5151]).
ドメイン間TE LSPのシグナリングは、（[RFC5151]のセクション7で説明した）セキュリティ上の問題を提起します。
[RFC4726] provides an overview of the requirements for security in an MPLS-TE or GMPLS multi-domain environment. In particular, when signaling an inter-domain RSVP-TE LSP, an operator may make use of the security features already defined for RSVP-TE ([RFC3209]). This may require some coordination between the domains to share the keys (see [RFC2747] and [RFC3097]), and care is required to ensure that the keys are changed sufficiently frequently. Note that this may involve additional synchronization, should the domain border nodes be protected with Fast Reroute ([RFC4090], since the Merge Point (MP) and Point of Local Repair (PLR) should also share the key. For an inter-domain TE LSP, especially when it traverses different administrative or trust domains, the following mechanisms SHOULD be provided to an operator (also see [RFC4216]):
[RFC4726]はMPLS-TEやGMPLSマルチドメイン環境でのセキュリティのための要件の概要を説明します。ドメイン間RSVP-TE LSPをシグナリングするとき、特に、オペレータは、既にRSVP-TE（[RFC3209]）のために定義されたセキュリティ機能を利用することができます。これは、キーを共有するドメインの間にいくつかの調整を必要とするかもしれない（[RFC2747]及び[RFC3097]を参照）、注意がキーは十分に頻繁に変更されることを保証する必要があります。合流点（MP）とローカル修復点（PLR）は、キーを共有する必要があるため、これは、追加の同期化を含むことができることに留意されたい、ドメインの境界ノードは、高速リルート（[RFC4090]で保護されるべきである。ドメイン間TEについてそれは別の管理や信頼ドメインを横断特にLSPは、以下のメカニズムがオペレータに提供されるべきである（参照[RFC4216]）。
1) A way to enforce policies and filters at the domain borders to process the incoming inter-domain TE LSP setup requests (Path messages) based on certain agreed trust and service levels/contracts between domains. Various LSP attributes such as bandwidth, priority, etc. could be part of such a contract.
1）一定の合意信頼とサービスレベルドメイン間の/契約に基づいて着信ドメイン間TE LSPの設定要求（Pathメッセージ）を処理するために、ドメイン境界でポリシーとフィルタを強制する方法。種々のLSPは、そのような契約の一部とすることができる等、帯域幅、優先度、などの属性。
2) A way for the operator to rate-limit LSP setup requests or error notifications from a particular domain.
2）操作者はレート制限するために、特定のドメインからのLSP設定要求またはエラー通知をするための方法。
3) A mechanism to allow policy-based outbound RSVP message processing at the domain border node, which may involve filtering or modification of certain addresses in RSVP objects and messages.
3）RSVPオブジェクトとメッセージ内の特定のアドレスのフィルタリングまたは修飾を含んでいてもよい、ドメイン境界ノードにポリシーベースのアウトバウンドRSVPメッセージ処理を可能にするメカニズムを。
This document relates to inter-domain path computation. It must be noted that the process for establishing paths described in this document does not increase the information exchanged between ASs and preserves topology confidentiality, in compliance with [RFC4105] and [RFC4216]. That being said, the signaling of inter-domain TE LSP according to the procedure defined in this document requires path computation on boundary nodes that may be exposed to various attacks. Thus, it is RECOMMENDED to support policy decisions to reject the ERO expansion of an inter-domain TE LSP if not allowed.
このドキュメントでは、ドメイン間経路計算に関するものです。情報を増加させない。この文書に記載されパスを確立するためのプロセスは、[RFC4105]及び[RFC4216]に準拠して、AS間で交換し、トポロジの機密性を保持することに留意しなければなりません。言われていることを、本文書で定義された手順に従ってドメイン間TE LSPのシグナリングは、様々な攻撃にさらされる可能性が境界ノードで経路計算を必要とします。このように、許可されていない場合は、ドメイン間TE LSPのERO拡大を拒否するように政策決定を支援することをお勧めします。
We would like to acknowledge input and helpful comments from Adrian Farrel, Jean-Louis Le Roux, Dimitri Papadimitriou, and Faisal Aslam.
私たちは、エードリアンファレル、ジャン=ルイ・ル・ルー、ディミトリPapadimitriou、そしてファイサルアスラムからの入力や有益なコメントを承認したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3209] 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.
[RFC3209] Awduche、D.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：LSPトンネルのためのRSVPの拡張"、RFC 3209年12月2001。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]バーガー、L.、エド。、 "一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリング資源予約プロトコル - トラフィックエンジニアリング（RSVP-TE）を拡張"、RFC 3473、2003年1月。
[RFC4920] Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita, N., and G. Ash, "Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE", RFC 4920, July 2007.
[RFC4920]ファレル、A.編、Satyanarayana、A.、岩田、A.、藤田、N.、およびG.アッシュ、 "MPLSおよびGMPLS RSVP-TEのためのクランクバックシグナリング拡張"、RFC 4920、2007年7月。
[RFC5151] Farrel, A., Ed., Ayyangar, A., and JP. Vasseur, "Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 5151, February 2008.
[RFC5151]ファレル、A.編、Ayyangar、A.、およびJP。 Vasseur、 "ドメイン間MPLSおよびGMPLSトラフィックエンジニアリング - リソース予約プロトコル - トラフィックエンジニアリング拡張機能（RSVP-TE）"、RFC 5151、2008年2月。
[RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel, "Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)", RFC 5150, February 2008.
[RFC5150] Ayyangar、A.、Kompella、K.、Vasseur、JP。、およびA.ファレルは、2008年2月、RFC 5150 "ラベルは、トラフィックエンジニアリング（TE GMPLS）をスイッチング汎用マルチプロトコルラベルとステッチスイッチパス"。
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
[RFC2702] Awduche、D.、マルコム、J.、Agogbua、J.、オデル、M.、およびJ.マクマナス、 "トラフィックエンジニアリングオーバーMPLSのための要件"、RFC 2702、1999年9月。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747]ベーカー、F.、リンデル、B.、およびM. Talwar、 "RSVP暗号化認証"、RFC 2747、2000年1月。
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic Authentication -- Updated Message Type Value", RFC 3097, April 2001.
[RFC3097]ブレーデン、R.とL.チャン、 "RSVP暗号化認証 - 更新メッセージタイプ価値"、RFC 3097、2001年4月。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[RFC3630]カッツ、D.、Kompella、K.、およびD.ヨン、 "トラフィックエンジニアリング（TE）OSPFバージョン2への拡張"、RFC 3630、2003年9月。
[RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004.
[RFC3784]スミット、H.、およびT.李、 "中間システムトラフィックエンジニアリング（TE）のための中間システム（IS-IS）への拡張"、RFC 3784、2004年6月。
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4090]パン、P.、エド。、ツバメ、G.、エド。、およびA.アトラス編、 "高速リルート機能拡張LSPトンネルのための-TEをRSVPする"、RFC 4090、2005年5月。
[RFC4105] Le Roux, J.-L., Ed., Vasseur, J.-P., Ed., and J. Boyle, Ed., "Requirements for Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005.
[RFC4105]ル・ルー、J.-L.、エド。、Vasseur、J.-P.、エド。、およびJ.ボイル、エド。、 "エリア間MPLSトラフィックエンジニアリングのための要件"、RFC 4105、2005年6月。
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005.
[RFC4203] Kompella、K.、エド。、およびY. Rekhter、エド。、RFC 4203、2005年10月 "OSPF拡張一般化マルチプロトコルラベルスイッチング（GMPLS）のサポートで"。
[RFC4205] Kompella, K., Ed., and Y. Rekhter, Ed., "Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4205, October 2005.
[RFC4205] Kompella、K.、エド。、およびY. Rekhter、エド。、 "中間システム（GMPLS）をスイッチング汎用マルチプロトコルラベルの支援における中間システム（IS-IS）への拡張"、RFC 4205、2005年10月。
[RFC4216] Zhang, R., Ed., and J.-P. Vasseur, Ed., "MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements", RFC 4216, November 2005.
[RFC4216]張、R.、編、及びJ.-P. Vasseur、エド。、 "MPLSインター自律システム（AS）トラフィックエンジニアリング（TE）の要件"、RFC 4216、2005年11月。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655]ファレル、A.、Vasseur、J.-P.、およびJ.アッシュ、 "パス計算要素（PCE）ベースのアーキテクチャ"、RFC 4655、2006年8月。
[RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, November 2006.
[RFC4726]ファレル、A.、Vasseur、J.-P.、およびA. Ayyangar、RFC 4726、2006年11月 "トラフィックエンジニアリングの切り替えドメイン間マルチプロトコルラベルのためのフレームワーク"。
[RFC4736] Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched Path (LSP)", RFC 4736, November 2006.
[RFC4736] Vasseur、JP。、エド。、池尻、Y.、およびR.張は、 "マルチプロトコルラベルの再最適化スイッチング（MPLS）トラフィックエンジニアリング（TE）緩くルーティングラベルスイッチパス（LSP）"、RFC 4736、2006年11月。
Authors' Addresses
著者のアドレス
JP Vasseur (editor) Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 USA
JP Vasseur（エディタ）シスコ・システムズ・インク1414年マサチューセッツアベニューボックスボロー、MA 01719 USA
EMail: jpv@cisco.com
メールアドレス：jpv@cisco.com
Arthi Ayyangar (editor) Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 USA
1194年にアイアンガー（編集）ジュニパーネットワークスの棺台ません。マチルダアベニューサニーベール、それらの94089
EMail: arthi@juniper.net
メールアドレス：arthi@juniper.net
Raymond Zhang BT 2160 E. Grand Ave. El Segundo, CA 90025 USA
レイモンド・チャンBT 2160 E.グランドアベニューエル・セグンド、CA 90025 USA
EMail: raymond.zhang@bt.com
メールアドレス：raymond.zhang@bt.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
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, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。