L3VPN Working Group Xiaohu Xu Internet Draft HUAWEI Expires: April 2006 October 17, 2005 Multicast in BGP/MPLS VPN draft-xu-l3vpn-2547bis-mcast-01.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 April 17, 2006. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract This document describes a set of procedures and protocols that allow IP multicast traffic in Border Gateway Protocol (BGP4)/ Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) to travel from one VPN site to another in MPLS Label Switching Path (LSP) tunnel. Xu Expires April 17, 2006 [Page 1] Internet-Draft Multicast in BGP/MPLS VPN 10/17/2005 Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. 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 . [1]. Table of Contents 1. Introduction..................................................3 2. Implementing multicast in BGP/MPLS VPN........................3 2.1. Discovery of PEs within the same MVPN....................3 2.1.1. BGP-based auto-discovery mechanism..................3 2.1.1.1. Auto-discovery with VPN-IPv4 address family....4 2.1.1.2. Auto-discovery with new address family.........4 2.2. Establishment of pseudo-wires............................4 2.2.1. Establishment of PW via targeted LDP................5 2.2.1.1. Format of VC FEC...............................5 2.2.2. Establishment of PW via BGP.........................6 2.3. Transmission of multicast traffic........................6 2.3.1. PIM-SM instance.....................................6 2.3.2. PIM-DM instance.....................................8 2.4. Compatibility............................................8 2.5. Scalability..............................................8 2.6. QoS......................................................8 2.7. TTL......................................................9 2.8. Extranet.................................................9 2.9. Inter-AS MVPN............................................9 2.10. Carrier's Carrier.......................................9 3. Formal Syntax................................................10 4. Security Considerations......................................10 5. IANA Considerations..........................................10 6. Conclusions..................................................10 7. Acknowledgments..............................................10 8. References...................................................10 8.1. Normative References....................................10 8.2. Informative References..................................11 Author's Addresses..............................................11 Intellectual Property Statement.................................11 Disclaimer of Validity..........................................12 Copyright Statement.............................................12 Xu Expires April 17, 2006 [Page 2] Internet-Draft Multicast in BGP/MPLS VPN 10/17/2005 1. Introduction [RFC2547bis] defines a set of procedures to provide an IP unicast Virtual Private Network (VPN) service in MPLS/IP networks. However, it does not provide a way to provide multicast service in BGP/MPLS VPN, also called MVPN. This document will specify a set of procedures to provide MVPN service. 2. Implementing multicast in BGP/MPLS VPN To provide MVPN service, the following three basic procedures are required: First, discover all the PEs which are attached to a particular MVPN. The PE attached to a particular MVPN can also be described as PE within that MVPN. Second, Full-meshed pseudo wires (PW) are established between each pair of the above PEs, and these PWs are bound to a particular MVRF (Multicast Virtual Routing Forwarding) related to the MVPN. Lastly, multicast control messages and multicast data traffic can be transmitted through those PWs. The above three procedures will be described in detail in the following section of this document. 2.1. Discovery of PEs within the same MVPN Like the procedure to discover PEs within the same VSI (Virtual Switching Instance) defined in VPLS related IETF drafts and RFCs, PEs within the same MVPN could also be discovered automatically via BGP. Manually configuring the addresses of the remote PEs within the same MVPN is also an option. However, this method is not scalable to a large MVPN with a large number of PEs. Each PE within a particular MVPN will create a MVRF table to maintain multicast routing information for that MVPN. 2.1.1. BGP-based auto-discovery mechanism The BGP Multi-protocol Extensions allow BGP to carry routes from multiple "address families". We use the following two methods to implement auto-discovery. Xu Expires April 17, 2006 [Page 3] Internet-Draft Multicast in BGP/MPLS VPN 10/17/2005 2.1.1.1. Auto-discovery with VPN-IPv4 address family A VPN-IPv4 address is a 12-byte quantity, beginning with an 8-byte "Route Distinguisher (RD)" and ending with a 4-byte IPv4 address. To realize auto-discovery of MVPN membership via BGP, each PE attached to a particular MVPN must issue a special BGP update message containing NLRI for VPN-IPv4 address family. The only difference with the unicast VPN-IPv4 route update is that the IPv4 address part of VPN-IPv4 address is specified as ''224.0.0.0'' and the prefix length is specified as ''4''. This special VPN-IPv4 address prefix belonged to a particular VRF means multicast is enabled for that VRF. 2.1.1.2. Auto-discovery with new address family BGP-based auto-discovery can also be done with a new address family named MVPN (to be assigned by IANA). Each PE attached to a particular MVPN must issue a BGP update message containing NLRI for this MVPN address family, as well as specific attributes. Each such BGP update must contain the following information: - IPv4 address of the originating PE, which is also the address used for establishing BGP session. - An RD of the VPN-related VRF, which is bound to the above IPv4 address to form a unique VPN-IPv4 address of the PE. - One or more Route Target attributes. If any other PE has a VRF associated with one of these Route Targets, it will treat the advertising PE as a member in the MVPN to which the VRF belongs. This allows each PE to discover the PEs that belong to a given MVPN. Other optional information can also be contained in that update message according to need. 2.2. Establishment of pseudo-wires Once discovery is done, each pair of PEs within the MVPN will establish pseudo-wires to each other, i.e., exchange demultiplexors. This process is known as signaling of VC label. In the context of MVPN, the VC label as demultiplexor not only says to which specific VMPN a packet belongs, but also identifies the ingress PE. For this reason, there is no need to carry ingress PE's address in multicast traffic with a special encapsulation such as GRE Xu Expires April 17, 2006 [Page 4] Internet-Draft Multicast in BGP/MPLS VPN 10/17/2005 for the purpose of RPF checking and other purposes. That is to say, each PE will assign a unique label to each one of the other PEs within the above MVPN, and those unique labels are associated to a particular MVRF related to the above MVPN. These PWs could be established via targeted LDP or BGP. 2.2.1. Establishment of PW via targeted LDP The VC label information is distributed, with a new type of FEC element named MVRF FEC (to be assigned by IANA), in downstream- unsolicited mode. Only a single VC FEC element MUST be advertised per LDP VC label. 2.2.1.1. Format of VC FEC The VC FEC element is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VC tlv | VC Type |RT info Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route Target | | Route Target | | '' | | '' | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - VC tlv A new value is to be assigned by IANA for MVRF FEC. - VC Type 16 bit, and the value 0x0001 represents a MVRF instance. - RT information length Xu Expires April 17, 2006 [Page 5] Internet-Draft Multicast in BGP/MPLS VPN 10/17/2005 8 bit, it specifies the length of the Route Target field. - Route Target This variable length field is used to carry the Route Target attributes of the particular MVRF. 2.2.2. Establishment of PW via BGP BGP can also be used to establish PW between each pair of the PEs. The mapping of VC label and PE neighbor per MVPN can be carried in BGP update containing NLRI for the MVPN address family. 2.3. Transmission of multicast traffic After the PWs bound to a particular MVRF are established between each pair of those PEs, multicast control messages and multicast data traffic can be transmitted through them. Now let's take PIM-SM and PIM-DM as examples to explain in brief how multicast control messages and multicast data traffic are transmitted in MVPN. Note that the following text is not normative for the specification. 2.3.1. PIM-SM instance As a (S,G)PIM join message is received by an ingress PE via a VRF attachment circuit, the PIM instance for that VRF will process this message. First, it will search the VRF table to find out the best route to S. If the next hop of that route is a loopback address of the other PE, also called egress PE, it will send a (S,G)PIM join message to that egress PE through the PW bound to that VRF between these two PEs. The (S,G)PIM join message is encapsulated in a MPLS frame with two layers of label, and the inner label is the VC label which is assigned to the ingress PE by the egress PE and is associated to a particular MVRF related to the above MVPN, and the outer label is the label of the LSP tunnel from the ingress PE to the egress PE. Meanwhile, the ingress PE will create a (S,G) routing entry in the above MVRF, and the outgoing interface is that VRF interface connected to the CE, and the incoming interface is the PW virtual interface bound to the above MVRF between those two PEs. This virtual interface can be expressed as Li, which is the VC label assigned to the egress PE by the ingress PE and is associated to a particular MVRF on ingress PE related to the above MVPN. Xu Expires April 17, 2006 [Page 6] Internet-Draft Multicast in BGP/MPLS VPN 10/17/2005 As the above (S,G) PIM join message is received by the egress PE, it will determine from which MVPN and from which PE this message is transmitted, then it will search the determined VRF table to find out the best route to S and send a (S,G) PIM join message to the particular CE on the best path to S. At the same time, the egress PE will also create a (S,G) routing entry in the above MVRF, and the incoming interface is the VRF interface connected to the CE, and the outgoing interface is the particular PW virtual interface which is destined to a special MVRF on the ingress PE. This virtual interface can be expressed as (Li,Lo), and the Li is the VC label which is assigned to the egress PE by the ingress PE and is associated to a particular MVRF related to the above MVPN, and the Lo is the label of the LSP tunnel from the egress PE to the ingress PE. PIM prune messages travel in a MVPN in the similar way with PIM join messages, so detailed procedure will not be described in this document. PIM hello messages can also be transmitted periodically through PWs between each pair of the PEs within the same MVPN in order to find out PIM neighbors in a particular MVRF associated with that MVPN. Of course, the hello mechanism between each pair of the PEs within the same MVPN can also be cancelled so as to reduce the periodical multicast traffic within the MVPN. PIM bootstrap messages can also be flooded to all the other PEs through PWs between each pair of PEs within the same MVPN when they are received from a CE by an ingress PE. The bootstrap messages received by egress PE through PW should be checked by RPF mechanism. Only if the PW through which the bootstrap messages are received is the one that is destined to the BSR indicated in the bootstrap messages, will the RPF checking succeed, otherwise, the RPF checking will fail. As full-meshed PWs are formed between each pair of the PEs within the same MVPN, the Bootstrap messages received through PW need not to be flooded to other PEs, this is known as ''horizon-splitting''. PIM assert mechanism is not needed on those PWs because full-meshed PWs are formed between each pair of the PEs within the same MVPN. PIM Candidate-RP-Advertisement messages (C-RP-Advs) are forwarded to the BSR of that MVPN in unicast mode by candidate RPs periodically, so there is no difference from the forwarding behavior defined in [RFC2547bis]. Xu Expires April 17, 2006 [Page 7] Internet-Draft Multicast in BGP/MPLS VPN 10/17/2005 As soon as the multicast distributing tree is established within the MVPN, multicast data traffic will be able to travel along the multicast distributing tree. The implementing procedure of PIM-SSM is similar to that of PIM-SM, so the procedures of processing PIM-SSM control messages in MVPN will not be described in this document. 2.3.2. PIM-DM instance PIM-DM can also be supported in this MVPN. As PIM-DM is a data-driven multicast routing protocol, which is different from the control- driven multicast routing protocol PIM-SM, so the procedure of implementing PIM-DM in MVPN is described as follows: first, as the multicast data traffic is received via a VRF attachment circuit, the traffic will be flooded to all the other PEs within that VRF related MVPN. Second, the multicast data traffic received by any one of the egress PEs within the MVPN will be checked by RPF mechanism. Only if the peer PE of the PW through which the traffic traveled is the next hop of the best route to the multicast source, the RPF checking will succeed, otherwise, the RPF checking will be failed. Third, once the RPF checking succeed, the multicast data traffic will be flooded to all the attached CEs via VRF attachment circuits, this is known as ''horizon-splitting''. 2.4. Compatibility From the above description, it can be seen that multicast in BGP/MPLS VPN is similar with ordinary multicast behaviors as long as the full- meshed PWs between each pair of the PEs within the same MVPN are looked as virtual interfaces with a binding to a particular VRF. That is to say, any kinds of current multicast routing protocols can be run within this MVPN. 2.5. Scalability As there is not special requirement on P routers, the scalability of this MVPN solution is good. In addition, the multicast traffic in MVPN could be distributed accurately to the necessary PEs. 2.6. QoS Diff-Serv can be implemented for multicast traffic in BGP/MPLS VPN traveling through PW by using the DSCP bits in IP head of the IP- based tunnel or the EXP bits in MPLS head of the MPLS LSP tunnel. In addition, if RSVP-TE tunnel is used as the tunnel of PW, the Xu Expires April 17, 2006 [Page 8] Internet-Draft Multicast in BGP/MPLS VPN 10/17/2005 multicast traffic can inherits the features including bandwidth assurance, TE and FRR from RSVP-TE. 2.7. TTL [RFC3031] defined TTL as a way to suppress loops in MPLS networks. The value of TTL field in the header of MPLS frame will be reduced as it travels through LSP tunnel. Generally the TTL value of protocol packet is set to 1. In order to transmit multicast control messages with TTL of 1 through PW, the TTL value of routing protocol packet with TTL of 1 should not be copied to IP header of the IP-based tunnel or the MPLS header of the MPLS LSP tunnel by the ingress PE. 2.8. Extranet As Route Target attributes, but not VPN ID, are used in auto- discovery mechanism of MVPN membership, Extranet can be supported natively. The PE with a particular VRF belonged to more than one VPN can establish PWs separately with other PE members within different MVPNs. Once Extranet is deployed with MVPN, horizon-splitting function should be disabled on the PEs with a particular VRF belonged to more than one VPN. 2.9. Inter-AS MVPN [RFC2547bis] defines three different options for supporting Inter-AS VPN. Among of them, option a) supports MVPN in nature by separately deploying the procedure described above in every AS, and procedure of implementing MVPN in option b) is still under consideration. Option c) creates an LSP from a PE in one AS to another PE in another AS. These PEs can establish PW across AS via multi-hop EBGP or targeted LDP, and the multicast traffic in that MVPN will be tunneled through the inter-AS LSP established between PEs as described above. 2.10. Carrier's Carrier The MVPN solution defined in this document supports the carrier's carrier model in native because there is no special requirement on P routers of sub-carrier. Xu Expires April 17, 2006 [Page 9] Internet-Draft Multicast in BGP/MPLS VPN 10/17/2005 3. Formal Syntax 4. Security Considerations The MVPN solution defined in this document inherits all of the security features of BGP/MPLS VPN. 5. IANA Considerations A new address family for MVPN in BGP (see section 2.1.1.2) and a new FEC for MVRF in LDP (see section 2.2.1.1) need to be assigned by IANA. 6. Conclusions The set of procedures to provide MVPN service specified in this document are compatible with any current multicast routing protocol, such as PIM-SM, PIM-SSM and PIM-DM. That is to say, any multicast routing protocol can run in BGP/MPLS VPN as long as the PWs between each pair of the PEs within the same MVPN are viewed as virtual interfaces with a binding to a particular VRF. 7. Acknowledgments The author would like to acknowledge the following individuals for their helpful comments and suggestions: Spencer Dawkins, Xudong Liang, Le Zhang and Yu Yi. 8. References 8.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. Xu Expires April 17, 2006 [Page 10] Internet-Draft Multicast in BGP/MPLS VPN 10/17/2005 8.2. Informative References [3] [RFC2547bis] Rosen, Rekhter, et. al. ''draft-ietf-l3vpn- rfc2547bis-01.txt'', September 2003, [4] [PIM-SM] Fenner, Handley, Holbrook, Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM)", '' draft-ietf- pim-sm-v2-new-08.txt'',October 2003, [5] [MVPN-FW] Eric C. Rosen, Rahul Aggarwal,''draft-ietf-l3vpn- 2547bis-mcast-00.txt'', May 2005 [6] [VPLS-BGP] K. Kompella, Y. Rekhter,''draft-ietf-l2vpn-vpls-bgp- 04'', February 2005 [7] [VPLS-LDP] Marc Lasserre, Vach Kompella, ''draft-ietf-l2vpn- vpls-ldp-05.txt'' September 2004 [8] [BGP-DISC] Lasserre, Kompella, "Using BGP as an Auto-Discovery Mechanism for Network-based VPNs", draft-ietf-l3vpn-bgpvpn- auto-02.txt, April 2004. [9] [RFC3031] E. Rosen, A. Viswanathan, R. Callon, ''Multiprotocol Label Switching Architecture'', January 2001 Author's Addresses Xiaohu Xu HUAWEI Hua Wei Bld.,No.3 Xinxi Rd., Shang-Di Information Industry Base Hai-Dian District Beijing P.R.China Phone: +86 010 82882457 Email: xuxh@huawei.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 Xu Expires April 17, 2006 [Page 11] Internet-Draft Multicast in BGP/MPLS VPN 10/17/2005 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 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 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 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. Xu Expires April 17, 2006 [Page 12]