RFC4428 日本語訳
4428 Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection andRestoration). D. Papadimitriou, Ed., E. Mannie, Ed.. March 2006. (Format: TXT=118749 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Papadimitriou, Ed.
Request for Comments: 4428 Alcatel
Category: Informational E. Mannie, Ed.
Perceval
March 2006
ワーキンググループD.Papadimitriou、エドをネットワークでつないでください。コメントのために以下を要求してください。 4428年のアルカテルカテゴリ: エド情報のE.マニー、Perceval2006年3月
Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based
Recovery Mechanisms (including Protection and Restoration)
一般化されたマルチプロトコルラベルスイッチング(GMPLS)ベースの回収機構の分析(保護と王政復古を含んでいます)
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(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.
このドキュメントは、Generalized Multi-プロトコルLabel Switching(GMPLS)プロトコル群能力を現在IETF CCAMP作業部会で提案される回収機構に対して評価して、比較して、対照するために分析格子を提供します。 RFC4427で定義された用語を使用することでそれぞれの回収段階の詳細に渡る分析を提供します。 このドキュメントはコントロール飛行機弾力と関連する局面ではなく、輸送機の生存性と回復問題に集中します。
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
1. 序論…3 2. 貢献者…4 3. このDocumentのコンベンションUsed…5 4. 障害管理…5 4.1. 失敗検出…5 4.2. 失敗ローカライズと孤立…8 4.3. 失敗通知…9 4.4. 失敗相関関係…11 5. 回復メカニズム…11 5.1. 制御飛行機に対して責任を輸送してください…11 5.2. 技術無党派と技術依存性機序…12 5.2.1. OTN回復…12 5.2.2. プレOTN回復…13 5.2.3. Sonet/SDH回復…13
Papadimitriou & Mannie Informational [Page 1] RFC 4428 GMPLS Recovery Mechanisms March 2006
2006年の[1ページ]RFC4428GMPLS回収機構行進の情報のPapadimitriouとマニー
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
5.3. 制御の飛行機ベースの回収機構の特定の局面…14 5.3.1. バンドにおけるシグナリング対バンドの外…14 5.3.2. Uni双方向の失敗に対して…15 5.3.3. フル・スパン回復に対して目がありません…17 5.3.4. LSPと、LSPセグメントと長さ回復の違い…18 5.4. 回復タイプと計画の違い…19 5.5. LSP回収機構…21 5.5.1. 分類…21 5.5.2. LSP王政復古…23 5.5.3. あらかじめ計画されたLSP王政復古…24 5.5.4. LSPセグメント王政復古…25 6. 逆戻り…26 6.1. 復元する待ち(WTR)…26 6.2. Revertiveモード操作…26 6.3. 孤児にします。27 7. 階層構造…27 7.1. 水平な階層構造(仕切り)…28 7.2. 垂直的階層組織(層)…28 7.2.1. 回復粒状…30 7.3. 増大戦略…30 7.4. Disjointness…31 7.4.1. SRLG Disjointness…32 8. 回収機構分析…33 8.1. 速い集合(検出/相関関係と下に成立する時間)…34 8.2. 効率(回復切換え時間)…34 8.3. 丈夫さ…35 8.4. リソース最適化…36 8.4.1. 回復リソース・シェアリング…37 8.4.2. 回復リソース・シェアリングとSRLG回復…39 8.4.3. 回復リソース・シェアリング、SRLG Disjointness、および入場は制御されます…40 9. 概要と結論…42 10. セキュリティ問題…43 11. 承認…43 12. 参照…44 12.1. 標準の参照…44 12.2. 有益な参照…44
Papadimitriou & Mannie Informational [Page 2] RFC 4428 GMPLS Recovery Mechanisms March 2006
2006年の[2ページ]RFC4428GMPLS回収機構行進の情報のPapadimitriouとマニー
1. Introduction
1. 序論
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).
このドキュメントは、Generalized MPLS(GMPLS)プロトコル群能力をIETF CCAMP作業部会で提案される回収機構に対して評価して、比較して、対照するために分析格子を提供します。 輸送機の生存性と回復問題には焦点がコントロール飛行機弾力関連の局面にあるのではなく、あります。 本書では説明された回収機構はGMPLSベースの回復プロトコルに異なった要件を課しますが、プロトコルの仕様は本書ではカバーされていないでしょう。 議論した概念は技術独立者ですが、このドキュメントはそれとなくSonet[T1.105]/SDH[G.707]、Optical Transport Networks(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プロトコルブロックの適用性を詳しく述べることによって、このドキュメントは結論を下します。
Papadimitriou & Mannie Informational [Page 3] RFC 4428 GMPLS Recovery Mechanisms March 2006
2006年の[3ページ]RFC4428GMPLS回収機構行進の情報のPapadimitriouとマニー
2. Contributors
2. 貢献者
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作業部会Protectionの結果であり、王政復古デザインチームは共同努力です。 エディタ以外に、↓これは現在のメモに貢献した作者です:
Deborah Brungard (AT&T) 200 S. Laurel Ave. Middletown, NJ 07748, USA
デボラBrungard(AT&T)200秒間ローレルAve。 ミドルタウン、ニュージャージー 07748、米国
EMail: dbrungard@att.com
メール: dbrungard@att.com
Sudheer Dharanikota
Sudheer Dharanikota
EMail: sudheer@ieee.org
メール: sudheer@ieee.org
Jonathan P. Lang (Sonos) 506 Chapala Street Santa Barbara, CA 93101, USA
サンタバーバラ、カリフォルニア 93101、ジョナサンP.ラング(Sonos)506チャパラ通り米国
EMail: jplang@ieee.org
メール: jplang@ieee.org
Guangzhi Li (AT&T) 180 Park Avenue, Florham Park, NJ 07932, USA
Guangzhi李(AT&T)180パーク・アベニュー、Florham公園、ニュージャージー 07932、米国
EMail: gli@research.att.com
メール: gli@research.att.com
Eric Mannie Perceval Rue Tenbosch, 9 1000 Brussels Belgium
エリックマニーPerceval悔悟Tenbosch、9 1000ブリュッセルベルギー
Phone: +32-2-6409194 EMail: eric.mannie@perceval.net
以下に電話をしてください。 +32-2-6409194はメールされます: eric.mannie@perceval.net
Dimitri Papadimitriou (Alcatel) Francis Wellesplein, 1 B-2018 Antwerpen, Belgium
フランシスWellesplein、ディミトリPapadimitriou(アルカテル)の1B-2018のアントウェルペン(ベルギー)
EMail: dimitri.papadimitriou@alcatel.be
メール: dimitri.papadimitriou@alcatel.be
Papadimitriou & Mannie Informational [Page 4] RFC 4428 GMPLS Recovery Mechanisms March 2006
2006年の[4ページ]RFC4428GMPLS回収機構行進の情報のPapadimitriouとマニー
Bala Rajagopalan Microsoft India Development Center Hyderabad, India
Bala Rajagopalanマイクロソフトインド開発センターハイデラバード(インド)
EMail: balar@microsoft.com
メール: balar@microsoft.com
Yakov Rekhter (Juniper) 1194 N. Mathilda Avenue Sunnyvale, CA 94089, USA
ヤコフRekhter(杜松)1194N.マチルダ・Avenueサニーベル、カリフォルニア 94089、米国
EMail: yakov@juniper.net
メール: yakov@juniper.net
3. Conventions Used in this Document
3. このDocumentのコンベンションUsed
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[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]で開発された用語によく知られさせると思われます。
4. Fault Management
4. 障害管理
4.1. Failure Detection
4.1. 失敗検出
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]を見る)かLink Managementプロトコル能力の使用でその後の動作のための制御飛行機の引き金とならなければならない([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]を見る)は以下を覆う指揮能力を提供します。
Papadimitriou & Mannie Informational [Page 5] RFC 4428 GMPLS Recovery Mechanisms March 2006
2006年の[5ページ]RFC4428GMPLS回収機構行進の情報のPapadimitriouとマニー
- 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は道(すなわち、セクションか経路)の連続の保全をモニターします。 この操作は、信号の存在/欠如をモニターすることによって、実行されます。 例は物理的な層のためのSignal(LOS)検出のLossです、経路層のためのUnequipped(UNEQ)信号検出、クライアントの(例えば、AIS)が層にするServer Signal Fail Detection。
- 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はエンドポイントの間の信号のルーティングの保全をモニターします。 層が手動(例えば、ファイバー配線盤)でフレキシブルな接続性、自動的に(例えば、十字接続)を提供するなら、接続性モニターが必要です。 例は異なった層と対応するTrail Trace Identifier Mismatch検出のときに使用されたTrail(すなわち、セクションか経路)跡のIdentifierです。
- 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
- 信号は(サウスダコタ)を下げます: 関連データが降格している欠陥状態がアクティブであるという意味で下がったのを示す信号、(例えば、Bit Error Rateであるなら宣言しているdDEGが超えている、aが敷居をあらかじめセットした、) または
Papadimitriou & Mannie Informational [Page 6] RFC 4428 GMPLS Recovery Mechanisms March 2006
2006年の[6ページ]RFC4428GMPLS回収機構行進の情報のPapadimitriouとマニー
- 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.
Optical Transport Networks(OTN)に、光学の、または、デジタルのセクション層(すなわち、Optical Transmissionセクション(OTS)、Optical Multiplexセクション(OMS)、およびOpticalチャンネルTransport Unit(OTU))において光学の、または、デジタルの経路層(すなわち、Optical Channel(OCh)とOpticalチャンネルData Unit(ODU))で同等な指揮能力を提供します。 興味のある読者はその他の詳細についてITU-TのRecommendations[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ネットワークでは、失敗は中間的O電子OベースのOptical線System(OLS)によってマスクをかけられるかもしれません、Photonic Cross接続している(PXC)が上流の失敗を検出するのを防いで。 そのような場合、失敗検出はバンドで出ている通信チャネルで促進されるかもしれません、そして、失敗状態はPXC制御飛行機に報告されるかもしれません。 PXCとOLS制御飛行機とのIPのメッセージベースのコミュニケーションを送る[RFC4209]拡張子を使用することによって、これを提供できます。 また、PXCsが縁どり形式から独立しているので、光学信号の欠如を検出するか、または品質を測定することによって、失敗状態を引き起こすことができるだけです。 一般に、これらのメカニズムは電気(デジタル)のものほど信頼できません。 このドキュメントの範囲の外に両方のタイプの検出メカニズムがあります。 LMP通信チャネルを使用して、中間的OLSが電気(デジタル)のメカニズムをサポートするなら、これらの失敗状態は報告されます。
the PXC and subsequent recovery actions are performed as described in Section 5. As such, from the control plane viewpoint, this mechanism turns the OLS-PXC-composed system into a single logical entity, thus having the same failure management mechanisms as any other O-E-O capable device.
PXCとその後の回復動作はセクション5で説明されるように実行されます。 そういうものとして、コントロール飛行機観点から、このメカニズムはOLS-PXCが落ち着いたシステムをただ一つの論理的な実体に変えます、その結果、いかなる他のO電子Oできる装置とも同じ失敗管理メカニズムを持っています。
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)の損失: 光学信号がもう与えられたインタフェースの受信機の上に検出されないFailure(SF)状態に合図してください。
- Signal Degrade (SD): detection of the signal degradation over
a specific period of time.
- 信号は(サウスダコタ)を下げます: 特定の期間の間の信号劣化の検出。
Papadimitriou & Mannie Informational [Page 7] RFC 4428 GMPLS Recovery Mechanisms March 2006
2006年の[7ページ]RFC4428GMPLS回収機構行進の情報のPapadimitriouとマニー
- For SONET/SDH payloads, all of the above-mentioned supervision
capabilities can be used, resulting in SD or SF conditions.
- Sonet/SDHペイロードのために、サウスダコタか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設備、Opaque十字接続、およびいくつかの制限によるTransparent十字接続など)
- 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 実体の間には、バンドにおけるコミュニケーションがある状態で: 実体は物理的に切り離されますが、輸送機はそれらのバンドにおけるコミュニケーションを提供します。(例えば、Alarm Indication Signal(AIS)などのServer Signal Failuresなど)
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]を使用する)の間にバンドで出ている通信チャネルを提供します。
4.2. Failure Localization and Isolation
4.2. 失敗ローカライズと孤立
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)/長さの故障を検出する輸送機実体の位置(そうはアイデンティティをそうする)に関して決めている実体に情報を提供します。 そして、決めている実体は、よりすばらしい粒状の回復を達成するという正確な決定を開閉動作にすることができます。 また、失敗通知の一部としてこの情報を含むことができることに注意してください(セクション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回復が簡単な失敗通知に基づいて実行されるとき(失敗の下におけるLSPsが条件とさせる働きの識別を含んでいて)、これは特にそうです。 「縁」が例えばサブネットワークエンドノードを示すことに注意してください。 この場合、これらのLSPsの回復の後により正確なローカライズと孤立を実行できます。
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)などのプロトコルを使用できます。
Papadimitriou & Mannie Informational [Page 8] RFC 4428 GMPLS Recovery Mechanisms March 2006
2006年の[8ページ]RFC4428GMPLS回収機構行進の情報のPapadimitriouとマニー
4.3. Failure Notification
4.3. 失敗通知
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/長さの故障が起こって、検出されたことを中間的ノードに知らせる中古の1と)対応するサービスが利用可能でないことを決めている実体(失敗したLSP/長さのどんな中間的かエンドポイントにも対応できる)に知らせる2です)。 一般に、これらの決めている実体は適切な回復決定をするものになるでしょう。 また、回復実体で共同見つけられていると、これらの実体は対応する回復動作を実行するでしょう。
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(アラームIndication Signal)は、SignalのLossなどの失敗状態の結果、起こって、失敗が起こったことを川下のノード(適切な層の処理の)に通知するのに使用されます。 AISは2つの機能を実行します: 1) 失敗が検出されて、2が、)サービスがもう利用可能でないように接続エンドポイントに通知することを中間的ノード(適切な層が能力をモニターしている)に知らせてください。
For a distributed control plane supporting one (or more) failure notification mechanism(s), regardless of the mechanism's actual implementation, the same capabilities are needed with more (or less) information provided about the LSPs/spans under failure condition, their detailed statuses, etc.
メカニズムの実際の実現にかかわらず1つ(さらに)の失敗通知メカニズムをサポートする分散制御飛行機において、同じ能力が失敗状態、それらの詳細な状態などの下でLSPs/長さに関して、より多くの(それほど)情報を提供している状態で必要です。
The most important difference between these mechanisms is related to the fact that transport plane notifications (as defined today) would directly initiate either a certain type of protection switching (such as those described in [RFC4427]) via the transport plane or restoration actions via the management plane.
これらのメカニズムの最も重要な違いは輸送機通知(今日定義されるように)が管理飛行機を通して直接輸送機を通したあるタイプの保護の切り換え([RFC4427]で説明されたものなどの)か回復動作のどちらかを開始するだろうという事実に関連します。
On the other hand, using a failure notification mechanism through the control plane would provide the possibility of triggering either a protection or a restoration action via the control plane. This has the advantage that a control-plane-recovery-responsible entity does not necessarily have to be co-located with a transport maintenance/recovery domain. A control plane recovery domain can be defined at entities not supporting a transport plane recovery.
他方では、制御飛行機を通して失敗通知メカニズムを使用すると、制御飛行機を通して保護か回復動作のどちらかの引き金となる可能性は提供されるでしょう。 これには、原因となるコントロール飛行機回復実体が輸送維持/回復ドメインで共同見つけられるように必ず持っているというわけではない利点があります。 輸送機回復を支持しない実体でコントロール飛行機回復ドメインを定義できます。
Moreover, as specified in [RFC3473], notification message exchanges through a GMPLS control plane may not follow the same path as the LSP/spans for which these messages carry the status. In turn, this ensures a fast, reliable (through acknowledgement and the use of
そのうえ、[RFC3473]で指定されるように、GMPLS制御飛行機を通した通知メッセージ交換はこれらのメッセージが状態を運ぶLSP/長さと同じ経路に続いて起こらないかもしれません。 順番に、これが信頼できる断食を確実にする、(承認と使用
Papadimitriou & Mannie Informational [Page 9] RFC 4428 GMPLS Recovery Mechanisms March 2006
2006年の[9ページ]RFC4428GMPLS回収機構行進の情報のPapadimitriouとマニー
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/長さ状態の集合を通した)制御チャンネルをネットワークでつなぐか、またはばらばらにならせます。失敗通知メカニズム。
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プロトコルフェーズを見てください)。 さらに、それに合図する([RFC3473]を見ます)GMPLSが、また、速い通知が存在との共同へ駆け込むメカニズムであるので、中間的ノードがままに失敗状態の下で働くLSP/長さの状態に関して知識があった状態でします。
The trade-off here arises when defining what information the
LSP/span end-points (more precisely, the deciding entities) need in
order for the recovering entity to take the best recovery action:
If not enough information is provided, the decision cannot be
optimal (note that in this eventuality, the important issue is to
quantify the level of sub-optimality). If too much information is
provided, the control plane may be overloaded with unnecessary
information and the aggregation/correlation of this notification
information will be more complex and time-consuming to achieve.
Note that a more detailed quantification of the amount of
information to be exchanged and processed is strongly dependent on
the failure notification protocol.
LSP/長さがどんな情報を終わりで指すかを定義するとき、ここでのトレードオフは起こります。(より正確に、回復実体が最も良い回復行動を取るように、決めている実体) 必要性は中で注文されます: 十分そうでなければ、情報を提供して、決定は最適であるはずがありません(この不測の事態では、切迫した課題がサブの最適のレベルを定量化することであることに注意してください)。 この通知情報の集合/相関関係は、達成するのにおいて、よりあまりに多くの情報を提供するなら、不要な情報で制御飛行機を積みすぎるかもしれなくて、複雑であって、手間がかかるでしょう。 交換された、処理されるべき情報量の、より詳細な定量化が強く失敗通知プロトコルに依存していることに注意してください。
- 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/エンドポイントか中間的数ポイントの1つ実行されないなら、ポイントは、失敗の場所を見つけるように通知メッセージから十分な情報を受け取るはずです。 さもなければ、彼らが、必要があるだろう、(再、)、失敗ローカライズと孤立動作を開始してください。
- 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)失敗。
Papadimitriou & Mannie Informational [Page 10] RFC 4428 GMPLS Recovery Mechanisms March 2006
2006年の[10ページ]RFC4428GMPLS回収機構行進の情報のPapadimitriouとマニー
- 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.
- アラーム相関関係と集合(失敗を検出するノードの)は速い集合(ノードを検出するところの)と速い通知(相関関係と集合がエンドポイントを受けるのに起こるのを含意する)の間のトレードオフを見つけることができる状態に基づく一貫した決定を含意します。
4.4. Failure Correlation
4.4. 失敗相関関係
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]を見てください)、またはSignal Failure/を使用するときにはSonet/SDH文脈でGroupを下げてください。
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.
失敗相関関係操作を実行できるデフォルト平均時間間隔はそれが強く基本的なネットワーク形態に依存しているので提供するのが難しいことに注意してください。 したがって、1ノードあたり1つの構成可能な失敗相関関係時間を提供するのは賢明である場合があります。 この時間間隔の詳細な選択評価基準がこのドキュメントの範囲の外にあります。
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.
失敗相関関係を提供しないとき、ただ一つの失敗に対応して複数の失敗通知メッセージを出すかもしれません(例えば、ファイバーは切れました)。 それぞれの失敗通知メッセージは1セットの失敗した働くリソース(例えば、このファイバーを通して流れる個々のλLSP)の情報を含んでいます。 これは、より迅速な応答を考慮しますが、多量の失敗通知のため潜在的に制御飛行機を積みすぎることができます。
5. Recovery Mechanisms
5. 回収機構
5.1. Transport vs. Control Plane Responsibilities
5.1. 輸送対コントロール飛行機責任
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/長さ回復の場合に制御飛行機によって取られた責任の概観を与えます:
Papadimitriou & Mannie Informational [Page 11] RFC 4428 GMPLS Recovery Mechanisms March 2006
2006年の[11ページ]RFC4428GMPLS回収機構行進の情報のPapadimitriouとマニー
1. LSP/span Protection
1. 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: 失敗Detection Transport飛行機--フェーズ2: 失敗Localization/孤立Transport/制御飛行機--フェーズ3: 失敗Notification Transport/制御飛行機--フェーズ4: 保護Switching Transport/制御飛行機--フェーズ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の食糧を供給する段階の間、原因となる飛行機(特に保護の切り換えることのための)の選択を示します。
2. LSP/span Restoration
2. 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: 失敗Detection Transport飛行機--フェーズ2: 失敗Localization/孤立Transport/制御飛行機--フェーズ3: 失敗Notification Control飛行機--フェーズ4: 回復Switching Control飛行機--フェーズ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回復リソースの食糧を供給すること、失敗通知メカニズム、回復の切り換え、および逆戻り操作に焦点を合わせます。 そのうえ、失敗ローカライズ/孤立フェーズに関連づけられたメカニズムにいくつかの追加問題を捧げることができます。
5.2. Technology-Independent and Technology-Dependent Mechanisms
5.2. 技術無党派と技術依存性機序
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.
離散的な帯域幅増分(Sonet/SDH、G.709 OTNなどのような)がGMPLSベースの分散制御飛行機によって制御されている状態で、現在の回収機構分析はどんなサーキット指向のデータ飛行機技術にも適用されます。
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ベースの回復が届けなければならないメカニズムが彼らのそれぞれの適用性関係で彼らのまやかしに打ち勝って、彼らのプロを利用することを決定して、彼らは各技術のためにプロとまやかしをリストアップします。
5.2.1. OTN Recovery
5.2.1. OTN回復
OTN recovery specifics are left for further consideration.
OTN回復詳細はさらなる考慮に残されます。
Papadimitriou & Mannie Informational [Page 12] RFC 4428 GMPLS Recovery Mechanisms March 2006
2006年の[12ページ]RFC4428GMPLS回収機構行進の情報のPapadimitriouとマニー
5.2.2. Pre-OTN Recovery
5.2.2. プレ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).
- 彼らは、より簡単な構造の利益を得ます、それをメッシュベースの回復タイプと計画(1チャンネルあたり1個のベースの)により適するようにして。
- Failure suppression at intermediate node transponders, e.g., use of
squelching, implies that failures (such as LoL) will propagate to
edge nodes. Thus, edge nodes will have the possibility to initiate
recovery actions driven by upper layers (vs. use of non-standard
masking of upstream failures).
- 中間的ノードトランスポンダーでの失敗抑圧(例えば、スケルチの使用)は、失敗(LoLなどの)がノードを斜めに進ませるために伝播されるのを含意します。 したがって、縁のノードには、上側の層で追い立てられた回復動作(上流の失敗の標準的でないマスキングの使用に対する)を開始する可能性があるでしょう。
The main disadvantage is the lack of interworking due to the large amount of failure management (in particular failure notification protocols) and recovery mechanisms currently available.
主な不都合は多量の失敗のため管理が現在利用可能な(特に失敗通知プロトコル)と回収機構であると織り込む不足です。
Note also, that for all-optical networks, combination of recovery with optical physical impairments is left for a future release of this document because corresponding detection technologies are under specification.
仕様には対応する検出技術があるのでオール光学のネットワークにおいて、光の物理的な損傷がある回復の組み合わせがこのドキュメントの今後のリリースに残されるというメモも。
5.2.3. SONET/SDH Recovery
5.2.3. Sonet/SDH回復
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]の利点のいくつか、 より一般的に、どんなTime事業部Multiplexing(TDM)輸送機回復も以下を提供するということです。
- Protection types operating at the data plane level that are
standardized (see [G.841]) and can operate across protected domains
and interwork (see [G.842]).
- タイプが標準化される([G.841]を見ます)データ飛行機レベルで操作して、保護されたドメインの向こう側に操作して、織り込むことができる([G.842]を見ます)保護。
- Failure detection, notification, and path/section Automatic
Protection Switching (APS) mechanisms.
- 失敗検出、通知、および経路/セクションAutomatic Protection Switching(APS)メカニズム。
- Greater control over the granularity of the TDM LSPs/links that can
be recovered with respect to coarser optical channel (or whole
fiber content) recovery switching
- より下品な光学チャンネル(または、全体の繊維含有率)回復の切り換えに関して回収できるTDM LSPs/リンクの粒状の大コントロール
Some of the limitations of the SONET/SDH recovery are:
Sonet/SDH回復の制限のいくつかは以下の通りです。
- Limited topological scope: Inherently the use of ring topologies,
typically, dedicated Sub-Network Connection Protection (SNCP) or
shared protection rings, has reduced flexibility and resource
efficiency with respect to the (somewhat more complex) meshed
recovery.
- 限られた位相的な範囲: 本来、リングtopologiesの使用(通常専用Sub-ネットワークConnection Protection(SNCP)か共有された保護リング)は、(いくらか複雑)のかみ合っている回復に関して柔軟性とリソース効率を減少させました。
Papadimitriou & Mannie Informational [Page 13] RFC 4428 GMPLS Recovery Mechanisms March 2006
2006年の[13ページ]RFC4428GMPLS回収機構行進の情報のPapadimitriouとマニー
- 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保護は設備余力がしばしば活動していないままで残っているtopologiesを鳴らすために主に適用されます、帯域幅用法の効率を実際の問題にして。
- 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ベースの分配された回収機構の開発を正当化します。)
5.3. Specific Aspects of Control Plane-Based Recovery Mechanisms
5.3. 制御の飛行機ベースの回収機構の特定の局面
5.3.1. In-Band vs. Out-Of-Band Signaling
5.3.1. バンドにおけるシグナリング対バンドの外
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つのクラスの移送機構を考えることができます: ファイバーかファイバーの外(Data Communication Networkか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.
バンドとバンドの外でさらにファイバーの移送機構に細分できます。 そういうものとして、バンドとファイバーのファイバーのシグナリングがaの考慮に減少させるバンドのアウトの区別は輸送機トポロジーに関して物理的に埋め込まれたコントロールに対してトポロジーを論理的に平らにします。 このドキュメントの範囲では、それぞれの組の隣接しているノードの間の少なくとも1個のIP制御チャンネルが絶え間なく回復関連の情報とメッセージの交換を可能にすることができると思われます。 したがって、どちらの場合(すなわち、バンドかバンドの外)ではも、いつもそれぞれの組のノードの間の少なくとも1個の論理的であるか物理的な制御チャンネルが利用可能であると予想されます。
Therefore, the key issue when using in-fiber signaling is whether one can assume independence between the fault-tolerance capabilities of control plane and the failures affecting the transport plane (including the nodes). Note also that existing specifications like the OTN provide a limited form of independence for in-fiber signaling by dedicating a separate optical supervisory channel (OSC, see [G.709] and [G.874]) to transport the overhead and other control traffic. For OTNs, failure of the OSC does not result in failing the optical channels. Similarly, loss of the control channel must not result in failing the data channels (transport plane).
したがって、ファイバーのシグナリングを使用するとき、主要な問題は人が、コントロールの耐障害性能力の間の独立が輸送機に影響する飛行機と失敗であると仮定できるかどうかという(ノードを含んでいて)ことです。 また、ファイバーの別々の光学管理のチャンネル(OSC、[G.709]と[G.874]を見る)を捧げるのによるシグナリングがオーバーヘッドと他のコントロール交通を輸送するようにOTNのような既存の仕様が限局型の独立を提供することに注意してください。 OTNsに関しては、OSCの失敗は光学チャンネルに失敗するのに結果として生じません。 同様に、制御チャンネルの損失はデータ・チャンネル(輸送機)に失敗するのに結果として生じてはいけません。
Papadimitriou & Mannie Informational [Page 14] RFC 4428 GMPLS Recovery Mechanisms March 2006
2006年の[14ページ]RFC4428GMPLS回収機構行進の情報のPapadimitriouとマニー
5.3.2. Uni- vs. Bi-Directional Failures
5.3.2. Uni双方向の失敗に対して
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:
uni方向かa双方向のLSP/長さの故障が起こるとき(または、両方の組み合わせ)、失敗検出、相関関係、および通知メカニズム(セクション4では、説明される)を引き起こすことができます。 図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. Uni方向の失敗検出: 失敗は受信機側に検出されます、すなわち、それが川下のノードだけによって失敗(またはそれぞれ失敗伝播方向に依存する上流のノードで)に検出されます。
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 |
| |----...----| |---------| |----...----| |
------- ------- ------- -------
------- ------- ------- ------- | | | |Tx Rx| | | | | NodeA|----...----| NodeB|xxxxxxxxx| NodeC|----...----| NodeD| | |----...----| |---------| |----...----| | ------- ------- ------- -------
t0 >>>>>>> F
t0>>>>>>>F
t1 x <---------------x
Notification
t2 <--------...--------x x--------...-------->
Up Notification Down Notification
t1x<。---------------x通知t2<。--------...--------x x--------...--------通知下に通知への>。
Figure 1: Uni-directional failure detection
図1: Uni方向の失敗検出
Papadimitriou & Mannie Informational [Page 15] RFC 4428 GMPLS Recovery Mechanisms March 2006
2006年の[15ページ]RFC4428GMPLS回収機構行進の情報のPapadimitriouとマニー
------- ------- ------- -------
| | | |Tx Rx| | | |
| NodeA |----...----| NodeB |xxxxxxxxx| NodeC |----...----| NodeD |
| |----...----| |xxxxxxxxx| |----...----| |
------- ------- ------- -------
------- ------- ------- ------- | | | |Tx Rx| | | | | NodeA|----...----| NodeB|xxxxxxxxx| NodeC|----...----| NodeD| | |----...----| |xxxxxxxxx| |----...----| | ------- ------- ------- -------
t0 F <<<<<<< >>>>>>> F
t0F<<<<<<<>>>>>>>F
t1 x <-------------> x
Notification
t2 <--------...--------x x--------...-------->
Up Notification Down Notification
t1x<。------------->x通知t2<。--------...--------x x--------...--------通知下に通知への>。
Figure 2: Bi-directional failure detection
図2: 双方向の失敗検出
After failure detection, the following failure management operations can be subsequently considered:
失敗検出の後に、次に、以下の失敗管理操作を考えることができます:
- Each detecting entity sends a notification message to the
corresponding transmitting entity. For instance, in Figure 1, node
C sends a notification message to node B. In Figure 2, node C
sends a notification message to node B while node B sends a
notification message to node C. To ensure reliable failure
notification, a dedicated acknowledgement message can be returned
back to the sender node.
- それぞれ、実体を検出すると、通知メッセージは対応する伝える実体に送られます。 例えば、図1では、ノードCはノードB.In図2に通知メッセージを送って、ノードBはToが信頼できる失敗通知を確実にするノード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).
- 次に、ある(そして、予定される)タイムウィンドウの中では、失敗発生によって影響を与えられたノードはそれらの相関関係を実行するかもしれません。 uni方向の失敗の場合には、ノードBはノードCから通知メッセージを受け取るだけです、そして、その結果、この操作のための時間は取るにたらないです。 双方向の失敗の場合には、ノードBは対応する局所的に検出された情報でノードCからの受信された通知メッセージを関連させなければなりません(ノードCはノードBからメッセージを同じように処理しなければなりません)。
- After some (pre-determined) period of time, referred to as the
hold-off time, if the local recovery actions (see Section 5.3.4)
were not successful, the following occurs. In case of uni-
directional failure and depending on the directionality of the LSP,
node B should send an upstream notification message (see [RFC3473])
to the ingress node A. Node C may send a downstream notification
message (see [RFC3473]) to the egress node D. However, in that
case, only node A would initiate an edge to edge recovery action.
Node A is referred to as the "master", and node D is referred to as
the "slave", per [RFC4427]. Note that the other LSP end-node (node
D in this case) may be optionally notified using a downstream
notification message (see [RFC3473]).
- 地方の回復動き(セクション5.3.4を見る)がうまくいかなかったなら下に成立する時間と呼ばれたいくつかの(予定されます)期間の後に、以下は起こります。 方向の失敗とLSPの方向性によるノードBが送るはずであるuniの場合には、イングレスノードA.Node Cへの上流の通知メッセージ([RFC3473]を見る)は川下の通知メッセージ([RFC3473]を見る)を出口ノードD.Howeverに送るかもしれなくて、その場合、ノードAだけが、回復動作を斜めに進ませるために縁を開始するでしょう。 ノードAは「マスター」と呼ばれます、そして、ノードDは[RFC4427]あたりの「奴隷」と呼ばれます。 川下の通知メッセージを使用することでもう片方のLSPエンドノード(この場合、ノードD)が任意に通知されるかもしれないことに注意してください([RFC3473]を見てください)。
Papadimitriou & Mannie Informational [Page 16] RFC 4428 GMPLS Recovery Mechanisms March 2006
2006年の[16ページ]RFC4428GMPLS回収機構行進の情報のPapadimitriouとマニー
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が送るべきであるノードの場合には、イングレスノードA.Node Cへの上流の通知メッセージ([RFC3473]を見る)は川下の通知メッセージ([RFC3473]を見る)を出口ノードD.Howeverに送るかもしれません、LSPの方向性への依存のためイングレスノードAだけが縁から縁への回復動作を開始するでしょう。 また、この出来事が川下の通知メッセージを使用するのについてもう片方のLSPエンドノード(この場合、ノードD)が通知されるべきであることに注意してください([RFC3473]を見てください)。 例えば、DからAまで指示されたLSPが失敗状態であるなら、ノードCからDに送られた通知メッセージだけが回復動作を開始するでしょう。 この場合、決めていて回復しているノードDは[RFC4427]に従って「マスター」と呼ばれます、ノードAは「奴隷」(すなわち、実体だけを回復する)と呼ばれますが。
Note: The determination of the master and the slave may be based
either on configured information or dedicated protocol capability.
以下に注意してください。 マスターと奴隷の決断は構成された情報かひたむきなプロトコル能力に基づくかもしれません。
In the above scenarios, the path followed by the upstream and downstream notification messages does not have to be the same as the one followed by the failed LSP (see [RFC3473] for more details on the notification message exchange). The important point concerning this mechanism is that either the detecting/reporting entity (i.e., nodes B and C) is also the deciding/recovery entity or the detecting/reporting entity is simply an intermediate node in the subsequent recovery process. One refers to local recovery in the former case, and to edge-to-edge recovery in the latter one (see also Section 5.3.4).
上のシナリオでは、上流の、そして、川下の通知メッセージがあとに続いた経路は失敗したLSP(通知交換処理に関するその他の詳細に関して[RFC3473]を見る)でものが続いたのと同じである必要はありません。 このメカニズムに関する重要なポイントはまた、検出/会計主体(すなわち、ノードBとC)が決定/回復実体であるか検出/会計主体がその後の回復の過程で単に中間的ノードであるということです。 人は前のケースと、後者のものにおける縁から縁への回復への地方の回復について言及します(また、セクション5.3.4を見てください)。
5.3.3. Partial vs. Full Span Recovery
5.3.3. フル・スパン回復に対して目がありません。
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.
与えられた長さが1つ以上のLSPかLSPセグメントを運ぶとき、追加局面を考えなければなりません。 長さの故障の場合には、グループ(別名大量LSP回復)として、または、独立しているサブグループとして個別に、それが運ぶLSPsを回収できます。 相関関係タイムウィンドウが使用されていて、ただ一つの要求を使用することで数個のLSPsの同時の回復を実行できるとき、このメカニズムの選択は失敗通知粒状の如何にかかわらず引き起こされるでしょう。 そのうえ、そのようなサブグループを形成する評価基準がこのドキュメントの範囲の外にあります。
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
追加複雑さが場合で起こる、(サブ、)、LSP回復を分類してください。 aの間でそのa当然のことをノードの組、LSPsに与える、(サブ、)、異なったソースノード(すなわち、創始者)から作成されたかもしれなくて、異なった目的地ノードに向けられて、グループは含みます。 その結果、数個のLSPs(または、それが運ぶLSPsの全体のグループ)に影響する両性愛者の方向の長さの故障に続く失敗通知メッセージは必ず同じ創始者ノードに向けられるというわけではありません。 特に、これらのメッセージは指示されるかもしれません。
Papadimitriou & Mannie Informational [Page 17] RFC 4428 GMPLS Recovery Mechanisms March 2006
2006年の[17ページ]RFC4428GMPLS回収機構行進の情報のPapadimitriouとマニー
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.
失敗への両方の上流の、そして、川下のノードに。 したがって、そのような長さの故障は両側(すなわち、上流と川下のノードの両方から失敗までの)から実行されるべき回復動作の引き金となるかもしれません。 人が、対応する回収機構(そして、それらの系列)の定義を容易にするために井戸としてここで決定(そして、回復)実体(「マスター」と呼ばれる)が[RFC4427]あたり全体のLSPの回復の唯一の創始者であると仮定する、(サブ、)、分類してください。
5.3.4. Difference between LSP, LSP Segment and Span Recovery
5.3.4. LSPと、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 Segmentと長さ回復の主要な違いはシグナリングメッセージが旅行しなければならない中間的ノードの数に関連します。 ノードが必ずLSP(または、LSP Segment)回復の場合で隣接しているというわけではないので、決定/回復実体への報告から交換処理に合図すると、いくつかの中間的ノードが交差しなければならないかもしれません。 特に、これは、ホップの数のため目的地と失敗発生の位置を切り離しながら、通知メッセージに適用されます。 これは追加伝播と推進遅れをもたらします。 前の遅れがある特定の状況では非取るにたらないかもしれないことに注意してください。 例えば、銅の中では、ネットワーク、遅れは200kmあたりバンドの外では、およそ1msです。
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を構成するかもしれないセグメントに終わりから終わりへのLSPsと、そして、適切な回収機構(すなわち、縁から縁への回復)はまさに同じである場合があります。 人は、後者の場合でしかしながら、失敗通知の目的地が通信するのがそれぞれのこれらのセグメントの出口にイングレス/なると予想します。 したがって、セクション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
以下に注意してください。 いくつかの研究がLSP/長さリカバリ技術の相対的パフォーマンスの定量分析を提供します。 例えば、[ワング]、ダイナミックなLSP回復(セクション5.5.2を見る)が中くらいのネットワーク負荷の下でよく振る舞いますが、性能転落を受けるこれらのテクニックが目立って、より高い負荷は回復リソースのための、より大きい主張を提供するので、分析格子を提供します。 失敗したリンクの周りの経路が影響を受けるLSPsのホップカウントを増加させて、その結果、追加ネットワーク資源を消費する傾向があるので、長さの故障の[ワング]で定義されるLSP回復は、より高い負荷で下がります。 また、初期の試みが失敗するなら新しい回復試みを開始する失敗した働くLSPのソースノードはLSP回復の性能を高めることができます。 試みが十分であるただ一つの再試行
Papadimitriou & Mannie Informational [Page 18] RFC 4428 GMPLS Recovery Mechanisms March 2006
2006年の[18ページ]RFC4428GMPLS回収機構行進の情報のPapadimitriouとマニー
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回復試みを開始する能力の大きい増加を起こしてください。 追加試みを許すと、性能におけるわずかな余禄だけが生産されます。 これは、ダイナミックなLSP回復を使用するとき、追加している(中間的)crankbackシグナリングを使用するのを示します(.2--セクション5.5で説明されて、2をケースに入れてください)。 このドキュメントの範囲の外にcrankbackシグナリングに関する詳細があります。
5.4. Difference between Recovery Type and Scheme
5.4. 回復タイプと計画の違い
[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/長さ回復タイプを定義します。 このセクションはこれらの回復タイプを使用することで築き上げることができる回復計画について説明します。 要するに、回復計画は与えられた回復タイプ(彼らが許す回復タイプのセットからの)を支持している数個のイングレス出口ノード組の組み合わせと定義されます。 1:1などの回復タイプの違いかM: Nと、(1:1)^nか(M: N)^n(共有されたメッシュ回復と呼ばれます)などの回復計画を例証するためにいくつかの例をここに提供します。
1. (1:1)^n with recovery resource sharing
1. (1:1)^回復リソース・シェアリングがあるn
The exponent, n, indicates the number of times a 1:1 recovery type is applied between at most n different ingress-egress node pairs. Here, at most n pairs of disjoint working and recovery LSPs/spans share a common resource at most n times. Since the working LSPs/spans are mutually disjoint, simultaneous requests for use of the shared (common) resource will only occur in case of simultaneous failures, which are less likely to happen.
解説者(n)は1:1回復タイプが高々n異なったイングレス出口ノード組の間で適用されるという回の数を示します。 ここで、nが対にする大部分では、働きをばらばらにならせてください。そうすれば、回復のLSPs/長さは高々n回一般的なリソースを共有します。 働くLSPs/長さが互いにそうので、ばらばらになってください、そして、共有された(一般的な)リソースの使用を求める同時の要求は同時の失敗の場合に現れるだけでしょう。失敗は、より起こりそうにはありません。
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.
例えば、2がケースに入れる一般的な(1:1)^では、グループにおける2回復LSPsが同じ一般的なリソースを重ね合わせるなら、ただ一つの失敗しか扱うことができません。 どんな複数の働くLSPの故障でも、少なくとも1働くLSPに対して自動復旧を否定するでしょう。 例えば、働くLSPs A B C、F-G-H、および彼らのそれぞれの回復LSPsがある以下のトポロジーが一般的なD-Eリンクリソースを共有するA D電子CとF D電子Hであると考えてください。
A---------B---------C
\ /
\ /
D-------------E
/ \
/ \
F---------G---------H
A---------B---------C\/\/D-------------E/\/\F---------G---------H
Papadimitriou & Mannie Informational [Page 19] RFC 4428 GMPLS Recovery Mechanisms March 2006
2006年の[19ページ]RFC4428GMPLS回収機構行進の情報のPapadimitriouとマニー
2. (M:N)^n with recovery resource sharing
2. (M: N)^回復リソース・シェアリングがあるn
The (M:N)^n scheme is documented here for the sake of completeness only (i.e., it is not mandated that GMPLS capabilities support this scheme). The exponent, n, indicates the number of times an M:N recovery type is applied between at most n different ingress-egress node pairs. So the interpretation follows from the previous case, except that here disjointness applies to the N working LSPs/spans and to the M recovery LSPs/spans while sharing at most n times M common resources.
(M: N)^n計画は完全性だけのためにここに記録されます(すなわち、GMPLS能力がこの計画を支持するのが強制されません)。 解説者(n)はM: 回復がタイプするNが高々n異なったイングレス出口ノード組の間で適用されるという回の数を示します。 それで、解釈は先の事件から続きます、ばらばらになるのがほとんどのn回Mで一般的なリソースを共有している間、ここでN働くLSPs/長さと、そして、M回復のLSPs/長さに適用されるのを除いて。
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 N n働くLSPsとすべてではなく、共有された回復リソースのプールがいずれにも利用可能である合計n=1の「グループ」をもたらします。 そのような状態、定義におけるaメートル法、それはLSPsが複数のLSPsの同時の失敗を扱うグループの性能のいくつかのしるしを与える回復の中でオーバラップの量について説明します。
For instance, in the simple (1:1)^n case, if n recovery LSPs in a (1:1)^n group overlap, then the group can handle only single failures; any simultaneous failure of multiple working LSPs will cause at least one working LSP to be denied automatic recovery. But if one considers, for instance, a (2:2)^2 group in which there are two pairs of overlapping recovery LSPs, then two LSPs (belonging to the same pair) can be simultaneously recovered. The latter case can be illustrated by the following topology with 2 pairs of working LSPs A-B-C and F-G-H and their respective recovery LSPs A-D-E-C and F-D-E-H that share two common D-E link resources.
例えば、簡単な(1:1)^n場合では、(1:1)^nグループにおけるn回復LSPsが重なるなら、グループはただ一つの失敗しか扱うことができません。 複数の働くLSPsのどんな同時の失敗でも、少なくとも1働くLSPに対して自動復旧を否定するでしょう。 しかし、人が、例えば、(2:2)^が回復LSPsを重ね合わせる2組がある2グループであると考えるなら、同時に、2LSPs(同じ組に属す)を回収できます。 2組の働くLSPs A B CとF-G-Hと彼らの2つの共有されるそれぞれの回復LSPs A D電子CとF D電子H一般的なD-Eリンクリソースがある以下のトポロジーは後者のケースを例証できます。
A========B========C
\\ //
\\ //
D =========== E
// \\
// \\
F========G========H
A========B========C\\//\\//D=========== E//\\//\\F========G========H
Moreover, in all these schemes, (working) path disjointness can be enforced by exchanging information related to working LSPs during the recovery LSP signaling. Specific issues related to the combination of shared (discrete) bandwidth and disjointness for recovery schemes are described in Section 8.4.2.
そのうえ、これらのすべての計画では、回復LSPシグナリングの間、働くLSPsに関連する情報を交換することによって、(働き)経路ばらばらになるのを実施できます。 回復計画のための共有された(離散的な)帯域幅の組み合わせに関連する特定の問題とばらばらになるのはセクション8.4.2で説明されます。
Papadimitriou & Mannie Informational [Page 20] RFC 4428 GMPLS Recovery Mechanisms March 2006
2006年の[20ページ]RFC4428GMPLS回収機構行進の情報のPapadimitriouとマニー
5.5. LSP Recovery Mechanisms
5.5. LSP回収機構
5.5.1. Classification
5.5.1. 分類
The recovery time and ratio of LSPs/spans depend on proper recovery LSP provisioning (meaning pre-provisioning when performed before failure occurrence) and the level of overbooking of recovery resources (i.e., over-provisioning). A proper balance of these two operations will result in the desired LSP/span recovery time and ratio when single or multiple failures occur. Note also that these operations are mostly performed during the network planning phases.
LSPs/長さの回復時間と比率は(意味プレの食糧を供給する以前実行されると失敗発生)と回復リソース(すなわち、食糧を供給し過ぎる)のオーバーブッキングのレベルに食糧を供給する適切な回復LSPに依存します。 単一であるか複数の失敗が起こると、これらの2つの操作の適性バランスは必要なLSP/長さ回復時間と比率をもたらすでしょう。 また、これらの操作がネットワーク計画段階の間ほとんど実行されることに注意してください。
The different options for LSP (pre-)provisioning and overbooking are classified below to structure the analysis of the different recovery mechanisms.
LSPのための異なったオプション、(プレ、)、食糧を供給するのとオーバーブッキングは、異なった回収機構の分析を構造化するために以下で分類されます。
1. Pre-Provisioning
1. プレの食糧を供給すること
Proper recovery LSP pre-provisioning will help to alleviate the failure of the working LSPs (due to the failure of the resources that carry these LSPs). As an example, one may compute and establish the recovery LSP either end-to-end or segment-per-segment, to protect a working LSP from multiple failure events affecting link(s), node(s) and/or SRLG(s). The recovery LSP pre-provisioning options are classified as follows in the figure below:
適切な回復LSPプレの食糧を供給するのは、働くLSPs(これらのLSPsを運ぶリソースの失敗による)の失敗を軽減するのを助けるでしょう。 リンク、ノード、そして/または、SRLG(s)に影響する複数の失敗出来事から働くLSPを保護するために例と、どちらかの終わりから終わりの回復LSPか1セグメントあたりのセグメントを計算して、書き立てるかもしれません。 オプションにあらかじめ食糧を供給する回復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:
フェーズに食糧を供給する回復LSP:
Papadimitriou & Mannie Informational [Page 21] RFC 4428 GMPLS Recovery Mechanisms March 2006
2006年の[21ページ]RFC4428GMPLS回収機構行進の情報のPapadimitriouとマニー
(1) Path Computation --> On-demand
|
|
--> Pre-Computed
|
|
(2) Signaling --> On-demand
|
|
--> Pre-Signaled
|
|
(3) Resource Selection --> On-demand
|
|
--> Pre-Selected
(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/長さ回復回数に通じることに注意してください。 以下のセクションは異なった回収機構を分析するときオプションにあらかじめ食糧を供給する上記を考えるでしょう。
2. Overbooking
2. オーバーブッキング
There are many mechanisms available that allow the overbooking of the recovery resources. This overbooking can be done per LSP (as in the example mentioned above), per link (such as span protection), or even per domain. In all these cases, the level of overbooking, as shown in the below figure, can be classified as dedicated (such as 1+1 and 1:1), shared (such as 1:N and M:N), or unprotected (and thus restorable, if enough recovery resources are available).
回復リソースのオーバーブッキングを許容する利用可能な多くのメカニズムがあります。 LSP(前記のように例のように)、リンク(長さ保護などの)、またはドメインさえ単位でこのオーバーブッキングができます。 全部で、捧げられるようにこれらのケース(以下の図に示されるようにオーバーブックするレベル)を分類できる、(1 +1と1:1) 共有されている、(M: 1:NやNなどの)保護のない、(その結果、復元できる、十分な回復リソースが利用可能である、)
Overbooking levels:
オーバーブッキングレベル:
+----- Dedicated (for instance: 1+1, 1:1, etc.)
|
|
+----- 捧げられます(: 例えば、+1、1つの1:1など)。 | |
+----- Shared (for instance: 1:N, M:N, etc.)
|
Level of |
Overbooking -----+----- Unprotected (for instance: 0:1, 0:N)
+----- 共有されます(M: : 例えば、1:N、Nなど)。 | 平ら| オーバーブッキング-----+----- 保護のない(: 例えば、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
また、共有された回復を使用するとき、preemptibleの余分な交通を支持するかもしれません。 そして、回収機構が回復動作の間の回復リソース主張の場合にこの低い優先権交通の先取りを許すと予想されます。 以下のセクションは考えるでしょう。
Papadimitriou & Mannie Informational [Page 22] RFC 4428 GMPLS Recovery Mechanisms March 2006
2006年の[22ページ]RFC4428GMPLS回収機構行進の情報のPapadimitriouとマニー
above-mentioned overbooking options when analyzing the different recovery mechanisms.
異なった回収機構を分析するときの上記のオーバーブッキングオプション。
5.5.2. LSP Restoration
5.5.2. LSP王政復古
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--経路選択時間: t--終わりから終わりへのLSP資源予約時間: Tr(また、リソース選択のためのデルタは考えられます、次に、対応する合計時はTrsと呼ばれる)--終わりから終わりへのLSP Resource Activation Time: バイバイ(また、リソース選択のためのデルタは考えられます、次に、対応する合計時はTasと呼ばれます)
The Path Selection Time (Ts) is considered when a pool of recovery LSP paths between a given pair of source/destination end-points is pre-computed, and after a failure occurrence one of these paths is selected for the recovery of the LSP under failure condition.
与えられた組の目的地ソース/エンドポイントの間の回復LSP経路のプールがあらかじめ計算されて、これらの経路の失敗発生1の後にLSPの回復のために失敗条件のもとで選択されると、Path Selection Time(t)は考えられます。
Note: failure management operations such as failure detection, correlation, and notification are considered (for a given failure event) as equally time-consuming for all the mechanisms described below:
以下に注意してください。 失敗検出や、相関関係や、通知などの失敗管理操作は以下で説明されたすべてのメカニズムにおいて等しく手間がかかると考えられます(与えられた失敗出来事のために):
1. With Route Pre-computation (or LSP re-provisioning)
1. ルートプレ計算で(または、LSP再の食糧を供給すること)
An end-to-end restoration LSP is established after the failure(s) occur(s) based on a pre-computed path. As such, one can define this as an "LSP re-provisioning" mechanism. Here, one or more (disjoint) paths for the restoration LSP are computed (and optionally pre- selected) before a failure occurs.
失敗が起こった後に回復LSPが設立される終わりから終わりへの(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と等しいです。
2. Without Route Pre-computation (or Full LSP re-routing)
2. ルートプレ計算なしで(または、Full LSPのコースを変更すること)
An end-to-end restoration LSP is dynamically established after the failure(s) occur(s). After failure occurrence, one or more (disjoint) paths for the restoration LSP are dynamically computed and
失敗が起こった後に回復LSPがダイナミックに設立される終わりから終わりへの(s)。 そして失敗発生の後に回復LSPのための1つ以上(ばらばらになる)の経路がダイナミックに計算される。
Papadimitriou & Mannie Informational [Page 23] RFC 4428 GMPLS Recovery Mechanisms March 2006
2006年の[23ページ]RFC4428GMPLS回収機構行進の情報のPapadimitriouとマニー
one is selected. As such, one can define this as a complete "LSP re-routing" mechanism.
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はその結果、+ (+ t)TrsがTcと等しいことです。 したがって、これらの2つのアプローチの間の時間性能は経路計算Tc(そして、潜在的選択時間、Ts)に必要である時までに異なります。
5.5.3. Pre-Planned LSP Restoration
5.5.3. あらかじめ計画されたLSP王政復古
Pre-planned LSP restoration (also referred to as pre-planned LSP re- routing) implies that the restoration LSP is pre-signaled. This in turn implies the reservation of recovery resources along the restoration path. Two cases can be defined based on whether the recovery resources are pre-selected.
あらかじめ計画されたLSP回復(また、あらかじめ計画されたLSP再ルーティングと呼ばれる)は、回復LSPがあらかじめ合図されるのを含意します。 これは回復経路に沿って順番に回復リソースの予約を含意します。 回復リソースが前選択されるかどうかに基づいて2つのケースを定義できます。
1. With resource reservation and without resource pre-selection
1. 予約とリソース前選択のないリソースで
Before failure occurrence, an end-to-end restoration path is pre- selected from a set of pre-computed (disjoint) paths. The restoration LSP is signaled along this pre-selected path to reserve resources at each node, but these resources are not selected.
失敗発生の前に、終わりから端への回復経路は1セットの(ばらばらになります)あらかじめ計算された経路からあらかじめ選択されます。 この前選択された経路に沿って回復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のために予約されたリソースは、LSPsが同時に失敗しないと働きに予想される複数の回復LSPsの間で捧げられるか、または共有されるかもしれません。 独立している失敗の向こう側にこれらのリソースを共有できる程度を定義するためにローカルのノード方針を適用できます。 また、回復計画が考えられるので、リソース・シェアリングを同じイングレスで終始する回復LSPsと出口ノードに制限するべきではありません。 したがって、この計画に参加する各ノードがこの計画がかかわる回復リソースの共有度合いに関する何らかのフィードバック情報を受け取ると予想されます。
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が活性であるときに、低優先度LSPsが回復リソースを使用することで設立されたなら、それらを先取りしなければなりません。
Thus, the expected total restoration time T is equal to Tas (post- failure activation), while operations performed before failure occurrence take Tc + Ts + Tr.
したがって、予想された総回復時間TはTas(ポスト失敗起動)と等しいです、失敗発生の前に実行された操作がTc+t+Tr取りますが。
Papadimitriou & Mannie Informational [Page 24] RFC 4428 GMPLS Recovery Mechanisms March 2006
2006年の[24ページ]RFC4428GMPLS回収機構行進の情報のPapadimitriouとマニー
2. With both resource reservation and resource pre-selection
2. 資源予約とリソース前選択の両方で
Before failure occurrence, an end-to-end restoration path is pre- selected from a set of pre-computed (disjoint) paths. The restoration LSP is signaled along this pre-selected path to reserve AND select resources at each node, but these resources are not committed at the data plane level. So that the selection of the recovery resources is committed at the control plane level only, no cross-connections are performed along the restoration path.
失敗発生の前に、終わりから端への回復経路は1セットの(ばらばらになります)あらかじめ計算された経路からあらかじめ選択されます。 回復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のために予約されて、選択されたリソースは、ひたむきであるかLSPsが同時に失敗しないと関連運用に予想される複数の回復LSPsの間で共有されてさえいるかもしれません。 独立している失敗の向こう側にこれらのリソースを共有できる程度を定義するためにローカルのノード方針を適用できます。 また、回復計画が考えられるので、リソース・シェアリングを同じイングレスで終始する回復LSPsと出口ノードに制限するべきではありません。 したがって、この計画に参加する各ノードがこの計画がかかわる回復リソースの共有度合いに関する何らかのフィードバック情報を受け取ると予想されます。
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が活性であるときに、低優先度LSPsが回復リソースを使用することで設立されたなら、それらを先取りしなければなりません。
Thus, the expected total restoration time T is equal to Ta (post- failure activation), while operations performed before failure occurrence take Tc + Ts + Trs. Therefore, time performance between these two approaches differs only by the time required for resource selection during the activation of the recovery LSP (i.e., Tas - Ta).
したがって、予想された総回復時間TはTa(ポスト失敗起動)と等しいです、失敗発生の前に実行された操作がTc+t+Trs取りますが。 したがって、これらの2つのアプローチの間の時間性能がリソース選択に回復LSPの起動の間、単に必要である時までに異なる、(すなわち、Tas--、バイバイ、)
5.5.4. LSP Segment Restoration
5.5.4. LSPセグメント王政復古
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セグメントベース(M: 例えば、地下鉄ネットワークにおける1:1縁から縁へのLSP保護、およびコアでのN縁から縁への保護)で適用された複数の回収機構は終わりから終わりへのLSPを回収できます。 これらのメカニズムは、理想的に独立していて、異なった失敗ローカライズと通知メカニズムを使用さえするかもしれません。
Papadimitriou & Mannie Informational [Page 25] RFC 4428 GMPLS Recovery Mechanisms March 2006
2006年の[25ページ]RFC4428GMPLS回収機構行進の情報のPapadimitriouとマニー
6. Reversion
6. 逆戻り
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/長さまでの交通を失敗状態の下に切り換えるメカニズムと定義されます。 回復ドメイン方針の裁量には正常化の使用があります。 使用される正常化メカニズムによって、正常化は通常の交通(1秒は当たった)に影響を与えるかもしれません。
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.
正常化を支持するなら、失敗状態がクリアされると、LSP/がかかる1を)働く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、そして/または、長さ)の再利用も回復ドメイン方針の裁量の下にあります。
6.1. Wait-To-Restore (WTR)
6.1. 復元する待ち(WTR)
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).
特定のメカニズム(復元する待ち)は、頻繁な回復が間欠欠陥(例えば、サウスダコタ敷居の周りで変動するBit Error Rate(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/長さ)がこの評価基準を満たした後に、通常の交通が再び対応するリソースを使用する前に時間の一定期間は経過するものとします。 この持続時間が、Waitと呼んだ、-、回復、(WTR) 期間かタイマが、一般に、数分(例えば、5分)の注文にはあって、設定できるべきです。 WTRタイマは、一定期間である、または再試行する前に、より長い期間に増加して備えるかもしれません。 以前に働くLSP/長さに関するSFかサウスダコタ状態がWTRタイマ価値をくつがえすでしょう(すなわち、WTRキャンセルとWTRタイマは再開するでしょう)。
6.2. Revertive Mode Operation
6.2. Revertiveモード操作
In revertive mode of operation, when the recovery LSP/span is no longer required, i.e., the failed working LSP/span is no longer in SD or SF condition, a local Wait-to-Restore (WTR) state will be activated before switching the normal traffic back to the recovered working LSP/span.
すなわち、回復のLSP/長さはもう必要でないときに操作、失敗した働くLSP/長さのrevertiveモードで、状態がもうサウスダコタかどんなSFにもありません、ローカル、Wait、回復する、回復している働くLSP/長さに通常の交通に元に戻らせる前に、(WTR)状態は動かされるでしょう。
During the reversion operation, since this state becomes the highest in priority, signaling must maintain the normal traffic on the
この状態が優先権で最も高くなって以来の逆戻り操作の間、シグナリングは通常の交通をオンに維持しなければなりません。
Papadimitriou & Mannie Informational [Page 26] RFC 4428 GMPLS Recovery Mechanisms March 2006
2006年の[26ページ]RFC4428GMPLS回収機構行進の情報のPapadimitriouとマニー
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/長さ用法は先取りされるかもしれません。
6.3. Orphans
6.3. 孤児
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などの)から削除の開始の引き金となってください。
7. Hierarchies
7. 階層構造
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
階層構造は、スケーラブルな複合システムを組立てるのに使用されます。内部の詳細を隠すことによって、抽象化は大きいネットワークを造るメカニズムとして、または、技術を実施するためのテクニックとして使用されます、位相的であるか、または管理の境界。 ネットワークの生存性を制御するために同じ階層的な概念を適用できます。 ネットワークの生存性はネットワークが失敗の場合、影響を受ける交通を復元できる能力のセットです。 ネットワークの生存性は[RFC4427]で、より詳しく定義されます。 一般に、回復行動が乗法を避けるために失敗の最も近くで回復可能なLSP/長さによって取られると予想されます。
Papadimitriou & Mannie Informational [Page 27] RFC 4428 GMPLS Recovery Mechanisms March 2006
2006年の[27ページ]RFC4428GMPLS回収機構行進の情報のPapadimitriouとマニー
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.
回復動作について。 そのうえ、制御飛行機論理的なパーティションに回復階層構造も縛ることができます(例えば、管理的、または、位相的な境界)。 それぞれの論理的なパーティションは異なった回収機構を適用するかもしれません。
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).
要するに、一般的に、より高い層が、よりすばらしい、しかし、より遅い回復を供給できる間下層が粗い、しかし、より速い回復を供給できると受け入れます。 そのうえ、また、機能的なオーバラップがある同様の層を避けるのもネットワーク資源利用と処理オーバヘッドを最適化するために望ましい、以来各層で同じ能力を繰り返すのは全体でネットワークのために少しの加えられた値も作成しません。 さらに、下層回収機構が可能にされても、それは上側の層で回収機構の追加条項を防ぎません。 逆さの声明は必ず成立するというわけではありません。 すなわち、上側の層の回収機構を可能にすると、下層回収機構の使用は防がれるかもしれません。 このような関係においては、このセクションは物理的な(受け身の)層を含むこれらの階層的な局面を分析します。
7.1. Horizontal Hierarchy (Partitioning)
7.1. 水平な階層構造(仕切り)
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セグメントは地下鉄かコアサブネットワークの中で定義されるかもしれませんが。 彼らが運ぶそれぞれのLSPsがそれ自身の回復タイプを持つことができるので(計画さえしてください)、それぞれのこれらの位相的な構造はそのように呼ばれた「回復ドメイン」を決定します。 サブネットワークの中の複数の回復タイプと計画のサポートは「マルチ回復のできるドメイン」か単に「マルチ回復ドメイン」と呼ばれます。
7.2. Vertical Hierarchy (Layers)
7.2. 垂直的階層組織(層)
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.
あるネットワーク生存性目的がネットワークによって支持されたサービスのために満たされるのを保証するために経路(すなわち、できる切り換え)とセクション層の向こう側に利用可能な異なった回復能力を結合するのは非常にやりがいがあります。
Papadimitriou & Mannie Informational [Page 28] RFC 4428 GMPLS Recovery Mechanisms March 2006
2006年の[28ページ]RFC4428GMPLS回収機構行進の情報のPapadimitriouとマニー
As a first analysis step, one can draw the following guidelines for a vertical coordination of the recovery mechanisms:
最初の分析ステップとして、人は回収機構の垂直的調整のために以下のガイドラインを描くことができます:
- The lower the layer, the faster the notification and switching.
- 層が低ければ低いほど、通知と切り換えは、より速いです。
- The higher the layer, the finer the granularity of the recoverable
entity and therefore the granularity of the recovery resource.
- 層が高ければ高いほど、回復可能な実体の粒状としたがって、回復リソースの粒状は、よりすばらしいです。
Moreover, in the context of this analysis, a vertical hierarchy consists of multiple layered transport planes providing different:
そのうえ、この分析の文脈では、異なるなら、垂直的階層組織は複数の層にされた輸送機から成ります:
- Discrete bandwidth granularities for non-packet LSPs such as OCh,
ODUk, STS_SPE/HOVC, and VT_SPE/LOVC LSPs and continuous bandwidth
granularities for packet LSPs.
- OChや、ODUkや、通り_SPE/HOVCや、バーモント_SPE/LOVC LSPsなどの非パケットLSPsのための離散的な帯域幅粒状とパケットLSPsのための連続した帯域幅粒状。
- Potential recovery capabilities with different temporal
granularities: ranging from milliseconds to tens of seconds
- 異なった時の粒状がある潜在的回復能力: ミリセカンドから10秒まで及びます。
Note: based on the bandwidth granularity, we can determine four classes of vertical hierarchies: (1) packet over packet, (2) packet over circuit, (3) circuit over packet, and (4) circuit over circuit. Below we briefly expand on (4) only. (2) is covered in [RFC3386]. (1) is extensively covered by the MPLS Working Group, and (3) by the PWE3 Working Group.
以下に注意してください。 帯域幅粒状に基づいて、私たちは4つのクラスの垂直的階層組織を決定できます: (1) パケットの上のパケット、サーキット、パケットの上の(3)サーキット、およびサーキットの上の(4)サーキットの上の(2)パケット。 以下では、私たちが簡潔に(4)だけについて詳述します。 (2) [RFC3386]では、覆われています。 (1) MPLS作業部会、および(3)でPWE3作業部会によって手広く覆われています。
In SONET/SDH environments, one typically considers the VT_SPE/LOVC and STS SPE/HOVC as independent layers (for example, VT_SPE/LOVC LSP uses the underlying STS_SPE/HOVC LSPs as links). In OTN, the ODUk path layers will lie on the OCh path layer, i.e., the ODUk LSPs use the underlying OCh LSPs as OTUk links. Note here that lower layer LSPs may simply be provisioned and not necessarily dynamically triggered or established (control driven approach). In this context, an LSP at the path layer (i.e., established using GMPLS signaling), such as an optical channel LSP, appears at the OTUk layer as a link, controlled by a link management protocol such as LMP.
Sonet/SDH環境で、人は、バーモント_SPE/LOVCとSTS SPE/HOVCが独立している層であると通常みなします(例えば、バーモント_SPE/LOVC LSPはリンクとして基本的な通り_SPE/HOVC LSPsを使用します)。 OTNでは、ODUk経路層はOCh経路層に位置するでしょう、すなわち、OTUkがリンクするとき、ODUk LSPsが基本的なOCh LSPsを使用します。 ここで下側の層のLSPsが必ず絶対に食糧を供給されて、ダイナミックに引き起こされるというわけではありませんし、また設立されるかもしれないというわけではないことに注意してください(駆動アプローチを制御してください)。 このような関係においては、経路層(すなわち、GMPLSシグナリングを使用することで、設立される)の光学チャンネルLSPなどのLSPは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回復を達成するためにコーディネートを必要とします。 したがって、丈夫さと速い集合を達成するために、マルチ層の回復は微調整されたコーディネートメカニズムを必要とします。
Papadimitriou & Mannie Informational [Page 29] RFC 4428 GMPLS Recovery Mechanisms March 2006
2006年の[29ページ]RFC4428GMPLS回収機構行進の情報のPapadimitriouとマニー
Moreover, in the absence of adequate recovery mechanism coordination (for instance, a pre-determined coordination when using a hold-off timer), a failure notification may propagate from one layer to the next one within a recovery hierarchy. This can cause "collisions" and trigger simultaneous recovery actions that may lead to race conditions and, in turn, reduce the optimization of the resource utilization and/or generate global instabilities in the network (see [MANCHESTER]). Therefore, a consistent and efficient escalation strategy is needed to coordinate recovery across several layers.
そのうえ、適切な回収機構コーディネート(例えば、下に成立するタイマを使用するときの予定されたコーディネート)がないとき、失敗通知は回復階層構造の中で1つの層から次の1つまで伝播されるかもしれません。 これは、「衝突」を引き起こして、競合条件につながるかもしれない同時の回復動作の引き金となって、順番にリソース利用の最適化を抑える、そして/または、ネットワークで世界的な不安定を発生させることができます([マンチェスター]を見てください)。 したがって、一貫して効率的な増大戦略が、数個の層の向こう側に回復を調整するのに必要です。
One can expect that the definition of the recovery mechanisms and protocol(s) is technology-independent so that they can be consistently implemented at different layers; this would in turn simplify their global coordination. Moreover, as mentioned in [RFC3386], some looser form of coordination and communication between (vertical) layers such as a consistent hold-off timer configuration (and setup through signaling during the working LSP establishment) can be considered, thereby allowing the synchronization between recovery actions performed across these layers.
人は、回収機構とプロトコルの定義が異なった層で一貫してそれらを実行できるように技術から独立していると予想できます。 これは順番に彼らのグローバルなコーディネートを簡素化するでしょう。 そのうえ、一貫した下に成立するタイマ構成(そして、働くLSP設立の間、合図するのによるセットアップ)などの(垂直)の層の[RFC3386]で言及されるような何らかのよりゆるいフォームに関するコーディネートとコミュニケーションを考えることができます、その結果、これらの層の向こう側に実行された回復動作の間の同期を許容します。
7.2.1. Recovery Granularity
7.2.1. 回復粒状
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制御飛行機は彼らの粒状の如何にかかわらずパケットLSPsの個々のパケットLSPsかグループを回収できます。 ネットワークが同じ粒状(そして、その結果、光学で、レベルを向けない)で切り替わる装置を含んでいるときだけ、反対側の上では、サブ波長レベル(すなわち、Sonet/SDH)における回復粒状を提供できます。 そして、したがって、ネットワーク層が1LSPあたり1個のベースで運転された制御飛行機回収機構を届けることができる、これらのLSPsが輸送機レベルで彼らの対応する切り換え粒状を支持させる場合にだけ。
7.3. Escalation Strategies
7.3. 増大戦略
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
ボトムアップ・アプローチは、下層回復タイプと計画が上側の層より好都合で速いさらに多くのものであると仮定します。 したがって、私たちは、より高い層の回復を抑制するか、または食い止めることができます。 しかしながら、この仮定は完全に本当ではありません。 OTN回復メカニズム(200未満msの回復時間がある)の上に横たわって、例えばSonet/SDHのベースの保護メカニズム(50未満msの保護切換え時間がある)を考えてください。 したがって、これ
Papadimitriou & Mannie Informational [Page 30] RFC 4428 GMPLS Recovery Mechanisms March 2006
2006年の[30ページ]RFC4428GMPLS回収機構行進の情報のPapadimitriouとマニー
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.
仮定は以下として(少なくとも)はっきりさせられるべきです。 下層回収機構が上側のレベル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つの隣接している層のそばで周期的な状態アップデートと共有されたと示唆します。 そのうえ、これらの回復動作のいくつかをある層にあらかじめ割り当てることができます(1リンクあたり1個のベースで)、例えば、別のものが光学層で回復されている間、与えられたリンクはパケット層で回収されるでしょう。
7.4. Disjointness
7.4. Disjointness
Having link and node diverse working and recovery LSPs/spans does not guarantee their complete disjointness. Due to the common physical layer topology (passive), additional hierarchical concepts, such as the Shared Risk Link Group (SRLG), and mechanisms, such as SRLG diverse path computation, must be developed to provide complete working and recovery LSP/span disjointness (see [IPO-IMP] and
リンク、ノードのさまざまの運用、および回復のLSPs/長さを持っているのはそれらの完全なばらばらになるのを保証しません。 そして完全な運用と回復のLSP/長さばらばらになるのを提供するために一般的な物理的な層のトポロジー(受け身の)、Shared Risk Link Groupなどの追加階層的な概念(SRLG)、およびSRLGのさまざまの経路計算などのメカニズムを開発しなければならない、([IPO-IMP]を見てください。
Papadimitriou & Mannie Informational [Page 31] RFC 4428 GMPLS Recovery Mechanisms March 2006
2006年の[31ページ]RFC4428GMPLS回収機構行進の情報のPapadimitriouとマニー
[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/長さに影響するでしょう。 人は「一般的な失敗」のような出来事について言及します。
7.4.1. SRLG Disjointness
7.4.1. SRLG Disjointness
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.
Shared Risk Link Group(SRLG)は一般的な危険(ファイバーリンクかファイバーケーブルなどの一般的な物理資源などの)を共有するリンクのセットと定義されます。 例えば、1セットのリンクLは同じSRLG sに属します、彼らが同じファイバーリンクfの上に食糧を供給されるなら。
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) そして、リンクが1SRLGに属す、それぞれのそれらでカバーされたリソースの1つに交差している場合にだけ。
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はこのLSPを構成する個々のリンクの個々のSRLG sの組合と定義されます。
SRLG disjointness is also applicable to LSPs:
また、SRLG disjointnessもLSPsに適切です:
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 disjointness概念は以下の公理に基づいています: そして、LSP(すなわち、リンクとノードの系列)がSRLGを覆っている、そのSRLGに属すリンクかノードの1つに交差している場合にだけ。
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.
したがって、SRLG disjointness、LSPsのために、以下の通り定義できます: そして、2LSPsがそう、SRLG sに関してばらばらになってください、彼らが同時にこの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.
aに関するLSPsのためのSRLG disjointnessはSRLGsのSを設定して、以下の通り定義されますが: そして、2LSPsがそう、SRLGs Sの1セットに関してばらばらになってください、両方のLSPsに共通の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 disjointnessは、ネットワークの生存性を確実にするためには必要で(a十分でない)の状態です。 物理ネットワークリソースに関して、働く回復のLSP/長さ組はひたむきな回復タイプの場合にSRLGばらばらになっていなければなりません。 他方では、共有された回復の場合に働くLSP/長さのグループは(単一で一般的)の共有された回復のためにそれぞれの働くLSPs/長さからSRLGそれ自体でばらばらになっているLSPを許容するために互いにSRLGばらばらになることであるに違いありません。
Papadimitriou & Mannie Informational [Page 32] RFC 4428 GMPLS Recovery Mechanisms March 2006
2006年の[32ページ]RFC4428GMPLS回収機構行進の情報のPapadimitriouとマニー
8. Recovery Mechanisms Analysis
8. 回収機構分析
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. 効率(スケーラビリティ): 回収されるLSPs/長さの数の如何にかかわらず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. リソース最適化(最適): 回復目的に必要であるLSPs/長さとノード(切り換え容量)を含むリソース容量を最小にしてください。 また、回復リソースの共有度合いを最適化するとこの寸法を呼ぶことができます。
5. Cost optimization: provide a cost-effective recovery type/scheme.
5. 最適化かかってください: 費用対効果に優れた回復タイプ/計画を提供してください。
However, these dimensions are either outside the scope of this document (such as cost optimization and recovery path computational aspects) or mutually conflicting. For instance, it is obvious that providing a 1+1 LSP protection minimizes the LSP downtime (in case of failure) while being non-scalable and consuming recovery resource without enabling any extra-traffic.
しかしながら、これらの寸法は、このドキュメント(費用最適化や回復経路計算的側面などの)の範囲の外のどちらかにあるか、または互いに闘争しています。 例えば、1+1LSP保護を提供すると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シグナリングとルーティング拡大の潜在的必要性の評価を許します。
Papadimitriou & Mannie Informational [Page 33] RFC 4428 GMPLS Recovery Mechanisms March 2006
2006年の[33ページ]RFC4428GMPLS回収機構行進の情報のPapadimitriouとマニー
8.1. Fast Convergence (Detection/Correlation and Hold-off Time)
8.1. 速い集合(検出/相関関係と下に成立する時間)
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で詳細です。
8.2. Efficiency (Recovery Switching Time)
8.2. 効率(回復切換え時間)
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設立の間のどんな潜在的crankbackの除去のためにも。
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つがcrankback問題を除くなら、ダイナミックであらかじめ計画された回復の違いは回復経路計算と選択時間に依存します。 このドキュメントの範囲の外にコンピュータの問題があるので、ダイナミックな回復があらかじめ計画された計画の上で有利であるか否かに関係なく、異なったシナリオとオペレータへの平均して最大の経路計算時間が決めると決心している業者まで、ネットワーク環境に依存してください。 また、この違いはあらかじめ計画された回復でダイナミックな回復に対して提供された柔軟性に依存します。 あらかじめ計画された回復はいくらか限られた数の失敗シナリオを含意します(例えば、それは地方の記憶容量制限のためであることができます)。 ダイナミックな回復は失敗通知メッセージを通して受け取られた情報に基づく要求次第の経路計算を可能にします、そして、そういうものとして、それは失敗シナリオ範囲に関して、より強健です。
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
Sonet/SDH保護の切り換え(失敗を検出する時間を含んでいない)のための目標復旧時間は50msの[G.841]で指定されます、距離で規制を考慮に入れて、ポートの数
Papadimitriou & Mannie Informational [Page 34] RFC 4428 GMPLS Recovery Mechanisms March 2006
2006年の[34ページ]RFC4428GMPLS回収機構行進の情報のPapadimitriouとマニー
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].
保護、リングでのノードの数にかかわって、リングに関するケース高めました。 別々の努力[RFC3386]で回復メカニズムのための目標復旧時間は提案されました。
8.3. Robustness
8.3. 丈夫さ
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/長さに、回復タイプが、より強健であるか、またはさまざまなただ一つの失敗には計画があります、適切なリソースが利用可能であれば。 そのうえ、回復リソースの前選択は回復リソース前選択がないより少ない柔軟性を与えます(複数の失敗シナリオの場合で)。 例えば、彼らの回復経路に沿って普通リンクを共有する2LSPsに影響する失敗が起こるなら、これらのLSPsの1つしか回復できません。 少なくともこれらのLSPsの1つの回復経路が再計算されるか、またはローカル資源課題が急いで変更されない場合、これは起こります。
In addition, recovery types and schemes with pre-planned recovery resources (in particular, LSP/spans for protection and LSPs for restoration purposes) will not be able to recover from failures that simultaneously affect both the working and recovery LSP/span. Thus, the recovery resources should ideally be as disjoint as possible (with respect to link, node, and SRLG) from the working ones, so that any single failure event will not affect both working and recovery LSP/span. In brief, working and recovery resources must be fully diverse in order to guarantee that a given failure will not affect simultaneously the working and the recovery LSP/span. Also, the risk of simultaneous failure of the working and the recovery LSPs can be reduced. It is reduced by computing a new recovery path whenever a failure occurs along one of the recovery LSPs or by computing a new recovery path and provision the corresponding LSP whenever a failure occurs along a working LSP/span. Both methods enable the network to maintain the number of available recovery path constant.
さらに、リソース(保護のための特にLSP/長さと回復目的のためのLSPs)がそんなに同時に失敗から回復できないあらかじめ計画された回復に伴う回復タイプと計画は働きと回復のLSP/長さの両方に影響します。 したがって、回復リソースが働くものから可能な状態で(リンク、ノード、およびSRLGに関する)ばらばらになるように理想的にそうあるべきです、どんな単一の失敗出来事も働きと回復のLSP/長さの両方に影響しないように。 要するに、運用と回復リソースは、与えられた失敗が同時に働きと回復のLSP/長さに影響しないのを保証するために完全に多様でなければなりません。 また、働きの同時の失敗と回復LSPsの危険は減少できます。 それは、働くLSP/長さに沿って起こるときはいつも、失敗が回復LSPsか新しい回復経路と支給を計算するのによる対応するLSPの1つに沿って起こるときはいつも、新しい回復経路を計算することによって、減少します。 両方の方法は、ネットワークが利用可能な回復経路の数を一定に維持するのを可能にします。
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の故障などのようにも
Papadimitriou & Mannie Informational [Page 35] RFC 4428 GMPLS Recovery Mechanisms March 2006
2006年の[35ページ]RFC4428GMPLS回収機構行進の情報のPapadimitriouとマニー
8.4. Resource Optimization
8.4. リソース最適化
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+1LSP/長さ保護は最も多くのリソースを消費する保護タイプです。
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) M: 1:NとNのLSP/長さ回復が1を必要とする、(そして、M、それぞれ)、余分な交通を考慮する回復のLSP/長さ(N働くLSP/長さを平等に割り当てます)。
Obviously, 1+1 protection precludes, and 1:1 recovery does not allow for any recovery LSP/span sharing, whereas 1:N and M:N recovery do allow sharing of 1 (M, respectively) recovery LSP/spans between N working LSP/spans. However, despite the fact that 1:1 LSP recovery precludes the sharing of the recovery LSP, the recovery schemes that can be built from it (e.g., (1:1)^n, see Section 5.4) do allow sharing of its recovery resources. In addition, the flexibility in the usage of shared recovery resources (in particular, shared links) may be limited because of network topology restrictions, e.g., fixed ring topology for traditional enhanced protection schemes.
1:1回復で、1+1保護は排除して、M: 1:NとN回復は共有してくださいというのではなく、あらゆる回復のLSP/長さ共有のためにN働くLSP/長さの間の1つ(それぞれM)の回復のLSP/長さは明らかに共有させてください。 しかしながら、1:1LSP回復が回復LSPの共有を排除するという事実にもかかわらず、それ(^n、例えば(1:1)、セクション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/長さ回復目的のために遂行されていないとき、preemptible交通(その結果preemptible LSP/長さの上)を運ぶのに予備リソースを使用できます。
From this, it clearly follows that less recovery resources (i.e., LSP/spans and switching capacity) have to be allocated to a shared
これから、より少ない回復リソース(すなわち、LSP/長さと切り換え容量)が共有されたaに割り当てられなければならないと明確にいうことになります。
Papadimitriou & Mannie Informational [Page 36] RFC 4428 GMPLS Recovery Mechanisms March 2006
2006年の[36ページ]RFC4428GMPLS回収機構行進の情報のPapadimitriouとマニー
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.
回復リソースプールは、より大きい共有度であるなら許容されています。 したがって、共有された回復リソースの量を定義する方針とこれらの回復リソースのために許容された最大の共有度に従って、ネットワーク生存性レベルは決定しています。
8.4.1. Recovery Resource Sharing
8.4.1. 回復リソース・シェアリング
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/長さにわたって共有されるとき、Maximum Reservable Bandwidth、Unreserved Bandwidth、およびMaximum LSP Bandwidth([RFC4202]を見る)の使用は共有された回復目的のために割り当てられたネットワーク資源の最適化を得るのに必要である情報を提供します。
The Maximum Reservable Bandwidth is defined as the Maximum Link Bandwidth but it may be greater in case of link over-subscription.
Maximum Reservable BandwidthはMaximum Link Bandwidthと定義されますが、それはリンク過剰購読の場合によりすばらしいかもしれません。
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.
Unreserved Bandwidth(優先権pにおける)は与えられたTEリンクの上にまだ控えられていなかった帯域幅と定義されます(各優先権pのための初期の値はMaximum Reservable Bandwidthに対応しています)。 最後に、Maximum LSP Bandwidth(優先権pにおける)はUnreserved Bandwidth(優先権pにおける)とMaximum Link Bandwidthで、より小さく定義されます。
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.
一般に、ここで、人は、回復リソース・シェアリング度合い(または、比率)が共有された回復リソース用法をグローバルに最適化すると考えます。 1優先権あたりの帯域幅プレ配分からTEリンクあたりの帯域幅利用の分配を推論できます。 Maximum LSP BandwidthとMaximum Reservable Bandwidthを使用することによって、共有された回復目的に使用できる(食糧を供給され過ぎる)のリソースの量は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).
この振舞いを分析するために、私たちはMaximum Reservable Bandwidth(この場合は、この値はMaximum Link Bandwidthより大きい)とTEリンクiあたりのMaximum LSP Bandwidthの違いをMaximum Shareable Bandwidthか最大_R[i]と定義します。 この量の中では、現在TEリンクiあたりの共有された回復のために割り当てられている帯域幅の量はR[i]と定義されます。 両方の量は離散的な帯域幅ユニットで表されます(その結果、Minimum LSP Bandwidthは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リンクあたり利用可能なこの情報に関する知識を利用できます。 人が共有された回復のために遂行されたTEリンクi(離散的な帯域幅ユニットに関する)あたりの実際の帯域幅としてのr[i]について言及するなら、潜在的TEリンク候補の上で以下の量を最大にしなければなりません:
sum {i=1}^N [(R{i} - r{i})/(t{i} - b{i})]
i=1をまとめてください、^N[(R i--r i)/(t i--b i)]
Papadimitriou & Mannie Informational [Page 37] RFC 4428 GMPLS Recovery Mechanisms March 2006
2006年の[37ページ]RFC4428GMPLS回収機構行進の情報のPapadimitriouとマニー
or equivalently: sum {i=1}^N [(R{i} - r{i})/r{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はt[i]の与えられたLSP、TEリンクiあたりのMaximum Link Bandwidth、帯域幅のTEリンクiあたりの合計が働くLSPsのために遂行したb[i]、および他の回復LSPs(その結果「共有された帯域幅」LSPsを除いて)によって横断されたリンクの総数です。 量[(R i--r i)/r i]はTEリンクiあたりのShared(回復)帯域幅Ratioと定義されます。 さらに、R[i]が最大_R[i]に達するか、またはr[i]=0がどの最大_R[i]のためにTEリンクと同様に共有された回復経路計算の間に剪定されるTEリンクは絶対に共有できない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
- ---------- マックスReservable Bandwidth| ----- ^ |R----- | | ----- | - ----- |最大_R----- | -------- TEがCapacityをリンクする、------- | - 最大のTeリンク帯域幅----- |r----- v----- <、-、-、-、-、-- b------>、----------- 最大のLSP帯域幅----- ----- ----- ----- ----- ----- ----- ----- ----- ----- <-- 最小のLSP帯域幅-------- 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
上のアプローチがいずれのLSP情報あたりの氾濫か帯域幅配分のどんなコンポーネントリンクあたりの詳細な分配、個々のポートまたはいずれさえも必要としないことに注意してください、-、優先権共有可能回復帯域幅情報(専用サブTLVを使用します)。 後者は1優先権あたりの既に定義されたMaximum LSP帯域幅情報と同じ能力を提供するでしょう。 このアプローチは[KODIALAM1]と[KODIALAM2]で説明されるようにPartial(または、Aggregated)情報ルート設定と呼ばれます。 彼らは、Full(または、Complete)情報ルート設定アプローチ(働きと回復LSPsの全体集合において、それらが使用する帯域幅ユニットの量が各ノードにおいて各リンクにリンク単位で知られているところ)で得られた違いが明確に取るにたらないのを示します。 完全情報ルート設定
Papadimitriou & Mannie Informational [Page 38] RFC 4428 GMPLS Recovery Mechanisms March 2006
2006年の[38ページ]RFC4428GMPLS回収機構行進の情報のPapadimitriouとマニー
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.
アプローチは[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シグナリング能力を広げていると、Partial情報ルート設定アプローチを機能アップできます。 働くLSP関連の情報とその特に経路(リンクとノード識別子を含んでいる)がLSPが要求する回復で交換されるのを許容することによって、それは高められます。 これは共有された回復リソース、および特にリンクの上流のノードで、より効率的な入場コントロールを可能にします(セクション8.4.3を見てください)。
8.4.2. Recovery Resource Sharing and SRLG Recovery
8.4.2. 回復リソース・シェアリングとSRLG回復
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.
また、回復リソース(特に共有されたTEリンク)によって各SRLGが保護されるという回の数に関してリソースshareabilityを最大にすることができます、そして、ただ一つのSRLGの故障の場合に共有された回復リソースの主張を避けるために方法を考えることができます。 彼らのそれぞれの働くLSPsが互いにそうなら、これらの方法は2(さらに)回復LSPsの間の回復リソースの共有を可能にして、リンク、ノード、およびSRLGsに関してばらばらになってください。 そして、ただ一つの失敗は同時に、数個の(または、少なくとも2)働くLSPsを混乱させません。
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が回復可能であるという回の数)に関して回復リソースshareabilityを覆うためにPartial情報ルート設定進入路を広げることができるのを示します。 このTEリンクあたりの集められた情報をあふれさせることによって、それぞれのTEリンクの上に予約された回復リソースの共有に関してSRLGさまざまの回復LSPsの経路計算と品揃えを最適化できます。 これは5%未満の性能差をもたらします([GLI]を見てください)。(対応するFull情報Floodingアプローチと比べて、%は取るにたらないです)。
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
このために、共有されたメッシュ回復のための経路計算を支持した[RFC4202]への追加拡大は文学でしばしば考えられました。 TEリンク属性は特に回復リソースがTEリンクの上に予約した回復LSPs共有の最新号を含んでいるでしょう、そして、TEで予約されたこの量の(共有される)の回復リソースで回復可能なSRLGsの最新号はリンクされます。 後者は回復リソースがTEリンクの上に予約した回復LSPs共有で回収されるSRLGsの最新号に同等です。 そして、明白なSRLG修復性が考えられるなら、SRLGs(TEリンクの上に予約された共有された回復リソースで回復可能な)の明白なリストと彼らのそれぞれの共有可能回復帯域幅を含んでいるTEリンク属性は加えられるでしょう。 後者の情報がSRLG(またはSRLGsのグループ単位で)あたりの共有可能回復帯域幅に同等である、どれ、含意
Papadimitriou & Mannie Informational [Page 39] RFC 4428 GMPLS Recovery Mechanisms March 2006
2006年の[39ページ]RFC4428GMPLS回収機構行進の情報のPapadimitriouとマニー
that the amount of shareable bandwidth and the number of listed SRLGs will decrease over time.
共有可能帯域幅の量と記載された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.
回復リソース・シェアリングだけに関するケースと比べて(SRLG修復性にかかわらずセクション8.4.1で説明されるように)、これらの追加TEリンク属性は潜在的に、共有されたメッシュ回復目的のための、より良い経路計算と選択(異なったイングレスノードの)を提供するでしょう。 しかしながら、より良い効率の証拠不十分のためとそのような拡大が発生させる複雑さのため、それらは現在の分析の範囲でさらに考えられません。 例えば、1SRLGあたりのグループ最小限/最大共有可能回復帯域幅が長さによって制限される、それ、対応、(サブ、)、TLVは撮影とその結果、それが含むことができるSRLGsの数がそうするかもしれません。 したがって、TEリンクサブTLVの形でGMPLSルーティング(合図さえして)プロトコル拡大に対応するパラメタを翻訳するべきではありません。
8.4.3. Recovery Resource Sharing, SRLG Disjointness and Admission
Control
8.4.3. 回復リソース・シェアリング、SRLG Disjointness、および入場コントロール
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
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(C D)に働くLSPを作成して、Bは同時に、Dへの働くLSP(B C D)と同じ目的地への回復LSP(B電子FのD)を作成します。 次に、Aが、D(A電子FのD)にa回復LSPを作成すると決めますが、C-Dの長さがともにLSPsを扱いながら運ばれるので、C-Dの長さが既に最大の回復帯域幅共有比に達したなら、ノードEは、この回復LSPに、ひたむきなリソースを割り当てるはずであるか、またはこの要求を拒絶するはずです。 後者の場合では、C-D長さの故障は、働くLSPの1つが回復可能でないことを含意するでしょう。
Consequently, node E must have the required information to perform admission control for the recovery LSP requests it processes (implying for instance, that the path followed by the working LSP is carried with the corresponding recovery LSP request). If node E can guarantee that the working LSPs (A-C-D and B-C-D) are SRLG disjoint over the C-D span, it may securely accept the incoming recovery LSP request and assign to the recovery LSPs (A-E-F-D and B-E-F-D) the
その結果、ノードEには、それが処理する回復LSP要求のための入場コントロールを実行する必須情報がなければなりません(例えば、含意して、経路が働くLSPで続いたのはLSPが要求する対応する回復で運ばれます)。 ノードEが、働くLSPs(A C DとB C D)がSRLGであることを保証できるなら、C-Dの長さの上ばらばらになってください、そして、しっかりとLSPが要求する入って来る回復を受け入れるかもしれなくて、LSPsを回復に割り当ててください(電子FのDとB電子FのD)。
Papadimitriou & Mannie Informational [Page 40] RFC 4428 GMPLS Recovery Mechanisms March 2006
2006年の[40ページ]RFC4428GMPLS回収機構行進の情報のPapadimitriouとマニー
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-Fをリンクしてください。 E-Fにはあるリンクがまだ最大の回復帯域幅共有比に達していなかったなら、これは起こるかもしれません。 この例では、人は、リンク故障確率と比べて、ノード故障確率が取るにたらないと仮定します。
To achieve this, the path followed by the working LSP is transported with the recovery LSP request and examined at each upstream node of potentially shareable links. Admission control is performed using the interface identifiers (included in the path) to retrieve in the TE DataBase the list of SRLG IDs associated to each of the working LSP links. If the working LSPs (A-C-D and B-C-D) have one or more link or SRLG ID in common (in this example, one or more SRLG id in common over the span C-D), node E should not assign the same resource over link E-F to the recovery LSPs (A-E-F-D and B-E-F-D). Otherwise, one of these working LSPs would not be recoverable if C-D span failure occurred.
働くLSPによって続かれた経路は、これを達成するために、LSPが要求する回復で輸送されて、潜在的に共有可能リンクのそれぞれの上流のノードで調べられます。 入場コントロールは、TE DataBaseでそれぞれの働くLSPリンクに関連づけられたSRLG IDのリストを検索するのに、インタフェース識別子(経路では、含まれている)を使用することで実行されます。 働くLSPs(A C DとB C D)が1リンクかSRLG IDが共通である、(この例、長さの上一般的の1つ以上のSRLGイド、C-D)、ノードEは回復LSPs(電子FのDとB電子FのD)へのE-Fをリンクの上の同じリソースに割り当てるはずがありません。 さもなければ、C-D長さの故障が起こるなら、これらの働くLSPsの1つは回復可能でないでしょうに。
There are some issues related to this method; the major one is the number of SRLG IDs that a single link can cover (more than 100, in complex environments). Moreover, when using link bundles, this approach may generate the rejection of some recovery LSP requests. This occurs when the SRLG sub-TLV corresponding to a link bundle includes the union of the SRLG id list of all the component links belonging to this bundle (see [RFC4202] and [RFC4201]).
この方法に関連するいくつかの問題があります。 主要なものは単一のリンクがカバーできるSRLG ID(複雑な環境において100以上)の数です。 リンクバンドルを使用するとき、そのうえ、このアプローチはいくつかの回復LSP要求の拒絶を発生させるかもしれません。 リンクバンドルに対応するSRLGサブTLVがこのバンドルに属すすべてのコンポーネントリンクのSRLGイドリストの組合を含んでいると([RFC4202]と[RFC4201]を見てください)、これは起こります。
In order to overcome this specific issue, an additional mechanism may consist of querying the nodes where the information would be available (in this case, node E would query C). The main drawback of this method is that (in addition to the dedicated mechanism(s) it requires) it may become complex when several common nodes are traversed by the working LSPs. Therefore, when using link bundles, solving this issue is closely related to the sequence of the recovery operations. Per-component flooding of SRLG identifiers would deeply impact the scalability of the link state routing protocol. Therefore, one may rely on the usage of an on-line accessible network management system.
この特定の問題に打ち勝つために、追加メカニズムは情報が利用可能である(この場合、ノードEはCについて質問するでしょう)ノードについて質問するのから成るかもしれません。 この方法の主な欠点はいくつかの一般的なノードが働くLSPsによって横断されるとき、複雑になるかもしれないということです。 したがって、リンクバンドルを使用するとき、この問題を解決するのは密接に回復動作の系列に関連します。 SRLG識別子の1コンポーネントあたりの氾濫は深くリンク州のルーティング・プロトコルのスケーラビリティに影響を与えるでしょう。 したがって、オンラインアクセスしやすいネットワーク管理システムの使用法を当てにするかもしれません。
Papadimitriou & Mannie Informational [Page 41] RFC 4428 GMPLS Recovery Mechanisms March 2006
2006年の[41ページ]RFC4428GMPLS回収機構行進の情報のPapadimitriouとマニー
9. Summary and Conclusions
9. 概要と結論
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 |
--------------------------------------------------------------------
-------------------------------------------------------------------- | 経路検索(計算と選択)-------------------------------------------------------------------- | 計画されるプレ(a)| 動力(b)-------------------------------------------------------------------- | | より速い回復| 適用しません。| | それほどフレキシブルでない| | 1 | それほど強健でない| | | リソースを最も消費しています。| 経路| | | セットアップ------------------------------------------------------------ | | 比較的速い回復| 適用しません。| | 比較的フレキシブルです。| | 2 | 比較的強健です。| | | リソース消費| | | 度を共有するのによります。| ------------------------------------------------------------ | | 比較的速い回復| より少ないより速い(計算)| | よりフレキシブル| 最もフレキシブル| 3 | 比較的強健です。| 最も強健| | より少ないリソース消費| リソースを最も消費していません。| | 度を共有するのによります。| --------------------------------------------------------------------
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.
2a。 資源予約(すなわち、シグナリング)とリソース前選択による回復LSPセットアップ(失敗発生の前の)はリソースプレ選択でコースを変更するあらかじめ計画されたLSPと呼ばれます。 これは失敗発生の後に回復LSP起動だけを含意します。
3a. Recovery LSP setup (before failure occurrence) with resource
reservation (i.e., signaling) and without resource selection is
referred to as pre-planned LSP re-routing without resource pre-
selection. This implies recovery LSP activation and resource
(i.e., label) selection after failure occurrence.
3a。 資源予約(すなわち、シグナリング)とリソース選択のない回復LSPセットアップ(失敗発生の前の)はリソースプレ選択なしでコースを変更するあらかじめ計画されたLSPと呼ばれます。 これは失敗発生の後に回復LSP起動とリソース(すなわち、ラベル)選択を含意します。
3b. Recovery LSP setup after failure occurrence is referred to as to
as LSP re-routing, which is full when recovery LSP path
computation occurs after failure occurrence.
3b。 失敗発生がLSPとしてコースを変更するのに関して言及された後に回復LSPセットアップ。(回復LSP経路計算が失敗発生の後に起こるとき、そのセットアップは完全です)。
Papadimitriou & Mannie Informational [Page 42] RFC 4428 GMPLS Recovery Mechanisms March 2006
2006年の[42ページ]RFC4428GMPLS回収機構行進の情報のPapadimitriouとマニー
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経路プレ計算、シグナリング(予約)、および先験的なリソース選択(任意の)について言及します。 また、2a)と3a)の特定のケースとして共有されたメッシュ回復計画を見なすことができます、セクション8.4.3で説明された追加規制を使用して。
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シグナリング拡張子は(2) (1) ケースのために1a、2a、および3aにあらかじめ食糧を供給する回復LSP、LSP失敗通知、(3)回復LSP開閉動作、および(4)逆戻りメカニズムを届ける際に主に集中するべきです。
Moreover, the present analysis (see Section 8) shows that no GMPLS routing extensions are expected to efficiently implement any of these recovery types and schemes.
そのうえ、現在の分析(セクション8を見る)は、GMPLSルーティング拡張子が全く効率的にこれらの回復タイプと計画のどれかを実行すると予想されないのを示します。
10. Security Considerations
10. セキュリティ問題
This document does not introduce any additional security issue or imply any specific security consideration from [RFC3945] to the current RSVP-TE GMPLS signaling, routing protocols (OSPF-TE, IS-IS- TE) or network management protocols.
このドキュメントは、[RFC3945]から現在のRSVP-TE GMPLSシグナリングまでどんな追加担保問題も紹介もしませんし、少しの特定の警備上の配慮も含意もしません、ルーティング・プロトコル、(OSPF-TE、-、-、TE) または、ネットワーク管理プロトコル。
However, the authorization of requests for resources by GMPLS-capable nodes should determine whether a given party, presumably already authenticated, has a right to access the requested resources. This determination is typically a matter of local policy control, for example, by setting limits on the total bandwidth made available to some party in the presence of resource contention. Such policies may become quite complex as the number of users, types of resources, and sophistication of authorization rules increases. This is particularly the case for recovery schemes that assume pre-planned sharing of recovery resources, or contention for resources in case of dynamic re-routing.
しかしながら、GMPLSできるノードによるリソースに関する要求の認可は、与えられたおそらく、既に認証されたパーティーには要求されたリソースにアクセスする権利があるかどうか決定するべきです。 通常、この決断は例えばリソース主張があるときいくつかのパーティーに利用可能にされた総帯域幅で制限を加えるのによる地方の方針コントロールの問題です。 ユーザの数、リソースのタイプ、および認可規則に関する洗練が増えるのに応じて、そのような方針はかなり複雑になるかもしれません。 これは特にダイナミックなコースを変更することの場合に回復リソースのあらかじめ計画された共有、またはリソースのための主張を仮定する回復計画のためのそうです。
Therefore, control elements should match the requests against the local authorization policy. These control elements must be capable of making decisions based on the identity of the requester, as verified cryptographically and/or topologically.
したがって、制御要素はローカルの認可方針に対して要求に合っているはずです。 これらの制御要素はリクエスタのアイデンティティに基づく決定をすることができなければなりません、暗号で位相的に確かめられるように。
11. Acknowledgements
11. 承認
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.
彼らの改正の努力についてファブリシュ・ポッペ(アルカテル)とバード・ルソー(アルカテル)に感謝します、そして、作者は、彼らの役に立つコメントのために、リチャードRabbat(富士通Labs)、デヴィッド・グリフィス(NIST)とリンドン・オング(Ciena)に感謝したいです。
Papadimitriou & Mannie Informational [Page 43] RFC 4428 GMPLS Recovery Mechanisms March 2006
2006年の[43ページ]RFC4428GMPLS回収機構行進の情報のPapadimitriouとマニー
Thanks also to Adrian Farrel for the thorough review of the document.
また、ドキュメントの徹底的なレビューをエードリアン・ファレルをありがとうございます。
12. References
12. 参照
12.1. Normative References
12.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[RFC3471] バーガー、L.、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)のシグナリングの機能的な記述」、RFC3471、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)拡大」、RFC3473、2003年1月。
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945] マニー、E.、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)構造」、RFC3945、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)におけるリンクバンドリング」、RFC4201、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.、エドY.Rekhter、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)を支持して拡大を発送すること」でのRFC4202(2005年10月)。
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC
4204, October 2005.
[RFC4204] ラング、J.、エド、「リンク管理プロトコル(LMP)」、RFC4204、10月2005日
[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.ラング、「濃い波長事業部のためのリンク管理プロトコル(LMP)は(DWDM)光学回線システムを多重送信すること」でのRFC4209(2005年10月)。
[RFC4427] Mannie E., Ed. and D. Papadimitriou, Ed., "Recovery
(Protection and Restoration) Terminology for Generalized
Multi-Protocol Label Switching (GMPLS)", RFC 4427, March
2006.
エド[RFC4427]マニーE.、エドD.Papadimitriou、「一般化されたマルチプロトコルラベルのための回復(保護と王政復古)用語は(GMPLS)を切り換えること」でのRFC4427(2006年3月)。
12.2. Informative References
12.2. 有益な参照
[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、他、「共有されたメシェドを計算する推計的なアプローチは光学ネットワークアーキテクチャでLightpathsを返した」IEEE Infocom2002、ニューヨーク市(2002年6月)。
Papadimitriou & Mannie Informational [Page 44] RFC 4428 GMPLS Recovery Mechanisms March 2006
2006年の[44ページ]RFC4428GMPLS回収機構行進の情報のPapadimitriouとマニー
[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 Communications Magazine、Vol.37、No.8、ページ 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 Infocom2002、ニューヨーク市(2002年6月)。
[IPO-IMP] Strand, J. and A. Chiu, "Impairments and Other
Constraints on Optical Layer Routing", RFC 4054, May
2005.
[IPO-悪童]のストランド、J.、およびA.チウ、「光の層のルート設定の損傷と他の規制」(RFC4054)は2005がそうするかもしれません。
[KODIALAM1] M. Kodialam and T.V. Lakshman, "Restorable Dynamic
Quality of Service Routing," IEEE Communications
Magazine, pp. 72-81, June 2002.
[KODIALAM1]M.KodialamとT.V.Lakshman、「復元できるダイナミックなサービスの質ルート設定」、IEEE Communications Magazine、ページ 72-81と、2002年6月。
[KODIALAM2] M. Kodialam and T.V. Lakshman, "Dynamic Routing of
Restorable Bandwidth-Guaranteed Tunnels using Aggregated
Network Resource Usage Information," IEEE/ ACM
Transactions on Networking, pp. 399-410, June 2003.
[KODIALAM2]M.KodialamとT.V.Lakshman、「復元できる帯域幅で保証されたTunnelsの使用のダイナミックルーティングはネットワーク資源用法情報に集めました」、Networkingの上のIEEE/ ACM Transactions、ページ 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が「階層構造と多層の生存性をネットワークでつなぐ」、RFC3386、11月2002日
[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.
[ワング]のJ.ワング、L.Sahasrabuddhe、およびB.ムーカジ、「経路対SubpathはIP過剰WDMの障害管理のためのリンク王政復古に対して以下をネットワークでつなぎます」。 「パフォーマンスComparisons Using GMPLS Control Signaling」、IEEE Communications Magazine、ページ 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)」、Recommendation G.709、2001年2月(そして、Amendment no.1、2001年10月)。
Papadimitriou & Mannie Informational [Page 45] RFC 4428 GMPLS Recovery Mechanisms March 2006
2006年の[45ページ]RFC4428GMPLS回収機構行進の情報のPapadimitriouとマニー
[G.783] ITU-T, "Characteristics of Synchronous Digital Hierarchy
(SDH) Equipment Functional Blocks," Recommendation
G.783, October 2000.
[G.783]ITU-T、「同期デジタルハイアラーキ(SDH)設備機能ブロックの特性」、推薦G.783、2000年10月。
[G.798] ITU-T, "Characteristics of optical transport network
hierarchy equipment functional block," Recommendation
G.798, June 2004.
[G.798]ITU-T、「光学転送ネットワーク階層構造設備機能ブロックの特性」、Recommendation 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、10月2000日
[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ネットワーク保護構造を織り込む」Recommendation 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、「光学転送ネットワーク要素の管理局面」、Recommendation G.874、2001年11月。
Editors' Addresses
エディタのアドレス
Dimitri Papadimitriou Alcatel Francis Wellesplein, 1 B-2018 Antwerpen, Belgium
ディミトリPapadimitriouアルカテルフランシスWellesplein、1B-2018のアントウェルペン(ベルギー)
Phone: +32 3 240-8491 EMail: dimitri.papadimitriou@alcatel.be
以下に電話をしてください。 +32 3 240-8491 メールしてください: dimitri.papadimitriou@alcatel.be
Eric Mannie Perceval Rue Tenbosch, 9 1000 Brussels Belgium
エリックマニーPerceval悔悟Tenbosch、9 1000ブリュッセルベルギー
Phone: +32-2-6409194 EMail: eric.mannie@perceval.net
以下に電話をしてください。 +32-2-6409194はメールされます: eric.mannie@perceval.net
Papadimitriou & Mannie Informational [Page 46] RFC 4428 GMPLS Recovery Mechanisms March 2006
2006年の[46ページ]RFC4428GMPLS回収機構行進の情報のPapadimitriouとマニー
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Papadimitriou & Mannie Informational [Page 47]
PapadimitriouとマニーInformationalです。[47ページ]
一覧
スポンサーリンク
