Routing Working Group IJ. Wijnands, Ed. Internet-Draft Cisco Intended status: Standards Track A. Csaszar, Ed. Expires: April 18, 2013 J. Tantsura Ericsson October 15, 2012 Tree Notification to Improve Multicast Fast Reroute draft-wijnands-rtgwg-mcast-frr-tn-00 Abstract This draft proposes using dataplane triggered notifications in order to support multicast fast reroute methods in various ways. Sending such notifications down the tree can be used to trigger fail-over in nodes not adjacent to the failure. Sending such dataplane notification up the tree can help to activate pre-built standby backup tree segments. 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 April 18, 2013. Copyright Notice Copyright (c) 2012 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 Wijnands, et al. Expires April 18, 2013 [Page 1] Internet-Draft Tree Notification for Multicast FRR October 2012 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. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Wijnands, et al. Expires April 18, 2013 [Page 2] Internet-Draft Tree Notification for Multicast FRR October 2012 Table of Contents 1. Terminology and Definitions . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Improving non-local failures . . . . . . . . . . . . . . . . . 5 3.1. Downstream Tree Notifications . . . . . . . . . . . . . . 6 3.2. DTNP processing/forwarding . . . . . . . . . . . . . . . . 6 4. Reduce the bandwidth consumption in failure-free network . . . 8 4.1. Upstream Tree Notifications . . . . . . . . . . . . . . . 8 4.2. Joining a tree in dedicated backup status . . . . . . . . 9 4.2.1. Single topology environment . . . . . . . . . . . . . 9 4.2.2. Multi-Topology Environment . . . . . . . . . . . . . . 10 4.3. Activation . . . . . . . . . . . . . . . . . . . . . . . . 10 4.4. MRT/MCI-Only Mode . . . . . . . . . . . . . . . . . . . . 10 5. The TN Packet . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. TN Packet Format . . . . . . . . . . . . . . . . . . . . . 11 5.1.1. TN TimeStamp TLV Format . . . . . . . . . . . . . . . 12 5.2. Origination of TN Packets . . . . . . . . . . . . . . . . 13 6. IP/PIM Specific TN Components . . . . . . . . . . . . . . . . 13 6.1. IP/PIM Downstream Tree Notifications . . . . . . . . . . . 13 6.2. IP/PIM Upstream Tree Notifications . . . . . . . . . . . . 13 6.3. Incremental deployment . . . . . . . . . . . . . . . . . . 14 7. mLDP Specific TN Components . . . . . . . . . . . . . . . . . 14 7.1. mLDP Downstream Tree Notification . . . . . . . . . . . . 15 7.1.1. Originating a DTNP . . . . . . . . . . . . . . . . . . 15 7.1.2. Receiving a DTNP . . . . . . . . . . . . . . . . . . . 15 7.1.3. Forwarding a DTNP . . . . . . . . . . . . . . . . . . 15 7.2. mLDP Upstream Tree Notification . . . . . . . . . . . . . 15 7.2.1. Originating a UTNP . . . . . . . . . . . . . . . . . . 15 7.2.2. Receiving a UTNP . . . . . . . . . . . . . . . . . . . 16 7.2.3. Forwarding a UTNP . . . . . . . . . . . . . . . . . . 16 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Wijnands, et al. Expires April 18, 2013 [Page 3] Internet-Draft Tree Notification for Multicast FRR October 2012 1. Terminology and Definitions MoFRR : Multicast only Fast Re-Route. LFA : Loop Free Alternate. mLDP : Multi-point Label Distribution Protocol. PIM : Protocol Independent Multicast. UMH : Upstream Multicast Hop, a candidate next-hop that can be used to reach the root of the tree. tree : Either a PIM (S,G)/(*,G) tree or a mLDP P2MP or MP2MP LSP. OIF : Outgoing InterFace, an interface used to forward multicast packets down the tree towards the receivers. Either a PIM (S,G)/(*,G) tree or a mLDP P2MP or MP2MP LSP. IIF : Incoming InterFace, an interface where multicast traffic is received by a router. MCE : MultiCast Egress, the last node where the multicast stream exits the current transport technology (MPLS-mLDP or IP-PIM) domain or administrative domain. This maybe the router attached to a multicast receiver. 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. DTNP : Downstream Tree Notification Packet. UTNP : Upstream Tree Notification Packet. TNP : Tree Notification Packet, Upstream or Downstream JM : Join Message, the message used to join to a multicast tree, i.e. to build up the tree. In PIM, this is a JOIN message, while in mLDP this corresponds to a LabelMap message. MRT : Maximally Redundant Trees. Repair Node : The node performing a dual-join to the tree through two different UMHs. Sometimes also called as dual-joining node or merging node (it merges the secondary and primary tree). Wijnands, et al. Expires April 18, 2013 [Page 4] Internet-Draft Tree Notification for Multicast FRR October 2012 Branching Node : A node, (i) which is considered as being on the primary tree by its immediate UMH and (ii) which has at least one secondary type of OIF installed for a multicast tree. 2. Introduction Both [I-D.karan-mofrr] and [I-D.atlas-rtgwg-mrt-mc-arch] describe "live-live" multicast protection, where a node joins a tree via different candidate upstream multicast hops (UMH). With MoFRR the list of candidate UMHs can come from either ECMP or Loop Free Alternate (LFA) paths towards the MultiCast Ingress node (MCI). With MRT, the candidate UMHs are determined by looking up the MCI in two different (Red and Blue) topologies. In either case, the multicast traffic is simultaneously received over different paths/topologies for the same tree. The node 'dual-joining' the tree needs a mechanism to prevent duplicate packets being forwarding to the end user. For that reason a node 'dual-joining' the tree only accepts packets from one of the UMHs at the time. Which UMH is preferred is a local decision that can be based on IGP reachability, link status, BFD, traffic flow monitoring, etc... Should the node detect a local failure on the primary UMH, the node has an instantly available secondary UMH that is can switch to, simply by unblocking the secondary UMH. The dual-joining node is also called Repair Node in the following. This draft attempts to improve these solutions by: o Improving fail-over time and the reliability of failure detection for non-local failures; and o Reducing the bandwidth consumption in a failure-free network. 3. Improving non-local failures If a failure is not local and happens further upstream, the dual- joining node needs a fast and reliable mechanism (i) to detect the upstream failure and (ii) to learn that other upstream nodes cannot circumvent the failure. Existing methods based on traffic monitoring are limited in scope and work best with a steady state packet flow. Therefore, we propose a method which can trigger the unblocking independently of the packet flow. Figure 1 shows an example. Consider that, e.g., node A goes down. Nodes C, D and E cannot detect that locally, so they need to resort to other means. After detecting the failure, node C should not Wijnands, et al. Expires April 18, 2013 [Page 5] Internet-Draft Tree Notification for Multicast FRR October 2012 change to its secondary UMH (node J) as it won't help for the failure of A. Node D, on the other hand, will have to unblock its secondary UMH (node I). Yet again, with MoFRR, node E should not unblock its secondary UMH (node K): (i) this won't help in resolving the failure of node A, and (ii) one of its upstream nodes (node D in this case) will be able to restore the stream with a fail-over action. 3.1. Downstream Tree Notifications The node detecting a local failure of its primary UMH MUST originate a Downstream Tree Notification Packet (DTNP) to all downstream branches of the tree. Each router that receives the DTNP determines if it is a Repair Node for that tree. If it is not a Repair Node, the DTNP is forwarded further down the tree. If the node is the Repair Node, the secondary UMH is unblocked and the DTNP is discarded. The DTNP allows a downstream router to unambigously identify the multicast tree impacted by the failure. In order to decrease reaction time, the DTNP SHOULD be originated from the data plane when a local failure is detected, as well as processed in the data plane when the DTNP is received. All the information necessary to send and receive a DTNP has to be available in the data plane in advance. 3.2. DTNP processing/forwarding When a DTNP is received from an UMH, the node MUST check o whether it has a secondary UMH, and if yes, o whether this particular DTNP was received on the primary or secondary UMH, and o whether another DTNP had been received beforehand from the other UMH. Whenever a node receives a DTNP from its primary UMH and the node has a secondary UMH for which no DTNP had been received beforehand, this node could be a Repair Node, so unblocks its secondary UMH. The DTNP MUST not be forwarded, but the node has to store the fact that a DTNP has been received for the primary UMH for this multicast tree. If a node receives a DTNP from its primary UMH but does not have a secondary UMH, this node is not the Repair Node and MUST forward the DTNP. If a node receives two DTNPs, one from the primary UMH and another one from the secondary UMH, then this node is not the Repair Node and Wijnands, et al. Expires April 18, 2013 [Page 6] Internet-Draft Tree Notification for Multicast FRR October 2012 it MUST forward the last received DTNP to all branches of the tree. (Secondary UMH does not need to be unblocked since it cannot remedy the failure.) A DTNP received only from the secondary UMH MUST NOT be forwarded, but the node has to store the fact that a DTNP has been received for the secondary UMH for this multicast tree. Whenever a decision has been taken to originate or forward a DTNP, it will be automatically replicated to all downstream legs, given that it is a multicast packet. DTNP MUST be replicated also to downstream stand-by legs if such legs exist. It would raise security issues if DTNPs propagated outside the operator network, so MCEs MUST prevent that DTNP packets propagate to receivers or to other domains. Rephrased, nodes MUST NOT forward DTNPs to legs that lead to receivers or to external autonomous systems. +-+ +-+ +-+ +-+ |F|---|G|---|H|---|I| +-+ +-+ +-+ +-+ / \ / \ +---+ +-+ +-+ +-+ +-+ +-+ |MCI|~~~~~~|A|---|B|---|C|---|D|---|E| +---+ +-+ +-+ +-+ +-+ +-+ \ / \ / \ / \ / +-+ +-+ |J| |K| +-+ +-+ Figure 1: Remote failure example As an example, consider Figure 1. If node A fails, B detects the failure locally and triggers a DTNP (towards C). Node C is not the Repair Node because it will receive the DTNP from both the primary UMH (from B) and the secondary UMH (from J). Because node C is not the Repair node it will forward the DTNP towards K and D (observing rule 3.). K does not have a secondary UMH for this tree, so it will send the DTNP downstream towards E (rule 2.). Node D has a secondary UMH, so it applies rule 1. Node E applies rule 4. As a result, subscribers sitting at or below nodes D and E will continue receiving the multicast traffic. Wijnands, et al. Expires April 18, 2013 [Page 7] Internet-Draft Tree Notification for Multicast FRR October 2012 4. Reduce the bandwidth consumption in failure-free network In some of networks, such as aggregation networks, bandwidth is more sparse than, e.g., in core networks. Live-live multicast protection results in traffic duplication in the failure-free network as it continuously uses bandwidth for both trees or segments. In such networks it is relevant if the capacity serving backup purposes can be used in the failure-free network, i.e., most of the time, by best- effort or even by lower-than-best-effort traffic. +---+ +-+ +-+ |MCI|~~~~~~|A|---|B| +---+ +-+ +-+ \\ // \\ // +-+ |C| +-+ Nodes A and B have receivers. Double lines show bandwidth consumption that is superfluous when there is no failure in the network. Figure 2: Example for secondary segments occupying bandwidth in MoFRR In live-standby mode the aim is that the secondary tree or secondary tree segments are not loaded with multicast traffic as long as there is no failure. A "live-standby" type of multicast protection method, however, requires two principal components: o Blocking OIFs at branching points in the secondary tree to avoid sending secondary packets in the first place; and o Simple and fast-enough procedures to be able to activate the standby tree or standby tree-segment. 4.1. Upstream Tree Notifications The UTN mechanism requires that the secondary tree or tree segment was built with dedicated backup status. In MoFRR or MRT live-live mode the secondary tree and tree segments are active, only the merge point, i.e. the Repair Node, keeps the secondary incoming interface blocked. Dedicated backup status means that the OIFs corresponding to the secondary tree are installed into the data plane but they are installed with a flag denoting they are blocked. Packets are not forwarded to these interfaces unless an Upstream Tree Notification Packet (UTNP) activates them. Wijnands, et al. Expires April 18, 2013 [Page 8] Internet-Draft Tree Notification for Multicast FRR October 2012 Sending notifications upstream helps facilitating live-standby mode instead of live-live. Whenever a node detects a failure on the primary tree (the failure being upstream from the node's location), a UTNP SHOULD be sent upstream towards the source on the secondary tree segment. It is to be noted that the reception of a DTNP MAY be used as an upstream failure indication, so it MAY trigger sending a UTNP. The UTNP activates the secondary tree segments at branching nodes, i.e., unblocks the secondary OIFs. Both the secondary JM and the UTNP go up the tree until a branching node is reached. The branching node is o in a single topology environment: a node that is part of the primary tree and that also has a secondary leg; or o the MCI. 4.2. Joining a tree in dedicated backup status The secondary join process is almost identical to what the MRT and MoFRR drafts describe, i.e., a repair node simply sends a secondary JM through another UMH (on another topology, in case of MRT). For UTN, the secondary JM, however, has to explicitly indicate the intended dedicated backup status. The backup indication MUST be an opaque and transitive indication, so that legacy nodes transparently keep the indication when sending the backup JM further up. In the following, such a JM will be called as "backup JM". How a JM may indicate its secondary status is protocol specific and will be discussed in the appropriate chapter below. 4.2.1. Single topology environment In a single topology environment (MoFRR), the repair node sends the secondary backup JM through a second UMH of its choice. From that UMH on, the backup JM is routed towards the source as if it was a regular JM. In every node, the backup JM MUST be processed identically to a regular JM (including adding a new entry to the OIF list), but, in addition, the added OIF MUST be marked with "blocked" flag. Traffic MUST NOT be forwarded through this interface for this multicast tree while in blocked status. If a node receives a primary JM after receiving a secondary JM from the same neighbor, the node MUST reset the corresponding OIF entry to "unblocked" state. Furthermore, the primary JM MUST be sent further upwards if the node had no other "unblocked" OIFs, i.e., if the node has not received a primary JM from any other neighbor for the given multicast tree. Wijnands, et al. Expires April 18, 2013 [Page 9] Internet-Draft Tree Notification for Multicast FRR October 2012 4.2.2. Multi-Topology Environment In a multi-topology environment (MRT), the secondary tree is built completely independent of the primary tree, on a second topology. This topology ID is attached to the backup JM. Not only the repair node, but each following node receiving the backup JM will route the backup JM towards the source on the second topology. The dedicated backup indication MUST be separated from the topology ID, i.e. a legacy node could send JMs on the secondary topology but will not set the dedicated backup flag. 4.3. Activation UTNP SHOULD be originated when an upstream failure has been detected on the primary multicast tree and the node has a secondary UMH installed with stand-by status. Note that the upstream failure may mean not only the (directly connected) UMH, but any failure up to the MCI. Such an upstream failure may be detected in several ways (out of scope). We note, however, that the reception of a DTNP from the primary UMH MAY be used as such a trigger. The UTNP activates the blocked OIF on which it was received. The UTNP is forwarded up until a branching node is reached, which discards the UTNP and starts forwarding multicast traffic on the leg from where the UTNP was received (e.g., after unblocking the respective OIF). If the branching node does not consider itself a reliable forwarder of the multicast traffic of the indicated tree (e.g., it received a failure indication in the form of a DTNP), it also sent a UTNP after receiving that indication to its secondary UMH, given it had one. 4.4. MRT/MCI-Only Mode If each node in the network supports UTN and also all nodes support MRT, the nodes may work in "MRT/MCI-only" mode. In MRT/MCI-only mode, there is one single branching point for all failures, the MCI. Other nodes MUST NOT consider themselves as branching nodes. MRT ensures the necessary maximally disjoint secondary tree up to the MCI, on a second topology. Only the MCI MUST keep its OIFs corresponding to the secondary tree blocked. Similarly, only MCEs MUST keep their secondary backup IIFs blocked. Any other nodes MUST NOT block their (secondary) IIFs or OIFs. In MRT/MCI-only mode, UTNP MUST be forwarded directly to the MCI. The mode enables that a node detecting a downstream failure of the primary tree MAY send a UTNP upstream towards the source/MCI on the primary tree. Wijnands, et al. Expires April 18, 2013 [Page 10] Internet-Draft Tree Notification for Multicast FRR October 2012 If an UTNP is received by the MCI on the secondary topology in "MRT/ MCI-only" mode, the MCI MUST unblock the OIF where the UTNP was received. This activates a whole sub-tree of the secondary tree. If an UTNP is received by the MCI on the primary topology in "MRT/ MCI-only" mode, the MCI gets no information on which leg to activate on the secondary tree, so it MUST activate (unblock) all secondary legs. 5. The TN Packet 5.1. TN Packet Format A Tree Notification is a IPv4 or IPv6 UDP packet with the following format. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version Number | Message Type | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originator ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLVs ... | . . . . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version number: This is a 2 octet field encoding the version number, currently 0. Message type: This is a 1 octet field encoding the message type, currently two are defined; Type 0: Downstream Tree Notification. Type 1: Upstream Tree Notification. Flags: A 1 octet field encoding the flags, currently no flags are defined, set to zero on send, ignored when received. Wijnands, et al. Expires April 18, 2013 [Page 11] Internet-Draft Tree Notification for Multicast FRR October 2012 Originator ID: IPv4 address owned by the of the TN originator. Sequence Number: Number starting at 0, and increased by 1 each time a new TN is originated. TLVs: TLVs (Type-Length-Value tuples). The TLV's have the following format. 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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value | . . . . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: This is a 2 octet field encoding the type number of the TLV. Length: This is a 2 octet field encoding the length of the Value in octets. Value: String of Length octets, to be interpreted as specified by the Type field. 5.1.1. TN TimeStamp TLV Format The TimeStamp is an optional TLV that MAY be included when the TN was originated, it has the following format. 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 = 0 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TimeStamp Sent (seconds) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TimeStamp Sent (microseconds) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Wijnands, et al. Expires April 18, 2013 [Page 12] Internet-Draft Tree Notification for Multicast FRR October 2012 TimeStamp: The TimeStamp is the time-of-day (in seconds and microseconds, according to the sender's clock) in NTP format [NTP] when the Tree Notification is sent. 5.2. Origination of TN Packets TN packets SHOULD be pre-loaded to the data plane cards, e.g. to a buffer, so that the packet only needs to be flushed when needed. This minimizes the incurred delay. One TN packet MUST be sent per affected multicast tree. This does not lead to a scalability problem in practical network deployments, where it is not expected that a node has to send more than a few 1000s of TN packets. 6. IP/PIM Specific TN Components The TN UDP datagram is encapsulated in an IP packet with (S,G) set as source and destination in the IP header. Such a TN packet is originated for each affected (S,G) multicast tree. The UDP portnumber is set to an IANA assigned number for PIM TN. 6.1. IP/PIM Downstream Tree Notifications As explained before, DTNP is multicasted on each tree on each outgoing interface (including potential "standby" OIFs). If a node is a potential repair node for a multicast tree, the IP forwarding engine MUST be programmed so that it monitors DTNP packets, which are to be recognized among the (S,G) normal data packets based on their UDP port number. If a DTNP is recognized, the affected tree can be identified from the IP header's source and destination address fields. As noted in Section 3.2, nodes MUST NOT forward DTNP outside the operator domain. I.e., nodes egressing the domain MUST filter and discard DTNP packets on their egress interfaces. The DTN mechanism does not require any update of PIM related specifications. 6.2. IP/PIM Upstream Tree Notifications An originated UTNP is to be sent upstream to the secondary UMH, i.e., upstream through the secondary incoming interface. The forwarding engine MUST be programmed so that despite the UTNP packet having (S,G) in the IP header, it MUST forward the UTNP packet upstream. (U)TN(P) packets are to be recognized based on their UDP port number. Wijnands, et al. Expires April 18, 2013 [Page 13] Internet-Draft Tree Notification for Multicast FRR October 2012 Only nodes that have installed some OIFs in blocked (backup) status need to keep monitoring for UTNP packets. The UTN mechanism requires that, when a node performs a secondary join, the PIM JOIN message indicates its dedicated "standby" status. Such an indication is required so that the recipient of a standby PIM JOIN can recognise that it can install its interface, through which the standby PIM JOIN was received, into the OIF list in blocked state. (A received UTNP could be one trigger to unblock such a backup OIF.) An extension of PIM JOIN messages and mechanisms is the responsibility of the PIM WG. It is to be noted that a secondary status indication has already been proposed to the IETF in [I-D.liu-pim-single-stream-multicast-frr]. 6.3. Incremental deployment The DTNP can be forwarded by legacy nodes as a data packet. So DTN can be deployed incrementally if the failure detecting node and repair nodes support it. In case of UTN, the (S,G) addressed (U)TN(P) packet MUST be forwarded towards to source, upstream. This is in contrast to the normal forwarding procedures for (S,G) packets. This means that legacy nodes cannot forward such packets. It remains to be studied if the UTNP packet can be a unicast packet sent towards the source or MCI, or if the UTNP packet can be tunneled through legacy nodes. In the current version of the spec, legacy nodes cannot handle UTNP. As a consequence, a node supporting this spec MUST NOT send dedicated backup JOIN messages to a legacy node. Detecting the capability of supporting Tree Notifications can be done via capability advertisement. This should be specified by the PIM WG. As an indication, it is likely that a "TN-Capable" PIM-Hello option needs to be standardized. 7. mLDP Specific TN Components Since MPLS is used as transport technology, the UTN and DTN are forwarded up and down the LSP using MPLS encapsulation. The MPLS label pushed onto the TN is the label associated with the MP LSP impacted by the failure. This follows more of less the same mechanism as described in [RFC4379]. Its important that a TN packet is never IP forwarded when the tail of the MP LSP is reached. In order to prevent IP forwarding, the destination address MUST be set to an address from the 127/8 range for IPv4 and that same range embedded in as IPv4-mapped IPv6 address. The source address in the IP header MUST be set to an address local to the router. The UDP Wijnands, et al. Expires April 18, 2013 [Page 14] Internet-Draft Tree Notification for Multicast FRR October 2012 port number is set to an IANA assigned number for mLDP TN. 7.1. mLDP Downstream Tree Notification 7.1.1. Originating a DTNP As documented in section Section 3.1, a Downstream Tree Notification is sent by a router that detects a failure of an upstream link or node. The DTN packet is then sent to each LDP neighbor in the Outgoing Interface List for each MP LSP impact by the failure using the MPLS Label that this neighbor has assigned for that MP LSP. 7.1.2. Receiving a DTNP A Downstream Tree Notification Packet is received inline with the data on a particular LSP. If the receiving router is a Repair Node, the MPLS forwarding logic will monitor the MPLS packets in order to detect the DTN packet based on the UDP port number assigned for mLDP TN. When a DTNP is detected, the outer MPLS label identifies the LSP. No additional mechanism or lookups are needed here. The MPLS forwarding code can immediately activate the standby upstream path and disable the old primary path following the procedures described in Section 3.2 7.1.3. Forwarding a DTNP If a router is not a Repair Node for a particular LSP it does not need to monitor the incoming traffic for that LSP in order to detect the DFN packet. Such a router will just forward the DTN packet down the LSP as normal data. Also, routers that don't support DTN processing will always just forward a DTN packet as normal data. For the network to benefit from this feature, not all routers need to be DTN capable. 7.2. mLDP Upstream Tree Notification 7.2.1. Originating a UTNP Following the procedures as described in Section 4.1, an UTNP MAY need to be originated and sent to an upstream LDP neighbor. A P2MP LSP has no upstream labeled path to reach the root because a P2MP LSP is unidirectional. In order to create an upstream path that follows the P2MP LSP all the way up towards the root we apply the procedures are documented in [I-D.ietf-mpls-mldp-hsmp]. A MP2MP LSP already has an upstream path to the root of the tree, however, these packets are also forwarded down the tree by other LSRs. There are two possible approuches, an LSRs that received a DTNP on an upstream interface may just choose to ignore these packets, or an LSR may filter out DTNP Wijnands, et al. Expires April 18, 2013 [Page 15] Internet-Draft Tree Notification for Multicast FRR October 2012 packets from ever being forwarded down the tree. More details will be added in later revisions of the draft. 7.2.2. Receiving a UTNP An Upstream Tree Notification is received on the upstream path associated with the MP LSP by node U. If router U has a downsteam interface in that MP LSPs OIF list that was joined in standby, it will move that interface to forwarding. The outer label in the MPLS header will identify the MP LSP that is targeted. However, that does not necessarily identify the downstream LDP neighbor and interface that needs to be put in forwarding state. Following the procedures in [I-D.ietf-mpls-mldp-hsmp] node U MAY assign all the downstream LDP neighbors the same label for the upstream path. For the purpose of UTN, node U MUST assign a unique label for each downstream LDP neighbor. If that Label is unique, the UTNP will identify the MP LSP and the downstream LDP neighbor. Since node U has selected the downstream interface, it knows which interface to put in forwarding mode. 7.2.3. Forwarding a UTNP A UTNP has to be forward upstream towards the root of the MP LSP following the procedures as defined in Section 4.3 8. Acknowledgements The authors would like express their thanks for Gabor Enyedi for initial discussions. The authors would also like to thank Stefan Olofsson and Javed Asghar for commenting on the draft. 9. IANA Considerations IANA is requested to allocate UDP port numbers to TN messages. One port number for TN in IP/PIM context, and another one for MPLS/mLDP context. The separation of UDP port numbers between IP and MPLS is requested to prevent problems when a PIM multicast tree is transported partly through an mLDP multicast tree. 10. Security Considerations Two types of security problems can be foreseen by the authors: o Handling illegally injected TN packets Wijnands, et al. Expires April 18, 2013 [Page 16] Internet-Draft Tree Notification for Multicast FRR October 2012 o Handling replay attacks (re-injecting previous TN messages) o TN messages propagating outside an operator's domain Illegal TN packets can be handled with authentication checks. Providing authentication for TN messages will be considered in later revisions of this spec. Prevention of replay attacks needs authentication in combination with sequence numbering. Preventing TN messages that travel inline with data packets MUST be solved by nodes egressing the operator's domain. Solutions for IP and MPLS are described in sections Section 6 and Section 7, respectively. 11. References 11.1. Normative References [I-D.ietf-mpls-mldp-hsmp] Jin, L., JOUNAY, F., Wijnands, I., and N. Leymann, "LDP Extensions for Hub & Spoke Multipoint Label Switched Path", draft-ietf-mpls-mldp-hsmp-00 (work in progress), September 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. [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. 11.2. Informative References [I-D.atlas-rtgwg-mrt-mc-arch] Atlas, A., Kebler, R., Wijnands, I., Csaszar, A., and G. Envedi, "An Architecture for Multicast Protection Using Maximally Redundant Trees", draft-atlas-rtgwg-mrt-mc-arch-00 (work in progress), March 2012. Wijnands, et al. Expires April 18, 2013 [Page 17] Internet-Draft Tree Notification for Multicast FRR October 2012 [I-D.liu-pim-single-stream-multicast-frr] Liu, H., Zheng, L., Bai, T., and Y. Yu, "Single Stream Multicast Fast ReRoute (SMFRR) Method", draft-liu-pim-single-stream-multicast-frr-01 (work in progress), October 2010. Authors' Addresses IJsbrand Wijnands (editor) Cisco De kleetlaan 6a Diegem, 1831 Belgium Phone: Email: ice@cisco.com Andras Csaszar (editor) Ericsson Konyves Kalman Krt 11/B Budapest, 1097 Hungary Phone: Email: Andras.Csaszar@ericsson.com Jeff Tantsura Ericsson 300 Holger Way San Jose, California 95134 USA Email: Jeff.Tantsura@ericsson.com Wijnands, et al. Expires April 18, 2013 [Page 18]