Network Working Group IJsbrand Wijnands Internet Draft Gargi Nalawade Expires: January 2005 Cisco Systems MT Tunnel Discovery and RPF check draft-wijnands-mt-discovery-01.txt Abstract This document describes a way to dynamically learn the headend point of a Multicast Tunnel (MT) and how to do a successful RPF check on the MT using a VPNv4 prefix reachable over that MT. This is complementary to [ROSEN- MCAST] 1. 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. 2. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. 3. Introduction Multicast Tunnels are built between Provider Edge (PE) routers to allow multicast communication between different site's of a VPN. The MT tunnel has a destination MDT group address that is unique to the VPN. All routers that act as PE's and are configured for a specific VPN join the VPN MDT multicast group in the backbone of the provider network to be able to receive each others packets. Each draft-wijnands-mt-discovery-00.txt [Page 1] Internet Draft draft-wijnands-mt-discovery-00.txt July 2004 router is also a sender to the MDT group. How the forwarding of the MDT packets is achieved is depending on the PIM mode of the MDT group. This can be either PIM-Bidir, PIM-SM or PIM SSM. The proposal in this document is related specifically to PIM SSM mode. An MT tunnel is setup between the PEs in one or more VPN- Providers networks. Over the MT tunnel we create PIM neighbor's. The IP address of the PIM neighbor that we see over the MT tunnel depends on the configured address of the Tunnel endpoint. This can either be an unnumbered address from a different interface or a configured address on the Tunnel itself. The PE router that does an RPF check on a VPN source can find which Tunnel the source is on, but may not know what PIM neighbor to target on that tunnel. Therefore we need a way to connect the BGP VPNv4 prefix to the PIM neighbor on the tunnel to allow the RPF check to succeed. 4. MT Tunnel discovery for SSM PIM SSM does not have a mechanism to learn the source to a multicast group using PIM like in Sparse Mode. The signaling of the source is done via an out-of-band mechanism. To allow SSM mode for building the MT Tunnel we need an out-of-band mechanism to learn the source of the MT Tunnel so we can join directly to it using PIM SSM. [BGP-MDT] defines a new AFI/SAFI to carry the MT Tunnel endpoint information. This AFI/SAFI carries the source of the MT tunnel, the MDT group and the RD for that specific VPN. 5. Originating PE's address for RPF Suppose we want to join to a source that is behind another VPN site. We do an RPF lookup on the source address in the VPNv4 unicast table on this PE. The RPF lookup will return a connected next-hop and interface to use to reach the source. The returned next-hop may not be the neighbor on the MT tunnel. This can be due to the next-hop being rewritten by BGP Route Reflectors (RR) or crossing AS's. Therefore we don't know which PIM neighbor to target as upstream neighbor in the PIM join. [BGP-MDT] defines a new attribute called the BGP Connector attribute. This document proposes sending the Originating PE's IP address as the value field when the BGP Connector attribute contains AFI/SAFI IPv4-MDT. This is the MT Tunnel IP address that is used to establish the PIM neighborship on the MT tunnel. This attribute is attached to all the BGP VPNv4 prefixes used for multicast. The PE router that was able to successfully RPF on a BGP VPNv4 prefix will use the IP address learned from the connected attribute to find the PIM neighbor on the MT tunnel. 6. Intellectual Property Considerations draft-wijnands-mt-discovery-00.txt [Page 2] Internet Draft draft-wijnands-mt-discovery-00.txt July 2004 Cisco Systems may seek patent or other intellectual property protection for some of all of the technologies disclosed in this document. If any standards arising from this document are or become protected by one or more patents assigned to Cisco Systems, Cisco intends to disclose those patents and license them on reasonable and non-discriminatory terms. 7. Acknowledgements The authors wish to thank Arjen Boers and Yiqun Cai, for their help and ideas. The authors also wish to thank Arjun Sreekantiah, Jennifer Li and Shyam Suri for their contributions and help. We would also like to thank Isidor Kouvelas, Ruchi Kapoor, Dan Tappan, Tony Speakman and Eric Rosen for their comments and suggestions. 8. Normative References [ROSEN-MCAST] "Multicast in MPLS/BGP VPNs", Rosen, Cai, et. al. April 2003, [BIDIR] "Bi-directional Protocol Independent Multicast", Handley, Kouvelas, Speakman, Vicisano, June 2002, [PIMv2] "Protocol Independent Multicast - Sparse Mode (PIM- SM)", Fenner, Handley, Holbrook, Kouvelas, December 2002, draft- ietf-pim-sm-v2-new-06.txt [RFC2547bis] "BGP/MPLS VPNs", Rosen, et. al., November 2002, draft- ietf-ppvpn-rfc2547bis-03.txt [BGP-MDT] "MDT SAFI", Nalawade, G., Sreekantiah, A., July 2004, , work in progress 9. Author's Addresses Gargi Nalawade Cisco Systems, Inc. 170 Tasman Drive San Jose, CA, 95134 E-mail: gargi@cisco.com IJsbrand Wijnands Cisco Systems, Inc. 170 Tasman Drive San Jose, CA, 95134 E-mail: ice@cisco.com 10. Full Copyright Statement draft-wijnands-mt-discovery-00.txt [Page 3] Internet Draft draft-wijnands-mt-discovery-00.txt July 2004 Copyright (C) The Internet Society (2001). 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." 11. Expiration Date This memo is filed as , and expires January, 2005. draft-wijnands-mt-discovery-00.txt [Page 4]