[要約] RFC 5714は、IP Fast Reroute（IP FRR）フレームワークに関するものであり、ネットワークの高可用性を確保するための技術を提供します。このRFCの目的は、IP FRRの実装と展開に関するガイドラインを提供することです。
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
IP Fast Rerouteフレームワーク
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 Fast-Rerouteとは異なり、メカニズムは、従来の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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
ルーターの最近の進歩により、リンク状態IGPSを使用して慎重に構成されたネットワークの場合、この間隔は1秒未満に減少しました。ただし、新しいインターネットサービスが出現しており、これはこれよりも桁違いに短いトラフィックの損失に敏感です。
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 Fast-Reroute [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 Fast-Rerouteについて議論する他のドキュメントを定義します。
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.
distany_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)
ダウンストリームパスこれは、ネイバーnが次の条件を満たしている場合、ループフリーの代替のサブセットです：distange_opt（n、d）<distany_opt（s、d）
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は、Sから宛先Dに到達するための主要な隣のルーターを示すために使用されます。ここで、SからDまでの最短パスのECMPセットがあり、これらはE_1、E_2などと呼ばれます。
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の場合、複数のプライマリネクストホップを使用してトラフィックを転送するために使用されます。
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 Fast-Reroute。
Link(A->B) A link connecting router A to router B.
リンク（a-> b）ルーターAをルーターBに接続するリンクB
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ループフリーの代替。隣人nは、宛先Dへの最短経路がルーターSを通って戻っていない主要な隣人Eではありません。隣接nは次の条件を満たす必要があります。distany_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.
ループフリーネイバーA隣人N_Iは、議論中の特定の主要な隣人E_Kではなく、Dへの最短パスはSを通過しません。たとえば、2つの主要な隣接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.
ループフリーのノード保護の交互に、保護されている特定の主要な隣接（e）を通過せずに宛先Dに到達するループフリー隣接n_iを介してパスを交互に行います。
N_i The ith neighbor of S.
n_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.
プライマリネイバーA n_iのn_iは、失敗する前にSのFIBの宛先Dの次のホップの1つです。
R_i_j The jth neighbor of N_i.
r_i_j n_iのjth隣人。
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.
sは、eとして示される隣接ルーターの障害、またはSとEのリンクのリンクを見越して計算される修理の原因であるルーターを示すために使用されます。。
SPF Shortest Path First, e.g., Dijkstra's algorithm.
SPF最初のパス、たとえば、Dijkstraのアルゴリズム。
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.
アップストリーム転送ループ一連のルーターを含む転送ループは、いずれもルーターの新しい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.
この作業の初期範囲は、リンク状態IGPSのコンテキストにあります。リンク状態プロトコルは、遍在するトポロジ情報を提供し、修理パスの計算を容易にします。
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. ネットワーク内の他のルーターへの失敗に関する情報を渡すのにかかった時間。ルーティングプロトコルパケット損失がない場合、これは通常、1ホップあたり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. 転送テーブルを再計算するのにかかる時間。これは通常、Dijkstraのアルゴリズムを使用したリンク状態プロトコルの数ミリ秒です。
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.
2番目のタスクなしで最初のタスクを実行すると、修理パスが交通に飢えているため、冗長になります。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:
障害検出時間を最小限に抑えることが重要です。次のような多くの十分に文書化されたアプローチが可能です。
1. Physical detection; for example, loss of light.
1. 物理的検出;たとえば、光の喪失。
2. Protocol detection that is routing protocol independent; for example, the Bidirectional Failure Detection protocol [BFD].
2. プロトコルを独立しているルーティングであるプロトコル検出。たとえば、双方向障害検出プロトコル[BFD]。
3. Routing protocol detection; for example, use of "fast Hellos".
3. ルーティングプロトコル検出。たとえば、「Fast Hellos」の使用。
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つによって障害が検出されると、以前に障害を横断していたトラフィックが1つ以上の修理パスに送信されます。修理パスの設計は、各ローカル障害を見越して事前に計算され、最小限の遅延で呼び出しが可能になるようにする必要があります。修復パスには3つの基本的なカテゴリがあります。
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. マルチホップの修理パス。実行可能なループフリーの代替パスがない場合、ルーターを見つけることができる可能性があります。ルーターは、障害に隣接するルーターから1つ以上離れているため、障害を横断せずにトラフィックが宛先に転送されます。
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]で説明されている）は、最も単純な修理パスを提供し、通常は使用可能なときに使用されます。これらの基本的な方法だけを使用して、障害の約80％（セクション5.2.2を参照）を修復できると予想されます。
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を使用して呼び出されるゆるいソースルートと機能的に同等です。これらには、トンネル[トンネル]、代替の最短パス[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. ネットワークの特定のコンポーネントを回避するために、すべてのルーターのFIBSに設置されたすべてのルーターの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ホップに到達する修復パスで十分であり、この方法では障害の約98％（セクション5.2.2を参照）を修復できると予想されます。ただし、完全な修理カバレッジを提供するには、一般的に長いマルチホップの修理パスを使用することが必要です。
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.
3. すべての目的地（d）およびすべての障害（f）について、保護されている潜在的な障害ケース全体（d*f）の割合。これは、要件が全体的な「ベストエフォルト」保護である場合に適切です。
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.
複数の無関係な障害に対する完全な保護は、この作業の範囲外です。ただし、修理が行われている間に2回目の障害が発生すると、修理戦略がない場合に達成されたレベルよりも著しく悪いサービスをもたらさないことが重要です。
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.
共有リスクリンクグループ（SRLG）は複数の関連する障害の例であり、それらの保護のより複雑な側面は、さらなる研究の問題です。
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の特定の例の1つは、ノード障害です。これにより、複数のリンクの同時障害が発生しますが、それらの密接に定義されたトポロジー関係により、問題がより扱いやすくなります。
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]に要約されています。次の要因は、分類において重要です。
1. Partial or complete protection against micro-loops.
1. マイクロループに対する部分的または完全な保護。
2. Convergence delay.
2. 収束遅延。
3. Tolerance of multiple failures (from node failures, and in general).
3. 複数の障害の耐性（ノード障害から、および一般的に）。
4. Computational complexity (pre-computed or real time).
4. 計算の複雑さ（事前計算またはリアルタイム）。
5. Applicability to scheduled events.
5. スケジュールされたイベントへの適用性。
6. Applicability to link/node reinstatement.
6. リンク/ノード回復への適用性。
7. Topological constraints.
7. トポロジー的制約。
While many of the management requirements will be specific to particular IPFRR solutions, the following general aspects need to be addressed:
管理要件の多くは特定のIPFRRソリューションに固有のものですが、次の一般的な側面に対処する必要があります。
1. Configuration
1. 構成
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.ループ回避戦略の構成
2. Monitoring and operational support
2. 監視と運用サポート
A. Notification of links/nodes/destinations that cannot be protected.
A.保護できないリンク/ノード/宛先の通知。
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.
選択したソリューションがトンネルを使用する場合、トンネルが攻撃ベクトルとして使用されないことを確認する必要があります。これに対処する1つの方法は、ユーザートラフィックによる使用から除外されるトンネルエンドポイントアドレスのセットを使用することです。
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.
著者は、Alia Atlas、Clarence Filsfils、Pierre Francois、Joel Halpern、Stefano Previdi、およびAlex Zininによる貢献を認めたいと考えています。
[ALT-SP] Tian, A., "Fast Reroute using Alternative Shortest Paths", Work in Progress, July 2004.
[Alt-SP] Tian、A。、「代替の最短パスを使用した高速再ルート」、2004年7月、進行中の作業。
[BFD] Katz, D. and D. Ward, "Bidirectional Forwarding Detection", Work in Progress, January 2010.
[BFD] Katz、D。およびD. Ward、「双方向転送検出」、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.、Lee、S.、Lu、Y.、Zhang、Z.、およびC. Chuah、「過渡リンク障害の取り扱いのための高速ローカル再ルーティング」、NetworkingのIEEE/ACMトランザクション、Vol。15、No。2、doi 10.1109/tnet.2007.892851、http：//www.ieeexplore.ieee.orgから入手可能、2007年4月。
[NOTVIA] Shand, M., Bryant, S., and S. Previdi, "IP Fast Reroute Using Not-via Addresses", Work in Progress, July 2009.
[Notvia] Shand、M.、Bryant、S。、およびS. Previdi、「非Viaアドレスを使用したIP Fast Reroute」、2009年7月、進行中の作業。
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4090] Pan、P.、Swallow、G。、およびA. Atlas、「LSPトンネルのRSVP-TEへの高速拡張式」、RFC 4090、2005年5月。
[RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast Reroute: Loop-Free Alternates", RFC 5286, September 2008.
[RFC5286] Atlas、A。およびA. Zinin、「IP高速リルートの基本仕様：ループフリーの代替品」、RFC 5286、2008年9月。
[RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free Convergence", RFC 5715, January 2010.
[RFC5715] Shand、M。およびS. Bryant、「ループフリーコンバージェンスのフレームワーク」、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.
[Simula] Kvalbein、A.、Hansen、A.、Cicic、T.、Gjessing、S.、およびO. Lysne、「複数のルーティング構成を使用した高速IPネットワークリカバリ」、InfoCom 10.1109/InfoCom.2006.227、HTTPから入手可能：//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.
[Tunnels] Bryant、S.、Filsfils、C.、Previdi、S。、およびM. Shand、「Tunnelsを使用したIP Fast Reroute」、2007年11月、Work in Progress。
[UTURN] Atlas, A., "U-turn Alternates for IP/LDP Fast-Reroute", Work in Progress, February 2006.
[Uturn] Atlas、A。、「UターンはIP/LDP Fast-Rerouteの代替」、2006年2月に進行中の作業。
Authors' Addresses
著者のアドレス
Mike Shand Cisco Systems 250, Longwater Avenue. Reading, Berks RG2 6GB UK
Mike Shand Cisco Systems 250、Longwater Avenue。読書、バークスRG2 6GB UK
EMail: mshand@cisco.com
Stewart Bryant Cisco Systems 250, Longwater Avenue. Reading, Berks RG2 6GB UK
スチュワートブライアントシスコシステム250、ロングウォーターアベニュー。読書、バークスRG2 6GB UK
EMail: stbryant@cisco.com