RFC 4872 - RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc4872
タイトル : RFC 4872 -
翻訳編集 : 自動生成

[要約] RFC 4872は、GMPLS回復をサポートするためのRSVP-TE拡張に関するものです。このRFCの目的は、ネットワークの障害時に効果的な回復メカニズムを提供することです。

Network Working Group                                     J.P. Lang, Ed.
Request for Comments: 4872                                         Sonos
Updates: 3471                                            Y. Rekhter, Ed.
Category: Standards Track                                        Juniper
                                                   D. Papadimitriou, Ed.
                                                                 Alcatel
                                                                May 2007

RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery

エンドツーエンドの一般化マルチプロトコルラベルスイッチング（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 protocol-specific procedures and extensions for Generalized Multi-Protocol Label Switching (GMPLS) Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling to support end-to-end Label Switched Path (LSP) recovery that denotes protection and restoration. A generic functional description of GMPLS recovery can be found in a companion document, RFC 4426.

このドキュメントでは、保護と回復を示すエンドツーエンドラベルスイッチドパス（LSP）回復をサポートするために、一般化されたマルチプロトコルラベルスイッチング（GMPLS）リソース予約プロトコル（RSVP-TE）シグナル伝達のプロトコル固有の手順と拡張機能について説明します。。GMPLS回復の一般的な機能的説明は、コンパニオンドキュメントRFC 4426に記載されています。

Table of Contents

  1. Introduction .....................................................3
   2. Conventions Used in This Document ...............................5
   3. Relationship to Fast Reroute (FRR) ..............................5
   4. Definitions .....................................................6
      4.1. LSP Identification .........................................6
      4.2. Recovery Attributes ........................................7
           4.2.1. LSP Status ..........................................7
           4.2.2. LSP Recovery ........................................8
      4.3. LSP Association ............................................9
   5. 1+1 Unidirectional Protection ...................................9
      5.1. Identifiers ...............................................10

   6. 1+1 Bidirectional Protection ...................................10
      6.1. Identifiers ...............................................11
      6.2. End-to-End Switchover Request/Response ....................11
   7. 1:1 Protection with Extra-Traffic ..............................13
      7.1. Identifiers ...............................................14
      7.2. End-to-End Switchover Request/Response ....................15
      7.3. 1:N (N > 1) Protection with Extra-Traffic .................16
   8. Rerouting without Extra-Traffic ................................17
      8.1. Identifiers ...............................................19
      8.2. Signaling Primary LSPs ....................................19
      8.3. Signaling Secondary LSPs ..................................19
   9. Shared-Mesh Restoration ........................................20
      9.1. Identifiers ...............................................22
      9.2. Signaling Primary LSPs ....................................22
      9.3. Signaling Secondary LSPs ..................................23
   10. LSP Preemption ................................................23
   11. (Full) LSP Rerouting ..........................................25
      11.1. Identifiers ..............................................25
      11.2. Signaling Reroutable LSPs ................................26
   12. Reversion .....................................................26
   13. Recovery Commands .............................................29
   14. PROTECTION Object .............................................31
      14.1. Format ...................................................31
      14.2. Processing ...............................................33
   15. PRIMARY_PATH_ROUTE Object .....................................33
      15.1. Format ...................................................34
      15.2. Subobjects ...............................................34
      15.3. Applicability ............................................35
      15.4. Processing ...............................................36
   16. ASSOCIATION Object ............................................37
      16.1. Format ...................................................37
      16.2. Processing ...............................................38
   17. Updated RSVP Message Formats ..................................39
   18. Security Considerations .......................................40
   19. IANA Considerations ...........................................41
   20. Acknowledgments ...............................................43
   21. References ....................................................43
      21.1. Normative References .....................................43
      21.2. Informative References ...................................44
   22. Contributors ..................................................45

1. Introduction

1. はじめに

Generalized Multi-Protocol Label Switching (GMPLS) extends MPLS to include support for Layer-2 Switch Capable (L2SC), Time-Division Multiplex (TDM), Lambda Switch Capable (LSC), and Fiber Switch Capable (FSC) interfaces. GMPLS recovery uses control plane mechanisms (i.e., signaling, routing, and link management mechanisms) to support data plane fault recovery. Note that the analogous (data plane) fault detection mechanisms are required to be present in support of the control plane mechanisms. In this document, the term "recovery" is generically used to denote both protection and restoration; the specific terms "protection" and "restoration" are only used when differentiation is required. The subtle distinction between protection and restoration is made based on the resource allocation done during the recovery phase (see [RFC4427]).

一般化されたマルチプロトコルラベルスイッチング（GMPLS）は、MPLSを拡張して、レイヤー-2スイッチ対応（L2SC）、時間分割マルチプレックス（TDM）、ラムダスイッチ対応（LSC）、およびファイバースイッチ対応（FSC）界面のサポートを含めます。GMPLS Recoveryは、コントロールプレーンメカニズム（つまり、シグナリング、ルーティング、およびリンク管理メカニズム）を使用して、データプレーンの障害回復をサポートします。類似の（データプレーン）障害検出メカニズムは、制御プレーンメカニズムをサポートするために存在する必要があることに注意してください。このドキュメントでは、「回復」という用語は、保護と回復の両方を示すために一般的に使用されます。特定の用語「保護」と「修復」は、分化が必要な場合にのみ使用されます。保護と回復の微妙な区別は、回復段階で行われたリソース割り当てに基づいて行われます（[RFC4427]を参照）。

A functional description of GMPLS recovery is provided in [RFC4426] and should be considered as a companion document. The present document describes the protocol-specific procedures for GMPLS RSVP-TE (Resource ReSerVation Protocol - Traffic Engineering) signaling (see [RFC3473]) to support end-to-end recovery. End-to-end recovery refers to the recovery of an entire LSP from its head-end (ingress node endpoint) to its tail-end (egress node endpoint). With end-to-end recovery, working LSPs are assumed to be resource-disjoint (where a resource is a link, node, or Shared Risk Link Group (SRLG)) in the network so that they do not share any failure probability, but this is not mandatory. With respect to a given set of network resources, a pair of working/protecting LSPs SHOULD be resource disjoint in case of dedicated recovery type (see below). On the other hand, in case of shared recovery (see below), a group of working LSPs SHOULD be mutually resource-disjoint in order to allow for a (single and commonly) shared protecting LSP, itself resource-disjoint from each of the working LSPs. Note that resource disjointness is a necessary (but not sufficient) condition to ensure LSP recoverability.

GMPLS回復の機能的な説明は[RFC4426]で提供されており、コンパニオンドキュメントと見なされる必要があります。現在のドキュメントでは、エンドツーエンドの回復をサポートするためのGMPLS RSVP-TE（リソース予約プロトコル - トラフィックエンジニアリング）シグナル（[RFC3473]を参照）のプロトコル固有の手順について説明します。エンドツーエンドの回復とは、ヘッドエンド（イングレスノードエンドポイント）からテールエンド（出口ノードエンドポイント）へのLSP全体の回復を指します。エンドツーエンドの回復により、作業LSPは、ネットワーク内のリソースダイジョン（リソース、リンク、ノード、または共有リスクリンクグループ（SRLG））であると想定されているため、障害確率を共有しませんが、これは必須ではありません。特定の一連のネットワークリソースに関しては、専用のリカバリタイプの場合、ワーキング/保護LSPのペアはリソースの矛盾である必要があります（以下を参照）。一方、回復の共有（以下を参照）の場合、作業LSPのグループは、（単一および一般的に）共有されたLSPを使用するために、それぞれの動作からリソースディスジョイントを共有する（単一および一般的に）共有されるLSPを可能にする必要があります。LSP。リソースの分離は、LSPの回復可能性を確保するために必要な（ただし十分ではない）条件であることに注意してください。

The present document addresses four types of end-to-end LSP recovery: 1) 1+1 (unidirectional/bidirectional) protection, 2) 1:N (N >= 1) LSP protection with extra-traffic, 3) pre-planned LSP rerouting without extra-traffic (including shared mesh), and 4) full LSP rerouting.

現在の文書は、4種類のエンドツーエンドのLSP回復に対応しています：1）1 1（単方向/双方向）保護、2）1：N（n> = 1）交通量が多いLSP保護、3）事前に計画されたLSPトラフィック外（共有メッシュを含む）、および4）フルLSPルーティングなしの再ルーティング。

1) The simplest notion of end-to-end LSP protection is 1+1 unidirectional protection. Using this type of protection, a protecting LSP is signaled over a dedicated resource-disjoint alternate path to protect an associated working LSP. Normal traffic is simultaneously sent on both LSPs and a selector is used at the egress node to receive traffic from one of the LSPs. If a failure occurs along one of the LSPs, the egress node selects the traffic from the valid LSP. No coordination is required between the end nodes when a failure/switchover occurs.

1) エンドツーエンドのLSP保護の最も単純な概念は、1 1単方向保護です。このタイプの保護を使用して、関連する作業LSPを保護するために、専用のリソースディスジョイント代替パスにわたって保護されているLSPがシグナル伝えられます。通常のトラフィックは同時にLSPSの両方に送信され、SELECTORはEgressノードで使用され、LSPの1つからトラフィックを受信します。LSPの1つに沿って障害が発生した場合、出力ノードは有効なLSPからトラフィックを選択します。障害/スイッチオーバーが発生した場合、エンドノード間に調整は必要ありません。

In 1+1 bidirectional protection, a protecting LSP is signaled over a dedicated resource-disjoint alternate path to protect the working LSP. Normal traffic is simultaneously sent on both LSPs (in both directions), and a selector is used at both ingress/egress nodes to receive traffic from the same LSP. This requires coordination between the end-nodes when switching to the protecting LSP.

1 1の双方向保護では、作業LSPを保護するために、専用のリソースディスジョイントの代替パスにわたって保護されているLSPが合図されます。通常のトラフィックは両方のLSP（両方の方向）に同時に送信され、同じLSPからトラフィックを受信するために、イングレス/出口ノードの両方でセレクターが使用されます。これには、保護LSPに切り替えるときにエンドノード間の調整が必要です。

2) In 1:N (N >= 1) protection with extra-traffic, the protecting LSP is a fully provisioned and resource-disjoint LSP from the N working LSPs, that allows for carrying extra-traffic. The N working LSPs MAY be mutually resource-disjoint. Coordination between end-nodes is required when switching from one of the working LSPs to the protecting LSP. As the protecting LSP is fully provisioned, default operations during protection switching are specified for a protecting LSP carrying extra-traffic, but this is not mandatory. Note that M:N protection is out of scope of this document (though mechanisms it defines may be extended to cover it).

2) 1：n（n> = 1）の保護では、トラフィック外の保護を備えた保護LSPは、n作業LSPから完全にプロビジョニングされ、リソースディスジョイントLSPであり、トラフィック外の運搬を可能にします。N作業LSPは相互にリソースディスジョイントである可能性があります。動作するLSPの1つから保護LSPに切り替える場合、エンドノード間の調整が必要です。保護LSPが完全にプロビジョニングされているため、トラフィック以外のLSPを保護するために保護スイッチング中のデフォルト操作が指定されていますが、これは必須ではありません。M：n保護はこのドキュメントの範囲外であることに注意してください（ただし、定義するメカニズムは、それをカバーするために拡張される場合があります）。

3) Pre-planned LSP rerouting (or restoration) relies on the establishment between the same pair of end-nodes of a working LSP and a protecting LSP that is link/node/SRLG disjoint from the working one. Here, the recovery resources for the protecting LSP are pre-reserved but explicit action is required to activate (i.e., commit resource allocation at the data plane) a specific protecting LSP instantiated during the (pre-)provisioning phase. Since the protecting LSP is not "active" (i.e., fully instantiated), it cannot carry any extra-traffic. This does not mean that the corresponding resources cannot be used by other LSPs. Therefore, this mechanism protects against working LSP(s) failure(s) but requires activation of the protecting LSP after working LSP failure occurrence. This requires restoration signaling along the protecting path. "Shared-mesh" restoration can be seen as a particular case of pre-planned LSP rerouting that reduces the recovery resource requirements by allowing multiple protecting LSPs to share common link and node resources. The recovery resources are pre-reserved but explicit action is required to activate (i.e., commit resource allocation at the data plane) a specific protecting LSP instantiated during the (pre-) provisioning phase. This procedure requires restoration signaling along the protecting path.

3) 事前に計画されたLSPルロアウト（または修復）は、作業LSPの同じエンドノードのペアと、リンク/ノード/SRLGの保護LSPの間の確立に依存しています。ここでは、保護LSPの回復リソースは事前に予約されていますが、（つまり、データプレーンでリソース割り当てをコミットする）ためには明示的なアクションが必要です（つまり、データプレーンでリソース割り当てをコミット）（前）プロビジョニングフェーズ中にインスタンス化された特定の保護が必要です。保護LSPは「アクティブ」ではないため（つまり、完全にインスタンス化されています）、交通量のないものを運ぶことはできません。これは、対応するリソースを他のLSPで使用できないことを意味するものではありません。したがって、このメカニズムは、LSPの動作障害から保護されますが、LSPの故障が発生した後、LSP保護の活性化が必要です。これには、保護パスに沿った復元シグナル伝達が必要です。「共有メッシュ」の復元は、複数の保護LSPが共通のリンクとノードのリソースを共有できるようにすることにより、回復リソース要件を削減する、事前に計画されたLSPリルートの特定のケースと見なすことができます。回復リソースは事前に予約されていますが、（つまり、データプレーンでリソース割り当てをコミットする）ためには明示的なアクションが必要です（つまり、データプレーンでリソース割り当てをコミット）（前）プロビジョニングフェーズ中にインスタンス化された特定の保護LSPが必要です。この手順では、保護パスに沿った復元シグナル伝達が必要です。

Note that in both cases, bandwidth pre-reserved for a protecting (but not activated) LSP can be made available for carrying extra traffic. LSPs for extra-traffic (with lower holding priority than the protecting LSP) can then be established using the bandwidth pre-reserved for the protecting LSP. Also, any lower priority LSP that use the pre-reserved resources for the protecting LSP(s) must be preempted during the activation of the protecting LSP.

どちらの場合も、保護（しかし活性化されていない）LSPのために帯域幅が事前に保護されているため、追加のトラフィックを運ぶために利用できるようにすることができます。トラフィック外（保護LSPよりも優先度が低い）のLSPは、保護LSPのために帯域幅を使用して確立できます。また、保護LSPの活性化中に、保護LSPに予約不利なリソースを使用する優先度の低いLSPは、保護するためにProtecting LSPを先取りする必要があります。

4) Full LSP rerouting (or restoration) switches normal traffic to an alternate LSP that is not even partially established until after the working LSP failure occurs. The new alternate route is selected at the LSP head-end node, it may reuse resources of the failed LSP at intermediate nodes and may include additional intermediate nodes and/or links.

4) 完全なLSPルーティング（または復元）は、通常のトラフィックを代替LSPに切り替えます。これは、作業LSPの故障が発生するまで部分的に確立されていません。新しい代替ルートはLSPヘッドエンドノードで選択されており、中間ノードで失敗したLSPのリソースを再利用し、追加の中間ノードおよび/またはリンクを含める場合があります。

Crankback signaling (see [CRANK]) and LSP segment recovery (see [RFC4873]) are further detailed in dedicated companion documents.

2. Conventions Used in This Document

2. このドキュメントで使用されている規則

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 [RFC3945], [RFC3471], [RFC3473] and referenced as well as in [RFC4427] and [RFC4426].

さらに、読者は[RFC3945]、[RFC3471]、[RFC3473]で使用されている用語に精通しており、[RFC4427]および[RFC4426]と同様に参照されます。

3. Relationship to Fast Reroute (FRR)

3. 高速ルートとの関係（frr）

There is no impact to RSVP-TE Fast Reroute (FRR) [RFC4090] introduced by end-to-end GMPLS recovery i.e., it is possible to use either method defined in FRR with end-to-end GMPLS recovery.

エンドツーエンドのGMPLS回復によって導入されたRSVP-TE Fast Reroute（FRR）[RFC4090]に影響はありません。

The objects used and/or newly introduced by end-to-end recovery will be ignored by [RFC4090] conformant implementations, and FRR can operate on a per LSP basis as defined in [RFC4090].

エンドツーエンドの回復によって使用および/または新たに導入されたオブジェクトは、[RFC4090]コンフォーマント実装によって無視され、FRRは[RFC4090]で定義されているように、LSPごとに動作できます。

4. Definitions

4. 定義

4.1. LSP Identification

4.1. LSP識別

This section reviews terms previously defined in [RFC2205], [RFC3209], and [RFC3473]. LSP tunnels are identified by a combination of the SESSION and SENDER_TEMPLATE objects (see also [RFC3209]). The relevant fields are as follows:

このセクションでは、[RFC2205]、[RFC3209]、および[RFC3473]で以前に定義された用語を確認します。LSPトンネルは、セッションとsender_templateオブジェクトの組み合わせによって識別されます（[RFC3209]も参照）。関連するフィールドは次のとおりです。

IPv4 (or IPv6) tunnel endpoint address

IPv4（またはIPv6）トンネルエンドポイントアドレス

IPv4 (or IPv6) address of the egress node for the tunnel.

Tunnel ID

トンネルID

A 16-bit identifier used in the SESSION that remains constant over the life of the tunnel.

セッションで使用される16ビット識別子は、トンネルの存続期間中に一定のままです。

Extended Tunnel ID

拡張トンネルID

A 32-bit (or 16-byte) identifier used in the SESSION that remains constant over the life of the tunnel. Normally set to all zeros. Ingress nodes that wish to narrow the scope of a SESSION to the ingress-egress pair MAY place their IPv4 (or IPv6) address here as a globally unique identifier.

セッションで使用される32ビット（または16バイト）の識別子は、トンネルの寿命にわたって一定のままです。通常、すべてのゼロに設定されています。イングレスエグレスペアにセッションの範囲を狭めたいと考えているイングレスノードは、ここでグローバルに一意の識別子としてIPv4（またはIPv6）アドレスを配置する可能性があります。

IPv4 (or IPv6) tunnel sender address

IPv4（またはIPv6）トンネル送信者アドレス

IPv4 (or IPv6) address for a sender node.

LSP ID

A 16-bit identifier used in the SENDER_TEMPLATE and FILTER_SPEC that can be changed to allow a sender to share resources with itself.

Sender_TemplateおよびFilter_Specで使用される16ビット識別子を変更して、送信者がリソース自体を共有できるようにすることができます。

The first three fields are carried in the SESSION object (Path and Resv message) and constitute the basic identification of the LSP tunnel.

