Network Working Group Rahul Aggarwal Internet Draft Tom Pusateri Expiration Date: January 2005 Juniper Networks PIM-SM Extensions for Supporting Remote Neighbors draft-raggarwa-pim-sm-remote-nbr-01.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or IPR claims of which I am aware have been 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 describes protocol extensions to PIM-SM for supporting PIM-SM neighbors that are not directly connected. The mechanism described herein makes use of PIM-SM Hello messages that are directed to the remote neighbor. Following the discovery of the remote neighbor PIM-SM Join and Prune messages can be exchanged. draft-raggarwa-pim-sm-remote-nbr-01.txt [Page 1] Internet Draft draft-raggarwa-pim-sm-remote-nbr-01.txt July 2004 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 [KEYWORDS]. 1. Introduction PIM-SM as described in [PIM-SM] can be used for multicast routing in a network topology where all the participating routers are directly connected. This does not apply to network topologies where it is desirable to exchange multicast routing information between non- directly connected i.e. remote neighbors. One approach, in this case, is to setup tunnels between the remote routers and model the tunnels as PIM-SM interfaces. However this requires the setup of tunnels and is operationally expensive. This document describes extensions to [PIM-SM] that can be used for multicast routing in a network topology with remote neighbors. The proposed mechanism is based on "directed" Hello messages that are exchanged between remote neighbors to establish remote neighbor adjacencies. Once the remote neighbor has been learned PIM-SM Join and Prune messages can be exchanged between the remote neighbors. 2. Directed Hello Messages [PIM-SM] relies on Hello messages to perform neighbor discovery. As described in [PIM-SM] Hello messages are sent periodically on each PIM-enabled interface. PIM Hello messages are sent to the ALL-PIM-ROUTERS link local IP multicast group with a TTL of 1. Neighbors will not accept Join or Prune messages from a router unless they have first heard a Hello message from that router. In the case of non-directly connected routers, the only existing mechanism for exchanging Hello messsages is to: a) Setup a tunnel between the remote routers and b) Model the tunnel as a PIM-SM interface. However this is not always desirable and is operationally expensive. This document introduces the concept of "directed" Hello messages to send Hello messages between remote routers. A directed Hello message is unicast to a remote router. A directed Hello message is sent once the local router decides to setup a neighbor adjacency with the remote router. This may be based on configuration or other mechanisms draft-raggarwa-pim-sm-remote-nbr-01.txt [Page 2] Internet Draft draft-raggarwa-pim-sm-remote-nbr-01.txt July 2004 that are outside the scope of this document. Neighbor discovery is complete when the remote router sends a directed Hello message back to the originating router. This may be in response to the received Hello message or may be driven by configuration or based on other mechanisms outside the scope of this document. A directed Hello message is sent to a unicast address belonging to the remote router. The source address is set to an address of the local router. For example these addresses may be the loopback addresses of the respective routers. A new OptionType is introduced in the Hello message to identify a directed Hello message. OptionType 21 (To be assigned by IANA) Directed Hello 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 = 21 | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Directed Hello OptionType SHOULD be included in a directed Hello message. It is to be noted that an implementation may reject Hello messages if they are not received on a PIM-SM enabled interface. However this MUST be relaxed if the Hello message is a directed Hello. Once directed Hello messages have been exchanged between remote neighbors, they can start exchanging Join and Prune messages as described in the next section. 3. Join/Prune Messages Between Remote Neighbors As described in [PIM-SM] Join/Prune messages should only be accepted for processing if they are received from a known PIM-SM neighbor. The exchange of directed Hello messages, as described above, establishes a neighbor relationship between remote routers. Hence Join/Prune messages can then be exchanged between the remote neighbors. The Join/Prune messages are directed to the remote neighbor and are not processed hop by hop as in [PIM-SM]. Whether a Join/Prune message is destined to a remote neighbor or sent to the directly connected neighbor, depends on the application. For instance a router may be configured to send Join/Prune messages draft-raggarwa-pim-sm-remote-nbr-01.txt [Page 3] Internet Draft draft-raggarwa-pim-sm-remote-nbr-01.txt July 2004 directly to a remote neighbor if that neighbor is the next-hop of the BGP route used to reach the multicast source. 3.1. RPF Interface [PIM-SM] uses the PIM-SM enabled interface used to reach the next-hop neighbor as the RPF interface. However in the case of remote neighbors the destination address in the Join/Prune message is that of the remote router. The interface on which it is sent out may well not be the interface on which the multicast traffic from the remote router is received. The RPF interface for remote neighbors depends on the application. For a typical application that uses remote PIM-SM neigbors, the multicast traffic will be tunnelled between the remote neighbors. In that case the RPF interface will be the tunnel on which the multicast traffic is expected to be received. If the tunnel is modelled as a logical interface in an implementation, the RPF interface will be that particular logical interface. 4. Operation The usage of the mechanisms described in this document is application dependent and should be described in application specific documents. However it is envisaged that a typical application will involve a network topology where the edges of the network are PIM-SM capable, but it is not desirable to run PIM-SM in the middle of the network. Thus the edge routers will act as remote PIM-SM neighbors to exchange multicast routing state. This can also be viewed as a mechanism to connect PIM-SM network clouds over a non PIM-SM network. The non PIM- SM network may have different mechanisms for carrying multicast traffic. 5. Security Considerations Security considerations discussed in [PIM-SM] apply. Other security considerations are for further study. draft-raggarwa-pim-sm-remote-nbr-01.txt [Page 4] Internet Draft draft-raggarwa-pim-sm-remote-nbr-01.txt July 2004 6. IANA Considerations The directed Hello message OptionType requires an option type value that has to be IANA assigned. This document currently uses the next available value as the directed OptionType. 7. Acknowledgments We would like to acknowledge the work in the MPLS WG for a solution to a similar problem relating to the Label Distribution Protocol (LDP). Thanks to Ravi Shekhar for his comments. 8. References 8.1. Normative References [PIM-SM] PIM WG, B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", draft-ietf-pim-sm-v2-new-08.txt. [RFC] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [LDP] L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. Thomas, "LDP Specification", RFC 3036 Author Information Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 Email: rahul@juniper.net Tom Pusateri Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 Email: pusateri@juniper.net draft-raggarwa-pim-sm-remote-nbr-01.txt [Page 5] Internet Draft draft-raggarwa-pim-sm-remote-nbr-01.txt July 2004 9. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. 10. Full Copyright Statement 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. 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. draft-raggarwa-pim-sm-remote-nbr-01.txt [Page 6] Internet Draft draft-raggarwa-pim-sm-remote-nbr-01.txt July 2004 11. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. draft-raggarwa-pim-sm-remote-nbr-01.txt [Page 7]