RFC5286 日本語訳
5286 Basic Specification for IP Fast Reroute: Loop-Free Alternates. A.Atlas, Ed., A. Zinin, Ed.. September 2008. (Format: TXT=71027 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group A. Atlas, Ed.
Request for Comments: 5286 BT
Category: Standards Track A. Zinin, Ed.
Alcatel-Lucent
September 2008
Network Working Group A. Atlas, Ed. Request for Comments: 5286 BT Category: Standards Track A. Zinin, Ed. Alcatel-Lucent September 2008
Basic Specification for IP Fast Reroute: Loop-Free Alternates
Basic Specification for IP Fast Reroute: Loop-Free Alternates
Status of This Memo
Status of This Memo
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Abstract
Abstract
This document describes the use of loop-free alternates to provide local protection for unicast traffic in pure IP and MPLS/LDP networks in the event of a single failure, whether link, node, or shared risk link group (SRLG). The goal of this technology is to reduce the packet loss that happens while routers converge after a topology change due to a failure. Rapid failure repair is achieved through use of precalculated backup next-hops that are loop-free and safe to use until the distributed network convergence process completes. This simple approach does not require any support from other routers. The extent to which this goal can be met by this specification is dependent on the topology of the network.
This document describes the use of loop-free alternates to provide local protection for unicast traffic in pure IP and MPLS/LDP networks in the event of a single failure, whether link, node, or shared risk link group (SRLG). The goal of this technology is to reduce the packet loss that happens while routers converge after a topology change due to a failure. Rapid failure repair is achieved through use of precalculated backup next-hops that are loop-free and safe to use until the distributed network convergence process completes. This simple approach does not require any support from other routers. The extent to which this goal can be met by this specification is dependent on the topology of the network.
Atlas, et al. Standards Track [Page 1] RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008
Atlas, et al. Standards Track [Page 1] RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008
Table of Contents
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Failure Scenarios . . . . . . . . . . . . . . . . . . . . 5
1.2. Requirement Language . . . . . . . . . . . . . . . . . . . 8
2. Applicability of Described Mechanisms . . . . . . . . . . . . 8
3. Alternate Next-Hop Calculation . . . . . . . . . . . . . . . . 9
3.1. Basic Loop-Free Condition . . . . . . . . . . . . . . . . 10
3.2. Node-Protecting Alternate Next-Hops . . . . . . . . . . . 10
3.3. Broadcast and Non-Broadcast Multi-Access (NBMA) Links . . 11
3.4. ECMP and Alternates . . . . . . . . . . . . . . . . . . . 12
3.5. Interactions with IS-IS Overload, RFC 3137, and Costed
Out Links . . . . . . . . . . . . . . . . . . . . . . . . 13
3.5.1. Interactions with IS-IS Link Attributes . . . . . . . 14
3.6. Selection Procedure . . . . . . . . . . . . . . . . . . . 14
3.7. LFA Types and Trade-Offs . . . . . . . . . . . . . . . . . 18
3.8. A Simplification: Per-Next-Hop LFAs . . . . . . . . . . . 19
4. Using an Alternate . . . . . . . . . . . . . . . . . . . . . . 20
4.1. Terminating Use of Alternate . . . . . . . . . . . . . . . 20
5. Requirements on LDP Mode . . . . . . . . . . . . . . . . . . . 22
6. Routing Aspects . . . . . . . . . . . . . . . . . . . . . . . 22
6.1. Multi-Homed Prefixes . . . . . . . . . . . . . . . . . . . 22
6.2. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.3. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.3.1. OSPF External Routing . . . . . . . . . . . . . . . . 24
6.3.2. OSPF Multi-Topology . . . . . . . . . . . . . . . . . 25
6.4. BGP Next-Hop Synchronization . . . . . . . . . . . . . . . 25
6.5. Multicast Considerations . . . . . . . . . . . . . . . . . 25
7. Security Considerations . . . . . . . . . . . . . . . . . . . 25
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9.1. Normative References . . . . . . . . . . . . . . . . . . . 26
9.2. Informative References . . . . . . . . . . . . . . . . . . 26
Appendix A. OSPF Example Where LFA Based on Local Area
Topology Is Insufficient . . . . . . . . . . . . . . 27
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Failure Scenarios . . . . . . . . . . . . . . . . . . . . 5 1.2. Requirement Language . . . . . . . . . . . . . . . . . . . 8 2. Applicability of Described Mechanisms . . . . . . . . . . . . 8 3. Alternate Next-Hop Calculation . . . . . . . . . . . . . . . . 9 3.1. Basic Loop-Free Condition . . . . . . . . . . . . . . . . 10 3.2. Node-Protecting Alternate Next-Hops . . . . . . . . . . . 10 3.3. Broadcast and Non-Broadcast Multi-Access (NBMA) Links . . 11 3.4. ECMP and Alternates . . . . . . . . . . . . . . . . . . . 12 3.5. Interactions with IS-IS Overload, RFC 3137, and Costed Out Links . . . . . . . . . . . . . . . . . . . . . . . . 13 3.5.1. Interactions with IS-IS Link Attributes . . . . . . . 14 3.6. Selection Procedure . . . . . . . . . . . . . . . . . . . 14 3.7. LFA Types and Trade-Offs . . . . . . . . . . . . . . . . . 18 3.8. A Simplification: Per-Next-Hop LFAs . . . . . . . . . . . 19 4. Using an Alternate . . . . . . . . . . . . . . . . . . . . . . 20 4.1. Terminating Use of Alternate . . . . . . . . . . . . . . . 20 5. Requirements on LDP Mode . . . . . . . . . . . . . . . . . . . 22 6. Routing Aspects . . . . . . . . . . . . . . . . . . . . . . . 22 6.1. Multi-Homed Prefixes . . . . . . . . . . . . . . . . . . . 22 6.2. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.3. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.3.1. OSPF External Routing . . . . . . . . . . . . . . . . 24 6.3.2. OSPF Multi-Topology . . . . . . . . . . . . . . . . . 25 6.4. BGP Next-Hop Synchronization . . . . . . . . . . . . . . . 25 6.5. Multicast Considerations . . . . . . . . . . . . . . . . . 25 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 9.1. Normative References . . . . . . . . . . . . . . . . . . . 26 9.2. Informative References . . . . . . . . . . . . . . . . . . 26 Appendix A. OSPF Example Where LFA Based on Local Area Topology Is Insufficient . . . . . . . . . . . . . . 27
Atlas, et al. Standards Track [Page 2] RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008
Atlas, et al. Standards Track [Page 2] RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008
1. Introduction
1. Introduction
Applications for interactive multimedia services such as Voice over IP (VoIP) and pseudowires can be very sensitive to traffic loss, such as occurs when a link or router in the network fails. A router's convergence time is generally on the order of hundreds of milliseconds; the application traffic may be sensitive to losses greater than tens of milliseconds.
Applications for interactive multimedia services such as Voice over IP (VoIP) and pseudowires can be very sensitive to traffic loss, such as occurs when a link or router in the network fails. A router's convergence time is generally on the order of hundreds of milliseconds; the application traffic may be sensitive to losses greater than tens of milliseconds.
As discussed in [FRAMEWORK], minimizing traffic loss requires a mechanism for the router adjacent to a failure to rapidly invoke a repair path, which is minimally affected by any subsequent re- convergence. This specification describes such a mechanism that allows a router whose local link has failed to forward traffic to a pre-computed alternate until the router installs the new primary next-hops based upon the changed network topology. The terminology used in this specification is given in [FRAMEWORK]. The described mechanism assumes that routing in the network is performed using a link-state routing protocol -- OSPF [RFC2328] [RFC2740] [RFC5340] or IS-IS [RFC1195] [RFC2966] (for IPv4 or IPv6). The mechanism also assumes that both the primary path and the alternate path are in the same routing area.
As discussed in [FRAMEWORK], minimizing traffic loss requires a mechanism for the router adjacent to a failure to rapidly invoke a repair path, which is minimally affected by any subsequent re- convergence. This specification describes such a mechanism that allows a router whose local link has failed to forward traffic to a pre-computed alternate until the router installs the new primary next-hops based upon the changed network topology. The terminology used in this specification is given in [FRAMEWORK]. The described mechanism assumes that routing in the network is performed using a link-state routing protocol -- OSPF [RFC2328] [RFC2740] [RFC5340] or IS-IS [RFC1195] [RFC2966] (for IPv4 or IPv6). The mechanism also assumes that both the primary path and the alternate path are in the same routing area.
When a local link fails, a router currently must signal the event to its neighbors via the IGP, recompute new primary next-hops for all affected prefixes, and only then install those new primary next-hops into the forwarding plane. Until the new primary next-hops are installed, traffic directed towards the affected prefixes is discarded. This process can take hundreds of milliseconds.
When a local link fails, a router currently must signal the event to its neighbors via the IGP, recompute new primary next-hops for all affected prefixes, and only then install those new primary next-hops into the forwarding plane. Until the new primary next-hops are installed, traffic directed towards the affected prefixes is discarded. This process can take hundreds of milliseconds.
<--
+-----+
/------| S |--\
/ +-----+ \
/ 5 8 \
/ \
+-----+ +-----+
| E | | N_1 |
+-----+ +-----+
\ /
\ \ 4 3 / /
\| \ / |/
-+ \ +-----+ / +-
\---| D |---/
+-----+
<-- +-----+ /------| S |--\ / +-----+ \ / 5 8 \ / \ +-----+ +-----+ | E | | N_1 | +-----+ +-----+ \ / \ \ 4 3 / / \| \ / |/ -+ \ +-----+ / +- \---| D |---/ +-----+
Figure 1: Basic Topology
Figure 1: Basic Topology
Atlas, et al. Standards Track [Page 3] RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008
Atlas, et al. Standards Track [Page 3] RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008
The goal of IP Fast Reroute (IPFRR) is to reduce failure reaction time to 10s of milliseconds by using a pre-computed alternate next- hop, in the event that the currently selected primary next-hop fails, so that the alternate can be rapidly used when the failure is detected. A network with this feature experiences less traffic loss and less micro-looping of packets than a network without IPFRR. There are cases where traffic loss is still a possibility since IPFRR coverage varies, but in the worst possible situation a network with IPFRR is equivalent with respect to traffic convergence to a network without IPFRR.
The goal of IP Fast Reroute (IPFRR) is to reduce failure reaction time to 10s of milliseconds by using a pre-computed alternate next- hop, in the event that the currently selected primary next-hop fails, so that the alternate can be rapidly used when the failure is detected. A network with this feature experiences less traffic loss and less micro-looping of packets than a network without IPFRR. There are cases where traffic loss is still a possibility since IPFRR coverage varies, but in the worst possible situation a network with IPFRR is equivalent with respect to traffic convergence to a network without IPFRR.
To clarify the behavior of IP Fast Reroute, consider the simple topology in Figure 1. When router S computes its shortest path to router D, router S determines to use the link to router E as its primary next-hop. Without IP Fast Reroute, that link is the only next-hop that router S computes to reach D. With IP Fast Reroute, S also looks for an alternate next-hop to use. In this example, S would determine that it could send traffic destined to D by using the link to router N_1 and therefore S would install the link to N_1 as its alternate next-hop. At some later time, the link between router S and router E could fail. When that link fails, S and E will be the first to detect it. On detecting the failure, S will stop sending traffic destined for D towards E via the failed link, and instead send the traffic to S's pre-computed alternate next-hop, which is the link to N_1, until a new SPF is run and its results are installed. As with the primary next-hop, an alternate next-hop is computed for each destination. The process of computing an alternate next-hop does not alter the primary next-hop computed via a standard SPF.
To clarify the behavior of IP Fast Reroute, consider the simple topology in Figure 1. When router S computes its shortest path to router D, router S determines to use the link to router E as its primary next-hop. Without IP Fast Reroute, that link is the only next-hop that router S computes to reach D. With IP Fast Reroute, S also looks for an alternate next-hop to use. In this example, S would determine that it could send traffic destined to D by using the link to router N_1 and therefore S would install the link to N_1 as its alternate next-hop. At some later time, the link between router S and router E could fail. When that link fails, S and E will be the first to detect it. On detecting the failure, S will stop sending traffic destined for D towards E via the failed link, and instead send the traffic to S's pre-computed alternate next-hop, which is the link to N_1, until a new SPF is run and its results are installed. As with the primary next-hop, an alternate next-hop is computed for each destination. The process of computing an alternate next-hop does not alter the primary next-hop computed via a standard SPF.
If in the example of Figure 1, the link cost from N_1 to D increased to 30 from 3, then N_1 would not be a loop-free alternate, because the cost of the path from N_1 to D via S would be 17 while the cost from N_1 directly to D would be 30. In real networks, we may often face this situation. The existence of a suitable loop-free alternate next-hop is dependent on the topology and the nature of the failure for which the alternate is calculated.
If in the example of Figure 1, the link cost from N_1 to D increased to 30 from 3, then N_1 would not be a loop-free alternate, because the cost of the path from N_1 to D via S would be 17 while the cost from N_1 directly to D would be 30. In real networks, we may often face this situation. The existence of a suitable loop-free alternate next-hop is dependent on the topology and the nature of the failure for which the alternate is calculated.
This specification uses the terminology introduced in [FRAMEWORK]. In particular, it uses Distance_opt(X,Y), abbreviated to D_opt(X,Y), to indicate the shortest distance from X to Y. S is used to indicate the calculating router. N_i is a neighbor of S; N is used as an abbreviation when only one neighbor is being discussed. D is the destination under consideration.
This specification uses the terminology introduced in [FRAMEWORK]. In particular, it uses Distance_opt(X,Y), abbreviated to D_opt(X,Y), to indicate the shortest distance from X to Y. S is used to indicate the calculating router. N_i is a neighbor of S; N is used as an abbreviation when only one neighbor is being discussed. D is the destination under consideration.
Atlas, et al. Standards Track [Page 4] RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008
Atlas, et al. Standards Track [Page 4] RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008
A neighbor N can provide a loop-free alternate (LFA) if and only if
A neighbor N can provide a loop-free alternate (LFA) if and only if
Distance_opt(N, D) < Distance_opt(N, S) + Distance_opt(S, D)
Distance_opt(N, D) < Distance_opt(N, S) + Distance_opt(S, D)
Inequality 1: Loop-Free Criterion
Inequality 1: Loop-Free Criterion
A subset of loop-free alternates are downstream paths that must meet a more restrictive condition that is applicable to more complex failure scenarios:
A subset of loop-free alternates are downstream paths that must meet a more restrictive condition that is applicable to more complex failure scenarios:
Distance_opt(N, D) < Distance_opt(S, D)
Distance_opt(N, D) < Distance_opt(S, D)
Inequality 2: Downstream Path Criterion
Inequality 2: Downstream Path Criterion
1.1. Failure Scenarios
1.1. Failure Scenarios
The alternate next-hop can protect against a single link failure, a single node failure, failure of one or more links within a shared risk link group, or a combination of these. Whenever a failure occurs that is more extensive than what the alternate was intended to protect, there is the possibility of temporarily looping traffic (note again, that such a loop would only last until the next complete SPF calculation). The example where a node fails when the alternate provided only link protection is illustrated below. If unexpected simultaneous failures occur, then micro-looping may occur since the alternates are not pre-computed to avoid the set of failed links.
The alternate next-hop can protect against a single link failure, a single node failure, failure of one or more links within a shared risk link group, or a combination of these. Whenever a failure occurs that is more extensive than what the alternate was intended to protect, there is the possibility of temporarily looping traffic (note again, that such a loop would only last until the next complete SPF calculation). The example where a node fails when the alternate provided only link protection is illustrated below. If unexpected simultaneous failures occur, then micro-looping may occur since the alternates are not pre-computed to avoid the set of failed links.
If only link protection is provided and the node fails, it is possible for traffic using the alternates to experience micro- looping. This issue is illustrated in Figure 2. If Link(S->E) fails, then the link-protecting alternate via N will work correctly. However, if router E fails, then both S and N will detect a failure and switch to their alternates. In this example, that would cause S to redirect the traffic to N and N to redirect the traffic to S and thus causing a forwarding loop. Such a scenario can arise because the key assumption, that all other routers in the network are forwarding based upon the shortest path, is violated because of a second simultaneous correlated failure -- another link connected to the same primary neighbor. If there are not other protection mechanisms to handle node failure, a node failure is still a concern when only using link-protecting LFAs.
If only link protection is provided and the node fails, it is possible for traffic using the alternates to experience micro- looping. This issue is illustrated in Figure 2. If Link(S->E) fails, then the link-protecting alternate via N will work correctly. However, if router E fails, then both S and N will detect a failure and switch to their alternates. In this example, that would cause S to redirect the traffic to N and N to redirect the traffic to S and thus causing a forwarding loop. Such a scenario can arise because the key assumption, that all other routers in the network are forwarding based upon the shortest path, is violated because of a second simultaneous correlated failure -- another link connected to the same primary neighbor. If there are not other protection mechanisms to handle node failure, a node failure is still a concern when only using link-protecting LFAs.
Atlas, et al. Standards Track [Page 5] RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008
Atlas, et al. Standards Track [Page 5] RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008
<@@@
@@@>
+-----+ +-----+
| S |-------| N |
+-+---+ 5 +-----+
| |
| 5 4 | |
| | | \|/
\|/ | |
| +-----+ |
+----| E |---+
+--+--+
|
|
| 10
|
+--+--+
| D |
+-----+
<@@@ @@@> +-----+ +-----+ | S |-------| N | +-+---+ 5 +-----+ | | | 5 4 | | | | | \|/ \|/ | | | +-----+ | +----| E |---+ +--+--+ | | | 10 | +--+--+ | D | +-----+
Figure 2: Link-Protecting Alternates Causing Loop on Node Failure
Figure 2: Link-Protecting Alternates Causing Loop on Node Failure
Micro-looping of traffic via the alternates caused when a more extensive failure than planned for occurs can be prevented via selection of only downstream paths as alternates. A micro-loop due to the use of alternates can be avoided by using downstream paths because each succeeding router in the path to the destination must be closer to the destination than its predecessor (according to the topology prior to the failures). Although use of downstream paths ensures that the micro-looping via alternates does not occur, such a restriction can severely limit the coverage of alternates. In Figure 2, S would be able to use N as a downstream alternate, but N could not use S; therefore, N would have no alternate and would discard the traffic, thus avoiding the micro-loop.
Micro-looping of traffic via the alternates caused when a more extensive failure than planned for occurs can be prevented via selection of only downstream paths as alternates. A micro-loop due to the use of alternates can be avoided by using downstream paths because each succeeding router in the path to the destination must be closer to the destination than its predecessor (according to the topology prior to the failures). Although use of downstream paths ensures that the micro-looping via alternates does not occur, such a restriction can severely limit the coverage of alternates. In Figure 2, S would be able to use N as a downstream alternate, but N could not use S; therefore, N would have no alternate and would discard the traffic, thus avoiding the micro-loop.
As shown above, the use of either a node-protecting LFA (described in Section 3.2) or a downstream path provides protection against micro- looping in the event of node failure. There are topologies where there may be either a node-protecting LFA, a downstream path, both, or neither. A node may select either a node-protecting LFA or a downstream path without risk of causing micro-loops in the event of neighbor node failure. While a link-and-node-protecting LFA guarantees protection against either link or node failure, a downstream path provides protection only against a link failure and may or may not provide protection against a node failure depending on the protection available at the downstream node, but it cannot cause a micro-loop. For example, in Figure 2, if S uses N as a downstream path, although no looping can occur, the traffic will not be
As shown above, the use of either a node-protecting LFA (described in Section 3.2) or a downstream path provides protection against micro- looping in the event of node failure. There are topologies where there may be either a node-protecting LFA, a downstream path, both, or neither. A node may select either a node-protecting LFA or a downstream path without risk of causing micro-loops in the event of neighbor node failure. While a link-and-node-protecting LFA guarantees protection against either link or node failure, a downstream path provides protection only against a link failure and may or may not provide protection against a node failure depending on the protection available at the downstream node, but it cannot cause a micro-loop. For example, in Figure 2, if S uses N as a downstream path, although no looping can occur, the traffic will not be
Atlas, et al. Standards Track [Page 6] RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008
Atlas, et al. Standards Track [Page 6] RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008
protected in the event of the failure of node E because N has no viable repair path, and it will simply discard the packet. However, if N had a link-and-node-protecting LFA or downstream path via some other path (not shown), then the repair may succeed.
protected in the event of the failure of node E because N has no viable repair path, and it will simply discard the packet. However, if N had a link-and-node-protecting LFA or downstream path via some other path (not shown), then the repair may succeed.
Since the functionality of link-and-node-protecting LFAs is greater than that of link-protecting downstream paths, a router SHOULD select a link-and-node-protecting LFA over a link-protecting downstream path. If there are any destinations for which a link-and-node- protecting LFA is not available, then by definition the path to all of those destinations from any neighbor of the computing router (S) must be through the node (E) being protected (otherwise there would be a node protecting LFA for that destination). Consequently, if there exists a downstream path to the protected node as destination, then that downstream path may be used for all those destinations for which a link-and-node-protecting LFA is not available; the existence of a downstream path can be determined by a single check of the condition Distance_opt(N, E) < Distance_opt(S, E).
Since the functionality of link-and-node-protecting LFAs is greater than that of link-protecting downstream paths, a router SHOULD select a link-and-node-protecting LFA over a link-protecting downstream path. If there are any destinations for which a link-and-node- protecting LFA is not available, then by definition the path to all of those destinations from any neighbor of the computing router (S) must be through the node (E) being protected (otherwise there would be a node protecting LFA for that destination). Consequently, if there exists a downstream path to the protected node as destination, then that downstream path may be used for all those destinations for which a link-and-node-protecting LFA is not available; the existence of a downstream path can be determined by a single check of the condition Distance_opt(N, E) < Distance_opt(S, E).
It may be desirable to find an alternate that can protect against other correlated failures (of which node failure is a specific instance). In the general case, these are handled by shared risk link groups (SRLGs) where any links in the network can belong to the SRLG. General SRLGs may add unacceptably to the computational complexity of finding a loop-free alternate.
It may be desirable to find an alternate that can protect against other correlated failures (of which node failure is a specific instance). In the general case, these are handled by shared risk link groups (SRLGs) where any links in the network can belong to the SRLG. General SRLGs may add unacceptably to the computational complexity of finding a loop-free alternate.
However, a sub-category of SRLGs is of interest and can be applied only during the selection of an acceptable alternate. This sub- category is to express correlated failures of links that are connected to the same router, for example, if there are multiple logical sub-interfaces on the same physical interface, such as VLANs on an Ethernet interface, if multiple interfaces use the same physical port because of channelization, or if multiple interfaces share a correlated failure because they are on the same line-card. This sub-category of SRLGs will be referred to as local-SRLGs. A local-SRLG has all of its member links with one end connected to the same router. Thus, router S could select a loop-free alternate that does not use a link in the same local-SRLG as the primary next-hop. The failure of local-SRLGs belonging to E can be protected against via node protection, i.e., picking a loop-free node-protecting alternate.
However, a sub-category of SRLGs is of interest and can be applied only during the selection of an acceptable alternate. This sub- category is to express correlated failures of links that are connected to the same router, for example, if there are multiple logical sub-interfaces on the same physical interface, such as VLANs on an Ethernet interface, if multiple interfaces use the same physical port because of channelization, or if multiple interfaces share a correlated failure because they are on the same line-card. This sub-category of SRLGs will be referred to as local-SRLGs. A local-SRLG has all of its member links with one end connected to the same router. Thus, router S could select a loop-free alternate that does not use a link in the same local-SRLG as the primary next-hop. The failure of local-SRLGs belonging to E can be protected against via node protection, i.e., picking a loop-free node-protecting alternate.
Where SRLG protection is provided, it is in the context of the particular OSPF or IS-IS area, whose topology is used in the SPF computations to compute the loop-free alternates. If an SRLG contains links in multiple areas, then separate SRLG-protecting alternates would be required in each area that is traversed by the affected traffic.
Where SRLG protection is provided, it is in the context of the particular OSPF or IS-IS area, whose topology is used in the SPF computations to compute the loop-free alternates. If an SRLG contains links in multiple areas, then separate SRLG-protecting alternates would be required in each area that is traversed by the affected traffic.
Atlas, et al. Standards Track [Page 7] RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008
Atlas, et al. Standards Track [Page 7] RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008
1.2. Requirement Language
1.2. Requirement Language
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].
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].
2. Applicability of Described Mechanisms
2. Applicability of Described Mechanisms
IP Fast Reroute mechanisms described in this memo cover intra-domain routing only, with OSPF [RFC2328] [RFC2740] [RFC5340] or IS-IS [RFC1195] [RFC2966] as the IGP. Specifically, Fast Reroute for BGP inter-domain routing is not part of this specification.
IP Fast Reroute mechanisms described in this memo cover intra-domain routing only, with OSPF [RFC2328] [RFC2740] [RFC5340] or IS-IS [RFC1195] [RFC2966] as the IGP. Specifically, Fast Reroute for BGP inter-domain routing is not part of this specification.
Certain aspects of OSPF inter-area routing behavior explained in Section 6.3 and Appendix A impact the ability of the router calculating the backup next-hops to assess traffic trajectories. In order to avoid micro-looping and ensure required coverage, certain constraints are applied to multi-area OSPF networks:
Certain aspects of OSPF inter-area routing behavior explained in Section 6.3 and Appendix A impact the ability of the router calculating the backup next-hops to assess traffic trajectories. In order to avoid micro-looping and ensure required coverage, certain constraints are applied to multi-area OSPF networks:
a. Loop-free alternates should not be used in the backbone area if
there are any virtual links configured unless, for each transit
area, there is a full mesh of virtual links between all Area
Border Routers (ABRs) in that area. Loop-free alternates may be
used in non-backbone areas regardless of whether there are
virtual links configured.
a. Loop-free alternates should not be used in the backbone area if there are any virtual links configured unless, for each transit area, there is a full mesh of virtual links between all Area Border Routers (ABRs) in that area. Loop-free alternates may be used in non-backbone areas regardless of whether there are virtual links configured.
b. Loop-free alternates should not be used for inter-area routes in
an area that contains more than one alternate ABR [RFC3509].
b. Loop-free alternates should not be used for inter-area routes in an area that contains more than one alternate ABR [RFC3509].
c. Loop-free alternates should not be used for AS External routes or
Autonomous System Border Router (ASBR) routes in a non-backbone
area of a network where there exists an ABR that is announced as
an ASBR in multiple non-backbone areas and there exists another
ABR that is in at least two of the same non-backbone areas.
c. Loop-free alternates should not be used for AS External routes or Autonomous System Border Router (ASBR) routes in a non-backbone area of a network where there exists an ABR that is announced as an ASBR in multiple non-backbone areas and there exists another ABR that is in at least two of the same non-backbone areas.
d. Loop-free alternates should not be used in a non-backbone area of
a network for AS External routes where an AS External prefix is
advertised with the same type of external metric by multiple
ASBRs, which are in different non-backbone areas, with a
forwarding address of 0.0.0.0 or by one or more ASBRs with
forwarding addresses in multiple non-backbone areas when an ABR
exists simultaneously in two or more of those non-backbone areas.
d. Loop-free alternates should not be used in a non-backbone area of a network for AS External routes where an AS External prefix is advertised with the same type of external metric by multiple ASBRs, which are in different non-backbone areas, with a forwarding address of 0.0.0.0 or by one or more ASBRs with forwarding addresses in multiple non-backbone areas when an ABR exists simultaneously in two or more of those non-backbone areas.
Atlas, et al. Standards Track [Page 8] RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008
Atlas, et al. Standards Track [Page 8] RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008
3. Alternate Next-Hop Calculation
3. Alternate Next-Hop Calculation
In addition to the set of primary next-hops obtained through a shortest path tree (SPT) computation that is part of standard link- state routing functionality, routers supporting IP Fast Reroute also calculate a set of backup next-hops that are engaged when a local failure occurs. These backup next-hops are calculated to provide the required type of protection (i.e., link-protecting and/or node- protecting) and to guarantee that when the expected failure occurs, forwarding traffic through them will not result in a loop. Such next-hops are called loop-free alternates or LFAs throughout this specification.
In addition to the set of primary next-hops obtained through a shortest path tree (SPT) computation that is part of standard link- state routing functionality, routers supporting IP Fast Reroute also calculate a set of backup next-hops that are engaged when a local failure occurs. These backup next-hops are calculated to provide the required type of protection (i.e., link-protecting and/or node- protecting) and to guarantee that when the expected failure occurs, forwarding traffic through them will not result in a loop. Such next-hops are called loop-free alternates or LFAs throughout this specification.
In general, to be able to calculate the set of LFAs for a specific destination D, a router needs to know the following basic pieces of information:
In general, to be able to calculate the set of LFAs for a specific destination D, a router needs to know the following basic pieces of information:
o Shortest-path distance from the calculating router to the
destination (Distance_opt(S, D))
o Shortest-path distance from the calculating router to the destination (Distance_opt(S, D))
o Shortest-path distance from the router's IGP neighbors to the
destination (Distance_opt(N, D))
o Shortest-path distance from the router's IGP neighbors to the destination (Distance_opt(N, D))
o Shortest path distance from the router's IGP neighbors to itself
(Distance_opt(N, S))
o Shortest path distance from the router's IGP neighbors to itself (Distance_opt(N, S))
o Distance_opt(S, D) is normally available from the regular SPF
calculation performed by the link-state routing protocols.
Distance_opt(N, D) and Distance_opt(N, S) can be obtained by
performing additional SPF calculations from the perspective of
each IGP neighbor (i.e., considering the neighbor's vertex as the
root of the SPT--called SPT(N) hereafter--rather than the
calculating router's one, called SPT(S)).
o Distance_opt(S, D) is normally available from the regular SPF calculation performed by the link-state routing protocols. Distance_opt(N, D) and Distance_opt(N, S) can be obtained by performing additional SPF calculations from the perspective of each IGP neighbor (i.e., considering the neighbor's vertex as the root of the SPT--called SPT(N) hereafter--rather than the calculating router's one, called SPT(S)).
This specification defines a form of SRLG protection limited to those SRLGs that include a link to which the calculating router is directly connected. Only that set of SRLGs could cause a local failure; the calculating router only computes alternates to handle a local failure. Information about local link SRLG membership is manually configured. Information about remote link SRLG membership may be dynamically obtained using [RFC4205] or [RFC4203]. Define SRLG_local(S) to be the set of SRLGs that include a link to which the calculating router S is directly connected Only SRLG_local(S) is of interest during the calculation, but the calculating router must correctly handle changes to SRLG_local(S) triggered by local link SRLG membership changes.
This specification defines a form of SRLG protection limited to those SRLGs that include a link to which the calculating router is directly connected. Only that set of SRLGs could cause a local failure; the calculating router only computes alternates to handle a local failure. Information about local link SRLG membership is manually configured. Information about remote link SRLG membership may be dynamically obtained using [RFC4205] or [RFC4203]. Define SRLG_local(S) to be the set of SRLGs that include a link to which the calculating router S is directly connected Only SRLG_local(S) is of interest during the calculation, but the calculating router must correctly handle changes to SRLG_local(S) triggered by local link SRLG membership changes.
Atlas, et al. Standards Track [Page 9] RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008
Atlas, et al. Standards Track [Page 9] RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008
In order to choose among all available LFAs that provide required SRLG protection for a given destination, the calculating router needs to track the set of SRLGs in SRLG_local(S) that the path through a specific IGP neighbor involves. To do so, each node D in the network topology is associated with SRLG_set(N, D), which is the set of SRLGs that would be crossed if traffic to D was forwarded through N. To calculate this set, the router initializes SRLG_set(N, N) for each of its IGP neighbors to be empty. During the SPT(N) calculation, when a new vertex V is added to the SPT, its SRLG_set(N, V) is set to the union of SRLG sets associated with its parents, and the SRLG sets in SRLG_local(S) that are associated with the links from V's parents to V. The union of the set of SRLGs associated with a candidate alternate next-hop and the SRLG_set(N, D) for the neighbor reached via that candidate next-hop is used to determine SRLG protection.
In order to choose among all available LFAs that provide required SRLG protection for a given destination, the calculating router needs to track the set of SRLGs in SRLG_local(S) that the path through a specific IGP neighbor involves. To do so, each node D in the network topology is associated with SRLG_set(N, D), which is the set of SRLGs that would be crossed if traffic to D was forwarded through N. To calculate this set, the router initializes SRLG_set(N, N) for each of its IGP neighbors to be empty. During the SPT(N) calculation, when a new vertex V is added to the SPT, its SRLG_set(N, V) is set to the union of SRLG sets associated with its parents, and the SRLG sets in SRLG_local(S) that are associated with the links from V's parents to V. The union of the set of SRLGs associated with a candidate alternate next-hop and the SRLG_set(N, D) for the neighbor reached via that candidate next-hop is used to determine SRLG protection.
The following sections provide information required for calculation of LFAs. Sections 3.1 through 3.4 define different types of LFA conditions. Section 3.5 describes constraints imposed by the IS-IS overload and OSPF stub router functionality. Section 3.6 defines the summarized algorithm for LFA calculation using the definitions in the previous sections.
The following sections provide information required for calculation of LFAs. Sections 3.1 through 3.4 define different types of LFA conditions. Section 3.5 describes constraints imposed by the IS-IS overload and OSPF stub router functionality. Section 3.6 defines the summarized algorithm for LFA calculation using the definitions in the previous sections.
3.1. Basic Loop-Free Condition
3.1. Basic Loop-Free Condition
Alternate next hops used by implementations following this specification MUST conform to at least the loop-freeness condition stated above in Inequality 1. This condition guarantees that forwarding traffic to an LFA will not result in a loop after a link failure.
Alternate next hops used by implementations following this specification MUST conform to at least the loop-freeness condition stated above in Inequality 1. This condition guarantees that forwarding traffic to an LFA will not result in a loop after a link failure.
Further conditions may be applied when determining link-protecting and/or node-protecting alternate next-hops as described in Sections 3.2 and 3.3.
Further conditions may be applied when determining link-protecting and/or node-protecting alternate next-hops as described in Sections 3.2 and 3.3.
3.2. Node-Protecting Alternate Next-Hops
3.2. Node-Protecting Alternate Next-Hops
For an alternate next-hop N to protect against node failure of a primary neighbor E for destination D, N must be loop-free with respect to both E and D. In other words, N's path to D must not go through E. This is the case if Inequality 3 is true, where N is the neighbor providing a loop-free alternate.
For an alternate next-hop N to protect against node failure of a primary neighbor E for destination D, N must be loop-free with respect to both E and D. In other words, N's path to D must not go through E. This is the case if Inequality 3 is true, where N is the neighbor providing a loop-free alternate.
Distance_opt(N, D) < Distance_opt(N, E) + Distance_opt(E, D)
Distance_opt(N, D) < Distance_opt(N, E) + Distance_opt(E, D)
Inequality 3: Criteria for a Node-Protecting Loop-Free Alternate
Inequality 3: Criteria for a Node-Protecting Loop-Free Alternate
Atlas, et al. Standards Track [Page 10] RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008
Atlas, et al. Standards Track [Page 10] RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008
If Distance_opt(N,D) = Distance_opt(N, E) + Distance_opt(E, D), it is possible that N has equal-cost paths and one of those could provide protection against E's node failure. However, it is equally possible that one of N's paths goes through E, and the calculating router has no way to influence N's decision to use it. Therefore, it SHOULD be assumed that an alternate next-hop does not offer node protection if Inequality 3 is not met.
If Distance_opt(N,D) = Distance_opt(N, E) + Distance_opt(E, D), it is possible that N has equal-cost paths and one of those could provide protection against E's node failure. However, it is equally possible that one of N's paths goes through E, and the calculating router has no way to influence N's decision to use it. Therefore, it SHOULD be assumed that an alternate next-hop does not offer node protection if Inequality 3 is not met.
3.3. Broadcast and Non-Broadcast Multi-Access (NBMA) Links
3.3. Broadcast and Non-Broadcast Multi-Access (NBMA) Links
Verification of the link-protection property of a next-hop in the case of a broadcast link is more elaborate than for a point-to-point link. This is because a broadcast link is represented as a pseudo- node with zero-cost links connecting it to other nodes.
Verification of the link-protection property of a next-hop in the case of a broadcast link is more elaborate than for a point-to-point link. This is because a broadcast link is represented as a pseudo- node with zero-cost links connecting it to other nodes.
Because failure of an interface attached to a broadcast segment may mean loss of connectivity of the whole segment, the condition described for broadcast link protection is pessimistic and requires that the alternate is loop-free with regard to the pseudo-node. Consider the example in Figure 3.
Because failure of an interface attached to a broadcast segment may mean loss of connectivity of the whole segment, the condition described for broadcast link protection is pessimistic and requires that the alternate is loop-free with regard to the pseudo-node. Consider the example in Figure 3.
+-----+ 15
| S |--------
+-----+ |
| 5 |
| |
| 0 |
/----\ 0 5 +-----+
| PN |-----| N |
\----/ +-----+
| 0 |
| | 8
| 5 |
+-----+ 5 +-----+
| E |----| D |
+-----+ +-----+
+-----+ 15 | S |-------- +-----+ | | 5 | | | | 0 | /----\ 0 5 +-----+ | PN |-----| N | \----/ +-----+ | 0 | | | 8 | 5 | +-----+ 5 +-----+ | E |----| D | +-----+ +-----+
Figure 3: Loop-Free Alternate That Is Link-Protecting
Figure 3: Loop-Free Alternate That Is Link-Protecting
In Figure 3, N offers a loop-free alternate that is link-protecting. If the primary next-hop uses a broadcast link, then an alternate SHOULD be loop-free with respect to that link's pseudo-node (PN) to provide link protection. This requirement is described in Inequality 4 below.
In Figure 3, N offers a loop-free alternate that is link-protecting. If the primary next-hop uses a broadcast link, then an alternate SHOULD be loop-free with respect to that link's pseudo-node (PN) to provide link protection. This requirement is described in Inequality 4 below.
D_opt(N, D) < D_opt(N, PN) + D_opt(PN, D)
D_opt(N, D) < D_opt(N, PN) + D_opt(PN, D)
Inequality 4: Loop-Free Link-Protecting Criterion for Broadcast Links
Inequality 4: Loop-Free Link-Protecting Criterion for Broadcast Links
Atlas, et al. Standards Track [Page 11] RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008
Atlas, et al. Standards Track [Page 11] RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008
Because the shortest path from the pseudo-node goes through E, if a loop-free alternate from a neighbor N is node-protecting, the alternate will also be link-protecting unless the router S can only reach the alternate neighbor N via the same pseudo-node. Since this is the only case for which a node-protecting LFA is not link- protecting, this implies that for point-to-point interfaces, an LFA that is node-protecting is always link-protecting. Because S can direct the traffic away from the shortest path to use the alternate N, traffic might pass through the same broadcast link as it would when S sent the traffic to the primary E. Thus, an LFA from N that is node-protecting is not automatically link-protecting for a broadcast or NBMA link.
Because the shortest path from the pseudo-node goes through E, if a loop-free alternate from a neighbor N is node-protecting, the alternate will also be link-protecting unless the router S can only reach the alternate neighbor N via the same pseudo-node. Since this is the only case for which a node-protecting LFA is not link- protecting, this implies that for point-to-point interfaces, an LFA that is node-protecting is always link-protecting. Because S can direct the traffic away from the shortest path to use the alternate N, traffic might pass through the same broadcast link as it would when S sent the traffic to the primary E. Thus, an LFA from N that is node-protecting is not automatically link-protecting for a broadcast or NBMA link.
To obtain link protection, it is necessary both that the path from the selected alternate next-hop does not traverse the link of interest and that the link used from S to reach that alternate next- hop is not the link of interest. The latter can only occur with non- point-to-point links. Therefore, if the primary next-hop is across a broadcast or NBMA interface, it is necessary to consider link protection during the alternate selection. To clarify, consider the topology in Figure 3. For N to provide link protection, it is first necessary that N's shortest path to D does not traverse the pseudo- node PN. Second, it is necessary that the alternate next-hop selected by S does not traverse PN. In this example, S's shortest path to N is via the pseudo-node. Thus, to obtain link protection, S must find a next-hop to N (the point-to-point link from S to N in this example) that avoids the pseudo-node PN.
To obtain link protection, it is necessary both that the path from the selected alternate next-hop does not traverse the link of interest and that the link used from S to reach that alternate next- hop is not the link of interest. The latter can only occur with non- point-to-point links. Therefore, if the primary next-hop is across a broadcast or NBMA interface, it is necessary to consider link protection during the alternate selection. To clarify, consider the topology in Figure 3. For N to provide link protection, it is first necessary that N's shortest path to D does not traverse the pseudo- node PN. Second, it is necessary that the alternate next-hop selected by S does not traverse PN. In this example, S's shortest path to N is via the pseudo-node. Thus, to obtain link protection, S must find a next-hop to N (the point-to-point link from S to N in this example) that avoids the pseudo-node PN.
Similar consideration of the link from S to the selected alternate next-hop as well as the path from the selected alternate next-hop is also necessary for SRLG protection. S's shortest path to the selected neighbor N may not be acceptable as an alternate next-hop to provide SRLG protection, even if the path from N to D can provide SRLG protection.
Similar consideration of the link from S to the selected alternate next-hop as well as the path from the selected alternate next-hop is also necessary for SRLG protection. S's shortest path to the selected neighbor N may not be acceptable as an alternate next-hop to provide SRLG protection, even if the path from N to D can provide SRLG protection.
3.4. ECMP and Alternates
3.4. ECMP and Alternates
With Equal-Cost Multi-Path (ECMP), a prefix may have multiple primary next-hops that are used to forward traffic. When a particular primary next-hop fails, alternate next-hops should be used to preserve the traffic. These alternate next-hops may themselves also be primary next-hops, but need not be. Other primary next-hops are not guaranteed to provide protection against the failure scenarios of concern.
With Equal-Cost Multi-Path (ECMP), a prefix may have multiple primary next-hops that are used to forward traffic. When a particular primary next-hop fails, alternate next-hops should be used to preserve the traffic. These alternate next-hops may themselves also be primary next-hops, but need not be. Other primary next-hops are not guaranteed to provide protection against the failure scenarios of concern.
Atlas, et al. Standards Track [Page 12] RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008
Atlas, et al. Standards Track [Page 12] RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008
20 L1 L3 3
[ N ]----[ S ]--------[ E3 ]
| | |
| 5 | L2 |
20 | | |
| --------- | 2
| 5 | | 5 |
| [ E1 ] [ E2 ]-----|
| | |
| 10 | 10 |
|---[ A ] [ B ]
| |
2 |--[ D ]-| 2
20 L1 L3 3 [ N ]----[ S ]--------[ E3 ] | | | | 5 | L2 | 20 | | | | --------- | 2 | 5 | | 5 | | [ E1 ] [ E2 ]-----| | | | | 10 | 10 | |---[ A ] [ B ] | | 2 |--[ D ]-| 2
Figure 4: ECMP Where Primary Next-Hops Provide Limited Protection
Figure 4: ECMP Where Primary Next-Hops Provide Limited Protection
In Figure 4 S has three primary next-hops to reach D; these are L2 to E1, L2 to E2, and L3 to E3. The primary next-hop L2 to E1 can obtain link and node protection from L3 to E3, which is one of the other primary next-hops; L2 to E1 cannot obtain link protection from the other primary next-hop L2 to E2. Similarly, the primary next-hop L2 to E2 can only get node protection from L2 to E1 and can only get link protection from L3 to E3. The third primary next-hop L3 to E3 can obtain link and node protection from L2 to E1 and from L2 to E2. It is possible for both the primary next-hop L2 to E2 and the primary next-hop L2 to E1 to obtain an alternate next-hop that provides both link and node protection by using L1.
In Figure 4 S has three primary next-hops to reach D; these are L2 to E1, L2 to E2, and L3 to E3. The primary next-hop L2 to E1 can obtain link and node protection from L3 to E3, which is one of the other primary next-hops; L2 to E1 cannot obtain link protection from the other primary next-hop L2 to E2. Similarly, the primary next-hop L2 to E2 can only get node protection from L2 to E1 and can only get link protection from L3 to E3. The third primary next-hop L3 to E3 can obtain link and node protection from L2 to E1 and from L2 to E2. It is possible for both the primary next-hop L2 to E2 and the primary next-hop L2 to E1 to obtain an alternate next-hop that provides both link and node protection by using L1.
Alternate next-hops are determined for each primary next-hop separately. As with alternate selection in the non-ECMP case, these alternate next-hops should maximize the coverage of the failure cases.
Alternate next-hops are determined for each primary next-hop separately. As with alternate selection in the non-ECMP case, these alternate next-hops should maximize the coverage of the failure cases.
3.5. Interactions with IS-IS Overload, RFC 3137, and Costed Out Links
3.5. Interactions with IS-IS Overload, RFC 3137, and Costed Out Links
As described in [RFC3137], there are cases where it is desirable not to have a router used as a transit node. For those cases, it is also desirable not to have the router used on an alternate path.
As described in [RFC3137], there are cases where it is desirable not to have a router used as a transit node. For those cases, it is also desirable not to have the router used on an alternate path.
For computing an alternate, a router MUST NOT use an alternate next- hop that is along a link whose cost or reverse cost is LSInfinity (for OSPF) or the maximum cost (for IS-IS) or that has the overload bit set (for IS-IS). For a broadcast link, the reverse cost associated with a potential alternate next-hop is the cost towards the pseudo-node advertised by the next-hop router. For point-to- point links, if a specific link from the next-hop router cannot be associated with a particular link, then the reverse cost considered is that of the minimum cost link from the next-hop router back to S.
For computing an alternate, a router MUST NOT use an alternate next- hop that is along a link whose cost or reverse cost is LSInfinity (for OSPF) or the maximum cost (for IS-IS) or that has the overload bit set (for IS-IS). For a broadcast link, the reverse cost associated with a potential alternate next-hop is the cost towards the pseudo-node advertised by the next-hop router. For point-to- point links, if a specific link from the next-hop router cannot be associated with a particular link, then the reverse cost considered is that of the minimum cost link from the next-hop router back to S.
Atlas, et al. Standards Track [Page 13] RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008
Atlas, et al. Standards Track [Page 13] RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008
In the case of OSPF, if all links from router S to a neighbor N_i have a reverse cost of LSInfinity, then router S MUST NOT use N_i as an alternate.
In the case of OSPF, if all links from router S to a neighbor N_i have a reverse cost of LSInfinity, then router S MUST NOT use N_i as an alternate.
Similarly in the case of IS-IS, if N_i has the overload bit set, then S MUST NOT consider using N_i as an alternate.
Similarly in the case of IS-IS, if N_i has the overload bit set, then S MUST NOT consider using N_i as an alternate.
This preserves the desired behavior of diverting traffic away from a router that is following [RFC3137], and it also preserves the desired behavior when an operator sets the cost of a link to LSInfinity for maintenance that is not permitting traffic across that link unless there is no other path.
This preserves the desired behavior of diverting traffic away from a router that is following [RFC3137], and it also preserves the desired behavior when an operator sets the cost of a link to LSInfinity for maintenance that is not permitting traffic across that link unless there is no other path.
If a link or router that is costed out was the only possible alternate to protect traffic from a particular router S to a particular destination, then there should be no alternate provided for protection.
If a link or router that is costed out was the only possible alternate to protect traffic from a particular router S to a particular destination, then there should be no alternate provided for protection.
3.5.1. Interactions with IS-IS Link Attributes
3.5.1. Interactions with IS-IS Link Attributes
[RFC5029] describes several flags whose interactions with LFAs need to be defined. A router SHOULD NOT specify the "local protection available" flag as a result of having LFAs. A router SHOULD NOT use an alternate next-hop that is along a link for which the link has been advertised with the attribute "link excluded from local protection path" or with the attribute "local maintenance required".
[RFC5029] describes several flags whose interactions with LFAs need to be defined. A router SHOULD NOT specify the "local protection available" flag as a result of having LFAs. A router SHOULD NOT use an alternate next-hop that is along a link for which the link has been advertised with the attribute "link excluded from local protection path" or with the attribute "local maintenance required".
3.6. Selection Procedure
3.6. Selection Procedure
A router supporting this specification SHOULD attempt to select at least one loop-free alternate next-hop for each primary next-hop used for a given prefix. A router MAY decide to not use an available loop-free alternate next-hop. A reason for such a decision might be that the loop-free alternate next-hop does not provide protection for the failure scenario of interest.
A router supporting this specification SHOULD attempt to select at least one loop-free alternate next-hop for each primary next-hop used for a given prefix. A router MAY decide to not use an available loop-free alternate next-hop. A reason for such a decision might be that the loop-free alternate next-hop does not provide protection for the failure scenario of interest.
The alternate selection should maximize the coverage of the failure cases.
The alternate selection should maximize the coverage of the failure cases.
When calculating alternate next-hops, the calculating router S applies the following rules.
When calculating alternate next-hops, the calculating router S applies the following rules.
1. S SHOULD select a loop-free node-protecting alternate next-hop,
if one is available. If no loop-free node-protecting alternate
is available, then S MAY select a loop-free link-protecting
alternate.
1. S SHOULD select a loop-free node-protecting alternate next-hop, if one is available. If no loop-free node-protecting alternate is available, then S MAY select a loop-free link-protecting alternate.
Atlas, et al. Standards Track [Page 14] RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008
Atlas, et al. Standards Track [Page 14] RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008
2. If S has a choice between a loop-free link-and-node-protecting
alternate and a loop-free node-protecting alternate that is not
link-protecting, S SHOULD select a loop-free link-and-node-
protecting alternate. This can occur as explained in
Section 3.3.
2. If S has a choice between a loop-free link-and-node-protecting alternate and a loop-free node-protecting alternate that is not link-protecting, S SHOULD select a loop-free link-and-node- protecting alternate. This can occur as explained in Section 3.3.
3. If S has multiple primary next-hops, then S SHOULD select as a
loop-free alternate either one of the other primary next-hops or
a loop-free node-protecting alternate if available. If no loop-
free node-protecting alternate is available and no other primary
next-hop can provide link-protection, then S SHOULD select a
loop-free link-protecting alternate.
3. If S has multiple primary next-hops, then S SHOULD select as a loop-free alternate either one of the other primary next-hops or a loop-free node-protecting alternate if available. If no loop- free node-protecting alternate is available and no other primary next-hop can provide link-protection, then S SHOULD select a loop-free link-protecting alternate.
4. Implementations SHOULD support a mode where other primary next-
hops satisfying the basic loop-free condition and providing at
least link or node protection are preferred over any non-primary
alternates. This mode is provided to allow the administrator to
preserve traffic patterns based on regular ECMP behavior.
4. Implementations SHOULD support a mode where other primary next- hops satisfying the basic loop-free condition and providing at least link or node protection are preferred over any non-primary alternates. This mode is provided to allow the administrator to preserve traffic patterns based on regular ECMP behavior.
5. Implementations considering SRLGs MAY use SRLG protection to
determine that a node-protecting or link-protecting alternate is
not available for use.
5. Implementations considering SRLGs MAY use SRLG protection to determine that a node-protecting or link-protecting alternate is not available for use.
Following the above rules maximizes the level of protection and use of primary (ECMP) next-hops.
Following the above rules maximizes the level of protection and use of primary (ECMP) next-hops.
Each next-hop is associated with a set of non-mutually-exclusive characteristics based on whether it is used as a primary next-hop to a particular destination D, and the type of protection it can provide relative to a specific primary next-hop E:
Each next-hop is associated with a set of non-mutually-exclusive characteristics based on whether it is used as a primary next-hop to a particular destination D, and the type of protection it can provide relative to a specific primary next-hop E:
Primary Path - The next-hop is used by S as primary.
Primary Path - The next-hop is used by S as primary.
Loop-Free Node-Protecting Alternate - This next-hop satisfies
Inequality 1 and Inequality 3. The path avoids S, S's primary
neighbor E, and the link from S to E.
Loop-Free Node-Protecting Alternate - This next-hop satisfies Inequality 1 and Inequality 3. The path avoids S, S's primary neighbor E, and the link from S to E.
Loop-Free Link-Protecting Alternate - This next-hop satisfies
Inequality 1 but not Inequality 3. If the primary next-hop uses a
broadcast link, then this next-hop satisfies Inequality 4.
Loop-Free Link-Protecting Alternate - This next-hop satisfies Inequality 1 but not Inequality 3. If the primary next-hop uses a broadcast link, then this next-hop satisfies Inequality 4.
An alternate path may also provide none, some, or complete SRLG protection as well as node and link or link protection. For instance, a link may belong to two SRLGs G1 and G2. The alternate path might avoid other links in G1 but not G2, in which case the alternate would only provide partial SRLG protection.
An alternate path may also provide none, some, or complete SRLG protection as well as node and link or link protection. For instance, a link may belong to two SRLGs G1 and G2. The alternate path might avoid other links in G1 but not G2, in which case the alternate would only provide partial SRLG protection.
Atlas, et al. Standards Track [Page 15] RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008
Atlas, et al. Standards Track [Page 15] RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008
Below is an algorithm that can be used to calculate loop-free alternate next-hops. The algorithm is given for informational purposes, and implementations are free to use any other algorithm as long as it satisfies the rules described above.
Below is an algorithm that can be used to calculate loop-free alternate next-hops. The algorithm is given for informational purposes, and implementations are free to use any other algorithm as long as it satisfies the rules described above.
The following procedure describes how to select an alternate next- hop. The procedure is described to determine alternate next-hops to use to reach each router in the topology. Prefixes that are advertised by a single router can use the alternate next-hop computed for the router to which they are attached. The same procedure can be used to reach a prefix that is advertised by more than one router when the logical topological transformation described in Section 6.1 is used.
The following procedure describes how to select an alternate next- hop. The procedure is described to determine alternate next-hops to use to reach each router in the topology. Prefixes that are advertised by a single router can use the alternate next-hop computed for the router to which they are attached. The same procedure can be used to reach a prefix that is advertised by more than one router when the logical topological transformation described in Section 6.1 is used.
S is the computing router. S has neighbors N_1 to N_j. A candidate next-hop is indicated by (outgoing link, neighbor) and the outgoing link must be bidirectionally connected, as is determined by the IGP. The candidate next-hops of S are enumerated as H_1 through H_k. Recall that S may have multiple next-hops over different interfaces to a neighbor. H_i.link refers to the outgoing link of that next-hop and H_i.neighbor refers to the neighbor of that next-hop.
S is the computing router. S has neighbors N_1 to N_j. A candidate next-hop is indicated by (outgoing link, neighbor) and the outgoing link must be bidirectionally connected, as is determined by the IGP. The candidate next-hops of S are enumerated as H_1 through H_k. Recall that S may have multiple next-hops over different interfaces to a neighbor. H_i.link refers to the outgoing link of that next-hop and H_i.neighbor refers to the neighbor of that next-hop.
For a particular destination router D, let S have already computed D_opt(S, D), and for each neighbor N_i, D_opt(N_i, D), D_opt(N_i, S), and D_opt(N_i, N_j), the distance from N_i to each other neighbor N_j, and the set of SRLGs traversed by the path D_opt(N_i, D). S should follow the below procedure for every primary next-hop selected to reach D. This set of primary next-hops is represented P_1 to P_p. This procedure finds the alternate next-hop(s) for P_i.
For a particular destination router D, let S have already computed D_opt(S, D), and for each neighbor N_i, D_opt(N_i, D), D_opt(N_i, S), and D_opt(N_i, N_j), the distance from N_i to each other neighbor N_j, and the set of SRLGs traversed by the path D_opt(N_i, D). S should follow the below procedure for every primary next-hop selected to reach D. This set of primary next-hops is represented P_1 to P_p. This procedure finds the alternate next-hop(s) for P_i.
First, initialize the alternate information for P_i as follows:
First, initialize the alternate information for P_i as follows:
P_i.alt_next_hops = {}
P_i.alt_type = NONE
P_i.alt_link-protect = FALSE
P_i.alt_node-protect = FALSE
P_i.alt_srlg-protect = {}
P_i.alt_next_hops = {} P_i.alt_type = NONE P_i.alt_link-protect = FALSE P_i.alt_node-protect = FALSE P_i.alt_srlg-protect = {}
For each candidate next-hop H_h,
For each candidate next-hop H_h,
1. Initialize variables as follows:
1. Initialize variables as follows:
cand_type = NONE
cand_link-protect = FALSE
cand_node-protect = FALSE
cand_srlg-protect = {}
cand_type = NONE cand_link-protect = FALSE cand_node-protect = FALSE cand_srlg-protect = {}
Atlas, et al. Standards Track [Page 16] RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008
Atlas, et al. Standards Track [Page 16] RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008
2. If H_h is P_i, skip it and continue to the next candidate next-
hop.
2. If H_h is P_i, skip it and continue to the next candidate next- hop.
3. If H_h.link is administratively allowed to be used as an
alternate,
3. If H_h.link is administratively allowed to be used as an alternate,
and the cost of H_h.link is less than the maximum,
and the reverse cost of H_h is less than the maximum,
and H_h.neighbor is not overloaded (for IS-IS),
and H_h.link is bidirectional,
and the cost of H_h.link is less than the maximum, and the reverse cost of H_h is less than the maximum, and H_h.neighbor is not overloaded (for IS-IS), and H_h.link is bidirectional,
then H_h can be considered as an alternate. Otherwise, skip it
and continue to the next candidate next-hop.
then H_h can be considered as an alternate. Otherwise, skip it and continue to the next candidate next-hop.
4. If D_opt( H_h.neighbor, D) >= D_opt( H_h.neighbor, S) + D_opt(S,
D), then H_h is not loop-free. Skip it and continue to the next
candidate next-hop.
4. If D_opt( H_h.neighbor, D) >= D_opt( H_h.neighbor, S) + D_opt(S, D), then H_h is not loop-free. Skip it and continue to the next candidate next-hop.
5. cand_type = LOOP-FREE.
5. cand_type = LOOP-FREE.
6. If H_h is a primary next-hop, set cand_type to PRIMARY.
6. If H_h is a primary next-hop, set cand_type to PRIMARY.
7. If H_h.link is not P_i.link, set cand_link-protect to TRUE.
7. If H_h.link is not P_i.link, set cand_link-protect to TRUE.
8. If D_opt(H_h.neighbor, D) < D_opt(H_h.neighbor, P_i.neighbor) +
D_opt(P_i.neighbor, D), set cand_node-protect to TRUE.
8. If D_opt(H_h.neighbor, D) < D_opt(H_h.neighbor, P_i.neighbor) + D_opt(P_i.neighbor, D), set cand_node-protect to TRUE.
9. If the router considers SRLGs, then set the cand_srlg-protect to
the set of SRLGs traversed on the path from S via P_i.link to
P_i.neighbor. Remove the set of SRLGs to which H_h belongs from
cand_srlg-protect. Remove from cand_srlg-protect the set of
SRLGs traversed on the path from H_h.neighbor to D. Now
cand_srlg-protect holds the set of SRLGs to which P_i belongs
and that are not traversed on the path from S via H_h to D.
9. If the router considers SRLGs, then set the cand_srlg-protect to the set of SRLGs traversed on the path from S via P_i.link to P_i.neighbor. Remove the set of SRLGs to which H_h belongs from cand_srlg-protect. Remove from cand_srlg-protect the set of SRLGs traversed on the path from H_h.neighbor to D. Now cand_srlg-protect holds the set of SRLGs to which P_i belongs and that are not traversed on the path from S via H_h to D.
10. If cand_type is PRIMARY, the router prefers other primary next-
hops for use as the alternate, and the P_i.alt_type is not
PRIMARY, goto Step 20.
10. If cand_type is PRIMARY, the router prefers other primary next- hops for use as the alternate, and the P_i.alt_type is not PRIMARY, goto Step 20.
11. If cand_type is not PRIMARY, P_i.alt_type is PRIMARY, and the
router prefers other primary next-hops for use as the alternate,
then continue to the next candidate next-hop
11. If cand_type is not PRIMARY, P_i.alt_type is PRIMARY, and the router prefers other primary next-hops for use as the alternate, then continue to the next candidate next-hop
12. If cand_node-protect is TRUE and P_i.alt_node-protect is FALSE,
goto Paragraph 20.
12. If cand_node-protect is TRUE and P_i.alt_node-protect is FALSE, goto Paragraph 20.
13. If cand_link-protect is TRUE and P_i.alt_link-protect is FALSE,
goto Step 20.
13. If cand_link-protect is TRUE and P_i.alt_link-protect is FALSE, goto Step 20.
Atlas, et al. Standards Track [Page 17] RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008
Atlas, et al. Standards Track [Page 17] RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008
14. If cand_srlg-protect has a better set of SRLGs than
P_i.alt_srlg-protect, goto Step 20.
14. If cand_srlg-protect has a better set of SRLGs than P_i.alt_srlg-protect, goto Step 20.
15. If cand_srlg-protect is different from P_i.alt_srlg-protect,
then select between H_h and P_i.alt_next_hops based upon
distance, IP addresses, or any router-local tie-breaker. If H_h
is preferred, then goto Step 20. If P_i.alt_next_hops is
preferred, skip H_h and continue to the next candidate next-hop.
15. If cand_srlg-protect is different from P_i.alt_srlg-protect, then select between H_h and P_i.alt_next_hops based upon distance, IP addresses, or any router-local tie-breaker. If H_h is preferred, then goto Step 20. If P_i.alt_next_hops is preferred, skip H_h and continue to the next candidate next-hop.
16. If D_opt(H_h.neighbor, D) < D_opt(P_i.neighbor, D) and
D_opt(P_i.alt_next_hops, D) >= D_opt(P_i.neighbor, D), then H_h
is a downstream alternate and P_i.alt_next_hops is simply an
LFA. Prefer H_h and goto Step 20.
16. If D_opt(H_h.neighbor, D) < D_opt(P_i.neighbor, D) and D_opt(P_i.alt_next_hops, D) >= D_opt(P_i.neighbor, D), then H_h is a downstream alternate and P_i.alt_next_hops is simply an LFA. Prefer H_h and goto Step 20.
17. Based upon the alternate types, the alternate distances, IP
addresses, or other tie-breakers, decide if H_h is preferred to
P_i.alt_next_hops. If so, goto Step 20.
17. Based upon the alternate types, the alternate distances, IP addresses, or other tie-breakers, decide if H_h is preferred to P_i.alt_next_hops. If so, goto Step 20.
18. Decide if P_i.alt_next_hops is preferred to H_h. If so, then
skip H_h and continue to the next candidate next-hop.
18. Decide if P_i.alt_next_hops is preferred to H_h. If so, then skip H_h and continue to the next candidate next-hop.
19. Add H_h into P_i.alt_next_hops. Set P_i.alt_type to the better
type of H_h.alt_type and P_i.alt_type. Continue to the next
candidate next-hop.
19. Add H_h into P_i.alt_next_hops. Set P_i.alt_type to the better type of H_h.alt_type and P_i.alt_type. Continue to the next candidate next-hop.
20. Replace the P_i alternate next-hop set with H_h as follows:
20. Replace the P_i alternate next-hop set with H_h as follows:
P_i.alt_next_hops = {H_h}
P_i.alt_type = cand_type
P_i.alt_link-protect = cand_link-protect
P_i.alt_node-protect = cand_node-protect
P_i.alt_srlg-protect = cand_srlg-protect
P_i.alt_next_hops = {H_h} P_i.alt_type = cand_type P_i.alt_link-protect = cand_link-protect P_i.alt_node-protect = cand_node-protect P_i.alt_srlg-protect = cand_srlg-protect
Continue to the next candidate next-hop.
Continue to the next candidate next-hop.
3.7. LFA Types and Trade-Offs
3.7. LFA Types and Trade-Offs
LFAs can provide different amounts of protection, and the decision about which type to prefer is dependent upon network topology and other techniques in use in the network. This section describes the different protection levels and the trade-offs associated with each.
LFAs can provide different amounts of protection, and the decision about which type to prefer is dependent upon network topology and other techniques in use in the network. This section describes the different protection levels and the trade-offs associated with each.
1. Primary Next-hop: When there are equal-cost primary next-hops,
using one as an alternate is guaranteed not to cause micro-loops
involving S. Traffic flows across the paths that the network
will converge to, but congestion may be experienced on the
primary paths since traffic is sent across fewer. All primary
next-hops are downstream paths.
1. Primary Next-hop: When there are equal-cost primary next-hops, using one as an alternate is guaranteed not to cause micro-loops involving S. Traffic flows across the paths that the network will converge to, but congestion may be experienced on the primary paths since traffic is sent across fewer. All primary next-hops are downstream paths.
Atlas, et al. Standards Track [Page 18] RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008
Atlas, et al. Standards Track [Page 18] RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008
2. Downstream Paths: A downstream path, unlike an LFA, is guaranteed
not to cause a micro-loop involving S regardless of the actual
failure detected. However, the expected coverage of such
alternates in a network is expected to be poor. All downstream
paths are LFAs.
2. Downstream Paths: A downstream path, unlike an LFA, is guaranteed not to cause a micro-loop involving S regardless of the actual failure detected. However, the expected coverage of such alternates in a network is expected to be poor. All downstream paths are LFAs.
3. LFA: An LFA can have good coverage of a network, depending on
topology. However, it is possible to get micro-loops involving S
if an unprotected failure occurs (e.g., a node fails when the LFA
only was link-protecting).
3. LFA: An LFA can have good coverage of a network, depending on topology. However, it is possible to get micro-loops involving S if an unprotected failure occurs (e.g., a node fails when the LFA only was link-protecting).
The different types of protection are abbreviated as LP (link- protecting), NP (node-protecting), and SP (SRLG-protecting).
The different types of protection are abbreviated as LP (link- protecting), NP (node-protecting), and SP (SRLG-protecting).
a. LP, NP, and SP: If such an alternate exists, it gives protection
against all failures.
a. LP, NP, and SP: If such an alternate exists, it gives protection against all failures.
b. LP and NP only: Many networks may handle SRLG failures via
another method or may focus on node and link failures as being
more common.
b. LP and NP only: Many networks may handle SRLG failures via another method or may focus on node and link failures as being more common.
c. LP only: A network may handle node failures via a high-
availability technique and be concerned primarily about
protecting the more common link failure case.
c. LP only: A network may handle node failures via a high- availability technique and be concerned primarily about protecting the more common link failure case.
d. NP only: These only exist on interfaces that aren't point-to-
point. If link protection is handled in a different layer, then
an NP alternate may be acceptable.
d. NP only: These only exist on interfaces that aren't point-to- point. If link protection is handled in a different layer, then an NP alternate may be acceptable.
3.8. A Simplification: Per-Next-Hop LFAs
3.8. A Simplification: Per-Next-Hop LFAs
It is possible to simplify the computation and use of LFAs when solely link protection is desired by considering and computing only one link-protecting LFA for each next-hop connected to the router. All prefixes that use that next-hop as a primary will use the LFA computed for that next-hop as its LFA.
It is possible to simplify the computation and use of LFAs when solely link protection is desired by considering and computing only one link-protecting LFA for each next-hop connected to the router. All prefixes that use that next-hop as a primary will use the LFA computed for that next-hop as its LFA.
Even a prefix with multiple primary next-hops will have each primary next-hop protected individually by the primary next-hop's associated LFA. That associated LFA might or might not be another of the primary next-hops of the prefix.
Even a prefix with multiple primary next-hops will have each primary next-hop protected individually by the primary next-hop's associated LFA. That associated LFA might or might not be another of the primary next-hops of the prefix.
This simplification may reduce coverage in a network. In addition to limiting protection for multi-homed prefixes (see Section 6.1), the computation per next-hop may also not find an LFA when one could be found for some of the prefixes that use that next-hop.
This simplification may reduce coverage in a network. In addition to limiting protection for multi-homed prefixes (see Section 6.1), the computation per next-hop may also not find an LFA when one could be found for some of the prefixes that use that next-hop.
Atlas, et al. Standards Track [Page 19] RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008
Atlas, et al. Standards Track [Page 19] RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008
For example, consider Figure 4 where S has three ECMP next-hops, E1, E2, and E3 to reach D. For the prefix D, E3 can give link protection for the next-hops E1 and E2; E1 and E2 can give link protection for the next-hops E3. However, if one uses this simplification to compute LFAs for E1, E2, and E3 individually, there is no link- protecting LFA for E1. E3 and E2 can protect each other.
For example, consider Figure 4 where S has three ECMP next-hops, E1, E2, and E3 to reach D. For the prefix D, E3 can give link protection for the next-hops E1 and E2; E1 and E2 can give link protection for the next-hops E3. However, if one uses this simplification to compute LFAs for E1, E2, and E3 individually, there is no link- protecting LFA for E1. E3 and E2 can protect each other.
4. Using an Alternate
4. Using an Alternate
If an alternate next-hop is available, the router redirects traffic to the alternate next-hop in case of a primary next-hop failure as follows.
If an alternate next-hop is available, the router redirects traffic to the alternate next-hop in case of a primary next-hop failure as follows.
When a next-hop failure is detected via a local interface failure or other failure detection mechanisms (see [FRAMEWORK]), the router SHOULD:
When a next-hop failure is detected via a local interface failure or other failure detection mechanisms (see [FRAMEWORK]), the router SHOULD:
1. Remove the primary next-hop associated with the failure.
1. Remove the primary next-hop associated with the failure.
2. Install the loop-free alternate calculated for the failed next-
hop if it is not already installed (e.g., the alternate is also a
primary next-hop).
2. Install the loop-free alternate calculated for the failed next- hop if it is not already installed (e.g., the alternate is also a primary next-hop).
Note that the router MAY remove other next-hops if it believes (via SRLG analysis) that they may have been affected by the same failure, even if it is not visible at the time of failure detection.
Note that the router MAY remove other next-hops if it believes (via SRLG analysis) that they may have been affected by the same failure, even if it is not visible at the time of failure detection.
The alternate next-hop MUST be used only for traffic types that are routed according to the shortest path. Multicast traffic is specifically out of scope for this specification.
The alternate next-hop MUST be used only for traffic types that are routed according to the shortest path. Multicast traffic is specifically out of scope for this specification.
4.1. Terminating Use of Alternate
4.1. Terminating Use of Alternate
A router MUST limit the amount of time an alternate next-hop is used after the primary next-hop has become unavailable. This ensures that the router will start using the new primary next-hops. It ensures that all possible transient conditions are removed and the network converges according to the deployed routing protocol.
A router MUST limit the amount of time an alternate next-hop is used after the primary next-hop has become unavailable. This ensures that the router will start using the new primary next-hops. It ensures that all possible transient conditions are removed and the network converges according to the deployed routing protocol.
There are techniques available to handle the micro-forwarding loops that can occur in a networking during convergence.
There are techniques available to handle the micro-forwarding loops that can occur in a networking during convergence.
A router that implements [MICROLOOP] SHOULD follow the rules given there for terminating the use of an alternate.
A router that implements [MICROLOOP] SHOULD follow the rules given there for terminating the use of an alternate.
A router that implements [ORDERED-FIB] SHOULD follow the rules given there for terminating the use of an alternate.
A router that implements [ORDERED-FIB] SHOULD follow the rules given there for terminating the use of an alternate.
Atlas, et al. Standards Track [Page 20] RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008
Atlas, et al. Standards Track [Page 20] RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008
It is desirable to avoid micro-forwarding loops involving S. An example illustrating the problem is given in Figure 5. If the link from S to E fails, S will use N1 as an alternate and S will compute N2 as the new primary next-hop to reach D. If S starts using N2 as soon as S can compute and install its new primary, it is probable that N2 will not have yet installed its new primary next-hop. This would cause traffic to loop and be dropped until N2 has installed the new topology. This can be avoided by S delaying its installation and leaving traffic on the alternate next-hop.
問題が図5で与えられているS.An例の例証にかかわるミクロを進める輪を避けるのは望ましいです。 SからEへのリンクが失敗すると、Sが新しい予備選挙を計算して、インストールできて、N2がまだ新しい第一の次のホップをインストールしていないのが、ありえそうであるとすぐに、達するためには次のホップ新しい第一のD.If SがN2を使用し始めるとき補欠とSがN2を計算するとき、SはN1を使用するでしょう。 N2が新しいトポロジーをインストールするまで、これは交通が輪にして、落とされることを引き起こすでしょう。 交互の次のホップの上でインストールを遅らせて、交通を出るSはこれを避けることができます。
+-----+
| N2 |-------- |
+-----+ 1 | \|/
| |
| +-----+ @@> +-----+
| | S |---------| N1 |
10 | +-----+ 10 +-----+
| | |
| 1 | | |
| | \|/ 10 |
| +-----+ | |
| | E | | \|/
| +-----+ |
| | |
| 1 | | |
| | \|/ |
| +-----+ |
|----| D |--------------
+-----+
+-----+ | N2|-------- | +-----+ 1 | \|/ | | | +-----+ @@> +-----+ | | S|---------| N1| 10 | +-----+ 10 +-----+ | | | | 1 | | | | | \|/ 10 | | +-----+ | | | | E| | \|/ | +-----+ | | | | | 1 | | | | | \|/ | | +-----+ | |----| D|-------------- +-----+
Figure 5: Example Where Continued Use of Alternate Is Desirable
図5: 補欠の継続的な使用が望ましい例
This is an example of a case where the new primary is not a loop-free alternate before the failure and therefore may have been forwarding traffic through S. This will occur when the path via a previously upstream node is shorter than the path via a loop-free alternate neighbor. In these cases, it is useful to give sufficient time to ensure that the new primary neighbor and other nodes on the new primary path have switched to the new route.
これは無輪の交互の隣人を通して、以前に上流のノードを通した経路が経路より短いときに、失敗としたがって、S.Thisを通して交通を進めたかもしれないのが起こる前に新しい予備選挙が無輪の補欠でないケースに関する例です。 これらの場合では、新しい第一の経路の新しい第一の隣人と他のノードが新しいルートに切り替わったのを保証できるくらいの時間を与えるのは役に立ちます。
If the newly selected primary was loop-free before the failure, then it is safe to switch to that new primary immediately; the new primary wasn't dependent on the failure and therefore its path will not have changed.
新たに選択された予備選挙が失敗の前に輪なしであったなら、すぐにその新しい予備選挙に切り替わるのは安全です。 新しい予備選挙は失敗に依存していませんでした、そして、したがって、経路は今まで変わっていないでしょう。
Given that there is an alternate providing appropriate protection and while the assumption of a single failure holds, it is safe to delay the installation of the new primaries; this will not create
適切な保護を提供する補欠がいます、そして、ただ一つの失敗の仮定は成立しますが、新しい予備選挙のインストールを遅らせるのは安全です。 これは作成しないでしょう。
Atlas, et al. Standards Track [Page 21] RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008
Atlas、他 標準化過程[21ページ]RFC5286IPは速くコースを変更します: 無輪の補欠2008年9月
forwarding loops because the alternate's path to the destination is known to not go via S or the failed element and will therefore not be affected by the failure.
目的地への補欠の経路がSか失敗した要素で行かないのが知られて、したがって、失敗で影響を受けないので、推進は輪にされます。
An implementation SHOULD continue to use the alternate next-hops for packet forwarding even after the new routing information is available based on the new network topology. The use of the alternate next- hops for packet forwarding SHOULD terminate:
SHOULDが新しいルーティング情報が利用可能になった後にさえパケット推進のための次のホップの補欠が新しいネットワーク形態に基礎づけた使用に続けている実現。 パケット推進SHOULDのための次の交互のホップの使用は終わります:
a. if the new primary next-hop was loop-free prior to the topology
change, or
またはa. 新しい第一の次のホップがトポロジーの前に輪なしであったなら変えてください。
b. if a configured hold-down, which represents a worst-case bound on
the length of the network convergence transition, has expired, or
またはb. 構成された抑制(ネットワーク集合変遷の長さで縛られた最悪の場合を表す)が期限が切れたなら。
c. if notification of an unrelated topological change in the network
is received.
c. ネットワークにおける関係ない位相的な変化の通知が受信されているなら。
5. Requirements on LDP Mode
5. 自由民主党モードに関する要件
Since LDP [RFC5036] traffic will follow the path specified by the IGP, it is also possible for the LDP traffic to follow the loop-free alternates indicated by the IGP. To do so, it is necessary for LDP to have the appropriate labels available for the alternate so that the appropriate out-segments can be installed in the forwarding plane before the failure occurs.
自由民主党[RFC5036]交通がIGPによって指定された経路に続いて起こるので、また、自由民主党交通がIGPによって示された無輪の補欠に続いて起こるのも、可能です。 そうするために、失敗が起こる前に適切な出ているセグメントを推進飛行機にインストールできて、自由民主党には補欠に利用可能な適切なラベルがあるのが必要です。
This means that a Label Switching Router (LSR) running LDP must distribute its labels for the Forwarding Equivalence Classes (FECs) it can provide to all its neighbors, regardless of whether or not they are upstream. Additionally, LDP must be acting in liberal label retention mode so that the labels that correspond to neighbors that aren't currently the primary neighbor are stored. Similarly, LDP should be in downstream unsolicited mode, so that the labels for the FEC are distributed other than along the SPT.
これは、Label Switching Router(LSR)走行自由民主党がそれがすべての隣人に提供できるForwarding Equivalence Classes(FECs)のためにラベルを分配しなければならないことを意味します、彼らが上流であるかどうかにかかわらず。 さらに、自由民主党が寛容なラベル保有モードで行動しなければならないので、現在第一の隣人でない隣人に文通されるラベルは格納されます。 同様に、自由民主党が川下の求められていないモードでそうあるべきです、SPTを除いて、FECのためのラベルが分配されるように。
If these requirements are met, then LDP can use the loop-free alternates without requiring any targeted sessions or signaling extensions for this purpose.
これらの必要条件が満たされるなら、狙っているセッションを必要とするか、またはこのために拡大に合図しないで、自由民主党は無輪の補欠を使用できます。
6. Routing Aspects
6. ルート設定局面
6.1. Multi-Homed Prefixes
6.1. マルチ、家へ帰り、接頭語
An SPF-like computation is run for each topology, which corresponds to a particular OSPF area or IS-IS level. The IGP needs to determine loop-free alternates to multi-homed routes. Multi-homed routes occur for routes obtained from outside the routing domain by multiple
または、SPFのような計算が各トポロジーへ走る、-、レベル。トポロジーは特定のOSPF領域に対応します。 無輪の補欠を決定する、IGPが、必要があるマルチ、家へ帰り、ルート。 マルチ、家へ帰り、ルートは倍数によって経路ドメインの外から入手されたルートに現れます。
Atlas, et al. Standards Track [Page 22] RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008
Atlas、他 標準化過程[22ページ]RFC5286IPは速くコースを変更します: 無輪の補欠2008年9月
routers, for subnets on links where the subnet is announced from multiple ends of the link, and for routes advertised by multiple routers to provide resiliency.
サブネットがリンクの複数の端から発表されるリンクの上のサブネット、および複数のルータによって広告に掲載された、弾性を提供したルートへのルータ。
Figure 6 demonstrates such a topology. In this example, the shortest path to reach the prefix p is via E. The prefix p will have the link to E as its primary next-hop. If the alternate next-hop for the prefix p is simply inherited from the router advertising it on the shortest path to p, then the prefix p's alternate next-hop would be the link to C. This would provide link protection, but not the node protection that is possible via A.
図6はそのようなトポロジーを示します。 この例、接頭語pに達する最短パスには、接頭語pが持っているE.を通して第一の次のホップとしてのEへのリンクがあります。 接頭語pのための交互の次のホップが最短パスにそれの広告を出すルータからpまで単に引き継がれるなら、接頭語pの交互の次のホップはThisがノード保護ではなく、Aを通して可能なリンク保護を提供するC.へのリンクでしょう。
5 +---+ 8 +---+ 5 +---+
------| S |------| A |-----| B |
| +---+ +---+ +---+
| | |
| 5 | 5 |
| | |
+---+ 5 +---+ 5 7 +---+
| C |---| E |------ p -------| F |
+---+ +---+ +---+
5 +---+ 8 +---+ 5 +---+ ------| S|------| A|-----| B| | +---+ +---+ +---+ | | | | 5 | 5 | | | | +---+ 5 +---+ 5 7 +---+ | C|---| E|------ p-------| F| +---+ +---+ +---+
Figure 6: Multi-Homed Prefix
図6: マルチ、家へ帰り、接頭語
To determine the best protection possible, the prefix p can be treated in the SPF computations as a node with unidirectional links to it from those routers that have advertised the prefix. Such a node need never have its links explored, as it has no out-going links.
単方向があるノードが接頭語の広告を出したそれらのルータからそれにリンクするとき、可能な最も良い保護を決定するために、SPF計算で接頭語pを扱うことができます。 そのようなノードで、どんな外向的なリンクも持っていないので、リンクを決して探ってはいけません。
If there exist multiple multi-homed prefixes that share the same connectivity and the difference in metrics to those routers, then a single node can be used to represent the set. For instance, if in Figure 6 there were another prefix X that was connected to E with a metric of 1 and to F with a metric of 3, then that prefix X could use the same alternate next-hop as was computed for prefix p.
複数で存在している、マルチ、家へ帰り、同じ接続性と測定基準の違いをそれらのルータと共有する接頭語、そして、セットを表すのにただ一つのノードを使用できます。 例えば、図6に、1におけるメートル法のaがあるEと、そして、Fに関連づけられた別の接頭語Xが3におけるメートル法のaをもってあれば、その接頭語Xは接頭語のために計算された同じ交互の次のホップpを使用するかもしれないでしょうに。
A router SHOULD compute the alternate next-hop for an IGP multi-homed prefix by considering alternate paths via all routers that have announced that prefix.
AルータSHOULDがIGPのために交互の次のホップを計算する、マルチ、家へ帰り、その接頭語を発表したすべてのルータで代替パスを考えることによって、前に置きます。
In all cases, a router MAY safely simplify the multi-homed prefix (MHP) calculation by assuming that the MHP is solely attached to the router that was its pre-failure optimal point of attachment. However, this may result in a prefix not being considered repairable, when the full computation would show that a repair was possible.
すべてのケース、5月が安全に簡素化するルータ、マルチ、家へ帰り、MHPが唯一プレ失敗最適の接着点であったルータに取り付けられると仮定することによって、(MHP)計算を前に置いてください。 しかしながら、修繕可能であることは考えられない場合、これが接頭語をもたらすかもしれません、完全な計算が、修理が可能であったのを示すと。
Atlas, et al. Standards Track [Page 23] RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008
Atlas、他 標準化過程[23ページ]RFC5286IPは速くコースを変更します: 無輪の補欠2008年9月
6.2. IS-IS
6.2. IS-IS
The applicability and interactions of LFAs with multi-topology IS-IS [RFC5120] is out of scope for this specification.
マルチトポロジーとのLFAsの適用性と相互作用、-、この仕様のための範囲の外に[RFC5120]があります。
6.3. OSPF
6.3. OSPF
OSPF introduces certain complications because it is possible for the traffic path to exit an area and then re-enter that area. This can occur whenever a router considers the same route from multiple areas. There are several cases where issues such as this can occur. They happen when another area permits a shorter path to connect two ABRs than is available in the area where the LFA has been computed. To clarify, an example topology is given in Appendix A.
交通経路が領域を出て、次に、その領域に再入するのが、可能であるので、OSPFはある複雑さを導入します。 ルータが複数の領域から同じルートを考えるときはいつも、これは起こることができます。 数個のケースがこれなどの問題が起こることができるところにあります。 別の領域が、LFAが計算された領域で利用可能であるというよりもさらに短い経路が2ABRsを接続することを許可すると、それらは起こります。 はっきりさせるために、Appendix Aで例のトポロジーを与えます。
a. Virtual Links: These allow paths to leave the backbone area and
traverse the transit area. The path provided via the transit
area can exit via any ABR. The path taken is not the shortest
path determined by doing an SPF in the backbone area.
a。 仮想のリンク: これらで、経路は、背骨領域を出て、トランジット領域を横断します。 トランジット領域を通して提供された経路はどんなABRを通しても出ることができます。 取られた経路は背骨領域でSPFをすることによって決定している最短パスではありません。
b. Alternate ABR [RFC3509]: When an ABR is not connected to the
backbone, it considers the inter-area summaries from multiple
areas. The ABR A may determine to use area 2 but that path could
traverse another alternate ABR B that determines to use area 1.
This can lead to scenarios similar to that illustrated in
Figure 7.
b。 ABR[RFC3509]を交替してください: ABRが背骨に接続されないとき、それは、相互領域が複数の領域からの概要であると考えます。 ABR Aは、領域2を使用することを決定するかもしれませんが、その経路は領域1を使用することを決定する別の交互のABR Bを横断するかもしれません。 これは図7で例証されたそれと同様のシナリオに通じることができます。
c. ASBR Summaries: An ASBR may itself be an ABR and can be announced
into multiple areas. This presents other ABRs with a decision as
to which area to use. This is the example illustrated in
Figure 7.
c。 ASBR概要: ASBRがそうするかもしれない、それ自体、ABRであり、複数の領域に発表できます。 これはどの領域を使用したらよいかに関して他のABRsに決定を与えます。 これは図7で例証された例です。
d. AS External Prefixes: A prefix may be advertised by multiple
ASBRs in different areas and/or with multiple forwarding
addresses that are in different areas, which are connected via at
least one common ABR. This presents such ABRs with a decision as
to which area to use to reach the prefix.
d。 外部の接頭語として: 接頭語は異なった領域少なくとも1一般的なABRを通してつなげられる異なった領域にある複数のフォーワーディング・アドレスで複数のASBRsによって広告を出されるかもしれません。 これは接頭語に達するというどの領域を使用したらよいかに関する決定をそのようなABRsに与えます。
Loop-free alternates should not be used in an area where one of the above issues affects that area.
上記の問題の1つがその領域に影響する領域で無輪の補欠を使用するべきではありません。
6.3.1. OSPF External Routing
6.3.1. OSPFの外部のルート設定
When a forwarding address is set in an OSPF AS-external Link State Advertisement (LSA), all routers in the network calculate their next- hops for the external prefix by doing a lookup for the forwarding address in the routing table, rather than using the next-hops
フォーワーディング・アドレスがOSPF AS外部のLink州Advertisement(LSA)に設定されるとき、ネットワークにおけるすべてのルータが、外部の接頭語のために経路指定テーブルのフォーワーディング・アドレスのために次のホップを使用するよりむしろルックアップをすることによって、それらの次のホップについて計算します。
Atlas, et al. Standards Track [Page 24] RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008
Atlas、他 標準化過程[24ページ]RFC5286IPは速くコースを変更します: 無輪の補欠2008年9月
calculated for the ASBR. In this case, the alternate next-hops SHOULD be computed by selecting among the alternate paths to the forwarding link(s) instead of among alternate paths to the ASBR.
ASBRのために、計算されています。 この場合、補欠はSHOULDを次に飛び越します。代替パスの代わりに代替パスの中で推進リンクに選択することによって、ASBRに計算されてください。
6.3.2. OSPF Multi-Topology
6.3.2. OSPFマルチトポロジー
The applicability and interactions of LFAs with multi-topology OSPF [RFC4915] [MT-OSPFv3] is out of scope for this specification.
この仕様のための範囲の外にマルチトポロジーOSPF[RFC4915][MT-OSPFv3]とのLFAsの適用性と相互作用があります。
6.4. BGP Next-Hop Synchronization
6.4. BGP次のホップ同期
Typically, BGP prefixes are advertised with the AS exit router's router-id as the BGP next-hop, and AS exit routers are reached by means of IGP routes. BGP resolves its advertised next-hop to the immediate next-hop by potential recursive lookups in the routing database. IP Fast Reroute computes the alternate next-hops to all IGP destinations, which include alternate next-hops to the AS exit router's router-id. BGP simply inherits the alternate next-hop from IGP. The BGP decision process is unaltered; BGP continues to use the IGP optimal distance to find the nearest exit router. Multicast BGP (MBGP) routes do not need to copy the alternate next-hops.
BGPが次に跳んで、AS出口ルータにIGPルートによる達しているとき、通常、AS出口ルータのルータイドでBGP接頭語の広告を出します。 BGPはルーティングデータベースの潜在的再帰的なルックアップで即座の次のホップに広告を出している次のホップを決議します。 IP Fast RerouteはすべてのIGPの目的地に交互の次のホップを計算します。(目的地はAS出口ルータのルータイドに交互の次のホップを含んでいます)。 BGPはIGPから交互の次のホップを単に引き継ぎます。 BGP決定の過程は非変更されます。 BGPは、最も近い出口ルータを見つけるのにIGPの最適の距離を使用し続けています。 マルチキャストBGP(MBGP)ルートは交互の次のホップをコピーする必要はありません。
It is possible to provide ASBR protection if BGP selected a set of BGP next-hops and allowed the IGP to determine the primary and alternate next-hops as if the BGP route were a multi-homed prefix. This is for future study.
BGPが、次のホップでBGPの1セットを選択して、まるでBGPルートがaであるかのようにIGPが第一の、そして、交互の次のホップを決定するのを許容したなら保護をASBRに供給するのが可能である、マルチ、家へ帰り、接頭語。 今後の研究にはこれがあります。
6.5. Multicast Considerations
6.5. マルチキャスト問題
Multicast traffic is out of scope for this specification of IP Fast Reroute. The alternate next-hops SHOULD NOT be used for multicast Reverse Path Forwarding (RPF) checks.
IP Fast Rerouteのこの仕様のための範囲の外にマルチキャスト交通があります。 補欠はSHOULD NOTを次に飛び越します。マルチキャストReverse Path Forwarding(RPF)チェックには、使用されてください。
7. Security Considerations
7. セキュリティ問題
The mechanism described in this document does not modify any routing protocol messages, and hence no new threats related to packet modifications or replay attacks are introduced. Traffic to certain destinations can be temporarily routed via next-hop routers that would not be used with the same topology change if this mechanism wasn't employed. However, these next-hop routers can be used anyway when a different topological change occurs, and hence this can't be viewed as a new security threat.
本書では説明されたメカニズムがしたがって、どんなルーティング・プロトコルメッセージにも関連しますが、パケット変更に関連しないどんな新しい脅威も変更しないか、または反射攻撃を導入します。 このメカニズムが使われないなら同じトポロジー変化と共に使用されない次のホップルータで一時ある目的地への交通を発送できます。 しかしながら、異なった位相的な変化が起こるとき、とにかくこれらの次のホップルータを使用できます、そして、したがって、新しい軍事的脅威としてこれを見なすことができません。
In LDP, the wider distribution of FEC label information is still to neighbors with whom a trusted LDP session has been established. This wider distribution and the recommendation of using liberal label retention mode are believed to have no significant security impact.
自由民主党には、まだ信じられた自由民主党のセッションが確立された隣人にはFECラベル情報の、より広い分配があります。 寛容なラベル保有モードを使用するこのより広い分配と推薦がどんな重要なセキュリティ影響も与えないと信じられています。
Atlas, et al. Standards Track [Page 25] RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008
Atlas、他 標準化過程[25ページ]RFC5286IPは速くコースを変更します: 無輪の補欠2008年9月
8. Acknowledgements
8. 承認
The authors would like to thank Joel Halpern, Mike Shand, Stewart Bryant, and Stefano Previdi for their assistance and useful review.
作者は彼らの支援と役に立つレビューについてジョエル・アルペルン、マイク・シャンド、スチュワートブライアント、およびステファーノPrevidiに感謝したがっています。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
April 1998.
[RFC2328]Moy、J.、「OSPF、バージョン2インチ、STD54、RFC2328、1998インチ年4月。
[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6",
RFC 2740, December 1999.
[RFC2740] ColtunとR.とファーガソン、D.とJ.Moy、「IPv6"、RFC2740、1999年12月のためのOSPF。」
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007.
[RFC5036] アンデションとL.とMinei、I.とB.トーマス、「自由民主党仕様」、RFC5036、2007年10月。
9.2. Informative References
9.2. 有益な参照
[FRAMEWORK] Shand, M. and S. Bryant, "IP Fast Reroute Framework",
Work in Progress, February 2008.
[枠組み] 「IPは速く枠組みを別ルートで送る」というシャンド、M.、およびS.ブライアントは進歩、2008年2月に働いています。
[MICROLOOP] Zinin, A., "Analysis and Minimization of Microloops in
Link-state Routing Protocols", Work in Progress,
October 2005.
[MICROLOOP]ジニン、「LinkState方式プロトコルにおける、Microloopsの分析と最小化」というA.は進歩、2005年10月に働いています。
[MT-OSPFv3] Mirtorabi, S. and A. Roy, "Multi-topology routing in
OSPFv3 (MT-OSPFv3)", Work in Progress, July 2007.
[MT-OSPFv3] MirtorabiとS.とA.ロイ、「OSPFv3(MT-OSPFv3)でのマルチトポロジールーティング」、Progress、2007年7月のWork。
[ORDERED-FIB] Francois, P., "Loop-free convergence using oFIB", Work
in Progress, February 2008.
[ORDERED-FIB] フランソア、P.、「oFIBを使用する無輪の集合」、Progress、2008年2月のWork。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP
and dual environments", RFC 1195, December 1990.
[RFC1195]Callon、R.、「使用、TCP/IPと二元的な環境におけるルーティングのためのOSI IS存在、」、RFC1195、12月1990日
[RFC2966] Li, T., Przygienda, T., and H. Smit, "Domain-wide
Prefix Distribution with Two-Level IS-IS", RFC 2966,
October 2000.
[RFC2966] 李、T.、Przygienda、T.、およびH.スミット、「2レベルとのドメイン全体の接頭語分配、-、」、RFC2966、10月2000日
[RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D.
McPherson, "OSPF Stub Router Advertisement", RFC 3137,
June 2001.
[RFC3137] レタナとA.とNguyenとL.とホワイトとR.とジニン、A.とD.マクファーソン、「OSPFスタッブルータ通知」、RFC3137、2001年6月。
Atlas, et al. Standards Track [Page 26] RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008
Atlas、他 標準化過程[26ページ]RFC5286IPは速くコースを変更します: 無輪の補欠2008年9月
[RFC3509] Zinin, A., Lindem, A., and D. Yeung, "Alternative
Implementations of OSPF Area Border Routers",
RFC 3509, April 2003.
[RFC3509] ジニン、A.、Lindem、A.、およびD.Yeung、「OSPF境界ルータの代替の実現」、RFC3509、2003年4月。
[RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in
Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4203, October 2005.
[RFC4203] KompellaとK.とY.Rekhter、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)を支持したOSPF拡張子」、RFC4203、2005年10月。
[RFC4205] Kompella, K. and Y. Rekhter, "Intermediate System to
Intermediate System (IS-IS) Extensions in Support of
Generalized Multi-Protocol Label Switching (GMPLS)",
RFC 4205, October 2005.
[RFC4205] Kompella、K.、およびY.Rekhter、「中間システムへの中間システム、(-、)、一般化されたマルチプロトコルを支持した拡大が切り換え(GMPLS)をラベルする、」、RFC4205(2005年10月)
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
RFC 4915, June 2007.
[RFC4915] Psenak、P.、Mirtorabi、S.、ロイ、A.、Nguyen、L.、およびP.Pillay-Esnault、「OSPFのマルチトポロジー(MT)ルート設定」、RFC4915(2007年6月)。
[RFC5029] Vasseur, JP. and S. Previdi, "Definition of an IS-IS
Link Attribute Sub-TLV", RFC 5029, September 2007.
JP[RFC5029]Vasseur、S.Previdi、「定義、-、属性サブTLVをリンクしてください、」、RFC5029、9月2007日
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120,
February 2008.
[RFC5120] Przygienda、T.、シン、N.、およびN.Sheth、「Mイシス:」 「中間システムへの中間システムのマルチトポロジー(MT)ルート設定、(-、ISs、)、」、RFC5120、2月2008日
[RFC5340] Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6",
RFC 5340, July 2008.
[RFC5340] ファーガソンとD.とMoy、J.とA.Lindem、「IPv6"、RFC5340、2008年7月のためのOSPF。」
Atlas, et al. Standards Track [Page 27] RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008
Atlas、他 標準化過程[27ページ]RFC5286IPは速くコースを変更します: 無輪の補欠2008年9月
Appendix A. OSPF Example Where LFA Based on Local Area Topology Is
Insufficient
局部トポロジーに基づくLFAが不十分である付録A.OSPFの例
This appendix provides an example scenario where the local area topology does not suffice to determine that an LFA is available. As described in Section 6.3, one problem scenario is for ASBR summaries where the ASBR is available in two areas via intra-area routes and there is at least one ABR or alternate ABR that is in both areas. The following Figure 7 illustrates this case.
この付録は局部トポロジーがLFAが利用可能であることを決定するために十分でない例のシナリオを提供します。 説明されるように、両方の領域にあるABRはセクション6.3、1問題シナリオでは、ASBR概要のためにASBRが2つの領域でイントラ領域ルートで利用可能であり、少なくとも1ABRがあるところにあるか、または交互です。 以下の図7は本件を例証します。
5
[ F ]-----------[ C ]
| |
| | 5
20 | 5 | 1
| [ N ]-----[ A ]*****[ F ]
| | # *
| 40 | # 50 * 2
| | 5 # 2 *
| [ S ]-----[ B ]*****[ G ]
| | *
| 5 | * 15
| | *
| [ E ] [ H ]
| | *
| 5 | * 10**
| | *
|---[ X ]----[ ASBR ]
5
5 [F]-----------[C]| | | | 5 20 | 5 | 1 | [N]-----*****[F]| | # * | 40 | # 50 * 2 | | 5 # 2 * | [S]-----[B]*****[G]| | * | 5 | * 15 | | * | [E][H]| | * | 5 | * 10** | | * |---[X]----[ASBR]5
---- Link in Area 1
**** Link in Area 2
#### Link in Backbone Area 0
---- 背骨領域0で領域の2####リンクで領域1****リンクでリンクしてください。
Figure 7: Topology with Multi-Area ASBR Causing Area Transiting
図7: マルチ領域ASBRが領域トランジットを引き起こしているトポロジー
In Figure 7, the ASBR is also an ABR and is announced into both area 1 and area 2. A and B are both ABRs that are also connected to the backbone area. S determines that N can provide a loop-free alternate to reach the ASBR. N's path goes via A. A also sees an intra-area route to ASBR via area 2; the cost of the path in area 2 is 30, which is less than 35, the cost of the path in area 1. Therefore, A uses the path from area 2 and directs traffic to F. The path from F in area 2 goes to B. B is also an ABR and learns the ASBR from both areas 1 and area 2; B's path via area 1 is shorter (cost 20) than B's path via area 2 (cost 25). Therefore, B uses the path from area 1 that connects to S.
図7では、ASBRはまた、ABRであり、領域1と領域2の両方に発表されます。 AとBはまた、背骨領域に接続される両方のABRsです。 Sは、NがASBRに達するように無輪の補欠を提供できることを決定します。 Nの経路はA.を通って行きます。また、Aは領域2を通ってASBRへのイントラ領域ルートを見ます。 領域2の経路の費用は30です。(その30は35未満、領域1の経路の費用です)。 したがって、Aは、領域2から経路を使用して、F.に交通整理します。領域2のFからの経路はB.に行きます。Bは、また、ABRであり、領域1と領域2の両方からASBRを学びます。 領域2を通って、領域1を通るビーズ経路はビーズ経路より短いです(20かかります)(25かかってください)。 したがって、Bは接続する領域1からSまで経路を使用します。
Atlas, et al. Standards Track [Page 28] RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008
Atlas、他 標準化過程[28ページ]RFC5286IPは速くコースを変更します: 無輪の補欠2008年9月
Authors' Addresses
作者のアドレス
Alia K. Atlas (editor) BT
アリアK.Atlas(エディタ)BT
EMail: alia.atlas@bt.com
メール: alia.atlas@bt.com
Alex Zinin (editor) Alcatel-Lucent 750D Chai Chee Rd, #06-06 Technopark@ChaiChee Singapore 469004
アレックスジニン(エディタ)アルカテル透明な750DチャイChee、#06-06 Technopark@ChaiChee 第シンガポール469004
EMail: alex.zinin@alcatel-lucent.com
メール: alex.zinin@alcatel-lucent.com
Raveendra Torvi FutureWei Technologies Inc. 1700 Alma Dr. Suite 100 Plano, TX 75075 USA
Raveendra Torvi FutureWei Technologies株式会社1700アルマSuite100プラノ博士(テキサス)75075米国
EMail: traveendra@huawei.com
メール: traveendra@huawei.com
Gagan Choudhury AT&T 200 Laurel Avenue, Room D5-3C21 Middletown, NJ 07748 USA
GaganチョウドリAT&T200ローレルAvenue、余地のD5-3C21ミドルタウン、ニュージャージー07748米国
Phone: +1 732 420-3721 EMail: gchoudhury@att.com
以下に電話をしてください。 +1 732 420-3721 メールしてください: gchoudhury@att.com
Christian Martin iPath Technologies
クリスチャンのマーチンiPath Technologies
EMail: chris@ipath.net
メール: chris@ipath.net
Atlas, et al. Standards Track [Page 29] RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008
Atlas、他 標準化過程[29ページ]RFC5286IPは速くコースを変更します: 無輪の補欠2008年9月
Brent Imhoff Juniper Networks 1194 North Mathilda Sunnyvale, CA 94089 USA
ブレントアンホフ杜松は1194北でマチルダ・カリフォルニア94089サニーベル(米国)をネットワークでつなぎます。
Phone: +1 314 378 2571 EMail: bimhoff@planetspork.com
以下に電話をしてください。 +1 2571年の314 378メール: bimhoff@planetspork.com
Don Fedyk Nortel Networks 600 Technology Park Billerica, MA 01821 USA
ドンFedykのノーテルネットワーク600技術Park MA01821ビルリカ(米国)
Phone: +1 978 288 3041 EMail: dwfedyk@nortelnetworks.com
以下に電話をしてください。 +1 3041年の978 288メール: dwfedyk@nortelnetworks.com
Atlas, et al. Standards Track [Page 30] RFC 5286 IP Fast Reroute: Loop-Free Alternates September 2008
Atlas、他 標準化過程[30ページ]RFC5286IPは速くコースを変更します: 無輪の補欠2008年9月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Atlas, et al. Standards Track [Page 31]
Atlas、他 標準化過程[31ページ]
一覧
スポンサーリンク