最初の3つのフィールドは、セッションオブジェクト（PATHおよびRESVメッセージ）に携帯され、LSPトンネルの基本的な識別を構成します。

The last two fields are carried in the SENDER_TEMPLATE (Path message) and FILTER_SPEC objects (Resv message). The LSP ID is used to differentiate LSPs that belong to the same LSP Tunnel (as identified by its Tunnel ID).

最後の2つのフィールドは、sender_template（パスメッセージ）とfilter_specオブジェクト（resvメッセージ）に携帯されています。LSP IDは、同じLSPトンネルに属するLSPを区別するために使用されます（トンネルIDで識別）。

4.2. Recovery Attributes

4.2. 回復属性

The recovery attributes include all the parameters that determine the status of an LSP within the recovery scheme to which it is associated. These attributes are part of the PROTECTION object introduced in Section 14.

回復属性には、それが関連付けられている回復スキーム内のLSPのステータスを決定するすべてのパラメーターが含まれます。これらの属性は、セクション14で導入された保護オブジェクトの一部です。

4.2.1. LSP Status

4.2.1.

The following bits are used in determining resource allocation and status of the LSP within the group of LSPs forming the protected entity:

次のビットは、保護されたエンティティを形成するLSPのグループ内のLSPのリソース割り当てとステータスを決定する際に使用されます。

- S (Secondary) bit: enables distinction between primary and secondary LSPs. A primary LSP is a fully established LSP for which the resource allocation has been committed at the data plane (i.e., full cross-connection has been performed). Both working and protecting LSPs can be primary LSPs. A secondary LSP is an LSP that has been provisioned in the control plane only, and for which resource selection MAY have been done but for which the resource allocation has not been committed at the data plane (for instance, no cross-connection has been performed). Therefore, a secondary LSP is not immediately available to carry any traffic (thus requiring additional signaling to be available). A secondary LSP can only be a protecting LSP. The (data plane) resources allocated for a secondary LSP MAY be used by other LSPs until the primary LSP fails over to the secondary LSP.

- S（セカンダリ）ビット：一次LSPとセカンダリLSPを区別できます。プライマリLSPは、完全に確立されたLSPであり、データプレーンでリソース割り当てが行われました（つまり、完全なクロス接続が実行されました）。LSPの動作と保護の両方は、主要なLSPになる可能性があります。セカンダリLSPは、コントロールプレーンのみでプロビジョニングされており、リソース選択が行われたかもしれないが、データプレーンでリソース割り当てがコミットされていないLSPです（たとえば、相互接続は実行されていません。）。したがって、トラフィックを運ぶために、二次LSPはすぐに利用できません（したがって、追加のシグナル伝達を利用できるようにする必要があります）。二次LSPは、保護LSPのみになります。二次LSPに割り当てられた（データプレーン）リソースは、一次LSPがセカンダリLSPに失敗するまで他のLSPによって使用できます。

- P (Protecting) bit: enables distinction between working and protecting LSPs. A working LSP must be a primary LSP whilst a protecting LSP can be either a primary or a secondary LSP. When protecting LSP(s) are associated with working LSP(s), one also refers to the latter as protected LSPs.

- P（保護）ビット：LSPの動作と保護の区別を有効にします。動作するLSPはプライマリLSPでなければなりませんが、保護LSPはプライマリまたはセカンダリLSPのいずれかです。LSPを保護することは、LSPの動作に関連している場合、後者を保護されたLSPとも呼びます。

Note: The combination "secondary working" is not valid (only protecting LSPs can be secondary LSPs). Working LSPs are always primary LSPs (i.e., fully established) whilst primary LSPs can be either working or protecting LSPs.

- O (Operational) bit: this bit is set when a protecting LSP is carrying the normal traffic after protection switching (i.e., applies only in case of dedicated LSP protection or LSP protection with extra-traffic; see Section 4.2.2).

- O（動作）ビット：このビットは、保護LSPが保護スイッチング後に通常のトラフィックを運ぶときに設定されます（つまり、専用のLSP保護または交通量の多いLSP保護の場合にのみ適用されます。セクション4.2.2を参照）。

In this document, the PROTECTION object uses as a basis the PROTECTION object defined in [RFC3471] and [RFC3473] and defines additional fields within it. The fields defined in [RFC3471] and [RFC3473] are unchanged by this document.

このドキュメントでは、保護オブジェクトは[RFC3471]および[RFC3473]で定義されている保護オブジェクトの基礎として使用し、その中の追加のフィールドを定義します。[RFC3471]および[RFC3473]で定義されているフィールドは、このドキュメントで変更されていません。

4.2.2. LSP Recovery

4.2.2. LSPリカバリ

The following classification is used to distinguish the LSP Protection Type with which LSPs can be associated at end-nodes (a distinct value is associated with each Protection Type in the PROTECTION object; see Section 14):

次の分類を使用して、LSPがエンドノードで関連付けられるLSP保護タイプを区別するために使用されます（個別の値は、保護オブジェクトの各保護タイプに関連付けられています。セクション14を参照）：

- Full LSP Rerouting: set if a primary working LSP is dynamically recoverable using (non pre-planned) head-end rerouting.

- フルLSP再ルーティング：プライマリ作業LSPが（事前にプランしていない）ヘッドエンドの再ルーティングを使用して動的に回復可能であるかどうかを設定します。

- Pre-planned LSP Rerouting without Extra-traffic: set if a protecting LSP is a secondary LSP that allows sharing of the pre-reserved recovery resources between one or more than one <sender;receiver> pair. When the secondary LSPs resources are not pre-reserved for a single <sender;receiver> pair, this type is referred to as "shared mesh" recovery.

- トラフィック以外の事前に計画されたLSPルアウト：保護LSPが1つまたは複数の<送信者;受信機>ペア間で事前に予約されたリカバリリソースを共有できる二次LSPであるかどうかを設定します。セカンダリLSPSリソースが単一の<sender; receiver>ペアのために事前に予約されていない場合、このタイプは「共有メッシュ」リカバリと呼ばれます。

- LSP Protection with Extra-traffic: set if a protecting LSP is a dedicated primary LSP that allows for extra-traffic transport and thus precludes any sharing of the recovery resources between more than one <sender;receiver> pair. This type includes 1:N LSP protection with extra-traffic.

- Dedicated LSP Protection: set if a protecting LSP does not allow sharing of the recovery resources nor the transport of extra-traffic (implying in the present context, duplication of the signal over both working and protecting LSPs as in 1+1 dedicated protection). Note also that this document makes a distinction between 1+1 unidirectional and bidirectional dedicated LSP protection.

- 専用のLSP保護：保護LSPが回復リソースの共有やトラフィック以外の輸送を許可しない場合（現在の文脈では、1 1の専用保護のように、LSPの動作と保護の両方に対する信号の複製を暗示しています）。また、このドキュメントは、1 1方向と双方向の専用LSP保護を区別していることに注意してください。

For LSP protection, in particular, when the data plane provides automated protection-switching capability (see for instance ITU-T [G.841] Recommendation), a Notification (N) bit is defined in the PROTECTION object. It allows for distinction between protection switching signaling via the control plane or the data plane.

Note: this document assumes that Protection Type values have end-to-end significance and that the same value is sent over the protected and the protecting path. In this context, shared-mesh (for instance) appears from the end-nodes perspective as being simply an LSP rerouting without extra-traffic services. The net result of this is that a single bit (the S bit alone) does not allow determining whether resource allocation should be performed with respect to the status of the LSP within the protected entity. The introduction of the P bit solves this problem unambiguously. These bits MUST be processed on a hop-by-hop basis (independently of the LSP Protection Type context). This allows for an easier implementation of reversion signaling (see Section 12) but also facilitates the transparent delivery of protected services since any intermediate node is not required to know the semantics associated with the incoming LSP Protection Type value.

注：このドキュメントは、保護型の値がエンドツーエンドの重要性を持ち、同じ値が保護されたパスと保護パスを介して送信されることを前提としています。これに関連して、共有メッシュ（たとえば）は、エンドノードの観点から、トラフィック以外のサービスなしで単にLSPの再ルーティングであると表示されます。これの最終的な結果は、単一のビット（Sビットだけ）では、保護されたエンティティ内のLSPのステータスに関してリソース割り当てを実行すべきかどうかを決定することができないことです。P BITの導入は、この問題を明確に解決します。これらのビットは、ホップバイホップベースで処理する必要があります（LSP保護タイプのコンテキストとは独立して）。これにより、リバージョンシグナル伝達の容易な実装が可能になり（セクション12を参照）、中間ノードは着信LSP保護型値に関連するセマンティクスを知る必要がないため、保護サービスの透明な配信も容易になります。

4.3. LSP Association

4.3.

The ASSOCIATION object, introduced in Section 16, is used to associate the working and protecting LSPs.

セクション16で導入された協会のオブジェクトは、LSPSと保護を関連付けるために使用されます。

When used for signaling the working LSP, the Association ID of the ASSOCIATION object (see Section 16) identifies the protecting LSP. When used for signaling the protecting LSP, this field identifies the LSP protected by the protecting LSP.

5. 1+1 Unidirectional Protection

5. 1 1単方向保護

One of the simplest notions of end-to-end LSP protection is 1+1 unidirectional protection.

Consider the following network topology:

次のネットワークトポロジを検討してください。

                                  A---B---C---D
                                   \         /
                                    E---F---G

The paths [A,B,C,D] and [A,E,F,G,D] are node and link disjoint, ignoring the ingress/egress nodes A and D. A 1+1 protected path is established from A to D over [A,B,C,D] and [A,E,F,G,D], and traffic is transmitted simultaneously over both component paths (i.e., LSPs).

パス[a、b、c、d]および[a、e、f、g、d]はノードであり、リンクがnisedointであり、侵入/出口ノードAおよびDを無視します。[a、b、c、d]および[a、e、f、g、d]、およびトラフィックは、両方のコンポーネントパス（つまり、LSP）に同時に送信されます。

During the provisioning phase, both LSPs are fully instantiated (and thus activated) so that no resource sharing can be done along the protecting LSP (nor can any extra-traffic be transported). It is also RECOMMENDED to set the N bit since no protection-switching signaling is assumed in this case.

プロビジョニング段階では、両方のLSPが完全にインスタンス化（したがって活性化されています）ため、保護LSPに沿ってリソース共有を行うことはできません（トラフィック外輸送も輸送できません）。この場合、保護スイッチングシグナル伝達が想定されていないため、Nビットを設定することもお勧めします。

When a failure occurs (say, at node B) and is detected at end-node D, the receiver at D selects the normal traffic from the other LSP. From this perspective, 1+1 unidirectional protection can be seen as an uncoordinated protection-switching mechanism acting independently at both endpoints. Also, for the LSP under failure condition, it is RECOMMENDED to not set the Path_State_Removed Flag of the ERROR_SPEC object (see [RFC3473]) upon PathErr message generation.

障害が発生し（たとえば、ノードBで）、エンドノードDで検出されると、Dの受信機は他のLSPから通常のトラフィックを選択します。この観点から、1 1単方向保護は、両方のエンドポイントで独立して作用する調整されていない保護スイッチングメカニズムと見なすことができます。また、障害条件下のLSPの場合、Patherrメッセージ生成時にERROR_SPECオブジェクトのPATH_STATE_REMOVEDフラグ（[RFC3473]を参照）を設定しないことをお勧めします。

Note: it is necessary that both paths are SRLG disjoint to ensure recoverability; otherwise, a single failure may impact both working and protecting LSPs.

注：回復可能性を確保するために、両方のパスがsrlgの分離である必要があります。それ以外の場合、単一の障害は、作業とLSPの保護の両方に影響を与える可能性があります。

5.1. Identifiers

5.1. 識別子

To simplify association operations, both LSPs belong to the same session. Thus, the SESSION object MUST be the same for both LSPs. The LSP ID, however, MUST be different to distinguish between the two LSPs.

協会の操作を簡素化するために、両方のLSPが同じセッションに属します。したがって、セッションオブジェクトは両方のLSPで同じでなければなりません。ただし、LSP IDは、2つのLSPを区別するために異なる必要があります。

A new PROTECTION object (see Section 14) is included in the Path message. This object carries the desired end-to-end LSP Protection Type -- in this case, "1+1 Unidirectional". This LSP Protection Type value is applicable to both uni- and bidirectional LSPs.

新しい保護オブジェクト（セクション14を参照）がパスメッセージに含まれています。このオブジェクトは、目的のエンドツーエンドのLSP保護タイプを搭載しています。この場合、「1 1単方向」です。このLSP保護タイプの値は、単方および双方向LSPの両方に適用できます。

To allow distinguishing the working LSP (from which the signal is taken) from the protecting LSP, the working LSP is signaled by setting in the PROTECTION object the S bit to 0, the P bit to 0, and in the ASSOCIATION object, the Association ID to the protecting LSP_ID. The protecting LSP is signaled by setting in the PROTECTION object the S bit to 0, the P bit to 1, and in the ASSOCIATION object, the Association ID to the associated protected LSP_ID.

動作LSPを保護LSPから区別できるようにするために、動作LSPは保護オブジェクトにSビットを0、Pビット0に、関連するオブジェクトであるAssociationを設定することにより信号が表示されます。保護lsp_idへのid。保護LSPは、保護オブジェクトにsビットを0、pビット1に、関連する保護されたLSP_IDに関連するオブジェクトに設定することにより信号が表示されます。

After protection switching completes, and after reception of the PathErr message, to keep track of the LSP from which the signal is taken, the protecting LSP SHOULD be signaled with the O bit set. The formerly working LSP MAY be signaled with the A bit set in the ADMIN_STATUS object (see [RFC3473]). This process assumes the tail-end node has notified the head-end node that traffic selection switchover has occurred.

保護スイッチングが完了した後、Patherrメッセージを受信した後、信号を取得するLSPを追跡するために、保護LSPをO BITセットで信号する必要があります。以前に作業していたLSPは、Admin_Statusオブジェクトに少し設定されたA a bit setでシグナルを受けることができます（[rfc3473]を参照）。このプロセスでは、テールエンドノードがヘッドエンドノードにトラフィック選択スイッチオーバーが発生したことを通知したことを想定しています。

6. 1+1 Bidirectional Protection

6.

1+1 bidirectional protection is a scheme that provides end-to-end protection for bidirectional LSPs.

Consider the following network topology:

次のネットワークトポロジを検討してください。

                                  A---B---C---D
                                   \         /
                                    E---F---G

The LSPs [A,B,C,D] and [A,E,F,G,D] are node and link disjoint, ignoring the ingress/egress nodes A and D. A bidirectional LSP is established from A to D over each path, and traffic is transmitted simultaneously over both LSPs. In this scheme, both endpoints must receive traffic over the same LSP. Note also that both LSPs are fully instantiated (and thus activated) so that no resource sharing can be done along the protection path (nor can any extra-traffic be transported).

lsps [a、b、c、d]および[a、e、f、g、d]はノードであり、リンクはnisjointであり、侵入/出口ノードAとDを無視します。パスとトラフィックは、両方のLSPで同時に送信されます。このスキームでは、両方のエンドポイントが同じLSPでトラフィックを受信する必要があります。また、両方のLSPは完全にインスタンス化されている（したがって活性化されている）ため、保護パスに沿ってリソース共有を行うことはできません（トラフィック外輸送もできません）。

When a failure is detected by one or both endpoints of the LSP, both endpoints must select traffic from the other LSP. This action must be coordinated between node A and D. From this perspective, 1+1 bidirectional protection can be seen as a coordinated protection-switching mechanism between both endpoints.

LSPの片方または両方のエンドポイントによって障害が検出される場合、両方のエンドポイントは他のLSPからトラフィックを選択する必要があります。このアクションは、ノードAとDの間で調整する必要があります。この観点から、1 1の双方向保護は、両方のエンドポイント間の調整された保護スイッチングメカニズムと見なすことができます。

Note: it is necessary that both paths are SRLG disjoint to ensure recoverability; otherwise, a single failure may impact both working and protecting LSPs.

6.1. Identifiers

6.1. 識別子

A new PROTECTION object (see Section 14) is included in the Path message. This object carries the desired end-to-end LSP Protection Type -- in this case, "1+1 Bidirectional". This LSP Protection Type value is only applicable to bidirectional LSPs.

新しい保護オブジェクト（セクション14を参照）がパスメッセージに含まれています。このオブジェクトは、目的のエンドツーエンドのLSP保護タイプを搭載しています。この場合、「1 1双方向」です。このLSP保護タイプの値は、双方向LSPにのみ適用されます。

It is also desirable to allow distinguishing the working LSP (from which the signal is taken) from the protecting LSP. This is achieved for the working LSP by setting in the PROTECTION object the S bit to 0, the P bit to 0, and in the ASSOCIATION object, the Association ID to the protecting LSP_ID. The protecting LSP is signaled by setting in the PROTECTION object the S bit to 0, the P bit to 1, and in the ASSOCIATION object the Association ID to the associated protected LSP_ID.

また、動作LSP（信号が採取されている）を保護LSPから区別できるようにすることも望ましい。これは、保護オブジェクトにSビットを0に、Pビットを0に設定し、Associationオブジェクトでは、LSP_IDを保護するための関連付けIDを設定することにより、作業LSPで達成されます。保護LSPは、保護オブジェクトにSビットを0に、Pビットを1に設定し、関連する保護されたLSP_IDに関連するオブジェクトに設定することにより信号があります。

6.2. End-to-End Switchover Request/Response

6.2.

To coordinate the switchover between endpoints, an end-to-end switchover request/response exchange is needed since a failure affecting one of the LSPs results in both endpoints switching to the other LSP (resulting in receiving traffic from the other LSP) in their respective directions.

エンドポイント間のスイッチオーバーを調整するには、LSPのいずれかに影響を与える障害がそれぞれ他のLSPに切り替えるエンドポイントの1つに影響するため、エンドツーエンドのスイッチオーバーリクエスト/応答交換が必要です（他のLSPからトラフィックを受信します）。方向。

The procedure is as follows:

手順は次のとおりです。

1. If an end-node (A or D) detects the failure of the working LSP (or a degradation of signal quality over the working LSP) or receives a Notify message including its SESSION object within the <upstream/downstream session list> (see [RFC3473]), and the new error code/sub-code "Notify Error/ LSP Locally Failed" in the (IF_ID)_ERROR_SPEC object, it MUST begin receiving on the protecting LSP. Note that the <sender descriptor> or <flow descriptor> is also present in the Notify message that resolves any ambiguity and race condition since identifying (together with the SESSION object) the LSP under failure condition.

