[要約] RFC 6981は、IPおよびMPLSの高速再ルーティングを実現するためのNot-Viaアドレスの使用に関するフレームワークを提供しています。このRFCの目的は、ネットワークの冗長性と信頼性を向上させるために、高速な再ルーティングメカニズムを提供することです。
Internet Engineering Task Force (IETF) S. Bryant
Request for Comments: 6981 S. Previdi
Category: Informational Cisco Systems
ISSN: 2070-1721 M. Shand
Individual Contributor
August 2013
A Framework for IP and MPLS Fast Reroute Using Not-Via Addresses
Not-Viaアドレスを使用したIPおよびMPLS高速リルートのフレームワーク
Abstract
概要
This document presents an illustrative framework for providing fast reroute in an IP or MPLS network through encapsulation and forwarding to "not-via" addresses. The general approach described here uses a single level of encapsulation and could be used to protect unicast, multicast, and LDP traffic against link, router, and shared risk group failure, regardless of network topology and metrics.
このドキュメントは、カプセル化と「not-via」アドレスへの転送を介してIPまたはMPLSネットワークで高速リルートを提供するためのフレームワークの例を示しています。ここで説明する一般的なアプローチは、単一レベルのカプセル化を使用し、ネットワークトポロジやメトリックに関係なく、リンク、ルーター、共有リスクグループの障害からユニキャスト、マルチキャスト、およびLDPトラフィックを保護するために使用できます。
The mechanisms presented in this document are purely illustrative of the general approach and do not constitute a protocol specification. The document represents a snapshot of the work of the Routing Area Working Group at the time of publication and is published as a document of record. Further work is needed before implementation or deployment.
このドキュメントに示されているメカニズムは、一般的なアプローチの単なる例示であり、プロトコル仕様を構成するものではありません。この文書は、発行時のルーティングエリアワーキンググループの作業のスナップショットを表しており、記録文書として発行されます。実装または展開の前に、さらに作業が必要です。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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（Internet Engineering Task Force）の製品です。これは、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/rfc6981.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6981で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
1.1. The Purpose of This Document ...............................4
1.2. Overview ...................................................4
2. Requirements Language ...........................................5
3. Overview of Not-Via Repairs .....................................5
3.1. Use of Equal-Cost Multi-Path ...............................6
3.2. Use of LFA Repairs .........................................6
4. Not-Via Repair Path Computation .................................7
4.1. Computing Not-Via Repairs in Distance and Path
Vector Routing Protocols ...................................8
5. Operation of Repairs ............................................8
5.1. Node Failure ...............................................8
5.2. Link Failure ...............................................9
5.2.1. Loop Prevention under Node Failure ..................9
5.3. Multi-Homed Prefixes .......................................9
5.4. Installation of Repair Paths ..............................11
6. Compound Failures ..............................................12
6.1. Shared Risk Link Groups ...................................12
6.2. Local Area Networks .......................................17
6.2.1. Simple LAN Repair ..................................18
6.2.2. LAN Component Repair ...............................19
6.2.3. LAN Repair Using Diagnostics .......................19
6.3. Multiple Independent Failures .............................20
6.3.1. Looping Repairs ....................................20
6.3.2. Outline Solution ...................................21
6.3.3. Mutually Looping Repairs ...........................22
6.3.3.1. Dropping Looping Packets ..................23
6.3.3.2. Computing Non-looping Repairs of Repairs ..23
6.3.4. Mixing LFAs and Not-Via ............................25
7. Optimizing Not-Via Computations Using LFAs .....................26
8. Multicast ......................................................27
9. Fast Reroute in an MPLS LDP Network ............................27
10. Encapsulation .................................................28
11. Routing Extensions ............................................28
12. Incremental Deployment ........................................28
13. Manageability Considerations ..................................29
13.1. Pre-failure Configuration ................................29
13.2. Pre-failure Monitoring and Operational Support ...........29
13.3. Failure Action Monitoring ................................30
14. Security Considerations .......................................30
15. Acknowledgements ..............................................31
16. References ....................................................31
16.1. Normative References .....................................31
16.2. Informative References ...................................31
Appendix A. Q-Space ...............................................33
This document presents an illustrative framework for providing fast reroute around a failure in an IP or MPLS network based on the concept of tunneling or encapsulating packets via an IP address that is known to avoid the failure. The general approach described here uses a single level of encapsulation and could be used to protect unicast, multicast, and LDP traffic against link, router, and shared risk group failure, regardless of network topology and metrics.
このドキュメントは、障害を回避することが知られているIPアドレスを介してパケットをトンネリングまたはカプセル化するという概念に基づいて、IPまたはMPLSネットワークでの障害の周りに高速リルートを提供するための例示的なフレームワークを示します。ここで説明する一般的なアプローチは、単一レベルのカプセル化を使用し、ネットワークトポロジやメトリックに関係なく、リンク、ルーター、共有リスクグループの障害からユニキャスト、マルチキャスト、およびLDPトラフィックを保護するために使用できます。
At the time of publication, there is no demand to deploy this technology; however, in view of the subtleties involved in the design of routing protocol extensions to provide IP Fast Reroute (IPFRR) [RFC5714], the Routing Area Working Group considered it desirable to publish this document to place on record the design considerations of the not-via address approach.
公開の時点では、このテクノロジーを配備する必要はありません。ただし、IP Fast Reroute（IPFRR）[RFC5714]を提供するルーティングプロトコル拡張の設計に伴う微妙な点を考慮して、ルーティングエリアワーキンググループは、このドキュメントを公開して、設計上の考慮事項を記録に残すことが望ましいと考えました。アドレスアプローチによる。
The mechanisms presented in this document are purely illustrative of the general approach and do not constitute a protocol specification. The document represents a snapshot of the work of the working group at the time of publication and is published as a document of record. Additional work is needed to specify the necessary routing protocol extensions necessary to support this IPFRR method before implementation or deployment.
このドキュメントに示されているメカニズムは、一般的なアプローチの単なる例示であり、プロトコル仕様を構成するものではありません。ドキュメントは、公開時のワーキンググループの作業のスナップショットを表し、記録のドキュメントとして公開されます。実装または展開の前に、このIPFRRメソッドをサポートするために必要なルーティングプロトコル拡張を指定するために、追加の作業が必要です。
When a link or a router fails, only the neighbors of the failure are initially aware that the failure has occurred. In a network operating IPFRR [RFC5714], the routers that are the neighbors of the failure repair the failure. These repairing routers have to steer packets to their destinations despite the fact that most other routers in the network are unaware of the nature and location of the failure.
リンクまたはルーターに障害が発生した場合、障害が発生したことに気づくのは近隣の障害者だけです。 IPFRR [RFC5714]を運用しているネットワークでは、障害の近隣であるルーターが障害を修復します。これらの修復ルーターは、ネットワーク内の他のほとんどのルーターが障害の性質と場所を認識していないという事実にもかかわらず、宛先にパケットを誘導する必要があります。
A common limitation in most IPFRR mechanisms is an inability to indicate the identity of the failure and explicitly steer the repaired packet around the failure. The extent to which this limitation affects the repair coverage is topology dependent. The mechanism proposed here is to encapsulate the packet to an address that explicitly identifies the network component that the repair must avoid. This produces a repair mechanism that, provided the network is not partitioned by the failure, will always achieve a repair.
ほとんどのIPFRRメカニズムの共通の制限は、障害のIDを示し、修復されたパケットを障害の周りに明示的に誘導できないことです。この制限が修復範囲に影響する程度は、トポロジに依存します。ここで提案するメカニズムは、修復が回避する必要があるネットワークコンポーネントを明示的に識別するアドレスにパケットをカプセル化することです。これにより、ネットワークが障害によって分割されない限り、常に修復が行われる修復メカニズムが生成されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
This section provides a brief overview of the not-via method of IPFRR. Consider the network fragment shown in Figure 1 below, in which S has a packet for some destination D that it would normally send via P and B, and that S suspects that P has failed.
このセクションでは、IPFRRのnot-viaメソッドの概要について説明します。以下の図1に示すネットワークフラグメントを考えてみます。Sには、宛先Pに対して、通常はPとBを介して送信するパケットがあり、SはPが失敗したと疑っています。
A
| Bp is the address to use to get
| a packet to B not via P
|
S----------P----------B. . . . . . . . . .D
\ | Bp^
\ | |
\ | |
\ C |
\ |
X-------Y-------Z
Repair to Bp
Figure 1: Not-Via Repair of Router Failure
図1：ルーター障害の非経由修理
In the not-via IPFRR method, S encapsulates the packet to Bp, where Bp is an address on node B that has the property of not being reachable from node P, i.e., the notation Bp means "an address of node B that is only reachable not via node P". We later show how to install the path from S to Bp such that it is the shortest path from S to B not going via P. If the network contains a path from S to B that does not transit router P, i.e., the network is not partitioned by the failure of P and the path from S to Bp has been installed, then the packet will be successfully delivered to B. In the example in Figure 1, this is the path S-X-Y-Z-B. When the packet addressed to Bp arrives at B, B removes the encapsulation and forwards the repaired packet towards its final destination.
not-via IPFRR方式では、SはパケットをBpにカプセル化します。ここで、BpはノードB上のアドレスであり、ノードPから到達できないという特性があります。つまり、Bpという表記は、「ノードBのアドレスノードP "経由では到達できません。 Pを経由しないSからBへの最短パスになるように、SからBpへのパスをインストールする方法を後で示します。ネットワークにルーターPを経由しないSからBへのパスが含まれている場合、つまり、ネットワークはPの障害によって分割されず、SからBpへのパスがインストールされている場合、パケットはBに正常に配信されます。図1の例では、これはパスSXYZBです。 Bp宛てのパケットがBに到着すると、Bはカプセル化を削除し、修復されたパケットを最終的な宛先に転送します。
Note that if the path from B to the final destination includes one or more nodes that are included in the repair path, a packet may backtrack after the encapsulation is removed. However, because the decapsulating router is always closer to the packet destination than the encapsulating router, the packet will not loop.
Bから最終宛先までのパスに、修復パスに含まれる1つ以上のノードが含まれている場合、カプセル化が削除された後、パケットがバックトラックする可能性があることに注意してください。ただし、カプセル化解除ルーターは常にカプセル化ルーターよりもパケットの宛先に近いため、パケットはループしません。
For complete protection, all of P's neighbors will require a not-via address that allows traffic to be directed to them without traversing P. This is shown in Figure 2. Similarly, P will require a set of not-via addresses (one for each neighbor) allowing traffic to be directed to P without traversing each of those neighbors.
完全な保護のために、Pのすべてのネイバーは、トラフィックをPを経由せずにそれらに向けることができるnot-viaアドレスを必要とします。これは図2に示されています。同様に、Pは一連のnot-viaアドレス（各ネイバー）トラフィックを各ネイバーを経由せずにPに転送できるようにします。
The not-via addresses are advertised in the routing protocol in a way that clearly identifies them as not-via addresses and not 'ordinary' addresses.
not-viaアドレスはルーティングプロトコルでアドバタイズされ、「通常の」アドレスではなくnot-viaアドレスとして明確に識別されます。
A
|Ap
|
Sp Pa|Pb
S----------P----------B
Ps|Pc Bp
|
Cp|
C
Figure 2: The Set of Not-Via P Addresses
図2：Not-Via Pアドレスのセット
A router can use an Equal-Cost Multi-Path (ECMP) repair in place of a not-via repair.
ルータは、not-via修復の代わりにEqual-Cost Multi-Path（ECMP）修復を使用できます。
A router computing a not-via repair path MAY subject the repair to ECMP.
not-via修復パスを計算するルーターは、修復をECMPの対象にする場合があります。
The not-via approach provides complete repair coverage and therefore may be used as the sole repair mechanism. There are, however, advantages in using not-via in combination with Loop-Free Alternates (LFAs) and/or downstream paths as documented in [RFC5286]. In particular, LFAs do not require the assignment and management of additional IP addresses to nodes, they do not require nodes in the network to be upgraded in order to calculate not-via repair paths, and they do not require the use of encapsulation.
not-viaアプローチは完全な修理範囲を提供するため、唯一の修理メカニズムとして使用できます。ただし、[RFC5286]で文書化されているように、not-viaをループフリー代替（LFA）および/またはダウンストリームパスと組み合わせて使用することには利点があります。特に、LFAはノードへの追加のIPアドレスの割り当てと管理を必要とせず、ネットワーク経由のノードをアップグレードせずに修復パスを計算せず、カプセル化を使用する必要もありません。
LFAs are computed on a per-destination basis, and in general only a subset of the destinations requiring repair will have a suitable LFA repair. In this case, those destinations that are repairable by LFAs are so repaired, and the remainder of the destinations are repaired using the not-via encapsulation. On the other hand, the path taken by an LFA repair may be less optimal than that of the equivalent not-via repair for traffic destined to nodes close to the far end of the failure, but it may be more optimal for some other traffic. This document assumes that LFAs will be used where available, but the distribution of repairs between the two mechanisms is a local implementation choice.
LFAは宛先ごとに計算され、一般に、修復が必要な宛先のサブセットのみが適切なLFA修復を行います。この場合、LFAで修復可能な宛先はそのように修復され、残りの宛先はnot-viaカプセル化を使用して修復されます。一方、LFA修復によって取られるパスは、障害の遠端に近いノードを宛先とするトラフィックの同等のnot-via修復よりも最適ではない場合がありますが、他の一部のトラフィックには最適な場合があります。このドキュメントでは、可能な場合はLFAが使用されることを想定していますが、2つのメカニズム間での修復の分散はローカル実装の選択です。
The not-via repair mechanism requires that all routers on the path from S to B (Figure 1) have a route to Bp. They can calculate this by failing node P, running a Shortest Path First (SPF) algorithm, and finding the shortest route to B.
not-via修復メカニズムでは、SからBへのパス上のすべてのルーター（図1）にBpへのルートが必要です。ノードPに障害が発生し、Shortest Path First（SPF）アルゴリズムを実行し、Bへの最短ルートを見つけることで、これを計算できます。
A router has no simple way of knowing whether it is on the shortest path for any particular repair. It is therefore necessary for every router to calculate the path it would use in the event of any possible router failure. Each router therefore "fails" every router in the network, one at a time, and calculates its own best route to each of the neighbors of that router. In other words, with reference to Figure 1, routers A, B, C, X, Y, Z, and P will consider each router in turn, assume that the router has failed, and then calculate its own route to each of the not-via addresses advertised by the neighbors of that router. In other words, in the case of a presumed failure of P, ALL routers (S, A, B, C, X, Y, and Z in this case) calculate their routes to Sp, Ap, Bp, and Cp -- in each case, not via P.
ルーターには、特定の修理のための最短経路上にあるかどうかを知る簡単な方法はありません。したがって、すべてのルーターで、ルーターに障害が発生した場合に使用するパスを計算する必要があります。したがって、各ルーターはネットワーク内のすべてのルーターを1つずつ「失敗」させ、そのルーターの各ネイバーへの独自の最適ルートを計算します。言い換えると、図1を参照すると、ルーターA、B、C、X、Y、Z、およびPは各ルーターを順番に検討し、ルーターに障害が発生したと想定し、各ルーターへの独自のルートを計算します。 -そのルーターのネイバーによってアドバタイズされたアドレス経由。つまり、Pの推定障害の場合、すべてのルーター（この場合はS、A、B、C、X、Y、およびZ）は、Sp、Ap、Bp、およびCpへのルートを計算します。 P経由ではなく、各ケース
To calculate the repair paths, a router has to calculate n-1 SPFs where n is the number of routers in the network. This is expensive to compute. However, the problem is amenable to a solution in which each router (X) proceeds as follows. X first calculates the base topology with all routers functional and determines its normal path to all not-via addresses. This can be performed as part of the normal SPF computation. For each router P in the topology, X then performs the following actions:
修復パスを計算するには、ルーターはn-1個のSPFを計算する必要があります。nはネットワーク内のルーターの数です。これは計算にコストがかかります。ただし、この問題は、各ルーター（X）が次のように進行するソリューションの影響を受けます。 Xはまず、すべてのルーターが機能する基本トポロジを計算し、すべての非経由アドレスへの通常のパスを決定します。これは、通常のSPF計算の一部として実行できます。トポロジーの各ルーターPについて、Xは次のアクションを実行します。
1. Removes router P from the topology.
1. トポロジーからルーターPを削除します。
2. Performs an incremental SPF (iSPF) [ISPF] on the modified topology. The iSPF process involves detaching the sub-tree affected by the removal of router P and then reattaching the detached nodes. However, it is not necessary to run the iSPF to completion. It is sufficient to run the iSPF up to the point where all of the nodes advertising not-via P addresses have been reattached to the Shortest Path Tree (SPT), and then terminate it.
2. 変更されたトポロジでインクリメンタルSPF（iSPF）[ISPF]を実行します。 iSPFプロセスには、ルーターPの削除の影響を受けるサブツリーの切り離しと、切り離されたノードの再接続が含まれます。ただし、iSPFを完全に実行する必要はありません。 P経由ではないアドレスをアドバタイズするすべてのノードが最短パスツリー（SPT）に再接続されるまでiSPFを実行し、それを終了するだけで十分です。
3. Reverts to the base topology.
3. 基本トポロジに戻します。
This algorithm is significantly less expensive than a set of full SPFs. Thus, although a router has to calculate the repair paths for n-1 failures, the computational effort is much less than n-1 SPFs.
このアルゴリズムは、完全なSPFのセットよりも大幅に安価です。したがって、ルーターはn-1個の障害の修復パスを計算する必要がありますが、計算量はn-1個のSPFよりはるかに少なくなります。
Experiments on a selection of real-world network topologies with between 40 and 400 nodes suggest that the worst-case computational complexity using the above optimizations is equivalent to performing between 5 and 13 full SPFs. Further optimizations are described in Section 6.
40〜400ノードの実際のネットワークトポロジを選択して実験したところ、上記の最適化を使用した最悪の場合の計算の複雑さは、5〜13個の完全なSPFを実行することと同等です。さらなる最適化については、セクション6で説明します。
4.1. Computing Not-Via Repairs in Distance and Path Vector Routing Protocols
4.1. 距離およびパスベクトルルーティングプロトコルでのNot-Via修復の計算
While this document focuses on link-state routing protocols, it is equally possible to compute not-via repairs in distance vector (e.g., RIP) or path vector (e.g., BGP) routing protocols. This can be achieved with very little protocol modification by advertising the not-via address in the normal way but ensuring that the information about a not-via address Ps is not propagated through the node S. In the case of link protection, this simply means that the advertisement from P to S is suppressed, with the result that S and all other nodes compute a route to Ps that doesn't traverse S, as required.
このドキュメントではリンクステートルーティングプロトコルに焦点を当てていますが、距離ベクトル（RIPなど）またはパスベクトル（BGPなど）ルーティングプロトコルでnot-via修復を計算することも同様に可能です。これは、通常の方法でnot-viaアドレスをアドバタイズし、not-viaアドレスPsに関する情報がノードSを介して伝播されないようにすることで、プロトコルをほとんど変更せずに実現できます。リンク保護の場合、これは単にPからSへのアドバタイズが抑制され、Sと他のすべてのノードが、必要に応じてSを通過しないPsへのルートを計算すること。
In the case of node protection, where P is the protected node and N is some neighbor, the advertisement of Np needs to be suppressed not only across the link N-P but also across any link to P. The simplest way of achieving this is for P itself to perform the suppression of any address of the form Xp.
Pが保護ノードでNが隣接ノードであるノード保護の場合、Npの通知は、リンクNPだけでなく、Pへのリンク全体でも抑制する必要があります。これを実現する最も簡単な方法は、Pです。 Xp形式のアドレスの抑制を実行するそれ自体。
This section explains the basic operation of the not-via repair of node and link failure.
このセクションでは、ノードとリンクの障害のnot-via修復の基本的な操作について説明します。
When router P fails (Figure 2), S encapsulates any packet that it would send to B via P to Bp and then sends the encapsulated packet on the shortest path to Bp. S follows the same procedure for routers A and C in Figure 2. The packet is decapsulated at the repair target (A, B, or C) and then forwarded normally to its destination. The repair target can be determined as part of the normal SPF by recording the "next-next hop" for each destination in addition to the normal next hop. The next-next hop is the router that the next-hop router regards as its own next hop to the destination. In Figure 1, B is S's next-next hop to D.
ルータPに障害が発生すると（図2）、SはPを介してBに送信するすべてのパケットをカプセル化し、次にカプセル化されたパケットを最短パスでBpに送信します。 Sは、図2のルーターAおよびCと同じ手順に従います。パケットは、修復ターゲット（A、B、またはC）でカプセル化が解除され、通常はその宛先に転送されます。通常のネクストホップに加えて、各宛先の「次の次のホップ」を記録することにより、通常のSPFの一部として修復ターゲットを決定できます。ネクストネクストホップは、ネクストホップルータが宛先への自身のネクストホップと見なすルータです。図1では、BはSのDへの次のホップです。
Notice that with this technique only one level of encapsulation is needed, and that it is possible to repair ANY failure regardless of link metrics and any asymmetry that may be present in the network. The only exception to this is where the failure was a single point of failure that partitioned the network, in which case ANY repair is clearly impossible.
この手法では、カプセル化の1つのレベルのみが必要であり、リンクメトリックやネットワークに存在する可能性のある非対称性に関係なく、すべての障害を修復できることに注意してください。これに対する唯一の例外は、障害がネットワークを分割する単一障害点であった場合であり、その場合、修復は明らかに不可能です。
The normal mode of operation of the network would be to assume router failure. However, where some destinations are only reachable through the failed router, it is desirable that an attempt be made to repair to those destinations by assuming that only a link failure has occurred.
ネットワークの通常の動作モードは、ルーターの障害を想定することです。ただし、一部の宛先が障害が発生したルーター経由でしか到達できない場合は、リンク障害のみが発生したと想定して、それらの宛先への修復を試みることが望ましいです。
To perform a link repair, S encapsulates to Ps (i.e., it instructs the network to deliver the packet to P not via S). All of the neighbors of S will have calculated a path to Ps in case S itself had failed. S could therefore give the packet to any of its neighbors (except, of course, P). However, S SHOULD send the encapsulated packet on the shortest available path to P. This path is calculated by running an SPF with the link S-P removed. Note that this may again be an incremental calculation, which can terminate when address Ps has been reattached.
リンク修復を実行するために、SはPにカプセル化します（つまり、パケットをS経由ではなくPに配信するようにネットワークに指示します）。 S自体に障害が発生した場合、SのすべてのネイバーがPsへのパスを計算します。したがって、Sはそのネイバー（もちろんPを除く）のいずれかにパケットを渡すことができます。ただし、Sはカプセル化されたパケットをPへの利用可能な最短パスで送信する必要があります。このパスは、リンクS-Pを削除してSPFを実行することにより計算されます。これも増分計算になる可能性があることに注意してください。これは、アドレスPsが再接続されたときに終了する可能性があります。
It is necessary to consider the behavior of IPFRR solutions when a link repair is attempted in the presence of node failure. In its simplest form, the not-via IPFRR solution prevents the formation of loops as a result of mutual repair, by never providing a repair path for a not-via address. The repair of packets with not-via addresses is considered in more detail in Section 6.3. Referring to Figure 2, if A was the neighbor of P that was on the link repair path from S to P, and P itself had failed, the repaired packet from S would arrive at A encapsulated to Ps. A would have detected that the A-P link had failed and would normally attempt to repair the packet. However, no repair path is provided for any not-via address, and so A would be forced to drop the packet, thus preventing the formation of a loop.
ノード障害が存在する状態でリンクの修復が試行される場合、IPFRRソリューションの動作を考慮する必要があります。最も単純な形式では、not-via IPFRRソリューションは、not-viaアドレスに修復パスを提供しないことにより、相互修復の結果としてのループの形成を防止します。 not-viaアドレスを持つパケットの修復については、セクション6.3で詳しく説明します。図2を参照すると、AがSからPへのリンク修復パス上にあるPのネイバーであり、P自体が失敗した場合、Sからの修復されたパケットはカプセル化されてPに到着します。 Aは、A-Pリンクが失敗したことを検出し、通常はパケットの修復を試みます。ただし、not-viaアドレスには修復パスが提供されていないため、Aは強制的にパケットをドロップし、ループの形成を防止します。
A Multi-Homed Prefix (MHP) is a prefix that is reachable via more than one router in the network. Some of these may be repairable using LFAs as described in [RFC5286]. Only those without such a repair need be considered here.
マルチホームプレフィックス（MHP）は、ネットワーク内の複数のルーターを介して到達可能なプレフィックスです。これらのいくつかは、[RFC5286]で説明されているように、LFAを使用して修復できる場合があります。ここでは、そのような修理のないものだけを考慮する必要があります。
When IPFRR router S (Figure 3) discovers that P has failed, it needs to send packets addressed to the MHP X, which is normally reachable through P, to an alternate router that is still able to reach X.
IPFRRルーターS（図3）は、Pに障害が発生したことを検出すると、通常はPを介して到達可能なMHP X宛のパケットを、Xに到達可能な代替ルーターに送信する必要があります。
X X X
| | |
| | |
| Sp |Pb |
Z...............S----------P----------B...............Y
Ps|Pc Bp
|
Cp|
C
Figure 3: Multi-Homed Prefixes
図3：マルチホームプレフィックス
S SHOULD choose the closest router that can reach X during the failure as the alternate router. S determines which router to use as the alternate while running the SPF with P removed. This is accomplished by the normal process of reattaching a leaf node to the core topology (this is sometimes known as a "partial SPF").
Sは、障害時にXに到達できる最も近いルーターを代替ルーターとして選択する必要があります。 Sは、Pが削除されたSPFの実行中に代替として使用するルーターを決定します。これは、リーフノードをコアトポロジに再接続する通常のプロセスによって実現されます（これは、「部分SPF」と呼ばれることもあります）。
First, consider the case where the shortest alternate path to X is via Z. S can reach Z without using the removed router P. However, S cannot just send the packet towards Z, because the other routers in the network will not be aware of the failure of P and may loop the packet back to S. S therefore encapsulates the packet to Z (using a normal address for Z). When Z receives the encapsulated packet, it removes the encapsulation and forwards the packet to X.
最初に、Xへの最短代替パスがZを経由する場合を考えます。Sは削除されたルーターPを使用せずにZに到達できます。ただし、ネットワーク内の他のルーターはZにパケットを送信できません。 Pの障害により、パケットがループしてSに戻る場合があります。したがって、SはパケットをZにカプセル化します（Zの通常のアドレスを使用）。 Zはカプセル化されたパケットを受信すると、カプセル化を削除し、パケットをXに転送します。
Now consider the case where the shortest alternate path to X is via Y, which S reaches via P and B. To reach Y, S must first repair the packet to B using the normal not-via repair mechanism. To do this, S encapsulates the packet for X to Bp. When B receives the packet, it removes the encapsulation and discovers that the packet is intended for MHP X. The situation now reverts to the previous case, in which the shortest alternate path does not require traversal of the failure. B therefore follows the algorithm above and encapsulates the packet to Y (using a normal address for Y). Y removes the encapsulation and forwards the packet to X.
Xへの最短代替パスがY経由であり、SがPおよびB経由で到達する場合を考えてみます。Yに到達するには、Sはまず通常のnot-via修復メカニズムを使用してパケットをBに修復する必要があります。これを行うには、SがXからBpへのパケットをカプセル化します。 Bはパケットを受信すると、カプセル化を削除し、パケットがMHP Xを対象としていることを検出します。これで、状況は前のケースに戻ります。この場合、最短の代替パスは障害の走査を必要としません。したがって、Bは上記のアルゴリズムに従い、パケットをYにカプセル化します（Yの通常のアドレスを使用）。 Yはカプセル化を削除し、パケットをXに転送します。
It may be that the cost of reaching X using local delivery from the alternate router (i.e., Z or Y) is greater than the cost of reaching X via P. Under those circumstances, the alternate router would normally forward to X via P, which would cause the IPFRR repair to loop. To prevent the repair from looping, the alternate router MUST locally deliver a packet received via a repair encapsulation. This may be specified by using a special address with the above semantics.
代替ルーター（つまり、ZまたはY）からのローカル配信を使用してXに到達するコストは、Pを介してXに到達するコストよりも大きい場合があります。これらの状況では、代替ルーターは通常Pを介してXに転送します。 IPFRR修復がループします。修復がループするのを防ぐために、代替ルーターは修復カプセル化を介して受信したパケットをローカルに配信する必要があります。これは、上記のセマンティクスを持つ特別なアドレスを使用して指定できます。
Note that only one such address is required per node. Notice that using the not-via approach, only one level of encapsulation was needed to repair MHPs to the alternate router.
ノードごとに必要なアドレスは1つだけであることに注意してください。 not-viaアプローチを使用すると、MHPを代替ルーターに修復するために必要なカプセル化レベルは1つだけであることに注意してください。
The following algorithm is used by node S (Figure 3) to pre-calculate and install repair paths in the Forwarding Information Base (FIB), ready for immediate use in the event of a failure. It is assumed that the not-via repair paths have already been calculated as described above.
次のアルゴリズムはノードS（図3）によって使用され、転送情報ベース（FIB）の修復パスを事前に計算してインストールし、障害発生時にすぐに使用できるようにします。非ビア修復経路は、上記のようにすでに計算されていると想定されています。
For each neighbor P, consider all destinations that are reachable via P in the current topology:
各隣接Pについて、現在のトポロジでPを介して到達可能なすべての宛先を検討します。
1. For all destinations with an ECMP or LFA repair (as described in [RFC5286]), install that repair.
1. ECMPまたはLFA修復（[RFC5286]で説明されている）を使用するすべての宛先に対して、その修復をインストールします。
2. For each destination (DR) that remains, identify in the current topology the next-next hop (H) (i.e., the neighbor of P that P will use to send the packet to DR). This can be determined during the normal SPF run by recording the additional information. If S has a path to the not-via address Hp (H not via P), install a not-via repair to Hp for the destination DR.
2. 残っている宛先（DR）ごとに、現在のトポロジで次のネクストホップ（H）（つまり、PがパケットをDRに送信するために使用するPのネイバー）を特定します。これは、追加情報を記録することにより、通常のSPF実行中に決定できます。 Sにnot-viaアドレスHP（P not via P）へのパスがある場合、宛先DRのHPにnot-via修復をインストールします。
3. Identify all remaining destinations (M) that can still be reached when node P fails. These will be multi-homed prefixes that are not repairable by LFA, and for which the normal attachment node is P (or a router for which P is a single point of failure), and that have an alternative attachment point that is reachable after P has failed. One way of determining these destinations would be to run an SPF rooted at S with node P removed, but an implementation may record alternative attachment points during the normal SPF run. In either case, the next-best point of attachment can also be determined for use in step (4) below.
3. ノードPに障害が発生しても到達できる残りの宛先（M）をすべて特定します。これらは、LFAで修復できないマルチホームプレフィックスであり、通常の接続ノードはP（またはPが単一障害点であるルーター）であり、Pの後に到達可能な代替接続ポイントがあります失敗した。これらの宛先を決定する1つの方法は、ノードPを削除してSをルートとするSPFを実行することですが、実装では、通常のSPF実行中に代替接続ポイントを記録する場合があります。どちらの場合も、次に最適な接続ポイントを決定して、以下のステップ（4）で使用できます。
4. For each multi-homed prefix (M) identified in step (3):
4. 手順（3）で識別された各マルチホームプレフィックス（M）について：
A. Identify the new attachment node (as shown in Figure 3). This may be:
A.新しい接続ノードを特定します（図3を参照）。これは：
o Y, where the next hop towards Y is P, or
o Y、Yへの次のホップはP、または
o Z, where the next hop towards Z is not P.
o Z。Zへの次のホップはPではありません。
If the attachment node is Z, install the repair for M as a tunnel to Z' (where Z' is the address of Z that is used to force local forwarding).
接続ノードがZの場合、Mの修復をZ 'へのトンネルとしてインストールします（Z'はローカル転送を強制するために使用されるZのアドレスです）。
B. For the subset of prefixes (M) that remain (having attachment point Y), install the repair path previously installed for destination Y.
B.残っているプレフィックス（M）のサブセット（アタッチメントポイントYを持つ）については、宛先Yに対して以前にインストールされた修復パスをインストールします。
For each destination (DS) that remains, install a not-via repair to Ps (P not via S). Note that these are destinations for which node P is a single point of failure, and they can only be repaired by assuming that the apparent failure of node P was simply a failure of the S-P link. Note that, if available, a downstream path to P MAY be used for such a repair. This cannot generate a persistent loop in the event of the failure of node P, but if one neighbor of P uses a not-via repair and another uses a downstream path, it is possible for a packet sent on the downstream path to be returned to the sending node inside a not-via encapsulation. Since packets destined to not-via addresses are not repaired, the packet will be dropped after executing a single turn of the loop.
残っている宛先（DS）ごとに、Ps（PはSを介さない）にnot-via修復をインストールします。これらは、ノードPが単一障害点である宛先であり、ノードPの明らかな障害が単にS-Pリンクの障害であると想定することによってのみ修復できることに注意してください。利用可能な場合、Pへのダウンストリームパスをそのような修復に使用できます。これは、ノードPに障害が発生した場合に永続的なループを生成できませんが、Pの1つのネイバーがnot-via修復を使用し、別のネイバーがダウンストリームパスを使用する場合、ダウンストリームパスで送信されたパケットがに返される可能性がありますnot-viaカプセル化内の送信ノード。 not-viaアドレス宛てのパケットは修復されないため、ループを1回実行した後、パケットはドロップされます。
Note that where multiple next-next hops are available to reach DR, any or several of them may be chosen from a routing correctness point of view. Unless other factors require consideration, the closest next-next hop to the repairing router would be the normal choice.
DRに到達するために複数のネクストネクストホップが利用できる場合、ルーティングの正確さの観点から、それらのホップのいずれかまたはいくつかを選択できることに注意してください。他の要因を考慮する必要がない限り、修復するルーターに最も近いネクストネクストホップが通常の選択です。
The following types of failures involve more than one component:
次のタイプの障害には、複数のコンポーネントが関係しています。
1. Shared Risk Link Groups
1. 共有リスクリンクグループ
2. Local Area Networks
2. ローカルエリアネットワーク
3. Multiple Independent Failures
3. 複数の独立した障害
The considerations that apply in each of the above situations are described in the following sections.
上記の各状況に適用される考慮事項について、以下のセクションで説明します。
A Shared Risk Link Group (SRLG) is a set of links whose failure can be caused by a single action such as a conduit cut or line card failure. When repairing the failure of a link that is a member of an SRLG, it MUST be assumed that all the other links that are also members of the SRLG have also failed. Consequently, any repair path needs to be computed to avoid not only the adjacent link but also all the links that are members of the same SRLG.
共有リスクリンクグループ（SRLG）は、コンジットカットやラインカードの障害などの単一のアクションによって障害が発生する可能性があるリンクのセットです。 SRLGのメンバーであるリンクの障害を修復する場合、SRLGのメンバーでもある他のすべてのリンクも障害が発生していると想定する必要があります。したがって、隣接するリンクだけでなく、同じSRLGのメンバーであるすべてのリンクも回避するために、修復パスを計算する必要があります。
In Figure 4 below, the links S-P and A-B are both members of SRLG "a". The semantics of the not-via address Ps changes from simply "P not via the link S-P" to be "P not via the link S-P or any other link with which S-P shares an SRLG". In Figure 4, these are the links that are members of SRLG "a", i.e., links S-P and A-B. Since the information about SRLG membership of all links is available in the link-state database, all nodes computing routes to the not-via address Ps can infer these semantics and perform the computation by failing all the links in the SRLG when running the iSPF.
下の図4では、リンクS-PとA-BはどちらもSRLG "a"のメンバーです。 not-viaアドレスPsのセマンティクスは、単に「リンクS-Pを介さないP」から「リンクS-PまたはS-PがSRLGを共有する他のリンクを介さないP」に変わります。図4では、これらはSRLG "a"のメンバーであるリンク、つまりリンクS-PとA-Bです。すべてのリンクのSRLGメンバーシップに関する情報はリンク状態データベースで利用できるため、not-viaアドレスPsへのルートを計算するすべてのノードは、iSPFの実行時にSRLGのすべてのリンクを失敗させることにより、これらのセマンティクスを推論し、計算を実行できます。
Note that it is not necessary for S to consider repairs to any other nodes attached to members of the SRLG (such as B). It is sufficient for S to repair to the other end of the adjacent link (P in this case).
SがSRLGのメンバー（Bなど）に接続されている他のノードの修復を考慮する必要がないことに注意してください。 Sが隣接リンクのもう一方の端（この場合はP）まで修復すれば十分です。
a Ps
S----------P---------D
| |
| a |
A----------B
| |
| |
C----------E
Figure 4: Shared Risk Link Group
図4：共有リスクリンクグループ
In some cases, it may be that the links comprising the SRLG occur in series on the path from S to the destination D, as shown in Figure 5. In this case, multiple consecutive repairs may be necessary. S will first repair to Ps, then P will repair to Dp. In both cases, because the links concerned are members of SRLG "a", the paths are computed to avoid all members of SRLG "a".
場合によっては、図5に示すように、SRLGを構成するリンクがSから宛先Dへのパス上で直列に発生することがあります。この場合、複数の連続した修復が必要になることがあります。 Sは最初にPsに修復し、次にPはDpに修復します。どちらの場合も、関係するリンクはSRLG "a"のメンバーであるため、パスはSRLG "a"のすべてのメンバーを回避するように計算されます。
a Ps a Dp
S----------P---------D
| | |
| a | |
A----------B |
| | |
| | |
C----------E---------F
Figure 5: Shared Risk Link Group Members in Series - Decapsulation and Re-encapsulation by One Node
図5：直列の共有リスクリンクグループメンバー-1つのノードによるカプセル化解除と再カプセル化
While the use of multiple repairs in series introduces some additional overhead, these semantics avoid the potential combinatorial explosion of not-via addresses that could otherwise occur.
連続して複数の修復を使用すると、追加のオーバーヘッドが発生しますが、これらのセマンティクスにより、そうでない場合に発生する可能性があるnot-viaアドレスの潜在的な組み合わせの爆発が回避されます。
Note that although multiple repairs are used, only a single level of encapsulation is required. This is because the first repair packet is decapsulated before the packet is re-encapsulated using the not-via address corresponding to the far side of the next link that is a member of the same SRLG. In some cases, the decapsulation and re-encapsulation take place (at least notionally) at a single node, while in other cases, these functions may be performed by different nodes. This scenario is illustrated in Figure 6 below.
複数の修復が使用されますが、カプセル化の単一レベルのみが必要であることに注意してください。これは、同じSRLGのメンバーである次のリンクの反対側に対応するnot-viaアドレスを使用してパケットが再カプセル化される前に、最初の修復パケットがカプセル化解除されるためです。場合によっては、カプセル化解除と再カプセル化が（少なくとも概念的には）1つのノードで行われますが、これらの機能は異なるノードで実行される場合もあります。このシナリオを以下の図6に示します。
a Ps a Dg
S----------P---------G--------D
| | | |
| a | | |
A----------B | |
| | | |
| | | |
C----------E---------F--------H
Figure 6: Shared Risk Link Group Members in Series - Decapsulation and Re-encapsulation by Different Nodes
図6：シリーズの共有リスクリンクグループメンバー-異なるノードによるカプセル化解除と再カプセル化
In this case, S first encapsulates to Ps, and node P decapsulates the packet and forwards it "native" to G using its normal FIB entry for destination D. G then repairs the packet to Dg.
この場合、Sは最初にPにカプセル化し、ノードPはパケットをカプセル化解除し、宛先Dの通常のFIBエントリを使用して「ネイティブ」でGに転送します。次に、GはパケットをDgに修復します。
It can be shown that such multiple repairs can never form a loop, because each repair causes the packet to move closer to its destination.
修復ごとにパケットが宛先に近づくため、このような複数の修復がループを形成することはありません。
It is often the case that a single link may be a member of multiple SRLGs, and those SRLGs may not be isomorphic. This is illustrated in Figure 7 below.
1つのリンクが複数のSRLGのメンバーである場合がよくあり、それらのSRLGは同型ではない場合があります。これを以下の図7に示します。
ab Ps a Dg
S----------P---------G--------D
| | | |
| a | | |
A----------B | |
| | | |
| b | | b |
C----------E---------F--------H
| |
| |
J----------K
Figure 7: Multiple Shared Risk Link Groups
図7：複数の共有リスクリンクグループ
The link S-P is a member of SRLGs "a" and "b". When a failure of the link S-P is detected, it MUST be assumed that BOTH SRLGs have failed. Therefore, the not-via path to Ps needs to be computed by failing all links that are members of SRLG "a" or SRLG "b", i.e., the semantics of Ps is now "P not via any links that are members of any of the SRLGs of which link S-P is a member". This is illustrated in Figure 8 below.
リンクS-Pは、SRLGの「a」と「b」のメンバーです。リンクS-Pの障害が検出された場合、両方のSRLGが失敗したと想定する必要があります。したがって、Psへのnot-viaパスは、SRLG "a"またはSRLG "b"のメンバーであるすべてのリンクを失敗させることによって計算する必要があります。つまり、Psのセマンティクスは、 "P not any link of any links that anyリンクSPがメンバーであるSRLGのこれを以下の図8に示します。
ab Ps a Dg
S----/-----P---------G---/----D
| | | |
| a | | |
A----/-----B | |
| | | |
| b | | b |
C----/-----E---------F---/----H
| |
| |
J----------K
Figure 8: Topology Used for Repair Computation for Link S-P
図8：リンクS-Pの修復計算に使用されるトポロジ
In this case, the repair path to Ps will be S-A-C-J-K-E-B-P. It may appear that there is no path to D because G-D is a member of SRLG "a" and F-H is a member of SRLG "b". This is true if BOTH SRLGs "a" and "b" have in fact failed, which would be an instance of multiple independent failures. In practice, it is likely that there is only a single failure, i.e., either SRLG "a" or SRLG "b" has failed but not both. These two possibilities are indistinguishable from the point of view of the repairing router S, and so it needs to repair on the assumption that both are unavailable. However, each link repair is considered independently. The repair to Ps delivers the packet to P, which then forwards the packet to G. When the packet arrives at G, if SRLG "a" has failed, it will be repaired around the path G-F-H-D. This is illustrated in Figure 9 below. If, on the other hand, SRLG "b" has failed, link G-D will still be available. In this case, the packet will be delivered as normal across the link G-D.
この場合、Psへの修復パスはS-A-C-J-K-E-B-Pになります。 G-DはSRLG "a"のメンバーであり、F-HはSRLG "b"のメンバーであるため、Dへのパスがないように見えることがあります。これは、両方のSRLG "a"および "b"が実際に失敗した場合に当てはまります。これは、複数の独立した失敗のインスタンスになります。実際には、単一の障害のみが発生している可能性があります。つまり、SRLG "a"またはSRLG "b"のいずれかが失敗し、両方は失敗していない可能性があります。これら2つの可能性は、ルーターSの修復の観点から区別がつかないため、両方が使用できないという前提で修復する必要があります。ただし、各リンク修復は個別に考慮されます。 Psの修復は、パケットをPに配信し、PはパケットをGに転送します。パケットがGに到着したときに、SRLG "a"が失敗した場合、パスG-F-H-Dの周りで修復されます。これを以下の図9に示します。一方、SRLG "b"が失敗しても、リンクG-Dは引き続き使用できます。この場合、パケットはリンクG-Dを介して通常どおり配信されます。
ab Ps a Dg
S----/-----P---------G---/----D
| | | |
| a | | |
A----/-----B | |
| | | |
| b | | b |
C----------E---------F--------H
| |
| |
J----------K
Figure 9: Topology Used for Repair Computation for Link G-D
図9：リンクG-Dの修復計算に使用されるトポロジ
If both SRLG "a" and SRLG "b" had failed, the packet would be repaired as far as P by S and would be forwarded by P to G. G would encapsulate the packet to D using the not-via address Dg and forward it to F. F would recognize that its next hop to Dg (H) was unreachable due to the failure of link F-H (part of SRLG "b") and would drop the packet, because packets addressed to a not-via address are not repaired in basic not-via IPFRR.
SRLG "a"とSRLG "b"の両方に障害が発生した場合、パケットはP by Sまで修復され、PからGに転送されます。Gはnot-viaアドレスDgを使用してパケットをDにカプセル化し、転送します。 FへのリンクFは、リンクFH（SRLG "b"の一部）の障害が原因でDg（H）への次のホップに到達できなかったことを認識し、パケットをドロップします。 IPFRRを介さない基本的な方法で修復されました。
The repair of multiple independent failures is not provided by the basic not-via IPFRR method described so far in this memo.
複数の独立した障害の修復は、このメモでこれまでに説明したIPFRRを経由しない基本的な方法では提供されません。
A repair strategy that assumes the worst-case failure for each link can often result in longer repair paths than necessary. In cases where only a single link fails rather than the full SRLG, this strategy may occasionally fail to identify a repair even though a viable repair path exists in the network. The use of suboptimal repair paths is an inevitable consequence of this compromise approach. The failure to identify any repair is a serious deficiency but is a rare occurrence in a robustly designed network. This problem can be addressed by:
各リンクの最悪の場合の障害を想定した修復戦略では、多くの場合、必要以上に修復パスが長くなる可能性があります。完全なSRLGではなく単一のリンクのみで障害が発生した場合、実行可能な修復パスがネットワークに存在していても、この戦略は修復の識別に失敗することがあります。次善の修復パスの使用は、この妥協アプローチの必然的な結果です。修復を識別できないことは重大な欠陥ですが、堅牢に設計されたネットワークではまれなケースです。この問題は、次の方法で対処できます。
1. Reporting that the link in question is irreparable, so that the network designer can take appropriate action.
1. 問題のリンクが修復不能であることを報告し、ネットワーク設計者が適切なアクションを実行できるようにします。
2. Modifying the design of the network to avoid this possibility.
2. この可能性を回避するためにネットワークの設計を変更します。
3. Using some form of SRLG diagnostic (for example, by running Bidirectional Forwarding Detection (BFD) [RFC5880] over alternate repair paths) to determine which SRLG member(s) have actually failed and using this information to select an appropriate pre-computed repair path. However, aside from the complexity of performing the diagnostics, this requires multiple not-via addresses per interface, which has poor scaling properties.
3. 何らかの形式のSRLG診断を使用して（たとえば、代替転送パスで双方向転送検出（BFD）[RFC5880]を実行して）、実際に失敗したSRLGメンバーを特定し、この情報を使用して適切な事前計算された修復パスを選択する。ただし、診断を実行する複雑さを除けば、これには、インターフェイスごとに複数のnot-viaアドレスが必要であり、スケーリングプロパティが不十分です。
4. Using the mechanism described in Section 6.3.
4. セクション6.3で説明されているメカニズムの使用。
LANs are a special type of SRLG and are solved using the SRLG mechanisms outlined above. With all SRLGs, there is a trade-off between the sophistication of the fault detection and the size of the SRLG. Protecting against link failure of the LAN link(s) is relatively straightforward, but as with all fast-reroute mechanisms, the problem becomes more complex when it is desired to protect against the possibility of failure of the nodes attached to the LAN, as well as the LAN itself.
LANは特殊なタイプのSRLGであり、上記で概説したSRLGメカニズムを使用して解決されます。すべてのSRLGで、障害検出の高度化とSRLGのサイズの間にはトレードオフがあります。 LANリンクのリンク障害からの保護は比較的単純ですが、すべての高速リルートメカニズムと同様に、LANに接続されたノードの障害の可能性から保護する必要がある場合、問題はさらに複雑になります。 LAN自体として。
+--------------Q------C
|
|
|
A--------S-------(N)-------------P------B
|
|
|
+--------------R------D
Figure 10: Local Area Networks
図10：ローカルエリアネットワーク
Consider the LAN shown in Figure 10. For connectivity purposes, we consider that the LAN is represented by the pseudonode (N). To provide IPFRR protection, S needs to run a connectivity check to each of its protected LAN adjacencies P, Q, and R, using, for example, BFD [RFC5880].
図10に示されているLANについて考えます。接続のために、LANが疑似ノード（N）で表されていると考えます。 IPFRR保護を提供するために、Sは、BFD [RFC5880]などを使用して、保護されたLAN隣接P、Q、Rのそれぞれへの接続チェックを実行する必要があります。
When S discovers that it has lost connectivity to P, it is unsure whether the failure is:
SがPへの接続を失ったことを検出した場合、障害が次のいずれであるかは不明です。
o its own interface to the LAN
o LANへの独自のインターフェース
o the LAN itself
o LAN自体
o the LAN interface of P
o PのLANインターフェース
o the node P
o ノードP
A simple approach to LAN repair is to consider the LAN and all of its connected routers as a single SRLG. Thus, the address P not via the LAN (Pl) would require P to be reached not via any router connected to the LAN. This is shown in Figure 11.
LAN修復の簡単な方法は、LANとそれに接続されているすべてのルーターを1つのSRLGと見なすことです。したがって、ＬＡＮを介さないアドレスＰ（Ｐ１）は、ＬＡＮに接続されたルータを介さずにＰに到達することを要求するであろう。これを図11に示します。
Ql Cl
+-------------Q--------C
| Qc
|
As Sl | Pl Bl
A--------S-------(N)------------P--------B
Sa | Pb
|
| Rl Dl
+-------------R--------D
Rd
Figure 11: Local Area Networks - LAN SRLG
図11：ローカルエリアネットワーク-LAN SRLG
In this case, if S detected that P had failed, it would send traffic reached via P and B to B not via the LAN or any router attached to the LAN (i.e., to Bl). Any destination only reachable through P would be addressed to P not via the LAN or any router attached to the LAN (except, of course, P).
この場合、Pが失敗したことをSが検出した場合、Sは、PおよびBを介して到達したトラフィックを、LANまたはLANに接続されたルーターを介さずに（B1に）Bに送信します。 Pを介してのみ到達可能な宛先は、LANまたはLANに接続されたルーター（もちろんPを除く）を経由せずにPにアドレス指定されます。
While this approach is simple, it assumes that a large portion of the network adjacent to the failure has also failed. This will result in the use of suboptimal repair paths and, in some cases, the inability to identify a viable repair.
このアプローチは単純ですが、障害に隣接するネットワークの大部分も障害が発生していると想定しています。これにより、次善の修復パスが使用され、場合によっては、実行可能な修復を特定できなくなります。
In this approach, possible failures are considered at a finer granularity but without the use of diagnostics to identify the specific component that has failed. Because S is unable to diagnose the failure, it needs to repair traffic sent through P and B, to an address Bpn (B not-via P,N, i.e., B not via P and not via N), on the conservative assumption that both the entire LAN and P have failed. Destinations for which P is a single point of failure MUST, as usual, be sent to P using an address that avoids the interface by which P is reached from S, i.e., to P not via N. A similar process would also apply for routers Q and R.
このアプローチでは、発生する可能性のある障害はより細かい単位で考慮されますが、診断を使用して、失敗した特定のコンポーネントを識別することはありません。 Sは障害を診断できないため、次のような保守的な仮定に基づいて、PおよびBを介して送信されたトラフィックを、アドレスBpn（B not-via P、N、つまりB not via Pおよびnot via N）に修復する必要があります。 LAN全体とPの両方に障害が発生しています。 Pが単一障害点である宛先は、通常どおり、SからPに到達するインターフェイスを回避するアドレスを使用してPに送信する必要があります。つまり、N経由ではなくPに送信します。同様のプロセスがルーターにも適用されます。 QとR
Notice that each router that is connected to a LAN MUST, as usual, advertise one not-via address for each neighbor. In addition, each router on the LAN MUST advertise an extra address not via the pseudonode (P).
LANに接続されている各ルーターは、通常どおり、各ネイバーに1つのnot-viaアドレスをアドバタイズする必要があることに注意してください。さらに、LAN上の各ルーターは、疑似ノード（P）を介さずに追加のアドレスを通知する必要があります。
Notice also that each neighbor of a router connected to a LAN needs to advertise two not-via addresses: the usual one not via the neighbor, and an additional one not via either the neighbor or the pseudonode. The required set of LAN address assignments is shown in Figure 12 below. Each router on the LAN, and each of its neighbors, are advertising exactly one address more than they would otherwise have advertised if this degree of connectivity had been achieved using point-to-point links.
LANに接続されたルーターの各ネイバーは、2つのnot-viaアドレスをアドバタイズする必要があることにも注意してください。通常のアドレスはネイバーを経由せず、追加のアドレスはネイバーまたは疑似ノードを経由しません。必要なLANアドレス割り当てのセットを以下の図12に示します。 LAN上の各ルーターとその隣接ルーターは、ポイントツーポイントリンクを使用してこの程度の接続が実現されていた場合にアドバタイズした場合よりも正確に1つのアドレスだけアドバタイズします。
Qs Qp Qc Cqn
+--------------Q---------C
| Qr Qn Cq
|
Asn Sa Sp Sq | Ps Pq Pb Bpn
A--------S-------(N)-------------P---------B
As Sr Sn | Pr Pn Bp
|
| Rs Rp Pd Drn
+--------------R---------D
Rq Rn Dr
Figure 12: Local Area Networks - Component Repair
図12：ローカルエリアネットワーク-コンポーネントの修復
A more specific LAN repair can be undertaken by using diagnostics. In order to explicitly diagnose the failed network component, S correlates the connectivity reports from P and one or more of the other routers on the LAN, in this case Q and R. If it lost connectivity to P alone, it could deduce that the LAN was still functioning and that the fault lay with either P or the interface connecting P to the LAN. It would then repair to B not-via P (and P not-via N for destinations for which P is a single point of failure) in the usual way. If S lost connectivity to more than one router on the LAN, it could conclude that the fault lay only with the LAN and could repair to P, Q, and R not-via N, again in the usual way.
診断を使用して、より具体的なLANの修復を行うことができます。障害のあるネットワークコンポーネントを明示的に診断するために、SはPとLAN上の他の1つ以上のルーター（この場合はQとR）からの接続レポートを関連付けます。Pへの接続を失った場合、LANははまだ機能しており、障害はPまたはPをLANに接続しているインターフェイスのいずれかにありました。次に、通常の方法で、Pを経由しないB（およびPが単一障害点である宛先の場合はNを経由しないP）に修復します。 SがLAN上の複数のルーターへの接続を失った場合、障害はLANにのみ存在すると結論付け、通常の方法で、Nを介さずにP、Q、およびRを修復できます。
IPFRR repair of multiple simultaneous failures that are not members of a known SRLG is complicated by the problem that the use of multiple concurrent repairs may result in looping repair paths. As described in Section 5.2.1, the simplest method of preventing such loops is to ensure that packets addressed to a not-via address are not repaired but instead are dropped. It is possible that a network may experience multiple simultaneous failures. This may be due to simple statistical effects, but the more likely cause is unanticipated SRLGs. When multiple failures that are not part of an anticipated group are detected, repairs are abandoned, and the network reverts to normal convergence. Although safe, this approach is somewhat draconian, since there are many circumstances where multiple repairs do not induce loops.
既知のSRLGのメンバーではない複数の同時障害のIPFRR修復は、複数の同時修復を使用すると修復パスがループする可能性があるという問題によって複雑になります。セクション5.2.1で説明したように、このようなループを防止する最も簡単な方法は、not-viaアドレスにアドレス指定されたパケットが修復されずにドロップされるようにすることです。ネットワークで複数の同時障害が発生する可能性があります。これは単純な統計的影響が原因である可能性がありますが、より可能性の高い原因は予期しないSRLGです。予期されたグループの一部ではない複数の障害が検出された場合、修復は中止され、ネットワークは通常の収束に戻ります。安全ではありますが、複数の修復でループが発生しない状況が数多くあるため、このアプローチは多少厳格です。
This section describes the properties of multiple unrelated failures and proposes some methods that may be used to address this problem.
このセクションでは、複数の無関係な障害の特性について説明し、この問題に対処するために使用できるいくつかの方法を提案します。
Let us assume that the repair mechanism is based solely on not-via repairs. LFA or downstream routes MAY be incorporated and will be dealt with later.
修理メカニズムは、単に経由ではない修理にのみ基づいていると仮定します。 LFAまたはダウンストリームルートが組み込まれる場合があり、後で処理されます。
A------//------B------------D
/ \
/ \
F G
\ /
\ /
X------//------Y
Figure 13: The General Case of Multiple Failures
図13：複数の障害の一般的なケース
The essential case is as illustrated in Figure 13. Note that, depending on the repair case under consideration, there may be other paths present in Figure 13, in addition to those shown in the figure. For example, there may be paths between A and B, and/or between X and Y. These paths are omitted for graphical clarity.
基本的なケースは図13に示すとおりです。検討中の修復ケースによっては、図に示されているパスに加えて、図13に他のパスが存在する場合があります。たとえば、AとBの間、および/またはXとYの間にパスがある場合があります。これらのパスは、図を明確にするために省略されています。
There are three cases to consider:
考慮すべき3つのケースがあります。
1. Consider the general case of a pair of protected links A-B and X-Y, as shown in the network fragment shown in Figure 13. If the repair path for A-B does not traverse X-Y and the repair path for X-Y does not traverse A-B, this case is completely safe and will not cause looping or packet loss.
1. 図13に示すネットワークフラグメントに示すように、保護リンクABとXYのペアの一般的なケースを考えます。ABの修復パスがXYを通過せず、XYの修復パスがABを通過しない場合、このケースは完全です。安全であり、ループやパケット損失を引き起こしません。
A more common variation of this case is shown in Figure 14, which shows two failures in different parts of the network in which a packet from A to D traverses two concatenated repairs.
このケースのより一般的なバリエーションを図14に示します。これは、AからDへのパケットが2つの連結された修復を通過するネットワークの異なる部分での2つの障害を示しています。
A------//------B------------X------//------Y------D
| | | |
| | | |
M--------------+ N--------------+
Figure 14: Concatenated Repairs
図14：連結修復
2. In Figure 13, the repair for A-B traverses X-Y, but the repair for X-Y does not traverse A-B. This case occurs when the not-via path from A to B traverses link X-Y but the not-via path from X to Y traverses some path not shown in Figure 13. Without the multi-failure mechanism described in this section, the repaired packet for A-B would be dropped when it reached X-Y, since the repair of repaired packets would be forbidden. However, if this packet were allowed to be repaired, the path to D would be complete and no harm would be done, although two levels of encapsulation would be required.
2. 図13では、A-Bの修復はX-Yを通過しますが、X-Yの修復はA-Bを通過しません。このケースは、AからBへのnot-viaパスがリンクXYを通過するが、XからYへのnot-viaパスが図13に示されていないいくつかのパスを通過するときに発生します。このセクションで説明する多重障害メカニズムがないと、修復されたパケットは修復されたパケットの修復が禁止されるため、XYに到達するとABがドロップされます。ただし、このパケットの修復が許可された場合、Dへのパスは完全になり、害は発生しませんが、2つのレベルのカプセル化が必要になります。
3. The repair for A-B traverses X-Y AND the repair for X-Y traverses A-B. In this case, unrestricted repair would result in looping packets and increasing levels of encapsulation.
3. A-Bの修復はX-Yを横断し、X-Yの修復はA-Bを横断します。この場合、無制限に修復すると、パケットがループし、カプセル化のレベルが高くなります。
The challenge in applying IPFRR to a network that is undergoing multiple failures is, therefore, to identify which of these cases exist in the network and react accordingly.
したがって、複数の障害が発生しているネットワークにIPFRRを適用する際の課題は、これらのケースのどれがネットワークに存在するかを識別し、それに応じて対応することです。
When A is computing the not-via repair path for A-B (i.e., the path for packets addressed to Ba, read as "B not via A"), it is aware of the list of nodes that this path traverses. This can be recorded by a simple addition to the SPF process, and the not-via addresses associated with each forward link can be determined. If the path were A, F, X, Y, G, B, (Figure 13), the list of not-via addresses would be Fa, Xf, Yx, Gy, Bg. Under standard not-via operation, A would populate its FIB such that all normal addresses normally reachable via A-B would be encapsulated to Ba when A-B fails, but traffic addressed to any not-via address arriving at A would be dropped. The new procedure modifies this such that any traffic for a not-via address normally reachable over A-B is also encapsulated to Ba, unless the not-via address is one of those previously identified as being on the path to Ba -- for example, Yx, in which case the packet is dropped.
AがA-Bのnot-via修復パス（つまり、Baにアドレス指定されたパケットのパス、「B not via A」として読み取られる）を計算しているとき、このパスが通過するノードのリストを認識しています。これは、SPFプロセスに単純に追加することで記録でき、各順方向リンクに関連付けられている非経由アドレスを決定できます。パスがA、F、X、Y、G、Bの場合（図13）、not-viaアドレスのリストはFa、Xf、Yx、Gy、Bgになります。標準のnot-via操作では、AはFIBにデータを入力し、A-Bに障害が発生した場合、通常A-Bを介して到達可能な通常のアドレスはすべてBaにカプセル化されますが、Aに到着するnot-viaアドレス宛のトラフィックはドロップされます。新しい手順では、これを変更して、通常はAB経由で到達可能な非経由アドレスのトラフィックもBaにカプセル化します。ただし、非経由アドレスが以前にBaへのパス上にあると識別されたものでない場合は、たとえば、Yxです。 、その場合、パケットはドロップされます。
The above procedure allows cases 1 and 2 above to be repaired while preventing the loop that would result from case 3.
上記の手順により、上記のケース1と2を修復しながら、ケース3から生じるループを防止できます。
Note that this is accomplished by pre-computing the required FIB entries and does not require any detailed packet inspection. The same result could be achieved by checking for multiple levels of encapsulation and dropping any attempt to triple encapsulate. However, this would require more detailed inspection of the packet and causes difficulties when more than 2 "simultaneous" failures are contemplated.
これは、必要なFIBエントリを事前に計算することによって実行され、詳細なパケット検査を必要としないことに注意してください。同じ結果は、カプセル化の複数のレベルをチェックし、トリプルカプセル化の試みを削除することでも実現できます。ただし、これにはパケットのより詳細な検査が必要であり、2つ以上の「同時」障害が想定される場合は問題が発生します。
So far, we have permitted benign repairs to coexist, albeit sometimes requiring multiple encapsulation. Note that in many cases there will be no performance impact, since unless both failures are on the same node the two encapsulations or two decapsulations will be performed at different nodes. There is, however, the issue of the maximum transmission unit (MTU) impact of multiple encapsulations.
これまでのところ、複数のカプセル化が必要になることもありますが、無害な修復の共存を許可しています。両方の障害が同じノードで発生しない限り、2つのカプセル化または2つのカプセル化解除が異なるノードで実行されるため、多くの場合、パフォーマンスへの影響はありません。ただし、複数のカプセル化による最大転送単位（MTU）への影響の問題があります。
In the following sub-section we consider the various strategies that may be applied to case 3 -- mutual repairs that would loop.
次のサブセクションでは、ケース3（ループする相互修復）に適用できるさまざまな戦略について検討します。
In case 3, the simplest approach is to simply not install repairs for repair paths that might loop. In this case, although the potentially looping traffic is dropped, the traffic is not repaired. If we assume that a hold-down is applied before reconvergence in case the link failure was just a short glitch, and if a loop-free convergence mechanism further delays convergence, then the traffic will be dropped for an extended period. In these circumstances, it would be better to apply the "Abandoning All Hope" (AAH) mechanism ([RFC6976], Appendix A) and immediately invoke normal reconvergence.
ケース3では、最も単純なアプローチは、ループする可能性のある修復パスに修復をインストールしないことです。この場合、ループしている可能性のあるトラフィックはドロップされますが、トラフィックは修復されません。リンク障害が短いグリッチであった場合に備えて、再収束の前にホールドダウンが適用されると想定し、ループのない収束メカニズムが収束をさらに遅延させると、トラフィックは長期間にわたってドロップされます。このような状況では、「Abandoning All Hope」（AAH）メカニズム（[RFC6976]、付録A）を適用して、すぐに通常の再収束を呼び出すほうがよいでしょう。
Note that it is not sufficient to expedite the issuance of a Link State Packet (LSP) reporting the failure, since this may be treated as a permitted simultaneous failure by the ordered FIB (oFIB) algorithm [RFC6976]. It is therefore necessary to explicitly trigger an oFIB AAH.
障害を報告するリンクステートパケット（LSP）の発行を迅速に行うだけでは不十分であることに注意してください。これは、順序付きFIB（oFIB）アルゴリズムによって許可された同時障害として扱われる可能性があるためです[RFC6976]。したがって、oFIB AAHを明示的にトリガーする必要があります。
One approach to case 3 is to allow the repair, and to experimentally discover the incompatibility of the repairs if and when they occur. With this method, we permit the repair in case 3 and trigger AAH when a packet drop count on the not-via address has been incremented. Alternatively, it is possible to wait until the LSP describing the change is issued normally (i.e., when X announces the failure of X-Y). When the repairing node A, which has precomputed that X-Y failures are mutually incompatible with its own repairs, receives this LSP, it can then issue the AAH. This has the disadvantage that it does not overcome the hold-down delay, but it requires no "data-driven" operation, and it still has the required effect of abandoning the oFIB, which is probably the longer of the delays (although with signaled oFIB this should be sub-second).
ケース3への1つのアプローチは、修復を許可し、修復の非互換性が発生した場合に、その非互換性を実験的に発見することです。この方法では、ケース3での修復を許可し、not-viaアドレスのパケットドロップカウントが増加したときにAAHをトリガーします。または、変更を説明するLSPが正常に発行されるまで待機することもできます（つまり、XがX-Yの失敗を通知するとき）。 X-Y障害が自身の修復と相互に互換性がないと事前計算した修復ノードAがこのLSPを受信すると、AAHを発行できます。これには、ホールドダウン遅延を克服できないという欠点がありますが、「データ駆動型」の操作は不要であり、oFIBを放棄するという必要な効果があります。 oFIBこれは1秒未満である必要があります）。
While both of the experimental approaches described above are feasible, they tend to induce AAH in the presence of otherwise feasible repairs, and they are contrary to the philosophy of repair predetermination that has been applied to existing IPFRR solutions.
上記の実験的アプローチはどちらも実行可能ですが、他の場合は実行可能な修復が存在する場合にAAHを誘発する傾向があり、既存のIPFRRソリューションに適用されている修復の事前決定の哲学に反しています。
An alternative approach to simply dropping the looping packets, or to detecting the loop after it has occurred, is to use secondary SRLGs. With a link-state routing protocol, it is possible to pre-compute the incompatibility of the repairs in advance and to compute an alternative SRLG repair path. Although this does considerably increase the computational complexity, it may be possible to compute repair paths that avoid the need to simply drop the offending packets.
ループパケットを単にドロップする、またはループが発生した後にループを検出する別の方法は、セカンダリSRLGを使用することです。リンクステートルーティングプロトコルを使用すると、修復の非互換性を事前に計算し、代替のSRLG修復パスを計算できます。これにより計算の複雑さが大幅に増加しますが、問題のあるパケットを単にドロップする必要を回避する修復パスを計算することが可能になる場合があります。
This approach requires us to identify the mutually incompatible failures and advertise them as "secondary SRLGs". When computing the repair paths for the affected not-via addresses, these links are simultaneously removed. Note that the assumed simultaneous failure and resulting repair path only apply to the repair path computed for the conflicting not-via addresses and are not used for normal addresses. This implies that although there will be a longer repair path when there is more than one failure, if there is a single failure the repair path length will be "normal".
このアプローチでは、相互に互換性のない障害を特定し、それらを「セカンダリSRLG」として通知する必要があります。影響を受けるnot-viaアドレスの修復パスを計算するとき、これらのリンクは同時に削除されます。想定される同時障害とその結果の修復パスは、競合する非経由アドレスに対して計算された修復パスにのみ適用され、通常のアドレスには使用されないことに注意してください。これは、複数の障害がある場合は修復パスが長くなりますが、単一の障害がある場合は修復パスの長さが「通常」になることを意味します。
Ideally, we would wish to only invoke secondary SRLG computation when we are sure that the repair paths are mutually incompatible. Consider the case of node A in Figure 13. Node A first identifies that the repair path for A-B is via F-X-Y-G-B. It then explores this path, determining the repair path for each link in the path. Thus, for example, it performs a check at X by running an SPF rooted at X with the X-Y link removed to determine whether A-B is indeed on X's repair path for packets addressed to Yx.
理想的には、修復パスに相互に互換性がないことが確実な場合にのみ、セカンダリSRLG計算を呼び出したいと考えます。図13のノードAの場合を考えてみます。ノードAはまず、A-Bの修復パスがF-X-Y-G-B経由であることを識別します。次に、このパスを探索し、パス内の各リンクの修復パスを決定します。したがって、たとえば、X-Yリンクが削除されたXをルートとするSPFを実行してXでチェックを実行し、A-Bが実際にYx宛のパケットのXの修復パス上にあるかどうかを判断します。
Some optimizations are possible in this calculation, which appears at first sight to be order hk (where h is the average hop length of repair paths and k is the average number of neighbors of a router). When A is computing its set of repair paths, it does so for all its k neighbors. In each case, it identifies a list of node pairs traversed by each repair. These lists may often have one or more node pairs in common, so the actual number of link failures that require investigation is the union of these sets. It is then necessary to run an SPF rooted at the first node of each pair (the first node, because the pairings are ordered representing the direction of the path), with the link to the second node removed. This SPF, while not an incremental, can be terminated as soon as the not-via address is reached. For example, when running the SPF rooted at X, with the link X-Y removed, the SPF can be terminated when Yx is reached. Once the path has been found, the path is checked to determine if it traverses any of A's links in the direction away from A. Note that because the node pair X-Y may exist in the list for more than one of A's links (i.e., it lies on more than one repair path), it is necessary to identify the correct list, and hence link, that has a mutually looping repair path. That link of A is then advertised by A as a secondary SRLG paired with the link X-Y. Also note that X will be running this algorithm as well, and will identify that X-Y is paired with A-B and so advertise it. This could perhaps be used as a further check.
この計算ではいくつかの最適化が可能であり、一見すると次数hk（hは修復パスの平均ホップ長、kはルーターの隣接ノードの平均数）のように見えます。 Aがその修復パスのセットを計算しているとき、それはそのすべてのk近傍に対して計算します。いずれの場合も、各修復で通過したノードペアのリストを識別します。これらのリストには、多くの場合、1つ以上のノードペアが共通している可能性があるため、調査が必要なリンク障害の実際の数は、これらのセットの和集合です。次に、2番目のノードへのリンクを削除して、各ペアの最初のノード（パスの方向を表すペアリングが順序付けされているため、最初のノード）をルートとするSPFを実行する必要があります。このSPFは、増分ではありませんが、not-viaアドレスに到達するとすぐに終了できます。たとえば、Xをルートとし、リンクX-Yを削除してSPFを実行している場合、Yxに達したときにSPFを終了できます。パスが見つかると、パスがチェックされ、Aから離れる方向にAのリンクのいずれかを横断するかどうかが決定されます。ノードペアXYがAの複数のリンク（つまり、が複数の修復パス上にある場合）、相互にループしている修復パスを持つ正しいリスト、つまりリンクを特定する必要があります。次に、そのAのリンクは、リンクX-YとペアになっているセカンダリSRLGとしてAによってアドバタイズされます。また、Xもこのアルゴリズムを実行し、X-YがA-Bとペアになっていることを識別し、それをアドバタイズすることにも注意してください。これはおそらく、さらなるチェックとして使用できます。
The ordering of the pairs in the lists is important, i.e., X-Y and Y-X are dealt with separately. If and only if the repairs are mutually incompatible, we need to advertise the pair of links as a secondary SRLG, and then ALL nodes compute repair paths around both failures using an additional not-via address with the semantics not-via A-B AND not-via X-Y.
リスト内のペアの順序は重要です。つまり、X-YとY-Xは別々に処理されます。修復が相互に互換性がない場合に限り、リンクのペアをセカンダリSRLGとしてアドバタイズする必要があります。その後、すべてのノードが追加のnot-viaアドレスを使用し、セマンティクスnot-via-AB AND-- XY経由。
A further possibility is that because we are going to the trouble of advertising these SRLG sets, we could also advertise the new repair path and only get the nodes on that path to perform the necessary computation. Note also that once we have reached Q-space (Appendix A) with respect to the two failures, we need no longer continue the computation, so we only need to notify the nodes on the path that are not in Q-space.
さらなる可能性として、これらのSRLGセットをアドバタイズする問題が発生するため、新しい修復パスをアドバタイズし、そのパス上のノードのみを取得して必要な計算を実行することもできます。また、2つの失敗に関してQ空間（付録A）に到達すると、計算を続行する必要がなくなるため、Q空間にないパス上のノードに通知するだけで済みます。
One cause of mutually looping repair paths is the existence of nodes with only two links, or sections of the network that are only bi-connected. In these cases, repair is clearly impossible -- the failure of both links partitions the network. It would be advantageous to be able to identify these cases and inhibit the fruitless advertisement of the secondary SRLG information. This could be achieved by the node detecting the requirement for a secondary SRLG, first running the not-via computation with both links removed. If this does not result in a path, it is clear that the network would be partitioned by such a failure, and so no advertisement is required.
相互にループしている修復パスの1つの原因は、2つのリンクしかないノード、または二重接続しているだけのネットワークセクションがあることです。これらの場合、修復は明らかに不可能です-両方のリンクの障害がネットワークを分割します。これらのケースを識別し、二次的なSRLG情報の無益な広告を禁止できると有利です。これは、ノードがセカンダリSRLGの要件を検出し、最初に両方のリンクを削除してnot-via計算を実行することで実現できます。これがパスにならない場合、そのような障害によってネットワークが分割されることは明らかであるため、アドバタイズは必要ありません。
So far in this section, we have assumed that all repairs use not-via tunnels. However, in practice we may wish to use LFAs or downstream routes where available. This complicates the issue, because their use results in packets that are being repaired but NOT addressed to not-via addresses. If BOTH links are using downstream routes, there is no possibility of looping, since it is impossible to have a pair of nodes that are both downstream of each other [RFC5286].
これまでのところ、このセクションでは、すべての修理でnot-viaトンネルを使用することを想定しています。ただし、実際には、可能な場合はLFAまたはダウンストリームルートを使用することもできます。これを使用すると、パケットは修復されますが、経由しないアドレスには送信されないため、問題が複雑になります。両方のリンクがダウンストリームルートを使用している場合、両方が互いにダウンストリームであるノードのペアを持つことは不可能であるため、ループする可能性はありません[RFC5286]。
Loops can, however, occur when LFAs are used. An obvious example is the well-known node repair problem with LFAs [RFC5286]. If one link is using a downstream route while the other is using a not-via tunnel, the potential mechanism described above would work, provided it were possible to determine the nodes on the path of the downstream route. Some methods of computing downstream routes do not provide this path information. However, if the path information is available, the link using a downstream route will have a discard FIB entry for the not-via address of the other link. The consequence is that potentially looping packets will be discarded when they attempt to cross this link.
ただし、LFAを使用するとループが発生する可能性があります。明らかな例は、LFA [RFC5286]でよく知られているノード修復の問題です。一方のリンクがダウンストリームルートを使用し、もう一方がnot-viaトンネルを使用している場合、ダウンストリームルートのパス上のノードを特定できれば、上記のメカニズムが機能します。ダウンストリームルートを計算するいくつかの方法は、このパス情報を提供しません。ただし、パス情報が使用可能な場合、ダウンストリームルートを使用するリンクには、他のリンクのnot-viaアドレスの破棄FIBエントリがあります。その結果、ループする可能性のあるパケットは、このリンクを通過しようとすると破棄されます。
In the case where the mutual repairs are both using not-via repairs, the loop will be broken when the packet arrives at the second failure. However, packets are unconditionally repaired by means of a downstream routes, and thus when the mutual pair consists of a downstream route and a not-via repair, the looping packet will only be dropped when it gets back to the first failure, i.e., it will execute a single turn of the loop before being dropped.
相互修復の両方がnot-via修復を使用している場合、パケットが2番目の障害に到達すると、ループが切断されます。ただし、パケットは無条件にダウンストリームルートによって修復されるため、相互ペアがダウンストリームルートとnot-via修復で構成されている場合、ループパケットは最初の障害に戻ったときにのみドロップされます。ドロップされる前にループを1回実行します。
There is a further complication with downstream routes, since although the path may be computed to the far side of the failure, the packet may "peel off" to its destination before reaching the far side of the failure. In this case, it may traverse some other link that has failed and was not accounted for on the computed path. If the A-B repair (Figure 13) is a downstream route and the X-Y repair is a not-via repair, we can have the situation where the X-Y repair packets encapsulated to Yx follow a path that attempts to traverse A-B. If the A-B repair path for "normal" addresses is a downstream route, it cannot be assumed that the repair path for packets addressed to Yx can be sent to the same neighbor. This is because the validity of a downstream route MUST be ascertained in the topology represented by Yx, i.e., that with the link X-Y removed. This is not the same topology that was used for the normal downstream calculation, and use of the normal downstream route for the encapsulated packets may result in an undetected loop. If it is computationally feasible to check the downstream route in this topology (i.e., for any not-via address Qp that traverses A-B, we must perform the downstream calculation for that not-via address in the topology with link Q-P removed), then the downstream repair for Yx can safely be used. These packets cannot revisit X-Y, since by definition they will avoid that link. Alternatively, the packet could be always repaired in a not-via tunnel, i.e., even though the normal repair for traffic traversing A-B would be to use a downstream route, we could insist that such traffic addressed to a not-via address must use a tunnel to Ba. Such a tunnel would only be installed for an address Qp if it were established that it did not traverse Q-P (using the rules described above).
ダウンストリームルートにはさらに複雑な問題があります。これは、パスは障害の反対側まで計算される可能性がありますが、パケットは障害の反対側に到達する前に宛先に「はがれる」可能性があるためです。この場合、障害が発生し、計算されたパスで考慮されなかった他のリンクをトラバースする可能性があります。 A-B修復（図13）がダウンストリームルートであり、X-Y修復がnot-via修復である場合、Yxにカプセル化されたX-Y修復パケットがA-Bを通過しようとするパスをたどる状況になる可能性があります。 「通常の」アドレスのA-B修復パスがダウンストリームルートの場合、Yx宛てのパケットの修復パスを同じネイバーに送信できるとは想定できません。これは、ダウンストリームルートの有効性が、Yxで表されるトポロジ、つまりリンクX-Yが削除されたトポロジで確認される必要があるためです。これは、通常のダウンストリームの計算に使用されたトポロジとは異なります。カプセル化されたパケットに通常のダウンストリームルートを使用すると、ループが検出されなくなる可能性があります。このトポロジーのダウンストリームルートをチェックすることが計算上可能である場合（つまり、ABを通過するnot-viaアドレスQpの場合、リンクQPが削除されたトポロジーのそのnot-viaアドレスのダウンストリーム計算を実行する必要があります）、 Yxのダウンストリーム修復は安全に使用できます。これらのパケットは、X-Yを再訪することはできません。これは、定義上、そのリンクを回避するためです。または、パケットは常にnot-viaトンネルで修復できます。つまり、ABを通過するトラフィックの通常の修復はダウンストリームルートを使用することですが、not-viaアドレスに宛てられたそのようなトラフィックは、 Baへのトンネル。このようなトンネルは、Q-Pを通過しなかったことが（上記のルールを使用して）確立された場合にのみ、アドレスQpにインストールされます。
If repairing node S has an LFA to the repair endpoint, it is not necessary for any router to perform the incremental SPF with the link S-P removed in order to compute the route to the not-via address Ps. This is because the correct routes will already have been computed as a result of the SPF on the base topology. Node S can signal this condition to all other routers by including a bit in its LSP or Link State Advertisement (LSA) associated with each link protected by an LFA. Routers computing not-via routes can then omit the running of the iSPF for links with this bit set.
修復ノードSに修復エンドポイントへのLFAがある場合、どのビアもnot-viaアドレスPsへのルートを計算するためにリンクS-Pを削除してインクリメンタルSPFを実行する必要はありません。これは、ベーストポロジのSPFの結果として、正しいルートが既に計算されているためです。ノードSは、LSAまたはLFAで保護された各リンクに関連付けられたリンク状態アドバタイズメント（LSA）にビットを含めることにより、この状態を他のすべてのルーターに通知できます。 not-viaルートを計算するルーターは、このビットが設定されたリンクのiSPFの実行を省略できます。
When running the iSPF for a particular link A-B, the calculating router first checks whether the link A-B is present in the existing SPT. If the link is not present in the SPT, no further work is required. This check is a normal part of the iSPF computation.
特定のリンクA-Bに対してiSPFを実行する場合、計算ルーターはまず、リンクA-Bが既存のSPTに存在するかどうかを確認します。リンクがSPTに存在しない場合、それ以上の作業は必要ありません。このチェックは、iSPF計算の通常の部分です。
If the link is present in the SPT, this optimization introduces a further check to determine whether the link is marked as protected by an LFA in the direction in which the link appears in the SPT. If so, the iSPF need not be performed. For example, if the link appears in the SPT in the direction A->B and A has indicated that the link A-B is protected by an LFA, no further action is required for this link.
リンクがSPTに存在する場合、この最適化により、リンクがSPTに表示される方向でLFAによって保護されているとマークされているかどうかを判断するための追加のチェックが導入されます。その場合、iSPFを実行する必要はありません。たとえば、リンクがSPTの方向A-> Bに表示され、AがリンクA-BがLFAによって保護されていることを示している場合、このリンクに対してこれ以上のアクションは必要ありません。
If the receipt of this information is delayed, the correct operation of the protocol is not compromised, provided that the necessity to perform a not-via computation is re-evaluated whenever new information arrives.
この情報の受信が遅れても、新しい情報が到着するたびにnot-via計算を実行する必要性が再評価されれば、プロトコルの正しい動作が損なわれることはありません。
This optimization is not particularly beneficial to nodes close to the repair, since (as has been observed above) the computation for nodes on the LFA path is trivial. However, for nodes upstream of the link S-P for which S-P is in the path to P, there is a significant reduction in the computation required.
LFAパス上のノードの計算は簡単なので、この最適化は、修復に近いノードには特に有益ではありません。ただし、S-PがPへのパスにあるリンクS-Pの上流のノードでは、必要な計算が大幅に削減されます。
Multicast traffic can be repaired in a way similar to unicast. The multicast forwarder is able to use the not-via address to which the multicast packet was addressed as an indication of the expected receive interface and hence to correctly run the required Reverse Path Forwarding (RPF) check.
マルチキャストトラフィックは、ユニキャストと同様の方法で修復できます。マルチキャストフォワーダーは、マルチキャストパケットが宛てられたnot-viaアドレスを、予期される受信インターフェイスの指標として使用できるため、必要な逆パス転送（RPF）チェックを正しく実行できます。
In some cases, all the destinations, including the repair endpoint, are repairable by an LFA. In this case, all unicast traffic may be repaired without encapsulation. Multicast traffic still requires encapsulation, but for the nodes on the LFA repair path, the computation of the not-via forwarding entry is unnecessary: by definition, their normal path to the repair endpoint is not via the failure.
場合によっては、修復エンドポイントを含むすべての宛先がLFAによって修復可能です。この場合、すべてのユニキャストトラフィックをカプセル化せずに修復できます。マルチキャストトラフィックには引き続きカプセル化が必要ですが、LFA修復パス上のノードの場合、not-via転送エントリの計算は不要です。定義により、修復エンドポイントへの通常のパスは障害を経由しません。
A more complete description of multicast operation is left for further study.
マルチキャスト操作のより完全な説明は、今後の研究に残されます。
Not-via addresses are IP addresses, and LDP [RFC5036] will distribute labels for them in the usual way. The not-via repair mechanism may therefore be used to provide fast reroute in an MPLS network by first pushing the label that the repair endpoint uses to forward the packet and then pushing the label corresponding to the not-via address needed to effect the repair. Referring once again to Figure 1, if S has a packet destined for D that it must reach via P and B, S first pushes B's label for D. S then pushes the label that its next hop to Bp needs to reach Bp.
Not-viaアドレスはIPアドレスであり、LDP [RFC5036]は通常の方法でそれらのラベルを配布します。したがって、not-via修復メカニズムを使用して、最初に修復エンドポイントがパケットの転送に使用するラベルをプッシュし、次に、修復を行うために必要なnot-viaアドレスに対応するラベルをプッシュすることにより、MPLSネットワークで高速リルートを提供できます。もう一度図1を参照してください。SにD宛てのパケットがあり、PとBを介して到達する必要がある場合、SはまずBのラベルをDにプッシュします。次に、SはBpへの次のホップがBpに到達するために必要なラベルをプッシュします。
Note that in an MPLS LDP network, it is necessary for S to have the repair endpoint's label for the destination. When S is effecting a link repair, it already has this. In the case of a node repair, S either needs to set up a directed LDP session with each of its neighbor's neighbors or it needs to use a method similar to the next-next-hop label distribution mechanism proposed in [NNHL].
MPLS LDPネットワークでは、Sが宛先の修復エンドポイントのラベルを持つ必要があることに注意してください。 Sがリンクの修復を行っているとき、Sはすでにこれを持っています。ノードの修復の場合、Sはネイバーの各ネイバーとのダイレクトLDPセッションをセットアップするか、[NNHL]で提案されているネクストネクストホップラベル配布メカニズムと同様の方法を使用する必要があります。
Any IETF-specified IP-in-IP encapsulation may be used to carry a not-via repair. IP in IP [RFC2003], Generic Routing Encapsulation (GRE) [RFC1701], and the Layer 2 Tunneling Protocol (L2TPv3) [RFC3931] all have the necessary and sufficient properties. The requirement is that both the encapsulating router and the router to which the encapsulated packet is addressed have a common ability to process the chosen encapsulation type. When an MPLS LDP network is being protected, the encapsulation would normally be an additional MPLS label. In an MPLS-enabled IP network, an MPLS label may be used in place of an IP-in-IP encapsulation in the case above.
IETFで指定されたIP-in-IPカプセル化を使用して、not-via修復を実行できます。 IP in IP [RFC2003]、Generic Routing Encapsulation（GRE）[RFC1701]、およびLayer 2 Tunneling Protocol（L2TPv3）[RFC3931]はすべて、必要かつ十分なプロパティを備えています。要件は、カプセル化ルーターと、カプセル化されたパケットの宛先となるルーターの両方が、選択されたカプセル化タイプを処理する共通の機能を備えていることです。 MPLS LDPネットワークが保護されている場合、カプセル化は通常、追加のMPLSラベルになります。 MPLS対応のIPネットワークでは、上記の場合のIP-in-IPカプセル化の代わりにMPLSラベルを使用できます。
Care needs to be taken to ensure that the encapsulation used to provide a repair tunnel does not result in the packet exceeding the MTU of the links traversed by that repair.
修復トンネルを提供するために使用されるカプセル化によって、パケットがその修復を通過するリンクのMTUを超えないように注意する必要があります。
IPFRR requires routing protocol extensions. Each IPFRR router that is directly connected to a protected network component must advertise a not-via address for that component. This must be advertised in such a way that the association between the protected component (link, router, or SRLG) and the not-via address can be determined by the other routers in the network.
IPFRRにはルーティングプロトコル拡張が必要です。保護されたネットワークコンポーネントに直接接続されている各IPFRRルーターは、そのコンポーネントのnot-viaアドレスをアドバタイズする必要があります。これは、保護されたコンポーネント（リンク、ルーター、またはSRLG）とnot-viaアドレス間の関連付けがネットワーク内の他のルーターによって決定されるような方法でアドバタイズされる必要があります。
It is necessary that routers capable of supporting not-via routes advertise in the IGP that they will calculate not-via routes.
not-viaルートをサポートできるルータは、not-viaルートを計算することをIGPでアドバタイズする必要があります。
It is necessary for routers to advertise the type of encapsulation that they support (MPLS, GRE, L2TPv3, etc.). However, the deployment of mixed IP encapsulation types within a network is discouraged.
ルーターは、サポートするカプセル化のタイプ（MPLS、GRE、L2TPv3など）を通知する必要があります。ただし、ネットワーク内に混合IPカプセル化タイプを配置することはお勧めしません。
If the optimization proposed in Section 7 is to be used, then the use of the LFA in place of the not-via repair MUST also be signaled in the routing protocol.
セクション7で提案された最適化が使用される場合、not-via修理の代わりにLFAの使用もルーティングプロトコルで通知されなければなりません（MUST）。
Incremental deployment is supported by excluding routers that are not calculating not-via routes (as indicated by their capability information flooded with their link-state information) from the base topology used for the computation of repair paths. In that way, repairs may be steered around islands of routers that are not IPFRR capable. Routers that are protecting a network component need to have the capability to encapsulate and decapsulate packets. However, routers that are on the repair path only need to be capable of calculating not-via paths and including the not-via addresses in their FIB, i.e., these routers do not need any changes to their forwarding mechanism.
インクリメンタル展開は、リペアパスの計算に使用される基本トポロジーから、not-viaルートを計算していないルーター（リンク状態情報でフラッディングされた機能情報で示される）を除外することでサポートされます。このようにして、IPFRRに対応していないルーターのアイランドを中心に修復を行うことができます。ネットワークコンポーネントを保護しているルーターには、パケットをカプセル化およびカプセル化解除する機能が必要です。ただし、修復パス上にあるルーターは、not-viaパスを計算でき、FIBにnot-viaアドレスを含めることができる必要があります。つまり、これらのルーターは転送メカニズムを変更する必要がありません。
[RFC5714] outlines the general set of manageability considerations that apply to the general case of IPFRR. We slightly expand this and add details that are not-via specific. There are three classes of manageability considerations:
[RFC5714]は、IPFRRの一般的なケースに適用される管理性の考慮事項の一般的なセットの概要を示しています。これを少し拡張し、具体的ではない詳細を追加します。管理性に関する考慮事項には3つのクラスがあります。
1. Pre-failure configuration
1. 事前障害構成
2. Pre-failure monitoring and operational support
2. 障害前の監視と運用サポート
3. Failure action monitoring
3. 障害アクションの監視
Pre-failure configuration for not-via includes:
not-viaの事前障害構成には、次のものがあります。
o Enabling/disabling not-via IPFRR support.
o not-via IPFRRサポートの有効化/無効化。
o Enabling/disabling protection on a per-link or per-node basis.
o リンクごとまたはノードごとの保護の有効化/無効化。
o Expressing preferences regarding the links/nodes used for repair paths.
o 修復パスに使用されるリンク/ノードに関する設定を表現します。
o Configuration of failure detection mechanisms.
o 障害検出メカニズムの構成。
o Setting a preference concerning the use of LFAs.
o LFAの使用に関する設定を行います。
o Configuring a not-via address (per interface) or not-via address set (per node).
o not-viaアドレス（インターフェースごと）またはnot-viaアドレスセット（ノードごと）の構成。
o Configuring any SRLG rules or preferences.
o SRLGルールまたは設定を構成します。
Any standard configuration method may be used. The selection of the method to be used is outside the scope of this document.
標準の設定方法を使用できます。使用する方法の選択は、このドキュメントの範囲外です。
Pre-failure monitoring and operational support for not-via include:
not-viaの事前障害監視と運用サポートには、次のものが含まれます。
o Notification of links/nodes/destinations that cannot be protected.
o 保護できないリンク/ノード/宛先の通知。
o Notification of pre-computed repair paths.
o 事前に計算された修復パスの通知。
o Notification of repair type to be used (LFA or not-via).
o 使用する修理タイプの通知（LFAまたはnot-via）。
o Notification of not-via address assignment.
o not-viaアドレス割り当ての通知。
o Notification of path or address optimizations used.
o 使用されたパスまたはアドレス最適化の通知。
o Testing repair paths. Note that not-via addresses look identical to "ordinary" addresses as far as tools such as traceroute and ping are concerned, and thus it is anticipated that these will be used to verify the established repair path.
o 修復パスのテスト。 not-viaアドレスは、tracerouteやpingなどのツールに関する限り、「通常の」アドレスと同じに見えるため、これらが確立された修復パスの確認に使用されることが予想されます。
Any standard IETF method may be used for the above. The selection of the method to be used is outside the scope of this document.
上記には、任意の標準IETFメソッドを使用できます。使用する方法の選択は、このドキュメントの範囲外です。
Failure action monitoring for not-via includes:
not-viaの障害アクションモニタリングには、次のものが含まれます。
o Counts of failure detections, protection invocations, and packets forwarded over repair paths.
o 障害検出、保護の呼び出し、および修復パスを介して転送されたパケットの数。
o Logging of the events, using a sufficiently accurate and precise timestamp.
o 十分に正確で正確なタイムスタンプを使用したイベントのロギング。
o Validation that the packet loss was within specification, using a suitable loss verification tool.
o 適切な損失検証ツールを使用して、パケット損失が仕様の範囲内であったことの検証。
o Capture of the in-flight repair packet flows, using a tool such as IP Flow Information Export (IPFIX) [RFC5101].
o IPフロー情報エクスポート（IPFIX）[RFC5101]などのツールを使用した、処理中の修復パケットフローのキャプチャ。
Note that monitoring the repair in action requires the capture of the signatures of a short, possibly sub-second network transient; this technique is not a well-developed IETF technology.
動作中の修復を監視するには、1秒未満の短いネットワークトランジェントのシグネチャをキャプチャする必要があることに注意してください。この手法は、十分に開発されたIETFテクノロジではありません。
The repair endpoints present vulnerability in that they might be used as a method of disguising the delivery of a packet to a point in the network [RFC6169]. The primary method of protection SHOULD be through the use of a private address space for the not-via addresses [RFC1918] [RFC4193]. Repair endpoint addresses MUST NOT be advertised outside the routing domain over which not-via is deployed and MUST be filtered at the network entry points. In addition, a mechanism might be developed that allows the use of the mild security available through the use of a key [RFC1701] [RFC3931]. With the deployment of such mechanisms, the repair endpoints would not increase the security risk beyond that of existing IP tunnel mechanisms. An attacker may attempt to overload a router by addressing an excessive traffic load to the decapsulation endpoint. Typically, routers take a 50% performance penalty in decapsulating a packet. The attacker could not be certain that the router would be impacted, and the extremely high volume of traffic needed would easily be detected as an anomaly. If an attacker were able to influence the availability of a link, they could cause the network to invoke the not-via repair mechanism. A network protected by not-via IPFRR is less vulnerable to such an attack than a network that undertook a full convergence in response to a link up/down event.
修復エンドポイントは、ネットワーク内のポイントへのパケットの配信を偽装する方法として使用される可能性があるという点で脆弱性を示します[RFC6169]。保護の主要な方法は、非経由アドレス[RFC1918] [RFC4193]にプライベートアドレス空間を使用することによる必要があります（SHOULD）。修復エンドポイントアドレスは、not-viaが展開されているルーティングドメインの外でアドバタイズしてはならず、ネットワークエントリポイントでフィルタリングする必要があります。さらに、キーの使用を通じて利用可能な穏やかなセキュリティの使用を可能にするメカニズムが開発されるかもしれません[RFC1701] [RFC3931]。このようなメカニズムの導入により、修復エンドポイントは既存のIPトンネルメカニズムのセキュリティリスクを超えてセキュリティリスクを増大させることはありません。攻撃者は、カプセル化を解除するエンドポイントに過度のトラフィック負荷をかけることにより、ルーターに過負荷をかけようとする可能性があります。通常、ルーターはパケットのカプセル化を解除する際に50％のパフォーマンスの低下を伴います。攻撃者はルーターが影響を受けることを確信できず、必要とされる非常に大量のトラフィックが異常として簡単に検出されます。攻撃者がリンクの可用性に影響を与えることができる場合、ネットワークを介してnot-via修復メカニズムを呼び出す可能性があります。 not via IPFRRによって保護されたネットワークは、リンクアップ/ダウンイベントに応答して完全な収束を実行したネットワークよりも、このような攻撃に対して脆弱ではありません。
The authors would like to acknowledge contributions made by Alia Atlas and John Harper.
著者は、Alia AtlasとJohn Harperの貢献に謝意を表します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[ISPF] McQuillan, J., Richer, I., and E. Rosen, "ARPANET Routing Algorithm Improvements", BBN Technical Report 3803, 1978.
[ISPF] McQuillan、J.、Richer、I。、およびE. Rosen、「ARPANET Routing Algorithm Improvements」、BBN Technical Report 3803、1978。
[NNHL] Shen, N., Chen, E., and A. Tian, "Discovering LDP Next-Nexthop Labels", Work in Progress, May 2005.
[NNHL] Shen、N.、Chen、E。、およびA. Tian、「LDP Next-Nexthop Labelsの発見」、Work in Progress、2005年5月。
[REMOTE-LFA] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. So, "Remote LFA FRR", Work in Progress, May 2013.
[REMOTE-LFA]ブライアント、S。、フィルスフィルス、C。、プレビディ、S。、シャンド、M.、N。したがって、「リモートLFA FRR」、作業中、2013年5月。
[RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994.
[RFC1701] Hanks、S.、Li、T.、Farinacci、D。、およびP. Traina、「Generic Routing Encapsulation（GRE）」、RFC 1701、1994年10月。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、Moskowitz、R.、Karrenberg、D.、Groot、G。、およびE. Lear、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003]パーキンス、C。、「IP内のIPカプセル化」、RFC 2003、1996年10月。
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC3931] Lau、J.、Townsley、M。、およびI. Goyret、「Layer Two Tunneling Protocol-Version 3（L2TPv3）」、RFC 3931、2005年3月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193] Hinden、R。およびB. Haberman、「Unique Local IPv6 Unicast Addresses」、RFC 4193、2005年10月。
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007.
[RFC5036] Andersson、L.、Minei、I。、およびB. Thomas、「LDP仕様」、RFC 5036、2007年10月。
[RFC5101] Claise, B., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008.
[RFC5101] Claise、B。、「IPトラフィックフロー情報の交換のためのIPフロー情報エクスポート（IPFIX）プロトコルの仕様」、RFC 5101、2008年1月。
[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 Fast Rerouteの基本仕様：ループフリー代替」、RFC 5286、2008年9月。
[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 5714, January 2010.
[RFC5714] Shand、M。およびS. Bryant、「IP Fast Reroute Framework」、RFC 5714、2010年1月。
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010.
[RFC5880] Katz、D。およびD. Ward、「Bidirectional Forwarding Detection（BFD）」、RFC 5880、2010年6月。
[RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security Concerns with IP Tunneling", RFC 6169, April 2011.
[RFC6169]クリシュナン、S。、ターラー、D。、およびJ.ホアグランド、「IPトンネリングに関するセキュリティ上の懸念」、RFC 6169、2011年4月。
[RFC6976] Shand, M., Bryant, S., Previdi, S., Filsfils, C., Francois, P., and O. Bonaventure, "Framework for Loop-Free Convergence Using the Ordered Forwarding Information Base (oFIB) Approach", RFC 6976, July 2013.
[RFC6976] Shand、M.、Bryant、S.、Previdi、S.、Filsfils、C.、Francois、P。、およびO. Bonaventure、「Ordered Forwarding Information Base（oFIB）アプローチを使用したループフリーの収束のフレームワーク」 "、RFC 6976、2013年7月。
Q-space is the set of routers from which a specific router can be reached without any path (including equal-cost path splits) transiting the protected link (or node). It is described fully in [REMOTE-LFA].
Qスペースは、保護されたリンク（またはノード）を通過するパス（等価コストパス分割を含む）なしで特定のルーターに到達できるルーターのセットです。 [REMOTE-LFA]で完全に説明されています。
S---Eq
/ \
A Dq
\ /
B---Cq
Figure 15: The Q Space of E with Respect to the Link S-E
図15：リンクS-Eに関するEのQ空間
Consider a repair of link S-E (Figure 15). The set of routers from which the node E can be reached, by normal forwarding, without traversing the link S-E is termed the Q-space of E with respect to the link S-E. The Q-space can be obtained by computing a reverse Shortest Path Tree (rSPT) rooted at E, with the sub-tree that traverses the failed link excised (including those that are members of an ECMP). The rSPT uses the cost towards the root rather than from it and yields the best paths towards the root from other nodes in the network. In the case of Figure 15, the Q-space comprises nodes E, D, and C only.
リンクS-Eの修理を検討してください（図15）。リンクS-Eを経由せずに通常の転送によってノードEに到達できるルーターのセットは、リンクS-Eに関するEのQ空間と呼ばれます。 Eをルートとする逆の最短パスツリー（rSPT）を計算することにより、Q空間を取得できます。失敗したリンクを横断するサブツリー（ECMPのメンバーであるものを含む）を削除します。 rSPTは、コストをルートからではなくルートに向かって使用し、ネットワーク内の他のノードからルートへの最適なパスを生成します。図15の場合、Q空間はノードE、D、Cのみで構成されます。
Authors' Addresses
著者のアドレス
Stewart Bryant Cisco Systems 10 New Square, Bedfont Lakes Feltham, Middlesex TW18 8HA UK
Stewart Bryant Cisco Systems 10 New Square、Bedfont Lakes Feltham、Middlesex TW18 8HA UK
EMail: stbryant@cisco.com
Stefano Previdi Cisco Systems Via Del Serafico, 200 00142 Rome Italy
Stefano Previdi Cisco Systems Via Del Serafico、200 00142 Rome Italy
EMail: sprevidi@cisco.com
Mike Shand Individual Contributor
Mike Shand個人貢献者
EMail: imc.shand@googlemail.com