Geoff Mattson Internet Draft Corona Networks Expiration Date: January 2004 July 2003 Multicast Group Membership Update over 2547bis VPNs draft-mattson-multicast-2547bis-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [RFC-2026]. 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 [RFC2547-bis] is a peer-to-peer VPN model allowing customers to establish unicast routed connectivity over L3 VPNs. But [RFC2547bis] does not provide a means for customers to establish multicast distribution trees over these VPNs. This text proposes a simple means for supporting multicast over [RFC2547-bis] VPNs. The solution is generic and can be used with most multicast IGPs (M-IGPs) including PIM-SM, PIM-DM, IGMP proxy and CBT. The proposed technique allows a PE to act as a gateway between multicast M-IGP peers in the CE and the MBGP-based VPN. The PE maintains an M-IGMP peering relationship with an M-IGP agent at the CE. Through the M-IGP peering session the PE receives group membership information. The PE gateway exports this membership information to BGP. The information is then conveyed to the appropriate far-end PE by means of MBGP with proposed extensions. The far-end PE imports this membership information and acts on it according to the rules of the M-IGP it is supporting. In general the far-end PE will setup/teardown a forwarding entry for this group and pass the join/prune information toward the source. In order, to keep this protocol simple, this solution is directed only at the Source-Specific Multicast service model, but is structured in a way that does not explicitly preclude future expansion to cover the Any-Source Multicast service model. Another simplifying assumption regards the topology of the VPN. Multicast protocols are often designed with the assumption that the IGP routing on which it is based is symmetrical throughout the network. The proposal maintains this assumption. The solution is not necessarily applicable to all the possible multi-level, overlapping, asymmetrical VPN topologies that are possible within [2547-bis]. Rather, this proposal is directed at the fully-meshed VPNs with symmetrical routing metrics at each PE. 1. Introduction In the model specified in [2547-bis], PEs exchange this unicast routing information with Customer Edge (CE) devices by acting as an IGP or EGP peer to the CE. PE devices propoagete this information to each other using MBGP. [2547-bis] does not provide the same service for multicast routing information. The purpose of this draft is to propose extensions to MBGP that will allow PEs to share VPN-specific multicast information and to propagate this information to the CEs by acting as an M-IGP peer. There are several widely-supported M-IGPs (PIM-DM, PIM-SM, CBT, etc). The core function of each of these M-IGPs is to pass information regarding group information toward the source (or source proxy), to establish and de-establish at most one IFF for each group, and establishing the local OIF list for each group. Each of these M-IGPs relies on exchange of group membership information in order to accomplish its core functionality. This proposal supports propagation of basic group membership information which is necessary for any multicast IGP to function. The technique can be used to support the core function of any M-IGP but does not support all parts of these protocols. For example, functionality found in the PIM-SM referring to distribution of information relating to BSRs or RPs is outside the scope of this document. This proposal calls for PEs to function as M-IGP actors in relation to their CEs. Each PE will keep a separate M-IGP context for each VPN it locally supports. Membership information sent by the CEs (Explicit Joins, Implicit Joins, Explicit Prunes and Implicit Prunes) are then passed to BGP for propagation to the other PEs. BGP is enhanced with a new SAFI to that specifies a multicast group. This SAFI is used in conjunction with MP_REACHABLE_NLRI/MP_UNREACHABLE_NLRI to indicate whether a particular CE is joining itself to or pruning itself from this group. 2. MBGP Extensions The BGP Multiprotocol Extensions [BGP-MP] allow BGP to carry routes from multiple "address families". This draft proposes a new "VPN-IPv4-Group address family". A VPN-IPv4-Group address is a 16-byte quantity. It is composed of an 8-byte Route Distinguisher RD followed by a 32-bit unicast source address and a 32-bit class-D destination address. The RD serves the same function as it does for unicast addresses in [2547bis]. Note that a group in this context is source-specific; is distinguished by its source as well as its destination. The VPN-IPv4 Group address family is uses an AFI value of 1 to indicate IP and a SAFI value to be assigned by IANA. The NEXT_HOP attribute is set to the IP address identifying the PE router in the path to the source address. The ORIGIN attribute is set to the V4 IP address of the local PE to which the tunnel to the far end router is terminated. PEs receiving the advertisement will accept it only if the PE has as a local interface the address specified in the NEXT_HOP interface. RT extended community attributes are included in the UPDATE message and the advertisement is propagated as described in [2547-bis] and {BGP-COM]. 3. M-IGP interactions PE devices accepting advertisements of this type need to process MP_REACHABLE_NLRIs to join events and MP_UNREACHABLE_NLRIs as prune events. The exact actions vary from M-IGMP to M-IGMP. These actions are not specified in this text. 4. Restrictions The technique described in this text is simple and does not account for asymmetries in the VPN configuration. It is recommended that a non-hierarchical, non-overlapping VPN, fully-meshed VPN topology is provisioned for use with this technique. Otherwise, care must be taken by the network designer to avoid unfeasible multicast paths and redundant packet replication. 5. Security Considerations This draft does not introduce any new security considerations to [RFC2547-bis]. 6. References [BGP-COMM] Ramachandra, Tappan, et al., "BGP Extended Communities Attribute", June 2001, work in progress [BGP-MP] Bates, Chandra, Katz, and Rekhter, "Multiprotocol Extensions for BGP4", February 1998, RFC 2283 [RFC-3107] Rekhter Y, Rosen E., "Carrying Label Information in BGP4", January 2000, RFC3107 [RFC-2026] Bradner, S., "The Internet Standards Process -- Revision 3", RFC2026, October 1996. [RFC-2401] Kent S., Atkinson R., "Security Architecture for the Internet Protocol", RFC2401, November 1998. [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC2547-bis] Rosen E., et al, "BGP/MPLS VPNs", work in progress. 9. Acknowledgments To be supplied. 10. Author's Addresses Geoff Mattson Corona Networks 630 Alder Drive Milpitas CA 95051 gmattson@coronanetworks.com Full Copyright Statement Copyright (C) The Internet Society (date). 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.