1. エンドノード（aまたはd）が動作LSPの障害（または動作LSPに対する信号品質の分解）を検出するか、<upstream/downstreamセッションリスト内のセッションオブジェクトを含む通知メッセージを受信した場合（[参照RFC3473]）、および（if_id）_error_specオブジェクトで新しいエラーコード/サブコード「エラー/ LSPが局所的に故障した」という「通知」は、保護LSPで受信を開始する必要があります。<sender記述子>または<フロー記述子>は、故障条件下でLSPを識別してから曖昧さと人種条件を解決するNotifyメッセージにも存在することに注意してください。

Note: (IF_ID)_ERROR_SPEC indicates that either the ERROR_SPEC (C-Type 1/2) or the ERROR_SPEC (C-Type 3/4, defined in [RFC3473]) can be used.

注：（if_id）_error_specは、error_spec（c-type 1/2）またはerror_spec（c-type 3/4、[rfc3473]で定義）を使用できることを示しています。

This node MUST reliably send a Notify message, including the MESSAGE_ID object, to the other end-node (D or A, respectively) with the new error code/sub-code "Notify Error/LSP Failure" (Switchover Request) indicating the failure of the working LSP. This Notify message MUST be sent with the ACK_Desired flag set in the MESSAGE_ID object to request the receiver to send an acknowledgment for the message (see [RFC2961]).

このノードは、障害を示す新しいエラーコード/サブコード「通知エラー/LSP障害」（SwitchOverリクエスト）を使用して、メッセージ_IDオブジェクトを含むNotifyメッセージを他のエンドノード（それぞれDまたはA）に確実に送信する必要があります。作業LSPの。このNotifyメッセージは、Message_IDオブジェクトに設定されたACK_DESIREDフラグを使用して送信する必要があります。

This (switchover request) Notify message MAY indicate the identity of the failed link or any other relevant information using the IF_ID ERROR_SPEC object (see [RFC3473]). In this case, the IF_ID ERROR_SPEC object replaces the ERROR_SPEC object in the Notify message; otherwise, the corresponding (data plane) information SHOULD be received in the PathErr/ResvErr message.

この（スイッチオーバーリクエスト）通知メッセージは、IF_ID ERROR_SPECオブジェクトを使用して、失敗したリンクまたはその他の関連情報のIDを示す場合があります（[RFC3473]を参照）。この場合、IF_ID ERROR_SPECオブジェクトは、NotifyメッセージのERROR_SPECオブジェクトを置き換えます。それ以外の場合、対応する（データプレーン）情報をPatherr/resverrメッセージで受信する必要があります。

2. Upon receipt of the (switchover request) Notify message, the end-node (D or A, respectively) MUST begin receiving from the protecting LSP.

2. （スイッチオーバーリクエスト）通知メッセージを受信すると、エンドノード（それぞれDまたはA）が保護LSPから受信を開始する必要があります。

This node MUST reliably send a Notify message, including the MESSAGE_ID object, to the other end-node (A or D, respectively). This (switchover response) Notify message MUST also include a MESSAGE_ID_ACK object to acknowledge reception of the (switchover request) Notify message.

このノードは、message_idオブジェクトを含むNotifyメッセージを他のエンドノード（それぞれAまたはD）に確実に送信する必要があります。この（スイッチオーバー応答）通知メッセージには、（スイッチオーバーリクエスト）通知メッセージの受信を確認するためのメッセージ_ID_ACKオブジェクトも含める必要があります。

This (switchover response) Notify message MAY indicate the identity of the failed link or any other relevant information using the IF_ID ERROR_SPEC object (see [RFC3473]).

この（スイッチオーバー応答）通知メッセージは、IF_ID ERROR_SPECオブジェクトを使用して、失敗したリンクまたはその他の関連情報のIDを示す場合があります（[RFC3473]を参照）。

Note: upon receipt of the (switchover response) Notify message, the end-node (A or D, respectively) MUST send an Ack message to the other end-node to acknowledge its reception.

注：（スイッチオーバー応答）通知メッセージを受信すると、エンドノード（AまたはD、それぞれ）は、他のエンドノードにACKメッセージを送信して受信を確認する必要があります。

Since the intermediate nodes (B, C, E, F, and G) are assumed to be GMPLS RSVP-TE signaling capable, each node adjacent to the failure MAY generate a Notify message directed either to the LSP head-end (upstream direction), or the LSP tail-end (downstream direction), or even both. Therefore, it is expected that these LSP terminating nodes (that MAY also detect the failure of the LSP from the data plane) provide either the right correlation mechanism to avoid repetition of the above procedure or just discard subsequent Notify messages corresponding to the same Session. In addition, for the LSP under failure condition, it is RECOMMENDED to not set the Path_State_ Removed Flag of the ERROR_SPEC object (see [RFC3473]) upon PathErr message generation.

中間ノード（b、c、e、f、およびg）はgmpls rsvp-teシグナル伝達が可能であると想定されるため、障害に隣接する各ノードは、LSPヘッドエンドに向けられた通知メッセージを生成する場合があります（上流方向）、またはLSPテールエンド（下流方向）、またはその両方。したがって、これらのLSP終端ノード（データプレーンからのLSPの障害も検出される可能性がある）は、上記の手順の繰り返しを避けるために適切な相関メカニズムを提供するか、同じセッションに対応するその後の通知メッセージを破棄することが予想されます。さらに、故障状態でのLSPの場合、PatherRメッセージの生成時に、error_specオブジェクトのpath_state_削除フラグ（[rfc3473]を参照）を設定しないことをお勧めします。

After protection switching completes (step 2), and after reception of the PathErr message, to keep track of the LSP from which the signal is taken, the protecting LSP SHOULD be signaled with the O bit set. The formerly working LSP MAY be signaled with the A bit set in the ADMIN_STATUS object (see [RFC3473]).

保護スイッチングが完了した後（ステップ2）、およびPatherrメッセージの受信後、信号を使用するLSPを追跡するために、保護LSPをOビットセットで信号する必要があります。以前に作業していたLSPは、Admin_Statusオブジェクトに少し設定されたA a bit setでシグナルを受けることができます（[rfc3473]を参照）。

Note: when the N bit is set, the end-to-end switchover request/ response exchange described above only provides control plane coordination (no actions are triggered at the data plane level).

注：nビットが設定されている場合、上記のエンドツーエンドのスイッチオーバー要求/応答交換は、コントロールプレーンの調整のみを提供します（データプレーンレベルではアクションはトリガーされません）。

7. 1:1 Protection with Extra-Traffic

7. 1：1交通量が外れた保護

The most common case of end-to-end 1:N protection is to establish, between the same endpoints, an end-to-end working LSP (thus, N = 1) and a dedicated end-to-end protecting LSP that are mutually link/ node/SRLG disjoint. This protects against working LSP failure(s).

エンドツーエンドの1：n保護の最も一般的なケースは、同じエンドポイント間で、エンドツーエンドの作業LSP（したがって、n = 1）と、専用のエンドツーエンド保護LSPを確立することです。相互にリンク/ノード/ srlg dijoint。これは、LSPの動作障害から保護されます。

The protecting LSP is used for switchover when the working LSP fails. GMPLS RSVP-TE signaling allows for the pre-provisioning of protecting LSPs by indicating in the Path message (in the PROTECTION object; see Section 14) that the LSPs are of type protecting. Here, working and protecting LSPs are signaled as primary LSPs; both are fully instantiated during the provisioning phase.

Protecting LSPは、作業LSPが故障したときにスイッチオーバーに使用されます。GMPLS RSVP-TEシグナル伝達により、PATHメッセージ（保護オブジェクトで、セクション14を参照）でLSPがタイプ保護されていることを示すことにより、LSPを保護することを事前に確認できます。ここでは、LSPの動作と保護が一次LSPとしてシグナル伝えられます。両方とも、プロビジョニングフェーズ中に完全にインスタンス化されます。

Although the resources for the protecting LSP are pre-allocated, preemptable traffic may be carried end-to-end using this LSP. Thus, the protecting LSP is capable of carrying extra-traffic with the caveat that this traffic will be preempted if the working LSP fails.

保護LSPのためのリソースは事前に割り当てられていますが、このLSPを使用して、先制トラフィックをエンドツーエンドで運ぶことができます。したがって、保護LSPは、作業LSPが故障した場合にこのトラフィックが先制されるという警告を使用して、トラフィック外に運ぶことができます。

The setup of the working LSP SHOULD indicate that the LSP head-end and tail-end node wish to receive Notify messages using the NOTIFY REQUEST object. The node upstream to the failure (upstream in terms of the direction an Path message traverses) SHOULD send a Notify message to the LSP head-end node, and the node downstream to the failure SHOULD send an Notify message to the LSP tail-end node. Upon receipt of the Notify messages, both the end-nodes MUST switch the (normal) traffic from the working LSP to the pre-configured protecting LSP (see Section 7.2). Moreover, some coordination is required if extra-traffic is carried over the end-to-end protecting LSP. Note that if the working and the protecting LSP are established between the same end-nodes, no further notification is required to indicate that the working LSPs are no longer protected.

作業LSPのセットアップは、LSPヘッドエンドとテールエンドノードがNotifyリクエストオブジェクトを使用してNotifyメッセージを受信したいことを示す必要があります。障害の上流のノード（パスメッセージが通過する方向の上流の上流）は、LSPヘッドエンドノードに通知メッセージを送信し、障害の下流のノードはLSPテールエンドノードに通知メッセージを送信する必要があります。通知メッセージを受信すると、両方のエンドノードは、（通常の）トラフィックを動作LSPから事前に構成された保護LSPに切り替える必要があります（セクション7.2を参照）。さらに、トラフィックがエンドツーエンドの保護LSPを介して運ばれる場合、いくらかの調整が必要です。作業と保護LSPが同じエンドノード間で確立されている場合、作業LSPがもはや保護されていないことを示すために、それ以上の通知は必要ないことに注意してください。

Consider the following topology:

次のトポロジを検討してください。

                                  A---B---C---D
                                   \         /
                                    E---F---G

The working LSP [A,B,C,D] could be protected by the protecting LSP [A,E,F,G,D]. Both LSPs are fully instantiated (resources are allocated for both working and protecting LSPs) and no resource sharing can be done along the protection path since the primary protecting LSP can carry extra-traffic.

作業LSP [A、B、C、D]は、LSP [A、E、F、G、D]を保護することによって保護できます。両方のLSPは完全にインスタンス化されており（LSPの動作と保護の両方にリソースが割り当てられます）、LSPの主要な保護LSPは交通量の多いものを運ぶ可能性があるため、保護パスに沿ってリソース共有を行うことはできません。

Note: it is necessary that both paths are SRLG disjoint to ensure recoverability; otherwise, a single failure may impact both working and protecting LSPs.

7.1. Identifiers

7.1. 識別子

協会の操作を簡素化するために、両方のLSPが同じセッションに属します。したがって、セッションオブジェクトは両方のLSPで同じでなければなりません。ただし、LSP IDは、作業トラフィックを運ぶ保護されているLSPと、トラフィック以外の保護LSPを区別するために異なる必要があります。

A new PROTECTION object (see Section 14) is included in the Path message used to set up the two LSPs. This object carries the desired end-to-end LSP Protection Type -- in this case, "1:N Protection with Extra-Traffic". This LSP Protection Type value is applicable to both uni- and bidirectional LSPs.

新しい保護オブジェクト（セクション14を参照）は、2つのLSPをセットアップするために使用されるパスメッセージに含まれています。このオブジェクトは、目的のエンドツーエンドのLSP保護タイプ（この場合は「1：N保護を伴う交通による保護」を搭載しています。このLSP保護タイプの値は、単方および双方向LSPの両方に適用できます。

The working LSP is signaled by setting in the new PROTECTION object the S bit to 0, the P bit to 0, and in the ASSOCIATION object, the Association ID to the protecting LSP_ID.

作業LSPは、新しい保護オブジェクトにsビットを0に、pビットを0に設定し、Associationオブジェクトでは、lsp_idを保護するための関連付けIDを設定することにより信号があります。

The protecting LSP is signaled by setting in the new PROTECTION object the S bit to 0, the P bit to 1, and in the ASSOCIATION object, the Association ID to the associated protected LSP_ID.

保護LSPは、新しい保護オブジェクトにSビットを0に、Pビット1に、関連する保護されたLSP_IDにアソシエーションIDを設定することにより信号が表示されます。

7.2. End-to-End Switchover Request/Response

7.2. エンドツーエンドのスイッチオーバーリクエスト/応答

To coordinate the switchover between endpoints, an end-to-end switchover request/response is needed such that the affected LSP is moved to the protecting LSP. Protection switching from the working to the protecting LSP (implying preemption of extra-traffic carried over the protecting LSP) must be initiated by one of the end-nodes (A or D).

エンドポイント間のスイッチオーバーを調整するには、影響を受けるLSPが保護LSPに移動するように、エンドツーエンドのスイッチオーバー要求/応答が必要です。作業から保護LSPへの切り替え（保護LSPを介して携帯するトラフィック外の先制を暗示すること）は、最終ノード（aまたはd）の1つによって開始されなければなりません。

The procedure is as follows:

手順は次のとおりです。

1. If an end-node (A or D) detects the failure of the working LSP (or a degradation of signal quality over the working LSP) or receives a Notify message including its SESSION object within the <upstream/downstream session list> (see [RFC3473]), and the new error code/sub-code "Notify Error/LSP Locally Failed" in the (IF_ID)_ERROR_SPEC object, it disconnects the extra-traffic from the protecting LSP. Note that the <sender descriptor> or <flow descriptor> is also present in the Notify message that resolves any ambiguity and race condition since identifying (together with the SESSION object) the LSP under failure condition.

1. エンドノード（aまたはd）が動作LSPの障害（または動作LSPに対する信号品質の分解）を検出するか、<upstream/downstreamセッションリスト内のセッションオブジェクトを含む通知メッセージを受信した場合（[参照RFC3473]）、および（if_id）_error_specオブジェクトで新しいエラーコード/サブコード「エラー/lspが局所的に故障した」という「通知」は、トラフィック以降を保護するLSPから切断します。<sender記述子>または<フロー記述子>は、故障条件下でLSPを識別してから曖昧さと人種条件を解決するNotifyメッセージにも存在することに注意してください。

2. Upon receipt of the (switchover request) Notify message, the end-node (D or A, respectively) MUST disconnect the extra-traffic from the protecting LSP and begin sending/receiving normal traffic out/from the protecting LSP.

2. （スイッチオーバーリクエスト）通知メッセージを受信すると、エンドノード（それぞれDまたはA）は、交通量の保護LSPから外線を切断し、通常のトラフィックの送信/受信を開始する必要があります。

This (switchover response) Notify message MAY indicate the identity of the failed link or any other relevant information using the IF_ID ERROR_SPEC object (see [RFC3473]).

Note: since the Notify message generated by the other end-node (A or D, respectively) is distinguishable from the one generated by an intermediate node, there is no possibility of connecting the extra-traffic to the working LSP due to the receipt of a Notify message from an intermediate node.

注：他のエンドノード（それぞれAまたはD、それぞれ）によって生成された通知メッセージは、中間ノードによって生成されたメッセージと区別できるため、トラフィック外を作業LSPに接続する可能性はありません。中間ノードからの通知メッセージ。

3. Upon receipt of the (switchover response) Notify message, the end-node (A or D, respectively) MUST begin receiving normal traffic from or sending normal traffic out the protecting LSP.

3. （スイッチオーバー応答）通知メッセージを受信すると、エンドノード（AまたはD、それぞれ）は、通常のトラフィックの受信または保護LSPから通常のトラフィックを送信し始める必要があります。

This node MUST also send an Ack message to the other end-node (D or A, respectively) to acknowledge the reception of the (switchover response) Notify message.

このノードは、（スイッチオーバー応答）通知メッセージの受信を確認するために、他のエンドノード（それぞれDまたはA）にACKメッセージを送信する必要があります。

Note 1: a 2-phase protection-switching signaling is used in the present context; a 3-phase signaling (see [RFC4426]) that would imply a notification message, a switchover request, and a switchover response messages is not considered here. Also, when the protecting LSPs do not carry extra-traffic, protection-switching signaling (as defined in Section 6.2) MAY be used instead of the procedure described in this section.

注1：現在のコンテキストでは、2相保護スイッチングシグナル伝達が使用されています。通知メッセージ、スイッチオーバーリクエスト、およびスイッチオーバー応答メッセージを意味する3フェーズシグナル（[RFC4426]を参照）は、ここでは考慮されません。また、保護LSPがトラフィック以外のトラフィック以外の保護スイッチングシグナル伝達を運ばない場合（セクション6.2で定義されているように）、このセクションで説明する手順の代わりに使用できます。

Note 2: when the N bit is set, the above end-to-end switchover request/response exchange only provides control plane coordination (no actions are triggered at the data plane level).

注2：Nビットが設定されている場合、上記のエンドツーエンドのスイッチオーバーリクエスト/応答交換は、制御プレーンの調整のみを提供します（データプレーンレベルではアクションがトリガーされません）。

After protection switching completes (step 3), and after reception of the PathErr message, to keep track of the LSP from which the normal traffic is taken, the protecting LSP SHOULD be signaled with the O bit set. In addition, the formerly working LSP MAY be signaled with the A bit set in the ADMIN_STATUS object (see [RFC3473]).

7.3. 1:N (N > 1) Protection with Extra-Traffic

7.3. 1：n（n> 1）トラフィック外の保護

1:N (N > 1) protection with extra-traffic assumes that the fully provisioned protecting LSP is resource-disjoint from the N working LSPs. This protecting LSP thereby allows for carrying extra-traffic. Note that the N working LSPs and the protecting LSP are all between the same pair of endpoints. In addition, the N working LSPs (considered as identical in terms of traffic parameters) MAY be mutually resource-disjoint. Coordination between end-nodes is required when switching from one of the working to the protecting LSP.

1：N（n> 1）交通量の多い保護は、完全にプロビジョニングされた保護LSPがN作業LSPからのリソースdisjointであると想定しています。これにより、LSPを保護することで、トラフィック以外の運搬が可能になります。N作業LSPと保護LSPはすべて同じエンドポイントの間にあることに注意してください。さらに、n作業LSP（トラフィックパラメーターと同じと見なされる）は、相互にリソースダイジョンである場合があります。作業の1つから保護LSPに切り替える場合、エンドノード間の調整が必要です。

Each working LSP is signaled with both S bit and P bit set to 0. The LSP Protection Type is set to 0x04 (1:N Protection with Extra-Traffic) during LSP setup. Each Association ID points to the protecting LSP ID.

