Protocol Independent Multicast Working R. Kebler, Ed. Group A. Atlas Internet-Draft Juniper Networks Intended status: Standards Track N. Shen Expires: August 19, 2013 Cisco Systems, Inc. Y. Cai Microsoft February 15, 2013 PIM Extensions for Protection Using Maximally Redundant Trees draft-kebler-pim-mrt-protection-00 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-00]. 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 August 19, 2013. 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 Kebler, et al. Expires August 19, 2013 [Page 1] Internet-Draft PIM Protection using MRTs February 2013 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Global Protection (Live-Live) . . . . . . . . . . . . . . . . 4 3.1. Egress Router Behavior . . . . . . . . . . . . . . . . . . 5 3.2. Limitation when a LAN is a cut-link . . . . . . . . . . . 5 3.3. Using Different Groups to identify MRTs . . . . . . . . . 5 4. Local Protection . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. PLR Replication . . . . . . . . . . . . . . . . . . . . . 6 4.1.1. PLR Behavior . . . . . . . . . . . . . . . . . . . . . 6 4.1.2. Unicast convergence during PLR Replication . . . . . . 7 4.1.3. MP Behavior . . . . . . . . . . . . . . . . . . . . . 7 4.1.4. Downstream Routers from the MP . . . . . . . . . . . . 8 4.1.5. Protected Node Behavior . . . . . . . . . . . . . . . 8 4.2. MP-Initiated Alternate Trees . . . . . . . . . . . . . . . 8 4.2.1. Building the Backup Trees . . . . . . . . . . . . . . 9 4.2.2. PLR behavior . . . . . . . . . . . . . . . . . . . . . 10 4.2.3. MP behavior . . . . . . . . . . . . . . . . . . . . . 10 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Hello Options . . . . . . . . . . . . . . . . . . . . . . 11 5.1.1. MRT Protection Capabilities . . . . . . . . . . . . . 11 5.1.2. MP ID For PLR Replication . . . . . . . . . . . . . . 12 5.2. Join Attributes . . . . . . . . . . . . . . . . . . . . . 12 5.2.1. Merge Point Attribute . . . . . . . . . . . . . . . . 12 5.2.2. MRT Backup Attribute . . . . . . . . . . . . . . . . . 13 5.2.3. Upstream Address Join Attribute . . . . . . . . . . . 15 5.3. Encoded-Source Address Changes . . . . . . . . . . . . . . 16 5.4. New PIM Message Types . . . . . . . . . . . . . . . . . . 17 5.4.1. Join Response . . . . . . . . . . . . . . . . . . . . 17 5.4.2. PIM Backup JoinPrunes . . . . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Kebler, et al. Expires August 19, 2013 [Page 2] Internet-Draft PIM Protection using MRTs February 2013 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-00]. 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.karan-mofrr]. This document specifies how this can be accomplished using MRTs, however, providing 100% coverage without requiring any particular network topology. 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. An alternative to PLR replication is for the MPs to join an alternate tree to be used upon a network failure. For Node Protection, additional signaling is required for the MPs to learn of the PLR. Extensions are also needed to distinguish a backup Join and to signal the additional information required to specify the particular alternate tree. Upon a failure to the primary RPF interface, the MP will forward traffic from the alternate tree. 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 Kebler, et al. Expires August 19, 2013 [Page 3] Internet-Draft PIM Protection using MRTs February 2013 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. 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.karan-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 Kebler, et al. Expires August 19, 2013 [Page 4] Internet-Draft PIM Protection using MRTs February 2013 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.karan-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. 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-00]. 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. Two extra bits will be used from the Encoded-Source Address in the Join-Prune messages to indicate whether the source in the Join/Prune should have link or node protection. Kebler, et al. Expires August 19, 2013 [Page 5] Internet-Draft PIM Protection using MRTs February 2013 Each router will advertise in its MRT Protection Hello Options whether it is capable of performing Link or Node protection. Two methods of Local Protection are discussed in this document. The first method is when the PLR sends the traffic to be protected to all Merge Points. Also, there is a second method to reduce the replication burden on the PLR. With this method, alternate multicast trees are built from the MPs to the PLR. These methods are described in subsequent sections. 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 new MP ID Hello Option. 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). 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 (for node protection) and Hello Messages (for link protection) 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 Kebler, et al. Expires August 19, 2013 [Page 6] Internet-Draft PIM Protection using MRTs February 2013 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. 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, 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 (Protection- Timeout + PLR_Propagation_Delay) seconds before re-using that label for any other purpose. If the MP wants to change the label that is was advertising on a particular interface, it should wait (2*Hello_timer + 2*JoinPrune_Timer) before re-using the old label. Kebler, et al. Expires August 19, 2013 [Page 7] Internet-Draft PIM Protection using MRTs February 2013 4.1.4. Downstream Routers from the MP Some make-before-break techniques must 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 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 Hello Options. 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. 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. 4.2. MP-Initiated Alternate Trees In order to reduce the load of replication to all Merge Points on the PLR, alternate trees can be signaled from the MP to the PLR. The MP needs to learn the address of the PLR and then signal the Join towards the PLR, avoiding the node or link that is to be protected. An alternate multicast tree is formed from the MP to the PLR, avoiding the Protected Node/Link. Upon the failure, the PLR will use this alternate tree to forward the data to all MPs. The MP can prune itself off the alternate tree once it reconverges after the failure, and no longer needs the alternate tree to the given PLR. Any node that is capable of supporting MP-initiated Backup Trees must set the Backup-Join capable bit, the Join-Response Capable bit, and at least one of the node protection or link protection capable bits in the MRT Protection Hello Option. The PLR needs to advertise an Kebler, et al. Expires August 19, 2013 [Page 8] Internet-Draft PIM Protection using MRTs February 2013 Interface Identifier in the Interface Identifier Hello Option as specified in [RFC6395]. The Router Identifier of this message may be set to 0. 4.2.1. Building the Backup Trees The MP will send the Join to it upstream neighbor and indicate in the Join that it wants to do Node Protection or Link Protection. If Link Protection is used then the MP has the address and interface id (from the Interface Identifier Hello Option) of the PLR . If node Protection is used, then the upstream node of the MP is the Protected Node. If the MP supports Join Responses, as advertised in the MRT Protection Hello Option, then the Protected Node must send a Join Response to the MP. This Join Response has the same format as the JoinPrune. For each source that requires node protection, the Protected Node will include an Upstream Address Join Attribute with the address of the PLR and the interface id advertised in the Interface Identifier Hello Option of the RPF interface towards the PLR. PIM will consult the MRIB to obtain the the alternate upstream neighbor towards the PLR, given the node or link that it is trying to avoid. The MP will send a Backup Join to to this alternate upstream neighbor and it will include a MRT Backup Join Attribute. The Backup MRT Join attribute contains the PLR, the Protected-Node, the Protected-Link, and the MPLS label. There will be a unique MPLS label per backup tree. Additionally, the MP will include a MT-ID Join Attribute [RFC6420] in the Backup Join indicating the MRT that it expects to use to reach the PLR, avoiding the Protected-Node. The Backup Join state must be maintained per (S,G,PLR,Protected- Node,Protected Interface). If there is at least one downstream receiver for a given per (S,G,PLR,Protected-Node,Protected Interface), and the Join state is for the same MRT that this router would use to reach the PLR, avoiding the Protected-Node, then this router should propagate its Join upstream. The MRT of the downstream receivers should match this router's MRT to reach the PLR, except during transition events. If the MRTs are different, then the router will wait until it converges or waits until it receives a new Backup Join, indicating the correct MRT. Once the last downstream receiver prunes from the (S,G,PLR,Protected- Node,Protected Interface), then the router should Prune upstream. Each router will propagate the same PLR, protected-node, and protect- link info in the Backup MRT Join Attribute that it sends upstream. Each router will also advertise a label in the Backup MRT Join Attribute. The router will do a PLR, Protected-Node, Protected-link lookup to label lookup to determine the label that it should use. Kebler, et al. Expires August 19, 2013 [Page 9] Internet-Draft PIM Protection using MRTs February 2013 How this mapping is performed is outside the scope of this document. Join Suppression is only allowed if a downstream router detects another Backup Join for the same (S,G,PLR,Protected-Node,Protected- Interface,label). Otherwise the downstream router must not suppress its own Backup Join. The S,G in the Backup Join can be wildcard sources and groups. For example, if a MP wants to protect all multicast groups, then it will set the Source to 0/0 and the Group to 224/4. The MP can also specify more specific S,G's in the Backup Join. For each S,G that needs to be protected in upon a failure, the PLR will match the S,G to the most specific backup Join entry when determining the MPs. Thus, The MPs must all be in agreement if a more specific backup Join is going to be signaled for a particular S,G. This would be accomplished, most likely, with consistent configuration on each of the MPs. 4.2.2. PLR behavior Upon a failure to the downstream interface, the PLR will send traffic on the Alternate Tree that is protecting this interface, and it will start the Alternate-Tree-Protection-Timer for the S,G. The PLR will not Prune back on its upstream, even if this is the last interface in the outgoing list, while the Alternate-Tree-Protection-Timer is running. If all the downstream members of the Protection Tree Prune themselves, then the PLR can expire the Alternate-Tree-Protection- Timer. Once this timer expires, then the PLR will stop sending traffic on the Alternate Tree, and the PLR can Prune upstream, if appropriate. 4.2.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, traffic from the alternate tree will not be forwarded. If the RPF interface fails, the MP will forward the encapsulated alternate traffic (if it is received with the correct label). For a given interface, there may be multiple backup trees that are using that interface. The traffic for each of these backup trees must be programmed for forwarding upon the link failure. 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, and it will stop accepting the encapsulated alternate traffic. The MP can then prune the old alternate Tree for the previous PLR, Protected-Node, Kebler, et al. Expires August 19, 2013 [Page 10] Internet-Draft PIM Protection using MRTs February 2013 and protected Link. The MP will learn the new PLR, Protection Node, and Protected Link from its upstream node and send a Backup Join to the appropriate upstream neighbor. 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 = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |P|T|R|B|L|N| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MRT Protection Hello Option Format Type: TBD. Length: 4 Value: Reserved: Sent with 0, ignored on receipt 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. R: Join Response Capable. This bit is set if the Router is capable of sending and receiving Join Responses and Upstream Address Join Attributes, as defined in this document. B: Backup-Join Capable. This bit is set if the router is capable of sending Backup Joins and MRT Backup Join Attribute, as defined in this document. Kebler, et al. Expires August 19, 2013 [Page 11] Internet-Draft PIM Protection using MRTs February 2013 L: Link Protection Capable. This bit is set if the router is capable of performing Link Protection, as defined in this document. N: Node Protection. This bit is set if the router is capable of performing Node Protection, as defined in this document. 5.1.2. MP ID For PLR Replication The following Hello option is used for a Merge Point to advertise its address label. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MP ID Hello Option Format Type: TBD. Length: variable MP ID: The Encoded-Unicast Address for the Merge Point Reserved: 12 bits of reserved sent with 0. Ignored on receipt. Label: 20 bit Label to be used for traffic that is being protected 5.2. Join Attributes 5.2.1. Merge Point Attribute The following Join attribute is used for node 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 PLR-Replication capable, as advertised in Kebler, et al. Expires August 19, 2013 [Page 12] Internet-Draft PIM Protection using MRTs February 2013 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Merge Point Join Attribute F-bit: This bit will be clear as this is a non-transitive attribute. E-bit: As defined in [RFC5384] Type: TBD Length field: variable Value: Reserved: Sent with zero, ignored on receipt label: the MPLS label associated with this MP MP: The encoded-Unicast addresses of the Merge Point 5.2.2. MRT Backup Attribute The Join attribute is included with each source in the Backup Join message Kebler, et al. Expires August 19, 2013 [Page 13] Internet-Draft PIM Protection using MRTs February 2013 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 | Reserved | # labels | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PLR | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protected Node | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved | label1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved | labeln | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MRT Backup Join Attribute Format F-bit: This bit will be clear as this is a non-transitive attribute. E-bit: As defined in [RFC5384] Type: TBD Length field: the length of the value field. Value: Reserved: Sent with 0, ignored on receipt # labels: number of labels included in this message PLR: Encoded-Unicast Address of PLR. Protected Node: Encoded-Unicast Address of the node which is being protected. For Link Protection, this is the address of the MP Interface ID: a 32-bit identifier of the interface that connects the PLR to the Protected Node. Labels: MPLS labels to be used when sending traffic on the backup Kebler, et al. Expires August 19, 2013 [Page 14] Internet-Draft PIM Protection using MRTs February 2013 5.2.3. Upstream Address Join Attribute This Join attribute is used with MP-initiated node protection to signal the PLR address from the Protected Node to the MP. If a router advertises itself capable of capable of handling Join Responses in the MRT Protection Hello Option, then it MUST be capable of receiving this Join Attribute 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Upstream Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Upstream Interface Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Upstream Address Join Attribute Format F-bit: This bit will be clear as this is a non-transitive attribute. E-bit: End of Attributes. If this bit is set, then this is the last Join Attribute appearing in this Encoded-Source Address field. Type: TBD Length field: the length of the value Value: Reserved: set to all 0's when sent. Ignored on receipt Upstream Address: Encoded-Unicast Address of Upstream Address of the Router sending this Join Attribute. Upstream Link Id: The Interface Id of the PLR Kebler, et al. Expires August 19, 2013 [Page 15] Internet-Draft PIM Protection using MRTs February 2013 5.3. Encoded-Source Address Changes To indicate for a particular flow advertised in the JoinPrune message should have node or link protection, a bit in the Encoded-Source Address will be used. These bits are taken from the available Reserved field of the Encoded-Source Address. These bits should only be set to an upstream router that advertises the link or node capability 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Family | Encoding Type |Rsvd |L|N|S|W|R| Mask Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... Encoded-Source Address Addr Family: As specified in [RFC4601] Encoding Type: As specified in [RFC4601] Rsvd: Transmitted as zero, ignored on receipt. L Link protection requested for this source N Node protection requested for this source S As specified in [RFC4601] W As specified in [RFC4601] R As specified in [RFC4601] Mask Len: As specified in [RFC4601] Source Address: As specified in [RFC4601] Kebler, et al. Expires August 19, 2013 [Page 16] Internet-Draft PIM Protection using MRTs February 2013 5.4. New PIM Message Types 5.4.1. Join Response The Join Response message is identical to the JoinPrune message except the type field is TBD. The Join Response may contain additional Join Attributes. A router must not send a Join Response to an neighbor unless it has advertised this capability in the MRT Local Protection Hello Option. 5.4.2. PIM Backup JoinPrunes The Backup JoinPrune Response message is identical to the JoinPrune message except a new PIM type will be allocated. A router must not send a Backup JoinPrune to an upstream neighbor unless it has advertised this capability in the MRT Local Protection Hello Option. 6. IANA Considerations A new PIM Hello Option type is requested to assign to the MRT Protection Hello Option and the MP ID Hello Option A new PIM type is requested for the Join Response and Backup Join/ Prune messages. A new PIM Join Attribute Types is requested for the Merge Point Join Attribute, Upstream Address Join Attribute, and MRT Backup 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.karan-mofrr] Karan, A., Filsfils, C., Farinacci, D., Decraene, B., Leymann, N., and W. Henderickx, "Multicast only Fast Re- Route", draft-karan-mofrr-02 (work in progress), March 2012. [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, Kebler, et al. Expires August 19, 2013 [Page 17] Internet-Draft PIM Protection using MRTs February 2013 "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [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", RFC 6395, October 2011. [RFC6420] Cai, Y. and H. Ou, "PIM Multi-Topology ID (MT-ID) Join Attribute", RFC 6420, November 2011. 8.2. Informative References [I-D.atlas-rtwg-mrt-mc-arch-00] Atlas, A., Kebler, R., Wijnands, IJ., and G. Enyedi, "An Architecture for Multicast Protection Using Maximally Redundant Trees", atlas-rtwg-mrt-mc-arch-00 (work in progress), March 2012. [I-D.ietf-rtgwg-mrt-frr-architecture] Atlas, A., Kebler, R., Envedi, G., Csaszar, A., Konstantynowicz, M., White, R., and M. Shand, "An Architecture for IP/LDP Fast-Reroute Using Maximally Redundant Trees", draft-ietf-rtgwg-mrt-frr-architecture-01 (work in progress), March 2012. Authors' Addresses Robert Kebler (editor) Juniper Networks 10 Technology Park Drive Westford, MA 01886 USA Email: rkebler@juniper.net Alia Atlas Juniper Networks 10 Technology Park Drive Westford, MA 01886 USA Email: akatlas@juniper.net Kebler, et al. Expires August 19, 2013 [Page 18] Internet-Draft PIM Protection using MRTs February 2013 Naiming Shen Cisco Systems, Inc. 170 W. Tasman Drive San Jose, CA 95134 USA Email: naiming@cisco.com Yiqun Cai Microsoft La Avenida Mountain View, CA 94043 USA Email: yiqunc@microsoft.com Kebler, et al. Expires August 19, 2013 [Page 19]