[要約] RFC 5151は、Inter-Domain MPLSおよびGMPLS Traffic Engineeringに関するRSVP-TE拡張の要約と目的を提供します。このRFCの目的は、異なるドメイン間でのトラフィックエンジニアリングをサポートするために、RSVP-TEプロトコルに必要な拡張機能を定義することです。
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.
このドキュメントでは、マルチプロトコルラベルスイッチングエンジニアリング（MPLS-TE）パケットネットワークと一般化されたMPLS（GMPLS）パケットと非パケットネットワークにおけるマルチプロトコルラベルスイッチングエンジニアリング（MPLS-TE）パケットネットワークと非パケットネットワークにおけるリソース予約プロトコルトラフィックエンジニアリング（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, 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]に記載されています。これらの要件の多くは、一般化されたMPL（GMPL）ネットワークにも適用されます。ドメイン間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].
このドキュメントでは、MPLS-TEまたはGMPLSネットワークの複数のドメインにまたがるトラフィックエンジニアリングラベルスイッチ付きパス（TE LSP）のセットアップとメンテナンスのためのリソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）の手順と拡張を提示します。このドキュメントで説明されているシグナル伝達手順は、[RFC3473]で説明されているようにRSVP-TE GMPLS拡張機能を使用するRSVP-TE（[RFC3209]）およびすべてのLSP（パケットおよび非パケット）を使用して確立されたMPLS-TEパケット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]で特定されています。[RFC3209]および[RFC3473]の手順を使用して、隣接するLSPが達成され、すべてのドメインにまたがる単一のエンドツーエンドLSPを作成します。ネストされたLSPは、[RFC4206]で説明されている手法を使用して確立され、各ドメイン全体の別のトンネルにエンドツーエンドLSPを運ぶことができます。ステッチされたLSPは、[RFC5150]の手順を使用して確立され、各ドメインに及ぶ個別のLSPの連結からエンドツーエンドLSPを構築します。
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.
このドキュメントでは、3つのシグナル伝達メカニズムのうち、1つのエンドツーエンドの領土間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：自律システムボーダールーター。1つまたは複数のASリンクを介して、異なるまたは同じサービスプロバイダーのASSを接続するために使用されるルーター。
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バイパストンネル：Next-Hopバイパストンネル。保護された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.
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]で説明されています。ドメイン間TE LSPは、[RFC4726]で説明されている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 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.
実際、[RFC4726]で指摘されているように、これら3つのオプションの任意の組み合わせは、エンドツーエンドのドメイン間LSPの過程で使用できます。つまり、オプションは、ドメインA、トランジットドメインB、C、およびドメインEで終了するエンドツーエンドのドメイン間LSPがLSPを使用できるように、ドメインごとのトランジットオプションと見なす必要があります。ドメインAの侵入からドメインBを介してドメインCとの境界まで隣接するドメインCは、ドメイン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の確立に必要なルーティング拡張およびパス計算手法は範囲外です。輸送LSRの実装は、LSPのみを見ているため、ドメイン間のTE LSPのオプションを認識していません。ドメイン境界LSRの実装では、ドメイン間TE LSPサポートのメカニズムを含めるためにどのメカニズムを決定する必要がありますが、いずれにせよ、これはRSVP-TEのデフォルト動作モードであるため、連続的なドメイン間TE LSPをサポートする必要があります。ネストされたLSPまたはステッチされたLSPのいずれかまたは両方のいずれかまたは両方をサポートできないため、オペレーターのオプションは制限されますが、領域間TELSPの確立を妨げません。
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は必要ありません。TELSPの同じ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].
ネストされた1つ以上のTE LSPは、[RFC4206]に記載されているように、別のTE LSP内にネストされる場合があります。この手法は、1つまたは複数のドメイン間Te LSPをドメイン内階層LSP（H-LSP）にネストするために使用できます。ラベルスタッキングコンストラクトは、パケットネットワークのネストを実現するために使用されます。このドキュメントの残りの部分では、H-LSPという用語は、他のLSPをその中にネストすることを可能にするLSPを参照するために使用されます。H-LSPは、ルーティングプロトコルの同じインスタンス内のTEリンクとして宣伝され、作成されたTEリンクを宣伝するために使用されました。その場合、転送隣接（FA）[RFC4206]です。
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になります。しかし、コントロールプレーンでは、各セグメントは個別のLSP（異なるRSVPセッションを備えた）として信号され、エンドツーエンド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.
説明されている1つ以上のシグナル伝達手法を使用して、エンドツーエンドのドメイン間TE LSPを実現できます。選択は、LSPセットアップ（イングレス）を要求するノードのポリシーの問題と、各ドメインボーダーノードごとにポリシーです。ドメイン間TE LSPのLSPセットアップリクエスト（RSVP-TEパスメッセージ）を受け取ったとき、LSPを連続的に信号するか、それを別のTE LSPにネストまたはステッチするかを決定することは、侵入からのシグナルのパラメーターに依存しますノードとローカルノードの構成上。
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の侵入は、パスメッセージが信号を送られたときにパラメーターを設定することにより、選択をさらに制限する場合があります。
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パスメッセージを受信した場合、パスメッセージをパスに沿って次のノードに転送する前に、次の手順を実行する必要があります。
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. ドメインとドメインの境界ノードにポリシーを適用します。これらのポリシーは、ドメイン間テープの確立を制限する可能性があります。ポリシーの障害が発生した場合、ノードはセットアップに失敗し、エラーコード「ポリシー制御障害」/「ドメイン間ポリシーの障害」を使用して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:
したがって、たとえば、侵入は、LSPの経路を最大の制御を行い、再最適化が行われるときに制御することを望んでいるため、連続したLSPを要求する場合があります。しかし、トランジットドメインのオペレーターは、（たとえば）LSPステッチのみが、オペレーターが自分の制御下で自分のドメインを再現する機会を提供するという理由で正確に許可されていることを決定する場合があります。この場合、トランジットドメインへのエントリで適用されるポリシーは、Patherrメッセージが返され、Ingressには以下の選択肢があります。
- 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].
3. [RFC3209]および[RFC3473]の手順に加えて、セクション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].
パス計算手順は、このドキュメントの範囲外です。[RFC5152]でパス計算オプションが指定されており、別のオプションはパス計算要素（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.
4a。ネスティングまたはステッチの場合、ドメイン間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で説明されているように、この場合のパスメッセージを静かに破棄することを選択できます。
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].
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.
パスまたはRESVメッセージの処理が成功した場合、ドメイン境界ノードは、セクション3.3で説明されているように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:
パスメッセージでドメイン境界ノードが受信するEROは、TE LSPのイングレスノードによって提供され、パスメッセージが伝播されると他のノード（他のドメイン境界ノード）によって更新された可能性があります。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.
パスメッセージがドメインの境界ノードに到達すると、次のルールが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処理に関連するポリシーがある場合は、それらを適用する必要があり、対応するアクションを実行する必要があります。たとえば、ドメイン内のノードを識別するEROSを拒否するポリシーがある場合があります。ERO処理に関連するポリシー障害に起因するドメイン間LSPセットアップの障害の場合、ノードはエラーコード「ポリシー制御障害」/「ドメイン間の明示的なルートを拒否する」でPatherrを発行する必要がありますが、静かに廃棄するように構成される場合があります。パスメッセージまたはセキュリティ上の理由で異なるエラーコードを返す。
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.
2. [RFC4206]のセクション8.2では、地域の端にあるノードが着信パスメッセージでEROを処理し、このEROを使用して既存のH-LSPを見つけたり、EROホップを使用して新しいH-LSPを信号したりする方法について説明します。このプロセスには、次のホップにパスメッセージを送信する前にEROを調整することが含まれます。これらの手順には、ドメイン間テープのネストまたはステッチのために従う必要があります。
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リンクを識別した場合、隣接するシグナルは使用してはなりません。ノードは、TEリンクを形成するLSPの機能、パスメッセージで信号を送信したパラメーター、およびローカルポリシーに従って、ネストまたはステッチのいずれかを使用する必要があります。EROに示されているTEリンクを形成するLSPの機能とパスメッセージのパラメーターの間に競合がある場合、ドメイン境界ノードはエラーコード「ルーティング問題」/「EROが相互競合するエラーコード「ルーティング」/「EROが競合する」を送信する必要があります。ドメインシグナリング方法」ですが、パスメッセージを静かに破棄するか、セキュリティ上の理由で異なるエラーコードを返すように構成されている場合があります。
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.
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.
5. ローカルドメインの境界ノードを超えたEROサブオブジェクトがない場合、LSP Egress（RSVPセッションオブジェクトにエンコードされた宛先）は、次のルーズホップとルール4が適用されると見なす必要があります。
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メッセージを送信する必要がありますが、パスメッセージを静かに破棄するか、異なるエラーコードを返すようにドメインの境界ルーターを構成することができます。セキュリティ上の理由。
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 Ingressノードに向かって送信され、問題が報告されます。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を確立するためのさらなる試みを行うことができます。このような試みには、ドメインを介した代替ルートの計算、または異なる下流ドメインの選択が含まれる場合があります。後続の試みが成功した場合、ドメインボーダールーターは保持されたPatherrメッセージを破棄する必要がありますが、その後のすべての試みが失敗した場合、ドメインボーダールーターはPatherrを上流のイングレスノードに送信する必要があります。この後者の場合、ドメインの境界ルーターは、[RFC4920]で説明されているように、さらにクランクバックの詳細と情報集約を提供するために、Patherrメッセージの情報を変更する場合があります。
Crankback rerouting MAY also be used to handle the failure of LSPs after they have been established [RFC4920].
Crankbackの再ルーティングは、LSPが確立された後の障害を処理するためにも使用できます[RFC4920]。
[RFC3209] defines the RRO as an optional object used for loop detection and for providing information about the hops traversed by LSPs.
[RFC3209]は、RROをループ検出およびLSPによって横断するホップに関する情報を提供するために使用されるオプションのオブジェクトとして定義します。
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.
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]で定義されている高速リルート手順では、RROの情報を使用して、使用するラベルとダウンストリームMPを決定します。
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.
Notify Requestオブジェクトの通知受信者の交換は、一部の通知メッセージ（たとえば、Ingress 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.
多くのネットワーク環境では、3つのドメイン間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:
このドキュメントでは、TLVの新しいビットを定義します。これは、ドメイン間TE LSPの侵入ノードによって設定して、中間ノードを隣接するシグナル伝達の使用に制限することができます。
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を設定するパスメッセージを発信するIngressノードによって設定されます。このフラグビットは、属性フラグ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）を含むパスメッセージを受信した場合、ノードはセットアップされているドメイン間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.
LSP_ATTRIBUTESオブジェクトと属性フラグTLVをサポートし、「連続したLSP」ビットを認識し、隣接するTE LSPをサポートすることはできない中間ノードは、エラーコード「ルーティング問題」/「隣接するLSPタイプタイプのエラーコードでパスエラーメッセージを送信する必要があります。「サポートされていません」このビットセットでパスメッセージを受信した場合。
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のフラグフィールドに設定された「隣接するLSP」ビットを使用してパスメッセージを受信する中間ノードは、オブジェクト、TLV、およびビットを認識し、目的の隣接するLSPの動作をサポートする場合、隣接するLSPを信号する必要があります。ノードがドメインボーダーノードである場合、またはノードがEROのルーズホップを展開する場合、「隣接するLSP」に対応するRESVメッセージ（そのようなオブジェクトが存在する場合）のrroに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を受信するIngressノードによるアクションの選択は、このドキュメントの範囲外ですが、代替パスの計算が含まれる場合があります。
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からのばらばらのままであるために、ERO拡張を実行するノードは、PLRとMPの間の保護されたLSPのパスを備えている必要があります。この情報は、保護された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の局所保護のための2つの方法を説明しています。このセクションでは、これらのメカニズムが、ドメイン間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.
このケースは、2つのドメインがTEリンクによって接続されている場合に発生します。この場合、各ドメインには独自のドメイン境界ノードがあり、これらの2つのノードはTEリンクによって接続されています。このケースの例は、2つのお尻の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高速ルートとドメイン間リンクを保護するには、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.
保護された各ドメイン間LSPを使用して保護された各ドメイン間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.
2つの境界ノード障害ケースが存在します。前のセクションで説明されているように、ドメインの境界線がリンクに該当する場合、リンクの両端にある境界ノードが失敗する可能性があります。あるいは、境界線が境界線ノード（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。したがって、これら2つの手法のいずれかが使用されている場合、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バックアップ）の選択は、RROを調べてバックアップされた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.
[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).
ただし、すべての場合において、Ingress 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のドメインごとの再最適化を介したエンドツーエンドの再最適化のもう1つの利点は、ドメインごとの再最適化がドメインの入力と出口ポイントを維持するために制限されることです（そうでなければ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で定義されているように））、これが情報の普及とローカルドメインの外側のシグナリングの呼び出しを必要とする場合でも、
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.
- Ingress LSRは、このドキュメントの拡張機能をサポートして、ドメイン内LSPを提供する必要はありません。lsp_attributesオブジェクトの属性フラグTLVに「連続的なLSP」ビットが設定されていないパスメッセージを受信するトランジットLSRによるデフォルトの動作、またはオブジェクトが存在することさえないことは、ドメイン間のすべてのモードを許可することです。、したがって、バックレベルのイングレス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は、特別な処理を実行する必要はなく、[RFC2205]の規則に従ってLSP_ATTRIBUTESオブジェクト以降に渡されます。したがって、バックレベルのトランジット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.
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とPLRもキーを共有する必要があるため、ドメインの境界ノードをFRRで保護する場合、これには追加の同期が含まれる場合があります。
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セットアップ要求（パスメッセージ）を処理する方法。帯域幅、優先度などのさまざまな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 Message Exchangeで構成されていないことを保証する場合があります。したがって、オペレーターがセキュリティリスクと見なされる可能性のあるオプションのプロトコル機能を制御できるように、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）オペレーターは、ドメインの境界ノードに何らかのEROフィルタリングポリシーを実装して、ドメイン内のホップを解消または無視することを選択して、着信パスメッセージのEROで識別されます。つまり、ポリシーは、ドメインの外側のノードがドメイン内のLSPのパスを指定できないということです。ドメインボーダーLSRは、次の2つの方法のいずれかでこのポリシーを実装できます。
- It can reject the Path message.
- パスメッセージを拒否できます。
- 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を返す代わりに、境界ノードにパスメッセージを静かに破棄する必要がある場合があります。これは、パスメッセージがネットワークプローブとして解釈される可能性があり、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メッセージがドメイン境界で傍受または変更されるか、ドメイン全体に透過的に渡される必要があります。このトピックのさらなる議論は、[Interas-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エラーコード/値は、「エラーコードとグローバルに定義されたエラー値サブコード」から割り当てられています。
For the existing error code "Policy control failure" (value 2), two new error values have been registered as follows:
既存のエラーコード「ポリシー制御障害」（値2）の場合、次のように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）の場合、次のように2つの新しいエラー値が登録されています。
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からの入力と有用なコメントを認めたいと考えています。Deborah BrungardとDimitri Papdimitriouは徹底的なレビューを提供しました。
Thanks to Sam Hartman for detailed discussions of the security considerations.
セキュリティ上の考慮事項の詳細な議論をしてくれたSam Hartmanに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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] Braden、R.、Ed。、Zhang、L.、Berson、S.、Herzog、S.、およびS. Jamin、「リソース予約プロトコル（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.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「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] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（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、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング（TE）を備えたラベルスイッチ付きパス（LSP）階層」、RFC 4206、2005年10月。
[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] Farrel、A.、ed。、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、「一般化されたマルチプロトコルラベルスイッチングトラフィックエンジニアリング（GMPLS TE）によるラベルスイッチ付きパスステッチ」、RFC 5150、2008年2月。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747] Baker、F.、Lindell、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] Braden、R。およびL. Zhang、「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] Pan、P.、Ed。、Ed。、Swallow、G.、Ed。、およびA. Atlas、ed。、「LSP TunnelsのRSVP-TEへの拡張速度」、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] Le Roux、J.-L.、ed。、vasseur、J.-P.、ed。、およびJ. Boyle、ed。、「A-A-Area MPLS Traffic Engineeringの要件」、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] Swallow、G.、Drake、J.、Ishimatsu、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] Zhang、R.、ed。、およびJ.-P。Vasseur、ed。、「MPLS Inter-autonomous System（AS）Traffic Engineering（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. Swallow、「Multi-Protocol Label Switched（MPLS）データプレーン障害の検出」、RFC 4379、2006年2月。
[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.、ed。、Ali、Z.、およびS. Sivabalan、「レコードルートオブジェクト（RRO）Node-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] Farrel、A.、Vasseur、J.-P。、およびJ. Ash、「パス計算要素（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] Farrel、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。、ed。、ekejiri、Y。、およびR. Zhang、「マルチプロトコルラベルスイッチング（MPLS）交通工学（TE）の再オプチミー化（TE）ゆるいルーティングラベルスイッチドパス（LSP）」、RFC 4736、2006年11月。
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007.
[RFC4873] Berger、L.、Bryskin、I.、Papadimitriou、D。、およびA. Farrel、「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] Lee、Cy。、Farrel、A。、およびS. de 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] Farrel、A.、ed。、Satyanarayana、A.、Iwata、A.、Fujita、N.、およびG. Ash、「MPLSおよびGMPLS RSVP-TEのクランクバックシグナリング拡張」、2007年7月。
[BFD-MPLS] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "BFD For MPLS LSPs", Work in Progress, February 2005.
[BFD-MPLS] Aggarwal、R.、Kompella、K.、Nadeau、T。、およびG. Swallow、「MPLS LSPSの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.
[Interas-Ping] Nadeau、T。およびG. Swallow、「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.
[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] Fang、L.、Ed。、Behringer、M.、Callon、R.、Le Roux、J。L.、Zhang、R.、Knight、P.、Stein、Y.、Bitar、N。、およびRGraveman。、「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.、ed。、およびR. Rahman、ed。、「GMPLSリソース予約プロトコル（RSVP）Graceful Restartへの拡張」、RFC 5063、2007年10月。
Authors' Addresses
Adrian Farrel Old Dog Consulting
EMail: adrian@olddog.co.uk
Arthi Ayyangar Juniper Networks 1194 N. Mathilda Avenue Sunnyvale, CA 94089 USA
Arthi Ayyangar Juniper Networks 1194 N. Mathilda Avenue Sunnyvale、CA 94089 USA
EMail: arthi@juniper.net
Jean Philippe Vasseur Cisco Systems, Inc. 300 Beaver Brook Road Boxborough , MA - 01719 USA
Jean Philippe Vasseur Cisco Systems、Inc。300 Beaver Brook Road Boxborough、MA -01719 USA
EMail: jpv@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。