各作業LSPは、SビットとPビットの両方が0に設定されていることで信号されます。LSP保護タイプは、LSPセットアップ中に0x04（1：N保護を備えた保護）に設定されます。各関連付けIDは、LSP IDの保護を指します。

The protecting LSP (carrying extra-traffic) is signaled with the S bit set to 0 and the P bit set to 1. The LSP Protection Type is set to 0x04 (1:N Protection with Extra-Traffic) during LSP setup. The Association ID MUST be set by default to the LSP ID of the protected LSP corresponding to N = 1.

保護LSP（トラフィックエクストラフィックを運ぶ）は、Sビットを0に設定し、Pビットを1に設定して信号を送信します。LSP保護タイプは、LSPセットアップ中に0x04（1：N保護を伴う交通量のない保護）に設定されます。Association IDは、n = 1に対応する保護されたLSPのLSP IDにデフォルトで設定する必要があります。

Any signaling procedure applicable to 1:1 protection with extra-traffic equally applies to 1:N protection with extra-traffic.

1：1の保護に適用されるシグナリング手順は、交通量が延期されているため、1：nの保護には、トラフィック外の保護に適用されます。

8. Rerouting without Extra-Traffic

8.

End-to-end (pre-planned) rerouting without extra-traffic relies on the establishment between the same pair of end-nodes of a working LSP and a protecting LSP that is link/node/SRLG disjoint from the working LSP. However, in this case the protecting LSP is not fully instantiated; thus, it cannot carry any extra-traffic (note that this does not mean that the corresponding resources cannot be used by other LSPs). Therefore, this mechanism protects against working LSP failure(s) but requires activation of the protecting LSP after failure occurrence.

Signaling is performed by indicating in the Path message (in the PROTECTION object; see Section 14) that the LSPs are of type working and protecting, respectively. Protecting LSPs are used for fast switchover when working LSPs fail. In this case, working and protecting LSPs are signaled as primary LSP and secondary LSP, respectively. Thus, only the working LSP is fully instantiated during the provisioning phase, and for the protecting LSPs, no resources are committed at the data plane level (they are pre-reserved at the control plane level only). The setup of the working LSP SHOULD indicate (using the NOTIFY REQUEST object as specified in Section 4 of [RFC3473]) that the LSP head-end node (and possibly the tail-end node) wish to receive a Notify message upon LSP failure occurrence. Upon receipt of the Notify message, the head-end node MUST switch the (normal) traffic from the working LSP to the protecting LSP after its activation. Note that since the working and the protecting LSPs are established between the same end-nodes, no further notification is required to indicate that the working LSPs are without protection.

シグナル伝達は、PATHメッセージ（保護オブジェクトで、セクション14を参照）で、LSPがそれぞれ型で機能し、保護されていることを示すことによって実行されます。LSPの保護は、LSPの動作が失敗するときに高速スイッチオーバーに使用されます。この場合、LSPの動作と保護は、それぞれ一次LSPおよび二次LSPとしてシグナル付けされます。したがって、プロビジョニングフェーズ中に作業用LSPのみが完全にインスタンス化され、保護LSPの場合、データプレーンレベルでリソースはコミットされません（制御プレーンレベルのみで事前に予約されています）。作業LSPのセットアップは、LSPヘッドエンドノード（およびテールエンドノード）がLSPの故障発生時に通知メッセージを受信することを望んでいることを（[RFC3473]のセクション4で指定した通知要求オブジェクトを使用して）示す必要があります。。Notifyメッセージを受信すると、ヘッドエンドノードは、活性化後に（通常の）トラフィックを動作LSPから保護LSPに切り替える必要があります。作業と保護LSPは同じエンドノードの間に確立されるため、作業LSPが保護されていないことを示すために、それ以上の通知は必要ないことに注意してください。

To make bandwidth pre-reserved for a protecting (but not activated) LSP available for extra-traffic, this bandwidth could be included in the advertised Unreserved Bandwidth at priority lower (means numerically higher) than the Holding Priority of the protecting LSP. In addition, the Max LSP Bandwidth field in the Interface Switching Capability Descriptor sub-TLV should reflect the fact that the bandwidth pre-reserved for the protecting LSP is available for extra traffic. LSPs for extra-traffic then can be established using the bandwidth pre-reserved for the protecting LSP by setting (in the Path message) the Setup Priority field of the SESSION_ATTRIBUTE object to X (where X is the Setup Priority of the protecting LSP), and the Holding Priority field to at least X+1. Also, if the resources pre-reserved for the protecting LSP are used by lower-priority LSPs, these LSPs MUST be preempted when the protecting LSP is activated (see Section 10).

トラフィック外の保護（しかし活性化されていない）LSPのために帯域幅を事前に保護するために、この帯域幅は、保護LSPの優先度よりも優先度の低い（数値的に高いことを意味する）優先度の低い未予約帯域幅に含めることができます。さらに、インターフェイススイッチング機能記述子Sub-TLVの最大LSP帯域幅フィールドは、保護用LSPのために帯域幅が予約されているという事実を反映する必要があります。交通量の多いLSPは、（パスメッセージで）セッション_Attributeオブジェクトのセットアップ優先フィールドをx（xは保護LSPのセットアップ優先度）に設定することにより、LSPを保護するために事前に予約された帯域幅を使用して確立できます。また、少なくともx 1までの優先度フィールドは、保護用LSPのために事前にリソースを保護するリソースが低優先度のLSPによって使用される場合、これらのLSPを保護するLSPが活性化されるときに先取りする必要があります（セクション10を参照）。

Consider the following topology:

次のトポロジを検討してください。

                                  A---B---C---D
                                   \         /
                                    E---F---G

The working LSP [A,B,C,D] could be protected by the protecting LSP [A,E,F,G,D]. Only the protected LSP is fully instantiated (resources are only allocated for the working LSP). Therefore, the protecting LSP cannot carry any extra-traffic. When a failure is detected on the working LSP (say, at B), the error is propagated and/or notified (using a Notify message with the new error code/sub-code "Notify Error/LSP Locally Failed" in the (IF_ID)_ERROR_SPEC object) to the ingress node (A). Upon reception, the latter activates the secondary protecting LSP instantiated during the (pre-)provisioning phase. This requires:

作業LSP [A、B、C、D]は、LSP [A、E、F、G、D]を保護することによって保護できます。保護されたLSPのみが完全にインスタンス化されます（リソースは、作業LSPにのみ割り当てられます）。したがって、保護するLSPは交通量の多いものを運ぶことはできません。動作LSP（たとえば、bで）で障害が検出されると、エラーは伝播および/または通知されます（新しいエラーコード/サブコードを使用してnotifyメッセージを使用して、（if_id/lspが局所的に失敗した」）_ERROR_SPECオブジェクト）イングレスノード（a）へ。受信後、後者は（事前）プロビジョニングフェーズ中にインスタンス化された二次保護LSPを活性化します。これには次のことが必要です。

(1)

In the following subsections, these features are described in more detail.

次のサブセクションでは、これらの機能について詳しく説明します。

8.1. Identifiers

8.1.

To simplify association operations, both LSPs (i.e., the protected and the secondary LSPs) belong to the same session. Thus, the SESSION object MUST be the same for both LSPs. The LSP ID, however, MUST be different to distinguish between the protected LSP carrying working traffic and the secondary LSP that cannot carry extra-traffic.

協会の操作を簡素化するために、両方のLSP（つまり、保護されたLSPとセカンダリLSP）の両方が同じセッションに属します。したがって、セッションオブジェクトは両方のLSPで同じでなければなりません。ただし、LSP IDは、作業トラフィックを運ぶ保護されているLSPと、トラフィック以外の運搬できないセカンダリLSPを区別するために異なる必要があります。

A new PROTECTION object (see Section 14) is used to set up the two LSPs. This object carries the desired end-to-end LSP Protection Type (in this case, "Rerouting without Extra-Traffic"). This LSP Protection Type value is applicable to both uni- and bidirectional LSPs.

新しい保護オブジェクト（セクション14を参照）を使用して、2つのLSPをセットアップします。このオブジェクトには、目的のエンドツーエンドのLSP保護タイプ（この場合は「トラフィック外ではなく再ルーティング」）を搭載しています。このLSP保護タイプの値は、単方および双方向LSPの両方に適用できます。

8.2. Signaling Primary LSPs

8.2. プライマリLSPのシグナリング

The new PROTECTION object is included in the Path message during signaling of the primary working LSP, with the end-to-end LSP Protection Type value set to "Rerouting without Extra-Traffic".

新しい保護オブジェクトは、プライマリ作業LSPのシグナル伝達中にパスメッセージに含まれており、エンドツーエンドのLSP保護タイプ値は「トラフィック外ではなく再ルーティング」に設定されています。

Primary working LSPs are signaled by setting in the new PROTECTION object the S bit to 0, the P bit to 0, and in the ASSOCIATION object, the Association ID to the associated secondary protecting LSP_ID.

プライマリ作業LSPは、新しい保護オブジェクトにSビットを0に、Pビットを0に設定し、Associationオブジェクトでは、関連するセカンダリ保護LSP_IDに関連するオブジェクトに設定することにより信号があります。

8.3. Signaling Secondary LSPs

8.3. シグナリング二次LSP

The new PROTECTION object is included in the Path message during signaling of secondary protecting LSPs, with the end-to-end LSP Protection Type value set to "Rerouting without Extra-Traffic".

新しい保護オブジェクトは、LSPの二次保護のシグナル伝達中にパスメッセージに含まれ、エンドツーエンドのLSP保護タイプ値は「トラフィック以外の再ルーティング」に設定されています。

二次保護LSPは、新しい保護オブジェクトにsビットとpビットを1に設定することにより、および関連するプライマリワーキングLSP_IDへのアソシエーションIDを設定することにより信号があります。

With this setting, the resources for the secondary LSP SHOULD be pre-reserved, but not committed at the data plane level, meaning that the internals of the switch need not be established until explicit action is taken to activate this secondary LSP. Activation of a secondary LSP is done using a modified Path message with the S bit set to 0 in the PROTECTION object. At this point, the link and node resources must be allocated for this LSP that becomes a primary LSP (ready to carry normal traffic).

この設定では、セカンダリLSPのリソースは事前に予約されている必要がありますが、データプレーンレベルではコミットされていません。つまり、このセカンダリLSPをアクティブにするために明示的なアクションが取られるまで、スイッチの内部を確立する必要はありません。セカンダリLSPのアクティブ化は、保護オブジェクトでSビットが0に設定された変更されたパスメッセージを使用して行われます。この時点で、リンクとノードのリソースを、主要なLSPになるこのLSPに割り当てる必要があります（通常のトラフィックを運ぶ準備ができています）。

From [RFC3945], the secondary LSP is set up with resource pre-reservation but with or without label pre-selection (both allowing sharing of the recovery resources). In the former case (defined as the default), label allocation during secondary LSP signaling does not require any specific procedure compared to [RFC3473]. However, in the latter case, label (and thus resource) re-allocation MAY occur during the secondary LSP activation. This means that during the LSP activation phase, labels MAY be reassigned (with higher precedence over existing label assignment; see also [RFC3471]).

[RFC3945]から、セカンダリLSPはリソースの事前予約でセットアップされていますが、ラベル前選択の有無にかかわらず（両方とも回復リソースの共有を可能にします）。前者の場合（デフォルトとして定義）、二次LSPシグナル伝達中のラベル割り当ては、[RFC3473]と比較して特定の手順を必要としません。ただし、後者の場合、二次LSPの活性化中にラベル（したがってリソース）の再配分が発生する可能性があります。これは、LSPアクティベーションフェーズ中に、ラベルが再割り当てされる可能性があることを意味します（既存のラベル割り当てよりも優先されます。[RFC3471]も参照）。

Note: under certain circumstances (e.g., when pre-reserved protecting resources are used by lower-priority LSPs), it MAY be desirable to perform the activation of the secondary LSP in the upstream direction (Resv trigger message) instead of using the default downstream activation. In this case, any mis-ordering and any mis-interpretation between a refresh Resv (along the lower-priority LSP) and a trigger Resv message (along the secondary LSP) MUST be avoided at any intermediate node. For this purpose, upon reception of the Path message, the egress node MAY include the PROTECTION object in the Resv message. The latter is then processed on a hop-by-hop basis to activate the secondary LSP until reaching the ingress node. The PROTECTION object included in the Path message MUST be set as specified in this section. In this case, the PROTECTION object with the S bit MUST be set to 0 and included in the Resv message sent in the upstream direction. The upstream activation behavior SHOULD be configurable on a local basis. Details concerning lower-priority LSP preemption upon secondary LSP activation are provided in Section 10.

注：特定の状況（例えば、事前に予約された保護リソースが低優先度LSPによって使用される場合）では、デフォルトのダウンストリームを使用する代わりに、上流方向（RESVトリガーメッセージ）で二次LSPのアクティブ化を実行することが望ましい場合があります。活性化。この場合、誤った注文と誤った解釈は、リフレッシュRESV（より低優先度のLSPに沿って）とトリガーRESVメッセージ（セカンダリLSPに沿って）を中間ノードで回避する必要があります。この目的のために、パスメッセージを受信すると、出力ノードにはRESVメッセージに保護オブジェクトを含めることができます。後者は、ホップバイホップベースで処理され、イングレスノードに到達するまでセカンダリLSPをアクティブにします。パスメッセージに含まれる保護オブジェクトは、このセクションで指定されているように設定する必要があります。この場合、Sビットの保護オブジェクトを0に設定し、上流方向に送信されたRESVメッセージに含める必要があります。上流のアクティベーション動作は、現地で構成可能である必要があります。セクション10には、二次LSPの活性化に関する低優先度のLSP先制に関する詳細が提供されています。

9. Shared-Mesh Restoration

9. 共有メッシュの修復

An approach to reduce recovery resource requirements is to have protection LSPs sharing network resources when the working LSPs that they protect are physically (i.e., link, node, SRLG, etc.) disjoint. This mechanism is referred to as shared mesh restoration and is described in [RFC4426]. Shared-mesh restoration can be seen as a particular case of pre-planned LSP rerouting (see Section 8) that reduces the recovery resource requirements by allowing multiple protecting LSPs to share common link and node resources. Here also, the recovery resources for the protecting LSPs are pre-reserved during the provisioning phase, thus an explicit signaling action is required to activate (i.e., commit resource allocation at the data plane) a specific protecting LSP instantiated during the (pre-) provisioning phase. This requires restoration signaling along the protecting LSP.

回復リソースの要件を削減するアプローチは、保護するLSPが保護する場合にネットワークリソースを保護することです。このメカニズムは、共有メッシュの復元と呼ばれ、[RFC4426]に記載されています。共有メッシュの復元は、複数の保護LSPが共通のリンクとノードリソースを共有できるようにすることにより、回復リソースの要件を削減する事前に計画されたLSP再リルアウトの特定のケースと見なすことができます（セクション8を参照）。ここでも、保護LSPの回復リソースはプロビジョニングフェーズ中に事前に予約されているため、（つまり、データプレーンでリソース割り当てをコミットする）ために明示的なシグナリングアクションが必要です（つまり、プレ - ）中にインスタンス化されたLSPを保護する特定の保護が必要です。プロビジョニングフェーズ。これには、保護LSPに沿った復元シグナル伝達が必要です。

To make bandwidth pre-reserved for a protecting (but not activated) LSP, available for extra-traffic this bandwidth could be included in the advertised Unreserved Bandwidth at priority lower (means numerically higher) than the Holding Priority of the protecting LSP. In addition, the Max LSP Bandwidth field in the Interface Switching Capability Descriptor sub-TLV should reflect the fact that the bandwidth pre-reserved for the protecting LSP is available for extra traffic. LSPs for extra-traffic then can be established using the bandwidth pre-reserved for the protecting LSP by setting (in the Path message) the Setup Priority field of the SESSION_ATTRIBUTE object to X (where X is the Setup Priority of the protecting LSP) and the Holding Priority field to at least X+1. Also, if the resources pre-reserved for the protecting LSP are used by lower priority LSPs, these LSPs MUST be preempted when the protecting LSP is activated (see Section 10). Further, if the recovery resources are shared between multiple protecting LSPs, the corresponding working LSPs head-end nodes must be informed that they are no longer protected when the protecting LSP is activated to recover the normal traffic for the working LSP under failure.

保護（しかし活性化されていない）LSPのために帯域幅を事前に保存するために、この帯域幅外幅に利用可能なLSPの保持優先度よりも優先度の低い（数値的に高いことを意味）、広告されていない帯域幅には、宣伝されていない帯域幅に含めることができます。さらに、インターフェイススイッチング機能記述子Sub-TLVの最大LSP帯域幅フィールドは、保護用LSPのために帯域幅が予約されているという事実を反映する必要があります。トラフィック外のLSPは、（パスメッセージで）セッション_Attributeオブジェクトのセットアップ優先フィールドをx（xは保護LSPのセットアップ優先度）と、および保護するためにLSPを保護するために事前に予約した帯域幅を使用して確立できます。保持優先フィールドは少なくともx 1までです。また、保護用LSPのために事前にリソースが優先度の低いLSPによって使用される場合、これらのLSPを保護するLSPがアクティブ化されるときに先取りする必要があります（セクション10を参照）。さらに、回復リソースが複数の保護LSP間で共有されている場合、対応する作業LSPヘッドエンドノードは、障害下で動作するLSPの通常のトラフィックを回復するために保護LSPがアクティブ化されたときにもはや保護されていないことを通知する必要があります。

Consider the following topology:

次のトポロジを検討してください。

                                  A---B---C---D
                                   \         /
                                    E---F---G
                                   /         \
                                  H---I---J---K

The working LSPs [A,B,C,D] and [H,I,J,K] could be protected by [A,E,F,G,D] and [H,E,F,G,K], respectively. Per [RFC3209], in order to achieve resource sharing during the signaling of these protecting LSPs, they must have the same Tunnel Endpoint Address (as part of their SESSION object). However, these addresses are not the same in this example. Resource sharing along E, F, and G can only be achieved if the nodes E, F, and G recognize that the LSP Protection Type of the secondary LSP is set to "Rerouting without Extra-Traffic" (see PROTECTION object, Section 14) and acts accordingly. In this case, the protecting LSPs are not merged (which is useful since the paths diverge at G), but the resources along E, F, G can be shared.

