Internet Engineering Task Force (IETF) M. Shand
Request for Comments: 5714 S. Bryant
Category: Informational Cisco Systems
ISSN: 2070-1721 January 2010
IP Fast Reroute Framework
Abstract
抽象
This document provides a framework for the development of IP fast-reroute mechanisms that provide protection against link or router failure by invoking locally determined repair paths. Unlike MPLS fast-reroute, the mechanisms are applicable to a network employing conventional IP routing and forwarding.
この文書では、ローカルに決定し、修復パスを呼び出すことにより、リンクやルータの故障に対する保護を提供するIP高速再ルーティングメカニズムの開発のためのフレームワークを提供します。 MPLS高速リルートは異なり、機構は、従来のIPルーティングおよび転送を使用するネットワークに適用可能です。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5714.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5714で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Scope and Applicability . . . . . . . . . . . . . . . . . . . 5
4. Problem Analysis . . . . . . . . . . . . . . . . . . . . . . . 5
5. Mechanisms for IP Fast-Reroute . . . . . . . . . . . . . . . . 7
5.1. Mechanisms for Fast Failure Detection . . . . . . . . . . 7
5.2. Mechanisms for Repair Paths . . . . . . . . . . . . . . . 8
5.2.1. Scope of Repair Paths . . . . . . . . . . . . . . . . 9
5.2.2. Analysis of Repair Coverage . . . . . . . . . . . . . 9
5.2.3. Link or Node Repair . . . . . . . . . . . . . . . . . 10
5.2.4. Maintenance of Repair Paths . . . . . . . . . . . . . 10
5.2.5. Local Area Networks . . . . . . . . . . . . . . . . . 11
5.2.6. Multiple Failures and Shared Risk Link Groups . . . . 11
5.3. Mechanisms for Micro-Loop Prevention . . . . . . . . . . . 12
6. Management Considerations . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
9. Informative References . . . . . . . . . . . . . . . . . . . . 14
When a link or node failure occurs in a routed network, there is inevitably a period of disruption to the delivery of traffic until the network re-converges on the new topology. Packets for destinations that were previously reached by traversing the failed component may be dropped or may suffer looping. Traditionally, such disruptions have lasted for periods of at least several seconds, and most applications have been constructed to tolerate such a quality of service.
リンクまたはノード障害がルーティングされたネットワーク内で発生した場合、新しいトポロジのネットワークの再収束するまでトラフィックの配信の中断の期間が必然的に存在しています。以前に失敗したコンポーネントをトラバースすることで到達した宛先のパケットが破棄される可能性があり、またはループ被る可能性があります。伝統的に、そのような混乱は、少なくとも数秒の期間のために続いた、とほとんどのアプリケーションは、このようなサービスの品質を許容するように構成されています。
Recent advances in routers have reduced this interval to under a second for carefully configured networks using link state IGPs. However, new Internet services are emerging that may be sensitive to periods of traffic loss that are orders of magnitude shorter than this.
ルータの最近の進歩は、リンク状態のIGPを使用して、慎重に構成されたネットワークのための第二の下に、この間隔が減少しています。しかし、新しいインターネットサービスは、これより短い桁違いにトラフィック損失の期間に敏感であることも浮上しています。
Addressing these issues is difficult because the distributed nature of the network imposes an intrinsic limit on the minimum convergence time that can be achieved.
ネットワークの分散性を達成することができる最小の収束時間に固有の制限を課しているため、これらの問題に対処することは困難です。
However, there is an alternative approach, which is to compute backup routes that allow the failure to be repaired locally by the router(s) detecting the failure without the immediate need to inform other routers of the failure. In this case, the disruption time can be limited to the small time taken to detect the adjacent failure and invoke the backup routes. This is analogous to the technique employed by MPLS fast-reroute [RFC4090], but the mechanisms employed for the backup routes in pure IP networks are necessarily very different.
しかし、故障が故障の他のルータに通知するための即時必要とせずに故障を検出するルータ（複数可）によって局所的に修復することを可能にするバックアップルートを計算する別のアプローチがあります。この場合には、中断時間が隣接障害を検出し、バックアップルートを起動するのに要する短い時間に限定することができます。これは、MPLS高速リルート[RFC4090]で使用される技術に類似しているが、純粋なIPネットワークにおけるバックアップルートの使用機構は必然的に非常に異なっています。
This document provides a framework for the development of this approach.
この文書では、このアプローチの開発のためのフレームワークを提供します。
Note that in order to further minimize the impact on user applications, it may be necessary to design the network such that backup paths with suitable characteristics (for example, capacity and/or delay) are available for the algorithms to select. Such considerations are outside the scope of this document.
さらに、ユーザ・アプリケーションへの影響を最小限にするために、（例えば、容量、および/または遅延のために）適切な特性を有する予備パスはアルゴリズムを選択するために利用可能であるようにネットワークを設計する必要があるかもしれないことに留意されたいです。このような考慮事項は、この文書の範囲外です。
This section defines words and acronyms used in this document and other documents discussing IP fast-reroute.
このセクションでは、この文書とIP高速再ルーティングを議論する他のドキュメントで使用されている単語や頭字語を定義します。
D Used to denote the destination router under discussion.
Dは、議論の下で、宛先ルータを示すために使用します。
Distance_opt(A,B) The metric sum of the shortest path from A to B.
Distance_opt（A、B）AからBへの最短経路のメトリックの和
Downstream Path This is a subset of the loop-free alternates where the neighbor N meets the following condition: Distance_opt(N, D) < Distance_opt(S,D)
Distance_opt（N、D）<Distance_opt（S、D）：ダウンストリームパスこれは隣人Nは、以下の条件を満たしているループのない交互のサブセットであります
E Used to denote the router that is the primary neighbor to get from S to the destination D. Where there is an ECMP set for the shortest path from S to D, these are referred to as E_1, E_2, etc.
Eは、これらが等E_1、E_2、と呼ばれ、SからDへのSからの最短パスのECMPセットが存在する宛先Dに取得する一次ネイバーであるルータを示すために使用します
ECMP Equal cost multi-path: Where, for a particular destination D, multiple primary next-hops are used to forward traffic because there exist multiple shortest paths from S via different output layer-3 interfaces.
ECMP等しいマルチパスのコスト：特定の宛先Dのために、複数の一次次ホップが異なる出力レイヤ3インタフェースを介してSから複数の最短経路が存在するため、トラフィックを転送するために使用される場合、。
FIB Forwarding Information Base. The database used by the packet forwarder to determine what actions to perform on a packet.
FIB転送情報ベース。データベースは、パケット上で実行するためにどのようなアクションを決定するために、パケットフォワーダが使用します。
IPFRR IP fast-reroute.
IPFRR IP高速再ルーティング。
Link(A->B) A link connecting router A to router B.
リンク（A-> B）ルータBにルータAを接続するリンク
LFA Loop-Free Alternate. A neighbor N, that is not a primary neighbor E, whose shortest path to the destination D does not go back through the router S. The neighbor N must meet the following condition: Distance_opt(N, D) < Distance_opt(N, S) + Distance_opt(S, D)
LFAループフリーの代替。 Distance_opt（N、D）<Distance_opt（N、S）：近隣Nは、それは、その最短経路宛先Dへの隣人Nには、次の条件を満たさなければならないバックルータS.通過しない一次隣接Eではありません+ Distance_opt（S、D）
Loop-Free Neighbor A neighbor N_i, which is not the particular primary neighbor E_k under discussion, and whose shortest path to D does not traverse S. For example, if there are two primary neighbors E_1 and E_2, E_1 is a loop-free neighbor with regard to E_2, and vice versa.
ループフリーの隣接は、特定の一次議論下隣接E_k、及びDへの最短経路は、例えばS.を通過しないではない隣人N_iは、二つの主要な隣人E_1とE_2がある場合、E_1はループフリーネイバーでありますE_2について、およびその逆で。
Loop-Free Link-Protecting Alternate A path via a Loop-Free Neighbor N_i that reaches destination D without going through the particular link of S that is being protected. In some cases, the path to D may go through the primary neighbor E.
ループフリーリンク保護代替保護されてSの特定のリンクを経由することなく目的地Dに到達したループフリーネイバーN_i経由パス。いくつかのケースでは、Dへのパスは、プライマリ隣人E.を経ること
Loop-Free Node-Protecting Alternate A path via a Loop-Free Neighbor N_i that reaches destination D without going through the particular primary neighbor (E) of S that is being protected.
ループフリーノード保護代替的に保護されてSの特定の一次隣接（E）を経由せずに目的地Dに到達するループフリー隣接N_i経由パス。
N_i The ith neighbor of S.
S.のN_iザ・i番目の隣人
Primary Neighbor A neighbor N_i of S which is one of the next hops for destination D in S's FIB prior to any failure.
プライマリ近隣故障前にSのFIB内の宛先Dのための次のホップの一つであるSの隣接N_i。
R_i_j The jth neighbor of N_i.
N_iのj番目の隣人をR_i_j。
Repair Path The path used by a repairing node to send traffic that it is unable to send via the normal path owing to a failure.
修復パスは、修復ノードによって使用されるパスは、故障のために、通常のパスを介して送信できないトラフィックを送信します。
Routing Transition The process whereby routers converge on a new topology. In conventional networks, this process frequently causes some disruption to packet delivery.
ルーティングの移行ルータが新しいトポロジに収束するプロセス。従来のネットワークでは、このプロセスは、しばしばパケット送達にいくつかの混乱を引き起こします。
RPF Reverse Path Forwarding, i.e., checking that a packet is received over the interface that would be used to send packets addressed to the source address of the packet.
RPFリバースパス転送、すなわち、パケットはパケットの送信元アドレス宛のパケットを送信するために使用されるインターフェースを介して受信されることを確認。
S Used to denote a router that is the source of a repair that is computed in anticipation of the failure of a neighboring router denoted as E, or of the link between S and E. It is the viewpoint from which IP fast-reroute is described.
これは、IP高速再ルーティングが記述された観点であるEとして示さ隣接ルータが故障した、またはS及びEの間のリンクを見越して計算される修復の元であるルータを示すために使用S 。
SPF Shortest Path First, e.g., Dijkstra's algorithm.
SPF最短パス優先、例えば、ダイクストラ法。
SPT Shortest path tree
SPT最短パスツリー
Upstream Forwarding Loop A forwarding loop that involves a set of routers, none of which is directly connected to the link that has caused the topology change that triggered a new SPF in any of the routers.
上流の転送ループAは、直接ルータのいずれかで新しいSPFをトリガトポロジ変更が発生したリンクに接続されているいずれもルータのセットを含むループを転送します。
The initial scope of this work is in the context of link state IGPs. Link state protocols provide ubiquitous topology information, which facilitates the computation of repairs paths.
この作品の最初の範囲は、リンク状態のIGPのコンテキストです。リンク状態プロトコルは修復経路の計算を容易にするユビキタストポロジ情報を、提供します。
Provision of similar facilities in non-link state IGPs and BGP is a matter for further study, but the correct operation of the repair mechanisms for traffic with a destination outside the IGP domain is an important consideration for solutions based on this framework.
非リンク状態のIGPとBGPで同様の施設の提供は、さらなる研究のための問題ですが、IGPドメイン外部の宛先との交通のための修復メカニズムの正しい操作は、このフレームワークに基づくソリューションの重要な考慮事項です。
Complete protection against multiple unrelated failures is out of scope of this work.
複数の無関係な障害に対する完全な保護は、この作業の範囲外です。
The duration of the packet delivery disruption caused by a conventional routing transition is determined by a number of factors:
従来のルーティング遷移によって生じるパケット配信中断の期間は多くの要因によって決定されます。
1. The time taken to detect the failure. This may be of the order of a few milliseconds when it can be detected at the physical layer, up to several tens of seconds when a routing protocol Hello is employed. During this period, packets will be unavoidably lost.
1.時間が障害を検出するのにかかります。ルーティングプロトコルハローが使用される場合、それが数十秒まで、物理レイヤで検出することができる場合、これは、数ミリ秒のオーダーであってもよいです。この期間中、パケットが不可避的に失われます。
2. The time taken for the local router to react to the failure. This will typically involve generating and flooding new routing updates, perhaps after some hold-down delay, and re-computing the router's FIB.
2.ローカルルータにかかる時間は、失敗に反応します。これは、一般的に生成し、おそらくいくつかのホールドダウンの遅延の後、新しいルーティングアップデートをフラッディング伴い、再計算ルータのFIBをします。
3. The time taken to pass the information about the failure to other routers in the network. In the absence of routing protocol packet loss, this is typically between 10 milliseconds and 100 milliseconds per hop.
3.時間は、ネットワーク内の他のルータに障害に関する情報を渡すために取ら。ルーティングプロトコルパケット損失の非存在下では、これは、典型的には10ミリ秒とホップ当たり100ミリ秒の間です。
4. The time taken to re-compute the forwarding tables. This is typically a few milliseconds for a link state protocol using Dijkstra's algorithm.
4.時間は、転送テーブルを再計算するために撮影しました。これは通常、ダイクストラのアルゴリズムを使用してリンク状態プロトコルの数ミリ秒です。
5. The time taken to load the revised forwarding tables into the forwarding hardware. This time is very implementation dependent and also depends on the number of prefixes affected by the failure, but may be several hundred milliseconds.
5.時間は、転送ハードウェアに改訂された転送テーブルをロードするために撮影しました。この時間は非常に実装依存であり、また、障害の影響を受けプレフィックスの数に依存するが、数百ミリ秒とすることができます。
The disruption will last until the routers adjacent to the failure have completed steps 1 and 2, and until all the routers in the network whose paths are affected by the failure have completed the remaining steps.
故障に隣接ルータは、ステップ1および2を完了するまで、およびパス障害の影響を受けているネットワーク内のすべてのルータは、残りのステップを完了するまで中断が続きます。
The initial packet loss is caused by the router(s) adjacent to the failure continuing to attempt to transmit packets across the failure until it is detected. This loss is unavoidable, but the detection time can be reduced to a few tens of milliseconds as described in Section 5.1.
最初のパケット損失は、それが検出されるまで、障害を横切ってパケットを送信しようとし続ける故障に隣接ルータ（複数可）によって引き起こされます。この損失は避けられないが、5.1節で説明したように検出時間は数十ミリ秒に短縮することができます。
In some topologies, subsequent packet loss may be caused by the "micro-loops" which may form as a result of temporary inconsistencies between routers' forwarding tables [RFC5715]. These inconsistencies are caused by steps 3, 4, and 5 above, and in many routers it is step 5 that is both the largest factor and that has the greatest variance between routers. The large variance arises from implementation differences and from the differing impact that a failure has on each individual router. For example, the number of prefixes affected by the failure may vary dramatically from one router to another.
一部のトポロジでは、後続のパケット損失は、ルータの転送テーブル[RFC5715]の間の一時的な不整合の結果として形成することができる「マイクロループ」によって引き起こされ得ます。これらの不整合は、ステップ3,4に起因する、上記5、及び多くのルータでは、最大の要因でもあり、それはルータ間の最大の分散を有するステップ5れます。大きな差異は実装の違いから、障害が個々のルータであり異なる影響から生じます。例えば、障害によって影響を受けるプレフィクスの数は、一つのルータから別のものに劇的に変化してもよいです。
In order to reduce packet disruption times to a duration commensurate with the failure detection times, two mechanisms may be required:
故障検出時間に見合った期間にパケットの中断時間を短縮するために、2つのメカニズムが必要とされ得ます。
a. A mechanism for the router(s) adjacent to the failure to rapidly invoke a repair path, which is unaffected by any subsequent re-convergence.
A。急速に後続の再収束に影響されない修復経路を、起動に失敗に隣接ルータ（複数可）のためのメカニズム。
b. In topologies that are susceptible to micro-loops, a micro-loop control mechanism may be required [RFC5715].
B。マイクロループに感受性であるトポロジでは、マイクロループ制御機構は、[RFC5715]を必要とすることができます。
Performing the first task without the second may result in the repair path being starved of traffic and hence being redundant. Performing the second without the first will result in traffic being discarded by the router(s) adjacent to the failure.
第ことなく、第1のタスクを実行すると、トラフィックが不足し、したがって、冗長されている修復経路をもたらすことができます。第なく、第2の実行は、トラフィックが障害に隣接ルータ（複数可）によって廃棄されることになります。
Repair paths may always be used in isolation where the failure is short-lived. In this case, the repair paths can be kept in place until the failure is repaired, therefore there is no need to advertise the failure to other routers.
修復経路は常に障害が短命であり、単独で使用してもよいです。この場合、障害が修復されるまで、修復パスが所定の位置に保持することができ、したがって、他のルータに失敗したことを宣伝する必要はありません。
Similarly, micro-loop avoidance may be used in isolation to prevent loops arising from pre-planned management action. In which case the link or node being shut down can remain in service for a short time after its removal has been announced into the network, and hence it can function as its own "repair path".
同様に、マイクロループの回避は、予め計画管理アクションから生じるループを防ぐために単独で使用することができます。その除去は、ネットワークに発表された後、リンクまたはノードがシャットダウンされた場合には、短時間のサービスに留まることができ、ひいてはそれ自身「修復経路」として機能することができます。
Note that micro-loops may also occur when a link or node is restored to service, and thus a micro-loop avoidance mechanism may be required for both link up and link down cases.
リンクまたはノードがサービスに復帰するので、マイクロループ回避メカニズムは、リンクアップの両方に必要とケースをリンクダウンしてもよい場合に、マイクロループも発生する可能性があります。
The set of mechanisms required for an effective solution to the problem can be broken down into the sub-problems described in this section.
問題に対する有効な解決策のために必要な機構のセットは、このセクションで説明するサブ問題に分解することができます。
It is critical that the failure detection time is minimized. A number of well-documented approaches are possible, such as:
障害検出時間が最小化されることが重要です。十分に文書化され多数のアプローチが可能であり、例えば：
2. Protocol detection that is routing protocol independent; for example, the Bidirectional Failure Detection protocol [BFD].
ルーティングプロトコルに依存しない2プロトコル検出。例えば、双方向障害検知プロトコル[BFD]。
When configuring packet-based failure detection mechanisms it is important that consideration be given to the likelihood and consequences of false indications of failure. The incidence of false indication of failure may be minimized by appropriately prioritizing the transmission, reception, and processing of the packets used to detect link or node failure. Note that this is not an issue that is specific to IPFRR.
パケットベースの障害検出メカニズムを設定する場合、検討が可能性と故障の誤表示の結果に与えられることが重要です。故障の誤指示の発生を適切にリンクまたはノードの障害を検出するために使用されるパケットの送信、受信、および処理を優先することによって最小化することができます。これはIPFRRに固有の問題ではないことに注意してください。
Once a failure has been detected by one of the above mechanisms, traffic that previously traversed the failure is transmitted over one or more repair paths. The design of the repair paths should be such that they can be pre-calculated in anticipation of each local failure and made available for invocation with minimal delay. There are three basic categories of repair paths:
障害が上記の機構のいずれかによって検出されると、以前に故障を横断したトラフィックは、一つ以上の救済パスを介して送信されます。修復経路の設計は、それらが各ローカル故障を見越して事前に計算され、最小の遅延で、呼び出しのために利用可能にすることができるようなものであるべきです。修理パスの三つの基本的なカテゴリがあります。
1. Equal cost multi-paths (ECMP). Where such paths exist, and one or more of the alternate paths do not traverse the failure, they may trivially be used as repair paths.
1.等価コストマルチパス（ECMP）。そのような経路が存在し、代替パスの1つ以上が故障を通過していない場合、それらは自明修復経路として使用することができます。
2. Loop-free alternate paths. Such a path exists when a direct neighbor of the router adjacent to the failure has a path to the destination that can be guaranteed not to traverse the failure.
2.ループのない代替パス。故障に隣接ルータの直接隣接障害を横断しないように保証することができる宛先へのパスを有する場合、そのようなパスが存在します。
3. Multi-hop repair paths. When there is no feasible loop-free alternate path it may still be possible to locate a router, which is more than one hop away from the router adjacent to the failure, from which traffic will be forwarded to the destination without traversing the failure.
3.マルチホップ修復経路。全く可能ループのない代替パスが存在しない場合、まだ、複数のホップ離れてトラフィックが障害を通過することなく、宛先に転送され、そこから故障に隣接ルータであるルータを配置することも可能です。
ECMP and loop-free alternate paths (as described in [RFC5286]) offer the simplest repair paths and would normally be used when they are available. It is anticipated that around 80% of failures (see Section 5.2.2) can be repaired using these basic methods alone.
ECMPおよびループフリーの代替経路（[RFC5286]に記載されているように）最も単純な修復経路を提供し、それらが利用可能な場合、通常使用されるであろう。失敗（5.2.2項を参照）の約80％が一人でこれらの基本的な方法を使用して修復することができることが予想されます。
Multi-hop repair paths are more complex, both in the computations required to determine their existence, and in the mechanisms required to invoke them. They can be further classified as:
マルチホップ修復経路は、それらの存在を決定するために必要な計算において、それらを起動するために必要な機構の両方において、より複雑です。彼らは、さらに次のように分類できます。
a. Mechanisms where one or more alternate FIBs are pre-computed in all routers, and the repaired packet is instructed to be forwarded using a "repair FIB" by some method of per-packet signaling such as detecting a "U-turn" [UTURN], [FIFR] or by marking the packet [SIMULA].
A。 1つまたは複数の代替のFIBは、すべてのルータに事前に計算され、そして修復パケットは、パケットごとのような「Uターン」を検出するようにシグナル伝達のいくつかの方法により「修復FIB」[UTURN]を使用して転送するように指示されるメカニズム[FIFR]またはパケットをマーキングすることによって[SIMULA]。
b. Mechanisms functionally equivalent to a loose source route that is invoked using the normal FIB. These include tunnels [TUNNELS], alternative shortest paths [ALT-SP], and label-based mechanisms.
B。通常のFIBを用いて呼び出されるルーズソースルートと機能的に同等のメカニズム。これらは、トンネル[TUNNELS]、代替の最短経路[ALT-SP]、ラベルベースの機構を含みます。
c. Mechanisms employing special addresses or labels that are installed in the FIBs of all routers with routes pre-computed to avoid certain components of the network. For example, see [NOTVIA].
C。ネットワークの特定のコンポーネントを回避するために事前計算ルートにすべてのルータのFIBにインストールされている特別なアドレスまたはラベルを使用する機構。例えば、[NOTVIA]参照。
In many cases, a repair path that reaches two hops away from the router detecting the failure will suffice, and it is anticipated that around 98% of failures (see Section 5.2.2) can be repaired by this method. However, to provide complete repair coverage, some use of longer multi-hop repair paths is generally necessary.
多くの場合、故障検出離れルータから2つのホップに到達修復経路が十分で、この方法で修復することができる（セクション5.2.2を参照）障害の約98％と予想されます。しかし、完全な修理保証を提供するために、長いマルチホップ修理パスの一部使用が一般的に必要です。
A particular repair path may be valid for all destinations which require repair or may only be valid for a subset of destinations. If a repair path is valid for a node immediately downstream of the failure, then it will be valid for all destinations previously reachable by traversing the failure. However, in cases where such a repair path is difficult to achieve because it requires a high order multi-hop repair path, it may still be possible to identify lower-order repair paths (possibly even loop-free alternate paths) that allow the majority of destinations to be repaired. When IPFRR is unable to provide complete repair, it is desirable that the extent of the repair coverage can be determined and reported via network management.
特定の修理・パスは、修理を必要とするか、または宛先のみのサブセットのために有効であり、すべての宛先に対して有効です。修理パスが失敗のすぐ下流のノードに対して有効である場合、それは失敗を横断することにより、以前に到達可能なすべての宛先に対して有効となります。しかし、場合には、このような修復経路は、それが高いため、マルチホップ修復経路を必要とするので、達成するのが困難である場合、まだ大部分を可能下位修復経路（おそらくはループフリー代替パス）を識別することが可能です目的地の修復します。 IPFRRが完全修復を提供することができない場合は、修理保証の程度を決定し、ネットワーク管理を介して報告することができることが望ましいです。
There is a trade-off between minimizing the number of repair paths to be computed, and minimizing the overheads incurred in using higher-order multi-hop repair paths for destinations for which they are not strictly necessary. However, the computational cost of determining repair paths on an individual destination basis can be very high.
そのため、彼らは厳密には必要ではない修復経路の数が計算される最小化、および宛先の高次のマルチホップ修復経路を使用して発生したオーバーヘッドを最小限にトレードオフがあります。しかし、個々の宛先に基づいて修復経路を決定する計算コストは非常に高くなり得ます。
It will frequently be the case that the majority of destinations may be repaired using only the "basic" repair mechanism, leaving a smaller subset of the destinations to be repaired using one of the more complex multi-hop methods. Such a hybrid approach may go some way to resolving the conflict between completeness and complexity.
それはしばしば、より複雑なマルチホップ方法のいずれかを使用して修復される宛先のより小さなサブセットを残して、目的地の大部分は、唯一の「基本的な」修復機構を使用して修復することができる場合であろう。このようなハイブリッドアプローチは、完全性と複雑さの間の紛争を解決するためにいくつかの道を行くことがあります。
The use of repair paths may result in excessive traffic passing over a link, resulting in congestion discard. This reduces the effectiveness of IPFRR. Mechanisms to influence the distribution of repaired traffic to minimize this effect are therefore desirable.
修復経路の使用は、輻輳廃棄その結果、リンクを介して過剰なトラフィックの通過をもたらすことができます。これはIPFRRの有効性を低減します。この影響を最小限に抑えるために修理したトラフィックの分布に影響を与えるメカニズムが望まです。
The repair coverage obtained is dependent on the repair strategy and highly dependent on the detailed topology and metrics. Estimates of the repair coverage quoted in this document are for illustrative purposes only and may not be always be achievable.
得られた修復カバレッジは、修復戦略に依存し、詳細なトポロジ及びメトリックに大きく依存します。本書で引用修理保証の推定値は、説明のみを目的としており、常に達成できないことがあります。
In some cases the repair strategy will permit the repair of all single link or node failures in the network for all possible destinations. This can be defined as 100% coverage. However, where the coverage is less than 100%, it is important for the purposes of comparisons between different proposed repair strategies to define what is meant by such a percentage. There are four possibilities:
いくつかのケースでは、修復戦略は、すべての可能な宛先のネットワーク内のすべての単一のリンクまたはノードの障害の修復を可能にします。これは、100％のカバレッジと定義することができます。カバレッジが100％未満であるところしかし、それは、このような割合が何を意味するかを定義するためのさまざまな提案補修戦略間の比較の目的のために重要です。 4つの可能性があります。
1. The percentage of links (or nodes) that can be fully protected (i.e., for all destinations). This is appropriate where the requirement is to protect all traffic, but some percentage of the possible failures may be identified as being un-protectable.
1.完全に保護することができるリンク（またはノード）の割合（すなわち、すべての宛先のため）。要件は、すべてのトラフィックを保護することですこれは適切であるが、可能性障害のいくつかの割合は、未保護可能であると識別することができます。
2. The percentage of destinations that can be protected for all link (or node) failures. This is appropriate where the requirement is to protect against all possible failures, but some percentage of destinations may be identified as being un-protectable.
2.すべてのリンク（またはノード）の障害のために保護することができる宛先のパーセンテージ。要件は、すべての可能な障害から保護することですこれは適切であるが、都市の割合は、未保護可能であると識別することができます。
3. For all destinations (d) and for all failures (f), the percentage of the total potential failure cases (d*f) that are protected. This is appropriate where the requirement is an overall "best-effort" protection.
すべての宛先（D）については、すべての障害（f）は、保護されて総潜在的な失敗例（dは*のF）の割合について3。要件は、全体的に「ベストエフォート型」の保護ここでこれが適切です。
4. The percentage of packets normally passing though the network that will continue to reach their destination. This requires a traffic matrix for the network as part of the analysis.
4.通常、彼らの目的地に到達していきますネットワークを通過するパケットのパーセンテージ。これは、分析の一部として、ネットワークのトラフィック行列が必要です。
A repair path may be computed to protect against failure of an adjacent link, or failure of an adjacent node. In general, link protection is simpler to achieve. A repair which protects against node failure will also protect against link failure for all destinations except those for which the adjacent node is a single point of failure.
修復経路は、隣接ノードの隣接リンク、又は故障の故障から保護するために計算されてもよいです。一般的には、リンク保護を達成するのは簡単です。ノードの障害から保護し、修復も、隣接ノードが単一障害点となるためにものを除くすべての宛先のリンク障害から保護します。
In some cases, it may be necessary to distinguish between a link or node failure in order that the optimal repair strategy is invoked. Methods for link/node failure determination may be based on techniques such as BFD [BFD]. This determination may be made prior to invoking any repairs, but this will increase the period of packet loss following a failure unless the determination can be performed as part of the failure detection mechanism itself. Alternatively, a subsequent determination can be used to optimize an already invoked default strategy.
場合によっては、最適な修復戦略が呼び出されるようにするために、リンクまたはノードの障害とを区別する必要があるかもしれません。リンク/ノード障害決意するための方法は、BFD [BFD]のような技術に基づくことができます。この決意は、任意の修理を起動する前に行ってもよいが、決意は、障害検出機構自体の一部として実行することができない限り、これは障害後のパケット損失の期間を増加させるであろう。代替的に、後続の決意はすでに呼び出され、デフォルトの戦略を最適化するために使用することができます。
In order to meet the response-time goals, it is expected (though not required) that repair paths, and their associated FIB entries, will be pre-computed and installed ready for invocation when a failure is detected. Following invocation, the repair paths remain in effect until they are no longer required. This will normally be when the routing protocol has re-converged on the new topology taking into account the failure, and traffic will no longer be using the repair paths.
応答時間目標を達成するためには、その修復経路、およびそれらに関連するFIBエントリは、予め計算し、障害が検出されたときに起動するための準備ができてインストールされます（必須ではないが）が期待されます。彼らはもはや必要とされるまでの呼び出しに続いて、修理パスが有効に残っていません。ルーティングプロトコルは、アカウントに失敗を取って新しいトポロジに再収束したとき、これは通常となり、トラフィックはもはや修復のパスを使用しません。
The repair paths have the property that they are unaffected by any topology changes resulting from the failure that caused their instantiation. Therefore, there is no need to re-compute them during the convergence period. They may be affected by an unrelated simultaneous topology change, but such events are out of scope of this work (see Section 5.2.6).
修理・パスは、彼らがインスタンス化の原因となった故障に起因するいかなるトポロジの変更の影響を受けない性質を持っています。したがって、収束期間中にそれらを再計算する必要はありません。彼らは無関係な同時トポロジの変更によって影響を受けることができるが、このようなイベントは、この作業の範囲外である（セクション5.2.6を参照してください）。
Once the routing protocol has re-converged, it is necessary for all repair paths to take account of the new topology. Various optimizations may permit the efficient identification of repair paths that are unaffected by the change, and hence do not require full re-computation. Since the new repair paths will not be required until the next failure occurs, the re-computation may be performed as a background task and be subject to a hold-down, but excessive delay in completing this operation will increase the risk of a new failure occurring before the repair paths are in place.
ルーティングプロトコルを再収束した後はすべての修復パスが新しいトポロジを考慮することが必要です。様々な最適化は、完全な再計算を必要とせず、したがって変化によって影響を受けない修復経路の効率的な同定を可能とすることができます。次の障害が発生するまで、新たな修復経路が必要とされないので、再計算は、バックグラウンドタスクとして実行され、ホールドダウンを受けることが、この操作を完了するの過度の遅延は、新規障害のリスクを増加させることができます修理・パスの前に発生した場所です。
Protection against partial or complete failure of LANs is more complex than the point-to-point case. In general, there is a trade-off between the simplicity of the repair and the ability to provide complete and optimal repair coverage.
LANの部分的または完全な障害に対する保護は、ポイント・ツー・ポイントの場合よりも複雑です。一般的には、修理のシンプルさと、完全かつ最適な修理保証を提供する能力との間にはトレードオフが存在します。
Complete protection against multiple unrelated failures is out of scope of this work. However, it is important that the occurrence of a second failure while one failure is undergoing repair should not result in a level of service which is significantly worse than that which would have been achieved in the absence of any repair strategy.
複数の無関係な障害に対する完全な保護は、この作業の範囲外です。しかし、第二の障害発生1つの故障が受けている間に修復が任意の修理戦略の不存在下で達成されたと思われるものよりも著しく悪化しているサービスのレベルになってはならないことが重要です。
Shared Risk Link Groups (SRLGs) are an example of multiple related failures, and the more complex aspects of their protection are a matter for further study.
共有リスクリンクグループ（SRLGs）複数の関連障害の一例であり、その保護のより複雑な側面は、さらなる研究のための問題です。
One specific example of an SRLG that is clearly within the scope of this work is a node failure. This causes the simultaneous failure of multiple links, but their closely defined topological relationship makes the problem more tractable.
この作業の範囲内で明らかであるSRLGの一の具体例は、ノード障害です。これは、複数のリンクの同時故障の原因となるが、その密接に定義された位相関係は、問題がより扱いやすいなります。
Ensuring the absence of micro-loops is important not only because they can cause packet loss in traffic that is affected by the failure, but because by saturating a link with looping packets micro-loops can cause congestion. This congestion can then lead to routers discarding traffic that would otherwise be unaffected by the failure.
彼らは、障害の影響を受けているトラフィックのパケット損失を引き起こす可能性がありますが、理由はパケットマイクロループをループでリンクを飽和させることによって輻輳を引き起こす可能性があるので、マイクロループがないことを確保することだけではなく、重要です。この混雑は、そうでない場合は、障害の影響を受けないだろうトラフィックを破棄ルータにつながることができます。
A number of solutions to the problem of micro-loop formation have been proposed and are summarized in [RFC5715]. The following factors are significant in their classification:
マイクロループ形成の問題に対する解決策の数が提案されていると[RFC5715]にまとめられています。次の要因は、その分類に重要です：
3. Tolerance of multiple failures (from node failures, and in general).
（ノードの障害から、および一般的に）複数の障害の3トレランス。
While many of the management requirements will be specific to particular IPFRR solutions, the following general aspects need to be addressed:
管理要件の多くは、特定のIPFRRソリューションに固有のものになりますが、以下の一般的な側面に対処する必要があります。
A. Enabling/disabling IPFRR support.
A.はIPFRRサポートを無効/有効にします。
B. Enabling/disabling protection on a per-link or per-node basis.
B.は、リンク単位またはノードごとに保護を無効/有効にします。
C. Expressing preferences regarding the links/nodes used for repair paths.
C.は、修理・パスのために使用されるリンク/ノードに関する嗜好を表現します。
D. Configuration of failure detection mechanisms.
障害検出メカニズムのD.設定。
E. Configuration of loop-avoidance strategies
ループ回避戦略のE.設定
A. Notification of links/nodes/destinations that cannot be
protected.
B. Notification of pre-computed repair paths, and anticipated traffic patterns.
事前計算修復経路のB.通知、および予想されるトラフィックパターン。
C. Counts of failure detections, protection invocations, and packets forwarded over repair paths.
C.は、修復パスを介して転送障害検出、保護の呼び出し、およびパケットのカウントします。
D. Testing repairs.
D.テスト修理。
This framework document does not itself introduce any security issues, but attention must be paid to the security implications of any proposed solutions to the problem.
このフレームワークドキュメント自体はセキュリティ上の問題を紹介しませんが、注意は、問題への提案されたソリューションのセキュリティへの影響に注意を払わなければなりません。
Where the chosen solution uses tunnels it is necessary to ensure that the tunnel is not used as an attack vector. One method of addressing this is to use a set of tunnel endpoint addresses that are excluded from use by user traffic.
選択された溶液は、トンネルを使用する場合には、トンネルが攻撃ベクトルとして使用されないことを保証する必要があります。これに対処する一つの方法は、ユーザ・トラフィックによって使用から除外されるトンネルエンドポイントアドレスのセットを使用することです。
There is a compatibility issue between IPFRR and reverse path forwarding (RPF) checking. Many of the solutions described in this document result in traffic arriving from a direction inconsistent with a standard RPF check. When a network relies on RPF checking for security purposes, an alternative security mechanism will need to be deployed in order to permit IPFRR to used.
そこIPFRR間の互換性の問題があるとパス転送（RPF）チェックを逆転します。標準RPFチェックと矛盾方向から到来するトラフィックに、このドキュメントの結果で説明したソリューションの多く。ネットワークがセキュリティ上の目的のためにチェックRPFに依存している場合は、代わりのセキュリティ・メカニズムを使用するIPFRRを可能にするために展開する必要があります。
Because the repair path will often be of a different length than the pre-failure path, security mechanisms that rely on specific Time to Live (TTL) values will be adversely affected.
修理・パスは、多くの場合、障害発生前のパスとは異なる長さのものであろうので、（TTL）値をライブするために、特定の時間に依存しているセキュリティメカニズムが悪影響を受けることになります。
The authors would like to acknowledge contributions made by Alia Atlas, Clarence Filsfils, Pierre Francois, Joel Halpern, Stefano Previdi, and Alex Zinin.
著者はアリアアトラス、クラレンスFilsfils、ピエール・フランソワ・ジョエル・ハルパーン、ステファノPrevidi、およびアレックスジニンの貢献を認めたいと思います。
[ALT-SP] Tian, A., "Fast Reroute using Alternative Shortest Paths", Work in Progress, July 2004.
[ALT-SP]天、A.、 "代替最短経路を使用して高速リルート"、進歩、2004年7月の作業。
[BFD] Katz, D. and D. Ward, "Bidirectional Forwarding Detection", Work in Progress, January 2010.
[BFD]カッツ、D.とD.ウォード、 "双方向フォワーディング検出"、進歩、2010年1月の作業。
[FIFR] Nelakuditi, S., Lee, S., Lu, Y., Zhang, Z., and C. Chuah, "Fast Local Rerouting for Handling Transient Link Failures", IEEE/ACM Transactions on Networking, Vol. 15, No. 2, DOI 10.1109/TNET.2007.892851, available from http://www.ieeexplore.ieee.org, April 2007.
[FIFR] Nelakuditi、S.、リー、S.、呂、Y.、張、Z.、およびC. Chuah、ネットワーク上の、IEEE / ACM取引、巻 "一時リンク障害の処理のための高速ローカル再ルーティング"。 15、2007年4月、http://www.ieeexplore.ieee.orgから入手可能な2号、DOI 10.1109 / TNET.2007.892851、。
[NOTVIA] Shand, M., Bryant, S., and S. Previdi, "IP Fast Reroute Using Not-via Addresses", Work in Progress, July 2009.
[NOTVIA] "使用しない - を経由してIPアドレス高速リルート" シャンド、M.、ブライアント、S.、およびS. Previdiは、進捗状況、2009年7月に作業します。
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4090]パン、P.、ツバメ、G.、およびA.アトラスは、RFC 4090、2005年5月 "高速リルート機能拡張は、LSPトンネルの-TEをRSVPに"。
[RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast Reroute: Loop-Free Alternates", RFC 5286, September 2008.
[RFC5286]アトラス、A.とA.ジニン、 "IP高速リルートのための基本仕様：ループフリーのAlternates"、RFC 5286、2008年9月。
[RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free Convergence", RFC 5715, January 2010.
[RFC5715]シャンド、M.とS.ブライアント、 "ループフリーコンバージェンスのための枠組み"、RFC 5715、2010年1月。
[SIMULA] Kvalbein, A., Hansen, A., Cicic, T., Gjessing, S., and O. Lysne, "Fast IP Network Recovery using Multiple Routing Configurations", Infocom 10.1109/INFOCOM.2006.227, available from http://www.ieeexplore.ieee.org, April 2006.
HTTPから入手できる "複数のルーティング設定を使用して高速IPネットワークの回復" [SIMULA] Kvalbein、A.、ハンセン、A.、Cicic、T.、Gjessing、S.、およびO. Lysne、インフォコム10.1109 / INFOCOM.2006.227、： //www.ieeexplore.ieee.org、2006年4月。
[TUNNELS] Bryant, S., Filsfils, C., Previdi, S., and M. Shand, "IP Fast Reroute using tunnels", Work in Progress, November 2007.
"トンネルを使用してIP高速リルート" [TUNNELS]ブライアント、S.、Filsfils、C.、Previdi、S.、およびM.シャンド、進歩、2007年11月に作業。
[UTURN] Atlas, A., "U-turn Alternates for IP/LDP Fast-Reroute", Work in Progress, February 2006.
[UTURN]アトラス、A.、 "IP / LDP高速リルートのためのUターンを交互に"、進歩、2006年2月に作業。
Authors' Addresses
著者のアドレス
Mike Shand Cisco Systems 250, Longwater Avenue. Reading, Berks RG2 6GB UK
マイク・シャンドシスコシステムズ250、Longwaterアベニュー。読書、バークスRG2 6ギガバイト英国
EMail: mshand@cisco.com
メールアドレス：mshand@cisco.com
Stewart Bryant Cisco Systems 250, Longwater Avenue. Reading, Berks RG2 6GB UK
スチュワートブライアントシスコシステムズ250、Longwaterアベニュー。読書、バークスRG2 6ギガバイト英国
EMail: stbryant@cisco.com
メールアドレス：stbryant@cisco.com