Internet Draft Network Working Group Eric C. Rosen Internet Draft Yiqun Cai Expiration Date: May 2001 Yakov Rekhter Dan Tappan IJsbrand Wijnands Cisco Systems, Inc. Dino Farinacci Procket Networks, Inc. November 2000 Multicast in MPLS/BGP VPNs draft-rosen-vpn-mcast-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 [RFC2547bis] describes a method of providing a VPN service. It specifies the protocols and procedures which must be implemented in order for a Service Provider to provide a unicast VPN. This document extends that specification by describing the protocols and procedures which a Service Provider must implement in order to support multicast traffic in a VPN, assuming that PIM [PIMv2] is the multicast routing protocol used within the VPN, and the the SP network can provide PIM Rosen, et al. [Page 1] Internet Draft draft-rosen-vpn-mcast-00.txt November 2000 as well. Table of Contents 1 Introduction ....................................... 2 2 Multicast Domains .................................. 4 2.1 Multicast VRFs ..................................... 4 2.2 Multicast Tunnels .................................. 5 2.3 PIM across the MD .................................. 6 2.4 RPF Determination .................................. 6 2.5 Avoiding Conflict with Internet Multicast .......... 7 2.6 Dense Mode ......................................... 7 2.7 Forwarding ......................................... 7 2.8 Scalability ........................................ 8 2.9 Increasing the Optimality .......................... 8 2.10 Inter-Provider Considerations ...................... 9 3 VPN-IP PIM-SM ...................................... 9 3.1 Multicast VRFs ..................................... 10 3.2 Use of VPN-IP addresses in PIM ..................... 10 3.3 Forwarding ......................................... 11 3.4 Associating VPN-IP PIM Messages with VRFs .......... 11 3.5 The RPF Hint ....................................... 12 3.6 When a PE Sends a PIM Message to the Backbone ...... 12 3.7 PIM Bootstrap Messages ............................. 14 4 Multicast Domains Using PIM NBMA Techniques ........ 15 5 Intellectual Property Considerations ............... 15 6 Acknowledgments .................................... 16 7 References ......................................... 16 8 Authors' Addresses ................................. 16 1. Introduction [RFC2547bis] describes a method of providing a VPN service. It specifies the protocols and procedures which must be implemented in order for a Service Provider to provide a unicast VPN. This document extends that specification by describing the protocols and procedures which a Service Provider must implement in order to support multicast traffic in a VPN, assuming that PIM [PIMv2] is the multicast routing protocol used within the VPN, and that the SP network can provide PIM as well. Familiarity with the terminology and procedures of [RFC2547bis] is presupposed. Familiarity with [PIMv2] is also presupposed. Rosen, et al. [Page 2] Internet Draft draft-rosen-vpn-mcast-00.txt November 2000 The discussion here must not be confused with discussions elsewhere of Internet multicast. What we are considering here is primarily Enterprise multicast; our goal is to allow an Enterprise which has a VPN service as defined in [RFC2547bis] to implement Enterprise multicasts using PIM-SM or PIM-DM. VPNs which are constructed according to [RFC2547bis] obtain optimal unicast routing through the SP backbone, even though: - the P routers do not maintain any routing information for the VPNs, or indeed, any per-VPN state at all, and - the CE routers at different sites do not maintain routing adjacencies with each other. Unfortunately, one cannot do quite so well with multicast routing. For optimal multicast routing, when a PE router receives a multicast data packet of a particular multicast group from a CE router, the packet must get to every other PE router which is on the path to a receiver of that group. It must not get to any other PEs. And it must not be unnecessarily replicated. Optimal routing requires a source-tree for the multicast group, which would mean that the P routers would have to maintain state for each transmitter of each multicast group in each VPN. While this would provide optimal multicast routing, it also requires an unbounded amount of state in the P routers, since the SP has no control whatsoever of the number of multicast groups in the VPNs that it supports. Nor does it have any control over the number of transmitters in each group, nor of the distribution of the receivers. In short, true optimal routing of VPN multicasts in the SP network does not appear to be scalable. For completeness, we do specify, in section 3 ("VPN-IP PIM"), how one could provide true optimal routing of Spare Mode VPN multicasts in the SP network. While we do not propose to adopt this solution, it is instructive to compare it with the solution we do propose in section 2. We also include, in section 4, a very brief description of a scheme which does not require any multicast routing state at all to be kept in the P routers, but in which all the replication is done in the PE routers. If we are willing to send multicasts along paths on which there are no receivers, then it is possible to support VPN multicasts, using exactly one multicast distribution tree for each VPN, and without requiring that all replication is done by the PE routers. If more than one site in a VPN may have multicast transmitters, it is best Rosen, et al. [Page 3] Internet Draft draft-rosen-vpn-mcast-00.txt November 2000 for this single tree to be a bidirectional tree [BIDIR]. (In environments, such as an ATM-LSR backbone, where bidirectional trees cannot be supported, a single shared tree can be used.) We describe in section 2 the procedures and protocols used to implement this solution, which we dub "Multicast Domains". It is this procedure which we propose for adoption. In unicast routing, a CE router is an adjacency of a PE router, and CE routers at different sites do NOT become adjacencies of each other. We retain this characteristic for multicast routing -- a CE router becomes a PIM adjacency of a PE router, and CE routers at different sites do NOT become adjacencies of each other. An Enterprise which uses PIM multicasting in its network before adopting the VPN service can transition to the VPN service while continuing to use whatever multicast router configurations it was previously using; no changes need be made to CE routers or to other routers at customer sites. Any dynamic RP-discovery procedures that area already in use may be left in place. The notion of a "VRF", defined in [RFC2547bis], to include multicast routing entries as well as unicast routing entries. 2. Multicast Domains In this section, we describe the solution we are proposing for adoption. A "Multicast Domain" is essentially a set of VRFs associated with interfaces that can send multicast traffic to each other. 2.1. Multicast VRFs Each VRF has its own multicast routing table. When a multicast data or control packet is received from a particular CE device, multicast routing is done in the associated VRF. Each PE router runs a number of instances of PIM-SM, as many as one per VRF. In each instance of PIM-SM, the PE maintains a PIM adjacency with each of the PIM-capable CE routers associated with that VRF. The multicast routing table created by each instance is specific to the corresponding VRF. We will refer to these PIM instances as "VPN-specific PIM instances". Each PE router also runs a "global" instance of PIM-SM, in which it Rosen, et al. [Page 4] Internet Draft draft-rosen-vpn-mcast-00.txt November 2000 has a PIM adjacency with each of its IGP neighbors (i.e., with P routers), but NOT with any CE routers, and not with other PE routers (unless they happen to be adjacent in the SP's network). In order to help clarify when we are global of the global PIM instance and when we are speaking of a VPN-specific PIM instance, we will use the prefixes "P-" and "C-" respectively. Thus a P-Join would be a PIM Join which is processed by the global PIM instance, and a C-Join would be a PIM Join which is processed by a VPN-specific PIM instance. A P-group address would be a group address in the SP's address space, and a C-group address would be a group address in a VPN's address space. 2.2. Multicast Tunnels Each multicast VRF is assigned to one or more multicast domains. Each such VRF MD is configured with a multicast P-group address. As part of the configuration of the global PIM instance, an RP address (in the address space of the P network) is configured for each such P-group address. (Or the RP addresses may be discovered by any other acceptable procedure, such as PIM Bootstrap messages.) Each MD has a distinct P-group address. For each MD, a "Multicast Tunnel" (MT) is created in the global PIM instance, using ordinary PIM-SM techniques. The various PEs in the MD discover each other by joining the shared tree rooted at the RP. For best scalability, this should be a bidirectional tree [BIDIR]. (Strictly speaking, the scheme works even if the MTs are realized by PIM source trees. However, this could result in large numbers of multicast distribution trees per MD, which would severely reduce the scalability of the scheme.) The MT is used to carry multicast C-packets, both data and control packets, among the PE routers in a common MD. To send a packet through an MT the packet must of course be encapsulated. This could be done either with MPLS or with GRE. If it is done with MPLS, then the "MPLS label distribution via PIM" procedures [MPLS-PIM] must be supported. When a packet is received from an MT, the receiving PE must be able to determine the MT (and hence the MD) from which the packet was received. (In the case of MPLS encapsulation, this will be determined from the incoming MPLS label; penultimate hop popping must not be performed.) The packet is then passed to the corresponding Rosen, et al. [Page 5] Internet Draft draft-rosen-vpn-mcast-00.txt November 2000 Multicast VRF and VPN-specific PIM instance for further processing. 2.3. PIM across the MD If a particular VRF is in a particular MD, the corresponding MT is treated by that VRF's VPN-specific PIM instances as a LAN interface. The PEs which are adjacent on the MT must execute the PIM LAN procedures, including the generation and processing of Assert packets. This allows VPN-specific PIM routes to be extended from site to site, without appearing in the P routers. If a PE in a particular MD transmits a C-multicast data packet to the backbone, by transmitting it through an MD, every other PE in that MD will receive it. Any of those PEs which are not on a C-multicast distribution tree for the packet's C-multicast destination address (as determined by applying ordinary PIM procedures to the corresponding multicast VRF) will have to discard the packet. 2.4. RPF Determination Although the MT is treated as a PIM-enabled interface, unicast routing is NOT run over it, and there are no unicast routing adjacencies over it. If a VRF is in a single MD: - a C-packet received over an MT is considered to pass the RPF check if the IGP next hop to its source address, according to the associated VRF, is not one of the interfaces associated with that VRF; - a C-Join/Prune message from a CE router needs to be forwarded over the MT if the next hop interface to the root of the corresponding multicast tree is not one of the interfaces associated with that VRF. If a VRF is in more than one MD, then the PE must be able to determine which MT is the RPF for a particular C-address. This can be done by means of BGP Extended Community attributes. Each MD can be associated with a BGP Extended Community attribute, into which the MD's group address is encoded. When a unicast VPN-IP address is distributed from a VRF which is in a MD, the address can carry Extended Community attributes which identify the MDs that the VRF belongs to. Then the PE can find the MT which is the RPF for a given address by looking at the Extended Community attributes of the corresponding route. Rosen, et al. [Page 6] Internet Draft draft-rosen-vpn-mcast-00.txt November 2000 The above specifies how to determine the RPF interface. To determine the RPF neighbor for a particular C-address, we need to first determine the BGP next hop for the corresponding VPN-IP address, then verify that the BGP next hop is a PIM neighbor on the RPF interface. 2.5. Avoiding Conflict with Internet Multicast If the SP is providing Internet multicast, distinct from its VPN multicast services, it must ensure that the P-group addresses which correspond to its MDs are distinct from any of the group addresses of the Internet multicasts it supports. This is best done by using administratively scoped addresses [ADMIN-ADDR]. The C-group addresses need not be distinct from either the P-group addresses or the Internet multicast addresses. 2.6. Dense Mode Dense mode multicasts via PIM-DM are easily supported using MDs. The MT is still created using PIM-SM, and the PEs simply use PIM-DM procedures as necessary when transmitting C-data and C-control packets across the MT. Thus an Enterprise which uses dense mode multicasting can use the VPN service without changing its native multicasting techniques. The P routers are not aware of whether the Enterprise is using dense mode or sparse mode. 2.7. Forwarding The P routers will not be able to tell, from the contents of the C- packet as sent from CE to PE, which MT the packet should be sent along. Therefore the packets need to be encapsulated. If MPLS multicast [MPLS-PIM] is supported, then MPLS can be used for the encapsulation. This would require only a single MPLS label. Penultimate hop popping would not be used (otherwise the egress PE could not tell which MD the packet belongs to). Other encapsulations are also possible. For example, one could use a GRE encapsulation, with the MD's P-group address appearing in the IP destination address field. In this case, the SP must filter, at the edges of its network, all non-VPN packets carrying any of these P- group addresses in their destination address fields. If a PIM shared tree (RP-tree) is being used, rather than a bidir tree, and if MPLS encapsulation is being used, then Register packets Rosen, et al. [Page 7] Internet Draft draft-rosen-vpn-mcast-00.txt November 2000 must themselves be encapsulated in GRE before being encapsulated in MPLS. This is necessary in order to carry the MT's P-group address corresponding to the RP. Note that the RP cannot remove the GRE header before forwarding the packet, since the RP has no way of knowing that a particular packet is a tunneled VPN multicast packet, rather than an "ordinary" multicast. As a result, the GRE header would have to be used for all tunneled VPN multicast packets carried within MPLS, even if those packets are sent down a source tree. 2.8. Scalability While this procedure requires the P routers to maintain multicast state, the amount of state is bounded by the number of supported VPNs. The P routers do NOT run any VPN-specific PIM instances. The multicast routing provided by this scheme is not optimal, in that a packet of a particular multicast group may be forwarded to PE routers which have no downstream receivers for that group, and hence which may need to discard the packet. The use of a single bidirectional tree per VPN scales well as the number of transmitters and receivers increases, but not so well as the amount of multicast traffic per VPN increases. 2.9. Increasing the Optimality Suppose that for each MT we create not one, but a number of multicast distribution trees. One of these trees, the default tree, is joined by all PEs in the MD. PIM control messages from the CEs are forwarded along the default tree. However, multicast data messages are mapped to particular distribution trees depending on the source and group addresses that appear in them. The assignment of an (S,G) pair (or, in our terminology, a (C-S, C-G) pair) to a particular distribution tree would be done by the PE which receives the data from a CE (i.e., by the transmitting side), and indicated to the other PEs by a special PIM message sent on the default distribution tree. While every PE in an MD joins the default distribution tree for the corresponding MT, a PE does not join a non-default distribution tree unless it is connected to a VPN site which needs to receive traffic from a group which has been assigned to that tree. If it were known that certain C-groups have receivers at many VPN sites, but others have receivers only at a few VPN sites, the former could be mapped to the default tree, and the latter could be mapped Rosen, et al. [Page 8] Internet Draft draft-rosen-vpn-mcast-00.txt November 2000 to one or more non-default distribution trees. This could significantly reduce the amount of multicast data traffic that gets sent to PEs that do not need to receive it. Another, perhaps more feasible, approach is to keep all the low throughput groups on the default distribution tree, and to distribute the high throughput groups among the other distribution trees. Of course, any scheme like this requires still more state in the P routers, so again presents a trade-off between state and optimality. 2.10. Inter-Provider Considerations If there are multi-provider VPNs which require multicast, then an MD will cross provider boundaries. The multicast group address associated with the MT must then be agreed upon by the providers. [RFC2547bis] describes three methods for creating inter-provider VPNs: 1. VRF-to-VRF connections at the AS border routers. 2. EBGP redistribution of labeled VPN-IP routes from AS to neighboring AS. 3. Multihop EBGP redistribution of labeled VPN-IP routes between source and destination ASes, with EBGP redistribution of labeled IP routes from AS to neighboring AS. The use of MDs for interprovider VPN multicast is compatible with methods 1 and 3, but not with method 2. 3. VPN-IP PIM-SM In this section, we present for completeness sake a solution that, while it provides optimal multicast routing, we must deprecate due to its scalability problems. In this solution, PIM-SM is used to extend an (S,G) or (*,G) multicast distribution tree from a set of customer sites, through the SP backbone, to a set of customer sites. This solution must solve the following basic problems: Rosen, et al. [Page 9] Internet Draft draft-rosen-vpn-mcast-00.txt November 2000 - It extends the multicast routing of a VPN into the backbone, despite the facts that: * the unicast routing of that VPN is NOT extended into the backbone, and * PIM-SM assumes the presence of the unicast routing in order to determine the RPF interface for a multicast distribution tree. - It ensures that multicast routing entries of different VPNs are kept distinct in the backbone, even if the IP addresses corresponding to the respective S and G values of the (S,G) entries are not unique across VPNs. - It ensures that when a PE router receives a PIM Join/Prune message from the backbone, it associates that message with the proper VRF. - It properly handles PIM-SM Bootstrap Messages, which must be flooded along an RPF-tree away from the unicast route to the origin of the message. 3.1. Multicast VRFs Each PE router runs a number of instances of PIM-SM, as many as one per VRF. In each instance of PIM-SM, the PE maintains a PIM adjacency with each of the PIM-capable CE routers associated with that VRF. The multicast routing table created by each instance is specific to the corresponding VRF. Each PE router also runs a "global" instance of PIM-SM, in which it has a PIM adjacency with each of its IGP neighbors. Multicast routing data from a particular VRF is leaked into the global multicast routing table, but the address of the root of each multicast tree is first translated from an IP address to a VPN-IP address. 3.2. Use of VPN-IP addresses in PIM When multicast routing entries are distributed from a VRF to the global routing table, they are modified as follows. Consider an (S,G) entry in a VRF multicast routing table. This entry can only exist if there is a route to S in the corresponding unicast VRF. If there a route to S in the unicast VRF, it will correspond to a VPN-IP route RD:S (where RD is the Route Distinguisher, see [RFC2547bis]). Rosen, et al. [Page 10] Internet Draft draft-rosen-vpn-mcast-00.txt November 2000 So the (S,G) entry in the multicast VRF becomes an (RD:S,G) entry in the global multicast routing table. This distinguishes the multicast distribution tree from any other (S,G) tree which comes from a different VPN. In the case of a shared tree, a (*,G) entry becomes a RD:* entry, where RD is the Route Distinguisher of the VPN-IP address of the tree's RP. P routers have only global multicast routing tables. Join/Prune messages are sent between P routers and between P and PE routers using the PIMv2 address family extensions, which allow the VPN-IP addresses to be encoded. This is specified in ZZZ. In short, if two trees have the same value of G, but are in different VPNS, they are distinguished by means of the RD of the root of the tree. 3.3. Forwarding The contents of the IP header of a multicast packet are insufficient to determine the multicast tree that a particular packet is traveling on. So the packets must be encapsulated while being forwarded through the backbone, where the encapsulation can be used to uniquely associate each packet with an (RD:S,G) or (RD:*,G) entry. This is best done using MPLS multicast labels, and the MPLS label distribution technique specified in [MPLS-PIM]. Whereas unicast VPN packets generally carry two MPLS labels, multicast VPN packets would carry only one. When the egress PE receives a labeled multicast packet from the backbone, the top label tells it which CEs to send the packet to after the label is popped. 3.4. Associating VPN-IP PIM Messages with VRFs How does a PE, when it receives a PIM message from the backbone, associate it with a particular VRF? If the PIM message references a source tree, then the VPN-IP address of the source (RD:S) is in the PIM message. The PE finds the VRF from which the route to RD:s was exported, and associates the PIM message with the (S,G) entry of that VRF. If the PIM message references a shared tree, then the entries in the join and/or prune lists will each have an RD. The PE looks for a (*,G) entry whose RP has that RD. The presence of more than Rosen, et al. [Page 11] Internet Draft draft-rosen-vpn-mcast-00.txt November 2000 one such is considered a configuration error. 3.5. The RPF Hint When a P router receives a PIM Join/Prune message corresponding to a VPN-IP PIM message, it must be able to determine the IGP next hop towards the root of the specified multicast distribution tree. In ordinary PIM, determination of the next hop is easily done, since the IP address of the root of each multicast tree is known, and the backbone routers know the unicast route towards the root of the tree. However, in the case of a BGP/MPLS VPN the root of the multicast distribution tree will be within a VPN, and hence will not have a unique IP address. VPN-IP PIM must therefore use the VPN-IP address of the root of the multicast distribution tree. But the backbone routers do not know unicast routes for VPN-IP addresses. To solve this, the PE router, before sending a PIM Join/Prune message to a backbone router, must insert the address of its BGP next hop towards the root of the tree. Call this the RPF hint. This is generally the address of the PE router which attaches to the site containing the root. Backbone routers always have IGP routes to the PE routers' BGP next hops, and the IGP next hop towards the root of a tree is always the same as the IGP next hop towards the PE router which attaches to the site containing the root. When a P router receives one of these Join/Prune messages, instead of looking up the IGP next hop to the root of the specified multicast distribution tree, it looks up the IGP next hop of the RPF hint. The RPF hint is not an essential part of the identification of the multicast distribution tree. A change in the value of the RPF hint is regarded simply as an RPF change, which changes the shape of the tree, but which does not necessarily require construction of an entirely new tree. 3.6. When a PE Sends a PIM Message to the Backbone A PE router only sends a VPN-IP PIM Join to the backbone if it receives a PIM Join from a CE router. That Join will contain the IP address of the root of a particular multicast distribution tree. The PE looks up the unicast route to this address in the VRF associated with the CE. If this route exists in the VRF as a result of a VPN-IP route's having been imported from BGP, the corresponding VPN-IP route is identified. The VPN-IP address of the root of the tree can then be Rosen, et al. [Page 12] Internet Draft draft-rosen-vpn-mcast-00.txt November 2000 formed by appending its IP address to the RD of that VPN-IP route. This VPN-IP address, rather than the IP address will be placed in the VPN-IP PIM Join List. (This applies in the case where the WC bit and the RPT bit are both 1, as well as the case where they are both 0.) With respect to the (S,G) state maintained by a PE router, the "S" will be a VPN-IP address rather than an IP address. With respect to the (*,G) state maintained by a PE router, the address of the RP corresponding to the (*,G) tree will be maintained as a VPN-IP address. Similarly, if a CE prunes itself from a tree, and as a result the PE must prune itself from the tree, the VPN-IP address of the root of the tree will appear in the Prune List of the VPN-IP PIM Join/Prune message sent to the backbone. (This applies in the case where the WC bit and the RPT bit are both 1, as well a the case where they are both 0.) If a PE must prune a particular source from a (*,G) tree whose input interface leads to the backbone, then the prune list in the VPN-IP PIM Join/Prune message will contain a VPN-IP address whose RD is taken from the VPN-IP address of the (*,G) tree's RP, and whose IP address part is the IP address of the source being pruned. (This applies in the case where the WC bit is 0 and the RPT bit is 1.) When a router receives a VPN-IP PIM Join/Prune message which requests that a VPN-IP source be pruned off a shared tree, it identifies the shared tree by looking for a (*,G) entry with the specified value of G, and whose RP has a VPN-IP address with the specified RD. Note that all the sources transmitting to a particular group MUST have mutually unique source addresses, so it is not necessary to use an RD to identify the source when pruning the source off the shared tree. (Of course it is necessary to use an RD to identify the source when operating on a source tree.) It is however necessary to use an RD to identify the RP that corresponds to the shared tree. Of course, a PE router may receive a PIM Join/Prune from a CE router, and find that the RPF leads to a directly attached CE router, rather than to a PE router. In this case, an "ordinary" PIM Join/Prune message is just sent to the CE router. If multicast is being done by a multi-provider VPN, the VPN-IP PIM messages have to be processed by and forwarded by the BGP border routers. Further, the RPF hint put in the VPN-IP PIM message by the Rosen, et al. [Page 13] Internet Draft draft-rosen-vpn-mcast-00.txt November 2000 ingress PE will be the address of a border router, rather than the address of the egress PE. Thus a border router processing a VPN-IP PIM message has to replace the RPF hint with the address of its own BGP next hop towards the VPN-IP address of the root of the multicast distribution tree which the VPN-IP PIM message references. 3.7. PIM Bootstrap Messages If a particular VPN uses PIM Bootstrap Messages to do auto-discovery of RPs, and the SP is providing VPN multicast service via the VPN-IP PIM scheme, then the bootstrap messages will need to be flooded throughout the backbone. Suppose a PE receives a Bootstrap Message from a CE, and the interface to the CE is the RPF interface to the source of the Bootstrap Message. Then the PE router must flood the Bootstrap Message to all its P router PIM neighbors. However, the PE should first modify the Bootstrap Message as follows: - It should replace the source address with its own address. - The original source address of the Bootstrap Message must be modified to be a VPN-IP address, and placed in a newly defined "origin" field within the Bootstrap Message. The VPN-IP address is formed by using the RD which is used when the route to the origin is exported. We can call these "VPN-IP PIM Bootstrap Messages". P routers that receive VPN-IP PIM Bootstrap Messages must flood them normally, but should not maintain the RP/Group mappings from these messages. When a PE router receives a VPN-IP PIM Bootstrap Message on the RPF interface to the message's source address, then in addition to forwarding it as necessary to other backbone routers, it extracts the origin field, and checks to see if that VPN-IP address (or less specific prefix) has been imported into one or more of its VRFs. If so, it translates the message back into the original PIM Bootstrap Message and forwards it to the CEs associated with those VRFs. Rosen, et al. [Page 14] Internet Draft draft-rosen-vpn-mcast-00.txt November 2000 4. Multicast Domains Using PIM NBMA Techniques In the solution of section 2, the PEs in a common Multicast Domain are attached to a common Multicast Tunnel, which is treated as a LAN-like interface, and which is instantiated as one or more multicast distribution trees. It is possible instead to think of the Multicast Tunnel as an NBMA-like interface. Then one doesn't need to instantiate the tunnel as a multicast distribution tree at all. Rather, C-multicast packets are simply unicast (tunneled) from one PE router to the other PE routers which need to receive those packets. This has the advantages of keeping all multicast routing state out of the P routers, and of not delivering multicast traffic to any PE routers that don't need to receive it. It has the disadvantage of requiring the transmitting PE router to replicate the multicast packets, along with the consequent disadvantage of sending more packets through the core. While multicast routers must always be able to replicate packets, generally the number of replicas that need to be created is bounded by the number of outgoing interfaces; in this case, it would be bounded only by the number of other PE routers containing sites in the same VPN. So the characteristics of this solution seem unfavorable. This solution could be implemented with a two-layer MPLS stack, very similar to the handling of unicast. Each PE router would distribute, via BGP, a list of the Multicast Domains in which it has VRFs, along with an MPLS label for each one. This would enable the PE in a common Multicast Domain to auto-discover each other, as well as providing the bottom label of the two-label MPLS label stack. 5. Intellectual Property Considerations Cisco Systems may seek patent or other intellectual property protection for some of all of the technologies disclosed in this document. If any standards arising from this document are or become protected by one or more patents assigned to Cisco Systems, Cisco intends to disclose those patents and license them on reasonable and non-discriminatory terms. Rosen, et al. [Page 15] Internet Draft draft-rosen-vpn-mcast-00.txt November 2000 6. Acknowledgments The authors wish to thank Tony Speakman and Ted Qian for their help and their ideas. 7. References [ADMIN-ADDR] "Administratively Scoped IP Multicast", Meyer, July 1998, RFC 2365 [BIDIR] "Bi-directional Protocol Independent Multicast", Handley, Kouvelas, and Vicisano, March 2000, <draft-ietf-pim-bidir-00.txt> [MPLS-PIM] "Using PIM to Distribute MPLS Labels for Multicast Routes", Farinacci, Rekhter, Rosen, Qian, July 2000,[PIMv2] "Protocol Independent Multicast - Sparse Mode (PIM-SM)", Fenner, Handley, Holbrook, Kouvelas, July 2000, draft-ietf-pim-sm- v2-new-00.txt [RFC2547bis] "BGP/MPLS VPNs", Rosen, et. al., July 2000, draft- rosen-rfc2547bis-02.txt 8. Authors' Addresses Yiqun Cai Cisco Systems, Inc. 170 Tasman Drive San Jose, CA, 95134 E-mail: ycai@cisco.com Dino Farinacci Procket Networks, Inc. 3850 North First Street SAn Jose, CA, 95134 E-mail: dino@procket.com Yakov Rekhter Cisco Systems, Inc. 170 Tasman Drive San Jose, CA, 95134 E-mail: yakov@cisco.com Eric C. Rosen Cisco Systems, Inc. Rosen, et al. [Page 16] Internet Draft draft-rosen-vpn-mcast-00.txt November 2000 250 Apollo Drive Chelmsford, MA, 01824 E-mail: erosen@cisco.com Dan Tappan Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824 E-mail: tappan@cisco.com IJsbrand Wijnands Cisco Systems, Inc. 170 Tasman Drive San Jose, CA, 95134 E-mail: ice@cisco.com Rosen, et al. [Page 17]