L3VPN Working Group L. Han, Ed. Internet-Draft R. Li Intended status: Standards Track Huawei Technologies Expires: January 31, 2013 July 30, 2012 Multicast VPN Support by Receiver-Driven Multicast Extensions to RSVP-TE draft-hlj-l3vpn-mvpn-mrsvp-te-01 Abstract This document describes a method to support multicast VPN (MVPN) by a receiver-driven multicast extension to RSVP-TE (mRSVP-TE). This method is desirable and applicable to MVPN applications when QoS assurance and traffic-engineered tunnels are desired. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 31, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Han & Li Expires January 31, 2013 [Page 1] Internet-Draft mVPN support by mRSVP-TE July 2012 This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Multicast LSP . . . . . . . . . . . . . . . . . . . . . . 7 3.2. PIM States, PIM Interfaces and PMSI . . . . . . . . . . . 7 3.3. Reverse-Path Forwarding . . . . . . . . . . . . . . . . . 8 3.4. Default mLSP . . . . . . . . . . . . . . . . . . . . . . . 9 3.4.1. Establishment of Default mLSP . . . . . . . . . . . . 9 3.4.2. Virtual PIM Interface for Default mLSP . . . . . . . . 10 3.4.3. PIM signaling over Default mLSP . . . . . . . . . . . 10 3.4.4. PIM state with Default mLSP . . . . . . . . . . . . . 12 3.4.5. Multicast data over default mLSP . . . . . . . . . . . 13 3.5. Data mLSP . . . . . . . . . . . . . . . . . . . . . . . . 13 3.5.1. Establishment of Data mLSP . . . . . . . . . . . . . . 13 3.5.2. Virtual PIM interface for Data mLSP . . . . . . . . . 14 3.5.3. mLSP ID and data mLSP mapping . . . . . . . . . . . . 14 3.5.4. Switching of Data mLSP . . . . . . . . . . . . . . . . 15 3.5.5. PIM Prune Impact to Data mLSP . . . . . . . . . . . . 15 3.5.6. Deletion of Data mLSP . . . . . . . . . . . . . . . . 16 3.5.7. PIM (S,G) signaling after Data mLSP is created . . . . 16 4. PIM-SSM Solutions . . . . . . . . . . . . . . . . . . . . . . 16 4.1. Option 1 . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2. Option 2 . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.3. Option 3 . . . . . . . . . . . . . . . . . . . . . . . . . 17 5. PIM-SM solutions . . . . . . . . . . . . . . . . . . . . . . . 18 5.1. RP-PE mLSP . . . . . . . . . . . . . . . . . . . . . . . . 18 5.2. Source-PE mLSP . . . . . . . . . . . . . . . . . . . . . . 18 5.3. PIM register process . . . . . . . . . . . . . . . . . . . 18 5.3.1. Scenario 1: The multicast source and RP are behind the same PE . . . . . . . . . . . . . . . . . . . . . 18 5.3.2. Scenario 2: The multicast source and RP are behind the different PE . . . . . . . . . . . . . . . . . . . 19 Han & Li Expires January 31, 2013 [Page 2] Internet-Draft mVPN support by mRSVP-TE July 2012 5.4. SPT switching . . . . . . . . . . . . . . . . . . . . . . 21 5.5. RPT prune . . . . . . . . . . . . . . . . . . . . . . . . 21 5.6. Data mLSP switching . . . . . . . . . . . . . . . . . . . 21 5.7. PIM state at Receiver-PE . . . . . . . . . . . . . . . . . 22 6. Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . 22 6.1. Aggregation by Default mLSP . . . . . . . . . . . . . . . 23 6.2. Aggregation by Data mLSP . . . . . . . . . . . . . . . . . 23 7. Non-VPN multicast support . . . . . . . . . . . . . . . . . . 23 8. Message Format and Constants . . . . . . . . . . . . . . . . . 24 8.1. Path session object for PIM-SSM option 1 (IPv4) . . . . . 24 8.2. Path session object for PIM-SSM option 1 (IPv6) . . . . . 25 8.3. Path session object for other PIM modes (IPv4) . . . . . . 26 8.4. Path session object for other PIM modes (IPv6) . . . . . . 27 8.5. mLSP TLV Message format for IPv4 . . . . . . . . . . . . . 27 8.6. mLSP TLV Message format for IPv6 . . . . . . . . . . . . . 28 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 11. Security Considerations . . . . . . . . . . . . . . . . . . . 29 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 12.1. Normative References . . . . . . . . . . . . . . . . . . . 29 12.2. Informative References . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Han & Li Expires January 31, 2013 [Page 3] Internet-Draft mVPN support by mRSVP-TE July 2012 1. Introduction A L3VPN service that supports multicast is known as a Multicast VPN, or MVPN for short. There have been different proposed messages, procedures and mechanisms to support MVPN. These methods differ in protocols used in the service provider's network, for example, the mGRE-based MVPN, BGP extensions to transport customer's PIM signaling and P2MP RSVP-TE extensions to transport multicast data streams, and mLDP-based MVPN, as summarized as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Data Plane| Protocols for core | Standard| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | mGRE | PIM, BGP(with MDT_SAFI) | RFC6037 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | MPLS | P2MP RSVP-TE, BGP(with extension) | RFC6513 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 | MPLS | mLDP | No | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Table 1. Existing mVPN Solutions Type 1 solution requires to run PIM in the service provider's network. Both Type 2 and Type 3 require an MPLS data forwarding plane, but they differ in protocols used in the service provider's network. Type 2 uses RSVP-TE with a P2MP extension [RFC4875] for multicast data streams and BGP extensions with multicast encodings and procedures [RFC6514] for PIM signaling, or use mLDP [RFC6388] for both control plane signaling and multicast data streams. Type 3 is simpler than type 2 in terms of required protocols and provisioning. With Type 2 solution, multicast traffic is carried over MPLS-TE tunnels, QoS and traffic engineering are supported for mVPN applications. It is an advantage of Type 2 over Type 3. However, for Type 2 solution, BGP has to be extended with seven (7) types of MCAST-VPN NLRIs together with four (4) new BGP attributes. In some scenarios, multiple P2MP RSVP-TE tunnels are used. And therefore, it requires to upgrade both BGP and RSVP-TE, which brings more complexity and operational inconvenience. In addition to the above-mentioned three methods, do we have any alternative method which is expected to be simpler and more scalable, but can still provide QoS assurance and traffic-engineered transport? This document specifies a new method to implement multicast VPN by Han & Li Expires January 31, 2013 [Page 4] Internet-Draft mVPN support by mRSVP-TE July 2012 receiver-driven multicast extensions to RSVP-TE (mRSVP-TE) specified in [I-D.lzj-mpls-receiver-driven-multicast-rsvp-te]. mRSVP-TE is a new extension to RSVP-TE for multicast applications in MPLS networks, whose behavior is closer to IP PIM since both of them work by sending control messages from the data receivers to the data senders. The receiver-driven nature of the mRSVP-TE makes it more adaptive and easier to be integrated with PIM for multicast applications including multicast VPN. As an extension to RSVP-TE, mRSVP-TE inherits all the desirable features from RSVP-TE such as QoS assurance and traffic-engineered paths, which makes it to distinguish from mLDP used in Type 3. By using an MP2MP tunnel created by mRSVP-TE to carry the customer's PIM signaling, we do not need to use BGP multicast extension to signal customer's multicast information. The MVPN method described in the document supports both PIM-SSM and PIM-SM. For PIM-SM, this method supports multicast source, receiver, Rendezvous Point (RP) located at any place including PE, CE or any device connected to CE. It can also support Bootstrap Router (BSR) Mechanism [RFC5059]. 2. Terminology 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 [RFC2119] and indicate requirement levels for compliant MVPN implementations. 2.1. Definitions In what follows we describe some terminologies which are widely used in this document. Source-PE Source-PE is a PE which is connected to a MVPN CE and the multicast source is on or behind the CE. Receiver-PE Receiver-PE is a PE which is connected to a MVPN CE and the multicast receiver is on or behind the CE RP-PE RP PE is a PE which is connected to a MVPN CE and the multicast Rendezvous Point for PIM-SM is on or behind the CE Han & Li Expires January 31, 2013 [Page 5] Internet-Draft mVPN support by mRSVP-TE July 2012 PE type A PE can be either Source-PE, Receiver-PE or RP-PE for different MVPN and different (S,G). Its type can also be the mixture of any combination of the three PE type. MDT Multicast Distribution Tree, introduced in [RFC6037] for the IP backbone based MVPN. MDT is composed of mGRE tunnels. There are default MDT and data MDT mLSP Multicast-Label-Switched-Path. It is the equivalent of MDT in MPLS networks, and sometimes we will use mLSP and MDT interchangeably. The same as MDT, we also have default mLSP and data mLSP. Source-PE mLSP mLSP whose header-end is a Source-PE. RP-PE mLSP mLSP whose header-end is a RP-PE. MI-PMSI(MVPN_ID) It corresponds to the MI-PMSI [RFC6513] for a MVPN (ID is MVPN_ID), it is the Multidirectional Inclusive P-Multicast Service interface for the default mLSP or the MP2MP tunnel at either tail-end or header-end. S-PMSI(MVPN_ID, mLSP_ID) It corresponds to a S-PMSI [RFC6513] for a MVPN (ID is MVPN_ID) and the mLSP ID is mLSP_ID, it is the Selective P-Multicast Service interface for the P2MP tunnel for (S,G) at either tail- end or header-end. OIF Outgoing Interface for PIM state IIF Incoming Interface for PIM state Olist Outgoing Interface list for PIM state 3. Overview Han & Li Expires January 31, 2013 [Page 6] Internet-Draft mVPN support by mRSVP-TE July 2012 3.1. Multicast LSP Multicast-Label-Switched-Path (mLSP) is an MPLS tree in MPLS network to distribute multicast data to different receivers who are interested in particular multicasted data stream(s). An mLSP is composed of multiple Sub-Label-Switched-Paths (sub-LSP) which connect different Label Switch Routers (LSRs) to form an MPLS multicast network. There are two basic types of mLSPs: P2MP LSP and MP2MP LSP. In the case of P2MP LSP, the header-end of an mLSP is the Source-PE which connects the source device of multicast traffic, and its tail- ends are the Receiver-PEs which connect the destination device of multicast traffic. The joint points on an mLSP are called "Branch LSR" where the MPLS packets are replicated and then forwarded to different downstream LSRs. In the case of MP2MP LSP, there is a special LSR which serves as the root of the mLSP, and all the leaf nodes are both the Source-PE and Receiver-PEs. For mVPN multicast traffic, it travels on a multicast tree which spans over two different networks: MPLS network operated by service providers and IP network on the customer's sites. The mVPN multicast traffic always starts from one customer's site as IP multicast, and then is transported over the MPLS network to other customer's sites. The traffic on customer's sites is distributed over a PIM multicast distribution tree, while in service provider's MPLS network it is distributed by mLSP tunnels. The mLSP and the PIM distribution tree SHOULD be seamlessly integrated. The IP multicast data received from a CE is encapsulated as MPLS packet at the Source-PE of an mLSP tree, and then transported over the mLSP. The MPLS packet is replicated at the branch LSRs and delivered to the different Receiver-PEs, where the MPLS packet is de-capsulated to IP multicast packet and forwarded to the connected IP multicast tree, then it is distributed to the particular receivers. 3.2. PIM States, PIM Interfaces and PMSI It is assumed that PIM is used on customer's sites and mRSVP-TE is used in service provider's network without PIM being enabled in service provider's network. In order to set up customer's multicast distribution trees across a service provider's MPLS network, it is desired that the customer's PIM SHOULD inter-work with service provider's mRSVP-TE, which brings up some new requirements about PIM states and interfaces. The most important factors for PIM states are the IIF and OIF, both of which are PIM-enabled interfaces. A PIM interface appearing in an PIM state is characterized as follows: Han & Li Expires January 31, 2013 [Page 7] Internet-Draft mVPN support by mRSVP-TE July 2012 o It has an IP address configured o It has the PIM protocol enabled and running o It has one or more PIM adjacencies Since the customer's PIM adjacencies MUST be established between PEs, virtual interfaces associated with the MPLS tunnels connecting PEs are introduced. Such virtual interfaces are also called PMSI for Provider Multicast Service Interface. In this document we will use two types of PMSI: MI-PMSI and S-PMSI. 3.3. Reverse-Path Forwarding For multicast forwarding by a PIM state (S,G), we need to check if the packet is coming from the expected interface which is the egress interface to reach the source S based on the unicast routing table. The expected interface is called RPF interface, or the IIF (Incoming interface). In this document, we will consider the following two modes: o PIM-SSM mode: the state to forward traffic is (S,G), so there is only one IIF for a (S,G). o PIM-SM mode: RP will have (*,G) before the traffic is received and (S,G) after the register processing is finished. Other routers have (*,G) before the SPT switching and (S,G) after the SPT switching. For the (*,G), the RPF is the interface to reach RP by unicast routing. In the context of mVPN, PE is the boundary router between customer's IP network and service provider's MPLS network, and thus needs to handle the RPF issue as follows: o For a Source-PE, the RPF checking for any (S,G) does not have any change since the IIF is still a normal IP interface. o For a Receiver-PE, the RPF interface for any (S,G) or (*,G) is not derived from the unicast routing table for the multicast source S or RP for a multicast stream. Instead, we MUST force the RPF interface to be the PIM interface which is associated with either an MI-PMSI or an S-PMSI. o For a RP-PE, before traffic starts, the RPF interface is not set for (*,G) since the multicast source is unknown. After the PIM register process is completed, the (S,G) state will be created. Then we MUST force the RPF interface to be the PIM interface which is associated with the MI-PMSI for the MVPN. Han & Li Expires January 31, 2013 [Page 8] Internet-Draft mVPN support by mRSVP-TE July 2012 RPF does not apply to the multicast forwarding in MPLS network by mLSP. mLSP established by mRSVP-TE protocol can guarantee the loop- free for packet forwarding which is the whole purpose of RPF checking. 3.4. Default mLSP To each mVPN, we associate an mLSP, called its default mLSP. Given an mVPN, its default mLSP is a multi-directional shared tree with all the PEs as its leaf nodes. Default mLSP is a MP2MP tunnel which can provide a multi-directional transportation for any data. The default mLSP is used for the following two purposes: o Cusomer's PIM signaling: Cusomer's PIM signaling is transported over such default mLSP o Default customer's multicast data distribution: Customer's multicast data are transported and distributed over such mLSP by default. 3.4.1. Establishment of Default mLSP The construction of default mLSP does not depend on the existence of multicast traffic for a MVPN; it is built up before any such multicast traffic is seen. Default mLSP is established when a VPN attached to a PE enables MVPN service. After the MVPN is enabled, the mRSVP-TE stack MUST send the mRSVP-TE path message continuously. The time interval to send the path message at each PE could be default value or configurable. If it is configurable, different PE's interval value MUST be proper to guarantee the mLSP state is steady without any flapping. To enable MVPN service on a PE, root node(s) IP address MUST be given. Root node is normally a P router inside the backbone network. The location of root node may impact the efficiency of a MP2MP tunnel. How to choose a root node to establish a MP2MP tunnel to obtain the efficient multicast replication in MPLS network is out of scope of the document. In addition to the root node, explicit nodes from any PE to the root node P MAY be applied as an option if user wants the path from the root node P to a PE goes through some expected routers. For the details of root node and explicit node in a MP2MP tunnel, please refer to the [I-D.lzj-mpls-receiver-driven-multicast-rsvp-te]. Han & Li Expires January 31, 2013 [Page 9] Internet-Draft mVPN support by mRSVP-TE July 2012 If the redundancy for the root node is desired to protect the failure of root node, multiple root nodes may be given to construct multiple default mLSP. The redundancy for root node is out of scope of this document. With the method herein, there is only one default mLSP for each MVPN, or two for root redundancy case, 3.4.2. Virtual PIM Interface for Default mLSP A MI-MPSI interface SHOULD be created at both Source-PE and Receiver-PE when the default mLSP for a MVPN is established. This is a PIM enabled interface for a MVPN. It is used for PIM adjacency, PIM state keeping, and PIM IIF and OIF representation for the MPLS packet forwarding over MPLS network. MI-PMSI is a joint point of IP multicast tree and mLSP. If a MI-PMSI is one OIF in the Olist for a multicast forwarding entry (S,G), it means the IP multicast stream (S,G) will be replicated for the MI- PMSI and sent to the interface. If a MI-PMSI is the IIF for a multicast forwarding entry (S,G), it means the MPLS packet received from MI-PMSI will be forwarded by the forwarding entry (S,G) if the de-capsulated MPLS packet is IP packet, and source and group are S and G respectively. MI-PMSI is a PIM interface and its IP address will be the address for the PIM peering. This address on one PE MUST be reachable from all other PEs. When PIM adjacency are established between PEs, one PE can see all its PIM adjacency's MI-PMSI are up. For the convenience, it is RECOMMENDED to use the BGP source address for the BGP session between PEs for MI-PMSI. The BGP session here refers to the BGP for unicast VPN service. All PIM hello variables for a virtual interface MI-PMSI, such as timer, are default value when the interface is created. But they could be configurable and this is up to the implementation. 3.4.3. PIM signaling over Default mLSP For MVPN attached PE, PIM is enabled for the interfaces connecting different CEs which may belong to the same or different VPNs. Each interface has a MVPN instance associated with it. After a MI- PMSI(MVPN_ID) is created for a default mLSP, it MUST join the same PIM domain for the particular MVPN. The default mLSP SHOULD support all PIM multicast messages: Han & Li Expires January 31, 2013 [Page 10] Internet-Draft mVPN support by mRSVP-TE July 2012 o HELLO message o JOIN/PRUNE message o ASSERT o BOOTSTRAP For the following PIM unicast message, they SHOULD NOT be sent to the default mLSP, instead, they SHOULD be sent over a unicast MPLS tunnel to the destination PE. o REGISTER message o REGISTER-STOP message o GRAFT o GRAFT-ACK o CANDIDATE-RP-ADV For one MVPN at a PE, PIM signaling (multicast) messages SHOULD be multicasted to all PIM interfaces for that particular MVPN including MI-PMSI. PIM messages are sent to a MI-PMSI(MVPN_ID) immediately after the interface is created. The messages are encapsulated to MPLS packets and will be distributed to all other receiver-PEs in the same MVPN through the default mLSP. At Receiver-PE, the MPLS packets are de-capsulated and delivered to a particular MVPN, the MVPN ID is determined by the MPLS label which was allocated locally on Receiver-PE when the PE initializes the default mLSP by sending mRSVP-TE path message to the root node. The popped MPLS label from the received MPLS packet can associate the packet with a MI-PMSI(MVPN_ID) interface as incoming interface, So, the MI-PMSI(MVPN_ID) interface at Receiver-PE can be used for RPF checking of multicast forwarding. Receiver-PE SHOULD punt PIM signaling message to PIM protocol stack for the particular MVPN. After all PIM HELLO messages are exchanged between PEs, PIM adjacencies are established between multiple PEs through each PE's MI-PMSI(MVPN_ID) which is associated with a particular MVPN. As the result of PIM adjacency over the default mLSP, the details of MPLS backbone network topology is hidden for PIM. It will make the MVPN PIM virtually run over a virtual muti-access interface which is composed of multiple MI-PMSI(MVPN_ID) from different PEs. Han & Li Expires January 31, 2013 [Page 11] Internet-Draft mVPN support by mRSVP-TE July 2012 3.4.4. PIM state with Default mLSP Since the MI-PMSI interface is a PIM enabled interface, all PIM multicast messages, Hello, Join, Prune, Bootstrap and Assert, can be sent to or received from the MI-PMSI interface. PIM protocol can create and update the appropriate state for a MVPN accordingly. MI- PMSI can behavior as a normal PIM interface to join or exit the Olist for PIM state. Below is the detail of the PIM processing for different PIM modes and join messages. All behaviors are based on the PIM protocol and some PIM changes are required for MVPN solution described in this document. (S,G) join for PIM-SSM When a Receiver-PE receives PIM (S,G) join message from attached CE, it SHOULD send the join message through MI- PMSI(MVPN_ID) interface to the default mLSP. Meanwhile, if PIM (S,G) state was not created on the Receiver-PE, PIM MUST create a (S,G) state for which the MI-PMSI(MVPN_ID) is IIF. As a result of sending PIM join message to MI-PMSI(MVPN_ID) interface, the message will be populated to all PEs connected to the same default mLSP. However, only Source-PE SHOULD process the PIM join message. The Source-PE is derived from the BGP next hop of source address S. All other PEs SHOULD ignore the join message. After the Source-PE receives the (S,G) join from a default mLSP, if the PIM (S,G) state was not created, PIM SHOULD create a PIM (S,G) state for multicast routing table, the entry SHOULD add MI-PMSI(MVPN_ID) to its Olist. After the 1st PIM join message is processed at both Receiver-PE and Source-PE, the subsequent PIM join message will only reset the PIM timer and will not change the PIM (S,G) state. This behavior is same as PIM in IP network. (*,G,RP) join for PIM-SM PIM-SM (*,G) join message will be populated through default mLSP to all PEs attached to the same mLSP. The behavior for PIM (*,G) join is the same as PIM-SSM. The only difference is that (*,G) join is sent to RP (Rendezvous Points). As a result, only RP-PE SHOULD process the PIM join message. The RP-PE is derived from the BGP next hop of RP address. All other PEs SHOULD ignore the join message. After the PIM (*,G) join message is sent from Receiver-PE and received by RP-PE. PIM SHOULD create a (*,G) state on Receiver-PE, for which the MI-PMSI(MVPN_ID) is IIF. PIM SHOULD create a (*,G) state at RP-PE and add the MI-PMSI(MVPN_ID) to its Olist. PIM prune message processing has no change on PE, it may lead to the Han & Li Expires January 31, 2013 [Page 12] Internet-Draft mVPN support by mRSVP-TE July 2012 interface state change for a PIM state, or a PIM state deletion. When a PIM state is deleted on a receiver-PE, it MUST send the PIM prune message to the default mLSP to forward the prune message to source-PE or RP-PE. When a Source-PE or RP-PE receives a prune message from the default mLSP, it MUST prune the MI-PMSI from the PIM state's Olist. 3.4.5. Multicast data over default mLSP If a default mLSP is used to carry user's multicast data, it will send the multicast data to all PEs connected to the default mLSP, no matter if a PE is intended or not to receive the particular multicast traffic. The PIM join or prune does not start or stop the traffic over the default mLSP. This is normally used for the beginning of the multicast traffic flowing when the traffic rate is low. Obviously, there are two drawbacks for it o Some PE may not want to receive some multicast traffic, this will be wasteful for the bandwidth and resource for routers. o Too much multicast data shares one tree can congest the MP2MP tunnel. To overcome above problems, data mLSP is used to offload the data traffic from the default mLSP. 3.5. Data mLSP Data mLSP is used to offload some data stream from the default mLSP. It is a P2MP tunnel corresponding to a (S,G) entry in a MVPN. Data mLSP is built up either statically or dynamically depending on the solutions for different PIM modes. Section 4 and 5 will discuss details. 3.5.1. Establishment of Data mLSP Static data mLSP establishment is triggered by a Receiver-PE to send the mRSVP-TE P2MP path message to a Source-PE. It will be described in section 4.1. Dynamical data mLSP establishment is driven by the multicast traffic. The mechanism is similar to the data MDT described in [RFC6037]. Source-PE MUST monitor the rate of all multicast streams passing through it. As for how to monitor the traffic rate, it is out of the scope of the document. When a Source-PE detects the rate of a MVPN multicast stream (S,G) Han & Li Expires January 31, 2013 [Page 13] Internet-Draft mVPN support by mRSVP-TE July 2012 exceeds the pre-configured threshold, it MUST send a data mLSP join TLV to the default data mLSP. The format of data mLSP join TLV is defined in section 8.5 and 8.6. The data mLSP join TLV will be flooded to all PE connected to the same default mLSP. When a PE receives the data mLSP join TLV and if the PE has joined the group G, it MUST initialize the setup of P2MP tunnel by sending the mRSVP-TE P2MP path message to the Source-PE for (S,G). Source-PE address is derived from the BGP nexhop of the VPN address S. The periodically sending of mRSVP-TE path message from receiver-PE to Source-PE is driven by the periodically received mLSP join TLV message at receiver-PE The operation of data mLSP is similar to the operation of data MDT for mGRE based mVPN. It has four timer defined to govern the data mLSP: MDT_DATA_DELAY, MDT_DATA_TIMEOUT, MDT_DATA_HOLDDOWN, MDT_INTERVAL. For the detailed definition of those timers and operations, please refer to [RFC6037]. Since the interval to receive mLSP join TLV message will determine the interval to send mRSVP-TE path message, we SHOULD make sure the interval of mLSP join TLV is less than the timeout value of sub-LSP created by the mRSVP-TE path message. 3.5.2. Virtual PIM interface for Data mLSP After a data mLSP is created, the S-PMSI(MVPN_ID,mLSP_ID) MUST be instantiated. S-PMSI(MVPN_ID,mLSP_ID) is only used for Incoming Interface (IIF) at Receiver-PE and Outgoing Interface (OIF) at Source-PE for the multicast forwarding, it is not used for PIM signaling. The mLSP_ID is "mLSP ID" shown in Fig.3 which is assigned at Source-PE. S-PMSI(MVPN_ID,mLSP_ID) points to the same PIM interface as MI- PMSI(MVPN_ID). It only adds extra L2 rewriting information block to the PIM interface for the packet forwarding purpose. 3.5.3. mLSP ID and data mLSP mapping Data mLSP is identified by "mLSP ID" which is defined in section 8.3 and 8.4. mLSP ID is a 4 byte value starting from 1 for data mLSP. mLSP ID 0 is reserved for the default mLSP. mLSP ID is to distinguish different data mLSP (P2MP tunnel) at Source-PE side. During the data mLSP building, the mLSP ID allocated at a Source-PE MUST be notified Han & Li Expires January 31, 2013 [Page 14] Internet-Draft mVPN support by mRSVP-TE July 2012 to all Receiver-PE by the mLSP join TLV. When a Source-PE detects the rate of a MVPN multicast stream (S,G) exceeds the pre-configured threshold, it MUST assign a mLSP ID from its mLSP pool for the (S,G). And the mLSP join TLV message binds (S,G) with mLSP ID. The Receiver-PE receiving the mLSP join TLV will know the binding relationship. As a result, both Source-PE and Receiver-PE will have a mapping for the mLSP ID and data mLSP, this is used for the switching of data MDT for a stream (S,G). After a data MLSP is deleted, the associated mLSP ID MUST be returned to the mLSP pool. 3.5.4. Switching of Data mLSP The Source-PE SHOULD switch the traffic from default mLSP to data mLSP after it created the data mLSP for a multicast stream (S,G). The mLSP ID and data mLSP mapping information will tell which data mLSP is used for which stream (S,G). From the PIM state point of view, at Source-PE, the PIM state (S,G) SHOULD change the OIF from MI-PMSI(MVPN_ID) to S-PMSI(MVPN_ID, mLSP_ID). Since MI-PMSI(MVPN_ID) and S-PMSI(MVPN_ID, mLSP_ID) share the same PIM interface, the switching essentially means the MPLS forwarding is switched from the MP2MP tunnel to P2MP tunnel. There is no PIM interface changing for PIM signaling during and after the data mLSP switching After switching, Receiver-PE MUST use the correct data mLSP associated S-PMSI(MVPN_ID, mLSP_ID) for the RPF checking for a stream (S,G). The data mLSP switching is associated with the change of forwarding state for (S,G) as following o Source-PE MUST modify the OIF from MI-PMSI(MVPN_ID) to S-PMSI(MVPN_ID, mLSP_ID). o Receiver-PE MUST modify the IIF from MI-PMSI(MVPN_ID) to S-PMSI(MVPN_ID, mLSP_ID). 3.5.5. PIM Prune Impact to Data mLSP When the multicast data is transported over a data mLSP, the PIM prune may cause the prune of the data mLSP tree. After a Receiver-PE receives PIM prune message and if the prune message leads to the IIF prune for a PIM state, it MUST update the PIM state in such that the IIF represented by the S-PMSI(MVPN_ID,mLSP_ID) is pruned. And the Receiver-PE MUST send the mRSVP-TE PATHTEAR message to the upstream LSR to prune the data mLSP tree. If a Source-PE receives the Han & Li Expires January 31, 2013 [Page 15] Internet-Draft mVPN support by mRSVP-TE July 2012 mRSVP-TE PATHTEAR message, the whole data mLSP is deleted and Source-PE MUST stop flooding the mLSP join TLV to the default mLSP. 3.5.6. Deletion of Data mLSP Data mLSP join TLV will be flooded through default mLSP periodically by the interval of MDT_INTERVAL [RFC6037], if during the timeout period defined by MDT_DATA_TIMEOUT [RFC6037], there is no mLSP join TLV received for a receiver-PE, the receiver-PE will start to delete the P2MP leaf from the data mLSP. This is done by sending mRSVP-TE PATHTEAR message to the upstream LSR. After the whole data mLSP is deleted, the traffic will be switched back to the default mLSP. 3.5.7. PIM (S,G) signaling after Data mLSP is created When a data mLSP is created for a particular multicast stream (S,G), the PIM signaling is not changed. PIM join, prune for (S,G) is still going through the default mLSP. 4. PIM-SSM Solutions To support PIM-SSM by mRSVP, we have three options. 4.1. Option 1 PIM (S,G) join message received at Receiver-PE MUST trigger the data mLSP setup by sending a mRSVP-TE P2MP path message to the Source-PE, if the data mLSP was not created before. Source-PE address is the BGP next hop of the address S. The mRSVP-TE path message MUST embed the (S,G) information as shown in Fig. 1. PIM join message is sent to default mLSP and received by the Source-PE. This SHOULD trigger the PIM (S,G) state created at Source-PE and Receiver-PE. The (S,G) state at Source-PE MUST add the S-PMSI(MVPN_ID,mLSP_ID) for the data mLSP to its Olist; The (S,G) state at reveier-PE SHOULD set the S-PMSI(MVPN_ID,mLSP_ID) as IIF. After the PIM (S,G) state created at Source-PE, the traffic can be sent to data mLSP immediately. The P2MP mRSVP-TE path message for data mLSP MUST include the ERO objects when the explicit path is given for the source S. There is no default mLSP to data mLSP switching for this option. Han & Li Expires January 31, 2013 [Page 16] Internet-Draft mVPN support by mRSVP-TE July 2012 4.2. Option 2 PIM (S,G) join message received at Receiver-PE MUST be sent to the default mLSP and received by the Source-PE. This SHOULD trigger the PIM (S,G) state created at Source-PE and Receiver-PE, if the PIM state was not created before. The PIM (S,G) state at Source-PE SHOULD add the MI-PMSI(MVPN_ID) as OIF; The (S,G) state at receiver-PE SHOULD add the MI-PMSI(MVPN_ID) as IIF. After the (S,G) state created at source-PE, the traffic can be sent to the default mLSP. Source-PE MUST detects the rate for the multicast stream (S,G) in a MVPN. If the traffic rate for (S,G) exceeds the configured threshold, the Source-PE MUST flood the mLSP join TLV to all PEs. Each PE, if it is interested to receive the traffic for (S,G), MUST initialize a mRSVP-TE P2MP path message to the Source-PE. The P2MP path message MUST include the ERO objects when the explicit path is given for the source S. After the Source-PE creates a data mLSP for (S,G), it MUST switch the traffic from default mLSP to data mLSP. 4.3. Option 3 PIM (S,G) join message received at Receiver-PE MUST be sent to the default mLSP and received by the Source-PE. This SHOULD trigger the PIM (S,G) state created at Source-PE and Receiver-PE, if the PIM state was not created before. Unlike the option 2, PIM does not add the default mLSP interface MI-PMSI(MVPN_ID) as the IIF and OIF for (S,G) state. In stead, Source-PE MUST trigger a mLSP join TLV flooded to all PEs. Each PE, if it is interested to receive the traffic for (S,G), MUST initialize a mRSVP-TE P2MP path message to the Source-PE to build up a data mLSP. As the result of data mLSP setup, The PIM (S,G) state at receiver-PE MUST add the S-PMSI(MVPN_ID, mLSP_ID) as IIF. At the Source-PE, after the data mLSP is created. The PIM (S,G) state MUST add the S-PMSI(MVPN_ID, mLSP_ID) as OIF; The P2MP path message MUST include the ERO objects when the explicit path is given for the source S. There is no default mLSP to data mLSP switching for this option. Han & Li Expires January 31, 2013 [Page 17] Internet-Draft mVPN support by mRSVP-TE July 2012 5. PIM-SM solutions PIM-SM supporting is different to the PIM-SSM. It involves some extra process like PIM register, register stop, RPT and SPT switching, etc [RFC4601]. Following describes the details of different scenarios for MVPN PIM-SM. 5.1. RP-PE mLSP RP-PE mLSP is a mLSP whose header-end is at the RP-PE, and multiple tail-ends at different Receiver-PEs. RP-PE mLSP is the equivalence of RPT (RP tree or shared tree) of IP PIM in MPLS network. RP-PE mLSP will use the default mLSP in the method specified in this document. PIM (*,G,RP) join message received at Receiver-PE MUST be sent to the default mLSP and finally reach the RP-PE. Then, the Source-PE and RP-PE can create the PIM state for (*,G). The (*, G) state at RP-PE MUST have the MI-PMSI(MVPN_ID) as its OIF, and the (*, G) state at Receiver-PE MUST have the MI-PMSI(MVPN_ID) as its IIF. 5.2. Source-PE mLSP Source-PE mLSP is a mLSP whose header-end is at a Source-PE. Depending on the location of tail-end, we have Source-PE to RP-PE mLSP, and Source-PE to Receiver-PE mLSP. Source-PE to RP-PE mLSP is the tree whose header-end is at the source-PE, and the tail-ends at RP-PE. It is constructed after the PIM register process is finished but before the PIM SPT switching or data mLSP switching. Source-PE to receiver-PE mLSP is the tree whose header-end is at the source-PE, and the tail-ends at receiver-PEs. It is built after SPT switching or data mLSP switching. By the method specified in this document, Source-PE to RP-PE mLSP also use the default mLSP like RP-PE mLSP. source-PE to receiver-PE mLSP will use the data mLSP. When the Source-PE and RP-PE are same (scenario 1 in section 6.3.1), there is no Source-PE to RP-PE mLSP. 5.3. PIM register process PIM register process is between multicast source and RP. Depending on the PR location, we can have different scenarios. 5.3.1. Scenario 1: The multicast source and RP are behind the same PE For this scenario, both RP and the multicast source are behind the same PE for the same MVPN. In another words, the unicast path from the multicast source to the multicast RP for a particular MVPN does Han & Li Expires January 31, 2013 [Page 18] Internet-Draft mVPN support by mRSVP-TE July 2012 not need to go through one PE to another PE and cross the MPLS network. So, the RP-PE is also the Source-PE. The PIM register process does not cross different PEs in the core MPLS network. Both RP-PE and source-PE are not aware of the PIM register process. There is no particular design consideration for MPLS tunnels. Before PIM register process, the PIM (*,G) join message from different Receiver-PE MUST be forwarded to the RP-PE. As a result, the PIM (*,G) state MUST be created on both RP-PE and Receiver-PE. The state (*,G) at RP-PE has the MI-PMSI(MVPN_ID) as its OIF, and the state (*,G) at Receiver-PE has the MI-PMSI(MVPN_ID) as its IIF. After the PIM register process is finished, PIM state on RP-PE will be changed to (S,G) which inherits all OIF from its parent (*,G). There is no change for PIM state for (*,G) at Receiver-PE. The multicast traffic will be flooded to all Receiver-PE through the RP- mLSP, or default mLSP. the Receiver-PE SHOULD drop the traffic if it does not have the (*,G) state created before. 5.3.2. Scenario 2: The multicast source and RP are behind the different PE For this scenario, RP and the multicast source are behind the different PEs for the same MVPN. The unicast path from the multicast source to the multicast RP MUST go through source-PE to RP-PE and cross the MPLS network. After the PIM(*,G) join is forwarded to the RP-PE through the default mLSP from different Receiver-PE, Only the RP-PE and receiver-PE have the state (*,G) created. The state at RP-PE has the default mLSP as its OIF, and the interface connecting to a CE as the IIF, which CE is the nexthop to reach RP from the RP-PE. The state at receiver-PE has the default mLSP as IIF. At Source-PE, there is no forwarding state. Multicast source S MUST start the register process by sending data packet to RP. The PIM register message is IP unicast message (encapsulated multicast data) which destination is to RP from source S, it SHOULD go through a unicast MPLS tunnel from Source-PE to RP-PE. The creation of unicast MPLS tunnel is out of scope of this document. When RP-PE receives register message which is encapsulated in MPLS format, following things SHOULD happen: o RP-PE MUST de-capsulate the MPLS packet and forward the PIM register message to RP behind the RP-PE. RP then MUST forward the multicast packet (de-capsulated from PIM register message) to all Receiver-PE. This is done through the (*,G) state created before Han & Li Expires January 31, 2013 [Page 19] Internet-Draft mVPN support by mRSVP-TE July 2012 PIM register process. The traffic from RP will be forwarded back to RP-PE from the interface connecting to CE, and then RP-PE will forward the traffic to RP-mLSP, or the default mLSP. o All PEs attached to the default mLSP SHOULD receive the traffic. Source-PE and receiver-PE which did not join the group G SHOULD drop the traffic. o RP initialize a PIM (S,G) join to source S. S address is retrieved from the received data traffic from PIM register message. The (S,G) join message MUST be forwarded from RP to RP-PE, and then RP-PE MUST forward the join through the default mLSP to the Source-PE. The address of Source-PE is determined by the BGP next hop of the VPN address S. o The Source-PE and RP-PE MUST create a PIM (S,G) state as a result of PIM (S,G) join message processing, PIM (S,G) state at Source-PE MUST have the MI-PMSI(MVPN_ID) as OIF, PIM (S,G) state at RP-PE MUST inherit all OIF from the previous (*,G) state, and adds the MI-PMSI(MVPN_ID) as IIF. Note, the OIF for old (*,G) state has had the MI-PMSI(MVPN_ID) as OIF, this OIF MUST NOT be inherited for (S,G). o At Source-PE, the multicast traffic received from a multicast source behind Source-PE, MUST be forwarded through the source-PE to RP-PE mLSP represented by the OIF of MI-PMSI(MVPN_ID). The "source-PE to RP-PE mLSP" is the default mLSP. Meanwhile, multicast source S still embeds the traffic as the PIM register message and send it to RP through the unicast MPLS tunnel. o After the RP-PE receives the traffic from the source-PE to RP-PE mLSP (default mLSP) during the PIM register process, following events SHOULD happen 1. RP-PE SHOULD forward the traffic to RP. 2. After RP receives the native multicast traffic from the interface which was used to forward the PIM (S,G) join message to multicast source S, RP SHOULD stop de-capsulating the PIM register message. All received PIM register message will be discarded. 3. RP Sends a PIM register-stop (unicast) message to multicast source S. o After the multicast source receives register-stop message, it MUST stop to send PIM register message to RP, and all multicast data is natively forwarded by the (S,G) state to flood to the source-PE to Han & Li Expires January 31, 2013 [Page 20] Internet-Draft mVPN support by mRSVP-TE July 2012 RP-PE mLSP, or the default mLSP. 5.4. SPT switching After Receiver-PE receive multicast traffic from the default mLSP. Each Receiver-PE SHOULD forward the traffic to some attached CEs by the PIM state (*,G) created when the PIM (*,G) join was received from the attached CEs. After the traffic reaches the Last Hop Router (LHR), LHR can initialize the Shortest Path Tree (SPT) switching by checking the traffic rate. If the rate exceeds the pre-configured threshold, LHR SHOULD send the PIM (S,G) join to the multicast source. With the above solution for SPT switching, the Receiver-PE MUST still forward the PIM (S,G) join to the default mLSP. And the PIM (S,G) state SHOULD be created at the Receiver-PE and the state SHOULD inherit all Olist from the previously created (*,G) state. As a result of this SPT switching solution, only Receiver-PE has the PIM state change. The traffic will be forwarded by (S,G) instead of (*,G). Source-PE has no change to the PIM state (S,G). There is no MPLS LSP changes for the traffic forwarding path in MPLS core network. The traffic is still forwarded to the default mLSP at source-PE. 5.5. RPT prune Using the above method, the SPT switching does not lead to the traffic receiving interface change on the receiver PE, so, there is no RPT prune message triggered. 5.6. Data mLSP switching As described in above section, the SPT switching does not change the MPLS path for multicast forwarding. Some receiver-PEs still receive the traffic even there is no intention to join the specific group G. We will use data mLSP switching to serve the similar purpose for MPLS network as SPT switching in IP network. By data mLSP switching, the multicast forwarding path in MPLS network can be changed from a shared tree (default mLSP) to a o Shortest MPLS path from receiver to source, if the explicit path is not configured for the source S, and the QoS is not required. o User defined path, if the explicit path is configured for the source S, or the QoS reservation is required. Han & Li Expires January 31, 2013 [Page 21] Internet-Draft mVPN support by mRSVP-TE July 2012 If the traffic rate for the stream (S,G) exceeds the threshold, the Source-PE MUST flood the mLSP join TLV to all PEs. Each PE, if it has already created the PIM state for group G, MUST initialize a mRSVP-TE P2MP path message to the Source-PE. The Source-PE is found by the BGP next hop address for S. The Receiver-PE MUST update its IIF for state (S,G) from MI- PMSI(MVPN_ID) to S-PMSI(MVPN_ID, mLSP_ID). After the data mLSP is constructed at Source-PE, the PIM state (S,G) MUST add S-PMSI(MVPN_ID, mLSP_ID) to its Olist and prune the old OIF MI-PMSI(MVPN_ID). Note, at this moment, the traffic is still sent to the default mLSP from the Source-PE. As a result of OIF updating for (S,G) at Source-PE, the traffic is switched from the default mLSP to the data mLSP for (S,G). 5.7. PIM state at Receiver-PE PIM state at Receiver-PE may be different due to the rate threshold configuration of SPT switching and data mLSP switching. o If the rate threshold for mLSP data switching is less than the rate threshold for SPT switching, the data mLSP will be switched earlier than the SPT switching in IP. The multicast distribution tree in MPLS could be switched to a shortest path tree but the tree in IP network is still a shared tree. As a result, the traffic is carried by a P2MP tunnel in MPLS network. But at the receiver-PE, the de-capsulated MPLS traffic MUST be still forwarded by a PIM state (*,G) which is corresponding to a shared tree. o If the rate threshold for mLSP data switching is greater than the rate threshold for SPT switching, the data mLSP will be switched later than the SPT switching in IP. The tree in IP network is switched to a shortest path tree but the multicast distribution tree in MPLS is still a default mLSP. So, the traffic is carried by a MP2MP tunnel in MPLS network, and at the receiver-PE, the de- capsulated MPLS traffic will be forwarded by a PIM state (S,G) which is corresponding to a shortest path tree. 6. Aggregation With the method described above, there is one data mLSP per multicast stream (S,G). This may not be feasible if the stream number is big, or, there is limit for MPLS label for multicast in a network. Under those scenarios, traffic aggregation in MPLS network is desired. Han & Li Expires January 31, 2013 [Page 22] Internet-Draft mVPN support by mRSVP-TE July 2012 Aggregation can save the MPLS tunnel, but always with trade off. When multiple MPLS multicast trees are not completely overlapped, to aggregate them will lead to some sub-LSP waste the bandwidth. For example, if two trees have different set of receiver-PEs, some traffic has to be dropped on a PE if it does not have the (S,G) state created before. 6.1. Aggregation by Default mLSP The aggregation by the default mLSP is straightforward. If we do not set the data mLSP for any (S,G), the traffic of (S,G) will be kept in the default mLSP forever. The aggregation for selective (S,G) can be done at CLI level by ACL (Access List) or any other kind of tool to make the streams which satisfy some conditions to stay in the default mLSP. 6.2. Aggregation by Data mLSP The aggregation by the data mLSP can be achieved by the following ways o Source-PE assigns the same mLSP ID for the streams expected to be aggregated, and keeps the mapping for the mLSP ID to different (S,G). o Source-PE floods the mLSP join TLV for each (S,G) with the same mLSP ID to default mLSP. o Receiver-PE receives the mLSP join TLV and checks if the data mLSP corresponding to the mLSP ID is created already. If yes, receiver-PE SHOULD only update its mapping for the mLSP ID to an new (S,G) but SHOULD NOT initialize the new path message to source-PE. o Source-PE SHOULD switch multiple streams which were assigned with the same mLSP ID to the same data mLSP after it is created. The aggregation by data mLSP essentially aggregates multicast streams which share the same source-PE even they have different multicast source. 7. Non-VPN multicast support The method specified in this document can also apply to the non-VPN multicast support. For the non-VPN multicast case, we will take the same approach as VPN Han & Li Expires January 31, 2013 [Page 23] Internet-Draft mVPN support by mRSVP-TE July 2012 multicast case. Basically, we will treat the public table with a special VPN ID = 0 (see section 9 for VPN ID). By such treatment, the multicast in public domain becomes the multicast in a special table, and it can be supported as normal mVPN. 8. Message Format and Constants Two types of new message format have to be introduced to support mVPN by mRSVP-TE. One is the SESSION-object message format for mRSVP-TE. Another is the mLSP join TLV message format. The SESSION-object defined in mRSVP-TE is a opaque value (Fig. 7 in [I-D.lzj-mpls-receiver-driven-multicast-rsvp-te]). So, we can define the details of the opaque value based on the mVPN requirement. For the PIM-SSM support option 1 (Fig. 1, Fig. 2), we can embed the "c-source" and "c-group" directly into the SESSION-object. But for PIM-SM support, and PIM-SSM support option 2/3, we can embed the "mLSP ID" into the SESSION-object (Fig. 3). "mLSP ID" can map to different "c-source" and "c-group" at PEs. The mLSP join TLV message format is similar to the MDT defined in section 7.2 and 7.3 [RFC6037]. Both use UDP to encapsulate the join TLV message, and the IP destination address are also same, it is ALL- PIM-ROUTERS (224.0.0.13) for IPv4 and ALL-PIM-ROUTERS (ff02::d) for IPv6. But there are some difference for MDT and mLSP. The 1st difference is that we have to use a value (mLSP ID) other than "P Group" for MPLS case since we do not have "P Group" for MPLS core network. The 2nd difference is that we have to use different port number instead of 3232 assigned to mGRE based MDT. The exact UDP port number is TBD. 8.1. Path session object for PIM-SSM option 1 (IPv4) The MVPN mRSVP path message for PIM-SSM option 1 for IPv4 has the following format. Class = SESSION, mRSVP_TE_MVPN_IPv4 C-Type = TBD Han & Li Expires January 31, 2013 [Page 24] Internet-Draft mVPN support by mRSVP-TE July 2012 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + VPN ID + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C-source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C-group | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fig. 1 mVPN mRSVP-TE path session object for PIM-SSM option 1 (IPv4) VPN ID: This is the ID for MVPN, it MUST be same for the same VPN cross a MPLS network. VRF RD (Route Distinguisher) or any other unique value in a MPLS network can be used for VPN ID. 0 is reserved for the global MPLS multicast or non MVPN case C-source (32 bits): the IPv4 address of the traffic source in the VPN. C-group (32 bits): the IPv4 address of the multicast traffic destination address in the VPN. 8.2. Path session object for PIM-SSM option 1 (IPv6) The MVPN mRSVP path message for PIM-SSM option 1 for IPv6 has the following format. Class = SESSION, mRSVP_TE_MVPN_IPv6 C-Type = TBD Han & Li Expires January 31, 2013 [Page 25] Internet-Draft mVPN support by mRSVP-TE July 2012 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + VPN ID + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | C-source | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | C-group | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fig. 2 mVPN mRSVP-TE path session object for PIM-SSM option 1 (IPv6) VPN ID: Same definition as in Fig. 1 C-source (128 bits): the IPv6 address of the traffic source in the VPN. C-group (128 bits): the IPv6 address of the multicast traffic destination address in the VPN. 8.3. Path session object for other PIM modes (IPv4) The MVPN mRSVP-TE path message for PIM-SM, PIM-SSM (Option 2 and 3) for IPv4 has the following format. Class = SESSION, mRSVP_TE_MVPN_IPv4 C-Type = TBD Han & Li Expires January 31, 2013 [Page 26] Internet-Draft mVPN support by mRSVP-TE July 2012 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + VPN ID + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mLSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fig. 3 mVPN mRSVP-TE path session object for PIM-SM, PIM-SSM (Option 2 and 3) VPN ID: Same definition as in Fig. 1 mLSP ID: the mLSP ID corresponding to a tunnel, 0 is reserved for default mLSP. For all non-zero mLSP ID, it SHOULD come from the mLSP join TLV message, see Fig. 4 and Fig. 5 8.4. Path session object for other PIM modes (IPv6) The MVPN mRSVP-TE path message for PIM-SM, PIM-SSM (Option 2 and 3) for IPv6 has the following format. Class = SESSION, mRSVP_TE_MVPN_IPv6 C-Type = TBD The session object format is the same as for IPv4 shown in Fig 3. 8.5. mLSP TLV Message format for IPv4 The mLSP Join TLV for IPv4 streams 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C-source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C-group | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mLSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Han & Li Expires January 31, 2013 [Page 27] Internet-Draft mVPN support by mRSVP-TE July 2012 Fig. 4 mLSP join TLV message format for IPv4 Type (8 bits): MUST be set to 1. Length (16 bits): MUST be set to 16. Reserved (8 bits): for future use. C-source (32 bits): the IPv4 address of the traffic source in the VPN. C-group (32 bits): the IPv4 address of the multicast traffic destination address in the VPN. mLSP ID (32 bits): the mLSP ID corresponding to the data mLSP carrying the flow (C-source, C-group). 8.6. mLSP TLV Message format for IPv6 The mLSP Join TLV for IPv6 streams 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | C-source | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | C-group | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mLSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fig. 5 mLSP join TLV message format for IPv6 Han & Li Expires January 31, 2013 [Page 28] Internet-Draft mVPN support by mRSVP-TE July 2012 Type (8 bits): MUST be set to 4. Length (16 bits): MUST be set to 40. Reserved (8 bits): for future use. C-source (128 bits): the IPv6 address of the traffic source in the VPN. C-group (128 bits): the IPv6 address of the multicast traffic destination address in the VPN. mLSP ID (32 bits): the mLSP ID corresponding to the data mLSP carrying the flow (C-source, C-group). 9. Acknowledgements We would like to thank Katherine Zhao and Quintin Zhao for comments on early drafts of this work. 10. IANA Considerations There is no change with regards to IANA 11. Security Considerations There is no change with regards to the security for PIM protocol and mRSVP-TE after the MVPN is provided 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Han & Li Expires January 31, 2013 [Page 29] Internet-Draft mVPN support by mRSVP-TE July 2012 Switched Paths (LSPs)", RFC 4875, May 2007. [RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point-to- Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, November 2011. [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP VPNs", RFC 6513, February 2012. [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, "Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM)", RFC 5059, January 2008. [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, February 2012. [I-D.lzj-mpls-receiver-driven-multicast-rsvp-te] Li, R., Zhao, Q., and C. Jacquenet, "Receiver-Driven Multicast Traffic-Engineered Label-Switched Paths", draft-lzj-mpls-receiver-driven-multicast-rsvp-te-01 (work in progress), July 2012. 12.2. Informative References [RFC6037] Rosen, E., Cai, Y., and IJ. Wijnands, "Cisco Systems' Solution for Multicast in BGP/MPLS IP VPNs", RFC 6037, October 2010. Authors' Addresses Lin Han (editor) Huawei Technologies 2330 Central Expressway Santa Clara, CA 95050 USA Phone: +10 408 330 4613 Email: lin.han@huawei.com Han & Li Expires January 31, 2013 [Page 30] Internet-Draft mVPN support by mRSVP-TE July 2012 Renwei Li Huawei Technologies 2330 Central Expressway Santa Clara, CA 95050 USA Phone: Email: renwei.li@huawei.com Han & Li Expires January 31, 2013 [Page 31]