RFC3469 日本語訳
3469 Framework for Multi-Protocol Label Switching (MPLS)-basedRecovery. V. Sharma, Ed., F. Hellstrand, Ed.. February 2003. (Format: TXT=89331 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group V. Sharma, Ed.
Request for Comments: 3469 Metanoia, Inc.
Category: Informational F. Hellstrand, Ed.
Nortel Networks
February 2003
ワーキンググループのV.シャルマ、エドをネットワークでつないでください。コメントのために以下を要求してください。 3469年のMetanoia Inc.カテゴリ: エド情報のF.Hellstrand、ノーテルは2003年2月をネットワークでつなぎます。
Framework for Multi-Protocol Label Switching (MPLS)-based Recovery
マルチプロトコルラベルスイッチングの(MPLS)ベースの回復のための枠組み
Status of this Memo
この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)インターネット協会(2003)。 All rights reserved。
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は、異なった経路で運ばれた交通の保護を提供するためにセットに手順を要求します。 これは、ラベル切り換えルータ(LSRs)が欠点検出、欠点通知、および欠点回収機構をサポートして、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
1. 序論…2 1.1. バックグラウンド…3 1.2. MPLSベースの回復に関する動機…4 1.3. 目的/目標…5 2. 概観…6 2.1. 回復はモデル化されます…7 2.1 .1 コースを変更します…7 2.1 .2 保護の切り換え…8 2.2. 回復サイクルズ…8 2.2 .1MPLS回復サイクルはモデル化されます…8 2.2 .2MPLS逆戻りサイクルはモデル化されます…10 2.2 .3のダイナミックなコースを変更しているサイクルモデル…12 2.2 .4例の回復サイクル…13 2.3. 定義と用語…14 2.3 .1 一般回復用語…14
Sharma & Hellstrand Informational [Page 1] RFC 3469 Framework for MPLS-based Recovery February 2003
MPLSベースの回復2003年2月のためのシャルマとHellstrandの情報[1ページ]のRFC3469枠組み
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
2.3.2 失敗用語…17 2.4. 略語…18 3. MPLSを拠点とする回復プリンシプルズ…18 3.1. 回復の構成…19 3.2. 経路セットアップの開始…19 3.3. 資源配分の開始…20 3.3 保護の切り換えの.1血液型亜型…21 3.4. 回復の範囲…21 3.4 .1トポロジー…21 3.4 .2経路マッピング…24 3.4 .3 Tunnelsを迂回させてください…25 3.4 .4回復粒状…25 3.4 .5 回復経路リソース使用…26 3.5. 欠点検出…26 3.6. 欠点通知…27 3.7. 操作を転換してください…28 3.7 .1回復引き金…28 3.7 .2 回復動作…29 3.8. 回復動作を掲示してください…29 3.8 .1 保護対応者を修理します…29 3.8 .2 ダイナミックな保護対応者…30 3.8 .3の王政復古と通知…31 3.8 .4 都合のよい経路(または、制御配列換え)に戻ります…31 3.9. パフォーマンス…32 4. MPLS回復機能…32 5. 比較評価基準…33 6. セキュリティ問題…35 7. 知的所有権問題…36 8. 承認…36 9. 参照…36 9.1 標準の参照…36 9.2 有益な参照…37 10. 作者を寄付します…37 11. 作者のアドレス…39 12. 完全な著作権宣言文…40
1. Introduction
1. 序論
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ベースの回復のために原則について概説して、また、異なった回復計画を比較して、評価する基礎として機能するかもしれない比較評価基準を提供します。
Sharma & Hellstrand Informational [Page 2] RFC 3469 Framework for MPLS-based Recovery February 2003
MPLSベースの回復2003年2月のためのシャルマとHellstrandの情報[2ページ]のRFC3469枠組み
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によって指定されている需要を満たすほど説明するために開発されると予想されます。
1.1. Background
1.1. バックグラウンド
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を提供する重要なコンポーネントは確かに効率的にデータを輸送する能力です。 現在のルーティング・アルゴリズムは、強健であって、生存可能ですが、それらが欠点から回復するにはかかる時間は重要である場合があります、数秒(内部のゲートウェイプロトコル(IGPs)のための)か数分(ボーダ・ゲイトウェイ・プロトコルなどの外のゲートウェイプロトコル(BGP)のための)の注文で、その間いくつかのアプリケーションのためのサービスの分裂を引き起こして。 これは高信頼性サービスを提供する目的がことであるところで状況において容認できません、最小10年代の秒のミリセカンドの注文にある回復回で。 また、IPルーティングは帯域幅回復を供給できないかもしれません、元の経路で利用可能な状態で迂回経路だけではなく、それに同等な帯域幅も供給するところで目的がことである。 (帯域幅回復計画のいくらかの近作について、読者は言及されます[MPLS- BACKUP]。) そのようなアプリケーションに関する例はVirtual Leased線サービス、証券取引所データサービス、ビデオサービス音声トラヒック(サービスにおける分裂をサービス契約か必要なレベルの品質を実現させないほど長くするすなわちあらゆるアプリケーション)ですなど。
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
制限があるという概念で現在のルーティング・アルゴリズムの回復倍を改良するのにMPLS回復を動機づけるかもしれません。MPLS回収機構[MPLS-PATH]でこれらのアルゴリズムを増大させることによって、追加改良を得ることができます。 MPLSが将来のIPを拠点とする転送ネットワークにおける選択の可能な技術であることで、MPLSが交通の保護と返還を提供できるのは、役に立ちます。 MPLSは共通制御機構と管理飛行機におけるネットワークの機能性の集合を容易にするかもしれません。 さらに、分化として保護優先を使用できました。
Sharma & Hellstrand Informational [Page 3] RFC 3469 Framework for MPLS-based Recovery February 2003
MPLSベースの回復2003年2月のためのシャルマとHellstrandの情報[3ページ]のRFC3469枠組み
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.
Virtual Leased線サービスや、高い優先権声やビデオ交通などの高信頼性を必要とするプレミアムサービスのためのメカニズム。 このドキュメントの残りはMPLSのベースの回復に枠組みを提供します。 それは、概念的なレベルで焦点を合わせられて、動機、目的、および要件を記述することになっています。 回復経路によって運ばれた交通のメカニズムの問題、方針、ルーティングプラン、および特性はこのドキュメントの範囲を超えています。
1.2. Motivation for MPLS-Based Recovery
1.2. 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ベースのRecoveryと呼ばれる)のMPLSのベースの保護は様々な意味で役に立ちます。 最も重要であるのが、(または、IP層)アプローチだけがゆったり過ごす伝統的なLayer3で可能であるというよりも欠点へのさらに速い応答を可能にすることによってネットワークの信頼性を増加させる性能であり、それでも、ネットワークの目に見えることを提供するのはLayer3を都合しました。 その上、MPLSを使用する保護メカニズムは、IP交通がWDMの光学チャンネルの直接上に置かれて、介入しているSonet層も光の保護なしで回復オプションを供給するのを可能にするかもしれません。 これは速い回復能力を要求するIP過剰WDMネットワークの工事を容易にするでしょう(ここで意味されることがGeneralized MPLS、またはGMPLSではなく、WDMリンクの上のIP交通の輸送であることに注意してください、WDMリンクのコントロール)。
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.
IPルーティング・プロトコルの集合倍より小さい回復回を支持する必要があるコアMPLSネットワークには、I.層3かIPのコースを変更するのが遅過ぎるかもしれません。
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のコースを変更するのが特定の流れ(例えば、IPの上の声、仮想の専用線サービス)に帯域幅保護を提供する能力を提供しません。
III. Layer 0 (for example, optical layer) or Layer 1 (for example,
SONET) mechanisms may be wasteful use of resources.
III。 層0(例えば、光学層)かLayer1(例えば、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
V.層0かLayer1メカニズムが、より高い層の操作に目に見えることを全く持っていないかもしれません。 したがって、例えば、彼らが提供しているかもしれない間、保護をリンクしてください、と彼らは容易に層3で輸送された交通のノード保護か保護を前提とすることができません。 さらに、これはトラフィックに基づいた回復が必要とする提供からの下層を防ぐかもしれません。 例えば、それを必要とする交通のための速い回復、およびそれが速く必要としない交通のための、より遅い回復(リソースのことによるとより最適の使用がある)
Sharma & Hellstrand Informational [Page 4] RFC 3469 Framework for MPLS-based Recovery February 2003
MPLSベースの回復2003年2月のためのシャルマとHellstrandの情報[4ページ]のRFC3469枠組み
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.
回復。 後者のクラスの交通が優位であるネットワークでは、すべてのクラスの交通に速い回復を提供するのはサービスプロバイダーの見解から費用効率がよくないかもしれません。
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。 ルータ/LSRsの間の保護メカニズムの相互運用性を異なった業者からIPかMPLSネットワークに確立するのが、回収機構が「マルチ-業者」環境で働いて、MPLSコアに対する、ある保護されたサービスの変遷を可能にするのを可能にすることが望まれています。
1.3. Objectives/Goals
1.3. 目的/目標
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のベースの回収機構は、エンドユーザアプリケーションには、十分速い回復時間を容易にすることを目指すはずです。 すなわち、より良いのはエンドユーザのアプリケーション要件に合っています。 いくつかの場合、これはミリセカンドに10年代と同じくらい不足するかもしれません。
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.
闘争目的、および取り引きが取り止めになったなら、私たちは、私と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
V. MPLSベースのリカバリ技術は、様々な粒状で交通の保護に適切であることを目指すべきです。 例えば、個々の経路における交通の部分にMPLSベースの回復を指定するのは可能であるべきです、すべての交通に
Sharma & Hellstrand Informational [Page 5] RFC 3469 Framework for MPLS-based Recovery February 2003
MPLSベースの回復2003年2月のためのシャルマとHellstrandの情報[5ページ]のRFC3469枠組み
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.
個々の経路の上、または、経路のグループにおけるすべての交通に。 経路が一般項として使用されて、リンク、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.
ξ。 望まれているなら、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.
私たちは、上記のいくつかが闘争目標であり、本当の展開がしばしば費用や、エンドユーザアプリケーション要件や、ネットワーク効率や、伴われる複雑さや、収入問題などのさまざまな要素に基づく設計上の妥協にかかわるのを観測します。 したがって、これらの目標は上の問題に基づく見返りを受けることがあります。
2. Overview
2. 概観
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.
交通の保護を提供するためのいくつかのオプションがあります。 最も一般的な要件は回復が動作を切り換えるか、または別ルートで送りながらLayer3(または、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
一般にネットワーク・オペレータは、最も速くて、最も安定して、妥当な価格で提供できる中で最も良い保護メカニズムを提供することを目指します。 保護のレベルが高ければ高いほど、より多くです。
Sharma & Hellstrand Informational [Page 6] RFC 3469 Framework for MPLS-based Recovery February 2003
MPLSベースの回復2003年2月のためのシャルマとHellstrandの情報[6ページ]のRFC3469枠組み
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ベースの回復では、異なったクラスのサービスのための異なったレベルの保護を提供するのは可能である場合があります、それらのサービス要件に基づいて。 例えば、以下に概説されたアプローチを使用して、ボイス・オーバー IP(VoIP)のようなVirtual Leased線(VLL)サービスかリアルタイムのアプリケーションが、プレ確立して、プレ予約された経路保護と共にリンク/ノード保護を使用することで支持されるかもしれません。 それらのアプリケーションの範囲に関する別の例として、MPLSのベースの回復戦略は元々ラベルの切り換えられた経路を流れない交通を保護するのに使用されるかもしれません、通常、ホップごとにラベルの上に進められた交通が経路を切り換えたのと同じくらいよく発送されるIP交通などのように。他方では、ベストエフォート型交通は要求に応じて確立されるか、または単に当てにされるかもしれない経路保護を使用するかもしれません。IPでは、層の回収機構は、より高くコースを変更しています。
2.1. Recovery Models
2.1. 回復モデル
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.
以下で定義されるように切り替わって、コースを変更する保護は一緒に使用されるかもしれません。 例えば、コースを変更するのが新しい最適のネットワーク・コンフィギュレーションを決定している間、回復経路に切り替わる保護は接続性の急速回復に使用されるかもしれません、経路を再配列して、必要に応じて、後で。
2.1.1 Rerouting
2.1.1 コースを変更すること
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.
ネットワークルーティング・アルゴリズムが欠点の後にいったん一点に集まると、いくつかの場合、aがネットワークの現状に基づいて別ルートで送る実行とネットワーク方針でネットワークを再最適化するのは望ましいかもしれません。 セクション3.8で、より詳しくこれについて議論します。
In terms of the principles defined in section 3, reroute recovery employs paths established-on-demand with resources reserved-on- demand.
セクション3で定義された原則に関して、回復雇用が確立して予約して進行中の要求しているリソースで要求次第の経路であると別ルートで送ってください。
Sharma & Hellstrand Informational [Page 7] RFC 3469 Framework for MPLS-based Recovery February 2003
MPLSベースの回復2003年2月のためのシャルマとHellstrandの情報[7ページ]のRFC3469枠組み
2.1.2 Protection Switching
2.1.2 保護の切り換え
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で詳細です。
2.2. The Recovery Cycles
2.2. 回復サイクルズ
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サイクルのどれかはサイクルのあとに続いて、再び最適化されたネットワークを達成するかもしれません。 逆戻りサイクルは一点に集まるようにどんなダイナミックルーティングプロトコルも当てにしない明らかに発送された交通に申し込みます。 ダイナミックなコースを変更するサイクルはホップごとのルーティングに基づいて進められる交通に申し込みます。
2.2.1 MPLS Recovery Cycle Model
2.2.1 MPLS回復サイクルモデル
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 |
--ネットワーク損傷| --検出された欠点| | --通知の始まり| | | -- 回復動作の始まり| | | | --回復動作完全です。| | | | | --経路交通は回復しました。| | | | | | | | | | | | v v対v vに---------------------------------------------------------------- | T1| T2| T3| T4| T5|
Figure 1. MPLS Recovery Cycle Model
図1。 MPLS回復サイクルモデル
Sharma & Hellstrand Informational [Page 8] RFC 3469 Framework for MPLS-based Recovery February 2003
MPLSベースの回復2003年2月のためのシャルマとHellstrandの情報[8ページ]のRFC3469枠組み
The various timing measures used in the model are described below.
モデルで使用される様々なタイミング測定は以下で説明されます。
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ベースの回収機構This時間によって検出される瞬間の間の時間は下位層プロトコルに非常に依存しているかもしれません。
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ベースの回復行動を取る検出の間の構成された待ち時間。 下にFault Hold Timeはゼロであるかもしれません。
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よりむしろPath Switch LSR(PSL))が待つために構成されるなら、下にFault Hold TimeはFault Notification Time間隔の後に起こるかもしれません。
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によるFault Indication Signal(FIS)の開始と時間の間のPath Switch 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が欠点自体を検出するなら、回復動作の検出と始まりの間には、下にFault Hold Timeの期間がまだあるかもしれません。
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.
1番目と最後の回復動作の間の時間。 これは、回復動作を調整するためにPSLとPML(経路Merge LSR)の間の交換処理を含むかもしれません。
Sharma & Hellstrand Informational [Page 9] RFC 3469 Framework for MPLS-based Recovery February 2003
MPLSベースの回復2003年2月のためのシャルマとHellstrandの情報[9ページ]のRFC3469枠組み
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)の発生による混乱させられたか降格しているサービスを経験したネットワークでポイントにもう一度到着するのに必要である時間を説明することを意図します。 今回は回復経路に沿って欠点、回収機構、および伝播遅延の位置によるかもしれません。
2.2.2 MPLS Reversion Cycle Model
2.2.2 MPLS逆戻りサイクルモデル
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.
その経路の欠点がクリアされるとき、保護の切り換え(revertiveモード)は、交通が都合のよい経路に元に戻らされるのを必要とします。 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|
--ネットワーク損傷は修理されました。| --欠点はクリアされました。| | --利用可能な経路| | | --逆戻り操作の始まり| | | | --逆戻り操作完全です。| | | | | --都合のよい経路で復元された交通| | | | | | | | | | | | 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の逆戻り演算時間T11交通逆戻り欠点開拓地時間T8下に成立する時間T9明記時間T10時間
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(上では、目立たない)がネットワーク損傷が修理されないで、交通が回復経路を流れている時間であることに注意してください。
Sharma & Hellstrand Informational [Page 10] RFC 3469 Framework for MPLS-based Recovery February 2003
MPLSベースの回復2003年2月のためのシャルマとHellstrandの情報[10ページ]のRFC3469枠組み
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 Timeはゼロであるかもしれません。
Note: The Clear Hold-Off Time may occur after the Clear
Notification Time interval if the PSL is configured to wait.
以下に注意してください。 PSLが待つために構成されるなら、下にClear Hold TimeはClear Notification Time間隔の後に起こるかもしれません。
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によるFault Recovery Signal(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が欠点自体をクリアするなら、逆戻り操作の欠点開拓地と始まりの間には、下にClear Hold Timeの期間がまだあるかもしれません。
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.
1番目と最後の逆戻り動作の間の時間。 これは、逆戻り動作を調整するために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).
最後の逆戻り動作と交通(存在しているなら)が都合のよい経路で完全に復元される時間の間の時間。 両方の経路が働いているのでこの間隔がかなり小さいと予想されて、交通分裂(例えば、「以前、開閉してください」というテクニックを使用して、オーバー切り替わります同期)を制限するために注意するかもしれません。
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
逆戻りサイクルで最もおもしろい回が実際には、下にClear Hold TimeとTraffic Reversion Timeと共にReversion Operation Timeである、(交通のある他の手段
Sharma & Hellstrand Informational [Page 11] RFC 3469 Framework for MPLS-based Recovery February 2003
MPLSベースの回復2003年2月のためのシャルマとHellstrandの情報[11ページ]のRFC3469枠組み
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).
両方の経路が利用可能であるなら、最小量の分裂があるよく制御されたジグザグの山道を持っているのを待つのは新しい欠点を導入するかもしれない即時操作を持っているより(恐らく回復経路が都合のよい経路に匹敵するサービスの質を提供できないときに時を除いて)良いです。
2.2.3 Dynamic Re-routing Cycle Model
2.2.3 ダイナミックなコースを変更しているサイクルモデル
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 |
--ネットワークは損傷の後に準安定状態に入ります。| --ダイナミックルーティングプロトコルは一点に集まります。| | --PSLの間の新しい働く経路のセットアップに着手してください。| | | そして、PML| | | --転換操作完全です。| | | | --新しい働く経路に動かされた交通| | | | | | | | | | 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
(任意)のT12の転換演算時間T15交通王政復古ネットワークルート集合時間T13抑制時間T14時間
Sharma & Hellstrand Informational [Page 12] RFC 3469 Framework for MPLS-based Recovery February 2003
MPLSベースの回復2003年2月のためのシャルマとHellstrandの情報[12ページ]のRFC3469枠組み
Network Route Convergence Time
ネットワークルート集合時間
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.
1番目と最後の転換動作の間の時間。 これは、転換動作を調整するために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.
最後の回復動作と交通(存在しているなら)が新しい都合のよい経路で完全に復元される時間の間の時間。
2.2.4 Example Recovery Cycle
2.2.4例の回復サイクル
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。 シグナリングは検出された欠点IIIによって(FIS)を開始しました。 FISはPSL IVに到着します。 PSLはPSLが働く経路から回復経路VIまでの交通の上で切り換えるあらかじめ設定された回復経路V.に回線切替装置を開始します。 ネットワークは準安定状態VIIを入力します。 ダイナミックルーティングプロトコルは欠点の後に一点に集まります、そして、新しい働く経路は計算されます(例えば、セクション2.1.1で言及した評価基準のいくつかに基づいています)。 VIII。 新しい働く経路はPSLとPML(仮定はPSLとPMLが変化していないということである)IXの間で確立されます。 交通は新しい働く経路に転換されます。
Sharma & Hellstrand Informational [Page 13] RFC 3469 Framework for MPLS-based Recovery February 2003
MPLSベースの回復2003年2月のためのシャルマとHellstrandの情報[13ページ]のRFC3469枠組み
2.3. Definitions and Terminology
2.3. 定義と用語
This document assumes the terminology given in [RFC3031], and, in addition, introduces the following new terms.
このドキュメントは、用語が負けて[RFC3031]、さらに、次の新学期を紹介すると仮定します。
2.3.1 General Recovery Terminology
2.3.1 一般回復用語
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.
回復経路との同義語は以下の通りです。 経路、迂回経路、および保護経路をバックアップしてください。
Sharma & Hellstrand Informational [Page 14] RFC 3469 Framework for MPLS-based Recovery February 2003
MPLSベースの回復2003年2月のためのシャルマとHellstrandの情報[14ページ]のRFC3469枠組み
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。 使われた回復計画のタイプに頼っていて、例えば、PORはPSLかPMLであるかもしれません。
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)
経路グループ(未成年者不適当映画)
A logical bundling of multiple working paths, each of which is
routed identically between a Path Switch LSR and a Path Merge LSR.
複数の働く経路の論理的なバンドリング。それは同様にそれぞれPath Switch LSRとPath Merge 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ビットのコード・ポイントは保護された部分を特定するかもしれません。
Sharma & Hellstrand Informational [Page 15] RFC 3469 Framework for MPLS-based Recovery February 2003
MPLSベースの回復2003年2月のためのシャルマとHellstrandの情報[15ページ]のRFC3469枠組み
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]を使用することで1セットの働く経路を支援するのに役立つ経路。 働く経路と迂回トンネルは同じ経路スイッチ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
Revertiveモード
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
非revertiveモード
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.
働く経路とその対応する回復経路が発送されるLSRsのセット。
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保護ドメインで展開しました。
Sharma & Hellstrand Informational [Page 16] RFC 3469 Framework for MPLS-based Recovery February 2003
MPLSベースの回復2003年2月のためのシャルマとHellstrandの情報[16ページ]のRFC3469枠組み
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の間で定期的にリンク調べメカニズムとして機能する隣接しているLSRsを交換しました。 それは隣人生きることのチェックと同様に2LSRsの間のフォワードの保全チェックとリンクに関する逆方向を提供します。
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.)
経路か経路セグメントの保全と連続について確かめるテスト。 そのようなテストの詳細はこのドキュメントの範囲を超えています。 (これを例えば、データ通信量として同じリンクとノードに沿ってコントロールメッセージを送ることによって達成できるだろうか、または交通の欠如とフィードバックを提供することによって、同様に測定できるでしょう。)
2.3.2 Failure Terminology
2.3.2 失敗用語
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
経路に沿った欠点が起こったのを示す信号。 それはそれぞれの中間的LSRによって上流の、または、川下の隣人にリレーされます、MPLS回復(POR)を実行するセットアップであるLSRに達するまで。 FISは伝えられます。
Sharma & Hellstrand Informational [Page 17] RFC 3469 Framework for MPLS-based Recovery February 2003
MPLSベースの回復2003年2月のためのシャルマとHellstrandの情報[17ページ]のRFC3469枠組み
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.
何らかの構成可能な長さの時間の失敗までの最も近くか伝えるノードまでのノード/ノードは隣人から承認を定期的に受けます。
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はノード/ノードによって失敗まで最も近くに定期的に伝えられます、何らかの構成可能な長さの時間か伝えるノードが隣人から承認を受けるまで。
2.4. Abbreviations
2.4. 略語
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: 経路マージLSR。 未成年者不適当映画: 経路グループ。 POR: 修理のポイント。 PPG: 経路グループを保護しました。 PTP: 交通部分を保護しました。 PSL: 経路スイッチLSR。
3. MPLS-based Recovery Principles
3. MPLSを拠点とする回復プリンシプルズ
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回復は、保護が切り替わっていて達成されると思われて、MPLS LSRがそれが匹敵しているか、または相当している完成時間を切り換えている間、見られるかもしれません、Sonet層の50msオーバースイッチ完成時間。 さらに、MPLSベースの回復はそれを必要とする経路のための帯域幅保護を提供するかもしれません。 このセクションはMPLSベースの回復の概念と原理の議論を提供します。 概念は回復アプローチを指定するために結合されるかもしれない原子の、または、原始の用語で提示されます。 私たちは下位層1か層に関する少しの仮定も2台の移送機構かそれらの回収機構にしません。
Sharma & Hellstrand Informational [Page 18] RFC 3469 Framework for MPLS-based Recovery February 2003
MPLSベースの回復2003年2月のためのシャルマとHellstrandの情報[18ページ]のRFC3469枠組み
3.1. Configuration of Recovery
3.1. 回復の構成
An LSR may support any or all of the following recovery options on a per-path basis:
LSRは1経路あたり1個のベースで以下の回復オプションのいずれかすべてを支持するかもしれません:
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ベースの回復): 働く経路における交通はLayer3か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つ以上の回復経路を使用することで回復されます。
3.2. Initiation of Path Setup
3.2. 経路セットアップの開始
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-自由民主党[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.
プレ確立した経路は作成される必要はなくて、それはプレ適切であるかもしれません。 プレ適切な回復経路は、働く経路を保護するために明白に作成されませんが、代わりに他の目的のために作成された経路です、すなわち、それを決定した後に回復経路として指定されて、それは、働く経路交通を運ぶための受け入れられる代案です。 異形は光路か道が構成されますが、スイッチが全く設定されないケースを含んでいます。
Sharma & Hellstrand Informational [Page 19] RFC 3469 Framework for MPLS-based Recovery February 2003
MPLSベースの回復2003年2月のためのシャルマとHellstrandの情報[19ページ]のRFC3469枠組み
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に検出されて、通知された後に回復経路は確立されます。 回復経路は、あらかじめ計算されるか、または要求のときに計算されるかもしれません。(それは、回復回に影響を及ぼします)。
3.3. Initiation of Resource Allocation
3.3. 資源配分の開始
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.
このオプションは保護の切り換えだけに適用されます。 ここで、プレ確立した回復経路は設立の間、ルートに沿ったすべてのホップに関する必要なリソースを予約します。 各ノードの予約されたリソース(例えば、帯域幅、そして/または、バッファ)はすべての失敗が起こる前にノードに存在している交通で使用されるためには、より扱っている経路を認めるのにおいて使用されていて、それらが利用可能であるということであるはずがありませんが。 同時に失敗を被りやすくないリソースを保護するなら、1セットの回復経路によって保持されたリソースは共有されるかもしれません。
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.
回復経路で予約されたリソースの量によって、それが上では、両方のオプションでの、同等な回復経路か限られた回復経路のどちらかであるかもしれないことに注意してください。
Sharma & Hellstrand Informational [Page 20] RFC 3469 Framework for MPLS-based Recovery February 2003
MPLSベースの回復2003年2月のためのシャルマとHellstrandの情報[20ページ]のRFC3469枠組み
3.3.1 Subtypes of Protection Switching
3.3.1 保護の切り換えの血液型亜型
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のためのもの」)保護では、回復経路が働く経路で過度に当然に使用中である時を除いて、回復経路に割り当てられたリソース(もしあれば)はpreemptibleの低い優先権交通に完全に利用可能です。 言い換えれば、1:1保護では、保護された交通は、通常、働く経路だけを旅行して、働く経路に欠点がある場合にだけ、回復経路に切り換えられます。 回線切替装置がいったん開始されると、回復経路で運ばれる低い優先権交通は保護された交通で置き換えられるかもしれません。 この方法は回復経路の効率的な使用をリソースにする方法を提供します。
This concept can be extended to 1:n (one for n) and m:n (m for n) protection.
この概念について1:n(nのためのもの)とmまで敷衍できます: n(nのためのm)保護。
3.4. Scope of Recovery
3.4. 回復の範囲
3.4.1 Topology
3.4.1 トポロジー
3.4.1.1 Local Repair
3.4.1.1 局部的修繕
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:
局部的修繕の意図は、リンクか隣人ノード欠点から守って、失敗伝播のために所要時間を最小にすることです。 地方では、至急、(また、知られている地方の回復)、ノードを修理してください。欠点の上流は回復(コースを変更するか保護の切り換えのどちらか)を起こすものです。 2つのタイプには局部的修繕があることができます:
Sharma & Hellstrand Informational [Page 21] RFC 3469 Framework for MPLS-based Recovery February 2003
MPLSベースの回復2003年2月のためのシャルマとHellstrandの情報[21ページ]のRFC3469枠組み
Link Recovery/Restoration
リンク回復/王政復古
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.
この場合、回復経路は頼り無いと考えられたあるリンクの周りのルートに構成されるかもしれません。 保護の切り換えが使用されているなら、いくつかの回復経路が個人的には経路を扱いながら、構成されるかもしれません、それぞれが守る特定の不完全なリンクによって。
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、および働く経路に部分を重ね合わせる回復経路シェアで回復経路に転換されます。
3.4.1.2 Global Repair
3.4.1.2 グローバルな修理
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).
グローバルな修理ではも、終わりから終わりへの経路回復/回復は適用されます。 多くのケース、経路を完全にすることができる回復では、リンクとノードは働く経路でばらばらになります。 これには、働く経路(終わりから端への経路か経路セグメント)ですべてのリンクとノード欠点から守る利点があります。
Sharma & Hellstrand Informational [Page 22] RFC 3469 Framework for MPLS-based Recovery February 2003
MPLSベースの回復2003年2月のためのシャルマとHellstrandの情報[22ページ]のRFC3469枠組み
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に移動しなければならないより遅いかもしれません。
3.4.1.3 Alternate Egress Repair
3.4.1.3 交互の出口修理
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 topologiesの信頼性を高めながら、簡略化するかもしれません。 候補回復経路が同じくらい単にリンクされて、ノードが働く経路の即座の川下のLSRと共にばらばらになるとき、PSLはLSP/FEC結合に資格を与えるかもしれません。
3.4.1.4 Multi-Layer Repair
3.4.1.4 マルチ層の修理
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.
マルチ層の修理は総合的なネットワーク目標を達成するために複数のネットワーク層に一緒に対処できるそれらのケースのためにネットワーク設計者のツール・セットを広くします。 マルチ層の修理がいつ適切であるかを決定する特定の評価基準はこのドキュメントの範囲を超えています。
3.4.1.5 Concatenated Protection Domains
3.4.1.5 連結された保護ドメイン
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.
与えられたサービスは複数のネットワークに交差するかもしれません、そして、これらは異なった回収機構を使うかもしれません。保護ドメインを連結するのは、終わりから終わりをサービス回復に提供できるくらい可能です。 異なったドメインの回収機構が自主的に動作するかもしれなくて、複数のポイントの付属がドメイン(失敗のどんな単一のポイントもないのを保証する)の間で使用されるかもしれないと考えられます。 失敗(PML)の明白なMPLSポイントが定義上除かれるので、交互の出口修理は連結されたドメインを管理に要求します。 連結された保護ドメインの詳細はこのドキュメントの範囲を超えています。
Sharma & Hellstrand Informational [Page 23] RFC 3469 Framework for MPLS-based Recovery February 2003
MPLSベースの回復2003年2月のためのシャルマとHellstrandの情報[23ページ]のRFC3469枠組み
3.4.2 Path Mapping
3.4.2 経路マッピング
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..
経路マッピングは不完全な働く経路から交通を写像する方法を回復経路と呼びます。 これのためのいくつかのオプションが以下で説明されるようにあります。 以下でのオプションが働きと保護経路がどう写像されるかを互いに説明するだけである原子用語として見なされるべきであることに注意してください。 これらの経路と、一般的により使用された合成語まで転換がどう実際に実行されたリードであるかに沿った資源予約の1つの+1と1:1保護などの問題。(それは、セクション4.3.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から1Protection
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つの保護では、最大n働く経路が、1つの回復経路だけを使用することで保護されます。 意図が何か働く経路のどれかのただ一つの欠点から守ることであるなら、n働く経路がさまざまに同じPSLとPMLの間に発送されるべきです。 いくつかの場合、PSLとPMLの間のハンドシェイクが、回復を終了するのに必要であるかもしれません。その詳細がこのドキュメントの範囲にあります。
n-to-m Protection
nからmへのProtection
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への保護では、最大n働く経路が、m回復経路を使用することで保護されます。 もう一度、n働く経路とm回復経路は意図が何かn働く経路のどれかのただ一つの欠点から守ることであるなら、さまざまに同じ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
分裂経路保護では、複数の回復経路が、ある構成可能な負荷分かれる比に基づく働く経路の交通を運ぶことができます。 欠点の場合に働く経路の全体の交通を運ぶことができるどんなただ一つの回復経路も見つけることができないとき、これは特に役に立ちます。 分裂経路保護が、PSLとPML(s)の間のハンドシェイクを必要として、PML(s)が交通到着を関連させるのを必要とするかもしれない、オン
Sharma & Hellstrand Informational [Page 24] RFC 3469 Framework for MPLS-based Recovery February 2003
MPLSベースの回復2003年2月のためのシャルマとHellstrandの情報[24ページ]のRFC3469枠組み
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.
働く経路がある複数の回復経路。 これは魅力的な選択ですが、分裂経路保護の詳細はこのドキュメントの範囲を超えています。
3.4.3 Bypass Tunnels
3.4.3 Bypass Tunnels
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.
いくつかの場合、PPGのためにPSLとPMLの間で「迂回トンネル」を作成するのは便利であるかもしれません、その結果、複数の回復経路が介入しているLSRs[RFC2702]に透明であることを許容します。 この場合、許容できるルートに従うPSLとPMLの間に1LSP(トンネル)を設立します、そして、ラベルの積み重ねを通してトンネルを通って多くの回復経路を支持できます。 迂回トンネルを使用するときのラベルの積み重ねを適用するのは必要ではありません。 前項で議論したオプションを写像する経路のいずれと共にも迂回トンネルを使用できます。
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.
回復経路なら、迂回トンネルには、サービス退行なしで回復を供給できるくらいの資源予約があるかもしれません。 迂回トンネルが同時に何らかの数の働く経路を回復できるくらいのリソースを持っていますが、すべて持っているというわけではないのは可能です。 その時々でトンネルの交通を運ぶ回復経路の数が制限されるなら、これはnからnから1かmへの保護セクション3.4.2で言及したケースと同様です。
3.4.4 Recovery Granularity
3.4.4 回復粒状
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.
回復の別次元は保護を必要とする交通の量を考えます。 これは経路の部分から経路のバンドルまで及ぶかもしれません。
3.4.4.1 Selective Traffic Recovery
3.4.4.1 選択している交通回復
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ヘッダーの優先権ビットで。
3.4.4.2 Bundling
3.4.4.2 バンドリング
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
バンドリングは同時にそれらを回復するために複数の働く経路を分類するのに使用されるテクニックです。 保護を必要とする複数の働く経路の論理的なバンドリングは保護された経路グループと呼ばれます。それは同様にそれぞれPSLとPMLの間に発送されます。
Sharma & Hellstrand Informational [Page 25] RFC 3469 Framework for MPLS-based Recovery February 2003
MPLSベースの回復2003年2月のためのシャルマとHellstrandの情報[25ページ]のRFC3469枠組み
(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.
(PPG。) 欠点が全体が起こることができるようにPPG、PPGを運びながら働く経路に起こるときには、迂回トンネルに切り換えられるか、または回復経路に切り換えられることによって、保護されてください。
3.4.5 Recovery Path Resource Use
3.4.5 回復経路リソース使用
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.
許容された余分な交通: 働く経路が失敗すると回復経路が働く交通を運ぶだけであるなら、余分な交通が他の時に予約されたリソースを使用するのを許容するのは可能です。 余分な交通は定義上回復経路リソースが働く経路交通を運ぶのに必要であるときはいつも、置き換えることができる(サービス契約に違反しないで)交通です。
Shared-resource: A shared recovery resource is dedicated for use by multiple primary resources that (according to SRLGs) are not expected to fail simultaneously.
共用資源: 共有された回復リソースは使用のために同時に失敗しないと予想される(SRLGsによると)複数の天然資源によって捧げられます。
3.5. Fault Detection
3.5. 欠点検出
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.
IP層における、または、MPLSの操作における、下層欠点か欠点のどちらかの検出がメカニズムを基礎づけた後に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
経路Failure(PF)は経路の接続性が無くなるのをMPLSベースの回復計画に示す欠点です。 これはPSLとPMLの間の経路連続テストで検出されるかもしれません。 いくつか、および恐らく最も通例、経路失敗は隣人LSRsの間のリンク調べメカニズムを使用するのが検出されるかもしれません。 調べメカニズムに関する例は同輩LSRs[MPLS-PATH]の間の働く経路に沿って定期的に交換される活性メッセージです。 リンク調べメカニズムか経路連続テストのどちらかが有効であるなら、働きか回復経路と同じルートに従うためにテストメッセージを保証しなければなりません、テストされるセグメントの上で。 さらに、経路連続テストは経路マージポイント取らなければなりません。
Sharma & Hellstrand Informational [Page 26] RFC 3469 Framework for MPLS-based Recovery February 2003
MPLSベースの回復2003年2月のためのシャルマとHellstrandの情報[26ページ]のRFC3469枠組み
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.
考慮に。 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.
経路Degraded(PD)は経路には接続性がありますが、接続の品質が容認できないのをMPLSベースの回復計画/メカニズムに示す欠点です。 これは、経路の経路か何らかの部分の誤り率を測定するために経路性能監視メカニズム、またはある他のメカニズムによって検出されるかもしれません。 これは、ラベルミスマッチのためかTTL誤りの例えばためLSRに地方であり、インタフェースでパケットを過度の捨てるのから成ります。
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.
失敗されて、リンクFailure(LF)は下層からの経路が運ばれるリンクがそうしたという指示です。 下層がこの欠点(例えばリンクの故障SONET LOS(Signalの損失)を示すすなわちどんな欠点も)の検出と報告を支持するなら、これは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.
リンクDegraded(LD)は下層からの経路が運ばれるリンクが以下で合格水準を実行しているという指示です。 下層がこの欠点の検出と報告を支持するなら、それはMPLS回収機構によって使用されるかもしれません。 いくつかの場合、LD指摘を使用すると、MPLSベースの欠点検出メカニズムだけを使用するより速い欠点検出は提供されるかもしれません。
3.6. Fault Notification
3.6. 欠点通知
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に川下を送る、(POR、1、+1、)、いくつかの手段のどれかによるPOR上流(1:nの間の)と以下を伝えてください。 - コントロール飛行機メッセージング--ユーザ飛行機リターンパス(双方向のLSPを通した、または、他の手段を通した)
Sharma & Hellstrand Informational [Page 27] RFC 3469 Framework for MPLS-based Recovery February 2003
MPLSベースの回復2003年2月のためのシャルマとHellstrandの情報[27ページ]のRFC3469枠組み
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(s)に向かって伝播されるのを保証するべきです。 欠点通知がMPLSドメインのLSRsでどう構成されるかによって、Layer2かLayer3パケット[MPLS-PATH]としてFISを送ることができました。 Layerの2ベースの通知の使用はLayer2経路をPORにダイレクトに必要とします。 FISに関する例は任意の欠点通知分野セットで川下のLSRによって上流の隣人に送られた活性メッセージであるかもしれませんか分解メッセージはそれとなくそれを指示できます。 あるいはまた、それは別々の欠点通知パケットであるかもしれません。 中間的LSRは、入って来るリンクのどれに関してFISを伝播するかを特定するはずです。
3.7. Switch-Over Operation
3.7. オーバースイッチ操作
3.7.1 Recovery Trigger
3.7.1 回復引き金
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に受け取られた欠点通知への応答から生じます。 欠点検出とトリガー機構が結合されるのは、可能です、PF、PD、LF、またはLDがPSLに検出されて、回復経路に回線切替装置の引き金となるとき、そうであるように。 しかしながら、多くの場合、検出とトリガー機構は異なっています、欠点通知の伝播が回線切替装置引き金としてPORで機能するFISを通してPORにあとに続いたいくらかの中間的LSRで欠点の検出にかかわって。 オペレータがPOR(あるいはまた、中間的LSRへの構成コマンドで、どれがPORに向かってFISを伝える)へのコマンドで回線切替装置を開始するとき、外部のコマンドに対応して切り替わるMPLS保護は結果として生じます。
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)結果はサービスプロバイダーと顧客の間で協定をサービスレベルに基礎づけました。
Sharma & Hellstrand Informational [Page 28] RFC 3469 Framework for MPLS-based Recovery February 2003
MPLSベースの回復2003年2月のためのシャルマとHellstrandの情報[28ページ]のRFC3469枠組み
3.7.2 Recovery Action
3.7.2 回復動作
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によって受け取られた後に、回復動作は操作を切り換えるコースを変更するか保護にかかわります。 両方のシナリオでは、回復経路のための次のホップラベル推進エントリーは働く経路に縛られます。
3.8. Post Recovery Operation
3.8. ポスト回復動作
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つのスタイル、保護対応者(すなわち、働きと回復経路)が固定されているか、または彼らのルートに「ピンで止められる」もの、および失敗に関するリアルタイムの知識があるPSLか他のネットワーク実体がダイナミックに保護されたサービスを包括する経路の再建か制御配列換えを実行するものがあります。
3.8.1 Fixed Protection Counterparts
3.8.1 固定保護対応者
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は適切な行動であらかじめ設定されて、元の固定経路がサービスに回復するとき、取るでしょう。 選択はrevertiveと非revertiveモードです。 選択は働きと保護経路の相対的なコスト、および再びまだ経路を切り換えているという効果に対するサービスの寛容に通常依存するようになるでしょう。 これらの保護モードは、都合のよい経路があるかどうかを保護された交通に示します。
3.8.1.1 Revertive Mode
3.8.1.1 Revertiveモード
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.
いつも働く経路が都合のよい経路であるなら、それが利用可能であるときはいつも、この経路は使用されるでしょう。 したがって、この経路の欠点の場合、未利用資源は失敗でネットワークによって取り戻されないでしょう。 ここのリソースは割り当てられたラベル、帯域幅リンクなどを含むかもしれません。 働く経路に欠点があるなら、交通は回復経路に切り換えられます。 都合のよい経路が回復するとき、操作のrevertiveモードで、交通はそれに自動的に元に戻らされます。
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.
- 失敗、回復経路に動かされた後に、元の働く経路における経路欠陥のような時間が修理されるまで、交通は保護がなく、その経路はサービスに回復しています。
Sharma & Hellstrand Informational [Page 29] RFC 3469 Framework for MPLS-based Recovery February 2003
MPLSベースの回復2003年2月のためのシャルマとHellstrandの情報[29ページ]のRFC3469枠組み
- upon failure and after traffic has been moved to the recovery
path, the resources associated with the original path remain
reserved.
- 失敗、交通が回復経路に動かされた後に、元の経路に関連しているリソースは予約されていたままで残っています。
3.8.1.2 Non-revertive Mode
3.8.1.2 非revertiveモード
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).
非revertive運転モードには、どんな都合のよい経路もないか、またはさらなるrevertive切り換え操作で起こされたサービスの分裂を最小にするのは望ましいかもしれません。 元の経路がその経路における欠点の発生の後にもう存在しないかもしれないので、元の働く経路へのジグザグの山道は、必要でないか、または可能ではありません。 欠点が働く経路にあれば、交通は回復経路に切り換えられます。 または、いつことであるか、そして、不完全な経路(元々働く経路)が回復しています、回復経路になるかもしれないということであるかどうか、(どちらか構成で管理活動で望まれている、)
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.
非revertive運転モードで、働く交通はとにかく新しい最適の働く経路、または、元の働く経路に復元されるかもしれません。 それがいくつかの場合どちらかの役に立つかもしれないので、これは以下の通りです。 (a) (c) (b) 経路の保全に関してさらなる保証を獲得した後に、行政上元の働く経路に回線切替装置を実行して戻してください。さもないと、回復経路における操作を続けているのは許容できるかもしれません、または、交通をネットワーク形態とネットワーク方針に基づいて計算される新しい最適の働く経路に動かすのは望ましいかもしれません。 新しい働く経路がいったん定義されると、関連回復経路はセットアップであるかもしれません。
3.8.2 Dynamic Protection Counterparts
3.8.2 ダイナミックな保護対応者
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または他のネットワーク実体のそれが新しい働く経路を確立すると仮定します。
Sharma & Hellstrand Informational [Page 30] RFC 3469 Framework for MPLS-based Recovery February 2003
MPLSベースの回復2003年2月のためのシャルマとHellstrandの情報[30ページ]のRFC3469枠組み
3.8.3 Restoration and Notification
3.8.3 王政復古と通知
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。 王政復古はPSLによって働く経路が修理されるという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.
また、revertiveモードによる固定対応者のために、働く経路に欠点を検出したLSRは働く経路の返還を検出します。 働く経路がLF欠陥になったなら、LSRは同輩からの活性メッセージの領収書で通常の操作へのリターンを検出します。 働く経路がLSRインタフェースにおけるLD欠陥になったなら、LSRはそのインタフェースにおけるエラーのないパケットレセプションの再開で通常の操作へのリターンを検出するかもしれません。 あるいはまた、もうLF欠陥を検出しない下層は、LSRで同輩LSRへのリンクが操作上であることをMPLSベースの回収機構に知らせるかもしれません。 そして、LSRは働く経路における交通を伝えていた上流のLSR(s)に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に概説された非revertiveのスイッチ操作の恩恵を提供するので、保護がない状態で回復経路を出ないで。
3.8.4 Reverting to Preferred Path (or Controlled Rearrangement)
3.8.4 都合のよい経路に戻ること。(または、配列換えを制御します)
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.
revertiveモードによる、「以前、開閉してください」という回復の切り換え(ネットワーク損傷の発生を切り換える保護を実行するほど破壊的でない)を使用できます。 これはパケット損失とパケット再命令の両方を最小にするでしょう。 また、MPLSドメインの向こう側にロードバランシングのための交通工学要件を満たすのに経路の制御配列換えを使用できます。
Sharma & Hellstrand Informational [Page 31] RFC 3469 Framework for MPLS-based Recovery February 2003
MPLSベースの回復2003年2月のためのシャルマとHellstrandの情報[31ページ]のRFC3469枠組み
3.9. Performance
3.9. パフォーマンス
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。 先取り属性: 回復経路は働く経路か下側のものと同じ先取り属性を持つことができます。
4. MPLS Recovery Features
4. MPLS回復機能
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回復が保護グループ(PPGs)と保護部分(PTPs)を特定するためにオプションを提供するのは、望ましいです。
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
III。 MPLS回復方法は手動の保護切り換え命令を排除するべきではありません。 これは、働く経路から回復経路までの交通を移すか、または回復から交通を移すのが管理指揮で可能であることを含意します。
Sharma & Hellstrand Informational [Page 32] RFC 3469 Framework for MPLS-based Recovery February 2003
MPLSベースの回復2003年2月のためのシャルマとHellstrandの情報[32ページ]のRFC3469枠組み
path to a working path, once the working path becomes
operational following a fault.
働く経路への経路欠点に続いて、働く経路がいったん操作上になると。
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. 回復モデルは中間的LSRsで合併する考慮経路を連れていくべきです。 欠点が非合併しているセグメントに影響するなら欠点が同様に、合併しているセグメント(その合併しているセグメントを共有するのが回復できるべきであるすべての経路)に影響するなら、欠点で影響を受ける経路だけが回復されるべきです。
5. Comparison Criteria
5. 比較評価基準
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.
私たちは欠点の後に回復経路が活性化するのに必要である時間(そして、交通流動)と回復時間を定義します。 回復TimeはFault Detection Time、下にHold Time、Notification Time、Recovery Operation Time、およびTraffic王政復古Timeの合計です。 言い換えれば、回復経路がインストールされて、交通がそれを流れ始める前にネットワークにおけるノードかリンクの失敗と時間の間の時間です。
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,
働く経路か働く経路のセットが回復経路計算と回復経路がセットアップするようなタスクの間保護がない状態で残される時間は、計画を比較するために費やされるかもしれません。 この脆弱性の本質は考慮に入れられるべきです、例えば、End計画へのEndが働く経路で脆弱性を関連させます。
Sharma & Hellstrand Informational [Page 33] RFC 3469 Framework for MPLS-based Recovery February 2003
MPLSベースの回復2003年2月のためのシャルマとHellstrandの情報[33ページ]のRFC3469枠組み
Local Repair schemes have a topological correlation that cuts
across working paths and Network Plan approaches have a
correlation that impacts the entire network.
地方のRepair計画で、働く経路を横切る位相的な相関関係とNetwork Planアプローチには、全体のネットワークに影響を与える相関関係があります。
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.
回復計画が「親類」から「絶対」まで及ぶかもしれない「パケットの生存性」のスペクトルを取り囲むと考えることができます。 相対的な生存性は、パケットが対等で失敗を乗り切るネットワークの一部に関するリソースを競争することにおける、例と同じデフ-servコード・ポイント(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)).
また、保護プランにおける、回復経路の数が成長するのに従って、それらを維持しなければならなかった状態は発展します。 計画は、あるレベルの適用範囲などを維持するために異なった数の経路を必要とするかもしれません。 また、必要である状態は回復に使用される特定の計画に依存するかもしれません。 州のオーバーヘッドはいくつかのパラメタの関数であるかもしれません。 例えば、回復経路の数と保護された施設の数(リンク、ノード、または共有されたリンクリスクグループ(SRLGs))。
Sharma & Hellstrand Informational [Page 34] RFC 3469 Framework for MPLS-based Recovery February 2003
MPLSベースの回復2003年2月のためのシャルマとHellstrandの情報[34ページ]のRFC3469枠組み
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.
経路がどれくらい速く作用するかもしれない保護されることの数に対して、欠点で影響を受ける経路の全体集合を回復できました。 保護の比率はn/Nです、そして、Nは経路の総数です。そこでは、nが保護された経路の数です。
6. Security Considerations
6. セキュリティ問題
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.
このドキュメントの範囲の外に回復経路の情報の秘密性か暗号化がありますが、他の文脈でこれをするように設計されたどんな方法も本書では説明される方法で使用されるかもしれません。
Sharma & Hellstrand Informational [Page 35] RFC 3469 Framework for MPLS-based Recovery February 2003
MPLSベースの回復2003年2月のためのシャルマとHellstrandの情報[35ページ]のRFC3469枠組み
7. Intellectual Property Considerations
7. 知的所有権問題
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は本書では含まれた仕様いくつかかすべてに関して要求された知的所有権について通知されました。 詳しい情報に関しては、要求された権利のオンラインリストに相談してください。
8. Acknowledgements
8. 承認
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、デーヴ・アラン、デーヴDanenberg、Sharam Davari、およびニール・ハリソン。
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.
エディタは彼のドキュメントの慎重で非常に徹底的な読書のためのカーティスVillamizarと取ることの非常に特別な感謝にドキュメントの最後の2、3の改正に非常に役立っている頻繁な提案を提供する時間を与えたがっています。 ドキュメントの最後のバージョンを読むのによるaのためのエードリアン・ファレルとジーン-フィリップVasseurといくつかの役に立つ編集のコメントと提案、および帯域幅回復に関する入力のためのアンナ・シャルニーにも感謝があります。
9. References
9. 参照
9.1 Normative
9.1、標準
[RFC3031] Rosen, E., Viswanathan, A. and R. Callon,
"Multiprotocol Label Switching Architecture", RFC 3031,
January 2001.
[RFC3031] ローゼンとE.とViswanathanとA.とR.Callon、「Multiprotocolラベル切り換え構造」、RFC3031、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.、マルコムとJ.とAgogbuaとJ.とオデルとM.とJ.マクマナス、「MPLSの上の交通工学のための要件」RFC2702(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.とバーガーとL.とガンとD.と李とT.、SrinivasanとV.とG.ツバメ、「LSP TunnelsのためのRSVPへのRSVP-Te拡大」RFC3209(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.編、アンデション、L.、Callon、R.、Dantu、R.、ウー、L.、Doolan、P.、オースター、T.、フェルドマン、N.、Fredette、A.、Girish、M.、グレー、E.、Heinanen、J.、Kilty、T.、およびA.Malis、「自由民主党を使用して、規制ベースのLSPはセットアップします」、RFC3212、2002年1月。
Sharma & Hellstrand Informational [Page 36] RFC 3469 Framework for MPLS-based Recovery February 2003
MPLSベースの回復2003年2月のためのシャルマとHellstrandの情報[36ページ]のRFC3469枠組み
9.2 Informative
9.2、有益
[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.、シャルニー、A.、LeFaucheur、F.、およびAchirica、「MPLS Traffic Engineering Fastはコースを変更します」。 「帯域幅保護のためのバックアップトンネル経路計算」、ProgressのWork。
[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-経路]Haung、C.、シャルマ、V.、オーエンス、K.、Makam対「経路保護メカニズムを使用するビルの信頼できるMPLSネットワーク」、IEEE Commun 雑誌、Vol.40、Issue3、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]ブレーデン、R.、チャン、L.、Berson、S.、ハーツォグ、S.、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、1997年9月。
10. Contributing Authors
10. 作者を寄付します。
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
ベンマック-クレーンTellabs OperationsのInc.1415の西ディール・Roadナパービル、イリノイ 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 Eshernet1712年のInc.Ada Ct。 ナパービル、イリノイ 60540
Phone: (630) 308-3213 EMail: Smakam60540@yahoo.com
以下に電話をしてください。 (630) 308-3213 メールしてください: Smakam60540@yahoo.com
Sharma & Hellstrand Informational [Page 37] RFC 3469 Framework for MPLS-based Recovery February 2003
MPLSベースの回復2003年2月のためのシャルマとHellstrandの情報[37ページ]のRFC3469枠組み
Ken Owens Edward Jones Investments 201 Progress Parkway St. Louis, MO 63146
Parkwayセントルイス、ケンオーエンスエドワードジョーンズInvestments201Progress 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ホアンカールトン大学ミントーセンター、Rm。 3082 1125、Driveオタワ、Ontで、植民地です。 K1S 5B6カナダ
Phone: (613) 520-2600 x2477 EMail: Changcheng.Huang@sce.carleton.ca
以下に電話をしてください。 (613) 520-2600x2477 EMail: Changcheng.Huang@sce.carleton.ca
Jon Weil
ジョン・ウィル
Brad Cain Storigen Systems 650 Suffolk Street Lowell, MA 01854
サフォーク通りローウェル、ブラッドカインStorigen Systems650MA 01854
Phone: (978) 323-4454 EMail: bcain@storigen.com
以下に電話をしてください。 (978) 323-4454 メールしてください: bcain@storigen.com
Loa Andersson
Loaアンデション
EMail: loa@pi.se
メール: loa@pi.se
Bilel Jamoussi Nortel Networks 3 Federal Street, BL3-03 Billerica, MA 01821, USA
Bilel Jamoussiノーテルは3のFederal通り、BL3-03ビルリカ、MA 01821、米国をネットワークでつなぎます。
Phone:(978) 288-4506 EMail: jamoussi@nortelnetworks.com
電話: (978) 288-4506 メールしてください: jamoussi@nortelnetworks.com
Sharma & Hellstrand Informational [Page 38] RFC 3469 Framework for MPLS-based Recovery February 2003
MPLSベースの回復2003年2月のためのシャルマとHellstrandの情報[38ページ]のRFC3469枠組み
Angela Chiu AT&T Labs-Research 200 Laurel Ave. Rm A5-1F13 Middletown , NJ 07748
アンジェラチウAT&T研究室研究200ローレルAve。 Rm A5-1F13ミドルタウン、ニュージャージー 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
セイハンCivanlarキツネザルはInc.135の第20第5West Floor通り(ニューヨーク)、ニューヨーク 10011をネットワークでつなぎます。
Phone: (212) 367-7676 EMail: scivanlar@lemurnetworks.com
以下に電話をしてください。 (212) 367-7676 メールしてください: scivanlar@lemurnetworks.com
11. Editors' Addresses
11. エディタのアドレス
Vishal Sharma (Editor) Metanoia, Inc. 1600 Villa Street, Unit 352 Mountain View, CA 94041-1174
Metanoia, Inc.1600Villa通り、Vishalシャルマ(エディタ)Unit352マウンテンビュー、カリフォルニア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(エディタ)ノーテルは通りEriksgatan115私書箱6701 113 85ストックホルム(スウェーデン)をネットワークでつなぎます。
Phone: +46 8 5088 3687 EMail: fiffi@nortelnetworks.com
以下に電話をしてください。 +46 8 5088 3687はメールされます: fiffi@nortelnetworks.com
Sharma & Hellstrand Informational [Page 39] RFC 3469 Framework for MPLS-based Recovery February 2003
MPLSベースの回復2003年2月のためのシャルマとHellstrandの情報[39ページ]のRFC3469枠組み
12. Full Copyright Statement
12. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Sharma & Hellstrand Informational [Page 40]
シャルマとHellstrand情報です。[40ページ]
一覧
スポンサーリンク
