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
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
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.
この文書では、一般化マルチプロトコルラベルスイッチング（GMPLS）リソース予約プロトコルのためのプロトコル固有の手順や拡張機能について説明します - トラフィックエンジニアリングを（RSVP-TE）の保護と回復を示し、エンドツーエンドのラベルスイッチパス（LSP）の回復を支援するためのシグナリング。 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
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）は対応レイヤ2スイッチ（L2SC）、時分割多重（TDM）、ラムダは、（LSC）対応スイッチをサポートするようにMPLSを拡張し、繊維ができる（FSC）のインターフェイスを切り替えます。 GMPLS回復はデータプレーンの障害復旧をサポートするために、制御プレーンメカニズム（すなわち、シグナリング、ルーティング、リンク管理メカニズム）を使用します。類似した（データプレーン）障害検出メカニズムが制御プレーンメカニズムのサポート中に存在することが必要であることに留意されたいです。この文書では、用語「回復」は、一般的な保護と回復の両方を示すために使用されます。分化が必要な場合に、特定の用語「保護」と「復元」をのみ使用されます。保護と回復の間の微妙な区別は回復期（[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]に提供され、仲間ドキュメントとして考慮されるべきです。シグナリング（参照[RFC3473]）は、エンドツーエンドの回復をサポートする - 本文書では、GMPLS RSVP-TE（トラヒックエンジニアリングリソース予約プロトコル）のためのプロトコル固有の手順について説明します。エンドツーエンドの回復は、その末尾（出口ノードエンドポイント）へのヘッドエンド（入口ノードエンドポイント）から全LSPの回復を指します。エンドツーエンドの回復では、作業のLSPは、それらが任意の故障確率を共有しないように、ネットワーク内（リソースがリンク、ノード、または共有リスクリンクグループ（SRLG）である場合）、リソース、互いに素であると想定されますが、これは必須ではありません。ネットワークリソースの所与の組に関して、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.
3）事前に計画、エクストラトラフィックでN（N> = 1）LSP保護：1）1 + 1（単方向/双方向）の保護、2）1：本文書は、エンドツーエンドLSP回復の4種類のアドレス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を保護するための専用のリソース互いに素な代替経路を介してシグナリングされます。通常のトラフィックが同時に両方のLSP上で送られ、セレクタは、LSPのいずれかからトラフィックを受信する出口ノードで使用されます。障害がLSPの一方に沿って発生した場合、出口ノードは、有効な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に作動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を再ルーティング（または復元事前に計画された）リンク/作動一方からノード/ SRLGの互いに素であるワーキングLSPと保護LSPのエンドノードの同一の対の間に確立に依存しています。ここで、保護LSPの回復リソースは、（プレ）プロビジョニング段階中にインスタンス化特定保護LSP（すなわち、データプレーンにおけるリソース割り当てをコミット）事前に予約されているが、明示的なアクションをアクティブにするために必要とされます。保護LSP（すなわち、完全にインスタンス化）「アクティブ」ではないので、余分なトラフィックを運ぶことができません。これは、対応するリソースが他のLSPで使用することができないことを意味するものではありません。したがって、この機構は、ワーキングLSP（S）障害（S）から保護するが、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（S）用に事前予約されたリソースを使用するすべてのより低い優先順位のLSPは、保護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.
クランクバックシグナリング（[クランク]参照）、LSPセグメント回復（[RFC4873]を参照）専用コンパニオンドキュメントにさらに詳述されています。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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]ならびにを参照します。
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.
高速リルート（FRR）エンドツーエンドGMPLS回復即ちにより導入された[RFC4090]-TEをRSVPへの影響はありません、エンド・ツー・エンドのGMPLS回復とFRRで定義されているいずれかの方法を使用することが可能です。
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]に準拠実装によって無視され、[RFC4090]で定義されるようFRRが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トンネルはSESSIONとSENDER_TEMPLATEオブジェクトの組み合わせによって識別される（参照[RFC3209]）。次のように関連するフィールドは以下のとおりです。
IPv4 (or IPv6) tunnel endpoint address
IPv4（またはIPv6）トンネルエンドポイントアドレス
IPv4 (or IPv6) address of the egress node for the tunnel.
IPv4（またはIPv6）トンネルの出口ノードのアドレス。
Tunnel ID
トンネルID
A 16-bit identifier used in the SESSION that remains constant
over the life of the tunnel.
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.
IPv4 (or IPv6) tunnel sender address
IPv4（またはIPv6）トンネルの送信元アドレス
IPv4 (or IPv6) address for a sender node.
IPv4（またはIPv6）は、送信側ノードのアドレス。
LSP ID
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.
The first three fields are carried in the SESSION object (Path and Resv message) and constitute the basic identification of the LSP tunnel.
最初の3つのフィールドは、セッション・オブジェクト（パスと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（Pathメッセージ）とFILTER_SPECオブジェクト（Resvメッセージ）で運ばれます。 LSP IDが同じLSPトンネル（そのトンネルIDによって識別される）に属するLSPを区別するために使用されます。
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に導入された保護対象の一部です。
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によって使用されてもよいです。
- 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を保護する場合（S）ワーキングLSP（S）に関連付けられて、一つは、保護の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.
注意：組み合わせは「二次加工は、」有効ではありません（唯一の保護のLSPは、二次のLSPすることができます）。主のLSPが動作またはLSPを保護することができますどちらか一方で作業するLSPは常にプライマリのLSP（すなわち、完全に確立）です。
- 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]で定義されたフィールドは、この文書によって変更されません。
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は、エンドノード（別個の値は保護対象の各保護タイプに関連付けられている、セクション14を参照）に関連することが可能なLSP保護タイプを区別するために使用されます。
- 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である場合に設定。二次LSPのリソースが単一のために事前に予約されていない場合<送信側、受信側>ペア、このタイプは「共用メッシュ」回復と呼ばれます。
- 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.
- エクストラトラフィックとLSP保護：保護LSPは、余分なトラフィックの輸送を可能にし、これ以上の間、回復リソースのいずれかの共有排除する専用のプライマリLSPであれば設定<送信者、受信者>のペアを。余分なトラフィックとN LSP保護：このタイプは1を含んでいます。
- 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.
データプレーンは、自動保護スイッチング能力（例えば、ITU-T [G.841]勧告を参照）を提供する場合LSP保護のため、特に、通知（N）ビットは、保護オブジェクトに定義されています。なお、制御プレーンまたはデータプレーンを介してシグナルプロテクションスイッチングの間の区別を可能にします。
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ビットの導入は、明確にこの問題を解決します。これらのビットは（独立LSP保護タイプのコンテキストの）ホップバイホップに基づいて処理しなければなりません。これは、シグナリング復帰のより容易な実装を可能にする（セクション12を参照）だけでなく、任意の中間ノードが受信LSP保護タイプ値に関連付けられた意味を知ることが必要とされないので、保護されたサービスの透明な送達を促進します。
The ASSOCIATION object, introduced in Section 16, is used to associate the working and protecting LSPs.
部16に導入された関連オブジェクトが、作業及び保護LSPを関連付けるために使用されます。
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.
ワーキングLSPをシグナリングするために使用される場合、関連オブジェクトのアソシエーションID（セクション16を参照）保護LSPを識別する。保護LSPをシグナリングするために使用される場合、このフィールドは、保護LSPによって保護LSPを識別する。
One of the simplest notions of end-to-end LSP protection is 1+1 unidirectional protection.
エンドツーエンドのLSP保護の最も簡単な概念の一つは、1つの+ 1単方向保護です。
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]は入口/出口ノードAを無視して、ノードとリンクディスジョイントであり、D. A 1 + 1保護経路がから確立されています[A、B、C、D]を超える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メッセージ生成時（[RFC3473]を参照）ERROR_SPECオブジェクトのPath_State_Removedフラグを設定しないことをお勧めします。
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の両方に影響を与える可能性があります。
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を参照）Pathメッセージに含まれています。この場合、「1 + 1単方向」で - このオブジェクトは、所望のエンドツーエンドのLSP保護タイプを運びます。この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は、0、0、Pビットに保護対象のSビットを設定することによって通知され、および関連オブジェクトで、アソシエーション保護LSP_IDのID。保護LSPが0に保護対象のSビットを設定することによって通知され、Pビットを1にし、関連オブジェクトは、関連する保護LSP_IDにアソシエーション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ビットセットでシグナリングされるべきです。 Aは、（[RFC3473]を参照）ADMIN_STATUSオブジェクトに設定されたビットが以前働いてLSPをシグナリングすることができます。このプロセスは、テールエンドノードがトラフィックの選択の切り替えが発生したヘッドエンドノードに通知した想定しています。
1+1 bidirectional protection is a scheme that provides end-to-end protection for bidirectional LSPs.
1つの+ 1双方向保護は、双方向のLSPのためのエンドツーエンドの保護を提供する方式です。
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).
LSP [A、B、C、D]及び[A、E、F、G、D]入口/出口ノードAを無視して、ノードとリンクディスジョイントであるとは、D. A双方向LSPはそれぞれ上から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.
故障は、1つまたはLSPの両方のエンドポイントによって検出された場合、両方のエンドポイントは、他のLSPからのトラフィックを選択しなければなりません。このアクションは、1つの+ 1双方向保護の両方のエンドポイント間の協調保護切替機構とみなすことができ、このような観点から、ノードAとDの間で調整しなければなりません。
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の両方に影響を与える可能性があります。
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 Bidirectional". This LSP Protection Type value is only applicable to bidirectional LSPs.
新しい保護オブジェクトは、（セクション14を参照）Pathメッセージに含まれています。この場合、「1 + 1双方向」で - このオブジェクトは、所望のエンドツーエンドのLSP保護タイプを運びます。この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を区別できるようにすることも望ましいです。これが0に保護対象のSビットを設定することにより、作業LSPのために達成され、Pビット0に、および関連オブジェクトで、保護LSP_IDにアソシエーションID。保護LSPを1に、0に保護対象のSビットを設定することにより、Pビットをシグナリング、および対応して関連する保護LSP_IDへの関連IDをオブジェクトです。
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の結果のいずれかに影響を与えるために必要とされる、それぞれに（他の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上の信号品質の劣化）を検出または<上流/下流セッションリスト>内のセッションオブジェクトを含む通知メッセージを受信した場合（ （IF_ID）_ERROR_SPECオブジェクトに「失敗ローカルエラー/ LSPを通知」[RFC3473]）を参照して、新しいエラーコード/サブコードは、保護LSPに受信開始しなければなりません。 <送信元記述>または<流れ記述子が>また故障条件でLSP（セッション・オブジェクトと一緒に）を識別するので、任意の曖昧さとレースコンディションを解消通知メッセージ内に存在することに留意されたいです。
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.
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障害」（切替要求）を有する他のエンドノード（DまたはA、それぞれ）に、MESSAGE_IDオブジェクトを含む、通知メッセージを送らなければなりませんワーキングLSPの。この通知メッセージは、メッセージに対する肯定応答を送信するために受信機を要求するMESSAGE_IDオブジェクトに設定ACK_Desiredフラグで送らなければなりません（[RFC2961]を参照）。
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.
この（切替要求）メッセージは、（[RFC3473]を参照）IF_ID ERROR_SPECオブジェクトを使用して、故障したリンクの識別またはその他の関連情報を示すことができる通知。この場合、IF_ID ERROR_SPECオブジェクトは、通知メッセージ内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.
このノードは確実に（それぞれ、AまたはD）他のエンドノードに、MESSAGE_IDオブジェクトを含む通知メッセージを送らなければなりません。この（切替応答）メッセージを通知は、メッセージを通知（切替要求）の受信を確認するMESSAGE_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]).
この（切替応答）（[RFC3473]を参照）メッセージがIF_ID ERROR_SPECオブジェクトを使用して、故障したリンクの識別またはその他の関連情報を示すことができる通知。
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のために、それはERROR_SPECオブジェクトフラグ削除Path_State_を設定しないように推奨されたPathErrメッセージ生成時（[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ビットセットでシグナリングされるべきです。 Aは、（[RFC3473]を参照）ADMIN_STATUSオブジェクトに設定されたビットが以前働いてLSPをシグナリングすることができます。
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ビットが設定されている場合、上述したエンド・ツー・エンドの切替要求/応答交換のみ制御プレーン調整を（全くアクションがデータプレーンレベルでトリガされていない）を提供します。
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のばらばら。これは、作業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.
ワーキングLSPが失敗したときに保護LSPは、スイッチオーバーのために使用されています。 GMPLS RSVP-TEシグナリングは、Pathメッセージで示すことによりLSPを保護する事前プロビジョニングを可能にする（保護対象における、セクション14を参照）の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のセットアップはLSPのヘッドエンドとテールエンドノードはNOTIFYリクエストオブジェクトを使用してメッセージを通知受け取りたいことを示す必要があります。障害（Pathメッセージが横断方向において上流側）に上流のノードは、LSPヘッドエンドノードに通知メッセージを送信する必要があり、故障の下流ノードは、LSPテールエンドノードに通知メッセージを送信するべきです。通知メッセージを受信すると、両方のエンドノードが事前に設定保護LSP（セクション7.2を参照）ワーキングLSPから（通常の）トラフィックを切り替える必要があります。エクストラトラフィックは、エンドツーエンドの保護を介して搬送されている場合また、いくつかの調整が必要です
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が同一のエンドノード間で確立された場合、さらなる通知が作業の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保護余分なトラフィックを運ぶことができるので、何の資源共有がプロテクションパスに沿って行うことができません。
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の両方に影響を与える可能性があります。
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 protected LSP carrying working traffic and the protecting LSP that can carry extra-traffic.
関連の操作を簡略化するために、両方の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を設定するために使用されるPathメッセージに含まれています。この場合には「：Nエクストラトラフィックと保護1」 - このオブジェクトは、所望のエンドツーエンドのLSP保護タイプを運びます。この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は、0、0、Pビットに新たな保護対象にSビットを設定することによって合図され、関連オブジェクトに、保護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が0に新たな保護対象にSビットを設定することによって通知され、Pビットを1にし、関連オブジェクトは、関連する保護LSP_IDにアソシエーションID。
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）のいずれかによって開始されなければなりません。
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上の信号品質の劣化）を検出または<上流/下流セッションリスト>内のセッションオブジェクトを含む通知メッセージを受信した場合（ [RFC3473]）を参照し、新しいエラーコード/サブコードは、（IF_ID）_ERROR_SPECオブジェクトの「エラー/ LSPがローカル失敗通知」は、保護LSPから余分なトラフィックを切断します。 <送信元記述>または<流れ記述子が>また故障条件でLSP（セッション・オブジェクトと一緒に）を識別するので、任意の曖昧さとレースコンディションを解消通知メッセージ内に存在することに留意されたいです。
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障害」（切替要求）を有する他のエンドノード（DまたはA、それぞれ）に、MESSAGE_IDオブジェクトを含む、通知メッセージを送らなければなりませんワーキングLSPの。この通知メッセージは、メッセージに対する肯定応答を送信するために受信機を要求するMESSAGE_IDオブジェクトに設定ACK_Desiredフラグで送らなければなりません（[RFC2961]を参照）。
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.
この（切替要求）メッセージは、（[RFC3473]を参照）IF_ID ERROR_SPECオブジェクトを使用して、故障したリンクの識別またはその他の関連情報を示すことができる通知。この場合、IF_ID ERROR_SPECオブジェクトは、通知メッセージ内ERROR_SPECオブジェクトを置き換えます。そうでない場合は、対応する（データプレーン）情報はのPathErr / ResvErrメッセージで受信されるべきです。
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から余分なトラフィックを切断し、アウト/保護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.
このノードは確実に（それぞれ、AまたはD）他のエンドノードに、MESSAGE_IDオブジェクトを含む通知メッセージを送らなければなりません。この（切替応答）メッセージを通知は、メッセージを通知（切替要求）の受信を確認するMESSAGE_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]).
この（切替応答）（[RFC3473]を参照）メッセージがIF_ID ERROR_SPECオブジェクトを使用して、故障したリンクの識別またはその他の関連情報を示すことができる通知。
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に余分なトラフィックを接続の可能性が原因の領収書に存在しませんA中間ノードからのメッセージを受け取ります。
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.
（切替応答）を受信する（それぞれ、AまたはD）メッセージ、エンドノードに通知すると3.から通常のトラフィックを受信するか、保護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]).
保護が完了した（ステップ3）に切り替えた後、とのPathErrメッセージを受信した後、通常のトラフィックが撮影されたLSPを追跡するために、保護LSPがOビットセットでシグナリングされるべきです。 Aは、（[RFC3473]を参照）ADMIN_STATUSオブジェクトに設定されたビットがまた、以前働いてLSPをシグナリングすることができます。
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から資源互いに素であることを前提としています。この保護LSPは、それによって余分なトラフィックを伝送することができます。 N作業のLSPと保護LSPがすべてのエンドポイントの同じ対の間にあることに留意されたいです。また、（トラフィックパラメータの点で同一とみなす）NワーキングLSPは、相互リソース互いに素であるかもしれ。保護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保護タイプは0x04の（1：Nエクストラトラフィックと保護）に設定されているLSPセットアップ中。保護LSP IDにそれぞれ関連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セットアップ中：（エクストラトラフィックにN保護1）Sを0に設定ビットとPがLSP保護タイプが0x04のに設定されている1にセットビットが（余分なトラフィックを運ぶ）保護LSPがシグナリングされます。アソシエーション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保護の余分なトラフィックを持ちます。
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.
エンドツーエンドの（事前に計画）エクストラトラフィックなしに再ルーティングワーキングLSPからのリンク/ノード/ SRLGの互いに素であるワーキングLSPと保護LSPのエンドノードの同一の対の間に確立に依存しています。しかし、この場合、保護LSPが完全にインスタンス化されていません。したがって、それは（これは、対応するリソースが他のLSPで使用することができないことを意味するわけではないことに注意してください）余分なトラフィックを運ぶことができません。したがって、この機構は、ワーキングLSP障害（S）から保護するが、障害発生後に保護LSPの活性化を必要とします。
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の保持優先度よりも（数値的に高いことを意味します）。また、インタフェーススイッチング能力記述子サブTLVのマックスLSP Bandwidthフィールドは、帯域幅保護LSPのために事前に予約が余分なトラフィックのために利用可能であるという事実を反映すべきです。余分なトラフィックのためのLSPは、次に、帯域幅（Xは、保護LSPの設定優先である）Xに（Pathメッセージにおいて）SESSION_ATTRIBUTEオブジェクトのセットアップ優先度フィールドを設定することにより、保護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は、余分なトラフィックを運ぶことができません。障害が（たとえば、Bで）ワーキングLSP上で検出された場合、エラーが伝播され、および/または新しいエラーコード/サブコードと通知メッセージを使用して（通知（IF_IDで「エラー/ LSPがローカル失敗通知」入口ノード（A）へ）_ERROR_SPECオブジェクト）。受信すると、後者は、（プレ）プロビジョニング段階中にインスタンス化二次保護LSPを活性化します。これが必要です。
(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 activate a secondary LSP after failure occurrence.
（1）「二次保護LSP」を同定する能力は、（ここに「二次LSP」という）と、二次LSPを関連付ける（2）の能力（ここに「保護されたLSP」と呼ばれる）別の主要作業LSPを回復するために使用しました保護されたLSP（3）機能は、障害発生後の二次LSPを活性化します。
In the following subsections, these features are described in more detail.
以下のサブセクションでは、これらの機能をより詳細に説明されています。
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 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の両方に適用可能です。
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のシグナリングの中にPathメッセージに含まれています。
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は0、0にPビットに新たな保護対象にSビットを設定することにより、シグナリング、および関連オブジェクトで、アソシエーションID関連する二次保護LSP_IDにされます。
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のシグナリングの間Pathメッセージに含まれています。
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.
二次保護LSPは1に新たな保護対象にSビットとPビットをセットすることによって合図され、関連オブジェクトに、二次LSPのシグナリングの前に知っていなければならない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の活性化は、保護対象0に設定Sビットが変更パスメッセージを用いて行われます。この時点で、リンク及びノードのリソースが一次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の活性化を実行することが望ましいかもしれない代わりにデフォルトを使用する下流活性化。この場合、任意の誤順序及び（低優先度LSPに沿って）リフレッシュのResvの間の任意の誤解釈および（二次LSPに沿って）トリガResvメッセージは、任意の中間ノードで避けなければなりません。この目的のために、Pathメッセージを受信すると、出口ノードは、Resvメッセージ中の保護対象を含むかもしれません。後者は、その後、入口ノードに到達するまで二次LSPを活性化するためにホップバイホップに基づいて処理されます。保護対象は、このセクションで指定されるように設定しなければならないPathメッセージに含まれます。この場合、Sビットによる保護オブジェクトは0に設定しなければならなくて、上流方向に送信されたResvメッセージに含まれます。上流活性化挙動は、ローカルに基づいて構成可能であるべきです。二次LSP活性化の際に優先度の低いLSPプリエンプションに関する詳細はセクション10に設けられています。
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は、物理的に（すなわち、リンク、ノード、SRLG、など）互いに素であるとき、ネットワークリソースを共有する保護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の保持優先度よりも（数値的に高いことを意味します）。また、インタフェーススイッチング能力記述子サブTLVのマックスLSP Bandwidthフィールドは、帯域幅保護LSPのために事前に予約が余分なトラフィックのために利用可能であるという事実を反映すべきです。余分なトラフィックのためのLSPは、帯域幅（Pathメッセージに）設定することによって、保護LSPのために事前に予約を使用して確立することができるXにSESSION_ATTRIBUTEオブジェクトのセットアップ優先度フィールド（Xは、保護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は、二次LSPのLSP保護タイプが「エクストラトラフィックなしに再ルーティング」に設定されていることを認識した場合、E、F、およびGに沿ってリソースの共有にのみ達成することができる（保護対象を参照し、セクション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.
障害が（Bで、例えば）ワーキングLSPのいずれかで検出された場合、エラーが伝播され、および/または新しいエラーコード/サブコードと通知メッセージを使用して（通知の「エラー/ LSPがローカル失敗通知」入口ノード（A）から（IF_ID）_ERROR_SPECオブジェクト）。受信すると、後者は、二次保護LSP（セクション8を参照）を活性化します。この時点で、リソースが使用していますので（Jで言う、）他のLSP上の障害が保護LSPダウンデータを送信するために、他の進入（H）を生じさせないことが重要です。これは、次の手順を使用して、ノードEによって達成することができます。容量が最初の保護LSPのために予約されている場合、E（それぞれ、[A、B、C、D]及び[H、I、J、K]）のLSPが保護されていることを確認する必要があり、任意の共通のリソースを共有しません。障害が発生した（たとえば、Bで）及び保護LSP [A、E、F、G、D]が起動されるときに、Eは保護LSP [H、E、F、GのためのリソースことHを通知する必要があり、 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を関連付ける（2）の能力（ここに「保護されたLSP」と呼ばれる）別の主要作業LSPを回復するために使用しましたLSP二次LSPをインスタンス化しながら、保護LSPによって使用されるリソースに関する情報を含むように（3）機能を保護しました。 （4）効率的な方法でプロビジョニング相いくつかの二次LSPの中にインスタンス化する機能。 （5）障害発生後の二次LSPを活性化する能力を。
In the following subsections, these features are described in detail.
以下のサブセクションでは、これらの機能が詳細に記載されています。
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 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の両方に適用可能です。
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のシグナリングの中にPathメッセージに含まれています。
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は0、0にPビットに新たな保護対象にSビットを設定することにより、シグナリング、および関連オブジェクトで、アソシエーションID関連する二次保護LSP_IDにされます。
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のシグナリングの間Pathメッセージに含まれています。
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は1に新たな保護対象にSビットとPビットをセットすることによって合図され、関連オブジェクトに、二次LSPのシグナリングの前に知っていなければならないLSP_ID作業関連プライマリへアソシエーションID。また、二次LSPをインスタンス化するために使用されるPathメッセージは、さらに、二次経路に沿った各中間ノードで回復リソース共有を可能にする少なくとも一つのPRIMARY_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の活性化は、保護対象0に設定Sビットが変更パスメッセージを用いて行われます。この時点で、リンク及びノードのリソースが一次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]）。
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:
保護リソースのみ二次のLSPのために事前に予約されている場合、それらは、低い優先順位のLSPを設定するために使用されるかもしれません。保護LSPが起動されると、この場合、これらのリソースは、プリエンプトされなければなりません。二次保護LSPが活性化され、低優先順位のLSP（S）はプリエンプトされる間に、追加の条件は、誤接続の回避から上昇させます。二次保護LSP（すなわち、先取りLSP）Pathメッセージがより低い優先順位のLSP（S）のためのリソースを使用してノードに到達したときの手順を適用する以下の通りである（すなわち、LSP（s）はプリエンプト）。
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.
1.先取りのLSPによって使用されるリソースを割り当て解除し、クロスコネクトを放出します。先取りLSPが双方向である場合、これらのリソースは、1つまたは2つの低優先のLSPから来るかもしれないし、2つのLSPの場合、それらはユニまたは双方向であってもよいことに留意されたいです。これは、下流ノードがより迅速にリソースを再割り当てすることができる場合誤って接続となって下流のパスにつながる可能性があるため、リソースの割り当て解除が完了する前に先取りしたノードは、Pathメッセージを送るべきではありません。
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).
2.新しいエラーコード/サブコードとPathTearとのPathErrメッセージを送信する「ポリシー制御不良は/ハード横取り」と差し替えLSP（S）のためのPath_State_Removedフラグがセット。
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を先取り双方向の上流のリソースを相互接続することはできません。
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.
下流ノードからのトリガResvメッセージを受信すると5.下流パス・リソースを相互接続し、先取り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.
アラームが先取りLSPのために提起される可能性があり、そのステップ1に注意してください。アラーム抑制が望まれる場合、先取りノードは、ステップ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。デリソースを割り当てる前に、プリエンプトLSPのためにアラームを無効にするために、ADMIN_STATUSオブジェクトを含む、Resvメッセージを送信します。図1b。アラームが無効になっていることを示すPathメッセージを受信します。
At the downstream node (with respect to the preempting LSP), the processing is RECOMMENDED to be as follows:
次のように（プリエンプトLSPに対して）下流ノードに、処理をすることが推奨されます。
1. Receive PathTear (and/or PathErr) message for the preempted LSP(s).
1. PathTear（及び/又はのPathErr）プリエンプション処理LSP（S）のためのメッセージを受信します。
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].
図2（a）。 、先取り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.
前記下流ノードに転送、通常のように先取りLSPプロセスのためのPathメッセージを受信します。
4. Receive the Resv message for the preempting LSP and process as normal, forwarding it to the upstream node.
4.上流のノードに転送し、通常通り先取りLSPプロセスのためのResvメッセージを受信します。
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のヘッドエンドで選択され、元の経路に含まれる中間ノードを再利用することができます。それはまた、追加の中間ノードを含むことができます。厳密ホップルーティングのために、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.
（フル）LSPの再ルーティングは、LSP障害を検出またはNotifyメッセージおよび/または新しいエラーコード/サブコードとのPathErrメッセージは、「エラーを通知/ LSPがローカル失敗」を受信したいずれかのヘッドエンドノードによって開始されますこのLSP。新しいLSPのリソースが古いLSPが取り壊される前に、新しいLSPが設定されているメイクビフォア・ブレークメカニズムを、使用して確立することができます。これはSESSION_ATTRIBUTEオブジェクトと共有-明示（SE）予約スタイル（[RFC3209]を参照のこと）のメカニズムを使用することによって行われます。どちらも新旧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に割り当てられたリソースを保持する価値があります。
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_ID値は、新しい代替LSPから古いを区別します。古いLSPを共有-明示（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-スタイルのリソース予約で任意の障害発生前に、同じトンネルエンドポイントアドレス、トンネルID、拡張トンネルID、およびオリジナルのLSP（すなわち、唯一のLSP IDとトンネルの送信者アドレスを設定することができます値）が異なっている必要があります。
In both cases, the Association ID of the ASSOCIATION object MUST be set to the LSP ID value of the signaled LSP.
両方の場合において、関連オブジェクトのアソシエーションIDが通知LSPのLSP ID値に設定しなければなりません。
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.
新しい保護対象は、「フル再ルーティング」に設定し、エンドツーエンドのLSP保護タイプ値と、動的reroutable LSPのシグナリングの間Pathメッセージに含まれています。ユニまたは双方向のいずれかであることができるこれらのLSPが0に保護対象のSビットを設定することによりシグナリングされる、0〜Pビット、及びシグナリングLSPのLSP_ID値にアソシエーションID値。プロビジョニング段階中に取られる特定のアクションは、エンドノードローカルポリシー次第です。
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は、そのようなポリシー条件で駆動されるパスの再最適化と帯域幅の調整など、他の理由で再確立することができないという意味ではありません。
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回復通知」（スイッチバックRequest）を用いて行われます。
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回復」（スイッチバック要求）と先に確実に通知メッセージを送信します。この通知メッセージは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]).
宛先は、操作の完了を確認したソースに確実に通知メッセージを送信します。このメッセージは、通知受信メッセージの受信を確認するために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オブジェクトのビット。
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回復通知」（スイッチバックRequest）を用いて行われます。
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回復」（スイッチバック要求）と先に確実に通知メッセージを送信します。この通知メッセージは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]).
宛先は、操作の完了を確認したソースに確実に通知メッセージを送信します。このメッセージは、通知受信メッセージの受信を確認するために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, 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オブジェクトのビット。
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回復通知」（スイッチバックRequest）を用いて行われます。
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回復」（スイッチバック要求）と先に確実に通知メッセージを送信します。この通知メッセージは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]).
宛先は、操作の完了を確認したソースに確実に通知メッセージを送信します。このメッセージは、通知受信メッセージの受信を確認するために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, 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, de-activate the protecting LSP by setting the S bit to 1 in the PROTECTION object sent over the protecting LSP.
3.最後に、保護LSPを介して送信される保護対象で1にSビットを設定することにより、保護LSPを非活性化します。
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:
回復LSPのA.ロックアウト：
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
ロックアウト（L）ADMIN_STATUSオブジェクトのビットは、[RFC3471]のセクション8と[RFC3473]のセクション7で定義された規則に従って使用されます。 Lビットは、Pathメッセージで送信ADMIN_STATUSオブジェクトに反映（R）ビットと一緒に設定されなければなりません。を受信すると
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).
LビットがセットされたRESVメッセージが、これは回復LSPが（正常またはエクストラトラフィックのいずれか）トラフィックを転送するために一時的に使用不可であることを強制します。ロック解除は、[RFC3473]のセクション7で定義された規則に従って、Lビットをクリアすることによって行われます。 、または0x08に（1 + 1単方向保護）、または0x10の（1 + 1双方向保護）：LSP保護タイプフラグが0x04の（Nエクストラトラフィックと保護1）のいずれかに設定されている場合、この手順は、適用可能です。
The updated format of the ADMIN_STATUS object to include the L bit is as follows:
次のようにLビットを含むようにADMIN_STATUSオブジェクトの更新された形式は次のとおりです。
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).
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]。
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ビットは、通常のトラフィックを転送するために一時的に使用できないことが回復LSPを強制的に1に設定されています。ワーキングLSPは、通常のトラフィックを伝送している場合を除き、この動作は発生してはなりません。ロック解除は、保護LSP上にOビットをクリアすることによって行われます。 、または0x08に（1 + 1単方向保護）、または0x10の（1 + 1双方向保護）：LSP保護タイプフラグが0x04の（Nエクストラトラフィックと保護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で定義された手順に従って回復LSPに、通常のトラフィックを切り替えることを開始し、9障害状態が（回復LSPを含む）、他の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.
回復シグナリングは、この要求は、障害状態がワーキングLSP上に存在するか、等しいか、より高い優先順位のスイッチコマンドが有効である場合を除いて実行され、セクション12で定義された手順に従って作業LSPに、通常のトラフィックを切り替えることで開始されます。
This section describes the extensions to the PROTECTION object to broaden its applicability to end-to-end LSP recovery.
このセクションでは、エンドツーエンドのLSP回復への適用可能性を広げるために保護対象に拡張機能について説明します。
The format of the PROTECTION Object (Class-Num = 37, C-Type = 2) is as follows:
次のように保護対象のフォーマットは（クラス民37 = Cタイプ= 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
二次（S）：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が0にPセットで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（デフォルト値）に設定すると、それが制御プレーンのメッセージ交換は、保護スイッチングの目的で使用されていることを示しています。 、または0x08に（1 + 1単方向保護）、または0x10の（1 + 1双方向保護）：LSP保護タイプフラグが0x04の（Nエクストラトラフィックと保護1）のいずれかに設定されている場合、N個のビットのみ適用可能です。 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保護切替えた後、通常のトラフィックを運んでいることを示しています。 、または0x08に（1 + 1単方向保護）又は0x10の（1：Pビットが1に設定され、LSP保護タイプフラグが0x04の（Nエクストラトラフィックと保護1）のいずれかに設定されているときにOビットのみ適用され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.
希望エンド・ツー・エンドのLSP回復タイプを示します。 0の値は、LSPが「保護されていない」であることを意味します。値は1つだけの時間に設定してください。次の値が定義されています。その他の値はすべて予約されています。
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
Reservedフィールド：32ビット
Encoding of this field is detailed in [RFC4873].
このフィールドのエンコーディングは、[RFC4873]に詳述されています。
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".
PROTECTIONオブジェクトを含むPathメッセージを処理し、中間及び出口ノードは、要求されたLSP保護タイプが着信インターフェースによって満たすことができることを確認しなければなりません。それができない場合、ノードは新しいエラーコード/サブコード「ルーティングの問題/サポートされていないLSP保護」で、の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保護タイプ0×02（エクストラトラフィックなしで再ルーティング）設定値とPRIMARY_PATH_ROUTEオブジェクト（セクション15を参照）を用いて保護対象を含むPathメッセージを処理する中間ノードは、要求されたLSP保護タイプは、発信インターフェイスによってサポートできることを確認しなければなりません。それができない場合、ノードは新しいエラーコード/サブコード「ルーティングの問題/サポートされていないLSP保護」とのPathErrメッセージを発生させなければなりません。
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の経路に沿ってノードに通知するために定義されている（アソシエーションIDフィールドによって指定される）LSPを保護しました。 LSP保護タイプ値は（エクストラトラフィックなしに再ルーティング）0x02のに設定されている場合、このオブジェクトは、（LSPは、1つ以上の二次保護のLSPとの間に回復リソースの共有を可能にするために、保護二の事前プロビジョニングのためのPathメッセージ中に存在すべきです）第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オブジェクトはEXPLICIT ROUTEオブジェクトおよび/または、彼らは保護主な作業LSPのレコードルートオブジェクトから抽出された情報を運びます。ますPproコンテンツの選択は、要求を開始し、ヘッドエンドノードのローカルポリシー次第です。したがって、これらのオブジェクトに含まれる情報は、その回復リソースのみ、その関連する一次LSPのリンク/ノード/ SRLGディスジョイント経路を有する二次保護のLSP間で共有されるように、ポリシーベースのアドミッションコントロールとして使用することができます。
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）を介して指定されています。 38 0bbbbbbbはフォームのプライマリパスルートクラス数（クラス-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
クラス民は、（フォームの0bbbbbbbは）38、Cタイプ= 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オブジェクトの内容は、サブオブジェクト（セクション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を知らせるために、Pathメッセージは、各オブジェクトが意味を持つ1つまたは複数PRIMARY_PATH_ROUTEオブジェクトを含むことができます。所定の二次保護LSPは、複数の一次LSPからのリンク/ノード/ SRLGの互いに素でなければならない場合、後者は有用である（すなわち、複数の一次LSPを保護しています）。
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).
PRIMARY_PATH_ROUTEオブジェクトは、サブオブジェクトと呼ばれる可変長のデータ項目のリストとして定義されます。これらのサブオブジェクトは、明示的経路および/または一次作業LSP（単数または複数）のレコードルートオブジェクトのサブオブジェクトから誘導されます。
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])
- サブタイプ1：IPv4アドレス（[RFC3209]を参照） - サブタイプ2：IPv6アドレス（[RFC3209]を参照） - サブタイプ3：ラベル（[RFC3473]を参照） - サブタイプ4：番号なしインターフェイス（参照[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".
なしサブオブジェクトで空ますPproが違法と見なされます。いかなる第一サブオブジェクトがない場合、対応するPathメッセージはエラーでもあり、受信ノードは、新しいエラーコード/サブコード「ルーティング問題/バート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、または対応するTEリンクへのポインタとして4つのサブオブジェクト値を使用してローカルIGP-TEデータベースからSRLG識別子を導出することができる（それらの各々は、関連するSRLG TE属性を持つと仮定して）。
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]).
経路に沿った全てのGMPLSノードがPRIMARY_PATH_ROUTEオブジェクトをサポートする場合PRIMARY_PATH_ROUTEオブジェクトにのみ使用されてもよく、二次保護LSPが要求されています。 PRIMARY_PATH_ROUTEオブジェクトは、フォームの0bbbbbbbはクラス値が割り当てられます。このオブジェクトが「未知のオブジェクトクラス」エラーコードのPathErrメッセージを返さなければなりませんサポートしていない経路に沿ってGMPLSノードを受ける（参照[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).
- 二次保護のLSP（Sビット= 1とPビット= 1）をシグナリングするときPPROsは、Pathメッセージに含まれてもよく、LSP保護タイプ値は、保護対象に（エクストラトラフィックを再ルーティングすることなく）0×02に設定されている場合（セクションを参照します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は、1つ以上の二次保護のLSP（15.4項を参照）との間に回復リソースの共有を可能にするための二次保護LSPの事前プロビジョニングのためのPathメッセージ中に存在すべきです。
- 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を確立するために再利用してはいけません受け取りました。
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).
それらの対応する主要作業のLSPは、互いに（リンク/ノード/ SRLG）互いに素な経路を有する場合は、与えられますPpro二次保護LSPと1つ以上の二次保護のLSPとの間に回復リソースを共有可能にします。 （n個の一次作業LSPを保護するノードNいるN二次保護のLSPを介して（例えば、P [1]、...、P [n]が）、すでに確立されていると考えるたとえば、P '[1]、...、 P '[N]）。これらのN個の二次加工のLSPは、所与の発信リンクリソース（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は、（たとえば、Qは、Qを保護 '）追加の二次保護LSPのパスメッセージを受信したとします。次のようにこのPathメッセージによって運ばれます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.
- Nチェックは主要作業のLSPのPかどう '[1]、...、P' [n]はLSPをP [1]、...、P [n]は、それぞれ、有する任意のリンク、ノード、および関連付けられました主要作業Qと共通のSLRG [1]、...、P「格納されますPproを比較することによって（Qに関連した）がPに関連付けられたサブオブジェクト 『』ますPproと[n]がQに関連付けられたサブオブジェクト」Pathメッセージで受信。
- 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 [1]、...、P [n]とQ.しかし、ローカルポリシーの決定の際に、Nは、割り当てることができるPとの間の送信リンクリソースRを共有しないでください他の利用可能な（共有） 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はPのLSPのために選択されたものと正確に同じであってもよいです[1]、...、P [N]。これは、選択されたリンクrはこれらのLSP間で共有することができること（ノードのローカルポリシーから）確認した後に起こります。そうでない場合（例えば、共有率は、そのリンクのためにその最大値に達している）、およびローカルポリシーの決定の際に、他のリンクがQに割り当てることを許可されていない場合、Nは、エラーコードのPathErrメッセージを返すべき/サブコード「アドミッション制御不良/要求帯域利用不可」（参照[RFC2205]）。 （他のリンクが利用できない場合）それ以外の場合、Nは、新しいエラーコード/サブコード「アドミッション制御不良/ LSPアドミッション失敗」との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（M = <N）二次保護のLSP PPROsは、上記の比較およびその後のリンクの選択を実行するためにローカルに基づいて選択することができ、それを通してプロセスは、この文書の範囲外であることに留意されたいです。
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.
関連オブジェクトは、互いにLSPを関連付けるために使用されます。エンドツーエンドのLSP回復の文脈では、関連は、同じトンネルIDならびに同じトンネルの送信元アドレス及びトンネルエンドポイントアドレスをサポートするLSPを識別しなければなりません。オブジェクトのアソシエーションのタイプ、アソシエーション・ソース、及びアソシエーションIDフィールドは、一緒に一意の関連付けを識別する。オブジェクトは非サポートノードとの互換性を確保するために、フォーム11bbbbbbのオブジェクトクラス番号を使用します。
The ASSOCIATION object is used to associate LSPs with each other.
関連オブジェクトは、互いにLSPを関連付けるために使用されます。
The IPv4 ASSOCIATION object (Class-Num of the form 11bbbbbb with value = 199, C-Type = 1) has the format:
IPv4の関連オブジェクト（値を持つフォーム11bbbbbbのクラスのNum = 199、C-タイプ= 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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の関連オブジェクト（値を持つフォーム11bbbbbbのクラスのNum = 199、C-タイプ= 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(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.
IPv4またはIPv6アドレスは、それぞれ、それが関連を発信したノードに関連付けられています。
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（S）またはその回復LSPで保護LSP（S）と回復LSPを関連付けるために使用されます。オブジェクトは、Pathメッセージで運ばれます。複数のオブジェクトは、単一のPathメッセージで行うことができます。
Transit nodes MUST transmit, without modification, any received ASSOCIATION object in the corresponding outgoing Path message.
トランジットノードは、いずれかが、対応する送信Pathメッセージに関連オブジェクトを受信し、修正することなく、送信しなければなりません。
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のPathメッセージの値「復旧」に設定しなければなりません。
- 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 IDは、このLSPを保護し、このLSPまたはLSPによって保護さに設定しなければなりません。不明な場合は、この値は、独自の合図LSP_ID値（デフォルト）に設定されています。また、協会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を関連付ける受信ASSOCIATIONオブジェクト（複数可）の値に設定アソシエーションタイプで「リカバリ」を使用します。この情報は、一緒に適切な作業と回復LSPをバインドするために使用されます。そのようなノードが存在する場合には関連オブジェクト（複数可）を含む、受信したPathメッセージは、（保護対象処理のためのセクション14を参照）、適切な保護対象の設定で処理されることを保証しなければなりません。それ以外の場合、このノードは新しいエラーコード/サブコード「LSPアドミッション失敗/バッド協会タイプ」とのPathErrメッセージを返さなければなりません。とPathメッセージを受信し、同様に、終端ノード
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メッセージを返さなければなりません。
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メッセージの形式は次のとおりです。
<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のための<送信元記述>のフォーマットは、本文書によって変更されません。
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.
<フロー記述子リスト>この文書では変更されません。
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メッセージ認証と完全性を提供します。 [RFC3473]で説明したように非ホップバイホップRSVPメッセージ交換のための標準の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].
また、この文書は、通知メッセージ交換を利用します。これは、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。
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:
二つのRSVPのクラス番号（クラスのNum）と3つのクラスの型（C-タイプ）の値は、レジストリでIANAによって定義される必要があります：
http://www.iana.org/assignments/rsvp-parameters
ｈっｔｐ：／／ｗっｗ。いあな。おｒｇ／あっしｇんめんｔｓ／ｒｓｖｐーぱらめてｒｓ
1) PROTECTION object (defined in Section 14.1)
セクション14.1で定義された1）保護対象（）
o PROTECTION object: Class-Num = 37
O保護オブジェクト：クラス民は37 =
- Type 2: C-Type = 2
- タイプ2：Cタイプ= 2
2) PRIMARY_PATH_ROUTE object (defined in Section 15.1)
セクション15.1で定義された2）PRIMARY_PATH_ROUTEオブジェクト（）
o PRIMARY_PATH_ROUTE object: Class-Num = 38 (of the form 0bbbbbbb),
O PRIMARY_PATH_ROUTEオブジェクト：クラス民は、（フォームの0bbbbbbbは）38 =
- Primary Path Route: C-Type = 1
- プライマリパスルート：C-タイプ= 1
3) ASSOCIATION object (defined in Section 16.1)
セクション16.1で定義されている3）ASSOCIATIONオブジェクト（）
o ASSOCIATION object: Class-Num = 199 (of the form 11bbbbbb)
O関連オブジェクト：クラスのNum = 199（フォーム11bbbbbbの）
- IPv4 Association: C-Type = 1 - IPv6 Association: C-Type = 2
- IPv4の協会：Cタイプ= 1 - IPv6の協会：Cタイプ= 2
o Association Type
お あっそしあちおん Ｔｙぺ
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)
O "ルーティング問題/バートPRIMARY_PATH_ROUTEオブジェクト"（19）O（18） "該当しないルーティング問題/ PROTECTIONオブジェクト" O "ルーティング問題/サポートされていないLSP保護"（17）O（20） "ルーティング問題/ PRIMARY_PATH_ROUTEは該当しないオブジェクト"
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）（11）を "ローカル失敗エラー/ LSPを通知します" ○
5) Registration of the ADMIN_STATUS object bits
ADMIN_STATUSオブジェクトビット5）登録
The ADMIN_STATUS object (Class-Num = 196, C-Type = 1) is defined in [RFC3473].
ADMIN_STATUSオブジェクトは（クラスのNum = 196、C-タイプ= 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]
[28]コントロールを呼び出す（C）ビットが[29]テスト（T）ビットが[30]管理上のダウン（A）ビットは[RFC3471] [31]削除で定義されている[RFC3471]で定義されている[GMPLS-CALL]で定義されています進行中の（D）ビットは、[RFC3471]で定義されています
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.
著者は、ドキュメントの彼の徹底的な見直し、（論説レビューのために）バート・ルソー、ドミニクVerchere（セクション10及び11に、具体的には）彼の積極的な協力は、この文書への貢献のためのエードリアンファレルのためにジョン・ドレイクに感謝したいと思います、およびStefaanデ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.
著者は、また、本文書に貢献するには、彼が設計チームと一緒に過ごした時間と労力のためのルー・バーガーに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]ブレーデン、R.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1の機能的な仕様"、RFC 2205、1997年9月。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747]ベーカー、F.、リンデル、B.、およびM. Talwar、 "RSVP暗号化認証"、RFC 2747、2000年1月。
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001.
[RFC2961]バーガー、L.、ガン、D.、ツバメ、G.、パン、P.、Tommasi、F.、及びS. Molendini、 "RSVPリフレッシュオーバーヘッド削減拡張"、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.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "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]バーガー、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]バーガー、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]マニー、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]ラング、J.、Rajagopalan、B.、およびD. Papadimitriou、 "一般化されたマルチプロトコルラベルスイッチング（GMPLS）回復機能仕様"、RFC 4426、2006月。
[RFC4873] Berger, L., Bryskin, I., Papdimitriou, D., and A. Farrel, "GMPLS Segment Recovery," RFC 4873, May 2007.
[RFC4873]バーガー、L.、Bryskin、I.、Papdimitriou、D.、およびA.ファレル、 "GMPLSセグメント回復、" RFC 4873、2007年5月。
[RFC4783] Berger, L., "GMPLS - Communication of Alarm Information", RFC 4783, December 2006.
[RFC4783]バーガー、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]ファレル、A.編、 "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.、エド。、およびA.ファレル、エド。、 "一般化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]パン、P.、エド。、ツバメ、G.、エド。、およびA.アトラス編、 "高速リルート機能拡張LSPトンネルのための-TEをRSVPする"、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]マニー、E.、エド。、およびD. Papadimitriou、エド。、 "リカバリ（保護と回復）一般化マルチプロトコルラベルスイッチング（GMPLS）のための用語"、RFC 4427、2006月。
[RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4874, April 2007.
[RFC4874]リー、CY、ファレル、A.、およびS.デCnodderは、 "ルートの除外 - 拡張をリソースへの予約プロトコル - トラフィックエンジニアリング（RSVP-TE）"、RFC 4874、2007年4月。
[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ネットワーク保護アーキテクチャの特性、" http://www.itu.intから入手勧告G.841、1998年10月、。
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
デボラBrungard（AT＆T）Rmを。 200、S.ローレルアベニュー - D1-3C22ミドルタウン、NJ 07748、USA Eメール：dbrungard@att.com
Sudheer Dharanikota EMail: sudheer@ieee.org
Sudheer Dharanikota Eメール：sudheer@ieee.org
Guangzhi Li (AT&T) 180 Park Avenue Florham Park, NJ 07932, USA EMail: gli@research.att.com
Guangzhiリー（AT＆T）180パークアベニューフローラムパーク、NJ 07932、USA Eメール：gli@research.att.com
Eric Mannie (Perceval) Rue Tenbosch, 9 1000 Brussels, Belgium Phone: +32-2-6409194 EMail: eric.mannie@perceval.net
エリック・マニー（パーシヴァル）ルーテンボス、9千ブリュッセル、ベルギー電話：+ 32-2-6409194 Eメール：eric.mannie@perceval.net
Bala Rajagopalan (Intel Broadband Wireless Division) 2111 NE 25th Ave. Hillsboro, OR 97124, USA EMail: bala.rajagopalan@intel.com
バラRajagopalan（インテル・ブロードバンド・ワイヤレス部門）2111 NE 25日アベニュー。ヒルズボロ、OR 97124、USA Eメール：bala.rajagopalan@intel.com
Editors' Addresses
エディタのアドレス
Jonathan P. Lang Sonos 506 Chapala Street Santa Barbara, CA 93101, USA
ジョナサンP.ラングSonosの506チャパラストリートサンタバーバラ、CA 93101、USA
EMail: jplang@ieee.org
メールアドレス：jplang@ieee.org
Yakov Rekhter Juniper 1194 N. Mathilda Avenue Sunnyvale, CA 94089, USA
ヤコフ・レックタージュニパー1194 N.マチルダアベニューサニーベール、CA 94089、USA
EMail: yakov@juniper.net
メールアドレス：yakov@juniper.net
Dimitri Papadimitriou Alcatel Copernicuslaan 50 B-2018, Antwerpen, Belgium
ディミトリPapadimitriouアルカテルKopernikoslaan 50 B-2018、Antverpen、Velgiom
EMail: dimitri.papadimitriou@alcatel-lucent.be
メールアドレス：dimitri.papadimitriou@alcatel-lucent.be
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。