Network Working Group                             IJsbrand Wijnands
Internet Draft                                       Gargi Nalawade
Expires: January 2005 Cisco Systems

                   MT Tunnel Discovery and RPF check


   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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

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

   [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

8. Normative References

   [ROSEN-MCAST] "Multicast in MPLS/BGP VPNs", Rosen, Cai,  et.  al.
   April 2003, <draft-rosen-vpn-mcast-07.txt>

   [BIDIR]  "Bi-directional  Protocol  Independent  Multicast", Handley,
   Kouvelas,  Speakman,  Vicisano, June 2002, <draft- ietf-pim-bidir-

   [PIMv2]   "Protocol  Independent  Multicast  -  Sparse  Mode (PIM-
   SM)",  Fenner,  Handley,  Holbrook,  Kouvelas, December 2002, draft-

   [RFC2547bis] "BGP/MPLS VPNs", Rosen, et. al., November 2002, draft-

   [BGP-MDT] "MDT SAFI", Nalawade, G., Sreekantiah, A.,  July 2004,
   <draft-nalawade-idr-mdt-safi-01.txt>,   work   in progress

9. Author's Addresses

   Gargi Nalawade
   Cisco Systems, Inc.
   170 Tasman Drive
   San Jose, CA, 95134

   IJsbrand Wijnands
   Cisco Systems, Inc.
   170 Tasman Drive
   San Jose, CA, 95134

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

11. Expiration Date

   This memo is filed as <draft-nalawade-idr-mdt-safi-00.txt>, and
   expires January, 2005.

draft-wijnands-mt-discovery-00.txt                                      [Page 4]