[要約] RFC 6372は、MPLS-TPの生存性フレームワークに関するものであり、MPLSネットワークの障害復旧機能を提供するためのガイドラインを提供しています。その目的は、MPLS-TPネットワークの信頼性と可用性を向上させることです。
Internet Engineering Task Force (IETF) N. Sprecher, Ed.
Request for Comments: 6372 Nokia Siemens Networks
Category: Informational A. Farrel, Ed.
ISSN: 2070-1721 Juniper Networks
September 2011
MPLS Transport Profile (MPLS-TP) Survivability Framework
MPLSトランスポートプロファイル（MPLS-TP）サバイバビリティフレームワーク
Abstract
概要
Network survivability is the ability of a network to recover traffic delivery following failure or degradation of network resources. Survivability is critical for the delivery of guaranteed network services, such as those subject to strict Service Level Agreements (SLAs) that place maximum bounds on the length of time that services may be degraded or unavailable.
ネットワークの生存性とは、ネットワークが障害またはネットワークリソースの劣化後のトラフィック配信を回復する能力です。生存性は、サービスが劣化または利用できない時間の長さに最大の境界を置く厳格なサービスレベル契約（SLA）の対象となるような保証されたネットワークサービスの提供に重要です。
The Transport Profile of Multiprotocol Label Switching (MPLS-TP) is a packet-based transport technology based on the MPLS data plane that reuses many aspects of the MPLS management and control planes.
マルチプロトコルラベルスイッチング（MPLS-TP）の輸送プロファイルは、MPLS管理および制御プレーンの多くの側面を再利用するMPLSデータプレーンに基づくパケットベースのトランスポートテクノロジーです。
This document comprises a framework for the provision of survivability in an MPLS-TP network; it describes recovery elements, types, methods, and topological considerations. To enable data-plane recovery, survivability may be supported by the control plane, management plane, and by Operations, Administration, and Maintenance (OAM) functions. This document describes mechanisms for recovering MPLS-TP Label Switched Paths (LSPs). A detailed description of pseudowire recovery in MPLS-TP networks is beyond the scope of this document.
このドキュメントは、MPLS-TPネットワークでの生存性の提供のためのフレームワークで構成されています。回復要素、種類、方法、およびトポロジカルな考慮事項について説明します。データプレーンの回復を可能にするために、サバイバビリティは、コントロールプレーン、管理プレーン、および運用、管理、およびメンテナンス（OAM）機能によってサポートされます。このドキュメントでは、MPLS-TPラベルスイッチ付きパス（LSP）を回復するためのメカニズムについて説明します。MPLS-TPネットワークにおける擬似動物の回復の詳細な説明は、このドキュメントの範囲を超えています。
This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet-based transport network as defined by the ITU-T.
このドキュメントは、IETF MPLSおよびPSEUDOWIREエミュレーションエッジ（PWE3）アーキテクチャ内にMPLS輸送プロファイルを含めるための共同インターネットエンジニアリングタスクフォース（IETF） /国際電気通信連合電気通信標準化セクター（ITU-T）の製品です。ITU-Tで定義されているパケットベースのトランスポートネットワークの機能と機能をサポートします。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。すべての文書ではありません
approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
IESGによって承認されたのは、あらゆるレベルのインターネット標準の候補者です。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6372.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6372で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Recovery Schemes ...........................................4
1.2. Recovery Action Initiation .................................5
1.3. Recovery Context ...........................................6
1.4. Scope of This Framework ....................................7
2. Terminology and References ......................................8
3. Requirements for Survivability .................................10
4. Functional Architecture ........................................10
4.1. Elements of Control .......................................10
4.1.1. Operator Control ...................................11
4.1.2. Defect-Triggered Actions ...........................12
4.1.3. OAM Signaling ......................................12
4.1.4. Control-Plane Signaling ............................12
4.2. Recovery Scope ............................................13
4.2.1. Span Recovery ......................................13
4.2.2. Segment Recovery ...................................13
4.2.3. End-to-End Recovery ................................14
4.3. Grades of Recovery ........................................15
4.3.1. Dedicated Protection ...............................15
4.3.2. Shared Protection ..................................16
4.3.3. Extra Traffic ......................................17
4.3.4. Restoration ........................................19
4.3.5. Reversion ..........................................20
4.4. Mechanisms for Protection .................................20
4.4.1. Link-Level Protection ..............................20
4.4.2. Alternate Paths and Segments .......................21
4.4.3. Protection Tunnels .................................22
4.5. Recovery Domains ..........................................23
4.6. Protection in Different Topologies ........................24
4.7. Mesh Networks .............................................25
4.7.1. 1:n Linear Protection ..............................26
4.7.2. 1+1 Linear Protection ..............................28
4.7.3. P2MP Linear Protection .............................29
4.7.4. Triggers for the Linear Protection
Switching Action ...................................30
4.7.5. Applicability of Linear Protection for LSP
Segments ...........................................31
4.7.6. Shared Mesh Protection .............................32
4.8. Ring Networks .............................................33
4.9. Recovery in Layered Networks ..............................34
4.9.1. Inherited Link-Level Protection ....................35
4.9.2. Shared Risk Groups .................................35
4.9.3. Fault Correlation ..................................36
5. Applicability and Scope of Survivability in MPLS-TP ............37
6. Mechanisms for Providing Survivability for MPLS-TP LSPs ........39
6.1. Management Plane ..........................................39
6.1.1. Configuration of Protection Operation ..............40
6.1.2. External Manual Commands ...........................41
6.2. Fault Detection ...........................................41
6.3. Fault Localization ........................................42
6.4. OAM Signaling .............................................43
6.4.1. Fault Detection ....................................44
6.4.2. Testing for Faults .................................44
6.4.3. Fault Localization .................................45
6.4.4. Fault Reporting ....................................45
6.4.5. Coordination of Recovery Actions ...................46
6.5. Control Plane .............................................46
6.5.1. Fault Detection ....................................47
6.5.2. Testing for Faults .................................47
6.5.3. Fault Localization .................................48
6.5.4. Fault Status Reporting .............................48
6.5.5. Coordination of Recovery Actions ...................49
6.5.6. Establishment of Protection and Restoration LSPs ...49
7. Pseudowire Recovery Considerations .............................50
7.1. Utilization of Underlying MPLS-TP Recovery ................50
7.2. Recovery in the Pseudowire Layer ..........................51
8. Manageability Considerations ...................................51
9. Security Considerations ........................................52
10. Acknowledgments ...............................................52
11. References ....................................................53
11.1. Normative References .....................................53
11.2. Informative References ...................................54
Network survivability is the network's ability to recover traffic delivery following the failure or degradation of traffic delivery caused by a network fault or a denial-of-service attack on the network. Survivability plays a critical role in the delivery of reliable services in transport networks. Guaranteed services in the form of Service Level Agreements (SLAs) require a resilient network that very rapidly detects facility or node degradation or failures, and immediately starts to recover network operations in accordance with the terms of the SLA.
ネットワークの生存性とは、ネットワークの障害またはネットワークへのサービス拒否攻撃によって引き起こされる交通配信の障害または劣化に続いて、交通納期を回復するネットワークの能力です。生存性は、輸送ネットワークでの信頼できるサービスの提供において重要な役割を果たします。サービスレベル契約（SLA）の形式での保証されたサービスには、施設またはノードの劣化または障害を非常に迅速に検出する回復力のあるネットワークが必要であり、SLAの条件に従って直ちにネットワーク運用を回復し始めます。
The MPLS Transport Profile (MPLS-TP) is described in [RFC5921]. MPLS-TP is designed to be consistent with existing transport network operations and management models, while providing survivability mechanisms, such as protection and restoration. The functionality provided is intended to be similar to or better than that found in established transport networks that set a high benchmark for reliability. That is, it is intended to provide the operator with functions with which they are familiar through their experience with other transport networks, although this does not preclude additional techniques.
MPLS輸送プロファイル（MPLS-TP）は[RFC5921]で説明されています。MPLS-TPは、保護や回復などの生存可能性メカニズムを提供しながら、既存の輸送ネットワーク運用および管理モデルと一致するように設計されています。提供される機能は、信頼性のために高いベンチマークを設定する確立された輸送ネットワークに見られるものと見られるものとは異なることを目的としています。つまり、他の輸送ネットワークとの経験を通じて馴染みのある機能をオペレーターに提供することを目的としていますが、これは追加の手法を排除しません。
This document provides a framework for MPLS-TP-based survivability that meets the recovery requirements specified in [RFC5654]. It uses the recovery terminology defined in [RFC4427], which draws heavily on [G.808.1], and it refers to the requirements specified in [RFC5654].
このドキュメントは、[RFC5654]で指定された回復要件を満たすMPLS-TPベースの生存性のフレームワークを提供します。[RFC4427]で定義された回復用語を使用します。これは[G.808.1]を大きく描き、[RFC5654]で指定された要件を指します。
This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet-based transport network, as defined by the ITU-T.
このドキュメントは、IETF MPLSおよびPWE3アーキテクチャ内にMPLS輸送プロファイルを含めるための共同インターネットエンジニアリングタスクフォース（IETF） /国際電気通信連合電気通信標準化セクター（ITU-T）の製品です。-ITU-Tで定義されているように、ベースの輸送ネットワーク。
Various recovery schemes (for protection and restoration) and processes have been defined and analyzed in [RFC4427] and [RFC4428]. These schemes can also be applied in MPLS-TP networks to re-establish end-to-end traffic delivery according to the agreed service parameters, and to trigger recovery from "failed" or "degraded" transport entities. In the context of this document, transport entities are nodes, links, transport path segments, concatenated transport path segments, and entire transport paths. Recovery actions are initiated by the detection of a defect, or by an external request (e.g., an operator's request for manual control of protection switching).
さまざまな回復スキーム（保護と回復のため）とプロセスは、[RFC4427]および[RFC4428]で定義および分析されています。これらのスキームは、MPLS-TPネットワークに適用して、合意されたサービスパラメーターに従ってエンドツーエンドのトラフィック配信を再確立し、「失敗した」または「劣化した」輸送機関からの回復をトリガーすることもできます。このドキュメントのコンテキストでは、輸送エンティティはノード、リンク、輸送パスセグメント、連結された輸送パスセグメント、および輸送パス全体です。回復アクションは、欠陥の検出、または外部リクエスト（たとえば、保護スイッチングの手動制御のオペレーターの要求）によって開始されます。
[RFC4427] makes a distinction between protection switching and restoration mechanisms.
[RFC4427]は、保護の切り替えと修復メカニズムを区別します。
- Protection switching uses pre-assigned capacity between nodes, where the simplest scheme has a single, dedicated protection entity for each working entity, while the most complex scheme has m protection entities shared between n working entities (m:n).
- 保護スイッチングは、ノード間で事前に割り当てられた容量を使用します。最もシンプルなスキームには、各作業エンティティごとに単一の専用保護エンティティがあり、最も複雑なスキームにはN作業エンティティ（M：N）の間で共有されています。
- Restoration uses any capacity available between nodes and usually involves rerouting. The resources used for restoration may be pre-planned (i.e., predetermined, but not yet allocated to the recovery path), and recovery priority may be used as a differentiation mechanism to determine which services are recovered and which are not recovered.
- 修復は、ノード間で利用可能な容量を使用し、通常は再ルーティングを伴います。修復に使用されるリソースは、事前に計画されている場合（つまり、事前に決められていますが、まだ回復パスに割り当てられていません）、回復の優先順位を分化メカニズムとして使用して、どのサービスが回復し、どのサービスが回復されないかを決定できます。
Both protection switching and restoration may be either unidirectional or bidirectional; unidirectional implies that protection switching is performed independently for each direction of a bidirectional transport path, while bidirectional means that both directions are switched simultaneously using appropriate coordination, even if the fault applies to only one direction of the path.
保護の切り替えと回復の両方が、一方向または双方向のいずれかです。単方向とは、双方向の輸送経路の各方向に対して保護スイッチングが独立して実行されることを意味しますが、双方向は、障害がパスの1つの方向のみに適用されても、適切な調整を使用して両方の方向が同時に切り替えられることを意味します。
Both protection and restoration mechanisms may be either revertive or non-revertive as described in Section 4.11 of [RFC4427].
保護メカニズムと回復メカニズムの両方が、[RFC4427]のセクション4.11で説明されているように、復帰または非反転のいずれかです。
Preemption priority may be used to determine which services are sacrificed to enable the recovery of other services. Restoration may also be either unidirectional or bidirectional. In general, protection actions are completed within time frames amounting to tens of milliseconds, while automated restoration actions are normally completed within periods ranging from hundreds of milliseconds to a maximum of a few seconds. Restoration is not guaranteed (for example, because network resources may not be available at the time of the defect).
先制の優先順位を使用して、他のサービスの回復を可能にするために犠牲にされたサービスを決定することができます。復元は、単方向または双方向のいずれかです。一般に、保護措置は数十ミリ秒までの時間枠内で完了しますが、自動化された修復アクションは通常、数百ミリ秒から最大数秒までの期間内に完了します。修復は保証されていません（たとえば、欠陥の時点でネットワークリソースが利用できない場合があるため）。
The recovery schemes described in [RFC4427] and evaluated in [RFC4428] are presented in the context of control-plane-driven actions (such as the configuration of the protection entities and functions, etc.). The presence of a distributed control plane in an MPLS-TP network is optional. However, the absence of such a control plane does not affect the operation of the network and the use of MPLS-TP forwarding, Operations, Administration, and Maintenance (OAM), and survivability capabilities. In particular, the concepts
[RFC4427]で説明され、[RFC4428]で評価された回復スキームは、制御プレーン駆動型のアクション（保護エンティティや機能の構成など）のコンテキストで提示されます。MPLS-TPネットワーク内に分散制御プレーンの存在はオプションです。ただし、このような制御プレーンの存在は、ネットワークの動作と、MPLS-TP転送、運用、管理、およびメンテナンス（OAM）、および生存可能性能力の使用に影響しません。特に、概念
discussed in [RFC4427] and [RFC4428] refer to recovery actions effected in the data plane; they are equally applicable in MPLS-TP, with or without the use of a control plane.
[rfc4427]および[rfc4428]で説明されています。それらは、コントロールプレーンの使用の有無にかかわらず、MPLS-TPで等しく適用できます。
Thus, some of the MPLS-TP recovery mechanisms do not depend on a control plane and use MPLS-TP OAM mechanisms or management actions to trigger recovery actions.
したがって、MPLS-TP回復メカニズムの一部は制御プレーンに依存せず、MPLS-TP OAMメカニズムまたは管理アクションを使用して回復アクションをトリガーします。
The principles of MPLS-TP protection-switching actions are similar to those described in [RFC4427], since the protection mechanism is based on the capability to detect certain defects in the transport entities within the recovery domain. The protection-switching controller does not care which initiation method is used, provided that it can be given information about the status of the transport entities within the recovery domain (e.g., OK, signal failure, signal degradation, etc.).
保護メカニズムは回復ドメイン内の輸送エンティティ内の特定の欠陥を検出する能力に基づいているため、MPLS-TP保護スイッチングアクションの原理は[RFC4427]に記載されているものと類似しています。保護スイッチングコントローラーは、回復ドメイン内の輸送エンティティのステータスに関する情報（OK、信号障害、信号の劣化など）についての情報を提供できる限り、どの開始方法が使用されるかを気にしません。
In the context of MPLS-TP, it is imperative to ensure that performing switchovers is possible, regardless of the way in which the network is configured and managed (for example, regardless of whether a control-plane, management-plane, or OAM initiation mechanism is used).
MPLS-TPのコンテキストでは、ネットワークの構成と管理の方法に関係なく（たとえば、コントロールプレーン、管理プレーン、またはOAMの開始に関係なく、パフォーマンスのパフォーマンスが可能になることを保証することが不可欠です。メカニズムが使用されます）。
All MPLS and GMPLS protection mechanisms [RFC4428] are applicable in an MPLS-TP environment. It is also possible to provision and manage the related protection entities and functions defined in MPLS and GMPLS using the management plane [RFC5654]. Regardless of whether an OAM, management, or control plane initiation mechanism is used, the protection-switching operation is a data-plane operation.
すべてのMPLSおよびGMPLS保護メカニズム[RFC4428]は、MPLS-TP環境に適用されます。また、管理プレーン[RFC5654]を使用して、MPLSおよびGMPLSで定義されている関連する保護エンティティと機能を提供および管理することもできます。OAM、管理、または制御プレーンの開始メカニズムが使用されるかどうかに関係なく、保護スイッチング操作はデータプレーン操作です。
In some recovery schemes (such as bidirectional protection switching), it is necessary to coordinate the protection state between the edges of the recovery domain to achieve initiation of recovery actions for both directions. An MPLS-TP protocol may be used as an in-band (i.e., data-plane based) control protocol in order to coordinate the protection state between the edges of the protection domain. When the MPLS-TP control plane is in use, a control-plane-based mechanism can also be used to coordinate the protection states between the edges of the protection domain.
一部の回復スキーム（双方向保護スイッチングなど）では、回復ドメインのエッジ間の保護状態を調整して、両方向の回復アクションの開始を実現する必要があります。MPLS-TPプロトコルは、保護ドメインのエッジ間の保護状態を調整するために、インバンド（つまり、データプレーンベースの）制御プロトコルとして使用できます。MPLS-TPコントロールプレーンが使用されている場合、コントロールプレーンベースのメカニズムを使用して、保護ドメインのエッジ間の保護状態を調整することもできます。
An MPLS-TP Label Switched Path (LSP) may be subject to any part of or all of MPLS-TP link recovery, path-segment recovery, or end-to-end recovery, where:
MPLS-TPラベルスイッチ付きパス（LSP）は、MPLS-TPリンク回復、パスセグメントリカバリ、またはエンドツーエンドの回復の任意の部分またはすべての部分の対象となる場合があります。
o MPLS-TP link recovery refers to the recovery of an individual link (and hence all or a subset of the LSPs routed over the link) between two MPLS-TP nodes. For example, link recovery may be provided by server-layer recovery.
o MPLS-TPリンク回復とは、2つのMPLS-TPノード間の個々のリンク（したがって、リンクを介してルーティングされたLSPのすべてまたはサブセット）の回復を指します。たとえば、リンクの回復は、サーバー層の回復によって提供される場合があります。
o Segment recovery refers to the recovery of an LSP segment (i.e., segment and concatenated segment in the language of [RFC5654]) between two nodes and is used to recover from the failure of one or more links or nodes.
o セグメントの回復とは、2つのノード間のLSPセグメント（つまり、[RFC5654]の言語のセグメントと連結セグメント）の回復を指し、1つ以上のリンクまたはノードの故障から回復するために使用されます。
o End-to-end recovery refers to the recovery of an entire LSP, from its ingress to its egress node.
o エンドツーエンドの回復とは、侵入から出口ノードまでのLSP全体の回復を指します。
For additional resiliency, more than one of these recovery techniques may be configured concurrently for a single path.
追加の回復力のために、これらの回復手法の複数が単一のパスに対して同時に構成される場合があります。
Co-routed bidirectional MPLS-TP LSPs are defined in a way that allows both directions of the LSP to follow the same route through the network. In this scenario, the operator often requires the directions to fate-share (that is, if one direction fails, both directions should cease to operate).
協調的な双方向MPLS-TP LSPは、LSPの両方向がネットワークを介して同じルートをたどることができるように定義されています。このシナリオでは、オペレーターはしばしば運命の株の方向を必要とします（つまり、1つの方向が失敗した場合、両方方向が動作しなくなるはずです）。
Associated bidirectional MPLS-TP LSPs exist where the two directions of a bidirectional LSP follow different paths through the network. An operator may also request fate-sharing for associated bidirectional LSPs.
関連する双方向MPLS-TP LSPが存在し、双方向LSPの2つの方向がネットワークを介して異なる経路をたどります。オペレーターは、関連する双方向LSPの運命共有を要求することもできます。
The requirement for fate-sharing causes a direct interaction between the recovery processes affecting the two directions of an LSP, so that both directions of the bidirectional LSP are recovered at the same time. This mode of recovery is termed bidirectional recovery and may be seen as a consequence of fate-sharing.
運命共有の要件は、LSPの2つの方向に影響を与える回復プロセス間の直接的な相互作用を引き起こすため、双方向LSPの両方の方向が同時に回復されます。この回復モードは双方向回復と呼ばれ、運命共有の結果として見られる可能性があります。
The recovery scheme operating at the data-plane level can function in a multi-domain environment (in the wider sense of a "domain" [RFC4726]). It can also protect against a failure of a boundary node in the case of inter-domain operation. MPLS-TP recovery schemes are intended to protect client services when they are sent across the MPLS-TP network.
データプレーンレベルで動作する回復スキームは、マルチドメイン環境で機能する可能性があります（「ドメイン」[RFC4726]のより広い意味で）。また、ドメイン間操作の場合の境界ノードの障害から保護することもできます。MPLS-TP回復スキームは、MPLS-TPネットワーク全体で送信されるときにクライアントサービスを保護することを目的としています。
This framework introduces the architecture of the MPLS-TP recovery domain and describes the recovery schemes in MPLS-TP (based on the recovery types defined in [RFC4427]) as well as the principles of operation, recovery states, recovery triggers, and information exchanges between the different elements that support the reference model.
このフレームワークでは、MPLS-TP回復ドメインのアーキテクチャを紹介し、MPLS-TPの回復スキーム（[RFC4427]で定義されている回復タイプに基づく）と、運用の原則、回復状態、回復トリガー、情報交換について説明します。参照モデルをサポートするさまざまな要素間。
The framework also describes the qualitative grades of the survivability functions that can be provided, such as dedicated recovery, shared protection, restoration, etc. In the event of a network failure, the grade of recovery directly affects the service grade provided to the end-user.
フレームワークでは、専用の回復、共有保護、回復など、提供できる生存可能性関数の定性グレードも説明します。ネットワーク障害が発生した場合、回復のグレードは、終了まで提供されるサービスグレードに直接影響します。ユーザー。
The general description of the functional architecture is applicable to both LSPs and pseudowires (PWs); however, PW recovery is only introduced in Section 7, and the relevant details are beyond the scope of this document and are for further study.
機能アーキテクチャの一般的な説明は、LSPと擬似動物の両方に適用できます（PWS）。ただし、PWの回復はセクション7でのみ導入されており、関連する詳細はこのドキュメントの範囲を超えており、さらなる研究のためです。
This framework applies to general recovery schemes as well as to mechanisms that are optimized for specific topologies and are tailored to efficiently handle protection switching.
このフレームワークは、一般的な回復スキームと、特定のトポロジに最適化され、保護スイッチングを効率的に処理するように調整されたメカニズムに適用されます。
This document addresses the need for the coordination of protection switching across multiple layers and at sub-layers (for clarity, we use the term "layer" to refer equally to layers and sub-layers). This allows an operator to prevent race conditions and allows the protection-switching mechanism of one layer to recover from a failure before switching is invoked at another layer.
このドキュメントでは、複数の層とサブ層での保護スイッチングの調整の必要性に対応しています（明確にするために、「レイヤー」という用語を使用して、レイヤーとサブ層を等しく参照します）。これにより、オペレーターは人種条件を防ぐことができ、1つの層の保護機構が、切り替えが別の層で呼び出される前に障害から回復できるようにします。
This framework also specifies the functions that must be supported by MPLS-TP to provide the recovery mechanisms. MPLS-TP introduces a tool kit to enable recovery in MPLS-TP-based networks and to ensure that affected services are recovered in the event of a failure.
このフレームワークは、回復メカニズムを提供するためにMPLS-TPでサポートする必要がある関数も指定します。MPLS-TPは、MPLS-TPベースのネットワークの回復を可能にし、障害が発生した場合に影響を受けるサービスが回復することを確認するためのツールキットを導入します。
Generally, network operators aim to provide the fastest, most stable, and best protection mechanism at a reasonable cost in accordance with customer requirements. The greater the grade of protection required, the greater the number of resources will be consumed. It is therefore expected that network operators will offer a wide spectrum of service grade. MPLS-TP-based recovery offers the flexibility to select a recovery mechanism, define the granularity at which traffic delivery is to be protected, and choose the specific traffic types that are to be protected. With MPLS-TP-based recovery, it should be possible to provide different grades of protection for different traffic classes within the same path based on the service requirements.
一般的に、ネットワークオペレーターは、顧客の要件に従って、最速で最も安定した最高の保護メカニズムを合理的なコストで提供することを目指しています。必要な保護の勾配が大きいほど、リソースの数が増えます。したがって、ネットワークオペレーターは幅広いサービスグレードを提供することが期待されています。MPLS-TPベースのリカバリは、回復メカニズムを選択する柔軟性を提供し、交通配信が保護される粒度を定義し、保護される特定のトラフィックタイプを選択します。MPLS-TPベースの回復により、サービス要件に基づいて同じパス内で異なるトラフィッククラスにさまざまなグレードの保護を提供できるはずです。
The terminology used in this document is consistent with that defined in [RFC4427]. The latter is consistent with [G.808.1].
このドキュメントで使用されている用語は、[RFC4427]で定義されているものと一致しています。後者は[G.808.1]と一致しています。
However, certain protection concepts (such as ring protection) are not discussed in [RFC4427]; for those concepts, the terminology used in this document is drawn from [G.841].
ただし、特定の保護概念（リング保護など）は[RFC4427]で説明されていません。これらの概念については、このドキュメントで使用される用語は[G.841]から描かれています。
Readers should refer to those documents for normative definitions.
読者は、規範的な定義については、これらのドキュメントを参照する必要があります。
This document supplies brief summaries of a number of terms for reasons of clarity and to assist the reader, but it does not redefine terms.
このドキュメントは、明確さの理由と読者を支援するために、いくつかの用語の簡単な要約を提供しますが、条件を再定義しません。
Note, in particular, the distinction and definitions made in [RFC4427] for the following three terms:
特に、次の3つの用語について[RFC4427]で作成された区別と定義に注意してください。
o Protection: re-establishing end-to-end traffic delivery using pre-allocated resources.
o 保護：事前に割り当てられたリソースを使用したエンドツーエンドのトラフィック配信を再確立します。
o Restoration: re-establishing end-to-end traffic delivery using resources allocated at the time of need; sometimes referred to as "repair" of a service, LSP, or the traffic.
o 復元：必要に応じて割り当てられたリソースを使用したエンドツーエンドのトラフィック配信を再確立します。サービス、LSP、またはトラフィックの「修理」と呼ばれることもあります。
o Recovery: a generic term covering both Protection and Restoration.
o 回復：保護と回復の両方をカバーする一般的な用語。
Note that the term "survivability" is used in [RFC5654] to cover the functional elements of "protection" and "restoration", which are collectively known as "recovery".
「生存可能性」という用語は、[RFC5654]で使用されて、「回復」として集合的に知られている「保護」と「修復」の機能要素をカバーすることに注意してください。
Important background information on survivability can be found in [RFC3386], [RFC3469], [RFC4426], [RFC4427], and [RFC4428].
生存可能性に関する重要な背景情報は、[RFC3386]、[RFC3469]、[RFC4426]、[RFC4427]、および[RFC4428]に記載されています。
In this document, the following additional terminology is applied:
このドキュメントでは、次の追加用語が適用されます。
o "Fault Management", as defined in [RFC5950].
o [RFC5950]で定義されている「障害管理」。
o The terms "defect" and "failure" are used interchangeably to indicate any defect or failure in the sense that they are defined in [G.806]. The terms also include any signal degradation event as defined in [G.806].
o 「欠陥」と「障害」という用語は、[G.806]で定義されているという意味での欠陥または障害を示すために互換性があります。この用語には、[G.806]で定義されている信号分解イベントも含まれます。
o A "fault" is a fault or fault cause as defined in [G.806].
o 「障害」は、[G.806]で定義されている障害または障害の原因です。
o "Trigger" indicates any event that may initiate a recovery action. See Section 4.1 for a more detailed discussion of triggers.
o 「トリガー」は、回復アクションを開始する可能性のあるイベントを示します。トリガーの詳細については、セクション4.1を参照してください。
o The acronym "OAM" is defined as Operations, Administration, and Maintenance, consistent with [RFC6291].
o 「OAM」という頭字語は、[RFC6291]と一致して、運用、管理、およびメンテナンスとして定義されます。
o A "Transport Entity" is a node, link, transport path segment, concatenated transport path segment, or entire transport path.
o 「輸送エンティティ」は、ノード、リンク、輸送パスセグメント、連結された輸送パスセグメント、または輸送パス全体です。
o A "Working Entity" is a transport entity that carries traffic during normal network operation.
o 「ワーキングエンティティ」とは、通常のネットワーク操作中にトラフィックを運ぶ輸送エンティティです。
o A "Protection Entity" is a transport entity that is pre-allocated and used to protect and transport traffic when the working entity fails.
o 「保護エンティティ」とは、作業エンティティが故障したときにトラフィックを保護および輸送するために事前に割り当てられ、使用される輸送エンティティです。
o A "Recovery Entity" is a transport entity that is used to recover and transport traffic when the working entity fails.
o 「回復エンティティ」とは、作業エンティティが失敗したときにトラフィックを回復および輸送するために使用される輸送エンティティです。
o "Survivability Actions" are the steps that may be taken by network nodes to communicate faults and to switch traffic from faulted or degraded paths to other paths. This may include sending messages and establishing new paths.
o 「生存性アクション」とは、ネットワークノードが障害を通信し、トラフィックを障害または劣化したパスから他のパスに切り替えるための手順です。これには、メッセージの送信と新しいパスの確立が含まれます。
General terminology for MPLS-TP is found in [RFC5921] and [ROSETTA]. Background information on MPLS-TP requirements can be found in [RFC5654].
MPLS-TPの一般用語は、[RFC5921]および[Rosetta]にあります。MPLS-TP要件に関する背景情報は、[RFC5654]に記載されています。
MPLS-TP requirements are presented in [RFC5654] and serve as normative references for the definition of all MPLS-TP functionality, including survivability. Survivability is presented in [RFC5654] as playing a critical role in the delivery of reliable services, and the requirements for survivability are set out using the recovery terminology defined in [RFC4427].
MPLS-TP要件は[RFC5654]で提示され、生存可能性を含むすべてのMPLS-TP機能の定義の規範的参照として機能します。生存性は[RFC5654]で信頼できるサービスの提供に重要な役割を果たすものとして提示されており、生存可能性の要件は[RFC4427]で定義された回復用語を使用して定められています。
This section presents an overview of the elements relating to the functional architecture for survivability within an MPLS-TP network. The components are presented separately to demonstrate the way in which they may be combined to provide the different grades of recovery needed to meet the requirements set out in the previous section.
このセクションでは、MPLS-TPネットワーク内での生存性に関する機能アーキテクチャに関連する要素の概要を示します。コンポーネントは個別に提示され、前のセクションで定められた要件を満たすために必要なさまざまな勾配の回復グレードを提供するための方法を実証する方法を実証します。
Recovery is achieved by implementing specific actions. These actions aim to repair network resources or redirect traffic along paths that avoid failures in the network. They may be triggered automatically by the MPLS-TP network nodes upon detection of a network defect, or they may be triggered by an operator. Automated actions may be enhanced by in-band (i.e., data-plane-based) OAM mechanisms, or by in-band or out-of-band control-plane signaling.
特定のアクションを実装することにより、回復が達成されます。これらのアクションは、ネットワークリソースを修復するか、ネットワークの障害を回避するパスに沿ったトラフィックをリダイレクトすることを目的としています。ネットワーク欠陥の検出時にMPLS-TPネットワークノードによって自動的にトリガーされる場合があります。または、オペレーターによってトリガーされる場合があります。自動化されたアクションは、インバンド（つまり、データプレーンベースの）OAMメカニズム、またはインバンドまたはバンド外のコントロールプレーンシグナリングによって強化される場合があります。
The survivability behavior of the network as a whole, and the reaction of each transport path when a fault is reported, may be controlled by the operator. This control can be split into two sets of functions: policies and actions performed when the transport path is set up, and commands used to control or force recovery actions for established transport paths.
ネットワーク全体の生存可能性の動作、および障害が報告された場合の各輸送経路の反応は、オペレーターによって制御される場合があります。このコントロールは、輸送パスが設定されたときに実行されるポリシーとアクションの2つの機能に分割でき、確立された輸送パスの回復アクションを制御または強制するために使用されるコマンドです。
The operator may establish network-wide or local policies that determine the actions that will be taken when various defects are reported that affect different transport paths. Also, when a service request is made that causes the establishment of one or more transport paths in the network, the operator (or requesting application) may define a particular grade of service, and this will be mapped to specific survivability actions taken before and during transport path setup, after the discovery of a failure of network resources, and upon recovery of those resources.
オペレーターは、異なる輸送経路に影響を与えるさまざまな欠陥が報告されたときにとられるアクションを決定するネットワーク全体またはローカルポリシーを確立することができます。また、ネットワーク内の1つ以上の輸送パスの確立を引き起こすサービスリクエストが作成されると、オペレーター（またはアプリケーションを要求）が特定のグレードのサービスを定義する場合があり、これは前後に取られた特定の生存可能性アクションにマッピングされます。ネットワークリソースの障害の発見後、およびそれらのリソースの回復時に、パスのセットアップを輸送します。
It should be noted that it is unusual to present a user or customer with options directly related to recovery actions. Instead, the user/customer enters into an SLA with the network provider, and the network operator maps the terms of the SLA (for example, for guaranteed delivery, availability, or reliability) to recovery schemes within the network.
ユーザーまたは顧客に回復アクションに直接関連するオプションを提示することは珍しいことに注意する必要があります。代わりに、ユーザー/顧客はネットワークプロバイダーでSLAに入り、ネットワークオペレーターは、ネットワーク内の回復スキームにSLAの条件（たとえば、配信、可用性、信頼性の保証など）をマッピングします。
The operator can also issue commands to control recovery actions and events. For example, the operator may perform the following actions:
オペレーターは、復旧アクションとイベントを制御するコマンドを発行することもできます。たとえば、オペレーターは次のアクションを実行できます。
o Enable or disable the survivability function.
o 生存可能性関数を有効または無効にします。
o Invoke the simulation of a network fault.
o ネットワーク障害のシミュレーションを呼び出します。
o Force a switchover from a working path to a recovery path or vice versa.
o 作業経路から回復パスへのスイッチオーバー、またはその逆を強制します。
Forced switchover may be performed for network optimization purposes with minimal service interruption, such as when modifying protected or unprotected services, when replacing MPLS-TP network nodes, etc. In some circumstances, a fault may be reported to the operator, and the operator may then select and initiate the appropriate recovery action. A description of the different operator commands is found in Section 4.12 of [RFC4427].
強制スイッチオーバーは、保護または保護されていないサービスを変更した場合、MPLS-TPネットワークノードを交換するときなど、最小限のサービス中断でネットワーク最適化の目的で実行できます。状況によっては、オペレーターに障害が報告される場合があり、オペレーターは障害を報告する場合があります。次に、適切な回復アクションを選択して開始します。異なる演算子コマンドの説明は、[RFC4427]のセクション4.12に記載されています。
Survivability actions may be directly triggered by network defects. This means that the device that detects the defect (for example, notification of an issue reported from equipment in a lower layer, failure to receive an OAM Continuity message, or receipt of an OAM message reporting a failure condition) may immediately perform a survivability action.
生存可能性アクションは、ネットワークの欠陥によって直接トリガーされる場合があります。これは、欠陥を検出するデバイス（たとえば、下層の機器から報告された問題の通知、OAM連続性メッセージの受信の失敗、または故障条件を報告するOAMメッセージの受信）がすぐに生存可能性のアクションを実行できることを意味します。。
The action is directly triggered by events in the data plane. Note, however, that coordination of recovery actions between the edges of the recovery domain may require message exchanges for some recovery functions or for performing a bidirectional recovery action.
アクションは、データプレーン内のイベントによって直接トリガーされます。ただし、回復ドメインのエッジ間の回復アクションの調整は、いくつかの回復関数または双方向回復アクションの実行にメッセージ交換が必要になる場合があることに注意してください。
OAM signaling refers to data-plane OAM message exchange. Such messages may be used to detect and localize faults or to indicate a degradation in the operation of the network. However, in this context these messages are used to control or trigger survivability actions. The mechanisms to achieve this are discussed in [RFC6371].
OAMシグナリングとは、データプレーンOAMメッセージ交換を指します。このようなメッセージは、障害を検出およびローカライズするため、またはネットワークの動作における劣化を示すために使用できます。ただし、この文脈では、これらのメッセージは、生存可能性アクションを制御またはトリガーするために使用されます。これを達成するメカニズムは[RFC6371]で説明されています。
OAM signaling may also be used to coordinate recovery actions within the protection domain.
OAMシグナル伝達は、保護ドメイン内の回復アクションを調整するためにも使用できます。
Control-plane signaling is responsible for setup, maintenance, and teardown of transport paths that do not fall under management-plane control. The control plane may also be used to coordinate the detection, localization, and reaction to network defects pertaining to peer relationships (neighbor-to-neighbor or end-to-end). Thus, control-plane signaling may initiate and coordinate survivability actions.
コントロールプレーンシグナル伝達は、管理面の制御に該当しない輸送経路のセットアップ、メンテナンス、および分裂を担当します。コントロールプレーンは、ピア関係（隣人から隣人またはエンドツーエンド）に関連するネットワーク欠陥に対する検出、ローカリゼーション、および反応を調整するためにも使用できます。したがって、コントロールプレーンシグナル伝達は、生存可能性アクションを開始および調整する場合があります。
The control plane can also be used to distribute topology and information relating to resource availability. In this way, the "graceful shutdown" [RFC5817] of resources may be affected by withdrawing them; this can be used to invoke a survivability action in a similar way to that used when reporting or discovering a fault, as described in the previous sections.
コントロールプレーンは、リソースの可用性に関するトポロジと情報を配布するためにも使用できます。このようにして、リソースの「優雅なシャットダウン」[RFC5817]は、それらを撤回することで影響を受ける可能性があります。これは、前のセクションで説明されているように、障害を報告または発見するときに使用されるものと同様の方法で生存可能性アクションを呼び出すために使用できます。
The use of a control plane for MPLS-TP is discussed in [RFC6373].
MPLS-TPのコントロールプレーンの使用については、[RFC6373]で説明しています。
This section describes the elements of recovery. These are the quantitative aspects of recovery, that is, the parts of the network for which recovery can be provided.
このセクションでは、回復の要素について説明します。これらは、回復の定量的側面、つまり回復が提供できるネットワークの部分です。
Note that the terminology in this section is consistent with [RFC4427]. Where the terms differ from those in [RFC5654], mapping is provided.
このセクションの用語は[RFC4427]と一致していることに注意してください。[RFC5654]の用語とは異なる場合、マッピングが提供されます。
A span is a single hop between neighboring MPLS-TP nodes in the same network layer. A span is sometimes referred to as a link, and this may cause some confusion between the concept of a data link and a traffic engineering (TE) link. LSPs traverse TE links between neighboring MPLS-TP nodes in the MPLS-TP network layer. However, a TE link may be provided by any of the following:
スパンは、同じネットワークレイヤーの隣接するMPLS-TPノード間の単一ホップです。スパンはリンクと呼ばれることがあり、これにより、データリンクの概念とトラフィックエンジニアリング（TE）リンクの間にある程度の混乱が生じる可能性があります。MPLS-TPネットワークレイヤーの隣接するMPLS-TPノード間のLSPSトラバースTEリンク。ただし、次のいずれかでTEリンクを提供できます。
o A single data link.
o 単一のデータリンク。
o A series of data links in a lower layer, established as an LSP and presented to the upper layer as a single TE link.
o LSPとして確立され、単一のTEリンクとして上層に提示された下層の一連のデータリンク。
o A set of parallel data links in the same layer, presented either as a bundle of TE links, or as a collection of data links that together provide a data-link-layer protection scheme.
o 同じレイヤーの一連の並列データリンクは、TEリンクのバンドルとして提示され、データリンクレイヤー保護スキームを提供するデータリンクのコレクションとして表示されます。
Thus, span recovery may be provided by any of the following:
したがって、スパンの回復は、次のいずれかによって提供される場合があります。
o Selecting a different TE link from a bundle.
o バンドルから別のTEリンクを選択します。
o Moving the TE link so that it is supported by a different data link between the same pair of neighbors.
o TEリンクを移動して、同じ近隣のペア間の異なるデータリンクによってサポートされます。
o Rerouting the LSP in the lower layer.
o 下層のLSPを再ルーティングします。
Moving the protected LSP to another TE link between the same pair of neighbors is a form of segment recovery and not a form of span recovery. Segment Recovery is described in Section 4.2.2.
保護されたLSPを同じ近隣のペア間の別のTEリンクに移動することは、スパンリカバリの形ではなく、セグメント回復の形式です。セグメントの回復については、セクション4.2.2で説明します。
An LSP segment comprises one or more continuous hops on the path of the LSP. [RFC5654] defines two terms. A "segment" is a single hop along the path of an LSP, while a "concatenated segment" is more than one hop along the path of an LSP. In the context of this document, a segment covers both of these concepts.
LSPセグメントは、LSPのパス上の1つ以上の連続ホップを含む。[RFC5654]は2つの用語を定義します。「セグメント」はLSPのパスに沿った単一のホップであり、「連結セグメント」はLSPのパスに沿って複数のホップです。このドキュメントのコンテキストでは、セグメントはこれらの両方の概念をカバーしています。
A PW segment refers to a Single-Segment PW (SS-PW) or to a single segment of a Multi-Segment PW (MS-PW) that is set up between two PE devices that may be Terminating PEs (T-PEs) or Switching PEs (S-PEs) so that the full set of possibilities is T-PE to S-PE, S-PE to S-PE, S-PE to T-PE, or T-PE to T-PE (for the SS-PW case). As indicated in Section 1, the recovery of PWs and PW segments is beyond the scope of this document; however, see Section 7.
PWセグメントとは、単一セグメントPW（SS-PW）またはPES（T-PES）または終了する可能性のある2つのPEデバイスの間にセットアップされるマルチセグメントPW（MS-PW）の単一セグメントを指します。PES（S-PES）を切り替えて、可能性の完全なセットがT-PEからS-PE、S-PEからS-PE、S-PEからT-PE、またはT-PEからT-PEになるようにSS-PWケース）。セクション1に示されているように、PWSおよびPWセグメントの回復はこのドキュメントの範囲を超えています。ただし、セクション7を参照してください。
Segment recovery involves redirecting or copying traffic at the source end of a segment onto an alternate path leading to the other end of the segment. According to the required grade of recovery (described in Section 4.3), traffic may be either redirected to a pre-established segment, through rerouting the protected segment, or tunneled to the far end of the protected segment through a "bypass" LSP. For details on recovery mechanisms, see Section 4.4.
セグメントの回復には、セグメントのソースエンドでトラフィックをリダイレクトまたはコピーして、セグメントのもう一方の端に通じる代替パスへのコピーが含まれます。必要なグレードの回復（セクション4.3で説明）によると、トラフィックは、保護されたセグメントを再ルーティングすることにより、事前に確立されたセグメントにリダイレクトされるか、「バイパス」LSPを介して保護されたセグメントの遠端にトンネルされている場合があります。回復メカニズムの詳細については、セクション4.4を参照してください。
Note that protecting a transport path against node failure requires the use of segment recovery or end-to-end recovery, while a link failure can be protected using span, segment, or end-to-end recovery.
ノード障害に対する輸送経路を保護するには、セグメントの回復またはエンドツーエンドの回復の使用が必要であり、スパン、セグメント、またはエンドツーエンドの回復を使用してリンク障害を保護できることに注意してください。
End-to-end recovery is a special case of segment recovery where the protected segment comprises the entire transport path. End-to-end recovery may be provided as link-diverse or node-diverse recovery where the recovery path shares no links or no nodes with the working path.
エンドツーエンドの回復は、保護されたセグメントが輸送パス全体を構成するセグメント回復の特別なケースです。エンドツーエンドの回復は、回復パスが作業パスとリンクまたはノードを共有しない場合、リンクダイバーまたはノードダイバーリカバリとして提供される場合があります。
Note that node-diverse paths are necessarily link-diverse and that full, end-to-end node-diversity is required to guarantee recovery.
ノードダイバーパスは必然的にリンクダイバースであり、回復を保証するために完全なエンドツーエンドのノード型型が必要であることに注意してください。
Two observations need to be made about end-to-end recovery.
エンドツーエンドの回復について2つの観察を行う必要があります。
- Firstly, there may be circumstances where node-diverse end-to-end paths do not guarantee recovery. The ingress and egress nodes will themselves be single points of failure. Additionally, there may be shared risks of failure (for example, geographic collocation, shared resources, etc.) between diverse nodes as described in Section 4.9.2.
- 第一に、ノードダイバーエンドツーエンドパスが回復を保証しない状況があるかもしれません。イングレスノードと出口ノード自体は、単一の障害点になります。さらに、セクション4.9.2で説明されているように、多様なノード間で、障害のリスクが共有される場合があります（たとえば、地理的コロケーション、共有リソースなど）。
- Secondly, it is possible to use end-to-end recovery techniques even when there is not full diversity and the working and protection paths share links or nodes.
- 第二に、完全な多様性がなく、作業および保護パスがリンクまたはノードを共有している場合でも、エンドツーエンドの回復技術を使用することができます。
This section describes the qualitative grades of survivability that can be provided. In the event of a network failure, the grade of recovery offered directly affects the service grade provided to the end-user. This will be observed as the amount of data lost when a network fault occurs, and the length of time required to recover connectivity.
このセクションでは、提供できる生存可能性の定性的グレードについて説明します。ネットワークの障害が発生した場合、提供されるリカバリのグレードは、エンドユーザーに提供されるサービスグレードに直接影響します。これは、ネットワーク障害が発生したときに失われたデータの量、および接続性の回復に必要な時間の長さとして観察されます。
In general, there is a correlation between the recovery service grade (i.e., the speed of recovery and reduction of data loss) and the amount of resources used in the network; better service grades require the pre-allocation of resources to the recovery paths, and those resources cannot be used for other purposes if high-quality recovery is required. An operator will consider how providing different grades of recovery may require that network resources be provisioned and allocated for exclusive use of the recovery paths such that the resources cannot be used to support other customer services.
一般に、回復サービスグレード（つまり、回収速度とデータ損失の削減）とネットワークで使用されるリソースの量との間には相関関係があります。より良いサービスグレードでは、回復パスへのリソースの事前配分が必要であり、高品質の回復が必要な場合、それらのリソースは他の目的に使用することはできません。オペレーターは、さまざまなグレードのリカバリを提供することで、ネットワークリソースをプロビジョニングし、リカバリパスを排他的に使用するために割り当てられるようにする方法を検討します。
Sections 6 and 7 of [RFC4427] provide a full breakdown of the protection and recovery schemes. This section summarizes the qualitative grades available.
[RFC4427]のセクション6および7は、保護および回復スキームの完全な内訳を提供します。このセクションでは、利用可能な定性グレードをまとめます。
Note that, in the context of recovery, a useful discussion of the term "resource" and its interpretation in both the IETF and ITU-T contexts may be found in Section 3.2 of [RFC4397].
回復のコンテキストでは、「リソース」という用語の有用な議論とIETFとITU-Tの両方のコンテキストでのその解釈の有用な議論は、[RFC4397]のセクション3.2に記載されている可能性があることに注意してください。
The selection of the recovery grade and schemes to satisfy the service grades for an LSP using available network resources is subject to network and local policy and may be pre-designated through network planning or may be dynamically determined by the network.
利用可能なネットワークリソースを使用してLSPのサービスグレードを満たすための回復グレードとスキームの選択は、ネットワークおよびローカルポリシーの対象であり、ネットワーク計画を通じて事前に指定されるか、ネットワークによって動的に決定される場合があります。
In dedicated protection, the resources for the recovery entity are pre-assigned for the sole use of the protected transport path. This will clearly be the case in 1+1 protection, and may also be the case in 1:1 protection where extra traffic (see Section 4.3.3) is not supported.
専用の保護において、回復エンティティのリソースは、保護された輸送パスの唯一の使用のために事前に割り当てられています。これは明らかに1 1の保護の場合であり、追加のトラフィック（セクション4.3.3を参照）がサポートされていない1：1の保護の場合でもそうかもしれません。
Note that when using protection tunnels (see Section 4.4.3), resources may also be dedicated to the protection of a specific transport path. In some cases (1:1 protection), the entire bypass tunnel may be dedicated to providing recovery for a specific transport path, while in other cases (such as facility backup), a subset of the resources associated with the bypass tunnel may be pre-assigned for the recovery of a specific service.
保護トンネルを使用する場合（セクション4.4.3を参照）、リソースは特定の輸送経路の保護にも捧げられる可能性があることに注意してください。場合によっては（1：1の保護）、バイパストンネル全体が特定の輸送経路の回復を提供することに専念することがありますが、他の場合（施設のバックアップなど）、バイパストンネルに関連するリソースのサブセットはpreである場合があります。 - 特定のサービスの回復のために割り当てられます。
However, as described in Section 4.4.3, the bypass tunnel method can also be used for shared protection (Section 4.3.2), either to carry extra traffic (Section 4.3.3) or to achieve best-effort recovery without the need for resource reservation.
ただし、セクション4.4.3で説明したように、バイパストンネル法は、共有保護（セクション4.3.2）にも使用できます。リソース予約。
In shared protection, the resources for the recovery entities of several services are shared. These may be shared as 1:n or m:n and are shared on individual links. Link-by-link resource sharing may be managed and operated along LSP segments, on PW segments, or on end-to-end transport paths (LSP or PW). Note that there is no requirement for m:n recovery in the list of MPLS-TP requirements documented in [RFC5654]. Shared protection can be applied in different topologies (mesh, ring, etc.) and can utilize different protection mechanisms (linear, ring, etc.).
共有保護では、いくつかのサービスの回復エンティティのリソースが共有されます。これらは1：nまたはm：nとして共有され、個々のリンクで共有されます。リンクごとのリソース共有は、LSPセグメント、PWセグメント、またはエンドツーエンドの輸送パス（LSPまたはPW）に沿って管理および操作できます。[RFC5654]に文書化されたMPLS-TP要件のリストには、M：N回復の要件がないことに注意してください。共有保護は、さまざまなトポロジ（メッシュ、リングなど）に適用でき、さまざまな保護メカニズム（線形、リングなど）を利用できます。
End-to-end shared protection shares resources between a number of paths that have common end points. Thus, a number of paths (n paths) are all protected by one or more protection paths (m paths, where m may equal 1). When there have been m failures, there are no more available protection paths, and the n paths are no longer protected. Thus, in 1:n protection, one fault can be protected against before all the n paths are unprotected. The fact that the paths have become unprotected needs to be conveyed to the path end points since they may need to report the change in service grade or may need to take further action to increase their protection. In end-to-end shared protection, this communication is simple since the end points are common.
エンドツーエンドの共有保護は、共通のエンドポイントを持つ多くのパス間でリソースを共有します。したがって、多くのパス（nパス）はすべて1つ以上の保護パス（mパス、mでは1に等しい場合があります）によって保護されています。M障害が発生した場合、利用可能な保護パスはもうありません。Nパスはもはや保護されていません。したがって、1：n保護では、すべてのnパスが保護されていない前に、1つの障害を保護できます。パスが保護されていないという事実は、サービスグレードの変更を報告する必要があるか、保護を増やすためにさらなる行動をとる必要がある可能性があるため、パスエンドポイントに伝える必要があります。エンドツーエンドの共有保護では、エンドポイントが一般的であるため、この通信は簡単です。
In shared mesh protection (see Section 4.7.6), the paths that share the protection resources do not necessarily have the same end points. This provides a more flexible resource-sharing scheme, but the network planning and the coordination of protection state after a recovery action are more complex.
共有メッシュ保護（セクション4.7.6を参照）では、保護リソースを共有するパスには必ずしも同じエンドポイントがありません。これにより、より柔軟なリソース共有スキームが提供されますが、回復アクション後のネットワーク計画と保護状態の調整はより複雑です。
Where a bypass tunnel is used (Section 4.4.3), the tunnel might not have sufficient resources to simultaneously protect all of the paths for which it offers protection; in the event that all paths were affected by network defects and failures at the same time, not all of them would be recovered. Policy would dictate how this situation should be handled: some paths might be protected, while others would simply fail; the traffic for some paths would be guaranteed, while traffic on other paths would be treated as best-effort with the risk of dropped packets. Alternatively, it is possible that protection would not be attempted according to local policy at the nodes that perform the recovery actions.
バイパストンネルが使用されている場合（セクション4.4.3）、トンネルには、保護を提供するすべてのパスを同時に保護するのに十分なリソースがない場合があります。すべてのパスがネットワークの欠陥と障害の影響を同時に受けた場合、それらのすべてが回復するわけではありません。ポリシーは、この状況をどのように処理するかを決定します。一部のパスは保護されている可能性がありますが、他のパスは単に失敗する可能性があります。一部のパスのトラフィックは保証されますが、他のパス上のトラフィックは、パケットを落とすリスクとともに最良のエフォートとして扱われます。あるいは、回復アクションを実行するノードのローカルポリシーに従って保護が試みられない可能性があります。
Shared protection is a trade-off between assigning network resources to protection (which is not required most of the time) and risking unrecoverable services in the event that multiple network defects or failures occur. Rapid recovery can be achieved with dedicated protection, but it is delayed by message exchanges in the management, control, or data planes for shared protection. This means that there is also a trade-off between rapid recovery and resource sharing. In some cases, shared protection might not meet the speed required for protection, but it may still be faster than restoration.
共有保護は、複数のネットワークの欠陥または障害が発生した場合に、ネットワークリソースを保護に割り当てること（ほとんどの場合必須ではない）と回復不可能なサービスを危険にさらすこととのトレードオフです。専用の保護で迅速な回復を達成できますが、共有保護のために管理、制御、またはデータプレーンのメッセージ交換によって遅れます。これは、迅速な回復とリソース共有の間にトレードオフもあることを意味します。場合によっては、共有保護が保護に必要な速度を満たしていない場合がありますが、回復よりも速い場合があります。
These trade-offs may be somewhat mitigated by the following:
これらのトレードオフは、以下によってやや緩和される場合があります。
o Adjusting the value of n in 1:n protection.
o 1：n保護でnの値を調整します。
o Using m:n protection for a value of m > 1.
o M：nの値を使用して、m> 1の値を保護します。
o Establishing new protection paths as each available protection path is put into use.
o 利用可能な各保護パスが使用されるときに新しい保護パスを確立します。
In an MPLS-TP network, the degree to which a resource is shared between LSPs is a policy issue. This policy may be applied to the resource or to the LSPs, and may be pre-configured, configured per LSP and installed during LSP establishment, or may be dynamically configured.
MPLS-TPネットワークでは、LSP間でリソースが共有される程度はポリシーの問題です。このポリシーは、リソースまたはLSPに適用される場合があり、事前に構成され、LSPごとに構成され、LSPの確立中にインストールされるか、動的に構成される場合があります。
Section 2.5.1.1 of [RFC5654] says: "Support for extra traffic (as defined in [RFC4427]) is not required in MPLS-TP and MAY be omitted from the MPLS-TP specifications". This document observes that extra traffic facilities may therefore be provided as part of the MPLS-TP survivability toolkit depending upon the development of suitable solution specifications. The remainder of this section explains the concepts of extra traffic without prejudging the decision to specify or not specify such solutions.
[RFC5654]のセクション2.5.1.1は次のように述べています。「[RFC4427]で定義されている余分なトラフィックのサポートは、MPLS-TPでは必要ありません。MPLS-TP仕様から省略できます」。したがって、このドキュメントは、適切なソリューション仕様の開発に応じて、MPLS-TP Survivability Toolkitの一部として追加の交通施設が提供される可能性があることを観察しています。このセクションの残りの部分では、そのようなソリューションを指定または指定しないという決定を事前に訴えることなく、余分なトラフィックの概念を説明します。
Network resources allocated for protection represent idle capacity during the time that recovery is not actually required, and can be utilized by carrying other traffic, referred to as "extra traffic".
保護のために割り当てられたネットワークリソースは、回復が実際には不要ではなく、「余分なトラフィック」と呼ばれる他のトラフィックを運ぶことで利用できます。
Note that extra traffic does not need to start or terminate at the ends of the entity (e.g., LSP) that it uses.
追加のトラフィックは、使用するエンティティ（例：LSP）の終わりで開始または終了する必要がないことに注意してください。
When a network resource carrying extra traffic is required for the recovery of protected traffic from the failed working path, the extra traffic is disrupted. This disruption make take one of two forms:
失敗した作業経路から保護されたトラフィックの回復に追加のトラフィックを運ぶネットワークリソースが必要な場合、追加のトラフィックは破壊されます。この混乱により、2つの形式のいずれかを取得します。
- In "hard preemption", the extra traffic is excluded from the protection resource. The disruption of the extra traffic is total, and the service supported by the extra traffic must be dropped, or some form of rerouting or restoration must be applied to the extra traffic LSP in order to recover the service.
- 「ハードプリエンプション」では、追加のトラフィックは保護リソースから除外されます。余分なトラフィックの混乱は合計であり、追加のトラフィックによってサポートされているサービスを落とす必要があります。または、サービスを回復するために、追加のトラフィックLSPに何らかの形の再ルーティングまたは修復を適用する必要があります。
Hard preemption is achieved by "setting a switch" on the path of the extra traffic such that it no longer flows. This situation may be detected by OAM and reported as a fault, or may be proactively reported through OAM or control-plane signaling.
ハードプリエンプションは、余分なトラフィックのパスに「スイッチを設定する」ことで達成され、流れないようになります。この状況はOAMによって検出され、障害として報告されるか、OAMまたはコントロールプレーンシグナル伝達を介して積極的に報告される場合があります。
- In "soft preemption", the extra traffic is not explicitly excluded from the protection resource, but is given lower priority than the protected traffic. In a packet network (such as MPLS-TP), this can result in oversubscription of the protection resource with the result that the extra traffic receives "best-effort" delivery. Depending on the volume of protection and extra traffic, and the level of oversubscription, the extra traffic may be slightly or heavily impacted.
- 「ソフトプリエンプション」では、追加のトラフィックは保護リソースから明示的に除外されていませんが、保護されたトラフィックよりも優先度が低くなります。パケットネットワーク（MPLS-TPなど）では、保護リソースのオーバーサブスクリプションに伴い、追加のトラフィックが「ベストエフォルト」配信を受信することになります。保護の量と余分なトラフィックの量、およびオーバーサブスクリプションのレベルに応じて、余分なトラフィックがわずかまたは多大な影響を受ける可能性があります。
The event of soft preemption may be detected by OAM and reported as a degradation of traffic delivery or as a fault. It may also be proactively reported through OAM or control-plane signaling.
ソフトプリエンプションのイベントは、OAMによって検出され、交通配信の劣化または障害として報告される場合があります。また、OAMまたはコントロールプレーンシグナル伝達を通じて積極的に報告される場合があります。
Note that both hard and soft preemption may utilize additional message exchanges in the management, control, or data planes. These messages do not necessarily mean that recovery is delayed, but may increase the complexity of the protection system. Thus, the benefits of carrying extra traffic must be weighed against the disadvantages of delayed recovery, additional network overhead, and the impact on the services that support the extra traffic according to the details of the solutions selected.
ハードプリエンプションとソフトプリエンプションの両方が、管理、コントロール、またはデータプレーンで追加のメッセージ交換を利用する可能性があることに注意してください。これらのメッセージは、必ずしも回復が遅れていることを意味するわけではなく、保護システムの複雑さを高める可能性があります。したがって、余分なトラフィックを運ぶことの利点は、遅延回復、追加のネットワークオーバーヘッドの欠点、および選択されたソリューションの詳細に従って追加のトラフィックをサポートするサービスへの影響と比較検討する必要があります。
Note that extra traffic is not protected by definition, but may be restored.
定義上、追加のトラフィックは保護されていませんが、復元される場合があることに注意してください。
Extra traffic is not supported on dedicated protection resources, which, by definition, are used for 1+1 protection (Section 4.3.1), but it can be supported in other protection schemes, including shared protection (Section 4.3.2) and tunnel protection (Section 4.4.3).
専用の保護リソースでは追加のトラフィックはサポートされていません。これは、定義上、1 1保護に使用されますが（セクション4.3.1）、共有保護（セクション4.3.2）やトンネル保護など、他の保護スキームでサポートできます。（セクション4.4.3）。
Best-effort traffic should not be confused with extra traffic. For best-effort traffic, the network does not guarantee data delivery, and the user does not receive guaranteed quality of service (e.g., in terms of jitter, packet loss, delay, etc.). Best-effort traffic depends on the current traffic load. However, for extra traffic, quality can only be guaranteed until resources are required for recovery. At this point, the extra traffic may be completely
ベストエフォルトトラフィックは、余分なトラフィックと混同しないでください。ベストエフォルトトラフィックの場合、ネットワークはデータ配信を保証するものではなく、ユーザーは保証されたサービス品質を受け取っていません（たとえば、ジッター、パケットの損失、遅延など）。ベストエフォルトトラフィックは、現在のトラフィック負荷に依存します。ただし、追加のトラフィックの場合、リソースが回復に必要になるまで品質を保証できます。この時点で、余分なトラフィックは完全に
displaced, may be treated as best effort, or may itself be recovered (for example, by restoration techniques).
変位し、最善の努力として扱われるか、それ自体が回収される場合があります（例えば、修復技術によって）。
This section refers to LSP restoration. Restoration for PWs is beyond the scope of this document (but see Section 7).
このセクションでは、LSPの復元について言及しています。PWSの復元は、このドキュメントの範囲を超えています（ただし、セクション7を参照）。
Restoration represents the most effective use of network resources, since no resources are reserved for recovery. However, restoration requires the computation of a new path and the activation of a new LSP (through the management or control plane). It may be more time-consuming to perform these steps than to implement recovery using protection techniques.
回復は、回復のためにリソースが予約されていないため、ネットワークリソースの最も効果的な使用を表しています。ただし、復元には、新しいパスの計算と新しいLSPの活性化が必要です（管理プレーンまたはコントロールプレーンを介して）。保護技術を使用して回復を実装するよりも、これらの手順を実行する方が時間がかかる場合があります。
Furthermore, there is no guarantee that restoration will be able to recover the service. It may be that all suitable network resources are already in use for other LSPs, so that no new path can be found. This problem can be partially mitigated by using LSP setup priorities, so that recovery LSPs can preempt existing LSPs with lower priorities.
さらに、修復がサービスを回復できるという保証はありません。すべての適切なネットワークリソースがすでに他のLSPに使用されているため、新しいパスが見つかりません。この問題は、LSPセットアップの優先順位を使用して部分的に軽減できるため、Recovery LSPは優先度の低い既存のLSPを先取りできます。
Additionally, when a network defect occurs, multiple LSPs may be disrupted by the same event. These LSPs may have been established by different Network Management Stations (NMSes) or they may have been signaled by different head-end MPLS-TP nodes, meaning that multiple points in the network will try to compute and establish recovery LSPs at the same time. This can lead to a lack of resources within the network and cause recovery failures; some recovery actions will need to be retried, resulting in even slower recovery times for some services.
さらに、ネットワークの欠陥が発生すると、同じイベントによって複数のLSPが破壊される可能性があります。これらのLSPは、さまざまなネットワーク管理ステーション（NMS）によって確立されている可能性があるか、異なるヘッドエンドMPLS-TPノードによってシグナル化されている可能性があります。つまり、ネットワーク内の複数のポイントが同時に回復LSPを計算して確立しようとします。これにより、ネットワーク内のリソースの不足につながり、回復の失敗を引き起こす可能性があります。いくつかの回復アクションを再試行する必要があり、一部のサービスの回復時間が遅くなります。
Both hard and soft LSP restoration may be supported. For hard LSP restoration, the resources of the working LSP are released before the recovery LSP is fully established (i.e., break-before-make). For soft LSP restoration, the resources of the working LSP are released after an alternate LSP is fully established (i.e., make-before-break). Note that in the case of reversion (Section 4.3.5), the resources associated with the working LSP are not released.
硬質と柔らかいLSPの両方の修復がサポートされる場合があります。硬いLSPの修復のために、回復LSPが完全に確立される前に、作業LSPのリソースがリリースされます（つまり、壊れた後にメイク）。ソフトLSPの修復のために、作業LSPのリソースは、代替LSPが完全に確立された後にリリースされます（つまり、ブレイク前）。復帰の場合（セクション4.3.5）、作業LSPに関連するリソースはリリースされていないことに注意してください。
The restoration resources may be pre-calculated and even pre-signaled before the restoration action starts, but not pre-allocated. This is known as pre-planned LSP restoration. The complete establishment/activation of the restoration LSP occurs only when the restoration action starts. Pre-planning may occur periodically and provides the most accurate information about the available resources in the network.
修復リソースは、復元アクションが開始される前に事前計算され、事前にシグナル化される場合もありますが、事前に割り当てられていません。これは、事前に計画されたLSP修復として知られています。修復LSPの完全な確立/アクティベーションは、修復アクションが開始されたときにのみ発生します。事前計画は定期的に発生する場合があり、ネットワーク内の利用可能なリソースに関する最も正確な情報を提供します。
After a service has been recovered and traffic is flowing along the recovery LSP, the defective network resource may be replaced. Traffic can be redirected back onto the original working LSP (known as "reversion"), or it can be left where it is on the recovery LSP ("non-revertive" behavior).
サービスが回復し、回復LSPに沿ってトラフィックが流れている後、欠陥のあるネットワークリソースが交換される可能性があります。トラフィックは、元の作業LSP（「リバージョン」と呼ばれる）にリダイレクトすることも、回復LSP（「非リバーティブ」の動作）にある場所に残すことができます。
It should be possible to specify the reversion behavior of each service; this might even be configured for each recovery instance.
各サービスの逆転挙動を指定できるはずです。これは、リカバリインスタンスごとに構成される場合もあります。
In non-revertive mode, an additional operational option is possible where protection roles are switched, so that the recovery LSP becomes the working LSP, while the previous working path (or the resources used by the previous working path) are used for recovery in the event of an additional fault.
非反vertiveモードでは、保護の役割が切り替えられる場合に追加の運用オプションが可能になり、回復LSPが動作LSPになり、以前の作業パス（または以前の作業パスで使用されるリソース）が回復に使用されます。追加の障害のイベント。
In revertive mode, it is important to prevent excessive swapping between the working and recovery paths in the case of an intermittent defect. This can be addressed by using a reversion delay timer (the Wait-To-Restore timer), which controls the length of time to wait before reversion following the repair of a fault on the original working path. It should be possible for an operator to configure this timer per LSP, and a default value should be defined.
復帰モードでは、断続的な欠陥の場合、作業経路と回復パス間の過度の交換を防ぐことが重要です。これは、元の作業経路での障害の修復に続いて回復の前に待機するまでの時間の長さを制御する回転遅延タイマー（待機対象タイマー）を使用することで対処できます。オペレーターがLSPごとにこのタイマーを構成できるようにする必要があり、デフォルト値を定義する必要があります。
This section provides general descriptions (MPLS-TP non-specific) of the mechanisms that can be used for protection purposes. As indicated above, while the functional architecture applies to both LSPs and PWs, the mechanism for recovery described in this document refers to LSPs and LSP segments only. Recovery mechanisms for pseudowires and pseudowire segments are for further study and will be described in a separate document (see also Section 7).
このセクションでは、保護目的で使用できるメカニズムの一般的な説明（MPLS-TP非固有）を提供します。上記のように、機能アーキテクチャはLSPとPWの両方に適用されますが、このドキュメントで説明されている回復のメカニズムは、LSPとLSPセグメントのみを指します。擬似動物および擬似ワイヤのセグメントの回復メカニズムはさらなる研究のためであり、別の文書で説明されます（セクション7も参照）。
Link-level protection refers to two paradigms: (1) where protection is provided in a lower network layer and (2) where protection is provided by the MPLS-TP link layer.
リンクレベルの保護とは、次の2つのパラダイムを指します。（1）より低いネットワークレイヤーで保護が提供される場合、（2）MPLS-TPリンクレイヤーによって保護が提供される場合。
Note that link-level protection mechanisms do not protect the nodes at each end of the entity (e.g., a link or span) that is protected. End-to-end or segment protection should be used in conjunction with link-level protection to protect against a failure of the edge nodes.
リンクレベルの保護メカニズムは、保護されているエンティティの各端（例：リンクまたはスパン）のノードを保護しないことに注意してください。エンドツーエンドまたはセグメントの保護は、エッジノードの障害から保護するために、リンクレベルの保護と組み合わせて使用する必要があります。
Link-level protection offers the following grades of protection:
リンクレベルの保護は、次のグレードの保護を提供します。
o Full protection where a dedicated protection entity (e.g., a link or span) is pre-established to protect a working entity. When the working entity fails, the protected traffic is switched to the protecting entity. In this scenario, all LSPs carried over the working entity are recovered (in one protection operation) when there is a failure condition. This is referred to in [RFC4427] as "bulk recovery".
o 専用の保護エンティティ（リンクやスパンなど）が作業エンティティを保護するために事前に確立されている完全な保護。作業エンティティが失敗すると、保護されたトラフィックが保護エンティティに切り替えられます。このシナリオでは、障害条件がある場合、作業エンティティを運転するすべてのLSPが（1つの保護操作で）回復されます。これは[RFC4427]で「バルクリカバリー」と呼ばれます。
o Partial protection where only a subset of the LSPs or traffic carried over a selected entity is recovered when there is a failure condition. The decision as to which LSPs will be recovered and which will not depends on local policy.
o 障害条件がある場合、選択したエンティティを介して運ばれたLSPまたはトラフィックのサブセットのみが回収される部分保護。どのLSPが回復されるかについての決定と、それはローカルポリシーに依存しません。
When there is no failure on the working entity, the protection entity may transport extra traffic that may be preempted when protection switching occurs.
作業エンティティに障害がない場合、保護エンティティは、保護の切り替えが発生したときに先制される可能性のある追加のトラフィックを輸送する場合があります。
If link-level protection is available, it may be desirable to allow this to be attempted before attempting other recovery mechanisms for the transport paths affected by the fault because link-level protection may be faster and more conservative of network resources. This can be achieved both by limiting the propagation of fault condition notifications and by delaying the other recovery actions. This consideration of other protection can be compared with the discussion of recovery domains (Section 4.5) and recovery in multi-layer networks (Section 4.9).
リンクレベルの保護が利用可能な場合、リンクレベルの保護はネットワークリソースのより速く、より保守的である可能性があるため、障害の影響を受ける輸送パスの他の回復メカニズムを試みる前に、これを試みることが望ましい場合があります。これは、障害状態通知の伝播を制限することと、他の回復アクションを遅らせることによって達成できます。他の保護のこの考慮事項は、回復ドメインの議論（セクション4.5）および多層ネットワークの回復（セクション4.9）と比較できます。
A protection mechanism may be provided at the MPLS-TP link layer (which connects two MPLS-TP nodes). Such a mechanism can make use of the procedures defined in [RFC5586] to set up in-band communication channels at the MPLS-TP Section level, to use these channels to monitor the health of the MPLS-TP link, and to coordinate the protection states between the ends of the MPLS-TP link.
MPLS-TPリンクレイヤー（2つのMPLS-TPノードを接続する）で保護メカニズムが提供される場合があります。このようなメカニズムは、[RFC5586]で定義された手順を利用して、MPLS-TPセクションレベルでバンド通信チャネルを設定し、これらのチャネルを使用してMPLS-TPリンクの健康を監視し、保護を調整することができ、保護を調整できます。MPLS-TPリンクの端の間の状態。
The use of alternate paths and segments refers to the paradigm whereby protection is performed in the network layer in which the protected LSP is located; this applies either to the entire end-to-end LSP or to a segment of the LSP. In this case, hierarchical LSPs are not used (compare with Section 4.4.3).
代替パスとセグメントの使用は、保護されたLSPが配置されているネットワーク層で保護が実行されるパラダイムを指します。これは、エンドツーエンドのLSP全体またはLSPのセグメントのいずれかに適用されます。この場合、階層LSPは使用されません（セクション4.4.3と比較）。
Different grades of protection may be provided:
さまざまなグレードの保護が提供される場合があります：
o Dedicated protection where a dedicated entity (e.g., LSP or LSP segment) is (fully) pre-established to protect a working entity
o 専用のエンティティ（LSPまたはLSPセグメントなど）が（完全に）作業エンティティを保護するために（完全に）事前に確立されている専用の保護
(e.g., LSP or LSP segment). When a failure condition occurs on the working entity, traffic is switched onto the protection entity. Dedicated protection may be performed using 1:1 or 1+1 linear protection schemes. When the failure condition is eliminated, the traffic may revert to the working entity. This is subject to local configuration.
（例えば、LSPまたはLSPセグメント）。作業エンティティで障害条件が発生すると、トラフィックが保護エンティティに切り替えられます。1：1または1 1の線形保護スキームを使用して、専用の保護を実行できます。故障条件が排除されると、トラフィックが作業エンティティに戻る場合があります。これはローカル構成の対象となります。
o Shared protection where one or more protection entities is pre-established to protect against a failure of one or more working entities (1:n or m:n).
o 1つ以上の保護エンティティが1つ以上の作業エンティティ（1：nまたはm：n）の障害から保護するために事前に確立されている共有保護。
When the fault condition on the working entity is eliminated, the traffic should revert back to the working entity in order to allow other related working entities to be protected by the shared protection resource.
作業エンティティの障害条件が排除されると、他の関連する作業エンティティが共有保護リソースによって保護されるように、トラフィックが作業エンティティに戻る必要があります。
A protection tunnel is pre-provisioned in order to protect against a failure condition along a sequence of spans in the network. This may be achieved using LSP heirarchy. We call such a sequence a network segment. A failure of a network segment may affect one or more LSPs that transit the network segment.
ネットワーク内の一連のスパンに沿った故障条件から保護するために、保護トンネルが事前に生成されています。これは、LSP Heirarchyを使用して達成される場合があります。このようなシーケンスをネットワークセグメントと呼びます。ネットワークセグメントの障害は、ネットワークセグメントを通過する1つ以上のLSPに影響を与える可能性があります。
When a failure condition occurs in the network segment (detected either by OAM on the network segment, or by OAM on a concatenated segment of one of the LSPs transiting the network segment), one or more of the protected LSPs are switched over at the ingress point of the network segment and are transmitted over the protection tunnel. This is implemented through label stacking. Label mapping may be an option as well.
ネットワークセグメントで障害条件が発生した場合（ネットワークセグメントのOAMによって検出された場合、またはネットワークセグメントを通過するLSPの1つの連結セグメントでOAMによって）、保護されたLSPの1つ以上が侵入で切り替えられますネットワークセグメントのポイントと保護トンネル上に送信されます。これは、ラベルスタッキングを通じて実装されます。ラベルマッピングもオプションかもしれません。
Different grades of protection may be provided:
さまざまなグレードの保護が提供される場合があります：
o Dedicated protection where the protection tunnel reserves sufficient resources to provide protection for all protected LSPs without causing service degradation.
o 保護トンネルがサービスの劣化を引き起こすことなく、保護されたすべてのLSPに保護を提供するのに十分なリソースを留保する専用の保護。
o Partial protection where the protection tunnel has enough resources to protect some of the protected LSPs, but not all of them simultaneously. Policy dictates how this situation should be handled: it is possible that some LSPs would be protected, while others would simply fail; it is possible that traffic would be guaranteed for some LSPs, while for other LSPs it would be treated as best effort with the risk of packets being dropped. Alternatively, it is possible that protection would not be attempted.
o 保護トンネルが保護されたLSPの一部を保護するのに十分なリソースがあるが、それらのすべてを同時に保護するのに十分なリソースを持っている部分保護。ポリシーは、この状況をどのように処理するかを決定します。一部のLSPが保護される可能性がありますが、他のLSPは単に失敗する可能性があります。一部のLSPではトラフィックが保証される可能性がありますが、他のLSPでは、パケットが削除されるリスクとともに最善の努力として扱われます。あるいは、保護が試みられない可能性があります。
Protection and restoration are performed in the context of a recovery domain. A recovery domain is defined between two or more recovery reference end points that are located at the edges of the recovery domain and that border on the element on which recovery can be provided (as described in Section 4.2). This element can be an end-to-end path, a segment, or a span.
保護と回復は、回復ドメインのコンテキストで実行されます。回復ドメインは、回復ドメインのエッジにある2つ以上の回復基準エンドポイントと、回復が提供できる要素の境界線との間で定義されます（セクション4.2で説明されています）。この要素は、エンドツーエンドのパス、セグメント、またはスパンです。
An end-to-end path can be observed as a special segment case where the ingress and egress Label Edge Routers (LERs) serve as the recovery reference end points.
エンドツーエンドのパスは、イングレスと出口のラベルエッジルーター（LERS）が回復基準エンドポイントとして機能する特別なセグメントケースとして観察できます。
In this simple case of a point-to-point (P2P) protected entity, two end points reside at the boundary of the protection domain. An LSP can enter through one reference end point and exit the recovery domain through another reference end point.
ポイントツーポイント（P2P）保護されたエンティティのこの単純なケースでは、2つのエンドポイントが保護ドメインの境界にあります。LSPは、1つの参照エンドポイントを介して入力し、別の参照エンドポイントを介して回復ドメインを終了できます。
In the case of unidirectional point-to-multipoint (P2MP), three or more end points reside at the boundary of the protection domain. One of the end points is referred to as the source/root, while the others are referred to as sinks/leaves. An LSP can enter the recovery domain through the root point and exit the recovery domain through the leaf points.
単方向のポイントツーマルチポイント（P2MP）の場合、3つ以上のエンドポイントが保護ドメインの境界にあります。エンドポイントの1つはソース/ルートと呼ばれ、他はシンク/葉と呼ばれます。LSPは、ルートポイントを介して回復ドメインを入力し、葉のポイントを介して回復ドメインを終了できます。
The recovery mechanism should restore traffic that was interrupted by a facility (link or node) fault within the recovery domain. Note that a single link may be part of several recovery domains. If two recovery domains have common links, one recovery domain must be contained within the other. This can be referred to as nested recovery domains. The boundaries of recovery domains may coincide, but recovery domains must not overlap.
回復メカニズムは、回復ドメイン内の施設（リンクまたはノード）障害によって中断されたトラフィックを回復する必要があります。単一のリンクは、いくつかのリカバリドメインの一部である可能性があることに注意してください。2つの回復ドメインに共通のリンクがある場合、1つの回復ドメインを他のリンク内に含める必要があります。これは、ネストされた回復ドメインと呼ぶことができます。回復ドメインの境界が一致する場合がありますが、回復ドメインが重複してはなりません。
Note that the edges of a recovery domain are not protected, and unless the whole domain is contained within another recovery domain, the edges form a single point of failure.
回復ドメインのエッジは保護されていないことに注意してください。ドメイン全体が別の回復ドメインに含まれていない限り、エッジは単一の障害点を形成します。
A recovery group is defined within a recovery domain and consists of a working (primary) entity and one or more recovery (backup) entities that reside between the end points of the recovery domain. To guarantee protection in all situations, a dedicated recovery entity should be pre-provisioned using disjoint resources in the recovery domain, in order to protect against a failure of a working entity. Of course, mechanisms to detect faults and to trigger protection switching are also needed.
回復グループは回復ドメイン内で定義され、回復ドメインのエンドポイントの間に存在する作業（プライマリ）エンティティと1つ以上の回復（バックアップ）エンティティで構成されます。あらゆる状況で保護を保証するために、労働エンティティの障害から保護するために、回復ドメインの馬鹿げたリソースを使用して、専用の回復エンティティを事前に生成する必要があります。もちろん、障害を検出し、保護スイッチングをトリガーするメカニズムも必要です。
The method used to monitor the health of the recovery element is beyond the scope of this document. The end points that are
回復要素の健康を監視するために使用される方法は、このドキュメントの範囲を超えています。エンドポイントです
responsible for the recovery action must receive information on its condition. The condition of the recovery element may be 'OK', 'failed', or 'degraded'.
回復措置の責任は、その状態に関する情報を受け取る必要があります。回復要素の条件は、「OK」、「失敗」、または「分解」される場合があります。
When the recovery operation is to be triggered by OAM mechanisms, an OAM Maintenance Entity Group must be defined for each of the working and protection entities.
OAMメカニズムによって回復操作をトリガーする場合、作業および保護エンティティごとにOAMメンテナンスエンティティグループを定義する必要があります。
The recovery entities and functions in a recovery domain can be configured using a management plane or a control plane. A management plane may be used to configure the recovery domain by setting the reference points, the working and recovery entities, and the recovery type (e.g., 1:1 bidirectional linear protection, ring protection, etc.). Additional parameters associated with the recovery process may also be configured. For more details, see Section 6.1.
回復ドメイン内の回復エンティティと機能は、管理プレーンまたはコントロールプレーンを使用して構成できます。管理プレーンを使用して、参照ポイント、作業および回復エンティティ、および回復タイプを設定することにより、回復ドメインを構成することができます（例：1：1の双方向線形保護、リング保護など）。回復プロセスに関連付けられた追加のパラメーターも構成できます。詳細については、セクション6.1を参照してください。
When a control plane is used, the ingress LERs may communicate with the recovery reference points that request that protection or restoration be configured across a recovery domain. For details, see Section 6.5.
コントロールプレーンを使用すると、イングレスレーは、回復または復元をリカバリドメインで構成することを要求するリカバリの参照ポイントと通信する場合があります。詳細については、セクション6.5を参照してください。
Cases of multiple interconnections between distinct recovery domains create a hierarchical arrangement of recovery domains, since a single top-level recovery domain is created from the concatenation of two recovery domains with multiple interconnections. In this case, recovery actions may be taken both in the individual, lower-level recovery domains to protect any LSP segment that crosses the domain, and within the higher-level recovery domain to protect the longer LSP segment that traverses the higher-level domain.
異なる回復ドメイン間の複数の相互接続のケースは、複数の相互接続を持つ2つの回復ドメインの連結から単一のトップレベルの回復ドメインが作成されるため、回復ドメインの階層的な配置を作成します。この場合、回復アクションは、ドメインを横切るLSPセグメントを保護するために、個々の低レベルの回復ドメインと、高レベルのドメインを通過するより長いLSPセグメントを保護するために高レベルのリカバリドメイン内で行われる可能性があります。。
The MPLS-TP recovery mechanism can be arranged to ensure coordination between domains. In interconnected rings, for example, it may be preferable to allow the upstream ring to perform recovery before the downstream ring, in order to ensure that recovery takes place in the ring in which the defect occurred. Coordination of recovery actions is particularly important in nested domains and is discussed further in Section 4.9.
MPLS-TP回復メカニズムは、ドメイン間の調整を確保するために配置できます。たとえば、相互接続されたリングでは、欠陥が発生したリングで回復が行われるように、下流のリングの前に上流のリングが回復できるようにすることが望ましい場合があります。回復アクションの調整は、ネストされたドメインで特に重要であり、セクション4.9でさらに説明します。
As described in the requirements listed in Section 3 and detailed in [RFC5654], the selected recovery techniques may be optimized for different network topologies if the optimized mechanisms perform significantly better than the generic mechanisms in the same topology.
セクション3にリストされており、[RFC5654]に詳述されている要件に記載されているように、選択された回復手法は、最適化されたメカニズムが同じトポロジの一般的なメカニズムよりも大幅に優れている場合、異なるネットワークトポロジに対して最適化される場合があります。
These mechanisms are required (R91 of [RFC5654]) to interoperate with the mechanisms defined for arbitrary topologies, in order to allow
これらのメカニズムは、任意のトポロジーで定義されたメカニズムと相互運用するために、許可するために必要な（[RFC5654]のR91）が必要です
end-to-end protection and to ensure that consistent protection techniques are used across the entire network. In this context, 'interoperate' means that the use of one technique must not inhibit the use of another technique in an adjacent part of the network for use on the same end-to-end transport path, and must not prohibit the use of end-to-end protection mechanisms.
エンドツーエンドの保護と、ネットワーク全体で一貫した保護技術が使用されるようにするため。この文脈では、「Interoperate」とは、1つの手法の使用が、同じエンドツーエンドの輸送パスで使用するためにネットワークの隣接する部分で別の手法の使用を阻害してはならず、終了の使用を禁止してはならないことを意味します。 - エンドまでの保護メカニズム。
The next sections (4.7 and 4.8) describe two different topologies and explain how recovery may be markedly different in those different scenarios. They also develop the concept of a recovery domain and show how end-to-end survivability may be achieved through a concatenation of recovery domains, each providing some grade of recovery in part of the network.
次のセクション（4.7および4.8）では、2つの異なるトポロジーについて説明し、これらの異なるシナリオで回復が著しく異なる方法を説明します。また、回復ドメインの概念を開発し、回復ドメインの連結を通じてエンドツーエンドの生存性がどのように達成されるかを示し、それぞれがネットワークの一部である程度の回復を提供します。
A mesh network is any network where there is arbitrary interconnectivity between nodes in the network. Mesh networks are usually contrasted with more specific topologies such as hub-and-spoke or ring (see Section 4.8), although such networks are actually examples of mesh networks. This section is limited to the discussion of protection techniques in the context of mesh networks. That is, it does not include optimizations for specific topologies.
メッシュネットワークは、ネットワーク内のノード間に任意の相互接続性があるネットワークです。メッシュネットワークは通常、ハブアンドスポークやリングなどのより特定のトポロジとは対照的です（セクション4.8を参照）。このようなネットワークは実際にはメッシュネットワークの例です。このセクションは、メッシュネットワークのコンテキストでの保護技術の議論に限定されています。つまり、特定のトポロジの最適化は含まれません。
Linear protection is a protection mechanism that provides rapid and simple protection switching. In a mesh network, linear protection provides a very suitable protection mechanism because it can operate between any pair of points within the network. It can protect against a defect in a node, a span, a transport path segment, or an end-to-end transport path. Linear protection gives a clear indication of the protection status.
線形保護は、迅速かつ単純な保護スイッチングを提供する保護メカニズムです。メッシュネットワークでは、線形保護は、ネットワーク内の任意のポイント間で動作できるため、非常に適切な保護メカニズムを提供します。ノード、スパン、輸送パスセグメント、またはエンドツーエンドの輸送パスの欠陥から保護できます。線形保護は、保護状態を明確に示しています。
Linear protection operates in the context of a protection domain. A protection domain is a special type of recovery domain (see Section 4.5) associated with the protection function. A protection domain is composed of the following architectural elements:
線形保護は、保護ドメインのコンテキストで動作します。保護ドメインは、保護機能に関連する特別なタイプの回復ドメイン（セクション4.5を参照）です。保護ドメインは、次のアーキテクチャ要素で構成されています。
o A set of end points that reside at the boundary of the protection domain. In the simple case of 1:n or 1+1 P2P protection, two end points reside at the boundary of the protection domain. In each transmission direction, one of the end points is referred to as the source, and the other is referred to as the sink. For unidirectional P2MP protection, three or more end points reside at the boundary of the protection domain. One of the end points is referred to as the source/root, while the others are referred to as sinks/leaves.
o 保護ドメインの境界に存在する一連のエンドポイント。1：nまたは1 1 p2p保護の単純な場合、2つのエンドポイントは保護ドメインの境界にあります。各伝送方向では、エンドポイントの1つがソースと呼ばれ、もう1つはシンクと呼ばれます。単方向P2MP保護の場合、3つ以上のエンドポイントが保護ドメインの境界にあります。エンドポイントの1つはソース/ルートと呼ばれ、他はシンク/葉と呼ばれます。
o A Protection Group consists of one or more working (primary) paths and one or more protection (backup) paths that run between the end points belonging to the protection domain. To guarantee protection in all scenarios, a dedicated protection path should be pre-provisioned to protect against a defect of a working path (i.e., 1:1 or 1+1 protection schemes). In addition, the working and the protection paths should be disjoint; i.e., the physical routes of the working and the protection paths should be physically diverse in every respect.
o 保護グループは、1つ以上の作業（一次）パスと、保護ドメインに属するエンドポイント間で実行される1つ以上の保護（バックアップ）パスで構成されています。すべてのシナリオで保護を保証するには、作業経路の欠陥（つまり、1：1または1 1の保護スキーム）の欠陥から保護するために、専用の保護パスを事前に解決する必要があります。さらに、作業経路と保護パスはばらばらでなければなりません。つまり、作業経路と保護パスの物理的ルートは、あらゆる点で物理的に多様でなければなりません。
Note that if the resources of the protection path are less than those of the working path, the protection path may not have sufficient resources to protect the traffic of the working path.
保護パスのリソースが作業経路のリソースよりも少ない場合、保護パスには作業パスのトラフィックを保護するのに十分なリソースがない場合があることに注意してください。
As mentioned in Section 4.3.2, the resources of the protection path may be shared as 1:n. In this scenario, the protection path will not have sufficient resources to protect all the working paths at a specific time.
セクション4.3.2で述べたように、保護パスのリソースは1：nとして共有される場合があります。このシナリオでは、保護パスには、特定の時間にすべての作業パスを保護するのに十分なリソースがありません。
For bidirectional P2P paths, both unidirectional and bidirectional protection switching are supported. If a defect occurs when bidirectional protection switching is defined, the protection actions are performed in both directions (even if the defect is unidirectional). The protection state is required to operate with a level of coordination between the end points of the protection domain.
双方向P2Pパスの場合、単方向保護と双方向保護の両方のスイッチングがサポートされています。双方向保護スイッチングが定義されているときに欠陥が発生した場合、保護アクションは両方向に実行されます（欠陥が単方向であっても）。保護状態は、保護ドメインのエンドポイント間の調整レベルで動作する必要があります。
In unidirectional protection switching, the protection actions are only performed in the affected direction.
単方向保護スイッチングでは、保護アクションは影響を受ける方向でのみ実行されます。
Revertive and non-revertive operations are provided as options for the network operator.
回復操作と非反論操作は、ネットワークオペレーターのオプションとして提供されます。
Linear protection supports the protection schemes described in the following sub-sections.
線形保護は、次のサブセクションで説明されている保護スキームをサポートします。
In the 1:1 scheme, a protection path is allocated to protect against a defect, failure, or a degradation in a working path. As described above, to guarantee protection, the protection entity should support the full capacity and bandwidth, although it may be configured (for example, because of limited network resource availability) to offer a degraded service when compared with the working entity.
1：1スキームでは、保護パスが、作業経路での欠陥、障害、または劣化から保護するために割り当てられます。上記のように、保護を保証するために、保護エンティティは完全な容量と帯域幅をサポートする必要がありますが、作業エンティティと比較した場合、劣化したサービスを提供するように構成されている可能性があります（たとえば、ネットワークリソースの可用性が限られているため）。
Figure 1 presents 1:1 protection architecture. In normal conditions, data traffic is transmitted over the working entity, while the protection entity functions in the idle state. (OAM may run on the
図1は、1：1の保護アーキテクチャを示しています。通常の条件では、データトラフィックは作業エンティティを介して送信され、保護エンティティはアイドル状態で機能します。（OAMはで実行される場合があります
protection entity to verify its state.) Normal conditions are defined when there is no defect, failure, or degradation on the working entity, and no administrative configuration or request causes traffic to flow over the protection entity.
保護エンティティその状態を検証するためのエンティティ。）通常の条件は、作業エンティティに欠陥、障害、または劣化がなく、管理構成や要求がなく、トラフィックが保護エンティティ上に流れない場合に定義されます。
|-----------------Protection Domain---------------|
==============================
/**********Working path***********\
+--------+ ============================== +--------+
| Node /| |\ Node |
| A {< | | >} B |
| | | |
+--------+ ============================== +--------+
Protection path
==============================
Figure 1: 1:1 Protection Architecture
図1：1：1保護アーキテクチャ
If there is a defect on the working entity or a specific administrative request, traffic is switched to the protection entity.
作業エンティティに欠陥がある場合、または特定の管理リクエストがある場合、トラフィックは保護エンティティに切り替えられます。
Note that when operating with non-revertive behavior (see Section 4.3.5), after the conditions causing the switchover have been cleared, the traffic continues to flow on the protection path, but the working and protection roles are not switched.
非反転挙動で動作する場合（セクション4.3.5を参照）、スイッチオーバーを引き起こす条件がクリアされた後、トラフィックは保護パス上で流れ続けますが、作業および保護の役割は切り替えられないことに注意してください。
In each transmission direction, the protection domain source bridges traffic onto the appropriate entity, while the sink selects traffic from the appropriate entity. The source and the sink need to coordinate the protection states to ensure that bridging and selection are performed to and from the same entity. For this reason, a signaling coordination protocol (either a data-plane in-band signaling protocol or a control-plane-based signaling protocol) is required.
各伝送方向では、保護ドメインが適切なエンティティにトラフィックをブリッジし、シンクは適切なエンティティからトラフィックを選択します。ソースとシンクは、同じエンティティとの間で橋渡しと選択が実行されるように、保護状態を調整する必要があります。このため、シグナリング調整プロトコル（データプレーンインバンドシグナル伝達プロトコルまたはコントロールプレーンベースのシグナル伝達プロトコルのいずれか）が必要です。
In bidirectional protection switching, both ends of the protection domain are switched to the protection entity (even when the fault is unidirectional). This requires a protocol to coordinate the protection state between the two end points of the protection domain.
双方向保護スイッチングでは、保護ドメインの両端が保護エンティティに切り替えられます（障害が一方向である場合でも）。これには、保護ドメインの2つのエンドポイント間の保護状態を調整するプロトコルが必要です。
When there is no defect, the bandwidth resources of the idle entity may be used for traffic with lower priority. When protection switching is performed, the traffic with lower priority may be preempted by the protected traffic through tearing down the LSP with lower priority, reporting a fault on the LSP with lower priority, or by treating the traffic with lower priority as best effort and discarding it when there is congestion.
欠陥がない場合、アイドルエンティティの帯域幅リソースは、優先度の低いトラフィックに使用される場合があります。保護スイッチングが実行されると、優先度の低いトラフィックが優先度の低いLSPを引き裂くこと、LSPの障害を優先度の低いと報告すること、または最優先事項の低い努力と廃棄としてのトラフィックをより低い扱いを行うことにより、保護されたトラフィックによって先取りされる可能性があります。混雑があるとき。
In the general case of 1:n linear protection, one protection entity is allocated to protect n working entities. The protection entity might not have sufficient resources to protect all the working entities that may be affected by fault conditions at a specific time. In this case, in order to guaranteed protection, the protection entity should support enough capacity and bandwidth to protect any of the n working entities.
1：n線形保護の一般的なケースでは、1つの保護エンティティがN作業エンティティを保護するために割り当てられます。保護エンティティには、特定の時間に障害条件の影響を受ける可能性のあるすべての作業エンティティを保護するのに十分なリソースがない場合があります。この場合、保護を保証するために、保護エンティティは、N作業エンティティのいずれかを保護するのに十分な能力と帯域幅をサポートする必要があります。
When defects or failures occur along multiple working entities, the entity to be protected should be prioritized. The protection states between the edges of the protection domain should be fully coordinated to ensure consistent behavior. As explained in Section 4.3.5, revertive behavior is recommended when 1:n is supported.
複数の作業エンティティに沿って欠陥または障害が発生した場合、保護されるエンティティに優先順位を付ける必要があります。保護ドメインのエッジ間の保護状態は、一貫した動作を確保するために完全に調整する必要があります。セクション4.3.5で説明されているように、1：nがサポートされている場合は、復帰動作が推奨されます。
In the 1+1 protection scheme, a fully dedicated protection entity is allocated.
1 1保護スキームでは、完全に専用の保護エンティティが割り当てられます。
As depicted in Figure 2, data traffic is copied and fed at the source to both the working and the protection entities. The traffic on the working and the protection entities is transmitted simultaneously to the sink of the protection domain, where selection between the working and protection entities is performed (based on some predetermined criteria).
図2に示すように、データトラフィックがコピーされ、ソースで作業エンティティと保護エンティティの両方に供給されます。作業エンティティと保護エンティティのトラフィックは、運用エンティティと保護エンティティ間の選択が実行される保護ドメインのシンクに同時に送信されます（いくつかの所定の基準に基づいて）。
|---------------Protection Domain---------------|
==============================
/**********Working path************\
+--------+ ============================== +--------+
| Node /| |\ Node |
| A {< | | >} Z |
| \| |/ |
+--------+ ============================== +--------+
\**********Protection path*********/
==============================
Figure 2: 1+1 Protection Architecture
図2：1 1保護アーキテクチャ
Note that control traffic between the edges of the protection domain (such as OAM or a control protocol to coordinate the protection state, etc.) may be transmitted on an entity that differs from the one used for the protected traffic. These packets should not be discarded by the sink.
保護ドメインのエッジ間の制御トラフィック（OAMやコントロールプロトコルなど）は、保護状態などを調整するなど）は、保護されたトラフィックに使用されるエンティティとは異なるエンティティに送信される可能性があることに注意してください。これらのパケットは、シンクによって破棄されるべきではありません。
In 1+1 unidirectional protection switching, there is no need to coordinate the protection state between the protection controllers at both ends of the protection domain. In 1+1 bidirectional protection switching, a protocol is required to coordinate the protection state between the edges of the protection domain.
1 1単方向保護スイッチングでは、保護ドメインの両端の保護コントローラー間の保護状態を調整する必要はありません。1 1の双方向保護スイッチングでは、保護ドメインのエッジ間の保護状態を調整するためにプロトコルが必要です。
In both protection schemes, traffic flows end-to-end on the working entity after the conditions causing the switchover have been cleared. Data selection may return to selecting traffic from the working entity if reversion is enabled, and it will require coordination of the protection state between the edges of the protection domain. To avoid frequent switching caused by intermittent defects or failures when the network is not stable, traffic is not selected from the working entity before the Wait-To-Restore (WTR) timer has expired.
両方の保護スキームで、スイッチオーバーを引き起こす条件がクリアされた後、トラフィックが作業エンティティのエンドツーエンドで流れます。データの選択は、回復が有効になっている場合、作業エンティティからのトラフィックの選択に戻る場合があり、保護ドメインのエッジ間の保護状態の調整が必要になります。ネットワークが安定していない場合に断続的な欠陥または障害によって引き起こされる頻繁な切り替えを回避するために、待機対策（WTR）タイマーが期限切れになる前に、トラフィックは作業エンティティから選択されません。
Linear protection may be applied to protect unidirectional P2MP entities using 1+1 protection architecture. The source/root MPLS-TP node bridges the user traffic to both the working and protection entities. Each sink/leaf MPLS-TP node selects the traffic from one entity according to some predetermined criteria. Note that when there is a fault condition on one of the branches of the P2MP path, some leaf MPLS-TP nodes may select the working entity, while other leaf MPLS-TP nodes may select traffic from the protection entity.
1 1保護アーキテクチャを使用して、一方向P2MPエンティティを保護するために線形保護を適用することができます。ソース/ルートMPLS-TPノードは、ユーザーのトラフィックを作業エンティティと保護エンティティの両方にブリッジします。各シンク/リーフMPLS-TPノードは、いくつかの所定の基準に従って、1つのエンティティからトラフィックを選択します。P2MPパスの分岐の1つに障害状態がある場合、一部の葉のMPLS-TPノードは作業エンティティを選択する場合があり、他の葉のMPLS-TPノードは保護エンティティからトラフィックを選択する場合があります。
In a 1:1 P2MP protection scheme, the source/root MPLS-TP node needs to identify the existence of a fault condition on any of the branches of the network. This means that the sink/leaf MPLS-TP nodes need to notify the source/root MPLS-TP node of any fault condition. This also necessitates a return path from the sinks/leaves to the source/root MPLS-TP node. When protection switching is triggered, the source/root MPLS-TP node selects the protection transport path for traffic transfer.
1：1 P2MP保護スキームでは、ソース/ルートMPLS-TPノードは、ネットワークのいずれかのブランチに障害状態の存在を特定する必要があります。これは、シンク/リーフMPLS-TPノードが、障害状態のソース/ルートMPLS-TPノードに通知する必要があることを意味します。これには、シンク/葉からソース/ルートMPLS-TPノードへのリターンパスも必要です。保護スイッチングがトリガーされると、ソース/ルートMPLS-TPノードは、トラフィック転送用の保護輸送パスを選択します。
A form of "segment recovery for P2MP LSPs" could be constructed. Given a P2MP LSP, one can protect any possible point of failure (link or node) using N backup P2MP LSPs. Each backup P2MP LSP originates from the upstream node with respect to a different possible failure point and terminates at all of the destinations downstream of the potential failure point. In case of a failure, traffic is redirected to the backup P2MP path.
「P2MP LSPのセグメントリカバリ」の形式を構築できます。P2MP LSPを考えると、NバックアップP2MP LSPを使用して、障害の可能性（リンクまたはノード）を保護できます。各バックアップP2MP LSPは、異なる可能な障害点に関して上流ノードから発生し、潜在的な障害点の下流のすべての目的地で終了します。障害の場合、トラフィックはバックアップP2MPパスにリダイレクトされます。
Note that such mechanisms do not yet exist, and their exact behavior is for further study.
そのようなメカニズムはまだ存在しておらず、それらの正確な行動はさらなる研究のためのものであることに注意してください。
A 1:n protection scheme for P2MP transport paths is also required by [RFC5654]. Such a mechanism is for future study.
[RFC5654]では、P2MP輸送パスの1：N保護スキームも必要です。このようなメカニズムは、将来の研究のためのものです。
Protection switching may be performed when:
保護スイッチングは、次の場合に実行できます。
o A defect condition is detected on the working entity, and the protection entity has "no" or an inferior condition. Proactive in-band OAM Continuity Check and Connectivity Verification (CC-V) monitoring of both the working and the protection entities may be used to enable the rapid detection of a fault condition. For protection switching, it is common to run a CC-V every 3.33 ms. In the absence of three consecutive CC-V messages, a fault condition is declared. In order to monitor the working and the protection entities, an OAM Maintenance Entity Group should be defined for each entity. OAM indications associated with fault conditions should be provided at the edges of the protection domain that is responsible for the protection-switching operation. Input from OAM performance monitoring that indicates degradation in the working entity may also be used as a trigger for protection switching. In the case of degradation, switching to the protection entity is needed only if the protection entity can exhibit better operating conditions.
o 作業エンティティで欠陥条件が検出され、保護エンティティには「NO」または劣った条件があります。障害状態の迅速な検出を可能にするために、作業機関と保護エンティティの両方のプロアクティブなインバンドOAM連続性チェックと接続検証（CC-V）モニタリングを使用することができます。保護スイッチングの場合、3.33ミリ秒ごとにCC-Vを実行することが一般的です。 3つの連続したCC-Vメッセージがない場合、障害状態が宣言されています。作業および保護エンティティを監視するには、各エンティティに対してOAMメンテナンスエンティティグループを定義する必要があります。断層条件に関連するOAM適応症は、保護操作を担当する保護ドメインの端に提供する必要があります。作業エンティティの劣化を示すOAMパフォーマンス監視からの入力は、保護スイッチングのトリガーとしても使用できます。劣化の場合、保護エンティティがより良い動作条件を示すことができる場合にのみ、保護エンティティへの切り替えが必要です。
o An indication is received from a lower-layer server that there is a defect in the lower layer.
o 下層サーバーから、下層に欠陥があることを示す表示が受けられます。
o An external operator command is received (e.g., 'Forced Switch', 'Manual Switch'). For details, see Section 6.1.2.
o 外部演算子コマンドが受信されます（例：「強制スイッチ」、「手動スイッチ」）。詳細については、セクション6.1.2を参照してください。
o A request to switch over is received from the far end. The far end may initiate this request, for example, on receipt of an administrative request to switch over, or when bidirectional 1:1 protection switching is supported and a defect occurred that could only be detected by the far end, etc.
o 切り替えのリクエストは、遠端から受信されます。遠端は、たとえば、管理の要求を受け取ったときに、または双方向1：1の保護スイッチングがサポートされ、遠端などでのみ検出できる欠陥が発生した場合、この要求を開始する場合があります。
As described above, the protection state should be coordinated between the end points of the protection domain. Control messages should be exchanged between the edges of the protection domain to coordinate the protection state of the edge nodes. Control messages can be delivered using an in-band, data-plane-driven control protocol or a control-plane-based protocol.
上記のように、保護状態は保護ドメインのエンドポイント間で調整する必要があります。制御メッセージは、エッジノードの保護状態を調整するために、保護ドメインのエッジ間で交換する必要があります。コントロールメッセージは、インバンドのデータプレーン駆動型コントロールプロトコルまたはコントロールプレーンベースのプロトコルを使用して配信できます。
For 50-ms protection switching, it is recommended that an in-band, data-plane-driven signaling protocol be used in order to coordinate the protection states. An in-band, data-plane protocol for use in MPLS-TP networks is documented in [MPLS-TP-LP] for linear protection (ring protection is discussed in Section 4.8 of this document). This protocol is also used to detect mismatches between the configurations provisioned at the ends of the protection domain.
50 ms保護スイッチングの場合、保護状態を調整するために、帯域内のデータプレーン駆動型シグナル伝達プロトコルを使用することをお勧めします。MPLS-TPネットワークで使用するインバンドのデータプレーンプロトコルは、線形保護のために[MPLS-TP-LP]で文書化されています（このドキュメントのセクション4.8でリング保護について説明します）。このプロトコルは、保護ドメインの端でプロビジョニングされた構成間の不一致を検出するためにも使用されます。
As described in Section 6.5, the GMPLS control plane already includes procedures and message elements to coordinate the protection states between the edges of the protection domain. These procedures and protocol messages are specified in [RFC4426], [RFC4872], and [RFC4873]. However, these messages lack the capability to coordinate the revertive/non-revertive behavior and the consistency of configured timers at the edges of the protection domain (timers such as WTR, hold-off timer, etc.).
セクション6.5で説明したように、GMPLS制御プレーンには、保護ドメインのエッジ間の保護状態を調整する手順とメッセージ要素が既に含まれています。これらの手順とプロトコルメッセージは、[RFC4426]、[RFC4872]、および[RFC4873]で指定されています。ただし、これらのメッセージには、リバート/非反転の動作と、保護ドメインのエッジで構成されたタイマーの一貫性を調整する機能がありません（WTR、ホールドオフタイマーなどのタイマー）。
In order to implement data-plane-based linear protection on LSP segments, use is made of the Sub-Path Maintenance Element (SPME), an MPLS-TP architectural element defined in [RFC5921]. Maintenance operations (e.g., monitoring, protection, or management) engage with message transmission (e.g., OAM, Protection Path Coordination, etc.) in the maintained domain. Further discussion of the architecture for OAM and SPME is found in [RFC5921] and [RFC6371]. An SPME is an LSP that is basically defined and used for the purposes of OAM monitoring, protection, or management of LSP segments. The SPME uses the MPLS construct of a hierarchical, nested LSP, as defined in [RFC3031].
LSPセグメントにデータ平面ベースの線形保護を実装するために、[RFC5921]で定義されたMPLS-TPアーキテクチャ要素であるサブパスメンテナンス要素（SPME）の使用が行われます。メンテナンス操作（監視、保護、管理など）は、メンテナンスドメインのメッセージ送信（OAM、保護パス調整など）に従事します。OAMとSPMEのアーキテクチャのさらなる議論は、[RFC5921]および[RFC6371]にあります。SPMEは、基本的に定義され、LSPセグメントのOAM監視、保護、または管理の目的に使用されるLSPです。SPMEは、[RFC3031]で定義されているように、階層的なネストされたLSPのMPLSコンストラクトを使用します。
For linear protection, SPMEs should be defined over the working and protection entities between the edges of a protection domain. OAM messages and messages used to coordinate protection state can be initiated at the edge of the SPME and sent to the peer edge of the SPME. Note that these messages are sent over the Generic Associated Channel (G-ACh) within the SPME, and that they use a two-label stack, the SPME label, and, at the bottom of the stack, the G-ACh label (GAL) [RFC5586].
線形保護のために、SPMEは、保護ドメインのエッジ間の作業および保護エンティティを介して定義する必要があります。保護状態を調整するために使用されるOAMメッセージとメッセージは、SPMEの端で開始し、SPMEのピアエッジに送信できます。これらのメッセージは、SPME内の汎用関連チャネル（G-ach）を介して送信され、2ラベルスタック、SPMEラベル、およびスタックの下部にG-achラベル（gal）を使用していることに注意してください。）[RFC5586]。
The end-to-end traffic of the LSP, which includes data traffic and control traffic (messages for OAM, management, signaling, and to coordinate protection state), is tunneled within the SPMEs by means of label stacking, as defined in [RFC3031].
データトラフィックと制御トラフィック（OAM、管理、シグナリング、および保護状態を調整するためのメッセージ）を含むLSPのエンドツーエンドトラフィックは、[RFC3031で定義されているラベルスタッキングによってSPME内でトンネル化されます。]。
Mapping between an LSP and an SPME can be 1:1; this is similar to the ITU-T Tandem Connection element that defines a sub-layer corresponding to a segment of a path. Mapping can also be 1:n to allow the scalable protection of a set of LSP segments traversing the part of the network in which a protection domain is defined. Note that each of these LSPs can be initiated or terminated at different end points in the network, but that they all traverse the protection domain and share similar constraints (such as requirements for quality of service (QoS), terms of protection, etc.).
LSPとSPMEのマッピングは1：1です。これは、パスのセグメントに対応するサブレイヤーを定義するITU-Tタンデム接続要素に似ています。マッピングは、保護ドメインが定義されているネットワークの部分を通過するLSPセグメントのセットのスケーラブルな保護を可能にするために、1：nです。これらの各LSPは、ネットワーク内の異なるエンドポイントで開始または終了することができますが、それらはすべて保護ドメインを通過し、同様の制約（サービス品質の要件（QoS）、保護条件など）を共有することに注意してください。。
Note also that in the context of segment protection, the SPMEs serve as the working and protection entities.
また、セグメント保護のコンテキストでは、SPMESは作業および保護エンティティとして機能することに注意してください。
For shared mesh protection, the protection resources are used to protect multiple LSPs that do not all share the same end points; for example, in Figure 3 there are two paths, ABCDE and VWXYZ. These paths do not share end points and cannot, therefore, make use of 1:n linear protection, even though they do not have any common points of failure.
共有メッシュ保護のために、保護リソースは、すべてが同じエンドポイントを共有していない複数のLSPを保護するために使用されます。たとえば、図3には、ABCDEとVWXYZの2つのパスがあります。これらのパスはエンドポイントを共有せず、したがって、障害の一般的なポイントがない場合でも、1：nの線形保護を使用することはできません。
ABCDE may be protected by the path APQRE, while VWXYZ can be protected by the path VPQRZ. In both cases, 1:1 or 1+1 protection may be used. However, it can be seen that if 1:1 protection is used for both paths, the PQR network segment does not carry traffic when no failures affect either of the two working paths. Furthermore, in the event of only one failure, the PQR segment carries traffic from only one of the working paths.
ABCDEはパスAPQREによって保護される場合がありますが、VWXYZはパスVPQRZによって保護できます。どちらの場合も、1：1または1 1の保護を使用できます。ただし、両方のパスに1：1の保護が使用されている場合、2つの作業パスのいずれかに障害が影響しない場合、PQRネットワークセグメントはトラフィックを運ばないことがわかります。さらに、1つの障害のみが発生した場合、PQRセグメントは作業パスの1つだけからトラフィックを運びます。
Thus, it is possible for the network resources on the PQR segment to be shared by the two recovery paths. In this way, mesh protection can substantially reduce the number of network resources that have to be reserved in order to provide 1:n protection.
したがって、PQRセグメントのネットワークリソースが2つの回復パスで共有される可能性があります。このようにして、メッシュ保護は、1：N保護を提供するために予約する必要があるネットワークリソースの数を大幅に削減できます。
A----B----C----D----E
\ /
\ /
\ /
P-----Q-----R
/ \
/ \
/ \
V----W----X----Y----Z
Figure 3: A Shared Mesh Protection Topology
図3：共有メッシュ保護トポロジ
As the network becomes more complex and the number of LSPs increases, the potential for shared mesh protection also increases. However, this can quickly become unmanageable owing to the increased complexity. Therefore, shared mesh protection is normally pre-planned and configured by the operator, although an automated system cannot be ruled out.
ネットワークがより複雑になり、LSPの数が増えると、共有メッシュ保護の可能性も増加します。ただし、複雑さの増加により、これはすぐに管理できなくなる可能性があります。したがって、共有メッシュ保護は通常、事前に計画され、オペレーターによって構成されますが、自動化されたシステムを除外することはできません。
Note that shared mesh protection operates as 1:n linear protection (see Section 4.7.1). However, the protection state needs to be coordinated between a larger number of nodes: the end points of the shared concatenated protection segment (nodes P and R in the example)
共有メッシュ保護は1：n線形保護として動作することに注意してください（セクション4.7.1を参照）。ただし、保護状態は、より多くのノードの間で調整する必要があります。共有された連結保護セグメントのエンドポイント（例のノードPおよびR）
as well as the end points of the protected LSPs (nodes A, E, V, and Z in the example).
保護されたLSPのエンドポイント（例のノードA、E、V、およびZ）。
Additionally, note that the shared-protection resources could be used to carry extra traffic. For example, in Figure 4, an LSP JPQRK could be a preemptable LSP that constitutes extra traffic over the PQR hops; it would be displaced in the event of a protection event. In this case, it should be noted that the protection state must also be coordinated with the ends of the extra-traffic LSPs.
さらに、共有保護リソースを使用して追加のトラフィックを運ぶことができることに注意してください。たとえば、図4では、LSP JPQRKは、PQRホップ上の余分なトラフィックを構成する先制的なLSPである可能性があります。保護イベントが発生した場合には移動します。この場合、保護状態は、交通量の多いLSPの端とも調整する必要があることに注意する必要があります。
A----B----C----D----E
\ /
\ /
\ /
J-----P-----Q-----R-----K
/ \
/ \
/ \
V----W----X----Y----Z
Figure 4: Shared Mesh Protection with Extra Traffic
図4：追加のトラフィックで共有メッシュ保護
Several service providers have expressed great interest in the operation of MPLS-TP in ring topologies; they demand a high degree of survivability functionality in these topologies.
いくつかのサービスプロバイダーは、リングトポロジーでのMPLS-TPの運用に大きな関心を示しています。これらのトポロジーでは、高度な生存可能性機能を必要とします。
Various criteria for optimization are considered in ring topologies, such as:
最適化のためのさまざまな基準は、次のようなリングトポロジーで考慮されています。
1. Simplification in ring operation in terms of the number of OAM Maintenance Entities that are needed to trigger the recovery actions, the number of recovery elements, the number of management-plane transactions during maintenance operations, etc.
1. リング操作の単純化回復アクションをトリガーするために必要なOAMメンテナンスエンティティの数、回復要素の数、メンテナンス操作中の管理面トランザクションの数など。
2. Optimization of resource consumption around the ring, such as the number of labels needed for the protection paths that traverse the network, the total bandwidth required in the ring to ensure path protection, etc. (see R91 of [RFC5654]).
2. ネットワークを横断する保護パスに必要なラベルの数、パス保護などを確保するためにリングに必要な帯域幅の総幅など、リングの周りのリソース消費の最適化（[RFC5654]のR91を参照）。
[RFC5654] introduces a list of requirements for ring protection covering the recovery mechanisms needed to protect traffic in a single ring as well as traffic that traverses more than one ring. Note that configuration and the operation of the recovery mechanisms in a ring must scale well with the number of transport paths, the number of nodes, and the number of ring interconnects.
[RFC5654]は、単一のリングのトラフィックを保護するために必要な回復メカニズムと、複数のリングを通過するトラフィックをカバーするリング保護の要件のリストを導入します。リング内の回復メカニズムの構成と動作は、トランスポートパスの数、ノードの数、およびリングの相互接続の数で十分にスケーリングする必要があることに注意してください。
The requirements for ring protection are fully compatible with the generic requirements for recovery.
リング保護の要件は、回復のための一般的な要件と完全に互換性があります。
The architecture and the mechanisms for ring protection are specified in separate documents. These mechanisms need to be evaluated against the requirements specified in [RFC5654], which includes guidance on the principles for the development of new mechanisms.
アーキテクチャとリング保護のメカニズムは、個別のドキュメントで指定されています。これらのメカニズムは、[RFC5654]で指定された要件に対して評価する必要があります。これには、新しいメカニズムの開発の原則に関するガイダンスが含まれます。
In multi-layer or multi-regional networking [RFC5212], recovery may be performed at multiple layers or across nested recovery domains.
多層ネットワークまたは多層ネットワーキング[RFC5212]では、複数の層またはネストされた回復ドメイン全体で回復を実行できます。
The MPLS-TP recovery mechanism must ensure that the timing of recovery is coordinated in order to avoid race scenarios. This also allows the recovery mechanism of the server layer to fix the problem before recovery takes place in the MPLS-TP layer, or the MPLS-TP layer to perform recovery before a client network.
MPLS-TP回復メカニズムは、人種シナリオを避けるために、回復のタイミングが調整されることを保証する必要があります。これにより、サーバーレイヤーの回復メカニズムがMPLS-TPレイヤーまたはMPLS-TPレイヤーで回復する前に問題を修正して、クライアントネットワークの前に回復を実行します。
A hold-off timer is required to coordinate recovery timing in multiple layers or across nested recovery domains. Setting this configurable timer involves a trade-off between rapid recovery and the creation of a race condition where multiple layers respond to the same fault, potentially allocating resources in an inefficient manner. Thus, the detection of a defect condition in the MPLS-TP layer should not immediately trigger the recovery process if the hold-off timer is configured as a value other than zero. Instead, the hold-off timer should be started when the defect is detected and, on expiry, the recovery element should be checked to determine whether the defect condition still exists. If it does exist, the defect triggers the recovery operation.
複数のレイヤーまたはネストされた回復ドメイン全体で回復タイミングを調整するには、ホールドオフタイマーが必要です。この構成可能なタイマーの設定には、迅速な回復と複数の層が同じ障害に応答し、非効率的な方法でリソースを割り当てる可能性のある人種条件の作成との間のトレードオフが含まれます。したがって、Hold-Offタイマーがゼロ以外の値として構成されている場合、MPLS-TP層の欠陥条件の検出は、すぐに回復プロセスをトリガーしないはずです。代わりに、欠陥が検出されたときにホールドオフタイマーを開始し、有効期限が切れると、欠陥条件がまだ存在するかどうかを判断するために回復要素をチェックする必要があります。それが存在する場合、欠陥は回復操作を引き起こします。
The hold-off timer should be configurable.
ホールドオフタイマーは構成可能である必要があります。
In other configurations, where the lower layer does not have a restoration capability, or where it is not expected to provide protection, the lower layer needs to trigger the higher layer to immediately perform recovery. Although this can be forced by configuring the hold-off timer as zero, it may be that because of layer independence, the higher layer does not know whether the lower layer will perform restoration. In this case, the higher layer will configure a non-zero hold-off timer and rely on the receipt of a specific notification from the lower layer if the lower layer cannot perform restoration. Since layer boundaries are always within nodes, such coordination is implementation-specific and does not need to be covered here.
下層に復元能力がない場合、または保護を提供することが期待されていない他の構成では、下層が高層をトリガーしてすぐに回復を実行する必要があります。これは、ホールドオフタイマーをゼロとして構成することで強制される可能性がありますが、層の独立性のために、より高いレイヤーが下層が回復を実行するかどうかはわかりません。この場合、高層は非ゼロホールドオフタイマーを構成し、下層が復元を実行できない場合は下層からの特定の通知の受領に依存します。レイヤー境界は常にノード内にあるため、このような調整は実装固有であり、ここでカバーする必要はありません。
Reference should be made to [RFC3386], which discusses the interaction between layers in survivable networks.
[RFC3386]を参照する必要があります。[RFC3386]は、生存可能なネットワークの層間の相互作用について説明します。
Where a link in the MPLS-TP network is formed through connectivity (i.e., a packet or non-packet LSP) in a lower-layer network, that connectivity may itself be protected; for example, the LSP in the lower-layer network may be provisioned with 1+1 protection. In this case, the link in the MPLS-TP network has an inherited grade of protection.
MPLS-TPネットワークのリンクが、低層ネットワークの接続性（つまり、パケットまたは非パケットLSP）を介して形成される場合、その接続自体が保護される可能性があります。たとえば、低層ネットワークのLSPには、1 1保護でプロビジョニングされる場合があります。この場合、MPLS-TPネットワークのリンクには、継承されたグレードの保護があります。
An LSP in the MPLS-TP network may be provisioned with protection in the MPLS-TP network, as already described, or it may be provisioned to utilize only those links that have inherited protection.
MPLS-TPネットワークのLSPは、すでに説明されているように、MPLS-TPネットワークの保護を備えたプロビジョニングであるか、保護を継承したリンクのみを利用するようにプロビジョニングされる場合があります。
By classifying the links in the MPLS-TP network according to the grade of protection that they inherited from the server network, it is possible to compute an end-to-end path in the MPLS-TP network that uses only those links with a specific or superior grade of inherited protection. This means that the end-to-end MPLS-TP LSP can be protected at the grade necessary to conform to the SLA without needing to provide any additional protection in the MPLS-TP layer. This reduces complexity, saves network resources, and eliminates protection-switching coordination problems.
サーバーネットワークから継承した保護グレードに従ってMPLS-TPネットワークのリンクを分類することにより、特定のリンクのみを使用するMPLS-TPネットワークのエンドツーエンドパスを計算することができます。または継承された保護の優れたグレード。これは、MPLS-TP層に追加の保護を提供する必要なく、SLAに適合するために必要なグレードでエンドツーエンドのMPLS-TP LSPを保護できることを意味します。これにより、複雑さが軽減され、ネットワークリソースが節約され、保護スイッチング調整の問題がなくなります。
When the requisite grade of inherited protection is not available on all segments along the path in the MPLS-TP network, segment protection may be used to achieve the desired protection grade.
MPLS-TPネットワークのパスに沿ったすべてのセグメントで、継承された保護の必要なグレードが利用できない場合、セグメント保護を使用して、望ましい保護グレードを達成できます。
It should be noted, however, that inherited protection only applies to links. Nodes cannot be protected in this way. An operator will need to perform an analysis of the relative likelihood and consequences of node failure if this approach is taken without providing protection in the MPLS-TP LSP or PW layer to handle node failure.
ただし、継承された保護はリンクにのみ適用されることに注意する必要があります。この方法でノードを保護することはできません。このアプローチがMPLS-TP LSPまたはPW層で保護を提供してノード障害を処理することなく、このアプローチが取られた場合、オペレーターは、ノード障害の相対的な可能性と結果の分析を実行する必要があります。
When an MPLS-TP protection scheme is established, it is important that the working and protection paths do not share resources in the network. If this is not achieved, a single defect may affect both the working and the protection paths with the result that traffic cannot be delivered -- since under such a condition the traffic was not protected.
MPLS-TP保護スキームが確立される場合、作業および保護パスがネットワーク内のリソースを共有しないことが重要です。これが達成されない場合、単一の欠陥は作業経路と保護パスの両方に影響を与える可能性があり、その結果、トラフィックは配信できません。そのような条件下では、トラフィックは保護されていません。
Note that this restriction does not apply to restoration, since this takes place after the fault has occurred, which means that the point of failure can be avoided if an available path exists.
この制限は、障害が発生した後に行われるため、回復には適用されないことに注意してください。つまり、利用可能なパスが存在する場合、障害点を回避できます。
When planning a recovery scheme, it is possible to use a topology map of the MPLS-TP layer to select paths that use diverse links and nodes within the MPLS-TP network. However, this does not guarantee that the paths are truly diverse; for example, two separate links in an MPLS-TP network may be provided by two lambdas in the same optical fiber, or by two fibers that cross the same bridge. Moreover, two completely separate MPLS-TP nodes might be situated in the same building with a shared power supply.
回復スキームを計画する場合、MPLS-TPレイヤーのトポロジマップを使用して、MPLS-TPネットワーク内で多様なリンクとノードを使用するパスを選択することができます。ただし、これはパスが本当に多様であることを保証するものではありません。たとえば、MPLS-TPネットワーク内の2つの別々のリンクは、同じ光ファイバの2つのラムダ、または同じブリッジを横切る2つの繊維によって提供される場合があります。さらに、2つの完全に個別のMPLS-TPノードが、共有電源を備えた同じ建物に位置する可能性があります。
Thus, in order to achieve proper recovery planning, the MPLS-TP network must have an understanding of the groups of lower-layer resources that share a common risk of failure. From this, MPLS-TP shared risk groups can be constructed that show which MPLS-TP resources share a common risk of failure. Diversity of working and protection paths can be planned, not only with regard to nodes and links but also in order to refrain from using resources from the same shared risk groups.
したがって、適切な回復計画を達成するために、MPLS-TPネットワークは、障害の一般的なリスクを共有する低層リソースのグループを理解する必要があります。このことから、MPLS-TP共有リスクグループを構築することができ、どのMPLS-TPリソースが障害の共通のリスクを共有するかを示すことができます。ノードとリンクに関してだけでなく、同じ共有リスクグループのリソースの使用を控えるために、作業および保護パスの多様性を計画することができます。
In a layered network, a low-layer fault may be detected and reported by multiple layers and may sometimes lead to the generation of multiple fault reports from the same layer. For example, a failure of a data link may be reported by the line cards in an MPLS-TP node, but it could also be detected and reported by the MPLS-TP OAM.
階層化されたネットワークでは、低層障害が検出および複数の層によって報告される場合があり、同じ層から複数の障害報告の生成につながる場合があります。たとえば、データリンクの障害は、MPLS-TPノードのラインカードによって報告される場合がありますが、MPLS-TP OAMで検出および報告することもできます。
Section 4.6 explains how it is important to coordinate the survivability actions configured and operated in a multi-layer network in a way that will avoid over-equipping the survivability resources in the network, while ensuring that recovery actions are performed in only one layer at a time.
セクション4.6では、ネットワーク内の生存可能性リソースの装備を過度に配置することを避けながら、マルチレイヤーネットワークで構成および動作する生存性アクションを調整することがどのように重要であるかを説明し、回復アクションが1つのレイヤーでのみ実行されるようにします。時間。
Fault correlation is about understanding which single event has generated a set of fault reports, so that recovery actions can be coordinated, and so that the fault logging system does not become overloaded. Fault correlation depends on understanding resource use at lower layers, shared risk groups, and a wider view with regard to the way in which the layers are interrelated.
障害相関とは、どの単一のイベントが一連の障害レポートを生成したかを理解することであり、回復アクションを調整し、障害ロギングシステムが過負荷にならないようにすることです。障害相関は、下層、共有リスクグループ、および層の相互関係の方法に関するより広いビューでのリソースの使用を理解することに依存します。
Fault correlation is most easily performed at the point of fault detection; for example, an MPLS-TP node that receives a fault notification from the lower layer, and detects a fault on an LSP in the MPLS-TP layer, can easily correlate these two events. Furthermore, if the same node detects multiple faults on LSPs that
障害の相関は、障害検出の時点で最も簡単に実行されます。たとえば、下層から障害通知を受信し、MPLS-TP層のLSPの障害を検出するMPLS-TPノードは、これら2つのイベントを簡単に相関させることができます。さらに、同じノードがLSPの複数の障害を検出した場合
share the same faulty data link, it can easily correlate them. Such a node may use correlation to perform group-based recovery actions and can reduce the number of alarm events that it generates to its management station.
同じ障害のあるデータリンクを共有すると、それらを簡単に相関させることができます。このようなノードは、相関を使用してグループベースの回復アクションを実行し、管理ステーションに生成するアラームイベントの数を減らすことができます。
Fault correlation may also be performed at a management station that receives fault reports from different layers and different nodes in the network. This enables the management station to coordinate management-originated recovery actions and to present consolidated fault information to the user and automated management systems.
ネットワーク内のさまざまなレイヤーと異なるノードから障害レポートを受信する管理ステーションで障害相関を実行することもできます。これにより、管理ステーションは、管理著な回復アクションを調整し、ユーザーおよび自動化された管理システムに統合された障害情報を提示することができます。
It is also necessary to correlate fault information detected and reported through OAM. This function would enable a fault detected at a lower layer, and reported at a transit node of an MPLS-TP LSP, to be correlated with an MPLS-TP-layer fault detected at a Maintenance End Point (MEP) -- for example, the egress of the MPLS-TP LSP. Such correlation allows the coordination of recovery actions performed at the MEP, but it also requires that the lower-layer fault information is propagated to the MEP, which is most easily achieved using a control plane, management plane, or OAM message.
また、OAMを通じて検出および報告された障害情報を相関させる必要があります。この関数は、下層で検出され、MPLS-TP LSPのトランジットノードで報告された障害を可能にし、メンテナンスエンドポイント（MEP）で検出されたMPLS-TP層障害と相関することができます。たとえば、たとえば、MPLS-TP LSPの出口。このような相関により、MEPで実行される回復アクションの調整が可能になりますが、低層障害情報をMEPに伝播する必要があります。
The MPLS-TP network can be viewed as two layers (the MPLS LSP layer and the PW layer). The MPLS-TP network operates over data-link connections and data-link networks whereby the MPLS-TP links are provided by individual data links or by connections in a lower-layer network. The MPLS LSP layer is a mandatory part of the MPLS-TP network, while the PW layer is an optional addition for supporting specific services.
MPLS-TPネットワークは、2つのレイヤー（MPLS LSP層とPWレイヤー）として見ることができます。MPLS-TPネットワークは、MPLS-TPリンクが個々のデータリンクまたは低層ネットワークの接続によって提供されるデータリンク接続とデータリンクネットワークを介して動作します。MPLS LSPレイヤーはMPLS-TPネットワークの必須部分であり、PWレイヤーは特定のサービスをサポートするためのオプションの追加です。
MPLS-TP survivability provides recovery from failure of the links and nodes in the MPLS-TP network. The link defects and failures are typically caused by defects or failures in the underlying data-link connections and networks, but this section is only concerned with recovery actions performed in the MPLS-TP network, which must recover from the manifestation of any problem as a defect failure in the MPLS-TP network.
MPLS-TP Survivabilityは、MPLS-TPネットワークのリンクとノードの障害からの回復を提供します。リンクの欠陥と障害は通常、基礎となるデータリンク接続とネットワークの欠陥または障害によって引き起こされますが、このセクションは、MPLS-TPネットワークで実行される回復アクションのみに関係しています。MPLS-TPネットワークの欠陥障害。
This section lists the recovery elements (see Section 1) supported in each of the two layers that can recover from defects or failures of nodes or links in the MPLS-TP network.
このセクションには、MPLS-TPネットワークのノードまたはリンクの欠陥または障害から回復できる2つのレイヤーのそれぞれでサポートされている回復要素（セクション1を参照）をリストします。
+--------------+---------------------+------------------------------+
| Recovery | MPLS LSP Layer | PW Layer |
| Element | | |
+--------------+---------------------+------------------------------+
| Link | MPLS LSP recovery | The PW layer is not aware of |
| Recovery | can be used to | the underlying network. |
| | survive the failure | This function is not |
| | of an MPLS-TP link. | supported. |
+--------------+---------------------+------------------------------+
| Segment/Span | An individual LSP | For an SS-PW, segment |
| Recovery | segment can be | recovery is the same as |
| | recovered to | end-to-end recovery. |
| | survive the failure | Segment recovery for an MS-PW|
| | of an MPLS-TP link. | is for future study, and |
| | | this function is now |
| | | provided using end-to-end |
| | | recovery. |
+--------------+---------------------+------------------------------+
| Concatenated | A concatenated LSP | Concatenated segment |
| Segment | segment can be | recovery (in an MS-PW) is for|
| Recovery | recovered to | future study, and this |
| | survive the failure | function is now provided |
| | of an MPLS-TP link | using end-to-end recovery. |
| | or node. | |
+--------------+---------------------+------------------------------+
| End-to-End | An end-to-end LSP | End-to-end PW recovery can |
| Recovery | can be recovered to | be applied to survive any |
| | survive any node or | node (including S-PE) or |
| | link failure, | link failure, except for |
| | except for the | failure of the ingress or |
| | failure of the | egress T-PE. |
| | ingress or egress | |
| | node. | |
+--------------+---------------------+------------------------------+
| Service | The MPLS LSP layer | PW-layer service recovery |
| Recovery | is service- | requires surviving faults in |
| | agnostic. This | T-PEs or on Attachment |
| | function is not | Circuits (ACs). This is |
| | supported. | currently out of scope for |
| | | MPLS-TP. |
+--------------+---------------------+------------------------------+
Table 1: Recovery Elements Supported by the MPLS LSP Layer and PW Layer
表1：MPLS LSP層とPW層によってサポートされる回復要素
Section 6 provides a description of mechanisms for MPLS-TP-LSP survivability. Section 7 provides a brief overview of mechanisms for MPLS-TP-PW survivability.
セクション6では、MPLS-TP-LSPの生存性のメカニズムの説明を提供します。セクション7では、MPLS-TP-PWの生存性のメカニズムの簡単な概要を説明します。
This section describes the existing mechanisms that provide LSP protection within MPLS-TP networks and highlights areas where new work is required.
このセクションでは、MPLS-TPネットワーク内でLSP保護を提供する既存のメカニズムについて説明し、新しい作業が必要な領域を強調します。
As described above, a fundamental requirement of MPLS-TP is that recovery mechanisms should be capable of functioning in the absence of a control plane. Recovery may be triggered by MPLS-TP OAM fault management functions or by external requests (e.g., an operator's request for manual control of protection switching). Recovery LSPs (and in particular Restoration LSPs) may be provisioned through the management plane.
上記のように、MPLS-TPの基本的な要件は、コントロールプレーンの非存在下で回復メカニズムが機能できるはずであるということです。回復は、MPLS-TP OAM障害管理機能または外部リクエスト（たとえば、保護スイッチングの手動制御のオペレーターの要求）によってトリガーされる場合があります。回復LSP（特に修復LSP）は、管理プレーンを介してプロビジョニングされる場合があります。
The management plane may be used to configure the recovery domain by setting the reference end-point points (which control the recovery actions), the working and the recovery entities, and the recovery type (e.g., 1:1 bidirectional linear protection, ring protection, etc.).
管理プレーンは、参照エンドポイント（回復アクションを制御する）、作業および回復エンティティ、および回復タイプ（例：1：1の双方向線形保護、リング保護）を設定することにより、回復ドメインを構成するために使用できます。、など）。
Additional parameters associated with the recovery process (such as WTR and hold-off timers, revertive/non-revertive operation, etc.) may also be configured.
回復プロセスに関連付けられた追加のパラメーター（WTRおよびホールドオフタイマー、リバート/非リバート操作など）も設定されます。
In addition, the management plane may initiate manual control of the recovery function. A priority should be set for the fault conditions and the operator's requests.
さらに、管理プレーンは、回復関数の手動制御を開始する場合があります。障害条件とオペレーターの要求に対して優先事項を設定する必要があります。
Since provisioning the recovery domain involves the selection of a number of options, mismatches may occur at the different reference points. The MPLS-TP protocol to coordinate protection state, which is specified in [MPLS-TP-LP], may be used as an in-band (i.e., data-plane-based) control protocol to coordinate the protection states between the end points of the recovery domain, and to check the consistency of configured parameters (such as timers, revertive/non-revertive behavior, etc.) with discovered inconsistencies that are reported to the operator.
回復ドメインのプロビジョニングには多くのオプションの選択が含まれるため、異なる参照ポイントでミスマッチが発生する場合があります。[MPLS-TP-LP]で指定されている保護状態を調整するMPLS-TPプロトコルは、エンドポイント間の保護状態を調整するために、インバンド（つまり、データプレーンベース）制御プロトコルとして使用できます。回復ドメインの、およびオペレーターに報告された発見された矛盾を備えた構成されたパラメーター（タイマー、リバート/非反転挙動など）の一貫性を確認する。
It should also be possible for the management plane to track the recovery status by receiving reports or by issuing polls.
また、管理プレーンがレポートを受け取ったり、投票を発行したりすることにより、回復状況を追跡することも可能です。
To implement the protection-switching mechanisms, the following entities and information should be configured and provisioned:
保護スイッチングメカニズムを実装するには、次のエンティティと情報を構成およびプロビジョニングする必要があります。
o The end points of a recovery domain. As described above, these end points border on the element of recovery to which recovery is applied.
o 回復ドメインのエンドポイント。上記のように、これらのエンドポイントは、回復が適用される回復の要素に境界を付けます。
o The protection group, which, depending on the required protection scheme, consists of a recovery entity and one or more working entities. In 1:1 or 1+1 P2P protection, the paths of the working entity and the recovery entities must be physically diverse in every respect (i.e., not share any resources or physical locations), in order to guarantee protection.
o 必要な保護スキームに応じて、回復エンティティと1つ以上の作業エンティティで構成される保護グループ。1：1または1 1 P2P保護では、保護を保証するために、作業エンティティと回復エンティティの経路は、あらゆる点で物理的に多様でなければなりません（つまり、リソースや物理的な場所を共有しないでください）。
o As defined in Section 4.8, the SPME must be supported in order to implement data-plane-based LSP segment recovery, since related control messages (e.g., for OAM, Protection Path Coordination, etc.) can be initiated and terminated at the edges of a path where push and pop operations are enabled. The SPME is an end-to-end LSP that in this context corresponds to the recovery entities (working and protection) and makes use of the MPLS construct of hierarchical nested LSP, as defined in [RFC3031]. OAM messages and messages to coordinate protection state can be initiated at the edge of the SPME and sent over G-ACH to the peer edge of the SPME. It is necessary to configure the related SPMEs and map between the LSP segments being protected and the SPME. Mapping can be 1:1 or 1:N to allow scalable protection of a set of LSP segments traversing the part of the network in which a protection domain is defined.
o セクション4.8で定義されているように、関連する制御メッセージ（OAM、保護パス調整など）を開始および終了することができるため、データプレーンベースのLSPセグメントリカバリを実装するためにSPMEをサポートする必要があります。プッシュおよびポップ操作が有効になっているパス。SPMEは、このコンテキストで回復エンティティ（作業と保護）に対応するエンドツーエンドLSPであり、[RFC3031]で定義されているように、階層ネストLSPのMPLSコンストラクトを使用します。保護状態を調整するOAMメッセージとメッセージは、SPMEの端で開始し、G-achを介してSPMEのピアエッジに送信できます。保護されているLSPセグメントとSPME間の関連するSPMEとマップを構成する必要があります。マッピングは、1：1または1：nにすることができます。これは、保護ドメインが定義されているネットワークの部分を通過するLSPセグメントのセットのスケーラブルな保護を可能にすることができます。
Note that each of these LSPs can be initiated or terminated at different end points in the network, but that they all traverse the protection domain and share similar constraints (such as requirements for QoS, terms of protection, etc.).
これらの各LSPは、ネットワーク内の異なるエンドポイントで開始または終了することができますが、それらはすべて保護ドメインを通過し、同様の制約（QoS、保護条件などの要件など）を共有することに注意してください。
o The protection type that should be defined (e.g., unidirectional 1:1, bidirectional 1+1, etc.)
o 定義する必要のある保護タイプ（例：単方向1：1、双方向1 1など）
o Revertive/non-revertive behavior should be configured.
o 復帰/非反論の動作を構成する必要があります。
o Timers (such as WTR, hold-off timer, etc.) should be set.
o タイマー（WTR、ホールドオフタイマーなど）を設定する必要があります。
The following external, manual commands may be provided for manual control of the protection-switching operation. These commands apply to a protection group; they are listed in descending order of priority:
保護スイッチング操作を手動で制御するために、以下の外部の手動コマンドを提供できます。これらのコマンドは保護グループに適用されます。それらは優先順位の降順でリストされています：
o Blocked protection action - a manual command to prevent data traffic from switching to the recovery entity. This command actually disables the protection group.
o ブロックされた保護アクション - データトラフィックが回復エンティティに切り替えるのを防ぐための手動コマンド。このコマンドは実際に保護グループを無効にします。
o Force protection action - a manual command that forces a switch of normal data traffic to the recovery entity.
o 強制保護アクション - 通常のデータトラフィックのスイッチを回復エンティティに強制する手動コマンド。
o Manual protection action - a manual command that forces a switch of data traffic to the recovery entity only when there is no defect in the recovery entity.
o 手動保護アクション - 回復エンティティに欠陥がない場合にのみ、データトラフィックのスイッチを回復エンティティに強制する手動コマンド。
o Clear switching command - the operator may request that a previous administrative switch command (manual or force switch) be cleared.
o クリアスイッチングコマンド - オペレーターは、以前の管理スイッチコマンド（マニュアルまたはフォーススイッチ）をクリアするよう要求する場合があります。
Fault detection is a fundamental part of recovery and survivability. In all schemes, with the exception of some types of 1+1 protection, the actions required for the recovery of traffic delivery depend on the discovery of some kind of fault. In 1+1 protection, the selector (at the receiving end) may simply be configured to choose the better signal; thus, it does not detect a fault or degradation of itself, but simply identifies the path that is better for data delivery.
障害検出は、回復と生存性の基本的な部分です。すべてのスキームにおいて、あるタイプの1 1保護を除き、交通配信の回復に必要なアクションは、何らかの障害の発見に依存します。1 1保護では、セレクター（受信側）を単により良い信号を選択するように構成することができます。したがって、それ自体の断層や分解を検出するのではなく、データ配信に適したパスを単純に識別します。
Faults may be detected in a number of ways depending on the traffic pattern and the underlying hardware. End-to-end faults may be reported by the application or by knowledge of the application's data pattern, but this is an unusual approach. There are two more common mechanisms for detecting faults in the MPLS-TP layer:
障害は、トラフィックパターンと基礎となるハードウェアに応じて、さまざまな方法で検出される場合があります。エンドツーエンドの障害は、アプリケーションまたはアプリケーションのデータパターンの知識によって報告される場合がありますが、これは異常なアプローチです。MPLS-TP層の障害を検出するための2つの一般的なメカニズムがあります。
o Faults reported by the lower layers.
o 下層によって報告された障害。
o Faults detected by protocols within the MPLS-TP layer.
o MPLS-TP層内のプロトコルによって検出された障害。
In an IP/MPLS network, the second mechanism may utilize control-plane protocols (such as the routing protocols) to detect a failure of adjacency between neighboring nodes. In an MPLS-TP network, it is possible that no control plane will be present. Even if a control plane is present, it will be a GMPLS control plane [RFC3945], which logically separates control channels from data channels; thus, no conclusion about the health of a data channel can be drawn from the
IP/MPLSネットワークでは、2番目のメカニズムは、コントロールプレーンプロトコル（ルーティングプロトコルなど）を利用して、隣接するノード間の隣接性の障害を検出する場合があります。MPLS-TPネットワークでは、コントロールプレーンが存在しない可能性があります。コントロールプレーンが存在していても、コントロールチャネルをデータチャネルから論理的に分離するGMPLSコントロールプレーン[RFC3945]になります。したがって、データチャネルの健康についての結論は、
failure of an associated control channel. MPLS-TP-layer faults are, therefore, only detected through the use of OAM protocols, as described in Section 6.4.1.
関連する制御チャネルの障害。したがって、MPLS-TP層断層は、セクション6.4.1で説明されているように、OAMプロトコルの使用によってのみ検出されます。
Faults may, however, be reported by a lower layer. These generally show up as interface failures or data-link failures (sometimes known as connectivity failures) within the MPLS-TP network, for example, an underlying optical link may detect loss of light and report a failure of the MPLS-TP link that uses it. Alternatively, an interface card failure may be reported to the MPLS-TP layer.
ただし、障害は下層によって報告される場合があります。これらは通常、MPLS-TPネットワーク内のインターフェイス障害またはデータリンク障害（接続障害と呼ばれることもあります）として表示されます。たとえば、基礎となる光学リンクは、光の喪失を検出し、MPLS-TPリンクの障害を使用する場合があります。それ。あるいは、インターフェイスカードの障害がMPLS-TP層に報告される場合があります。
Faults reported by lower layers are only visible in specific nodes within the MPLS-TP network (i.e., at the adjacent end points of the MPLS-TP link). This would only allow recovery to be performed locally, so, to enable recovery to be performed by nodes that are not immediately local to the fault, the fault must be reported (Sections 6.4.3 and 6.5.4).
下層によって報告された障害は、MPLS-TPネットワーク内の特定のノード（つまり、MPLS-TPリンクの隣接するエンドポイント）でのみ表示されます。これにより、回復がローカルでのみ実行されるため、障害のすぐにローカルではないノードによって回復を実行できるようにするため、障害を報告する必要があります（セクション6.4.3および6.5.4）。
If an MPLS-TP node detects that there is a fault in an LSP (that is, not a network fault reported from a lower layer, but a fault detected by examining the LSP), it can immediately perform a recovery action. However, unless the location of the fault is known, the only practical options are:
MPLS-TPノードがLSPに障害があることを検出した場合（つまり、下層から報告されたネットワーク障害ではなく、LSPを調べることで検出された障害）、すぐに回復アクションを実行できます。ただし、障害の場所がわかっていない限り、唯一の実用的なオプションは次のとおりです。
o Perform end-to-end recovery.
o エンドツーエンドの回復を実行します。
o Perform some other recovery as a speculative act.
o 投機的行為として他の回復を実行します。
Since the speculative acts are not guaranteed to achieve the desired results and could consume resources unnecessarily, and since end-to-end recovery can require a lot of network resources, it is important to be able to localize the fault.
投機的行為は望ましい結果を達成することを保証されておらず、不必要にリソースを消費する可能性があるため、エンドツーエンドの回復には多くのネットワークリソースが必要になる可能性があるため、障害をローカライズできることが重要です。
Fault localization may be achieved by dividing the network into protection domains. End-to-end protection is thereby operated on LSP segments, depending on the domain in which the fault is discovered. This necessitates monitoring of the LSP at the domain edges.
ネットワークを保護ドメインに分割することにより、障害のローカリゼーションが達成される場合があります。これにより、障害が発見されたドメインに応じて、LSPセグメントでエンドツーエンドの保護が操作されます。これには、ドメインエッジでのLSPの監視が必要です。
Alternatively, a proactive mechanism of fault localization through OAM (Section 6.4.3) or through the control plane (Section 6.5.3) is required.
あるいは、OAM（セクション6.4.3）またはコントロールプレーン（セクション6.5.3）を介した障害局在の積極的なメカニズムが必要です。
Fault localization is particularly important for restoration because a new path must be selected that avoids the fault. It may not be practical or desirable to select a path that avoids the entire failed
障害のローカリゼーションは、障害を回避する新しいパスを選択する必要があるため、回復に特に重要です。失敗全体を回避するパスを選択することは実用的または望ましくないかもしれません
working path, and it is therefore necessary to isolate the fault's location.
作業経路、したがって、障害の位置を分離する必要があります。
MPLS-TP provides a comprehensive set of OAM tools for fault management and performance monitoring at different nested levels (end-to-end, a portion of a path (LSP or PW), and at the link level) [RFC6371].
MPLS-TPは、さまざまなネストレベル（エンドツーエンド、パスの一部（LSPまたはPW）、およびリンクレベル）での障害管理とパフォーマンスモニタリングのための包括的なOAMツールセットを提供します[RFC6371]。
These tools support proactive and on-demand fault management (for fault detection and fault localization) as well as performance monitoring (to measure the quality of the signals and detect degradation).
これらのツールは、プロアクティブおよびオンデマンド障害管理（障害検出および障害のローカリゼーションのため）とパフォーマンス監視（信号の品質を測定し、分解を検出するため）をサポートします。
To support fast recovery, it is useful to use some of the proactive tools to detect fault conditions (e.g., link/node failure or degradation) and to trigger the recovery action.
迅速な回復をサポートするために、いくつかの積極的なツールを使用して、障害条件（リンク/ノードの障害や分解など）を検出し、回復作用をトリガーすることが役立ちます。
The MPLS-TP OAM messages run in-band with the traffic and support unidirectional and bidirectional P2P paths as well as P2MP paths.
MPLS-TP OAMメッセージは、トラフィックで帯域内で実行され、P2MPパスと同様に一方向および双方向のP2Pパスをサポートします。
As described in [RFC6371], MPLS-TP OAM operates in the context of a Maintenance Entity that borders on the OAM responsibilities and represents the portion of a path between two points that is monitored and maintained, and along which OAM messages are exchanged. [RFC6371] refers also to a Maintenance Entity Group (MEG), which is a collection of one or more Maintenance Entities (MEs) that belong to the same transport path (e.g., P2MP transport path) and which are maintained and monitored as a group.
[RFC6371]で説明されているように、MPLS-TP OAMは、OAMの責任に隣接し、監視および維持されている2つのポイント間のパスの部分を表すメンテナンスエンティティのコンテキストで動作し、OAMメッセージが交換されます。[RFC6371]は、同じ輸送経路（P2MP輸送経路など）に属する1つ以上のメンテナンスエンティティ（ME）のコレクションであり、グループとして維持および監視されるメンテナンスエンティティグループ（MEG）を指します。。
An ME includes two MEPs (Maintenance Entity Group End Points) that reside at the boundaries of an ME, and a set of zero or more MIPs (Maintenance Entity Group Intermediate Points) that reside within the Maintenance Entity along the path. A MEP is capable of initiating and terminating OAM messages, and as such can only be located at the edges of a path where push and pop operations are supported. In order to define an ME over a portion of path, it is necessary to support SPMEs.
MEには、MEの境界に存在する2つのMEP（メンテナンスエンティティグループエンドポイント）と、パスに沿ってメンテナンスエンティティ内に存在するゼロ以上のMIPS（メンテナンスエンティティグループの中間点）のセットが含まれています。MEPはOAMメッセージを開始および終了することができるため、プッシュおよびポップ操作がサポートされているパスの端にのみ配置できます。パスの一部に私を定義するには、SPMESをサポートする必要があります。
The SPME is an end-to-end LSP that in this context corresponds to the ME; it uses the MPLS construct of hierarchical nested LSPs, which is defined in [RFC3031]. OAM messages can be initiated at the edge of the SPME and sent over G-ACH to the peer edge of the SPME.
SPMEは、この文脈でMEに対応するエンドツーエンドのLSPです。[RFC3031]で定義されている階層ネストLSPのMPLSコンストラクトを使用します。OAMメッセージは、SPMEの端で開始し、G-achを介してSPMEのピアエッジに送信できます。
The related SPMEs must be configured, and mapping must be performed between the LSP segments being monitored and the SPME. Mapping can be 1:1 or 1:N to allow scalable operation. Note that each of these
関連するSPMEを構成する必要があり、監視対象のLSPセグメント間でマッピングを実行する必要があります。マッピングは、スケーラブルな動作を可能にするために1：1または1：nにすることができます。これらのそれぞれに注意してください
LSPs can be initiated or terminated at different end points in the network and can share similar constraints (such as requirements for QoS, terms of protection, etc.).
LSPは、ネットワーク内の異なるエンドポイントで開始または終了することができ、同様の制約（QoS、保護条件などの要件など）を共有できます。
With regard to recovery, where MPLS-TP OAM is supported, an OAM Maintenance Entity Group is defined for each of the working and protection entities.
MPLS-TP OAMがサポートされている回復に関しては、作業および保護エンティティごとにOAMメンテナンスエンティティグループが定義されています。
MPLS-TP OAM tools may be used proactively to detect the following fault conditions between MEPs:
MPLS-TP OAMツールは、MEP間の次の障害条件を検出するために積極的に使用できます。
o Loss of continuity and misconnectivity - the proactive Continuity Check (CC) function is used to detect loss of continuity between two MEPs in an MEG. The proactive Connectivity Verification (CV) allows a sink MEP to detect a misconnectivity defect (e.g., mismerge or misconnection) with its peer source MEP when the received packet carries an incorrect ME identifier. For protection switching, it is common to run a CC-V (Continuity Check and Connectivity Verification) message every 3.33 ms. In the absence of three consecutive CC-V messages, loss of continuity is declared and is notified locally to the edge of the recovery domain in order to trigger a recovery action. In some cases, when a slower recovery time is acceptable, it is also possible to lengthen the transmission rate.
o 連続性の喪失と誤解 - プロアクティブ連続性チェック（CC）関数を使用して、MEGの2つのMEP間の連続性の損失を検出します。プロアクティブ接続検証（CV）により、シンクMEPは、受け取ったパケットに誤ったME識別子を担当する場合、ピアソースMEPを使用して、ミス接続性欠陥（例えば、誤ったまたは誤った接続）を検出できます。保護スイッチングの場合、3.33ミリ秒ごとにCC-V（連続性チェックおよび接続検証）メッセージを実行することが一般的です。3つの連続したCC-Vメッセージがない場合、連続性の損失が宣言され、回復アクションをトリガーするために回復ドメインの端までローカルに通知されます。場合によっては、回復時間が遅い場合、送信速度を延長することもできます。
o Signal degradation - notification from OAM performance monitoring indicating degradation in the working entity may also be used as a trigger for protection switching. In the event of degradation, switching to the recovery entity is necessary only if the recovery entity can guarantee better conditions. Degradation can be measured by proactively activating MPLS-TP OAM packet loss measurement or delay measurement.
o 信号の劣化 - 作業エンティティの劣化を示すOAMパフォーマンス監視からの通知は、保護スイッチングのトリガーとしても使用される場合があります。劣化が発生した場合、回復エンティティがより良い条件を保証できる場合にのみ、回復エンティティへの切り替えが必要です。分解は、MPLS-TP OAMパケット損失測定または遅延測定を積極的に活性化することにより測定できます。
o A MEP can receive an indication from its sink MEP of a Remote Defect Indication and locally notify the end point of the recovery domain regarding the fault condition, in order to trigger the recovery action.
o MEPは、リモート欠陥の表示のシンクMEPから表示を受け取り、回復アクションをトリガーするために、障害状態に関する回復ドメインのエンドポイントをローカルに通知できます。
The management plane may be used to initiate the testing of links, LSP segments, or entire LSPs.
管理プレーンは、リンク、LSPセグメント、またはLSP全体のテストを開始するために使用できます。
MPLS-TP provides OAM tools that may be manually invoked on-demand for a limited period, in order to troubleshoot links, LSP segments, or entire LSPs (e.g., diagnostics, connectivity verification, packet
MPLS-TPは、リンク、LSPセグメント、またはLSP全体（診断、接続性の確認、パケットなどのトラブルシューティングのために、限られた期間オンデマンドで手動で呼び出される可能性のあるOAMツールを提供します。
loss measurements, etc.). On-demand monitoring covers a combination of "in-service" and "out-of-service" monitoring functions. Out-of-service testing is supported by the OAM on-demand lock operation. The lock operation temporarily disables the transport entity (LSP, LSP segment, or link), preventing the transmission of all types of traffic, with the exceptions of test traffic and OAM (dedicated to the locked entity).
損失測定など）。オンデマンドモニタリングは、「インサービス」と「サービス外」の監視機能の組み合わせをカバーしています。サービス外テストは、OAMオンデマンドロック操作によってサポートされています。ロック操作は、輸送エンティティ（LSP、LSPセグメント、またはリンク）を一時的に無効にし、テストトラフィックとOAM（ロックされたエンティティ専用）を除き、あらゆる種類のトラフィックの送信を防ぎます。
[RFC6371] describes the operations of the OAM functions that may be initiated on-demand and provides some considerations.
[RFC6371]は、オンデマンドで開始される可能性のあるOAM関数の操作を説明し、いくつかの考慮事項を提供します。
MPLS-TP also supports in-service and out-of-service testing of the recovery (protection and restoration) mechanism, the integrity of the protection/recovery transport paths, and the coordination protocol between the end points of the recovery domain. The testing operation emulates a protection-switching request but does not perform the actual switching action.
MPLS-TPは、回復（保護と回復）メカニズム、保護/回復輸送パスの整合性、および回復ドメインのエンドポイント間の調整プロトコルのサービス内およびサービス外テストもサポートしています。テスト操作は保護スイッチングリクエストをエミュレートしますが、実際の切り替えアクションは実行されません。
MPLS-TP provides OAM tools to locate a fault and determine its precise location. Fault detection often only takes place at key points in the network (such as at LSP end points or at MEPs). This means that a fault may be located anywhere within a segment of the relevant LSP. Finer information granularity is needed to implement optimal recovery actions or to diagnose the fault. On-demand tools like trace-route, loopback, and on-demand CC-V can be used to localize a fault.
MPLS-TPは、障害を見つけて正確な場所を決定するためのOAMツールを提供します。障害検出は、多くの場合、ネットワークのキーポイント（LSPエンドポイントやMEPSなど）でのみ行われます。これは、障害が関連するLSPのセグメント内のどこにでも配置される可能性があることを意味します。最適な回復アクションを実装したり、障害を診断するには、より細かい情報の粒度が必要です。Trace-Route、Loopback、オンデマンドCC-Vなどのオンデマンドツールを使用して、障害をローカライズできます。
The information may be notified locally to the end point of the recovery domain to allow implementation of optimal recovery action. This may be useful for the re-calculation of a recovery path.
情報は、最適な回復アクションの実装を可能にするために、回復ドメインのエンドポイントまでローカルに通知される場合があります。これは、回復パスの再計算に役立つ場合があります。
The information should also be reported to network management for diagnostic purposes.
情報は、診断目的でネットワーク管理にも報告する必要があります。
The end points of a recovery domain should be able to detect fault conditions in the recovery domain and to notify the management plane.
回復ドメインのエンドポイントは、回復ドメインの障害条件を検出し、管理プレーンに通知できる必要があります。
In addition, a node within a recovery domain that detects a fault condition should also be able to report this to network management. Network management should be capable of correlating the fault reports and identifying the source of the fault.
さらに、障害状態を検出する回復ドメイン内のノードも、これをネットワーク管理に報告できるはずです。ネットワーク管理は、障害レポートを相関させ、障害の原因を特定できる必要があります。
MPLS-TP OAM tools support a function where an intermediate node along a path is able to send an alarm report message to the MEP, indicating
MPLS-TP OAMツールは、パスに沿った中間ノードがMEPにアラームレポートメッセージを送信し、示す関数をサポートしています。
the presence of a fault condition in the server layer that connects it to its adjacent node. This capability allows a MEP to suppress alarms that may be generated as a result of a failure condition in the server layer.
サーバーレイヤーに障害状態が存在することは、隣接するノードに接続します。この機能により、MEPは、サーバーレイヤーの障害条件の結果として生成される可能性のあるアラームを抑制できます。
As described above, in some cases (such as in bidirectional protection switching, etc.) it is necessary to coordinate the protection states between the edges of the recovery domain. [MPLS-TP-LP] defines procedures, protocol messages, and elements for this purpose.
上記のように、場合によっては（双方向保護スイッチングなど）、回復ドメインのエッジ間で保護状態を調整する必要があります。[MPLS-TP-LP]この目的のための手順、プロトコルメッセージ、および要素を定義します。
The protocol is also used to signal administrative requests (e.g., manual switch, etc.), but only when these are provisioned at the edge of the recovery domain.
このプロトコルは、管理要求（手動スイッチなど）を通知するためにも使用されますが、これらが回復ドメインの端でプロビジョニングされている場合にのみ使用されます。
The protocol also enables mismatches to be detected between the configurations at the ends of the protection domain (such as timers, revertive/non-revertive behavior); these mismatches can subsequently be reported to the management plane.
また、プロトコルは、保護ドメインの終わり（タイマー、リバート/非反転挙動など）の構成間で不一致を検出できるようにします。これらの不一致は、その後、管理面に報告できます。
In the absence of suitable coordination (owing to failures in the delivery or processing of the coordination protocol messages), protection switching will fail. This means that the operation of the protocol that coordinates the protection state is a fundamental part of protection switching.
適切な調整がない場合（調整プロトコルメッセージの配信または処理の障害により）、保護の切り替えは失敗します。これは、保護状態を調整するプロトコルの動作が保護スイッチングの基本的な部分であることを意味します。
The GMPLS control plane has been proposed as the control plane for MPLS-TP [RFC5317]. Since GMPLS was designed for use in transport networks, and since it has been implemented and deployed in many networks, it is not surprising that it contains many features that support a high degree of survivability.
GMPLSコントロールプレーンは、MPLS-TP [RFC5317]のコントロールプレーンとして提案されています。GMPLSは輸送ネットワークで使用するように設計されており、多くのネットワークで実装および展開されているため、高度な生存性をサポートする多くの機能が含まれていることは驚くことではありません。
The signaling elements of the GMPLS control plane utilize extensions to the Resource Reservation Protocol (RSVP) (as described in a series of documents commencing with [RFC3471] and [RFC3473]), although it is based on [RFC3209] and [RFC2205]. The architecture for GMPLS is provided in [RFC3945], while [RFC4426] gives a functional description of the protocol extensions needed to support GMPLS-based recovery (i.e., protection and restoration).
GMPLSコントロールプレーンのシグナル要素は、[RFC3209]および[RFC2205]に基づいていますが、リソース予約プロトコル（RSVP）（[RFC3471]および[RFC3473]から始まる一連のドキュメントで説明されている）に拡張機能を使用します。GMPLSのアーキテクチャは[RFC3945]で提供され、[RFC4426]はGMPLSベースの回復（つまり、保護と修復）をサポートするために必要なプロトコル拡張の機能的な説明を提供します。
A further control-plane protocol called the Link Management Protocol (LMP) [RFC4204] is part of the GMPLS protocol family and can be used to coordinate fault localization and reporting.
リンク管理プロトコル（LMP）[RFC4204]と呼ばれるさらなるコントロールプレーンプロトコルは、GMPLSプロトコルファミリーの一部であり、障害のローカリゼーションとレポートの調整に使用できます。
Clearly, the control-plane techniques described here only apply where an MPLS-TP control plane is deployed and operated. All mandatory MPLS-TP survivability features must be enabled, even in the absence of the control plane. However, when present, the control plane may be used to provide alternative mechanisms that may be desirable, since they offer simple automation or a richer feature set.
明らかに、ここで説明するコントロールプレーン技術は、MPLS-TPコントロールプレーンが展開および操作されている場合にのみ適用されます。コントロールプレーンがない場合でも、すべての必須のMPLS-TPサバイバビリティ機能を有効にする必要があります。ただし、存在する場合、コントロールプレーンを使用して、単純な自動化またはより豊富な機能セットを提供するため、望ましい可能性のある代替メカニズムを提供することができます。
The control plane is unable to detect data-plane faults. However, it does provide mechanisms that detect control-plane faults, and these can be used to recognize data-plane faults when it is evident that the control and data planes are fate-sharing. Although [RFC5654] specifies that MPLS-TP must support an out-of-band control channel, it does not insist that it be used exclusively. This means that there may be deployments where an in-band (or at least an in-fiber) control channel is used. In this scenario, failure of the control channel can be used to infer that there is a failure of the data channel, or, at least, it can be used to trigger an investigation of the health of the data channel.
コントロールプレーンは、データプレーン障害を検出できません。ただし、制御面障害を検出するメカニズムを提供し、これらを使用して、コントロールプレーンとデータプレーンが運命共有であることが明らかな場合にデータ面障害を認識することができます。[RFC5654]は、MPLS-TPがバンド外の制御チャネルをサポートする必要があることを指定していますが、それが排他的に使用されることを主張していません。これは、インバンド（または少なくとも繊維内）制御チャネルが使用される展開があることを意味します。このシナリオでは、制御チャネルの障害を使用して、データチャネルの障害があることを推測することができます。少なくとも、データチャネルの健康の調査をトリガーするために使用できます。
Both RSVP and LMP provide a control channel "keep-alive" mechanism (called the Hello message in both cases). Failure to receive a message in the configured/negotiated time period indicates a control-plane failure. GMPLS routing protocols ([RFC4203] and [RFC5307]) also include keep-alive mechanisms designed to detect routing adjacency failures. Although these keep-alive mechanisms tend to operate at a relatively low frequency (on the order of seconds), it is still possible that the first indication of a control-plane fault will be received through the routing protocol.
RSVPとLMPの両方が、制御チャネルの「キープアライブ」メカニズムを提供します（どちらの場合もHelloメッセージと呼ばれます）。構成/交渉された期間でメッセージを受信しないと、コントロールプレーンの障害が示されます。GMPLSルーティングプロトコル（[RFC4203]および[RFC5307]）には、ルーティングの隣接障害を検出するように設計されたキープアライブメカニズムも含まれています。これらのキープアライブメカニズムは、比較的低い周波数で動作する傾向がありますが（秒程度）、制御面障害の最初の兆候がルーティングプロトコルを介して受信される可能性があります。
Note, however, that care must be taken to ascertain that a specific failure is not caused by a problem in the control-plane software or in a processor component at the far end of a link.
ただし、特定の障害がコントロールプレーンソフトウェアまたはリンクの遠端にあるプロセッサコンポーネントの問題によって引き起こされないことを確認するために注意する必要があることに注意してください。
Because of the various issues involved, it is not recommended that the control plane be used as the primary mechanism for fault detection in an MPLS-TP network.
関係するさまざまな問題のため、MPLS-TPネットワークでの障害検出の主要なメカニズムとして制御面を使用することは推奨されません。
The control plane may be used to initiate and coordinate the testing of links, LSP segments, or entire LSPs. This is important in some technologies where it is necessary to halt data transmission while testing, but it may also be useful where testing needs to be specifically enabled or configured.
コントロールプレーンは、リンク、LSPセグメント、またはLSP全体のテストを開始および調整するために使用できます。これは、テスト中にデータ送信を停止する必要があるいくつかのテクノロジーでは重要ですが、テストを特別に有効または構成する必要がある場合にも役立つ場合があります。
LMP provides a control-plane mechanism to test the continuity and connectivity (and naming) of individual links. A single management operation is required to initiate the test at one end of the link, while the LMP handles the coordination with the other end of the link. The test mechanism for an MPLS packet link relies on the LMP Test message inserted into the data stream at one end of the link and extracted at the other end of the link. This mechanism need not disrupt data flowing over the link.
LMPは、個々のリンクの連続性と接続性（および命名）をテストするための制御面メカニズムを提供します。LMPはリンクの一方の端でテストを開始するには、単一の管理操作が必要です。LMPは、リンクのもう一方の端との調整を処理します。MPLSパケットリンクのテストメカニズムは、リンクの一方の端にあるデータストリームに挿入され、リンクのもう一方の端で抽出されたLMPテストメッセージに依存しています。このメカニズムは、リンク上に流れるデータを破壊する必要はありません。
Note that a link in the LMP may, in fact, be an LSP tunnel used to form a link in the MPLS-TP network.
LMPのリンクは、実際、MPLS-TPネットワークにリンクを形成するために使用されるLSPトンネルである可能性があることに注意してください。
GMPLS signaling (RSVP) offers two mechanisms that may also assist with fault testing. The first mechanism [RFC3473] defines the Admin_Status object that allows an LSP to be set into "testing mode". The interpretation of this mode is implementation-specific and could be documented more precisely for MPLS-TP. The mode sets the whole LSP into a state where it can be tested; this need not be disruptive to data traffic.
GMPLSシグナリング（RSVP）は、障害検査を支援する可能性のある2つのメカニズムを提供します。最初のメカニズム[RFC3473]は、LSPを「テストモード」に設定できるようにするadmin_statusオブジェクトを定義します。このモードの解釈は実装固有であり、MPLS-TPについてより正確に文書化できます。このモードは、LSP全体をテストできる状態に設定します。これは、データトラフィックを破壊する必要はありません。
The second mechanism provided by GMPLS to support testing is described in [GMPLS-OAM]. This protocol extension supports the configuration (including enabling and disabling) of OAM mechanisms for a specific LSP.
テストをサポートするためにGMPLSによって提供される2番目のメカニズムは、[GMPLS-OAM]で説明されています。このプロトコル拡張は、特定のLSPのOAMメカニズムの構成（有効化と無効化を含む）をサポートします。
Fault localization is the process whereby the exact location of a fault is determined. Fault detection often only takes place at key points in the network (such as at LSP end points or at MEPs). This means that a fault may be located anywhere within a segment of the relevant LSP.
障害のローカリゼーションは、障害の正確な位置が決定されるプロセスです。障害検出は、多くの場合、ネットワークのキーポイント（LSPエンドポイントやMEPSなど）でのみ行われます。これは、障害が関連するLSPのセグメント内のどこにでも配置される可能性があることを意味します。
If segment or end-to-end protection is in use, this level of information is often sufficient to repair the LSP. However, if finer information granularity is required (either to implement optimal recovery actions or to diagnose a fault), it is necessary to localize the specific fault.
セグメントまたはエンドツーエンドの保護が使用されている場合、このレベルの情報はLSPを修復するのに十分な場合が多いです。ただし、より細かい情報の粒度が必要な場合（最適な回復アクションを実装するか、障害を診断するために）、特定の障害をローカライズする必要があります。
LMP provides a cascaded test-and-propagate mechanism that is designed specifically for this purpose.
LMPは、この目的のために特別に設計されたカスケードテストアンドプロパゲートメカニズムを提供します。
GMPLS signaling uses the Notify message to report fault status [RFC3473]. The Notify message can apply to a single LSP or can carry fault information for a set of LSPs, in order to improve the scalability of fault notification.
GMPLSシグナル伝達は、Notifyメッセージを使用して障害ステータス[RFC3473]を報告します。Notifyメッセージは、障害通知のスケーラビリティを改善するために、単一のLSPに適用するか、LSPのセットに障害情報を携帯することができます。
Since the Notify message is targeted at a specific node, it can be delivered rapidly without requiring hop-by-hop processing. It can be targeted at LSP end points or at segment end points (such as MEPs). The target points for Notify messages can be manually configured within the network, or they may be signaled when the LSP is set up.
Notifyメッセージは特定のノードをターゲットにしているため、ホップバイホップ処理を必要とせずに迅速に配信できます。LSPエンドポイントまたはセグメントエンドポイント（MEPなど）をターゲットにすることができます。Notifyメッセージのターゲットポイントは、ネットワーク内で手動で構成することも、LSPが設定されたときに信号を送信することもできます。
This enables the process to be made consistent with segment protection as well as with the concept of Maintenance Entities.
これにより、プロセスをセグメント保護とメンテナンスエンティティの概念と一致させることができます。
GMPLS signaling also provides a slower, hop-by-hop mechanism for reporting individual LSP faults on a hop-by-hop basis using PathErr and ResvErr messages.
GMPLSシグナリングは、PatherrおよびResverrメッセージを使用して、ホップバイホップベースで個々のLSP障害を報告するための遅いホップバイホップメカニズムも提供します。
[RFC4783] provides a mechanism to coordinate alarms and other event or fault information through GMPLS signaling. This mechanism is useful for understanding the status of the resources used by an LSP and for providing information as to why an LSP is not functioning; however, it is not intended to replace other fault-reporting mechanisms.
[RFC4783]は、GMPLSシグナリングを通じてアラームやその他のイベントまたは障害情報を調整するメカニズムを提供します。このメカニズムは、LSPが使用するリソースのステータスを理解し、LSPが機能していない理由に関する情報を提供するのに役立ちます。ただし、他の障害報告メカニズムを置き換えることは意図されていません。
GMPLS routing protocols [RFC4203] and [RFC5307] are used to advertise link availability and capabilities within a GMPLS-enabled network. Thus, the routing protocols can also provide indirect information about network faults; that is, the protocol may stop advertising or may withdraw the advertisement for a failed link, or it may advertise that the link is about to be shut down gracefully [RFC5817]. This mechanisms is, however, not normally considered to be fast enough for use as a trigger for protection switching.
GMPLSルーティングプロトコル[RFC4203]および[RFC5307]は、GMPLS対応ネットワーク内のリンクの可用性と機能を宣伝するために使用されます。したがって、ルーティングプロトコルは、ネットワーク障害に関する間接的な情報を提供することもできます。つまり、プロトコルは広告を停止するか、失敗したリンクの広告を撤回するか、リンクが優雅にシャットダウンしようとしていることを広告する場合があります[RFC5817]。ただし、このメカニズムは、通常、保護スイッチングのトリガーとして使用するのに十分な速度であるとは考えられていません。
Fault coordination is an important feature for certain protection mechanisms (such as bidirectional 1:1 protection). The use of the GMPLS Notify message for this purpose is described in [RFC4426]; however, specific message field values have not yet been defined for this operation.
障害調整は、特定の保護メカニズム（双方向1：1保護など）の重要な機能です。この目的のためにGMPLS通知メッセージの使用は[RFC4426]で説明されています。ただし、この操作では、特定のメッセージフィールド値はまだ定義されていません。
Further work is needed in GMPLS for control and configuration of reversion behavior for end-to-end and segment protection, and the coordination of timer values.
エンドツーエンドおよびセグメント保護のためのリバージョン動作の制御と構成、およびタイマー値の調整のためのGMPLSでは、さらなる作業が必要です。
The management plane may be used to set up protection and recovery LSPs, but, when present, the control plane may be used.
管理プレーンは、保護および回復LSPをセットアップするために使用できますが、存在する場合、コントロールプレーンを使用できます。
Several protocol extensions exist that simplify this process:
このプロセスを簡素化するいくつかのプロトコル拡張機能が存在します。
o [RFC4872] provides features that support end-to-end protection switching.
o [RFC4872]は、エンドツーエンドの保護スイッチングをサポートする機能を提供します。
o [RFC4873] describes the establishment of a single, segment-protected LSP. Note that end-to-end protection is a special case of segment protection, and [RFC4872] can also be used to provide end-to-end protection.
o [RFC4873]は、単一のセグメントで保護されたLSPの確立について説明しています。エンドツーエンドの保護はセグメント保護の特別なケースであり、[RFC4872]を使用してエンドツーエンドの保護を提供できることに注意してください。
o [RFC4874] allows an LSP to be signaled with a request that its path exclude specified resources such as links, nodes, and shared risk link groups (SRLGs). This allows a disjoint protection path to be requested or a recovery path to be set up to avoid failed resources.
o [RFC4874]は、リンク、ノード、共有リスクリンクグループ（SRLG）などの指定されたリソースを除外するパスを除外するという要求でLSPを信号することができます。これにより、失敗したリソースを回避するために、馬鹿げた保護パスを要求するか、回復パスを設定できます。
o Lastly, it should be noted that [RFC5298] provides an overview of the GMPLS techniques available to achieve protection in multi-domain environments.
o 最後に、[RFC5298]は、マルチドメイン環境で保護を実現するために利用可能なGMPLS技術の概要を提供することに注意する必要があります。
Pseudowires provide end-to-end connectivity over the MPLS-TP network and may comprise a single pseudowire segment, or multiple segments "stitched" together to provide end-to-end connectivity.
Pseudowiresは、MPLS-TPネットワーク上でエンドツーエンドの接続を提供し、単一の擬似ワイヤーセグメント、またはエンドツーエンドの接続を提供するために「ステッチされた」複数のセグメントを構成する場合があります。
The pseudowire may, itself, require protection, in order to meet the service-level guarantees of its SLA. This protection could be provided by the MPLS-TP LSPs that support the pseudowire, or could be a feature of the pseudowire layer itself.
擬似ワイヤー自体は、SLAのサービスレベルの保証を満たすために、保護を必要とする場合があります。この保護は、擬似ワイヤをサポートするMPLS-TP LSPによって提供されるか、擬似層自体の特徴である可能性があります。
As indicated above, the functional architecture described in this document applies to both LSPs and pseudowires. However, the recovery mechanisms for pseudowires are for further study and will be defined in a separate document by the PWE3 working group.
上記のように、このドキュメントで説明されている機能アーキテクチャは、LSPと擬似動物の両方に適用されます。ただし、擬似動物の回復メカニズムはさらなる研究のためであり、PWE3ワーキンググループによって別の文書で定義されます。
MPLS-TP PWs are carried across the network inside MPLS-TP LSPs. Therefore, an obvious way to provide protection for a PW is to protect the LSP that carries it. Such protection can take any of the forms described in this document. The choice of recovery scheme will depend on the required speed of recovery and the traffic loss that is acceptable for the SLA that the PW is providing.
MPLS-TP PWSは、MPLS-TP LSP内のネットワークを介して運ばれます。したがって、PWを保護する明白な方法は、それを運ぶLSPを保護することです。このような保護は、このドキュメントに記載されているフォームのいずれかをとることができます。回復スキームの選択は、必要な回復速度と、PWが提供しているSLAに受け入れられる交通量の損失に依存します。
If the PW is a Multi-Segment PW, then LSP recovery can only protect the PW in individual segments. This means that a single LSP recovery action cannot protect against a failure of a PW switching point (an
PWがマルチセグメントPWである場合、LSP回復は個々のセグメントのPWのみを保護できます。これは、単一のLSPリカバリアクションがPWスイッチングポイントの障害から保護できないことを意味します（
S-PE), nor can it protect more than one segment at a time, since the LSP tunnel is terminated at each S-PE. In this respect, LSP protection of a PW is very similar to link-level protection offered to the MPLS-TP LSP layer by an underlying network layer (see Section 4.9).
s-Pe）は、LSPトンネルが各S-PEで終了するため、一度に複数のセグメントを保護することもできません。この点で、PWのLSP保護は、基礎となるネットワーク層によってMPLS-TP LSP層に提供されるリンクレベルの保護と非常に似ています（セクション4.9を参照）。
Recovery in the PW layer can be provided by simply running separate PWs end-to-end. Other recovery mechanisms in the PW layer, such as segment or concatenated segment recovery, or service-level recovery involving survivability of T-PE or AC faults will be described in a separate document.
PW層の回復は、個別のPWSエンドツーエンドを実行するだけで提供できます。セグメントや連結セグメントの回復、またはT-PEまたはAC障害の生存可能性を含むサービスレベルの回復など、PW層の他の回復メカニズムについては、別のドキュメントに記載されています。
As with any recovery mechanism, it is important to coordinate between layers. This coordination is necessary to ensure that actions associated with recovery mechanisms are only performed in one layer at a time (that is, the recovery of an underlying LSP needs to be coordinated with the recovery of the PW itself). It also makes sure that the working and protection PWs do not both use the same MPLS resources within the network (for example, by running over the same LSP tunnel; see also Section 4.9).
回復メカニズムと同様に、レイヤー間を調整することが重要です。この調整は、回復メカニズムに関連するアクションが一度に1つの層でのみ実行されることを保証するために必要です（つまり、基礎となるLSPの回復をPW自体の回復と調整する必要があります）。また、作業と保護のPWが両方ともネットワーク内の同じMPLSリソースを使用しないことを確認します（たとえば、同じLSPトンネルを実行することで、セクション4.9も参照）。
Manageability of MPLS-TP networks and their functions is discussed in [RFC5950]. OAM features are discussed in [RFC6371].
MPLS-TPネットワークとその機能の管理可能性については、[RFC5950]で説明しています。OAM機能については、[RFC6371]で説明しています。
Survivability has some key interactions with management, as described in this document. In particular:
このドキュメントで説明されているように、サバイバビリティには管理との重要な相互作用があります。特に：
o Recovery domains may be configured in a way that prevents one-to-one correspondence between the MPLS-TP network and the recovery domains.
o 回復ドメインは、MPLS-TPネットワークと回復ドメインの間の1対1の対応を防ぐ方法で構成できます。
o Survivability policies may be configured per network, per recovery domain, or per LSP.
o 生存可能性ポリシーは、ネットワーク、回復ドメインごと、またはLSPごとに構成できます。
o Configuration of OAM may involve the selection of MEPs; enabling OAM on network segments, spans, and links; and the operation of OAM on LSPs, concatenated LSP segments, and LSP segments.
o OAMの構成には、MEPの選択が含まれる場合があります。ネットワークセグメント、スパン、およびリンクでOAMを有効にする。LSP、連結LSPセグメント、およびLSPセグメントでのOAMの動作。
o Manual commands may be used to control recovery functions, including forcing recovery and locking recovery actions.
o 手動コマンドは、回復の強制や回復アクションのロックなど、回復機能を制御するために使用できます。
See also the considerations regarding security for management and OAM in Section 9 of this document.
このドキュメントのセクション9の管理とOAMに関するセキュリティに関する考慮事項も参照してください。
This framework does not introduce any new security considerations; general issues relating to MPLS security can be found in [RFC5920].
このフレームワークでは、新しいセキュリティ上の考慮事項は導入されません。MPLSセキュリティに関連する一般的な問題は、[RFC5920]に記載されています。
However, several points about MPLS-TP survivability should be noted here.
ただし、MPLS-TPの生存性に関するいくつかのポイントは、ここで注意する必要があります。
o If an attacker is able to force a protection switch-over, this may result in a small perturbation to user traffic and could result in extra traffic being preempted or displaced from the protection resources. In the case of 1:n protection or shared mesh protection, this may result in other traffic becoming unprotected. Therefore, it is important that OAM protocols for detecting or notifying faults use adequate security to prevent them from being used (through the insertion of bogus messages or through the capture of legitimate messages) to falsely trigger a recovery event.
o 攻撃者が保護スイッチオーバーを強制することができる場合、これによりユーザートラフィックがわずかに摂動する可能性があり、追加のトラフィックが予約または保護リソースから追放される可能性があります。1：n保護または共有メッシュ保護の場合、これにより他のトラフィックが保護されていない可能性があります。したがって、障害を検出または通知するためのOAMプロトコルは、適切なセキュリティを使用してそれらを使用するのを防ぐことが重要です（偽のメッセージの挿入を介して、または合法的なメッセージのキャプチャを介して）回復イベントを誤ってトリガーすることが重要です。
o If manual commands are modified, captured, or simulated (including replay), it might be possible for an attacker to perform forced recovery actions or to impose lock-out. These actions could impact the capability to provide the recovery function and could also affect the normal operation of the network for other traffic. Therefore, management protocols used to perform manual commands must allow the operator to use appropriate security mechanisms. This includes verification that the user who performs the commands has appropriate authorization.
o 手動コマンドが変更、キャプチャ、またはシミュレートされている場合（リプレイを含む）、攻撃者が強制回復アクションを実行したり、ロックアウトを課したりすることが可能かもしれません。これらのアクションは、回復機能を提供する機能に影響を与える可能性があり、他のトラフィックのネットワークの通常の動作にも影響を与える可能性があります。したがって、手動コマンドを実行するために使用される管理プロトコルは、オペレーターが適切なセキュリティメカニズムを使用できるようにする必要があります。これには、コマンドを実行するユーザーが適切な承認があることの確認が含まれます。
o If the control plane is used to configure or operate recovery mechanisms, the control-plane protocols must also be capable of providing adequate security.
o コントロールプレーンが回復メカニズムの構成または操作に使用される場合、コントロールプレーンプロトコルも適切なセキュリティを提供できる必要があります。
Thanks to the following people for useful comments and discussions: Italo Busi, David McWalter, Lou Berger, Yaacov Weingarten, Stewart Bryant, Dan Frost, Lievren Levrau, Xuehui Dai, Liu Guoman, Xiao Min, Daniele Ceccarelli, Scott Bradner, Francesco Fondelli, Curtis Villamizar, Maarten Vissers, and Greg Mirsky.
有用なコメントとディスカッションについては、次の人々に感謝します：イタロBUSI、デビッドマクウォルター、ルーベルガー、ヤコフウェインガーテン、スチュワートブライアント、ダンフロスト、リーヴレンレヴラウ、Xuehui Dai、Liu Guoman、Xiao Min、Daniele Ceccarelli、Scott Bradner、Francesco Fondelli、カーティス・ヴィラミザ、マルテン・ヴィッサー、グレッグ・ミルスキー。
The Editors would like to thank the participants in ITU-T Study Group 15 for their detailed review.
編集者は、詳細なレビューについてITU-T研究グループ15の参加者に感謝します。
Some figures and text on shared mesh protection were borrowed from [MPLS-TP-MESH] with thanks to Tae-sik Cheung and Jeong-dong Ryoo.
Tae-Sik CheungとJeong-Dong Ryooに感謝して、[MPLS-TP-Mesh]から共有メッシュ保護に関するいくつかの数字とテキストが借りられました。
[G.806] ITU-T, "Characteristics of transport equipment - Description methodology and generic functionality", Recommendation G.806, January 2009.
[G.806] ITU -T、「輸送機器の特性 - 説明方法と一般的な機能性」、推奨G.806、2009年1月。
[G.808.1] ITU-T, "Generic Protection Switching - Linear trail and subnetwork protection", Recommendation G.808.1, December 2003.
[G.808.1] ITU -T、「一般的な保護スイッチング - 線形トレイルとサブネットワーク保護」、推奨G.808.1、2003年12月。
[G.841] ITU-T, "Types and Characteristics of SDH Network Protection Architectures", Recommendation G.841, October 1998.
[G.841] ITU-T、「SDHネットワーク保護アーキテクチャの種類と特性」、推奨G.841、1998年10月。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205] Braden、R.、Ed。、Zhang、L.、Berson、S.、Herzog、S.、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、9月1997年。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、 "RSVP-TE：LSP TunnelsのRSVPへの拡張"、RFC 3209、12月2001年。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナル伝達機能説明」、RFC 3471、2003年1月。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリングリソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）拡張」、RFC 3473、2003年1月。
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945] Mannie、E.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）アーキテクチャ」、RFC 3945、2004年10月。
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005.
[RFC4203] Kompella、K.、ed。、およびY. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートするOSPF拡張」、RFC 4203、2005年10月。
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, October 2005.
[RFC4204] Lang、J.、ed。、「Link Management Protocol（LMP）」、RFC 4204、2005年10月。
[RFC4427] Mannie, E., Ed., and D. Papadimitriou, Ed., "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, March 2006.
[RFC4427] Mannie、E.、ed。、およびD. Papadimitriou、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）のリカバリ（保護および回復）用語」、RFC 4427、2006年3月。
[RFC4428] Papadimitriou, D., Ed., and E. Mannie, Ed., "Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration)", RFC 4428, March 2006.
[RFC4428] Papadimitriou、D.、ed。、およびE. Mannie、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）ベースの回復メカニズム（保護と修復を含む）の分析」、RFC 4428、2006年3月。
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007.
[RFC4873] Berger、L.、Bryskin、I.、Papadimitriou、D。、およびA. Farrel、「Gmplsセグメントリカバリー」、RFC 4873、2007年5月。
[RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, October 2008.
[RFC5307] Kompella、K.、ed。、およびY. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートするIS-IS拡張機能」、RFC 5307、2008年10月。
[RFC5317] Bryant, S., Ed., and L. Andersson, Ed., "Joint Working Team (JWT) Report on MPLS Architectural Considerations for a Transport Profile", RFC 5317, February 2009.
[RFC5317] Bryant、S.、ed。、およびL. Andersson、ed。、「輸送プロファイルのMPLSアーキテクチャに関する考慮事項に関する共同作業チーム（JWT）レポート」、RFC 5317、2009年2月。
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, June 2009.
[RFC5586] Bocci、M.、Ed。、Vigoureux、M.、ed。、およびS. Bryant、ed。、「Mpls Generic Associated Channel」、RFC 5586、2009年6月。
[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009.
[RFC5654] Niven-Jenkins、B.、Ed。、Brungard、D.、Ed。、Betts、M.、Ed。、Sprecher、N.、およびS. Ueno、「MPLS輸送プロファイルの要件」、RFC 5654、2009年9月。
[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010.
[RFC5921] Bocci、M.、ed。、Bryant、S.、ed。、Frost、D.、ed。、Levrau、L。、およびL. Berger、「輸送ネットワークのMPLSのフレームワーク」、RFC 5921、2010年7月。
[RFC5950] Mansfield, S., Ed., Gray, E., Ed., and K. Lam, Ed., "Network Management Framework for MPLS-based Transport Networks", RFC 5950, September 2010.
[RFC5950] Mansfield、S.、Ed。、Gray、E.、Ed。、およびK. Lam、ed。、「MPLSベースの輸送ネットワークのネットワーク管理フレームワーク」、RFC 5950、2010年9月。
[RFC6371] Buci, I., Ed. and B. Niven-Jenkins, Ed., "A Framework for MPLS in Transport Networks", RFC 6371, September 2011.
[RFC6371] Buci、I.、ed。and B. Niven-Jenkins、ed。、「輸送ネットワークにおけるMPLSのフレームワーク」、RFC 6371、2011年9月。
[GMPLS-OAM] Takacs, A., Fedyk, D., and J. He, "GMPLS RSVP-TE extensions for OAM Configuration", Work in Progress, July 2011.
[gmpls-oam] Takacs、A.、Fedyk、D。、およびJ. He、「GMPLS RSVP-TE拡張機能用の拡張機能」、2011年7月、進行中の作業。
[MPLS-TP-LP] Weingarten, Y., Osborne, E., Sprecher, N., Fulignoli, A., Ed., and Y. Weingarten, Ed., "MPLS-TP Linear Protection", Work in Progress, August 2011.
[MPLS-TP-LP] Weingarten、Y.、Osborne、E.、Sprecher、N.、Fulignoli、A.、ed。、およびY. Weingarten、ed。、「MPLS-TP Linear Protection」、Work in Progress、2011年8月。
[MPLS-TP-MESH] Cheung, T. and J. Ryoo, "MPLS-TP Shared Mesh Protection", Work in Progress, April 2011.
[MPLS-TP-MESH] Cheung、T。およびJ. Ryoo、「MPLS-TP共有メッシュ保護」、2011年4月、作業中。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、RFC 3031、2001年1月。
[RFC3386] Lai, W., Ed., and D. McDysan, Ed., "Network Hierarchy and Multilayer Survivability", RFC 3386, November 2002.
[RFC3386] Lai、W.、ed。、およびD. McDysan、ed。、「ネットワーク階層と多層の生存性」、RFC 3386、2002年11月。
[RFC3469] Sharma, V., Ed., and F. Hellstrand, Ed., "Framework for Multi-Protocol Label Switching (MPLS)-based Recovery", RFC 3469, February 2003.
[RFC3469] Sharma、V.、ed。、およびF. Hellstrand、ed。、「マルチプロトコルラベルスイッチング（MPLS）ベースの回復のフレームワーク」、RFC 3469、2003年2月。
[RFC4397] Bryskin, I. and A. Farrel, "A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within the Context of the ITU-T's Automatically Switched Optical Network (ASON) Architecture", RFC 4397, February 2006.
[RFC4397] Bryskin、I。およびA. Farrel、「ITU-Tの自動切り替え光ネットワーク（ASON）アーキテクチャのコンテキスト内で、一般化されたマルチプロトコルラベルスイッチング（GMPLS）の用語の解釈のための辞書誌」、RFC 4397、2006年2月。
[RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D. Papadimitriou, Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification", RFC 4426, March 2006.
[RFC4426] Lang、J.、Ed。、Rajagopalan、B.、ed。、およびD. Papadimitriou、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）回復機能仕様」、RFC 4426、2006年3月。
[RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, November 2006.
[RFC4726] Farrel、A.、Vasseur、J.-P。、およびA. Ayyangar、「ドメイン間マルチプロトコルラベルスイッチングトラフィックエンジニアリングのフレームワーク」、RFC 4726、2006年11月。
[RFC4783] Berger, L., Ed., "GMPLS - Communication of Alarm Information", RFC 4783, December 2006.
[RFC4783] Berger、L.、ed。、「Gmpls-アラーム情報の通信」、RFC 4783、2006年12月。
[RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, Ed., "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 2007.
[RFC4872] Lang、J.、Ed。、Rekhter、Y.、ed。、およびD. Papadimitriou、ed。、「RSVP-TE拡張機能エンドツーエンド一般化マルチプロトコルラベルスイッチング（GMPLS）回復をサポートする"、RFC 4872、2007年5月。
[RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4874, April 2007.
[RFC4874] Lee、Cy。、Farrel、A。、およびS. de Cnodder、「除外ルート - リソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）への拡張」、RFC 4874、2007年4月。
[RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, M., and D. Brungard, "Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, July 2008.
[RFC5212] Shiomoto、K.、Papadimitriou、D.、Le Roux、Jl。、Vigoureux、M。、およびD. Brungard、「GMPLSベースのマルチレジオンおよびマルチ層ネットワーク（MRN/MLN）の要件」RFC 5212、2008年7月。
[RFC5298] Takeda, T., Ed., Farrel, A., Ed., Ikejiri, Y., and JP. Vasseur, "Analysis of Inter-Domain Label Switched Path (LSP) Recovery", RFC 5298, August 2008.
[RFC5298] Takeda、T.、Ed。、Farrel、A.、ed。、Ikejiri、Y。、およびJP。Vasseur、「ドメイン間ラベルスイッチドパス（LSP）回復の分析」、RFC 5298、2008年8月。
[RFC5817] Ali, Z., Vasseur, JP., Zamfir, A., and J. Newton, "Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks", RFC 5817, April 2010.
[RFC5817] Ali、Z.、Vasseur、JP。、Zamfir、A。、およびJ. Newton、「MPLSおよびGeneralized MPLS Traffic Engineering Networksの優雅なシャットダウン」、RFC 5817、2010年4月。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920] Fang、L.、ed。、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、2010年7月。
[RFC6373] Andersson, L., Ed., Berger, L., Ed., Fang, L., Ed., and Bitar, N., Ed, and E. Gray, Ed., "MPLS-TP Control Plane Framework", RFC 6373, September 2011.
[RFC6373] Andersson、L.、ed。、Berger、L.、Ed。、Fang、L.、Ed。、およびBitar、N.、Ed、およびE. Gray、 "Mpls-TPコントロールプレーンフレームワーク"、RFC 6373、2011年9月。
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, D., and S. Mansfield, "Guidelines for the Use of the "OAM" Acronym in the IETF", BCP 161, RFC 6291, June 2011.
[RFC6291] Andersson、L.、Van Helvoort、H.、Bonica、R.、Romascanu、D。、およびS. Mansfield、「IETFでの「OAM」頭字語を使用するためのガイドライン」、BCP 161、RFC 6291、2011年6月。
[ROSETTA] Van Helvoort, H., Ed., Andersson, L., Ed., and N. Sprecher, Ed., "A Thesaurus for the Terminology used in Multiprotocol Label Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's Transport Network Recommendations", Work in Progress, June 2011.
[Rosetta] van Helvoort、H.、ed。、Andersson、L.、ed。、およびN. Sprecher、ed。、「マルチプロトコルラベルスイッチングトランスポートプロファイル（MPLS-TP）ドラフト/RFCSおよびRFCSおよびRFCSおよびITU-Tのトランスポートネットワークの推奨事項」、2011年6月、進行中の作業。
Authors' Addresses
著者のアドレス
Nurit Sprecher (editor) Nokia Siemens Networks 3 Hanagar St. Neve Ne'eman B Hod Hasharon, 45241 Israel
Nurit Sprecher（編集者）Nokia Siemens Networks 3 Hanagar St. Neve Ne'eman B Hod Hasharon、45241 Israel
EMail: nurit.sprecher@nsn.com
Adrian Farrel (editor) Juniper Networks
Adrian Farrel（編集者）ジュニパーネットワーク
EMail: adrian@olddog.co.uk