Network Working Group Eric C. Rosen (Editor) Internet Draft Arjen Boers Intended Status: Proposed Standard Yiqun Cai Expires: June 31, 2009 IJsbrand Wijnands Cisco Systems, Inc. December 31, 2008 MVPN Profiles Using PIM Control Plane draft-rosen-l3vpn-mvpn-profiles-02.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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. Copyright and License Notice Copyright (c) 2008 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. Rosen, et al. [Page 1] Internet Draft draft-rosen-l3vpn-mvpn-profiles-02.txt December 2008 Abstract The MVPN (Multicast Virtual Private Network) architecture is divided into a number of functional "layers". At each layer, multiple options are allowed. It is necessary to allow multiple options at each layer because "one size doesn't fit all." However, it is not expected that any particular implementation will support all the possible combinations of options. To ensure multi-vendor interoperability, it is useful to specify "profiles", where each profile is a particular combination of options. The number of specified profiles will be much less than the total number of possible combination, and a given implementation can be characterized by saying which profiles it supports. This document describes two profiles that use a PIM control plane. Rosen, et al. [Page 2] Internet Draft draft-rosen-l3vpn-mvpn-profiles-02.txt December 2008 Table of Contents 1 Specification of requirements ......................... 4 2 Introduction .......................................... 4 3 The PIM+GRE Profile ................................... 5 3.1 Auto-discovery ........................................ 5 3.2 MI-PMSI Instantiation ................................. 5 3.2.1 Source Specific Multicast Mode ........................ 6 3.2.2 Any System Multicast Mode, Unidirectional ............. 6 3.2.3 Bidir ................................................. 6 3.3 Distribution of C-Multicast Routing Information ....... 7 3.4 Encapsulation ......................................... 7 3.5 S-PMSIs ............................................... 7 3.6 Inter-AS support ...................................... 7 3.7 Upstream Multicast Hop Determination .................. 8 4 The PIM+MPLS/MP2MP Profile: PIM over MS-PMSI .......... 8 4.1 Auto-discovery ........................................ 8 4.2 Joining an MP2MP LSP .................................. 9 4.2.1 Joining to Receive BSR Messages ....................... 9 4.2.2 Joining to Send PIM C-Join/Prune Messages ............. 10 4.2.3 Joining to Send Data Without Having Sent a C-J/P ...... 10 4.2.4 Pruning Oneself from a MP2MP LSP ...................... 11 4.3 Sending and Receiving C-Multicast Data ................ 11 4.4 Encapsulation ......................................... 11 4.5 Additional S-PMSIs .................................... 12 4.6 Inter-AS Support ...................................... 12 4.7 Upstream Multicast Hop Determination .................. 13 4.8 Extensions of this Profile ............................ 13 5 IANA Considerations ................................... 13 6 Security Considerations ............................... 13 7 Authors' Addresses .................................... 14 8 Normative References .................................. 14 9 Informative References ................................ 15 Rosen, et al. [Page 3] Internet Draft draft-rosen-l3vpn-mvpn-profiles-02.txt December 2008 1. Specification of requirements 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 [RFC2119]. 2. Introduction The MVPN (Multicast Virtual Private Network) architecture, as specified in [MVPN] and [MVPN-MSPMSI], allows Service Providers (SPs) to offer IP multicast service over the sort of Virtual Private Networks (VPNs) that are specified in [VPN]. The MVPN architecture contains a number of functional layers, and at each layer, multiple options are allowed. For example, one of the "functional layers" is the control protocol which a Provider Edge (PE) router uses to distribute Customer- multicast (C-multicast) routing to other PE routers. Two options are allowed for this: (a) PIM and (b) BGP. Several different variations of PIM are accommodated by the architecture as well. Another functional layer is the encapsulation which a PE router uses to transmit a customer's multicast data to other PE routers. Both MPLS and IP-based encapsulations are allowed by the architecture. When MPLS encapsulation is used, transmission of user data is done over Multipoint LSPs. There are however three very different kinds of Multipoint LSPs that can be used. The LSPs can be MP2MP (Multipoint-to-multipoint) LSPs set up by mLDP [MLDP], P2MP (Point- to-Multipoint) LSPs set up by mLDP, or P2MP LSPs set up by RSVP-TE [MP-RSVP-TE]. Although the architecture allows any option at one layer to be used with any option at another, it is not expected that any given implementation will actually support the full set of options at each layer, and in fact not all arbitrary combinations of options are sensible. It is useful therefore to describe a set of MVPN "Profiles", where each profile contains a single mandatory option at each layer. Implementations can then be characterized by the set of profiles they support. The intention is that each profile be fully conformant to the [MVPN] standard. The profiles are described in the terminology of [MVPN], which is presupposed by this document. Deployments of MVPN based on the "PIM+GRE" profile (most precisely, Rosen, et al. [Page 4] Internet Draft draft-rosen-l3vpn-mvpn-profiles-02.txt December 2008 on a pre-standards version of that profile described in [ORIGINAL- MVPN]) have existed since the turn of the century. The use of PIM for distributing C-multicast routes has thus been proven in deployment. Issues have been raised about whether this will be adequate in the future if MVPN deployments greatly increase in scale. However, the alternative of using BGP for distributing C-multicast routes has not been proven in deployment, and the authors believe that that alternative has a number of issues having to do with functionality, scaling, and dynamic behavior that are not yet fully understood. Until those are better understood, it does not seem prudent to migrate quickly from PIM to BGP for distributing C- multicast routes. The authors also believe that the ability to deploy MPLS encapsulation for multicast VPN traffic should not be gated by the need to deploy BGP as the C-multicast routing control plane. Therefore we also specify a "PIM+MPLS" profile. 3. The PIM+GRE Profile The PIM+GRE Profile corresponds closely to the "pre-standards" MVPN deployments from Cisco Systems [ORIGINAL-MVPN], that have existed for many years. The specification [ORIGINAL-MVPN] contains the precise details of how the pre-standards version deviates slightly from the later standard. 3.1. Auto-discovery Auto-discovery is done by means of BGP, using the "Intra-AS I-PMSI A- D routes" described in section 4 of [MVPN] and sections 4.1 and 8.1 of [MVPN-BGP]. Each PE attached to a particular MPVN is configured with a PIM group address for that MVPN. The group address with which a given PE is configured is carried in the PMSI Tunnel Attribute (see [MVPN] section 4 and [MVPN-BGP] section 5) of the Intra-AS I-PMSI A-D route originated by that PE. This PIM group address is used to create the P-tunnels that instantiate the MVPN's MI-PMSI (see section 2.2). 3.2. MI-PMSI Instantiation In the PIM+GRE profile, the PEs attached to a given MVPN are connected via an MI-PMSI (see [MVPN] sections 3.3.1 and 3.3.2). The P-tunnels that instantiate the MI-PMSIs are multicast distribution trees constructed with PIM. Each MVPN VRF is configured with a PIM Group P-address. The Intra-AS A-D route sent by each PE specifies this group address. The P-tunnels may be created using the Source- Specific Mode (SSM) service model, or the Any Source Mode (ASM) Rosen, et al. [Page 5] Internet Draft draft-rosen-l3vpn-mvpn-profiles-02.txt December 2008 service model. In the latter case, P-tunnels may be a mixture of source-specific trees with unidirectional shared trees rooted at Rendezvous Points (RPs) (this mixture is the normal result of applying PIM "sparse mode" procedures). Alternatively, each MI-PMSI may be instantiated by a single bidirectional tree (created by BIDIR- PIM). The Intra-AS I-PMSI A-D route sent by each PE specifies a PIM group address. Other PEs use PIM to join the specified group, thereby creating the P-tunnels. The P-tunnels are thus created automatically as a result of the auto-discovery process. This profile does NOT require support for the capability to have a single P-tunnel carry traffic from multiple VPNs. Note that if the group address G used for the P-tunnels is an ASM group, the BGP-based auto-discovery process is not strictly needed; each PE MAY join the requisite set of P tunnels for a given MVPN just by joining the (*,G) tree for the P-group address G that has been configured for that VPN. However, for consistency, the auto- discovery process SHOULD always take place. 3.2.1. Source Specific Multicast Mode Consider the set of PEs that support a given MVPN. Each pair is associated with a source specific mode PIM group address. If the set of PEs supporting the given MVPN is PE1, ..., PEn, and the corresponding set of group addresses is G1, ..., Gn, then PEk joins each source tree for which 1 <= i <= n and i != k. That is, the MI-PMSI is instantiated as a "full mesh" (i.e., containing all the PEs attached to the MVPN) of source trees. The normal PIM procedures specified in [PIM-SM] are used. 3.2.2. Any System Multicast Mode, Unidirectional Each MVPN is associated with a non-SSM PIM group address. Each PE attached to the MVPN joins the group, using the PIM sparse mode procedures. If there are n PEs, the MI-PMSI is thus instantiated as a shared tree plus a set of up to n source trees. The normal PIM procedures specified in [PIM-SM] are used. 3.2.3. Bidir Each MVPN is associated with a bidirectional mode PIM group address. Each PE attached to the MVPN joins the group, using the BIDIR-PIM procedures. If there are n PEs, the MI-PMSI is thus instantiated as a shared tree plus a set of up to n source trees. The procedures for Rosen, et al. [Page 6] Internet Draft draft-rosen-l3vpn-mvpn-profiles-02.txt December 2008 setting up a BIDIR-PIM tree are specified in [PIM-BIDIR]. 3.3. Distribution of C-Multicast Routing Information As already specified, an MI-PMSI is automatically created, containing all the PEs belonging to a VPN. C-multicast routing information is distributed by running PIM over the MI-PMSI, using standard PIM LAN procedures. See sections 3.4.1.1, 5.1, and 5.2 of [MVPN]. 3.4. Encapsulation All C-multicast data messages, and all C-PIM messages (i.e., PIM messages carrying C-multicast routing information) are encapsulated in GRE [GRE], precisely as specified in section 11.1.1 of the [MVPN]. 3.5. S-PMSIs This profile supports non-aggregated S-PMSIs, where each S-PMSI is instantiated as a PIM source tree in SSM mode. The assignment of a particular C-multicast data stream to a particular S-PMSI is done via the protocol specified in section 7.2.1 of [MVPN]. 3.6. Inter-AS support Inter-AS support is provided via the non-segmented inter-as tunnels described in section 8.1 of [MVPN]. Intra-AS A-D routes must (despite their name) be distributed across AS boundaries. To set up the inter-AS P-tunnels instantiating a PMSI, it is necessary for a PE in one AS to send PIM control messages which identify PEs in other ASes. In order to construct the multicast distribution trees, P routers processing these messages need to determine the (IGP) route to the identified PE router. However, in inter-AS VPNs constructed according to option b of section 10 of RFC 4364, a given AS does not necessarily have routes to PEs in the other ASes. Therefore, the PIM messages contain the "PIM MVPN Join Attribute". This allows the multicast distribution tree to be properly constructed even if routes to PEs in other ASes do not exist in the given AS's IGP, and even if the routes to those PEs do not exist in BGP. The use of an PIM MVPN Join Attribute in the PIM messages allows the inter-AS trees to be built. The basic format of a PIM Join Attribute is specified in [PIM-ATTRIB]. The details of Rosen, et al. [Page 7] Internet Draft draft-rosen-l3vpn-mvpn-profiles-02.txt December 2008 the PIM MVPN Join Attribute are specified in [MVPN]. 3.7. Upstream Multicast Hop Determination According to section 5 of [MVPN], where the selected "Upstream Multicast Hop" (UMH) route is the installed UMH route. The procedures of section 5 for single forwarder selection are not applied. Multicast data packets arriving from the "wrong" upstream PE are not discarded. However, since PIM LAN procedures are run over the MI-PMSI, the standard PIM "Assert" procedures will result in a single choice of forwarder. Packet duplication is possible during the Assert convergence period. Although a given source will end up having a single PE as forwarder. Load balancing is possible within that constraint. That is, if S1 and S2 are two different sources, and each source has both PE1 and PE2 as an eligible UMH, and if PE3 needs to join the C-trees (S1, G1) and (S2, G2), a form of load balancing can be providing by having PE3 join (S1, G1) via PE1 but having it join (S2, G2) via PE2. 4. The PIM+MPLS/MP2MP Profile: PIM over MS-PMSI In this profile, as in the PIM+GRE profile, the PEs use PIM to convey multicast routing information to each other. However, PIM is not used to instantiate the P-tunnels. Rather, mLDP is used to create Multipoint-to-Multipoint (MP2MP, or bidirectional) LSPs to serve as the P-tunnels. Furthermore, an MI-PMSI is not used at all. PIM is run over one or more MS-PMSIs (as specified in MVPN-MSPMSI), and P- tunnels are only created if they are actually needed for carrying multicast data. 4.1. Auto-discovery Each PE that attaches to a given MVPN MUST originate an Intra-AS I- PMSI A-D route that does NOT contain a PMSI Tunnel Attribute (PTA) or a PE Distinguisher Labels Attribute. (I.e., there is no MI-PMSI.) After the Intra-AS I-PMSI A-D route is originated, each such PE MUST originate an S-PMSI A-D route whose PTA specifies a MP2MP LSP rooted at the originating PE. The Tunnel Identifier for the MP2MP LSP consists of an MLDP MP2MP FEC element [MLDP], which itself consists of an IP address of the originating PE router, followed by an "opaque value" identifying the MP2MP LSP in the context of that PE router. This opaque value may be configured or autogenerated, and there is no need for different PEs attached to a given MVPN to use the same Rosen, et al. [Page 8] Internet Draft draft-rosen-l3vpn-mvpn-profiles-02.txt December 2008 opaque value. The IP address which appears in the tunnel identifier field of the PTA MUST be the same IP address that the PE uses for sending and receiving PIM control messages. The S-PMSI A-D route originated by PE1 specifies an MS-PMSI of which PE1 is the root. The S-PMSI A-D route MUST bind the LSP to the "double wildcard" (*,*). Use and interpretation of the double wildcard when the PTA specifies a MP2MP LSP is specified in section 4.1.4 [MVPN-MSPMSI]. Per [MVPN-MSPMSI], the specified MS-PMSI becomes the default PMSI that its root node uses to send a C-flow to the other PEs, as long as the C-flow is traveling along a unidirectional C-tree. For C-flows traveling along a bidirectional C-tree, the MS-PMSI is the default PMSI for that any PE uses to transmit to other PEs, as long as the root node is the selected upstream PE for the C-RPA. The MS-PMSI is associated with a particular MVPN by means of the RTs carried by the S-PMSI A-D route, exactly as specified in [MVPN] and [MVPN-BGP]. When PE1 is the root of an MS-PMSI, we will sometimes refer to the MS-PMSI as "PE1's MS-PMSI". (Of course, a given PE may be the root for more than one MS- PMSI, for the same or different MVPNs. Rules governing the association of an S-PMSI A-D route with a given MVPN are as specified in [MVPN] and [MVPN-BGP].) This profile does not require support for the use of non-zero values in the MPLS label field of the PTA, nor does this profile require the use of the PE Distinguisher Labels attribute. 4.2. Joining an MP2MP LSP When a PE receives one of the S-PMSI A-D routes mentioned in the previous section, it may or may not need to invoke MLDP signaling procedures to join the specified MP2MP LSP. In particular, a PE MUST NOT join the specified MP2MP LSP unless and until it has a need to do so. This is discussed in subsequent sub-sections. 4.2.1. Joining to Receive BSR Messages Each PE attached to an MVPN needs to know the RP or RPA that corresponds to each C-group address for which it may need to send or receive traffic. This information may be preconfigured, but more likely is known through some automated procedure such as BSR Rosen, et al. [Page 9] Internet Draft draft-rosen-l3vpn-mvpn-profiles-02.txt December 2008 (Bootstrap Routing Protocol for PIM [BSR]). If a PE, say PE1, receives a BSR message from a CE which belongs to a particular MVPN, it needs to transmit BSR messages to the other PEs attached to that MVPN. It does so by sending the BSR messages over the MS-PMSI for that MVPN of which it is the root. However, it MUST also originate another S-PMSI A-D route, with the same PTA, but whose C-source field specifies the address of the PE itself, and whose C- group field specifies the ALL-PIM-ROUTERS address (224.0.0.13). See section 5 of [MVPN]. When this S-PMSI A-D route is received by the other PEs attached to the MVPN, those other PEs MUST as soon as possible initiate the LDP signaling necessary to join the MP2MP LSP, so that they can receive the BSR messages from PE1. of the LSP. 4.2.2. Joining to Send PIM C-Join/Prune Messages If PE1 needs to direct a PIM C-Join/Prune message to PE2, PE1 MUST join the LSP advertised in PE2's S-PMSI A-D route. The PIM J/P messages MUST be sent over that LSP. Note that multicast data cannot be received over a given LSP unless a C-Join/Prune message has been sent over that LSP. (Except in the case of BSR messages discussed previously.) Therefore these procedures cause a PE to join a particular MP2MP LSP ONLY if the PE needs to receive data on it. Thus the number of LSPs that actually get created for a given MVPN is equal to the number of PEs that serve as ingress PEs for the multicast traffic of that MVPN. In an MVPN which has its multicast transmitters at a single site, only one LSP would be required. Any PIM Hellos that PE1 sends MUST be sent on the LSP advertised in PE1's own S-PMSI A-D route (i.e., on PE1's MS-PMSI). Thus the need to send Hellos does not trigger the joining of an LSP. 4.2.3. Joining to Send Data Without Having Sent a C-J/P If a particular PE is on a "sender only" branch of a C-bidir tree, then it may need to send C-data that is traveling on the C-bidir tree without having previously sent a corresponding C-Join. A given PE, PE1, still sends the data on PE2's LSP if and only if PE1 has selected PE2 as the upstream PE for the RPA of the C-bidir tree. PE1 MAY join that tree when it first has data to send on it, or it MAY join the tree when first recognizes that PE2 is the selected upstream PE for some RPA of which it knows. Rosen, et al. [Page 10] Internet Draft draft-rosen-l3vpn-mvpn-profiles-02.txt December 2008 4.2.4. Pruning Oneself from a MP2MP LSP A PE SHOULD prune itself from an MP2MP LSP whenever it no longer has a need to send or receive data on that LSP. 4.3. Sending and Receiving C-Multicast Data When a PE receives multicast data from a CE, it may need to forward that data to the other PEs. If the data is traveling on a unidirectional C-tree, the PE sends the data on its own MS-PMSI. When PE1 receives, from PE2's MS-PMSI, C-multicast data that is traveling on a unidirectional C-tree, PE MUST discard the data (without PIM processing) if PE2 is not the PE from which the data was expected (i.e., if PE2 is not the PE1's selected upstream PE for the C-root of the C-tree on which the data is traveling). If PE1 needs to send data traveling on a bidirectional C-tree, it does so using the procedures specified in [MVPN] section 12.2.3. The procedures specified therein also detail the conditions under which a PE must discard data from a bidirectional group when that data is received on the LSP. Since data arriving on the "wrong LSP" is always discarded, Assert processing will never occur. Since Assert processing does not occur, "single forwarder selection" need not be used (see sections 9 and 5.1 of [MVPN]). That is, PE1 can receive, e.g., (S,G) traffic from PE2 while PE3 receives (S,G) traffic from PE4. This enables the use of enhanced load balancing procedures. Also, the PIM+GRE profile, this profile can support the use of anycast source address (e.g., anycast- RP). The Join Suppression and Prune Override procedures still operate as they normally do on LANs. 4.4. Encapsulation The encapsulation specified in [MVPN] section 11.1.3 is used. (See also [MPLS-MCAST-ENCAPS]). Aggregation of multiple VPNs onto a single set of P-tunnels is not required by this profile. Rosen, et al. [Page 11] Internet Draft draft-rosen-l3vpn-mvpn-profiles-02.txt December 2008 4.5. Additional S-PMSIs This profile REQUIRES support for the use of additional, "non- default", S-PMSIs, where each S-PMSI is instantiated as an mLDP- created P2MP or MP2MP LSP. P2MP LSPs MAY be used for carrying C-multicast traffic that is traveling along unidirectional shared or source-specific C-trees. MP2MP LSPs MAY used for carrying C-multicast that is traveling along bidirectional C-trees. Multiple data streams MAY be aggregated on a single MP2MP LSP, but the profile does not require mandatory support for aggregation of data streams from different VPNs. The assignment of a particular C-flow or set of C-flows to a particular S-PMSI MAY be done via the protocol specified in section 7.2.1 of [MVPN]. The protocol will be suitably extended so that it can identify an mLDP-created MP2MP LSP, and can support the wild card selectors defined in [MVPN-MSPMSI]. The assignment MAY also be done by the use of S-PMSI A-D routes. Any given deployment MUST, by configuration, choose one of these methods. 4.6. Inter-AS Support Inter-AS support is provided via the non-segmented inter-as tunnels described in section 8.1 of [MVPN]. Intra-AS I-PMSI A-D routes must (despite their name) be distributed across AS boundaries. To set up the inter-AS P-tunnels instantiating a PMSI, it is necessary for a PE to send mLDP control messages which identify PEs in other ASes. In order to construct the multicast distribution trees, P routers processing these messages need to determine the (IGP) route to the identified PE router. However, In inter-AS VPNs constructed according to option b of section 10 of RFC 4364, a given AS does not necessarily have routes to PEs in the other ASes. Therefore, the mLDP messages will be extended along the lines of the "PIM MVPN Join Attribute" discussed in section 2.9. This allows the multicast distribution tree to be properly constructed even if routes to PEs in other ASes do not exist in the given AS's IGP, and even if the routes to those PEs do not exist in BGP. Rosen, et al. [Page 12] Internet Draft draft-rosen-l3vpn-mvpn-profiles-02.txt December 2008 4.7. Upstream Multicast Hop Determination Upstream multicast hop determination is exactly as specified in section 5 of [MVPN]. 4.8. Extensions of this Profile This profile may be extended in the future to add the following options: 1. Aggregation of traffic from multiple VPNs onto a single MS- PMSI. This requires support for MPLS upstream-assigned labels [MPLS-UPSTREAM-LABEL]. 2. Support for Segmented Inter-AS P-Tunnels, as described in section 8.2 of [MVPN]. This will require support for the "Inter-AS A-D Routes" described in section 8.2.1 of [MVPN]. 3. The use of RSVP-TE P2MP LSPs for instantiating S-PMSIs carrying traffic which is traveling on a unidirectional shared or source-specific C-tree. (With support of MPLS upstream- assigned labels, traffic traveling on bidirectional C-tree from the customer could also be carried over an RSVP-TE P2MP LSP.) 5. IANA Considerations This document does not require any actions of IANA. 6. Security Considerations [VPN] discusses in general the security considerations that pertain to when the RFC4364 type of VPN is deployed. [PIM-SM] discusses the security considerations that pertain to the use of PIM. [MLDP] discusses the security considerations that pertain to the use of LDP. When the PIM+GRE profile is used, the security considerations of [MPLS-in-GRE] and [VPN-GRE] also apply. The security considerations of [MVPN] and [MVPN-BGP] apply. Rosen, et al. [Page 13] Internet Draft draft-rosen-l3vpn-mvpn-profiles-02.txt December 2008 7. Authors' Addresses Arjen Boers Cisco Systems, Inc. 170 Tasman Drive San Jose, CA, 95134 E-mail: aboers@cisco.com Yiqun Cai Cisco Systems, Inc. 170 Tasman Drive San Jose, CA, 95134 E-mail: ycai@cisco.com Eric C. Rosen (Editor) Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA, 01719 E-mail: erosen@cisco.com IJsbrand Wijnands Cisco Systems, Inc. De kleetlaan 6a Diegem 1831 Belgium E-mail: ice@cisco.com 8. Normative References [GRE] RFC 2784, "Generic Routing Encapsulation", D. Farinacci, et. al., March 2000 [MLDP] "LDP Extensions for P2MP and MP2MP LSPs", I. Minei, K. Kompella, I. Wijnands, B. Thomas, draft-ietf-mpls-ldp-p2mp-05.txt, June 2008 [MPLS-MCAST-ENCAPS] "MPLS Multicast Encapsulations", T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, RFC 5332, August 2008 [MVPN] "Multicast in MPLS/BGP IP VPNs", E. Rosen, R. Aggarwal, et. Rosen, et al. [Page 14] Internet Draft draft-rosen-l3vpn-mvpn-profiles-02.txt December 2008 al., draft-ietf-l3vpn-2547bis-mcast-07.txt, June 2008 [MVPN-BGP] "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter, C. Kodeboniya, draft-ietf-l3vpn-2547bis-mcast-bgp-05.txt, June 2008 [MVPN-MSPMSI] "MVPN: Optimized use of PIM, Wild Card Selectors, Bidirectional Tunnels", draft-rosen-l3vpn-mvpn-mspmsi-02.txt, October 2008 [PIM-ATTRIB] "The PIM Join Attribute Format", A. Boers, IJ. Wijnands, E. Rosen, RFC 5384, November 2008 [PIM-BIDIR] RFC 5015, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", M. Handley, I. Kouvelas, T. Speakman, L. Vicisano, October 2007 [PIM-SM] RFC 4601 "Protocol Independent Multicast - Sparse Mode (PIM- SM)", Fenner, Handley, Holbrook, Kouvelas, August 2006 [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels.", Bradner, March 1997 [VPN] RFC 4364, "BGP/MPLS IP VPNs", Rosen, Rekhter, et. al., February 2006 9. Informative References [BSR], RFC 5059, "Bootstrap Router Mechanism for PIM", N. Bhaskar, A. Gall, J. Lingard, S. Venaas, January 2008. [MPLS-UPSTREAM-LABEL] "MPLS Upstream Label Assignment and Context- Specific Label Space", R. Aggarwal, Y. Rekhter, E. Rosen, RFC 5331, August 2008 [MP-RSVP-TE] RFC 4875, "Extensions to RSVP-TE P2MP TE LSPs" R. Aggarwal, Ed., D. Papadimitriou, Ed., S. Yasukawa, Ed.. May 2007 [MPLS-in-GRE] RFC 4023, "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", T. Worster, Y. Rekhter, E. Rosen, March 2005 [VPN-GRE] RFC 4797, "Use of PE-PE GRE or IP in BGP/MPLS IP VPNs", Y. Rekhter, R. Bonica, E. Rosen, January 2007 [ORIGINAL-MVPN] "Multicast in MPLS/BGP IP VPNs", E. Rosen, Y. Cai, IJ. Wijnands, draft-rosen-vpn-mcast-09.txt, May 2008 Rosen, et al. [Page 15] Internet Draft draft-rosen-l3vpn-mvpn-profiles-02.txt December 2008 Rosen, et al. [Page 16]