Network Working Group Hong-Ke Zhang INTERNET-DRAFT Chun-Yue Zhou Hua-Chun Zhou Beijing Jiaotong University En-Hui Liu Spencer Dawkins Huawei Technologies Co.,Ltd. Expires: October 2007 April 3, 2007 Multicast in Virtual Router-based IP VPNs draft-zhang-l3vpn-vr-mcast-03.txt 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/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on September 3, 2007. 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 about the process in local customer sites, establishing of multicast distribution trees in SP networks and forwarding of multicast data packets. 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. Hong-Ke Zhang, et al. Expires October 3, 2007 [Page 1] Internet-Draft Multicast in Virtual Router-based IP VPNs April 2007 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 [RFC2119]. Table of Contents 1. Introduction.................................... ............2 2. Terminology..................................... ............3 3. VR deployment scenarios......................................3 4. Auto-Discovery of VPN membership.............................4 5. Procedures for multicast in VR-VPNs..........................4 5.1. Encapsulation............................... ...........4 5.1.1. Encapsulation in GRE...............................5 5.1.2. Encapsulation in IP................................5 5.1.3. Encapsulation in MPLS..............................5 5.1.4. Interoperability...................................6 5.2. Multicast routing protocols.............................6 5.3. Multicast source routing table in VR....................6 5.4. Routing in local VPN sites..............................6 5.5. Routing in SP Networks..................................7 5.6. Multicast Data Forwarding...............................7 5.6.1. Case 1: SPT........................................8 5.6.2. Case 2: RPT........................................8 6. Scalability Considerations...................................9 7. Security Considerations.......................... ...........9 8. Acknowledgments.................................. ...........9 9. References....................................... ..........10 9.1. Normative References...................................10 9.2. Informative References.................................10 Author's Addresses.................................. ..........11 Intellectual Property Statement................................11 Disclaimer of Validity.............................. ..........12 Copyright Statement................................. ..........12 Acknowledgment...................................... ..........12 1. Introduction [MREQT] describes requirements for deployment IP 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. VR is a logical router entity and has all capabilities of a physical router. Multiple VRs can exist in a PE router to server for different VPNs. Hong-ke Zhang, et al. Expires October 3, 2007 [Page 2] Internet-Draft Multicast in Virtual Router-based IP VPNs April 2007 This document specifies the procedures to implement IP multicast traffic in VR-VPN (Virtual Router-based IP VPN). It details the solution about the process in local sites, establishing of multicast distribution trees in SP networks and forwarding of multicast data packets. The shared tree (or multiple shortest path tree rooted in VRs according to the networks conditions) is established in SP networks for a specific VPN, the VRs interested in the multicast service join the tree as leaf nodes. VR records the multicast states in the VPN site and SP networks, and transmits the VPN multicast data through SP multicast delivery tree. 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 memo. Please refer to the [RFC4026] 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. 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. P-Group: a group address in the SP's address space. C-Group: a group address in a VPN's address space. MSRtable: Multicast Source Routing table which is recorded in VRs to filter the multicast data. 3. VR deployment scenarios In VR-VPNs, VPN customer sites access to service provider backbone via the connection between CE and VR. CE can connect to VR via any access link, and then forward all non-local packets to VR. VRs Hong-ke Zhang, et al. Expires October 3, 2007 [Page 3] Internet-Draft Multicast in Virtual Router-based IP VPNs April 2007 belonging to the same VPN must discover VPN membership and distribute reachability information. VRs only maintain route state for the VPNs they belong to. 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 multicast service, VR 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 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. 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-8]. These also apply to the MPLS-in-IP and MPLS-in-GRE encapsulation methods. Hong-ke Zhang, et al. Expires October 3, 2007 [Page 4] Internet-Draft Multicast in Virtual Router-based IP VPNs April 2007 5.1.1. Encapsulation in GRE GRE encapsulation can be used when forwarding multicast traffic through SP networks. The IP Protocol Number field in the IP Header and the Protocol Type field of the GRE Header show in [RFC2874]. 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 [RFC2003]. 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 || ++=============++ ++=============++ ++=============++ | 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 [MPLS-ME]. Hong-ke Zhang, et al. Expires October 3, 2007 [Page 5] Internet-Draft Multicast in Virtual Router-based IP VPNs April 2007 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. 5.2. 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-Bi-directional. 5.3. Multicast source routing table in VR In this solution, in order to decide whether there exist multicast requirements from local VPN sites, every VR should record a multicast source routing table (MSRtable for short) constructed by reachability information distributed by VRs through different mechanisms such as static routing, traditional unicast routing or multicast protocol. For a Specific VPN, this table records reachability information of every multicast source S and C-group which the VR is interested in and the relevant VR, and that is (S, C-group, VR). VR implements the filter packets based on this table and reduces the bandwidth consumption. 5.4. Routing in local VPN sites Multicast routing protocols must be running in a local VPN site. In this solution, 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. Hong-ke Zhang, et al. Expires October 3, 2007 [Page 6] Internet-Draft Multicast in Virtual Router-based IP VPNs April 2007 Every VR in a VR-VPN acts as a proxy Source/RP [P2MP] for its connected VPN sites. The proxy Source/RP connects 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, while 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. 5.5. Routing in SP Networks To transmit the C-group data through the SP networks we define the Source-VR in this memo, which means the VR connected to a customer VPN site which has multicast sources. Source-VR as a Proxy Source sends the PIM source register message to the RP in SP networks and the VRs wanted to get the multicast data send the PIM join message to RP. In this way a shared tree (RPT) is established to transmit the multicast data. Besides, the shortest path tree (SPT) rooted at Source-VR can be set up in the SP's address space using PIM-based protocols or MPLS P2MP tunnel. SPT can improve delivery efficiency, while RPT can reduce the number of multicast state in SP networks. SPT and RPT use the address in SP networks address space, and all multicast traffic from multiple C-groups in a Source-VR to other VRs shares the tree (SPT or RPT) in the SP network, and VR perform the multicast filter based on its MSRtable to block the unsubscribed C- group data. 5.6. Multicast Data Forwarding We will discuss the multicast forward process based on the different SP multicast tree type. Hong-ke Zhang, et al. Expires October 3, 2007 [Page 7] Internet-Draft Multicast in Virtual Router-based IP VPNs April 2007 5.6.1. Case 1: SPT After VR 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 receiver from the Source-VR by looking up in MSRtable. If there is no receiver in the local VPN sites it served, the VR will discard multicast packets and prune 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, and then receive multicast packets from the Source-VR. Every VR repeats these operations, thus multicast packets from a Source-VR are forwarded only to those VRs which require receiving 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 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. 5.6.2. Case 2: RPT VR as the proxy source or RP in a specific VPN site gathers the multicast state information into the MSRtable. For Source-VR, it encapsulates the C-group data in P-group and sends to RP, and RP forwards the data to the VR subscribed to the P-group. For the VR which has the multicast receivers will send a C-group PIM join message encapsulated in the P-group join message to the RP in the SP networks. After RP has received the message, it will forward multicast packets from the Source-VR. To compatible with the existed multicast route protocols, all C-group multicast data is transmitted on the SP networks and filtered by the VR using the MSRtable. From the above-mentioned, the processing of multicast trees and packets between VRs in a VPN is driven by multicast receiving requirements of VRs by gathering the multicast state of (C-source, C- Group) and (*, C-Group). Only after multicast traffic from Source-VR reach RP or leaf VRs with multicast receiving requirements through Hong-ke Zhang, et al. Expires October 3, 2007 [Page 8] Internet-Draft Multicast in Virtual Router-based IP VPNs April 2007 the tree, VRs will decide whether to discard or forward multicast packets to local C-Group according to its MSRtable. It needs a mechanism to switch RPT to SPT based on some metric of the C-group service such as bandwidth. If some C-group bandwidth exceeds the predefined threshold, it will trigger the switch process. For example SP networks can use the PIM-SM to implement this mechanism in implementation. 6. Scalability Considerations Scalability is a key requirement for multicast VPN solutions. Generally, efficient multicast routing and scalability are competing goals. In this solution, the SP networks have no control over the number of multicast groups in the VPNs and amount of route states and all multicast traffic in a specific VPN share one SP multicast delivery tree and with SPT as a complement. Thus the number of trees in SP networks will never exceed the number of VRs. 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. 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. 8. Acknowledgments 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. Hong-ke Zhang, et al. Expires October 3, 2007 [Page 9] Internet-Draft Multicast in Virtual Router-based IP VPNs April 2007 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informative References [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. [RFC2784] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. [RFC4026] "Provider Provisioned VPN terminology", L. Anderssoo, T. Madsen, RFC 4026, March 2005. [MREQT] "Requirements for Multicast in L3 Provider-povisioned VPNs", T. Morin, Ed., France Telecom R&D, draft-ietf-l3vpn-ppvpn- mcast-reqts-10, November 2006. [VR-VPN] "Network based IP VPN Architecture using Virtual Routers", Paul Knight, Hamid Ould-Brahim, Bryan Gleeson, draft-ietf- l3vpn-vpn-vr-03, March 2006. [MVPN-8] "Multicast in MPLS/BGP VPNs", E. Rosen Yiqun Cai, IJsbrand Wijnands, draft-rosen-vpn-mcast-08, December 2004. [MPLS-ME] “MPLS Multicast Encapsulations”, Toerless Eckert, Eric C. Rosen, Rahul Aggarwal, Yakov Rekhter, draft-rosen-mpls- multicast-encaps-00, April 2005. [P2MP] "BGP/MPLS IP Multicast VPNs", Seisho Yasukawa et al., draft- yasukawa-l3vpn-p2mp-mcast-01, February 2005. Hong-ke Zhang, et al. Expires October 3, 2007 [Page 10] Internet-Draft Multicast in Virtual Router-based IP VPNs April 2007 Author's 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, Hua-Chun Zhou IP lab, Beijing JiaoTong Univ. Beijing, China, 100044 Email: zhouchunyue@hotmail.com hchzhou@bjtu.edu.cn En-Hui LIU Huawei Technologies Co., Ltd. Beijing, China, 100085 Tel: +86-10-82882495 Fax: +86-10-82882537 Email: LEH10814@huawei.com Spencer Dawkins Huawei Technologies Co., Ltd. TX, USA, 75075 Email: sdawkins@futurewei.com 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 Hong-ke Zhang, et al. Expires October 3, 2007 [Page 11] Internet-Draft Multicast in Virtual Router-based IP VPNs April 2007 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. Disclaimer of Validity 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, THE IETF TRUST 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. Copyright Statement Copyright (C) The IETF Trust (2007). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Hong-ke Zhang, et al. Expires October 3, 2007 [Page 12]