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
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
一种使用非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.
本文档提供了一个说明性框架，用于通过封装和转发到“非通过”地址，在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.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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/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.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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快速重路由（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机制中的一个常见限制是无法指示故障的身份，并显式地引导修复后的数据包绕过故障。此限制对修复范围的影响程度取决于拓扑。这里提出的机制是将数据包封装到一个地址，该地址明确标识修复必须避免的网络组件。这就产生了一种修复机制，只要网络没有因故障而分区，该机制将始终实现修复。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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的非通过方法。考虑下面的图1所示的网络片段，其中S有一个用于目标D的包，它通常会通过P和B发送，并且怀疑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
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表示“只能通过节点P访问的节点B地址”。稍后，我们将展示如何安装从S到Bp的路径，使其成为不经过P的从S到B的最短路径。如果网络包含不经过路由器P的从S到B的路径，即，网络未因P故障而分区，并且已安装从S到Bp的路径，然后，数据包将成功地传送到B。在图1中的示例中，这是路径S-X-Y-Z-B。当发送给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到最终目的地的路径包括修复路径中包括的一个或多个节点，则在移除封装之后，分组可以回溯。但是，由于解封路由器总是比封装路由器更接近数据包目的地，因此数据包不会循环。
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的所有邻居都需要一个not via地址，该地址允许在不经过P的情况下将流量定向到它们。如图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
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.
路由器可以使用等成本多路径（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]中所述，将非通孔与无环交替（LFA）和/或下游路径结合使用具有优势。特别是，LFA不需要向节点分配和管理额外的IP地址，也不需要升级网络中的节点以计算not via修复路径，也不需要使用封装。
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
LFA是根据每个目的地计算的，通常只有需要维修的目的地的子集才会有合适的LFA维修。在这种情况下，LFA可修复的目的地将被修复，其余的目的地将使用not via封装进行修复。另一方面，LFA修复所采用的路径可能不如目的地靠近网络远端节点的流量的等效非经由修复路径的最优路径
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，但两种机制之间的修复分配是本地实现选择。
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失效、运行最短路径优先（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，路由器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首先计算所有路由器正常工作时的基本拓扑，并确定其到所有not via地址的正常路径。这可以作为正常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直到完成。只要将iSPF运行到所有非通过P地址发送广告的节点都已重新连接到最短路径树（SPT）上，然后将其终止即可。
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. 不通过修复距离和路径向量路由协议进行计算
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地址Ps的信息不通过节点S传播，这可以通过很少的协议修改来实现。在链路保护的情况下，这仅仅意味着抑制从P到S的公布，其结果是S和所有其他节点计算到Ps的路由，该路由不会根据需要穿过S。
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的播发不仅需要在链路N-P上被抑制，还需要在到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到Bp发送给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.
请注意，使用这种技术只需要一个级别的封装，并且可以修复任何故障，而不考虑链路度量和网络中可能存在的任何不对称性。唯一的例外是，故障是将网络分区的单点故障，在这种情况下，显然不可能进行任何修复。
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封装到Ps（即，它指示网络不通过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地址提供修复路径来防止由于相互修复而形成环路。第6.3节将更详细地讨论具有非通孔地址的数据包的修复。参考图2，如果A是在从S到P的链路修复路径上的P的邻居，并且P本身发生故障，则从S修复的数据包将到达封装到Ps的A。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出现故障时，它需要将发往MHP X的数据包（通常可以通过P到达）发送到仍然可以到达X的备用路由器。
X X X
| | |
| | |
| Sp |Pb |
Z...............S----------P----------B...............Y
Ps|Pc Bp
|
Cp|
C
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确定在运行SPF时将哪个路由器用作备用路由器，同时删除P。这是通过将叶节点重新连接到核心拓扑（有时称为“部分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。Z可以到达Z而不使用删除的路由器P。然而，S不能仅向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必须首先使用正常的非通过修复机制将包修复到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.
请注意，每个节点只需要一个这样的地址。请注意，使用not via方法，只需要一个封装级别就可以将MHP修复到备用路由器。
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）中预先计算并安装修复路径，以便在发生故障时立即使用。假设已经如上所述计算了not via修复路径。
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有一个到非通过地址Hp（H非通过P）的路径，请为目标DR安装一个非通过修复到Hp。
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故障后可到达的备用连接点。确定这些目的地的一种方法是在移除节点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），将not via repair安装到Ps（P not via S）。注意，这些目的地的节点P是单点故障，并且只能通过假设节点P的明显故障只是S-P链路的故障来修复它们。注意，如果可用，P的下游路径可用于此类维修。这无法在节点P发生故障的情况下生成持久循环，但是如果P的一个邻居使用not-via修复，而另一个使用下行路径，则在下行路径上发送的数据包有可能在not-via封装内返回给发送节点。由于不通过地址发送的数据包不会被修复，因此在执行单圈循环后，数据包将被丢弃。
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的语义从简单的“P not via link S-P”更改为“P not via link S-P或S-P与之共享SRLG的任何其他链路”。在图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
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".
在一些情况下，组成SRLG的链路可能在从S到目的地D的路径上串联出现，如图5所示。在这种情况下，可能需要多次连续维修。S将首先修复为Ps，然后P将修复为Dp。在这两种情况下，由于相关链路是SRLG“a”的成员，因此计算路径以避免SRLG“a”的所有成员。
a Ps a Dp
S----------P---------D
| | |
| a | |
A----------B |
| | |
| | |
C----------E---------F
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：串联的共享风险链接组成员-一个节点的解封装和重新封装
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地址重新封装包之前，第一修复包被解除封装。在某些情况下，去封装和重新封装（至少在概念上）发生在单个节点上，而在其他情况下，这些功能可由不同节点执行。此场景如下图6所示。
a Ps a Dg
S----------P---------G--------D
| | | |
| a | | |
A----------B | |
| | | |
| | | |
C----------E---------F--------H
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首先封装到Ps，节点P解除封装该分组并使用其针对目的地D的正常FIB条目将其“本机”转发到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.
通常情况下，单个链路可能是多个SRLGs的成员，而这些SRLGs可能不是同构的。下面的图7对此进行了说明。
ab Ps a Dg
S----------P---------G--------D
| | | |
| a | | |
A----------B | |
| | | |
| b | | b |
C----------E---------F--------H
| |
| |
J----------K
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是SRLGs“a”和“b”的成员。当检测到链路S-P故障时，必须假设两个SRLGs都发生故障。因此，需要通过使属于SRLG“a”或SRLG“b”成员的所有链路失效来计算到Ps的not via路径，即，Ps的语义现在是“P not via not via not WITH any links-P是其成员的任何SRLGs的成员的链路”。下面的图8对此进行了说明。
ab Ps a Dg
S----/-----P---------G---/----D
| | | |
| a | | |
A----/-----B | |
| | | |
| b | | b |
C----/-----E---------F---/----H
| |
| |
J----------K
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
在这种情况下，到Ps的修复路径将是S-A-C-J-K-E-B-P。似乎没有到D的路径，因为G-D是SRLG“A”的成员，F-H是SRLG“B”的成员。如果SRLGs“a”和“b”实际上都发生了故障，这将是多个独立故障的实例，则情况就是如此。实际上，很可能只有一个故障，即SRLG“a”或SRLG“b”中的一个故障，但不是两个都故障。从修复路由器的角度来看，这两种可能性是无法区分的，因此它需要在网络上进行修复
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的修复将数据包交付给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
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”都出现故障，则数据包将被S修复至P，并由P转发至G。G将使用非通孔地址Dg将数据包封装至D，并将其转发至F。F将认识到由于链路F-H（SRLG“b”的一部分）故障而无法到达其到Dg（H）的下一跳，并将丢弃数据包，因为发往not via地址的数据包不会在basic not via 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成员实际发生故障，并使用此信息选择适当的预计算修复路径。但是，除了执行诊断的复杂性之外，这还需要每个接口有多个非通孔地址，这具有较差的扩展特性。
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.
局域网是一种特殊类型的SRLG，使用上述SRLG机制解决。对于所有SRLG，在故障检测的复杂性和SRLG的大小之间存在权衡。防止LAN链路的链路故障相对简单，但与所有快速重路由机制一样，当需要防止连接到LAN的节点以及LAN本身发生故障的可能性时，问题变得更加复杂。
+--------------Q------C
|
|
|
A--------S-------(N)-------------P------B
|
|
|
+--------------R------D
+--------------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。对于连接的目的，我们认为局域网由伪节点（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 它自己与局域网的接口
o the LAN itself
o 局域网本身
o the LAN interface of P
o P
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.
局域网修复的一种简单方法是将局域网及其所有连接路由器视为单个SRLG。因此，不通过LAN（Pl）的地址P将要求不通过连接到LAN的任何路由器到达P。如图11所示。
Ql Cl
+-------------Q--------C
| Qc
|
As Sl | Pl Bl
A--------S-------(N)------------P--------B
Sa | Pb
|
| Rl Dl
+-------------R--------D
Rd
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).
在这种情况下，如果S检测到P出现故障，它会将通过P和B到达的流量发送到B，而不是通过LAN或连接到LAN的任何路由器（即，发送到Bl）。只有通过P才能到达的任何目的地都将被发送到P，而不是通过LAN或连接到LAN的任何路由器（当然，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不通过P，N，即B不通过P和N）的通信量，保守假设整个LAN和P都发生故障。通常，P为单点故障的目的地必须使用避免P从S到达的接口的地址发送到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的路由器必须像往常一样，为每个邻居通告一个而不是通过地址。此外，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的路由器的每个邻居都需要公布两个非通过地址：通常的一个不是通过邻居，另外一个不是通过邻居或伪节点。所需的一组LAN地址分配如下图12所示。LAN上的每个路由器及其每个邻居都在公布一个地址，如果使用点对点链接实现这种连接程度，则它们会公布的地址会比其他情况下公布的地址多。
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
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
可以通过使用诊断进行更具体的LAN修复。为了明确诊断发生故障的网络组件，S将来自P和LAN上的一个或多个其他路由器（在本例中为Q和R）的连接报告关联起来。如果S单独与P失去连接，则可以推断LAN仍在运行
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.
故障在于P或将P连接到LAN的接口。然后，它将以通常的方式不通过P（对于P为单点故障的目的地，P不通过N）修复到B。如果S失去了与LAN上多个路由器的连接，它可以得出结论，故障只发生在LAN上，并且可以以通常的方式修复P、Q和R，而不是通过N。
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.
IPFRR修复非已知SRLG成员的多个同时故障是复杂的，因为使用多个并发修复可能会导致修复路径循环。如第5.2.1节所述，防止此类循环的最简单方法是确保寻址到not via地址的数据包不会被修复，而是被丢弃。网络可能同时发生多个故障。这可能是由于简单的统计效应，但更可能的原因是意外的SRLGs。当检测到不属于预期组的多个故障时，将放弃修复，网络将恢复正常聚合。虽然安全，但这种方法有点苛刻，因为在许多情况下，多次修复不会导致环路。
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.
让我们假设修复机制完全基于not via修复。可合并LFA或下游路线，并将在以后处理。
A------//------B------------D
/ \
/ \
F G
\ /
\ /
X------//------Y
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:
有三种情况需要考虑：
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. 考虑一对受保护链接A- B和X-Y的一般情况，如图13所示的网络片段所示。如果A-B的修复路径不穿过X-Y，并且X-Y的修复路径不穿过A-B，则这种情况是完全安全的，不会导致循环或数据包丢失。
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的数据包经过两个串联修复。
A------//------B------------X------//------Y------D
| | | |
| | | |
M--------------+ N--------------+
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的非通孔路径穿过链路X-Y，但从X到Y的非通孔路径穿过一些图13中未显示的路径时，会发生这种情况。如果没有本节所述的多故障机制，A-B的修复数据包将在到达X-Y时丢弃，因为修复的数据包将被禁止。但是，如果允许修复此数据包，则到D的路径将是完整的，不会造成任何伤害，尽管需要两个级别的封装。
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
当A计算A-B的not-via修复路径（即，寻址到Ba的分组的路径，读作“B not-via”）时，它知道该路径所经过的节点列表。这可以通过简单地添加到SPF过程中来记录，并且可以确定与每个前向链路相关联的not via地址。如果路径是A、F、X、Y、G、B（图13），那么非via地址列表将是Fa、Xf、Yx、Gy、Bg。在标准not via操作下，A将填充其FIB，以使所有正常地址正常工作
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-B出现故障时，可通过A-B访问的数据将被封装到Ba中，但发送到到达A的任何非通过地址的流量将被丢弃。新的过程对此进行了修改，使得通常可通过a-B到达的非经由地址的任何通信也被封装到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.
到目前为止，我们已经允许良性修复共存，尽管有时需要多次封装。请注意，在许多情况下不会影响性能，因为除非两个故障都在同一个节点上，否则两个封装或两个解封装将在不同的节点上执行。然而，存在多重封装对最大传输单元（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中，最简单的方法是不为可能循环的修复路径安装修复。在这种情况下，尽管潜在的循环流量被丢弃，但该流量不会被修复。如果我们假设在链路故障只是一个短故障的情况下，在重新会聚之前应用抑制，并且如果无环会聚机制进一步延迟会聚，那么通信量将在较长时间内下降。在这种情况下，最好采用“放弃所有希望”（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.
请注意，由于有序FIB（oFIB）算法[RFC6976]可能会将其视为允许的同时故障，因此仅加快发布报告故障的链路状态包（LSP）是不够的。因此，有必要显式触发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的一种方法是允许修复，并在修复发生时通过实验发现修复的不相容性。使用此方法，我们允许在情况3中进行修复，并在not via地址上的数据包丢弃计数增加时触发AAH。或者，可以等待，直到描述变更的LSP正常发出（即，当X宣布X-Y故障时）。当修复节点A（其预先计算出X-Y故障与其自身的修复互不兼容）接收到该LSP时，它可以随后发出AAH。这有一个缺点，即它不能克服抑制延迟，但它不需要“数据驱动”操作，并且它仍然具有放弃oFIB的所需效果，这可能是延迟中较长的一个（尽管对于信号oFIB，这应该是亚秒）。
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.
简单丢弃循环数据包或在循环发生后检测循环的另一种方法是使用辅助SRLGs。使用链路状态路由协议，可以预先计算修复的不兼容性，并计算备用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".
这种方法要求我们识别相互不兼容的故障，并将其公布为“次要SRLGs”。当计算受影响的not via地址的修复路径时，这些链接将同时删除。请注意，假定的同时故障和结果修复路径仅适用于为冲突的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,
理想情况下，我们只希望在确定修复路径互不兼容时调用辅助SRLG计算。考虑图13中节点A的情况。节点A首先确定A-B的修复路径是通过F-X-Y-G-B。然后它探索该路径，确定路径中每个链路的修复路径。因此
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.
例如，它在X处执行检查，方法是在X处运行根于X的SPF，并移除X-Y链接，以确定a-B是否确实位于X的修复路径上，该路径用于指向Yx的数据包。
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个邻居进行修复。在每种情况下，它都会标识每个修复所遍历的节点对列表。这些列表通常可能有一个或多个共同的节点对，因此需要调查的链路故障的实际数量是这些集合的并集。然后，有必要运行以每对的第一个节点为根的SPF（第一个节点，因为成对的顺序表示路径的方向），删除到第二个节点的链接。此SPF虽然不是增量的，但可以在到达not via地址后立即终止。例如，当运行以X为根的SPF时，当链接X-Y被移除时，SPF可以在到达Yx时终止。一旦找到路径，将检查路径以确定其是否在远离A的方向上穿过A的任何链路。注意，由于节点对X-Y可能存在于A的多个链路的列表中（即，它位于多个修复路径上），因此有必要识别正确的列表，从而识别链路，具有相互循环的修复路径。然后，A将A的该链路作为与链路X-Y配对的辅助SRLG进行广告。还请注意，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-B和not via-Y）计算两个故障周围的修复路径。
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集，我们还可以公布新的修复路径，并且只让该路径上的节点执行必要的计算。还请注意，一旦我们就这两个故障达到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.
有利于识别这些情况，并抑制次要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].
到目前为止，在本节中，我们假设所有维修均不通过隧道进行。然而，在实践中，我们可能希望在可用的情况下使用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地址的丢弃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修复的情况下，当数据包到达第二个故障时，循环将被中断。然而，分组通过下游路由被无条件地修复，并且因此当相互对由下游路由和非通孔修复组成时，循环分组将仅在其返回到第一故障时被丢弃，即，它将在被丢弃之前执行单圈循环。
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
下游路由存在进一步的复杂性，因为尽管可以计算到故障的远端的路径，但是分组可以在到达故障的远端之前“剥离”到其目的地。在这种情况下，它可能会遍历已发生故障且未在计算路径上说明的其他链接。如果A-B修复（图13）是一条下游路径，而X-Y修复是一条非通孔修复，那么我们可以看到封装到Yx的X-Y修复数据包沿着一条试图穿越A-B的路径。如果“正常”地址的A-B修复路径是一条下游路径，则不能假设数据包的修复路径是
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).
发到Yx的地址可以发送到同一个邻居。这是因为下游路线的有效性必须在Yx表示的拓扑中确定，即在链路X-Y被移除的情况下确定。这与用于正常下游计算的拓扑不同，并且对封装的分组使用正常下游路由可能导致未检测到的环路。如果在计算上检查该拓扑中的下游路由是可行的（即，对于穿过A-B的任何非通孔地址Qp，我们必须在移除链路Q-P的情况下对拓扑中的非通孔地址执行下游计算），则可以安全地使用Yx的下游修复。这些数据包不能重新访问X-Y，因为根据定义，它们将避免该链接。或者，可以始终在非经由隧道中修复数据包，即，即使穿越a-B的流量的正常修复将使用下游路由，我们可以坚持寻址到非经由地址的此类流量必须使用到Ba的隧道。如果确定地址Qp不穿过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，则任何路由器都不必在移除链路S-P的情况下执行增量SPF以计算到not via地址Ps的路由。这是因为在基本拓扑上的SPF已经计算出正确的路由。节点S可以通过在其LSP或与LFA保护的每个链路相关联的链路状态通告（LSA）中包括比特来向所有其他路由器发送该条件的信号。不通过路由进行计算的路由器可以省略对具有该位集的链路运行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上游的节点，其S-P位于到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]将以通常的方式为它们分发标签。因此，通过首先推送修复端点用于转发分组的标签，然后推送与实现修复所需的非经由地址相对应的标签，非经由修复机制可用于在MPLS网络中提供快速重路由。再次参考图1，如果S有一个目的地为D的数据包，它必须通过P和B到达，则S首先推送B的D标签。然后推送其下一跳到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需要与其每个邻居建立定向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封装可用于承载非通孔修复。IP[RFC2003]中的IP、通用路由封装（GRE）[RFC1701]和第二层隧道协议（L2TPv3）[RFC3931]都具有必要和充分的属性。要求是封装路由器和封装数据包寻址到的路由器都具有处理所选封装类型的通用能力。当MPLS LDP网络受到保护时，封装通常是附加的MPLS标签。在启用MPLS的IP网络中，在上述情况下，可以使用MPLS标签代替IP-In-IP封装。
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.
能够支持非经由路由的路由器必须在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节中提出的优化，那么在路由协议中也必须用信号通知使用LFA代替not via修复。
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
通过从用于修复路径计算的基本拓扑中排除不通过路由计算的路由器（如其充满链路状态信息的能力信息所示），支持增量部署。通过这种方式，可以围绕不具备IPFRR能力的路由器孤岛进行维修。保护网络组件的路由器需要具有封装和解封数据包的能力。但是，修复路径上的路由器只需要能够
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路径并在其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一般情况的一般可管理性注意事项。我们稍微扩展了这一点，并添加了非特定的细节。有三类可管理性注意事项：
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:
非通孔的故障前配置包括：
o Enabling/disabling not-via IPFRR support.
o 非通过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 配置非通过地址（每个接口）或非通过地址集（每个节点）。
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:
非通孔的故障前监测和运行支持包括：
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或非via）。
o Notification of not-via address assignment.
o 通知不通过地址分配。
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 测试修复路径。请注意，就traceroute和ping等工具而言，not via地址看起来与“普通”地址相同，因此预计这些地址将用于验证已建立的修复路径。
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:
非通孔的故障动作监控包括：
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.
注意，监测正在进行的修复需要捕获短时间（可能是亚秒）网络瞬态的特征；这种技术不是一种成熟的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
修复端点存在漏洞，因为它们可能被用作伪装向网络中某个点传递数据包的方法[RFC6169]。保护的主要方法应该是通过使用非通孔地址的专用地址空间[RFC1918][RFC4193]。修复端点地址不得在部署了NOT via的路由域之外播发，并且必须在网络入口点进行过滤。此外，还可以开发一种机制，允许通过使用密钥[RFC1701][RFC3931]使用轻度安全性。通过部署此类机制，修复端点不会增加现有IP隧道机制之外的安全风险。攻击者可能试图通过以下方式使路由器过载：
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.
解决去封装终结点的过多流量负载。通常，路由器在对数据包进行去封装时会受到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路由算法改进”，BBN技术报告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，“发现自民党下一代标签”，正在进行的工作，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]Bryant，S.，Filsfils，C.，Previdi，S.，Shand，M.，和N.So，“远程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.，Farinaci，D.，和P.Traina，“通用路由封装（GRE）”，RFC 17011994年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]Perkins，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，“第二层隧道协议-版本3（L2TPv3）”，RFC 39312005年3月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193]Hinden，R.和B.Haberman，“唯一本地IPv6单播地址”，RFC 41932005年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快速重路由的基本规范：无环路交替”，RFC 5286，2008年9月。
[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 5714, January 2010.
[RFC5714]Shand，M.和S.Bryant，“IP快速重路由框架”，RFC 5714，2010年1月。
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010.
[RFC5880]Katz，D.和D.Ward，“双向转发检测（BFD）”，RFC 58802010年6月。
[RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security Concerns with IP Tunneling", RFC 6169, April 2011.
[RFC6169]Krishnan，S.，Thaler，D.，和J.Hoagland，“IP隧道的安全问题”，RFC 61692011年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，“使用有序转发信息库（oFIB）方法的无循环收敛框架”，RFC 69762013年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-space是一组路由器，在没有任何路径（包括等成本路径拆分）通过受保护链路（或节点）的情况下，可以从这些路由器到达特定的路由器。[REMOTE-LFA]对此进行了详细描述。
S---Eq
/ \
A Dq
\ /
B---Cq
S---Eq
/ \
A Dq
\ /
B---Cq
Figure 15: The Q Space of E with Respect to the Link S-E
图15:E相对于链路S-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）。通过正常转发可以到达节点E而不穿过链路S-E的路由器集被称为相对于链路S-E的E的Q空间。Q空间可以通过计算根植于E的反向最短路径树（rSPT）来获得，其中穿过故障链路的子树被切除（包括ECMP的成员）。rSPT使用指向根的成本，而不是来自根的成本，并从网络中的其他节点产生指向根的最佳路径。在图15的情况下，Q空间仅包括节点E、D和C。
Authors' Addresses
作者地址
Stewart Bryant Cisco Systems 10 New Square, Bedfont Lakes Feltham, Middlesex TW18 8HA UK
斯图尔特·布莱恩特思科系统10新广场，贝德方特湖费尔瑟姆，米德尔塞克斯TW18 8HA英国
EMail: stbryant@cisco.com
EMail: stbryant@cisco.com
Stefano Previdi Cisco Systems Via Del Serafico, 200 00142 Rome Italy
Stefano Previdi Cisco Systems Via Del Serafico，意大利罗马200 00142
EMail: sprevidi@cisco.com
EMail: sprevidi@cisco.com
Mike Shand Individual Contributor
迈克·尚德个人投稿人
EMail: imc.shand@googlemail.com
EMail: imc.shand@googlemail.com