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).
著作権（C）インターネット協会（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]、およびプレ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 /スパン障害（またはそのような障害を発生する他のイベント）が発生したときに実行される必要がある一般的な操作のシーケンスを定義します。
- 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
デボラBrungard（AT＆T）200 S.ローレルアベニューミドルタウン、NJ 07748、USA
EMail: dbrungard@att.com
メールアドレス：dbrungard@att.com
Sudheer Dharanikota
Sudhir Dharanikota
EMail: sudheer@ieee.org
メールアドレス：sudheer@ieee.org
Jonathan P. Lang (Sonos) 506 Chapala Street Santa Barbara, CA 93101, USA
ジョナサンP.ラング（Sonosの）506チャパラストリートサンタバーバラ、CA 93101、USA
EMail: jplang@ieee.org
メールアドレス：jplang@ieee.org
Guangzhi Li (AT&T) 180 Park Avenue, Florham Park, NJ 07932, USA
Guangzhiリー（AT＆T）180パークアベニュー、フローハムパーク、NJ 07932、USA
EMail: gli@research.att.com
メールアドレス：gli@research.att.com
Eric Mannie Perceval Rue Tenbosch, 9 1000 Brussels Belgium
エリック・マニーパーシヴァルルーテンボス、9千ブリュッセルベルギー
Phone: +32-2-6409194 EMail: eric.mannie@perceval.net
電話：+ 32-2-6409194 Eメール：eric.mannie@perceval.net
Dimitri Papadimitriou (Alcatel) Francis Wellesplein, 1 B-2018 Antwerpen, Belgium
ディミトリスPapadimitriou（アルカテル）フランシスVellesplein、1 B-2018アントワープ、Velgiom
EMail: dimitri.papadimitriou@alcatel.be
メールアドレス：dimitri.papadimitriou@alcatel.be
Bala Rajagopalan Microsoft India Development Center Hyderabad, India
バラRajagopalanマイクロソフト、インド開発センターハイデラバード、インド
EMail: balar@microsoft.com
メールアドレス：balar@microsoft.com
Yakov Rekhter (Juniper) 1194 N. Mathilda Avenue Sunnyvale, CA 94089, USA
ヤコフ・レックター（ジュニパー）1194 N.マチルダアベニューサニーベール、CA 94089、USA
EMail: yakov@juniper.net
メールアドレス：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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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は、TRAIL（すなわち、セクションまたはパス）の連続の完全性を監視します。この操作は、信号の存在/不在をモニタリングすることによって行われます。例には、パス層、クライアント層のサーバ信号障害の検出（例えば、AIS）のための信号（LOS）検出の物理層のため、未実装（UNEQ）信号検出の損失です。
- 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は、エンドポイント間の信号のルーティングの完全性を監視します。層（例えば、ファイバ分配フレーム）のいずれかに自動的に（例えば、クロスコネクト）、または手動で、柔軟な接続を提供する場合、接続の監視が必要とされます。例えばトレイル（すなわち、セクションまたはパス）トレースIDは、異なる層及び対応する後続トレースID不一致検出に使用されます。
- 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:
最も重要な点は、監視プロセスと（回復期（S）を開始するために使用される）に対応する故障検出のいずれかをもたらすことです。
- 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）において、等価監視機能は/デジタル/光学部層（すなわち、光伝送セクション（OTS）、光学多重化セクション（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
プレOTNネットワークでは、障害は、上流の障害を検出してからフォトニッククロスコネクト（PXC）を防ぐ、中間体O-E-O系光回線システム（OLS）によってマスクされてもよいです。このような場合には、故障検出は、アウト・オブ・バンド通信チャネルによって支援することができ、故障状態がPXC制御プレーンに報告することができます。これは、PXCとOLS制御プレーンとの間のIPメッセージベースの通信を実現[RFC4209]の拡張機能を使用することによって提供することができます。 PXCsがフレーミングフォーマットとは無関係であるので、また、故障状態は、光信号の不在を検出することによって、又はその品質を測定することによってのいずれかでトリガすることができます。これらの機構は、一般に、電気的（デジタル）のものよりも信頼性が低いです。検出機構の両方のタイプは、この文書の範囲外です。中間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.
制御プレーンの観点から、このように第5節で説明したようにPXCとその後の回復動作が実行され、この機構は、このように他のOEO同じ障害管理機構を有する、単一の論理エンティティにOLS-PXC-構成されるシステムをオン対応デバイス。
More generally, the following are typical failure conditions in SONET/SDH and pre-OTN networks:
より一般的には、以下がSONET / SDHおよびプレ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:
- エンティティを検出し、報告する非共同設置：
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（S）/スパン（S）障害を検出する搬送プレーンエンティティの位置（及び従って同一性）について決定エンティティに情報を提供します。決定エンティティは、スイッチング動作をより細かい粒度の回復（複数可）を達成するための正確な決定を行うことができます。この情報はまた、障害通知の一部として含めることが可能である（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).
障害通知はLSP /スパンに障害が発生したと検出されたと2）を決定する失敗LSP /スパンの任意の中間体またはエンドポイントに対応することができるエンティティ（）ことを通知するために中間ノードを通知するために、1）使用されます対応するサービスは利用できません。一般的には、これらの決定エンティティは、適切な回復決定を下すものとなります。回復エンティティと同じ場所に配置すると、これらのエンティティにも対応する回復アクション（複数可）を実行します。
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つ（またはそれ以上）をサポートする分散制御プレーンの障害通知メカニズム（複数可）にかかわらず、機構の実際の実装の、同じ機能は以上（以下）で必要とされたLSPについて提供される情報は/失敗条件にまたがる、その詳細なステータスなど
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.
LSP /はそのため、これらのメッセージは、ステータスを運ぶまたがるようにまた、[RFC3473]で指定されるように、GMPLS制御プレーンを介して通知メッセージ交換は、同じ経路をたどるなくてもよいです。今度は、これは、高速（確認応答と、専用制御プレーンネットワークまたはばらばら制御チャネルのいずれかの使用を介して）信頼性が高く、効率的な（同一のメッセージ内の複数のLSP /スパン状態の集合を介して）障害通知メカニズムを確実にします。
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シグナリングと共同で実行されている機構であり、中間ノード/障害条件下またがるワーキングLSPのステータスについて通知滞在することができ（[RFC3473]を参照）。
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 /スパンのエンドポイントは（より正確には、決定エンティティは）最高の回復アクションを取るために回復するエンティティのために必要な情報を定義する場合、ここでのトレードオフが発生します最適な（この不測の事態では、重要な問題は、準最適のレベルを定量化することであることに注意してください）。あまりにも多くの情報が提供されている場合、制御プレーンは不要な情報でオーバーロードされてもよく、この通知情報の集合/相関を達成することはより複雑で時間がかかるであろう。交換及び処理すべき情報量のより詳細な定量が障害通知プロトコルに強く依存することに留意されたいです。
- 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）故障検出出力（すなわち、アラーム相関を）相関障害（複数可）を検出するノードで集約されていることを意味し、2）故障の通知が（目的地の制限されたセットに向けられています一般的なエンドポイント）、および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.
このようなシナリオでは、一般的に、障害の相関時間と呼ばれ、一定時間待機し、障害（または単にグループの障害）のグループとしてそれらを報告するすべての障害を収集するために重要になることがあります。例えば、このアプローチは、プレ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.
障害相関がない場合、複数の障害通知メッセージが（例えば、ファイバ切断）は、単一の故障に応答して送出されてもよいです。各障害通知メッセージが失敗した作業リソースに関する情報のセットを含む（例えば、個々のラムダこのファイバ内を流れる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:
以下の表は、LSP /スパン回復の場合の制御プレーンで撮影した責任の概観を与えます：
- 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 /スパン保護の文脈において、制御プレーン・アクションのいずれかの動作目的及び/又は同期の目的のために行うことができる（輸送および制御プレーンとの間の垂直同期）および/または通知の目的で、制御プレーンにおけるエンドノードの間の（水平同期レベル）。これは、保護/保護LSPのプロビジョニング段階中（保護スイッチングのために特に）責任面の選択を示唆しています。
- 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.
以下のサブセクションでは、別の対1つの技術を支持することを意図していません。彼らは、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).
- 中間ノードのトランスポンダにおける障害抑制は、例えば、スケルチの使用は、（例えば、大爆笑のような）障害がエッジノードに伝播することを意味します。したがって、エッジノードは、（上流の障害の非標準的なマスキングの使用対）上位レイヤによって駆動される回復動作を開始する可能性を有するであろう。
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.842]参照）が標準化されている（[G.841]を参照）、保護されたドメインとインターワークを横切って動作することができるデータプレーンレベルで動作する保護タイプ。
- 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のLSP /リンクの粒度をより細かく制御
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.)
- メッシュ回復のサポートは、集中ネットワーク管理の開発を必要とし、機能性は、ネットワーク要素と要素管理システムの能力の両方によって制限される（従って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.
で繊維搬送機構はさらに、帯域内および帯域外に細分することができます。このように、アウトオブバンドシグナリングにおけるファイバ帯域内とにおける繊維間の区別は、トランスポート・プレーン・トポロジーに対して物理的に埋め込まれた制御プレーン・トポロジー対logically-の考慮に低減します。この文書の範囲では、隣接ノードの各対の間に少なくとも1つのIP制御チャネルが回復に関する情報及びメッセージの交換を可能にするために継続的に利用可能であると仮定されます。したがって、いずれの場合も（すなわち、バンドまたはアウトオブバンド）ノードの各対の間に少なくとも一つの論理的または物理制御チャネルは、常に利用可能であると予想されます。
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).
したがって、ファイバ内シグナリングを使用して重要な問題は、1つの制御プレーンのフォールトトレランス機能と（ノードを含む）の搬送面に影響を与える故障間の独立性を仮定することができるかどうかです。注またOTNなど、既存の仕様がオーバーヘッドと他の制御トラフィックを転送する（OSCは、[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 /スパンに障害が発生した（または両方の組み合わせ）のいずれか。図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
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
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は、図2ではノードBに通知メッセージを送信し、ノードBは、信頼性の高い障害通知を確実にするためにCをノードに通知メッセージ、専用の肯定応答を送信している間、ノードCはノードBに通知メッセージを送信します。メッセージは送信ノードに戻って返すことができます。
- 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は、ノードBからのメッセージと同じことをしなければならない）とノードCから受信した通知メッセージを相関させるために有しています。
- 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は、上流の通知メッセージを送信する下流通知メッセージを送信することができる入口ノードAをノードCに（[RFC3473]参照）（参照[RFC3473]）出口ノードへ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、ノードCは、しかし、出口ノードDに（[RFC3473]を参照）下流通知メッセージを送信することができるまでLSPの方向に依存する、唯一の入口ノードAは、エッジツーエッジ回復動作を開始することになります。他のLSPエンドノード（この場合、ノードD）も（[RFC3473]を参照）下流通知メッセージを使用して、このイベントが通知されるべきであることに留意されたいです。 AとDから導かLSPが障害状態下にある場合、例えば、D、ノードCから送信されたのみの通知メッセージは、回復動作を開始することになります。ノードAが（すなわち、唯一のエンティティを回復）「スレーブ」と呼ばれながら、この場合には、[RFC4427]あたり、決定及び回収ノードDは、「マスター」と呼ばれます。
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をノード）も決定/回復エンティティであるか、または検出/報告企業は、単にその後の回復過程における中間ノードです。一つは、前者の場合には、ローカル回復を参照して、エッジ - エッジに後者の回復を（セクション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セグメント）回復する場合には必ずしも隣接していない決定/回復エンティティにレポートからのメッセージ交換をシグナリングするためのいくつかの中間ノードを横断する必要があります。特に、これは、その宛先から障害発生の位置を分離するホップ数を通知メッセージに適用されます。これは、追加の伝搬および転送遅延をもたらします。前者の遅延は、特定の状況では無視できないとすることができることに留意されたいです。例えば、銅アウトオブバンドネットワークにおいて、遅延は、200キロ当たり約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 /スパン回復技術の相対的なパフォーマンスの定量的な分析を提供しています。 【WANG】例えば、動的LSP復元（セクション5.5.2を参照）媒体ネットワーク負荷の下で良好に機能することを示すこれらの技術の分析グリッドを提供するが、回復リソースのより大きい競合に起因するより高い負荷で性能劣化を被ります。パスの周りに失敗したリンクは、影響を受けたLSPのホップ数を増やすため、追加のネットワークリソースを消費する傾向があるので、スパンの故障時にLSPの復元は、[WANG]で定義されるように、高負荷で低下します。また、LSP復元のパフォーマンスは最初の試みが失敗した場合、新たな回復の試みを開始できなかった作業LSPのソースノードによって向上させることができます。単一の再試行は、長期平均復旧時間を大幅に追加されていないが、回復の成功率、特に高負荷時に、成功したLSP復元の試みを開始する能力の大きな増加をもたらすのに十分です。追加の試みを許可するとパフォーマンスがわずかな追加の利益を生成します。これは、（ - ケース2のセクション5.5.2に記載）動的LSP復元を使用する場合、追加の（中間の）クランクバックシグナリングを使用することを提案します。クランクバックシグナリングの詳細については、このドキュメントの範囲外です。
[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 /スパン回復タイプを定義します。このセクションでは、これらの回復タイプを使用して構築することができ、回復スキームを説明します。簡単に、回復スキームは、（それらが許可回復タイプのセットから）指定されたリカバリ・タイプをサポートするいくつかの入口、出口ノードのペアの組み合わせとして定義されます。などのN、および回復方式：1又はM：いくつかの例は、1と回復タイプの違い示すために、ここで提供される（1：1）^ nまたは（M：N）^ 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.
1リカバリ型高々n個の異なる入出口ノード対との間に印加される：指数は、nは、1回の数を示します。ここでは、最大で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つの回収のLSPは、同じ共通のリソースを重複する場合^ 2の場合、それは単一の障害を処理することができます。任意の複数の作業LSPの失敗は、LSPが自動回復を拒否することに努めて少なくとも一つの原因になります。例えば、ワーキングLSPのA-B-C及びF-G-Hと、それぞれの回収共通D-Eリンク・リソースを共有するLSP A-D-E-CとF-D-E-Hと次のトポロジを考えます。
A---------B---------C
\ /
\ /
D-------------E
/ \
/ \
F---------G---------H
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個の異なる入出口ノード対間に印加されます。そのここ互いに素はN作業のLSP /スパンに適用され、最もn回M共通リソースで共有しながら、M回復のLSPに/またがる。除いてそう解釈は、前のケースから、次の
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.
両方のスキームでは、任意の所与の作業LSPに利用可能であるとの和{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回復LSPの場合：（1）^ n個の場合、例えば、単純に^ n個のグループの重なり、そのグループは、単一の障害を処理することができます。複数の作業LSPのいずれかの同時故障は、LSPが自動回復を拒否することに努めて少なくとも一つの原因になります。一つは考える場合には、例えば、（2：2）^ 2基は、ここで回復LSPを重複の二対があり、（同じペアに属する）2つのLSPを同時に回収することができます。後者の場合は、2つの一般的なD-Eリンクリソースを共有するLSP A-B-C及びF-G-Hと、それぞれの回復のLSP A-D-E-CとF-D-E-H作業の2対を用いて、以下のトポロジーによって示すことができます。
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.
回復時間とのLSP /スパンの比は、適切回復LSPのプロビジョニング（障害発生前に行う場合、事前プロビジョニングを意味する）と（即ち、オーバプロビジョニング）回復リソースのオーバーブッキングのレベルに依存します。これらの二つの操作の適切なバランスは、単一または複数の障害が発生し、所望のLSP /スパン回復時間との比をもたらすであろう。これらの操作は、主にネットワーク計画段階中に実行されていることにも注意してください。
The different options for LSP (pre-)provisioning and overbooking are classified below to structure the analysis of the different recovery mechanisms.
LSP（プレ）プロビジョニングとオーバーブッキングのためのさまざまなオプションは、異なる回復メカニズムの分析を構造化するために、次の分類されています。
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に影響を与える複数の障害イベントから作業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
回復LSPのプロビジョニングフェーズ：（1）経路計算 - >オンデマンド| | - >事前に計算| | （2）シグナリング - >オンデマンド| | - >プリシグナリングさ| | （3）資源の選択 - >オンデマンド| | - >事前に選択
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 /スパン復旧時間につながることに注意してください。別の回復メカニズムを分析する際、次のセクションでは、上記の事前プロビジョニングのオプションを検討します。
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（リソース選択のためのデルタも考慮され、対応する総時間は、その後タスと呼びます）
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パスのプールは、事前に計算されたときに考慮され、障害発生後にこれらのパスの一つは下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:
注：このような障害検出、相関、および通知などの障害管理動作が等しく、時間がかかり、以下に記載された全てのメカニズムのように（所定の失敗イベントの場合）であると考えられます。
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が確立されたエンド・ツー・エンドの復元（S）。このように、一方が「LSP再プロビジョニング」メカニズムとしてこれを定義することができます。障害が発生する前に、ここで、復元LSPのための1つ以上（ばらばら）経路が計算される（および必要に応じて予め選択します）。
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.
専用の計算は、各ワーキングLSPに対して実行されたときに予想される総復帰時間Tは、TS + TrsとまたはTrsとすることに等しいです。
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を動的故障（S）発生（S）の後に確立されます。障害発生後、復元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つのケースが回復リソースが事前に選択されているかどうかに基づいて定義することができます。
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.
障害発生前に実行される操作は、TcがTsの+ + Trとを取りつつ、予想総復帰時間Tは、（TAS）（ポスト故障活性化）に等しいです。
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).
障害発生前に実行される操作は、TcがTsの+ + Trsをとりつつ、予想総復帰時間Tは、TA（後故障活性化）に等しいです。したがって、これらの2つのアプローチの間の時間性能は、回復LSP（ - Taのすなわち、TAS）の活性化中にリソースの選択に要する時間によって異なります。
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 /スパンから以前に故障状態の下で作動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 /スパンは、ワーキングLSP /スパンに戻されなければならず、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).
特定の機構（待ち-TO-復元）による間欠欠陥（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は、例えば、特定の回復閾値未満BER故障自由になる必要があります。回収されたLSP /スパン（すなわち、以前にワーキングLSP /スパン）がこの基準を満たした後、通常のトラフィックが再び対応するリソースを使用する前に、一定時間が経過しなければなりません。復元待ち（WTR）期間またはタイマーと呼ばれるこの期間は数分（例えば、5分）の順で、一般的であると設定することが可能でなければなりません。 WTRタイマは、一定期間のいずれか、または再試行する前に、漸増的に長い期間を提供することができます。以前に働くLSP /スパンの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.
（WTR）回復LSP /スパンがもはや必要とされる運転の復帰モード、すなわちでは、失敗した働くLSP /スパンがSDまたはSF状態ではもはやあり、地元の復元待ち状態が切り替わる前にアクティブになりますバック復旧作業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 /スパンの使用量は、先取りすることができる、です。
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オーバー光学」ネットワーク内の複数のに利用可能になる（すべてではない）されています。しかし、各層は特定の回復機能を有し、一つは、これらの層によって提供される回収機構との間の相互作用の正確な影響を決定する必要があります。
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は、入口および出口メトロノードとの間に画定されます。彼らが運ぶ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:
第1の分析ステップとして、一つは回復メカニズムの垂直方向の調整については、次のガイドラインを描くことができます。
- 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のLSPパケットの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.
注：パケット上（1）パケット、回路上（2）パケット、パケットオーバー（3）回路、および回路上（4）回路：帯域粒度に基づいて、我々は垂直階層の4つのクラスを決定することができます。以下は、我々は簡単にのみ（4）で展開します。 （2）[RFC3386]で覆われています。 （1）広くPWE3ワーキンググループによってMPLSワーキンググループによって覆われており、（3）されます。
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 LSPがリンクとして下地STS_SPE / HOVC LSPを使用して）独立した層としてVT_SPE / LOVC及びSTS SPE / HOVCを考慮する。 OTNにおいて、のODUkパス層、すなわち、のODUkのLSPは、のOTUkリンクとして根底のOCh LSPを使用して、OCH3パス層上にあるであろう。下層の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.
また、（ホールドオフタイマーを使用して、例えば、予め決定された配位）十分な回収機構の調整の不在下で、障害通知が回復階層内の次のいずれか一つの層から伝搬することができます。これは「衝突」が発生し、（[MANCHESTER]参照）競合状態につながると、今度は、リソース使用率の最適化を減少および/またはネットワークの世界的な不安定性を生成することができ、同時回復アクションをトリガーすることができます。したがって、一貫した効率的なエスカレーション戦略がいくつかの層を横切って回復を調整するために必要とされます。
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は、トランスポート・プレーン・レベルでサポートされているそれらの対応するスイッチング粒度を持っている場合にのみ場合したがって、ネットワーク層ごとの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.
ボトムアップアプローチは、下位層の回復の種類と方式は、より好都合と上層のものよりも高速であることを前提としています。したがって、我々は、より高い層の回復を阻害するか、またはオフに保持することができます。しかし、この仮定は完全に真実ではありません。例えば、（50ミリ秒未満の保護スイッチング時間を有する）SONET / SDHベースの保護機構（200ミリ秒未満の回復時間で）OTN復帰機構の上に横たわっていると考えます。したがって、この仮定は、（少なくとも）でなければならないように明確化：下層回収機構が回復機構の同じタイプは、各レイヤで使用される場合、上位レベル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.
トップダウンアプローチは、下位層の回復を起動する前に、より高い層のサービス回復を試みます。上位層の回復は、サービスの選択、および「毎のCoSの」許可または「接続ごとの」再ルーティングです。このアプローチでは、最も重要な側面は、上位層が下位層から独自の信頼性と独立した障害検出メカニズムを提供しなければならないということです。
[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
リンクとノードの多様な作業と回復のLSP /スパンを持つことは、彼らの完全な互いに素を保証するものではありません。共通の物理層のトポロジー（パッシブ）は、そのような共有リスクリンクグループ（SRLG）、および、そのようなSRLG多様な経路計算などのメカニズム、などの追加階層的な概念に、完全な作業と回復LSP /スパン互いに素を（提供するために開発されなければなりません[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 /スパンに影響を与える障害はまた、潜在的に回復LSP /スパンに影響を与えます。一つは、「一般的な失敗」などのイベントを指します。
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）は（例えばファイバリンク、または光ファイバケーブルのような共通物理リソースのような）共通のリスクを共有するリンクの集合として定義されます。彼らは同じファイバリンクF上にプロビジョニングされている場合たとえば、リンクLのセットは、同じSRLG sに属します。
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）リンクがあれば、複数のSRLGに属し、それはそれらのそれぞれによってカバーされたリソースのいずれかを横切る場合にのみ。
2) Two links belonging to the same SRLG can belong individually to (one or more) other SRLGs.
2）同じSRLGに属する2つのリンクは、（1または複数の）他のSRLGsに個別に属することができます。
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セットSは、個々のSRLGのこのLSPを構成する個々のリンクの集合として定義されます。
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をカバーし、そのSRLGに属するリンクまたはノードの1つを横切る場合のみ：LSP 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 Sに対して互いに素です。
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の集合Sに対するLSPのためのSRLGの互いに素一方、定義されている2つのLSPはならSRLGs Sのセットに対して互いに素であり、両方のLSPに共通する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 /スパンのペアは、専用の回復タイプの場合のSRLGディスジョイントでなければなりません。一方、共有回復の場合、ワーキングLSP /スパンのグループは、SRLGディスジョイントワーキングLSPのそれぞれから、それ自体で（単と共通）共有回復LSPを可能にするために互いにSRLG-互いに素でなければなりません/及びます。
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 /数の回収されたスパン（これは、効率的な障害相関、高速障害通知、及び時間効率の回復メカニズムを意味します）。
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 /スパンノード（スイッチング容量）を含むリソース容量を最小限に抑えます。この寸法はまた、回復リソースの共有度合いの最適化と呼ぶことができます。
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.
1は、クランクバックの問題を除外した場合は、ダイナミックで事前に計画された復元の違いは、復旧パス計算と選択時間に依存します。計算上の考慮事項は、この文書の範囲外であるので、動的な修復が依存事前に計画された方式より有利であるか否かを決定するために、異なるシナリオにおいて、オペレータに平均および最大経路計算時間を決定するために、ベンダーまでですネットワーク環境。この違いは、動的復旧対事前に計画された復元によって提供される柔軟性に依存します。事前に計画された回復は障害シナリオの幾分限られた数（つまり、ローカルストレージ容量の制限により、例えば、原因であることができる）を意味します。動的回復は障害通知メッセージを介して受信した情報に基づいて、オンデマンドの経路計算を可能にし、そのようなものとして、それは失敗シナリオ範囲に対してよりロバストです。
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].
距離のアカウントの制約、接続の数関係を考慮して、50ミリ秒で[G.841]で指定されている（障害を検出するための時間を含まない）、及び環強化保護の場合にSONET / SDH保護スイッチングのための回復時間の目標、リング内のノードの数。回復メカニズムの復旧時間目標は、個別の努力[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 /スパンの少ない事前割り当て（保護）/事前計画（復元）は、より堅牢な回復タイプやスキームは、単一障害の多様であり、十分な資源が利用可能であることを提供します。また、回復リソースの事前選択は、（複数の障害シナリオの場合）なし回復リソース事前選択未満の柔軟性を与えます。たとえば、障害が発生した場合には、これらのみLSPの1を回収することができ、その復旧パスに沿って、共通のリンクを共有する二つのLSPに影響を与えます。これは、これらのLSPの少なくとも一つの復旧パスは再計算されない限り発生し、またはローカルリソース割り当てをオンザフライで変更されます。
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 /スパンの両方に影響を与える障害から回復することはできません（特に、LSP /は復元の目的のために保護とのLSPのためにまたがります）。任意の単一障害イベントは、作業や回復LSP /スパンの両方に影響を与えないように、このように、回復リソースは、理想的には、作業のものから（リンク、ノード、および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.
リカバリスキームのロバスト性はまた、仮予約の量によって決定される所定の共有リソースプール内の回復リソース（すなわち、シグナリング）：リカバリ・リソース増加の共有度として、回復方式は、複数のLSP /スパンに少ない堅牢ななります障害発生。回復スキームは、（持つ又は事前選択なし）プレシグナリングリソース予約を有する特定の修復、そのような任意の単一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 /スパン保護が最もリソースを消費する保護タイプです。
2) 1:1 LSP/span recovery requires dedicated recovery LSP/span allowing for extra traffic.
2）1：1つのLSP /スパン回復は、余分なトラフィックを可能に専用の回復LSP /スパンが必要です。
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 /スパン回復余分トラフィックを可能にするNワーキングLSP /スパンの間で共有される）回復LSP /スパン（）はそれぞれ、1を必要とする（そしてM。
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：NとM：1に対し、1回復は、任意の回復LSP /スパン共有することはできませんN回復が1（それぞれM、）の共有を可能に行う回復LSPは/ Nの作業の間にまたがりますLSP /スパン。しかし、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 /スパン回復の目的のためにコミットされていない（したがってプリエンプティブLSP /スパンで）プリエンプティブトラフィックを運ぶために使用することができます。
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.
ここで、一つは一般共有回復リソースの使用を最適化グローバルに回復リソース共有度（又は比）を考慮する。 TEリンクあたりの帯域幅利用率の分布ごとの優先帯域幅の事前割り当てから推測することができます。最大の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、最大予約可能帯域幅の間の差（本例では、この値が最大リンク帯域幅よりも大きい）とTEリンクあたりの最大LSP帯域幅を定義します]。この量の範囲内、現在TEリンクあたり共有回復のために割り当てられた帯域幅の量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:
TEリンクごとに使用可能なこの情報の知識を共有し、回復のためのTEリンクごとに割り当てられたリソースの使用を最適化するために活用することができます。一つはI（離散的な帯域幅の単位で）を共有回復のためにコミットTEリンクあたりの実際の帯域幅として[I] Rを参照する場合、次の量は、潜在的な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}]
合計{i = 1} ^ N [（R {I} - R {I}）/（T {I} - B {I}）]または同等：合計{i = 1} ^ N [（R {I} - R {I}）/ R {I}]
with R{i} >= 1 and r{i} >= 1 (in terms of per component bandwidth unit)
（成分帯域当たり単位換算）R {I}> = 1及びr {I}> = 1
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当たりリンクI、およびB [i]は帯域幅のI TEリンクあたりの合計は、作業のLSPのためにコミットされ、他の（したがって、「共有帯域幅」のLSPを除く）回復のLSP。量[（R {I} - R {I}）/ R {I}]共有（リカバリ）TEリンクIあたりの帯域幅の比として定義されます。加えて、TEリンクはれるR [i]はmax_Rに到達[I]またはそのためのR [I] = 0共有回収経路計算ならびにTEリンクのmax_Rは、[I] = R [i]の間に剪定されることができ単に共有することはありません。
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.
上記のアプローチは、（専用のサブTLVを使用して）任意のLSPあたりの情報またはコンポーネントリンクまたは個々のポートごとの帯域割り当てのいずれかの詳細な分布の浸水あるいは任意単位の優先共有可能回復帯域幅の情報を必要としないことに留意されたいです。後者は、既に定義された最大のLSP帯域幅毎の優先度情報と同じ機能を提供するであろう。 [KODIALAM2] [KODIALAM1]に記載のように、このアプローチは、ルーティング情報部分（または凝集）と呼ばれます。彼らは、（作業と回復の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の障害が発生した場合に、共有回復リソースの競合を回避するために考慮することができます。それぞれの作業のLSPは、リンク、ノード、及びSRLGsに対して互いに素である場合、これらの方法は、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が回復可能である）に対する回復リソース共有可能性をカバーするように拡張することができることを示しています。 TEリンク、経路計算及びSRLG-多様な回復LSPの選択当たりのこの集約情報をフラッディングすることにより、各TEリンク上で予約済み回復リソースの共有に関して最適化することができます。これは、対応する完全な情報のフラッディングアプローチ（[GLI]を参照）と比較して無視できる程度である5％未満、の性能差を生じます。
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リンクの上で予約（共有）回復リソースのこの量によって回復SRLGsの現在の数が含まれます。後者は、TEリンク上で予約済み回復リソースを共有し、回復のLSPによって回収されるであろうSRLGsの現在の数に相当します。明示的なSRLGの回収可能性を考慮すればその後、TEリンク属性はSRLGsの明示的なリスト（TEリンクの上に確保共有回復リソースによって回復）とそれぞれ共有可能回復帯域幅を含んでいる追加されます。後者の情報は、共有可能な帯域幅の量と記載されているSRLGsの数が時間の経過とともに減少することを意味SRLGあたり（またはSRLGsのグループあたり）共有可能回復帯域幅に相当します。
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をとることができるので、SRLGsの数は、それが含むことができる長さによって制限されます。したがって、対応するパラメータは、GMPLSルーティング翻訳（あるいはシグナリング）されるべきではないTEリンクサブTLVの形でプロトコルの拡張。
8.4.3. Recovery Resource Sharing, SRLG Disjointness and Admission Control
8.4.3. 回復リソースの共有、SRLG互いに素とアドミッション制御
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は同時にD（B-C-D）に作用LSPと同じ宛先への回復LSP（B-E-F-D）を作成します。その後、AはD（AEFD）に回復LSPを作成することを決定したが、CDスパンが両方のワーキングLSPを運ぶので、ノードEは、この回復LSPのための専用リソースを割り当てる必要がいずれかまたはCDスパンは既にその最大値に達した場合には、この要求を拒否します回復帯域幅共有比。後者の場合には、C-Dスパン障害がワーキングLSPの一つは回収できないことを暗示します。
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は、LSPは、それが（ワーキングLSP続くパスが対応する回復LSP要求に運ばれること、例えば、意味）処理要求の回復のためにアドミッション制御を実行するために必要な情報を有していなければなりません。ノードEが動作のLSP（A-C-DおよびB-C-D）はC-Dスパン上SRLG互いに素であることを保証することができれば、それは確実に着信回復LSP要求を受け付けると、回復のLSPに割り当ててもよい（A-E-F-DおよびB-E-F-D）リンクE-Fで同じリソース。リンクE-Fは、まだその最大回復帯域幅共有比に達していない場合に発生することがあります。この例では、1つのノードの故障確率がリンク故障確率と比較して無視できると仮定しています。
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続くパスは、回復LSP要求に輸送され、潜在的に共有可能なリンクの各上流ノードで検査されます。アドミッション制御は、TEデータベースに作業LSPリンクの各々に関連するSRLG IDのリストを取得する（パスに含まれる）インタフェース識別子を使用して実行されます。作業のLSP（ACDとBCD）は、（スパンCDの上に共通して、この例では、一つ以上のSRLG ID）を、共通の1つまたは複数のリンクまたはSRLG IDをお持ちの場合は、ノードEは、にリンクEF以上同じリソースを割り当てるべきではありません回復のLSP（AEFDとBEFD）。 C-Dのスパンに障害が発生した場合にはそうでない場合は、これらの作業のLSPの一つが回収できないでしょう。
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]).
この方法に関連するいくつかの問題があります。主要な一つは単一のリンクが（複雑な環境では、100以上）を覆うことができるSRLG IDの数です。リンクバンドルを使用した場合また、このアプローチは、いくつかの回復LSP要求の拒否を発生させることができます。 SRLGサブTLVはリンクバンドルに対応するときにこれが発生すると、（[RFC4202]及び[RFC4201]を参照）、このバンドルに属するすべてのコンポーネントリンクのSRLG IDリストの組合を含みます。
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。 （障害発生前に）回復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.
図2（a）。回復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.
図3（a）。回復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は、主ケース1A、2A、および3A、（2）LSP障害通知、（3）回復LSPのスイッチング動作（複数可）、及び（4）の復帰のために（1）回復LSP事前プロビジョニングを送達に焦点を当てるべきですメカニズム。
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.
この文書は、追加のセキュリティ上の問題を導入するか、現在のRSVP-TE GMPLSシグナリング、ルーティングプロトコル（OSPF-TEは、IS-IS-TE）またはネットワーク管理プロトコルに[RFC3945]から、任意の特定のセキュリティの考慮を意味するものではありません。
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.
作者は彼らの役に立つコメントをファブリスPoppe（アルカテル）とその改正の努力のためのバートルソー（アルカテル）、およびリチャードRabbat（富士通研究所）、デビッド・グリフィス（NIST）、およびリンドンオング（シエナ）を感謝したいと思います。
Thanks also to Adrian Farrel for the thorough review of the document.
文書の徹底的な見直しのためにも、エードリアンファレルに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]バーガー、L.、 "一般化されたマルチプロトコルラベルスイッチング（GMPLS）機能説明シグナリング"、RFC 3471、2003年1月。
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]バーガー、L.、 "一般化マルチプロトコルラベルスイッチング（GMPLS）シグナリング資源予約プロトコル - トラフィックエンジニアリング（RSVP-TE）を拡張"、RFC 3473、2003年1月。
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945]マニー、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.バーガー、 "MPLSでのリンクバンドルトラフィックエンジニアリング（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.、エド。 、RFC 4202およびY. Rekhter、エド。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）の支援でルーティング拡張機能」、2005年10月。
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, October 2005.
[RFC4204]ラング、J.、エド。、 "リンク管理プロトコル（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] Fredette、A.編。そして、J.ラング、エド。、RFC 4209、2005年10月、 "高密度波長分割多重（DWDM）光回線システムのリンク管理プロトコル（LMP）"。
[RFC4427] Mannie E., Ed. and D. Papadimitriou, Ed., "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, March 2006.
[RFC4427]マニーE.、エド。そして、D. Papadimitriou、エド。、 "一般化されたマルチプロトコルラベルの回復（保護と回復）用語スイッチング（GMPLS）"、RFC 4427、2006年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ら、「確率的アプローチは、光ネットワークのアーキテクチャで共有メッシュ型復元光パスを計算するために、」IEEEインフォコム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、ら、 "マルチレイヤネットワークにおけるレジリエンス、" IEEE通信誌、巻。 37、第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.リーら、「共有修復接続のための効率的な分散型経路選択、」IEEEインフォコム2002年、ニューヨーク市、2002年6月。
[IPO-IMP] Strand, J. and A. Chiu, "Impairments and Other Constraints on Optical Layer Routing", RFC 4054, May 2005.
[IPO-IMP]ストランド、J.およびA.チウ、 "減損および光学層ルーティング上の他の制約"、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.ラクシュマン、 "サービスルーティングの復元可能ダイナミックな品質、" IEEEコミュニケーションマガジン、頁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.ラクシュマン、「集約ネットワークリソース使用状況の情報を使用して復元可能帯域保証型トンネルのダイナミックルーティング、」ネットワーク上のIEEE / ACM取引、頁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. Bonenfant及びC.ニュートン、「トランスポートネットワーク生存性の進化、」IEEEコミュニケーションズマガジン、1999年8月。
[RFC3386] Lai, W. and D. McDysan, "Network Hierarchy and Multilayer Survivability", RFC 3386, November 2002.
[RFC3386]ライ、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.王、L. Sahasrabuddhe、およびB.ムカジー、「パス対IP-オーバー-WDMネットワークにおける障害管理のためのサブパス対リンク回復：GMPLS制御シグナリングを使用したパフォーマンスの比較、」IEEEコミュニケーションマガジン頁。 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勧告G.783、2000年10月 "同期デジタル階層（SDH）設備機能ブロックの特性"。
[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
ディミトリスPapadimitriouアルカテルフランシスVellesplein、1 B-2018アントワープ、Velgiom
Phone: +32 3 240-8491 EMail: dimitri.papadimitriou@alcatel.be
電話：+32 3 240-8491 Eメール：dimitri.papadimitriou@alcatel.be
Eric Mannie Perceval Rue Tenbosch, 9 1000 Brussels Belgium
エリック・マニーパーシヴァルルーテンボス、9千ブリュッセルベルギー
Phone: +32-2-6409194 EMail: eric.mannie@perceval.net
電話：+ 32-2-6409194 Eメール：eric.mannie@perceval.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。