[要約] RFC 3469は、MPLSベースの回復に関するフレームワークを提供しています。その目的は、ネットワークの障害時に効果的な回復メカニズムを提供することです。
Network Working Group V. Sharma, Ed.
Request for Comments: 3469 Metanoia, Inc.
Category: Informational F. Hellstrand, Ed.
Nortel Networks
February 2003
Framework for Multi-Protocol Label Switching (MPLS)-based Recovery
マルチプロトコルラベルスイッチング（MPLS）ベースの回復のフレームワーク
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 (2003). All Rights Reserved.
Copyright（C）The Internet Society（2003）。全著作権所有。
Abstract
概要
Multi-protocol label switching (MPLS) integrates the label swapping forwarding paradigm with network layer routing. To deliver reliable service, MPLS requires a set of procedures to provide protection of the traffic carried on different paths. This requires that the label switching routers (LSRs) support fault detection, fault notification, and fault recovery mechanisms, and that MPLS signaling support the configuration of recovery. With these objectives in mind, this document specifies a framework for MPLS based recovery. Restart issues are not included in this framework.
マルチプロトコルラベルスイッチング（MPLS）は、ラベルスワッピング転送パラダイムをネットワークレイヤールーティングと統合します。信頼性の高いサービスを提供するために、MPLSでは、さまざまなパスで伝送されるトラフィックを保護するための一連の手順が必要です。これには、ラベルスイッチングルーター（LSR）が障害検出、障害通知、および障害回復メカニズムをサポートし、MPLSシグナリングが回復の構成をサポートする必要があります。これらの目的を念頭に置いて、このドキュメントではMPLSベースのリカバリのフレームワークを指定します。再起動の問題はこのフレームワークには含まれていません。
Table of Contents
目次
1. Introduction................................................2
1.1. Background............................................3
1.2. Motivation for MPLS-Based Recovery....................4
1.3. Objectives/Goals......................................5
2. Overview....................................................6
2.1. Recovery Models.......................................7
2.1.1 Rerouting.....................................7
2.1.2 Protection Switching..........................8
2.2. The Recovery Cycles...................................8
2.2.1 MPLS Recovery Cycle Model.....................8
2.2.2 MPLS Reversion Cycle Model...................10
2.2.3 Dynamic Re-routing Cycle Model...............12
2.2.4 Example Recovery Cycle.......................13
2.3. Definitions and Terminology..........................14
2.3.1 General Recovery Terminology.................14
2.3.2 Failure Terminology..........................17
2.4. Abbreviations........................................18
3. MPLS-based Recovery Principles.............................18
3.1. Configuration of Recovery............................19
3.2. Initiation of Path Setup.............................19
3.3. Initiation of Resource Allocation....................20
3.3.1 Subtypes of Protection Switching.............21
3.4. Scope of Recovery....................................21
3.4.1 Topology.....................................21
3.4.2 Path Mapping.................................24
3.4.3 Bypass Tunnels...............................25
3.4.4 Recovery Granularity.........................25
3.4.5 Recovery Path Resource Use...................26
3.5. Fault Detection......................................26
3.6. Fault Notification...................................27
3.7. Switch-Over Operation................................28
3.7.1 Recovery Trigger.............................28
3.7.2 Recovery Action..............................29
3.8. Post Recovery Operation..............................29
3.8.1 Fixed Protection Counterparts................29
3.8.2 Dynamic Protection Counterparts..............30
3.8.3 Restoration and Notification.................31
3.8.4 Reverting to Preferred Path
(or Controlled Rearrangement)................31
3.9. Performance..........................................32
4. MPLS Recovery Features.....................................32
5. Comparison Criteria........................................33
6. Security Considerations....................................35
7. Intellectual Property Considerations.......................36
8. Acknowledgements...........................................36
9. References.................................................36
9.1 Normative References.................................36
9.2 Informative References...............................37
10. Contributing Authors.......................................37
11. Authors' Addresses.........................................39
12. Full Copyright Statement...................................40
This memo describes a framework for MPLS-based recovery. We provide a detailed taxonomy of recovery terminology, and discuss the motivation for, the objectives of, and the requirements for MPLS-based recovery. We outline principles for MPLS-based recovery, and also provide comparison criteria that may serve as a basis for comparing and evaluating different recovery schemes.
このメモは、MPLSベースの回復のフレームワークについて説明しています。回復用語の詳細な分類を提供し、MPLSベースの回復の動機、目的、要件について説明します。 MPLSベースの回復の原則を概説し、さまざまな回復スキームを比較および評価するための基礎として役立つ比較基準も提供します。
At points in the document, we provide some thoughts about the operation or viability of certain recovery objectives. These should be viewed as the opinions of the authors, and not the consolidated views of the IETF. The document is informational and it is expected that a standards track document will be developed in the future to describe a subset of this document as to meet the needs currently specified by the TE WG.
ドキュメントのいくつかの時点で、特定の復旧目標の運用または実行可能性についての考えを提供します。これらは執筆者の意見であり、IETFの総合的な見解ではありません。このドキュメントは情報提供であり、TE WGによって現在指定されているニーズを満たすために、このドキュメントのサブセットを説明する標準トラックドキュメントが将来開発されることが期待されています。
Network routing deployed today is focused primarily on connectivity, and typically supports only one class of service, the best effort class. Multi-protocol label switching [RFC3031], on the other hand, by integrating forwarding based on label-swapping of a link local label with network layer routing allows flexibility in the delivery of new routing services. MPLS allows for using such media-specific forwarding mechanisms as label swapping. This enables some sophisticated features such as quality-of-service (QoS) and traffic engineering [RFC2702] to be implemented more effectively. An important component of providing QoS, however, is the ability to transport data reliably and efficiently. Although the current routing algorithms are robust and survivable, the amount of time they take to recover from a fault can be significant, in the order of several seconds (for interior gateway protocols (IGPs)) or minutes (for exterior gateway protocols, such as the Border Gateway Protocol (BGP)), causing disruption of service for some applications in the interim. This is unacceptable in situations where the aim is to provide a highly reliable service, with recovery times that are in the order of seconds down to 10's of milliseconds. IP routing may also not be able to provide bandwidth recovery, where the objective is to provide not only an alternative path, but also bandwidth equivalent to that available on the original path. (For some recent work on bandwidth recovery schemes, the reader is referred to [MPLS-BACKUP].) Examples of such applications are Virtual Leased Line services, Stock Exchange data services, voice traffic, video services etc, i.e., every application that gets a disruption in service long enough to not fulfill service agreements or the required level of quality.
現在展開されているネットワークルーティングは、主に接続性に焦点を当てており、通常、ベストエフォートクラスの1つのサービスクラスのみをサポートしています。一方、マルチプロトコルラベルスイッチング[RFC3031]は、リンクローカルラベルのラベルスワップに基づく転送とネットワークレイヤールーティングを統合することにより、新しいルーティングサービスの配信に柔軟性をもたらします。 MPLSでは、ラベルスワッピングなどのメディア固有の転送メカニズムを使用できます。これにより、サービス品質（QoS）やトラフィックエンジニアリング[RFC2702]などの高度な機能をより効果的に実装できます。ただし、QoSを提供する重要なコンポーネントは、データを確実かつ効率的に転送する機能です。現在のルーティングアルゴリズムは堅牢で存続可能ですが、障害からの回復にかかる時間は、数秒（内部ゲートウェイプロトコル（IGP）の場合）または数分（外部ゲートウェイプロトコル（ボーダーゲートウェイプロトコル（BGP））。一部のアプリケーションのサービスが一時的に中断されます。これは、非常に信頼性の高いサービスを提供することを目的とする状況では受け入れられません。回復時間は数秒から数十ミリ秒程度です。また、IPルーティングでは、代替パスだけでなく、元のパスで使用可能な帯域幅と同等の帯域幅を提供することを目的とした帯域幅の回復も提供できない場合があります。 （帯域幅回復スキームに関する最近のいくつかの作業については、リーダーは[MPLS-BACKUP]と呼ばれます。）そのようなアプリケーションの例は、仮想専用線サービス、証券取引所データサービス、音声トラフィック、ビデオサービスなどです。つまり、サービス契約または必要な品質レベルを満たさないほど長くサービスが中断する。
MPLS recovery may be motivated by the notion that there are limitations to improving the recovery times of current routing algorithms. Additional improvement can be obtained by augmenting these algorithms with MPLS recovery mechanisms [MPLS-PATH]. Since MPLS is a possible technology of choice in future IP-based transport networks, it is useful that MPLS be able to provide protection and restoration of traffic. MPLS may facilitate the convergence of network functionality on a common control and management plane. Further, a protection priority could be used as a differentiating mechanism for premium services that require high reliability, such as Virtual Leased Line services, and high priority voice and video traffic. The remainder of this document provides a framework for MPLS based recovery. It is focused at a conceptual level and is meant to address motivation, objectives and requirements. Issues of mechanism, policy, routing plans and characteristics of traffic carried by recovery paths are beyond the scope of this document.
MPLSリカバリは、現在のルーティングアルゴリズムのリカバリ時間を改善するのに制限があるという概念に動機付けられている可能性があります。これらのアルゴリズムをMPLSリカバリメカニズム[MPLS-PATH]で補強することにより、さらに改善できます。 MPLSは将来のIPベースのトランスポートネットワークで選択可能なテクノロジであるため、MPLSがトラフィックの保護と復元を提供できると便利です。 MPLSは、共通の制御プレーンと管理プレーンでのネットワーク機能の収束を促進します。さらに、保護優先順位は、仮想専用線サービスなどの高い信頼性を必要とするプレミアムサービスと、優先順位の高い音声およびビデオトラフィックの差別化メカニズムとして使用できます。このドキュメントの残りの部分では、MPLSベースのリカバリのフレームワークを提供します。概念レベルに焦点を当てており、動機、目的、要件に対処することを目的としています。メカニズム、ポリシー、ルーティング計画、およびリカバリパスによって伝送されるトラフィックの特性の問題は、このドキュメントの範囲外です。
MPLS based protection of traffic (called MPLS-based Recovery) is useful for a number of reasons. The most important is its ability to increase network reliability by enabling a faster response to faults than is possible with traditional Layer 3 (or IP layer) approaches alone while still providing the visibility of the network afforded by Layer 3. Furthermore, a protection mechanism using MPLS could enable IP traffic to be put directly over WDM optical channels and provide a recovery option without an intervening SONET layer or optical protection. This would facilitate the construction of IP-over-WDM networks that request a fast recovery ability (Note that what is meant here is the transport of IP traffic over WDM links, not the Generalized MPLS, or GMPLS, control of a WDM link).
MPLSベースのトラフィック保護（MPLSベースの回復と呼ばれる）は、いくつかの理由で役立ちます。最も重要なのは、従来のレイヤー3（またはIPレイヤー）アプローチのみで可能な場合よりも、レイヤー3によって提供されるネットワークの可視性を提供しながら、障害へのより高速な応答を可能にすることにより、ネットワークの信頼性を高める能力です。 MPLSを使用すると、IPトラフィックをWDM光チャネルに直接送信でき、SONETレイヤーや光保護を介在させずに回復オプションを提供できます。これにより、高速リカバリ機能を要求するIP-over-WDMネットワークの構築が容易になります（ここでの意味は、WDMリンクの一般化MPLS（GMPLS）制御ではなく、WDMリンクを介したIPトラフィックの転送です）。
The need for MPLS-based recovery arises because of the following:
次の理由により、MPLSベースのリカバリが必要になります。
I. Layer 3 or IP rerouting may be too slow for a core MPLS network that needs to support recovery times that are smaller than the convergence times of IP routing protocols.
I.レイヤ3またはIP再ルーティングは、IPルーティングプロトコルの収束時間よりも短いリカバリ時間をサポートする必要があるコアMPLSネットワークには遅すぎる可能性があります。
II. Layer 3 or IP rerouting does not provide the ability to provide bandwidth protection to specific flows (e.g., voice over IP, virtual leased line services).
II。レイヤー3またはIPの再ルーティングでは、特定のフロー（Voice over IP、仮想専用回線サービスなど）に帯域幅保護を提供する機能は提供されません。
III. Layer 0 (for example, optical layer) or Layer 1 (for example, SONET) mechanisms may be wasteful use of resources.
III。レイヤー0（たとえば、光レイヤー）またはレイヤー1（たとえば、SONET）メカニズムは、リソースの無駄な使用になる場合があります。
IV. The granularity at which the lower layers may be able to protect traffic may be too coarse for traffic that is switched using MPLS-based mechanisms.
IV。下位層がトラフィックを保護できる粒度は、MPLSベースのメカニズムを使用してスイッチングされるトラフィックには粗すぎる場合があります。
V. Layer 0 or Layer 1 mechanisms may have no visibility into higher layer operations. Thus, while they may provide, for example, link protection, they cannot easily provide node protection or protection of traffic transported at layer 3. Further, this may prevent the lower layers from providing restoration based on the traffic's needs. For example, fast restoration for traffic that needs it, and slower restoration (with possibly more optimal use of resources) for traffic that does not require fast restoration. In networks where the latter class of traffic is dominant, providing fast restoration to all classes of traffic may not be cost effective from a service provider's perspective.
V.レイヤー0またはレイヤー1のメカニズムでは、上位レイヤーの操作を確認できない場合があります。したがって、たとえばリンク保護を提供することはできますが、ノード保護やレイヤー3で転送されるトラフィックの保護を簡単に提供することはできません。さらに、これにより、下位レイヤーがトラフィックのニーズに基づいて復元を提供できない場合があります。たとえば、それを必要とするトラフィックの高速復元と、高速復元を必要としないトラフィックの復元（遅い場合はリソースの最適な使用）。後者のクラスのトラフィックが支配的なネットワークでは、すべてのクラスのトラフィックに高速の復元を提供することは、サービスプロバイダーの観点からは費用効果が高くない場合があります。
VI. MPLS has desirable attributes when applied to the purpose of recovery for connectionless networks. Specifically that an LSP is source routed and a forwarding path for recovery can be "pinned" and is not affected by transient instability in SPF routing brought on by failure scenarios.
VI。 MPLSは、コネクションレス型ネットワークのリカバリーの目的に適用されるときに望ましい属性を持っています。具体的には、LSPがソースルーティングされ、リカバリの転送パスを「固定」でき、障害シナリオによって引き起こされるSPFルーティングの一時的な不安定性の影響を受けないこと。
VII. Establishing interoperability of protection mechanisms between routers/LSRs from different vendors in IP or MPLS networks is desired to enable recovery mechanisms to work in a multivendor environment, and to enable the transition of certain protected services to an MPLS core.
VII。マルチベンダー環境でリカバリメカニズムを機能させ、特定の保護されたサービスをMPLSコアに移行できるようにするには、IPまたはMPLSネットワークの異なるベンダーのルーター/ LSR間で保護メカニズムの相互運用性を確立することが望まれます。
The following are some important goals for MPLS-based recovery.
以下は、MPLSベースのリカバリーのいくつかの重要な目標です。
I. MPLS-based recovery mechanisms may be subject to the traffic engineering goal of optimal use of resources.
I. MPLSベースの回復メカニズムは、リソースの最適な使用というトラフィックエンジニアリングの目標の対象となる場合があります。
II. MPLS based recovery mechanisms should aim to facilitate restoration times that are sufficiently fast for the end user application. That is, that better match the end-user's application requirements. In some cases, this may be as short as 10s of milliseconds.
II。 MPLSベースの回復メカニズムは、エンドユーザーアプリケーションにとって十分に速い復元時間を促進することを目的とする必要があります。つまり、エンドユーザーのアプリケーション要件によりよく一致します。場合によっては、これは数十ミリ秒と短い場合があります。
We observe that I and II may be conflicting objectives, and a trade off may exist between them. The optimal choice depends on the end-user application's sensitivity to restoration time and the cost impact of introducing restoration in the network, as well as the end-user application's sensitivity to cost.
IとIIは目的が矛盾している可能性があり、両者の間にはトレードオフが存在する可能性があります。最適な選択は、復元時間に対するエンドユーザーアプリケーションの感度と、ネットワークに復元を導入することによるコストへの影響、およびエンドユーザーアプリケーションのコストに対する感度によって異なります。
III. MPLS-based recovery should aim to maximize network reliability and availability. MPLS-based recovery of traffic should aim to minimize the number of single points of failure in the MPLS protected domain.
III。 MPLSベースのリカバリは、ネットワークの信頼性と可用性を最大化することを目的とする必要があります。 MPLSベースのトラフィックの回復は、MPLSで保護されたドメイン内の単一障害点の数を最小限に抑えることを目的とする必要があります。
IV. MPLS-based recovery should aim to enhance the reliability of the protected traffic while minimally or predictably degrading the traffic carried by the diverted resources.
IV。 MPLSベースのリカバリーは、迂回されたリソースによって運ばれるトラフィックを最小限にまたは予想通りに低下させながら、保護されたトラフィックの信頼性を高めることを目的とする必要があります。
V. MPLS-based recovery techniques should aim to be applicable for protection of traffic at various granularities. For example, it should be possible to specify MPLS-based recovery for a portion of the traffic on an individual path, for all traffic on an individual path, or for all traffic on a group of paths. Note that a path is used as a general term and includes the notion of a link, IP route or LSP.
V. MPLSベースのリカバリ技術は、さまざまな粒度でのトラフィック保護に適用できることを目的とする必要があります。たとえば、個々のパスのトラフィックの一部、個々のパスのすべてのトラフィック、またはパスのグループのすべてのトラフィックに対して、MPLSベースのリカバリを指定できるようにする必要があります。パスは一般的な用語として使用され、リンク、IPルート、またはLSPの概念を含むことに注意してください。
VI. MPLS-based recovery techniques may be applicable for an entire end-to-end path or for segments of an end-to-end path.
VI。 MPLSベースのリカバリ手法は、エンドツーエンドパス全体またはエンドツーエンドパスのセグメントに適用できます。
VII. MPLS-based recovery mechanisms should aim to take into consideration the recovery actions of lower layers. MPLS-based mechanisms should not trigger lower layer protection switching nor should MPLS-based mechanisms be triggered when lower layer switching has or may imminently occur.
VII。 MPLSベースの回復メカニズムは、下位層の回復アクションを考慮することを目的とする必要があります。 MPLSベースのメカニズムは、下位層の保護切り替えをトリガーしないでください。また、下位層の切り替えが発生した場合、または発生する可能性がある場合にMPLSベースのメカニズムをトリガーしてはなりません。
VIII. MPLS-based recovery mechanisms should aim to minimize the loss of data and packet reordering during recovery operations. (The current MPLS specification itself has no explicit requirement on reordering.)
VIII。 MPLSベースの回復メカニズムは、回復操作中のデータとパケットの順序変更の損失を最小限に抑えることを目的とする必要があります。 （現在のMPLS仕様自体には、並べ替えに関する明示的な要件はありません。）
IX. MPLS-based recovery mechanisms should aim to minimize the state overhead incurred for each recovery path maintained.
IX。 MPLSベースの回復メカニズムは、維持される各回復パスで発生する状態オーバーヘッドを最小限に抑えることを目的とする必要があります。
X. MPLS-based recovery mechanisms should aim to minimize the signaling overhead to setup and maintain recovery paths and to notify failures.
X. MPLSベースの回復メカニズムは、回復パスを設定および維持し、障害を通知するためのシグナリングオーバーヘッドを最小限にすることを目的とする必要があります。
XI. MPLS-based recovery mechanisms should aim to preserve the constraints on traffic after switchover, if desired. That is, if desired, the recovery path should meet the resource requirements of, and achieve the same performance characteristics as, the working path.
XI。 MPLSベースの回復メカニズムは、必要に応じて、スイッチオーバー後にトラフィックの制約を維持することを目的とする必要があります。つまり、必要に応じて、復旧パスは現用パスのリソース要件を満たし、現用パスと同じパフォーマンス特性を実現する必要があります。
We observe that some of the above are conflicting goals, and real deployment will often involve engineering compromises based on a variety of factors such as cost, end-user application requirements, network efficiency, complexity involved, and revenue considerations. Thus, these goals are subject to tradeoffs based on the above considerations.
上記のいくつかは相反する目標であり、実際の導入には、コスト、エンドユーザーアプリケーションの要件、ネットワーク効率、関連する複雑さ、収益の考慮事項などのさまざまな要因に基づくエンジニアリングの妥協が含まれることがよくあります。したがって、これらの目標は、上記の考慮事項に基づくトレードオフの影響を受けます。
There are several options for providing protection of traffic. The most generic requirement is the specification of whether recovery should be via Layer 3 (or IP) rerouting or via MPLS protection switching or rerouting actions.
トラフィックの保護を提供するためのいくつかのオプションがあります。最も一般的な要件は、レイヤ3（またはIP）再ルーティングによるものか、MPLS保護スイッチングまたは再ルーティングアクションによるものかを指定することです。
Generally network operators aim to provide the fastest, most stable, and the best protection mechanism that can be provided at a reasonable cost. The higher the levels of protection, the more the resources consumed. Therefore it is expected that network operators will offer a spectrum of service levels. MPLS-based recovery should give the flexibility to select the recovery mechanism, choose the granularity at which traffic is protected, and to also choose the specific types of traffic that are protected in order to give operators more control over that tradeoff. With MPLS-based recovery, it can be possible to provide different levels of protection for different classes of service, based on their service requirements. For example, using approaches outlined below, a Virtual Leased Line (VLL) service or real-time applications like Voice over IP (VoIP) may be supported using link/node protection together with pre-established, pre-reserved path protection. Best effort traffic, on the other hand, may use path protection that is established on demand or may simply rely on IP re-route or higher layer recovery mechanisms. As another example of their range of application, MPLS-based recovery strategies may be used to protect traffic not originally flowing on label switched paths, such as IP traffic that is normally routed hop-by-hop, as well as traffic forwarded on label switched paths.
一般に、ネットワークオペレーターは、妥当なコストで提供できる、最速、最も安定した、最高の保護メカニズムを提供することを目指しています。保護レベルが高いほど、消費されるリソースが多くなります。したがって、ネットワーク事業者がさまざまなサービスレベルを提供することが期待されます。 MPLSベースの回復では、回復メカニズムを選択し、トラフィックを保護する細かさを選択し、保護されている特定のタイプのトラフィックを選択して、オペレーターがそのトレードオフをより細かく制御できるようにする柔軟性を提供する必要があります。 MPLSベースのリカバリを使用すると、サービス要件に基づいて、さまざまなサービスクラスにさまざまなレベルの保護を提供できます。たとえば、以下に概説するアプローチを使用すると、仮想専用線（VLL）サービスやVoice over IP（VoIP）などのリアルタイムアプリケーションは、リンク/ノード保護と事前に確立された事前予約されたパス保護を使用してサポートされます。一方、ベストエフォートトラフィックは、オンデマンドで確立されるパス保護を使用するか、単にIP再ルーティングまたは上位層の回復メカニズムに依存する場合があります。アプリケーションの範囲の別の例として、MPLSベースのリカバリ戦略を使用して、通常はホップバイホップでルーティングされるIPトラフィックやラベルスイッチで転送されるトラフィックなど、ラベルスイッチパスで元々流れていないトラフィックを保護できます。パス。
There are two basic models for path recovery: rerouting and protection switching.
パス回復には、再ルーティングと保護切り替えの2つの基本モデルがあります。
Protection switching and rerouting, as defined below, may be used together. For example, protection switching to a recovery path may be used for rapid restoration of connectivity while rerouting determines a new optimal network configuration, rearranging paths, as needed, at a later time.
以下に定義されているように、保護の切り替えと再ルーティングを併用できます。たとえば、リカバリパスへの保護切り替えは、接続の迅速な復元に使用できますが、再ルーティングは、新しい最適なネットワーク構成を決定し、後で必要に応じてパスを再配置します。
Recovery by rerouting is defined as establishing new paths or path segments on demand for restoring traffic after the occurrence of a fault. The new paths may be based upon fault information, network routing policies, pre-defined configurations and network topology information. Thus, upon detecting a fault, paths or path segments to bypass the fault are established using signaling.
再ルーティングによる回復は、障害発生後にトラフィックを復元するためにオンデマンドで新しいパスまたはパスセグメントを確立することとして定義されます。新しいパスは、障害情報、ネットワークルーティングポリシー、事前定義された構成、およびネットワークトポロジ情報に基づく場合があります。したがって、障害を検出すると、障害を回避するためのパスまたはパスセグメントがシグナリングを使用して確立されます。
Once the network routing algorithms have converged after a fault, it may be preferable, in some cases, to reoptimize the network by performing a reroute based on the current state of the network and network policies. This is discussed further in Section 3.8.
障害後にネットワークルーティングアルゴリズムが収束したら、場合によっては、ネットワークの現在の状態とネットワークポリシーに基づいて再ルーティングを実行してネットワークを再最適化することが望ましい場合があります。これについては、セクション3.8で詳しく説明します。
In terms of the principles defined in section 3, reroute recovery employs paths established-on-demand with resources reserved-on-demand.
セクション3で定義された原則の観点から、再ルーティング回復は、オンデマンドで予約されたリソースを使用してオンデマンドで確立されたパスを使用します。
Protection switching recovery mechanisms pre-establish a recovery path or path segment, based upon network routing policies, the restoration requirements of the traffic on the working path, and administrative considerations. The recovery path may or may not be link and node disjoint with the working path. However if the recovery path shares sources of failure with the working path, the overall reliability of the construct is degraded. When a fault is detected, the protected traffic is switched over to the recovery path(s) and restored.
保護切り替えリカバリメカニズムは、ネットワークルーティングポリシー、現用パス上のトラフィックの復元要件、および管理上の考慮事項に基づいて、リカバリパスまたはパスセグメントを事前に確立します。リカバリパスは、リンクである場合とそうでない場合があり、ノードは現用パスと切り離されています。ただし、復旧パスが障害の原因を現用パスと共有している場合、構造の全体的な信頼性が低下します。障害が検出されると、保護されたトラフィックがリカバリパスに切り替えられ、復元されます。
In terms of the principles in section 3, protection switching employs pre-established recovery paths, and, if resource reservation is required on the recovery path, pre-reserved resources. The various sub-types of protection switching are detailed in Section 4.4 of this document.
セクション3の原則に関して、保護切り替えでは、事前に確立された回復パスが使用され、回復パスでリソースの予約が必要な場合は、事前予約されたリソースが使用されます。保護切り替えのさまざまなサブタイプについては、このドキュメントのセクション4.4で詳しく説明しています。
There are three defined recovery cycles: the MPLS Recovery Cycle, the MPLS Reversion Cycle and the Dynamic Re-routing Cycle. The first cycle detects a fault and restores traffic onto MPLS-based recovery paths. If the recovery path is non-optimal the cycle may be followed by any of the two latter cycles to achieve an optimized network again. The reversion cycle applies for explicitly routed traffic that does not rely on any dynamic routing protocols to converge. The dynamic re-routing cycle applies for traffic that is forwarded based on hop-by-hop routing.
3つの定義された回復サイクルがあります。MPLS回復サイクル、MPLS復帰サイクル、および動的再ルーティングサイクルです。最初のサイクルは障害を検出し、トラフィックをMPLSベースの回復パスに復元します。リカバリパスが最適ではない場合、サイクルの後に、最適化されたネットワークを再び実現するために、後の2つのサイクルのいずれかが続く場合があります。復帰サイクルは、収束するために動的ルーティングプロトコルに依存しない明示的にルーティングされたトラフィックに適用されます。動的再ルーティングサイクルは、ホップバイホップルーティングに基づいて転送されるトラフィックに適用されます。
The MPLS recovery cycle model is illustrated in Figure 1. Definitions and a key to abbreviations follow.
MPLS回復サイクルモデルを図1に示します。定義と略語のキーは次のとおりです。
--Network Impairment
| --Fault Detected
| | --Start of Notification
| | | -- Start of Recovery Operation
| | | | --Recovery Operation Complete
| | | | | --Path Traffic Recovered
| | | | | |
| | | | | |
v v v v v v
----------------------------------------------------------------
| T1 | T2 | T3 | T4 | T5 |
Figure 1. MPLS Recovery Cycle Model The various timing measures used in the model are described below.
図1. MPLS回復サイクルモデルモデルで使用されるさまざまなタイミング測定値を以下に説明します。
T1 Fault Detection Time T2 Fault Hold-off Time T3 Fault Notification Time T4 Recovery Operation Time T5 Traffic Recovery Time
T1障害検出時間T2障害ホールドオフ時間T3障害通知時間T4回復動作時間T5トラフィック回復時間
Definitions of the recovery cycle times are as follows:
回復サイクル時間の定義は次のとおりです。
Fault Detection Time
障害検出時間
The time between the occurrence of a network impairment and the moment the fault is detected by MPLS-based recovery mechanisms. This time may be highly dependent on lower layer protocols.
ネットワーク障害が発生してから、MPLSベースの回復メカニズムによって障害が検出されるまでの時間。この時間は、下位層のプロトコルに大きく依存している可能性があります。
Fault Hold-Off Time
障害ホールドオフ時間
The configured waiting time between the detection of a fault and taking MPLS-based recovery action, to allow time for lower layer protection to take effect. The Fault Hold-off Time may be zero.
障害を検出してからMPLSベースの回復アクションを実行するまでの構成された待機時間。これにより、下位層の保護が有効になる時間を確保できます。障害ホールドオフ時間はゼロになる場合があります。
Note: The Fault Hold-Off Time may occur after the Fault Notification Time interval if the node responsible for the switchover, the Path Switch LSR (PSL), rather than the detecting LSR, is configured to wait.
注：スイッチオーバーを担当するノードである検出LSRではなくパススイッチLSR（PSL）が待機するように構成されている場合、障害通知時間間隔の後に障害ホールドオフ時間が発生することがあります。
Fault Notification Time
障害通知時間
The time between initiation of a Fault Indication Signal (FIS) by the LSR detecting the fault and the time at which the Path Switch LSR (PSL) begins the recovery operation. This is zero if the PSL detects the fault itself or infers a fault from such events as an adjacency failure.
LSRが障害を検出して障害表示信号（FIS）を開始してから、パススイッチLSR（PSL）が回復操作を開始するまでの時間。 PSL自体が障害を検出した場合、または隣接障害などのイベントから障害を推測した場合、これはゼロです。
Note: If the PSL detects the fault itself, there still may be a Fault Hold-Off Time period between detection and the start of the recovery operation.
注：PSLが障害自体を検出した場合でも、検出から回復操作の開始までの間に障害ホールドオフ期間が存在する可能性があります。
Recovery Operation Time
復旧作業時間
The time between the first and last recovery actions. This may include message exchanges between the PSL and PML (Path Merge LSR) to coordinate recovery actions.
最初と最後の回復アクションの間の時間。これには、回復アクションを調整するためのPSLとPML（Path Merge LSR）間のメッセージ交換が含まれる場合があります。
Traffic Recovery Time
トラフィック回復時間
The time between the last recovery action and the time that the traffic (if present) is completely recovered. This interval is intended to account for the time required for traffic to once again arrive at the point in the network that experienced disrupted or degraded service due to the occurrence of the fault (e.g., the PML). This time may depend on the location of the fault, the recovery mechanism, and the propagation delay along the recovery path.
最後の回復アクションとトラフィック（存在する場合）が完全に回復するまでの時間。この間隔は、障害（PMLなど）の発生によりサービスが中断または低下したネットワークのポイントにトラフィックが再び到着するのに必要な時間を考慮したものです。この時間は、障害の場所、回復メカニズム、および回復パスに沿った伝播遅延に依存する場合があります。
Protection switching, revertive mode, requires the traffic to be switched back to a preferred path when the fault on that path is cleared. The MPLS reversion cycle model is illustrated in Figure 2. Note that the cycle shown below comes after the recovery cycle shown in Fig. 1.
保護切り替え、リバーティブモードでは、そのパスの障害がクリアされたときに、トラフィックを優先パスに切り替える必要があります。 MPLS復帰サイクルモデルを図2に示します。以下に示すサイクルは、図1に示す回復サイクルの後にあることに注意してください。
--Network Impairment Repaired
| --Fault Cleared
| | --Path Available
| | | --Start of Reversion Operation
| | | | --Reversion Operation Complete
| | | | | --Traffic Restored on Preferred Path
| | | | | |
| | | | | |
v v v v v v
-----------------------------------------------------------------
| T7 | T8 | T9 | T10| T11|
Figure 2. MPLS Reversion Cycle Model
図2. MPLS復帰サイクルモデル
The various timing measures used in the model are described below.
モデルで使用されるさまざまなタイミング指標を以下に示します。
T7 Fault Clearing Time T8 Clear Hold-Off Time T9 Clear Notification Time T10 Reversion Operation Time T11 Traffic Reversion Time
T7障害クリア時間T8クリアホールドオフ時間T9クリア通知時間T10復帰動作時間T11トラフィック復帰時間
Note that time T6 (not shown above) is the time for which the network impairment is not repaired and traffic is flowing on the recovery path.
時間T6（上記には表示されていません）は、ネットワーク障害が修復されず、トラフィックがリカバリパスを流れている時間であることに注意してください。
Definitions of the reversion cycle times are as follows:
復帰サイクルタイムの定義は次のとおりです。
Fault Clearing Time
障害クリア時間
The time between the repair of a network impairment and the time that MPLS-based mechanisms learn that the fault has been cleared. This time may be highly dependent on lower layer protocols.
ネットワーク障害の修復から、MPLSベースのメカニズムが障害が解消されたことを知るまでの時間。この時間は、下位層のプロトコルに大きく依存している可能性があります。
Clear Hold-Off Time
ホールドオフ時間をクリア
The configured waiting time between the clearing of a fault and MPLS-based recovery action(s). Waiting time may be needed to ensure that the path is stable and to avoid flapping in cases where a fault is intermittent. The Clear Hold-Off Time may be zero.
障害のクリアとMPLSベースの回復アクションの間の構成された待機時間。パスが安定していることを確認し、障害が断続的である場合にフラッピングを回避するために、待機時間が必要になる場合があります。 Clear Hold-Off Timeがゼロになる場合があります。
Note: The Clear Hold-Off Time may occur after the Clear Notification Time interval if the PSL is configured to wait.
注：PSLが待機するように構成されている場合、クリア通知オフ時間の後にクリアホールドオフ時間が発生することがあります。
Clear Notification Time
通知時間をクリア
The time between initiation of a Fault Recovery Signal (FRS) by the LSR clearing the fault and the time at which the path switch LSR begins the reversion operation. This is zero if the PSL clears the fault itself.
LSRが障害をクリアして障害回復信号（FRS）を開始してから、パススイッチLSRが復帰操作を開始するまでの時間。 PSLが障害自体をクリアした場合、これはゼロです。
Note: If the PSL clears the fault itself, there still may be a Clear Hold-off Time period between fault clearing and the start of the reversion operation.
注：PSLが障害自体をクリアした場合でも、障害のクリアから復帰操作の開始までの間に、クリアホールドオフ期間が存在する可能性があります。
Reversion Operation Time
復帰操作時間
The time between the first and last reversion actions. This may include message exchanges between the PSL and PML to coordinate reversion actions.
最初と最後の復帰アクション間の時間。これには、復帰アクションを調整するためのPSLとPML間のメッセージ交換が含まれる場合があります。
Traffic Reversion Time
トラフィックの復帰時間
The time between the last reversion action and the time that traffic (if present) is completely restored on the preferred path. This interval is expected to be quite small since both paths are working and care may be taken to limit the traffic disruption (e.g., using "make before break" techniques and synchronous switch-over).
最後の復帰アクションからトラフィック（存在する場合）が優先パスで完全に復元されるまでの時間。両方のパスが機能しており、トラフィックの中断を制限するように注意が必要な場合があるため、この間隔は非常に短いと予想されます（たとえば、「make before break」手法と同期スイッチオーバーを使用）。
In practice, the most interesting times in the reversion cycle are the Clear Hold-off Time and the Reversion Operation Time together with Traffic Reversion Time (or some other measure of traffic disruption). The first interval is to ensure stability of the repaired path and the latter one is to minimize disruption time while the reversion action is in progress.
実際には、復帰サイクルで最も興味深い時間は、クリアホールドオフ時間と復帰操作時間、およびトラフィック復帰時間（または他のトラフィック中断の測定）です。最初の間隔は、修復されたパスの安定性を確保するためのものであり、後者は、復元アクションの進行中の中断時間を最小限にするためのものです。
Given that both paths are available, it is better to wait to have a well-controlled switch-back with minimal disruption than have an immediate operation that may cause new faults to be introduced (except, perhaps, when the recovery path is unable to offer a quality of service comparable to the preferred path).
両方のパスが利用可能であることを考えると、新しい障害を引き起こす可能性のある即時の操作を行うよりも、混乱を最小限に抑えて適切に制御されたスイッチバックを待つことをお勧めします（おそらく、復旧パスが提供できない場合を除く）優先パスに匹敵するサービス品質）。
Dynamic rerouting aims to bring the IP network to a stable state after a network impairment has occurred. A re-optimized network is achieved after the routing protocols have converged, and the traffic is moved from a recovery path to a (possibly) new working path. The steps involved in this mode are illustrated in Figure 3.
動的再ルーティングは、ネットワーク障害が発生した後、IPネットワークを安定した状態にすることを目的としています。再最適化されたネットワークは、ルーティングプロトコルが収束した後に実現され、トラフィックは回復パスから（おそらく）新しい作業パスに移動されます。このモードに含まれる手順を図3に示します。
Note that the cycle shown below may be overlaid on the recovery cycle shown in Fig. 1 or the reversion cycle shown in Fig. 2, or both (in the event that both the recovery cycle and the reversion cycle take place before the routing protocols converge), and occurs if after the convergence of the routing protocols it is determined (based on on-line algorithms or off-line traffic engineering tools, network configuration, or a variety of other possible criteria) that there is a better route for the working path.
以下に示すサイクルは、図1に示すリカバリーサイクルまたは図2に示す復帰サイクル、あるいはその両方（ルーティングプロトコルが収束する前にリカバリーサイクルと復帰サイクルの両方が発生した場合）にオーバーレイされる場合があることに注意してください。 ）、ルーティングプロトコルの収束後に、（オンラインアルゴリズムまたはオフライントラフィックエンジニアリングツール、ネットワーク構成、またはその他のさまざまな可能な基準に基づいて）動作するためのより良いルートがあると判断された場合に発生します道。
--Network Enters a Semi-stable State after an Impairment
| --Dynamic Routing Protocols Converge
| | --Initiate Setup of New Working Path between PSL
| | | and PML
| | | --Switchover Operation Complete
| | | | --Traffic Moved to New Working Path
| | | | |
| | | | |
v v v v v
-----------------------------------------------------------------
| T12 | T13 | T14 | T15 |
Figure 3. Dynamic Rerouting Cycle Model
図3.動的再ルーティングサイクルモデル
The various timing measures used in the model are described below.
モデルで使用されるさまざまなタイミング対策を以下に示します。
T12 Network Route Convergence Time T13 Hold-down Time (optional) T14 Switchover Operation Time T15 Traffic Restoration Time Network Route Convergence Time
T12ネットワークルート収束時間T13ホールドダウン時間（オプション）T14スイッチオーバー操作時間T15トラフィック復旧時間ネットワークルート収束時間
We define the network route convergence time as the time taken for the network routing protocols to converge and for the network to reach a stable state.
ネットワークルートの収束時間は、ネットワークルーティングプロトコルが収束し、ネットワークが安定した状態になるまでの時間として定義されます。
Holddown Time
ホールドダウン時間
We define the holddown period as a bounded time for which a recovery path must be used. In some scenarios it may be difficult to determine if the working path is stable. In these cases a holddown time may be used to prevent excess flapping of traffic between a working and a recovery path.
ホールドダウン期間は、リカバリパスを使用する必要がある制限時間として定義します。一部のシナリオでは、作業パスが安定しているかどうかを判断することが難しい場合があります。これらの場合、ホールドダウン時間を使用して、現用パスと復旧パスの間のトラフィックの過度のフラッピングを防ぐことができます。
Switchover Operation Time
切り替え操作時間
The time between the first and last switchover actions. This may include message exchanges between the PSL and PML to coordinate the switchover actions.
最初と最後のスイッチオーバーアクション間の時間。これには、切り替えアクションを調整するためのPSLとPML間のメッセージ交換が含まれる場合があります。
Traffic Restoration Time
交通復旧時間
The time between the last restoration action and the time that traffic (if present) is completely restored on the new preferred path.
最後の復元アクションと、トラフィック（存在する場合）が新しい優先パスで完全に復元されるまでの時間。
As an example of the recovery cycle, we present a sequence of events that occur after a network impairment occurs and when a protection switch is followed by dynamic rerouting.
回復サイクルの例として、ネットワーク障害が発生した後、保護切り替えの後に動的再ルーティングが行われたときに発生する一連のイベントを示します。
I. Link or path fault occurs II. Signaling initiated (FIS) for the detected fault III. FIS arrives at the PSL IV. The PSL initiates a protection switch to a pre-configured recovery path V. The PSL switches over the traffic from the working path to the recovery path VI. The network enters a semi-stable state VII. Dynamic routing protocols converge after the fault, and a new working path is calculated (based, for example, on some of the criteria mentioned in Section 2.1.1). VIII. A new working path is established between the PSL and the PML (assumption is that PSL and PML have not changed) IX. Traffic is switched over to the new working path.
I.リンクまたはパスの障害が発生したII。検出された障害のシグナリング開始（FIS）III。 FISがPSL IVに到着します。 PSLは、事前に構成されたリカバリパスVへの保護切り替えを開始します。PSLは、トラフィックを現用パスからリカバリパスVIに切り替えます。ネットワークは準安定状態VIIに入ります。動的ルーティングプロトコルは障害の後に収束し、新しい作業パスが計算されます（たとえば、セクション2.1.1で説明されているいくつかの基準に基づいて）。 VIII。 PSLとPMLの間に新しい作業パスが確立されます（PSLとPMLが変更されていないことが前提です）IX。トラフィックは新しい現用パスに切り替えられます。
This document assumes the terminology given in [RFC3031], and, in addition, introduces the following new terms.
このドキュメントは、[RFC3031]で与えられた用語を前提とし、さらに、次の新しい用語を紹介します。
Re-routing
再ルーティング
A recovery mechanism in which the recovery path or path segments are created dynamically after the detection of a fault on the working path. In other words, a recovery mechanism in which the recovery path is not pre-established.
現用パスで障害が検出された後、回復パスまたはパスセグメントが動的に作成される回復メカニズム。つまり、回復パスが事前に確立されていない回復メカニズム。
Protection Switching
保護切り替え
A recovery mechanism in which the recovery path or path segments are created prior to the detection of a fault on the working path. In other words, a recovery mechanism in which the recovery path is pre-established.
現用パスの障害を検出する前にリカバリパスまたはパスセグメントが作成されるリカバリメカニズム。つまり、回復パスが事前に確立されている回復メカニズム。
Working Path
ワーキングパス
The protected path that carries traffic before the occurrence of a fault. The working path can be of different kinds; a hop-by-hop routed path, a trunk, a link, an LSP or part of a multipoint-to-point LSP.
障害が発生する前にトラフィックを運ぶ保護パス。作業パスにはさまざまな種類があります。ホップバイホップのルーティングされたパス、トランク、リンク、LSP、またはマルチポイントツーポイントLSPの一部。
Synonyms for a working path are primary path and active path.
現用パスの同義語は、プライマリパスとアクティブパスです。
Recovery Path
回復パス
The path by which traffic is restored after the occurrence of a fault. In other words, the path on which the traffic is directed by the recovery mechanism. The recovery path is established by MPLS means. The recovery path can either be an equivalent recovery path and ensure no reduction in quality of service, or be a limited recovery path and thereby not guarantee the same quality of service (or some other criteria of performance) as the working path. A limited recovery path is not expected to be used for an extended period of time.
障害発生後にトラフィックが復元されるパス。つまり、回復メカニズムによってトラフィックが誘導されるパスです。回復パスはMPLS手段によって確立されます。リカバリー・パスは、同等のリカバリー・パスであり、サービス品質の低下がないことを保証するか、制限付きリカバリー・パスであり、それにより、作業パスと同じサービス品質（または他のパフォーマンス基準）を保証できません。限定されたリカバリパスは、長期間使用することは想定されていません。
Synonyms for a recovery path are: back-up path, alternative path, and protection path.
リカバリー・パスの同義語は、バックアップ・パス、代替パス、および保護パスです。
Protection Counterpart
保護対象
The "other" path when discussing pre-planned protection switching schemes. The protection counterpart for the working path is the recovery path and vice-versa.
事前に計画された保護切り替え方式について説明するときの「その他の」経路。現用パスの保護相手はリカバリパスであり、その逆も同様です。
Path Switch LSR (PSL)
パススイッチLSR（PSL）
An LSR that is responsible for switching or replicating the traffic between the working path and the recovery path.
現用パスと復旧パス間のトラフィックの切り替えまたは複製を担当するLSR。
Path Merge LSR (PML)
パスマージLSR（PML）
An LSR that is responsible for receiving the recovery path traffic, and either merging the traffic back onto the working path, or, if it is itself the destination, passing the traffic on to the higher layer protocols.
回復パストラフィックを受信し、トラフィックを現用パスにマージする、またはそれが宛先である場合は、トラフィックを上位層プロトコルに渡すLSR。
Point of Repair (POR)
修理のポイント（POR）
An LSR that is setup for performing MPLS recovery. In other words, an LSR that is responsible for effecting the repair of an LSP. The POR, for example, can be a PSL or a PML, depending on the type of recovery scheme employed.
MPLSリカバリーを実行するためにセットアップされたLSR。言い換えると、LSPの修復に影響を与えるLSRです。 ＰＯＲは、例えば、採用される回復スキームのタイプに応じて、ＰＳＬまたはＰＭＬであり得る。
Intermediate LSR
中級LSR
An LSR on a working or recovery path that is neither a PSL nor a PML for that path.
そのパスのPSLでもPMLでもない、作業パスまたは回復パスのLSR。
Path Group (PG)
パスグループ（PG）
A logical bundling of multiple working paths, each of which is routed identically between a Path Switch LSR and a Path Merge LSR.
複数の現用パスの論理的なバンドル。各パスは、パススイッチLSRとパスマージLSRの間で同じようにルーティングされます。
Protected Path Group (PPG)
保護パスグループ（PPG）
A path group that requires protection.
保護が必要なパスグループ。
Protected Traffic Portion (PTP)
保護されたトラフィック部分（PTP）
The portion of the traffic on an individual path that requires protection. For example, code points in the EXP bits of the shim header may identify a protected portion.
保護が必要な個々のパス上のトラフィックの部分。たとえば、シムヘッダーのEXPビット内のコードポイントは、保護された部分を識別できます。
Bypass Tunnel
バイパストンネル
A path that serves to back up a set of working paths using the label stacking approach [RFC3031]. The working paths and the bypass tunnel must all share the same path switch LSR (PSL) and the path merge LSR (PML).
ラベルスタッキングアプローチ[RFC3031]を使用して、一連の作業パスをバックアップするためのパス。現用パスとバイパストンネルはすべて、同じパススイッチLSR（PSL）とパスマージLSR（PML）を共有する必要があります。
Switch-Over
切り替える
The process of switching the traffic from the path that the traffic is flowing on onto one or more alternate path(s). This may involve moving traffic from a working path onto one or more recovery paths, or may involve moving traffic from a recovery path(s) on to a more optimal working path(s).
トラフィックが流れているパスから1つ以上の代替パスにトラフィックを切り替えるプロセス。これには、トラフィックを現用パスから1つ以上のリカバリパスに移動することや、リカバリパスからより最適な現用パスにトラフィックを移動することが含まれます。
Switch-Back
スイッチバック
The process of returning the traffic from one or more recovery paths back to the working path(s).
1つまたは複数のリカバリパスから現用パスにトラフィックを戻すプロセス。
Revertive Mode
リバーティブモード
A recovery mode in which traffic is automatically switched back from the recovery path to the original working path upon the restoration of the working path to a fault-free condition. This assumes a failed working path does not automatically surrender resources to the network.
トラフィックが障害のない状態に復旧すると、トラフィックが自動的に復旧パスから元の現用パスに切り替わる復旧モード。これは、障害のある作業パスがリソースをネットワークに自動的に委譲しないことを前提としています。
Non-revertive Mode
非リバーティブモード
A recovery mode in which traffic is not automatically switched back to the original working path after this path is restored to a fault-free condition. (Depending on the configuration, the original working path may, upon moving to a fault-free condition, become the recovery path, or it may be used for new working traffic, and be no longer associated with its original recovery path, i.e., is surrendered to the network.)
このパスが障害のない状態に復元された後、トラフィックが元の現用パスに自動的に切り替えられないリカバリモード。 （構成によっては、元の現用パスが障害のない状態に移行すると、復旧パスになるか、新しい現用トラフィックに使用され、元の復旧パスに関連付けられなくなる場合があります。つまり、ネットワークに降伏した。）
MPLS Protection Domain
MPLS保護ドメイン
The set of LSRs over which a working path and its corresponding recovery path are routed.
作業パスとそれに対応するリカバリパスがルーティングされるLSRのセット。
MPLS Protection Plan
MPLS保護計画
The set of all LSP protection paths and the mapping from working to protection paths deployed in an MPLS protection domain at a given time.
すべてのLSP保護パスのセットと、所定の時間にMPLS保護ドメインに展開された、現用パスから保護パスへのマッピング。
Liveness Message
活力メッセージ
A message exchanged periodically between two adjacent LSRs that serves as a link probing mechanism. It provides an integrity check of the forward and the backward directions of the link between the two LSRs as well as a check of neighbor aliveness.
リンク調査メカニズムとして機能する2つの隣接するLSR間で定期的に交換されるメッセージ。これは、2つのLSR間のリンクの順方向および逆方向の整合性チェックと、ネイバーの活性のチェックを提供します。
Path Continuity Test
パス連続性テスト
A test that verifies the integrity and continuity of a path or path segment. The details of such a test are beyond the scope of this document. (This could be accomplished, for example, by transmitting a control message along the same links and nodes as the data traffic or similarly could be measured by the absence of traffic and by providing feedback.)
パスまたはパスセグメントの整合性と連続性を検証するテスト。そのようなテストの詳細は、このドキュメントの範囲を超えています。 （これは、たとえば、データトラフィックと同じリンクおよびノードに沿って制御メッセージを送信することによって、または同様に、トラフィックがないことによって、およびフィードバックを提供することによって測定できます。）
Path Failure (PF)
パス障害（PF）
Path failure is a fault detected by MPLS-based recovery mechanisms, which is defined as the failure of the liveness message test or a path continuity test, which indicates that path connectivity is lost.
パス障害は、MPLSベースの回復メカニズムによって検出される障害です。これは、活性メッセージテストまたはパス接続性テストの障害として定義され、パス接続が失われたことを示します。
Path Degraded (PD)
パスの劣化（PD）
Path degraded is a fault detected by MPLS-based recovery mechanisms that indicates that the quality of the path is unacceptable.
パスの劣化は、MPLSベースの回復メカニズムによって検出された障害であり、パスの品質が許容できないことを示します。
Link Failure (LF)
リンク障害（LF）
A lower layer fault indicating that link continuity is lost. This may be communicated to the MPLS-based recovery mechanisms by the lower layer.
リンクの連続性が失われたことを示す下位層の障害。これは、下位層によってMPLSベースの回復メカニズムに伝達される場合があります。
Link Degraded (LD)
リンク劣化（LD）
A lower layer indication to MPLS-based recovery mechanisms that the link is performing below an acceptable level.
リンクが許容レベルを下回って実行されていることをMPLSベースの回復メカニズムに通知する下位層。
Fault Indication Signal (FIS)
障害表示信号（FIS）
A signal that indicates that a fault along a path has occurred. It is relayed by each intermediate LSR to its upstream or downstream neighbor, until it reaches an LSR that is setup to perform MPLS recovery (the POR). The FIS is transmitted periodically by the node/nodes closest to the point of failure, for some configurable length of time or until the transmitting node receives an acknowledgement from its neighbor.
パスに沿った障害が発生したことを示す信号。 MPLSリカバリー（POR）を実行するように設定されたLSRに到達するまで、各中間LSRによってアップストリームまたはダウンストリームのネイバーにリレーされます。 FISは、構成可能な時間の長さの間、または送信ノードが隣接ノードから確認応答を受信するまで、障害点に最も近いノードによって定期的に送信されます。
Fault Recovery Signal (FRS)
障害回復信号（FRS）
A signal that indicates a fault along a working path has been repaired. Again, like the FIS, it is relayed by each intermediate LSR to its upstream or downstream neighbor, until is reaches the LSR that performs recovery of the original path. The FRS is transmitted periodically by the node/nodes closest to the point of failure, for some configurable length of time or until the transmitting node receives an acknowledgement from its neighbor.
現用パスに沿った障害を示す信号が修復されました。再び、FISと同様に、元のパスの回復を実行するLSRに到達するまで、各中間LSRによってアップストリームまたはダウンストリームのネイバーに中継されます。 FRSは、構成可能な時間の長さの間、または送信ノードが隣接ノードから確認応答を受信するまで、障害点に最も近いノードによって定期的に送信されます。
FIS: Fault Indication Signal. FRS: Fault Recovery Signal. LD: Link Degraded. LF: Link Failure. PD: Path Degraded. PF: Path Failure. PML: Path Merge LSR. PG: Path Group. POR: Point of Repair. PPG: Protected Path Group. PTP: Protected Traffic Portion. PSL: Path Switch LSR.
FIS：障害表示信号。 FRS：障害回復信号。 LD：リンクの劣化。 LF：リンク障害。 PD：パスの劣化。 PF：パス障害。 PML：Path Merge LSR。 PG：パスグループ。 POR：ポイントオブリペア。 PPG：保護されたパスグループ。 PTP：保護されたトラフィック部分。 PSL：パススイッチLSR。
MPLS-based recovery refers to the ability to effect quick and complete restoration of traffic affected by a fault in an MPLS-enabled network. The fault may be detected on the IP layer or in lower layers over which IP traffic is transported. Fastest MPLS recovery is assumed to be achieved with protection switching and may be viewed as the MPLS LSR switch completion time that is comparable to, or equivalent to, the 50 ms switch-over completion time of the SONET layer. Further, MPLS-based recovery may provide bandwidth protection for paths that require it. This section provides a discussion of the concepts and principles of MPLS-based recovery. The concepts are presented in terms of atomic or primitive terms that may be combined to specify recovery approaches. We do not make any assumptions about the underlying layer 1 or layer 2 transport mechanisms or their recovery mechanisms.
MPLSベースのリカバリとは、MPLS対応ネットワークの障害の影響を受けたトラフィックを迅速かつ完全に復元する機能を指します。障害は、IPトラフィックが転送されるIP層または下位層で検出される場合があります。最速のMPLS回復は保護切り替えで達成されると想定され、SONETレイヤーの50ミリ秒の切り替え完了時間と同等または同等のMPLS LSRスイッチ完了時間と見なすことができます。さらに、MPLSベースのリカバリは、それを必要とするパスに帯域幅保護を提供する場合があります。このセクションでは、MPLSベースのリカバリの概念と原則について説明します。概念は、回復アプローチを指定するために組み合わせることができるアトミックまたはプリミティブの用語で提示されます。基礎となるレイヤー1またはレイヤー2のトランスポートメカニズムやその回復メカニズムについては、想定していません。
An LSR may support any or all of the following recovery options on a per-path basis:
LSRは、パスごとに以下の回復オプションの一部またはすべてをサポートします。
Default-recovery (No MPLS-based recovery enabled): Traffic on the working path is recovered only via Layer 3 or IP rerouting or by some lower layer mechanism such as SONET APS. This is equivalent to having no MPLS-based recovery. This option may be used for low priority traffic or for traffic that is recovered in another way (for example load shared traffic on parallel working paths may be automatically recovered upon a fault along one of the working paths by distributing it among the remaining working paths).
デフォルトのリカバリー（MPLSベースのリカバリーは使用不可）：現用パスのトラフィックは、レイヤー3またはIP再ルーティングを介して、またはSONET APSなどの下位レイヤーメカニズムによってのみリカバリーされます。これは、MPLSベースのリカバリがない場合と同じです。このオプションは、優先度の低いトラフィックまたは別の方法で回復されるトラフィックに使用できます（たとえば、並列の作業パスの負荷共有トラフィックは、残りの作業パスに分散することにより、作業パスの1つに沿った障害時に自動的に回復できます）。 。
Recoverable (MPLS-based recovery enabled): This working path is recovered using one or more recovery paths, either via rerouting or via protection switching.
回復可能（MPLSベースの回復が有効）：この作業パスは、1つ以上の回復パスを使用して、再ルーティングまたは保護切り替えによって回復されます。
There are three options for the initiation of the recovery path setup. The active and recovery paths may be established by using either RSVP-TE [RFC2205][RFC3209] or CR-LDP [RFC3212], or by any other means including SNMP.
リカバリー・パスのセットアップを開始するには、3つのオプションがあります。アクティブパスとリカバリパスは、RSVP-TE [RFC2205] [RFC3209]またはCR-LDP [RFC3212]のいずれかを使用するか、SNMPを含む他の方法で確立できます。
Pre-established:
事前に確立済み：
This is the same as the protection switching option. Here a recovery path(s) is established prior to any failure on the working path. The path selection can either be determined by an administrative centralized tool, or chosen based on some algorithm implemented at the PSL and possibly intermediate nodes. To guard against the situation when the pre-established recovery path fails before or at the same time as the working path, the recovery path should have secondary configuration options as explained in Section 3.3 below.
これは、保護切り替えオプションと同じです。ここでは、作業パスで障害が発生する前にリカバリパスが確立されます。パスの選択は、集中管理ツールによって決定するか、PSLおよび場合によっては中間ノードに実装されているアルゴリズムに基づいて選択できます。事前に確立された復旧パスが現用パスの前または同時に失敗した場合に備えて、復旧パスには、以下のセクション3.3で説明するように、セカンダリ構成オプションが必要です。
Pre-Qualified:
事前認定済み：
A pre-established path need not be created, it may be pre-qualified. A pre-qualified recovery path is not created expressly for protecting the working path, but instead is a path created for other purposes that is designated as a recovery path after determining that it is an acceptable alternative for carrying the working path traffic. Variants include the case where an optical path or trail is configured, but no switches are set.
事前に確立されたパスを作成する必要はありません。事前に修飾されている場合があります。事前修飾されたリカバリパスは、現用パスを保護するために明示的に作成されるのではなく、現用パストラフィックを伝送するための受け入れ可能な代替手段であると判断した後、リカバリパスとして指定される他の目的のために作成されたパスです。バリアントには、光パスまたはトレイルが構成されているが、スイッチが設定されていない場合が含まれます。
Established-on-Demand:
オンデマンドで確立：
This is the same as the rerouting option. Here, a recovery path is established after a failure on its working path has been detected and notified to the PSL. The recovery path may be pre-computed or computed on demand, which influences recovery times.
これは、再ルーティングオプションと同じです。ここで、復旧パスは、その現用パスの障害が検出され、PSLに通知された後に確立されます。リカバリパスは、事前計算またはオンデマンドで計算され、リカバリ時間に影響します。
A recovery path may support the same traffic contract as the working path, or it may not. We will distinguish these two situations by using different additive terms. If the recovery path is capable of replacing the working path without degrading service, it will be called an equivalent recovery path. If the recovery path lacks the resources (or resource reservations) to replace the working path without degrading service, it will be called a limited recovery path. Based on this, there are two options for the initiation of resource allocation:
リカバリパスは、現用パスと同じトラフィックコントラクトをサポートする場合とサポートしない場合があります。異なる加法用語を使用して、これら2つの状況を区別します。復旧パスがサービスを低下させることなく現用パスを置き換えることができる場合、同等の復旧パスと呼ばれます。復旧パスに、サービスを低下させることなく現用パスを置き換えるためのリソース（またはリソース予約）がない場合、限定復旧パスと呼ばれます。これに基づいて、リソース割り当ての開始には2つのオプションがあります。
Pre-reserved:
事前予約：
This option applies only to protection switching. Here a pre-established recovery path reserves required resources on all hops along its route during its establishment. Although the reserved resources (e.g., bandwidth and/or buffers) at each node cannot be used to admit more working paths, they are available to be used by all traffic that is present at the node before a failure occurs. The resources held by a set of recovery paths may be shared if they protect resources that are not simultaneously subject to failure.
このオプションは、保護切り替えにのみ適用されます。ここでは、事前に確立された回復パスが、確立中にそのルートに沿ったすべてのホップで必要なリソースを予約します。各ノードで予約されているリソース（帯域幅やバッファーなど）を使用して、より多くの現用パスを許可することはできませんが、障害が発生する前にノードに存在するすべてのトラフィックで使用できます。障害が同時に発生しないリソースを保護する場合、回復パスのセットが保持するリソースを共有できます。
Reserved-on-Demand:
予約オンデマンド：
This option may apply either to rerouting or to protection switching. Here a recovery path reserves the required resources after a failure on the working path has been detected and notified to the PSL and before the traffic on the working path is switched over to the recovery path.
このオプションは、再ルーティングまたは保護切り替えに適用できます。ここで、復旧パスは、現用パスの障害が検出されてPSLに通知された後、現用パスのトラフィックが復旧パスに切り替わる前に、必要なリソースを予約します。
Note that under both the options above, depending on the amount of resources reserved on the recovery path, it could either be an equivalent recovery path or a limited recovery path.
上記の両方のオプションでは、リカバリパスで予約されているリソースの量に応じて、同等のリカバリパスまたは制限されたリカバリパスのいずれかになる可能性があることに注意してください。
The resources (bandwidth, buffers, processing) on the recovery path may be used to carry either a copy of the working path traffic or extra traffic that is displaced when a protection switch occurs. This leads to two subtypes of protection switching.
リカバリパス上のリソース（帯域幅、バッファ、処理）は、現用パストラフィックのコピー、または保護切り替えが発生したときに置き換えられる追加のトラフィックを伝送するために使用できます。これにより、2つのサブタイプの保護切り替えが発生します。
In 1+1 ("one plus one") protection, the resources (bandwidth, buffers, processing capacity) on the recovery path are fully reserved, and carry the same traffic as the working path. Selection between the traffic on the working and recovery paths is made at the path merge LSR (PML). In effect the PSL function is deprecated to establishment of the working and recovery paths and a simple replication function. The recovery intelligence is delegated to the PML.
1 + 1（「1プラス1」）保護では、リカバリー・パス上のリソース（帯域幅、バッファー、処理能力）が完全に予約され、現用パスと同じトラフィックを伝送します。現用パスと復旧パスのトラフィック間の選択は、パスマージLSR（PML）で行われます。実際には、PSL機能は、作業パスとリカバリパスの確立、および単純なレプリケーション機能で非推奨になっています。回復インテリジェンスはPMLに委任されます。
In 1:1 ("one for one") protection, the resources (if any) allocated on the recovery path are fully available to preemptible low priority traffic except when the recovery path is in use due to a fault on the working path. In other words, in 1:1 protection, the protected traffic normally travels only on the working path, and is switched to the recovery path only when the working path has a fault. Once the protection switch is initiated, the low priority traffic being carried on the recovery path may be displaced by the protected traffic. This method affords a way to make efficient use of the recovery path resources.
1：1（「1対1」）保護では、復旧パスに割り当てられたリソース（存在する場合）は、現用パスの障害が原因で復旧パスが使用されている場合を除いて、プリエンプティブル低優先度トラフィックで完全に利用できます。つまり、1：1保護では、保護されたトラフィックは通常、現用パス上のみを移動し、現用パスに障害が発生した場合にのみリカバリパスに切り替えられます。保護切り替えが開始されると、回復パスで伝送されている優先度の低いトラフィックは、保護されたトラフィックによって置き換えられる可能性があります。この方法は、リカバリー・パス・リソースを効率的に使用する方法を提供します。
This concept can be extended to 1:n (one for n) and m:n (m for n) protection.
この概念は、1：n（nに1つ）およびm：n（nにm）の保護に拡張できます。
The intent of local repair is to protect against a link or neighbor node fault and to minimize the amount of time required for failure propagation. In local repair (also known as local recovery), the node immediately upstream of the fault is the one to initiate recovery (either rerouting or protection switching). Local repair can be of two types: Link Recovery/Restoration
ローカル修復の目的は、リンクまたは隣接ノードの障害から保護し、障害の伝播に必要な時間を最小限に抑えることです。ローカル修復（ローカル回復とも呼ばれます）では、障害のすぐ上流のノードが回復（再ルーティングまたは保護切り替え）を開始するノードです。ローカル修復には、2つのタイプがあります。リンクの回復/復元
In this case, the recovery path may be configured to route around a certain link deemed to be unreliable. If protection switching is used, several recovery paths may be configured for one working path, depending on the specific faulty link that each protects against.
この場合、回復パスは、信頼できないと見なされる特定のリンクを迂回するように構成できます。保護切り替えを使用する場合、それぞれが保護する特定の障害のあるリンクに応じて、1つの現用パスに対して複数のリカバリパスを設定できます。
Alternatively, if rerouting is used, upon the occurrence of a fault on the specified link, each path is rebuilt such that it detours around the faulty link.
または、再ルーティングが使用されている場合、指定されたリンクで障害が発生すると、各パスが再構築され、障害のあるリンクを迂回します。
In this case, the recovery path need only be disjoint from its working path at a particular link on the working path, and may have overlapping segments with the working path. Traffic on the working path is switched over to an alternate path at the upstream LSR that connects to the failed link. Link recovery is potentially the fastest to perform the switchover, and can be effective in situations where certain path components are much more unreliable than others.
この場合、リカバリパスは、作業パス上の特定のリンクで作業パスから切り離すだけでよく、作業パスと重複するセグメントがある場合があります。現用パス上のトラフィックは、障害が発生したリンクに接続するアップストリームLSRで代替パスに切り替えられます。リンクの回復は、潜在的にスイッチオーバーを実行するのに最速であり、特定のパスコンポーネントが他のものよりもはるかに信頼性が低い状況で効果的です。
Node Recovery/Restoration
ノードの回復/復元
In this case, the recovery path may be configured to route around a neighbor node deemed to be unreliable. Thus the recovery path is disjoint from the working path only at a particular node and at links associated with the working path at that node. Once again, the traffic on the primary path is switched over to the recovery path at the upstream LSR that directly connects to the failed node, and the recovery path shares overlapping portions with the working path.
この場合、回復パスは、信頼できないと見なされた隣接ノードを迂回するように構成できます。したがって、回復パスは、特定のノードおよびそのノードの現用パスに関連付けられたリンクでのみ、現用パスから切り離されます。この場合も、プライマリパスのトラフィックは、障害が発生したノードに直接接続されているアップストリームLSRでリカバリパスに切り替えられ、リカバリパスは重複している部分を現用パスと共有します。
The intent of global repair is to protect against any link or node fault on a path or on a segment of a path, with the obvious exception of the faults occurring at the ingress node of the protected path segment. In global repair, the POR is usually distant from the failure and needs to be notified by a FIS.
グローバル修復の目的は、パスまたはパスのセグメント上のリンクまたはノードの障害から保護することです。ただし、保護されたパスセグメントの入力ノードで発生する障害は明らかに例外です。グローバルな修理では、PORは通常、障害から離れており、FISから通知を受ける必要があります。
In global repair also, end-to-end path recovery/restoration applies. In many cases, the recovery path can be made completely link and node disjoint with its working path. This has the advantage of protecting against all link and node fault(s) on the working path (end-to-end path or path segment).
グローバルな修復でも、エンドツーエンドのパスの回復/復元が適用されます。多くの場合、リカバリパスを完全にリンクし、ノードを動作パスと切り離すことができます。これには、現用パス（エンドツーエンドパスまたはパスセグメント）上のすべてのリンクおよびノードの障害から保護するという利点があります。
However, it may, in some cases, be slower than local repair since the fault notification message must now travel to the POR to trigger the recovery action.
ただし、場合によっては、障害通知メッセージがPORに移動して回復アクションをトリガーする必要があるため、ローカルの修復よりも時間がかかることがあります。
It is possible to restore service without specifically recovering the faulted path.
障害が発生したパスを明確に回復しなくても、サービスを復元できます。
For example, for best effort IP service it is possible to select a recovery path that has a different egress point from the working path (i.e., there is no PML). The recovery path egress must simply be a router that is acceptable for forwarding the FEC carried by the working path (without creating looping). In an engineering context, specific alternative FEC/LSP mappings with alternate egresses can be formed.
たとえば、ベストエフォートIPサービスの場合、現用パスとは異なる出力ポイントを持つリカバリパスを選択できます（つまり、PMLはありません）。リカバリパスの出口は、（ループを作成することなく）現用パスによって伝送されたFECを転送するために受け入れ可能なルーターである必要があります。エンジニアリングのコンテキストでは、代替の出口を備えた特定の代替FEC / LSPマッピングを形成できます。
This may simplify enhancing the reliability of implicitly constructed MPLS topologies. A PSL may qualify LSP/FEC bindings as candidate recovery paths as simply link and node disjoint with the immediate downstream LSR of the working path.
これにより、暗黙的に構築されたMPLSトポロジの信頼性を高めることが簡単になります。 PSLは、LSP / FECバインディングをリカバリパスの候補として認定することができます。これは、リンクとノードが、現用パスのすぐ下流のLSRと切り離されているためです。
Multi-layer repair broadens the network designer's tool set for those cases where multiple network layers can be managed together to achieve overall network goals. Specific criteria for determining when multi-layer repair is appropriate are beyond the scope of this document.
マルチレイヤー修復により、ネットワーク設計者のツールセットが拡張され、複数のネットワークレイヤーをまとめて管理して、全体的なネットワーク目標を達成できる場合に対応できます。多層修理が適切である場合を判断するための具体的な基準は、このドキュメントの範囲外です。
A given service may cross multiple networks and these may employ different recovery mechanisms. It is possible to concatenate protection domains so that service recovery can be provided end-to-end. It is considered that the recovery mechanisms in different domains may operate autonomously, and that multiple points of attachment may be used between domains (to ensure there is no single point of failure). Alternate egress repair requires management of concatenated domains in that an explicit MPLS point of failure (the PML) is by definition excluded. Details of concatenated protection domains are beyond the scope of this document.
特定のサービスが複数のネットワークにまたがることがあり、これらは異なる回復メカニズムを使用する場合があります。サービス回復をエンドツーエンドで提供できるように、保護ドメインを連結することが可能です。異なるドメインの回復メカニズムは自律的に動作する可能性があり、複数の接続ポイントがドメイン間で使用される可能性があると考えられます（単一障害点がないことを確認するため）。代替の出力修復では、明示的なMPLS障害点（PML）が定義から除外されているため、連結されたドメインの管理が必要です。連結された保護ドメインの詳細は、このドキュメントの範囲外です。
Path mapping refers to the methods of mapping traffic from a faulty working path on to the recovery path. There are several options for this, as described below. Note that the options below should be viewed as atomic terms that only describe how the working and protection paths are mapped to each other. The issues of resource reservation along these paths, and how switchover is actually performed lead to the more commonly used composite terms, such as 1+1 and 1:1 protection, which were described in Section 4.3.1..
パスマッピングとは、障害のある現用パスから回復パスにトラフィックをマッピングする方法を指します。以下に説明するように、これにはいくつかのオプションがあります。以下のオプションは、現用パスと保護パスが相互にどのようにマッピングされるかを説明するだけのアトミック用語として表示する必要があることに注意してください。これらのパスに沿ったリソース予約の問題、およびスイッチオーバーが実際にどのように実行されるかにより、セクション4.3.1で説明されている1 + 1および1：1保護などのより一般的に使用される複合用語が発生します。
1-to-1 Protection
1対1の保護
In 1-to-1 protection the working path has a designated recovery path that is only to be used to recover that specific working path.
1対1保護では、現用パスに指定された復旧パスがあり、その特定の現用パスの復旧にのみ使用されます。
n-to-1 Protection
n対1の保護
In n-to-1 protection, up to n working paths are protected using only one recovery path. If the intent is to protect against any single fault on any of the working paths, the n working paths should be diversely routed between the same PSL and PML. In some cases, handshaking between PSL and PML may be required to complete the recovery, the details of which are beyond the scope of this document.
n対1の保護では、1つの回復パスのみを使用して、最大n個の作業パスが保護されます。いずれかの現用パスの単一の障害から保護することを意図している場合、n個の現用パスは、同じPSLとPMLの間でさまざまにルーティングする必要があります。場合によっては、回復を完了するためにPSLとPML間のハンドシェイクが必要になることがありますが、その詳細はこのドキュメントの範囲外です。
n-to-m Protection
n対mの保護
In n-to-m protection, up to n working paths are protected using m recovery paths. Once again, if the intent is to protect against any single fault on any of the n working paths, the n working paths and the m recovery paths should be diversely routed between the same PSL and PML. In some cases, handshaking between PSL and PML may be required to complete the recovery, the details of which are beyond the scope of this document. n-to-m protection is for further study.
n対mの保護では、m個のリカバリパスを使用して、最大n個の作業パスが保護されます。この場合も、n個の動作パスのいずれかで単一の障害から保護することが目的である場合、n個の動作パスとm個のリカバリパスは、同じPSLとPMLの間でさまざまにルーティングする必要があります。場合によっては、回復を完了するためにPSLとPML間のハンドシェイクが必要になることがありますが、その詳細はこのドキュメントの範囲外です。 n対mの保護は、今後の検討課題です。
Split Path Protection
スプリットパス保護
In split path protection, multiple recovery paths are allowed to carry the traffic of a working path based on a certain configurable load splitting ratio. This is especially useful when no single recovery path can be found that can carry the entire traffic of the working path in case of a fault. Split path protection may require handshaking between the PSL and the PML(s), and may require the PML(s) to correlate the traffic arriving on multiple recovery paths with the working path. Although this is an attractive option, the details of split path protection are beyond the scope of this document.
スプリットパス保護では、特定の構成可能な負荷分割比に基づいて、複数のリカバリパスが現用パスのトラフィックを伝送することができます。これは、障害発生時に現用パスのトラフィック全体を伝送できる単一のリカバリパスが見つからない場合に特に役立ちます。スプリットパス保護では、PSLとPMLの間のハンドシェイクが必要になる場合があり、PMLが複数のリカバリパスに到達するトラフィックを現用パスと相関させる必要がある場合があります。これは魅力的なオプションですが、スプリットパス保護の詳細はこのドキュメントの範囲を超えています。
It may be convenient, in some cases, to create a "bypass tunnel" for a PPG between a PSL and PML, thereby allowing multiple recovery paths to be transparent to intervening LSRs [RFC2702]. In this case, one LSP (the tunnel) is established between the PSL and PML following an acceptable route and a number of recovery paths can be supported through the tunnel via label stacking. It is not necessary to apply label stacking when using a bypass tunnel. A bypass tunnel can be used with any of the path mapping options discussed in the previous section.
場合によっては、PSLとPMLの間にPPGの「バイパストンネル」を作成すると、介在するLSR [RFC2702]に対して複数のリカバリパスを透過的にできるので便利です。この場合、許容可能なルートに従ってPSLとPMLの間に1つのLSP（トンネル）が確立され、ラベルスタッキングを介してトンネルを介して複数のリカバリパスをサポートできます。バイパストンネルを使用する場合は、ラベルスタッキングを適用する必要はありません。バイパストンネルは、前のセクションで説明した任意のパスマッピングオプションで使用できます。
As with recovery paths, the bypass tunnel may or may not have resource reservations sufficient to provide recovery without service degradation. It is possible that the bypass tunnel may have sufficient resources to recover some number of working paths, but not all at the same time. If the number of recovery paths carrying traffic in the tunnel at any given time is restricted, this is similar to the n-to-1 or n-to-m protection cases mentioned in Section 3.4.2.
リカバリパスと同様に、バイパストンネルには、サービスを低下させることなくリカバリを提供するのに十分なリソース予約がある場合とない場合があります。バイパストンネルには、いくつかの現用パスを回復するのに十分なリソースがある可能性がありますが、すべて同時にではありません。トンネル内の任意の時点でトラフィックを伝送するリカバリパスの数が制限されている場合、これはセクション3.4.2で説明したn対1またはn対mの保護ケースと同様です。
Another dimension of recovery considers the amount of traffic requiring protection. This may range from a fraction of a path to a bundle of paths.
回復の別の側面では、保護が必要なトラフィックの量を考慮します。これは、パスの一部からパスのバンドルまでさまざまです。
This option allows for the protection of a fraction of traffic within the same path. The portion of the traffic on an individual path that requires protection is called a protected traffic portion (PTP). A single path may carry different classes of traffic, with different protection requirements. The protected portion of this traffic may be identified by its class, as for example, via the EXP bits in the MPLS shim header or via the priority bit in the ATM header.
このオプションにより、同じパス内の一部のトラフィックを保護できます。個々のパス上のトラフィックの保護が必要な部分は、保護されたトラフィック部分（PTP）と呼ばれます。単一のパスは、さまざまな保護要件を持つさまざまなクラスのトラフィックを伝送できます。このトラフィックの保護された部分は、そのクラスによって識別できます。たとえば、MPLSシムヘッダーのEXPビットや、ATMヘッダーの優先ビットを使用できます。
Bundling is a technique used to group multiple working paths together in order to recover them simultaneously. The logical bundling of multiple working paths requiring protection, each of which is routed identically between a PSL and a PML, is called a protected path group (PPG). When a fault occurs on the working path carrying the PPG, the PPG as a whole can be protected either by being switched to a bypass tunnel or by being switched to a recovery path.
バンドリングは、複数の作業パスをグループ化して同時に回復するために使用される手法です。保護が必要な複数の現用パスを論理的に束ね、それぞれをPSLとPMLの間で同じようにルーティングすることを、保護パスグループ（PPG）と呼びます。 PPGを伝送する現用パスで障害が発生した場合、バイパストンネルに切り替えるか、復旧パスに切り替えることにより、PPG全体を保護できます。
In the case of pre-reserved recovery paths, there is the question of what use these resources may be put to when the recovery path is not in use. There are two options:
事前予約されたリカバリパスの場合、リカバリパスが使用されていないときにこれらのリソースをどのように使用できるかという問題があります。 2つのオプションがあります。
Dedicated-resource: If the recovery path resources are dedicated, they may not be used for anything except carrying the working traffic. For example, in the case of 1+1 protection, the working traffic is always carried on the recovery path. Even if the recovery path is not always carrying the working traffic, it may not be possible or desirable to allow other traffic to use these resources.
専用リソース：リカバリー・パス・リソースが専用の場合、それらは、作業トラフィックの搬送以外には使用できません。たとえば、1 + 1保護の場合、現用トラフィックは常にリカバリパスで伝送されます。復旧パスが常に動作中のトラフィックを伝送しているわけではない場合でも、他のトラフィックがこれらのリソースを使用できるようにすることは不可能または望ましくない場合があります。
Extra-traffic-allowed: If the recovery path only carries the working traffic when the working path fails, then it is possible to allow extra traffic to use the reserved resources at other times. Extra traffic is, by definition, traffic that can be displaced (without violating service agreements) whenever the recovery path resources are needed for carrying the working path traffic.
Extra-traffic-allowed：現用パスに障害が発生したときに復旧パスが現用トラフィックのみを伝送する場合、追加トラフィックが他の時間に予約済みリソースを使用できるようにすることが可能です。エクストラトラフィックは、定義上、現用パストラフィックを伝送するためにリカバリパスリソースが必要なときはいつでも（サービス契約に違反することなく）移動できるトラフィックです。
Shared-resource: A shared recovery resource is dedicated for use by multiple primary resources that (according to SRLGs) are not expected to fail simultaneously.
共有リソース：共有リカバリリソースは、（SRLGに従って）同時に障害が発生するとは予想されない複数のプライマリリソース専用です。
MPLS recovery is initiated after the detection of either a lower layer fault or a fault at the IP layer or in the operation of MPLS-based mechanisms. We consider four classes of impairments: Path Failure, Path Degraded, Link Failure, and Link Degraded.
MPLSリカバリは、下位層の障害またはIP層の障害の検出後、またはMPLSベースのメカニズムの動作中に開始されます。障害には、パス障害、パスの劣化、リンクの障害、リンクの劣化の4つのクラスがあります。
Path Failure (PF) is a fault that indicates to an MPLS-based recovery scheme that the connectivity of the path is lost. This may be detected by a path continuity test between the PSL and PML. Some, and perhaps the most common, path failures may be detected using a link probing mechanism between neighbor LSRs. An example of a probing mechanism is a liveness message that is exchanged periodically along the working path between peer LSRs [MPLS-PATH]. For either a link probing mechanism or path continuity test to be effective, the test message must be guaranteed to follow the same route as the working or recovery path, over the segment being tested. In addition, the path continuity test must take the path merge points into consideration. In the case of a bi-directional link implemented as two unidirectional links, path failure could mean that either one or both unidirectional links are damaged.
パス障害（PF）は、パスの接続が失われたことをMPLSベースの回復スキームに示す障害です。これは、PSLとPML間のパス連続性テストによって検出される場合があります。いくつかの、そしておそらく最も一般的なパス障害は、隣接するLSR間のリンク調査メカニズムを使用して検出される場合があります。プロービングメカニズムの例は、ピアLSR [MPLS-PATH]間の現用パスに沿って定期的に交換される活性メッセージです。リンクプローブメカニズムまたはパス連続性テストのいずれかを有効にするには、テストメッセージが、テスト中のセグメント上で、現用パスまたは復旧パスと同じルートをたどることが保証されている必要があります。さらに、パスの連続性テストでは、パスのマージポイントを考慮する必要があります。 2つの単方向リンクとして実装された双方向リンクの場合、パス障害は片方または両方の片方向リンクが破損していることを意味する場合があります。
Path Degraded (PD) is a fault that indicates to MPLS-based recovery schemes/mechanisms that the path has connectivity, but that the quality of the connection is unacceptable. This may be detected by a path performance monitoring mechanism, or some other mechanism for determining the error rate on the path or some portion of the path. This is local to the LSR and consists of excessive discarding of packets at an interface, either due to label mismatch or due to TTL errors, for example.
Path Degraded（PD）は、MPLSベースの回復スキーム/メカニズムに対して、パスに接続性があるが、接続の品質が許容できないことを示す障害です。これは、パスパフォーマンスモニタリングメカニズム、またはパスまたはパスの一部のエラーレートを判別する他のメカニズムによって検出される場合があります。これはLSRにローカルであり、たとえば、ラベルの不一致やTTLエラーが原因で、インターフェイスでのパケットの過剰な廃棄で構成されています。
Link Failure (LF) is an indication from a lower layer that the link over which the path is carried has failed. If the lower layer supports detection and reporting of this fault (that is, any fault that indicates link failure e.g., SONET LOS (Loss of Signal)), this may be used by the MPLS recovery mechanism. In some cases, using LF indications may provide faster fault detection than using only MPLS-based fault detection mechanisms.
リンク障害（LF）は、パスが実行されているリンクで障害が発生したことを下位層から示しています。下位層がこの障害（つまり、SONET LOS（信号消失）などのリンク障害を示す障害）の検出と報告をサポートしている場合、これはMPLS回復メカニズムで使用されます。場合によっては、LFインジケーションを使用すると、MPLSベースの障害検出メカニズムのみを使用するよりも高速な障害検出が提供されることがあります。
Link Degraded (LD) is an indication from a lower layer that the link over which the path is carried is performing below an acceptable level. If the lower layer supports detection and reporting of this fault, it may be used by the MPLS recovery mechanism. In some cases, using LD indications may provide faster fault detection than using only MPLS-based fault detection mechanisms.
Link Degraded（LD）は、パスが実行されているリンクのパフォーマンスが許容レベルを下回っていることを下位層から示しています。下位層がこの障害の検出と報告をサポートしている場合、それはMPLS回復メカニズムによって使用される可能性があります。場合によっては、LDインジケーションを使用すると、MPLSベースの障害検出メカニズムのみを使用するよりも高速な障害検出が提供されることがあります。
MPLS-based recovery relies on rapid and reliable notification of faults. Once a fault is detected, the node that detected the fault must determine if the fault is severe enough to require path recovery. If the node is not capable of initiating direct action (e.g., as a point of repair, POR) the node should send out a notification of the fault by transmitting a FIS to the POR. This can take several forms:
MPLSベースの回復は、障害の迅速で信頼性の高い通知に依存しています。障害が検出されると、障害を検出したノードは、障害がパスの回復を必要とするほど深刻かどうかを判断する必要があります。ノードが直接アクションを開始できない場合（たとえば、修理のポイントとしてPOR）、ノードはFISをPORに送信することによって障害の通知を送信する必要があります。これにはいくつかの形式があります。
(i) control plane messaging: relayed hop-by-hop along the path upstream of the failed LSP until a POR is reached. (ii) user plane messaging: sent downstream to the PML, which may take corrective action (as a POR for 1+1) or communicate with a POR upstream (for 1:n) by any of several means: - control plane messaging - user plane return path (either through a bi-directional LSP or via other means)
（i）コントロールプレーンメッセージング：PORに到達するまで、障害が発生したLSPの上流のパスに沿ってホップバイホップで中継されます。 （ii）ユーザープレーンメッセージング：下流でPMLに送信され、（1 + 1のPORとして）修正アクションを実行するか、いくつかの手段のいずれかによってPORアップストリーム（1：nの場合）と通信します。-コントロールプレーンメッセージング-ユーザープレーンのリターンパス（双方向LSPまたはその他の手段による）
Since the FIS is a control message, it should be transmitted with high priority to ensure that it propagates rapidly towards the affected POR(s). Depending on how fault notification is configured in the LSRs of an MPLS domain, the FIS could be sent either as a Layer 2 or Layer 3 packet [MPLS-PATH]. The use of a Layer 2-based notification requires a Layer 2 path direct to the POR. An example of a FIS could be the liveness message sent by a downstream LSR to its upstream neighbor, with an optional fault notification field set or it can be implicitly denoted by a teardown message. Alternatively, it could be a separate fault notification packet. The intermediate LSR should identify which of its incoming links to propagate the FIS on.
FISは制御メッセージであるため、影響を受けるPORに向けて迅速に伝播することを保証するために、高い優先度で送信する必要があります。 MPLSドメインのLSRでの障害通知の構成方法に応じて、FISはレイヤー2またはレイヤー3パケット[MPLS-PATH]として送信できます。レイヤ2ベースの通知を使用するには、PORへの直接のレイヤ2パスが必要です。 FISの例としては、オプションの障害通知フィールドが設定されたダウンストリームLSRからアップストリームネイバーに送信される活性メッセージなどがあります。また、ティアダウンメッセージで暗黙的に示すこともできます。または、個別の障害通知パケットである場合もあります。中間LSRは、FISを伝播する着信リンクを特定する必要があります。
The activation of an MPLS protection switch following the detection or notification of a fault requires a trigger mechanism at the PSL. MPLS protection switching may be initiated due to automatic inputs or external commands. The automatic activation of an MPLS protection switch results from a response to a defect or fault conditions detected at the PSL or to fault notifications received at the PSL. It is possible that the fault detection and trigger mechanisms may be combined, as is the case when a PF, PD, LF, or LD is detected at a PSL and triggers a protection switch to the recovery path. In most cases, however, the detection and trigger mechanisms are distinct, involving the detection of fault at some intermediate LSR followed by the propagation of a fault notification to the POR via the FIS, which serves as the protection switch trigger at the POR. MPLS protection switching in response to external commands results when the operator initiates a protection switch by a command to a POR (or alternatively by a configuration command to an intermediate LSR, which transmits the FIS towards the POR).
障害の検出または通知に続くMPLS保護スイッチのアクティブ化には、PSLでのトリガーメカニズムが必要です。自動入力または外部コマンドにより、MPLS保護切り替えが開始される場合があります。 MPLS保護スイッチの自動アクティブ化は、PSLで検出された障害または障害状態への応答、またはPSLで受信された障害通知に起因します。 PSLでPF、PD、LF、またはLDが検出され、リカバリパスへの保護切り替えがトリガーされる場合のように、障害検出メカニズムとトリガーメカニズムを組み合わせることができます。ただし、ほとんどの場合、検出とトリガーのメカニズムは異なり、中間のLSRでの障害の検出に続いて、障害通知がFIS経由でPORに伝搬されます。これは、PORでの保護スイッチトリガーとして機能します。外部コマンドに応じたMPLS保護切り替えは、オペレーターがPORへのコマンド（または、代わりにFISをPORに送信する中間LSRへの構成コマンド）によって保護切り替えを開始すると発生します。
Note that the PF fault applies to hard failures (fiber cuts, transmitter failures, or LSR fabric failures), as does the LF fault, with the difference that the LF is a lower layer impairment that may be communicated to MPLS-based recovery mechanisms. The PD (or LD) fault, on the other hand, applies to soft defects (excessive errors due to noise on the link, for instance). The PD (or LD) results in a fault declaration only when the percentage of lost packets exceeds a given threshold, which is provisioned and may be set based on the service level agreement(s) in effect between a service provider and a customer.
PF障害は、LF障害と同様にハード障害（ファイバー切断、トランスミッター障害、またはLSRファブリック障害）に適用されることに注意してください。ただし、LFは、MPLSベースの回復メカニズムに伝達される可能性のある下位層の障害です。一方、PD（またはLD）障害は、ソフト障害（たとえば、リンク上のノイズによる過度のエラー）に適用されます。 PD（またはLD）は、失われたパケットのパーセンテージがプロビジョニングされ、サービスプロバイダーとカスタマーの間で有効なサービスレベルアグリーメントに基づいて設定される可能性がある所定のしきい値を超えた場合にのみ、障害宣言になります。
After a fault is detected or FIS is received by the POR, the recovery action involves either a rerouting or protection switching operation. In both scenarios, the next hop label forwarding entry for a recovery path is bound to the working path.
障害が検出された後、またはFISがPORによって受信された後の回復アクションには、再ルーティングまたは保護切り替え操作が含まれます。どちらのシナリオでも、リカバリパスのネクストホップラベル転送エントリは、現用パスにバインドされています。
When traffic is flowing on the recovery path, decisions can be made as to whether to let the traffic remain on the recovery path and consider it as a new working path or to do a switch back to the old or to a new working path. This post recovery operation has two styles, one where the protection counterparts, i.e., the working and recovery path, are fixed or "pinned" to their routes, and one in which the PSL or other network entity with real-time knowledge of failure dynamically performs re-establishment or controlled rearrangement of the paths comprising the protected service.
トラフィックがリカバリパスを流れている場合、トラフィックをリカバリパスに残して新しい作業パスと見なすか、古いまたは新しい作業パスに戻すかを決定できます。このポストリカバリオペレーションには2つのスタイルがあります。1つは保護カウンターパート、つまり作業パスとリカバリパスがルートに固定または「固定」されているスタイルと、PSLまたは他のネットワークエンティティが動的に障害をリアルタイムで把握しているスタイルです。保護されたサービスを構成するパスの再確立または制御された再配置を実行します。
For fixed protection counterparts the PSL will be pre-configured with the appropriate behavior to take when the original fixed path is restored to service. The choices are revertive and non-revertive mode. The choice will typically be dependent on relative costs of the working and protection paths, and the tolerance of the service to the effects of switching paths yet again. These protection modes indicate whether or not there is a preferred path for the protected traffic.
固定保護の対応物については、PSLは、元の固定パスがサービスに復元されたときに取る適切な動作で事前構成されます。選択肢は、リバーティブモードと非リバーティブモードです。選択は通常、現用パスと保護パスの相対的なコスト、およびパスの切り替えの影響に対するサービスの許容度に依存します。これらの保護モードは、保護されたトラフィックの優先パスがあるかどうかを示します。
If the working path always is the preferred path, this path will be used whenever it is available. Thus, in the event of a fault on this path, its unused resources will not be reclaimed by the network on failure. Resources here may include assigned labels, links, bandwidth etc. If the working path has a fault, traffic is switched to the recovery path. In the revertive mode of operation, when the preferred path is restored the traffic is automatically switched back to it.
作業パスが常に優先パスである場合、このパスが使用可能な場合は常にこのパスが使用されます。したがって、このパスで障害が発生した場合、その未使用のリソースは、障害時にネットワークによって回収されません。ここのリソースには、割り当てられたラベル、リンク、帯域幅などが含まれる場合があります。現用パスに障害がある場合、トラフィックは復旧パスに切り替えられます。リバーティブ動作モードでは、優先パスが復元されると、トラフィックは自動的にそのパスに切り替えられます。
There are a number of implications to pinned working and recovery paths:
ピン留めされたワーキングパスとリカバリパスには多くの影響があります。
- upon failure and after traffic has been moved to the recovery path, the traffic is unprotected until such time as the path defect in the original working path is repaired and that path restored to service.
- 障害が発生し、トラフィックがリカバリパスに移動された後は、元の現用パスのパス障害が修復され、そのパスがサービスに復元されるまで、トラフィックは保護されません。
- upon failure and after traffic has been moved to the recovery path, the resources associated with the original path remain reserved.
- 障害発生時、およびトラフィックがリカバリパスに移動された後、元のパスに関連付けられたリソースは予約されたままになります。
In the non-revertive mode of operation, there is no preferred path or it may be desirable to minimize further disruption of the service brought on by a revertive switching operation. A switch-back to the original working path is not desired or not possible since the original path may no longer exist after the occurrence of a fault on that path. If there is a fault on the working path, traffic is switched to the recovery path. When or if the faulty path (the originally working path) is restored, it may become the recovery path (either by configuration, or, if desired, by management actions).
非リバーティブモードの動作では、優先パスが存在しないか、リバーティブスイッチング動作によって引き起こされるサービスのさらなる中断を最小限に抑えることが望ましい場合があります。元のパスで障害が発生すると元のパスが存在しなくなる可能性があるため、元の現用パスへのスイッチバックは望ましくないか、不可能です。現用パスに障害がある場合、トラフィックは回復パスに切り替えられます。障害のあるパス（元は正常に機能していたパス）が復元されると、復元パスになる可能性があります（構成によって、または必要に応じて管理アクションによって）。
In the non-revertive mode of operation, the working traffic may or may not be restored to a new optimal working path or to the original working path anyway. This is because it might be useful, in some cases, to either: (a) administratively perform a protection switch back to the original working path after gaining further assurances about the integrity of the path, or (b) it may be acceptable to continue operation on the recovery path, or (c) it may be desirable to move the traffic to a new optimal working path that is calculated based on network topology and network policies. Once a new working path has been defined, an associated recovery path may be setup.
非リバーティブ操作モードでは、作業トラフィックは、新しい最適な作業パスまたは元の作業パスに復元される場合と復元されない場合があります。これは、場合によっては、（a）パスの整合性についてさらに保証を得た後、管理上、元の現用パスに保護切り替えを実行すること、または（b）続行しても問題ないことがあるからです。回復パスでの操作、または（c）ネットワークトポロジとネットワークポリシーに基づいて計算された新しい最適な動作パスにトラフィックを移動することが望ましい場合があります。新しい作業パスが定義されると、関連するリカバリパスをセットアップできます。
For dynamic protection counterparts when the traffic is switched over to a recovery path, the association between the original working path and the recovery path may no longer exist, since the original path itself may no longer exist after the fault. Instead, when the network reaches a stable state following routing convergence, the recovery path may be switched over to a different preferred path either optimization based on the new network topology and associated information or based on pre-configured information.
トラフィックが復旧パスに切り替えられたときの動的保護の対応物では、元のパス自体が障害後に存在しなくなる可能性があるため、元の現用パスと復旧パス間の関連付けが存在しなくなる可能性があります。代わりに、ルーティングの収束後にネットワークが安定した状態になると、新しいネットワークトポロジと関連情報に基づく最適化、または事前設定された情報に基づいて、リカバリパスを別の優先パスに切り替えることができます。
Dynamic protection counterparts assume that upon failure, the PSL or other network entity will establish new working paths if another switch-over will be performed.
動的保護の対応者は、障害発生時に、別のスイッチオーバーが実行される場合、PSLまたは他のネットワークエンティティが新しい現用パスを確立すると想定しています。
MPLS restoration deals with returning the working traffic from the recovery path to the original or a new working path. Restoration is performed by the PSL either upon receiving notification, via FRS, that the working path is repaired, or upon receiving notification that a new working path is established.
MPLS復元では、復旧パスから元のまたは新しい現用パスに現用トラフィックを戻すことを扱います。復元は、PSRによって、FRSを介して、ワーキングパスが修復されたという通知を受信したとき、または新しいワーキングパスが確立されたという通知を受信したときに実行されます。
For fixed counterparts in revertive mode, an LSR that detected the fault on the working path also detects the restoration of the working path. If the working path had experienced a LF defect, the LSR detects a return to normal operation via the receipt of a liveness message from its peer. If the working path had experienced a LD defect at an LSR interface, the LSR could detect a return to normal operation via the resumption of error-free packet reception on that interface. Alternatively, a lower layer that no longer detects a LF defect may inform the MPLS-based recovery mechanisms at the LSR that the link to its peer LSR is operational. The LSR then transmits FRS to its upstream LSR(s) that were transmitting traffic on the working path. At the point the PSL receives the FRS, it switches the working traffic back to the original working path.
リバーティブモードの固定対応の場合、現用パスの障害を検出したLSRは、現用パスの復元も検出します。現用パスでLF障害が発生した場合、LSRは、ピアからの活性メッセージの受信により、通常の動作への復帰を検出します。 LSRインターフェースで現用パスにLD障害が発生した場合、LSRは、そのインターフェースでエラーのないパケット受信を再開することにより、通常の動作への復帰を検出できます。または、LF障害を検出しなくなった下位層は、LSRのMPLSベースの回復メカニズムに、ピアLSRへのリンクが動作していることを通知する場合があります。次に、LSRは、現用パスでトラフィックを送信していたアップストリームLSRにFRSを送信します。 PSLがFRSを受信した時点で、現用トラフィックを元の現用パスに切り替えます。
A similar scheme is used for dynamic counterparts where e.g., an update of topology and/or network convergence may trigger installation or setup of new working paths and may send notification to the PSL to perform a switch over.
同様のスキームは動的トポロジーにも使用されます。たとえば、トポロジーの更新やネットワークの収束により、新しい作業パスのインストールまたはセットアップがトリガーされ、PSLに通知が送信されて切り替えが実行されます。
We note that if there is a way to transmit fault information back along a recovery path towards a PSL and if the recovery path is an equivalent working path, it is possible for the working path and its recovery path to exchange roles once the original working path is repaired following a fault. This is because, in that case, the recovery path effectively becomes the working path, and the restored working path functions as a recovery path for the original recovery path. This is important, since it affords the benefits of non-revertive switch operation outlined in Section 4.8.1, without leaving the recovery path unprotected.
障害情報をPSLに向けて復旧パスに沿って送信する方法があり、復旧パスが同等の現用パスである場合、元の現用パスが完了すると、現用パスとその復旧パスが役割を交換できることに注意してください。故障後に修理されます。その場合、復旧パスは事実上現用パスとなり、復旧した現用パスは元の復旧パスの復旧パスとして機能するからである。これは、リカバリパスを保護せずにセクション4.8.1で概説した非リバーティブスイッチ操作の利点を提供するため、重要です。
In the revertive mode, "make before break" restoration switching can be used, which is less disruptive than performing protection switching upon the occurrence of network impairments. This will minimize both packet loss and packet reordering. The controlled rearrangement of paths can also be used to satisfy traffic engineering requirements for load balancing across an MPLS domain.
リバーティブモードでは、「make before break」復元スイッチングを使用できます。これは、ネットワーク障害が発生したときに保護スイッチングを実行するよりも混乱が少なくなります。これにより、パケット損失とパケットの並べ替えの両方が最小限に抑えられます。パスの制御された再配置は、MPLSドメイン全体のロードバランシングに関するトラフィックエンジニアリング要件を満たすためにも使用できます。
Resource/performance requirements for recovery paths should be specified in terms of the following attributes:
リカバリー・パスのリソース/パフォーマンス要件は、以下の属性に関して指定する必要があります。
I. Resource Class Attribute: Equivalent Recovery Class: The recovery path has the same performance guarantees as the working path. In other words, the recovery path meets the same SLAs as the working path.
I.リソースクラス属性：同等のリカバリクラス：リカバリパスには、現用パスと同じパフォーマンス保証があります。つまり、リカバリパスは現用パスと同じSLAを満たしています。
Limited Recovery Class: The recovery path does not have the same performance guarantees as the working path.
制限付きリカバリクラス：リカバリパスには、現用パスと同じパフォーマンス保証がありません。
A. Lower Class: The recovery path has lower resource requirements or less stringent performance requirements than the working path.
A.下位クラス：リカバリパスは、現用パスよりもリソース要件が低いか、パフォーマンス要件が厳しくありません。
B. Best Effort Class: The recovery path is best effort.
B.ベストエフォートクラス：復旧パスはベストエフォートです。
II. Priority Attribute: The recovery path has a priority attribute just like the working path (i.e., the priority attribute of the associated traffic trunks). It can have the same priority as the working path or lower priority.
II。優先度属性：リカバリパスには、現用パスと同様に優先度属性があります（つまり、関連するトラフィックトランクの優先度属性）。優先度は現用パスと同じか、それより低くすることができます。
III. Preemption Attribute: The recovery path can have the same preemption attribute as the working path or a lower one.
III。プリエンプション属性：リカバリパスは、現用パスと同じプリエンプション属性を持つことができます。
The following features are desirable from an operational point of view:
運用の観点から、次の機能が望ましいです。
I. It is desirable that MPLS recovery provides an option to identify protection groups (PPGs) and protection portions (PTPs).
I. MPLSリカバリが保護グループ（PPG）と保護部分（PTP）を識別するオプションを提供することが望ましい。
II. Each PSL should be capable of performing MPLS recovery upon the detection of the impairments or upon receipt of notifications of impairments.
II。各PSLは、障害の検出時または障害の通知の受信時にMPLS回復を実行できる必要があります。
III. A MPLS recovery method should not preclude manual protection switching commands. This implies that it would be possible under administrative commands to transfer traffic from a working path to a recovery path, or to transfer traffic from a recovery path to a working path, once the working path becomes operational following a fault.
III。 MPLS回復方法は、手動の保護切り替えコマンドを妨げるべきではありません。これは、管理コマンドの下で、障害後に作業パスが動作可能になると、作業パスから回復パスにトラフィックを転送したり、回復パスから作業パスにトラフィックを転送したりできることを意味します。
IV. A PSL may be capable of performing either a switch back to the original working path after the fault is corrected or a switchover to a new working path, upon the discovery or establishment of a more optimal working path.
IV。 PSLは、障害が修正された後、元の現用パスへの切り替え、またはより最適な現用パスの検出または確立時に新しい現用パスへの切り替えを実行できる場合があります。
V. The recovery model should take into consideration path merging at intermediate LSRs. If a fault affects the merged segment, all the paths sharing that merged segment should be able to recover. Similarly, if a fault affects a non-merged segment, only the path that is affected by the fault should be recovered.
V.復旧モデルでは、中間LSRでのパスのマージを考慮する必要があります。障害がマージされたセグメントに影響を与える場合、そのマージされたセグメントを共有するすべてのパスが回復できるはずです。同様に、障害がマージされていないセグメントに影響を与える場合、障害の影響を受けるパスのみを回復する必要があります。
Possible criteria to use for comparison of MPLS-based recovery schemes are as follows:
MPLSベースのリカバリスキームの比較に使用できる基準は次のとおりです。
Recovery Time
回復時間
We define recovery time as the time required for a recovery path to be activated (and traffic flowing) after a fault. Recovery Time is the sum of the Fault Detection Time, Hold-off Time, Notification Time, Recovery Operation Time, and the Traffic Restoration Time. In other words, it is the time between a failure of a node or link in the network and the time before a recovery path is installed and the traffic starts flowing on it.
復旧時間は、障害発生後に復旧パスがアクティブになる（およびトラフィックが流れる）のに必要な時間と定義します。回復時間は、障害検出時間、ホールドオフ時間、通知時間、回復操作時間、およびトラフィック復元時間の合計です。つまり、ネットワーク内のノードまたはリンクの障害から、復旧パスがインストールされてトラフィックがそこに流れ始めるまでの時間です。
Full Restoration Time
完全な復元時間
We define full restoration time as the time required for a permanent restoration. This is the time required for traffic to be routed onto links, which are capable of or have been engineered sufficiently to handle traffic in recovery scenarios. Note that this time may or may not be different from the "Recovery Time" depending on whether equivalent or limited recovery paths are used.
完全な復元時間は、永続的な復元に必要な時間として定義されます。これは、トラフィックがリンクにルーティングされるのに必要な時間です。リンクは、回復シナリオでトラフィックを処理することができるか、十分に処理されています。この時間は、同等または限定されたリカバリパスが使用されているかどうかによって、「リカバリ時間」と異なる場合があることに注意してください。
Setup vulnerability
セットアップの脆弱性
The amount of time that a working path or a set of working paths is left unprotected during such tasks as recovery path computation and recovery path setup may be used to compare schemes. The nature of this vulnerability should be taken into account, e.g., End to End schemes correlate the vulnerability with working paths, Local Repair schemes have a topological correlation that cuts across working paths and Network Plan approaches have a correlation that impacts the entire network.
復旧パスの計算や復旧パスのセットアップなどのタスク中に、作業パスまたは作業パスのセットが保護されないままになっている時間を使用して、スキームを比較できます。この脆弱性の性質を考慮に入れる必要があります。たとえば、エンドツーエンドスキームは脆弱性をワーキングパスと相関させ、ローカル修復スキームはワーキングパスを横断するトポロジー相関を持ち、ネットワークプランアプローチはネットワーク全体に影響する相関を持ちます。
Backup Capacity
バックアップ容量
Recovery schemes may require differing amounts of "backup capacity" in the event of a fault. This capacity will be dependent on the traffic characteristics of the network. However, it may also be dependent on the particular protection plan selection algorithms as well as the signaling and re-routing methods.
リカバリスキームでは、障害発生時に異なる量の「バックアップ容量」が必要になる場合があります。この容量は、ネットワークのトラフィック特性に依存します。ただし、これは、特定の保護計画選択アルゴリズム、およびシグナリングと再ルーティングの方法にも依存する場合があります。
Additive Latency
加法潜時
Recovery schemes may introduce additive latency for traffic. For example, a recovery path may take many more hops than the working path. This may be dependent on the recovery path selection algorithms.
リカバリスキームにより、トラフィックに追加のレイテンシが生じる場合があります。たとえば、リカバリパスは、現用パスよりも多くのホップを要する場合があります。これは、リカバリパス選択アルゴリズムに依存する場合があります。
Quality of Protection
保護の品質
Recovery schemes can be considered to encompass a spectrum of "packet survivability" which may range from "relative" to "absolute". Relative survivability may mean that the packet is on an equal footing with other traffic of, as an example, the same diff-serv code point (DSCP) in contending for the resources of the portion of the network that survives the failure. Absolute survivability may mean that the survivability of the protected traffic has explicit guarantees.
回復スキームは、「相対」から「絶対」まで及ぶ「パケットの存続可能性」の範囲を含むと考えることができます。相対的な存続可能性とは、パケットが、他のトラフィックと同じように、たとえば、障害が発生してもネットワークの一部のリソースについて競合しているDiff-serv Code Point（DSCP）が同じであることを意味します。絶対的な存続可能性は、保護されたトラフィックの存続可能性が明確な保証を持っていることを意味する場合があります。
Re-ordering
再注文
Recovery schemes may introduce re-ordering of packets. Also the action of putting traffic back on preferred paths might cause packet re-ordering.
回復スキームにより、パケットの並べ替えが発生する場合があります。また、トラフィックを優先パスに戻すアクションにより、パケットの並べ替えが発生する場合があります。
State Overhead
州のオーバーヘッド
As the number of recovery paths in a protection plan grows, the state required to maintain them also grows. Schemes may require differing numbers of paths to maintain certain levels of coverage, etc. The state required may also depend on the particular scheme used for recovery. The state overhead may be a function of several parameters. For example, the number of recovery paths and the number of the protected facilities (links, nodes, or shared link risk groups (SRLGs)).
保護計画の回復パスの数が増えると、それらを維持するために必要な状態も大きくなります。スキームでは、特定のレベルのカバレッジなどを維持するために、異なる数のパスが必要になる場合があります。必要な状態は、リカバリに使用される特定のスキームにも依存します。状態のオーバーヘッドは、いくつかのパラメータの関数である場合があります。たとえば、回復パスの数と保護された施設（リンク、ノード、または共有リンクリスクグループ（SRLG））の数。
Loss
損失
Recovery schemes may introduce a certain amount of packet loss during switchover to a recovery path. Schemes that introduce loss during recovery can measure this loss by evaluating recovery times in proportion to the link speed.
リカバリスキームにより、リカバリパスへのスイッチオーバー中に一定量のパケット損失が発生する場合があります。回復中に損失をもたらすスキームは、リンク速度に比例して回復時間を評価することにより、この損失を測定できます。
In case of link or node failure a certain packet loss is inevitable.
リンクまたはノードに障害が発生した場合、特定のパケット損失は避けられません。
Coverage
カバレッジ
Recovery schemes may offer various types of failover coverage. The total coverage may be defined in terms of several metrics:
リカバリスキームは、さまざまなタイプのフェイルオーバーカバレッジを提供します。総カバレッジは、いくつかのメトリックで定義できます。
I. Fault Types: Recovery schemes may account for only link faults or both node and link faults or also degraded service. For example, a scheme may require more recovery paths to take node faults into account.
I.障害の種類：回復スキームは、リンク障害のみ、またはノードとリンクの両方の障害、またはサービスの低下を説明する場合があります。たとえば、ノードの障害を考慮するために、より多くのリカバリパスが必要になる場合があります。
II. Number of concurrent faults: dependent on the layout of recovery paths in the protection plan, multiple fault scenarios may be able to be restored.
II。同時障害の数：保護計画の復旧パスのレイアウトによっては、複数の障害シナリオを復元できる場合があります。
III. Number of recovery paths: for a given fault, there may be one or more recovery paths.
III。回復パスの数：特定の障害に対して、1つ以上の回復パスが存在する場合があります。
IV. Percentage of coverage: dependent on a scheme and its implementation, a certain percentage of faults may be covered. This may be subdivided into percentage of link faults and percentage of node faults.
IV。カバレッジのパーセンテージ：スキームとその実装に応じて、特定の割合の障害がカバーされる場合があります。これは、リンク障害の割合とノード障害の割合に分けられます。
V. The number of protected paths may effect how fast the total set of paths affected by a fault could be recovered. The ratio of protection is n/N, where n is the number of protected paths and N is the total number of paths.
V.保護されたパスの数は、障害の影響を受けたパスのセット全体を回復できる速さに影響する場合があります。保護の比率はn / Nで、nは保護されたパスの数、Nはパスの総数です。
The MPLS recovery that is specified herein does not raise any security issues that are not already present in the MPLS architecture.
ここで指定されたMPLSリカバリーは、MPLSアーキテクチャーにはまだ存在していないセキュリティー問題を引き起こしません。
Confidentiality or encryption of information on the recovery path is outside the scope of this document, but any method designed to do this in other contexts may be used with the methods described in this document.
回復パスの情報の機密性または暗号化はこのドキュメントの範囲外ですが、他のコンテキストでこれを行うように設計された方法は、このドキュメントで説明されている方法で使用できます。
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
IETFには、このドキュメントに含まれている仕様の一部またはすべてに関して主張されている知的財産権が通知されています。詳細については、主張されている権利のオンラインリストを参照してください。
We would like to thank members of the MPLS WG mailing list for their suggestions on the earlier versions of this document. In particular, Bora Akyol, Dave Allan, Dave Danenberg, Sharam Davari, and Neil Harrison whose suggestions and comments were very helpful in revising the document.
このドキュメントの以前のバージョンに関する提案をMPLS WGメーリングリストのメンバーに感謝します。特に、Bora Akyol、Dave Allan、Dave Danenberg、Sharam Davari、Neil Harrisonの3人は、ドキュメントの改訂に非常に役立ちました。
The editors would like to give very special thanks to Curtis Villamizar for his careful and extremely thorough reading of the document and for taking the time to provide numerous suggestions, which were very helpful in the last couple of revisions of the document. Thanks are also due to Adrian Farrel for a through reading of the last version of the document, and to Jean-Phillipe Vasseur and Anna Charny for several useful editorial comments and suggestions, and for input on bandwidth recovery.
編集者は、Curtis Villamizar氏が文書を注意深く非常に徹底的に読み、時間を割いて多くの提案を提供してくれたことに非常に感謝します。これは、文書の最後の数回の改訂に非常に役立ちました。また、ドキュメントの最後のバージョンを最後まで読んでいただいたAdrian Farrel、およびいくつかの有用な編集上のコメントと提案、および帯域幅回復に関する情報を提供してくれたJean-Phillipe VasseurとAnna Charnyにも感謝します。
[RFC3031] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]ローゼン、E。、ヴィスワナサン、A。、およびR.キャロン、「マルチプロトコルラベルスイッチングアーキテクチャ」、RFC 3031、2001年1月。
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
[RFC2702] Awduche、D.、Malcolm、J.、Agogbua、J.、O'Dell、M.、J。McManus、「MPLS上のトラフィックエンジニアリングの要件」、RFC 2702、1999年9月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and G. Swallow, "RSVP-TE Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE Extensions to RSVP for LSP Tunnels」、RFC 3209、2001年12月。
[RFC3212] Jamoussi, B. (Ed.), Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T. and A. Malis, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002.
[RFC3212] Jamoussi、B。（編）、Andersson、L.、Callon、R.、Dantu、R.、Wu、L.、Doolan、P.、Worster、T.、Feldman、N.、Fredette、A 。、Girish、M.、Gray、E.、Heinanen、J.、Kilty、T。、およびA. Malis、「LDPを使用した制約ベースのLSPセットアップ」、RFC 3212、2002年1月。
[MPLS-BACKUP] Vasseur, J. P., Charny, A., LeFaucheur, F., and Achirica, "MPLS Traffic Engineering Fast reroute: backup tunnel path computation for bandwidth protection", Work in Progress.
[MPLS-BACKUP] Vasseur、J。P.、Charny、A.、LeFaucheur、F。、およびAchirica、「MPLSトラフィックエンジニアリング高速リルート：帯域幅保護のためのバックアップトンネルパス計算」、作業中。
[MPLS-PATH] Haung, C., Sharma, V., Owens, K., Makam, V. "Building Reliable MPLS Networks Using a Path Protection Mechanism", IEEE Commun. Mag., Vol. 40, Issue 3, March 2002, pp. 156-162.
[MPLS-PATH] Haung、C.、Sharma、V.、Owens、K.、Makam、V。「Building Reliable MPLS Networks Using a Path Protection Mechanism」、IEEE Commun。 Mag。、Vol。 40、第3号、2002年3月、156-162ページ。
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、「Resource ReSerVation Protocol（RSVP）-Version 1 Functional Specification」、RFC 2205、1997年9月。
This document was the collective work of several individuals over a period of three years. The text and content of this document was contributed by the editors and the co-authors listed below. (The contact information for the editors appears in Section 11, and is not repeated below.)
この文書は、3年間にわたる数人の個人の共同作業でした。このドキュメントのテキストとコンテンツは、以下にリストする編集者と共著者によって寄稿されました。 （編集者の連絡先情報はセクション11にあり、以下では繰り返されません。）
Ben Mack-Crane Tellabs Operations, Inc. 1415 West Diehl Road Naperville, IL 60563
Ben Mack-Crane Tellabs Operations、Inc. 1415 West Diehl Road Naperville、IL 60563
Phone: (630) 798-6197 EMail: Ben.Mack-Crane@tellabs.com
電話：（630）798-6197メール：Ben.Mack-Crane@tellabs.com
Srinivas Makam Eshernet, Inc. 1712 Ada Ct. Naperville, IL 60540
Srinivas Makam Eshernet、Inc. 1712 Ada Ct。ネーパーヴィル、IL 60540
Phone: (630) 308-3213 EMail: Smakam60540@yahoo.com Ken Owens Edward Jones Investments 201 Progress Parkway St. Louis, MO 63146
電話：（630）308-3213メール：Smakam60540@yahoo.com Ken Owens Edward Jones Investments 201 Progress Parkway St. Louis、MO 63146
Phone: (314) 515-3431 EMail: ken.owens@edwardjones.com
電話：（314）515-3431メール：ken.owens@edwardjones.com
Changcheng Huang Carleton University Minto Center, Rm. 3082 1125 Colonial By Drive Ottawa, Ont. K1S 5B6 Canada
Changcheng Huangカールトン大学ミントセンター、Rm。 3082 1125 Colonial By Driveオタワ、オンタリオ州。 K1S 5B6カナダ
Phone: (613) 520-2600 x2477 EMail: Changcheng.Huang@sce.carleton.ca
電話：（613）520-2600 x2477メール：Changcheng.Huang@sce.carleton.ca
Jon Weil
ジョン・ウェイル
Brad Cain Storigen Systems 650 Suffolk Street Lowell, MA 01854
Brad Cain Storigen Systems 650 Suffolk Streetローウェル、MA 01854
Phone: (978) 323-4454 EMail: bcain@storigen.com
電話：（978）323-4454メール：bcain@storigen.com
Loa Andersson
ロア・アンダーソン
EMail: loa@pi.se
Bilel Jamoussi Nortel Networks 3 Federal Street, BL3-03 Billerica, MA 01821, USA
Baleel Buffalo Nortel Networks by Federal Street、BL3-03 Billerica、MA 0821、
Phone:(978) 288-4506 EMail: jamoussi@nortelnetworks.com Angela Chiu AT&T Labs-Research 200 Laurel Ave. Rm A5-1F13 Middletown , NJ 07748
電話：（978）288-4506メール：jamoussi@nortelnetworks.com Angela Chiu AT＆T Labs-Research 200 Laurel Ave. Rm A5-1F13 Middletown、NJ 07748
Phone: (732) 420-9061 EMail: chiu@research.att.com
電話：（732）420-9061メール：chiu@research.att.com
Seyhan Civanlar Lemur Networks, Inc. 135 West 20th Street, 5th Floor New York, NY 10011
Seyhan Civanlar Lemur Networks、Inc.135 West 20th Street、5th Floor New York、NY 10011
Phone: (212) 367-7676 EMail: scivanlar@lemurnetworks.com
電話：（212）367-7676メール：scivanlar@lemurnetworks.com
Vishal Sharma (Editor) Metanoia, Inc. 1600 Villa Street, Unit 352 Mountain View, CA 94041-1174
Vishal Sharma（編集者）Metanoia、Inc. 1600 Villa Street、Unit 352 Mountain View、CA 94041-1174
Phone: (650) 386-6723 EMail: v.sharma@ieee.org
電話：（650）386-6723メール：v.sharma@ieee.org
Fiffi Hellstrand (Editor) Nortel Networks St Eriksgatan 115 PO Box 6701 113 85 Stockholm, Sweden
Fiffi Hellstrand（編集者）Nortel Networks St Eriksgatan 115 PO Box 6701 113 85ストックホルム、スウェーデン
Phone: +46 8 5088 3687
EMail: fiffi@nortelnetworks.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（C）The Internet Society（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、実装を支援する派生物を、全体または一部を問わず、準備、コピー、公開、配布することができます。ただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されない一切の保証を含みません。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能への資金提供は、現在Internet Societyから提供されています。