Network Working Group Naiming Shen Internet Draft Liming Wei Redback Networks Expiration Date: June 2004 Dino Farinacci Procket Networks December 2003 Discovering PIM-SM Next-Nexthop Downstream Nodes Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document specifies extensions to PIM-SM in support of next-nexthop downstream node discovery. This next-nexthop node information can be used for PIM to fast re-route multicast traffic onto explicitly routed tunnels, for downstream node protection in case of outbound link or nexthop node failure. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [3]. Shen, Wei, Farinacci Expires June 2004 [Page 1] Internet Draft PIM Next-Nexthop Nodes December 2003 1. Introduction PIM-SM as defined in [1] creates PIM distribution trees by downstream PIM nodes sending Join/Prune messages to either (*,G) or (S,G) upstream PIM nodes. These Join/Prune messages are sent hop by hop towards the RP or the sources of the group. It is possible for a PIM node to know the direct downstream neighbors, but currently it has no mechanism to learn the downstream nodes of the adjacent neighbors, or the next-nexthop downstream nodes. This document proposes an PIM-SM extension to allow a PIM node to discover its next-nexthop downstream neighbors. One application for learning the next-nexthop downstream PIM neighbors is IP multicast traffic fast re-route in NFRR (Nexthop Fast ReRoute) node-protection [2]. The NFRR scheme allows a node to perform fast re-route of IP multicast traffic onto a (LSP) tunnel in case of a link or node failure. Such a Nexthop Fast ReRoute tunnel will most likely be a MPLS TE LSP, but it can be a source routed IP tunnel or a sub-IP tunnel. When the NFRR is used for node-protection for IP multicast traffic, a node acting as the Point of Local Repair (PLR) has tunnels that terminate in the next-nexthop downstream PIM nodes. These next-nexthop downstream nodes receive traffic forwarded by the PLR through the protected node. For each multicast forwarding path going through the PLR and the downstream protected node, the PLR needs to learn the identity of the next-nexthop neighbors. To discover PIM-SM next-nexthop downstream nodes, a PIM node needs to learn its directly connected downstream nodes first. Thus the downstream nodes MUST NOT suppress their Join/Prunes to the upstream neighbors over the multi-access interfaces. In order to allow the PLR to dynamicly associate an OIF (or a protected downstream neighbor) of a (*,G) or (S,G), with a tunnel (or tunnels) leading to the correct next-nexthop neighbors, the PLR needs to learn the association between a next-nexthop neighbor's interface address and the remote NFRR tunnel end point. Since the NFRR tunnel's remote end point uses a router-ID, this router-ID needs to be communicated back to the PLR node. A new message type and a new Encoded Next-Nexthop Address format is defined in this document to relay the downstream's Join/Prune information to the upstream neighbors. This scheme allows a PIM-SM node to send join/prune information with two-hop limit upstream. Two new Option Types are defined for PIM Hello message. One of them is to indicate the sender is interested in receiving the next-nexthop Join/Prune messages from the neighbors. Another is to advertise the sender's router-ID in the Hello message. Shen, Wei, Farinacci Expires June 2004 [Page 2] Internet Draft PIM Next-Nexthop Nodes December 2003 2. Discovering PIM-SM Next-Nexthop Downstream Nodes Scheme This PIM-SM extension involves 3 new actions: 1) downstream PIM nodes advertise router ID in PIM Hello messages; 2) upstream PIM nodes send Next-Nexthop Node Request to downstream nodes in Hello messages; and 3) a PIM node modifies and relays downstream's Join/Prune messages to all relevant upstream nodes. For each (*,G) or (S,G), the PIM PLR node builds a relation of downstream nodes and next-nexthop downstream nodes. When the outbound interface going to the downstream node is down or the downstream node itself is down, the PLR node can fast re-route the multicast traffic directly to those next-nexthop downstream nodes using the pre-built NFRR tunnels. 2.1 Example The diagram below shows an example of this scheme. lsp1 +---------------------------+ (S,G) | | (upstreams) | <--- J/P --- V downstream [R1]====>[R2]a=======>b[R3]=======>c[R4]-- (to receivers) <- NNhop J/P -- Figure 1: NFRR node-protection for IP multicast traffic Node R2 is the PLR (Point of Local Repair). It is configured with an NFRR LSP for the purpose of protecting node R3. Assume R3 is the downstream PIM node of R2 for a (S,G), R4 is the downstream node of R3 for the same (S,G). The links between the nodes can be either point-to-point or multi-access. R2 indicates to R3 in PIM Hellos, that it is interested in receiving R3's downstream Join/Prune messages. R4 advertises its router-ID to R3 in its Hello messages. When R3 receives a Join/Prune message for the (S,G), it resends it in a Next-Nexthop Join/Prune (NNJP) message to its upstream neighbor R2. This NNJP contains R4's router-ID, which R3 learned from R4's Hello message. This NNJP message is unicast directed at R2, After R2 receives the relayed messages from R3, it can make the association of its downstream R3 with NFRR LSP lsp1 for the (S,G). In the case of link "a" going down, the multicast forward engine on R2 can quickly switch the traffic for the (S,G) from OIF of interface "a" onto lsp1. The RPF checks on R4 needs to to accept multicast traffic from lsp1. The mechanism of this modified RPF check for re-routed multicast traffic is described in [2]. Shen, Wei, Farinacci Expires June 2004 [Page 3] Internet Draft PIM Next-Nexthop Nodes December 2003 In a topology more complicated than that shown in figure 1, there are multiple LSPs associated with a (S,G) over an oif, going to multiple next-nexthop nodes. 2.2 Router-ID Option in Hello Message A new option is defined to support the advertisement of a PIM node's router-ID. A router-ID is a 4 byte number uniquely identifying a PIM node. The same router-ID is also be used to establish the tail-end of the NFRR LSP. A PLR PIM node makes the association of a next-nexthop downstream node and a NFRR tunnel based on the router-ID. A router may have multiple router-IDs for different applications. The router-ID being used for this option MUST match the NFRR LSP destination address in order for PIM-SM on the PLR to make the association. 2.3 Next-Nexthop Node Request Option in Hello Message This option is used by an upstream node to indicate to its downstream nodes that it is interested in receiving the Join/Prune messages of their downstream nodes. An upstream node can optionally send the Next-Nexthop Node Request when there is at least one NFRR tunnel configured to protect the downstream nodes over the interface. This request is implicitly withdrawn if the last NFRR tunnel is torn down (or a NFRR LSP is removed). Upon receiving the Hello messages with the Next-Nexthop Node Request, a PIM node SHOULD relay the modified Join/Prune messages from its downstream nodes to the relevant upstream nodes who requested the service. 2.4 Next-Nexthop Node Address in Next-Nexthop Join/Prune Message A new Next-Nexthop Join/Prune Message is defined for an PIM node to modify and relay the downstream Join/Prune messages to their corresponding upstream neighbors. The format of the message is the same as the Join/Prune message except that the Encoded Upstream Neighbor Unicast Address is replaced by the Encoded Next-Nexthop Address and the message is destined to a unicast interface address of the upstream neighbor. A new Encoded Next-Nexthop Node Address is defined for this scheme. The address family code and the Encoding Type are not changed. The Address field includes the downstream node router-ID and the downstream interface IP address. This new Encoded Address is used in the Next-Nexthop Join/Prune Message to re-group the (S,G)s for each upstream neighbors. A PIM node MUST silently drop the packet if it does not support this Next-Nexthop Node extension, or the sender of the message is not one of the downstream nodes it protects, or the interface where it received this NNhop Join/Prune message is pruned. Shen, Wei, Farinacci Expires June 2004 [Page 4] Internet Draft PIM Next-Nexthop Nodes December 2003 3. Packet Format 3.1 Router-ID Option in Hello Message The Value field of the option Router-ID is a 4 byte number. This option can be included in the Hello message to advertise the unique address of the router. 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 (IANA allocate) | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.2 Next-Nexthop Node Request Option in Hello Message This option is used by upstream node to inform the downstream nodes that it is interested in receiving the Next-Nexthop Node information. This option can be included in the Hello message. 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 (IANA allocate) | Length = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.3 Next-Nexthop Join/Prune Message This is a new PIM-SM message type. The code is to be allocated by IANA. This message has the same format as the normal Join/Prune message except for: - the Next-Nexthop Node Address replaces the Upstream Neighbor Unicast Address in Join/Prune message. - the message is destined to an unicast interface address of the intended upstream PIM neighbor. This modified Join/Prune message is sent to the neighbor's interface unicast address with TTL 1. This message MUST only contain the (S,G)s or (*,G) which share the same upstream PIM neighbor. 3.4 Next-Nexthop Node Address This Next-Nexthop Node Address is used by a PIM node to replace the Upstream Neighbor Address in the original Join/Prune message. Shen, Wei, Farinacci Expires June 2004 [Page 5] Internet Draft PIM Next-Nexthop Nodes December 2003 This Address contains the interface address and router-ID from the next-nexthop PIM neighbor's original join/prune message. 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 | Router ID (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID (Continued) | Unicast Address (Interface) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... Addr Family - The PIM address family of the Unicast Address of Interface field of this address. Encoding Type - The value is set to 0. Router ID - A 4 byte number to represent the unique address of an downstream PIM node. Unicast Interface Address - The interface address of the downstream PIM neighbor. 4. Security Considerations This mechanism does not introduce any new security issue in LDP. 5. IANA Considerations The Router-ID and Next-Nexthop Node Request option types in Hello messages, the Next-Nexthop Join/Prune Mesage type and the Next-Nexthop Node Address are proposed in this document. This PIM-SM extension requires that IANA allocate those numbers. 6. Acknowledgments The authors would like to thank Yiqun Cai for the discussion and comments to this document. 7. Intellectual Property Considerations Redback Networks may have intellectual property rights claimed in regard to some of the specification contained in this document. 8. Full Copyright Statement Shen, Wei, Farinacci Expires June 2004 [Page 6] Internet Draft PIM Next-Nexthop Nodes December 2003 Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 9. References [1] Estrin, et al., "Protocol Independent Multicast-Sparse Mode (PIM- SM): Protocol Specification", RFC 2362, June 1998. [2] Shen, N., Pan, P., "Nexthop Fast ReRoute for IP and MPLS", Internet draft, draft-shen-nhop-fastreroute-00.txt, work in progress. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10. Author's Addresses Naiming Shen Redback Networks 300 Holger Way San Jose, CA 95134 Email: naiming@redback.com Liming Wei Redback Networks 300 Holger Way Shen, Wei, Farinacci Expires June 2004 [Page 7] Internet Draft PIM Next-Nexthop Nodes December 2003 San Jose, CA 95134 Email: lwei@redback.com Dino Farinacci Procket Networks dino@procket.com Shen, Wei, Farinacci Expires June 2004 [Page 8]