[要約] RFC 4873は、GMPLS（Generalized Multiprotocol Label Switching）セグメントの回復に関する標準化された手法を提供します。その目的は、ネットワークの障害が発生した場合に、セグメントの回復を効果的に行うためのガイドラインを提供することです。
Network Working Group L. Berger
Request for Comments: 4873 LabN Consulting
Updates: 3473, 4872 I. Bryskin
Category: Standards Track ADVA Optical
D. Papadimitriou
Alcatel
A. Farrel
Old Dog Consulting
May 2007
GMPLS Segment Recovery
GMPLSセグメントの回復
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
Abstract
概要
This document describes protocol specific procedures for GMPLS (Generalized Multi-Protocol Label Switching) RSVP-TE (Resource ReserVation Protocol - Traffic Engineering) signaling extensions to support label switched path (LSP) segment protection and restoration. These extensions are intended to complement and be consistent with the RSVP-TE Extensions for End-to-End GMPLS Recovery (RFC 4872). Implications and interactions with fast reroute are also addressed. This document also updates the handling of NOTIFY_REQUEST objects.
このドキュメントでは、GMPL（一般化されたマルチプロトコルラベルスイッチング）RSVP-TE（リソース予約プロトコル - トラフィックエンジニアリング）シグナリング拡張機能のプロトコル固有の手順について、ラベルスイッチドパス（LSP）セグメントの保護と復元をサポートします。これらの拡張は、エンドツーエンドGMPLS回復のRSVP-TE拡張機能（RFC 4872）を補完し、一致することを目的としています。Fast Rerouteとの意味と相互作用も対処されています。このドキュメントでは、notify_requestオブジェクトの処理も更新されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Segment Recovery ................................................4
2.1. Segment Protection .........................................6
2.2. Segment Re-routing and Restoration .........................6
3. ASSOCIATION Object ..............................................6
3.1. Format .....................................................7
3.2. Procedures .................................................7
3.2.1. Recovery Type Processing ............................7
3.2.2. Resource Sharing Association Type Processing ........7
4. Explicit Control of LSP Segment Recovery ........................8
4.1. Secondary Explicit Route Object Format .....................8
4.1.1. Protection Subobject ................................8
4.2. Explicit Control Procedures ................................9
4.2.1. Branch Failure Handling ............................10
4.2.2. Resv Message Processing ............................11
4.2.3. Admin Status Change ................................12
4.2.4. Recovery LSP Teardown ..............................12
4.3. Teardown From Non-Ingress Nodes ...........................12
4.3.1. Modified NOTIFY_REQUEST Object Processing ..........13
4.3.2. Modified Notify and Error Message Processing .......14
5. Secondary Record Route Objects .................................14
5.1. Format ....................................................14
5.2. Path Processing ...........................................15
5.3. Resv Processing ...........................................15
6. Dynamic Control of LSP Segment Recovery ........................16
6.1. Modified PROTECTION Object Format .........................16
6.2. Dynamic Control Procedures ................................17
7. Updated RSVP Message Formats ...................................18
8. Security Considerations ........................................20
9. IANA Considerations ............................................21
9.1. New Association Type Assignment ...........................21
9.2. Definition of PROTECTION Object Reserved Bits .............21
9.3. Secondary Explicit Route Object ...........................21
9.4. Secondary Record Route Object .............................21
9.5. New Error Code ............................................22
9.6. Use of PROTECTION Object C-type ...........................22
10. References ....................................................23
10.1. Normative References .....................................23
10.2. Informative References ...................................23
[RFC4427] covers multiple types of protection, including end-to-end and segment-based approaches. "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery" [RFC4872] defines a set of extensions to support multiple types of recovery. The supported types include 1+1 unidirectional/ 1+1 bidirectional protection, LSP protection with extra-traffic (including 1:N protection with extra-traffic), pre-planned LSP re-routing without extra-traffic (including shared mesh), and full LSP re-routing. In all cases, the recovery is provided on an end-to-end basis, i.e., the ingress and egress nodes of both the protected and the protecting LSP are the same.
[RFC4427]は、エンドツーエンドおよびセグメントベースのアプローチなど、複数のタイプの保護をカバーしています。「RSVP-TE拡張エンドツーエンドの一般化マルチプロトコルラベルスイッチング（GMPLS）回復をサポートする」[RFC4872]は、複数のタイプの回復をサポートする一連の拡張機能を定義します。サポートされているタイプには、1 1単方向/ 1 1双方向保護、トラフィック外のLSP保護（1：N保護を含むトラフィック以外の保護を含む）、交通量の多い（共有メッシュを含む）、完全な計画LSPの再ルーティング、および完全なフルLSPの再ルーティング。すべての場合において、回復はエンドツーエンドベースで提供されます。つまり、保護されたLSPと保護LSPの両方の入り口と出口ノードが同じです。
[RFC4090] provides a form of segment recovery for packet MPLS-TE networks. Two methods of fast reroute are defined in [RFC4090]. The one-to-one backup method creates detour LSPs for each protected LSP at each potential point of local repair. The facility backup method creates a bypass tunnel to protect a potential failure point that is shared by multiple LSPs and uses label stacking. Neither approach supports the full set of recovery types supported by [RFC4872]. Additionally, the facility backup method is not applicable to most non-PSC (packet switch capable) switching technologies.
[RFC4090]は、パケットMPLS-TEネットワークのセグメント回復の形式を提供します。高速ルートの2つの方法は、[RFC4090]で定義されています。1対1のバックアップメソッドは、ローカル修理の各潜在的なポイントで保護された各LSPに対して迂回LSPを作成します。施設のバックアップ方法は、複数のLSPで共有され、ラベルスタッキングを使用する潜在的な障害点を保護するために、バイパストンネルを作成します。どちらのアプローチも、[RFC4872]でサポートされている回復タイプの完全なセットをサポートしていません。さらに、施設のバックアップ方法は、ほとんどの非PSC（パケットスイッチ対応）スイッチングテクノロジーには適用できません。
The extensions defined in this document allow for support of the full set of recovery types supported by [RFC4872], but on a segment, or portion of the LSP, basis. The extensions allow (a) the signaling of desired LSP segment protection type, (b) upstream nodes to optionally identify where segment protection starts and stops, (c) the optional identification of hops used on protection segments, and (d) the reporting of paths used to protect an LSP. The extensions also widen the topological scope over which protection can be supported. They allow recovery segments that protect against an arbitrary number of nodes and links. They enable overlapping protection and nested protection. These extensions are intended to be compatible with fast reroute, and in some cases used with fast reroute.
このドキュメントで定義されている拡張機能により、[RFC4872]でサポートされているリカバリタイプの完全なセットをサポートすることができますが、LSPの一部、またはBaseの一部をサポートできます。拡張により、（a）目的のLSPセグメント保護タイプのシグナル、（b）上流ノードがオプションでセグメント保護の開始と停止、（c）保護セグメントで使用されるホップのオプションの識別、および（d）の報告を許可します。LSPを保護するために使用されるパス。拡張機能は、保護をサポートできるトポロジースコープも拡大します。これらは、任意の数のノードとリンクから保護する回復セグメントを許可します。それらは、保護とネストされた保護を重複させることができます。これらの拡張機能は、高速ルートと互換性があり、場合によっては高速再ルートで使用されることを目的としています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
In addition, the reader is assumed to be familiar with the terminology used in [RFC3209], [RFC3471], and [RFC3473], as well as [RFC4427], [RFC4426], [RFC4872], and [RFC4090].
さらに、読者は[RFC3209]、[RFC3471]、および[RFC3473]、および[RFC4427]、[RFC4426]、[RFC4872]、[RFC4872]、および[RFC4090]に使用される用語に精通していると想定されています。
Segment recovery is used to provide protection and restoration over a portion of an end-to-end LSP. Such segment protection and restoration is useful to protect against a span failure, a node failure, or failure over a particular portion of a network used by an LSP.
セグメントの回復は、エンドツーエンドのLSPの一部にわたって保護と回復を提供するために使用されます。このようなセグメントの保護と修復は、LSPが使用するネットワークの特定の部分にわたるスパン障害、ノード障害、または障害から保護するのに役立ちます。
Consider the following topology:
次のトポロジを検討してください。
A---B---C---D---E---F
\ /
G---I
In this topology, end-to-end protection and recovery is not possible for an LSP going between node A and node F, but it is possible to protect/recover a portion of the LSP. Specifically, if the LSP uses a working path of [A,B,C,D,E,F], then a protection or restoration LSP can be established along the path [C,G,I,E]. This LSP protects against failures on spans {C,D} and {D,E}, as well as a failure of node D. This form of protection/restoration is referred to as Segment Protection and Segment Restoration, or as Segment Recovery, collectively. The LSP providing the protection or restoration is referred to as a segment protection LSP or a segment restoration LSP. The term "segment recovery LSP" is used to cover either a segment protection LSP or a segment restoration LSP. The term "branch node" is used to refer to a node that initiates a recovery LSP, e.g., node C in the figure shown above. This is equivalent to the point of local repair (PLR) used in [RFC4090]. As with [RFC4090], the term "merge node" is used to refer to a node that terminates a recovery LSP, e.g., node E in the figure shown above.
このトポロジでは、ノードAとノードFの間を移動するLSPでエンドツーエンドの保護と回復は不可能ですが、LSPの一部を保護/回復することは可能です。具体的には、LSPが[a、b、c、d、e、f]の作業経路を使用する場合、パス[c、g、i、e]の保護または復元LSPを確立できます。このLSPは、スパン{c、d}および{d、e}、およびノードDの障害での障害から保護されます。。保護または修復を提供するLSPは、セグメント保護LSPまたはセグメント修復LSPと呼ばれます。「セグメントリカバリLSP」という用語は、セグメント保護LSPまたはセグメント修復LSPのいずれかをカバーするために使用されます。「Branchノード」という用語は、上記の図のリカバリLSP、たとえばノードCを開始するノードを参照するために使用されます。これは、[RFC4090]で使用されているローカル修理（PLR）に相当します。[RFC4090]と同様に、「マージノード」という用語は、上記の図の回復LSP、たとえばノードEを終了するノードを参照するために使用されます。
Segment protection or restoration is signaled using a working LSP and one or more segment recovery LSPs. Each segment recovery LSP is signaled as an independent LSP. Specifically, the Sender_Template object uses the IP address of the node originating the recovery path, e.g., node C in the topology shown above, and the Session object contains the IP address of the node terminating the recovery path, e.g., node E shown above. There is no specific requirement on LSP ID value, Tunnel ID, and Extended Tunnel ID. Values for these fields are selected normally, including consideration for the make-before-break concept (as described in [RFC3209]). Intermediate nodes follow standard signaling procedures when processing segment recovery LSPs. A segment recovery LSP may be protected itself using segment or end-to-end protection/restoration. Note, in PSC environments, it may be desirable to construct the Sender_Template and Session objects per [RFC4090].
When [RFC4090] isn't being used, the association between segment recovery LSPs with other LSPs is indicated using the ASSOCIATION object defined in [RFC4872]. The ASSOCIATION object is used to associate recovery LSPs with the LSP they are protecting. Working and protecting LSPs, as well as primary and secondary LSPs, are identified using LSP Status as described in [RFC4872]. The O-bit in the segment flags portion of the PROTECTION object is used to identify when a recovery LSP is carrying the normal (active) traffic.
[RFC4090]が使用されていない場合、[RFC4872]で定義された関連付けオブジェクトを使用して、セグメントリカバリLSPと他のLSPとの関連性が示されます。Associationオブジェクトは、リカバリLSPを保護しているLSPと関連付けるために使用されます。[RFC4872]に記載されているように、LSPの動作と保護、および一次および二次LSPは、LSPステータスを使用して特定されます。保護オブジェクトのセグメントフラグ部分のOビットは、回復LSPが通常の（アクティブな）トラフィックを運ぶときに識別するために使用されます。
An upstream node can permit downstream nodes to dynamically identify branch and merge points by setting the desired LSP segment protection bits in the PROTECTION object. These bits are defined below.
アップストリームノードでは、ダウンストリームノードが保護オブジェクトに目的のLSPセグメント保護ビットを設定することにより、ブランチを動的に識別し、ポイントをマージすることができます。これらのビットを以下に定義します。
Optionally, an upstream node, usually the ingress node, can identify the endpoints of a segment recovery LSP. This is accomplished using a new object. This object uses the same format as an Explicit Route Object (ERO) and is referred to as a Secondary Explicit Route object (SERO); see Section 4.1. SEROs also support a new subobject to indicate the type of protection or restoration to be provided. At a minimum, an SERO will indicate a recovery LSP's initiator, protection/restoration type and terminator. Standard ERO semantics (see [RFC3209]) can optionally be used within and SERO to explicitly control the recovery LSP. A Secondary Record Route object (SRRO) is defined for recording the path of a segment recovery LSP; see Section 5.
オプションで、上流ノード（通常はイングレスノード）は、セグメントリカバリLSPのエンドポイントを識別できます。これは、新しいオブジェクトを使用して達成されます。このオブジェクトは、明示的なルートオブジェクト（ERO）と同じ形式を使用し、セカンダリ明示的ルートオブジェクト（SERO）と呼ばれます。セクション4.1を参照してください。SEROSは、提供される保護または修復の種類を示す新しいサブオブジェクトもサポートしています。少なくとも、SEROは、回復LSPのイニシエーター、保護/修復タイプ、ターミネーターを示します。標準のEROセマンティクス（[RFC3209]を参照）をオプションで使用して、回復LSPを明示的に制御するために使用できます。セグメントリカバリLSPのパスを記録するために、セカンダリレコードルートオブジェクト（SRRO）が定義されています。セクション5を参照してください。
SEROs are carried between the node creating the SERO, typically the ingress, and the node initiating a recovery LSP. The node initiating a recovery LSP uses the SERO to create the ERO for the recovery LSP. At this (branch) node, all local objects are removed, and the new protection subobject is used to create the PROTECTION object for the recovery LSP. It is also possible to control the handling of a failure to establish a recovery LSP.
SEROSは、ノードの間に携帯されており、SERO、通常は侵入を作成し、回復LSPを開始するノードが作成されます。リカバリLSPを開始するノードは、SEROを使用してRecovery LSPのEROを作成します。この（分岐）ノードでは、すべてのローカルオブジェクトが削除され、新しい保護サブオブジェクトが使用されて、回復LSPの保護オブジェクトが作成されます。また、回復LSPの確立の失敗の処理を制御することも可能です。
SRROs are carried in Path messages between the node terminating a recovery LSP, the merge node, and the egress. SRROs are used in Resv messages between a branch node and the ingress. The merge node of a recovery LSP creates an SRRO by copying the RRO from the Path message of the associated recovery LSP into a new SRRO object. Any SRROs present in the recovery LSP's Path message are also copied. The branch node of a recovery LSP creates an SRRO by copying the RRO from the Resv message of associated recovery LSP into a new SRRO object. Any SRROs present in the recovery LSP's Resv message are also copied.
SRROSは、回復LSP、マージノード、および出口を終了するノード間のパスメッセージで運ばれます。SRROは、ブランチノードとイングレス間のRESVメッセージで使用されます。リカバリLSPのマージノードは、関連するリカバリLSPのパスメッセージからRROを新しいSRROオブジェクトにコピーすることにより、SRROを作成します。Recovery LSPのパスメッセージに存在するSRROもコピーされます。Recovery LSPの分岐ノードは、関連する回復LSPのRESVメッセージからRROを新しいSRROオブジェクトにコピーすることにより、SRROを作成します。Recovery LSPのRESVメッセージに存在するSRROもコピーされます。
Notify request processing is also impacted by LSP segment recovery. Per [RFC3473], only one NOTIFY_REQUEST object is meaningful and should be propagated. Additional NOTIFY_REQUEST objects are used to identify recovery LSP branch nodes.
通知要求処理は、LSPセグメントの回復の影響も受けます。[rfc3473]に従って、notify_requestオブジェクトは1つだけ意味があり、伝播する必要があります。追加のnotify_requestオブジェクトは、回復LSPブランチノードを識別するために使用されます。
Three approaches for end-to-end protection are defined in [RFC4872]: 1+1 Unidirectional Protection (Section 5), 1+1 Bidirectional Protection (Section 6), and 1:1 Protection With Extra-Traffic (Section 7). The segment protection forms of these protection approaches all operate much like their end-to-end counterparts. Each behaves just like its end-to-end counterpart, with the exception that the protection LSP protects only a portion of the working LSP. The type of protection to be used on a segment protection LSP is indicated, to the protection LSP's ingress, using the protection SERO subobject defined in Section 4.1.
エンドツーエンドの保護のための3つのアプローチは、[RFC4872]で定義されています：1 1単方向保護（セクション5）、1 1の双方向保護（セクション6）、および1：1のトラフィック以降の保護（セクション7）。これらの保護アプローチのセグメント保護フォームはすべて、エンドツーエンドの対応物と同じように機能します。保護LSPが作業LSPの一部のみを保護することを除いて、それぞれがエンドツーエンドの対応物と同じように動作します。セクション4.1で定義されている保護セロサブオブジェクトを使用して、セグメント保護LSPで使用される保護LSPで使用される保護のタイプが、保護LSPの侵入に対して示されています。
The switch-over processing for segment 1+1 Bidirectional protection and 1:1 Protection With Extra-Traffic follows the same procedures as end-to-end protection forms; see Sections 6.2 and 7.2 of [RFC4872] for details.
セグメント1 1のスイッチオーバー処理1 1双方向保護と交通量のない1：1保護は、エンドツーエンドの保護フォームと同じ手順に従います。詳細については、[RFC4872]のセクション6.2および7.2を参照してください。
Three re-routing and restoration approaches are defined in [RFC4872]: Re-routing without Extra-Traffic (Section 8), Shared-Mesh Restoration (Section 9), (Full) LSP Re-routing (Section 11). As with protection, these approaches are supported on a segment basis. The segment forms of re-routing and restoration operate exactly like their end-to-end counterparts, with the exception that the restoration LSP recovers only a portion of the working LSP. The type of re-routing or restoration to be used on a segment restoration LSP is indicated, to the restoration LSP's ingress, using the new protection SERO subobject.
3つの再ルーティングと修復アプローチは、[RFC4872]で定義されています。トラフィック外（セクション8）、共有メッシュの修復（セクション9）、（フル）LSPの再ルーティング（セクション11）なしで再ルーティング。保護と同様に、これらのアプローチはセグメントベースでサポートされています。再ルーティングと修復のセグメント形式は、修復LSPが作業LSPの一部のみを回復することを除いて、エンドツーエンドの対応物とまったく同じように動作します。セグメント復元LSPで使用する再ルーティングまたは復元のタイプは、新しい保護セロサブオブジェクトを使用して、LSPの復元に示されています。
The ASSOCIATION object is used for the association of segment protection LSPs when [RFC4090] isn't being used. The ASSOCIATION object is defined in [RFC4872]. In this document, we define a new Association Type field value to support make-before-break; the formats and procedures defined in [RFC4872] are not otherwise modified.
[RFC4090]が使用されていない場合、アソシエーションオブジェクトはセグメント保護LSPの関連付けに使用されます。アソシエーションオブジェクトは[RFC4872]で定義されています。このドキュメントでは、ブレイク前のメイクをサポートするために、新しいアソシエーションタイプのフィールド値を定義します。[RFC4872]で定義されている形式と手順は、それ以外の場合は変更されません。
Association Type: 16 bits
アソシエーションタイプ：16ビット
Value Type
----- ----
2 Resource Sharing (R)
See [RFC4872] for the definition of other fields and values.
他のフィールドと値の定義については、[RFC4872]を参照してください。
The ASSOCIATION object is used to associate different LSPs with each other. In the protection and restoration context, the object is used to associate a recovery LSP with the LSP it is protecting. The ASSOCIATION object is also used to support resource sharing during make-before-break. This object MUST NOT be used when association is made according to the methods defined in [RFC4090].
アソシエーションオブジェクトは、異なるLSPを互いに関連付けるために使用されます。保護および回復のコンテキストでは、オブジェクトは回復LSPを保護しているLSPに関連付けるために使用されます。アソシエーションオブジェクトは、ブレイク前にリソース共有をサポートするためにも使用されます。このオブジェクトは、[RFC4090]で定義されている方法に従って関連付けを行う場合は使用しないでください。
Recovery type processing procedures are the same as those defined in [RFC4872], but processing and identification occur with respect to segment recovery LSPs. Note that this means that multiple ASSOCIATION objects of type recovery may be present on an LSP.
回復型処理手順は[RFC4872]で定義されている手順と同じですが、セグメントリカバリLSPに関して処理と識別が発生します。これは、型回復の複数の関連性オブジェクトがLSPに存在する可能性があることを意味することに注意してください。
The ASSOCIATION object with an Association Type with the value Resource Sharing is used to enable resource sharing during make-before-break. Resource sharing during make-before-break is defined in [RFC3209]. The defined support only works with LSPs that share the same LSP egress. With the introduction of segment recovery LSPs, it is now possible for an LSP endpoint to change during make-before-break.
バリューリソース共有を持つ関連タイプを持つ関連オブジェクトは、ブレイク前にリソース共有を有効にするために使用されます。ブレイク前のリソース共有は、[RFC3209]で定義されています。定義されたサポートは、同じLSP出力を共有するLSPでのみ機能します。セグメントリカバリLSPの導入により、ブレイク前にLSPエンドポイントが変更されるようになりました。
A node includes an ASSOCIATION object with a Resource Sharing Association Type in an outgoing Path message when it wishes to indicate resource sharing across an associated set of LSPs. The Association Source is set to the originating node's router address. The Association ID MUST be set to a value that uniquely identifies the association of LSPs. This MAY be set to the working LSP's LSP ID. Once included, an ASSOCIATION object with a Resource Sharing Association Type SHOULD NOT be removed from the Path messages associated with an LSP.
ノードには、関連するLSPのセット全体でリソース共有を示したい場合、発信パスメッセージにリソース共有アソシエーションタイプを持つアソシエーションオブジェクトが含まれます。アソシエーションソースは、発信元ノードのルーターアドレスに設定されます。関連付けIDは、LSPの関連付けを一意に識別する値に設定する必要があります。これは、動作するLSPのLSP IDに設定される場合があります。一度含めると、リソース共有関連のタイプを持つアソシエーションオブジェクトは、LSPに関連付けられたパスメッセージから削除しないでください。
Any node processing a Path message for which the node does not have a matching state, and which contains an ASSOCIATION object with a Resource Sharing type, examines existing LSPs for matching Association Type, Association Source, and Association ID values. If any match is found, then [RFC3209] style resource sharing SHOULD be provided between the new and old LSPs. See [RFC3209] for additional details.
ノード処理ノードに一致する状態がなく、リソース共有タイプの関連付けオブジェクトが含まれるパスメッセージを処理するには、一致するアソシエーションタイプ、アソシエーションソース、および関連付けID値の既存のLSPを調べます。一致が見つかった場合は、[RFC3209]スタイルのリソース共有を新しいLSPと古いLSP間で提供する必要があります。詳細については、[RFC3209]を参照してください。
Secondary Explicit Route objects, or SEROs, are defined in this document. They may be used to indicate the branch and merge nodes of recovery LSPs. They may also provide additional information that is to be carried in a recovery LSP's ERO. When upstream control of branch and merge nodes is not desired, SEROs are not used.
このドキュメントでは、二次的な明示的なルートオブジェクト（SERO）が定義されています。それらは、分岐を示し、回復LSPのノードをマージするために使用される場合があります。また、リカバリLSPのEROで運ばれる追加情報を提供する場合があります。ブランチとマージノードの上流制御が望ましくない場合、SEROは使用されません。
The format of a SECONDARY_EXPLICIT_ROUTE object is the same as an EXPLICIT_ROUTE object. This includes the definition of subobjects defined for EXPLICIT_ROUTE object. The class of the SECONDARY_EXPLICIT_ROUTE object is 200 (of the form 11bbbbbb).
seconvorion_explicit_routeオブジェクトの形式は、liblicit_routeオブジェクトと同じです。これには、explicit_routeオブジェクトに対して定義されたサブオブジェクトの定義が含まれます。seconvory_explicit_routeオブジェクトのクラスは200（フォーム11bbbbbbの）です。
A new subobject, called the protection subobject, is defined for use in the SECONDARY_EXPLICIT_ROUTE object. As mentioned above, the new protection subobject is used to create the PROTECTION object for the recovery LSP. Specific procedures related to the protection subobject are provided in Section 4.2. The protection subobject is not valid for use with the Explicit and Record Route objects and MUST NOT be included in those objects.
保護サブオブジェクトと呼ばれる新しいサブオブジェクトは、seconvorion_explicit_routeオブジェクトで使用するために定義されています。上記のように、新しい保護サブオブジェクトを使用して、回復LSPの保護オブジェクトを作成します。保護サブオブジェクトに関連する特定の手順は、セクション4.2に記載されています。保護サブオブジェクトは、明示的なルートオブジェクトとレコードルートオブジェクトでの使用には無効であり、それらのオブジェクトに含める必要はありません。
The format of the protection subobject is defined as follows:
保護サブオブジェクトの形式は、次のように定義されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Reserved | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PROTECTION Object Contents |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L-bit
l-bit
This is defined in [RFC3209] and MUST be set to zero for protection subobjects.
これは[RFC3209]で定義されており、保護サブオブジェクトの場合はゼロに設定する必要があります。
Type
タイプ
37 Protection
37保護
Length
長さ
As defined in [RFC3209], Section 4.3.3.
[RFC3209]で定義されているように、セクション4.3.3。
Reserved
予約済み
This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt.
このフィールドは予約されています。送信時にゼロに設定する必要があり、受領時に無視する必要があります。
C-Type
Cタイプ
The C-Type of the included PROTECTION object.
付属の保護オブジェクトのCタイプ。
PROTECTION Object Contents
保護オブジェクトの内容
The contents of the PROTECTION object, with the format matching the indicated C-Type, excluding the object header.
オブジェクトヘッダーを除く、指定されたCタイプと一致する形式がある保護オブジェクトの内容。
SEROs are carried in Path messages and indicate at which node a recovery LSP is to be initiated relative to the LSP carrying the SERO. More than one SERO MAY be present in a Path message.
SEROSはパスメッセージで運ばれ、どのノードAリカバリLSPがSEROを運ぶLSPに対して開始されるかを示します。パスメッセージには複数のセロが存在する場合があります。
To indicate the branch and merge nodes of a recovery LSP, an SERO is created and added to the Path message of the LSP being recovered. The decision to create and insert an SERO is a local matter and outside the scope of this document.
ブランチを示し、回復LSPのノードをマージするために、SEROが作成され、LSPが回収されているパスメッセージに追加されます。SEROを作成して挿入するという決定は、このドキュメントの範囲外であり、局所的な問題です。
An SERO SHOULD contain at least three subobjects. The first subobject MUST indicate the node that is to originate the recovery LSP, i.e. the segment branch node. The address used SHOULD also be listed in the ERO or another SERO. This ensures that the branch node is along the LSP path. The second subobject SHOULD be a protection subobject and should indicate the protection or restoration to be provided by the recovery LSP. When the protection subobject is present, the LSP Segment Recovery Flags in the protection subobject MUST be ignored. The final subobject in the SERO MUST be the merge node of the recovery LSP, and MAY have the L-bit set. Standard ERO subobjects MAY be inserted between the protection subobject and the final subobject. These subobjects MAY be loose or strict.
SEROには、少なくとも3つのサブオブジェクトを含める必要があります。最初のサブオブジェクトは、回復LSP、つまりセグメントブランチノードを発信するノードを示す必要があります。使用するアドレスは、EROまたは別のSeroにもリストする必要があります。これにより、ブランチノードがLSPパスに沿っていることが保証されます。2番目のサブオブジェクトは保護サブオブジェクトである必要があり、回復LSPによって提供される保護または修復を示す必要があります。保護サブオブジェクトが存在する場合、保護サブオブジェクトのLSPセグメントリカバリフラグを無視する必要があります。Seroの最後のサブオブジェクトは、Recovery LSPのマージノードでなければならず、Lビットセットがある場合があります。標準のEROサブオブジェクトは、保護サブオブジェクトと最終的なサブオブジェクトの間に挿入できます。これらのサブオブジェクトはゆるいまたは厳格である場合があります。
A node receiving a Path message containing one or more SEROs SHOULD examine each SERO to see if it indicates a local branch point. This determination is made by examining the first object of each SERO and seeing if the address indicated in the subobject can be associated with the local node. If any of indicated addresses are associated with the local node, then the local node is a branch node. If the local node is not a branch node, all received SEROs MUST be transmitted, without modification, in the corresponding outgoing Path message.
1つ以上のSEROを含むパスメッセージを受信するノードは、各SEROを調べて、ローカルブランチポイントを示すかどうかを確認する必要があります。この決定は、各Seroの最初のオブジェクトを調べ、サブオブジェクトに示されているアドレスがローカルノードに関連付けられるかどうかを確認することによって行われます。指定されたアドレスのいずれかがローカルノードに関連付けられている場合、ローカルノードはブランチノードです。ローカルノードがブランチノードでない場合、対応する発信パスメッセージで、すべての受信したSEROを変更せずに送信する必要があります。
At a branch node, the SERO, together with the Path message of LSP being recovered, provides the information to create the recovery LSP. The Path message for the recovery LSP is created at the branch node by cloning the objects carried in the incoming Path message of the LSP being protected. Certain objects are replaced or modified in the recovery LSP's outgoing Path message. The Sender_template object MUST be updated to use an address (in its Tunnel Sender Address field) on the local node, and the LSP ID MUST be updated to ensure uniqueness. The Session object MUST be updated to use the address indicated in the final subobject of the SERO as the tunnel endpoint address, the tunnel ID MAY be updated, and the extended tunnel ID MUST be set to the local node address. The PROTECTION object is replaced with the contents of the matching SERO protection subobject, when present. In all cases, the R-bit of a new PROTECTION object is reset (0). Any RROs and EROs present in the incoming Path message MUST NOT be included in the recovery LSP. A new ERO MUST be included, with the contents of the SERO that indicated a local branch. As with all EROs, no local information (local address and any protection subobjects) is carried in the ERO carried in the recovery LSP's outgoing Path message. The SERO that indicated a local branch MUST be omitted from the recovery LSP's outgoing Path message. Note, by default, all other received SEROs are passed in the recovery LSP's outgoing Path message. SEROs MAY be omitted, from the recovery LSP's outgoing Path message as well as the outgoing Path message for the LSP being protected, when the SERO does not relate to the outgoing path message.
ブランチノードでは、SEROは、LSPが回復されるというパスメッセージとともに、回復LSPを作成するための情報を提供します。リカバリLSPのパスメッセージは、保護されているLSPの着信パスメッセージに掲載されたオブジェクトをクローニングすることにより、ブランチノードで作成されます。特定のオブジェクトは、Recovery LSPの発信パスメッセージで交換または変更されます。sender_templateオブジェクトは、ローカルノードでアドレス（トンネル送信者アドレスフィールド）を使用するために更新する必要があり、LSP IDを更新して一意性を確保する必要があります。セッションオブジェクトを更新して、SEROの最終サブオブジェクトに示されているアドレスを使用して、トンネルエンドポイントアドレスとして、トンネルIDを更新し、拡張トンネルIDをローカルノードアドレスに設定する必要があります。保護オブジェクトは、存在するときに一致するSero Protection Subobjectの内容に置き換えられます。すべての場合において、新しい保護オブジェクトのRビットはリセットされます（0）。着信パスメッセージに存在するRROSとEROは、Recovery LSPに含めてはなりません。ローカルブランチを示すSeroの内容とともに、新しいEROを含める必要があります。すべてのEROと同様に、ローカル情報（ローカルアドレスと保護サブオブジェクト）は、Recovery LSPの発信パスメッセージに掲載されたEROで運ばれません。ローカルブランチを示すSeroは、Recovery LSPの発信パスメッセージから省略する必要があります。注意して、デフォルトでは、他のすべての受信したSEROは、RECOVER LSPの発信パスメッセージに渡されます。SEROが発信パスメッセージに関連していない場合、Recovery LSPの発信パスメッセージと、保護されているLSPの発信パスメッセージから、SEROSは省略される場合があります。
The resulting Path message is used to create the recovery LSP. From this point on, Standard Path message processing is used in processing the resulting Path message.
結果のパスメッセージは、回復LSPを作成するために使用されます。この時点から、標準のパスメッセージ処理は、結果のパスメッセージの処理に使用されます。
During setup, it is possible that a processing node will be unable to support a requested branch. Additionally, during setup and normal operation, PathErr messages may be received at a branch node. The processing of these events depend on a number of factors.
セットアップ中、処理ノードが要求されたブランチをサポートできない可能性があります。さらに、セットアップおよび通常の操作中に、Patherrメッセージがブランチノードで受信される場合があります。これらのイベントの処理は、多くの要因に依存します。
When a failure or received PathErr message is associated with the LSP being protected, the event is first processed per standard processing rules. This includes generation of a standard PathErr message. When LSP state is removed due to a local failure or a PathErr message with the Path_State_Removed flag set (1), the node MUST send a PathTear message downstream on all other branches.
障害または受信したPatherrメッセージがLSPが保護されていることに関連付けられている場合、イベントは標準処理ルールごとに最初に処理されます。これには、標準のPatherrメッセージの生成が含まれます。PATH_STATE_REMOVEDフラグセット（1）を使用したローカル障害またはPATHERRメッセージのためにLSP状態が削除される場合、ノードは他のすべてのブランチにPathTearメッセージを下流に送信する必要があります。
When a failure or received PathErr message is associated with a recovery LSP, processing is based on the R-bit in addition to the Path_State_Removed flag. In all cases, a received PathErr message is first processed per standard processing rules and the failure or received PathErr message SHOULD trigger the generation of a PathErr message upstream for the LSP being protected. The outgoing PathErr message SHOULD indicate an error of "Routing Problem/LSP Segment Protection Failed". The outgoing PathErr message MUST include any SEROs carried in a received PathErr message. If no SERO is present in a received PathErr message or when the failure is local, then an SERO that matches the errored LSP or failed branch MUST be added to the outgoing PathErr message.
障害または受信したPatherrメッセージが回復LSPに関連付けられている場合、処理はPATH_STATE_REMOVEDフラグに加えてRビットに基づいています。すべての場合において、受信したpatherrメッセージは最初に標準処理ルールごとに処理され、障害または受信したpatherrメッセージは、保護されているLSPの上流のPatherrメッセージの生成をトリガーするはずです。発信PATHERRメッセージは、「ルーティング問題/LSPセグメント保護が失敗した」というエラーを示す必要があります。発信Patherrメッセージには、受信したPatherrメッセージに掲載されたSerosを含める必要があります。受信したPatherrメッセージにSeroが存在しない場合、または障害がローカルである場合、エラーのあるLSPまたは失敗したブランチに一致するSeroを発信Patherrメッセージに追加する必要があります。
When a PathErr message with the Path_State_Removed flag cleared (0) is received, the outgoing (upstream) PathErr message SHOULD be sent with the Path_State_Removed flag cleared (0).
path_state_removedフラグがクリアされた（0）を使用したpatherrメッセージが受信されると、path_state_removedフラグがクリア（0）で送信（上流）patherrメッセージを送信する必要があります。
When a PathErr message for a recovery LSP with the Path_State_Removed flag set (1) is received, the processing node MUST examine the R-bit (as defined below) of the LSP being protected. The R-bit is carried in the PROTECTION object that triggered the initiation of the recovery LSP. When the R-bit is not set (0), the outgoing (upstream) PathErr message SHOULD be sent with the Path_State_Removed flag cleared (0). When the R-bit is set (1), the outgoing (upstream) PathErr message MUST be sent with the Path_State_Removed flag set (1).
Path_State_Removedフラグセット（1）を使用したリカバリLSPのPatherrメッセージが受信されると、処理ノードは保護されているLSPのRビット（以下に定義）を調べる必要があります。R-BITは、回復LSPの開始をトリガーした保護オブジェクトに搭載されています。r-bitが設定されていない場合（0）、発信（上流）patherrメッセージをpath_state_removedフラグをクリアして送信する必要があります（0）。Rビットが設定されている場合（1）、発信（上流）patherrメッセージをpath_state_removedフラグセット（1）で送信する必要があります。
In all cases where an outgoing (upstream) PathErr message is sent with the Path_State_Removed flag set (1), all path state for the LSP being protected MUST be removed, and the node MUST send a PathTear message downstream on all active branches.
Path_State_Removedフラグセット（1）で発信（上流の）PATHERRメッセージが送信されるすべての場合において、保護されているLSPのすべてのパス状態を削除する必要があり、ノードはすべてのアクティブなブランチにPathTearメッセージを下流に送信する必要があります。
Branch nodes will process Resv messages for both recovery LSPs and LSPs being protected. Resv messages are propagated upstream of branch nodes only after a Resv message is received for the protected LSP. Resv messages on recovery LSPs will typically not trigger transmission of upstream Resv messages (for the LSP being protected). Exceptions to this include when RROs/SRROs are being collected and during certain ADMIN_STATUS object processing. See below for more information on related processing.
ブランチノードは、回復LSPとLSPの両方のRESVメッセージを処理します。RESVメッセージは、保護されたLSPに対してRESVメッセージが受信された後にのみ、分岐ノードの上流に伝播されます。リカバリLSPに関するRESVメッセージは、通常、上流のRESVメッセージの送信をトリガーしません（LSPの保護されています）。これの例外には、RROS/SRROが収集されている場合、および特定のadmin_Statusオブジェクト処理中に含まれます。関連処理の詳細については、以下を参照してください。
In general, objects in a recovery LSP are created based on the corresponding objects in the LSP being protected. The ADMIN_STATUS object is created the same way, but it also requires some special coordination at branch nodes. Specifically, in addition to normal processing, a branch node that receives an ADMIN_STATUS object in a Path message also MUST relay the ADMIN_STATUS object in a Path on every recovery LSP. All Path messages MAY be concurrently sent downstream.
Downstream nodes process the change in the ADMIN_STATUS object per [RFC3473], including generation of Resv messages. When the most recently received upstream ADMIN_STATUS object has the R bit set, branch nodes wait for a Resv message with a matching ADMIN_STATUS object to be received on all branches before relaying a corresponding Resv message upstream.
ダウンストリームノードは、RESVメッセージの生成を含む[RFC3473]ごとにAdmin_Statusオブジェクトの変更を処理します。最近受信したアップストリームAdmin_StatusオブジェクトにRビットが設定されている場合、ブランチノードは、対応するRESVメッセージを上流にリレーする前に、すべてのブランチで一致するadmin_Statusオブジェクトを備えたRESVメッセージを待機します。
Recovery LSP removal follows standard procedures defined in [RFC3209] and [RFC3473]. This includes with and without setting the administrative status.
回復LSP除去は、[RFC3209]および[RFC3473]で定義された標準手順に従います。これには、管理ステータスを設定する場合と使用せずに含まれます。
The node initiating the teardown originates a PathTear message. Each node that receives a PathTear message processes the PathTear message per standard processing (see [RFC3209] and [RFC2205]), and MUST also relay a PathTear on every recovery LSP. All PathTear messages (received from upstream and locally originated) may be concurrently sent downstream.
分解を開始するノードは、PATHTEARメッセージを発信します。PATHTEARメッセージを受信する各ノードは、標準処理ごとにPATHTEARメッセージを処理し（[RFC3209]および[RFC2205]を参照）、すべての回復LSPにPATHTEARを中継する必要があります。すべてのPATHTEARメッセージ（上流および局所から受信された）は、同時に下流に送信される場合があります。
Per [RFC3473], the ingress node originates a Path message with the D and R bits set in the ADMIN_STATUS object. The admin status change procedure defined in Section 4.2.3 MUST then be followed. Once the ingress receives all expected Resv messages, it MUST follow the teardown procedure described in Section 4.2.4.1.
[RFC3473]に従って、イングレスノードは、admin_statusオブジェクトに設定されたdおよびrビットを使用してパスメッセージを発信します。セクション4.2.3で定義されている管理者ステータス変更手順に従う必要があります。Ingressが予想されるすべてのRESVメッセージを受信したら、セクション4.2.4.1で説明されている分解手順に従う必要があります。
As with any LSP, any node along a recovery LSP may initiate removal of the recovery LSP. To do this, the node initiating the teardown sends a PathErr message with the appropriate Error Code and the Path_State_Removed flag cleared (0) toward the LSP ingress. As described above, the recovery LSP ingress will propagate the error to the LSP ingress, which can then signal the removal of the recovery LSP.
他のLSPと同様に、回復LSPに沿ったノードは、回復LSPの除去を開始する場合があります。これを行うために、断脱走を開始するノードは、適切なエラーコードを使用してPatherrメッセージを送信し、PATH_STATE_REMOVEDフラグがLSPイングレスに向かってクリアされました（0）。上記のように、Recovery LSP IngressはLSP Ingressにエラーを伝播し、リカバリLSPの除去を示すことができます。
It is also possible for the node initiating the teardown to remove a Recovery LSP in a non-graceful manner. In this case, the initiator sends a PathTear message downstream and a PathErr message with a "Confirmation" indication (error code and value set to zero), and the Path_State_Removed flag set (1) toward the LSP ingress node. This manner of non-ingress node teardown is NOT RECOMMENDED because in some cases it can result in the removal of the LSP being protected.
また、ノードが分解物を開始して、不利な方法で回復LSPを除去することも可能です。この場合、イニシエーターは、下流のPathTearメッセージと「確認」表示（エラーコードと値がゼロに設定）を備えたPatherRメッセージを送信し、PATH_STATE_REMOVEDフラグセット（1）をLSP Ingressノードに向けて送信します。この方法の非炎症ノードの断片は、LSPが保護されている場合があるため、推奨されません。
A parallel set of rules are applied at branch and merge nodes to enable the branch or merge node to add a NOTIFY_REQUEST object to the Path and Resv messages of protected and recovery LSPs. Branch nodes add NOTIFY_REQUEST objects to Path messages, and merge nodes add NOTIFY_REQUEST objects to Resv messages.
ブランチとマージノードに一連のルールセットが適用され、ブランチを有効にするか、ノードをマージできるように、保護されたリカバリLSPのパスおよびRESVメッセージにnotify_requestオブジェクトを追加します。ブランチノードは、notify_requestオブジェクトをパスメッセージに追加し、ノードをマージし、notify_requestオブジェクトをRESVメッセージにマージします。
When a node is branching or merging a recovery LSP, the node SHOULD include a single NOTIFY_REQUEST object in the Path message of the recovery LSP, in the case of a branch node, or the Resv message of the recovery LSP, in the case of a merge node. The notify node address MUST be set to the router address of the processing node.
Branch and merge nodes SHOULD also add a NOTIFY_REQUEST object to the LSP being protected. For branch nodes, the notify node address is set to the address used in the sender template object of the associated recovery LSP. For merge nodes, the notify node address is set to the address used in the session object of the associated recovery LSP. A locally added NOTIFY_REQUEST object MUST be listed first in an outgoing message; any received NOTIFY_REQUEST objects MUST then be listed in the message in the order that they were received. Note that this can result in a stack (or ordered list) of objects.
ブランチとマージノードは、保護されているLSPにnotify_requestオブジェクトを追加する必要があります。ブランチノードの場合、Notifyノードアドレスは、関連するリカバリLSPの送信者テンプレートオブジェクトで使用されるアドレスに設定されます。マージノードの場合、Notifyノードアドレスは、関連するリカバリLSPのセッションオブジェクトで使用されるアドレスに設定されます。ローカルに追加されたnotify_requestオブジェクトは、最初に発信メッセージにリストする必要があります。受信したnotify_requestオブジェクトは、受信された順序でメッセージにリストされている必要があります。これにより、オブジェクトのスタック（または順序付けられたリスト）が得られる可能性があることに注意してください。
Normal notification procedures are then followed for the LSP being protected. That is, the notifying node MUST issue a Notify message to the recipient indicated by the notify address of the first listed NOTIFY_REQUEST object. Under local policy control, a node issuing a Notify message MAY also send a Notify message to the Notify Node Address indicated in the last, or any other, NOTIFY_REQUEST object carried in the Path or Resv message.
その後、LSPが保護されている場合、通常の通知手順に従います。つまり、通知ノードは、最初にリストされたnotify_requestオブジェクトの通知アドレスで示される受信者に通知メッセージを発行する必要があります。ローカルポリシー制御の下で、Notifyメッセージを発行するノードは、パスまたはRESVメッセージに掲載された最後に示されているNotify Nodeアドレスまたはその他のnotify_requestオブジェクトに通知メッセージを送信する場合があります。
Recovery LSP merge and branch nodes remove the object added by the recovery branch or merge node from outgoing Path and Resv messages for the LSP being protected. This is done by removing the NOTIFY_REQUEST object that, in the case of a merge node, matches the source address of the recovery LSP and, in the case of a branch node, matches the tunnel endpoint address of the recovery LSP. The matching NOTIFY_REQUEST object will normally be the first of the listed NOTIFY_REQUEST objects. Note, to cover certain backwards compatibility scenarios, the NOTIFY_REQUEST object SHOULD NOT be removed if it is the sole NOTIFY_REQUEST object.
Recovery LSP Merge and Branch Nodes Recovery BranchまたはMerge Nodeから追加されたオブジェクトを削除し、保護されているLSPの発信パスとRESVメッセージからノードをマージします。これは、マージノードの場合、回復LSPのソースアドレスと一致し、分岐ノードの場合、回復LSPのトンネルエンドポイントアドレスと一致するnotify_requestオブジェクトを削除することによって行われます。一致するnotify_requestオブジェクトは、通常、リストされているnotify_requestオブジェクトの最初のオブジェクトです。注意して、特定の後方互換性シナリオをカバーするために、Sole notify_requestオブジェクトである場合、notify_requestオブジェクトを削除しないでください。
Note this requires the following change to [RFC3473], Section 4.2.1:
これには、[RFC3473]、セクション4.2.1への次の変更が必要です。
o old text: If a message contains multiple NOTIFY_REQUEST objects, only the first object is meaningful. Subsequent NOTIFY_REQUEST objects MAY be ignored and SHOULD NOT be propagated.
o 古いテキスト：メッセージに複数のnotify_requestオブジェクトが含まれている場合、最初のオブジェクトのみが意味があります。後続のNotify_Requestオブジェクトは無視される場合があり、伝播しないでください。
o new text: If a message contains multiple NOTIFY_REQUEST objects, only the first object used is in notification. Subsequent NOTIFY_REQUEST objects MUST be propagated in the order received.
o 新しいテキスト：メッセージに複数のnotify_requestオブジェクトが含まれている場合、使用される最初のオブジェクトのみが通知にあります。後続のnotify_requestオブジェクトは、受信した順序で伝播する必要があります。
Branch and merge nodes MUST support the following modification to Notify message processing. When a branch or merge node receives notification of an LSP failure and it is unable to recover from that failure, it MUST notify the node indicated in the first NOTIFY_REQUEST object received in the Path message (for branch nodes) or Resv message (for merge nodes) associated with the LSP.
ブランチとマージノードは、メッセージ処理を通知するために次の変更をサポートする必要があります。ブランチまたはマージノードがLSP障害の通知を受信し、その障害から回復できない場合、パスメッセージで受信した最初のnotify_requestオブジェクトに示されているノードに通知する必要があります（ブランチノード用）またはRESVメッセージ（マージノード用）LSPに関連付けられています。
Secondary Record Route objects, or SRROs, are used to record the path used by recovery LSPs.
二次レコードルートオブジェクト、またはSRROSは、回復LSPで使用されるパスを記録するために使用されます。
The format of a SECONDARY_RECORD_ROUTE object is the same as a RECORD_ROUTE object, Class number 21. This includes the definition of subobjects defined for RECORD_ROUTE object. The class of the SECONDARY_RECORD_ROUTE object is 201 (of the form 11bbbbbb).
secondary_record_routeオブジェクトの形式は、record_routeオブジェクト、クラス番号21と同じです。これには、record_routeオブジェクトに定義されたサブオブジェクトの定義が含まれます。Secondary_Record_Routeオブジェクトのクラスは201（フォーム11bbbbbbの）です。
The protection subobject defined above can also be used in SECONDARY_RECORD_ROUTE objects.
上記の保護サブオブジェクトは、seconvory_record_routeオブジェクトでも使用できます。
SRROs may be carried in Path messages and indicate the presence of upstream recovery LSPs. More than one SRRO MAY be added and present in a Path message.
SRROSはパスメッセージに携帯されており、上流の回復LSPの存在を示している場合があります。パスメッセージに複数のSRROが追加され、存在する場合があります。
Any received SRRO MUST be transmitted by transit nodes, without modification, in the corresponding outgoing Path message.
受信したSRROは、対応する発信パスメッセージで、変更なしでトランジットノードによって送信する必要があります。
SRROs are inserted in Path messages by recovery LSP merge nodes. The SRRO is created by copying the contents of an RRO received by the recovery LSP into a new SRRO object. This SRRO is added to the outgoing Path message of the recovered LSP. Note that multiple SRROs may be present. The collection of SRROs is controlled via the segment-recording-desired flag in the SESSION_ATTRIBUTE object. This flag MAY be set even when SEROs are not used.
SRROSは、回復LSPマージノードによってパスメッセージに挿入されます。SRROは、回復LSPによって受信されたRROの内容を新しいSRROオブジェクトにコピーすることにより作成されます。このSRROは、回復したLSPの発信パスメッセージに追加されます。複数のSRROが存在する可能性があることに注意してください。SRROSのコレクションは、Session_Attributeオブジェクトのセグメント録音デザインフラグを介して制御されます。このフラグは、Serosが使用されていない場合でも設定される場合があります。
SRROs may be carried in Resv messages and indicate the presence of downstream recovery LSPs. More than one SRRO MAY be added and present in a Resv message.
Any received SRRO MUST be transmitted by transit nodes, without modification, in the corresponding outgoing Resv message. When Resv messages are merged, the resulting merged Resv SHOULD contain all SRROs received in downstream Resv messages.
受信したSRROは、対応する発信RESVメッセージで、変更なしでトランジットノードによって送信する必要があります。RESVメッセージがマージされた場合、結果のマージされたRESVには、下流のRESVメッセージで受信されたすべてのSRROSを含める必要があります。
SRROs are inserted in Resv messages by branch nodes of recovery LSPs. The SRRO SHOULD be created with the first two objects being the local node address, followed by a protection subobject with the contents of the recovery LSP's PROTECTION object. The remainder of the SRRO SHOULD be created by copying the contents of the RRO received by the recovery LSP. This SRRO SHOULD be added to the outgoing Resv message of the recovered LSP. Again, multiple SRROs may be present.
SRROSは、回復LSPの分岐ノードによってRESVメッセージに挿入されます。SRROは、最初の2つのオブジェクトがローカルノードアドレスであることで作成され、その後、Recovery LSPの保護オブジェクトの内容を持つ保護サブオブジェクトが続きます。SRROの残りの部分は、回復LSPで受信したRROの内容をコピーすることで作成する必要があります。このSRROは、回復したLSPの発信RESVメッセージに追加する必要があります。繰り返しますが、複数のSRROが存在する場合があります。
If the newly added SRRO causes the message to be too big to fit in a Resv message, SRRO subobjects SHOULD be removed from any present SRROs. When removing subobjects, the first two subobjects and the last subobject in an SRRO MUST NOT be removed. Note that the subobject that followed a removed subobject MUST be updated with the L-bit set (1). If after removing all but the first and last subobjects in all SRROs the resulting message is still too large to fit, then whole SRROs SHOULD be removed until the message does fit.
新しく追加されたSRROがメッセージをRESVメッセージに収めるには大きすぎる場合、SRROサブオブジェクトを現在のSRROから削除する必要があります。サブオブジェクトを削除する場合、最初の2つのサブオブジェクトとSRROの最後のサブオブジェクトを削除する必要はありません。削除されたサブオブジェクトに続いたサブオブジェクトは、Lビットセット（1）で更新する必要があることに注意してください。すべてのSRROで最初と最後のサブオブジェクトを除くすべてを削除した後、結果のメッセージがまだ大きすぎて収まるには削除される必要があります。
Dynamic identification of branch and merge nodes is supported via the LSP Segment Recovery Flags carried in the PROTECTION object. The LSP Segment Recovery Flags are carried within one of the Reserved fields defined in the PROTECTION object defined in [RFC4872]. LSP Segment Recovery Flags are used to indicate when LSP segment recovery is desired. When these bits are set, branch and merge nodes are dynamically identified.
ブランチとマージノードの動的識別は、保護オブジェクトに掲載されたLSPセグメントリカバリフラグを介してサポートされます。LSPセグメントの回復フラグは、[RFC4872]で定義されている保護オブジェクトで定義されている予約済みフィールドの1つ内に運ばれます。LSPセグメントの回復フラグは、LSPセグメントの回復が必要な時期を示すために使用されます。これらのビットが設定されると、ブランチとマージノードが動的に識別されます。
Note, the procedures defined in this section parallel the explicit control procedures defined above in Section 4.2. The primary difference is in the creation of a recovery LSP's ERO.
このセクションで定義されている手順は、セクション4.2で上記で定義された明示的な制御手順と並行しています。主な違いは、リカバリLSPのEROの作成です。
LSP Segment Recovery Flags are carried in the PROTECTION object of the same C-Type defined in [RFC4872]. The format of the flags are:
LSPセグメントリカバリフラグは、[RFC4872]で定義されている同じC型の保護オブジェクトに搭載されています。フラグの形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(37) | C-Type (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|P|N|O| Reserved | LSP Flags | Reserved | Link Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I|R| Reserved | Seg.Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In-Place (I): 1 bit
In-Place（i）：1ビット
When set (1) indicates that the desired segment recovery type indicated in the LSP Segment Recovery Flag is already in place for the associated LSP.
設定された場合（1）は、LSPセグメントリカバリフラグに示されている目的のセグメントリカバリタイプが、関連するLSPに対してすでに導入されていることを示します。
Required (R): 1 bit
必須（r）：1ビット
When set (1) indicates that failure to establish the indicated protection should result in a failure of the LSP being protected.
Segment Recovery Flags (Seg.Flags): 6 bits
セグメントリカバリフラグ（SEG.FLAGS）：6ビット
This field is used to indicate when an upstream node desires LSP Segment recovery to be dynamically initiated where possible. The values used in this field are identical to the values defined for LSP Flags; see [RFC4872].
このフィールドは、上流ノードがLSPセグメントの回復を可能な限り動的に開始することを望むときを示すために使用されます。このフィールドで使用される値は、LSPフラグで定義された値と同一です。[RFC4872]を参照してください。
See [RFC4872] for the definition of other fields.
他のフィールドの定義については、[RFC4872]を参照してください。
LSP Segment Recovery Flags are set to indicate that LSP segment recovery is desired for the LSP being signaled. The type of recovery desired is indicated by the flags. The decision to set the LSP Segment Recovery Flags is a local matter and outside the scope of this document. A value of zero (0) means that no dynamic identification of segment recovery branch nodes are needed for the associated LSP. When the In-Place bit is set, it means that the desired type of recovery is already in place for that particular LSP.
LSPセグメントの回復フラグは、LSPが信号を送信するためにLSPセグメントの回復が望ましいことを示すように設定されています。必要な回復のタイプは、フラグによって示されます。LSPセグメントリカバリフラグを設定する決定は、ローカルな問題であり、このドキュメントの範囲外です。ゼロ（0）の値は、関連するLSPにセグメントリカバリブランチノードの動的識別が必要ないことを意味します。インプレースビットが設定されている場合、その特定のLSPに対して、目的のタイプの回復がすでに整っていることを意味します。
A transit node receiving a Path message containing a PROTECTION object with a non-zero LSP Segment Recovery Flags value and the In-Place bit clear (0) SHOULD consider if it can support the indicated recovery type and if it can identify an appropriate merge node for a recovery LSP. Dynamic identification MUST NOT be done when the processing node is identified as a branch node in an SERO. If a node is unable to provide the indicated recovery type or identify a merge node, the Path message MUST be processed normally, and the LSP Segment Recovery Flags MUST NOT be modified.
ゼロ以外のLSPセグメントリカバリフラグ値を持つ保護オブジェクトを含むパスメッセージを受信するトランジットノードは、指定されたリカバリタイプをサポートできるかどうか、適切なマージノードを識別できるかどうかを検討する必要があります。回復用lsp。処理ノードがSEROのブランチノードとして識別される場合、動的識別を実行しないでください。ノードが指定された回復タイプを提供したり、マージノードを識別できない場合、パスメッセージは正常に処理する必要があり、LSPセグメントリカバリフラグを変更する必要はありません。
When a node dynamically identifies itself as a branch node and identifies the merge node for the type of recovery indicated in the LSP Segment Recovery Flags, it attempts to setup a recovery LSP. The dynamically identified information, together with the Path message of LSP being recovered, is used to create the recovery LSP.
ノードが自体をブランチノードとして動的に識別し、LSPセグメントリカバリフラグに示されているリカバリのタイプのマージノードを識別すると、リカバリLSPをセットアップしようとします。動的に識別された情報は、LSPが回復されるというパスメッセージとともに、回復LSPを作成するために使用されます。
The Path message for the recovery LSP is created at the branch node by cloning the objects carried in the incoming Path message of the LSP being protected. Certain objects are replaced or modified in the recovery LSP's outgoing Path message. The Sender_template object MUST be updated to use an address (in its Tunnel Sender Address field) on the local node, and the LSP ID MUST be updated to ensure uniqueness. The Session object MUST be updated to use the address of the dynamically identified merge node as the tunnel endpoint address, the tunnel ID MAY be updated, and the extended tunnel ID MUST be set to the local node address. The PROTECTION object is updated with the In-Place bit set (1). Any RROs and EROs present in the incoming Path message MUST NOT be included in the recovery LSP. A new ERO MAY be created based on any path information dynamically computed by the local node.
リカバリLSPのパスメッセージは、保護されているLSPの着信パスメッセージに掲載されたオブジェクトをクローニングすることにより、ブランチノードで作成されます。特定のオブジェクトは、Recovery LSPの発信パスメッセージで交換または変更されます。sender_templateオブジェクトは、ローカルノードでアドレス（トンネル送信者アドレスフィールド）を使用するために更新する必要があり、LSP IDを更新して一意性を確保する必要があります。セッションオブジェクトは、動的に識別されたマージノードのアドレスをトンネルエンドポイントアドレスとして使用するために更新する必要があります。トンネルIDを更新し、拡張トンネルIDをローカルノードアドレスに設定する必要があります。保護オブジェクトは、インプレースビットセット（1）で更新されます。着信パスメッセージに存在するRROSとEROは、Recovery LSPに含めてはなりません。ローカルノードによって動的に計算されたパス情報に基づいて、新しいEROを作成できます。
The resulting Path message is used to create the recovery LSP. While the recovery LSP exists, the PROTECTION object in the original Path message (unless overridden by local policy) MUST also be updated with the In-Place bit set (1). From this point on, Standard Path message processing is used in processing the resulting and original Path messages.
結果のパスメッセージは、回復LSPを作成するために使用されます。回復LSPが存在しますが、元のパスメッセージの保護オブジェクト（ローカルポリシーによってオーバーライドされていない限り）も、インプレースビットセット（1）で更新する必要があります。この時点から、標準のパスメッセージ処理は、結果の元のパスメッセージの処理に使用されます。
The merge node of a dynamically controlled recovery LSP SHOULD reset (0) the In-Place bit in the PROTECTION object of the outgoing Path message associated with the terminated recovery LSP.
Unlike with explicit control, if the creation of a dynamically identified recovery LSP fails for any reason, the recovery LSP is removed, and no error message or indication is sent upstream. With this exception, all the other procedures for explicitly controlled recovery LSPs apply to dynamically controlled recovery LSPs. These other procedures are defined above in Sections 4.2.1 through 4.2.4.
明示的な制御とは異なり、動的に識別された回復LSPの作成が何らかの理由で失敗した場合、回復LSPは削除され、エラーメッセージまたは表示は上流に送信されません。この例外を除き、明示的に制御された回復LSPの他のすべての手順は、動的に制御された回復LSPに適用されます。これらの他の手順は、上記のセクション4.2.1〜4.2.4で定義されています。
This section presents the RSVP message related formats as modified by this document. Where they differ, formats for unidirectional LSPs are presented separately from bidirectional LSPs.
このセクションでは、このドキュメントで変更されたRSVPメッセージ関連形式を示します。それらが異なる場合、単方向LSPの形式は双方向LSPとは別に提示されます。
The format of a Path message is as follows:
パスメッセージの形式は次のとおりです。
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <PROTECTION> ]
[ <LABEL_SET> ... ]
[ <SESSION_ATTRIBUTE> ]
[ <NOTIFY_REQUEST> ... ]
[ <ADMIN_STATUS> ]
[ <ASSOCIATION> ... ]
[ <SECONDARY_EXPLICIT_ROUTE> ... ]
[ <POLICY_DATA> ... ]
<sender descriptor>
The format of the sender description for unidirectional LSPs is:
単方向LSPの送信者説明の形式は次のとおりです。
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
[ <SUGGESTED_LABEL> ]
[ <RECOVERY_LABEL> ]
[ <SECONDARY_RECORD_ROUTE> ... ]
The format of the sender description for bidirectional LSPs is:
双方向LSPの送信者説明の形式は次のとおりです。
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
[ <SUGGESTED_LABEL> ]
[ <RECOVERY_LABEL> ]
<UPSTREAM_LABEL>
[ <SECONDARY_RECORD_ROUTE> ... ]
The format of a PathErr message is as follows:
Patherrメッセージの形式は次のとおりです。
<PathErr Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <ERROR_SPEC>
[ <ACCEPTABLE_LABEL_SET> ... ]
[ <SECONDARY_EXPLICIT_ROUTE> ... ]
[ <POLICY_DATA> ... ]
<sender descriptor>
The format of a Resv message is as follows:
RESVメッセージの形式は次のとおりです。
<Resv Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <NOTIFY_REQUEST> ... ]
[ <ADMIN_STATUS> ]
[ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list>
<flow descriptor list> ::= <FF flow descriptor list>
| <SE flow descriptor>
<FF flow descriptor list> ::= <FLOWSPEC> <FILTER_SPEC>
<LABEL> [ <RECORD_ROUTE> ]
[ <SECONDARY_RECORD_ROUTE> ... ]
| <FF flow descriptor list>
<FF flow descriptor>
<FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
[ <RECORD_ROUTE> ]
[ <SECONDARY_RECORD_ROUTE> ... ]
<SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list>
<SE filter spec list> ::= <SE filter spec>
| <SE filter spec list> <SE filter spec>
<SE filter spec> ::= <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ]
[ <SECONDARY_RECORD_ROUTE> ... ]
This document introduces new message objects for use in GMPLS signaling [RFC3473]. It does not introduce any new signaling messages, nor change the relationship between LSRs that are adjacent in the control plane.
このドキュメントでは、GMPLSシグナル伝達[RFC3473]で使用する新しいメッセージオブジェクトを紹介します。新しいシグナリングメッセージは導入されたり、コントロールプレーンに隣接しているLSR間の関係を変更したりしません。
The procedures defined in this document result in an increase in the amount of topology information carried in signaling messages since the presence of SEROs and SRROs necessarily means that there is more information about LSP paths carried than in simple EROs and RROs. Thus, in the event of the interception of a signaling message, slightly more could be deduced about the state of the network than was previously the case, but this is judged to be a very minor security risk as this information is already available via routing.
このドキュメントで定義されている手順は、SEROSとSRROの存在が必ずしも単純なEROSやRROよりもLSPパスについてより多くの情報があることを意味するため、シグナリングメッセージに搭載されているトポロジ情報の量が増加します。したがって、信号メッセージの傍受が発生した場合、以前よりもネットワークの状態についてわずかに推測することができますが、これは非常に小さなセキュリティリスクであると判断されます。
Otherwise, this document introduces no additional security considerations. See [RFC3473] for relevant security considerations.
それ以外の場合、このドキュメントでは、追加のセキュリティ上の考慮事項を紹介しません。関連するセキュリティに関する考慮事項については、[RFC3473]を参照してください。
IANA has assigned the following values for the namespaces defined in this document and reviewed in this section.
IANAは、このドキュメントで定義され、このセクションでレビューされている名前空間に次の値を割り当てました。
IANA has made the following assignment to the "GMPLS Signaling Parameters" Registry (see [RFC4872]) located at http://www.iana.org/assignments/gmpls-sig-parameters.
IANAは、http：//www.iana.org/assignments/gmpls-sig-parametersにある「GMPLSシグナリングパラメーター」レジストリ（[RFC4872]を参照）に次の割り当てを行いました。
Value Type
----- ----
2 Resource Sharing (R) [RFC4873]
This document defines bits carried in the Reserved field of the PROTECTION object defined in [RFC4872]. As no IANA registry for these bits is requested in [RFC4872], no IANA action is required related to this definition.
このドキュメントでは、[RFC4872]で定義されている保護オブジェクトの予約済みフィールドにあるビットを定義します。これらのビットのIANAレジストリは[RFC4872]で要求されていないため、この定義に関連するIANAアクションは必要ありません。
IANA has made the following assignments in the "Class Names, Class Numbers, and Class Types" section of the "RSVP PARAMETERS" registry located at http://www.iana.org/assignments/rsvp-parameters.
IANAは、http://www.iana.org/assignments/rsvp-parametersにある「クラス名、クラス番号、およびクラスタイプ」レジストリのセクションで次の割り当てを行いました。
A new class named SECONDARY_EXPLICIT_ROUTE has been created in the 11bbbbbb range (200) with the following definition: Class Types or C-types:
次の定義を使用して、secondar_explicit_routeという名前の新しいクラスが11bbbbbb範囲（200）で作成されました。クラスタイプまたはcタイプ：
Same values as EXPLICIT_ROUTE object (C-Num 20)
riblicit_routeオブジェクトと同じ値（c-num 20）
For Class 1, C-Type 1, the following additional Subobject type is defined:
クラス1のCタイプ1の場合、次の追加のサブオブジェクトタイプが定義されています。
37 PROTECTION [RFC4873]
37保護[RFC4873]
IANA has made the following assignments in the "Class Names, Class Numbers, and Class Types" section of the "RSVP PARAMETERS" registry located at http://www.iana.org/assignments/rsvp-parameters.
IANAは、http://www.iana.org/assignments/rsvp-parametersにある「クラス名、クラス番号、およびクラスタイプ」レジストリのセクションで次の割り当てを行いました。
A new class named SECONDARY_RECORD_ROUTE has been created in the 11bbbbbb range (201) with the following definition:
次の定義で、secondary_record_routeという名前の新しいクラスが11bbbbbb範囲（201）で作成されました。
Class Types or C-types:
クラスタイプまたはCタイプ：
Same values as RECORD_ROUTE object (C-Num 21)
record_routeオブジェクトと同じ値（c-num 21）
For Class 1, C-Type 1, the following additional Subobject type is defined:
クラス1のCタイプ1の場合、次の追加のサブオブジェクトタイプが定義されています。
37 PROTECTION [RFC4873]
IANA has made the following assignments in the "Routing Problem" subsection of "Error Codes and Values" section of the "RSVP PARAMETERS" registry located at http://www.iana.org/assignments/rsvp-parameters.
IANAは、http：//www.iana.org/assignments/rsvp-parametersにある「RSVPパラメーター」レジストリの「エラーコードと値」セクションの「ルーティング問題」サブセクションで次の割り当てを行っています。
21 = LSP Segment Protection Failed [RFC4873]
21 = LSPセグメントの保護が失敗した[RFC4873]
This document modifies the PROTECTION object, class number 37, C-Type 2 (defined in Section 14.1. of [RFC4872]).
このドキュメントは、クラス番号37、Cタイプ2（[RFC4872]のセクション14.1。で定義）を変更します。
[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., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、1997年9月。
[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年。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナル伝達機能説明」、RFC 3471、2003年1月。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling - Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC4872] Lang, J.P., Ed., Rekhter, Y., Ed., and D. Papadimitriou, Ed., "RSVP-TE Extensions in support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 2007.
[RFC4872] Lang、J.P.、ed。、Rekhter、Y.、ed。、およびD. Papadimitriou、ed。、「RSVP-TE拡張機能エンドツーエンドの一般化マルチプロトコルラベルスイッチング（GMPLS）リカバリー」、RFC 4872、2007年5月。
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4090] Pan、P.、Swallow、G。、およびA. Atlas、「LSPトンネルのRSVP-TEへの高速拡張式」、RFC 4090、2005年5月。
[RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D. Papadimitriou, Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification," RFC 4426, March 2006.
[RFC4426] Lang、J.、ed。、Rajagopalan、B.、ed。、およびD. Papadimitriou、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）回復機能仕様」、RFC 4426、2006年3月。
[RFC4427] Mannie, E., Ed., and D. Papadimitriou, Ed., "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, March 2006.
[RFC4427] Mannie、E.、ed。、およびD. Papadimitriou、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）の回復（保護および回復）用語」、RFC 4427、2006年3月。
Authors' Addresses
著者のアドレス
Lou Berger LabN Consulting, L.L.C.
Lou Berger Labn Consulting、L.L.C。
Phone: +1 301-468-9228
EMail: lberger@labn.net
Igor Bryskin ADVA Optical 7926 Jones Branch Drive Suite 615 McLean VA, 22102
Igor Bryskin Adva Optical 7926 Jones Branch Drive Suite 615 McLean VA、22102
EMail: IBryskin@advaoptical.com
Dimitri Papadimitriou Alcatel Francis Wellesplein 1 B-2018 Antwerpen, Belgium
Dimitri Papadimitriou Alcatel Francis Wellesplein 1 B-2018 Antwerpen、ベルギー
Phone: +32 3 240-8491
EMail: dimitri.papadimitriou@alcatel-lucent.be
Adrian Farrel Old Dog Consulting
エイドリアンファレルオールドドッグコンサルティング
Phone: +44 (0) 1978 860944
EMail: adrian@olddog.co.uk
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
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への情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.