動作するLSP [a、b、c、d]および[h、i、j、k]は、[a、e、f、g、d]および[h、e、f、g、k]によって保護される可能性があります。それぞれ。[RFC3209]によると、これらの保護LSPのシグナル伝達中にリソース共有を達成するためには、同じトンネルエンドポイントアドレス（セッションオブジェクトの一部として）を持たなければなりません。ただし、これらのアドレスはこの例では同じではありません。E、F、およびGに沿ったリソース共有は、ノードE、F、およびGが、セカンダリLSPのLSP保護タイプが「交通量のないものなしで再ルーティング」に設定されていることを認識した場合にのみ達成できます（保護オブジェクト、セクション14を参照）それに応じて行動します。この場合、保護LSPはマージされていません（これは、gで発生するため、これは有用です）が、e、f、gに沿ったリソースを共有できます。

When a failure is detected on one of the working LSPs (say, at B), the error is propagated and/or notified (using a Notify message with the new error code/sub-code "Notify Error/LSP Locally Failed" in the (IF_ID)_ERROR_SPEC object) to the ingress node (A). Upon reception, the latter activates the secondary protecting LSP (see Section 8). At this point, it is important that a failure on the other LSP (say, at J) does not cause the other ingress (H) to send the data down the protecting LSP since the resources are already in use. This can be achieved by node E using the following procedure. When the capacity is first reserved for the protecting LSP, E should verify that the LSPs being protected ([A,B,C,D] and [H,I,J,K], respectively) do not share any common resources. Then, when a failure occurs (say, at B) and the protecting LSP [A,E,F,G,D] is activated, E should notify H that the resources for the protecting LSP [H,E,F,G,K] are no longer available.

動作LSPの1つ（たとえば、bで）で障害が検出されると、エラーが伝播および/または通知されます（新しいエラーコード/サブコードで「notify error/lspが局所的に失敗した」というnotifyメッセージを使用して、（if_id）_error_specオブジェクト）イングレスノード（a）へ。受信後、後者は二次保護LSPを活性化します（セクション8を参照）。この時点で、他のLSP（たとえば、J）の障害により、他の侵入（h）がリソースがすでに使用されているため、データを保護LSPに送信しないことが重要です。これは、次の手順を使用してノードEで実現できます。容量がLSPの保護のために最初に予約されている場合、EはLSPが保護されていることを確認する必要があります（それぞれ[a、b、c、d]および[h、i、j、k]が共通のリソースを共有しないことを確認する必要があります。次に、障害が発生した場合（たとえば、bで）、保護LSP [a、e、f、g、d]がアクティブ化されると、eはlsp [h、e、f、g、k]は利用できなくなりました。

The following subsections detail how shared mesh restoration can be implemented in an interoperable fashion using GMPLS RSVP-TE extensions (see [RFC3473]). This includes:

次のサブセクションでは、GMPLS RSVP-TE拡張機能を使用して、共有メッシュの修復を相互運用可能な方法で実装する方法を詳しく説明しています（[RFC3473]を参照）。これも：

(1) the ability to identify a "secondary protecting LSP" (hereby called the "secondary LSP") used to recover another primary working LSP (hereby called the "protected LSP") (2) the ability to associate the secondary LSP with the protected LSP (3) the capability to include information about the resources used by the protected LSP while instantiating the secondary LSP. (4) the capability to instantiate during the provisioning phase several secondary LSPs in an efficient manner. (5) the capability to activate a secondary LSP after failure occurrence.

(1) 別の主要な作業LSP（「保護されたLSP」と呼ばれる）を回復するために使用される「二次保護LSP」（「セカンダリLSP」と呼ばれる）を識別する能力（2）セカンダリLSPを保護されたLSPに関連付ける能力（2）3）セカンダリLSPをインスタンス化しながら、保護されたLSPが使用するリソースに関する情報を含める機能。（4）プロビジョニングフェーズ中に、効率的な方法でいくつかの二次LSPをインスタンス化する機能。（5）故障発生後に二次LSPをアクティブにする能力。

In the following subsections, these features are described in detail.

次のサブセクションでは、これらの機能について詳しく説明します。

9.1. Identifiers

9.1. 識別子

A new PROTECTION object (see Section 14) is used to set up the two LSPs. This object carries the desired end-to-end LSP Protection Type -- in this case, "Rerouting without Extra-Traffic". This LSP Protection Type value is applicable to both uni- and bidirectional LSPs.

新しい保護オブジェクト（セクション14を参照）を使用して、2つのLSPをセットアップします。このオブジェクトは、目的のエンドツーエンドのLSP保護タイプを搭載しています。この場合は、「交通量のないリアウト」です。このLSP保護タイプの値は、単方および双方向LSPの両方に適用できます。

9.2. Signaling Primary LSPs

9.2. プライマリLSPのシグナリング

The new PROTECTION object is included in the Path message during signaling of the primary working LSPs, with the end-to-end LSP Protection Type value set to "Rerouting without Extra-Traffic".

新しい保護オブジェクトは、プライマリ作業LSPのシグナリング中にパスメッセージに含まれており、エンドツーエンドのLSP保護タイプ値は「トラフィック外ではなく再ルーティング」に設定されています。

9.3. Signaling Secondary LSPs

9.3. シグナリング二次LSP

The new PROTECTION object is included in the Path message during signaling of the secondary protecting LSPs, with the end-to-end LSP Protection Type value set to "Rerouting without Extra-Traffic".

新しい保護オブジェクトは、LSPのセカンダリ保護のシグナル伝達中にパスメッセージに含まれており、エンドツーエンドのLSP保護タイプ値は「トラフィック外ではなく再ルーティング」に設定されています。

Secondary protecting LSPs are signaled by setting in the new PROTECTION object the S bit and the P bit to 1, and in the ASSOCIATION object, the Association ID to the associated primary working LSP_ID, which MUST be known before signaling of the secondary LSP. Moreover, the Path message used to instantiate the secondary LSP SHOULD include at least one PRIMARY_PATH_ROUTE object (see Section 15) that further allows for recovery resource sharing at each intermediate node along the secondary path.

二次保護LSPは、新しい保護オブジェクトにsビットとpビットを1に設定することにより、および関連するプライマリワーキングLSP_IDへのアソシエーションIDを設定することにより信号があります。さらに、セカンダリLSPをインスタンス化するために使用されるパスメッセージには、セカンダリパスに沿った各中間ノードでリカバリリソース共有をさらに可能にする少なくとも1つのプライマリ_Path_Routeオブジェクト（セクション15を参照）を含める必要があります。

With this setting, the resources for the secondary LSP SHOULD be pre-reserved, but not committed at the data plane level, meaning that the internals of the switch need not be established until explicit action is taken to activate this LSP. Activation of a secondary LSP is done using a modified Path message with the S bit set to 0 in the PROTECTION object. At this point, the link and node resources must be allocated for this LSP that becomes a primary LSP (ready to carry normal traffic).

この設定では、セカンダリLSPのリソースは事前に予約されている必要がありますが、データプレーンレベルではコミットされていません。つまり、このLSPをアクティブにするために明示的なアクションが取られるまで、スイッチの内部を確立する必要はありません。セカンダリLSPのアクティブ化は、保護オブジェクトでSビットが0に設定された変更されたパスメッセージを使用して行われます。この時点で、リンクとノードのリソースを、主要なLSPになるこのLSPに割り当てる必要があります（通常のトラフィックを運ぶ準備ができています）。

From [RFC3945], the secondary LSP is set up with resource pre-reservation but with or without label pre-selection (both allowing sharing of the recovery resources). In the former case (defined as the default), label allocation during secondary LSP signaling does not require any specific procedure compared to [RFC3473]. However, in the latter case, label (and thus resource) re-allocation MAY occur during the secondary LSP activation. This means that, during the LSP activation phase, labels MAY be reassigned (with higher precedence over existing label assignment; see also [RFC3471]).

[RFC3945]から、セカンダリLSPはリソースの事前予約でセットアップされていますが、ラベル前選択の有無にかかわらず（両方とも回復リソースの共有を可能にします）。前者の場合（デフォルトとして定義）、二次LSPシグナル伝達中のラベル割り当ては、[RFC3473]と比較して特定の手順を必要としません。ただし、後者の場合、二次LSPの活性化中にラベル（したがってリソース）の再配分が発生する可能性があります。これは、LSPの活性化フェーズ中に、ラベルが再割り当てされる可能性があることを意味します（既存のラベル割り当てよりも優先されるよりも高い。[RFC3471]も参照）。

10. LSP Preemption

10. LSPプリエンプション

When protecting resources are only pre-reserved for the secondary LSPs, they MAY be used to set up lower-priority LSPs. In this case, these resources MUST be preempted when the protecting LSP is activated. An additional condition raises from misconnection avoidance between the secondary protecting LSP being activated and the low-priority LSP(s) being preempted. Procedure to be applied when the secondary protecting LSP (i.e., the preempting LSP) Path message reaches a node using the resources for lower-priority LSP(s) (i.e., preempted LSP(s)) is as follows: 1. De-allocate resources to be used by the preempting LSP and release the cross-connection. Note that if the preempting LSP is bidirectional, these resources may come from one or two lower-priority LSPs, and if from two LSPs, they may be uni- or bi-directional. The preempting node SHOULD NOT send the Path message before the de-allocation of resources has completed since this may lead to the downstream path becoming misconnected if the downstream node is able to reassign the resources more quickly.

リソースを保護することは、二次LSPのためだけに事前に予約されている場合、より低優先度のLSPをセットアップするために使用される場合があります。この場合、これらのリソースは、保護LSPがアクティブ化されたときに先取りする必要があります。LSPが活性化される二次保護と低優先LSP（S）が先制される間の誤接続回避から追加の条件が上昇します。適用する手順LSP（つまり、先制LSP）パスメッセージが低優先順位LSP（S）（つまり、先制LSP（s））のリソースを使用してノードに到達する場合に適用する手順は次のとおりです。1。de-allocateLSPを先取りして使用し、クロス接続を解放するリソース。Preempting LSPが双方向である場合、これらのリソースは1つまたは2つの低優先度のLSPから来る可能性があり、2つのLSPからの場合、それらは一方向または双方向である可能性があることに注意してください。下流ノードがリソースをより迅速に再割り当てできる場合、リソースの脱アラケーションが完了する前に、リソースの脱アラケーションが完了する前にパスメッセージを送信してはなりません。

2. Send PathTear and PathErr messages with the new error code/sub-code "Policy Control failure/Hard preempted" and the Path_State_Removed flag set for the preempted LSP(s).

3. Reserve the preempted resources for the protecting LSP. The preempting node MUST NOT cross-connect the upstream resources of a bidirectional preempting LSP.

3. 保護LSPのための先制リソースを予約します。先制ノードは、LSPを双方向にプリエンプする上流のリソースをクロス接続してはなりません。

4. Send the Path message.

4. パスメッセージを送信します。

5. Upon reception of a trigger Resv message from the downstream node, cross-connect the downstream path resources, and if the preempting LSP is bidirectional, perform cross-connection for the upstream path resources.

5. ダウンストリームノードからトリガーRESVメッセージを受信すると、ダウンストリームパスリソースをクロス接続し、Preempting LSPが双方向である場合は、上流のパスリソースに対して相互接続を実行します。

Note that step 1 may cause alarms to be raised for the preempted LSP. If alarm suppression is desired, the preempting node MAY insert the following steps before step 1.

ステップ1では、先制型LSPのアラームが発生する可能性があることに注意してください。アラーム抑制が必要な場合、先制ノードはステップ1の前に次の手順を挿入する場合があります。

1a. Before de-allocating resources, send a Resv message, including an ADMIN_STATUS object, to disable alarms for the preempted LSP. 1b. Receive a Path message indicating that alarms are disabled.

1a。リソースを解凍する前に、admin_statusオブジェクトを含むRESVメッセージを送信して、先制lspのアラームを無効にします。1b。アラームが無効になっていることを示すパスメッセージを受信します。

At the downstream node (with respect to the preempting LSP), the processing is RECOMMENDED to be as follows:

下流ノード（Preempting LSPに関して）では、処理は次のとおりであることをお勧めします。

1. Receive PathTear (and/or PathErr) message for the preempted LSP(s).

1. 先制lsp（および/またはpatherr）メッセージを受信します。

2a. Release the resources associated with the LSP on the interface to the preempting LSP, remove any cross-connection, and release all other resources associated with the preempted LSP. 2b. Forward the PathTear (and/or PathErr) message per [RFC3473].

2a。インターフェイス上のLSPに関連付けられたリソースをリリースして、LSPを先制し、相互接続を削除し、先制型LSPに関連付けられた他のすべてのリソースをリリースします。2b。[RFC3473]ごとにPATHTEAR（および/またはPatherr）メッセージを転送します。

3. Receive the Path message for the preempting LSP and process as normal, forwarding it to the downstream node.

3. LSPを先取りするためのパスメッセージを受信し、通常どおりプロセスして、下流ノードに転送します。

4. Receive the Resv message for the preempting LSP and process as normal, forwarding it to the upstream node.

4. LSPを先制するためのRESVメッセージを受信し、通常どおりプロセスして、アップストリームノードに転送します。

11. (Full) LSP Rerouting

11. （フル）LSP Rerouting

LSP rerouting, on the other hand, switches normal traffic to an alternate LSP that is fully established only after failure occurrence. The new (alternate) route is selected at the LSP head-end and may reuse intermediate nodes included in the original route; it may also include additional intermediate nodes. For strict-hop routing, TE requirements can be directly applied to the route computation, and the failed node or link can be avoided. However, if the failure occurred within a loose-routed hop, the head-end node may not have enough information to reroute the LSP around the failure. Crankback signaling (see [CRANK]) and route exclusion techniques (see [RFC4874]) MAY be used in this case.

一方、LSPルーティングは、故障が発生した後にのみ完全に確立される代替LSPに通常のトラフィックを切り替えます。新しい（代替）ルートはLSPヘッドエンドで選択され、元のルートに含まれる中間ノードを再利用する場合があります。また、追加の中間ノードが含まれる場合があります。Strict-Hopルーティングの場合、TE要件はルート計算に直接適用でき、失敗したノードまたはリンクを回避できます。ただし、ルーズルートホップ内で障害が発生した場合、ヘッドエンドノードには、障害の周りでLSPを再ルーティングするのに十分な情報がない場合があります。この場合、クランクバックシグナル伝達（[クランク]を参照）およびルート除外技術（[RFC4874]を参照）を使用できます。

The alternate route MAY be either computed on demand (that is, when the failure occurs; this is referred to as full LSP rerouting) or pre-computed and stored for use when the failure is reported. The latter offers faster restoration time. There is, however, a risk that the alternate route will become out of date through other changes in the network; this can be mitigated to some extent by periodic recalculation of idle alternate routes.

代替ルートは、オンデマンドで計算される可能性があります（つまり、障害が発生した場合、これは完全なLSPルーティングと呼ばれます）か、障害が報告されたときに使用するために事前に計算され、保存されます。後者は、より速い修復時間を提供します。ただし、ネットワークの他の変更により、代替ルートが時代遅れになるリスクがあります。これは、アイドル代替ルートの定期的な再計算により、ある程度緩和できます。

(Full) LSP rerouting will be initiated by the head-end node that has either detected the LSP failure or received a Notify message and/or a PathErr message with the new error code/sub-code "Notify Error/LSP Locally Failed" for this LSP. The new LSP resources can be established using the make-before-break mechanism, where the new LSP is set up before the old LSP is torn down. This is done by using the mechanisms of the SESSION_ATTRIBUTE object and the Shared-Explicit (SE) reservation style (see [RFC3209]). Both the new and old LSPs can share resources at common nodes.

（FULL）LSP Reroutingは、LSP障害を検出したか、新しいエラーコード/サブコードを使用してNotifyメッセージおよび/またはPatherRメッセージを受信したヘッドエンドノードによって開始されます。このLSP。新しいLSPリソースは、古いLSPが取り壊される前に新しいLSPがセットアップされるメイクブレイク前のメカニズムを使用して確立できます。これは、session_attributeオブジェクトのメカニズムと共有explicit（se）予約スタイルを使用して行われます（[rfc3209]を参照）。新しいLSPと古いLSPの両方は、共通ノードでリソースを共有できます。

Note that the make-before-break mechanism is not used to avoid disruption to the normal traffic flow (the latter has already been broken by the failure that is being repaired). However, it is valuable to retain the resources allocated on the original LSP that will be reused by the new alternate LSP.

ブレイク前のメカニズムは、通常のトラフィックフローの破壊を避けるために使用されていないことに注意してください（後者は、修復されている障害によってすでに破られています）。ただし、新しい代替LSPによって再利用される元のLSPに割り当てられたリソースを保持することは価値があります。

11.1. Identifiers

11.1. 識別子

The Tunnel Endpoint Address, Tunnel ID, Extended Tunnel ID, and Tunnel Sender Address uniquely identify both the old and new LSPs. Only the LSP_ID value differentiates the old from the new alternate LSP. The new alternate LSP is set up before the old LSP is torn down using Shared-Explicit (SE) reservation style. This ensures that the new (alternate) LSP is established without double-counting resource requirements along common segments.

トンネルエンドポイントアドレス、トンネルID、拡張トンネルID、およびトンネル送信者アドレスは、古いLSPと新しいLSPの両方を一意に識別します。LSP_ID値のみが古いものを新しい代替LSPと区別します。新しい代替LSPは、Shared-Explicit（SE）予約スタイルを使用して、古いLSPが取り壊される前に設定されます。これにより、一般的なセグメントに沿って、新しい（代替）LSPがダブルカウントリソース要件なしで確立されることが保証されます。

The alternate LSP MAY be set up before any failure occurrence with SE-style resource reservation, the latter shares the same Tunnel End Point Address, Tunnel ID, Extended Tunnel ID, and Tunnel Sender Address with the original LSP (i.e., only the LSP ID value MUST be different).

代替LSPは、SEスタイルのリソース予約で障害が発生する前にセットアップできます。後者は、元のLSPと同じトンネルエンドポイントアドレス、トンネルID、拡張トンネルID、トンネルセンダーアドレスを共有します（つまり、LSP IDのみがLSP IDのみです。値は異なる必要があります）。

In both cases, the Association ID of the ASSOCIATION object MUST be set to the LSP ID value of the signaled LSP.

どちらの場合も、AssociationオブジェクトのアソシエーションIDは、信号されたLSPのLSP ID値に設定する必要があります。

11.2. Signaling Reroutable LSPs

11.2. シグナリング再利用可能なLSP

