Network Working Group Seisho Yasukawa IETF Internet Draft NTT Expires: April 2005 Shankar Karuna Sarveshwar Bandi Motorola Adrian Farrel Old Dog Consulting October 2004 BGP/MPLS IP Multicast VPNs draft-yasukawa-l3vpn-p2mp-mcast-00.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Yasukawa, Karuna, Bandi and Farrel. [Page 1] Internet Draft draft-yasukawa-l3vpn-p2mp-mcast-00.txt October 2004 Abstract This document describes a solution framework for IP Multicast VPNs. It describes procedures for establishing optimal virtual private IP multicast networks over a provider network. The simple multicast tunnel operation mechanism within a core network provides easy and flexible IP multicast VPN service operation for the service provider. And because the solution can minimize PIM neighbor maintenance over remote PEs, the solution enhances the scalability performance of the multicast VPN service network. This document also describes a P2MP TE LSP based multicast tunnel mechanism which could enhance TE capability and reliability of IP multicast VPNs. Conventions used in this document 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]. Yasukawa, Karuna, Bandi and Farrel. [Page 2] Internet Draft draft-yasukawa-l3vpn-p2mp-mcast-00.txt October 2004 Contents 1. Introduction .................................................. 04 2. Motivations ................................................... 04 2.1. Basic Motivations for IP multicast VPN operation ......... 04 2.2. Motivations for IP multicast VPN protocol design ......... 05 3. IP Multicast VPN Framework .................................... 06 3.1. Basic network model ...................................... 06 3.2. Proxy-Source/RP model .................................... 08 3.3. Proxy-Source/RP function ................................. 09 3.4. Auto-Discovery of VPN membership ......................... 09 3.5. Default MDT configuration ................................ 10 3.6 Exchanging IP multicast register information .............. 10 3.6.1. Source Activate (SA) SAFI .............................. 11 3.6.2. JOIN SAFI .............................................. 12 3.7 Default MDT operation ..................................... 13 3.8. Data MDT operation ....................................... 14 3.9. Inter-Site Scaling and Site Interdependencies ............ 16 3.10. Multi-Homing scenario ................................... 17 3.11. Multi-Area/As operation ................................. 17 4. IANA Considerations ........................................... 17 5. Security Considerations ....................................... 17 6. Acknowledgements .............................................. 17 7. Intellectual Property Considerations .......................... 17 8. Normative References .......................................... 18 9. Informational References ...................................... 18 10. Authors' Addresses ........................................... 19 11. Full Copyright Statement ..................................... 20 Yasukawa, Karuna, Bandi and Farrel. [Page 3] Internet Draft draft-yasukawa-l3vpn-p2mp-mcast-00.txt October 2004 1. Introduction This document describes a solution framework for IP Multicast VPNs. It describes basic procedures for establishing optimal virtual private IP multicast networks over a provider network by dividing a customer's multicast network into multiple regions and setting independent multicast distribution trees within each customer site and interconnecting these independent trees by provider P2MP MPLS tunnels. In this solution, each PE connected to a customer's site acts as a proxy-source or a proxy-rendezvous point (RP) for the multicast group and a default multicast tunnel is established from a PE which accommodates a multicast source to multiple PEs which act as proxy-source/RP for their receivers in the connected site. As a result, the solution can construct IP multicast distribution trees that have optimal topologies for IP multicast distribution and avoid using multiple multicast and unicast distribution tunnels in the service provider core during the customer's tree transition phase. This simple multicast tunnel operation mechanism within a core provides easy and flexible IP multicast VPN service operation for the service provider. And, because the solution can terminate each customer's Join/Prune message at PEs, the solution can minimize PIM neighbor maintenance over remote PEs. This enhances the scalability performance of multicast VPN service network. This document also describes a P2MP TE LSP based multicast tunnel mechanism which could enhance TE capability and reliability of IP multicast VPNs. 2. Motivations 2.1. Basic Motivations for IP multicast VPN operation There are growing demands for providing IP multicast services on top of a BGP/MPLS IP VPN [RFC2547bis] environment. Candidates for these services are, for example, in-house video distribution/conference and data synchronization/distribution between business system servers which usually require strict QoS control and highly reliable network conditions. Therefore it is highly desirable that a solution has the capability to implement some QoS guarantee and protection mechanisms in itself, or has capabilities to operate with conventional QoS guarantee and protection mechanisms. Because IP multicast VPNs require full meshed multicast distribution between multiple customer sites, and this operation usually requires complicated multicast tree management within a provider core network, it is also highly desirable that a solution provides the service provider with several easy mechanisms to control and manage these IP multicast distributions within the network. Yasukawa, Karuna, Bandi and Farrel. [Page 4] Internet Draft draft-yasukawa-l3vpn-p2mp-mcast-00.txt October 2004 2.2. Motivations for IP multicast VPN protocol design The basic function of an IP multicast VPN is to enable a multicast source which exists in a customer site to send IP multicast traffic privately over the provider core network to multicast receivers that exist in different customer sites. To enable this private IP multicast transmission, several solutions have been proposed. Within the proposals, the most significant solution is [MCAST-VPN] which introduces the Multicast Domain (MD) mechanism to interconnect each customer's IP multicast networks over the provider network to enable IP multicast distribution between the sites. An MD is essentially a set of MVRFs associated with interfaces that can send multicast traffic to each other and is equivalent to a multi-access interface from the standpoint of a PIM customer instance. Therefore, in this MD model, a provider wide customer IP multicast network is formed over an MD which transparently exchanges customer's IP multicast control messages between PEs which form IP multicast adjacencies between them. This means that when the customer network runs the PIM protocol, PIM adjacencies are formed between MVRFs at the PEs and periodic PIM Join/Prune messages and Hello messages are transmitted between them. This features introduces some scalability concerns for the service provider when they operate IP multicast VPNs because today's conventional L3VPNs accommodate a lot of large scale VPNs and it is easily assumed that a majority of these VPNs will introduce IP multicast VPN services in the near future. This would require a huge amount of PIM adjacencies to be maintained over the provider core network and this would reduce the VPN's network performance and increase the difficulties of managing the network. A further MVPN proposal [MVPN-RAGGARWA] addresses three scalability concerns for this conventional [MCAST-VPN] solution as fundamental issues to be resolved. The first addressed concern is the overhead of PIM neighbor adjacencies. The second concern is the overhead of periodic PIM Join/Prune messages, and the last concern is the amount of state in the SP core. It is highly desirable for any solution to address these concerns. Another concern which is not yet addressed is suboptimal IP multicast distribution which could easily occur in an IP multicast VPN environment. Most customers want to operate their own private IP multicast networks over multiple customer sites which are usually widely separated from each other over the provider network, and it is easily assumed that the customer runs PIM [PIM-SM] with only a very limited number of RPs in sites which may be located remotely from the site which a multicast source belongs to. In this case, during shared Yasukawa, Karuna, Bandi and Farrel. [Page 5] Internet Draft draft-yasukawa-l3vpn-p2mp-mcast-00.txt October 2004 tree distribution, multicast packets must first be sent to the RP's site and then must to be sent back to receivers' sites even in the case where some receivers belong to the same site as the source. This kind of multiple transmission over the provider network is suboptimal and wastes network resource. Moreover some receivers would suffer severe transmission delays and some multicast application would not tolerate this. In addition to these undesirable conditions, a customer's IP multicast distribution pattern changes drastically when the distribution tree is transferred from a shared tree to a source specific tree. This would also cause drastic changes in the multicast distribution pattern in the provider core and would introduce unstable conditions for the operation of the core network and consequently for the VPNs. There is no mechanism for a service provider to limit this kind of undesirable condition and to control the multicast distribution pattern. Therefore it is highly desirable for a solution to address these concerns. It is desirable for a solution to provide the service provider with mechanisms which can avoid this kind of suboptimal IP multicast distribution within their core networks and which can allow control of multicast distribution within their core networks by eliminating the necessity of using and changing multiple multicast tunnels and by providing a minimum number of stable multicast tunnels which are easily managed by the service provider. Because some IP multicast VPN applications require bandwidth guarantees, delay-constrained multicast distribution paths, and highly reliable paths, it is desirable for a solution to have capabilities to setup a bandwidth guaranteed multicast distribution path, to explicitly control routes of the distribution path, and to accommodate global and fast local repair mechanisms. 3. IP Multicast VPN Framework 3.1. Basic network model This document utilizes the same network model as BGP/IP MPLS VPNs [RFC2547bis] for realizing IP multicast VPNs. A provider configures whether a particular VPN is multicast-enabled or not. All the PEs that contain customer sites belonging to the same VPN with multicast enabled on them will be connected using a "Multicast Distribution Tree (MDT)" in the provider's backbone. Yasukawa, Karuna, Bandi and Farrel. [Page 6] Internet Draft draft-yasukawa-l3vpn-p2mp-mcast-00.txt October 2004 As deployed in BGP/IP MPLS VPNs [RFC2547bis] and [MCAST-VPN], each CE router is a multicast routing adjacency of a PE router, but CE routers at different sites do NOT become multicast routing adjacencies of each other. Unlike the [MCAST-VPN] model, this document proposes the use of BGP for both discovering IP multicast VPN membership and exchanging IP multicast routing information in a given IP multicast VPN. As for the membership discovery, all the PE routers advertise their IP multicast VPN membership to other PE routers using BGP so that each PE router in the network has a complete view of the IP multicast VPN membership of the other PE routers. After this information exchange, the Default MDT for a Multicast Domain is constructed automatically. Note that this Default MDT construction occurs when the PEs in the domain come up and advertise their membership of a multicast enabled VPN, and the construction does not depend on the existence of multicast traffic in the domain. One further difference is that the MDTs are usually created by P2MP TE LSPs by running a P2MP TE signaling protocol in the backbone. Therefore, it may not be necessary to run IP multicast routing protocols in the core to support IP multicast VPNs (dependent on how the P2MP TE trees are managed). As for multicast routing information exchange, this document proposes BGP to carry the information. Therefore, being different from the [MCAST-VPN] model, the customer's IP multicast instances of a particular VPN running on the PE do not form routing adjacencies with each other. This means that the customer's IP multicast control packets are always terminated at PEs and independent multicast domains are formed within each customer site which is a member of the IP multicast VPN. In this model, the customer's IP multicast control messages, such as PIM Join/Prune messages, are converted to BGP messages and these messages are exchanged between PEs so that IP multicast routing can be enabled between each independent IP multicast domains. This preserves two important features of BGP/IP MPLS VPNs [RFC2547bis]; "Separation of controlling and forwarding plane in the provider core" and "Distribution of customer's routing information via provider's routing facility". These are very important preservations for the SP to preserve its network management model while allowing it to control/engineer the customer's data traffic and control traffic over the network. Yasukawa, Karuna, Bandi and Farrel. [Page 7] Internet Draft draft-yasukawa-l3vpn-p2mp-mcast-00.txt October 2004 Multicast data packets from within a VPN are received from a CE router by an ingress PE router, the ingress PE then encapsulates the mutlicast packets and forwards them along the Default MDT to all the PE routers connected to sites of the given VPN. Every PE router attached to a site of the given VPN thus receives all multicast packets from within that VPN. If a particular PE router is not on the path to any receiver of that multicast group, the PE simply discards that packet. In the same way as [MCAST-VPN], this document proposes to set up Data MDTs to accommodate a large amount of traffic being sent to a particular multicast group but where that group does not have receivers at all the VPN sites. 3.2. Proxy-Source/RP model Section 2.2 of [RFC3446] describes the need to run multiple RPs in the scenarios where the topological location of RP, Source and receivers are unpredictable. This document proposes a solution along similar lines. This document proposes that all PEs which are members of a given VPN act as proxy Source/RPs for a given IP multicast group. Approving all the PEs to be a proxy Source/RP for the group, each customer site can form an independent IP multicast tree within the site regardless of multicast tree formations in other sites. To accomplish this model, a PE that is either directly connected to the multicast source in the VPN or connected via a CE MUST act as a proxy-RP for the receivers in the same site when the customer network runs PIM-SM protocol in the VPN. If a customer wants to run the RP within his network, in such a case the customer can configure one RP on each of his sites and can use an anycast-RP and MSDP based mechanism [RFC3446]. This solution can be extended to support such an approach and is presently out of scope of this document. A PE that is either directly connected to an RP in the VPN or connected via a CE MUST act as a Source/RP for the receivers in the same site, and a PE that is either directly connected to multicast receivers for that multicast group or connected via a CE MUST act as a Source/RP for the receivers in the same site. Yasukawa, Karuna, Bandi and Farrel. [Page 8] Internet Draft draft-yasukawa-l3vpn-p2mp-mcast-00.txt October 2004 A P2MP TE LSP or a MP2MP TE LSP which is described in a later section is established from an ingress PE to multiple egress PEs to form a default MDT. The setup of default MDT is triggered after the VPN membership auto-discovery phase. Therefore, each egress PE which acts as a proxy-Source/RP can always receive IP multicast data traffic via this LSP tunnel. A P2MP TE LSP is established from an ingress PE to egress PEs which are interested in receiving the multicast data dynamically to form a data MDT. The ingress PE sets up and modifies a data MDT dynamically by receiving BGP messages which convey egress PEs interests for joining/leaving the VPN membership. Therefore, each egress PE which acts as a proxy-Source/RP can receive IP multicast data traffic via this LSP tunnel on demand. 3.3. Proxy-Source/RP function To make each PE interconnected to a customer site act as a proxy-RP, this document assumes that some RP discovery mechanisms, such as static configuration or Bootstrap Router, indicates all of the PIM router existing in the connected customer site to perform the same group-to-RP (PE) mapping. This ensures that all the PIM router in the customers site utilize the PE as RP. The PE which act as RP and interconnected to IP multicast source must handle PIM register message operations, including decapsulation and sending source specific join message and PIM register stop message and must convert PIM register message to IP multicast source active information. The PE which acts as RP and is interconnected to multicast receivers must terminate PIM Join/Prune messages and convert this information to IP multicast registration information. 3.4. Auto-Discovery of VPN membership This document assumes MDT SAFI [MDT-SAFI] to discover VPN membership. In this model, a MDT group-address is defined per Multicast Domain and all the PEs that are configured with MVRFs belonging to same IP multicast VPN discover each other thorough this SAFI. Yasukawa, Karuna, Bandi and Farrel. [Page 9] Internet Draft draft-yasukawa-l3vpn-p2mp-mcast-00.txt October 2004 3.5. Default MDT configuration After VPN membership discovery, each PE which is a member of an IP multicast VPN will trigger the formation of a P2MP tree towards every other PE that has Multicast VRFs for the same Multicast Domain. The P2MP TE LSPs [P2MP-RSVP] are established by assigning a MDT group-address to the P2MP ID of the SESSION object, and assigning the initiator PE's address to the Tunnel Sender Address of the SENDER_TEMPLATE object. The destination PEs are designated as leaves of the P2MP tree and are encoded as recipients in P2P Sub-LSP Objects. In order for each PE to forward received IP multicat data packets to the appropriate MVRF, each PE which is a member of the IP multicast VPN MUST associate the P2MP TE LSPs with a proper MVRF by assigned P2MP Labels. These associations are configured when a PE assigns P2MP Labels to the P2MP TE LSPs. Therefore, in this model, PHP operation MUST be strictly prohibited. A MP2MP TE LSP can be also utilized for establishing a Default MDT. With the help of Route Reflector functionality in MP-BGP the PE's interested in this Multicast Domain are learnt at the node that runs as the Route reflector and these PE's are configured as leaves for P2MP TE LSP with the route reflector node as root. After an RP has set up a P2MP TE LSP to the leaves, the leaves setup a P2P TE LSPs to the RP. In this way, a MP2MP TE LSP is established between PEs which are members of the Multicast Domain. This MP2MP based Default MDT configuration mechanism is useful but it is out of scope of this document. The detailed mechanism and procedure will be defined in the another [MP2MP-TE-MPLS] document. 3.6 Exchanging IP multicast register information This documents proposes exchanging two kinds of IP multicast register information between PEs via BGP. A new Subsequent-Address Family called Source Activate (SA) SAFI is newly defined to announce the activation of a particular customer's IP multicast data stream. This SAFI is used by a PE which is either directly connected to an IP multicast source or connected via a CE to inform other PEs located in different sites that a particular customer's (S,G) IP multicast data stream has become active and this active IP multicast data can be accessed via this announcing PE. Therefore, a PE which is either directly connected to an IP multicast source or connected via a CE and acts as proxy RP and sends this information via BGP after it confirms establishment of a source Yasukawa, Karuna, Bandi and Farrel. [Page 10] Internet Draft draft-yasukawa-l3vpn-p2mp-mcast-00.txt October 2004 specific IP multicast tree between the Designated Router and itself by sending a Register-Stop message and receiving a Null-Register Message. Another Subsequent-Address Family called JOIN SAFI is also newly defined to announce the interest of a particular PE to join and prune a particular customer's IP multicast data stream. This SAFI is used by PEs which are either directly connected to IP multicast receivers or connected via CEs to inform a PE which is either directly connected to an IP multicast source or connected via a CE that they are interested in receiving a particular customer's (S,G) IP multicast data stream by announcing JOIN SAFI information. Therefore PEs which are either directly connected to IP multicast receivers or connected via CEs and which act as proxy-Source/RPs send this information via BGP after they have received SA information and have confirmed that IP multicast receivers in their site are also interested in receiving/leaving this IP multicast data stream by receiving customer Join/Prune message. 3.6.1. Source Activate (SA) SAFI This SAFI is used to announce to all the other PEs about a particular customer (S,G) data stream becoming active. SA SAFI: +------------------------------+ | | | RD (8 octets) | +------------------------------+ | PE's IPv4 address | | (4 octets) | +------------------------------+ | Provider's Group-address | | (4 octets) | +------------------------------+ | Customer's Source-address | | (4 octets) | +------------------------------+ | Customer's Group-address | | (4 octets) | +------------------------------+ PE's IPv4 address: IP address of the PE that has detected a multicast source in the customer network. Yasukawa, Karuna, Bandi and Farrel. [Page 11] Internet Draft draft-yasukawa-l3vpn-p2mp-mcast-00.txt October 2004 Provider's Group-address: The PE assigns a multicast group address from an address range that is independent of the customer multicast group addresses. This multicast group address is used by the PE's that have interested receivers to be able to associate a Data MDT associated with data stream corresponding to Customer's Source-address and Customer's Group-address Customer's Source-address: Address of customer's multicast source. Customer's Group-address : Address of customer's multicast group address. 3.6.2. JOIN SAFI This SAFI will be used by a PE when it desires to receive data for a particular customer (S,G) data stream. JOIN SAFI: +------------------------------+ | | | RD (8 octets) | +------------------------------+ | PE's IPv4 address | | (4 octets) | +------------------------------+ | Customer's Source-address | | (4 octets) | +------------------------------+ | Customer's Group-address | | (4 octets) | +------------------------------+ PE's IPv4 address: IP address of the PE that has interested receivers. Customer's Source-address: Address of customer's multicast source. Customer's Group-address : Address of customer's multicast group address. Yasukawa, Karuna, Bandi and Farrel. [Page 12] Internet Draft draft-yasukawa-l3vpn-p2mp-mcast-00.txt October 2004 3.7 Default MDT operation This section describes how the proposed solution enables IP multicast VPN operation using a Default MDT assuming a VPN customer runs the PIM-SM protocol within their network. To establish a Default MDT, MVRFs are first configured on every PE which is a member of a given IP multicast VPN. A unique group address and RD are assigned to that Multicast Domain. After this configuration, each that PE belongs to that Multicast Domain announces its VPN membership to other PEs by BGP using MDT-SAFI. After this auto-discovery of VPN membership, each PE initiates the formation of a P2MP TE LSP by assigning the group address to that LSP. A P2MP TE LSP is established from the initiator PE to other PEs which are also members of this Multicast Domain. During the P2MP TE LSP establishment each PE that is also egress of the LSP and a member of that Multicast Domain configures an association between P2MP TE LSPs which constitute Default MDT and MVRF for that Multicast Domain by relating assigned MPLS labels to the MVRF. The egress PE uses the group address announced by the PE, which is the root for this P2MP TE LSP, in the MDT-SAFI message [MDT-SAFI]. Note that as described in the previous section, a MP2MP TE LSP could be utilized to establish the Default MDT. But MP2MP TE MPLS is out of scope of this document and its detailed mechanism and procedure will be addressed in another document. Because in this mechanism, each PE that is member of the Multicast Domain must act as a proxy-RP for that multicast groups. Therefore, all PIM router within a customer's site must be configured by some mechanism to treat a connected PE as its RP and to perform same group-to-proxy-RP mapping. Examples of these mechanism are static configuration and Bootstrap Router mechanism [PIM-BSR] described in the previous section. Consider the situation where an IP multicast source starts IP multicast distribution. The Designated Router (DR) encapsulates IP multicast data packets and sends these packets as PIM register messages to a PE which now act as proxy-RP for that customer's site. Receiving PIM register messages, the PE sends a source specific Join message to the DR to form a source specific multicast tree between the PE and the DR. The PE simultaneously starts announcing to other PEs the activation of a multicast group via BGP using the SA SAFI. The PE sends a Register stop message to the DR after it starts receiving multicast Data on the source specific tree. Yasukawa, Karuna, Bandi and Farrel. [Page 13] Internet Draft draft-yasukawa-l3vpn-p2mp-mcast-00.txt October 2004 When receivers in another customer site want to Join a given multicast distribution, then the receivers send Join (*,G) messages to their RP to form a shared multicast distribution tree. Note that a PE which is either directly connected to the receivers or connected via a CE now acts as proxy-RP for the receivers. Therefore a shared multicast distribution tree is formed from proxy-RP (PE) to multiple receivers in a customer's site. And because this PE knows that corresponding multicast data is already activated, the PE sends its IP multicast registry information via BGP using JOIN SAFI. This information is flooded to all the PEs. As a result, an ingress PE which is either directly connected to the IP multicast source or connected via a CE configures its MVRF to start forwarding received IP multicast data packets to a P2MP TE LSP which comprises the Default MDT. In this way, IP multicast data packets are MPLS encapsulated at an ingress proxy-RP (PE) and are tunneled via the P2MP TE LSP to all the egress proxy-Source/RPs (PEs) and these IP multicast data packets are decapsulated at the egress PEs and IP multicast data packets are transmitted to IP multicast receivers in the site if a shared tree is already formed by multicast receivers who are interested in receiving these IP multicast flows. When receivers in the customer's site want to switch multicast distribution trees from a shared tree to a source specific tree, the receivers send source specific Join (S,G) message to source node. In this case, a source node is located in another site and therefore this message is always transmitted to the PE which now acts as the proxy-RP for that multicast group. Receiving this source specific Join message, the PE changes IP multicast distribution to the source specific tree because the PE starts acting as proxy-Source from that point of time. Note that this multicast tree switch over does not cause any additional JOIN SAFI transmission by the PE because the PE can already receive IP multicast data and can act as proxy- Source without changing the multicast distribution operation over the provider core network. In this way, each customer's IP multicast domain switches IP multicast tree from shared tee to source specific tree independently without affecting the multicast distribution within a provider core network and another customer's sites. 3.8. Data MDT operation This document proposes to setup Data MDTs in addition to a Default MDT when IP multicast transmission over a Default MDT is judged as inefficient. The difference from conventional approaches [MCAST-VPN] [MVPN-RAGGARWA] is this document assumes that Data MDTs are constructed by [P2MP-RSVP]. Therefore, this proposal can construct QoS guaranteed and highly reliable Data MDTs which would be better for a particular class of IP multicast traffic. Yasukawa, Karuna, Bandi and Farrel. [Page 14] Internet Draft draft-yasukawa-l3vpn-p2mp-mcast-00.txt October 2004 This section describes how the proposed solution enables IP multicast VPN operation using the Data MDT assuming a VPN customer runs the PIM-SM protocol within their network. In this document, we assume two kinds of Data MDT construction model; Static configuration model and Traffic driven model. In the static configuration model, we assume that IP multicast flows which are transmitted by Data MDTs are pre-defined and mutually agreed by the SP and its customers. This means that multicast group addresses assigned for IP multicast flows which use Data MDT are pre-defined and configured on each PE's MVRF. Therefore an ingress PE which is registered by this multicast group address can setup, modify and tear-down an appropriate P2MP TE LSP on demand. When several downstream PEs which act as proxy-RP for interconnected customer sites detect the existence of receivers which are interested in joining a particular multicast distribution by receiving Join messages, then the PEs report their interest to join the group by BGP using the JOIN SAFI. After receiving these reports, an ingress PE establishes a P2MP TE LSP to the egress leaves which have reported interest. After this operation, when a new PE uses the BGP JOIN SAFI to report to the ingress PE its interest to join the the group, the ingress PE initiates Grafting and expands the P2MP TE LSP to reach that new PE. When an existing PE detects that no more receivers are connected to a customer's site by receiving Prune messages, the PE withdraws the corresponding IP multicast registration by using BGP withdraw message specifying the corresponding JOIN SAFI. Then the ingress PE initiates Pruning and cuts out the unnecessary leaf from the P2MP TE LSP. In this way, this proposal can setup, modify and tear-down Data MDT on demand basis. In the traffic driven model, an ingress PE monitors incoming IP multicast data packets and when it detects some data flow exceeds a pre-determined threshold, then the ingress PE immediately establishes a new P2MP TE LSP to reach the receivers' PEs because the ingress PE recognizes which PEs are interested in joining this group via BGP. After establishment, the ingress PE switches corresponding IP multicast data packets from the Default MDT to the Data MDT. In this way, Data MDT based IP multicast transmission is performed on demand in this model. After this Data MDT establishment, this model follows exactly the same operations as the static configuration model when the Data MDT is modified. In order to associate the Data MDT with the appropriate MVRF, the egress PEs utilize the PE Group-address announced by the PE (which is the root of the P2MP TE LSP) via the SA SAFI. Yasukawa, Karuna, Bandi and Farrel. [Page 15] Internet Draft draft-yasukawa-l3vpn-p2mp-mcast-00.txt October 2004 3.9. Inter-Site Scaling and Site Interdependencies As described in section 3.8, customer sites may be members of the same multicast VPN yet operate in near independence. That is, each site has its own RP and may choose to use a source-specific tree based at the PE, or a shared distribution tree. This choice is private to each customer site, and is not communicated to other sites (nor would it provide any useful information if it were communicated). Clearly, also, the number of leaves downstream of an egress PE does not affect the way in which the traffic is managed at upstream nodes. That is, neither the source site nor the MPLS P2MP TE LSP in the SP's network are in any way different if there is one or one hundred receivers at a customer site downstream of an egress PE. The PE represents a fixed point in the multicast tree that must receive data and is an egress of the MPLS P2MP TE LSP. For this reason, there is no requirement for the routing protocols to report each receiver across the SP network to the ingress site when the receivers are added to or removed from the multicast group. All that is required is that the egress PE reports (using the BGP JOIN SAFI) when the first receiver joins the group so that it becomes a leaf on the MPLS P2MP TE LSP, and indicates when the last receiver at the site leaves the multicast group so that the PE can be pruned from the MPLS P2MP TE LSP. In order to make this optimization each PE must count the number of receivers at its site, but since it is acting as a proxy-source/RP this is easy for it to do. Such an optimization substantially reduces the amount of MP-BGP traffic caused by the VPN multicast group and is RECOMMENDED for all implementations. Note that an egress PE that makes this optimization may further protect itself against flapping membership of a multicast group. In the case where the membership may frequently vary between no receivers and some receivers an egress PE MAY choose to remain as a leaf of the MPLS P2MP TE LSP for some period of time (controllable by the operator) even when it has no downstream receivers for the multicast traffic. If a local timer expires before any new receivers join the group, the PE should use MP-BGP to report that it no longer wishes to receive data for the multicast group, and this will result in it being pruned from the MPLS P2MP TE LSP tree. Any traffic received by a PE for a multicast group for which it has no downstream receivers SHOULD be discarded. Yasukawa, Karuna, Bandi and Farrel. [Page 16] Internet Draft draft-yasukawa-l3vpn-p2mp-mcast-00.txt October 2004 3.10. Multi-Homing scenario The proposed solution provides a very effective fail over mechanism in the case where the multicast source/receivers are connected to multiple PEs. The PEs which are connected to the customer network announce themselves as the RPs via the bootstrap mechanism. When one of the PE fails the alternate PE becomes RP for this multicast domain and this PE can readily takeover as it is already connected via the default MDT. 3.11. Multi-Area/As operation This solution can be easily extended to Multi-Area/As operations as P2MP TE tunnels can be setup in such scenarios between the PEs. The details of this section will be provided in the next revision. 4. IANA Considerations [TBD] 5. Security Considerations Since this document is based on [RFC2547bis] and [P2MP-RSVP], the security considerations involving those drafts apply here as well. 6. Acknowledgements We would like to thank Antu Chatterjee and Masaaki TAKAGI for their suggestions and contributions to this draft 7. Intellectual Property Considerations 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. Yasukawa, Karuna, Bandi and Farrel. [Page 17] Internet Draft draft-yasukawa-l3vpn-p2mp-mcast-00.txt October 2004 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. 8. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667, February 2004. [RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3668, February 2004. [RFC2547bis] Rosen, E., et. al. "BGP/MPLS VPNs", draft-ietf-l3vpn-rfc2547bis, work in progress [PIM-SM] B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", draft-ietf-pim-sm-v2-new-08.txt, work in progress. 9. Informational References [RFC3446] D. Kim, D. Meyer, H. Kilmer, D. Farinacci, "Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP)", January 2003 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP: 26, RFC 2434, October 1998. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. Yasukawa, Karuna, Bandi and Farrel. [Page 18] Internet Draft draft-yasukawa-l3vpn-p2mp-mcast-00.txt October 2004 [RFC3552] Rescorla E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP: 72, RFC 3552, July 2003. [P2MP-REQ] S. Yasukawa, et. al., "Requirements for Point to Multipoint Traffic Engineered MPLS LSPs", draft-ietf-mpls-p2mp-requirement, work in progress. [P2MP-RSVP] R. Aggarwal, et. al., "Extensions to RSVP-TE for Point to Multipoint TE LSPs", draft-raggarwa-mpls-rsvp-te-p2mp, work in progress. [MDT-SAFI] Nalawade and Sreekantiah, "MDT SAFI", draft-nalawade-idr-mdt-safi-00.txt, February 2004 [MCAST-VPN] Y. Cai, E. Rosen, I. Wijnands, "Multicast in BGP/MPLS IP VPNs", , May 2004. [MVPN-RAGGARWA] R. Aggarwal, "Multicast in BGP/MPLS VPNs and VPLS", , February, 2004. [MP2MP-TE-MPLS] Work in progress [PIM-BSR] N.Bhaskar, A Gall and Stig Venaas, "BootStrap Router(BSR) Mechanism for PIM", , July 2004. 10. Authors' Addresses Seisho Yasukawa NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585, Japan Phone: +81 422 59 4769 Email: yasukawa.seisho@lab.ntt.co.jp Shankar Karuna Motorola Vanenburg IT park, Madhapur, Hyderabad, India Email: kshankar@motorola.com Yasukawa, Karuna, Bandi and Farrel. [Page 19] Internet Draft draft-yasukawa-l3vpn-p2mp-mcast-00.txt October 2004 Sarveshwar Bandi Motorola Vanenburg IT park, Madhapur, Hyderabad, India Email: sarvesh@motorola.com Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk 11. Full Copyright Statement Copyright (C) The Internet Society (2004). 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 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Yasukawa, Karuna, Bandi and Farrel. [Page 20]