Network Working Group Hong-Ke Zhang Document: draft-zhang-l3vpn-vr-mcast-00.txt Chun-Yue Zhou Expiration Date: November 2005 Bing-Yi Zhang Beijing Jiaotong University May 2005 Multicast in Virtual Router-based IP VPNs draft-zhang-l3vpn-vr-mcast-00.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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes the procedures required to implement Hong-Ke Zhang, et al. Expires November 2005 [Page 1] Internet Draft Multicast in Virtual Router-based IP VPNs May 2005 multicast for an IP multicast VPN based on Virtual Routers. It details the solution according to process in local customer sites, method of establishing multicast distribution trees in SP networks and forwarding flow of multicast data packets. This document is based on prior 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 ...............................................2 2 Terminology ................................................3 3 VR deployment scenario .....................................4 4 Auto-discovery .............................................5 5 Procedures .................................................5 5.1 Encapsulation ..............................................5 5.1.1 Encapsulation in GRE .......................................5 5.1.2 Encapsulation in IP ........................................6 5.1.3 Encapsulation in MPLS ......................................6 5.1.4 Interoperability ...........................................6 5.2 Multicast source routing table .............................7 5.3 Routing in the VPN sites .................................. 7 5.4 Routing in the SP Network ................................. 8 5.5 Multicast VPN Data Forwarding ..............................8 6 scalability Considerations .................................9 7 Security Considerations ....................................9 8 Acknowledgments ...........................................10 9 Normative References ......................................10 10 Informative References ....................................10 11 Authors Address ...........................................10 12 Intellectual Property Statement ...........................11 1. Introduction Hong-Ke Zhang, et al. Expires November 2005 [Page 2] Internet Draft Multicast in Virtual Router-based IP VPNs May 2005 This document describes the procedures required to implement multicast for an IP multicast VPN based on Virtual Routers. It details the solution according to process in local sites, method of establishing multicast distribution trees in SP networks and forwarding flow of multicast data packets. It is based on prior requirements for Multicast in L3 Provider-Provisioned VPNs[MREQT] and specifications of network based IP VPN Architecture using Virtual Routers[VR-VPN] that have been implemented and deployed. It establishes reverse shortest path trees in SP network, those VRs that have multicast requirements act as the tree's leaf nodes and join multicast groups dynamically. This solution is a tradeoff between scalability and flexibility of router optimization, which ensures bandwidth resource utilization. 2. Terminology Here we propose some general terms for concept that appear in the 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 introduces 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 November 2005 [Page 3] Internet Draft Multicast in Virtual Router-based IP VPNs May 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 scenario On VR-VPN network, VPN customer sites access to service provider backbone via the connection between Customer Edge(CE) equipment and 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 of VPN they belong to. There can exist multiple VRs on one Provider Edge(PE) equipment. 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 virtual routers over a backbone virtual router. The above VR deployment scenarios can coexist on a single PE and they are not mutually exclusive. For multicast realization, 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 solution fits for those SP network without backbone VR or do not need to consider effect of backbone VR. Hong-Ke Zhang, et al. Expires November 2005 [Page 4] Internet Draft Multicast in Virtual Router-based IP VPNs May 2005 4. Auto-Discovery The first step to realize 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, make the VR be member of VPN connected, and handle the information of that. The mechanism to distribute membership, topology, and tunnel information among VRs which are members of the same VPN is the same as unicast [VR-VPN]. "Auto-discovery" can be achieved through explicit configuration, directory server approach, piggybacking information using extended BGP protocols or other approaches. 5. Procedures 5.1 Encapsulation This solution uses the same encapsulation methods as [MVPN-7]. These apply also to the MPLS-in-IP and MPLS-in-GRE encapsulations. 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 P-IP Header and the Protocol Type field of the GRE Header must follow [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 PE in the service by egress PEs provider network +---------------+ | P-IP Header | +---------------+ | GRE | ++=============++ ++=============++ ++=============++ || C-IP Header || || C-IP Header || || C-IP Header || ++=============++ >>>>> ++=============++ >>>>> ++=============++ || C-Payload || || C-Payload || || C-Payload || ++=============++ ++=============++ ++=============++ Hong-Ke Zhang, et al. Expires November 2005 [Page 5] Internet Draft Multicast in Virtual Router-based IP VPNs May 2005 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. Packets received Packets in transit Packets forwarded at ingress PE in the service by egress PEs provider network +---------------+ | P-IP Header | ++=============++ ++=============++ ++=============++ || C-IP Header || || C-IP Header || || C-IP Header || ++=============++ >>>>> ++=============++ >>>>> ++=============++ || C-Payload || || C-Payload || || C-Payload || ++=============++ ++=============++ ++=============++ 5.1.3 Encapsulation in MPLS If the P routes on SP network 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 PE in the service by egress PEs provider network +---------------+ | P-MPLS Header | ++=============++ ++=============++ ++=============++ || C-IP Header || || C-IP Header || || C-IP Header || ++=============++ >>>>> ++=============++ >>>>> ++=============++ || C-Payload || || C-Payload || || C-Payload || ++=============++ ++=============++ ++=============++ 5.1.4 Interoperability In VR-VPN network, every Virtual Router in PE must agree on the Hong-Ke Zhang, et al. Expires November 2005 [Page 6] Internet Draft Multicast in Virtual Router-based IP VPNs May 2005 method of encapsulation mentioned above. It can be implemented either by configuration or means of some discovery protocols. Here, GRE encapsulation is suggested to be used due to its simple and lower payload. 5.2 Multicast source routing table According to forward model of VR-VPN, 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 the VPN sites It is necessary to deploy local multicast routing protocols in the VPN sites. Considering the superiority and generality of PIM protocol, certain PIM (PIM-SM, Bidirectional PIM, or PIM-SSM) are suggested. There is an important characteristic in VR VPNs that each VR becomes a PIM adjacency of the CE router connected, but CE routers at different sites do not become PIM adjacencies of each other, and VRs in the same PE do not have PIM adjacencies to each other, either. In this solution, all VRs connecting to VPN sites are deployed as proxy Source/RPs for that VPN site. This proxy Source/RP connect to the multicast source in the VPN directly or via a CE router. Since each VR acts as a proxy-Source/RP of its VPN, it can form an independent multicast tree within the customer site regardless of multicast tree formations in other sites. From the point of view of SP, Proxy Source/RP is the deputation of local VPN site . On the other hand, it is the RP of all multicast trees in local VPN site from the standpoint of VPN site, all route states such as (C-Source,C-Group) and (*,C-Group) assemble to RP via PIM Join/Prune messages. Here a P-group address would be a group address in the SP's address space, and a C-group address would be a group address in a VPN's address space. From the point of view of customer VPN sites, VR must be the egress Hong-Ke Zhang, et al. Expires November 2005 [Page 7] Internet Draft Multicast in Virtual Router-based IP VPNs May 2005 of all traffic. Acting as RP means that multicast sources in the VPN sites must register to VR, then forward multicast packets to remote sites. It is consistent with the direction of local sites' traffic. 5.4 Routing in the SP Network First there is a definition of that Source-VR is a VR connected to a customer VPN site which has multicast source traffic. According to VPN membership and reachability information, it can construct a Shortest Path Tree rooted at every Source-VR and addressed on P-Group in the SP's address space. The shortest path tree (Source-VR, P-Group) can be setup using PIM-DM or MPLS P2MP tunnel. All traffic from VRs share the tree (Source-VR ,P-Group). When there is a Source-VR acting as a proxy-RP of customer site to receive multicast packets from local customer site, it encapsulates the packets in GRE or in IP, the traffic will broadcast to all VRs acting as leaf nodes in the same VPN along the Shortest Path Tree. 5.5 Multicast VPN Data Forwarding After VRs acting as leaf nodes have received the first packet from Source-VR, they extract basic information in encapsulated packets, that is VR and P-Group, then decide whether it has multicast requirement from VRs. If there is no receiver interested in this VR, it discards multicast packets and prunes from multicast tree (Source-VR, P-Group) to reject traffic from this VR. Those leaf VRs which have been pruned from trees will store state information of (Source-VR ,P-Group). As soon as local site has requirements of any C-Source in VPN site which this VR connecting to, the pruned leaf nodes should explicitly join the tree again, then receive multicast packets from this VR. Every VR acting as leaf nodes repeats these operations, thus multicast packets from Source-VR have been forwarded only to those VRs which have requirements of multicast source. Every VR can be source (root) or receiver (leaf), different trees are identified by (Source-VR, P-Group). When a certain leaf VR has new multicast requirements to multicast source S, it checks the multicast source routing table to get the relation between S and Source-VR. If the leaf VR has been on the tree Hong-Ke Zhang, et al. Expires November 2005 [Page 8] Internet Draft Multicast in Virtual Router-based IP VPNs May 2005 (Source-VR, P-Group), it continues receiving packets from Source-VR without extra 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, each process of multicast trees and multicast packets is based on requirements of source (local C-Source of VRs ) from leaf VRs, while independent of C-Group. Only when all traffic from Source-VR have reached to leaf VRs which have requirements through multicast trees, do leaf VRs decide whether to discard or forward multicast packets according to local state (C-Source,C-Group). 6. Scalability Solution Scalability is a key requirement for multicast VPN solutions. Generally, efficient multicast routing and scalability are competing goals. The SP has no control on the number of multicast groups in the VPNs and amount of states in the routes. In this solution, Multicast trees in SP network are all Shortest Path trees. The number of trees rooted on VRs is relatively static. The group address can be configured by administrator or auto-selection in certain range and the address can be the same for different source VRs. Thus number of trees on SP network will neither exceed total of VRs nor change with the number of customers, the number of client multicast channels and varying of topology. So it not only reduces payload on SP network 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 degree between different VPNs is crucial to a great extent. In this solution, Hong-Ke Zhang, et al. Expires November 2005 [Page 9] Internet Draft Multicast in Virtual Router-based IP VPNs May 2005 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 a preferable level. 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 suggestion 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., draft-rosen-vpn-mcast-07.txt 11.Author Information Hong-Ke Zhang IP lab Beijing JiaoTong Univ. China, 100044 Email: hkzhang@center.njtu.edu.cn Chun-Yue Zhou, Bing-Yi Zhang IP lab Beijing JiaoTong Univ. China, 100044 Chun-Yue Zhou: zhouchunyue@hotmail.com Bing-Yi Zhang: bingyizhang@hotmail.com Hong-ke Zhang, et al. Expires November 2005 [Page 10] Internet Draft Multicast in Virtual Router-based IP VPNs May 2005 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 November 2005 [Page 11]