A new PROTECTION object is included in the Path message during signaling of dynamically reroutable LSPs, with the end-to-end LSP Protection Type value set to "Full Rerouting". These LSPs that can be either uni- or bidirectional are signaled by setting in the PROTECTION object the S bit to 0, the P bit to 0, and the Association ID value to the LSP_ID value of the signaled LSP. Any specific action to be taken during the provisioning phase is up to the end-node local policy.

Note: when the end-to-end LSP Protection Type is set to "Unprotected", both S and P bit MUST be set to 0, and the LSP SHOULD NOT be rerouted at the head-end node after failure occurrence. The Association_ID value MUST be set to the LSP_ID value of the signaled LSP. This does not mean that the Unprotected LSP cannot be re-established for other reasons such as path re-optimization and bandwidth adjustment driven by policy conditions.

注：エンドツーエンドのLSP保護タイプが「保護されていない」に設定されている場合、sとpの両方を0に設定する必要があり、故障が発生した後、LSPをヘッドエンドノードで再ルーティングする必要はありません。Association_id値は、信号lspのlsp_id値に設定する必要があります。これは、保護されていないLSPが、パスの再最適化や政策条件によって駆動される帯域幅の調整など、他の理由で再確立できないことを意味するものではありません。

12. Reversion

12. 復帰

Reversion refers to a recovery switching operation, where the normal traffic returns to (or remains on) the working LSP when it has recovered from the failure. Reversion implies that resources remain allocated to the LSP that was originally routed over them even after a failure. It is important to have mechanisms that allow reversion to be performed with minimal service disruption and reconfiguration.

復帰とは、回復スイッチング操作を指します。ここでは、通常のトラフィックが障害から回復したときに動作するLSPに戻ります（またはそのままです）。復帰は、リソースが失敗後でも元々それらを介してルーティングされていたLSPに割り当てられたままであることを意味します。最小限のサービス破壊と再構成で復帰を実行できるメカニズムを持つことが重要です。

For "1+1 bidirectional Protection", reversion to the recovered LSP occurs by using the following sequence:

「1 1双方向保護」の場合、回収されたLSPへの復帰は、次のシーケンスを使用して発生します。

1. Clear the A bit of the ADMIN_STATUS object if set for the recovered LSP.

1. 回収されたLSPに設定されている場合、Admin_Statusオブジェクトの少しをクリアします。

2. Then, apply the method described below to switch normal traffic back from the protecting to the recovered LSP. This is performed by using the new error code/sub-code "Notify Error/LSP Recovered" (Switchback Request).

2. 次に、以下の方法を適用して、通常のトラフィックを保護から回収したLSPに戻します。これは、新しいエラーコード/サブコード「通知エラー/LSPの回復」（スイッチバック要求）を使用して実行されます。

The procedure is as follows:

手順は次のとおりです。

1) The initiating (source) node sends the normal traffic onto both the working and the protecting LSPs. Once completed, the source node sends reliably a Notify message to the destination with the new error code/sub-code "Notify Error/LSP Recovered" (Switchback Request). This Notify message includes the MESSAGE_ID object. The ACK_Desired flag MUST be set in this object to request the receiver to send an acknowledgment for the message (see [RFC2961]).

1) 開始（ソース）ノードは、通常のトラフィックを動作LSPと保護LSPの両方に送信します。完了すると、ソースノードは、新しいエラーコード/サブコード「通知エラー/LSPの回復」（スイッチバックリクエスト）を使用して、宛先に通知メッセージを確実に送信します。この通知メッセージには、message_idオブジェクトが含まれています。ACK_DESIREDフラグをこのオブジェクトに設定して、受信機にメッセージの確認を送信するよう要求する必要があります（[RFC2961]を参照）。

2) Upon receipt of this message, the destination selects the traffic from the working LSP. At the same time, it transmits the traffic onto both the working and protecting LSP.

2) このメッセージを受け取ると、宛先は作業LSPからトラフィックを選択します。同時に、LSPと保護の両方にトラフィックを送信します。

The destination then sends reliably a Notify message to the source confirming the completion of the operation. This message includes the MESSAGE_ID_ACK object to acknowledge reception of the received Notify message. This Notify message also includes the MESSAGE_ID object. The ACK_Desired flag MUST be set in this object to request the receiver to send an acknowledgment for the message (see [RFC2961]).

その後、宛先は、操作の完了を確認するソースに信頼できる通知メッセージを送信します。このメッセージには、受信したNotifyメッセージの受信を確認するMessage_id_ackオブジェクトが含まれています。この通知メッセージには、message_idオブジェクトも含まれています。ACK_DESIREDフラグをこのオブジェクトに設定して、受信機にメッセージの確認を送信するよう要求する必要があります（[RFC2961]を参照）。

3) When the source node receives this Notify message, it switches to receive traffic from the working LSP.

3) ソースノードがこの通知メッセージを受信すると、動作するLSPからトラフィックを受信するように切り替えます。

The source node then sends an Ack message to the destination node confirming that the LSP has been reverted.

ソースノードは、LSPが戻っていることを確認する宛先ノードにACKメッセージを送信します。

3. Finally, clear the O bit of the PROTECTION object sent over the protecting LSP.

3. 最後に、保護LSPに送信される保護オブジェクトのoビットをクリアします。

For "1:N Protection with Extra-traffic", reversion to the recovered LSP occurs by using the following sequence:

「1：nトラフィックによる保護」の場合、回収されたLSPへの復帰は、次のシーケンスを使用して発生します。

1. Clear the A bit of the ADMIN_STATUS object if set for the recovered LSP.

1. 回収されたLSPに設定されている場合、Admin_Statusオブジェクトの少しをクリアします。

The procedure is as follows:

手順は次のとおりです。

2) Upon receipt of this message, the destination selects the traffic from the working LSP. At the same time, it transmits the traffic onto both the working and protecting LSP.

2) このメッセージを受け取ると、宛先は作業LSPからトラフィックを選択します。同時に、LSPと保護の両方にトラフィックを送信します。

3) When the source node receives this Notify message, it switches to receive traffic from the working LSP, and stops transmitting traffic on the protecting LSP.

3) ソースノードがこの通知メッセージを受信すると、動作するLSPからトラフィックを受信するように切り替え、保護LSPのトラフィックの送信を停止します。

The source node then sends an Ack message to the destination node confirming that the LSP has been reverted.

ソースノードは、LSPが戻っていることを確認する宛先ノードにACKメッセージを送信します。

4) Upon receipt of this message, the destination node stops transmitting traffic along the protecting LSP.

4) このメッセージを受け取ると、宛先ノードは保護LSPに沿ってトラフィックの送信を停止します。

3. Finally, clear the O bit of the PROTECTION object sent over the protecting LSP.

3. 最後に、保護LSPに送信される保護オブジェクトのoビットをクリアします。

For "Rerouting without Extra-traffic" (including the shared recovery case), reversion implies that the formerly working LSP has not been torn down by the head-end node upon PathErr message reception, i.e., the head-end node kept refreshing the working LSP under failure condition. This ensures that the exact same resources are retrieved after reversion switching (except if the working LSP required re-signaling). Re-activation is performed using the following sequence:

「交通量が多い」（共有リカバリーケースを含む）の「再ルーティング」の場合、復帰は、以前に作業していたLSPがPatherrメッセージ受信時にヘッドエンドノードによって引き裂かれていないことを意味します。故障状態のLSP。これにより、回復スイッチング後にまったく同じリソースが取得されることが保証されます（作業LSPが再署名を必要とする場合を除きます）。再活性化は、次のシーケンスを使用して実行されます。

1. Clear the A bit of the ADMIN_STATUS object if set for the recovered LSP.

1. 回収されたLSPに設定されている場合、Admin_Statusオブジェクトの少しをクリアします。

The procedure is as follows:

手順は次のとおりです。

2) Upon receipt of this message, the destination selects the traffic from the working LSP. At the same time, it transmits the traffic onto both the working and protecting LSP.

2) このメッセージを受け取ると、宛先は作業LSPからトラフィックを選択します。同時に、LSPと保護の両方にトラフィックを送信します。

3) When the source node receives this Notify message, it switches to receive traffic from the working LSP, and stops transmitting traffic on the protecting LSP.

The source node then sends an Ack message to the destination node confirming that the LSP has been reverted.

ソースノードは、LSPが戻っていることを確認する宛先ノードにACKメッセージを送信します。

4) Upon receipt of this message, the destination node stops transmitting traffic along the protecting LSP.

4) このメッセージを受け取ると、宛先ノードは保護LSPに沿ってトラフィックの送信を停止します。

3. Finally, de-activate the protecting LSP by setting the S bit to 1 in the PROTECTION object sent over the protecting LSP.

3. 最後に、保護LSPを介して送信された保護オブジェクトのSビットを1に設定することにより、保護LSPを解除します。

13. Recovery Commands

13. 回復コマンド

This section specifies the control plane behavior when using several commands (see [RFC4427]) that can be used to influence the recovery operations.

このセクションでは、回復操作に影響を与えるために使用できるいくつかのコマンド（[RFC4427を参照]を参照）を使用するときのコントロールプレーンの動作を指定します。

A. Lockout of recovery LSP:

A.回復のロックアウトLSP：

The Lockout (L) bit of the ADMIN_STATUS object is used following the rules defined in Section 8 of [RFC3471] and Section 7 of [RFC3473]. The L bit must be set together with the Reflect (R) bit in the ADMIN_STATUS object sent in the Path message. Upon reception of the Resv message with the L bit set, this forces the recovery LSP to be temporarily unavailable to transport traffic (either normal or extra-traffic). Unlock is performed by clearing the L bit, following the rules defined in Section 7 of [RFC3473]. This procedure is only applicable when the LSP Protection Type Flag is set to either 0x04 (1:N Protection with Extra-Traffic), or 0x08 (1+1 Unidirectional Protection), or 0x10 (1+1 Bidirectional Protection).

admin_statusオブジェクトのロックアウト（l）ビットは、[RFC3471]のセクション8および[RFC3473]のセクション7で定義されているルールに従って使用されます。lビットは、パスメッセージで送信されたadmin_statusオブジェクトの反射（r）ビットと一緒に設定する必要があります。L BITセットを使用してRESVメッセージを受信すると、回復LSPがトラフィック（通常または交通量のない）の輸送に一時的に利用できなくなります。[RFC3473]のセクション7で定義されているルールに従って、ロック解除はLビットをクリアすることにより実行されます。この手順は、LSP保護タイプフラグが0x04（1：nトラフィック外の保護）、または0x08（1 1方向保護）、または0x10（1 1双方向保護）のいずれかに設定されている場合にのみ適用されます。

The updated format of the ADMIN_STATUS object to include the L bit is as follows:

admin_statusオブジェクトの更新された形式は、lビットを含むように次のとおりです。

     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(196)|   C-Type (1)  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |R|                        Reserved                 |L|I|C|T|A|D|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Lockout (L): 1 bit

ロックアウト（L）：1ビット

When set, forces the recovery LSP to be temporarily unavailable to transport traffic (either normal or extra traffic).

設定すると、回復LSPをトラフィックを輸送するために一時的に利用できないように強制します（通常または余分なトラフィックのいずれか）。

The R (Reflect), T (Testing), A (Administratively down), and D (Deletion in progress) bits are defined in [RFC3471]. The C (Call control) bit is defined in [GMPLS-CALL], and the I (Inhibit alarm communication) bit in [RFC4783].

R（反射）、T（テスト）、A（管理上）、およびD（進行中の削除）ビットは[RFC3471]で定義されています。C（コールコントロール）ビットは[gmpls-call]で定義され、i（rfc4783]のi（阻害アラーム通信）ビットが定義されます。

B. Lockout of normal traffic:

B.通常のトラフィックのロックアウト：

The O bit of the PROTECTION object is set to 1 to force the recovery LSP to be temporarily unavailable to transport normal traffic. This operation MUST NOT occur unless the working LSP is carrying the normal traffic. Unlock is performed by clearing the O bit over the protecting LSP. This procedure is only applicable when the LSP Protection Type Flag is set to either 0x04 (1:N Protection with Extra-Traffic), or 0x08 (1+1 Unidirectional Protection), or 0x10 (1+1 Bidirectional Protection).

保護オブジェクトのoビットは1に設定されており、回復LSPを通常のトラフィックを輸送するために一時的に利用できないように強制します。作業LSPが通常のトラフィックを運んでいない限り、この操作は発生してはなりません。ロック解除は、保護LSPの上でOビットをクリアすることにより実行されます。この手順は、LSP保護タイプフラグが0x04（1：nトラフィック外の保護）、または0x08（1 1方向保護）、または0x10（1 1双方向保護）のいずれかに設定されている場合にのみ適用されます。

C. Forced switch for normal traffic:

C.通常のトラフィック用の強制スイッチ：

Recovery signaling is initiated that switches normal traffic to the recovery LSP following the procedures defined in Section 6, 7, 8, and 9.

セクション6、7、8、および9で定義された手順に従って、通常のトラフィックを回復LSPに切り替えることを開始します。

D. Requested switch for normal traffic:

D.通常のトラフィックのスイッチを要求しました：

Recovery signaling is initiated that switches normal traffic to the recovery LSP following the procedures defined in Section 6, 7, 8, and 9. This happens unless a fault condition exists on other LSPs or spans (including the recovery LSP), or a switch command of equal or higher priority is in effect.

セクション6、7、8、および9で定義された手順に従って、通常のトラフィックを回復LSPに切り替えることを開始します。等しいまたはより高い優先度が有効です。

E. Requested switch for recovery LSP:

E.リカバリのスイッチを要求しましたLSP：

Recovery signaling is initiated that switches normal traffic to the working LSP following the procedure defined in Section 12. This request is executed except if a fault condition exists on the working LSP or an equal or higher priority switch command is in effect.

セクション12で定義されている手順に従って、通常のトラフィックを動作LSPに切り替えることを開始します。この要求は、作業LSPに障害条件が存在する場合、または等またはより高い優先度のスイッチコマンドが有効である場合を除きます。

14. PROTECTION Object

14. 保護オブジェクト

This section describes the extensions to the PROTECTION object to broaden its applicability to end-to-end LSP recovery.

このセクションでは、エンドツーエンドのLSPリカバリへの適用性を拡大するための保護オブジェクトへの拡張について説明します。

14.1. Format

14.1. フォーマット

The format of the PROTECTION Object (Class-Num = 37, C-Type = 2) is as follows:

保護オブジェクトの形式（class-num = 37、c-type = 2）は次のとおりです。

      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|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Reserved                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Secondary (S): 1 bit

セカンダリ：1ビット

When set to 1, this bit indicates that the requested LSP is a secondary LSP. When set to 0 (default), it indicates that the requested LSP is a primary LSP.

1に設定すると、このビットは、要求されたLSPがセカンダリLSPであることを示します。0（デフォルト）に設定すると、要求されたLSPがプライマリLSPであることを示します。

Protecting (P): 1 bit

保護（P）：1ビット

When set to 1, this bit indicates that the requested LSP is a protecting LSP. When set to 0 (default), it indicates that the requested LSP is a working LSP. The combination, S set to 1 with P set to 0 is not valid.

1に設定すると、このビットは、要求されたLSPが保護LSPであることを示します。0（デフォルト）に設定すると、要求されたLSPが機能するLSPであることを示します。sは、pを0に設定して1に設定されている組み合わせは無効です。

Notification (N): 1 bit

通知（n）：1ビット

When set to 1, this bit indicates that the control plane message exchange is only used for notification during protection switching. When set to 0 (default), it indicates that the control plane message exchanges are used for protection-switching purposes. The N bit is only applicable when the LSP Protection Type Flag is set to either 0x04 (1:N Protection with Extra-Traffic), or 0x08 (1+1 Unidirectional Protection), or 0x10 (1+1 Bidirectional Protection). The N bit MUST be set to 0 in any other case.

1に設定すると、このビットは、コントロールプレーンのメッセージ交換が保護スイッチング中の通知にのみ使用されることを示しています。0（デフォルト）に設定すると、コントロールプレーンのメッセージ交換が保護スイッチング目的で使用されることを示します。nビットは、LSP保護タイプフラグが0x04（1：nトラフィック以外の保護）または0x08（1 1単方向保護）、または0x10（1 1双方向保護）のいずれかに設定されている場合にのみ適用可能です。Nビットは、他の場合は0に設定する必要があります。

Operational (O): 1 bit

運用（o）：1ビット

When set to 1, this bit indicates that the protecting LSP is carrying the normal traffic after protection switching. The O bit is only applicable when the P bit is set to 1, and the LSP Protection Type Flag is set to either 0x04 (1:N Protection with Extra-Traffic), or 0x08 (1+1 Unidirectional Protection) or 0x10 (1+1 Bidirectional Protection). The O bit MUST be set to 0 in any other case.

1に設定すると、このビットは、保護LSPが保護スイッチング後に通常のトラフィックを運ぶことを示しています。oビットは、pビットが1に設定されている場合にのみ適用可能であり、LSP保護タイプフラグは0x04（1：nトラフィックのある保護）または0x08（1 1単方向保護）または0x10（1 1に設定されている場合にのみ適用されます。双方向保護）。他のケースでは、Oビットを0に設定する必要があります。

Reserved: 5 bits

予約済み：5ビット

This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt. These bits SHOULD be passed through unmodified by transit nodes.

このフィールドは予約されています。送信時にゼロに設定する必要があり、受領時に無視する必要があります。これらのビットは、トランジットノードによって変更されていないことを通過する必要があります。

LSP (Protection Type) Flags: 6 bits

LSP（保護タイプ）フラグ：6ビット

Indicates the desired end-to-end LSP recovery type. A value of 0 implies that the LSP is "Unprotected". Only one value SHOULD be set at a time. The following values are defined. All other values are reserved.

0x00 Unprotected 0x01 (Full) Rerouting 0x02 Rerouting without Extra-Traffic 0x04 1:N Protection with Extra-Traffic 0x08 1+1 Unidirectional Protection 0x10 1+1 Bidirectional Protection

Reserved: 10 bits

予約済み：10ビット

This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt. These bits SHOULD be passed through unmodified by transit nodes.

Link Flags: 6 bits

リンクフラグ：6ビット

Indicates the desired link protection type (see [RFC3471]).

目的のリンク保護タイプを示します（[RFC3471]を参照）。

Reserved field: 32 bits

Encoding of this field is detailed in [RFC4873].

このフィールドのエンコードは[RFC4873]で詳しく説明されています。

14.2. Processing

14.2. 処理

Intermediate and egress nodes processing a Path message containing a PROTECTION object MUST verify that the requested LSP Protection Type can be satisfied by the incoming interface. If it cannot, the node MUST generate a PathErr message, with the new error code/sub-code "Routing problem/Unsupported LSP Protection".

