Network Working Group Hong-Ke Zhang INTERNET-DRAFT Chun-Yue Zhou Expiration Date: January 2006 Bing-Yi Zhang Beijing Jiaotong University En-Hui Liu Spencer Dawkins Huawei Technologies Co.,Ltd. July 2005 Multicast in Virtual Router-based IP VPNs Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document specifies the procedures required to be implemented for IP multicast traffic to travel from one VPN site to another within a VR-VPN (Virtual Router-based IP VPN).It details the solution according to process in local customer sites, establishing of multicast distribution trees in SP networks and forwarding of multicast data packets. Hong-Ke Zhang, et al. Expires January 2006 [Page 1] Internet Draft Multicast in Virtual Router-based IP VPNs July 2005 This document is based on Requirements for Multicast in L3 Provider-Provisioned VPNs [MREQT] and specification of Network based IP VPN Architecture using Virtual Routers [VR-VPN] that have been implemented and deployed. 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]. Table of Contents 1 Introduction................................................3 2 Terminology.................................................3 3 VR deployment scenarios.....................................4 4 Auto-discovery of VPN membership............................4 5 Procedures for multicast in VR-VPNs.........................5 5.1 Encapsulation...............................................5 5.1.1 Encapsulation in GRE........................................5 5.1.2 Encapsulation in IP.........................................5 5.1.3 Encapsulation in MPLS.......................................6 5.1.4 Interoperability............................................6 5.2 Multicast source routing table in VR........................7 5.3 Routing in local VPN sites..................................7 5.4 Routing in SP Networks......................................8 5.5 Multicast Data Forwarding...................................8 6 Scalability Considerations..................................9 7 Security Considerations.....................................9 8 Acknowledgments............................................10 9 Normative References.......................................10 10 Informative References.....................................10 11 Authors' Addresses.........................................10 12 Intellectual Property Statement............................11 Hong-Ke Zhang, et al. Expires January 2006 [Page 2] Internet Draft Multicast in Virtual Router-based IP VPNs July 2005 1. Introduction [MREQT] describes Requirements for Multicast in L3 provider-provisioned VPNs. [VR-VPN] specifies a network based IP VPN architecture using Virtual Routers, which have been implemented and deployed by some vendors and service providers. Based on them, this document specifies the procedures required to be implemented for IP multicast traffic to travel from one VPN site to another within a VR-VPN (Virtual Router-based IP VPN). It details the solution according to process in local sites, establishing of multicast distribution trees in SP networks and forwarding of multicast data packets. The reverse shortest path trees are established in SP networks, and the VRs with multicast service requirements act as the tree's leaf nodes and join/leave multicast groups dynamically. This solution is a tradeoff between scalability and flexibility of router optimization, which ensures bandwidth resource utilization in core networks. 2. Terminology Here we introduce some general terms for concepts that appear in this Multicast solution of Virtual Router-based IP VPNs. Please refer to the [PPVPN-TERM] document for details about terminology specifically relevant to VPN aspects. In addition to the terminology used in [MREQT], this document uses the following terms: - GRE: Generic Route Encapsulation, which specifies a protocol for encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol. - PE : Provider Edge - CE : Customer Edge - SP : Service Provider - PIM: Protocol Independent Multicast - RP : Rendezvous Point which is a shared root for every multicast group, sources on the same group send their traffic to the RP and then forwarded to receivers down a shared distribution tree. Hong-Ke Zhang, et al. Expires January 2006 [Page 3] Internet Draft Multicast in Virtual Router-based IP VPNs July 2005 - G : denotes a multicast group. - S : denotes a multicast source. - P-Group: a group address in the SP's address space. - C-Group: a group address in a VPN's address space. 3. VR deployment scenarios In VR-VPNs, VPN customer sites access to service provider backbone via the connection between Customer Edge(CE) and Virtual Router(VR). CE can connect to VR via any access link, then forward all non-local service to VR. VRs belonging to the same VPN domain must discover VPN membership and distribute reachability information. VRs only maintain route state for the VPNs they belong to. There can exist multiple VRs on one Provider Edge(PE) device. Three main VR deployment scenarios can be used for building virtual private networks as described in [VR-VPN]: 1) VR to VR connectivity over a layer 2 connection; 2) VR to VR connectivity tunneled over an IP or MPLS network; 3) Aggregating multiple VRs over a backbone VR. The above VR deployment scenarios can coexist on a single PE and they are not mutually exclusive. For support of multicast, the virtual router has exactly the same mechanisms as a physical router entirely. All existing routing protocols can be used unmodified on VR, between VRs or between VR and CE. Moreover, multicast traffic can be forwarded through IP or MPLS based tunnels. This multicast solution of VR-VPNs fits for all above VR deployment scenarios without any additional configuration or any impact on the backbone VRs in SP networks. 4. Auto-Discovery of VPN membership The first step to support VPN multicast is Auto-Discovery of VPN membership, validation and distribution of reachability information. It is required to select appropriate PE for customer sites, distribute identifier for VPN, configure VR on correlative PE, add the VR to the VPN connected, and forward packets for that VPN. Hong-Ke Zhang, et al. Expires January 2006 [Page 4] Internet Draft Multicast in Virtual Router-based IP VPNs July 2005 The mechanism to distribute membership, topology, and tunnel information among VRs which are members of the same VPN is the same as for unicast in [VR-VPN]. "Auto-discovery" can be achieved through explicit configuration, directory server approach, piggybacking information using extended BGP protocols or other approaches. 5. Procedures for multicast in VR-VPNs 5.1 Encapsulation This multicast solution of VR-VPNs uses the same encapsulation methods as listed in [MVPN-7]. These also apply to the MPLS-in-IP and MPLS-in-GRE encapsulation methods. 5.1.1 Encapsulation in GRE GRE encapsulation can be used when forwarding multicast traffic through SP network. The IP Protocol Number field in the IP Header and the Protocol Type field of the GRE Header follows [MVPN-7]. The following diagram shows the progression of the packet as it enters and leaves the service provider network. Packets received Packets in transit Packets forwarded at ingress VR in the service by egress VRs provider network ++=============++ ++=============++ ++=============++ || C-Payload || || C-Payload || || C-Payload || ++=============++ >>>>> ++=============++ >>>>> ++=============++ || C-IP Header || || C-IP Header || || C-IP Header || ++=============++ ++=============++ ++=============++ | GRE | +---------------+ | P-IP Header | +---------------+ 5.1.2 Encapsulation in IP IP-in-IP encapsulation can also be used. The parameter about IP Protocol Number field follows [MVPN-7]. The following diagram shows the progression of the packet as it enters and leaves the service provider network. Hong-Ke Zhang, et al. Expires January 2006 [Page 5] Internet Draft Multicast in Virtual Router-based IP VPNs July 2005 Packets received Packets in transit Packets forwarded at ingress VR in the service by egress VRs provider network ++=============++ ++=============++ ++=============++ || C-Payload || || C-Payload || || C-Payload || ++=============++ >>>>> ++=============++ >>>>> ++=============++ || C-IP Header || || C-IP Header || || C-IP Header || ++=============++ ++=============++ ++=============++ | P-IP Header | +---------------+ 5.1.3 Encapsulation in MPLS If the P routers in SP networks support MPLS and extended RSVP protocol, MPLS encapsulation can be used. The multicast distribution trees can be constructed by P2MP MPLS LSP mechanism, and additional MPLS encapsulation procedures are used, as specified in [RSVP-TE-P2MP]. Packets received Packets in transit Packets forwarded at ingress VR in the service by egress VRs provider network ++=============++ ++=============++ ++=============++ || C-Payload || || C-Payload || || C-Payload || ++=============++ >>>>> ++=============++ >>>>> ++=============++ || C-IP Header || || C-IP Header || || C-IP Header || ++=============++ ++=============++ ++=============++ | P-MPLS Header | +---------------+ 5.1.4 Interoperability In a VR-VPN, all Virtual Routers in the VPN must agree on the method of encapsulation. It can be achieved either by configuration or by means of some discovery protocols. Here, GRE encapsulation is suggested to be used due to its simple and lower payload. Hong-Ke Zhang, et al. Expires January 2006 [Page 6] Internet Draft Multicast in Virtual Router-based IP VPNs July 2005 5.1 Multicast routing protocols It is necessary to deploy multicast routing protocols in local VPN sites, CEs and PEs. In this solution, all multicast routing protocols with the mechanism of Join and Prune can be used. However, this document only considers the use of PIM-based protocols, including PIM-SM, PIM-SSM, PIM-DM or PIM-Bidir. 5.2 Multicast source routing table in VR In this solution, in order to decide whether there exists multicast requirements from local VPN sites, every VR should store a multicast source routing table constructed by reachability information distributed by VRs through different mechanisms such as static routing, traditional unicast routing or multicast protocol. This table records reachability information of every multicast source S which the VR is interested in and the relative VR, that is (S, VR). 5.3 Routing in local VPN sites Multicast routing protocols must be running in a local VPN site. In this solution, it is an important characteristic that each VR becomes a PIM adjacency of the CE connected, but CEs at different sites do not become PIM adjacencies of each other, and VRs in the same PE do not become PIM adjacencies to each other, either. Every VR in a VR-VPN acts as a proxy Source/RP [P2MP] for its connected VPN sites. The proxy Source/RP connect to the multicast source in the VPN directly or via CEs. Since each VR acts as a proxy-Source/RP in its VPN for its connected VPN sites, an independent multicast tree can be formed within a customer site regardless of multicast trees conformation within other sites. From the view of SP, the Proxy Source/RP is the proxy of all multicast sources within a local VPN site. From the view of a VPN site, the Proxy Source/RP is the RP of all multicast trees within the local VPN site, i.e. all route states such as (C-Source,C-Group) and (*,C-Group) assemble to RP via PIM Join/Prune messages. Here, a C-Source address is a multicast source address in the local VPN site, and a C-group address is a multicast group address in a VPN's address space. Acting as the Proxy Source means that VR must be the egress of all multicast traffic to remote sites. Acting as the RP means that all multicast sources within the VPN sites must register to VR, and VR must be the ingress of all multicast traffic from remote sites. Hong-Ke Zhang, et al. Expires January 2006 [Page 7] Internet Draft Multicast in Virtual Router-based IP VPNs July 2005 5.4 Routing in SP Networks First we define that Source-VR is a VR connected to a customer VPN site which has multicast sources. According to VPN membership and reachability information, it can construct Shortest Path Trees between VRs in a VR-VPN, which are rooted at every Source-VR and addressed on P-Group in the SP's address space. A shortest path tree (Source-VR, P-Group) can be setup using PIM-based protocols or MPLS P2MP tunnel. All multicast traffic from a Source-VR to other VRs share the tree (Source-VR ,P-Group) in the SP network. Here, a P-Group address is a multicast group address in a SP's address space, which represents all other VRs required to receive the multicast traffic from a Source-VR. When there is a Source-VR acting as a Proxy Source/RP of a customer site to receive multicast packets from the site, it encapsulates the packets in GRE or in IP, and the traffic will broadcast to all VRs acting as leaf nodes in the same VPN along the Shortest Path Tree. 5.5 Multicast Data Forwarding After a VR acting as a leaf node has received the first packet from Source-VR, it extracts basic information in encapsulated packets, that are Source-VR address and P-Group address, then decides whether it has multicast requirement from the Source-VR. If there is no multicast receiver in the local VPN sites it served, the VR discards multicast packets and prunes from multicast tree (Source-VR, P-Group) to reject traffic from this Source-VR. A leaf VR which has been pruned from trees should store the state information of (Source-VR, P-Group). As soon as a local site connecting to the pruned leaf VR needs to receive any C-Source traffic proxied by the Source-VR, the pruned leaf VR should explicitly join the tree again, then receive multicast packets from the Source-VR. Every VR acting as leaf nodes repeats these operations, thus multicast packets from a Source-VR are forwarded only to those VRs which require to receive multicast traffic from the Source-VR. Every VR can be source (i.e. root) or receiver (i.e. leaf) of a shortest path tree, and different trees are identified by (Source-VR, P-Group). When a certain leaf VR has new multicast requirements to multicast source C-Source, it checks the multicast source routing table to get the relation between C-Source and Source-VR. If the leaf VR has been Hong-Ke Zhang, et al. Expires January 2006 [Page 8] Internet Draft Multicast in Virtual Router-based IP VPNs July 2005 on the tree (Source-VR, P-Group), it continues receiving packets from Source-VR without additional processing. If this leaf VR has pruned itself from the tree rooted on Source-VR, it sends Join message to the tree, then begins to receive encapsulated packets from Source-VR. After receiving packets, VR decapsulates and recovers multicast packets, then forwards them to local receivers or discards them according to local multicast forwarding table. From the above-mentioned, the processing of multicast trees and packets between VRs in a VPN is drived by multicast receiving requirements of leaf VRs from a C-source, while independent of local state of (C-source, C-Group). Only after multicast traffic from Source-VR reach leaf VRs with multicast receiving requirements through the tree, leaf VRs decide whether to discard or forward multicast packets to local C-Group according to local state of (C-Source,C-Group). 6. Scalability Considerations Scalability is a key requirement for multicast VPN solutions. Generally, efficient multicast routing and scalability are competing goals. The SP has no control over the number of multicast groups in the VPNs and amount of route states. In this solution, all multicast trees (Source-VR, P-Group) in SP networks are Shortest Path Trees. The number of trees rooted on VRs is relatively static. The P-Group address can be configured by administrator or auto-selected in certain range and the P-Group address can be the same for different source VRs in the same VR-VPN. Thus the number of trees (Source-VR, P-Group) in SP networks will neither exceed the number of VRs nor change with the number of customers, the number of C-Source and C-Group, or the topology of local trees (C-Source, C-Group) in local sites. So it not only reduces payload on SP networks effectively but also improves scalability. 7. Security Considerations Security considerations discussed in [VR-VPN] apply to this document. From a route deployment standpoint, the isolation between different VPNs is crucial. In this solution, processing in SP network will be implemented in those VRs belonging to the same VPN. It can get good isolation performance because every VPN has private multicast address space. If only the whole system isolates VRs in the same PE reliably, the security will reach an acceptable level. Hong-Ke Zhang, et al. Expires January 2006 [Page 9] Internet Draft Multicast in Virtual Router-based IP VPNs July 2005 8. Acknowledgment We would like to thank Quan-Lin Li, En-Hui Liu, Yue Zhang, Shuai Gao and Ya-juan Qin for their valuable comments and suggestions on this document. 9. Normative References [PPVPN-TERM] "Provider Provisioned VPN terminology", L. Anderssoo, T. Madsen, September 2004, draft-ietf-l3vpn-ppvpn-terminology-04 10. Informative References [MREQT] "Requirements for Multicast in L3 Provider-Provisioned VPNs", T. Morin, Ed. ,France Telecom R&D, February 2005, draft-ietf-l3vpn-ppvpn-mcast-reqts-00.txt [VR-VPN] "Network based IP VPN Architecture using Virtual Routers", Paul Knight, Hamid Ould-Brahim, Bryan Gleeson, April 2004, draft-ietf-l3vpn-vpn-vr-02.txt [MVPN-7] "Multicast in MPLS/BGP VPNs", E. Rosen. et. al., May 2004 draft-rosen-vpn-mcast-07.txt [P2MP] "BGP/MPLS IP Multicast VPNs", Seisho Yasukawa et. al., October 2004, draft-yasukawa-l3vpn-p2mp-mcast-00.txt 11. Authors' Addresses Hong-Ke Zhang IP lab, Beijing JiaoTong Univ. Beijing, China, 100044 Tel: +86-10-51685677 Email: hkzhang@center.njtu.edu.cn Chun-Yue Zhou, Bing-Yi Zhang IP lab, Beijing JiaoTong Univ. Beijing, China, 100044 Email: zhouchunyue@hotmail.com bingyizhang@hotmail.com En-Hui LIU Huawei Technologies Co., Ltd. Beijing, China, 100085 Tel: +86-10-82882495 Fax: +86-10-82882537 Email: LEH10814@huawei.com Hong-ke Zhang, et al. Expires January 2006 [Page 10] Internet Draft Multicast in Virtual Router-based IP VPNs July 2005 Spencer Dawkins Huawei Technologies Co., Ltd. TX, USA, 75075 Email: sdawkins@futurewei.com 12. Intellectual Property Statement 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. Full Copyright Notice Copyright (C) The Internet Society (2005). 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 are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Hong-Ke Zhang, et al. Expires January 2006 [Page 11]