PIM Extensions for Protection Using Maximally Redundant Trees
Author(s): Yiqun Cai, Naiming Shen, Robert Kebler, Alia Atlas
This document specifies Protocol Independent Multicast (PIM) procedures for Failure Protection, as specified in the MRT Multicast architecture [I-D.atlas-rtwg-mrt-mc-arch]. This can be accomplished with Global Repair (aka Live-Live) or with Local Repair (aka Fast Re- route). Maximally Redundant...
Protocol Independent Multicast Working Group R. Kebler, Ed. Internet-Draft A. Atlas Intended status: Standards Track Juniper Networks Expires: January 13, 2014 N. Shen Cisco Systems, Inc. Y. Cai Microsoft July 12, 2013 PIM Extensions for Protection Using Maximally Redundant Trees draft-kebler-pim-mrt-protection-01 Abstract This document specifies Protocol Independent Multicast (PIM) procedures for Failure Protection, as specified in the MRT Multicast architecture [I-D.atlas-rtwg-mrt-mc-arch]. This can be accomplished with Global Repair (aka Live-Live) or with Local Repair (aka Fast Re- route). Maximally Redundant Trees (MRTs) provide the capability to PIM to provide alternate paths around any given failure. 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." 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 Kebler, et al. Expires January 13, 2014 [Page 1] Internet-Draft PIM Protection using MRTs July 2013 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Global Protection (Live-Live) . . . . . . . . . . . . . . . . 4 3.1. Egress Router Behavior . . . . . . . . . . . . . . . . . 4 3.2. Limitation when a LAN is a cut-link . . . . . . . . . . . 4 3.3. Using Different Groups to identify MRTs . . . . . . . . . 5 4. Local Protection . . . . . . . . . . . . . . . . . . . . . . 5 4.1. PLR Replication . . . . . . . . . . . . . . . . . . . . . 5 4.1.1. PLR Behavior . . . . . . . . . . . . . . . . . . . . 6 4.1.2. Unicast convergence during PLR Replication . . . . . 6 4.1.3. MP Behavior . . . . . . . . . . . . . . . . . . . . . 6 4.1.4. Downstream Routers from the MP . . . . . . . . . . . 7 4.1.5. Protected Node Behavior . . . . . . . . . . . . . . . 7 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Hello Options . . . . . . . . . . . . . . . . . . . . . . 8 5.1.1. MRT Protection Capabilities . . . . . . . . . . . . . 8 5.2. Join Attributes . . . . . . . . . . . . . . . . . . . . . 9 5.2.1. Merge Point Attribute . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction This document specifies how to reduce traffic loss after network failures by using Maximally Redundant Trees (MRTs). This can be accomplished with Global Repair (aka Live-Live) or with Local Repair (aka Fast Re-route). The tradeoffs and applicability for each method of protection are discussed in the MRT Multicast architecture [I-D.atlas-rtwg-mrt-mc-arch]. With Global Repair, a multicast egress will send PIM Joins for the same stream on multiple MRT topologies. The Global Repair specified in this document is similar to [I-D.ietf-rtgwg-mofrr]. This document specifies how this can be accomplished using MRTs, however, providing 100% coverage without requiring any particular network topology. Kebler, et al. Expires January 13, 2014 [Page 2] Internet-Draft PIM Protection using MRTs July 2013 Local Repair for Link or Node protection can also be used to protect Multicast traffic. A Point of Local Repair (PLR) can replicate the traffic to all Merge Points (MPs). In order to accomplish this, the PLR must know the unicast destination of all MPs. Upon the failure, the PLR will send the traffic to all MPs. 2. Terminology 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. 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. 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. 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. Kebler, et al. Expires January 13, 2014 [Page 3] Internet-Draft PIM Protection using MRTs July 2013 MT-ID: Multi-topology identifier 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 as described in [I-D.ietf-rtgwg-mofrr]. MultiCast Egress (MCE): Multicast Egress, a node where the multicast stream exists the current PIM domain. This is usually a receiving router that may forward the multicast traffic towards receivers based upon IGMP or other technology. 3. Global Protection (Live-Live) In order to achieve Global Protection, traffic will flow through the network through disjoint paths. A multicast egress (MCE) router will trigger this traffic flow by sending PIM joins on two different interfaces. The MRT algorithm will ensure that these joins travel through maximally disjoint paths to the source. The egress router must then forward a single stream along to its downstream members. Any failure in the network to either stream can be repaired by this egress router, since it is receiving the redundant stream. Any router that is capable of supporting Global Repair with MRTs must advertise the T bit in the MRT Protection Hello Option. 3.1. Egress Router Behavior A multicast egress (MCE) router will join a multicast stream on both the Blue and Red MRT. The MT-ID [RFC6420] of the MRT will be included in the Join as a Join Attribute [RFC5384]. Traffic will flow down both MRTs to the egress router to achieve redundancy. The egress router will forward a single stream along to its downstream interfaces. The techniques for this stream selection are described in MoFRR [I-D.ietf-rtgwg-mofrr]. 3.2. Limitation when a LAN is a cut-link There is a limitation in end-to-end protection when, for a given S,G, the MRTs converge on a single LAN with different upstream neighbors. In this case, both upstream neighbors will be sending on the LAN, and there is no distinguishing the data traffic for the different MRTs if it is carried with the same S,G. The PIM Assert procedures will select a single forwarding router on the LAN and the other router will stop sending. This could cause the Assert Loser to prune back the S,G. Therefore, traffic will flow on only one MRT between the source and the downstream router on the LAN. Kebler, et al. Expires January 13, 2014 [Page 4] Internet-Draft PIM Protection using MRTs July 2013 3.3. Using Different Groups to identify MRTs There may be cases when different sources or groups are used to send the same stream, as decribed in the MRT Multicast architecture [I-D.atlas-rtwg-mrt-mc-arch]. In this case the egress router may not need to perform the stream selection. However, it would be desirable for the egress router to join the sources or groups on different MRTS. The mechanism to perform group to MRT mapping is outside the scope of this document. Once the egress router knows the group to MRT mapping, then it will join for the S,G on the particular tree by including the MT-ID for the MRT in the Join message. In this case, the streams can travel across the same LAN without the issues described above. 4. Local Protection Local Protection can protect either a link or node, and this will be determined on a per flow basis. A Join Attribute will be used for downstream routers to signal the Merge Point information. Each router will advertise in its MRT Protection Hello Options whether it is capable of performing Link or Node protection. 4.1. PLR Replication At a PLR, each S,G flow will have a set of downstream interfaces and a set of MPs for each downstream interface. There will be MPLS label information learned for each MP. Upon a failure to the protected link, the PLR will encapsulate and send the protected multicast traffic to all MPs for that particlar (S,G,intf). The MP will, therefore, receive the encapsulated data upon the failure and traffic will resume to all of its downstream receivers. Once the PLR has given the downstream routers sufficient time to recover from the failure, it can stop sending the protected traffic, and prune upstream, if required. For the PLR to send the protected traffic upon a failure, it requires the unicast address and an MPLS label (which may be Implicit Null) for all the Merge Points. Each MP will advertise this information in a Merge Point Join Attribute. If link protection is used, this is sufficient to reach the PLR. For node protection, the information for all MPs will be sent to the PLR in a Join Attribute from the upstream node of the MP (i.e., the Protected Node). In this case, the MP will set the N bit in these Join Attributes to indicate the Protected Node needs to send the Join Attribute upstream to the PLR. If the MP or the Protecting Node is sending the Join attribute to the PLR, it will set the P bit in the Join Attribute. Kebler, et al. Expires January 13, 2014 [Page 5] Internet-Draft PIM Protection using MRTs July 2013 All routers that support this functionality will advertise the Link or Node capability bits in the MRT Protection Hello Option. Any Node that is capable of acting as a PLR will advertise the PLR-Replication capable bit in the MRT Protection Hello Option. 4.1.1. PLR Behavior The PLR will learn the location of all the MPs in the its Join Messages that it receives from downstream routers. The Merge Points will be kept per (S,G, downstream-interface). Upon a failure to the protected interface, the PLR will encapsulate and forward the multicast data to all the MPs for that downstream interface, and it will start the Alternate-Tree-Protection-Timer. The Alternate-Tree- Protection-Timer should be a configurable timer with a default of 10 seconds. The PLR will suppress the PIM Prunes from being sent while the Protection-Timer is running. Once this timer expires, it will stop sending the traffic to MPs, and it can send a Prune upstream if required. For a PLR to learn of all MPs, then Join Suppression must be disabled on the interfaces between the MP and the PLR. In addition, the PLR must accept all MP ID Join Attributes that it receives from downstream neighbors. 4.1.2. Unicast convergence during PLR Replication Since it is likely for unicast routes to converge before PIM fully converges, the PLR must still be able to route the traffic to all MPs while unicast recovers from the original failure. The PLR must not use stale forwarding information to reach the MPs for the protected multicast traffic if unicast has already updated it forwarding entries after the network event. An implementation should use the same forwarding information that would be used to forward unicast traffic to that destination. In this way, the PLR will be able to forward traffic to the MPs. 4.1.3. MP Behavior As is done today, the MP will forward traffic received on its normal incoming interface. While the normal RPF interface is up, encapulated alternate traffic will not be forwarded. If the RPF interface fails, the MP will forward the encapulated alternate traffic (if it is received with the correct encapsulation). This procedure assumes that there is a method for the routers on both sides of the protected link to determine if the link has gone down. Such methods are outside the scope of this document. Kebler, et al. Expires January 13, 2014 [Page 6] Internet-Draft PIM Protection using MRTs July 2013 After the incoming interface changes the MP will start the Alternate- Tree-Protection-Timer. Once traffic arrives on the new incoming interface or the Alternate-Tree-Protection-Timer expires, the Merge Point will advertise the label for the new RPF interface in the Merge Point Join Attribute, and it will stop accepting the encapsulated alternate traffic. The MP needs to know when it can release the label that it has advertised and potentially re-use that label for another purpose. If the interface goes down or the adjacency goes down on an interface that the MP was advertising a label, it should wait JP_Holdtime for link protection and (2 * JP_Holdtime) for node protection before re- using that label for any other purpose. 4.1.4. Downstream Routers from the MP Some make-before-break techniques should be used on routers downstream from the failure to ensure that traffic is not discarded once these routers learn of the unicast change. For example, if a downstream router, upon a unicast route change, prunes itself off its old RPF interface and discards traffic until the new tree is formed back to the source, then there will be end-to-end loss. The work that the upstream routers did to repair the local failure will be wasted since the downstream router is going to discard flowing traffic. The make-before-breaks procedures needed on the downstream router is outside the scope of this document. 4.1.5. Protected Node Behavior Kebler, et al. Expires January 13, 2014 [Page 7] Internet-Draft PIM Protection using MRTs July 2013 For Node Protection, the MP will be one hop away from the Protected Node and two hops away from the PLR. In this case, there may be multiple next-next-hops to advertise as Merge Points in the Join Attribute. The Protected Node will learn the downstream members and it will gather the MP information from each downstream neighbor's Merge Point Join Attribute. For each Merge Point in the downstream list, the Protected Node will include a Merge Point Join Attribute in the Join that is sent upstream to the PLR. These Join attributes must have the N bit cleared when they are sent to the PLR. The PLR will add a Merge Point attribute for its own information to include itself as a Merge Point. All the Join attributes will have the P bit set, indicating they are being sent to a PLR. The Merge Point information may change for a route entry before the JoinPrune would normally be updated or refreshed to the PLR. Upon a change to the next-next hop list, the router can send a triggered JoinPrune with the updated Join Attribute, or it can wait for the next periodic refresh. It would be a tradeoff of increased control messages against a window of being unprotected. For a PLR to learn of all MPs, then Join Suppression must be disabled on the interfaces between the MP and the PLR. 5. Packet Formats 5.1. Hello Options 5.1.1. MRT Protection Capabilities 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = TBD | Length = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsvd |P|T|L|N| +-+-+-+-+-+-+-+-+ MRT Protection Hello Option Format Type: TBD. Length: 1 Rsvd: Sent with 0, ignored on receipt Kebler, et al. Expires January 13, 2014 [Page 8] Internet-Draft PIM Protection using MRTs July 2013 P: PLR Replication capable. This bit is set if a router is capable of acting as a PLR-replicating router, as described in this document. This router must also be capable of receiving a Merge Point Join Attribute. T: MRT Topology Capable. This bit is set if the router is capable of understanding MRT topology IDs sent in the MT-ID Join Attribute [RFC5384], as defined in this document. L: Link Protection Capable. This bit is set if the router is capable of performing Link Protection, as defined in this document. This router must also be capable of receiving a Merge Point Join Attribute. N: Node Protection. This bit is set if the router is capable of performing Node Protection, as defined in this document. This router must also be capable of receiving a Merge Point Join Attribute. 5.2. Join Attributes 5.2.1. Merge Point Attribute The following Join attribute is used for local protection, when the Protected-Node needs to signal the Merge Point information to the PLR. There will be a separate Merge Point Attribute for each Merge Point being advertised for the source. This attribute should only be sent to routers that are Link or Node capable, as advertised in the MRT Protection Hello Option. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|E| Type | Length |N|P| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Merge Point Join Attribute F-bit: This bit will be clear as this is a non-transitive attribute. Kebler, et al. Expires January 13, 2014 [Page 9] Internet-Draft PIM Protection using MRTs July 2013 E-bit: As defined in [RFC5384] Type: TBD Length field: variable N bit - This Label is for a node-protecting MP. The label and this Join attribute will need to be sent upstream (to the PLR) in the upstream Join message. When sending this Join attribute upstream, this bit MUST be cleared. P bit - This bit indicates that the receiving router should act as a PLR. This bit should only be set in Joins to routers that are PLR-Replication capable, as advertised in the MRT Protection Hello Option Reserved: Sent with zero, ignored on receipt label: the MPLS label associated with this MP MP: The encoded-Unicast addresses of the Merge Point 6. IANA Considerations A new PIM Hello Option type is requested to assign to the MRT Protection Hello Option A new PIM Join Attribute Type is requested for the Merge Point Join Attribute 7. Security Considerations There are no security considerations for this design other than what is already in the main PIM specification [RFC4601] . 8. References 8.1. Normative 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. [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC4601, August 2006. Kebler, et al. Expires January 13, 2014 [Page 10] Internet-Draft PIM Protection using MRTs July 2013 [RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol Independent Multicast (PIM) Join Attribute Format", RFC 5384, November 2008. [RFC6395] Gulrajani, S. and S. Venaas, "An Interface Identifier (ID) Hello Option for PIM", RFC6395, October 2011. [RFC6420] Cai, Y. and H. Ou, "PIM Multi-Topology ID (MT-ID) Join Attribute", RFC6420, November 2011. 8.2. Informative References [I-D.atlas-rtwg-mrt-mc-arch] Atlas, A., Kebler, R., Wijnands, IJ., and G. Enyedi, "An Architecture for Multicast Protection Using Maximally Redundant Trees", atlas-rtwg-mrt-mc-arch-02 (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-02 (work in progress), February 2013. Authors' Addresses Robert Kebler (editor) Juniper Networks 10 Technology Park Drive Westford, MA 01886 USA Email: firstname.lastname@example.org Alia Atlas Juniper Networks 10 Technology Park Drive Westford, MA 01886 USA Email: email@example.com Kebler, et al. Expires January 13, 2014 [Page 11] Internet-Draft PIM Protection using MRTs July 2013 Naiming Shen Cisco Systems, Inc. 170 W. Tasman Drive San Jose, CA 95134 USA Email: firstname.lastname@example.org Yiqun Cai Microsoft La Avenida Mountain View, CA 94043 USA Email: email@example.com Kebler, et al. Expires January 13, 2014 [Page 12]