中間および出口ノード保護オブジェクトを含むパスメッセージの処理要求されたLSP保護タイプが着信インターフェイスによって満たされることを確認する必要があります。できない場合は、新しいエラーコード/サブコード「ルーティング問題/サポートされていないLSP保護」を使用して、NodeがPatherrメッセージを生成する必要があります。

Intermediate nodes processing a Path message containing a PROTECTION object with the LSP Protection Type 0x02 (Rerouting without Extra-Traffic) value set and a PRIMARY_PATH_ROUTE object (see Section 15) MUST verify that the requested LSP Protection Type can be supported by the outgoing interface. If it cannot, the node MUST generate a PathErr message with the new error code/sub-code "Routing problem/Unsupported LSP Protection".

中間ノードLSP保護オブジェクトを含むパスメッセージの処理LSP保護タイプ0x02（トラフィックエクストラフィックなしでの再ルーティング）値セットとPrimary_Path_Routeオブジェクト（セクション15を参照）は、リクエストされたLSP保護タイプが発信インターフェイスによってサポートできることを確認する必要があります。できない場合、ノードは新しいエラーコード/サブコード「ルーティング問題/サポートされていないLSP保護」を使用してPatherRメッセージを生成する必要があります。

15. PRIMARY_PATH_ROUTE Object

15. Primary_path_routeオブジェクト

The PRIMARY_PATH_ROUTE object (PPRO) is defined to inform nodes along the path of a secondary protecting LSP about which resources (link/nodes) are being used by the associated primary protected LSP (as specified by the Association ID field). If the LSP Protection Type value is set to 0x02 (Rerouting without Extra-Traffic), this object SHOULD be present in the Path message for the pre-provisioning of the secondary protecting LSP to enable recovery resource sharing between one or more secondary protecting LSPs (see Section 9). This document does not assume or preclude any other usage for this object.

Primary_Path_Routeオブジェクト（PPRO）は、関連するプライマリ保護LSPによって使用されているリソース（リンク/ノード）が使用されている（Association IDフィールドで指定）LSPを保護するためのノードを通知するように定義されています。LSP保護タイプの値が0x02に設定されている場合（交通量のないものなしで再ルーティング）、このオブジェクトは、LSPを1つまたは複数の二次保護（LSP）間で回復リソース共有を可能にするために、二次保護LSPの事前プロビジョニングのためのパスメッセージに存在する必要があります（セクション9を参照）。このドキュメントでは、このオブジェクトの他の使用法を想定または排除しません。

PRIMARY_PATH_ROUTE objects carry information extracted from the EXPLICIT ROUTE object and/or the RECORD ROUTE object of the primary working LSPs they protect. Selection of the PPRO content is up to local policy of the head-end node that initiates the request. Therefore, the information included in these objects can be used as policy-based admission control to ensure that recovery resources are only shared between secondary protecting LSPs whose associated primary LSPs have link/node/SRLG disjoint paths.

Primary_path_routeオブジェクトは、明示的なルートオブジェクトおよび/または保護するプライマリ作業LSPのレコードルートオブジェクトから抽出された情報を運びます。PPROコンテンツの選択は、リクエストを開始するヘッドエンドノードのローカルポリシー次第です。したがって、これらのオブジェクトに含まれる情報は、ポリシーベースのアミズニーコントロールとして使用して、関連するプライマリLSPにリンク/ノード/SRLGディスジョイントパスがあるLSPを副次保護することの間で回復リソースが共有されるようにすることができます。

15.1. Format

15.1. フォーマット

The primary path route is specified via the PRIMARY_PATH_ROUTE object (PPRO). The Primary Path Route Class Number (Class-Num) of form 0bbbbbbb 38.

プライマリパスルートは、Primary_Path_Routeオブジェクト（PPRO）を介して指定されています。フォーム0bbbbbbbb 38のプライマリパスルートクラス番号（クラスNum）。

Currently one C-Type (Class-Type) is defined, Type 1, Primary Path Route. The PRIMARY_PATH_ROUTE object has the following format:

現在、1つのCタイプ（クラスタイプ）が定義されています。タイプ1、プライマリパスルートです。Primary_path_routeオブジェクトには、次の形式があります。

Class-Num = 38 (of the form 0bbbbbbb), C-Type = 1

class-num = 38（フォーム0bbbbbbbb）、c-type = 1

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     //                        (Subobjects)                         //
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The contents of a PRIMARY_PATH_ROUTE object are a series of variable-length data items called subobjects (see Section 15.3).

Primary_path_routeオブジェクトの内容は、Subobjectsと呼ばれる一連の可変長データ項目です（セクション15.3を参照）。

To signal a secondary protecting LSP, the Path message MAY include one or multiple PRIMARY_PATH_ROUTE objects, where each object is meaningful. The latter is useful when a given secondary protecting LSP must be link/node/SRLG disjoint from more than one primary LSP (i.e., is protecting more than one primary LSP).

二次保護LSPを信号にするために、パスメッセージには、各オブジェクトが意味のある1つまたは複数のPrimary_Path_Routeオブジェクトを含めることができます。後者は、特定の二次保護LSPがリンク/ノード/srlgの分離を複数のプライマリLSPから切り離す必要がある場合に役立ちます（つまり、複数のプライマリLSPを保護しています）。

15.2. Subobjects

15.2.

The PRIMARY_PATH_ROUTE object is defined as a list of variable-length data items called subobjects. These subobjects are derived from the subobjects of the EXPLICIT ROUTE and/or RECORD ROUTE object of the primary working LSP(s).

Each subobject has its own length field. The length contains the total length of the subobject in bytes, including the Type and Length fields. The length MUST always be a multiple of 4, and at least 4.

各サブオブジェクトには独自の長さフィールドがあります。長さには、タイプと長さのフィールドを含む、バイト内のサブオブジェクトの全長が含まれます。長さは常に4の倍数で、少なくとも4でなければなりません。

The following subobjects are currently defined for the PRIMARY_PATH_ROUTE object:

現在、次のサブオブジェクトは、Primary_Path_Routeオブジェクトに対して定義されています。

- Sub-Type 1: IPv4 Address (see [RFC3209]) - Sub-Type 2: IPv6 Address (see [RFC3209]) - Sub-Type 3: Label (see [RFC3473]) - Sub-Type 4: Unnumbered Interface (see [RFC3477]) An empty PPRO with no subobjects is considered illegal. If there is no first subobject, the corresponding Path message is also in error, and the receiving node SHOULD return a PathErr message with the new error code/sub-code "Routing Problem/Bad PRIMARY_PATH_ROUTE object".

- サブタイプ1：IPv4アドレス（[rfc3209]を参照）） - サブタイプ2：IPv6アドレス（[rfc3209]を参照） - サブタイプ3：ラベル（[rfc3473]を参照）） - サブタイプ4：未満のインターフェース（参照[RFC3477]）サブオブジェクトのない空のPPROは違法と見なされます。最初のサブオブジェクトがない場合、対応するパスメッセージも誤っており、受信ノードは新しいエラーコード/サブコード「ルーティング問題/bad primary_path_routeオブジェクト」を使用してpatherrメッセージを返す必要があります。

Note: an intermediate node processing a PPRO can derive SRLG identifiers from the local IGP-TE database using its Type 1, 2, or 4 subobject values as pointers to the corresponding TE Links (assuming each of them has an associated SRLG TE attribute).

注：中間ノード処理PPROは、タイプ1、2、または4つのサブオブジェクト値を対応するTEリンクへのポインターとして使用して、ローカルIGP-TEデータベースからSRLG識別子を導き出すことができます（それぞれが関連するSRLG TE属性があると仮定します）。

15.3. Applicability

15.3. 適用可能性

The PRIMARY_PATH_ROUTE object MAY only be used when all GMPLS nodes along the path support the PRIMARY_PATH_ROUTE object and a secondary protecting LSP is being requested. The PRIMARY_PATH_ROUTE object is assigned a class value of the form 0bbbbbbb. Receiving GMPLS nodes along the path that do not support this object MUST return a PathErr message with the "Unknown Object Class" error code (see [RFC2205]).

Primary_Path_Routeオブジェクトは、パスに沿ったすべてのGMPLSノードがPrimary_Path_Routeオブジェクトをサポートし、二次保護LSPが要求されている場合にのみ使用できます。Primary_path_routeオブジェクトには、フォーム0bbbbbbbbのクラス値が割り当てられます。このオブジェクトをサポートしないパスに沿ってGMPLSノードを受信するには、「不明なオブジェクトクラス」エラーコードを使用してPatherRメッセージを返す必要があります（[RFC2205]を参照）。

Also, the following restrictions MUST be applied with respect to the PPRO usage:

また、PPROの使用に関して、次の制限を適用する必要があります。

- PPROs MAY only be included in Path messages when signaling secondary protecting LSPs (S bit = 1 and P bit = 1) and when the LSP Protection Type value is set to 0x02 (without Rerouting Extra-Traffic) in the PROTECTION object (see Section 14).

- PPROSは、LSPS（sビット= 1およびpビット= 1）のセカンダリ保護を信号する場合、および保護オブジェクトのLSP保護タイプの値が0x02（交通量外の再ルーティングなし）に設定されている場合にのみパスメッセージに含まれる場合があります（セクション14を参照してください。）。

- PRROs SHOULD be present in the Path message for the pre-provisioning of the secondary protecting LSP to enable recovery resource sharing between one or more secondary protecting LSPs (see Section 15.4).

- PRROSは、LSPを1つまたは複数の二次保護間のリカバリリソース共有を可能にするために、二次保護LSPの事前プロビジョニングのためのパスメッセージに存在する必要があります（セクション15.4を参照）。

- PPROs MUST NOT be used in any other conditions. In particular, if a PPRO is received when the S bit is set to 0 in the PROTECTION object, the receiving node MUST return a PathErr message with the new error code/sub-code "Routing Problem/PRIMARY_PATH_ROUTE object not applicable".

- PPROSは、他の条件で使用してはなりません。特に、保護オブジェクトでSビットが0に設定されたときにPPROを受信する場合、受信ノードは新しいエラーコード/サブコード「ルーティング問題/Primary_Path_Routeオブジェクトを該当しない」でPatherRメッセージを返す必要があります。

- Crossed exchanges of PPROs over primary LSPs are forbidden (i.e., their usage is restricted to a single set of protected LSPs).

- 一次LSPを介したPPROSの交差交換は禁止されています（つまり、その使用は、保護されたLSPの単一セットに制限されています）。

- The PPRO's content MUST NOT include subobjects coming from other PPROs. In particular, received PPROs MUST NOT be reused to establish other working or protecting LSPs.

- PPROのコンテンツには、他のPPROSからのサブオブジェクトを含めてはなりません。特に、受信したPPROSを再利用して、他の作業または保護LSPを確立してはいけません。

15.4. Processing

15.4. 処理

The PPRO enables sharing recovery resources between a given secondary protecting LSP and one or more secondary protecting LSPs if their corresponding primary working LSPs have mutually (link/node/SRLG) disjoint paths. Consider a node N through which n secondary protecting LSPs (say, P[1],...,P[n]) have already been established that protect n primary working LSPs (say, P'[1],...,P'[n]). Suppose also that these n secondary working LSPs share a given outgoing link resource (say r).

PPROは、対応する一次作業LSPが相互に（link/node/srlg）分離パスを持っている場合、特定の二次保護LSPと1つ以上の二次保護LSPの間で回復リソースを共有できるようにします。n二次保護LSP（たとえば、p [1]、...、p [n]）が既に確立されているノードnを考えてみてください（たとえば、p '[1]、...、p '[n]）。また、これらのN二次作業LSPが特定の発信リンクリソース（RたようにR）を共有していると仮定します。

Now, suppose that node N receives a Path message for an additional secondary protecting LSP (say, Q, protecting Q'). The PPRO carried by this Path message is processed as follows:

ここで、ノードnが追加の二次保護LSPのパスメッセージを受信したと仮定します（たとえば、q、q 'の保護）。このパスメッセージによって運ばれるPPROは、次のように処理されます。

- N checks whether the primary working LSPs P'[1],...,P'[n] associated with the LSPs P[1],...,P[n], respectively, have any link, node, and SLRG in common with the primary working Q' (associated with Q) by comparing the stored PPRO subobjects associated with P'[1],...,P'[n] with the PPRO subobjects associated with Q' received in the Path message.

- If this is the case, N SHOULD NOT attempt to share the outgoing link resource r between P[1],...,P[n] and Q. However, upon local policy decision, N MAY allocate another available (shared) link other than r for use by Q. If this is not the case (upon the local policy decision that no other link is allowed to be allocated for Q) or if no other link is available for Q, N SHOULD return a PathErr message with the new error code/sub-code "Admission Control Failure/LSP Admission Failure".

- この場合、NはP [1]、...、P [n]、Qの間で発信リンクリソースrを共有しようとしないでください。ただし、ローカルポリシーの決定に応じて、nは別の利用可能な（共有）リンクを割り当てることができますQで使用するr以外。これが当てはまらない場合（qに他のリンクを割り当てることが許可されていないというローカルポリシーの決定に基づいて）、またはqに他のリンクが利用できない場合、nはpatherrメッセージを返す必要があります。新しいエラーコード/サブコード「入場制御の失敗/LSP入場失敗」。

- Otherwise (if P'[1],...,P'[n] and Q' are fully disjoint), the link r selected by N for the LSP Q MAY be exactly the same as the one selected for the LSPs P[1],...,P[n]. This happens after verifying (from the node's local policy) that the selected link r can be shared between these LSPs. If this is not the case (for instance, the sharing ratio has reached its maximum for that link), and if upon local policy decision, no other link is allowed to be allocated for Q, N SHOULD return a PathErr message with the error code/sub-code "Admission Control Failure/Requested Bandwidth Unavailable" (see [RFC2205]). Otherwise (if no other link is available), N SHOULD return a PathErr message with the new error code/sub-code "Admission Control Failure/LSP Admission Failure".

- それ以外の場合（p '[1]、...、p' [n]、q 'が完全にばらばらである場合）、LSP qに対してnで選択されたリンクrは、LSPS Pで選択されたものとまったく同じである可能性があります[1]、...、p [n]。これは、選択したリンクrをこれらのLSP間で共有できることを（ノードのローカルポリシーから）確認した後に発生します。そうでない場合（たとえば、共有比率はそのリンクの最大に達しました）、ローカルポリシーの決定に応じてqに他のリンクを割り当てることは許可されていない場合、nはエラーコードを使用してpatherrメッセージを返す必要があります/サブコード「入場制御の失敗/要求された帯域幅が利用できない」（[RFC2205]を参照）。それ以外の場合は（他のリンクがない場合）、nは新しいエラーコード/サブコード「Andiming Control Fails/LSP Admission Falion」を使用してPatherrメッセージを返す必要があります。

Note that the process, through which m out of the n (m =< n) secondary protecting LSPs' PPROs may be selected on a local basis to perform the above comparison and subsequent link selection, is out of scope of this document.

n（m = <n）のm（m = <n）のMのM = <n）のプロセスは、上記の比較とその後のリンク選択を実行するためにローカルベースで選択される可能性があることに注意してください。このドキュメントの範囲外です。

16. ASSOCIATION Object

16. アソシエーションオブジェクト

The ASSOCIATION object is used to associate LSPs with each other. In the context of end-to-end LSP recovery, the association MUST only identify LSPs that support the same Tunnel ID as well as the same tunnel sender address and tunnel endpoint address. The Association Type, Association Source, and Association ID fields of the object together uniquely identify an association. The object uses an object class number of the form 11bbbbbb to ensure compatibility with non-supporting nodes.

Associationオブジェクトは、LSPを互いに関連付けるために使用されます。エンドツーエンドのLSP回復のコンテキストでは、関連付けは、同じトンネルIDと同じトンネル送信者アドレスとトンネルエンドポイントアドレスをサポートするLSPのみを特定する必要があります。オブジェクトの関連タイプ、アソシエーションソース、およびアソシエーションIDフィールドは、関連性を一意に識別します。オブジェクトは、フォーム11bbbbbbbのオブジェクトクラス番号を使用して、非サポートノードとの互換性を確保します。

The ASSOCIATION object is used to associate LSPs with each other.

Associationオブジェクトは、LSPを互いに関連付けるために使用されます。

16.1. Format

16.1.

The IPv4 ASSOCIATION object (Class-Num of the form 11bbbbbb with value = 199, C-Type = 1) has the format:

IPv4 Associationオブジェクト（value = 199、c-type = 1のフォーム11bbbbbbbのクラス番号）には、次の形式があります。

     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(199)|  C-Type (1)   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       Association Type        |       Association ID          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  IPv4 Association Source                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The IPv6 ASSOCIATION object (Class-Num of the form 11bbbbbb with value = 199, C-Type = 2) has the format:

IPv6 Associationオブジェクト（value = 199、c-type = 2のフォーム11bbbbbbbのクラス番号）には、次の形式があります。

     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(199)|  C-Type (2)   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       Association Type        |       Association ID          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                  IPv6 Association Source                      |
    |                                                               |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Association Type: 16 bits

アソシエーションタイプ：16ビット

Indicates the type of association being identified. Note that this value is considered when determining association. The following are values defined in this document.

特定されている関連付けのタイプを示します。この値は、関連性を決定するときに考慮されることに注意してください。以下は、このドキュメントで定義されている値です。

            Value       Type
            -----       ----
              0         Reserved
              1         Recovery (R)

Association ID: 16 bits

アソシエーションID：16ビット

A value assigned by the LSP head-end. When combined with the Association Type and Association Source, this value uniquely identifies an association.

LSPヘッドエンドによって割り当てられた値。協会の種類と協会のソースと組み合わせると、この値はアソシエーションを一意に識別します。

Association Source: 4 or 16 bytes

アソシエーションソース：4または16バイト

An IPv4 or IPv6 address, respectively, that is associated to the node that originated the association.

それぞれAssociationを発信したノードに関連付けられているIPv4またはIPv6アドレス。

16.2. Processing

16.2. 処理

In the end-to-end LSP recovery context, the ASSOCIATION object is used to associate a recovery LSP with the LSP(s) it is protecting or a protected LSP(s) with its recovery LSP. The object is carried in Path messages. More than one object MAY be carried in a single Path message.

エンドツーエンドのLSP回復コンテキストでは、関連付けオブジェクトを使用して、回復LSPを保護しているLSPまたは保護されたLSPを回復LSPで関連付けます。オブジェクトはパスメッセージに携帯されています。1つのパスメッセージで複数のオブジェクトを携帯することができます。

Transit nodes MUST transmit, without modification, any received ASSOCIATION object in the corresponding outgoing Path message.

トランジットノードは、修正なしで、対応する発信パスメッセージ内の受信したアソシエーションオブジェクトを送信する必要があります。

An ASSOCIATION object with an Association Type set to the value "Recovery" is used to identify an LSP-Recovery-related association. Any node associating a recovery LSP MUST insert an ASSOCIATION object with the following setting:

値「復旧」に設定されたアソシエーションタイプを持つアソシエーションオブジェクトは、LSP-回復関連の関連付けを識別するために使用されます。リカバリLSPを関連付けるノードは、次の設定で関連付けオブジェクトを挿入する必要があります。

- The Association Type MUST be set to the value "Recovery" in the Path message of the recovery LSP.

- アソシエーションタイプは、回復LSPのパスメッセージの値「回復」に設定する必要があります。

- The (IPv4/IPv6) Association Source MUST be set to the tunnel sender address of the LSP being protected.

- （IPv4/IPv6）アソシエーションソースは、保護されているLSPのトンネル送信者アドレスに設定する必要があります。

- The Association ID MUST be set to the LSP ID of the LSP being protected by this LSP or the LSP protecting this LSP. If unknown, this value is set to its own signaled LSP_ID value (default). Also, the value of the Association ID MAY change during the lifetime of the LSP.

- 関連付けIDは、このLSPによって保護されているLSPのLSP IDまたはこのLSPを保護するLSPに設定する必要があります。不明の場合、この値は独自のシグナル付きLSP_ID値（デフォルト）に設定されます。また、Association IDの価値は、LSPの寿命の間に変化する場合があります。

Terminating nodes use received ASSOCIATION object(s) with the Association Type set to the value "Recovery" to associate a recovery LSP with its matching working LSP. This information is used to bind the appropriate working and recovery LSPs together. Such nodes MUST ensure that the received Path messages, including ASSOCIATION object(s), are processed with the appropriate PROTECTION object settings, if present (see Section 14 for PROTECTION object processing). Otherwise, this node MUST return a PathErr message with the new error code/sub-code "LSP Admission Failure/Bad Association Type". Similarly, terminating nodes receiving a Path message with a

終了ノードは、受信したアソシエーションオブジェクトを使用して、アソシエーションタイプを値「回復」に設定して、回復LSPを一致する動作LSPに関連付けます。この情報は、適切な作業と回復のLSPを結合するために使用されます。このようなノードは、存在する場合（保護オブジェクト処理についてはセクション14を参照）、関連するオブジェクトを含む受信したパスメッセージが適切な保護オブジェクト設定で処理されることを確認する必要があります。それ以外の場合、このノードは、新しいエラーコード/サブコード「LSP入学障害/バッドアソシエーションタイプ」を使用してPatherrメッセージを返す必要があります。同様に、パスメッセージを受信するノードを終了する

PROTECTION object requiring association between working and recovery LSPs MUST include an ASSOCIATION object. Otherwise, such nodes MUST return a PathErr message with the new error code/sub-code "Routing Problem/PROTECTION object not Applicable".

作業と回復の間の関連性を必要とする保護オブジェクトLSPは、関連付けオブジェクトを含める必要があります。それ以外の場合、そのようなノードは、新しいエラーコード/サブコード「ルーティング問題/保護オブジェクトが該当しない」を使用してPatherRメッセージを返す必要があります。

17. Updated RSVP Message Formats

17. RSVPメッセージ形式を更新しました

This section presents the RSVP message-related formats as modified by this document. Unmodified RSVP message formats are not listed.

このセクションでは、このドキュメントで変更されたRSVPメッセージ関連形式を示します。変更されていないRSVPメッセージ形式はリストされていません。

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> ... ]
                      [ <PRIMARY_PATH_ROUTE> ... ]
                      [ <POLICY_DATA> ... ]
                      <sender descriptor>

