Network Working Group Hong-Ke Zhang INTERNET-DRAFT Chun-Yue Zhou Expiration Date: April 2006 Bing-Yi Zhang Beijing Jiaotong University En-Hui Liu Spencer Dawkins Hui Liu Huawei Technologies Co.,Ltd. October 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 Virtual Router-based IP VPN [VR-VPN]. It details the solution according to process in local customer sites and in SP backbone networks. Hong-Ke Zhang, et al. Expires April 2006 [Page 1] Internet Draft Multicast in Virtual Router-based IP VPNs October 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 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 VR Deployment Scenarios.....................................3 3 Proxy Source/RP and SPT Solution............................3 3.1 Multicast Source Routing Table in VR .......................3 3.2 Multicast Routing in Local VPN Sites .......................3 3.3 Routing in SP Networks......................................4 3.4 Multicast Data Receiving in Local Site......................5 4 Multicast Based on Unicast Tunnel...........................5 4.1 Virtual Leaf Router Concept.................................6 4.2. Group Control Message ......................................6 4.3 Group-VR State Table........................................7 4.4 Multicast Forwarding........................................8 5 Encapsulation...............................................9 6 Scalability Considerations.................................10 7 Security Considerations....................................11 8 Acknowledgments............................................11 9 Normative References.......................................11 10 Informative References.....................................11 11 Authors' Addresses.........................................11 12 Intellectual Property Statement............................12 1. Introduction [MREQT] describes Requirements for Multicast in L3 provider-provisioned VPNs. [VR-VPN] specifies a network based IP VPN architecture using Virtual Routers (denoted as VR-VPN) 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. It details the solutions according to process in local sites and SP networks. Hong-Ke Zhang, et al. Expires April 2006 [Page 2] Internet Draft Multicast in Virtual Router-based IP VPNs October 2005 Two solutions are proposed in this document. One is based on the Proxy Source/RP [P2MP] and Shortest Path Tree is set up for backbone transportation. It is detailedly described in former version of this draft. Another solution is based on unicast tunnel mechanism. Virtual Leaf Router concept is proposed and Group Control Message is introduced to optimize the multicast in local site and across backbone. 2. 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 forwards all non-local service to VR. VRs belonging to the same VPN domain must discover VPN membership and distribute reachability information. There can exist multiple VRs on one Provider Edge(PE) device. Prior to support of VPN multicast, unicast VR VPN scenario should be established. It is required to select appropriate PE for customer sites, distribute identifier for VPN, and configure VR on correlative PE. The membership discovery of VRs belonging to the same VPN domain can be achieved through server query, explicit configuration or auto-discovery method. Then tunnels (IP- or MPLS- based) are set up to make connections between VRs. Finally the routing protocol running on each VR disseminates VPN reachability information through tunnels to other VRs. At this time VR VPN is set up for data transmission. The mechanism for doing these is detailed in [VR-VPN]. 3 Proxy Source/RP and SPT Solution 3.1 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. This table records reachability information of every multicast source S which the VR is interested in. The entry is (S, VR). 3.2 Multicast Routing in Local VPN Sites It is necessary to deploy multicast routing protocols in local VPN sites, CEs and PEs. All multicast routing protocols with the Hong-Ke Zhang, et al. Expires April 2006 [Page 3] Internet Draft Multicast in Virtual Router-based IP VPNs October 2005 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. 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. 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. 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. 3.3 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, Shortest Path Trees (SPT) can be constructed between VRs in a VR-VPN, which are rooted at every Source-VR and addressed on P-Group address space. A SPT 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, and the traffic will be sent to all VRs acting as leaf nodes in the same VPN along the Shortest Path Tree. Hong-Ke Zhang, et al. Expires April 2006 [Page 4] Internet Draft Multicast in Virtual Router-based IP VPNs October 2005 3.4 Multicast Data Receiving in Local Site After a VR acting as a leaf node has received the first packet from Source-VR, it extracts basic information (Source-VR address and P-Group address) in encapsulated packets, 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 (Source-VR, P-Group)state. As soon as a local site connecting to the pruned leaf VR needs again to receive any C-Source traffic proxied by the Source-VR, the pruned leaf VR should explicitly join the tree once more, 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). From the above-mentioned, the processing of multicast trees and packets between VRs in a VPN is driven by multicast receiving requirements of leaf VRs from a C-source, but independent of local state of (C-source, C-Group). Only after multicast traffic from Source-VR reach leaf VRs through the tree, leaf VRs decide whether to discard or forward multicast packets to local C-Group according to local (C-Source,C-Group) state. 4 Multicast Based on Unicast Tunnel One important characteristic of VR VPN is that it realizes better traffic isolation between different VPNs, which can be used in the case where security is highly demanded. Besides, this VPN architecture has no requirement on control and transport mechanism. Unicast tunnel for multicast enhances the security characteristic because it does not require SP backbone maintain multicast state of VPN. Broadcast replication between VRs is feasible when multicast load is low. But if multicast traffic between the VRs is high, it is necessary to make choice to send only to VRs with multicast demand. In order to avoid unnecessary traffic in local sites and across the backbone, Virtual Leaf Router concept and Group Control Message mechanism are introduced in this solution. Hong-Ke Zhang, et al. Expires April 2006 [Page 5] Internet Draft Multicast in Virtual Router-based IP VPNs October 2005 4.1 Virtual Leaf Router Concept Regardless of the interaction with the remote sites, the multicast processing in VPN customer site has no difference with normal Internet multicasting. Any PIM instance could be deployed. When considering sending multicast traffic to the backbone, VR at the customer side acts as a "leaf router". All remote group receiver and the backbone is thought as a "LAN" connected to the "leaf router". The Virtual Leaf Router has no difference with normal multicast leaf router, with only exception than the backbone behind it is treated as a virtual "LAN". In order not to pull multicast traffic down to VR and across backbone when no receiver exists in remote site, the VR "Leaf Router" should collect group membership of the "LAN". If there exists remote group receiver, VR will maintain the state for it, just as a normal router does after receiving a group report. The leaf router participates the local multicast in a normal way. It according to the group state from the "LAN" sends PIM Join or Prune messages in local domain. When a local source begins to send traffic to this group, VR "Leaf Router" will pull traffic to itself and relay the traffic to the remote group receiver. 4.2 Group Control Message In section 5.1.1, VR as a leaf router just does the same thing as a normal leaf router. It receives IGMP Report message from remote VRs, which is referred to Group Control Message. This could be achieved with two different methods. For instance, the remote VR could resolve this information from periodic PIM Join/Prune received from its internal nodes of the site. Or the router in the remote sites, as it receives IGMP report message from its links, is required to make a copy of the message to its VR. The second method may alter the behaviour of the routers a little but has the advantage of low group delay and can be applied to any PIM Protocol in local site. The first method does not affected the operation of local sites, but it doesn't work well in PIM-DM scenario. When PIM-SM or PIM-BIDIR is running in local sites, all PIM Join/Prunes are aggregated to RP in the protocol manner. Then it is possible to make configuration on RP to forward all the PIM (*,G) and (S,G) Join/Prune message to VR. VR will learn from these messages which group or which source-specific group exists in local site. If Hong-Ke Zhang, et al. Expires April 2006 [Page 6] Internet Draft Multicast in Virtual Router-based IP VPNs October 2005 the message shows a joining or leaving for a group, VR will generate a IGMP report message to be encapsulated and tunneled to remote VR or VRs. In this case, only RP is required to relay PIM Join/Prune message. Delay is introduced, for RP is in a transitional position and VR should wait for a period of time to make full decision. The second method could also be adopted here. When PIM-SSM is running, the group report will be for specific source. If the source is not in local site, the (S,G) Join/Leave will be unicasted to VR, who knows which VR in the remote end with this source attached to it. The first method is easily realized then and group delay is low compared to PIM-SM and PIM-BIDIR. The second method could also be adopted here. When PIM-DM is running, the first method is difficult to deploy, for without multicast traffic for a group sent to leaf router, no join or prune will be originated. So it is impossible for VR to know in advance the group state of the local sites. The only possible way is to adopt the second method. Once group membership states trigger on VR, they are immediately sent in IGMP message format to other related VRs, across the backbone. Utilization of this Group Control Message has three advantages. First, it is possible to introduce low latency as a remote receiver dynamically joins or leaves a group. Secondly, once received by VR, the "IGMP" message be delivered to the virtual "Leaf router", being incorporated well into the virtual "LAN" backbone mechanism. Thirdly, the message conveys only the IP group information and make no requirements of multicast protocol type for the two remote sites. Finally, the Group Control Message is in solid state and does not change so frequently as PIM Join/Prune messages. In this solution, Group Control Message should be transmitted encapsulated in unicast tunnel. But Group Control Method is not restricted only to unicast tunnel. It is possible to carry the Group Control Message in any other form of control mechanism, such as BGP protocol. And further, it is can even deployed in BGP/MPLS VPN model. It realized efficient control over multicast forwarding between VPN sites. 4.3 Group-VR State Table To avoid unnecessary replication, VR in the ingress should be aware which remote VR has actual receiver in its site. Thus VR in ingress should maintain group states from remote VRs, referred to as group-VR state table. When VR receives local multicast packets, it decides according to the group-VR table to choose to send to a Hong-Ke Zhang, et al. Expires April 2006 [Page 7] Internet Draft Multicast in Virtual Router-based IP VPNs October 2005 subset of VRs. Thus VRs without active members will not receive the traffic. The Group-VR state table is recorded in each VR. VR refers to it before transmitting. The table is constructed from the Group Control Message delivered by remote sites and changes dynamically as the remote receiver joins and leaves a group. There are two types of entry,(*,G)VR and (S,G)VR, respectively standing for normal group and source specific group. If a remote receiver joins in a (*,G) group, and there is no other receiver belongs to this group, group control information is tunneled by its VR (i.g. VR1) to every other VRs across the backbone. Other VRs will record this (*,G)-VR1 relation for this VPN. Usually multiple remote VRs may have members for the same group. Then the (*,G) state may link to multiple VRs, i.g. denoted as (*,G)-VR1-VR2-VR3. When PIM-SSM is used in local site, (S,G)Join should be initiated. In this case, only VR attached to S needs this group information. And (S,G)-VR1 entry should be maintained on this VR. And multiple VRs can be corresponded to a source-specific receiving, which can be denoted as (S,G)-VR1-VR2-VR3. The group-VR table on a VR is used in unicast tunnel multicast model. When local source delivers multicast traffic for remote receivers, it helps to eliminate unnecessary data transferring. The group states for local member need not be kept in the table. Because VR knows in advance the group information of other VRs before transmitting. Other VRs will not receive traffic they don't like, which implement some efficiency in backbone transfer. 4.4 Multicast Forwarding With the mechanism mentioned above, it is easy to make multicast forwarding in local sites. First, without remote senders or receivers for this site, the multicast process is exactly same as normal case. The Virtual Leaf Router behaves just like a normal router without any group member on it. No traffic will flow to VR and the backbone. If there exist remote receivers, the remote VR will inform this Virtual Leaf Router by Group Control Message. If a local source is sending traffic to that group, the multicast data will travel down to this VR Leaf Router. And the VR will relay them to backbone. If a remote source is sending, and there is local receiver for this group, VR will retrieve multicast data from backbone, and simply send them to Local site. Thus optimization is realized in local site: If no receiving require exists from remote sites, no traffic will flow to the VR on PE. And in backbone, VRs with no traffic will not receive unnecessary packets. Hong-Ke Zhang, et al. Expires April 2006 [Page 8] Internet Draft Multicast in Virtual Router-based IP VPNs October 2005 5 Encapsulation The multicast 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 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.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 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 | +---------------+ Hong-Ke Zhang, et al. Expires April 2006 [Page 9] Internet Draft Multicast in Virtual Router-based IP VPNs October 2005 5.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.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. 6 Scalability Considerations The first solution based on Proxy Source/RP initiates SPT tree in backbone. The SPT is set up on a per-VR basis. 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. 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. Hong-Ke Zhang, et al. Expires April 2006 [Page 10] Internet Draft Multicast in Virtual Router-based IP VPNs October 2005 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. Acknowledgment We would like to thank Quan-Lin Li, 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 Hong-Ke Zhang, et al. Expires April 2006 [Page 11] Internet Draft Multicast in Virtual Router-based IP VPNs October 2005 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 Spencer Dawkins Huawei Technologies Co., Ltd. TX, USA, 75075 Email: sdawkins@futurewei.com Hui Liu Huawei Technologies Co., Ltd. Beijing, China, 100085 Tel: +86-10-82882233 Fax: +86-10-82882770 Email: Liuhui47967@huawei.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. Hong-Ke Zhang, et al. Expires April 2006 [Page 12] Internet Draft Multicast in Virtual Router-based IP VPNs October 2005 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 April 2006 [Page 13]