[要約] RFC 4428は、GMPLSベースの回復メカニズム（保護および復旧を含む）の分析に関するものです。このRFCの目的は、GMPLSネットワークにおける回復機能の理解と評価を提供することです。
Network Working Group D. Papadimitriou, Ed.
Request for Comments: 4428 Alcatel
Category: Informational E. Mannie, Ed.
Perceval
March 2006
Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration)
一般化されたマルチプロトコルラベルスイッチング（GMPLS）ベースの回復メカニズム（保護と回復を含む）の分析
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This document provides an analysis grid to evaluate, compare, and contrast the Generalized Multi-Protocol Label Switching (GMPLS) protocol suite capabilities with the recovery mechanisms currently proposed at the IETF CCAMP Working Group. A detailed analysis of each of the recovery phases is provided using the terminology defined in RFC 4427. This document focuses on transport plane survivability and recovery issues and not on control plane resilience and related aspects.
このドキュメントは、IETF CCAMPワーキンググループで現在提案されている回復メカニズムと、一般化されたマルチプロトコルラベルスイッチング（GMPLS）プロトコルスイート機能を評価、比較、対比する分析グリッドを提供します。各回復フェーズの詳細な分析は、RFC 4427で定義された用語を使用して提供されます。このドキュメントは、コントロールプレーンの回復力と関連する側面ではなく、輸送機の生存性と回復の問題に焦点を当てています。
Table of Contents
目次
1. Introduction ....................................................3
2. Contributors ....................................................4
3. Conventions Used in this Document ...............................5
4. Fault Management ................................................5
4.1. Failure Detection ..........................................5
4.2. Failure Localization and Isolation .........................8
4.3. Failure Notification .......................................9
4.4. Failure Correlation .......................................11
5. Recovery Mechanisms ............................................11
5.1. Transport vs. Control Plane Responsibilities ..............11
5.2. Technology-Independent and Technology-Dependent
Mechanisms ................................................12
5.2.1. OTN Recovery .......................................12
5.2.2. Pre-OTN Recovery ...................................13
5.2.3. SONET/SDH Recovery .................................13
5.3. Specific Aspects of Control Plane-Based Recovery
Mechanisms ................................................14
5.3.1. In-Band vs. Out-Of-Band Signaling ..................14
5.3.2. Uni- vs. Bi-Directional Failures ...................15
5.3.3. Partial vs. Full Span Recovery .....................17
5.3.4. Difference between LSP, LSP Segment and
Span Recovery ......................................18
5.4. Difference between Recovery Type and Scheme ...............19
5.5. LSP Recovery Mechanisms ...................................21
5.5.1. Classification .....................................21
5.5.2. LSP Restoration ....................................23
5.5.3. Pre-Planned LSP Restoration ........................24
5.5.4. LSP Segment Restoration ............................25
6. Reversion ......................................................26
6.1. Wait-To-Restore (WTR) .....................................26
6.2. Revertive Mode Operation ..................................26
6.3. Orphans ...................................................27
7. Hierarchies ....................................................27
7.1. Horizontal Hierarchy (Partitioning) .......................28
7.2. Vertical Hierarchy (Layers) ...............................28
7.2.1. Recovery Granularity ...............................30
7.3. Escalation Strategies .....................................30
7.4. Disjointness ..............................................31
7.4.1. SRLG Disjointness ..................................32
8. Recovery Mechanisms Analysis ...................................33
8.1. Fast Convergence (Detection/Correlation and
Hold-off Time) ............................................34
8.2. Efficiency (Recovery Switching Time) ......................34
8.3. Robustness ................................................35
8.4. Resource Optimization .....................................36
8.4.1. Recovery Resource Sharing ..........................37
8.4.2. Recovery Resource Sharing and SRLG Recovery ........39
8.4.3. Recovery Resource Sharing, SRLG
Disjointness and Admission Control .................40
9. Summary and Conclusions ........................................42
10. Security Considerations .......................................43
11. Acknowledgements ..............................................43
12. References ....................................................44
12.1. Normative References .....................................44
12.2. Informative References ...................................44
This document provides an analysis grid to evaluate, compare, and contrast the Generalized MPLS (GMPLS) protocol suite capabilities with the recovery mechanisms proposed at the IETF CCAMP Working Group. The focus is on transport plane survivability and recovery issues and not on control-plane-resilience-related aspects. Although the recovery mechanisms described in this document impose different requirements on GMPLS-based recovery protocols, the protocols' specifications will not be covered in this document. Though the concepts discussed are technology independent, this document implicitly focuses on SONET [T1.105]/SDH [G.707], Optical Transport Networks (OTN) [G.709], and pre-OTN technologies, except when specific details need to be considered (for instance, in the case of failure detection).
このドキュメントは、IETF CCAMPワーキンググループで提案された回復メカニズムと一般化されたMPLS（GMPLS）プロトコルスイート機能を評価、比較、対比する分析グリッドを提供します。焦点は、輸送機の生存性と回復の問題にあり、コントロールプレーンレシリエンス関連の側面ではありません。このドキュメントで説明されている回復メカニズムは、GMPLSベースの回復プロトコルにさまざまな要件を課していますが、このドキュメントではプロトコルの仕様についてはカバーしません。議論されている概念はテクノロジーに依存しないものですが、このドキュメントは、SONET [T1.105]/SDH [G.707]、光学輸送ネットワーク（OTN）[G.709]、およびPre-OTNテクノロジーに暗黙的に焦点を当てています。考慮される（たとえば、障害検出の場合）。
A detailed analysis is provided for each of the recovery phases as identified in [RFC4427]. These phases define the sequence of generic operations that need to be performed when a LSP/Span failure (or any other event generating such failures) occurs:
[RFC4427]で特定された各回復段階の詳細な分析が提供されています。これらのフェーズは、LSP/SPAN障害（またはそのような障害を生成する他のイベント）が発生したときに実行する必要がある一般的な操作のシーケンスを定義します。
- Phase 1: Failure Detection - Phase 2: Failure Localization (and Isolation) - Phase 3: Failure Notification - Phase 4: Recovery (Protection or Restoration) - Phase 5: Reversion (Normalization)
- フェーズ1：障害検出 - フェーズ2：障害のローカリゼーション（および分離） - フェーズ3：障害通知 - フェーズ4：回復（保護または回復） - フェーズ5：復帰（正規化）
Together, failure detection, localization, and notification phases are referred to as "fault management". Within a recovery domain, the entities involved during the recovery operations are defined in [RFC4427]; these entities include ingress, egress, and intermediate nodes. The term "recovery mechanism" is used to cover both protection and restoration mechanisms. Specific terms such as "protection" and "restoration" are used only when differentiation is required. Likewise the term "failure" is used to represent both signal failure and signal degradation.
一緒に、障害検出、ローカリゼーション、および通知フェーズは「障害管理」と呼ばれます。回復ドメイン内で、回復操作中に関係するエンティティは[RFC4427]で定義されています。これらのエンティティには、イングレス、出口、および中間ノードが含まれます。「回復メカニズム」という用語は、保護メカニズムと回復メカニズムの両方をカバーするために使用されます。「保護」や「修復」などの特定の用語は、分化が必要な場合にのみ使用されます。同様に、「障害」という用語は、信号障害と信号分解の両方を表すために使用されます。
In addition, when analyzing the different hierarchical recovery mechanisms including disjointness-related issues, a clear distinction is made between partitioning (horizontal hierarchy) and layering (vertical hierarchy). In order to assess the current GMPLS protocol capabilities and the potential need for further extensions, the dimensions for analyzing each of the recovery mechanisms detailed in this document are introduced. This document concludes by detailing the applicability of the current GMPLS protocol building blocks for recovery purposes.
さらに、分離関連の問題を含むさまざまな階層的回復メカニズムを分析する場合、分割（水平階層）と階層化（垂直階層）との間に明確な区別が行われます。現在のGMPLSプロトコル機能とさらなる拡張の潜在的なニーズを評価するために、このドキュメントで詳述されている各回復メカニズムを分析するための次元が導入されます。このドキュメントは、回復の目的で現在のGMPLSプロトコルビルディングブロックの適用性を詳述することにより結論付けています。
This document is the result of the CCAMP Working Group Protection and Restoration design team joint effort. Besides the editors, the following are the authors that contributed to the present memo:
この文書は、CCAMPワーキンググループの保護と修復設計チームの共同努力の結果です。編集者に加えて、以下は現在のメモに貢献した著者です。
Deborah Brungard (AT&T) 200 S. Laurel Ave. Middletown, NJ 07748, USA
デボラ・ブランガード（AT＆T）200 S.ローレルアベニュー、ミドルタウン、ニュージャージー州07748、米国
EMail: dbrungard@att.com
Sudheer Dharanikota
Sudheer Dharanikota
EMail: sudheer@ieee.org
Jonathan P. Lang (Sonos) 506 Chapala Street Santa Barbara, CA 93101, USA
ジョナサンP.ラング（ソノス）506チャパラストリートサンタバーバラ、カリフォルニア州93101、米国
EMail: jplang@ieee.org
Guangzhi Li (AT&T) 180 Park Avenue, Florham Park, NJ 07932, USA
広州Li（AT＆T）180パークアベニュー、フローハムパーク、ニュージャージー州07932、米国
EMail: gli@research.att.com
Eric Mannie Perceval Rue Tenbosch, 9 1000 Brussels Belgium
エリックマニーパーセバルRue Tenbosch、9 1000ブリュッセルベルギー
Phone: +32-2-6409194
EMail: eric.mannie@perceval.net
Dimitri Papadimitriou (Alcatel) Francis Wellesplein, 1 B-2018 Antwerpen, Belgium
Dimitri Papadimitriou（Alcatel）Francis Wellesplein、1 B-2018 Antwerpen、ベルギー
EMail: dimitri.papadimitriou@alcatel.be
Bala Rajagopalan
Microsoft India Development Center
Hyderabad, India
EMail: balar@microsoft.com
Yakov Rekhter (Juniper) 1194 N. Mathilda Avenue Sunnyvale, CA 94089, USA
Yakov Rekhter（ジュニパー）1194 N. Mathilda Avenue Sunnyvale、CA 94089、米国
EMail: yakov@juniper.net
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
Any other recovery-related terminology used in this document conforms to that defined in [RFC4427]. The reader is also assumed to be familiar with the terminology developed in [RFC3945], [RFC3471], [RFC3473], [RFC4202], and [RFC4204].
このドキュメントで使用されている他の回復関連の用語は、[RFC4427]で定義されているものに準拠しています。読者はまた、[RFC3945]、[RFC3471]、[RFC3473]、[RFC4202]、および[RFC4204]で開発された用語に精通していると想定されています。
Transport failure detection is the only phase that cannot be achieved by the control plane alone because the latter needs a hook to the transport plane in order to collect the related information. It has to be emphasized that even if failure events themselves are detected by the transport plane, the latter, upon a failure condition, must trigger the control plane for subsequent actions through the use of GMPLS signaling capabilities (see [RFC3471] and [RFC3473]) or Link Management Protocol capabilities (see [RFC4204], Section 6).
輸送障害検出は、関連情報を収集するために輸送機へのフックが必要であるため、コントロールプレーンのみが達成できない唯一のフェーズです。故障イベント自体が輸送面によって検出されたとしても、後者は故障状態で、GMPLSシグナル伝達能力を使用して後続のアクションをコントロールプレーンにトリガーする必要があることを強調する必要があります（[RFC3471]および[RFC3473]を参照してください。）またはリンク管理プロトコル機能（[RFC4204]、セクション6を参照）。
Therefore, by definition, transport failure detection is transport technology dependent (and so exceptionally, we keep here the "transport plane" terminology). In transport fault management, distinction is made between a defect and a failure. Here, the discussion addresses failure detection (persistent fault cause). In the technology-dependent descriptions, a more precise specification will be provided.
したがって、定義上、輸送障害検出は輸送技術に依存しています（非常に例外的には、ここでは「輸送機」の用語を維持します）。輸送障害管理では、欠陥と障害の区別が行われます。ここで、議論は障害検出に対処します（永続的な障害原因）。技術依存の説明では、より正確な仕様が提供されます。
As an example, SONET/SDH (see [G.707], [G.783], and [G.806]) provides supervision capabilities covering:
例として、SONET/SDH（[G.707]、[G.783]、および[G.806]を参照）は、次のことをカバーする監督機能を提供します。
- Continuity: SONET/SDH monitors the integrity of the continuity of a trail (i.e., section or path). This operation is performed by monitoring the presence/absence of the signal. Examples are Loss of Signal (LOS) detection for the physical layer, Unequipped (UNEQ) Signal detection for the path layer, Server Signal Fail Detection (e.g., AIS) at the client layer.
- 連続性：SONET/SDHは、トレイルの連続性（つまり、セクションまたはパス）の完全性を監視します。この操作は、信号の存在/欠如を監視することにより実行されます。例としては、クライアントレイヤーでの物理レイヤーの信号（LOS）検出、装備されていない（UNEQ）信号検出、サーバー信号障害検出（AISなど）があります。
- Connectivity: SONET/SDH monitors the integrity of the routing of the signal between end-points. Connectivity monitoring is needed if the layer provides flexible connectivity, either automatically (e.g., cross-connects) or manually (e.g., fiber distribution frame). An example is the Trail (i.e., section or path) Trace Identifier used at the different layers and the corresponding Trail Trace Identifier Mismatch detection.
- 接続性：SONET/SDHは、エンドポイント間の信号のルーティングの完全性を監視します。レイヤーが柔軟な接続を自動的に（クロス接続など）または手動（ファイバー分布フレームなど）のいずれかを提供する場合、接続監視が必要です。例は、異なるレイヤーで使用されるトレイル（つまり、セクションまたはパス）トレース識別子と、対応するトレーストレース識別子の不一致の検出です。
- Alignment: SONET/SDH checks that the client and server layer frame start can be correctly recovered from the detection of loss of alignment. The specific processes depend on the signal/frame structure and may include: (multi-)frame alignment, pointer processing, and alignment of several independent frames to a common frame start in case of inverse multiplexing. Loss of alignment is a generic term. Examples are loss of frame, loss of multi-frame, or loss of pointer.
- アライメント：SONET/SDHは、クライアントとサーバーのレイヤーフレームの開始が、アライメントの喪失の検出から正しく回復できることを確認します。特定のプロセスは、信号/フレーム構造に依存し、（マルチ）フレームアライメント、ポインター処理、および逆の多重化の場合の共通フレーム開始に対するいくつかの独立したフレームのアラインメントが含まれます。アライメントの喪失は一般的な用語です。例は、フレームの喪失、マルチフレームの喪失、またはポインターの喪失です。
- Payload type: SONET/SDH checks that compatible adaptation functions are used at the source and the destination. Normally, this is done by adding a payload type identifier (referred to as the "signal label") at the source adaptation function and comparing it with the expected identifier at the destination. For instance, the payload type identifier is compared with the corresponding mismatch detection.
- ペイロードタイプ：SONET/SDHは、互換性のある適応関数がソースと宛先で使用されていることをチェックします。通常、これは、ソース適応関数にペイロードタイプ識別子（「信号ラベル」と呼ばれる）を追加し、宛先の予想される識別子と比較することによって行われます。たとえば、ペイロード型識別子は、対応する不一致の検出と比較されます。
- Signal Quality: SONET/SDH monitors the performance of a signal. For instance, if the performance falls below a certain threshold, a defect -- excessive errors (EXC) or degraded signal (DEG) -- is detected.
- 信号品質：SONET/SDHは、信号のパフォーマンスを監視します。たとえば、パフォーマンスが特定のしきい値を下回る場合、欠陥 - 過度のエラー（Exc）または劣化した信号（deg） - が検出されます。
The most important point is that the supervision processes and the corresponding failure detection (used to initiate the recovery phase(s)) result in either:
最も重要な点は、監督プロセスと対応する障害検出（回復段階の開始に使用）が次のとおりです。
- Signal Degrade (SD): A signal indicating that the associated data has degraded in the sense that a degraded defect condition is active (for instance, a dDEG declared when the Bit Error Rate exceeds a preset threshold). Or
- 信号分解（SD）：関連するデータが劣化した欠陥条件がアクティブであるという意味で劣化していることを示す信号（たとえば、ビットエラー率がプリセットしきい値を超えるとDDEGが宣言されました）。また
- Signal Fail (SF): A signal indicating that the associated data has failed in the sense that a signal interrupting near-end defect condition is active (as opposed to the degraded defect).
- 信号障害（SF）：関連するデータが、ニアエンドの欠陥条件を中断する信号がアクティブであるという意味で（劣化した欠陥とは対照的に）故障したことを示す信号。
In Optical Transport Networks (OTN), equivalent supervision capabilities are provided at the optical/digital section layers (i.e., Optical Transmission Section (OTS), Optical Multiplex Section (OMS) and Optical channel Transport Unit (OTU)) and at the optical/digital path layers (i.e., Optical Channel (OCh) and Optical channel Data Unit (ODU)). Interested readers are referred to the ITU-T Recommendations [G.798] and [G.709] for more details.
光輸送ネットワーク（OTN）では、光/デジタルセクションレイヤー（つまり、光学伝送セクション（OT）、光学マルチプレックスセクション（OMS）、光学チャネル輸送ユニット（OTU））および光/デジタルパスレイヤー（つまり、光チャネル（OCH）および光チャネルデータユニット（ODU））。興味のある読者は、詳細については、ITU-Tの推奨[G.798]および[G.709]を参照してください。
The above are examples that illustrate cases where the failure detection and reporting entities (see [RFC4427]) are co-located. The following example illustrates the scenario where the failure detecting and reporting entities (see [RFC4427]) are not co-located.
上記は、障害検出および報告エンティティ（[rfc4427]を参照）が共同配置されている場合を示す例です。次の例は、エンティティの検出と報告の障害（[RFC4427]を参照）が共同で行われないシナリオを示しています。
In pre-OTN networks, a failure may be masked by intermediate O-E-O based Optical Line System (OLS), preventing a Photonic Cross-Connect (PXC) from detecting upstream failures. In such cases, failure detection may be assisted by an out-of-band communication channel, and failure condition may be reported to the PXC control plane. This can be provided by using [RFC4209] extensions that deliver IP message-based communication between the PXC and the OLS control plane. Also, since PXCs are independent of the framing format, failure conditions can only be triggered either by detecting the absence of the optical signal or by measuring its quality. These mechanisms are generally less reliable than electrical (digital) ones. Both types of detection mechanisms are outside the scope of this document. If the intermediate OLS supports electrical (digital) mechanisms, using the LMP communication channel, these failure conditions are reported to
Pre-OTNネットワークでは、中間O-E-Oベースの光線システム（OLS）によって障害がマスクされ、写真の相互接続（PXC）が上流の障害を検出するのを防ぐことができます。そのような場合、障害検出はバンド外の通信チャネルによって支援され、障害条件がPXC制御プレーンに報告される場合があります。これは、PXCとOLSコントロールプレーン間のIPメッセージベースの通信を提供する[RFC4209]拡張機能を使用して提供できます。また、PXCはフレーミング形式に依存しないため、障害条件は、光信号の欠如を検出するか、その品質を測定することによってのみトリガーできます。これらのメカニズムは一般に、電気（デジタル）のメカニズムよりも信頼性が低いです。両方のタイプの検出メカニズムは、このドキュメントの範囲外です。中間OLSがLMP通信チャネルを使用して電気（デジタル）メカニズムをサポートしている場合、これらの障害条件はに報告されます
the PXC and subsequent recovery actions are performed as described in Section 5. As such, from the control plane viewpoint, this mechanism turns the OLS-PXC-composed system into a single logical entity, thus having the same failure management mechanisms as any other O-E-O capable device.
PXCおよびその後の回復アクションはセクション5で説明されているように実行されます。そのため、制御プレーンの視点から、このメカニズムはOLS-PXCに加えられたシステムを単一の論理エンティティに変え、したがって他のO-E-Oと同じ障害管理メカニズムを持つことができます。有能なデバイス。
More generally, the following are typical failure conditions in SONET/SDH and pre-OTN networks:
より一般的には、以下はSONET/SDHおよびPRE-OTNネットワークの典型的な故障条件です。
- Loss of Light (LOL)/Loss of Signal (LOS): Signal Failure (SF) condition where the optical signal is not detected any longer on the receiver of a given interface.
- 光の喪失（LOL）/信号の損失（LOS）：信号障害（SF）条件では、特定のインターフェイスの受信機で光信号が検出されなくなります。
- Signal Degrade (SD): detection of the signal degradation over a specific period of time.
- 信号分解（SD）：特定の期間にわたる信号分解の検出。
- For SONET/SDH payloads, all of the above-mentioned supervision capabilities can be used, resulting in SD or SF conditions.
- SONET/SDHペイロードの場合、上記のすべての監督機能を使用することができ、SDまたはSF条件が生まれます。
In summary, the following cases apply when considering the communication between the detecting and reporting entities:
要約すると、検出エンティティとレポートエンティティ間の通信を検討する場合、次のケースが適用されます。
- Co-located detecting and reporting entities: both the detecting and reporting entities are on the same node (e.g., SONET/SDH equipment, Opaque cross-connects, and, with some limitations, Transparent cross-connects, etc.)
- 共同開催の検出および報告エンティティ：検出エンティティとレポートエンティティの両方が同じノード上にあります（例：SONET/SDH機器、不透明なクロスコネクト、およびいくつかの制限付き、透明なクロスコネクトなど）
- Non-co-located detecting and reporting entities:
- 非Co-Located検出および報告エンティティ：
o with in-band communication between entities: entities are physically separated, but the transport plane provides in-band communication between them (e.g., Server Signal Failures such as Alarm Indication Signal (AIS), etc.)
o エンティティ間の帯域内通信：エンティティは物理的に分離されていますが、トランスポートプレーンはそれらの間の帯域内通信を提供します（例えば、アラーム表示信号（AIS）などのサーバー信号障害など）
o with out-of-band communication between entities: entities are physically separated, but an out-of-band communication channel is provided between them (e.g., using [RFCF4204]).
o エンティティ間の帯域外通信の場合：エンティティは物理的に分離されていますが、それらの間に帯域外の通信チャネルが提供されます（例：[RFCF4204]を使用）。
Failure localization provides information to the deciding entity about the location (and so the identity) of the transport plane entity that detects the LSP(s)/span(s) failure. The deciding entity can then make an accurate decision to achieve finer grained recovery switching action(s). Note that this information can also be included as part of the failure notification (see Section 4.3).
障害のローカリゼーションは、LSP/SPAN（S）障害を検出する輸送機エンティティの場所（およびID）に関する情報を決定するエンティティに提供します。決定的なエンティティは、より細かい粒度の回復スイッチングアクションを達成するために正確な決定を下すことができます。この情報は、障害通知の一部としても含めることができることに注意してください（セクション4.3を参照）。
In some cases, this accurate failure localization information may be less urgent to determine if it requires performing more time-consuming failure isolation (see also Section 4.4). This is particularly the case when edge-to-edge LSP recovery is performed based on a simple failure notification (including the identification of the working LSPs under failure condition). Note that "edge" refers to a sub-network end-node, for instance. In this case, a more accurate localization and isolation can be performed after recovery of these LSPs.
場合によっては、この正確な障害ローカリゼーション情報は、より時間のかかる障害分離を実行する必要があるかどうかを判断するのに緊急ではない場合があります（セクション4.4も参照）。これは、特に、単純な障害通知（故障状態での作業LSPの識別を含む）に基づいて、エッジからエッジへのLSP回復が実行される場合です。たとえば、「エッジ」とはサブネットワークのエンドノードを指します。この場合、これらのLSPの回復後、より正確なローカリゼーションと分離を実行できます。
Failure localization should be triggered immediately after the fault detection phase. This operation can be performed at the transport plane and/or (if the operation is unavailable via the transport plane) the control plane level where dedicated signaling messages can be used. When performed at the control plane level, a protocol such as LMP (see [RFC4204], Section 6) can be used for failure localization purposes.
障害検出フェーズの直後に障害のローカリゼーションをトリガーする必要があります。この操作は、輸送機で実行できます（輸送機を介して操作が利用できない場合）専用の信号メッセージを使用できるコントロールプレーンレベル。コントロールプレーンレベルで実行される場合、LMP（[RFC4204]、セクション6を参照）などのプロトコルを障害のローカライズ目的で使用できます。
Failure notification is used 1) to inform intermediate nodes that an LSP/span failure has occurred and has been detected and 2) to inform the deciding entities (which can correspond to any intermediate or end-point of the failed LSP/span) that the corresponding service is not available. In general, these deciding entities will be the ones making the appropriate recovery decision. When co-located with the recovering entity, these entities will also perform the corresponding recovery action(s).
障害通知が使用されます1）LSP/SPAN障害が発生し、検出されたことを中間ノードに通知し、2）決定的なエンティティ（失敗したLSP/SPANの中間またはエンドポイントに対応できる）に通知するために対応するサービスは利用できません。一般に、これらの決定的なエンティティは、適切な回復決定を下すものになります。回復エンティティと共同で開催されると、これらのエンティティは対応する回復アクションも実行します。
Failure notification can be provided either by the transport or by the control plane. As an example, let us first briefly describe the failure notification mechanism defined at the SONET/SDH transport plane level (also referred to as maintenance signal supervision):
障害通知は、輸送機または制御プレーンのいずれかによって提供できます。例として、最初にSONET/SDH輸送機レベルで定義された障害通知メカニズム（メンテナンス信号監督とも呼ばれます）について簡単に説明しましょう。
- AIS (Alarm Indication Signal) occurs as a result of a failure condition such as Loss of Signal and is used to notify downstream nodes (of the appropriate layer processing) that a failure has occurred. AIS performs two functions: 1) inform the intermediate nodes (with the appropriate layer monitoring capability) that a failure has been detected and 2) notify the connection end-point that the service is no longer available.
- AIS（アラーム表示信号）は、信号の喪失などの障害条件の結果として発生し、故障が発生したことを（適切な層処理の）下流ノードに通知するために使用されます。AISは2つの機能を実行します。1）中間ノード（適切なレイヤー監視機能を使用）に障害が検出されたことを通知し、2）サービスが使用できなくなったことを接続のエンドポイントに通知します。
For a distributed control plane supporting one (or more) failure notification mechanism(s), regardless of the mechanism's actual implementation, the same capabilities are needed with more (or less) information provided about the LSPs/spans under failure condition, their detailed statuses, etc.
メカニズムの実際の実装に関係なく、1つの（またはそれ以上の）障害通知メカニズムをサポートする分散制御プレーンの場合、障害条件下でのLSPS/スパンについて提供されるより多くの（またはそれ以下の）情報と同じ機能が必要です。、など
The most important difference between these mechanisms is related to the fact that transport plane notifications (as defined today) would directly initiate either a certain type of protection switching (such as those described in [RFC4427]) via the transport plane or restoration actions via the management plane.
これらのメカニズムの最も重要な違いは、輸送機通知（今日定義されている）が、輸送機に記載されている特定のタイプの保護スイッチング（[RFC4427]に記載されているなど）を直接開始するか、または輸送機または復元作用を介して直接開始するという事実に関連しています。管理プレーン。
On the other hand, using a failure notification mechanism through the control plane would provide the possibility of triggering either a protection or a restoration action via the control plane. This has the advantage that a control-plane-recovery-responsible entity does not necessarily have to be co-located with a transport maintenance/recovery domain. A control plane recovery domain can be defined at entities not supporting a transport plane recovery.
一方、制御プレーンを介した障害通知メカニズムを使用すると、制御プレーンを介して保護または修復作用のいずれかをトリガーする可能性が提供されます。これには、コントロールプレーンの回復に敏感なエンティティが必ずしも輸送メンテナンス/回復ドメインと共同で開催する必要がないという利点があります。コントロールプレーンの回復ドメインは、輸送機の回復をサポートしていないエンティティで定義できます。
Moreover, as specified in [RFC3473], notification message exchanges through a GMPLS control plane may not follow the same path as the LSP/spans for which these messages carry the status. In turn, this ensures a fast, reliable (through acknowledgement and the use of either a dedicated control plane network or disjoint control channels), and efficient (through the aggregation of several LSP/span statuses within the same message) failure notification mechanism.
さらに、[RFC3473]で指定されているように、GMPLSコントロールプレーンを介した通知メッセージ交換は、これらのメッセージがステータスを運ぶLSP/スパンと同じパスをたどることはできません。次に、これにより、高速で信頼性の高い（承認と専用のコントロールプレーンネットワークまたは分離制御チャネルの使用を通じて）、および効率的（同じメッセージ内の複数のLSP/SPANステータスの集約を通じて）障害通知メカニズムを保証します。
The other important properties to be met by the failure notification mechanism are mainly the following:
障害通知メカニズムによって満たされる他の重要な特性は、主に次のものです。
- Notification messages must provide enough information such that the most efficient subsequent recovery action will be taken at the recovering entities (in most of the recovery types and schemes this action is even deterministic). Remember here that these entities can be either intermediate or end-points through which normal traffic flows. Based on local policy, intermediate nodes may not use this information for subsequent recovery actions (see for instance the APS protocol phases as described in [RFC4427]). In addition, since fast notification is a mechanism running in collaboration with the existing GMPLS signaling (see [RFC3473]) that also allows intermediate nodes to stay informed about the status of the working LSP/spans under failure condition.
- 通知メッセージは、回復エンティティで最も効率的な後続の回復アクションが実行されるように十分な情報を提供する必要があります（このアクションはさらに決定的であることさえ、回復タイプとスキームのほとんどで）。ここでは、これらのエンティティは、通常のトラフィックが流れる中間またはエンドポイントのいずれかであることを忘れないでください。ローカルポリシーに基づいて、中間ノードはこの情報をその後の回復アクションに使用することはできません（たとえば、[RFC4427]で説明されているAPSプロトコルフェーズを参照）。さらに、高速通知は、既存のGMPLSシグナル伝達（[RFC3473を参照）と協力して実行されるメカニズムであるため、中間ノードは、故障状態での作業LSP/スパンのステータスについて情報を提供することもできます。
The trade-off here arises when defining what information the LSP/span end-points (more precisely, the deciding entities) need in order for the recovering entity to take the best recovery action: If not enough information is provided, the decision cannot be optimal (note that in this eventuality, the important issue is to quantify the level of sub-optimality). If too much information is provided, the control plane may be overloaded with unnecessary information and the aggregation/correlation of this notification information will be more complex and time-consuming to achieve. Note that a more detailed quantification of the amount of information to be exchanged and processed is strongly dependent on the failure notification protocol.
ここでのトレードオフは、回復エンティティが最良の回復アクションをとるために、LSP/SPANエンドポイント（より正確には決定的なエンティティ）が必要とする情報を定義するときに発生します。最適（この不測の事態において、重要な問題は、サブ最適性のレベルを定量化することであることに注意してください）。あまりにも多くの情報が提供されている場合、コントロールプレーンに不必要な情報が過負荷になる場合があり、この通知情報の集約/相関はより複雑で時間がかかります。交換および処理される情報の量のより詳細な定量化は、障害通知プロトコルに強く依存していることに注意してください。
- If the failure localization and isolation are not performed by one of the LSP/span end-points or some intermediate points, the points should receive enough information from the notification message in order to locate the failure. Otherwise, they would need to (re-) initiate a failure localization and isolation action.
- 障害のローカリゼーションと分離がLSP/スパンエンドポイントまたはいくつかの中間点のいずれかによって実行されない場合、ポイントは障害を見つけるために通知メッセージから十分な情報を受信する必要があります。それ以外の場合、障害のローカリゼーションと分離アクションを（再）開始する必要があります。
- Avoiding so-called notification storms implies that 1) the failure detection output is correlated (i.e., alarm correlation) and aggregated at the node detecting the failure(s), 2) the failure notifications are directed to a restricted set of destinations (in general the end-points), and 3) failure notification suppression (i.e., alarm suppression) is provided in order to limit flooding in case of multiple and/or correlated failures detected at several locations in the network.
- いわゆる通知暴風雨を回避することは、1）障害検出出力が相関（つまり、アラーム相関）であり、障害を検出するノードで集計されていることを意味します。エンドポイント）、および3）ネットワーク内のいくつかの場所で検出された複数および/または相関障害の場合に洪水を制限するために、障害通知抑制（つまり、アラーム抑制）が提供されます。
- Alarm correlation and aggregation (at the failure-detecting node) implies a consistent decision based on the conditions for which a trade-off between fast convergence (at detecting node) and fast notification (implying that correlation and aggregation occurs at receiving end-points) can be found.
- アラーム相関と集約（障害検出ノードで）は、高速収束（ノードの検出時）と高速通知のトレードオフ（エンドポイントの受信時に相関と集約が発生することを意味する条件に基づく一貫した決定を意味します。見つけることができます。
A single failure event (such as a span failure) can cause multiple failure (such as individual LSP failures) conditions to be reported. These can be grouped (i.e., correlated) to reduce the number of failure conditions communicated on the reporting channel, for both in-band and out-of-band failure reporting.
単一の障害イベント（スパン障害など）は、複数の障害（個々のLSP障害など）条件を報告する可能性があります。これらをグループ化（つまり、相関する）して、帯域内および帯域外の故障報告の両方について、レポートチャネルで通信した障害条件の数を減らすことができます。
In such a scenario, it can be important to wait for a certain period of time, typically called failure correlation time, and gather all the failures to report them as a group of failures (or simply group failure). For instance, this approach can be provided using LMP-WDM for pre-OTN networks (see [RFC4209]) or when using Signal Failure/Degrade Group in the SONET/SDH context.
このようなシナリオでは、通常は障害相関時間と呼ばれる一定の期間、障害のグループ（または単にグループ障害）として報告するすべての障害を収集することが重要です。たとえば、このアプローチは、PRE-OTNネットワークにLMP-WDMを使用して（[RFC4209]を参照）、またはSONET/SDHコンテキストで信号障害/分解グループを使用する場合に提供できます。
Note that a default average time interval during which failure correlation operation can be performed is difficult to provide since it is strongly dependent on the underlying network topology. Therefore, providing a per-node configurable failure correlation time can be advisable. The detailed selection criteria for this time interval are outside of the scope of this document.
故障相関操作を実行できるデフォルトの平均時間間隔は、基礎となるネットワークトポロジに強く依存しているため、提供するのが困難であることに注意してください。したがって、ノードごとの構成可能な障害相関時間を提供することをお勧めします。この時間間隔の詳細な選択基準は、このドキュメントの範囲外です。
When failure correlation is not provided, multiple failure notification messages may be sent out in response to a single failure (for instance, a fiber cut). Each failure notification message contains a set of information on the failed working resources (for instance, the individual lambda LSP flowing through this fiber). This allows for a more prompt response, but can potentially overload the control plane due to a large amount of failure notifications.
障害相関が提供されない場合、単一の障害（たとえば、ファイバーカット）に応じて複数の障害通知メッセージが送信される場合があります。各障害通知メッセージには、動作の失敗に関する情報のセットが含まれています（たとえば、このファイバーを流れる個々のLambda LSP）。これにより、より迅速な応答が可能になりますが、大量の障害通知により、コントロールプレーンに過負荷をかける可能性があります。
When applicable, recovery resources are provisioned, for both protection and restoration, using GMPLS signaling capabilities. Thus, these are control plane-driven actions (topological and resource-constrained) that are always performed in this context.
該当する場合、GMPLSシグナリング機能を使用して、保護と修復の両方に対して、回復リソースがプロビジョニングされます。したがって、これらは、このコンテキストで常に実行される制御プレーン駆動型のアクション（トポロジカルおよびリソースが制約されている）です。
The following tables give an overview of the responsibilities taken by the control plane in case of LSP/span recovery: 1. LSP/span Protection
次の表は、LSP/SPANリカバリの場合にコントロールプレーンが取った責任の概要を示しています：1。LSP/SPAN Protection
- Phase 1: Failure Detection Transport plane - Phase 2: Failure Localization/Isolation Transport/Control plane - Phase 3: Failure Notification Transport/Control plane - Phase 4: Protection Switching Transport/Control plane - Phase 5: Reversion (Normalization) Transport/Control plane
- フェーズ1：障害検出輸送面 - フェーズ2：障害のローカリゼーション/分離輸送/制御プレーン - フェーズ3：障害通知輸送/制御プレーン - フェーズ4：保護スイッチング輸送/制御プレーン - フェーズ5：復帰（正規化）輸送/制御飛行機
Note: in the context of LSP/span protection, control plane actions can be performed either for operational purposes and/or synchronization purposes (vertical synchronization between transport and control plane) and/or notification purposes (horizontal synchronization between end-nodes at control plane level). This suggests the selection of the responsible plane (in particular for protection switching) during the provisioning phase of the protected/protection LSP.
注：LSP/SPAN保護のコンテキストでは、制御プレーンアクションは、運用目的および/または同期（輸送および制御プレーン間の垂直同期）および/または通知目的（コントロールプレーンでのエンドノード間の水平同期化）のために実行できます。レベル）。これは、保護/保護LSPのプロビジョニング段階での責任平面（特に保護スイッチング用）の選択を示唆しています。
2. LSP/span Restoration
2. LSP/SPAN Restoration
- Phase 1: Failure Detection Transport plane - Phase 2: Failure Localization/Isolation Transport/Control plane - Phase 3: Failure Notification Control plane - Phase 4: Recovery Switching Control plane - Phase 5: Reversion (Normalization) Control plane
- フェーズ1：障害検出輸送面 - フェーズ2：障害ローカリゼーション/分離輸送/制御プレーン - フェーズ3：障害通知制御プレーン - フェーズ4：回復スイッチングコントロールプレーン - フェーズ5：再バージョン（正規化）制御プレーン
Therefore, this document primarily focuses on provisioning of LSP recovery resources, failure notification mechanisms, recovery switching, and reversion operations. Moreover, some additional considerations can be dedicated to the mechanisms associated to the failure localization/isolation phase.
したがって、このドキュメントは、主にLSP回復リソースのプロビジョニング、障害通知メカニズム、回復スイッチング、および逆転操作に焦点を当てています。さらに、いくつかの追加の考慮事項は、障害のローカリゼーション/分離フェーズに関連するメカニズムに専念できます。
The present recovery mechanisms analysis applies to any circuit-oriented data plane technology with discrete bandwidth increments (like SONET/SDH, G.709 OTN, etc.) being controlled by a GMPLS-based distributed control plane.
現在の回復メカニズム分析は、GMPLSベースの分散コントロールプレーンによって制御される離散帯域幅の増分（SONET/SDH、G.709 OTNなど）を備えた回路指向のデータプレーンテクノロジーに適用されます。
The following sub-sections are not intended to favor one technology versus another. They list pro and cons for each technology in order to determine the mechanisms that GMPLS-based recovery must deliver to overcome their cons and make use of their pros in their respective applicability context.
次のサブセクションは、あるテクノロジーと別のテクノロジーを支持することを意図したものではありません。GMPLSベースの回復が、それぞれの適用性のコンテキストでプロを克服し、プロを利用するためにGMPLSベースの回復が提供しなければならないメカニズムを決定するために、各テクノロジーのプロと短所をリストします。
OTN recovery specifics are left for further consideration.
OTN回復の詳細は、さらに検討するために残されています。
Pre-OTN recovery specifics (also referred to as "lambda switching") present mainly the following advantages:
OTN回復前の詳細（「ラムダスイッチング」とも呼ばれます）は、主に次の利点を示しています。
- They benefit from a simpler architecture, making it more suitable for mesh-based recovery types and schemes (on a per-channel basis).
- それらはより単純なアーキテクチャの恩恵を受けて、メッシュベースの回復タイプとスキームにより（チャネルごとに）より適しています。
- Failure suppression at intermediate node transponders, e.g., use of squelching, implies that failures (such as LoL) will propagate to edge nodes. Thus, edge nodes will have the possibility to initiate recovery actions driven by upper layers (vs. use of non-standard masking of upstream failures).
- 中間ノードトランスポンダーでの障害抑制、たとえば、抑制の使用は、障害（LOLなど）がエッジノードに伝播することを意味します。したがって、エッジノードは、上層によって駆動される回復アクションを開始する可能性があります（上流障害の非標準マスキングの使用）。
The main disadvantage is the lack of interworking due to the large amount of failure management (in particular failure notification protocols) and recovery mechanisms currently available.
主な欠点は、障害管理の大量（特に障害通知プロトコル）と現在利用可能な回復メカニズムのために、相互作用の欠如です。
Note also, that for all-optical networks, combination of recovery with optical physical impairments is left for a future release of this document because corresponding detection technologies are under specification.
また、オールオプティックネットワークの場合、対応する検出技術が仕様に基づいているため、回復と光学的障害の組み合わせがこのドキュメントの将来のリリースに残されていることに注意してください。
Some of the advantages of SONET [T1.105]/SDH [G.707], and more generically any Time Division Multiplexing (TDM) transport plane recovery, are that they provide:
SONET [T1.105]/SDH [G.707]の利点のいくつか、およびより一般的には、任意の時間分割多重化（TDM）輸送機の回復は次のとおりです。
- Protection types operating at the data plane level that are standardized (see [G.841]) and can operate across protected domains and interwork (see [G.842]).
- 標準化されたデータプレーンレベルで動作する保護タイプ（[G.841]を参照）を参照し、保護されたドメインとインターワーク全体で動作できます（[G.842]を参照）。
- Failure detection, notification, and path/section Automatic Protection Switching (APS) mechanisms.
- 障害検出、通知、およびパス/セクション自動保護スイッチング（APS）メカニズム。
- Greater control over the granularity of the TDM LSPs/links that can be recovered with respect to coarser optical channel (or whole fiber content) recovery switching
- 粗い光学チャネル（またはファイバー全体のコンテンツ全体）リカバリスイッチングに関して回復できるTDM LSPS/リンクの粒度のより大きな制御
Some of the limitations of the SONET/SDH recovery are:
SONET/SDH回復の制限のいくつかは次のとおりです。
- Limited topological scope: Inherently the use of ring topologies, typically, dedicated Sub-Network Connection Protection (SNCP) or shared protection rings, has reduced flexibility and resource efficiency with respect to the (somewhat more complex) meshed recovery.
- 限られたトポロジ範囲：本質的にリングトポロジの使用、通常は専用のサブネットワーク接続保護（SNCP）または共有保護リングは、（やや複雑な）メッシュ化された回復に関して柔軟性とリソース効率を低下させました。
- Inefficient use of spare capacity: SONET/SDH protection is largely applied to ring topologies, where spare capacity often remains idle, making the efficiency of bandwidth usage a real issue.
- 予備容量の非効率的な使用：SONET/SDH保護は、環状トポロジーに主に適用されます。スペア容量はしばしばアイドル状態のままで、帯域幅使用の効率が実際の問題になります。
- Support of meshed recovery requires intensive network management development, and the functionality is limited by both the network elements and the capabilities of the element management systems (thus justifying the development of GMPLS-based distributed recovery mechanisms.)
- Meshed Recoveryのサポートには集中的なネットワーク管理開発が必要であり、機能は要素管理システムのネットワーク要素と機能の両方によって制限されます（したがって、GMPLSベースの分散回復メカニズムの開発を正当化します。）
The nodes communicate through the use of IP terminating control channels defining the control plane (transport) topology. In this context, two classes of transport mechanisms can be considered here: in-fiber or out-of-fiber (through a dedicated physically diverse control network referred to as the Data Communication Network or DCN). The potential impact of the usage of an in-fiber (signaling) transport mechanism is briefly considered here.
ノードは、コントロールプレーン（輸送）トポロジを定義するIP終了制御チャネルを使用して通信します。これに関連して、ここでは、2つのクラスの輸送メカニズムを考慮することができます。ファイバーまたは繊維外（データ通信ネットワークまたはDCNと呼ばれる専用の物理的に多様な制御ネットワークを介して）。ここでは、繊維（シグナリング）輸送メカニズムの使用の潜在的な影響を簡単に考慮します。
In-fiber transport mechanisms can be further subdivided into in-band and out-of-band. As such, the distinction between in-fiber in-band and in-fiber out-of-band signaling reduces to the consideration of a logically- versus physically-embedded control plane topology with respect to the transport plane topology. In the scope of this document, it is assumed that at least one IP control channel between each pair of adjacent nodes is continuously available to enable the exchange of recovery-related information and messages. Thus, in either case (i.e., in-band or out-of-band) at least one logical or physical control channel between each pair of nodes is always expected to be available.
繊維内輸送メカニズムは、帯域内および帯域外にさらに細分化できます。そのため、輸送機のトポロジに関して、繊維内の帯域内と繊維外のシグナル伝達の区別は、論理的には物理的に包埋されたコントロールプレーントポロジーの考慮に減少します。このドキュメントの範囲では、隣接するノードの各ペア間の少なくとも1つのIPコントロールチャネルが継続的に利用可能で、回復関連の情報とメッセージの交換が可能になると想定されています。したがって、どちらの場合でも（つまり、インバンドまたはバンド外）、ノードの各ペア間の少なくとも1つの論理または物理的制御チャネルが常に利用可能になると予想されます。
Therefore, the key issue when using in-fiber signaling is whether one can assume independence between the fault-tolerance capabilities of control plane and the failures affecting the transport plane (including the nodes). Note also that existing specifications like the OTN provide a limited form of independence for in-fiber signaling by dedicating a separate optical supervisory channel (OSC, see [G.709] and [G.874]) to transport the overhead and other control traffic. For OTNs, failure of the OSC does not result in failing the optical channels. Similarly, loss of the control channel must not result in failing the data channels (transport plane).
したがって、ファイバーシグナル伝達を使用する際の重要な問題は、コントロールプレーンの断層耐性能力と輸送面（ノードを含む）に影響する障害との間の独立性を想定できるかどうかです。また、OTNのような既存の仕様は、オーバーヘッドおよびその他のコントロールトラフィックを輸送するために、個別の光学監督チャネル（OSC、[G.709]および[G.874]を参照）を捧げることにより、繊維内シグナル伝達の限られた形態の独立性を提供することに注意してください。。OTNSの場合、OSCの障害は光学チャネルの障害になりません。同様に、コントロールチャネルの損失により、データチャネル（輸送面）が失敗してはなりません。
The failure detection, correlation, and notification mechanisms (described in Section 4) can be triggered when either a uni-directional or a bi-directional LSP/Span failure occurs (or a combination of both). As illustrated in Figures 1 and 2, two alternatives can be considered here:
障害検出、相関、および通知メカニズム（セクション4で説明）は、単方向LSP/SPAN障害が発生する（または両方の組み合わせ）が発生した場合にトリガーできます。図1と2に示すように、ここでは2つの選択肢を考慮することができます。
1. Uni-directional failure detection: the failure is detected on the receiver side, i.e., it is detected by only the downstream node to the failure (or by the upstream node depending on the failure propagation direction, respectively).
1. 一方向の故障検出：障害はレシーバー側で検出されます。つまり、障害の下流ノードのみ（またはそれぞれ障害伝播方向に応じて上流のノードによって検出されます）。
2. Bi-directional failure detection: the failure is detected on the receiver side of both downstream node AND upstream node to the failure.
2. 双方向の故障検出：下流ノードのレシーバー側と障害に対するアップストリームノードの両方で障害が検出されます。
Notice that after the failure detection time, if only control-plane-based failure management is provided, the peering node is unaware of the failure detection status of its neighbor.
障害検出時間の後、コントロールプレーンベースの故障管理のみが提供されている場合、ピアリングノードは隣人の障害検出ステータスを認識していないことに注意してください。
------- ------- ------- -------
| | | |Tx Rx| | | |
| NodeA |----...----| NodeB |xxxxxxxxx| NodeC |----...----| NodeD |
| |----...----| |---------| |----...----| |
------- ------- ------- -------
t0 >>>>>>> F
t1 x <---------------x
Notification
t2 <--------...--------x x--------...-------->
Up Notification Down Notification
Figure 1: Uni-directional failure detection
図1：単方向障害検出
------- ------- ------- -------
| | | |Tx Rx| | | |
| NodeA |----...----| NodeB |xxxxxxxxx| NodeC |----...----| NodeD |
| |----...----| |xxxxxxxxx| |----...----| |
------- ------- ------- -------
t0 F <<<<<<< >>>>>>> F
t1 x <-------------> x
Notification
t2 <--------...--------x x--------...-------->
Up Notification Down Notification
Figure 2: Bi-directional failure detection
図2：双方向障害検出
After failure detection, the following failure management operations can be subsequently considered:
障害検出後、次の障害管理操作をその後考慮することができます。
- Each detecting entity sends a notification message to the corresponding transmitting entity. For instance, in Figure 1, node C sends a notification message to node B. In Figure 2, node C sends a notification message to node B while node B sends a notification message to node C. To ensure reliable failure notification, a dedicated acknowledgement message can be returned back to the sender node.
- 各検出エンティティは、対応する送信エンティティに通知メッセージを送信します。たとえば、図1では、ノードCはノードBに通知メッセージを送信します。図2では、ノードCはノードBに通知メッセージを送信し、ノードBはノードCに通知メッセージを送信して、信頼できる障害通知を確保するために、専用の承認メッセージは送信者ノードに戻すことができます。
- Next, within a certain (and pre-determined) time window, nodes impacted by the failure occurrences may perform their correlation. In case of uni-directional failure, node B only receives the notification message from node C, and thus the time for this operation is negligible. In case of bi-directional failure, node B has to correlate the received notification message from node C with the corresponding locally detected information (and node C has to do the same with the message from node B).
- 次に、特定の（および事前に決定された）タイムウィンドウ内で、障害発生の影響を受けるノードは相関を実行する場合があります。一方向性障害の場合、ノードBはノードCから通知メッセージのみを受信するため、この操作の時間はごくわずかです。双方向の障害の場合、ノードBは、ノードCから受信した通知メッセージを対応するローカルで検出された情報と相関させる必要があります（ノードCはノードBからのメッセージで同じことを行う必要があります）。
- After some (pre-determined) period of time, referred to as the hold-off time, if the local recovery actions (see Section 5.3.4) were not successful, the following occurs. In case of uni-directional failure and depending on the directionality of the LSP, node B should send an upstream notification message (see [RFC3473]) to the ingress node A. Node C may send a downstream notification message (see [RFC3473]) to the egress node D. However, in that case, only node A would initiate an edge to edge recovery action. Node A is referred to as the "master", and node D is referred to as the "slave", per [RFC4427]. Note that the other LSP end-node (node D in this case) may be optionally notified using a downstream notification message (see [RFC3473]).
- ホールドオフ時間と呼ばれるいくつかの（事前に決定された）期間の後、ローカル回復アクション（セクション5.3.4を参照）が成功しなかった場合、以下が発生します。一方向性障害の場合、LSPの方向性に応じて、ノードBはアップストリーム通知メッセージ（[RFC3473]を参照）をイングレスノードAに送信する必要があります。しかし、出口ノードDには、その場合、ノードAのみがエッジからエッジリカバリアクションを開始します。ノードAは「マスター」と呼ばれ、ノードDは[RFC4427]に従って「スレーブ」と呼ばれます。他のLSPエンドノード（この場合のノードD）は、ダウンストリーム通知メッセージを使用してオプションで通知される場合があることに注意してください（[RFC3473]を参照）。
In case of bi-directional failure, node B should send an upstream notification message (see [RFC3473]) to the ingress node A. Node C may send a downstream notification message (see [RFC3473]) to the egress node D. However, due to the dependence on the LSP directionality, only ingress node A would initiate an edge-to-edge recovery action. Note that the other LSP end-node (node D in this case) should also be notified of this event using a downstream notification message (see [RFC3473]). For instance, if an LSP directed from D to A is under failure condition, only the notification message sent from node C to D would initiate a recovery action. In this case, per [RFC4427], the deciding and recovering node D is referred to as the "master", while node A is referred to as the "slave" (i.e., recovering only entity).
双方向の障害の場合、ノードBはアップストリーム通知メッセージ（[RFC3473]を参照）をイングレスノードAに送信する必要があります。LSPの方向性に依存しているため、イングレスノードAのみがエッジからエッジへの回復アクションを開始します。他のLSPエンドノード（この場合のノードD）には、下流の通知メッセージを使用してこのイベントを通知する必要があることに注意してください（[RFC3473]を参照）。たとえば、DからAに向けられたLSPが故障状態にある場合、ノードCからDに送信された通知メッセージのみが回復アクションを開始します。この場合、[RFC4427]ごとに、決定と回復のノードDは「マスター」と呼ばれ、ノードAは「スレーブ」と呼ばれます（つまり、エンティティのみを回復する）。
Note: The determination of the master and the slave may be based either on configured information or dedicated protocol capability.
注：マスターとスレーブの決定は、構成された情報または専用のプロトコル機能のいずれかに基づいている場合があります。
In the above scenarios, the path followed by the upstream and downstream notification messages does not have to be the same as the one followed by the failed LSP (see [RFC3473] for more details on the notification message exchange). The important point concerning this mechanism is that either the detecting/reporting entity (i.e., nodes B and C) is also the deciding/recovery entity or the detecting/reporting entity is simply an intermediate node in the subsequent recovery process. One refers to local recovery in the former case, and to edge-to-edge recovery in the latter one (see also Section 5.3.4).
上記のシナリオでは、上流および下流の通知メッセージの後に続くパスは、通知メッセージ交換の詳細については、故障したLSPが続いたものと同じである必要はありません（[RFC3473]を参照）。このメカニズムに関する重要なポイントは、検出/報告エンティティ（つまり、ノードBおよびC）も決定/回復エンティティであるか、検出/レポートエンティティがその後の回復プロセスの中間ノードであるということです。1つは、前者の場合の局所回復と、後者の極端な回復を指します（セクション5.3.4も参照）。
When a given span carries more than one LSP or LSP segment, an additional aspect must be considered. In case of span failure, the LSPs it carries can be recovered individually, as a group (aka bulk LSP recovery), or as independent sub-groups. When correlation time windows are used and simultaneous recovery of several LSPs can be performed using a single request, the selection of this mechanism would be triggered independently of the failure notification granularity. Moreover, criteria for forming such sub-groups are outside of the scope of this document.
特定のスパンが複数のLSPまたはLSPセグメントを運ぶ場合、追加の側面を考慮する必要があります。スパンの障害が発生した場合、それが携帯するLSPは、グループ（別名バルクLSP回復）、または独立したサブグループとして個別に回復することができます。相関時間ウィンドウが使用され、単一のリクエストを使用して複数のLSPの同時回復を実行できる場合、このメカニズムの選択は、障害通知の粒度とは無関係にトリガーされます。さらに、このようなサブグループを形成するための基準は、このドキュメントの範囲外です。
Additional complexity arises in the case of (sub-)group LSP recovery. Between a given pair of nodes, the LSPs that a given (sub-)group contains may have been created from different source nodes (i.e., initiator) and directed toward different destination nodes. Consequently the failure notification messages following a bi-directional span failure that affects several LSPs (or the whole group of LSPs it carries) are not necessarily directed toward the same initiator nodes. In particular, these messages may be directed to both the upstream and downstream nodes to the failure. Therefore, such span failure may trigger recovery actions to be performed from both sides (i.e., from both the upstream and the downstream nodes to the failure). In order to facilitate the definition of the corresponding recovery mechanisms (and their sequence), one assumes here as well that, per [RFC4427], the deciding (and recovering) entity (referred to as the "master") is the only initiator of the recovery of the whole LSP (sub-)group.
（サブ）グループLSP回復の場合、追加の複雑さが発生します。特定のノードのペア間で、特定の（サブ）グループが含まれるLSPは、異なるソースノード（つまり、イニシエーター）から作成され、異なる宛先ノードに向けられている可能性があります。その結果、いくつかのLSP（または運ぶLSPの全グループ）に影響する双方向スパン障害に続く障害通知メッセージは、必ずしも同じイニシエーターノードに向けられているわけではありません。特に、これらのメッセージは、障害への上流ノードとダウンストリームノードの両方に向けられる場合があります。したがって、そのようなスパン障害は、両側から（つまり、上流と下流のノードの両方から障害まで）回復アクションをトリガーする可能性があります。対応する回復メカニズム（およびそのシーケンス）の定義を促進するために、[RFC4427]に従って、決定（および回復）エンティティ（「マスター」と呼ばれる）が唯一の開始者であると仮定しています。LSP（サブ）グループ全体の回復。
The recovery definitions given in [RFC4427] are quite generic and apply for link (or local span) and LSP recovery. The major difference between LSP, LSP Segment and span recovery is related to the number of intermediate nodes that the signaling messages have to travel. Since nodes are not necessarily adjacent in the case of LSP (or LSP Segment) recovery, signaling message exchanges from the reporting to the deciding/recovery entity may have to cross several intermediate nodes. In particular, this applies to the notification messages due to the number of hops separating the location of a failure occurrence from its destination. This results in an additional propagation and forwarding delay. Note that the former delay may in certain circumstances be non-negligible; e.g., in a copper out-of-band network, the delay is approximately 1 ms per 200km.
[RFC4427]に記載されている回復定義は非常に一般的であり、リンク（またはローカルスパン）およびLSPリカバリに適用されます。LSP、LSPセグメント、およびスパンリカバリの大きな違いは、信号メッセージが移動する必要がある中間ノードの数に関連しています。LSP（またはLSPセグメント）の回復の場合、ノードは必ずしも隣接しているわけではないため、レポートから決定/回復エンティティへのメッセージ交換は、いくつかの中間ノードを越えなければならない場合があります。特に、これは、故障の発生の位置を宛先から分離するホップ数があるため、通知メッセージに適用されます。これにより、追加の伝播と転送の遅延が発生します。特定の状況では、前者の遅延は無視できない可能性があることに注意してください。たとえば、銅の外れのネットワークでは、遅延は200kmあたり約1ミリ秒です。
Moreover, the recovery mechanisms applicable to end-to-end LSPs and to the segments that may compose an end-to-end LSP (i.e., edge-to-edge recovery) can be exactly the same. However, one expects in the latter case, that the destination of the failure notification message will be the ingress/egress of each of these segments. Therefore, using the mechanisms described in Section 5.3.2, failure notification messages can be exchanged first between terminating points of the LSP segment, and after expiration of the hold-off time, between terminating points of the end-to-end LSP.
さらに、エンドツーエンドのLSPおよびエンドツーエンドLSP（つまり、エッジツーエッジリカバリ）を構成する可能性のあるセグメントに適用可能な回復メカニズムはまったく同じです。ただし、後者の場合、障害通知メッセージの宛先はこれらの各セグメントの侵入/出口になると予想しています。したがって、セクション5.3.2で説明したメカニズムを使用して、障害通知メッセージは、LSPセグメントの終端ポイントと、エンドツーエンドLSPの終端ポイント間の保留時間の有効期限の間で最初に交換できます。
Note: Several studies provide quantitative analysis of the relative performance of LSP/span recovery techniques. [WANG] for instance, provides an analysis grid for these techniques showing that dynamic LSP restoration (see Section 5.5.2) performs well under medium network loads, but suffers performance degradations at higher loads due to greater contention for recovery resources. LSP restoration upon span failure, as defined in [WANG], degrades at higher loads because paths around failed links tend to increase the hop count of the affected LSPs and thus consume additional network resources. Also, performance of LSP restoration can be enhanced by a failed working LSP's source node that initiates a new recovery attempt if an initial attempt fails. A single retry attempt is sufficient to produce large increases in the restoration success rate and ability to initiate successful LSP restoration attempts, especially at high loads, while not adding significantly to the long-term average recovery time. Allowing additional attempts produces only small additional gains in performance. This suggests using additional (intermediate) crankback signaling when using dynamic LSP restoration (described in Section 5.5.2 - case 2). Details on crankback signaling are outside the scope of this document.
注：いくつかの研究は、LSP/SPANリカバリテクニックの相対的なパフォーマンスの定量分析を提供します。[Wang]たとえば、これらの手法の分析グリッドは、動的なLSPの修復（セクション5.5.2を参照）が中程度のネットワーク負荷の下でうまく機能するが、回復リソースのより大きな競合によりパフォーマンスの劣化に苦しむ。[Wang]で定義されているスパン障害時のLSP回復は、故障したリンクの周りのパスが影響を受けるLSPのホップ数を増加させ、したがって追加のネットワークリソースを消費するため、より高い負荷で分解します。また、LSP修復のパフォーマンスは、最初の試行が失敗した場合に新しい回復の試みを開始する機能の失敗したLSPのソースノードによって強化されます。1回の再試行では、修復成功率と、特に高負荷でのLSP修復試行を開始する能力が大幅に増加し、長期平均回復時間を大幅に追加しません。追加の試みを許可すると、パフォーマンスがわずかな追加利益のみを生み出します。これは、動的なLSP修復を使用する場合、追加（中間）クランクバックシグナルを使用することを示唆しています（セクション5.5.2-ケース2で説明）。クランクバックシグナル伝達の詳細は、このドキュメントの範囲外です。
[RFC4427] defines the basic LSP/span recovery types. This section describes the recovery schemes that can be built using these recovery types. In brief, a recovery scheme is defined as the combination of several ingress-egress node pairs supporting a given recovery type (from the set of the recovery types they allow). Several examples are provided here to illustrate the difference between recovery types such as 1:1 or M:N, and recovery schemes such as (1:1)^n or (M:N)^n (referred to as shared-mesh recovery).
[RFC4427]は、基本的なLSP/SPANリカバリタイプを定義します。このセクションでは、これらの回復タイプを使用して構築できる回復スキームについて説明します。簡単に言えば、回復スキームは、特定の回復タイプをサポートするいくつかの侵入侵入ノードペアの組み合わせとして定義されます（許可される回復タイプのセットから）。ここでは、1：1またはm：nなどの回復タイプの違いと（1：1）^nまたは（m：n）^nなどの回復スキームを示すために、いくつかの例が提供されています（共有メッシュリカバリと呼ばれます）。
1. (1:1)^n with recovery resource sharing
1. （1：1）^n回復リソース共有を備えた
The exponent, n, indicates the number of times a 1:1 recovery type is applied between at most n different ingress-egress node pairs. Here, at most n pairs of disjoint working and recovery LSPs/spans share a common resource at most n times. Since the working LSPs/spans are mutually disjoint, simultaneous requests for use of the shared (common) resource will only occur in case of simultaneous failures, which are less likely to happen.
指数nは、最大のnの異なる侵入侵入ノードペアで1：1の回復タイプが適用される回数を示します。ここでは、ほとんどの場合、nipのワーキングと回復のnペアLSP/スパンは、ほとんどのn回で共通のリソースを共有しています。動作中のLSP/スパンは相互にばらばらであるため、共有（共通）リソースの使用の同時リクエストは、同時障害の場合にのみ発生しますが、これは発生する可能性が低くなります。
For instance, in the common (1:1)^2 case, if the 2 recovery LSPs in the group overlap the same common resource, then it can handle only single failures; any multiple working LSP failures will cause at least one working LSP to be denied automatic recovery. Consider for instance the following topology with the working LSPs A-B-C and F-G-H and their respective recovery LSPs A-D-E-C and F-D-E-H that share a common D-E link resource.
たとえば、一般的な（1：1）^2の場合、グループ内の2回の回復LSPが同じ共通リソースと重複する場合、単一の障害のみを処理できます。複数の動作LSP障害により、少なくとも1つの作業LSPが自動回復を拒否されます。たとえば、作業LSPS A-B-CおよびF-G-Hと、一般的なD-Eリンクリソースを共有するそれぞれの回復LSPSPS A-D-E-CおよびF-D-E-Hを使用した次のトポロジを検討してください。
A---------B---------C
\ /
\ /
D-------------E
/ \
/ \
F---------G---------H
2. (M:N)^n with recovery resource sharing
2. （m：n）^n回復リソース共有と
The (M:N)^n scheme is documented here for the sake of completeness only (i.e., it is not mandated that GMPLS capabilities support this scheme). The exponent, n, indicates the number of times an M:N recovery type is applied between at most n different ingress-egress node pairs. So the interpretation follows from the previous case, except that here disjointness applies to the N working LSPs/spans and to the M recovery LSPs/spans while sharing at most n times M common resources.
（m：n）^nスキームは、完全性のみのためにここに文書化されています（つまり、GMPLS機能がこのスキームをサポートすることは義務付けられていません）。指数nは、m：nの回復タイプが最大の異なる侵入侵入ノードペアの間に適用される回数を示します。したがって、解釈は以前のケースから続きますが、ここでは、n作業LSP/スパンとm回復LSP/スパンには、ほとんどのn倍の一般的なリソースを共有することを除きます。
In both schemes, it results in a "group" of sum{n=1}^N N{n} working LSPs and a pool of shared recovery resources, not all of which are available to any given working LSP. In such conditions, defining a metric that describes the amount of overlap among the recovery LSPs would give some indication of the group's ability to handle simultaneous failures of multiple LSPs.
両方のスキームで、「グループ」の合計{n = 1}^n n {n}動作LSPと共有リカバリリソースのプールが得られます。このような条件では、回復LSP間の重複量を記述するメトリックを定義すると、複数のLSPの同時障害を処理するグループの能力がある程度示されます。
For instance, in the simple (1:1)^n case, if n recovery LSPs in a (1:1)^n group overlap, then the group can handle only single failures; any simultaneous failure of multiple working LSPs will cause at least one working LSP to be denied automatic recovery. But if one considers, for instance, a (2:2)^2 group in which there are two pairs of overlapping recovery LSPs, then two LSPs (belonging to the same pair) can be simultaneously recovered. The latter case can be illustrated by the following topology with 2 pairs of working LSPs A-B-C and F-G-H and their respective recovery LSPs A-D-E-C and F-D-E-H that share two common D-E link resources.
たとえば、単純な（1：1）^nの場合、（1：1）^nグループが重複するn回復LSPの場合、グループは単一の障害のみを処理できます。複数の作業LSPの同時障害は、少なくとも1つの作業LSPが自動回復を拒否されます。しかし、たとえば、2つのペアの重複する回復LSPがある（2：2）^2グループを考慮すると、2つのLSP（同じペアに属する）を同時に回復させることができます。後者のケースは、2ペアの作業LSP A-B-CおよびF-G-Hと、2つの一般的なD-Eリンクリソースを共有するそれぞれの回復LSP A-D-E-CおよびF-D-E-Hを備えた次のトポロジーによって説明できます。
A========B========C
\\ //
\\ //
D =========== E
// \\
// \\
F========G========H
Moreover, in all these schemes, (working) path disjointness can be enforced by exchanging information related to working LSPs during the recovery LSP signaling. Specific issues related to the combination of shared (discrete) bandwidth and disjointness for recovery schemes are described in Section 8.4.2.
さらに、これらのすべてのスキームで、回復LSPシグナル伝達中に作業LSPに関連する情報を交換することにより、（動作）パスのばらばらを実施することができます。共有（個別の）帯域幅と回復スキームの分離の組み合わせに関連する特定の問題については、セクション8.4.2で説明します。
The recovery time and ratio of LSPs/spans depend on proper recovery LSP provisioning (meaning pre-provisioning when performed before failure occurrence) and the level of overbooking of recovery resources (i.e., over-provisioning). A proper balance of these two operations will result in the desired LSP/span recovery time and ratio when single or multiple failures occur. Note also that these operations are mostly performed during the network planning phases.
LSPS/スパンの回復時間と比率は、適切な回復LSPプロビジョニング（故障が発生する前に実行する場合の事前生成を意味する）と、回復リソースのオーバーブッキングレベル（つまり、過剰な導入）に依存します。これら2つの操作の適切なバランスは、単一または複数の障害が発生すると、目的のLSP/SPANリカバリ時間と比率が発生します。また、これらの操作は主にネットワーク計画フェーズ中に実行されることに注意してください。
The different options for LSP (pre-)provisioning and overbooking are classified below to structure the analysis of the different recovery mechanisms.
LSP（Pre-）のプロビジョニングとオーバーブッキングのさまざまなオプションを以下に分類して、異なる回復メカニズムの分析を構成します。
1. Pre-Provisioning
1. 事前訪問
Proper recovery LSP pre-provisioning will help to alleviate the failure of the working LSPs (due to the failure of the resources that carry these LSPs). As an example, one may compute and establish the recovery LSP either end-to-end or segment-per-segment, to protect a working LSP from multiple failure events affecting link(s), node(s) and/or SRLG(s). The recovery LSP pre-provisioning options are classified as follows in the figure below:
適切な回復LSP事前プロビジョニングは、作業LSPの障害を軽減するのに役立ちます（これらのLSPを運ぶリソースの失敗により）。例として、リンク、ノード、および/またはSRLG（s（s）に影響を与える複数の障害イベントから作業LSPを保護するために、セグメントごとに回復LSPを計算および確立することができます。）。リカバリLSPの事前プロビジョニングオプションは、以下の図に次のように分類されています。
(1) The recovery path can be either pre-computed or computed on-demand.
(1) 回復パスは、事前に計算されるか、オンデマンドを計算できます。
(2) When the recovery path is pre-computed, it can be either pre-signaled (implying recovery resource reservation) or signaled on-demand.
(2) 回復パスが事前に計算された場合、それは事前にシグナル（回復リソースの予約を暗示する）か、オンデマンドに合図することができます。
(3) When the recovery resources are pre-signaled, they can be either pre-selected or selected on-demand.
(3) 回復リソースが事前に署名されている場合、それらは事前に選択されるか、オンデマンドを選択できます。
Recovery LSP provisioning phases:
(1) Path Computation --> On-demand
|
|
--> Pre-Computed
|
|
(2) Signaling --> On-demand
|
|
--> Pre-Signaled
|
|
(3) Resource Selection --> On-demand
|
|
--> Pre-Selected
Note that these different options lead to different LSP/span recovery times. The following sections will consider the above-mentioned pre-provisioning options when analyzing the different recovery mechanisms.
これらの異なるオプションは、異なるLSP/SPANリカバリ時間につながることに注意してください。以下のセクションでは、さまざまな回復メカニズムを分析する際に、上記の事前プロビジョニングオプションを検討します。
2. Overbooking
2. オーバーブッキング
There are many mechanisms available that allow the overbooking of the recovery resources. This overbooking can be done per LSP (as in the example mentioned above), per link (such as span protection), or even per domain. In all these cases, the level of overbooking, as shown in the below figure, can be classified as dedicated (such as 1+1 and 1:1), shared (such as 1:N and M:N), or unprotected (and thus restorable, if enough recovery resources are available).
回復リソースのオーバーブッキングを可能にする多くのメカニズムが利用可能です。このオーバーブッキングは、LSP（上記の例のように）、リンクごと（スパン保護など）、またはドメインごとに行うことができます。これらのすべての場合、下の図に示すように、オーバーブッキングのレベルは、専用（1 1および1：1など）、共有（1：nおよびm：nなど）、または保護されていない（および保護されていないものとして分類できます。したがって、十分な回復リソースが利用可能な場合、回復可能です）。
Overbooking levels:
オーバーブッキングレベル：
+----- Dedicated (for instance: 1+1, 1:1, etc.)
|
|
+----- Shared (for instance: 1:N, M:N, etc.)
|
Level of |
Overbooking -----+----- Unprotected (for instance: 0:1, 0:N)
Also, when using shared recovery, one may support preemptible extra-traffic; the recovery mechanism is then expected to allow preemption of this low priority traffic in case of recovery resource contention during recovery operations. The following sections will consider the above-mentioned overbooking options when analyzing the different recovery mechanisms.
また、共有リカバリを使用する場合、プリエンプション可能な人形中のトラフィックをサポートする場合があります。回復メカニズムは、回復操作中に回復リソースの競合の場合に、この低優先度トラフィックの先制が可能になると予想されます。次のセクションでは、さまざまな回復メカニズムを分析する際に、上記のオーバーブッキングオプションを検討します。
The following times are defined to provide a quantitative estimation about the time performance of the different LSP restoration mechanisms (also referred to as LSP re-routing):
次の時間は、異なるLSP修復メカニズムの時間性能に関する定量的推定を提供するために定義されています（LSPの再ルーティングとも呼ばれます）。
- Path Computation Time: Tc - Path Selection Time: Ts - End-to-end LSP Resource Reservation Time: Tr (a delta for resource selection is also considered, the corresponding total time is then referred to as Trs) - End-to-end LSP Resource Activation Time: Ta (a delta for resource selection is also considered, the corresponding total time is then referred to as Tas)
- パス計算時間：TC-パス選択時間：TS-エンドツーエンドのLSPリソース予約時間：TR（リソース選択のデルタも考慮されます、対応する合計時間はTRSと呼ばれます） - エンドツーエンドLSPリソースのアクティベーション時間：TA（リソース選択のデルタも考慮され、対応する合計時間はTASと呼ばれます）
The Path Selection Time (Ts) is considered when a pool of recovery LSP paths between a given pair of source/destination end-points is pre-computed, and after a failure occurrence one of these paths is selected for the recovery of the LSP under failure condition.
パス選択時間（TS）は、ソース/宛先エンドポイントの特定のペア間の回復LSPパスのプールが事前に計算され、障害が発生した後、これらのパスの1つがLSPの回復のために選択された場合に考慮されます。故障状態。
Note: failure management operations such as failure detection, correlation, and notification are considered (for a given failure event) as equally time-consuming for all the mechanisms described below:
注：障害検出、相関、通知などの障害管理操作は、以下に説明するすべてのメカニズムに対して等しく時間がかかるものと見なされます。
1. With Route Pre-computation (or LSP re-provisioning)
1. ルートの事前計算（またはLSPの再構成）を使用して
An end-to-end restoration LSP is established after the failure(s) occur(s) based on a pre-computed path. As such, one can define this as an "LSP re-provisioning" mechanism. Here, one or more (disjoint) paths for the restoration LSP are computed (and optionally pre-selected) before a failure occurs.
エンドツーエンドの修復LSPは、事前に計算されたパスに基づいて障害が発生した後に確立されます。そのため、これを「LSP再構成」メカニズムとして定義できます。ここでは、障害が発生する前に、復元LSPの1つ以上の（nisjoint）パスが計算されます（オプションで事前に選択されます）。
No reservation or selection of resources is performed along the restoration path before failure occurrence. As a result, there is no guarantee that a restoration LSP is available when a failure occurs.
故障が発生する前に、リソースの予約や選択は修復パスに沿って実行されません。その結果、障害が発生したときに復元LSPが利用できるという保証はありません。
The expected total restoration time T is thus equal to Ts + Trs or to Trs when a dedicated computation is performed for each working LSP.
したがって、予想される総回復時間tは、作業用LSPごとに専用計算が実行される場合のTS TRSまたはTRSに等しくなります。
2. Without Route Pre-computation (or Full LSP re-routing)
2. ルートの事前計算（または完全なLSPの再ルーティング）なし
An end-to-end restoration LSP is dynamically established after the failure(s) occur(s). After failure occurrence, one or more (disjoint) paths for the restoration LSP are dynamically computed and one is selected. As such, one can define this as a complete "LSP re-routing" mechanism.
エンドツーエンドの修復LSPは、障害が発生した後に動的に確立されます。障害が発生した後、復元LSPの1つ以上の（分離）パスが動的に計算され、1つが選択されます。そのため、これを完全な「LSP再ルーティング」メカニズムとして定義できます。
No reservation or selection of resources is performed along the restoration path before failure occurrence. As a result, there is no guarantee that a restoration LSP is available when a failure occurs.
故障が発生する前に、リソースの予約や選択は修復パスに沿って実行されません。その結果、障害が発生したときに復元LSPが利用できるという保証はありません。
The expected total restoration time T is thus equal to Tc (+ Ts) + Trs. Therefore, time performance between these two approaches differs by the time required for route computation Tc (and its potential selection time, Ts).
したがって、予想される総回復時間tはTC（TS）TRSに等しくなります。したがって、これら2つのアプローチ間の時間パフォーマンスは、ルート計算TC（およびその潜在的な選択時間、TS）に必要な時間とともに異なります。
Pre-planned LSP restoration (also referred to as pre-planned LSP re-routing) implies that the restoration LSP is pre-signaled. This in turn implies the reservation of recovery resources along the restoration path. Two cases can be defined based on whether the recovery resources are pre-selected.
事前に計画されたLSP復元（事前に計画されたLSPの再ルーティングとも呼ばれます）は、復元LSPが事前にシグナル化されていることを意味します。これは、回復経路に沿った回復リソースの留保を意味します。回復リソースが事前に選択されているかどうかに基づいて、2つのケースを定義できます。
1. With resource reservation and without resource pre-selection
1. リソースの予約とリソースの事前選択なし
Before failure occurrence, an end-to-end restoration path is pre-selected from a set of pre-computed (disjoint) paths. The restoration LSP is signaled along this pre-selected path to reserve resources at each node, but these resources are not selected.
障害が発生する前に、エンドツーエンドの修復パスは、事前に計算された（馬鹿げた）パスのセットから事前に選択されます。修復LSPは、各ノードのリソースを予約するためにこの事前に選択されたパスに沿って合図されますが、これらのリソースは選択されていません。
In this case, the resources reserved for each restoration LSP may be dedicated or shared between multiple restoration LSPs whose working LSPs are not expected to fail simultaneously. Local node policies can be applied to define the degree to which these resources can be shared across independent failures. Also, since a restoration scheme is considered, resource sharing should not be limited to restoration LSPs that start and end at the same ingress and egress nodes. Therefore, each node participating in this scheme is expected to receive some feedback information on the sharing degree of the recovery resource(s) that this scheme involves.
この場合、各修復LSPに予約されたリソースは、作業LSPが同時に失敗すると予想される複数の復元LSP間で専用または共有される場合があります。ローカルノードポリシーを適用して、独立した障害全体でこれらのリソースを共有できる程度を定義できます。また、復元スキームが考慮されるため、リソース共有は、同じ入り込みノードと出口ノードで開始および終了する復元LSPに限定されるべきではありません。したがって、このスキームに参加する各ノードは、このスキームが関与する回復リソースの共有度に関するフィードバック情報を受け取ることが期待されます。
Upon failure detection/notification message reception, signaling is initiated along the restoration path to select the resources, and to perform the appropriate operation at each node crossed by the restoration LSP (e.g., cross-connections). If lower priority LSPs were established using the restoration resources, they must be preempted when the restoration LSP is activated.
障害検出/通知メッセージ受信時に、リソースを選択し、修復LSP（クロス接続など）と交差した各ノードで適切な操作を実行するための復元パスに沿ってシグナリングが開始されます。回復リソースを使用して低い優先度LSPが確立された場合、修復LSPがアクティブになったときに先制する必要があります。
Thus, the expected total restoration time T is equal to Tas (post-failure activation), while operations performed before failure occurrence take Tc + Ts + Tr.
したがって、予想される総回復時間tはTAS（故障後の活性化）に等しく、故障の発生前に実行される操作はtc ts trを取ります。
2. With both resource reservation and resource pre-selection
2. リソースの予約とリソースの両方の選択の両方を備えています
Before failure occurrence, an end-to-end restoration path is pre-selected from a set of pre-computed (disjoint) paths. The restoration LSP is signaled along this pre-selected path to reserve AND select resources at each node, but these resources are not committed at the data plane level. So that the selection of the recovery resources is committed at the control plane level only, no cross-connections are performed along the restoration path.
障害が発生する前に、エンドツーエンドの修復パスは、事前に計算された（馬鹿げた）パスのセットから事前に選択されます。修復LSPは、各ノードでリソースを予約および選択するために、この事前に選択されたパスに沿って合図されますが、これらのリソースはデータプレーンレベルではコミットされていません。リカバリリソースの選択が制御プレーンレベルでのみコミットされるように、回復パスに沿って相互接続は実行されません。
In this case, the resources reserved and selected for each restoration LSP may be dedicated or even shared between multiple restoration LSPs whose associated working LSPs are not expected to fail simultaneously. Local node policies can be applied to define the degree to which these resources can be shared across independent failures. Also, because a restoration scheme is considered, resource sharing should not be limited to restoration LSPs that start and end at the same ingress and egress nodes. Therefore, each node participating in this scheme is expected to receive some feedback information on the sharing degree of the recovery resource(s) that this scheme involves.
この場合、各修復LSPに対して予約および選択されたリソースは、関連するLSPが同時に失敗するとは予想されない複数の修復LSP間で専用または共有される場合があります。ローカルノードポリシーを適用して、独立した障害全体でこれらのリソースを共有できる程度を定義できます。また、復元スキームが考慮されるため、リソース共有は、同じ入り込みノードと出力ノードで開始および終了する復元LSPに限定されるべきではありません。したがって、このスキームに参加する各ノードは、このスキームが関与する回復リソースの共有度に関するフィードバック情報を受け取ることが期待されます。
Upon failure detection/notification message reception, signaling is initiated along the restoration path to activate the reserved and selected resources, and to perform the appropriate operation at each node crossed by the restoration LSP (e.g., cross-connections). If lower priority LSPs were established using the restoration resources, they must be preempted when the restoration LSP is activated.
障害検出/通知メッセージ受信時に、修復パスに沿ってシグナリングが開始され、予約されたリソースと選択されたリソースをアクティブにし、修復LSP（例：クロス接続）と交差する各ノードで適切な操作を実行します。回復リソースを使用して低い優先度LSPが確立された場合、修復LSPがアクティブになったときに先制する必要があります。
Thus, the expected total restoration time T is equal to Ta (post-failure activation), while operations performed before failure occurrence take Tc + Ts + Trs. Therefore, time performance between these two approaches differs only by the time required for resource selection during the activation of the recovery LSP (i.e., Tas - Ta).
したがって、予想される総回復時間tはTA（故障後の活性化）に等しく、故障が発生する前に実行される操作はTC TS TRSを取得します。したがって、これら2つのアプローチ間の時間パフォーマンスは、リカバリLSP（つまり、TAS -TA）の活性化中にリソース選択に必要な時間によってのみ異なります。
The above approaches can be applied on an edge-to-edge LSP basis rather than end-to-end LSP basis (i.e., to reduce the global recovery time) by allowing the recovery of the individual LSP segments constituting the end-to-end LSP.
上記のアプローチは、エンドツーエンドを構成する個々のLSPセグメントの回復を可能にすることにより、エンドツーエンドのLSPベースではなく（つまり、グローバルな回復時間を短縮するため）、エッジツーエッジLSPベースで適用できます。lsp。
Also, by using the horizontal hierarchy approach described in Section 7.1, an end-to-end LSP can be recovered by multiple recovery mechanisms applied on an LSP segment basis (e.g., 1:1 edge-to-edge LSP protection in a metro network, and M:N edge-to-edge protection in the core). These mechanisms are ideally independent and may even use different failure localization and notification mechanisms.
また、セクション7.1で説明されている水平階層アプローチを使用することにより、LSPセグメントベースで適用される複数の回復メカニズムによってエンドツーエンドのLSPを回復できます（たとえば、メトロネットワークで1：1エッジツーエッジLSP保護、およびM：nコアのエッジからエッジへの保護）。これらのメカニズムは理想的には独立しており、異なる障害のローカリゼーションと通知メカニズムを使用することさえあります。
Reversion (a.k.a. normalization) is defined as the mechanism allowing switching of normal traffic from the recovery LSP/span to the working LSP/span previously under failure condition. Use of normalization is at the discretion of the recovery domain policy. Normalization may impact the normal traffic (a second hit) depending on the normalization mechanism used.
復帰（別名正規化）は、故障条件下での回復LSP/SPANから以前に動作するLSP/スパンへの通常のトラフィックの切り替えを可能にするメカニズムとして定義されます。正規化の使用は、回復ドメインポリシーの裁量にあります。正規化は、使用される正規化メカニズムに応じて、通常のトラフィック（2回目のヒット）に影響を与える可能性があります。
If normalization is supported, then 1) the LSP/span must be returned to the working LSP/span when the failure condition clears and 2) the capability to de-activate (turn-off) the use of reversion should be provided. De-activation of reversion should not impact the normal traffic, regardless of whether it is currently using the working or recovery LSP/span.
正規化がサポートされている場合、1）故障条件がクリアされたときにLSP/SPANを動作LSP/SPANに戻す必要があり、2）復帰の使用を解除（ターンオフ）する能力を提供する必要があります。現在作業LSP/スパンを使用しているか回復しているかにかかわらず、復帰の脱復活は通常のトラフィックに影響を及ぼさないはずです。
Note: during the failure, the reuse of any non-failed resources (e.g., LSP and/or spans) belonging to the working LSP/span is under the discretion of recovery domain policy.
注：障害中、作業用LSP/スパンに属する非失敗リソース（LSPおよび/またはスパンなど）の再利用は、回復ドメインポリシーの裁量下にあります。
A specific mechanism (Wait-To-Restore) is used to prevent frequent recovery switching operations due to an intermittent defect (e.g., Bit Error Rate (BER) fluctuating around the SD threshold).
特定のメカニズム（待機対策）を使用して、断続的な欠陥（SDしきい値の周りにビットエラー率（BER）が変動する）による頻繁な回復スイッチング操作を防ぐために使用されます。
First, an LSP/span under failure condition must become fault-free, e.g., a BER less than a certain recovery threshold. After the recovered LSP/span (i.e., the previously working LSP/span) meets this criterion, a fixed period of time shall elapse before normal traffic uses the corresponding resources again. This duration called Wait-To-Restore (WTR) period or timer is generally on the order of a few minutes (for instance, 5 minutes) and should be capable of being set. The WTR timer may be either a fixed period, or provide for incrementally longer periods before retrying. An SF or SD condition on the previously working LSP/span will override the WTR timer value (i.e., the WTR cancels and the WTR timer will restart).
第一に、故障状態でのLSP/スパンは、特定の回復のしきい値よりも少ない例えば、障害のないものになる必要があります。回収されたLSP/SPAN（つまり、以前に作業していたLSP/SPAN）がこの基準を満たした後、通常のトラフィックが再び対応するリソースを使用する前に、固定期間が経過するでしょう。Wait-to-Restore（WTR）期間またはタイマーと呼ばれるこの期間は、通常、数分（たとえば、5分）の順にあり、設定できる必要があります。WTRタイマーは固定期間であるか、再試行する前に徐々に長い期間を提供する場合があります。以前に作業していたLSP/SPANのSFまたはSD条件は、WTRタイマーの値をオーバーライドします（つまり、WTRキャンセルとWTRタイマーが再起動します）。
In revertive mode of operation, when the recovery LSP/span is no longer required, i.e., the failed working LSP/span is no longer in SD or SF condition, a local Wait-to-Restore (WTR) state will be activated before switching the normal traffic back to the recovered working LSP/span.
回復モードの動作モードでは、リカバリLSP/スパンが不要になった場合、つまり機能したLSP/SPANがSDまたはSF状態ではなくなった場合、切り替える前にローカル待機対策（WTR）状態がアクティブになります。回収された作業LSP/スパンに戻る通常のトラフィック。
During the reversion operation, since this state becomes the highest in priority, signaling must maintain the normal traffic on the recovery LSP/span from the previously failed working LSP/span. Moreover, during this WTR state, any null traffic or extra traffic (if applicable) request is rejected.
復帰操作中、この状態が優先度が最も高くなるため、シグナル伝達は、以前に機能したLSP/スパンから回復LSP/スパンの通常のトラフィックを維持する必要があります。さらに、このWTR状態では、ヌルトラフィックまたは余分なトラフィック（該当する場合）要求が拒否されます。
However, deactivation (cancellation) of the wait-to-restore timer may occur if there are higher priority request attempts. That is, the recovery LSP/span usage by the normal traffic may be preempted if a higher priority request for this recovery LSP/span is attempted.
ただし、優先度の高いリクエストの試行が高い場合、待機対象タイマーの非アクティブ化（キャンセル）が発生する可能性があります。つまり、この回復LSP/スパンのより高い優先度要求が試行された場合、通常のトラフィックによる回復LSP/SPANの使用法が先取りされる場合があります。
When a reversion operation is requested, normal traffic must be switched from the recovery to the recovered working LSP/span. A particular situation occurs when the previously working LSP/span cannot be recovered, so normal traffic cannot be switched back. In that case, the LSP/span under failure condition (also referred to as "orphan") must be cleared (i.e., removed) from the pool of resources allocated for normal traffic. Otherwise, potential de-synchronization between the control and transport plane resource usage can appear. Depending on the signaling protocol capabilities and behavior, different mechanisms are expected here.
復帰操作が要求される場合、通常のトラフィックを回復から回収した作業LSP/スパンに切り替える必要があります。特定の状況は、以前に作業していたLSP/スパンを回復できない場合に発生するため、通常のトラフィックを戻すことができません。その場合、故障条件下でのLSP/スパン（「孤児」とも呼ばれます）は、通常のトラフィックに割り当てられたリソースのプールからクリア（つまり、削除されます）をクリアする必要があります。それ以外の場合は、制御と輸送機のリソースの使用率の間の潜在的な非同期が現れる可能性があります。信号プロトコルの機能と動作に応じて、ここでは異なるメカニズムが予想されます。
Therefore, any reserved or allocated resources for the LSP/span under failure condition must be unreserved/de-allocated. Several ways can be used for that purpose: wait for the clear-out time interval to elapse, initiate a deletion from the ingress or the egress node, or trigger the initiation of deletion from an entity (such as an EMS or NMS) capable of reacting upon reception of an appropriate notification message.
したがって、障害条件下でのLSP/スパンの予約済みまたは割り当てられたリソースは、予約されていない/脱アロークされなければなりません。その目的のためにいくつかの方法を使用することができます：クリアアウト時間間隔が経過するのを待ち、イングレスまたは出口ノードからの削除を開始するか、またはできるエンティティ（EMSやNMSなど）からの削除の開始をトリガーします適切な通知メッセージを受信すると反応します。
Recovery mechanisms are being made available at multiple (if not all) transport layers within so-called "IP/MPLS-over-optical" networks. However, each layer has certain recovery features, and one needs to determine the exact impact of the interaction between the recovery mechanisms provided by these layers.
回復メカニズムは、いわゆる「IP/MPLS-Over-Over-Optical」ネットワーク内の複数の（すべてではないにしても）輸送層で利用可能になります。ただし、各レイヤーには特定の回復機能があり、これらのレイヤーによって提供される回復メカニズム間の相互作用の正確な影響を決定する必要があります。
Hierarchies are used to build scalable complex systems. By hiding the internal details, abstraction is used as a mechanism to build large networks or as a technique for enforcing technology, topological, or administrative boundaries. The same hierarchical concept can be applied to control the network survivability. Network survivability is the set of capabilities that allow a network to restore affected traffic in the event of a failure. Network survivability is defined further in [RFC4427]. In general, it is expected that the recovery action is taken by the recoverable LSP/span closest to the failure in order to avoid the multiplication of recovery actions. Moreover, recovery hierarchies also can be bound to control plane logical partitions (e.g., administrative or topological boundaries). Each logical partition may apply different recovery mechanisms.
階層は、スケーラブルな複雑なシステムを構築するために使用されます。内部の詳細を隠すことにより、抽象化は、大規模なネットワークを構築するためのメカニズムとして、またはテクノロジー、トポロジー、または管理の境界を施行するための手法として使用されます。ネットワークの生存性を制御するために、同じ階層概念を適用できます。ネットワークの生存性は、ネットワークが障害の場合に影響を受けたトラフィックを復元できるようにする一連の機能です。ネットワークの生存性は、[RFC4427]でさらに定義されています。一般に、回復アクションは、回復アクションの増殖を回避するために、障害に最も近い回復可能なLSP/スパンによって行われることが予想されます。さらに、回復階層は、平面の論理パーティション（たとえば、管理またはトポロジーの境界）を制御することもできます。各論理パーティションは、異なる回復メカニズムを適用する場合があります。
In brief, it is commonly accepted that the lower layers can provide coarse but faster recovery while the higher layers can provide finer but slower recovery. Moreover, it is also desirable to avoid similar layers with functional overlaps in order to optimize network resource utilization and processing overhead, since repeating the same capabilities at each layer does not create any added value for the network as a whole. In addition, even if a lower layer recovery mechanism is enabled, it does not prevent the additional provision of a recovery mechanism at the upper layer. The inverse statement does not necessarily hold; that is, enabling an upper layer recovery mechanism may prevent the use of a lower layer recovery mechanism. In this context, this section analyzes these hierarchical aspects including the physical (passive) layer(s).
簡単に言えば、下層層は粗いが速い回復を提供できるが、より高い層はより細かいが遅い回復を提供できることが一般的に受け入れられています。さらに、各レイヤーで同じ機能を繰り返してもネットワーク全体に付加値を作成しないため、ネットワークリソースの使用率とオーバーヘッドの処理を最適化するために、機能的な重複を備えた同様のレイヤーを回避することも望ましいです。さらに、下層回復メカニズムが有効になっていても、上層での回復メカニズムの追加の提供を妨げません。逆ステートメントは必ずしも保持されません。つまり、上層の回復メカニズムを有効にすると、下層回復メカニズムの使用が妨げられる可能性があります。これに関連して、このセクションでは、物理的（パッシブ）層を含むこれらの階層的側面を分析します。
A horizontal hierarchy is defined when partitioning a single-layer network (and its control plane) into several recovery domains. Within a domain, the recovery scope may extend over a link (or span), LSP segment, or even an end-to-end LSP. Moreover, an administrative domain may consist of a single recovery domain or can be partitioned into several smaller recovery domains. The operator can partition the network into recovery domains based on physical network topology, control plane capabilities, or various traffic engineering constraints.
水平階層は、単一層ネットワーク（およびその制御面）をいくつかの回復ドメインに分割するときに定義されます。ドメイン内では、回復スコープはリンク（またはスパン）、LSPセグメント、またはエンドツーエンドのLSPに及ぶ場合があります。さらに、管理ドメインは、単一の回復ドメインで構成されている場合や、いくつかの小さなリカバリドメインに分割することができます。オペレーターは、物理ネットワークトポロジ、制御プレーン機能、またはさまざまなトラフィックエンジニアリングの制約に基づいて、ネットワークを回復ドメインに分割できます。
An example often addressed in the literature is the metro-core-metro application (sometimes extended to a metro-metro/core-core) within a single transport layer (see Section 7.2). For such a case, an end-to-end LSP is defined between the ingress and egress metro nodes, while LSP segments may be defined within the metro or core sub-networks. Each of these topological structures determines a so-called "recovery domain" since each of the LSPs they carry can have its own recovery type (or even scheme). The support of multiple recovery types and schemes within a sub-network is referred to as a "multi-recovery capable domain" or simply "multi-recovery domain".
文献でよく扱われる例は、単一の輸送層内のメトロコアメトロアプリケーション（メトロメトロ/コアコアに拡張されることもある）です（セクション7.2を参照）。このような場合、エンドツーエンドのLSPは、イングレスメトロノードと出力メトロノードの間に定義され、LSPセグメントはMetroまたはCoreサブネットワーク内で定義できます。これらの各トポロジ構造は、運ぶLSPのそれぞれに独自の回復タイプ（またはスキーム）を持つことができるため、いわゆる「回復ドメイン」を決定します。サブネットワーク内の複数の回復タイプとスキームのサポートは、「マルチリクアーバル対応ドメイン」または単に「マルチリクアーバルドメイン」と呼ばれます。
It is very challenging to combine the different recovery capabilities available across the path (i.e., switching capable) and section layers to ensure that certain network survivability objectives are met for the network-supported services.
パス全体で利用可能なさまざまなリカバリ機能（つまり、スイッチング対応）とセクションレイヤーを組み合わせて、ネットワークがサポートするサービスで特定のネットワークサバイバリティ目標が満たされるようにすることは非常に困難です。
As a first analysis step, one can draw the following guidelines for a vertical coordination of the recovery mechanisms:
最初の分析ステップとして、回復メカニズムの垂直調整のために次のガイドラインを描くことができます。
- The lower the layer, the faster the notification and switching.
- レイヤーが低いほど、通知と切り替えが速くなります。
- The higher the layer, the finer the granularity of the recoverable entity and therefore the granularity of the recovery resource.
- 層が高いほど、回復可能なエンティティの粒度が細かく、したがって回収リソースの粒度が細かくなります。
Moreover, in the context of this analysis, a vertical hierarchy consists of multiple layered transport planes providing different:
さらに、この分析のコンテキストでは、垂直階層は、異なる階層化された輸送機で構成されています。
- Discrete bandwidth granularities for non-packet LSPs such as OCh, ODUk, STS_SPE/HOVC, and VT_SPE/LOVC LSPs and continuous bandwidth granularities for packet LSPs.
- OCH、ODUK、STS_SPE/HOVC、VT_SPE/LOVC LSPSおよびパケットLSPの連続帯域幅粒度などの非パケットLSPの離散帯域幅の粒度。
- Potential recovery capabilities with different temporal granularities: ranging from milliseconds to tens of seconds
- 異なる時間的粒度を持つ潜在的な回復機能：ミリ秒から数十秒までの範囲
Note: based on the bandwidth granularity, we can determine four classes of vertical hierarchies: (1) packet over packet, (2) packet over circuit, (3) circuit over packet, and (4) circuit over circuit. Below we briefly expand on (4) only. (2) is covered in [RFC3386]. (1) is extensively covered by the MPLS Working Group, and (3) by the PWE3 Working Group.
注：帯域幅の粒度に基づいて、4つのクラスの垂直階層を決定できます：（1）パケット上のパケット、（2）回路上のパケット、（3）パケット上の回路、および（4）回路上の回路以下では、（4）のみを簡単に展開します。（2）[RFC3386]で覆われています。（1）MPLSワーキンググループによって広くカバーされており、（3）PWE3ワーキンググループによってカバーされています。
In SONET/SDH environments, one typically considers the VT_SPE/LOVC and STS SPE/HOVC as independent layers (for example, VT_SPE/LOVC LSP uses the underlying STS_SPE/HOVC LSPs as links). In OTN, the ODUk path layers will lie on the OCh path layer, i.e., the ODUk LSPs use the underlying OCh LSPs as OTUk links. Note here that lower layer LSPs may simply be provisioned and not necessarily dynamically triggered or established (control driven approach). In this context, an LSP at the path layer (i.e., established using GMPLS signaling), such as an optical channel LSP, appears at the OTUk layer as a link, controlled by a link management protocol such as LMP.
SONET/SDH環境では、通常、VT_SPE/LOVCおよびSTS SPE/HOVCを独立層と見なします（たとえば、VT_SPE/LOVC LSPは、基礎となるSTS_SPE/HOVC LSPSをリンクとして使用します）。OTNでは、ODUKパスレイヤーはOCHパスレイヤーにあります。つまり、ODUK LSPは、基礎となるOCH LSPをOTUKリンクとして使用します。ここでは、下層LSPが単にプロビジョニングされ、必ずしも動的にトリガーまたは確立されているわけではないことに注意してください（制御駆動型アプローチ）。これに関連して、光チャネルLSPなどのパス層のLSP（つまり、GMPLSシグナルを使用して確立）は、LMPなどのリンク管理プロトコルによって制御されるリンクとしてOTUKレイヤーに表示されます。
The first key issue with multi-layer recovery is that achieving individual or bulk LSP recovery will be as efficient as the underlying link (local span) recovery. In such a case, the span can be either protected or unprotected, but the LSP it carries must be (at least locally) recoverable. Therefore, the span recovery process can be either independent when protected (or restorable), or triggered by the upper LSP recovery process. The former case requires coordination to achieve subsequent LSP recovery. Therefore, in order to achieve robustness and fast convergence, multi-layer recovery requires a fine-tuned coordination mechanism.
多層回復の最初の重要な問題は、個人またはバルクのLSP回復を達成することは、基礎となるリンク（ローカルスパン）回復と同じくらい効率的であることです。そのような場合、スパンは保護または保護されていない場合がありますが、運ぶLSPは（少なくとも局所的に）回復可能でなければなりません。したがって、スパンリカバリプロセスは、保護された場合（または回復可能）、LSP上部の回復プロセスによってトリガーされる場合に独立している場合があります。前者のケースでは、その後のLSP回復を達成するために調整が必要です。したがって、堅牢性と速い収束を達成するためには、多層回復には微調整された調整メカニズムが必要です。
Moreover, in the absence of adequate recovery mechanism coordination (for instance, a pre-determined coordination when using a hold-off timer), a failure notification may propagate from one layer to the next one within a recovery hierarchy. This can cause "collisions" and trigger simultaneous recovery actions that may lead to race conditions and, in turn, reduce the optimization of the resource utilization and/or generate global instabilities in the network (see [MANCHESTER]). Therefore, a consistent and efficient escalation strategy is needed to coordinate recovery across several layers.
さらに、適切な回復メカニズムの調整（たとえば、ホールドオフタイマーを使用する場合の事前に決められた調整）がない場合、障害通知は、1つのレイヤーからリカバリ階層内の次のレイヤーに伝播する場合があります。これにより、「衝突」を引き起こし、人種条件につながる可能性のある同時回復アクションをトリガーし、リソースの利用の最適化を減らし、ネットワーク内のグローバルな不安定性を生成します（[マンチェスター]を参照）。したがって、いくつかの層全体で回復を調整するには、一貫した効率的なエスカレーション戦略が必要です。
One can expect that the definition of the recovery mechanisms and protocol(s) is technology-independent so that they can be consistently implemented at different layers; this would in turn simplify their global coordination. Moreover, as mentioned in [RFC3386], some looser form of coordination and communication between (vertical) layers such as a consistent hold-off timer configuration (and setup through signaling during the working LSP establishment) can be considered, thereby allowing the synchronization between recovery actions performed across these layers.
回復メカニズムとプロトコルの定義は、テクノロジーに依存しないため、異なる層で一貫して実装できることが期待できます。これにより、グローバルな調整が簡素化されます。さらに、[RFC3386]で述べたように、一貫したホールドオフタイマー構成（および作業LSPの確立中にシグナリングを介したセットアップ）などの（垂直）層間の調整と通信のいくつかのゆるい形式を考慮して、それによって同期を可能にすることができます。これらのレイヤーで実行された回復アクション。
In most environments, the design of the network and the vertical distribution of the LSP bandwidth are such that the recovery granularity is finer at higher layers. The OTN and SONET/SDH layers can recover only the whole section or the individual connections they transports whereas the IP/MPLS control plane can recover individual packet LSPs or groups of packet LSPs independently of their granularity. On the other side, the recovery granularity at the sub-wavelength level (i.e., SONET/SDH) can be provided only when the network includes devices switching at the same granularity (and thus not with optical channel level). Therefore, the network layer can deliver control-plane-driven recovery mechanisms on a per-LSP basis if and only if these LSPs have their corresponding switching granularity supported at the transport plane level.
ほとんどの環境では、ネットワークの設計とLSP帯域幅の垂直分布は、回復粒度が高層でより細かくなるようなものです。OTNおよびSONET/SDHレイヤーは、輸送するセクション全体または個々の接続のみを回復できますが、IP/MPLSコントロールプレーンは、個々のパケットLSPまたは粒度とは無関係にパケットLSPのグループを回収できます。一方、サブ波長レベル（つまり、SONET/SDH）での回復粒度は、ネットワークに同じ粒度で切り替えるデバイスを含む（したがって光学チャネルレベルではない）場合にのみ提供できます。したがって、ネットワークレイヤーは、これらのLSPが輸送面レベルでサポートされている対応するスイッチング粒度がサポートされている場合にのみ、Control-Plane駆動型の回復メカニズムをlspごとに提供できます。
There are two types of escalation strategies (see [DEMEESTER]): bottom-up and top-down.
エスカレーション戦略には2つのタイプがあります（[Demeester]を参照）、ボトムアップとトップダウン。
The bottom-up approach assumes that lower layer recovery types and schemes are more expedient and faster than upper layer ones. Therefore, we can inhibit or hold off higher layer recovery. However, this assumption is not entirely true. Consider for instance a SONET/SDH based protection mechanism (with a protection switching time of less than 50 ms) lying on top of an OTN restoration mechanism (with a restoration time of less than 200 ms). Therefore, this assumption should be (at least) clarified as: the lower layer recovery mechanism is expected to be faster than the upper level one, if the same type of recovery mechanism is used at each layer.
ボトムアップのアプローチは、下層の回復タイプとスキームが上層層のものよりも適切で高速であると想定しています。したがって、より高い層の回復を阻害または抑制することができます。ただし、この仮定は完全に真実ではありません。たとえば、OTN修復メカニズムの上にあるSONET/SDHベースの保護メカニズム（50ミリ秒未満の保護スイッチング時間を使用）を検討してください（回復時間は200ミリ秒未満）。したがって、この仮定は（少なくとも）明確にする必要があります。各層で同じタイプの回復メカニズムが使用される場合、下層回復メカニズムは上位レベル1よりも高速になると予想されます。
Consequently, taking into account the recovery actions at the different layers in a bottom-up approach: if lower layer recovery mechanisms are provided and sequentially activated in conjunction with higher layer ones, the lower layers must have an opportunity to recover normal traffic before the higher layers do. However, if lower layer recovery is slower than higher layer recovery, the lower layer must either communicate the failure-related information to the higher layer(s) (and allow it to perform recovery), or use a hold-off timer in order to temporarily set the higher layer recovery action in a "standby mode". Note that the a priori information exchange between layers concerning their efficiency is not within the current scope of this document. Nevertheless, the coordination functionality between layers must be configurable and tunable.
その結果、ボトムアップアプローチの異なる層での回復アクションを考慮して：下層の回復メカニズムが提供され、より高い層のものと連携して連続的にアクティブ化された場合、下層はより高い層の前に通常のトラフィックを回復する機会がなければなりませんレイヤーはそうします。ただし、下層の回復がより高い層回復よりも遅い場合、下層は故障関連の情報をより高い層に通信する（そして回復を実行できるようにする）か、ホールドオフタイマーを使用する必要があります。「スタンバイモード」で高層回復アクションを一時的に設定します。その効率に関するレイヤー間のアプリオリ情報交換は、このドキュメントの現在の範囲内ではないことに注意してください。それにもかかわらず、レイヤー間の調整機能は構成可能で調整可能でなければなりません。
For example, coordination between the optical and packet layer control plane enables the optical layer to perform the failure management operations (in particular, failure detection and notification) while giving to the packet layer control plane the authority to decide and perform the recovery actions. If the packet layer recovery action is unsuccessful, fallback at the optical layer can be performed subsequently.
たとえば、光学層とパケット層制御プレーン間の調整により、光層が故障管理操作（特に障害検出と通知）を実行しながら、パケットレイヤー制御プレーンに復旧アクションを決定および実行する権限を与えます。パケット層の回復アクションが失敗した場合、その後、光層でのフォールバックを実行できます。
The top-down approach attempts service recovery at the higher layers before invoking lower layer recovery. Higher layer recovery is service selective, and permits "per-CoS" or "per-connection" re-routing. With this approach, the most important aspect is that the upper layer should provide its own reliable and independent failure detection mechanism from the lower layer.
トップダウンアプローチは、下層回復を呼び出す前に、高層でサービス回復を試みます。より高い層の回復はサービス選択的であり、「一人当たり」または「接続ごと」の再ルーティングを許可します。このアプローチでは、最も重要な側面は、上層が下層から独自の信頼できる独立した故障検出メカニズムを提供する必要があることです。
[DEMEESTER] also suggests recovery mechanisms incorporating a coordinated effort shared by two adjacent layers with periodic status updates. Moreover, some of these recovery operations can be pre-assigned (on a per-link basis) to a certain layer, e.g., a given link will be recovered at the packet layer while another will be recovered at the optical layer.
[Demeester]は、定期的なステータスの更新を備えた2つの隣接する層が共有する調整された努力を組み込んだ回復メカニズムも提案しています。さらに、これらの回復操作の一部は、特定のレイヤーに事前に割り当てられます（リンクごとに）特定のレイヤーになります。たとえば、特定のリンクはパケットレイヤーで回復し、別のリンクは光レイヤーで回収されます。
Having link and node diverse working and recovery LSPs/spans does not guarantee their complete disjointness. Due to the common physical layer topology (passive), additional hierarchical concepts, such as the Shared Risk Link Group (SRLG), and mechanisms, such as SRLG diverse path computation, must be developed to provide complete working and recovery LSP/span disjointness (see [IPO-IMP] and
リンクおよびノードの多様な作業と回復LSPS/スパンを持つことは、彼らの完全なばらばらを保証するものではありません。共通の物理層トポロジ（パッシブ）により、共有リスクリンクグループ（SRLG）などの追加の階層的概念、およびSRLG Diverse Path計算などのメカニズムを開発して、完全な動作と回復のLSP/SPANの分離を提供する必要があります（[IPO-IMP]およびを参照してください
[RFC4202]). Otherwise, a failure affecting the working LSP/span would also potentially affect the recovery LSP/span; one refers to such an event as "common failure".
[RFC4202]）。それ以外の場合、動作するLSP/SPANに影響を与える障害も、リカバリLSP/SPANに影響する可能性があります。1つは、そのようなイベントを「共通の失敗」と呼びます。
A Shared Risk Link Group (SRLG) is defined as the set of links sharing a common risk (such as a common physical resource such as a fiber link or a fiber cable). For instance, a set of links L belongs to the same SRLG s, if they are provisioned over the same fiber link f.
共有リスクリンクグループ（SRLG）は、共通のリスク（ファイバーリンクやファイバーケーブルなどの一般的な物理リソースなど）を共有するリンクのセットとして定義されます。たとえば、リンクLのセットは、同じファイバーリンクfでプロビジョニングされている場合、同じSRLGに属します。
The SRLG properties can be summarized as follows:
SRLGプロパティは、次のように要約できます。
1) A link belongs to more than one SRLG if and only if it crosses one of the resources covered by each of them.
1) リンクは、それぞれが対象とするリソースの1つを通過する場合にのみ、複数のSRLGに属します。
2) Two links belonging to the same SRLG can belong individually to (one or more) other SRLGs.
2) 同じSRLGに属する2つのリンクは、（1つまたは複数の）他のSRLGに個別に属することができます。
3) The SRLG set S of an LSP is defined as the union of the individual SRLG s of the individual links composing this LSP.
3) LSPのSRLGセットは、このLSPを構成する個々のリンクの個々のSRLGの結合として定義されます。
SRLG disjointness is also applicable to LSPs:
SRLGのばらばらは、LSPにも適用できます。
The LSP SRLG disjointness concept is based on the following postulate: an LSP (i.e., a sequence of links and nodes) covers an SRLG if and only if it crosses one of the links or nodes belonging to that SRLG.
LSP SRLGの分離概念は、次の仮定に基づいています。LSP（つまり、リンクとノードのシーケンス）は、そのSRLGに属するリンクまたはノードの1つを横切る場合にのみ、SRLGをカバーします。
Therefore, the SRLG disjointness for LSPs, can be defined as follows: two LSPs are disjoint with respect to an SRLG s if and only if they do not cover simultaneously this SRLG s.
したがって、LSPに対するSRLGのばらばらは、次のように定義できます。2つのLSPは、このsrlgを同時にカバーしていない場合にのみ、SRLGに関してはばらばらです。
Whilst the SRLG disjointness for LSPs with respect to a set S of SRLGs, is defined as follows: two LSPs are disjoint with respect to a set of SRLGs S if and only if the set of SRLGs that are common to both LSPs is disjoint from set S.
SRLGSのセットに関するLSPに対するSRLGのばらばらは、次のように定義されます。2つのLSPは、両方のLSPに共通するSRLGのセットがセットの分離とは異なる場合にのみ、SRLGSのセットに関してはばらばらです。S.
The impact on recovery is noticeable: SRLG disjointness is a necessary (but not a sufficient) condition to ensure network survivability. With respect to the physical network resources, a working-recovery LSP/span pair must be SRLG-disjoint in case of dedicated recovery type. On the other hand, in case of shared recovery, a group of working LSP/spans must be mutually SRLG-disjoint in order to allow for a (single and common) shared recovery LSP that is itself SRLG-disjoint from each of the working LSPs/spans.
回復への影響は顕著です。SRLGのばらばらは、ネットワークの生存性を確保するために必要な（ただし十分ではない）条件です。物理ネットワークリソースに関しては、労働回復LSP/SPANペアは、専用の回復タイプの場合にSRLG-Disjointでなければなりません。一方、回復の共有の場合、動作するLSP/スパンのグループは、それぞれの動作LSPからsrlg-disjointである（単一および一般的な）共有リカバリLSPを可能にするために、相互にsrlg-disjointでなければなりません。/スパン。
In order to provide a structured analysis of the recovery mechanisms detailed in the previous sections, the following dimensions can be considered:
前のセクションで詳述されている回復メカニズムの構造化された分析を提供するために、次の次の寸法を考慮することができます。
1. Fast convergence (performance): provide a mechanism that aggregates multiple failures (implying fast failure detection and correlation mechanisms) and fast recovery decision independently of the number of failures occurring in the optical network (also implying a fast failure notification).
1. 高速収束（パフォーマンス）：複数の障害（高速障害検出および相関メカニズムを暗示することを意味する）と、光ネットワークで発生する障害の数（高速障害通知を暗示する）とは無関係に、速い回復決定を集約するメカニズムを提供します。
2. Efficiency (scalability): minimize the switching time required for LSP/span recovery independently of the number of LSPs/spans being recovered (this implies efficient failure correlation, fast failure notification, and time-efficient recovery mechanisms).
2. 効率（スケーラビリティ）：回復中のLSP/スパンの数とは無関係にLSP/SPANリカバリに必要なスイッチング時間を最小化します（これは、効率的な障害相関、高速障害通知、および時間効率の高い回復メカニズムを意味します）。
3. Robustness (availability): minimize the LSP/span downtime independently of the underlying topology of the transport plane (this implies a highly responsive recovery mechanism).
3. 堅牢性（可用性）：輸送面の基礎となるトポロジーとは無関係にLSP/スパンダウンタイムを最小化します（これは非常に応答性の高い回復メカニズムを意味します）。
4. Resource optimization (optimality): minimize the resource capacity, including LSPs/spans and nodes (switching capacity), required for recovery purposes; this dimension can also be referred to as optimizing the sharing degree of the recovery resources.
4. リソースの最適化（最適性）：リカバリの目的で必要なLSP/スパンとノード（スイッチング容量）を含むリソース容量を最小限に抑えます。この次元は、リカバリリソースの共有度を最適化するものとも呼ばれます。
5. Cost optimization: provide a cost-effective recovery type/scheme.
5. コストの最適化：費用対効果の高いリカバリタイプ/スキームを提供します。
However, these dimensions are either outside the scope of this document (such as cost optimization and recovery path computational aspects) or mutually conflicting. For instance, it is obvious that providing a 1+1 LSP protection minimizes the LSP downtime (in case of failure) while being non-scalable and consuming recovery resource without enabling any extra-traffic.
ただし、これらの次元は、このドキュメントの範囲外（コスト最適化や回復パスの計算の側面など）の範囲外か相互に矛盾しています。たとえば、1 1 LSP保護を提供することで、トラフィック特別を可能にすることなく、非スケーラブルで消費する回復リソースである一方で、LSPのダウンタイム（故障の場合）を最小限に抑えることは明らかです。
The following sections analyze the recovery phases and mechanisms detailed in the previous sections with respect to the dimensions described above in order to assess the GMPLS protocol suite capabilities and applicability. In turn, this allows the evaluation of the potential need for further GMPLS signaling and routing extensions.
次のセクションでは、GMPLSプロトコルスイート機能と適用性を評価するために、上記の寸法に関する前のセクションで詳述されている回復段階とメカニズムを分析します。次に、これにより、さらなるGMPLSシグナリングとルーティング拡張の潜在的なニーズを評価することができます。
Fast convergence is related to the failure management operations. It refers to the time elapsed between failure detection/correlation and hold-off time, the point at which the recovery switching actions are initiated. This point has been detailed in Section 4.
高速収束は、障害管理操作に関連しています。これは、障害検出/相関とホールドオフ時間の間に経過した時間、回復スイッチングアクションが開始されるポイントを指します。この点は、セクション4で詳しく説明されています。
In general, the more pre-assignment/pre-planning of the recovery LSP/span, the more rapid the recovery is. Because protection implies pre-assignment (and cross-connection) of the protection resources, in general, protection recovers faster than restoration.
一般に、リカバリLSP/スパンの事前割り当て/事前計画が多いほど、回復はより速くなります。保護は、保護リソースの事前割り当て（および相互接続）を意味するため、一般に、保護は回復よりも速く回復するからです。
Span restoration is likely to be slower than most span protection types; however this greatly depends on the efficiency of the span restoration signaling. LSP restoration with pre-signaled and pre-selected recovery resources is likely to be faster than fully dynamic LSP restoration, especially because of the elimination of any potential crankback during the recovery LSP establishment.
スパンの修復は、ほとんどのスパン保護タイプよりも遅くなる可能性があります。ただし、これはスパン復元シグナル伝達の効率に大きく依存します。特に、回復LSPの確立中に潜在的なクランクバックを排除するため、事前に署名された事前に選択された回復リソースを使用したLSPの回復は、完全に動的なLSP修復よりも高速になる可能性があります。
If one excludes the crankback issue, the difference between dynamic and pre-planned restoration depends on the restoration path computation and selection time. Since computational considerations are outside the scope of this document, it is up to the vendor to determine the average and maximum path computation time in different scenarios and to the operator to decide whether or not dynamic restoration is advantageous over pre-planned schemes that depend on the network environment. This difference also depends on the flexibility provided by pre-planned restoration versus dynamic restoration. Pre-planned restoration implies a somewhat limited number of failure scenarios (that can be due, for instance, to local storage capacity limitation). Dynamic restoration enables on-demand path computation based on the information received through failure notification message, and as such, it is more robust with respect to the failure scenario scope.
クランクバックの問題を除外した場合、動的な復元と事前に計画された復元の違いは、復元パスの計算と選択時間に依存します。計算上の考慮事項はこのドキュメントの範囲外であるため、さまざまなシナリオでの平均パス計算時間を決定するのはベンダー次第であり、オペレーターは、動的回復が事前に計画されたスキームよりも有利であるかどうかを決定するために、オペレーター次第です。ネットワーク環境。この違いは、事前に計画された修復と動的回復によって提供される柔軟性にも依存します。事前に計画された復元は、故障シナリオのやや限られた数の障害シナリオを意味します（たとえば、ローカルストレージ容量の制限に起因する可能性があります）。動的復元により、障害通知メッセージを通じて受け取った情報に基づいてオンデマンドパス計算を可能にするため、障害シナリオの範囲に関してはより堅牢です。
Moreover, LSP segment restoration, in particular, dynamic restoration (i.e., no path pre-computation, so none of the recovery resource is pre-reserved) will generally be faster than end-to-end LSP restoration. However, local LSP restoration assumes that each LSP segment end-point has enough computational capacity to perform this operation while end-to-end LSP restoration requires only that LSP end-points provide this path computation capability.
さらに、LSPセグメントの復元、特に動的回復（つまり、パスの事前計算がないため、回復リソースは事前に予約されていません）は、一般にエンドツーエンドのLSP修復よりも高速になります。ただし、ローカルLSPの復元は、各LSPセグメントのエンドポイントがこの操作を実行するのに十分な計算能力があることを前提としていますが、エンドツーエンドのLSP修復には、LSPエンドポイントがこのパス計算機能を提供することのみが必要です。
Recovery time objectives for SONET/SDH protection switching (not including time to detect failure) are specified in [G.841] at 50 ms, taking into account constraints on distance, number of connections involved, and in the case of ring enhanced protection, number of nodes in the ring. Recovery time objectives for restoration mechanisms have been proposed through a separate effort [RFC3386].
SONET/SDH保護スイッチングの回復時間目標（障害を検出する時間を含めない）は、距離の制約、関係する接続の数、およびリング強化保護の場合、50ミリ秒の[G.841]で指定されています。リング内のノードの数。回復メカニズムの回復時間目的は、別の取り組みを通じて提案されています[RFC3386]。
In general, the less pre-assignment (protection)/pre-planning (restoration) of the recovery LSP/span, the more robust the recovery type or scheme is to a variety of single failures, provided that adequate resources are available. Moreover, the pre-selection of the recovery resources gives (in the case of multiple failure scenarios) less flexibility than no recovery resource pre-selection. For instance, if failures occur that affect two LSPs sharing a common link along their restoration paths, then only one of these LSPs can be recovered. This occurs unless the restoration path of at least one of these LSPs is re-computed, or the local resource assignment is modified on the fly.
一般に、リカバリLSP/スパンの事前割り当て（保護）/プランプランニング（回復）が少ないほど、適切なリソースが利用可能であれば、回復タイプまたはスキームはさまざまな単一の障害に対してより堅牢です。さらに、回復リソースの事前選択により、（複数の障害シナリオの場合）回復リソースの事前選択なしよりも柔軟性が低くなります。たとえば、復元パスに沿って共通のリンクを共有する2つのLSPに影響を与える障害が発生した場合、これらのLSPの1つのみを回復できます。これは、これらのLSPの少なくとも1つの修復経路が再計算されたり、ローカルリソースの割り当てがその場で変更されない限り発生します。
In addition, recovery types and schemes with pre-planned recovery resources (in particular, LSP/spans for protection and LSPs for restoration purposes) will not be able to recover from failures that simultaneously affect both the working and recovery LSP/span. Thus, the recovery resources should ideally be as disjoint as possible (with respect to link, node, and SRLG) from the working ones, so that any single failure event will not affect both working and recovery LSP/span. In brief, working and recovery resources must be fully diverse in order to guarantee that a given failure will not affect simultaneously the working and the recovery LSP/span. Also, the risk of simultaneous failure of the working and the recovery LSPs can be reduced. It is reduced by computing a new recovery path whenever a failure occurs along one of the recovery LSPs or by computing a new recovery path and provision the corresponding LSP whenever a failure occurs along a working LSP/span. Both methods enable the network to maintain the number of available recovery path constant.
さらに、事前に計画された回復リソース（特に、保護のためのLSP/スパンと復元目的のLSPS）を備えた回復タイプとスキームは、作業と回復の両方のLSP/SPANの両方に同時に影響する障害から回復することはできません。したがって、回復リソースは、単一の障害イベントが作業LSP/スパンの両方に影響を与えないように、機能するものから（リンク、ノード、およびSRLGに関して可能な限り（リンク、ノード、およびSRLGに関して）、可能な限り（可能な限り）ばらばらである必要があります。簡単に言えば、特定の障害が動作LSP/スパンに同時に影響を与えないことを保証するために、作業と回復のリソースが完全に多様でなければなりません。また、作業と回復LSPの同時故障のリスクを減らすことができます。回復LSPのいずれかに沿って障害が発生するたびに新しい回復パスを計算するか、新しいリカバリパスを計算して、機能LSP/スパンに沿って障害が発生するたびに対応するLSPを提供することで削減されます。どちらの方法でも、ネットワークは利用可能な回復パス定数の数を維持できます。
The robustness of a recovery scheme is also determined by the amount of pre-reserved (i.e., signaled) recovery resources within a given shared resource pool: as the sharing degree of recovery resources increases, the recovery scheme becomes less robust to multiple LSP/span failure occurrences. Recovery schemes, in particular restoration, with pre-signaled resource reservation (with or without pre-selection) should be capable of reserving an adequate amount of resource to ensure recovery from any specific set of failure events, such as any single SRLG failure, any two SRLG failures, etc.
回復スキームの堅牢性は、特定の共有リソースプール内の事前に返済される（つまり、シグナル付き）リカバリリソースの量によっても決定されます。故障の発生。リカバリスキームは、特に復元され、事前にシグナル付きのリソース予約（事前選択の有無にかかわらず）は、単一のSRLG障害、あらゆる任意の障害イベントからの回復を確保するために、適切な量のリソースを予約することができるはずです。2つのSRLG障害など
It is commonly admitted that sharing recovery resources provides network resource optimization. Therefore, from a resource utilization perspective, protection schemes are often classified with respect to their degree of sharing recovery resources with the working entities. Moreover, non-permanent bridging protection types allow (under normal conditions) for extra-traffic over the recovery resources.
リカバリリソースを共有すると、ネットワークリソースの最適化が提供されることが一般的に認められています。したがって、リソース利用の観点から、保護スキームは、回復リソースを作業エンティティと共有する程度に関して分類されることがよくあります。さらに、非永続的なブリッジング保護タイプにより、（通常の条件下で）回復リソース上の交通量が外れます。
From this perspective, the following statements are true:
この観点から、次のステートメントは真実です。
1) 1+1 LSP/Span protection is the most resource-consuming protection type because it does not allow for any extra traffic.
1) 1 1 LSP/SPAN保護は、追加のトラフィックを許可しないため、最もリソースを消費する保護タイプです。
2) 1:1 LSP/span recovery requires dedicated recovery LSP/span allowing for extra traffic.
2) 1：1 LSP/SPAN Recoveryには、専用のリカバリLSP/SPANが必要で、追加のトラフィックが可能です。
3) 1:N and M:N LSP/span recovery require 1 (and M, respectively) recovery LSP/span (shared between the N working LSP/span) allowing for extra traffic.
3) 1：NおよびM：N LSP/SPAN Recoveryには、1（およびM、M、それぞれ）リカバリLSP/SPAN（N作業LSP/SPANの間で共有）が必要になり、追加のトラフィックが可能になります。
Obviously, 1+1 protection precludes, and 1:1 recovery does not allow for any recovery LSP/span sharing, whereas 1:N and M:N recovery do allow sharing of 1 (M, respectively) recovery LSP/spans between N working LSP/spans. However, despite the fact that 1:1 LSP recovery precludes the sharing of the recovery LSP, the recovery schemes that can be built from it (e.g., (1:1)^n, see Section 5.4) do allow sharing of its recovery resources. In addition, the flexibility in the usage of shared recovery resources (in particular, shared links) may be limited because of network topology restrictions, e.g., fixed ring topology for traditional enhanced protection schemes.
明らかに、1 1の保護が除外され、1：1の回復は回復LSP/SPAN共有を許可しませんが、1：NおよびM：Nの回復は、動作LSP間の1（m、M、）リカバリ/スパンの共有を許可します。/スパン。ただし、1：1 LSPの回復が回復LSPの共有を排除するという事実にもかかわらず、そこから構築できる回復スキーム（（1：1）^n、セクション5.4を参照）は、回復リソースの共有を許可します。。さらに、ネットワークトポロジの制限（たとえば、従来の強化された保護スキームの固定リングトポロジ）のため、共有リカバリリソースの使用（特に共有リンク）の使用における柔軟性は制限される場合があります。
On the other hand, when using LSP restoration with pre-signaled resource reservation, the amount of reserved restoration capacity is determined by the local bandwidth reservation policies. In LSP restoration schemes with re-provisioning, a pool of spare resources can be defined from which all resources are selected after failure occurrence for the purpose of restoration path computation. The degree to which restoration schemes allow sharing amongst multiple independent failures is then directly inferred from the size of the resource pool. Moreover, in all restoration schemes, spare resources can be used to carry preemptible traffic (thus over preemptible LSP/span) when the corresponding resources have not been committed for LSP/span recovery purposes.
一方、LSP修復物を事前にシグナル型のリソース予約で使用する場合、予約された修復能力の量は、ローカル帯域幅予約ポリシーによって決定されます。再構成を伴うLSP修復スキームでは、復元パス計算の目的で故障発生後にすべてのリソースが選択される予備リソースのプールを定義できます。復元スキームが複数の独立した障害との間で共有を許可する程度は、リソースプールのサイズから直接推測されます。さらに、すべての復元スキームで、LSP/SPANリカバリの目的で対応するリソースがコミットされていない場合、予備のリソースを使用して、先制トラフィック（したがって、予約可能なLSP/SPANを超えて）を運ぶことができます。
From this, it clearly follows that less recovery resources (i.e., LSP/spans and switching capacity) have to be allocated to a shared recovery resource pool if a greater sharing degree is allowed. Thus, the network survivability level is determined by the policy that defines the amount of shared recovery resources and by the maximum sharing degree allowed for these recovery resources.
このことから、より少ないリカバリリソース（つまり、LSP/スパンとスイッチング容量）は、より大きな共有の程度が許可されている場合、共有リカバリリソースプールに割り当てる必要があることを明確に示しています。したがって、ネットワークの生存性レベルは、共有回収リソースの量を定義するポリシーと、これらの回復リソースに許可された最大共有度によって決定されます。
When recovery resources are shared over several LSP/Spans, the use of the Maximum Reservable Bandwidth, the Unreserved Bandwidth, and the Maximum LSP Bandwidth (see [RFC4202]) provides the information needed to obtain the optimization of the network resources allocated for shared recovery purposes.
リカバリリソースがいくつかのLSP/スパンにわたって共有される場合、最大予約可能帯域幅、予約されていない帯域幅、および最大LSP帯域幅（[RFC4202]を参照）の使用は、共有回収のために割り当てられたネットワークリソースの最適化を取得するために必要な情報を提供します目的。
The Maximum Reservable Bandwidth is defined as the Maximum Link Bandwidth but it may be greater in case of link over-subscription.
最大予約可能な帯域幅は、最大リンク帯域幅として定義されますが、リンク過剰サブスクリプションの場合は大きい場合があります。
The Unreserved Bandwidth (at priority p) is defined as the bandwidth not yet reserved on a given TE link (its initial value for each priority p corresponds to the Maximum Reservable Bandwidth). Last, the Maximum LSP Bandwidth (at priority p) is defined as the smaller of Unreserved Bandwidth (at priority p) and Maximum Link Bandwidth.
予約されていない帯域幅（優先度P）は、特定のTEリンクにまだ予約されていない帯域幅として定義されます（各優先度Pの初期値は、最大予約可能帯域幅に対応します）。最後に、最大LSP帯域幅（優先Pで）は、予約されていない帯域幅（優先P）および最大リンク帯域幅として定義されます。
Here, one generally considers a recovery resource sharing degree (or ratio) to globally optimize the shared recovery resource usage. The distribution of the bandwidth utilization per TE link can be inferred from the per-priority bandwidth pre-allocation. By using the Maximum LSP Bandwidth and the Maximum Reservable Bandwidth, the amount of (over-provisioned) resources that can be used for shared recovery purposes is known from the IGP.
ここでは、一般に、共有リカバリリソースの使用をグローバルに最適化するために、回復リソース共有の学位（または比率）を検討します。リンクごとの帯域幅の使用率の分布は、適切な帯域幅の事前配分から推測できます。最大LSP帯域幅と最大予約可能な帯域幅を使用することにより、共有回復の目的で使用できる（過剰に把握された）リソースの量がIGPから知られています。
In order to analyze this behavior, we define the difference between the Maximum Reservable Bandwidth (in the present case, this value is greater than the Maximum Link Bandwidth) and the Maximum LSP Bandwidth per TE link i as the Maximum Shareable Bandwidth or max_R[i]. Within this quantity, the amount of bandwidth currently allocated for shared recovery per TE link i is defined as R[i]. Both quantities are expressed in terms of discrete bandwidth units (and thus, the Minimum LSP Bandwidth is of one bandwidth unit).
この動作を分析するために、最大の帯域幅（この場合、この値は最大リンク帯域幅よりも大きい）と最大共有帯域幅またはMAX_Rとしての最大LSP帯域幅iの違いを定義します[i]。この数量内で、現在リンクIごとに共有回復に割り当てられている帯域幅の量は、r [i]として定義されています。両方の数量は、離散帯域幅単位で表されます（したがって、最小LSP帯域幅は1つの帯域幅単位のものです）。
The knowledge of this information available per TE link can be exploited in order to optimize the usage of the resources allocated per TE link for shared recovery. If one refers to r[i] as the actual bandwidth per TE link i (in terms of discrete bandwidth units) committed for shared recovery, then the following quantity must be maximized over the potential TE link candidates:
リンクごとに利用可能なこの情報の知識は、共有リンクごとに割り当てられたリソースの使用を最適化するために活用できます。R [i]を共有回復のためにコミットするリンクI（個別の帯域幅ユニットの観点から）あたりの実際の帯域幅として参照する場合、次の量を潜在的なTEリンク候補で最大化する必要があります。
sum {i=1}^N [(R{i} - r{i})/(t{i} - b{i})]
or equivalently: sum {i=1}^N [(R{i} - r{i})/r{i}]
with R{i} >= 1 and r{i} >= 1 (in terms of per component
bandwidth unit)
In this formula, N is the total number of links traversed by a given LSP, t[i] the Maximum Link Bandwidth per TE link i, and b[i] the sum per TE link i of the bandwidth committed for working LSPs and other recovery LSPs (thus except "shared bandwidth" LSPs). The quantity [(R{i} - r{i})/r{i}] is defined as the Shared (Recovery) Bandwidth Ratio per TE link i. In addition, TE links for which R[i] reaches max_R[i] or for which r[i] = 0 are pruned during shared recovery path computation as well as TE links for which max_R[i] = r[i] that can simply not be shared.
この式では、nは特定のLSPによって横断されるリンクの総数、t [i] te link Iごとの最大リンク帯域幅、およびb [i]作業用LSPおよびその他のためにコミットされた帯域幅のリンクIごとの合計回復LSP（したがって、「共有帯域幅」LSPを除く）。数量[（r {i} - r {i}）/r {i}]は、リンクごとの共有（回復）帯域幅比として定義されます。さらに、r [i]がmax_r [i]に到達するTeリンク、または共有回復パス計算中にr [i] = 0が剪定され、max_r [i] = r [i]ができるteリンク単に共有されません。
More generally, one can draw the following mapping between the available bandwidth at the transport and control plane level:
より一般的には、輸送プレーンレベルで使用可能な帯域幅の間に次のマッピングを描画できます。
- ---------- Max Reservable Bandwidth
| ----- ^
|R ----- |
| ----- |
- ----- |max_R
----- |
-------- TE link Capacity - ------ | - Maximum TE Link Bandwidth
----- |r ----- v
----- <------ b ------> - ---------- Maximum LSP Bandwidth
----- -----
----- -----
----- -----
----- -----
----- ----- <--- Minimum LSP Bandwidth
-------- 0 ---------- 0
Note that the above approach does not require the flooding of any per LSP information or any detailed distribution of the bandwidth allocation per component link or individual ports or even any per-priority shareable recovery bandwidth information (using a dedicated sub-TLV). The latter would provide the same capability as the already defined Maximum LSP bandwidth per-priority information. This approach is referred to as a Partial (or Aggregated) Information Routing as described in [KODIALAM1] and [KODIALAM2]. They show that the difference obtained with a Full (or Complete) Information Routing approach (where for the whole set of working and recovery LSPs, the amount of bandwidth units they use per-link is known at each node and for each link) is clearly negligible. The Full Information Routing approach is detailed in [GLI]. Note also that both approaches rely on the deterministic knowledge (at different degrees) of the network topology and resource usage status.
上記のアプローチでは、LSPごとの情報の洪水、またはコンポーネントリンクごとの帯域幅割り当ての詳細な配布、さらには適切な共有可能なリカバリ帯域幅情報（専用サブTLVを使用）を必要としないことに注意してください。後者は、既に定義されている最大LSP帯域幅ごとの透過情報と同じ機能を提供します。このアプローチは、[kodialam1]および[kodialam2]で説明されているように、部分的な（または集約された）情報ルーティングと呼ばれます。彼らは、完全な（または完全な）情報ルーティングアプローチで得られた違い（作業および回復のLSPのセット全体で、リンクごとに使用する帯域幅ユニットの量が各ノードで既知であり、各リンクに対して明らかに）を示しています無視できます。完全な情報ルーティングアプローチは[GLI]で詳しく説明されています。また、両方のアプローチは、ネットワークトポロジとリソースの使用状況の決定論的知識（異なる程度）に依存していることに注意してください。
Moreover, extending the GMPLS signaling capabilities can enhance the Partial Information Routing approach. It is enhanced by allowing working-LSP-related information and, in particular, its path (including link and node identifiers) to be exchanged with the recovery LSP request. This enables more efficient admission control at upstream nodes of shared recovery resources, and in particular, links (see Section 8.4.3).
さらに、GMPLSシグナリング機能を拡張すると、部分的な情報ルーティングアプローチが強化されます。ワーキングLSP関連の情報、特にそのパス（リンクおよびノード識別子を含む）を回復LSPリクエストと交換できるようにすることで強化されます。これにより、共有リカバリリソース、特にリンクの上流ノードでより効率的な入場制御が可能になります（セクション8.4.3を参照）。
Resource shareability can also be maximized with respect to the number of times each SRLG is protected by a recovery resource (in particular, a shared TE link) and methods can be considered for avoiding contention of the shared recovery resources in case of single SRLG failure. These methods enable the sharing of recovery resources between two (or more) recovery LSPs, if their respective working LSPs are mutually disjoint with respect to link, node, and SRLGs. Then, a single failure does not simultaneously disrupt several (or at least two) working LSPs.
リソースの共有性は、各SRLGが回復リソース（特に共有TEリンク）によって保護されている回数に関しても最大化でき、単一のSRLG障害の場合に共有リカバリリソースの競合を回避する方法を考慮することができます。これらの方法により、リンク、ノード、およびSRLGに関して、それぞれの作業LSPが相互にばらばらである場合、2つ（またはそれ以上）の回復LSP間の回復リソースを共有できます。次に、単一の障害では、同時にいくつかの（または少なくとも2つの）作業LSPを破壊しません。
For instance, [BOUILLET] shows that the Partial Information Routing approach can be extended to cover recovery resource shareability with respect to SRLG recoverability (i.e., the number of times each SRLG is recoverable). By flooding this aggregated information per TE link, path computation and selection of SRLG-diverse recovery LSPs can be optimized with respect to the sharing of recovery resource reserved on each TE link. This yields a performance difference of less than 5%, which is negligible compared to the corresponding Full Information Flooding approach (see [GLI]).
たとえば、[Bouillet]は、SRLGの回復可能性に関して回復リソースの共有可能性をカバーするために部分的な情報ルーティングアプローチを拡張できることを示しています（つまり、各SRLGが回復可能な回数）。このリンクごとにこの集約された情報をあふれさせることにより、SRLG-Diverse Recoveryのパス計算と選択LSPの選択は、各TEリンクで予約されたリカバリリソースの共有に関して最適化できます。これにより、5％未満のパフォーマンス差が得られます。これは、対応する完全な情報洪水アプローチと比較して無視できます（[GLI]を参照）。
For this purpose, additional extensions to [RFC4202] in support of path computation for shared mesh recovery have been often considered in the literature. TE link attributes would include, among others, the current number of recovery LSPs sharing the recovery resources reserved on the TE link, and the current number of SRLGs recoverable by this amount of (shared) recovery resources reserved on the TE link. The latter is equivalent to the current number of SRLGs that will be recovered by the recovery LSPs sharing the recovery resource reserved on the TE link. Then, if explicit SRLG recoverability is considered, a TE link attribute would be added that includes the explicit list of SRLGs (recoverable by the shared recovery resource reserved on the TE link) and their respective shareable recovery bandwidths. The latter information is equivalent to the shareable recovery bandwidth per SRLG (or per group of SRLGs), which implies that the amount of shareable bandwidth and the number of listed SRLGs will decrease over time.
この目的のために、共有メッシュ回復のためのパス計算をサポートする[RFC4202]への追加の拡張は、文献でしばしば考慮されています。TEリンク属性には、TEリンクで予約されている回復リソースを共有する現在の回収LSPの数と、TEリンクで予約されたこの（共有）リカバリリソースによって回収可能な現在のSRLGの現在の数が含まれます。後者は、TEリンクで予約されているリカバリリソースを共有する回復LSPによって回復されるSRLGの現在の数と同等です。次に、明示的なSRLG回復可能性を考慮すると、SRLGの明示的なリスト（TEリンクに予約されている共有リカバリリソースによって回復可能）とそれぞれの共有可能な回復帯域幅を含むTEリンク属性が追加されます。後者の情報は、SRLGあたりの共有可能な回復帯域幅（またはSRLGのグループごと）に相当します。これは、共有可能な帯域幅の量とリストされているSRLGの数が時間とともに減少することを意味します。
Compared to the case of recovery resource sharing only (regardless of SRLG recoverability, as described in Section 8.4.1), these additional TE link attributes would potentially deliver better path computation and selection (at a distinct ingress node) for shared mesh recovery purposes. However, due to the lack of evidence of better efficiency and due to the complexity that such extensions would generate, they are not further considered in the scope of the present analysis. For instance, a per-SRLG group minimum/maximum shareable recovery bandwidth is restricted by the length that the corresponding (sub-) TLV may take and thus the number of SRLGs that it can include. Therefore, the corresponding parameter should not be translated into GMPLS routing (or even signaling) protocol extensions in the form of TE link sub-TLV.
セクション8.4.1で説明されているように、回復リソース共有のみ（SRLG回復可能性に関係なく）と比較して、これらの追加のTEリンク属性は、共有メッシュ回復の目的でより良いパス計算と選択（明確なイングレスノード）を潜在的に提供する可能性があります。ただし、効率が向上した証拠がないため、そのような拡張が生成する複雑さのために、現在の分析の範囲ではさらに考慮されていません。たとえば、SRLGあたりのグループの最小/最大共有可能な回復帯域幅は、対応する（サブ）TLVが取る可能性のある長さ、したがって含まれるSRLGの数によって制限されます。したがって、対応するパラメーターは、TE Link Sub-TLVの形式のGMPLSルーティング（またはシグナル伝達）プロトコル拡張機能に変換されるべきではありません。
Admission control is a strict requirement to be fulfilled by nodes giving access to shared links. This can be illustrated using the following network topology:
入場管理は、共有リンクへのアクセスを提供するノードによって満たされるための厳格な要件です。これは、次のネットワークトポロジを使用して説明できます。
A ------ C ====== D
| | |
| | |
| B |
| | |
| | |
------- E ------ F
Node A creates a working LSP to D (A-C-D), B creates simultaneously a working LSP to D (B-C-D) and a recovery LSP (B-E-F-D) to the same destination. Then, A decides to create a recovery LSP to D (A-E-F-D), but since the C-D span carries both working LSPs, node E should either assign a dedicated resource for this recovery LSP or reject this request if the C-D span has already reached its maximum recovery bandwidth sharing ratio. In the latter case, C-D span failure would imply that one of the working LSP would not be recoverable.
ノードAは、d（a-c-d）に動作するLSPを作成し、bは同時に作業LSPをD（B-C-D）に、同じ宛先に回復LSP（B-E-F-D）を作成します。次に、aはd（a-e-f-d）にリカバリLSPを作成することを決定しますが、C-dスパンは動作LSPの両方を運ぶため、ノードEはこの回復LSPに専用リソースを割り当てるか、C-Dスパンがすでに最大に達している場合はこのリクエストを拒否する必要があります。回復帯域幅共有率。後者の場合、C-Dスパンの障害は、作業LSPの1つが回復できないことを意味します。
Consequently, node E must have the required information to perform admission control for the recovery LSP requests it processes (implying for instance, that the path followed by the working LSP is carried with the corresponding recovery LSP request). If node E can guarantee that the working LSPs (A-C-D and B-C-D) are SRLG disjoint over the C-D span, it may securely accept the incoming recovery LSP request and assign to the recovery LSPs (A-E-F-D and B-E-F-D) the same resources on the link E-F. This may occur if the link E-F has not yet reached its maximum recovery bandwidth sharing ratio. In this example, one assumes that the node failure probability is negligible compared to the link failure probability.
したがって、ノードEには、Recovery LSP Requests ITプロセスのために入学制御を実行するために必要な情報が必要です（たとえば、動作するLSPが続くパスが対応するリカバリLSPリクエストで運ばれることを意味します）。Node Eが、作業LSP（A-C-DおよびB-C-D）がC-DスパンでSRLGの格差であることを保証できる場合、着信リカバリLSPリクエストを安全に受け入れ、リンクE-Fの同じリソースを回復LSP（A-E-F-DおよびB-E-F-D）に割り当てることができます。これは、リンクE-Fがまだ最大回復帯域幅共有比に達していない場合に発生する可能性があります。この例では、リンク障害確率と比較して、ノードの故障確率が無視できると想定しています。
To achieve this, the path followed by the working LSP is transported with the recovery LSP request and examined at each upstream node of potentially shareable links. Admission control is performed using the interface identifiers (included in the path) to retrieve in the TE DataBase the list of SRLG IDs associated to each of the working LSP links. If the working LSPs (A-C-D and B-C-D) have one or more link or SRLG ID in common (in this example, one or more SRLG id in common over the span C-D), node E should not assign the same resource over link E-F to the recovery LSPs (A-E-F-D and B-E-F-D). Otherwise, one of these working LSPs would not be recoverable if C-D span failure occurred.
これを達成するために、動作中のLSPが続くパスは、Recovery LSPリクエストで輸送され、潜在的に共有可能なリンクの各アップストリームノードで検査されます。インターフェイス識別子（パスに含まれる）を使用して入場制御が実行され、TEデータベースで動作する各LSPリンクに関連付けられたSRLG IDのリストを取得します。動作LSP（A-C-DおよびB-C-D）に1つ以上のリンクまたはSRLG IDが共通している場合（この例では、SPAN C-Dで1つ以上のSRLG IDが共通しています）、ノードEはリンクE-Fに同じリソースを割り当ててはなりません。Recovery LSPS（A-E-F-DおよびB-E-F-D）。それ以外の場合、C-Dスパン障害が発生した場合、これらの動作LSPの1つは回復できません。
There are some issues related to this method; the major one is the number of SRLG IDs that a single link can cover (more than 100, in complex environments). Moreover, when using link bundles, this approach may generate the rejection of some recovery LSP requests. This occurs when the SRLG sub-TLV corresponding to a link bundle includes the union of the SRLG id list of all the component links belonging to this bundle (see [RFC4202] and [RFC4201]).
この方法に関連するいくつかの問題があります。主要なものは、単一のリンクがカバーできるSRLG IDの数（複雑な環境では100以上）です。さらに、リンクバンドルを使用する場合、このアプローチは、いくつかの回復LSPリクエストの拒否を生成する可能性があります。これは、リンクバンドルに対応するSRLGサブTLVに、このバンドルに属するすべてのコンポーネントリンクのSRLG IDリストの結合が含まれている場合に発生します（[RFC4202]および[RFC4201]を参照）。
In order to overcome this specific issue, an additional mechanism may consist of querying the nodes where the information would be available (in this case, node E would query C). The main drawback of this method is that (in addition to the dedicated mechanism(s) it requires) it may become complex when several common nodes are traversed by the working LSPs. Therefore, when using link bundles, solving this issue is closely related to the sequence of the recovery operations. Per-component flooding of SRLG identifiers would deeply impact the scalability of the link state routing protocol. Therefore, one may rely on the usage of an on-line accessible network management system.
この特定の問題を克服するために、追加のメカニズムは、情報が利用可能になるノードをクエリすることから構成されている場合があります（この場合、ノードEはCを照会します）。この方法の主な欠点は、（必要な専用メカニズムに加えて）、いくつかの一般的なノードが作業LSPによって移動されると複雑になる可能性があることです。したがって、リンクバンドルを使用する場合、この問題を解決することは、回復操作のシーケンスと密接に関連しています。SRLG識別子のコンポーネントごとの洪水は、リンク状態ルーティングプロトコルのスケーラビリティに深く影響します。したがって、オンラインでアクセス可能なネットワーク管理システムの使用に依存する場合があります。
The following table summarizes the different recovery types and schemes analyzed throughout this document.
次の表は、このドキュメント全体で分析されたさまざまな回復タイプとスキームをまとめたものです。
--------------------------------------------------------------------
| Path Search (computation and selection)
--------------------------------------------------------------------
| Pre-planned (a) | Dynamic (b)
--------------------------------------------------------------------
| | faster recovery | Does not apply
| | less flexible |
| 1 | less robust |
| | most resource-consuming |
Path | | |
Setup ------------------------------------------------------------
| | relatively fast recovery | Does not apply
| | relatively flexible |
| 2 | relatively robust |
| | resource consumption |
| | depends on sharing degree |
------------------------------------------------------------
| | relatively fast recovery | less faster (computation)
| | more flexible | most flexible
| 3 | relatively robust | most robust
| | less resource-consuming | least resource-consuming
| | depends on sharing degree |
--------------------------------------------------------------------
1a. Recovery LSP setup (before failure occurrence) with resource reservation (i.e., signaling) and selection is referred to as LSP protection.
1a。リソース予約（つまり、シグナル伝達）と選択を伴うRecovery LSPセットアップ（障害発生前）は、LSP保護と呼ばれます。
2a. Recovery LSP setup (before failure occurrence) with resource reservation (i.e., signaling) and with resource pre-selection is referred to as pre-planned LSP re-routing with resource pre-selection. This implies only recovery LSP activation after failure occurrence.
2a。リソースの予約（つまり、シグナル伝達）およびリソースの事前選択による回復LSPセットアップ（障害発生前）は、リソースの事前選択による事前に計画されたLSPリルートと呼ばれます。これは、故障発生後の回復LSPの活性化のみを意味します。
3a. Recovery LSP setup (before failure occurrence) with resource reservation (i.e., signaling) and without resource selection is referred to as pre-planned LSP re-routing without resource pre-selection. This implies recovery LSP activation and resource (i.e., label) selection after failure occurrence.
3a。リソースの予約（つまり、シグナル伝達）およびリソース選択なしの回復LSPセットアップ（故障発生前）は、リソースの事前選択なしで事前に計画されたLSPの再ルーティングと呼ばれます。これは、故障発生後のリカバリLSPの活性化とリソース（つまり、ラベル）選択を意味します。
3b. Recovery LSP setup after failure occurrence is referred to as to as LSP re-routing, which is full when recovery LSP path computation occurs after failure occurrence.
3b。故障の発生後の回復LSPセットアップは、LSPの再ルーティングに関して参照されます。これは、故障発生後に回復LSPパス計算が発生する場合に完全です。
Thus, the term pre-planned refers to recovery LSP path pre-computation, signaling (reservation), and a priori resource selection (optional), but not cross-connection. Also, the shared-mesh recovery scheme can be viewed as a particular case of 2a) and 3a), using the additional constraint described in Section 8.4.3.
したがって、事前に計画された用語とは、リカバリLSPパスの事前コンピューション、シグナル伝達（予約）、およびプライリリソース選択（オプション）を指しますが、相互接続ではありません。また、セクション8.4.3で説明されている追加の制約を使用して、共有メッシュの回復スキームは、2a）および3a）の特定のケースと見なすことができます。
The implementation of these recovery mechanisms requires only considering extensions to GMPLS signaling protocols (i.e., [RFC3471] and [RFC3473]). These GMPLS signaling extensions should mainly focus in delivering (1) recovery LSP pre-provisioning for the cases 1a, 2a, and 3a, (2) LSP failure notification, (3) recovery LSP switching action(s), and (4) reversion mechanisms.
これらの回復メカニズムの実装には、GMPLSシグナル伝達プロトコル（つまり、[RFC3471]および[RFC3473]）への拡張のみを考慮する必要があります。これらのGMPLSシグナリング拡張機能は、主に（1）ケース1A、2A、および3Aの回復LSPの前プロビジョン、（2）LSP障害通知、（3）リカバリLSPスイッチングアクション、および（4）逆転に焦点を当てる必要があります。メカニズム。
Moreover, the present analysis (see Section 8) shows that no GMPLS routing extensions are expected to efficiently implement any of these recovery types and schemes.
さらに、現在の分析（セクション8を参照）は、これらの回復タイプとスキームのいずれかを効率的に実装するGMPLSルーティング拡張機能がないことを示しています。
This document does not introduce any additional security issue or imply any specific security consideration from [RFC3945] to the current RSVP-TE GMPLS signaling, routing protocols (OSPF-TE, IS-IS-TE) or network management protocols.
このドキュメントでは、追加のセキュリティの問題を導入したり、[RFC3945]から現在のRSVP-TE GMPLSシグナリング、ルーティングプロトコル（OSPF-TE、IS-IS-TE）、またはネットワーク管理プロトコルまでの特定のセキュリティ検討を暗示していません。
However, the authorization of requests for resources by GMPLS-capable nodes should determine whether a given party, presumably already authenticated, has a right to access the requested resources. This determination is typically a matter of local policy control, for example, by setting limits on the total bandwidth made available to some party in the presence of resource contention. Such policies may become quite complex as the number of users, types of resources, and sophistication of authorization rules increases. This is particularly the case for recovery schemes that assume pre-planned sharing of recovery resources, or contention for resources in case of dynamic re-routing.
ただし、GMPLS対応ノードによるリソースの要求の承認は、特定の当事者がすでに認証されていると、要求されたリソースにアクセスする権利があるかどうかを判断する必要があります。この決定は、通常、地域の政策管理の問題です。たとえば、リソースの競合の存在下である当事者が利用できる帯域幅の総幅に制限を設定することにより。このようなポリシーは、ユーザーの数、リソースの種類、および承認ルールの洗練度が増加するにつれて非常に複雑になる可能性があります。これは特に、回復リソースの事前に計画された共有を仮定する回復スキームの場合、または動的な再ルーティングの場合のリソースの競合です。
Therefore, control elements should match the requests against the local authorization policy. These control elements must be capable of making decisions based on the identity of the requester, as verified cryptographically and/or topologically.
したがって、制御要素は、ローカル認証ポリシーとの要求と一致する必要があります。これらの制御要素は、暗号化および/またはトポロジー的に検証されたように、要求者の身元に基づいて決定を下すことができなければなりません。
The authors would like to thank Fabrice Poppe (Alcatel) and Bart Rousseau (Alcatel) for their revision effort, and Richard Rabbat (Fujitsu Labs), David Griffith (NIST), and Lyndon Ong (Ciena) for their useful comments.
著者は、改訂の取り組みについて、ファブリス・ポッペ（アルカテル）とバート・ルソー（アルカテル）、リチャード・ラバット（藤井研究所）、デビッド・グリフィス（NIST）、リンドン・オング（CIENA）に有用なコメントに感謝したいと思います。
Thanks also to Adrian Farrel for the thorough review of the document.
ドキュメントの徹底的なレビューをしてくれたAdrian Farrelにも感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471] Berger、L。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナル伝達機能説明」、RFC 3471、2003年1月。
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473] Berger、L。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナルリソースリソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）拡張」、RFC 3473、2003年1月。
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945] Mannie、E。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）アーキテクチャ」、RFC 3945、2004年10月。
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4201] Kompella、K.、Rekhter、Y.、およびL. Berger、「MPLS Traffic Engineering（TE）のリンクバンドリング」、RFC 4201、2005年10月。
[RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005.
[RFC4202] Kompella、K.、ed。and Y. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートするルーティング拡張機能」、RFC 4202、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月。
[RFC4209] Fredette, A., Ed. and J. Lang, Ed., "Link Management Protocol (LMP) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems", RFC 4209, October 2005.
[RFC4209]フレデット、A。、編and J. Lang、ed。、「高密度の波長分割多重化（DWDM）光線システムのリンク管理プロトコル（LMP）」、RFC 4209、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月。
[BOUILLET] E. Bouillet, et al., "Stochastic Approaches to Compute Shared Meshed Restored Lightpaths in Optical Network Architectures," IEEE Infocom 2002, New York City, June 2002.
[Bouillet] E. Bouillet、et al。、「光学ネットワークアーキテクチャで共有メッシュ化された復元されたライトパスを計算するための確率的アプローチ」、IEEE Infocom 2002、2002年6月。
[DEMEESTER] P. Demeester, et al., "Resilience in Multilayer Networks," IEEE Communications Magazine, Vol. 37, No. 8, pp. 70-76, August 1998.
[Demeester] P. Demeester、et al。、「多層ネットワークにおける回復力」、IEEE Communications Magazine、Vol。37、No。8、pp。70-76、1998年8月。
[GLI] G. Li, et al., "Efficient Distributed Path Selection for Shared Restoration Connections," IEEE Infocom 2002, New York City, June 2002.
[Gli] G. Li、et al。、「共有修復接続の効率的な分散パス選択」、IEEE Infocom 2002、ニューヨーク市、2002年6月。
[IPO-IMP] Strand, J. and A. Chiu, "Impairments and Other Constraints on Optical Layer Routing", RFC 4054, May 2005.
[IPO-IMP] Strand、J。およびA. Chiu、「光学層ルーティングの障害およびその他の制約」、RFC 4054、2005年5月。
[KODIALAM1] M. Kodialam and T.V. Lakshman, "Restorable Dynamic Quality of Service Routing," IEEE Communications Magazine, pp. 72-81, June 2002.
[Kodialam1] M. KodialamおよびT.V. Lakshman、「Restorable Dynamic of Service Routing」、IEEE Communications Magazine、pp。72-81、2002年6月。
[KODIALAM2] M. Kodialam and T.V. Lakshman, "Dynamic Routing of Restorable Bandwidth-Guaranteed Tunnels using Aggregated Network Resource Usage Information," IEEE/ ACM Transactions on Networking, pp. 399-410, June 2003.
[Kodialam2] M. KodialamおよびT.V. Lakshman、「集約されたネットワークリソースの使用情報を使用した修復可能な帯域幅の保証トンネルの動的ルーティング」、NetworkingのIEEE/ ACMトランザクション、pp。399-410、2003年6月。
[MANCHESTER] J. Manchester, P. Bonenfant and C. Newton, "The Evolution of Transport Network Survivability," IEEE Communications Magazine, August 1999.
[マンチェスター] J.マンチェスター、P。ボネンファント、C。ニュートン、「The Evolution of Transport Network Survivability」、IEEE Communications Magazine、1999年8月。
[RFC3386] Lai, W. and D. McDysan, "Network Hierarchy and Multilayer Survivability", RFC 3386, November 2002.
[RFC3386] Lai、W。およびD. McDysan、「ネットワーク階層と多層生存可能性」、RFC 3386、2002年11月。
[T1.105] ANSI, "Synchronous Optical Network (SONET): Basic Description Including Multiplex Structure, Rates, and Formats," ANSI T1.105, January 2001.
[T1.105] ANSI、「同期光ネットワーク（SONET）：マルチプレックス構造、レート、フォーマットを含む基本的な説明」、ANSI T1.105、2001年1月。
[WANG] J. Wang, L. Sahasrabuddhe, and B. Mukherjee, "Path vs. Subpath vs. Link Restoration for Fault Management in IP-over-WDM Networks: Performance Comparisons Using GMPLS Control Signaling," IEEE Communications Magazine, pp. 80-87, November 2002.
[Wang] J. Wang、L。Sahasrabuddhe、およびB. Mukherjee、「Path vs. Subpath vs. Link Restoration for IP-Over-WDMネットワークの障害管理：GMPLSコントロールシグナル伝達を使用したパフォーマンス比較」、IEEE Communications Magazine、pp。80-87、2002年11月。
For information on the availability of the following documents, please see http://www.itu.int
次のドキュメントの可用性については、http：//www.itu.intを参照してください。
[G.707] ITU-T, "Network Node Interface for the Synchronous Digital Hierarchy (SDH)," Recommendation G.707, October 2000.
[G.707] ITU-T、「同期デジタル階層のネットワークノードインターフェイス（SDH）」、推奨G.707、2000年10月。
[G.709] ITU-T, "Network Node Interface for the Optical Transport Network (OTN)," Recommendation G.709, February 2001 (and Amendment no.1, October 2001).
[G.709] ITU-T、「光輸送ネットワークのネットワークノードインターフェイス（OTN）」、推奨G.709、2001年2月（および修正第1号、2001年10月）。
[G.783] ITU-T, "Characteristics of Synchronous Digital Hierarchy (SDH) Equipment Functional Blocks," Recommendation G.783, October 2000.
[G.783] ITU-T、「同期デジタル階層（SDH）機器機能ブロックの特性」、推奨G.783、2000年10月。
[G.798] ITU-T, "Characteristics of optical transport network hierarchy equipment functional block," Recommendation G.798, June 2004.
[G.798] ITU-T、「光輸送ネットワーク階層装置機能ブロックの特性」、推奨G.798、2004年6月。
[G.806] ITU-T, "Characteristics of Transport Equipment - Description Methodology and Generic Functionality", Recommendation G.806, October 2000.
[G.806] ITU -T、「輸送機器の特性 - 説明方法と一般的な機能」、推奨G.806、2000年10月。
[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月。
[G.842] ITU-T, "Interworking of SDH network protection architectures," Recommendation G.842, October 1998.
[G.842] ITU-T、「SDHネットワーク保護アーキテクチャの交流」、推奨G.842、1998年10月。
[G.874] ITU-T, "Management aspects of the optical transport network element," Recommendation G.874, November 2001.
[G.874] ITU-T、「光学輸送ネットワーク要素の管理の側面」、推奨G.874、2001年11月。
Editors' Addresses
編集者のアドレス
Dimitri Papadimitriou Alcatel Francis Wellesplein, 1 B-2018 Antwerpen, Belgium
Dimitri Papadimitriou Alcatel Francis Wellesplein、1 B-2018 Antwerpen、ベルギー
Phone: +32 3 240-8491
EMail: dimitri.papadimitriou@alcatel.be
Eric Mannie Perceval Rue Tenbosch, 9 1000 Brussels Belgium
エリックマニーパーセバルRue Tenbosch、9 1000ブリュッセルベルギー
Phone: +32-2-6409194
EMail: eric.mannie@perceval.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。