Network Working Group Naiming Shen Internet Draft Liming Wei Redback Networks Expiration Date: January 2005 Dino Farinacci Procket Networks July 2004 Discovering PIM-SM Next-Nexthop Downstream Nodes Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 January 2005 [Page 1] Internet Draft PIM Next-Nexthop Nodes July 2004 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 January 2005 [Page 2] Internet Draft PIM Next-Nexthop Nodes July 2004 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 January 2005 [Page 3] Internet Draft PIM Next-Nexthop Nodes July 2004 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 January 2005 [Page 4] Internet Draft PIM Next-Nexthop Nodes July 2004 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 January 2005 [Page 5] Internet Draft PIM Next-Nexthop Nodes July 2004 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. 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-01.txt, work in progress. Shen, Wei, Farinacci Expires January 2005 [Page 6] Internet Draft PIM Next-Nexthop Nodes July 2004 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8. 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 San Jose, CA 95134 Email: lwei@redback.com Dino Farinacci Procket Networks dino@procket.com 7. Intellectual Property Considerations The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 8. Full Copyright Notice Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Shen, Wei, Farinacci Expires January 2005 [Page 7] Internet Draft PIM Next-Nexthop Nodes July 2004 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. Shen, Wei, Farinacci Expires January 2005 [Page 8]