Network Working Group Eric C. Rosen (Editor) Internet Draft Arjen Boers Intended Status: Informational Yiqun Cai Expires: May 9, 2008 IJsbrand Wijnands Cisco Systems, Inc. November 9, 2007 MVPN Profiles Using PIM Control Plane draft-rosen-l3vpn-mvpn-profiles-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The MVPN (Multicast Virtual Private Network) architecture, as specified in [MVPN], 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 Rosen, et al. [Page 1] Internet Draft draft-rosen-l3vpn-mvpn-profiles-00.txt November 2007 of possible combination, and a given implementation can be characterized by saying which profiles it supports. This document describes three profiles that use a PIM control plane. Rosen, et al. [Page 2] Internet Draft draft-rosen-l3vpn-mvpn-profiles-00.txt November 2007 Table of Contents 1 Introduction .......................................... 4 2 The PIM+GRE Profile ................................... 5 2.1 Auto-discovery ........................................ 5 2.2 MI-PMSI Instantiation ................................. 6 2.2.1 Source Specific Mode .................................. 6 2.2.2 Sparse Mode ........................................... 7 2.2.3 Bidir ................................................. 7 2.3 Distribution of C-Multicast Routing Information ....... 7 2.3.1 Legacy Issues ......................................... 7 2.4 Encapsulation ......................................... 8 2.5 S-PMSIs ............................................... 8 2.6 Inter-AS support ...................................... 8 2.7 Upstream Multicast Hop Determination .................. 9 2.8 Specification of Pre-Standard Fields .................. 9 2.8.1 Connector Attribute ................................... 9 2.8.2 MDT-SAFI .............................................. 10 2.9 The PIM MVPN Join Attribute ........................... 10 2.9.1 Definition ............................................ 10 2.9.2 Usage ................................................. 11 3 The PIM+MPLS/MP2MP Profile ............................ 12 3.1 Distribution of C-multicast routing information ....... 12 3.2 Auto-discovery ........................................ 12 3.3 MI-PMSI Instantiation ................................. 12 3.4 Encapsulation ......................................... 14 3.5 S-PMSIs ............................................... 14 3.6 Inter-AS Support ...................................... 14 3.7 Upstream Multicast Hop Determination .................. 15 3.8 Extensions of this Profile ............................ 15 4 The PIM+RSVP-TE Profile ............................... 15 4.1 Distribution of C-multicast routing information ....... 15 4.2 Auto-discovery ........................................ 16 4.3 MI-PMSI instantiation ................................. 16 4.4 Encapsulation ......................................... 16 4.5 S-PMSIs ............................................... 16 4.6 Inter-AS Support ...................................... 16 4.7 Upstream Multicast Hop Determination .................. 17 4.8 Extensions of this Profile ............................ 17 5 IANA Considerations ................................... 17 6 Security Considerations ............................... 17 7 Authors' Addresses .................................... 18 8 Normative References .................................. 18 9 Informative References ................................ 19 Rosen, et al. [Page 3] Internet Draft draft-rosen-l3vpn-mvpn-profiles-00.txt November 2007 10 Full Copyright Statement .............................. 19 11 Intellectual Property ................................. 20 1. Introduction The MVPN (Multicast Virtual Private Network) architecture, as specified in [MVPN], 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 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. In one case, however, there are deployments of "pre- standards" versions of a profile. This document specifies just how the pre-standard version differs from the standard version, in enough detail to allow interoperability with the pre-standards version. Rosen, et al. [Page 4] Internet Draft draft-rosen-l3vpn-mvpn-profiles-00.txt November 2007 The profiles are described in the terminology of [MVPN], which is presupposed by this document. At the present time, all existing deployments of MVPN are based on the "PIM+GRE" profile (most precisely, on a pre-standards version of that profile). 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 there are a number of scaling issues and functional issues with that alternative 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 specify in this document the "PIM+GRE Profile", in its pre-standard (but deployed today) and in its standard forms, as well as two "PIM+MPLS" profiles. 2. The PIM+GRE Profile The PIM+GRE Profile corresponds closely to the "pre-standards" MVPN deployments from Cisco Systems, that have existed for many years. 2.1. Auto-discovery Auto-discovery is done by means of BGP, using the Intra-AS 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 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). There are deployments based on pre-standard implementations which use a type of route known as "MDT-SAFI" for this purpose, rather than using the intra-AS A-D routes. The intra-AS A-D routes which are specified in [MVPN] and [MVPN-BGP] are a generalization of the "pre- standard" MDT-SAFI. The generalization was necessary in order to allow the use of non-PIM P-tunnels (e.g., multipoint LSPs) in other profiles. Also, the intra-AS AD routes, unlike the MDT-SAFI, carry Rosen, et al. [Page 5] Internet Draft draft-rosen-l3vpn-mvpn-profiles-00.txt November 2007 Route Targets, and so may be distributed inter-AS in the same manner as unicast routes. (Inter-AS distribution of "intra-AS A-D routes" is necessary in some cases, see below.) The specification of the legacy MDT-SAFI route is given in section 2.8.2. Note that there are some legacy implementations that do not provide BGP-based auto-discovery. Those implementations are restricted to the use of PIM-SM as the sole means of instantiating P-tunnels (see next section), and those implementations cannot provide any support for inter-AS VPNs that are constructed according to option b of section 10 of [VPN]. 2.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). MI- PMSIs are instantiated as multicast distribution trees ("P-tunnels" in the language of [MVPN}) constructed by means of PIM. Source Specific Mode (SSM), Sparse Mode (SM), and Bidirectional Mode (BIDIR) are all supported. The Intra-AS A-D route (or, in legacy deployments, the MDT-SAFI routes) sent by each PE specify the MVPN 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 support aggregation of multiple VPNs onto a single set of P-tunnels. Note that if the group address G used for the P-tunnels is a sparse mode group or a bidirectional group, the BGP-based auto-discovery process is not strictly needed; each PE can join the requisite set of P tunnels just by joining the (*,G) tree. However, for consistency, the auto-discovery process always take place, no matter whether the PIM group address is a "sparse mode" address, a "source specific mode" address, or a "bidirectional mode" address. (But see the note about some legacy implementations at the end of the previous section.) 2.2.1. Source Specific 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 Rosen, et al. [Page 6] Internet Draft draft-rosen-l3vpn-mvpn-profiles-00.txt November 2007 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. There are pre-standard implementations that require the same SSM group address to be assigned to all the PEs. Interoperability with those implementations requires conformance to this restriction. 2.2.2. Sparse Mode Each MVPN is associated with a sparse mode 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. 2.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 setting up a BIDIR-PIM tree are specified in [PIM-BIDIR]. 2.3. Distribution of C-Multicast Routing Information 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]. 2.3.1. Legacy Issues Section 5.1.2 [MVPN} specifies: Every route which is eligible for UMH (Upstream Multicast Hop) selection MUST carry a VRF Route Import Extended Community [MVPN- BGP]. This attribute identifies the PE that originated the route. Pre-standards deployments of the PIM+GRE profile do not use the "VRF Route Import Extended Community" attribute, but instead use the "Connector" attribute to identify the PE that originated a route. Rosen, et al. [Page 7] Internet Draft draft-rosen-l3vpn-mvpn-profiles-00.txt November 2007 The specification of the connector attribute as used for this purpose is given in section 2.8.1. 2.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]. 2.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]. 2.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 AD routes must 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 the PIM MVPN Join Attribute are specified in section 2.9. Rosen, et al. [Page 8] Internet Draft draft-rosen-l3vpn-mvpn-profiles-00.txt November 2007 2.7. Upstream Multicast Hop Determination According to section 5 of [MVPN], where the selected UMH route is the installed UMH route. The procedures of section 5 for single forwarder selection are not applied. However, since PIM LAN procedures are run over the MI-PMSI, the standard PIM "Assert" will result in a single choice of forwarder. Packet duplication is possible during the Assert convergence period. Section 5.1.2 of [MVPN] requires each unicast route that is a potential UMH route to carry a VRF Route Import Extended Community. In pre-standards implementations, this attribute may be absent, in which case the backwards compatibility procedures of section 5.2.3 apply. Some pre-standards implementation may use a non-standard "connector attribute" instead of the VRF Route Import Extended Community. Because Assert processing is done, 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. As long as every PE uses the same UMH for a given source, Assert processing about that source does not get invoked. 2.8. Specification of Pre-Standard Fields 2.8.1. Connector Attribute The Connector Attribute is an optional transitive attribute. It is formatted as follows: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv4 Address of PE | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rosen, et al. [Page 9] Internet Draft draft-rosen-l3vpn-mvpn-profiles-00.txt November 2007 2.8.2. MDT-SAFI BGP messages in which AFI=1 and SAFI=66 are "MDT-SAFI" messages. The NLRI format is 8-byte-RD:IPv4-address followed by the MDT group address. i.e. The MP_REACH attribute for this SAFI will contain one or more tuples of the following form : +-------------------------------+ | | | RD:IPv4-address (12 octets) | | | +-------------------------------+ | Group Address (4 octets) | +-------------------------------+ The IPv4 address identifies the PE that originated this route, and the RD identifies a VRF in that PE. The group address must be a multicast group address, and is used to build the P-tunnels. All PEs attached to a given MVPN must specify the same group-address, even if the group is an SSM group. MDT-SAFI routes do not carry RTs, and the group address is used to associated a received MDT-SAFI route with a VRF. 2.9. The PIM MVPN Join Attribute 2.9.1. Definition In [PIM-ATTRIB], the notion of a "join attribute" is defined, and a format for included join attributes in PIM Join/Prune messages is specified. We now define a new join attribute, which we call the "MVPN Join Attribute". 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 | Proxy IP address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RD +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-....... The Type field of the MVPN Join Attribute is set to 1. Rosen, et al. [Page 10] Internet Draft draft-rosen-l3vpn-mvpn-profiles-00.txt November 2007 The F bit is set to 0. Two information fields are carried in the MVPN Join attribute: - Proxy: The IP address of the node towards which the PIM Join/Prune message is to be forwarded. This will either be an IPv4 or an IPv6 address, depending on whether the PIM Join/Prune message itself is IPv4 or IPv6. - RD: An eight-byte RD. This immediately follows the proxy IP address. The PIM message also carries the address of the upstream PE. In the case of an intra-AS MVPN, the proxy and the upstream PE are the same. In the case of an inter-AS MVPN, proxy will be the ASBR which is the exit point from the local AS on the path to the upstream PE. 2.9.2. Usage When a PE router creates a PIM Join/Prune message in order to set up an inter-AS I-PMSI, it does so as a result of having received a particular Intra-AS A-D route. It includes an MVPN Join attribute whose fields are set as follows: - If the upstream PE is in the same AS as the local PE, then the proxy field contains the address of the upstream PE. Otherwise, it contains the address of the BGP next hop on the route to the upstream PE. - The Rd field contains the RD from the NLRI of the Intra-AS A-D route. - The upstream PE field contains the address of the PE that originated the Intra-AS A-D route (obtained from the NLRI of that route). When a PIM router processes a PIM Join/Prune message with an MVPN Join Attribute, it first checks to see if the proxy field contains one of its own addresses. If not, the router uses the proxy IP address in order to determine the RPF interface and neighbor. The MVPN Join Attribute must be passed upstream, unchanged. If the proxy address is one of the router's own IP addresses, then the router looks in its BGP routing table for an Intra-AS A-D route Rosen, et al. [Page 11] Internet Draft draft-rosen-l3vpn-mvpn-profiles-00.txt November 2007 whose NLRI consists of the upstream PE address prepended with the RD from the Join attribute. If there is no match, the PIM message is discarded. If there is a match the IP address from the BGP next hop field of the matching route is used in order to determine the RPF interface and neighbor. When the PIM Join/Prune is forwarded upstream, the proxy field is replaced with the address of the BGP next hop, and the RD and upstream PE fields are left unchanged. 3. The PIM+MPLS/MP2MP Profile 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) P-tunnels. 3.1. Distribution of C-multicast routing information 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. 3.2. Auto-discovery Auto-discovery is done by means of BGP, using the Intra-AS A-D routes described in section 4 of [MVPN]. Each PE attached to a particular MPVN is configured with an mLDP FEC (Forwarding Equivalence Class) value. The mLDP FEC value with which a given PE is configured is carried in the PMSI Tunnel Attribute of the Intra-AS A-D route originated by that PE. This mLDP FEC value is used to create the P- tunnels that instantiate the MVPN's MI-PMSI (see below.) If the PEs are not all within the same AS, the "inter-AS A-D routes" must be distributed across AS boundaries. 3.3. MI-PMSI Instantiation The PEs attached to a given MVPN are connected via an MI-PMSI. MI- PMSIs are instantiated as MP2MP LSPs created by mLDP. The Intra-AS A-D route sent by each PE in the MVPN specifies a FEC value. If PE1 distributes the FEC value F, other PEs in the MVPN can then use mLDP to join a MP2MP LSP whose root is PE1 and whose FEC value is F. However, a given PE, say PE2, does not join the MP2MP LSP whose root is PE1 unless PE2 actually needs to send PIM control traffic PE1. Rosen, et al. [Page 12] Internet Draft draft-rosen-l3vpn-mvpn-profiles-00.txt November 2007 More precisely, at any given time, PE2 SHOULD be a member of the MP2MP LSP whose root is PE1 IF AND ONLY IF, at that time, PE2 is maintaining state for some (C-S, C-G) or (C-*, C-G) tree for which PE2 has selected PE1 as the upstream multicast hop (see section 5.1 of [MVPN]). The number of P-tunnels needed to instantiate the MI-PMSI for a given MVPN is thus equal to the number of PEs that serve as ingress PEs for some multicast transmitter of that MVPN. In an MVPN which has its multicast transmitters at a single site, only one P-tunnel would be required. The number of P-tunnels used to instantiate the MI-PMSI may also change from time to time, as needed. Since the LSPs instantiating the MI-PMSI are MP2MP, any PE can transmit to any of those LSPs. However, there are precise rules for which of the LSPs a given PE uses to transmit a given message. When a PE needs to send a PIM Hello on the MI-PMSI, it sends it on the LSP for which it is the root. When a PE needs to send a PIM Join/Prune on the MI-PMSI, it sends it on the LSP whose root is the PE to which the Join/Prune is directed. When a PE receives multicast data from a CE, it may need to forward that data to the MI-PMSI. If the data belongs to an SM or SSM group, the PE sends the data on the LSP for which it is the root. When a PE receives SM or SSM data on one of the LSPs, it discards the data (without PIM processing) if the root of the LSP on which the data was received is not the PE from which the data was expected. If a PE needs to send data belonging to a Bidirectional PIM group to the MI-PMSI, 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 MI-PMSI. Since data arriving from an unexpected PE 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 when compared to the PIM+GRE profile. Also, unlike 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. Rosen, et al. [Page 13] Internet Draft draft-rosen-l3vpn-mvpn-profiles-00.txt November 2007 3.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 supported. 3.5. S-PMSIs This profile supports S-PMSIs, where each S-PMSI is instantiated as a instantiated as an mLDP-created P2MP or MP2MP LSP. P2MP LSPs are used for carrying traffic from Sparse Mode or Source Specific Mode streams. MP2MP LSPs are used for carrying traffic from BIDIR trees. Multiple data streams can be aggregated on a single MP2MP LSP, but data streams from different VPNs cannot be so aggregated. 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]. The protocol will be suitably extended so that it can identify an mLDP-created MP2MP LSP. 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 AD routes must 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 14] Internet Draft draft-rosen-l3vpn-mvpn-profiles-00.txt November 2007 3.7. Upstream Multicast Hop Determination Upstream multicast hop determination in the PIM+MPLS/MP2MP profile is as specified in section 5 of [MVPN]. 3.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 S-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 Sparse Mode or Source Specific Mode traffic. (With support of MPLS upstream-assigned labels, BIDIR-PIM traffic from the customer could also be carried.) 4. The PIM+RSVP-TE Profile In this profile, the PEs use unicast PIM ([MVPN], section 3.4.1.3) to convey multicast routing information to each other. Data traffic is always sent over an S-PMSI which is instantiated as an RSVP-TE P2MP LSP. The description of this profile is more preliminary than the description of the previous two profiles. 4.1. Distribution of C-multicast routing information As in [MVPN], section 3.4.1.3. Rosen, et al. [Page 15] Internet Draft draft-rosen-l3vpn-mvpn-profiles-00.txt November 2007 4.2. Auto-discovery As in section 3.2, or alternative, 2.1. 4.3. MI-PMSI instantiation No MI-PMSI is used. 4.4. Encapsulation The encapsulation specified in [MVPN] section 11.1.3 is used. Aggregation of multiple VPNs onto a single set of P-tunnels is not supported. 4.5. S-PMSIs This profile supports S-PMSIs, where each S-PMSI is instantiated as an RSVP-TE P2MP LSP. All data is sent on an S-PMSI. Multiple customer data streams may travel on the same S-PMSI, but traffic from two different VPNs may not travel on the same S-PMSI. 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], suitably extended to allow the control messages to refer to an RSVP-TE P2MP LSP. 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 AD routes must be distributed across AS boundaries. To set up the inter-AS P-tunnels instantiating a PMSI, it is necessary for a PE to send RSVP-TE 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 RSVP-TE 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 Rosen, et al. [Page 16] Internet Draft draft-rosen-l3vpn-mvpn-profiles-00.txt November 2007 even if the routes to those PEs do not exist in BGP. 4.7. Upstream Multicast Hop Determination Upstream multicast hop determination in the PIM+RSVP-TE profile is 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 S-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]. 5. IANA Considerations To be supplied. 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. However, the use of IPsec does not apply, as there are no established procedures for using IPsec to protect multicast traffic. Rosen, et al. [Page 17] Internet Draft draft-rosen-l3vpn-mvpn-profiles-00.txt November 2007 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, D. Farinacci, et. al., "Generic Routing Encapsulation", March 2000 [MLDP] "LDP Extensions for P2MP and MP2MP LSPs", I. Minei, IJ. Wijnands, draft-ietf-mpls-ldp-p2mp-03.txt, July 2007 [MPLS-MCAST-ENCAPS] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, "MPLS Multicast Encapsulations", draft-ietf-mpls-multicast- encaps-07.txt, November 2007 [MPLS-UPSTREAM-LABEL] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Rosen, et al. [Page 18] Internet Draft draft-rosen-l3vpn-mvpn-profiles-00.txt November 2007 Upstream Label Assignment and Context Specific Label Space", draft- ietf-mpls-upstream-label-02.txt, March 2007 [MVPN] E. Rosen, R. Aggarwal, et. al., "Multicast in MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-05.txt, July 2007 [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-03.txt, July 2007 [PIM-ATTRIB] A. Boers, IJ. Wijnands, E. Rosen, "Format for Using TLVs in PIM Messages", draft-ietf-pim-join-attributes-03, May 2007 [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 [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 10. Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an Rosen, et al. [Page 19] Internet Draft draft-rosen-l3vpn-mvpn-profiles-00.txt November 2007 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 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. 11. Intellectual Property 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. Rosen, et al. [Page 20]