Network Working Group A. Farrel, Ed.
Request for Comments: 5151 Old Dog Consulting
Updates: 3209, 3473 A. Ayyangar
Category: Standards Track Juniper Networks
JP. Vasseur
Cisco Systems, Inc.
February 2008
Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions
ドメイン間MPLSおよびGMPLSトラフィックエンジニアリング - リソース予約プロトコル - トラフィックエンジニアリング（RSVP-TE）の拡張
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 describes procedures and protocol extensions for the use of Resource Reservation Protocol-Traffic Engineering (RSVP-TE) signaling in Multiprotocol Label Switching-Traffic Engineering (MPLS-TE) packet networks and Generalized MPLS (GMPLS) packet and non-packet networks to support the establishment and maintenance of Label Switched Paths that cross domain boundaries.
この文書では、リソース予約プロトコル - トラフィックエンジニアリング（RSVP-TE）はスイッチング・トラフィックエンジニアリング（MPLS-TE）パケットネットワークと一般化MPLS（GMPLS）パケットと非パケット網をするマルチプロトコルラベルにシグナルを使用するための手順やプロトコルの拡張機能について説明しますドメインの境界を越えるラベルスイッチパスの確立と維持をサポートしています。
For the purpose of this document, a domain is considered to be any collection of network elements within a common realm of address space or path computation responsibility. Examples of such domains include Autonomous Systems, Interior Gateway Protocol (IGP) routing areas, and GMPLS overlay networks.
このドキュメントの目的のために、ドメインは、アドレス空間や経路計算責任の共通領域内のネットワーク要素の任意の集合であると考えられています。そのようなドメインの例としては、自律システム、インテリアゲートウェイプロトコル（IGP）ルーティングエリア、およびGMPLSオーバーレイネットワークを含みます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
1.2. Terminology ................................................4
2. Signaling Overview ..............................................4
2.1. Signaling Options ..........................................5
3. Procedures on the Domain Border Node ............................6
3.1. Rules on ERO Processing ....................................8
3.2. LSP Setup Failure and Crankback ...........................10
3.3. RRO Processing across Domains .............................11
3.4. Notify Message Processing .................................11
4. RSVP-TE Signaling Extensions ...................................12
4.1. Control of Downstream Choice of Signaling Method ..........12
5. Protection and Recovery of Inter-Domain TE LSPs ................13
5.1. Fast Recovery Support Using MPLS-TE Fast Reroute (FRR) ....14
5.1.1. Failure within a Domain (Link or Node Failure) .....14
5.1.2. Failure of Link at Domain Border ...................14
5.1.3. Failure of a Border Node ...........................15
5.2. Protection and Recovery of GMPLS LSPs .....................15
6. Reoptimization of Inter-Domain TE LSPs .........................16
7. Backward Compatibility .........................................17
8. Security Considerations ........................................18
9. IANA Considerations ............................................20
9.1. Attribute Flags for LSP_Attributes Object .................20
9.2. New Error Codes ...........................................20
10. Acknowledgments ...............................................21
11. References ....................................................21
11.1. Normative References ....................................21
11.2. Informative References ..................................22
The requirements for inter-area and inter-AS (Autonomous System) Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) are stated in [RFC4105] and [RFC4216], respectively. Many of these requirements also apply to Generalized MPLS (GMPLS) networks. The framework for inter-domain MPLS-TE is provided in [RFC4726].
エリア間およびインターAS（自律システム）マルチプロトコルラベルスイッチング（MPLS）トラフィックエンジニアリング（TE）のための要件は、それぞれ、[RFC4105]と[RFC4216]に記載されています。これらの要件の多くは、一般化MPLS（GMPLS）ネットワークに適用されます。ドメイン間MPLS-TEのためのフレームワークは[RFC4726]に提供されます。
This document presents procedures and extensions to Resource Reservation Protocol-Traffic Engineering (RSVP-TE) signaling for the setup and maintenance of traffic engineered Label Switched Paths (TE LSPs) that span multiple domains in MPLS-TE or GMPLS networks. The signaling procedures described in this document are applicable to MPLS-TE packet LSPs established using RSVP-TE ([RFC3209]) and all LSPs (packet and non-packet) that use RSVP-TE GMPLS extensions as described in [RFC3473].
この文書では、手順や機能拡張は、予約プロトコル・トラフィックのセットアップおよびトラフィックエンジニアリングラベルのメンテナンスのためのシグナリング・エンジニアリング（RSVP-TE）がMPLS-TEやGMPLSネットワーク内に複数のドメインにまたがるパス（TE LSPを）スイッチのリソースに提示します。 [RFC3473]に記載されているように、本書に記載のシグナリング手順は、使用RSVP-TE GMPLS拡張MPLS-TEパケットRSVP-TE（[RFC3209]）を使用して確立されたLSPとすべてのLSP（パケットと非パケット）に適用可能です。
Three different signaling methods for inter-domain RSVP-TE signaling are identified in [RFC4726]. Contiguous LSPs are achieved using the procedures of [RFC3209] and [RFC3473] to create a single end-to-end LSP that spans all domains. Nested LSPs are established using the techniques described in [RFC4206] to carry the end-to-end LSP in a separate tunnel across each domain. Stitched LSPs are established using the procedures of [RFC5150] to construct an end-to-end LSP from the concatenation of separate LSPs each spanning a domain.
ドメイン間RSVP-TEシグナリングのための3つの異なるシグナリング方法は、[RFC4726]で識別されます。連続LSPはすべてのドメインにまたがる単一のエンドツーエンドのLSPを作成するために[RFC3209]及び[RFC3473]の手順を使用して達成されます。ネストされたLSPは、各ドメインを横切って別個のトンネル内のエンドツーエンドのLSPを運ぶために、[RFC4206]に記載された技術を用いて確立されます。ステッチLSPは、各ドメインにまたがる別個のLSPの連結からエンドツーエンドのLSPを構築するために、[RFC5150]の手順を使用して確立されます。
This document defines the RSVP-TE protocol extensions necessary to control and select which of the three signaling mechanisms is used for any one end-to-end inter-domain TE LSP.
この文書では、制御およびいずれかのエンドツーエンドインター - ドメインTE LSPのために使用される3つのシグナル伝達機構のかを選択するために必要なRSVP-TEプロトコルの拡張機能を定義しています。
For the purpose of this document, a domain is considered to be any collection of network elements within a common realm of address space or path computation responsibility. Examples of such domains include Autonomous Systems, IGP areas, and GMPLS overlay networks ([RFC4208]).
このドキュメントの目的のために、ドメインは、アドレス空間や経路計算責任の共通領域内のネットワーク要素の任意の集合であると考えられています。そのようなドメインの例には、自律システム、IGP領域、及びGMPLSオーバーレイネットワークを含む（[RFC4208]）。
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]に記載されているように解釈されます。
AS: Autonomous System.
AS：自律システム。
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間リンクを介して異なるまたは同じサービスプロバイダーのお尻一緒に接続するために使用されます。
Bypass Tunnel: An LSP that is used to protect a set of LSPs passing over a common facility.
バイパストンネル：一般的な施設の上を通過するLSPのセットを保護するために使用されるLSP。
ERO: Explicit Route Object.
ERO：明示的なルートオブジェクト。
FA: Forwarding Adjacency.
FA：転送隣接。
LSR: Label Switching Router.
LSR：ラベルスイッチングルータ。
MP: Merge Point. The node where bypass tunnels meet the protected LSP.
MP：ポイントをマージします。バイパストンネルが保護LSPを満たすノード。
NHOP bypass tunnel: Next-Hop Bypass Tunnel. A backup tunnel, which bypasses a single link of the protected LSP.
NHOPバイパストンネル：ネクストホップバイパストンネル。保護されたLSPの単一リンクを迂回するバックアップトンネル、。
NNHOP bypass tunnel: Next-Next-Hop Bypass Tunnel. A backup tunnel, which bypasses a single node of the protected LSP.
NNHOPバイパストンネル：次の次ホップバイパストンネル。保護されたLSPの単一ノードをバイパスするバックアップトンネル、。
PLR: Point of Local Repair. The ingress of a bypass tunnel.
PLR：ローカル修理のポイント。バイパストンネルの進入。
RRO: Record Route Object.
RRO：レコードルートオブジェクト。
TE link: Traffic Engineering link.
TEリンク：トラフィックエンジニアリングリンク。
The RSVP-TE signaling of a TE LSP within a single domain is described in [RFC3209] and [RFC3473]. Inter-domain TE LSPs can be supported by one of three options as described in [RFC4726] and set out in the next section:
単一ドメイン内のTE LSPのRSVP-TEシグナリングは[RFC3209]及び[RFC3473]に記載されています。 [RFC4726]に記載され、次のセクションに記載のようにドメイン間TE LSPは、3つのオプションのいずれかによって支持することができます。
- contiguous LSPs - nested LSPs - stitched LSPs.
- 連続したLSP - ネストされたのLSP - ステッチのLSP。
In fact, as pointed out in [RFC4726], any combination of these three options may be used in the course of an end-to-end inter-domain LSP. That is, the options should be considered as per-domain transit options so that an end-to-end inter-domain LSP that starts in domain A, transits domains B, C, and D, and ends in domain E might use an
[RFC4726]で指摘したように、実際には、これらの3つのオプションの任意の組み合わせは、エンドツーエンドのドメイン間LSPの過程で使用されてもよいです。つまり、ドメインAで開始エンド・ツー・エンドのドメイン間LSPは、ドメインB、C、及びDを通過するようにオプションをドメインごとの中継オプションとして考慮されるべきであり、そして使用する可能性がある領域Eで終了します
LSP that runs contiguously from the ingress in domain A, through domain B to the border with domain C. Domain C might be transited using the nested LSP option to reach the border with domain D, and domain D might be transited using the stitched LSP option to reach the border with domain E, from where a normal LSP runs to the egress.
ドメインC.ドメインCとの境界にドメインBを介して、ドメインAの入口から連続実行LSPはドメインDとの境界に到達するために、ネストされたLSPのオプションを使用して遷移する可能性があり、ドメインDは、ステッチLSPオプションを使用して移行されるかもしれません通常のLSPが出口に走るどこから、ドメインEとの国境に到達します。
This document describes the RSVP-TE signaling extensions required to select and control which of the three signaling mechanisms is used.
この文書では、使用される3つのシグナル伝達機構のかを選択し、制御するために必要なRSVP-TEシグナリング拡張を記述しています。
The specific protocol extensions required to signal each LSP type are described in other documents and are out of scope for this document. Similarly, the routing extensions and path computation techniques necessary for the establishment of inter-domain LSPs are out of scope. An implementation of a transit LSR is unaware of the options for inter-domain TE LSPs since it sees only TE LSPs. An implementation of a domain border LSR has to decide what mechanisms of inter-domain TE LSP support to include, but must in any case support contiguous inter-domain TE LSPs since this is the default mode of operation for RSVP-TE. Failure to support either or both of nested LSPs or stitched LSPs, restricts the operators options, but does not prevent the establishment of inter-domain TE LSPs.
各LSPのタイプを通知するために必要な特定のプロトコルの拡張は、他の文書に記載されており、この文書の範囲外されています。同様に、ドメイン間LSPの確立のために必要なルーティング拡張および経路計算技術は、範囲外です。それが唯一のTE LSPを見ているので、トランジットLSRの実装では、ドメイン間TE LSPのためのオプションを認識しません。ドメイン境界LSRの実装では、ドメイン間TE LSPのメカニズムが含まれるようにサポートするかを決定するが、いずれの場合のサポートの隣接ドメイン間TEのLSPにこれはRSVP-TEのためのデフォルトの動作モードでなければならないからです。ネストされたのLSPやステッチLSPのいずれかまたは両方をサポートするための失敗は、事業者の選択肢を制限しますが、ドメイン間TE LSPの確立を妨げるものではありません。
There are three ways in which an RSVP-TE LSP could be signaled across multiple domains:
RSVP-TE LSPは、複数のドメイン間で信号を送ることができている3つの方法があります。
Contiguous A contiguous TE LSP is a single TE LSP that is set up across multiple domains using RSVP-TE signaling procedures described in [RFC3209] and [RFC3473]. No additional TE LSPs are required to create a contiguous TE LSP, and the same RSVP-TE information for the TE LSP is maintained along the entire LSP path. In particular, the TE LSP has the same RSVP-TE session and LSP ID at every LSR along its path.
連続連続TE LSPは、[RFC3209]及び[RFC3473]に記載のRSVP-TEシグナリング手順を使用して複数のドメイン間で設定された単一のTE LSPです。追加のTE LSPは連続TE LSPを作成するために必要とされない、そしてTE LSPのために同じRSVP-TE情報は、全体のLSPの経路に沿って維持されます。具体的には、TE LSPは、その経路に沿ってすべてのLSRに同じRSVP-TEセッションとLSP IDを有しています。
Nested One or more TE LSPs may be nested within another TE LSP as described in [RFC4206]. This technique can be used to nest one or more inter-domain TE LSPs into an intra-domain hierarchical LSP (H-LSP). The label stacking construct is used to achieve nesting in packet networks. In the rest of this document, the term H-LSP is used to refer to an LSP that allows other LSPs to be nested within it. An H-LSP may be advertised as a TE link within the same instance of the routing protocol as was used to advertise the TE links from which it was created, in which case it is a Forwarding Adjacency (FA) [RFC4206].
[RFC4206]に記載されているようにネストされた一の以上のTE LSPは別のTE LSP内にネストされてもよいです。この技術は、イントラドメイン階層LSP（H-LSP）に入れ子一つ以上のドメイン間のTE LSPのために使用することができます。ラベルスタッキング構築物は、パケットネットワークでネストを達成するために使用されます。この文書の残りの部分では、用語H-LSPは、他のLSPは、その中にネストされることを可能にするLSPを指すために使用されます。それは転送隣接（FA）[RFC4206]である場合には、それが作成されたTEリンクをアドバタイズするために使用されたようにH-LSPは、ルーティングプロトコルの同じインスタンス内にTEリンクとして広告することができます。
Stitched The concept of LSP stitching as well as the required signaling procedures are described in [RFC5150]. This technique can be used to stitch together shorter LSPs (LSP segments) to create a single, longer LSP. The LSP segments of an inter-domain LSP may be intra-domain LSPs or inter-domain LSPs.
LSPステッチの概念をステッチならびに必要なシグナリング手順は、[RFC5150]に記載されています。この技術は、単一の、より長いLSPを作成するために一緒に短いのLSP（LSPセグメント）をステッチするために使用することができます。ドメイン間LSPのLSPセグメントは、ドメイン内のLSPまたはドメイン間のLSPであってもよいです。
The process of stitching in the data plane results in a single, end-to-end contiguous LSP. But in the control plane, each segment is signaled as a separate LSP (with distinct RSVP sessions) and the end-to-end LSP is signaled as yet another LSP with its own RSVP session. Thus, the control plane operation for LSP stitching is very similar to that for nesting.
単一のエンドツーエンドの連続LSPにおけるデータプレーン結果における綴じの方法。しかし、制御プレーンでは、各セグメントは、（別個のRSVPセッションで）別個のLSPとしてシグナリングされ、エンドツーエンドのLSPは、独自のRSVPセッションにまだ別のLSPとしてシグナリングされます。したがって、LSPステッチのための制御プレーン動作はネスティングのためのものと非常に類似しています。
An end-to-end inter-domain TE LSP may be achieved using one or more of the signaling techniques described. The choice is a matter of policy for the node requesting LSP setup (the ingress) and policy for each successive domain border node. On receipt of an LSP setup request (RSVP-TE Path message) for an inter-domain TE LSP, the decision of whether to signal the LSP contiguously or whether to nest or stitch it to another TE LSP depends on the parameters signaled from the ingress node and on the configuration of the local node.
エンドツーエンドインター - ドメインTE LSPを説明シグナリング技術の1つまたは複数を使用して達成することができます。選択は、連続する各ドメインの境界ノードのためのLSP設定（入力）と政策を要求するノードのための政策の問題です。ドメイン間TE LSP、入れ子に連続かどうかLSPを信号またはTE LSPは、入口からシグナリングパラメータに依存別にステッチするかどうかの決定のためのLSP設定要求（RSVP-TE Pathメッセージ）を受信しますノードとローカル・ノードの構成に関する。
The stitching segment LSP or H-LSP used to cross a domain may be pre-established or signaled dynamically based on the demand caused by the arrival of the inter-domain TE LSP setup request.
ステッチセグメントLSPまたはH-LSPはドメインを横断するために使用されるドメイン間のTE LSP設定要求の到着に起因する需要に基づいて事前に確立されたまたは動的にシグナリングすることができます。
Whether an inter-domain TE LSP is contiguous, nested, or stitched is limited by the signaling methods supported by or configured on the intermediate nodes. It is usually the domain border nodes where this restriction applies since other transit nodes are oblivious to the mechanism in use. The ingress of the LSP may further restrict the choice by setting parameters in the Path message when it is signaled.
ドメイン間かどうかをTE LSPは、ネストされた、またはシグナリング方法でサポートされている、または中間ノードに設定さによって制限されるステッチ、連続しています。これは、通常、他のトランジットノードは、使用中のメカニズムに気づかされているので、この制限が適用されるドメインの境界ノードです。 LSPの入口はさらに、それが通知されたときPathメッセージ内のパラメータを設定することにより、選択を制限することができます。
When a domain border node receives the RSVP Path message for an inter-domain TE LSP setup, it MUST carry out the following procedures before it can forward the Path message to the next node along the path:
ドメインの境界ノードは、ドメイン間のTE LSPセットアップのためのRSVP Pathメッセージを受信すると、パスに沿って次のノードにPathメッセージを転送する前に、それは次の手順を実行する必要があります。
1. Apply policies for the domain and the domain border node. These policies may restrict the establishment of inter-domain TE LSPs. In case of a policy failure, the node SHOULD fail the setup and send a PathErr message with error code "Policy control failure"/ "Inter-domain policy failure".
1.ドメインとドメインの境界ノードのポリシーを適用します。これらのポリシーは、ドメイン間TE LSPの確立を制限することができます。政策の失敗の場合には、ノードは、セットアップに失敗し、エラーコード「ポリシー制御の失敗」/「ドメイン間ポリシーの失敗」とのPathErrメッセージを送るべきです。
2. Determine the signaling method to be used to cross the domain. If the ingress node of the inter-domain TE LSP has specified restrictions on the methods to be used, these MUST be adhered to. Within the freedom allowed by the ingress node, the domain border node MAY choose any method according to local configuration and policies. If no resultant signaling method is available or allowed, the domain border node MUST send a PathErr message with an error code as described in Section 4.1.
2.ドメインを横断するために使用されるシグナリング方法を決定します。ドメイン間のTE LSPの入口ノードを使用する方法の制限を指定している場合、これらはに付着しなければなりません。入口ノードによって許可された自由の中で、ドメインの境界ノードは、ローカル設定とポリシーに応じて任意の方法を選ぶかもしれません。全く得られシグナリング方法が利用可能であるか、または許可されない場合は、セクション4.1で説明したように、ドメイン境界ノードは、エラーコードのPathErrメッセージを送らなければなりません。
Thus, for example, an ingress may request a contiguous LSP
because it wishes to exert maximal control over the LSP's path
and to control when reoptimization takes place. But the
operator of a transit domain may decide (for example) that
only LSP stitching is allowed for exactly the reason that it
gives the operator the chance to reoptimize their own domain
under their own control. In this case, the policy applied at
the entry to the transit domain will result in the return of a
PathErr message and the ingress has a choice to:
- find another path avoiding the transit domain, - relax his requirements, or - fail to provide the service.
- 、トランジットドメインを避けて別のパスを見つける - 彼の要件を緩和、または - サービスを提供することができません。
3. Carry out ERO procedures as described in Section 3 in addition to the procedures in [RFC3209] and [RFC3473].
[RFC3209]及び[RFC3473]の手順に加えて、第3節で説明したように3 ERO手順を実行します。
4. Perform any path computations as required to determine the path across the domain and potentially to select the exit point from the domain.
4.ドメインを横切って経路を決定するために、潜在的にドメインからの出口点を選択するために必要な任意の経路計算を行います。
The path computation procedure is outside the scope of this
document. A path computation option is specified in
[RFC5152], and another option is to use a Path Computation
Element (PCE) [RFC4655].
4a. In the case of nesting or stitching, either find an existing intra-domain TE LSP to carry the inter-domain TE LSP or signal a new one, depending on local policy.
図4（a）。ネストまたはステッチの場合には、いずれかのドメイン間のTE LSPを運ぶか、ローカルポリシーに応じて、新しいものを知らせるために、既存のドメイン内TE LSPを見つけます。
In the event of a path computation failure, a PathErr message SHOULD be sent with error code "Routing Problem" using an error value selected according to the reason for computation failure. A domain border node MAY opt to silently discard the Path message in this case as described in Section 8.
経路計算に障害が発生した場合、のPathErrメッセージは計算失敗の原因に応じて選択された誤差値を使用して、エラーコード「ルーティング問題」で送られるべきです。ドメインの境界ノードは、第8章で説明したように静かに、この場合にPathメッセージを廃棄するように選ぶことができます。
In the event of the receipt of a PathErr message reporting signaling failure from within the domain or reported from a downstream domain, the domain border node MAY apply crankback procedures as described in Section 3.2. If crankback is not applied, or is exhausted, the border node MUST continue with PathErr processing as described in [RFC3209] and [RFC3473].
セクション3.2で説明したように、ドメイン内または下流ドメインから報告からシグナリング障害を報告するのPathErrメッセージを受信した場合に、ドメインの境界ノードは、クランクバック手順を適用することができます。クランクバックが適用されていない、または排出される場合は[RFC3209]及び[RFC3473]に記載されているように、ボーダー・ノードは、のPathErr処理を続行しなければなりません。
In the event of successful processing of a Path or Resv message, the domain border node MUST carry out RRO procedures as described in Section 3.3.
セクション3.3で説明したようにパスまたはResvメッセージの成功した処理の場合には、ドメインの境界ノードは、RROの手順を実行しなければなりません。
The ERO that a domain border node receives in the Path message was supplied by the ingress node of the TE LSP and may have been updated by other nodes (for example, other domain border nodes) as the Path message was propagated. The content of the ERO depends on several factors including:
ドメインの境界ノードは、Pathメッセージにおいて受信EROは、TE LSPの入口ノードによって供給されたとPathメッセージを伝播したように、他のノード（例えば、他のドメインの境界ノード）によって更新されていてもよいです。 EROの内容は、以下を含むいくつかの要因に依存します。
- the path computation techniques used, - the degree of TE visibility available to the nodes performing path computation, and - the policy at the nodes creating/modifying the ERO.
経路計算に使用される技術、 - 経路計算を行うノードに利用可能なTEの可視性の程度、および - - ノードのポリシーが作成/ EROを変更します。
In general, H-LSPs and LSP segments are used between domain border nodes, but there is no restriction on the use of such LSPs to span multiple hops entirely within a domain. Therefore, the discussion that follows may be equally applied to any node within a domain although the term "domain border node" continues to be used for clarity.
一般に、H-のLSPとLSPセグメントは、ドメイン境界ノード間で使用されているが、完全ドメイン内の複数のホップに及ぶため、そのようなLSPの使用に制限はありません。用語「ドメイン境界ノード」は、明確にするために使用され続けているが故に、以下の説明は、同様のドメイン内の任意のノードに適用されてもよいです。
When a Path message reaches the domain border node, the following rules apply for ERO processing and for further signaling.
Pathメッセージは、ドメインの境界ノードに到達すると、次の規則がEROの処理のために、さらにシグナリングのために適用されます。
1. If there are any policies related to ERO processing for the LSP, they MUST be applied and corresponding actions MUST be taken. For example, there might be a policy to reject EROs that identify nodes within the domain. In case of inter-domain LSP setup failures due to policy failures related to ERO processing, the node SHOULD issue a PathErr with error code "Policy control failure"/"Inter-domain explicit route rejected", but MAY be configured to silently discard the Path message or to return a different error code for security reasons.
1. LSPのためERO処理に関連するポリシーがある場合は、それらが適用されなければならないと、対応する措置が取られなければなりません。たとえば、ドメイン内のノードを識別エロスを拒絶するポリシーがあるかもしれません。原因ERO処理に関連する政策の失敗へのドメイン間LSPのセットアップ障害が発生した場合には、ノードは、/「ドメイン間の明示的なルートが拒否され、」エラーコード「ポリシー制御の失敗」とのPathErrを発行する必要がありますが、静かに破棄するように構成してもよい（MAY）セキュリティ上の理由から、別のエラーコードを返すために、Pathメッセージや。
2. Section 8.2 of [RFC4206] describes how a node at the edge of a region processes the ERO in the incoming Path message and uses this ERO, to either find an existing H-LSP or signal a new H-LSP using the ERO hops. This process includes adjusting the ERO before sending the Path message to the next hop. These procedures MUST be followed for nesting or stitching of inter-domain TE LSPs.
[RFC4206]の2セクション8.2は、領域のエッジにおけるノードは既存のH-LSPを見つけたりEROのホップを使用して、新しいH-LSPの信号のいずれかに、受信PathメッセージにEROを処理し、このEROを使用する方法について説明します。このプロセスは、次のホップにPathメッセージを送信する前にEROを調整することを含みます。これらの手順は、ドメイン間TE LSPのネスティングやステッチのために従わなければなりません。
3. If an ERO subobject identifies a TE link formed by the advertisement of an H-LSP or LSP segment (whether numbered or unnumbered), contiguous signaling MUST NOT be used. The node MUST use either nesting or stitching according to the capabilities of the LSP that forms the TE link, the parameters signaled in the Path message, and local policy. If there is a conflict between the capabilities of the LSP that forms the TE link indicated in the ERO and the parameters on the Path message, the domain border node SHOULD send a PathErr with error code "Routing Problem"/"ERO conflicts with inter-domain signaling method", but MAY be configured to silently discard the Path message or to return a different error code for security reasons.
3. EROサブオブジェクトは、H-LSPまたはLSPセグメントの広告（番号または番号なしか）によって形成されたTEリンクを識別する場合、隣接シグナリングを使用してはいけません。ノードは、パラメータがPathメッセージ、およびローカルポリシーにシグナリング、TEリンクを形成するLSPの能力に応じてネスティング又はステッチのいずれかを使用しなければなりません。相互とEROとPathメッセージにパラメータに示されているTEリンクを形成するLSPの能力との間に矛盾がある場合、ドメインの境界ノードはエラーコードでのPathErrを送ります「ルーティング問題」/「ERO競合ドメイン」の方法を、シグナリングが、静かにPathメッセージを破棄するか、セキュリティ上の理由から、別のエラーコードを返すように構成することができます。
4. An ERO in a Path message received by a domain border node may have a loose hop as the next hop. This may be an IP address or an AS number. In such cases, the ERO MUST be expanded to determine the path to the next hop using some form of path computation that may, itself, generate loose hops.
ドメイン境界ノードによって受信されたPathメッセージ4.アンEROは、ネクストホップとしてルーズホップを有していてもよいです。これは、IPアドレスやASの数であってもよいです。このような場合に、EROは、それ自体が、ルーズホップを生成することができる経路計算のいくつかのフォームを使用して、次のホップへのパスを決定するために拡張されなければなりません。
5. In the absence of any ERO subobjects beyond the local domain border node, the LSP egress (the destination encoded in the RSVP Session object) MUST be considered as the next loose hop and rule 4 applied.
次のルーズホップ及び規則4が適用される5は、ローカルドメインの境界ノード以降任意EROサブオブジェクトが存在しない場合、LSPの出口（RSVPセッションオブジェクトに符号化されたデスティネーション）が考慮されなければなりません。
6. In the event of any other failures processing the ERO, a PathErr message SHOULD be sent as described in [RFC3209] or [RFC3473], but a domain border router MAY be configured to silently discard the Path message or to return a different error code for security reasons.
6. EROを処理する任意の他の障害が発生した場合には、[RFC3209]または[RFC3473]に記載されているようのPathErrメッセージが送信されるべきであるが、ドメイン境界ルータがサイレントPathメッセージを破棄するか、異なるエラーを返すように構成されるかもしれセキュリティ上の理由のためのコード。
When an error occurs during LSP setup, a PathErr message is sent back towards the LSP ingress node to report the problem. If the LSP traverses multiple domains, this PathErr will be seen successively by each domain border node.
エラーがLSPのセットアップ時に発生した場合、のPathErrメッセージは、問題を報告するLSPの入口ノードに向けて送り返されます。 LSPは、複数のドメインを横断する場合、これのPathErrは、各ドメインの境界ノードによって順次分かります。
Domain border nodes MAY apply local policies to restrict the propagation of information about the contents of the domain. For example, a domain border node MAY replace the information in a PathErr message that indicates a specific failure at a specific node with information that reports a more general error with the entire domain. These procedures are similar to those described for the borders of overlay networks in [RFC4208].
ドメイン境界ノードは、ドメインの内容に関する情報の伝播を制限するためにローカルポリシーを適用することができます。たとえば、ドメインの境界ノードは、ドメイン全体でより多くの一般的なエラーを通知する情報を特定のノードで特定の障害を示したPathErrメッセージで情報を交換することができます。これらの手順は、[RFC4208]でオーバーレイネットワークの境界について記載したものと同様です。
However:
しかしながら：
- A domain border node MUST NOT suppress the propagation of a PathErr message except to attempt rerouting as described below.
- ドメインの境界ノードは、以下に説明するように再ルーティングしようとする以外のPathErrメッセージの伝播を抑制してはいけません。
- Nodes other than domain border nodes SHOULD NOT modify the contents of a PathErr message.
- ドメインの境界ノード以外のノードはのPathErrメッセージの内容を変更しないでください。
- Domain border nodes SHOULD NOT modify the contents of a PathErr message unless domain confidentiality is a specific requirement.
- ドメインの機密性は、特定の要件でない限り、ドメインの境界ノードは、のPathErrメッセージの内容を変更しないでください。
Domain border nodes provide an opportunity for crankback rerouting [RFC4920]. On receipt of a PathErr message generated because of an LSP setup failure, a domain border node MAY hold the PathErr and make further attempts to establish the LSP if allowed by local policy and by the parameters signaled on the Path message for the LSP. Such attempts might involve the computation of alternate routes through the domain, or the selection of different downstream domains. If a subsequent attempt is successful, the domain border router MUST discard the held PathErr message, but if all subsequent attempts are unsuccessful, the domain border router MUST send the PathErr upstream toward the ingress node. In this latter case, the domain border router MAY change the information in the PathErr message to provide further crankback details and information aggregation as described in [RFC4920].
ドメイン境界ノードは、クランクバック再ルーティング[RFC4920]のための機会を提供します。なぜならLSP設定障害の発生したのPathErrメッセージを受信すると、ドメインの境界ノードはのPathErrを保持し、ローカルポリシーによっておよびパラメータによって許可されている場合はLSPを確立するための更なる試みを行うことができるLSPのためのPathメッセージに合図をしました。そのような試みは、ドメインを介して代替ルートの計算、または異なる下流のドメインの選択を含むかもしれません。その後の試みが成功した場合は、ドメイン境界ルータが開催されたPathErrメッセージを捨てなければなりませんが、それ以降のすべての試みが失敗した場合は、ドメイン境界ルータは、入口ノードに向かって、上流のPathErrを送らなければなりません。 [RFC4920]に記載されているように、この後者の場合には、ドメイン境界ルータは、さらに、クランクバックの詳細を提供するためのPathErrメッセージ及び情報集合内の情報を変更してもよいです。
Crankback rerouting MAY also be used to handle the failure of LSPs after they have been established [RFC4920].
彼らは[RFC4920]を確立された後にクランクバック再ルーティングはまた、LSPの失敗を処理するために使用されるかもしれません。
[RFC3209] defines the RRO as an optional object used for loop detection and for providing information about the hops traversed by LSPs.
[RFC3209]はループ検出用とのLSPによって横断ホップについての情報を提供するために使用される任意のオブジェクトとしてRROを定義します。
As described for overlay networks in [RFC4208], a domain border node MAY filter or modify the information provided in an RRO for confidentiality reasons according to local policy. For example, a series of identifiers of hops within a domain MAY be replaced with the domain identifier (such as the AS number) or be removed entirely leaving just the domain border nodes.
[RFC4208]でオーバーレイネットワークについて記載したように、ドメイン境界ノードは、ローカルポリシーに従って機密保持上の理由からRROで提供される情報をフィルタリングまたは修正することができます。たとえば、ドメイン内のホップの識別子の系列は、（AS番号など）ドメイン識別子と置き換えることができるか、単にドメインの境界ノードを残して完全に除去します。
Note that a domain border router MUST NOT mask its own presence, and MUST include itself in the RRO.
ドメイン境界ルータは、自身の存在を隠すてはならない、とRROに自分自身を含まなければならないことに注意してください。
Such filtering of RRO information does not hamper the working of the signaling protocol, but the subsequent information loss may render management diagnostic procedures inoperable or at least make them more complicated, requiring the coordination of administrators of multiple domains.
RRO情報のそのようなフィルタリングは、シグナリングプロトコルの動作を妨げないが、その後の情報損失は動作不能管理診断手順をレンダリングするか、少なくとも複数のドメインの管理者の調整を必要とする、それらをより複雑にすることができます。
Similarly, protocol procedures that depend on the presence of RRO information may become inefficient. For example, the Fast Reroute procedures defined in [RFC4090] use information in the RRO to determine the labels to use and the downstream MP.
同様に、RRO情報の存在に依存するプロトコル手順は、非効率的になることができます。例えば、[RFC4090]で定義された高速リルート手順は、使用するラベルと下流MPを決定するために、RROの情報を使用します。
Notify messages are introduced in [RFC3473]. They may be sent direct rather than hop-by-hop, and so may speed the propagation of error information. If a domain border router is interested in seeing such messages (for example, to enable it to provide protection switching), it is RECOMMENDED that the domain border router update the Notify Request objects in the Path and Resv messages to show its own address following the procedures of [RFC3473].
通知メッセージは、[RFC3473]で導入されています。これらは、ホップバイホップではなく直接送信することができる、などのエラー情報の伝播を加速することができます。ドメイン境界ルータは、（例えば、保護スイッチングを提供することを可能にする）ようなメッセージを見ることに興味がある場合は、ドメイン境界ルータは、以下の自身のアドレスを表示するにはパスのリクエストオブジェクトとRESVメッセージを通知する更新することをお勧めします[RFC3473]の手順。
Note that the replacement of a Notify Recipient in the Notify Request object means that some Notify messages (for example, those intended for delivery to the ingress LSR) may need to be examined, processed, and forwarded at domain borders. This is an obvious trade-off issue as the ability to handle notifiable events locally (i.e., within the domain) may or may not outweigh the cost of processing and forwarding Notify messages beyond the domain. Observe that the cost increases linearly with the number of domains in use.
通知要求オブジェクト内の通知受信者の交換は、いくつかのメッセージを通知することを意味することに留意されたい（例えば、入口LSRへの送達のために意図されたもの）は、検査処理、及びドメイン境界で転送される必要があるかもしれません。局所的に通知可能なイベントを処理する能力（すなわち、ドメイン内）であるか否かのできる処理のコストを上回ると、ドメインを越えてメッセージを通知転送することができるので、これは明らかなトレードオフの問題です。コストは、使用中のドメインの数に対して直線的に増加することを確認します。
Also note that, as described in Section 8, a domain administrator may wish to filter or modify Notify messages that are generated within a domain in order to preserve security or confidentiality of network information. This is most easily achieved if the Notify messages are sent via the domain borders.
また、第8章で説明したように、ドメイン管理者がフィルタリングしたり、セキュリティやネットワーク情報の機密性を維持するためには、ドメイン内で生成されたメッセージを通知し、変更したい場合があり、注意してください。通知メッセージは、ドメインの境界線を経由して送信された場合、これは最も容易に達成されます。
The following RSVP-TE signaling extensions are defined to enable inter-domain LSP setup.
以下のRSVP-TEシグナリング拡張は、ドメイン間LSPの設定を有効にするために定義されています。
In many network environments, there may be a network-wide policy that determines which one of the three inter-domain LSP techniques is used. In these cases, no protocol extensions are required.
多くのネットワーク環境では、三ドメイン間LSP技術の一つを使用するかを決定するネットワーク全体のポリシーがあってもよいです。これらのケースでは、何のプロトコル拡張は必要ありません。
However, in environments that support more than one technique, an ingress node may wish to constrain the choice made by domain border nodes for each inter-domain TE LSP that it originates.
しかし、複数の技術をサポートする環境では、入口ノードは、それが由来する各ドメイン間のTE LSPのドメイン境界ノードによって行われた選択を制限することを望むかもしれません。
[RFC4420] defines the LSP_Attributes object that can be used to signal required attributes of an LSP. The Attributes Flags TLV includes Boolean flags that define individual attributes.
[RFC4420]はLSPの必要な属性を知らせるために使用することができるLSP_Attributesオブジェクトを定義します。属性フラグTLVは、個々の属性を定義するブールのフラグが含まれています。
This document defines a new bit in the TLV that can be set by the ingress node of an inter-domain TE LSP to restrict the intermediate nodes to using contiguous signaling:
この文書は、連続信号を使用する中間ノードを制限するドメイン間TE LSPの入口ノードによって設定することができるTLVに新しいビットを定義します。
Contiguous LSP bit (bit number assignment in Section 9.1)
連続LSPビット（セクション9.1のビット数の割り当て）
This flag is set by the ingress node that originates a Path message to set up an inter-domain TE LSP if it requires that the contiguous LSP technique is used. This flag bit is only to be used in the Attributes Flags TLV.
このフラグは、それが連続するLSPの技術が使用されることを必要とする場合、ドメイン間のTE LSPを設定するPathメッセージを発信入口ノードによって設定されています。このフラグビットは、属性フラグTLVで使用するだけです。
When a domain border LSR receives a Path message containing this bit set (one), the node MUST NOT perform stitching or nesting in support of the inter-domain TE LSP being set up. When this bit is clear (zero), a domain border LSR MAY perform stitching or nesting according to local policy.
ドメイン境界LSRは、このビットがセット（1）を含むPathメッセージを受信すると、ノードは、TE LSPがセットアップされているドメイン間の支持体に縫合またはネストを実行してはいけません。このビットが（ゼロ）クリアである場合、ドメイン境界LSRは、ローカルポリシーに従ってステッチ又はネスティングを行うことができます。
This bit MUST NOT be modified by any transit node.
このビットは、すべてのトランジットノードによって変更してはいけません。
An intermediate node that supports the LSP_Attributes object and the Attributes Flags TLV, and also recognizes the "Contiguous LSP" bit, but cannot support contiguous TE LSPs, MUST send a Path Error message with an error code "Routing Problem"/"Contiguous LSP type not supported" if it receives a Path message with this bit set.
連続したTE LSPをサポートすることはできませんLSP_Attributesオブジェクトと属性フラグTLVをサポートしており、また、「連続LSP」ビットを認識しますが、中間ノードは、エラーコードでパスエラーメッセージを送らなければなりません「ルーティング問題」/「連続LSPタイプそれは、このビットが設定されたPathメッセージを受信した場合、」サポートされていません。
If an intermediate node receiving a Path message with the "Contiguous LSP" bit set in the Flags field of the LSP_Attributes, recognizes the object, the TLV, and the bit and also supports the desired contiguous LSP behavior, then it MUST signal a contiguous LSP. If the node is a domain border node, or if the node expands a loose hop in the ERO, it MUST include an RRO Attributes subobject in the RRO of the corresponding Resv message (if such an object is present) with the "Contiguous LSP" bit set to report its behavior.
LSP_AttributesのFlagsフィールドに設定されている「連続LSP」ビットとPathメッセージを受信した中間ノードは、オブジェクト、TLV、及びビットを認識し、また、所望の隣接LSPの動作をサポートしている場合、それは連続したLSPを通知しなければなりません。ノードは、ドメイン境界ノードであるか、またはノードはEROにルーズホップを展開した場合、それは「連続LSP」で（例えば、オブジェクトが存在する場合）RROは、対応するResvメッセージのRROにサブオブジェクト属性含める必要がある場合ビットはその動作を報告するように設定します。
Domain border LSRs MUST support and act on the setting of the "Contiguous LSP" flag.
ドメイン境界のLSRはサポートして「連続LSP」フラグの設定に基づいて行動しなければなりません。
However, if the intermediate node supports the LSP_Attributes object but does not recognize the Attributes Flags TLV, or supports the TLV but does not recognize this "Contiguous LSP" bit, then it MUST forward the object unmodified.
中間ノードがLSP_Attributesオブジェクトをサポートしているが、属性フラグTLVを認識しない、またはTLVをサポートしていますが、この「連続LSP」ビットを認識しない場合は、それは、オブジェクトが変更されていない転送する必要があります。
The choice of action by an ingress node that receives a PathErr when requesting the use of a contiguous LSP is out of the scope of this document, but may include the computation of an alternate path.
連続LSPの使用を要求する際のPathErrを受け取る入口ノードによってアクションの選択は、この文書の範囲外であるが、代替パスの計算を含むことができます。
The procedures described in Sections 3 and 4 MUST be applied to all inter-domain TE LSPs, including bypass tunnels, detour LSPs [RFC4090], and segment recovery LSPs [RFC4873]. This means that these LSPs will also be subjected to ERO processing, policies, path computation, etc.
セクション3および4に記載された手順は、バイパストンネル、迂回のLSP [RFC4090]、セグメント回復のLSP [RFC4873]を含む、すべてのドメイン間TEのLSPに適用されなければなりません。これは、これらのLSPもERO処理、ポリシー、経路計算、等に供されることを意味し
Note also that the paths for these backup LSPs need to be either pre-configured, computed, and signaled with the protected LSP or computed on-demand at the PLR. Just as with any inter-domain TE LSP, the ERO may comprise strict or loose hops and will depend on the TE visibility of the computation point into the subsequent domain.
これらのバックアップのLSPのためのパスのいずれか、事前に設定計算され、保護されたLSPでシグナリングまたはオンデマンドPLRで計算する必要があることにも留意されたいです。ちょうど任意のドメイン間TE LSPと同様に、EROは、厳密または緩いホップを含んでもよく、後続の領域に計算点のTE可視性に依存するであろう。
If loose hops are present in the path of the backup LSP, ERO expansion will be required at some point along the path: probably at a domain border node. In order that the backup path remains disjoint from the protected LSP(s) the node performing the ERO expansion must be provided with the path of the protected LSPs between the PLR and the MP. This information can be gathered from the RROs of the protected LSPs and is signaled in the DETOUR object for Fast Reroute [RFC4090] and uses route exclusion [RFC4874] for other protection schemes.
ゆるいホップは、バックアップLSPのパスに存在している場合は、EROの拡張は、パスに沿っていくつかの点で必要とされます。おそらくドメインの境界ノードで。ために予備パスが保護LSP（S）PLRとMPとの間の保護されたLSPの経路を設けなければならないERO拡張を行うノードからばらばらのままです。この情報は保護されたLSPのRROsから収集することができ、高速リルート[RFC4090]のための迂回オブジェクトでシグナリングおよび他の保護スキームのルート除外[RFC4874]を使用しています。
[RFC4090] describes two methods for local protection for a packet TE LSP in case of link, Shared Risk Link Group (SRLG), or node failure. This section describes how these mechanisms work with the proposed signaling solutions for inter-domain TE LSP setup.
[RFC4090]は、リンク、共有リスクリンクグループ（SRLG）、またはノード障害が発生した場合にパケットTE LSPのために地元の保護のための二つの方法が記載されています。このセクションでは、これらのメカニズムは、ドメイン間TE LSP設定のための提案されたシグナリングソリューションと連携する方法について説明します。
The mode of operation of MPLS-TE Fast Reroute to protect a contiguous, stitched, or nested TE LSP within a domain is identical to the existing procedures described in [RFC4090]. Note that, in the case of nesting or stitching, the end-to-end LSP is automatically protected by the protection operation performed on the H-LSP or stitching segment LSP.
ドメイン内で、連続ステッチ、またはネストされたTE LSPを保護するためのMPLS-TE高速リルートの動作モードは、[RFC4090]に記載の既存の手順と同一です。ネストまたはステッチの場合には、エンドツーエンドのLSPを自動的H-LSPまたはステッチセグメントLSPに対して行わ保護動作によって保護されることに留意されたいです。
No protocol extensions are required.
いいえプロトコル拡張は必要ありません。
This case arises where two domains are connected by a TE link. In this case, each domain has its own domain border node, and these two nodes are connected by the TE link. An example of this case is where the ASBRs of two ASs are connected by a TE link.
二つのドメインは、TEリンクによって接続されている場合、このケースが生じます。この場合、各ドメインは、それ自体のドメイン境界ノードを有し、これらの二つのノードは、TEリンクによって接続されています。 2つのASののASBRは、TEリンクで接続される。この場合の例です。
A contiguous LSP can be backed up using any PLR and MP, but if the LSP uses stitching or nesting in either of the connected domains, the PLR and MP MUST be domain border nodes for those domains. It will be usual to attempt to use the local (connected by the failed link) domain border nodes as the PLR and MP.
連続したLSPは、任意のPLRとMPを使用してバックアップすることができるが、LSPが接続ドメインのいずれかのステッチまたはネストを使用する場合、PLRとMPは、それらのドメインのドメイン境界ノードでなければなりません。 PLRとMPなど（故障したリンクで接続された）ローカルドメインの境界ノードを使用しようとするのが普通だろう。
To protect an inter-domain link with MPLS-TE Fast Reroute, a set of backup tunnels must be configured or dynamically computed between the PLR and MP such that they are diversely routed from the protected inter-domain link and the protected inter-domain LSPs.
MPLS-TE高速リルートを持つドメイン間のリンクを保護するために、バックアップトンネルのセットが設定され、動的にそれらが多様に保護ドメイン間リンクと保護ドメイン間のLSPからルーティングされるようにPLRとMPとの間で計算されなければなりません。
Each protected inter-domain LSP using the protected inter-domain TE link must be assigned to an NHOP bypass tunnel that is diverse from the protected LSP. Such an NHOP bypass tunnel can be selected by analyzing the RROs in the Resv messages of the available bypass tunnels and the protected TE LSP. It may be helpful to this process if the extensions defined in [RFC4561] are used to clearly distinguish nodes and links in the RROs.
保護されたドメイン間のTEリンクを使用して、各保護ドメイン間LSPは、保護LSPから多様でNHOPバイパストンネルに割り当てなければなりません。そのようなNHOPバイパストンネルは、利用可能なバイパストンネルと保護TE LSPのRESVメッセージでRROsを分析することによって選択することができます。 [RFC4561]で定義された拡張機能が明確にRROs内のノードとリンクを区別するために使用されている場合は、このプロセスに役立つかもしれません。
Two border node failure cases exist. If the domain border falls on a link as described in the previous section, the border node at either end of the link may fail. Alternatively, if the border falls on a border node (as is the case with IGP areas), that single border node may fail.
二つの境界ノードの障害のケースが存在します。ドメイン境界は、前のセクションで説明したようにリンク上にある場合、リンクの両端に境界ノードが失敗してもよいです。あるいは、境界は、単一のボーダー・ノードが失敗し得ること、（IGP領域の場合のように）境界ノードに該当する場合。
It can be seen that if stitching or nesting is used, the failed node will be the start or end (or both) of a stitching segment LSP or H-LSP, in which case protection must be provided to the far end of the stitching segment or H-LSP. Thus, where one of these two techniques is in use, the PLR will be the upstream domain entry point in the case of the failure of the domain exit point, and the MP will be the downstream domain exit point in the case of the failure of the domain entry point. Where the domain border falls at a single domain border node, both cases will apply.
ステッチまたはネストが使用される場合、故障したノードは、ケース保護がステッチセグメントの遠端に提供されなければならないステッチセグメントLSPまたはH-LSPの開始または終了（あるいはその両方）であろうことがわかります又はH-LSP。これら二つの技術のいずれかが使用中である場合したがって、PLRは、ドメイン出口点の故障の場合に上流ドメインエントリポイントとなり、MPは、障害が発生した場合に下流のドメインの出口点となりますドメインのエントリポイント。ドメイン境界は、単一のドメイン境界ノードで立ち下がる場合は、両方のケースが適用されます。
If the contiguous LSP mechanism is in use, normal selection of the PLR and MP can be applied, and any node within the domains may be used to fill these roles.
連続LSP機構が使用されている場合、PLRとMPの通常の選択は、適用することができ、ドメイン内の任意のノードは、これらの役割を埋めるために使用されてもよいです。
As before, selection of a suitable backup tunnel (in this case, an NNHOP backup) must consider the paths of the backed-up LSPs and the available NNHOP tunnels by examination of their RROs.
前と同じように、（ここで、NNHOPバックアップ）適切なバックアップトンネルの選択は、それらのRROsの検査によってバックアップLSPの経路及び利用可能なNNHOPトンネルを考慮しなければなりません。
Note that where the PLR is not immediately upstream of the failed node, error propagation time may be delayed unless some mechanism such as [BFD-MPLS] is implemented or unless direct reporting, such as through the GMPLS Notify message [RFC3473], is employed.
PLRは、故障したノードのすぐ上流にない場合、このような[BFD-MPLS]などのいくつかのメカニズムが実装されている又はGMPLSを介して、直接報告は、メッセージ[RFC3473]を通知しない限り、使用されていない限り、エラー伝搬時間が遅延されてもよいことに留意されたいです。
[RFC4873] describes GMPLS-based segment recovery. This allows protection against a span failure, a node failure, or failure over any particular portion of a network used by an LSP.
[RFC4873]はGMPLSベースセグメント回復が記載されています。これは、LSPによって使用されるネットワークの任意の特定の部分にわたってスパン障害、ノード障害、または障害に対する保護を可能にします。
The domain border failure cases described in Section 5.1 may also occur in GMPLS networks (including packet networks) and can be protected against using segment protection without any additional protocol extensions.
セクション5.1で説明したドメイン境界故障例は、（パケットネットワークを含む）GMPLSネットワークで発生する可能性があり、任意の追加のプロトコルの拡張なしでセグメントの保護を用いて保護することができます。
Note that if loose hops are used in the construction of the working and protection paths signaled for segment protection, then care is required to keep these paths disjoint. If the paths are signaled incrementally, then route exclusion [RFC4874] may be used to ensure that the paths are disjoint. Otherwise, a coordinated path computation technique such as that offered by cooperating Path Computation Elements [RFC4655] can provide suitable paths.
ゆるいホップが作業の構築に使用され、保護パスは、セグメント保護の合図をした場合には、注意がばらばらこれらのパスを維持するために必要であることに注意してください。パスが増分シグナリングされる場合、ルート除外[RFC4874]はパスが互いに素であることを確実にするために使用されてもよいです。そうでなければ、そのようなパス計算要素[RFC4655]を協働によって提供されるような協調経路計算技術は、適切なパスを提供することができます。
Reoptimization of a TE LSP is the process of moving the LSP from the current path to a more preferred path. This involves the determination of the preferred path and make-before-break signaling procedures [RFC3209] to minimize traffic disruption.
TE LSPの再最適化は、より好ましい経路に電流経路からLSPを移動するプロセスです。これは、トラフィックの中断を最小限に抑えるために好ましい経路の決意を含み、メークビフォアブレーク手順シグナリング[RFC3209]。
Reoptimization of an inter-domain TE LSP may require a new path in more than one domain.
ドメイン間TE LSPの再最適化は、複数のドメインに新しいパスが必要な場合があります。
The nature of the inter-domain LSP setup mechanism defines how reoptimization can be applied. If the LSP is contiguous, then the signaling of the make-before-break process MUST be initiated by the ingress node as defined in [RFC3209]. But if the reoptimization is limited to a change in path within one domain (that is, if there is no change to the domain border nodes) and nesting or stitching is in use, the H-LSP or stitching segment may be independently reoptimized within the domain without impacting the end-to-end LSP.
ドメイン間LSP設定メカニズムの性質は、再最適化を適用できる方法を定義します。 LSPが連続である場合、[RFC3209]で定義されるように、その後、メーク・ビフォア・ブレーク処理のシグナリングは、入口ノードによって開始されなければなりません。再最適化は、1つのドメイン内経路の変化に限定される（ドメイン境界ノードに変更がない場合には、である）および入れ子又はステッチが使用中である場合には、H-LSPまたはステッチセグメントは、独立して内で再最適化することができますエンド・ツー・エンドのLSPに影響を与えることなくドメイン。
In all cases, however, the ingress LSR may wish to exert control and coordination over the reoptimization process. For example, a transit domain may be aware of the potential for reoptimization, but not bother because it is not worried by the level of service being provided across the domain. But the cumulative effect on the end-to-end LSP may cause the head-end to worry and trigger an end-to-end reoptimization request (of course, the transit domain may choose to ignore the request).
しかし、すべての場合において、入口LSRは、再最適化プロセスを制御および調整を発揮することを望むかもしれません。例えば、トランジットドメインは再最適化のための可能性を認識して、ドメイン間で提供されるサービスのレベルによって心配されていないので気にしないことがあります。しかし、エンド・ツー・エンドのLSP上の累積的影響は心配して（もちろん、トランジットドメインが要求を無視することもできます）、エンドツーエンドの再最適化要求をトリガするヘッドエンドを引き起こす可能性があります。
Another benefit of end-to-end reoptimization over per-domain reoptimization for non-contiguous inter-domain LSPs is that per-domain reoptimization is restricted to preserve the domain entry and exit points (since to do otherwise would break the LSP!). But end-to-end reoptimization is more flexible and can select new domain border LSRs.
非連続的なドメイン間のLSPごとのドメイン再最適化オーバーエンドツーエンドの再最適化のもう一つの利点は、ドメインごとの再最適化は、（そうでない場合はLSPを破るを！やっているので）ドメインの入口と出口のポイントを維持するために制限されていることです。しかし、エンド・ツー・エンドの再最適化は、より柔軟で、新しいドメイン境界のLSRを選択することができます。
There may be different cost-benefit analysis considerations between end-to-end reoptimization and per-domain reoptimization. The greater the number of hops involved in the reoptimization, the higher the risk of traffic disruption. The shorter the segment reoptimized, the lower the chance of making a substantial improvement on the quality of the end-to-end LSP. Administrative policies should be applied in this area with care.
エンド・ツー・エンドの再最適化と、ドメインごとの再最適化の間に別の費用便益分析の考慮事項があるかもしれません。再最適化に関与ホップ数、高トラフィックの中断のリスクが大きいです。短いセグメントは、エンドツーエンドLSPの品質に実質的な改善を作るチャンス低く、再最適化。管理ポリシーは、注意して、この領域に適用されるべきです。
[RFC4736] describes mechanisms that allow:
[RFC4736]は許可メカニズムを説明します。
- The ingress node to request each node with a loose next hop to re-evaluate the current path in order to search for a more optimal path.
- 入口ノードは、より最適な経路を探索するために、電流経路を再評価するために緩い次ホップと各ノードを要求します。
- A node with a loose next hop to inform the ingress node that a better path exists.
- 緩い次のホップのノードは、より良好な経路が存在する入口ノードに通知します。
These mechanisms SHOULD be used for reoptimization of a contiguous inter-domain TE LSP.
これらの機構は、隣接ドメイン間のTE LSPの再最適化のために使用されるべきです。
Note that end-to-end reoptimization may involve a non-local modification that might select new entry / exit points. In this case, we can observe that local reoptimization is more easily and flexibly achieved using nesting or stitching. Further, the "locality principle" (i.e., the idea of keeping information only where it is needed) is best achieved using stitching or nesting. That said, a contiguous LSP can easily be modified to take advantage of local reoptimizations (as defined in [RFC4736]) even if this would require the dissemination of information and the invocation of signaling outside the local domain.
エンド・ツー・エンドの再最適化は、新しい入口/出口ポイントを選択するかもしれない非ローカルの変更を伴う場合があります。この場合、私たちは、地元の再最適化をより簡単かつ柔軟にネスティングやステッチを使用して達成されていることを確認することができます。さらに、「局所性の原則は、」（すなわち、それが必要とされる情報のみを維持するという考えは）最高のステッチやネストを使用して達成されます。それによると、隣接LSPが簡単にこの情報の普及とローカルドメイン外シグナリングの起動を必要とする場合であっても（[RFC4736]で定義されるように）ローカルreoptimizationsを利用するように修正することができます。
The procedures in this document are backward compatible with existing deployments.
このマニュアルの手順は、既存の展開と下位互換性があります。
- Ingress LSRs are not required to support the extensions in this document to provision intra-domain LSPs. The default behavior by transit LSRs that receive a Path message that does not have the "Contiguous LSP" bit set in the Attributes Flags TLV of the LSP_Attributes object or does not even have the object present is to allow all modes of inter-domain TE LSP, so back-level ingress LSRs are able to initiate inter-domain LSPs.
- 入力のLSRは、規定のドメイン内のLSPにこのドキュメントの拡張をサポートする必要はありません。 「連続LSP」を持っていないPathメッセージを受け取るトランジットのLSRによってデフォルトの動作はLSP_AttributesのTLVオブジェクトの属性フラグに設定されたビットまたはさえ存在する物体を持っていないドメイン間TE LSPのすべてのモードを可能にすることですので、バックレベルの入口のLSRは、ドメイン間LSPを開始することができます。
- Transit, non-border LSRs are not required to perform any special processing and will pass the LSP_Attributes object onwards unmodified according to the rules of [RFC2205]. Thus, back-level transit LSRs are fully supported.
- トランジット、非境界のLSRは、特別な処理を実行するために必要とされないとLSP_Attributesは[RFC2205]のルールに従って、以降の非修飾オブジェクトを通過します。このように、バックレベルのトランジットのLSRは完全にサポートされています。
- Domain border LSRs will need to be upgraded before inter-domain TE LSPs are allowed. This is because of the need to establish policy, administrative, and security controls before permitting inter-domain LSPs to be signaled across a domain border. Thus, legacy domain border LSRs do not need to be considered.
- ドメイン境界のLSRは、ドメイン間TEのLSPが許可される前にアップグレードする必要があります。これは、ドメイン国境を越えて合図するためにドメイン間LSPを許可する前に、ポリシー、管理、およびセキュリティコントロールを確立する必要性です。このように、従来のドメイン境界のLSRは考慮する必要はありません。
The RRO additions in this document are fully backward compatible.
このドキュメントのRROの追加は、完全な下位互換性があります。
RSVP does not currently provide for automated key management. [RFC4107] states a requirement for mandatory automated key management under certain situations. There is work starting in the IETF to define improved authentication including automated key management for RSVP. Implementations and deployments of RSVP should pay attention to any capabilities and requirements that are outputs from this ongoing work.
RSVPは現在、自動化されたキー管理のために提供されていません。 [RFC4107]は特定の状況下で、必須自動化された鍵管理のための必要性を述べています。 RSVPのための自動化された鍵管理を含む改良認証を定義するためにIETFに作業開始があります。 RSVPの実装と展開は、この進行中の作業から出力されている任意の機能と要件に注意を払う必要があります。
A separate document is being prepared to examine the security aspects of RSVP-TE signaling with special reference to multi-domain scenarios [MPLS-SEC]. [RFC4726] provides an overview of the requirements for security in an MPLS-TE or GMPLS multi-domain environment.
別の文書は、マルチドメインのシナリオ[MPLS-SEC]に特別な参照してシグナリングRSVP-TEのセキュリティ面を調べるために準備されています。 [RFC4726]はMPLS-TEやGMPLSマルチドメイン環境でのセキュリティのための要件の概要を説明します。
Before electing to utilize inter-domain signaling for MPLS-TE, the administrators of neighboring domains MUST satisfy themselves as to the existence of a suitable trust relationship between the domains. In the absence of such a relationship, the administrators SHOULD decide not to deploy inter-domain signaling, and SHOULD disable RSVP-TE on any inter-domain interfaces.
MPLS-TEのためのドメイン間シグナリングを使用することを選択する前に、隣接するドメインの管理者は、ドメイン間の適切な信頼関係が存在することとして自分自身を満足しなければなりません。このような関係が存在しない場合に、管理者がドメイン間シグナリングを展開するために、任意のドメイン間のインターフェイス上でRSVP-TEを無効にする必要がないことを決定すべきです。
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 FRR, since the MP and PLR should also share the key.
ドメイン間RSVP-TE LSPに信号を送ると、オペレータは、既にRSVP-TE [RFC3209]のために定義されたセキュリティ機能を利用することができます。これは、キーを共有するドメインの間にいくつかの調整を必要とするかもしれない（[RFC2747]及び[RFC3097]を参照）、注意がキーは十分に頻繁に変更されることを保証する必要があります。これは、追加の同期化を伴うことがドメイン境界ノードはMP以来、FRRで保護されなければならないとPLRも鍵を共有する必要があることに注意してください。
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]):
それは別の管理や信頼ドメインを横断するとき、特に、以下のメカニズムがオペレータに提供されるべきドメイン間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メッセージ処理を可能にするメカニズムを。
Additionally, an operator may wish to reduce the signaling interactions between domains to improve security. For example, the operator might not trust the neighboring domain to supply correct or trustable restart information [RFC5063] and might ensure that the availability of restart function is not configured in the Hello message exchange across the domain border. Thus, suitable configuration MUST be provided in an RSVP-TE implementation to enable the operator to control optional protocol features that may be considered a security risk.
また、オペレータは、セキュリティを向上させるためにドメイン間のシグナリング相互作用を低減することを望むかもしれません。例えば、オペレータは、[RFC5063]正しいまたは信頼できる再起動情報を提供するために、隣接するドメインを信頼していない可能性があり、再起動の機能の利用がドメイン境界を横切るHelloメッセージ交換に設定されていないことを確認することがあります。したがって、適切な構成は、セキュリティ上のリスクと考えることができる任意のプロトコル機能を制御するためにオペレータを可能にするために、RSVP-TEの実装で提供されなければなりません。
Some examples of the policies described above are as follows:
次のように上記の方針のいくつかの例は以下のとおりです。
A) An operator may choose to implement some kind of ERO filtering policy on the domain border node to disallow or ignore hops within the domain from being identified in the ERO of an incoming Path message. That is, the policy is that a node outside the domain cannot specify the path of the LSP inside the domain. The domain border LSR can make implement this policy in one of two ways:
A）オペレータは、着信PathメッセージのEROにおいて同定されたドメイン内のホップを許可しない、または無視するドメインの境界ノードのEROフィルタポリシーのいくつかの種類を実装することを選択することができます。つまり、ポリシーは、ドメイン外のノードは、ドメイン内のLSPのパスを指定することができないことです。ドメイン境界LSRは、次のいずれかの方法で、このポリシーを実装することができます。
- It can reject the Path message.
- それは、Pathメッセージを拒否することができます。
- It can ignore the hops in the ERO that lie within the domain.
- それは、ドメイン内にあるEROでホップを無視することができます。
B) In order to preserve confidentiality of network topology, an operator may choose to disallow recording of hops within the domain in the RRO or may choose to filter out certain recorded RRO addresses at the domain border node.
B）ネットワークトポロジーの機密性を維持するために、オペレータは、RROにドメイン内のホップの記録を禁止することを選択することができるか、ドメイン境界ノードで特定の記録されたRROアドレスを除外することを選択することができます。
C) An operator may require the border node to modify the addresses of certain messages like PathErr or Notify originated from hops within the domain.
C）オペレータがのPathErrような特定のメッセージのアドレスを変更したり、ドメイン内のホップ由来通知するために境界ノードを必要とし得ます。
D) In the event of a path computation failure, an operator may require the border node to silently discard the Path message instead of returning a PathErr. This is because a Path message could be interpreted as a network probe, and a PathErr provides information about the network capabilities and policies.
D）経路計算に障害が発生した場合、オペレータは、サイレント代わりのPathErrを返すのPathメッセージを廃棄するように境界ノードを必要とし得ます。 Pathメッセージは、ネットワークプローブとして解釈される可能性があるためである、とのPathErrは、ネットワーク機能やポリシーに関する情報を提供します。
Note that the detailed specification of such policies and their implementation are outside the scope of this document.
詳細なポリシーの仕様とその実装はこの文書の範囲外であることに注意してください。
Operations, Administration, and Management (OAM) mechanisms including [BFD-MPLS] and [RFC4379] are commonly used to verify the connectivity of end-to-end LSPs and to trace their paths. Where the LSPs are inter-domain LSPs, such OAM techniques MAY require that OAM messages are intercepted or modified at domain borders, or are passed transparently across domains. Further discussion of this topic can be found in [INTERAS-PING] and [MPLS-SEC].
[BFD-MPLS]及び[RFC4379]などの操作、管理、および管理（OAM）メカニズムは、一般に、エンドツーエンドのLSPの接続性を確認し、そのパスをトレースするために使用されます。 LSPは、ドメイン間のLSPある場合、このようなOAM技術はOAMメッセージが傍受またはドメイン境界で変更、またはドメイン間で透過的に渡されていることを要求することができます。このトピックについてのさらなる議論は、[インターアクセス-PING]と[MPLS-SEC]に見出すことができます。
IANA has made the codepoint allocations described in the following sections.
IANAは、次のセクションで説明するコードポイントの割り当てを行っています。
A new bit has been allocated from the "Attributes Flags" sub-registry of the "RSVP TE Parameters" registry.
新しいビットが「RSVP TEパラメータ」レジストリの「属性フラグ」のサブレジストリから割り当てられています。
Bit | Name | Attribute | Path | RRO | Reference
No | | Flags Path | Flags Resv | |
----+----------------------+------------+------------+-----+----------
4 Contiguous LSP Yes No Yes [RFC5150]
New RSVP error codes/values have been allocated from the "Error Codes and Globally-Defined Error Value Sub-Codes" sub-registry of the "RSVP Parameters" registry.
新しいRSVPエラーコード/値は、「エラーコードおよびグローバル定義のエラー値サブコード」「RSVPパラメータ」レジストリのサブレジストリから割り当てられています。
For the existing error code "Policy control failure" (value 2), two new error values have been registered as follows:
次のように既存のエラーコード「ポリシー管理の失敗」（値2）については、二つの新しいエラー値が登録されています：
103 = Inter-domain policy failure 104 = Inter-domain explicit route rejected
103 =ドメイン間ポリシーの失敗104 =ドメイン間の明示的なルートは拒否します
For the existing error code "Routing Problem" (value 24), two new error values have been registered as follows:
次のように既存のエラーコード「ルーティングの問題」（値24）のために、二つの新しいエラー値が登録されています：
28 = Contiguous LSP type not supported 29 = ERO conflicts with inter-domain signaling method
28 =連続LSPはドメイン間シグナリング方法29 = EROの競合をサポートしていない入力します
The authors would like to acknowledge the input and helpful comments from Kireeti Kompella on various aspects discussed in the document. Deborah Brungard and Dimitri Papdimitriou provided thorough reviews.
作者は文書で議論される様々な側面についてKireeti Kompellaからの入力や有益なコメントを承認したいと思います。デボラBrungardとディミトリPapdimitriouは、徹底したレビューを提供します。
Thanks to Sam Hartman for detailed discussions of the security considerations.
セキュリティの考慮事項の詳細な議論のためのサム・ハートマンに感謝します。
[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月。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]ブレーデン、R.、エド、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1の機能的な仕様"。、RFC 2205、9月1997。
[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月。
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC4206] Kompella、K.とY. Rekhterは、RFC 4206、2005年10月 "ラベル・パス（LSP）の階層は、一般マルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング（TE）との交換しました"。
[RFC4420] Farrel, A., Ed., Papadimitriou, D., Vasseur, J.-P., and A. Ayyangar, "Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4420, February 2006.
[RFC4420]ファレル、A.編、Papadimitriou、D.、Vasseur、J.-P.、およびA. Ayyangar、「マルチプロトコルラベルスイッチングのための属性のエンコーディング（MPLS）リソース予約を使用したラベルスイッチパス（LSP）の確立をプロトコル - トラフィックエンジニアリング（RSVP-TE）」、RFC 4420、2006年2月。
[RFC5150] Ayyangar, A., Kompella, K., and JP. Vasseur, "Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)", RFC 5150, February 2008.
[RFC5150] Ayyangar、A.、Kompella、K.、およびJP。 Vasseur、RFC 5150、2008年2月「トラフィックエンジニアリング（TE GMPLS）をスイッチング汎用マルチプロトコルラベルとラベルスイッチパスのステッチ」。
[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月。
[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月。
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
[RFC4107] Bellovin氏、S.とR. Housley氏、 "暗号鍵管理のためのガイドライン"、BCP 107、RFC 4107、2005年6月。
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, "Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model", RFC 4208, October 2005.
[RFC4208]ツバメ、G.、ドレイク、J.、石松、H.、およびY. Rekhter、「一般化マルチプロトコルラベルスイッチング（GMPLS）ユーザネットワークインタフェース（UNI）：リソース予約プロトコル - トラフィックエンジニアリング（RSVP-TE）オーバレイモデルのサポート」、RFC 4208、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月。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379] Kompella、K.とG.ツバメ、2006年2月、RFC 4379 "を検出マルチプロトコルラベルは（MPLS）データプレーン障害をスイッチ"。
[RFC4561] Vasseur, J.-P., Ed., Ali, Z., and S. Sivabalan, "Definition of a Record Route Object (RRO) Node-Id Sub-Object", RFC 4561, June 2006.
[RFC4561] Vasseur、J.-P.、エド。、アリ、Z.、およびS.シババラン、 "レコードルートオブジェクト（RRO）ノードIDサブオブジェクトの定義"、RFC 4561、2006年6月。
[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月。
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007.
[RFC4873]バーガー、L.、Bryskin、I.、Papadimitriou、D.、およびA.ファレル、 "GMPLSセグメント回復"、RFC 4873、2007年5月。
[RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4874, April 2007.
[RFC4874]リー、CY、ファレル、A.、およびS.デCnodderは、 "ルートの除外 - 拡張をリソースへの予約プロトコル - トラフィックエンジニアリング（RSVP-TE）"、RFC 4874、2007年4月。
[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月。
[BFD-MPLS] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "BFD For MPLS LSPs", Work in Progress, February 2005.
[BFD-MPLS]アガルワル、R.、Kompella、K.、ナドー、T.、およびG.ツバメ、 "MPLSのLSPについてBFD"、進歩、2005年2月に働いています。
[INTERAS-PING] Nadeau, T. and G. Swallow, "Detecting MPLS Data Plane Failures in Inter-AS and inter-provider Scenarios", Work in Progress, October 2006.
[インターアクセス-PING]ナドー、T.、およびG.ツバメ、「インターASおよびインタープロバイダのシナリオでの検出MPLSデータプレーン障害」、進歩、2006年10月に作業。
[RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 5152, February 2008.
[RFC5152] Vasseur、JP。、エド。、Ayyangar、A.編、およびR.張は、 "ドメイン単位の経路計算方法のために確立するドメイン間トラフィックエンジニアリング（TE）ラベル（LSPを）パスの交換しました"、 RFC 5152、2008年2月。
[MPLS-SEC] Fang, L., Ed., Behringer, M., Callon, R., Le Roux, J. L., Zhang, R., Knight, P., Stein, Y., Bitar, N., and R. Graveman., "Security Framework for MPLS and GMPLS Networks", Work in Progress, July 2007.
[MPLS-SEC]牙、L.、エド。、ベーリンガー、M.、Callon、R.、ルルー、JL、張、R.、ナイト、P.、スタイン、Y.、ビタール、N.、およびR 。Graveman。、 "MPLSおよびGMPLSネットワークのセキュリティフレームワーク" が進歩、2007年7月の作業。
[RFC5063] Satyanarayana, A., Ed., and R. Rahman, Ed., "Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart", RFC 5063, October 2007.
[RFC5063] Satyanarayana、A.編、およびR.ラーマン、エド。、RFC 5063、2007年10月、 "GMPLSリソース予約プロトコル（RSVP）グレースフルリスタートへの拡張"。
Authors' Addresses
著者のアドレス
Adrian Farrel Old Dog Consulting
エードリアンファレル古い犬のコンサルティング
EMail: adrian@olddog.co.uk
メールアドレス：adrian@olddog.co.uk
Arthi Ayyangar Juniper Networks 1194 N. Mathilda Avenue Sunnyvale, CA 94089 USA
Arthi Ayyangarジュニパーネットワークスの1194 N.マチルダアベニューサニーベール、CA 94089 USA
EMail: arthi@juniper.net
メールアドレス：arthi@juniper.net
Jean Philippe Vasseur Cisco Systems, Inc. 300 Beaver Brook Road Boxborough , MA - 01719 USA
ジャン・フィリップVasseurシスコシステムズ社300ビーバーブルック・ロードボックスボロー、MA - 01719 USA
EMail: jpv@cisco.com
メールアドレス：jpv@cisco.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に情報を記述してください。