Network Working Group Wei Cao Internet Draft Hui Liu Huawei Qiang He Expires: August 2006 February 24, 2006 Multicast in MPLS/BGP IPv6 VPNs draft-cao-mcast-for-ipv6-ppvpn-00.txt Status of this Memo 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. This document is an Internet-Draft and is in full conformance with all provisions of RFC 3978/3979 . 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. Abstract This document describes a method by which a Service Provider may deploy IPv6 multicast service in BGP/MPLS IPv6 VPNs. Multicast in IPv4 BGP/MPLS VPN has been in operation for several years and related drafts are on RFC standard track . IPv6 infrastructure is under construction and new application based on IPv6 is being developing Cao, et al. Expires August 24, 2006 [Page 1] Internet-Draft draft-cao-mcast-for-IPv6-PPVPN-00.txt February 2006 now. Multicast will act an important role in the future IPv6 environment. This document reuses and extends the method defined in draft-ietf-l3vpn-2547bis-mcast-01 to support multicast traffic in IPv6 VPNs. Specially, both IPv6 core and IPv4 core are considered in this document. The inter-working between an IPv4 site and an IPv6 sited is outside the scope of this document. Table of Contents 1. Introduction................................................3 1.1. Motivations............................................3 1.2. Overview...............................................3 1.3. Scope and target of this document.......................4 2. Protocols and PMSI..........................................4 2.1. Multicast Protocol supported in IPv6 VPN................4 2.2. PMSI to Transmit IPv6 Multicast Traffic.................4 2.3. Auto discovery of MVPN Members..........................5 2.4. ... 3. Extension for BGP and PIM messages...........................5 3.1. MDT SAFI...............................................5 3.2. BGP Connector Attribute.................................6 3.3. PIM RPF Vector.........................................6 3.4. Extensions for MTD TLV..................................7 3.5. Extensions for MDT Join TLV.............................8 4. Encapsulation...............................................8 4.1. Encapsulating IPv6 Traffic In IPv4 Multicast Packet......9 4.2. Encapsulating IPv6 Traffic In IPv6 Multicast Packet......9 5. Security Considerations......................................9 6. IANA Considerations........................................10 7. Acknowledgments............................................10 7.1. Normative References...................................11 7.2. Informative References.................................11 Author's Addresses............................................11 Intellectual Property Statement................................12 Disclaimer of Validity........................................12 Copyright Statement...........................................12 Cao, et al. Expires August 24, 2006 [Page 2] Internet-Draft draft-cao-mcast-for-IPv6-PPVPN-00.txt February 2006 1. Introduction This document describes a method by which a Service Provider may deploy IPv6 multicast service in BGP/MPLS IPv6 VPNs. This document reuses and extends the method defined in [MVPN] and [ROSEN] to support multicast traffic in IPv6 VPNs. Specially, both IPv6 core and Ipv4 core are discussed in this document. This document adopts the definitions, acronyms and mechanisms defined in [MVPN], the details of MVPN will not be re-described unless necessary. 1.1. Motivations With the mature of techniques and more available devices IPv6 has attracted more and more attention than before. BGP/MPLS VPN solution, which is widely accepted and deployed in IPv4 network, has its extension in IPv6 network and called as 6VPN. [6VPN] describes the details of the method. Now several device vendors are planning to provide 6VPN in near future. IP multicast is accepted and used by more and more VPN customers in their private infrastructures. Naturally, 6VPN customer may need deploy multicast in their VPNs as they do in IPv4 VPNs. But in up-to- date documents, there are still little discussions pertaining to multicast in 6VPN. As it is known that implementation of IPv4 MVPN is provided before related specification had been specified, several problems (which are mentioned in [MVPN-EXP]) appeared in deployment. So it is better to pay some attention prior to the commencement of the deployment of IPv6 MVPN. 1.2. Overview [MVPN], as well as early "rosen-drafts", specifies the method to provide multicast service in BGP/MPLS VPNS. The same method can be used to enable multicast traffic transmitted between different IPv6 VPN sites. And form both the Service Provider and the customer perspectives, the multicast service in IPv6 VPN should be identical to that supported in IPv4 VPNs. The PE routers exchange the IPv6 reachability information for IPv6 VPN sites and PMSI is established to transmit IPv6 Multicast traffic through core network. Customers don't care and need not to know the network topology out their private networks. It should be noted that IPv6 6VPN needs to support both IPv4 and IPv6 core network that connect different IPv6 VPN Sites. So IPv6 multicast traffic may be encapsulated in IPv6 or IPv4 packet in the core network. In near future, using IPv4 core network seems Cao, et al. Expires August 24, 2006 [Page 3] Internet-Draft draft-cao-mcast-for-IPv6-PPVPN-00.txt February 2006 more attractive to the Service Providers. If IPv4 core network is used all PE devices have to support IPv4/IPv6 dual stack. 1.3. Scope and target of this document This document hopes to be helpful to the product vendors who plan to support multicast in 6VPN, it mainly concerns the most general problems to the implementations. This document tries to clarify some issues that need to be updated to adapt to IPv6 environment. Methods described in [MVPN] and [ROSEN] will not be re-stated here. The solution details already been discussed in earlier documents, such as RPF determination and spanning multi-as backbones, will be accepted here. New techniques are being discussed such as reducing PIM Join/Prune massages in backbone, using P2MP LSP as MDT tunnel are out of the scope of this document. They will be included in later version of this draft when needed. 2. Protocols and PMSI 2.1. Multicast Protocol supported in IPv6 VPN Currently in IPv6 environment, PIM-SM and PIM-SSM have been widely adopted while DVMRP and PIM-DM lost their position. Other protocols such as Bidir-PIM and multicast MPLS have few implementations in IPv6. No matter which multicast protocol will be widely accepted in IPv6 environment, implementation of IPv6 MVPN should not limit the customers' choices. 2.2. PMSI to Transmit IPv6 Multicast Traffic PMSI, also known as MDT, is used to transmit customer's multicast traffic in IPv4 MVPNs. In theory, many techniques can be taken to create PMSI, such as unicast tunnels (e.g. GRE tunnel) and P2MP LSP tunnels. But in real world PMSI created by PIM-SM/PIM-SSM dominate the available implementation. If IPv4 network is taken as 6VPN's core, all current method to create PMSI can be used in 6VPN. As to IPv6, since currently PIM-SM and PIM/SSM are the best candidates in IPv6 environment, this document suggests implementation chose PIM-SM or PIM-SSM to create PMSI ( MDT ) to transmit IPv6 VPNs' multicast traffic if IPv6 core is used. Of cause other method can be adopted with the evolvement of related techniques. The scenarios to create PMSI are same to that in IPv4 MVPN. If IPv6 core is used, multicast traffic packets are encapsulated in IPv6 packet ( multicast packet). If Ipv4 core is used, PE has to Cao, et al. Expires August 24, 2006 [Page 4] Internet-Draft draft-cao-mcast-for-IPv6-PPVPN-00.txt February 2006 encapsulate IPv6 multicast traffic in IPv4 packet at ingress and de- capsulate those IPv6 packets at PMSI egress. When PMSI is created by IPv4 protocol, in the view of IPv6 multicast VPN VRF, the PMSI is an IPv6 multicast interface. But in the view of public VRF of PE, the PMSI is a common IPv4 tunnel interface. Both I-PMSI and S-PMSI should be supported in IPv6 Multicast PPVPN. Packet encapsulation is discussed at section 4 2.3. Auto discovery of MVPN Members The principle of finding MVPN Members by BGP has been described in [MVPN]. No matter which protocol is used to establish PMSI, neighbor relationship through PMSI can be established by sending PIM HELLO message. However, packet loss may affect the reliability and periodically sending PIM HELLO messages to PMSI lowers the efficiency of the protocol. So this draft recommends BGP-based auto discovery in IPv6 MVPN, other methods are optional. The details of auto discovery will be discussed in later version of this draft. 3. Extension for BGP and PIM messages Several protocol messages' format have been defined in earlier related drafts to support MVPN. Extension of these protocol messages is described bellow. 3.1. MDT SAFI MDT SAFI is defined in [SAFI]. MDT SAFI contains the address of the nexthop which will be used by the multicast source PE to send PIM Join message for the I-PMSI ( default MDT ) address to. It is extended to support IPv6 AFI in this draft. The IPv6 NLRI has similar format with IPv4 NLRI, which is 8-byte- RD: PE-Address followed by the MDT group address. +-------------------------------+ | | | RD:PE-Address (variable) | | | +-------------------------------+ | MDT Group-address (16 octets)| +-------------------------------+ Cao, et al. Expires August 24, 2006 [Page 5] Internet-Draft draft-cao-mcast-for-IPv6-PPVPN-00.txt February 2006 Route-Distinguisher: is the RD of the VRF to which this MDT attribute belongs. PE-Address : is the nexthop address. It may be an IPv6 address or an IPv4 address corresponding to SP backbone network. Whether it is IPv6 or IPv4 can be deduced by the length of NLRI, e.g. a length of 28 octets means IPv4 while a length of 40 octets means IPv6. MDT Group Address : is the Group-address of the MDT-Group that a VRF is associated to. It's length is 16 octets. The usage is the same as of IPv4 MDT SAFI described in [SAFI]. 3.2. BGP Connector Attribute The format and usage in MVPN of BGP Connector attribute is defined in [CONNECTOR] and [SAFI]. It is used to transport the address of the originating PE router to the remote PE router in the same MVPN. The attribute used in IPv6 MVPN contains one or more tuples of the form : +------------------------------+ | | | Type (2 octets) | +------------------------------+ | | | Value (Variable) | | | +------------------------------+ Type : 0x0001 for IPv4 address and 0x8001 for IPv6 address. Value : is an IPv4 address or IPv6 address defined by the Type. If the SP backbone is an IPv4 networks, the Type field is 0x0001 with the Value field contain an IPv4 address. Or if the SP backbone is IPv6, the Type field should be 0x8001 with an IPv6 address in the Value field. Other usage and guidelines of this attribute is the same as defined in [BGP-CONN] and[MDT SAFI]. 3.3. PIM RPF Vector PIM RPF Vector TLV is defined in [RPF-VECTOR]. It is used in an environment when the network's IGP does not have a route to the source of the multicast tree. It consists of a single Vector which Cao, et al. Expires August 24, 2006 [Page 6] Internet-Draft draft-cao-mcast-for-IPv6-PPVPN-00.txt February 2006 identifies the exit point of the network. The usage of PIM RPF Vector in IPv4 MVPN is pointed out in section 5.6 of [ROSEN]. Here we extend the TLV for usage in IPv6 MVPN. The format of PIM RFP Vector in IPv6 MVPN is 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|S| Type | Length | IP address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+....... F bit: Forward Unknown TLV. If this bit is set the TLV is forwarded regardless if the router understands the Type. S bit: Bottom of Stack. If this bit is set then this is the last TLV in the stack. Type: The Vector Attribute type is 0 for IPv4 and 1 for IPv6. Length: Length in bytes is 4 for IPv4 and 16 for IPv6. Value: An IPv4 address or an IPv6 address. 3.4. Extensions for MTD TLV "MDT TLV" has the following format. It uses port 3232. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type (8 bits): the type of the MDT TLV. Currently, 1 is used in IPv4 MVPN MDT Join TLV . For IPv6 MVPN, the filed is to be defined ( 2? ); Length (16 bits): the total number of octets in the TLV for this type, including both the Type and Length field. Cao, et al. Expires August 24, 2006 [Page 7] Internet-Draft draft-cao-mcast-for-IPv6-PPVPN-00.txt February 2006 Value (variable length): the content of the TLV. 3.5. Extensions for MDT Join TLV "MDT Join TLV" has the following format. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 C-source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 C-group | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4/IPv6 P-group | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type (8 bits): as defined above. For MDT Join TLV in IPv6 VPN, the value of the field is 2. Length (16 bits): as defined above. Reserved (8 bits): for future use. IPv6 C-Source (128 bits): the IPv6 address of the traffic source in the IPv6 VPN. IPv6 C-Group (128 bits): the IPv6 address of the multicast traffic destination address in the IPv6 VPN. IPv4/IPv6 P-Group (32/128 bits): the IPv4/IPv6 group address that the PE router is going to use to encapsulate the traffic flow (C-Source, C-Group). 4. Encapsulation IPv6 multicast traffic is encapsulated in PMSI which can be created by different method. With different core networks used and different Cao, et al. Expires August 24, 2006 [Page 8] Internet-Draft draft-cao-mcast-for-IPv6-PPVPN-00.txt February 2006 protocols chosen, different encapsulation formats need to be defined. As in IPv4 MVPN, GRE encapsulation is recommended method to send multicast through PMSI. 4.1. Encapsulating IPv6 Traffic In IPv4 Multicast Packet If the core network is based on IPv4, the encapsulation format should be: ---------------------------------------------------------------- | P-IPv4 Header | GRE | C-IPv6 Header | C-Payload | ---------------------------------------------------------------- In IPv4 MVPN, the Protocol Number field in the P-IPv4 header must be set to 47 and Protocol Type field of the GRE Header is set to be 0x800 .When IPv6 packet is encapsulated in IPv4 MGRE, the same number may be used. It seems that filling the GRE Header with different number may bring some benefit. Current devices generally have control plane and packet forwarding plane. It is easy for control plane to distinguish whether it is IPv6 packet or IPv4 packet that is encapsulated in GRE because the IPv4 group address (or LSP label or other tunnel identifier) used for P-IPv4 Header is determined before the PMSI is created. But for packet forwarding plane, distinguishing which kind of packets are encapsulated may require looking up table or looking deeper in GRE packet content and consume more hardware resource. This should be discussed in latter version of this draft. 4.2. Encapsulating IPv6 Traffic In IPv6 Multicast Packet If the core network is based on IPv6, the encapsulation format should be: ---------------------------------------------------------------- | P-IPv6 Header | GRE | C-IPv6 Header | C-Payload | ---------------------------------------------------------------- The Protocol Number filed in the P-IPv6 head must be set to 47 and Protocol Type field of the GRE Header must be set to be 0x800. 5. Security Considerations This document has no known security implications. Cao, et al. Expires August 24, 2006 [Page 9] Internet-Draft draft-cao-mcast-for-IPv6-PPVPN-00.txt February 2006 6. IANA Considerations This document creates no new requirements on IANA namespaces. 7. Acknowledgments We'd like to thank Hongfei Chen for his feedback on this draft. Cao, et al. Expires August 24, 2006 [Page 10] Internet-Draft draft-cao-mcast-for-IPv6-PPVPN-00.txt February 2006 References 7.1. Normative References [2547bis] "BGP/MPLS VPNs", Rosen, Rekhter, et. al., September 2003, draft-ietf-l3vpn-rfc2547bis-01.txt [MVPN] "Multicast in MPLS/BGP IP VPNs", Rosen, Aggarwal, May 2005, draft-ietf-l3vpn-2547bis-mcast-03.txt 7.2. Informative References [ROSEN-8] E. Rosen, Y. Cai, I. Wijnands, "Multicast in MPLS/BGP IP VPNs", draft-rosen-vpn-mcast-08.txt [MVPN-PIM] R. Aggarwal, A. Lohiya, T. Pusateri, Y. Rekhter, "Base Specification for Multicast in MPLS/BGP VPNs", draft- raggarwa-l3vpn-2547-mvpn-00.txt [RAGGARWA-MCAST] R. Aggarwal, et. al., "Multicast in BGP/MPLS VPNs and VPLS", draft-raggarwa-l3vpn-mvpn-vpls-mcast--01.txt". [RP-MVPN] S. Yasukawa, et. al., "BGP/MPLS IP Multicast VPNs", draft- yasukawa-l3vpn-p2mp-mcast-00.txt [MDT SAFI] G. Nalawade, et. al., "MDT SAFI", draft-nalawade-idr-mdt- safi-03.txt [RPF-VECTOR ]draft-ietf-pim-rpf-vector-01 [MVPN-EXP] Yiqun Cai, Mike McBride, Chris Hall. ''Experience With Multicast VPN'', draft-ycai-mvpn-experience-00 [BGP-CONN] Gargi Nalawade, Ruchi Kapoor, David Ward. ''BGP Connector Attribute'', draft-nalawade-l3vpn-bgp-connector-00.txt Author's Addresses Wei Cao Huawei Technologies Co., Ltd. Email: caowayne@huawei.com Hui Liu Huawei Technologies Co., Ltd. Email: liuhui47967@huawei.comm Cao, et al. Expires August 24, 2006 [Page 11] Internet-Draft draft-cao-mcast-for-IPv6-PPVPN-00.txt February 2006 Qiang He Email: heqiangc@hotmail.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 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 (2006). 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. Cao, et al. Expires August 24, 2006 [Page 12]