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, <draft-rosen-vpn-mcast-07.txt>
[BIDIR] "Bi-directional Protocol Independent Multicast", Handley,
Kouvelas, Speakman, Vicisano, June 2002, <draft- ietf-pim-bidir-
04.txt>
[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,
<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
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 <draft-nalawade-idr-mdt-safi-00.txt>, and
expires January, 2005.
draft-wijnands-mt-discovery-00.txt [Page 4]