An Architecture for Multicast Protection Using Maximally Redundant Trees
Author(s): IJsbrand Wijnands, Robert Kebler, Alia Atlas, Andras Csaszar, Gabor Envedi
Failure protection is desirable for multicast traffic, whether signaled via PIM or mLDP. Different mechanisms are suitable for different use-cases and deployment scenarios. This document describes the architecture for global protection (aka multicast live- live) and for local...
Routing Area Working Group A. Atlas, Ed. Internet-Draft R. Kebler Intended status: Standards Track Juniper Networks Expires: January 13, 2014 IJ. Wijnands Cisco Systems, Inc. A. Csaszar G. Enyedi Ericsson July 12, 2013 An Architecture for Multicast Protection Using Maximally Redundant Trees draft-atlas-rtgwg-mrt-mc-arch-02 Abstract Failure protection is desirable for multicast traffic, whether signaled via PIM or mLDP. Different mechanisms are suitable for different use-cases and deployment scenarios. This document describes the architecture for global protection (aka multicast live- live) and for local protection (aka fast-reroute). The general methods for global protection and local protection using alternate-trees are dependent upon the use of Maximally Redundant Trees. Local protection can also tunnel traffic in unicast tunnels to take advantage of the routing and fast-reroute mechanisms available for IP/LDP unicast destinations. The failures protected against are single link or node failures. While the basic architecture might support protection against shared risk group failures, algorithms to dynamically compute MRTs supporting this are for future study. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Atlas, et al. Expires January 13, 2014 [Page 1] Internet-Draft MRT FRR Architecture July 2013 This Internet-Draft will expire on January 13, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Atlas, et al. Expires January 13, 2014 [Page 2] Internet-Draft MRT FRR Architecture July 2013 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Maximally Redundant Trees (MRTs) . . . . . . . . . . . . . 4 1.2. MRTs and Multicast . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Use-Cases and Applicability . . . . . . . . . . . . . . . . . 8 4. Global Protection: Multicast Live-Live . . . . . . . . . . . . 9 4.1. Creation of MRMTs . . . . . . . . . . . . . . . . . . . . 10 4.2. Traffic Self-Identification . . . . . . . . . . . . . . . 11 4.2.1. Merging MRMTs for PIM if Traffic Doesn't Self-Identify . . . . . . . . . . . . . . . . . . . . 12 4.3. Convergence Behavior . . . . . . . . . . . . . . . . . . . 13 4.4. Inter-area/level Behavior . . . . . . . . . . . . . . . . 14 4.4.1. Inter-area Node Protection with 2 border routers . . . 15 4.4.2. Inter-area Node Protection with > 2 Border Routers . . 16 4.5. PIM . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.5.1. Traffic Handling: RPF Checks . . . . . . . . . . . . . 17 4.6. mLDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5. Local Repair: Fast-Reroute . . . . . . . . . . . . . . . . . . 17 5.1. PLR-driven Unicast Tunnels . . . . . . . . . . . . . . . . 18 5.1.1. Learning the MPs . . . . . . . . . . . . . . . . . . . 19 5.1.2. Using Unicast Tunnels and Indirection . . . . . . . . 19 5.1.3. MP Alternate Traffic Handling . . . . . . . . . . . . 20 5.1.4. Merge Point Reconvergence . . . . . . . . . . . . . . 21 5.1.5. PLR termination of alternate traffic . . . . . . . . . 21 5.2. MP-driven Unicast Tunnels . . . . . . . . . . . . . . . . 21 5.3. MP-driven Alternate Trees . . . . . . . . . . . . . . . . 22 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 9. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 23 9.1. MP-driven Alternate Trees . . . . . . . . . . . . . . . . 23 9.1.1. PIM details for Alternate-Trees . . . . . . . . . . . 26 9.1.2. mLDP details for Alternate-Trees . . . . . . . . . . . 26 9.1.3. Traffic Handling by PLR . . . . . . . . . . . . . . . 26 9.2. Methods Compared for PIM . . . . . . . . . . . . . . . . . 27 9.3. Methods Compared for mLDP . . . . . . . . . . . . . . . . 27 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 10.1. Normative References . . . . . . . . . . . . . . . . . . . 27 10.2. Informative References . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Atlas, et al. Expires January 13, 2014 [Page 3] Internet-Draft MRT FRR Architecture July 2013 1. Introduction This document describes how the algorithms in [I-D.enyedi-rtgwg-mrt-frr-algorithm], which are used in [I-D.ietf-rtgwg-mrt-frr-architecture] for unicast IP/LDP fast- reroute, can be used to provide protection for multicast traffic. It specifically applies to multicast state signaled by PIM[RFC4601] or mLDP[RFC6388]. There are additional protocols that depend upon these (e.g. VPLS, mVPN, etc.) and consideration of the applicability to such traffic will be in a future version. In this document, global protection is used to refer to the method of having two maximally disjoint multicast trees where traffic may be sent on both and resolved by the receiver. This is similar to the ability with RSVP-TE LSPs to have a primary and a hot standby, except that it can operate in 1+1 mode. This capability is also referred to as multicast live-live and is a generalized form of that discussed in [I-D.ietf-rtgwg-mofrr]. In this document, local protection refers to the method of having alternate ways of reaching the pre-identified merge points upon detection of a local failure. This capability is also referred to as fast-reroute. This document describes the general architecture, framework, and trade-offs of the different approaches to solving these general problems. It will recommend how to generally provide global protection and local protection for mLDP and PIM traffic. Where protocol extensions are necessary, they will be defined in separate documents as follows. o Global 1+1 Protection Using PIM o Global 1+1 Protection Using mLDP o Local Protection Using mLDP: [I-D.wijnands-mpls-mldp-node-protection]This document describes how to provide node-protection and the necessary extensions using targeted LDP session. o Local Protection Using PIM 1.1. Maximally Redundant Trees (MRTs) Maximally Redundant Trees (MRTs) are described in [I-D.enyedi-rtgwg-mrt-frr-algorithm]; here we only give a brief description about the concept. A pair of MRTs is a pair of directed spanning trees (red and blue tree) with a common root, directed so that each node can be reached from the root on both trees. Moreover, these trees are redundant, since they are constructed so that no Atlas, et al. Expires January 13, 2014 [Page 4] Internet-Draft MRT FRR Architecture July 2013 single link or single node failure can separate any node from the root on both trees, unless that failed link or node is splitting the network into completely separated components (e.g. the link or node was a cut-edge or cut-vertex). Although for multicast, the arcs (directed links) are directed away from the root instead of towards the root, the same MRT computations are used and apply. This is similar to how multicast uses unicast routing's next-hops as the upstream-hops. Thus this definition slightly differs from the one presented in [I-D.enyedi-rtgwg-mrt-frr-algorithm], since the arcs are directed away and not towards the root. When we need two paths towards a given destination and not two away from it (e.g. for unicast detours for local repair solutions), we only need to reverse the arcs from how they are used for the unicast routing case; thus constructing MRTs towards or away from the root is the same problem. A pair of MRTs is depicted in Figure 1. [E]---[D]---| |---[J] | | | | | | | | | | [R] [F] [C]---[G] | | | | | | | | | | | [A]---[B]---| |---[H] (a) a network [E]<--[D]---| |-->[J] [E]<--[D] [J] ^ | | | | ^ ^ | V V | | | | [R] [F] [C]-->[G] | [R] [F] [C]-->[G] | | | | ^ ^ | | V V V | | | | [A]<--[B] [H] [A]-->[B]---| |-->[H] (b) Blue MRT of root R (c) Red MRT of root R Figure 1: A network and two MRTs found in it It is important to realize that this redundancy criterion does not imply that, after a failure, either of the MRTs remains intact, since a node failure must affect any spanning tree. Redundancy here means that there will be a set of nodes, which can be reached along the blue MRT, and there will be another set, which remains reachable along the red MRT. As an example, suppose that node F goes down; that would separate B and A on the blue MRT and D and E on the red Atlas, et al. Expires January 13, 2014 [Page 5] Internet-Draft MRT FRR Architecture July 2013 MRT. Naturally, it is possible that the intersection of these two sets is not empty, e.g. C, G, H and J will remain reachable on both MRTs. Additionally, observe that a single link can be used in both of the trees in different directions, so even a link failure can cut both trees. In this example, the failure of link F<->B leads to the same reachability sets. Finally, it is critical to recall that a pair of MRTs is always constructed together and they are not SPTs. While it would be useful to have an algorithm that could find a redundant pair for a given tree (e.g. for the SPT), that is impossible in general. Moreover, if there is a failure and at least one of the trees change, the other tree may need to change as well. Therefore, even if a node still receives the traffic along the red tree, it cannot keep the old red tree, and construct a blue pair for it; there can be reconfiguration in cases when traditional shortest-path-based-thinking would not expect it. To converge to a new pair of disjoint MRTs, it is generally necessary to update both the blue MRT and the red MRT. The two MRTs provide two separate forwarding topologies that can be used in addition to the default shortest-path-tree (SPT) forwarding topology (usually MT-ID 0). There is a Blue MRT forwarding topology represented by one MT-ID; similarly there is a Red MRT forwarding topology represented by a different MT-ID. Naturally, a multicast protocol is required to use the forwarding topologies information to build the desired multicast trees. The multicast protocol can simply request appropriate upstream interfaces, but include the MT-ID when needed. 1.2. MRTs and Multicast Maximally Redundant Trees (MRT) provide two advantages for protecting multicast traffic. First, for global protection, MRTs are precisely what needs to be computed to have maximally redundant multicast distribution trees. Second, for local repair, MRTs ensure that there will protection to the merge points; the certainty of a path from any merge point to the PLR that avoids the failure node allows for the creation of alternate trees. A known disadvantage of MRT, and redundant trees in general, is that the trees do not necessarily provide shortest detour paths. Modeling is underway to investigate and compare the MRT lengths for the different algorithm options [I-D.enyedi-rtgwg-mrt-frr-algorithm]. 2. Terminology Atlas, et al. Expires January 13, 2014 [Page 6] Internet-Draft MRT FRR Architecture July 2013 2-connected: A graph that has no cut-vertices. This is a graph that requires two nodes to be removed before the network is partitioned. 2-connected cluster: A maximal set of nodes that are 2-connected. 2-edge-connected: A network graph where at least two links must be removed to partition the network. ADAG: Almost Directed Acyclic Graph - a graph that, if all links incoming to the root were removed, would be a DAG. block: Either a 2-connected cluster, a cut-edge, or an isolated vertex. cut-link: A link whose removal partitions the network. A cut-link by definition must be connected between two cut-vertices. If there are multiple parallel links, then they are referred to as cut-links in this document if removing the set of parallel links would partition the network. cut-vertex: A vertex whose removal partitions the network. DAG: Directed Acyclic Graph - a graph where all links are directed and there are no cycles in it. GADAG: Generalized ADAG - a graph that is the combination of the ADAGs of all blocks. Maximally Redundant Trees (MRT): A pair of trees where the path from any node X to the root R along the first tree and the path from the same node X to the root along the second tree share the minimum number of nodes and the minimum number of links. Each such shared node is a cut-vertex. Any shared links are cut-links. Any RT is an MRT but many MRTs are not RTs. Maximally Redundant Multicast Trees (MRMT): A pair of multicast trees built of the sub-set of MRTs that is needed to reach all interested receivers. network graph: A graph that reflects the network topology where all links connect exactly two nodes and broadcast links have been transformed into the standard pseudo-node representation. Redundant Trees (RT): A pair of trees where the path from any node X to the root R along the first tree is node-disjoint with the path from the same node X to the root along the second tree. These can be computed in 2-connected graphs. Atlas, et al. Expires January 13, 2014 [Page 7] Internet-Draft MRT FRR Architecture July 2013 Merge Point (MP): For local repair, a router at which the alternate traffic rejoins the primary multicast tree. For global protection, a router which receives traffic on multiple trees and must decide which stream to forward on. Point of Local Repair (PLR): The router that detects a local failure and decides whether and when to forward traffic on appropriate alternates. MT-ID: Multi-topology identifier. The default shortest-path-tree topology is MT-ID 0. MultiCast Ingress (MCI): Multicast Ingress, the node where the multicast stream enters the current transport technology (MPLS- mLDP or IP-PIM) domain. This maybe the router attached to the multicast source, the PIM Rendezvous Point (RP) or the mLDP Root node address. Upstream Multicast Hop (UMH): Upstream Multicast Hop, a candidate next-hop that can be used to reach the MCI of the tree. Stream Selection: The process by which a router determines which of the multiple primary multicast streams to accept and forward. The router can decide on a packet-by-packet basis or simply per- stream. This is done for global protection 1+1 and described in [I-D.ietf-rtgwg-mofrr]. MultiCast Egress (MCE): Multicast Egress, a node where the multicast stream exists the current transport technology (MPLS- mLDP or IP-PIM) domain. This is usually a receiving router that may forward the multicast traffic on towards receivers based upon IGMP or other technology. 3. Use-Cases and Applicability Protection of multicast streams has gained importance with the use of multicast to distribute video, including live video such as IP-TV. There are a number of different scenarios and uses of multicast that require protection. A few preliminary examples are described below. o When video is distributed via IP or MPLS for a cable application, it is desirable to have global protection 1+1 so that the customer-perceived impact is limited. A QAM can join two multicast groups and determine which stream to use based upon the stream quality. A network implementing this may be custom- engineered for this particular purpose. Atlas, et al. Expires January 13, 2014 [Page 8] Internet-Draft MRT FRR Architecture July 2013 o In financial markets, stock ticker data is distributed via multicast. The loss of data can have a significant financial impact. Depending on the network, either global protection 1+1 or local protection can minimize the impact. o Several solutions exist for updating software or firmwares of a large number of end-user or operator-owned networking equipment that are based on IP multicast. Since IP multicast is based on datagram transport so taking care of lost data is cumbersome and decreases the advantages offered by multicast. Solutions may rely on sending the updates several times: a properly protected network may result in that less repetitions are required. Other solutions rely on the recipent asking for lost data segments explicitly on- demand. A network failure could cause data loss for a significant number of receivers, which in turn would start requesting the the lost data in a burst that could overload the server. Properly engineered multicast fast reroute would minimise such impacts. o Some providers offer multicast VPN services to their customers. SLAs between the customer and provider may set low packet loss requirements. In such cases interruptions longer than the outage timescales targeted by FRR could cause direct financial losses for the provider. Global protection 1+1 uses maximally redundant multicast trees (MRMTs) to simultaneously distribute a multicast stream on both MRMTs. The disadvantage is the extra state and bandwidth requirements of always sending the traffic twice. The advantage is that the latency of each MRMT can be known and the receiver can select the best stream. Local protection provides a patch around the fault while the multicast tree reconverges. When PLR replication is used, there is no extra multicast state in the network, but the bandwidth requirements vary based upon how many potential merge-points must be provided. When alternate-trees are used, there is extra multicast state but the bandwidth requirements on a link can be minimized to no more than once for the primary multicast tree traffic and once for the alternate-tree traffic. 4. Global Protection: Multicast Live-Live In MoFRR [I-D.ietf-rtgwg-mofrr], the idea of joining both a primary and a secondary tree is introduced with the requirement that the primary and secondary trees be link and node disjoint. This works well for networks where there are dual-planes, as explained in [I-D.ietf-rtgwg-mofrr]. For other networks, it is still desirable to Atlas, et al. Expires January 13, 2014 [Page 9] Internet-Draft MRT FRR Architecture July 2013 have two disjoint multicast trees and allow a receiver to join both and make its own decision about which traffic to accept. Using MRTs gives the ability to guarantee that the two trees are as disjoint as possible and dynamically recomputed whenever the topology changes. The MRTs used are rooted at the MultiCast Ingress (MCI). One multicast tree is created using the Blue MRT forwarding topology. The second multicast tree is created using the Red MRT forwarding topology. This can be accomplished by specifying the appropriate MT-ID associated with each forwarding topology. There are four different aspects of using MRTs for 1+1 Global Protection that are necessary to consider. They are as follows. 1. Creation of the maximally redundant multicast trees (MRMTs) based upon the forwarding topologies. 2. Traffic Identification: How to handle traffic when the two MRMTs overlap due to a cut-vertex or cut-link. 3. Convergence: How to converge after a network change and get back to a protected state. 4. Inter-area/inter-level Behavior: How to compute and use MRMTs when the multicast source is outside the area/level and how to provide border-router protection. 4.1. Creation of MRMTs The creation of the two maximally redundant multicast trees occurs as described below. This assumes that the next-hops to the MCI associated with the Blue and Red forwarding topologies have already been computed and stored. 1. A receiving router determines that it wants to join both the Blue tree and the Red tree. The details on how it does this decision are not covered in this document and could be based on configuration, additional protocols, etc. 2. The router selects among the Blue next-hops an Upstream Multicast Hop (UMH) to reach the MCI node. The router joins the tree towards the selected UMH including a multi-topology id (MT-ID) identifying the Blue MRT. 3. The router selects among the Red next-hops an Upstream Multicast Hop (UMH) to reach the MCI node. The router joins the tree towards the selected UMH including a multi-topology id (MT-ID) identifying the Red MRT. Atlas, et al. Expires January 13, 2014 [Page 10] Internet-Draft MRT FRR Architecture July 2013 4. When a router receives a tree setup request specifying a particular MT-ID (e.g. Color), then the router selects among the Color next-hops to the MCI a UMH node, creates the necessary multicast state, and joins the tree towards the UMH node. 4.2. Traffic Self-Identification Two maximally redundant trees will share any cut-vertices and cut- links in the network. In the multicast global protection 1+1 case, this means that the potential single failures of the other nodes and links in the network are still protected against. If each cut-vertex cannot associate traffic to a particular MRMT, then the traffic would be incorrectly replicated to both MRMT resulting in complete duplication of traffic. An example of such MRTs is given earlier in Figure 1 and repeated below in Figure 2, where there are two cut- vertices C and G and a cut-link C<->G. [E]---[D]---| |---[J] | | | | | | | | | | [R] [F] [C]---[G] | | | | | | | | | | | [A]---[B]---| |---[H] (a) a network [E]<--[D]---| |-->[J] [E]<--[D] [J] ^ | | | | ^ ^ | V V | | | | [R] [F] [C]-->[G] | [R] [F] [C]-->[G] | | | | ^ ^ | | V V V | | | | [A]<--[B] [H] [A]-->[B]---| |-->[H] (b) Blue MRT of root R (c) Red MRT of root R Figure 2: A network and two MRTs found in it In this example, traffic from the multicast source R to a receiver G, J, or H will cross link C<->G on both the Blue and Red MRMTs. When this occurs, there are several different possibilities depending upon protocol. Atlas, et al. Expires January 13, 2014 [Page 11] Internet-Draft MRT FRR Architecture July 2013 mLDP: Different label bindings will be created for the Blue and Red MRMTs. As specified in [I-D.iwijnand-mpls-mldp-multi-topology], the P2MP FEC Element will use the MT IP Address Family to encode the Root node address and MRT T-ID. Each MRMT will therefore have a different P2MP FEC Element and be assigned an independent label. PIM: There are three different ways to handle IP traffic forwarded based upon PIM when that traffic will overlap on a link. A. Different Groups: If different multicast groups are used for each MRMT, then the traffic clearly indicates which MRMT it belongs to. In this case, traffic on the Blue MRMT would use multicast group G-blue and traffic on the Red MRMT would use multicast group G-red. B. Different Source Loopbacks: Another option is to use different IP addresses for the source S, so S might announce S-red and S-blue. In this case, traffic on the Blue MRMT would have an IP source of S-blue and traffic on the Red MRMT would have an IP source of S-red. C. Stream Selection and Merging: The third option, described in Section 4.2.1, is to have a router that gets (S,G) Joins for both the Blue MT-ID and the Red MT-ID merge those into a single tree. The router may need to select which upstream stream to use, just as if it were a receiving router. There are three options presented for PIM. The most appropriate will depend upon deployment scenario as well as router capabilities. 4.2.1. Merging MRMTs for PIM if Traffic Doesn't Self-Identify When traffic doesn't self-identify, the cut-vertices must follow specific rules to avoid traffic duplication. This section describes that behavior which allows the same (S,G) to be used for both the Blue MT-ID and Red MT-ID (e.g. when the traffic doesn't self-identify as to its MT-ID). The behavior described in this section differs from the conflict resolution described in [RFC6420] because these rules apply to the Global Protection 1+1 case. Specifically, it is not sufficient for a upstream router to pick only one of the two MT-IDs to join because that does not maximize the protection provided. As described in [RFC6420], a router that receives (S,G) Joins for both the Blue MT-ID and the Red MT-ID can merge the set of downstream interfaces in its forwarding entry. Unlike the procedures defined in [RFC6420], the router must send a Join upstream for each MT-ID. If a Atlas, et al. Expires January 13, 2014 [Page 12] Internet-Draft MRT FRR Architecture July 2013 router has different upstream interfaces for these MRMTs, then the router will need to do stream selection and forward the selected stream to its outgoing interfaces, just as if it were an MCE. The stream selection methods of detecting failures and handle traffic discarding are described in [I-D.ietf-rtgwg-mofrr]. This method does not work if the MRMTs merge on a common LAN with different upstream routers. In this case, the traffic cannot be distinguished on the LAN and will result in duplication on the LAN. The normal PIM Assert procedure would stop one of the upstream routers from transmitting duplicates onto the LAN once it is detected. This, in turn, may cause the duplicate stream to be pruned back to the source. Thus, end-to-end protection in this case of the MRMTs converging on a single LAN with different upstream interfaces can only be accomplished by the methods of traffic self- identification. 4.3. Convergence Behavior It is necessary to handle topology changes and get back to having two MRMTs that provide global protection. To understand the requirements and what can be computed, recall the following facts. a. It is not generally possible to compute a single tree that is maximally redundant to an existing tree. b. The pair of MRTs must be computed simultaneously. c. After a single link or node failure, there is one set of nodes that can be reached from the root on the Blue MRMT and a second set of nodes that can be reached from the root on the Red MRMT. If the failure wasn't a cut-vertex or cut-edge, all nodes will be in at least one of these two sets. To gracefully converge, it is necessary to never have a router where both its red MRMT and blue MRMT are broken. There are three different ways in which this could be done. These options are being more fully explored to see which is most practical and provides the best set of trade-offs. Ordered Convergence When a single failure occurs, each receiver determines whether it was affected or unaffected. First, the affected receivers identify the broken MRMT color (e.g. blue) and join the MRMT via their new UMH for that MRT color. Once the affected receivers receive confirmation that the new MRMT has been successfully created back to the MCI, then the affected receivers switch to using that MRMT. The affected receivers tear down the old broken MRMT state and join the MRMT via their new UMH for the Atlas, et al. Expires January 13, 2014 [Page 13] Internet-Draft MRT FRR Architecture July 2013 other MRT color (e.g. red). Finally, once the affected receivers receive confirmation that the new MRMT has been successfully created back to the MCI, the affected receivers can tear down the old working MRMT state. Once the affected receivers have updated their state, the unaffected receivers need to also do the same staging - first joining the MRMT via their new UMH for the Blue MRT, waiting for confirmation, switching to using traffic from the Blue MRMT, tearing down the old Blue MRMT state, joining the MRMT via their new UMH for the Red MRT, waiting for confirmation, and tearing down the old Red MRMT state. There are complexities remaining, such as determining how an Unaffected Receiver decides that the Affected Receivers are done. When the topology change isn't a failure, all receivers are unaffected and the same process can apply. Protocol Make-Before-Break In the control plane, a router joins the tree on the new Blue topology but does not stop receiving traffic on the old Blue topology. Once traffic is observed from the new Blue UMH, then the router accepts traffic on the new Blue UMH and removes the old Blue UMH. This behavior can happen simultaneously with both Blue and Red forwarding topologies. An advantage is that it works regardless of the type of topology change and existing traffic streams aren't broken. Another advantage is that the complexity is limited and this method is well understood. The disadvantage is that the number of traffic-affecting events depends upon the number of hops to the MCI. Multicast Source Make-Before-Break On a topology change, routers would create new MRMTs using new MRT forwarding state and leaving the old MRMTs as they are. After the new MRMTs are complete, the multicast source could switch from sending on the old MRMTs to sending on the new MRMTs. After a time, the old MRMTs could be torn down. There are a number of details to still investigate. 4.4. Inter-area/level Behavior A source outside of the IGP area/level can be treated as a proxy node. When the join request reaches a border router (whether ABR for OSPF or LBR for ISIS), that border router needs to determine whether to use the Blue or Red forwarding topology in the next selected area/ level. Atlas, et al. Expires January 13, 2014 [Page 14] Internet-Draft MRT FRR Architecture July 2013 |-------------------| | | |---[S]---| [BR1]-----[ X ] | | | | | | [ A ]-----[ B ] | | | | | [ Y ]-----[BR2]--(proxy for S) | | [BR1]-----[BR2] (b) Area 10 Y's Red next-hop: BR1 (a) Area 0 Y's Blue next-hop: BR2 Red Next-Hops to S BR1's is BR2 BR2's is B B's is S Blue Next-Hops to S BR1's is A BR2's is BR1 A's is S Figure 3: Inter-area Selection - next-hops towards S Achieving maximally node-disjoint trees across multiple areas is hard due to the information-hiding and abstraction. If there is only one border router, it is trivial but protection of the border router is not possible. With exactly 2 border routers, inter-area/level node protection is reasonably straightforward but can require that the BR rewrite the (S,G) for PIM. With more than 2 border routers, inter- area node protection is possible at the cost of additional bandwidth and border router complexity. These two solutions are described in the following sub-sections. 4.4.1. Inter-area Node Protection with 2 border routers If there are exactly two border routers between the areas, then the solution and necessary computation is straightforward. In that specific case, each BR knows that only the other BR must specifically be avoided in the second area when a forwarding topology is selected. As described in [I-D.enyedi-rtgwg-mrt-frr-algorithm], it is possible for a node X to determine whether the Red or Blue forwarding topology should be used to reach a node D while avoiding another node Y. The results of this computation and the resulting changes in MT-ID from Red to Blue or Blue to Red are illustrated in Figure 3. It shows an example where BR1 must modify joins received from Area 10 for the Red MT-ID to use the Blue MT-ID in Area 0. Similarly, BR2 must modify joins received from Area 10 for the Blue MT-ID to use the Atlas, et al. Expires January 13, 2014 [Page 15] Internet-Draft MRT FRR Architecture July 2013 Red MT-ID in Area 0. For mLDP, modifying the MT-ID in the control-plane is all that is needed. For PIM, if the same (S,G) is used for both the Blue MT-ID and the Red MT-ID, then only control-plane changes are needed. However, for PIM, if different group IDs (e.g. G-red and G-blue) or different source loopback addresses (S-red and S-blue) are used, it is necessary to modify the traffic to reflect the MT-ID included in the join message received on that interface. An alternative could be to use an MPLS label that indicates the MT-ID instead of different group IDs or source loopback addresses. To summarize the necessary logic, when a BR1 receives a join from a neighbor in area N to a destination D in area M on the Color MT-ID, the BR1: a. Identifies the BR2 at the other end of the proxy node in area N. b. Determines which forwarding topology may avoid BR2 to reach D in area M. Refer to that as Color-2 MT-ID. c. Uses Color-2 MT-ID to determine the next-hops to S. When a join is sent upstream, the MT-ID used is that for Color-2. 4.4.2. Inter-area Node Protection with > 2 Border Routers If there are more than two BRs between areas, then the problem of ensuring inter-area node-disjointness is not solved. Instead, once a request to join the multicast tree has been received by a BR from an area that isn't closest to the multicast source, the BR must join both the Red MT-ID and the Blue MT-ID in the area closest to the multicast source. Regardless of what single link or node failure happens, each BR will receive the multicast stream. Then, the BR can use the stream-selection techniques specified in [I-D.ietf-rtgwg-mofrr] to pick either the Blue or Red stream and forward it to downstream routers in the other area. Each of the BRs for the other area should be attached to a proxy-node representing the other area. This approach ensures that a BR will receive the multicast stream in the closest area as long as the single link or node failure isn't a single point of failure. Thus, each area or level is independently protected. The BR is required to be able to select among the multicast streams and, if necessary for PIM, translate the traffic to contain the correct (S,G) for forwarding. Atlas, et al. Expires January 13, 2014 [Page 16] Internet-Draft MRT FRR Architecture July 2013 4.5. PIM Capabilities need to be exchanged to determine that a neighbor supports using MRT forwarding topologies with PIM. Additional signaling extensions are not necessary to PIM to support Global Protection. [RFC6420] already defines how to specify an MT-ID as a Join Attribute. 4.5.1. Traffic Handling: RPF Checks For PIM, RPF checks would still be enabled by the control plane. The control plane can program different forwarding entries on the G-blue incoming interface and on the G-red incoming interface. The other interfaces would still discard both G-blue and G-red traffic. The receiver would still need to detect failures and handle traffic discarding as is specified in [I-D.ietf-rtgwg-mofrr]. 4.6. mLDP Capabilities need to be exchanged to determine that a neighbor supports using MRT forwarding topologies with mLDP. The basic mechansims for mLDP to support multi-topology are already described in [I-D.iwijnand-mpls-mldp-multi-topology]. It may be desirable to extend the capability defined in this draft to indicate that MRT is or is not supported. 5. Local Repair: Fast-Reroute Local repair for multicast traffic is different from unicast in several important ways. o There is more than a single final destination. The full set of receiving routers may not be known by the PLR and may be extremely large. Therefore, it makes sense to repair to the immediate next- hops for link-repair and the next-next-hops for node-repair. These are the potential merge points (MPs). o If a failure cannot be positively identified as a node-failure, then it is important to repair to the immediate next-hops since they may have receivers attached. o If a failure cannot be positively identified as a link-failure and node protection is desired, then it is important to repair to the next-next-hops since they may not receive traffic from the immediate next-hops. Atlas, et al. Expires January 13, 2014 [Page 17] Internet-Draft MRT FRR Architecture July 2013 o Updating multicast forwarding state may take significantly longer than updating unicast state, since the multicast state is updated tree by tree based on control-plane signaling. o For tunnel-based IP/LDP approaches, neither the PLR nor the MP may be able to specify which interface the alternate traffic will arrive at the MP on. The simplest reason is the unicast forwarding includes the use of ECMP and the path selection is based upon internal router behavior for all paths between the PLR and the MP. For multicast fast-reroute, there are three different mechanisms that can be used. As long as the necessary signaling is available, these methods can be combined in the same network and even for the same PLR and failure point. PLR-driven Unicast Tunnels: The PLR learns the set of MPs that need protection. On a failure, the PLR replicates the traffic and tunnels it to each MP using the unicast route. If desired, an RSVP-TE tunnel could be used instead of relying upon unicast routing. MP-driven Unicast Tunnels: Each MP learns the identity of the PLR. Before failure, each MP independently signals to the PLR the desire for protection and other information to use. On a failure, the PLR replicates the traffic and tunnels it to each MP using the unicast route. If desired, an RSVP-TE tunnel could be used instead of relying upon unicast routing. MP-driven Alternate Trees: Each MP learns the identity of the PLR and the failure point (node and interface) to be protected against. Each MP selects an upstream interface and forwarding topology where the path will avoid the failure point; each MP signals a join towards that upstream interface to create that state. Each of these options is described in more detail in their respective sections. Then the methods are compared and contrasted for PIM and for mLDP. 5.1. PLR-driven Unicast Tunnels With PLR-driven unicast tunnels, the PLR learns the set of merge points (MPs) and, on a locally detected failure, uses the existing unicast routing to tunnel the multicast traffic to those merge points. The failure being protected against may be link or node failure. If unicast forwarding can provide an SRLG-protecting alternate, then SRLG-protection is also possible. Atlas, et al. Expires January 13, 2014 [Page 18] Internet-Draft MRT FRR Architecture July 2013 There are five aspects to making this work. 1. PLR needs to learn the MPs and their associated MPLS labels to create protection state. 2. Unicast routing has to offer alternates or have dedicated tunnels to reach the MPs. The PLR encapsulates the multicast traffic and directs it to be forwarded via unicast routing. 3. The MP must identify alternate traffic and decide when to accept and forward it or drop it. 4. When the MP reconverges, it must move to its new UMH using make- before-break so that traffic loss is minimized. 5. The PLR must know when to stop sending traffic on the alternates. 5.1.1. Learning the MPs If link-protection is all that is desired, then the PLR already knows the identities of the MPs. For node-protection, this is not sufficient. In the PLR-driven case, there is no direct communication possible between the PLR and the next-next-hops on the multicast tree. (For mLDP, when targeted LDP sessions are used, this is considered to be MP-driven and is covered in Section 5.2.) In addition to learning the identities of the MPs, the PLR must also learn the MPLS label, if any, associated with each MP. For mLDP, a different label should be supplied for the alternate traffic; this allows the MP to distinguish between the primary and alternate traffic. For PIM, an MPLS label is used to identify that traffic is the alternate. The unicast tunnel used to send traffic to the MP may have penultimate-hop-popping done; thus without an explicit MPLS label, there is no certainty that a packet could be conclusively identified as primary traffic or as alternate traffic. A router must tell its UMH the identity of all downstream multicast routers, and their associated alternate labels, on the particular multicast tree. This clearly requires protocol extensions. The extensions for PIM are given in [I-D.kebler-pim-mrt-protection]. 5.1.2. Using Unicast Tunnels and Indirection The PLR must encapsulate the multicast traffic and tunnel it towards each MP. The key point is how that traffic then reaches the MP. There are basically two possibilities. It is possible that a dedicated RSVP-TE tunnel exists and can be used to reach the MP for just this traffic; such an RSVP-TE tunnel would be explicitly routed Atlas, et al. Expires January 13, 2014 [Page 19] Internet-Draft MRT FRR Architecture July 2013 to avoid the failure point. The second possibility is that the packet is tunneled via LDP and uses unicast routing. The second case is explored here. It is necessary to assume that unicast LDP fast-reroute [I-D.ietf-rtgwg-mrt-frr-architecture][RFC5714][RFC5286] is supported by the PLR. Since multicast convergence takes longer than unicast convergence, the PLR may have two different routes to the MP over time. When the failure happens, the PLR will have an alternate, whether LFA or MRT, to reach the MP. Then the unicast routing converges and the PLR will have a new primary route to the MP. Once the routing has converged, it is important that alternate traffic is no longer carried on the MRT forwarding topologies. This rule allows the MRT forwarding topologies to reconverge and be available for the next failure. Therefore, it is also necessary for the tunneled multicast traffic to move from the alternate route to the new primary route when the PLR reconverges. Therefore, the tunneled multicast traffic should use indirection to obtain the unicast routing's current next-hops to the MP. If physical indirection is not feasible, then when the unicast LIB is updated, the associated multicast alternate tunnel state should be as well. When the PLR detects a local failure, the PLR replicates each multicast packet, swaps or adds the alternate MPLS label needed by the MP, and finally pushes the appropriate label for the MP based upon the outgoing interface selected by the unicast routing. For PIM, if no alternate labels are supplied by the MPs, then the multicast traffic could be tunneled in IP. This would require unicast IP fast-reroute. 5.1.3. MP Alternate Traffic Handling A potential Merge Point must determine when and if to accept alternate traffic. There are two critical components to this decision. First, the MP must know the state of all links to its UMH. This allows the MP to determine whether the multicast stream could be received from the UMH. Second, the MP must be able to distinguish between a normal multicast tree packet and an alternate packet. The logic is similar for PIM and mLDP, but in PIM there is only one RPF-interface or interface of interest to the UMH. In mLDP, all the directly connected interfaces to the UMH are of interest. When the MP detects a local failure, if that interface was the last connected to the UMH and used for the multicast group, then the MP must rapidly switch from accepting the normal multicast tree traffic to accepting the alternate traffic. This rapid change must happen within the same approximately 50 milliseconds that the PLR switching to send traffic Atlas, et al. Expires January 13, 2014 [Page 20] Internet-Draft MRT FRR Architecture July 2013 on the alternate takes and for the same reasons. It does no good for the PLR to send alternate traffic if the MP doesn't accept it when it is needed. The MP can identify alternate traffic based upon the MPLS label. This will be the alternate label that the MP supplied to its UMH for this purpose. 5.1.4. Merge Point Reconvergence After a failure, the MP will want to join the multicast tree according to the new topology. It is critical that the MP does this in a way that minimizes the traffic disruption. Whenever paths change, there is also the possibility for a traffic-affecting event due to different latencies. However, traffic impact above that should be avoided. The MP must do make-before-break. Until the MP knows that its new UMH is fully connected to the MCI, the MP should continue to accept its old alternate traffic. The MP could learn that the new UMH is sufficient either via control-plane mechanisms or data-driven. In the latter case, the reception of traffic from the new UMH can trigger the change-over. If the data-driven approach is used, a time-out to force the switch should apply to handle multicast trees that have long quiet periods. 5.1.5. PLR termination of alternate traffic The PLR sends traffic on the alternates for a configurable time-out. There is no clean way for the next-hop routers and/or next-next-hop routers to indicate that the traffic is no longer needed. If better control were desired, each MP could tell its UMH what the desired time-out is. The UMH could forward this to the PLR as well. Then the PLR could send alternate traffic to different MPs based upon the MP's individual timer. This would only be an advantage if some of the MPs were expected to have a longer multicast reconvergence time than others - either due to load or router capabilities. 5.2. MP-driven Unicast Tunnels MP-driven unicast tunnels are only relevant for mLDP where targeted LDP sessions are feasible. For PIM, there is no mechanism to communicate beyond a router's immediate neighbors; these techniques could work for link-protection, but even then there would not be a way of requesting that the PLR should stop sending traffic. There are three differences for MP-driven unicast tunnels from PLR- Atlas, et al. Expires January 13, 2014 [Page 21] Internet-Draft MRT FRR Architecture July 2013 driven unicast tunnels. 1. The MPs learn the identity of the PLR from their UMH. The PLR does not learn the identities of the MPs. 2. The MPs create direct connections to the PLR and communicate their alternate labels. 3. When the MPs have converged, each explicitly tells the PLR to stop sending alternate traffic. The first means that a router communicates its UMH to all its downstream multicast hops. Then each MP communicates to the PLR(s) (1 for link-protection and 1 for node-protection) and indicates the multicast tree that protection is desired for and the associated alternate label. When the PLR learns about a new MP, it adds that MP and associated information to the set of MPs to be protected. On a failure, the PLR does the same behavior as for the PLR-driven unicast tunnels. After the failure, the MP reconverges using make-before-break. Then the MP explicitly communicates to the PLR(s) that alternate traffic is no longer needed for that multicast tree. When the node- protecting PLR hasn't changed for a MP, it may be necessary to withdraw the old alternate label, which tells the PLR to stop transmitting alternate traffic, and then provide a new alternate label. 5.3. MP-driven Alternate Trees In this document we have defined different solutions to achieve fast convergence for multicast link and node protection based on MRTs. At a high level these solutions can be separated in Local and Global protections. Alternate Trees, which is a Local protection schema, initially looked like an attractive solution for Multicast node protection since it avoids replicating the packet by the PLR to each of the receivers of the protected node and waisting bandwidth. However, this comes at the expense of extra multicast state and complexity. In order to mitigate the extra multicast state its possible to aggregate the Alternate Trees by creating an Alternate Tree per protected node and reuse it for all the multicast trees going through this node. This further complicates the procedures and upstream assigned labels are required to de-aggregate the trees. With aggregation we are also introducing an unwanted side effect. The receiver population of the aggregated trees will very likely not be the same. That means multicast packets will be forwarded on the Alternate Tree to node(s) that may not have a receiver(s) for the Atlas, et al. Expires January 13, 2014 [Page 22] Internet-Draft MRT FRR Architecture July 2013 protected tree. The more protected trees are aggregated, the higher the risk of forwarding unwanted multicast packets, this leads again to waisting bandwidth. Considering the complexity of this solution and the unwanted side- effects, the authors of this document believe its better to solve Multicast node protection using a Global protection schema, as documented in Section 4. The solution previously defined in this section has been move to Appendix A (Section 9). 6. Acknowledgements The authors would like to thank Kishore Tiruveedhula, Santosh Esale, and Maciek Konstantynowicz for their suggestions and review. 7. IANA Considerations This doument includes no request to IANA. 8. Security Considerations This architecture is not currently believed to introduce new security concerns. 9. Appendix A 9.1. MP-driven Alternate Trees For some networks, it is highly desirable not to have the PLR perform replication to each MP. PLR replication can cause substantial congestion on links used by alternates to different MPs. At the same time, it is also desirable to have minimal extra state created in the network. This can be resolved by creating alternate-trees that can protect multiple multicast groups as a bypass-alternate-tree. An alternate-tree can also be created per multicast group, PLR and failure point. It is not possible to merge alternate-trees for different PLRs or for different neighbors. This is shown in Figure 4 where G can't select an acceptable upstream node on the alternate tree that doesn't violate either the need to avoid C (for PLR A) or D (for PLR B). Atlas, et al. Expires January 13, 2014 [Page 23] Internet-Draft MRT FRR Architecture July 2013 |-------[S]--------| Alternate from A must avoid C V V Alternate from B ust avoid D [A]------[E]-------[B] | | | V | V |--[C]------[F]-------[D]---| | | | | | |-------[G]--------| | | | | | | | |->[R1]-----[H]-------[R2]<-| (a) Multicast tree from S S->A->C->R1 and S->B->D->R2 Figure 4: Alternate Trees from PLR A and B can't be merged A MP that joins an alternate-tree for a particular multicast stream should not expect or request PLR-replicated tunneled alternate traffic for that same multicast stream. Each alternate-tree is identified by the PLR which sources the traffic and the failure point (node and link) (FP) to be avoided. Different multicast groups with the same PLR and FP may have different sets of MPs - but they are all at most going to include the FP (for link protection) and the neighbors of FP except for the PLR. For a bypass-alternate-tree to work, it must be acceptable to temporarily send a multicast group's traffic to FP's neighbors that do not need it. This is the trade-off required to reduce alternate- tree state and use bypass-alternate-trees. As discussed in Section 5.1.3, a potential MP can determine whether to accept alternate traffic based upon the state of its normal upstream links. Alternate traffic for a group the MP hasn't joined can just be discarded. [S]......[PLR]--[ A ] | | | 1| |2 | [ FP]--[MP3] | \ | | \ | [MP1]--[MP2] Figure 5: Alternate Tree Scenario Atlas, et al. Expires January 13, 2014 [Page 24] Internet-Draft MRT FRR Architecture July 2013 For any router, knowing the PLR and the FP to avoid will force selection of either the Blue MRT or the Red MRT. It is possible that the FP doesn't actually appear in either MRT path, but the FP will always be in either the set of nodes that might be used for the Blue MRT path or the set of nodes that might be used for the Red MRT path. The FP's membership in one of the sets is a function of the partial ordering and topological ordering created by the MRT algorithm and is consistent between routers in the network graph. To create an alternate-tree, the following must happen: 1. For node-protection, the MP learns from its upstream (the FP) the node-id of its upstream (the PLR) and, optionally, a link identifier for the link used to the PLR. The link-id is only needed for traffic handling in PIM, since mLDP can have targeted sessions between the MP and the PLR. 2. For link-protection, the MP needs to know the node-id of its upstream (the PLR) and, optionally, its identifier for the link used to the PLR. 3. The MP determines whether to use the Blue or Red forwarding topology to reach the PLR while avoiding the FP and associated interface. This gives the MP its alternate-tree upstream interface. 4. The MP signals a backup-join to its alternate-tree upstream interface. The backup-join specifies the PLR, FP and, for PIM, the FP-PLR link identifier. If the alternate-tree is not to be used as a bypass-alternate-tree, then the multicast group (e.g. (S,G) or Opaque-Value) must be specified. 5. A router that receives a backup-join and is not the PLR needs to create multicast state and send a backup-join towards the PLR on the appropriate Blue or Red forwarding topology as is locally determined to avoid the FP and FP-PLR link. 6. Backup-joins for the same (PLR, FP, PLR-FP link-id) that reference the same multicast group can be merged into a single alternate-tree. Similarly, backup-joins for the same (PLR, FP, PLR-FP link-id) that reference no multicast group can be merged into a single alternate-tree. 7. When the PLR receives the backup-join, it associates either the specified multicast group with that alternate-tree, if such is given, or associates all multicast groups that go to the FP via the specified FP-PLR link with the alternate-tree. Atlas, et al. Expires January 13, 2014 [Page 25] Internet-Draft MRT FRR Architecture July 2013 For an example, look at Figure 5. FP would send a backup-join to MP3 indicating (PLR, FP, PLR-FP link-1). MP3 sends a backup-join to A. MP1 sends a backup-join to MP2 and MP2 sends a backup-join to MP3. It is necessary that traffic on each alternate-tree self-identify as to which alternate-tree it is part of. This is because an alternate- tree for a multicast-group and a particular (PLR, FP, PLR-FP link-id) can easily overlap with an alternate-tree for the same multicast group and a different (PLR, FP, PLR-FP link-id). The best way of doing this depends upon whether PIM or mLDP is being used. 9.1.1. PIM details for Alternate-Trees For PIM, the (S,G) of the IP packet is a globally unique identifier and is understood. To identify the alternate-tree, the most straightforward way is to use MPLS labels distributed in the PIM backup-join messages. A MP can use the incoming label to indicate the set of RPF-interfaces for which the traffic may be an alternate. If the alternate-tree isn't a bypass-alternate-tree, then only one RPF interface is referenced. If the alternate-tree is a bypass- alternate-tree, then multiple RPF-interfaces (parallel links to FP) might be intended. Alternate-tree traffic may cross an interface multiple times - either because the interface is a broadcast interface and different downstream-assigned labels are provided and/or because a MP may provide different labels. 9.1.2. mLDP details for Alternate-Trees For mLDP, if bypass-alternate-trees are used, then the PLR must provide upstream-assigned labels to each multicast stream. The MP provides the label for the alternate-tree; if the alternate-tree is not a bypass-alternate-tree, this label also describes the multicast stream. If the alternate-tree is a bypass-alternate-tree, then it provides the context for the PLR-assigned labels for each multicast stream. If there are targeted LDP sessions between the PLR and the MPs, then the PLR could provide the necessary upstream-assigned labels. 9.1.3. Traffic Handling by PLR An issue with traffic is how long should the PLR continue to send alternate traffic out. With an alternate-tree, the PLR can know to stop forwarding alternate traffic on the alternate-tree when that alternate-tree's state is torn down. This provides a clear signal that alternate traffic is no longer needed. Atlas, et al. Expires January 13, 2014 [Page 26] Internet-Draft MRT FRR Architecture July 2013 9.2. Methods Compared for PIM The two approaches that are feasible for PIM are PLR-driven Unicast Tunnels and MP-driven Alternate-Trees. +-------------------------+-------------------+---------------------+ | Aspect | PLR-driven | MP-driven | | | Unicast Tunnels | Alternate-Trees | +-------------------------+-------------------+---------------------+ | Worst-case Traffic | 1 + number of MPs | 2 | | Replication Per Link | | | | PLR alternate-traffic | timer-based | control-plane | | | | terminated | | Extra multicast state | none | per (PLR,FP,S) for | | | | bypass mode | +-------------------------+-------------------+---------------------+ Which approach is prefered may be network-dependent. It should also be possible to use both in the same network. 9.3. Methods Compared for mLDP All three approaches are feasible for mLDP. Below is a brief comparison of various aspects of each. +-------------------+---------------+-------------+-----------------+ | Aspect | MP-driven | PLR-driven | MP-driven | | | Unicast | Unicast | Alternate-Trees | | | Tunnels | Tunnels | | +-------------------+---------------+-------------+-----------------+ | Worst-case | 1 + number of | 1 + number | 2 | | Traffic | MPs | of MPs | | | Replication Per | | | | | Link | | | | | PLR | control-plane | timer-based | control-plane | | alternate-traffic | terminated | | terminated | | Extra multicast | none | none | per (PLR,FP,S) | | state | | | for bypass mode | +-------------------+---------------+-------------+-----------------+ 10. References 10.1. Normative References [I-D.enyedi-rtgwg-mrt-frr-algorithm] Atlas, A., Envedi, G., Csaszar, A., and A. Gopalan, "Algorithms for computing Maximally Redundant Trees for Atlas, et al. Expires January 13, 2014 [Page 27] Internet-Draft MRT FRR Architecture July 2013 IP/LDP Fast- Reroute", draft-enyedi-rtgwg-mrt-frr-algorithm-03 (work in progress), July 2013. [I-D.ietf-rtgwg-mrt-frr-architecture] Atlas, A., Kebler, R., Envedi, G., Csaszar, A., Tantsura, J., Konstantynowicz, M., White, R., and M. Shand, "An Architecture for IP/LDP Fast-Reroute Using Maximally Redundant Trees", draft-ietf-rtgwg-mrt-frr-architecture-03 (work in progress), July 2013. [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC4601, August 2006. [RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point-to- Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC6388, November 2011. [RFC6420] Cai, Y. and H. Ou, "PIM Multi-Topology ID (MT-ID) Join Attribute", RFC6420, November 2011. 10.2. Informative References [I-D.ietf-rtgwg-mofrr] Karan, A., Filsfils, C., Farinacci, D., Wijnands, I., Decraene, B., Joorde, U., and W. Henderickx, "Multicast only Fast Re-Route", draft-ietf-rtgwg-mofrr-02 (work in progress), June 2013. [I-D.iwijnand-mpls-mldp-multi-topology] Wijnands, I. and K. Raza, "mLDP Extensions for Multi Topology Routing", draft-iwijnand-mpls-mldp-multi-topology-03 (work in progress), June 2013. [I-D.kebler-pim-mrt-protection] Kebler, R., Atlas, A., Wijnands, IJ., and G. Enyedi, "PIM Extensions for Protection Using Maximally Redundant Trees", draft-kebler-pim-mrt-protection-00 (work in progress), March 2012. [I-D.wijnands-mpls-mldp-node-protection] Wijnands, I., Rosen, E., Raza, K., Tantsura, J., Atlas, A., and Q. Zhao, "mLDP Node Protection", draft-wijnands-mpls-mldp-node-protection-04 (work in progress), June 2013. Atlas, et al. Expires January 13, 2014 [Page 28] Internet-Draft MRT FRR Architecture July 2013 [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast Reroute: Loop-Free Alternates", RFC5286, September 2008. [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC5714, January 2010. Authors' Addresses Alia Atlas (editor) Juniper Networks 10 Technology Park Drive Westford, MA 01886 USA Email: firstname.lastname@example.org Robert Kebler Juniper Networks 10 Technology Park Drive Westford, MA 01886 USA Email: email@example.com IJsbrand Wijnands Cisco Systems, Inc. Email: firstname.lastname@example.org Andras Csaszar Ericsson Konyves Kalman krt 11 Budapest 1097 Hungary Email: Andras.Csaszar@ericsson.com Atlas, et al. Expires January 13, 2014 [Page 29] Internet-Draft MRT FRR Architecture July 2013 Gabor Sandor Enyedi Ericsson Konyves Kalman krt 11. Budapest 1097 Hungary Email: Gabor.Sandor.Enyedi@ericsson.com Atlas, et al. Expires January 13, 2014 [Page 30]