The format of the <sender descriptor> for unidirectional and bidirectional LSPs is not modified by the present document.

単方向および双方向LSPの<SenderDecriptor>の形式は、現在のドキュメントによって変更されていません。

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> ]
                      [ <PROTECTION> ]
                      [ <NOTIFY_REQUEST> ]
                      [ <ADMIN_STATUS> ]
                      [ <POLICY_DATA> ... ]
                      <STYLE> <flow descriptor list>

<flow descriptor list> is not modified by this document.

<フロー記述子リスト>は、このドキュメントで変更されていません。

18. Security Considerations

18. セキュリティに関する考慮事項

The security threats identified in [RFC4426] may be experienced due to the exchange of RSVP messages and information as detailed in this document. The following security mechanisms apply.

[RFC4426]で特定されたセキュリティの脅威は、このドキュメントで詳述されているRSVPメッセージと情報の交換により、経験される場合があります。次のセキュリティメカニズムが適用されます。

RSVP signaling MUST be able to provide authentication and integrity. Authentication is required to ensure that the signaling messages are originating from the right place and have not been modified in transit.

RSVPシグナル伝達は、認証と整合性を提供できる必要があります。信号メッセージが適切な場所から発信され、輸送中に変更されていないことを確認するには、認証が必要です。

For this purpose, [RFC2747] provides the required RSVP message authentication and integrity for hop-by-hop RSVP message exchanges. For non hop-by-hop RSVP message exchanges the standard IPsec-based integrity and authentication can be used as explained in [RFC3473].

この目的のために、[RFC2747]は、ホップバイホップRSVPメッセージ交換に必要なRSVPメッセージ認証と整合性を提供します。非ホップバイホップRSVPメッセージ交換の場合、[RFC3473]で説明されているように、標準のIPSECベースの整合性と認証を使用できます。

Moreover, this document makes use of the Notify message exchange. This precludes RSVP's hop-by-hop integrity and authentication model. In the case, when the same level of security provided by [RFC2747] is desired, the standard IPsec based integrity and authentication can be used as explained in [RFC3473].

さらに、このドキュメントでは、Notifyメッセージ交換を利用しています。これにより、RSVPのホップバイホップの整合性と認証モデルが排除されます。この場合、[RFC2747]によって提供される同じレベルのセキュリティが望ましい場合、[RFC3473]で説明されているように、標準のIPSECベースの完全性と認証を使用できます。

To prevent the consequences of poorly applied protection and the increased risk of misconnection, in particular, when extra-traffic is involved, that would deliver the wrong traffic to the wrong destination, specific mechanisms have been put in place as described in Section 7.2, 8.3, and 10.

不十分に適用された保護の結果と、特に交通量の多い場合、間違ったトラフィックを間違った目的地に届けると、誤った接続のリスクの増加を防ぐために、セクション7.2、8.3で説明されているように特定のメカニズムが導入されています。、および10。

19. IANA Considerations

19. IANAの考慮事項

IANA assigns values to RSVP protocol parameters. Within the current document, a PROTECTION object (new C-Type), a PRIMARY_PATH_ROUTE object, and an ASSOCIATION object are defined. In addition, new Error code/sub-code values are defined in this document. Finally, registration of the ADMIN_STATUS object bits is requested.

IANAは、RSVPプロトコルパラメーターに値を割り当てます。現在のドキュメント内では、保護オブジェクト（新しいCタイプ）、Primary_Path_Routeオブジェクト、および関連付けオブジェクトが定義されています。さらに、このドキュメントでは、新しいエラーコード/サブコード値が定義されています。最後に、admin_statusオブジェクトビットの登録が要求されます。

Two RSVP Class Numbers (Class-Num) and three Class Types (C-Types) values have to be defined by IANA in registry:

2つのRSVPクラス番号（クラス-Num）と3つのクラスタイプ（Cタイプ）値は、レジストリのIANAによって定義する必要があります。

http://www.iana.org/assignments/rsvp-parameters

1) PROTECTION object (defined in Section 14.1)

o PROTECTION object: Class-Num = 37

o 保護オブジェクト：class-num = 37

- Type 2: C-Type = 2

2) PRIMARY_PATH_ROUTE object (defined in Section 15.1)

2) Primary_path_routeオブジェクト（セクション15.1で定義）

o PRIMARY_PATH_ROUTE object: Class-Num = 38 (of the form 0bbbbbbb),

- Primary Path Route: C-Type = 1

- プライマリパスルート：C-Type = 1

3) ASSOCIATION object (defined in Section 16.1)

3) アソシエーションオブジェクト（セクション16.1で定義）

o ASSOCIATION object: Class-Num = 199 (of the form 11bbbbbb)

o アソシエーションオブジェクト：class-num = 199（フォーム11bbbbbbbの）

- IPv4 Association: C-Type = 1 - IPv6 Association: C-Type = 2

- IPv4 Association：c-type = 1-ipv6 Association：c-type = 2

o Association Type

o 協会タイプ

The following values defined for the Association Type (16 bits) field of the ASSOCIATION object.

アソシエーションオブジェクトのアソシエーションタイプ（16ビット）フィールドに対して定義された次の値。

            Value       Type
            -----       ----
              0         Reserved
              1         Recovery (R)

Assignment of values (from 2 to 65535) by IANA are subject to IETF expert review process, i.e., IETF Standards Track RFC Action.

IANAによる（2から65535）の値の割り当ては、IETFエキスパートレビュープロセスの対象となります。つまり、IETF標準はRFCアクションを追跡します。

4) Error Code/Sub-code values

4) エラーコード/サブコード値

The following Error code/sub-code values are defined in this document:

次のエラーコード/サブコード値は、このドキュメントで定義されています。

Error Code = 01: "Admission Control Failure" (see [RFC2205])

エラーコード= 01：「入場制御の失敗」（[RFC2205]を参照）

o "Admission Control Failure/LSP Admission Failure" (4) o "Admission Control Failure/Bad Association Type" (5)

o 「入場制御の失敗/LSP入場失敗」（4）o「入場制御失敗/悪い関連タイプ」（5）

Error Code = 02: "Policy Control Failure" (see [RFC2205])

エラーコード= 02：「ポリシー管理の失敗」（[RFC2205]を参照）

o "Policy Control failure/Hard Pre-empted" (20)

o 「ポリシー管理の失敗/ハードプリエンプト」（20）

Error Code = 24: "Routing Problem" (see [RFC3209])

エラーコード= 24：「ルーティングの問題」（[RFC3209]を参照）

   o "Routing Problem/Unsupported LSP Protection" (17)
   o "Routing Problem/PROTECTION object not applicable" (18)
   o "Routing Problem/Bad PRIMARY_PATH_ROUTE object" (19)
   o "Routing Problem/PRIMARY_PATH_ROUTE object not applicable" (20)

Error Code = 25: "Notify Error" (see [RFC3209])

エラーコード= 25：「エラーの通知」（[RFC3209]を参照）

o "Notify Error/LSP Failure" (9) o "Notify Error/LSP Recovered" (10) o "Notify Error/LSP Locally Failed" (11)

o 「エラー/LSP障害の通知」（9）o「エラー/LSPが回復した通知」（10）o「エラー/LSPが局所的に失敗した」（11）

5) Registration of the ADMIN_STATUS object bits

5) admin_statusオブジェクトビットの登録

The ADMIN_STATUS object (Class-Num = 196, C-Type = 1) is defined in [RFC3473].

admin_statusオブジェクト（class-num = 196、c-type = 1）は[rfc3473]で定義されています。

IANA is also requested to track the ADMIN_STATUS bits extended by this document. For this purpose, the following new registry entries have been created:

IANAは、このドキュメントによって拡張されたadmin_statusビットを追跡することも要求されています。この目的のために、次の新しいレジストリエントリが作成されました。

http://www.iana.org/assignments/gmpls-sig-parameters

- ADMIN_STATUS bits:

- admin_statusビット：

        Name: ADMIN_STATUS bits
        Format: 32-bit vector of bits
        Position:
           [0]          Reflect (R) bit defined in [RFC3471]
           [1..25]      To be assigned by IANA via IETF Standards
                        Track RFC Action.
           [26]         Lockout (L) bit is defined in Section 13
           [27]         Inhibit alarm communication (I) in [RFC4783]

           [28]         Call control (C) bit is defined in
                        [GMPLS-CALL]
           [29]         Testing (T) bit is defined in [RFC3471]
           [30]         Administratively down (A) bit is defined in
                        [RFC3471]
           [31]         Deletion in progress (D) bit is defined in
                        [RFC3471]

20. Acknowledgments

20. 謝辞

The authors would like to thank John Drake for his active collaboration, Adrian Farrel for his contribution to this document (in particular, to the Section 10 and 11) and his thorough review of the document, Bart Rousseau (for editorial review), Dominique Verchere, and Stefaan De Cnodder. Thanks also to Ichiro Inoue for his valuable comments.

著者は、ジョン・ドレイクの積極的なコラボレーションであるエイドリアン・ファレルが、この文書（特に、セクション10と11への）への貢献と、ドキュメント・ルソー（編集レビューのため）のドミニク・ヴェルチェレの徹底的なレビューについて感謝したいと思います。、およびStefaan de Cnodder。また、彼の貴重なコメントをしてくれたイチロ・イノウエにも感謝します。

The authors would also like to thank Lou Berger for the time and effort he spent together with the design team, in contributing to the present document.

著者はまた、現在の文書に貢献して、デザインチームと一緒に過ごした時間と労力についてLou Bergerに感謝したいと思います。

21. References

21. 参考文献

21.1. Normative References

21.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月。

[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月。

[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001.

[RFC2961] Berger、L.、Gan、D.、Swallow、G.、Pan、P.、Tommasi、F。、およびS. Molendini、「RSVP Refrend Overhead Recotion Extensions」、RFC 2961、2001年4月。

[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., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.

[RFC3471] Berger、L。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナル伝達機能説明」、RFC 3471、2003年1月。

[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.

[RFC3473] Berger、L。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナルリソースリソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）拡張」、RFC 3473、2003年1月。

[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003.

[RFC3477] Kompella、K。およびY. Rekhter、「リソース予約プロトコルにおける無数のリンク - トラフィックエンジニアリング（RSVP -TE）」、RFC 3477、2003年1月。

[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.

[RFC3945] Mannie、E。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）アーキテクチャ」、RFC 3945、2004年10月。

[RFC4426] Lang, J., Rajagopalan, B., and D. Papadimitriou, "Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification", RFC 4426, March 2006.

[RFC4426] Lang、J.、Rajagopalan、B。、およびD. Papadimitriou、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）回復機能仕様」、RFC 4426、2006年3月。

[RFC4873] Berger, L., Bryskin, I., Papdimitriou, D., and A. Farrel, "GMPLS Segment Recovery," RFC 4873, May 2007.

[RFC4873] Berger、L.、Bryskin、I.、Papdimitriou、D。、およびA. Farrel、「Gmplsセグメントの回復」、RFC 4873、2007年5月。

21.2. Informative References

21.2. 参考引用

[RFC4783] Berger, L., "GMPLS - Communication of Alarm Information", RFC 4783, December 2006.

[RFC4783] Berger、L。、「Gmpls-アラーム情報の通信」、RFC 4783、2006年12月。

[CRANK] Farrel, A., Ed., "Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE", Work in Progress, January 2007.

[Crank] Farrel、A.、ed。、「MPLSおよびGMPLS RSVP-TEのクランクバックシグナリング拡張」、2007年1月、進行中の作業。

[GMPLS-CALL] Papadimitriou, D., Ed., and A. Farrel, Ed., "Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in support of Calls", Work in Progress, January 2007.

[GMPLS-CALL] Papadimitriou、D.、ed。、およびA. Farrel、ed。、「一般化されたMPLS（GMPLS）RSVP-TEシグナリング拡張がコールをサポートする」、2007年1月の作業。

[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月。

[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月。

[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月。

[G.841] ITU-T, "Types and Characteristics of SDH Network Protection Architectures," Recommendation G.841, October 1998, available from http://www.itu.int.

[G.841] ITU-T、「SDHネットワーク保護アーキテクチャのタイプと特性」、推奨G.841、1998年10月、http：//www.itu.intから入手可能。

22. Contributors

22. 貢献者

This document is the result of the CCAMP Working Group Protection and Restoration design team joint effort. The following are the authors that contributed to the present document:

この文書は、CCAMPワーキンググループの保護と修復設計チームの共同努力の結果です。以下は、現在の文書に貢献した著者です。

Deborah Brungard (AT&T) Rm. D1-3C22 - 200, S. Laurel Ave. Middletown, NJ 07748, USA EMail: dbrungard@att.com

デボラ・ブランガード（AT＆T）RM。D1-3C22-200、S。LaurelAve. Middletown、NJ 07748、USAメール：dbrungard@att.com

Sudheer Dharanikota EMail: sudheer@ieee.org

Sudheer Dharanikotaメール：sudheer@ieee.org

Guangzhi Li (AT&T) 180 Park Avenue Florham Park, NJ 07932, USA EMail: gli@research.att.com

広州Li（AT＆T）180 Park Avenue Florham Park、NJ 07932、USAメール：gli@research.att.com

Eric Mannie (Perceval) Rue Tenbosch, 9 1000 Brussels, Belgium Phone: +32-2-6409194 EMail: eric.mannie@perceval.net

エリック・マニー（パーセバル）Rue Tenbosch、9 1000ブリュッセル、ベルギー電話：32-2-6409194メール：eric.mannie@perceval.net

Bala Rajagopalan (Intel Broadband Wireless Division) 2111 NE 25th Ave. Hillsboro, OR 97124, USA EMail: bala.rajagopalan@intel.com

Bala Rajagopalan（Intel Broadband Wireless Division）2111 Ne 25th Ave. Hillsboro、または97124、USA Email：bala.rajagopalan@intel.com

Editors' Addresses

編集者のアドレス

Jonathan P. Lang Sonos 506 Chapala Street Santa Barbara, CA 93101, USA

ジョナサンP.ラングソノス506チャパラストリートサンタバーバラ、カリフォルニア州93101、米国

   EMail: jplang@ieee.org

Yakov Rekhter Juniper 1194 N. Mathilda Avenue Sunnyvale, CA 94089, USA

Yakov Rekhter Juniper 1194 N. Mathilda Avenue Sunnyvale、CA 94089、米国

   EMail: yakov@juniper.net

Dimitri Papadimitriou Alcatel Copernicuslaan 50 B-2018, Antwerpen, Belgium

Dimitri Papadimitriou Alcatel Copernicuslaan 50 B-2018、Antwerpen、ベルギー

   EMail: dimitri.papadimitriou@alcatel-lucent.be

Full Copyright Statement

完全な著作権声明

著作権（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.

RFCエディター機能の資金は現在、インターネット協会によって提供されています。