Network Working Group                                      Eric C. Rosen
Internet Draft                                                 Yiqun Cai
Expiration Date: October 2003                                 Dan Tappan
                                                       IJsbrand Wijnands
                                                     Cisco Systems, Inc.

                                                           Yakov Rekhter
                                                  Juniper Networks, Inc.

                                                          Dino Farinacci
                                                  Procket Networks, Inc.

                                                              April 2003


                       Multicast in MPLS/BGP VPNs


                      draft-rosen-vpn-mcast-05.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



Rosen, et al.                                                   [Page 1]


Internet Draft        draft-rosen-vpn-mcast-05.txt            April 2003


   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
   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  ...............  16
    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



Rosen, et al.                                                   [Page 2]


Internet Draft        draft-rosen-vpn-mcast-05.txt            April 2003


   presupposed.

   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



Rosen, et al.                                                   [Page 3]


Internet Draft        draft-rosen-vpn-mcast-05.txt            April 2003


   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
   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".



Rosen, et al.                                                   [Page 4]


Internet Draft        draft-rosen-vpn-mcast-05.txt            April 2003


   Each PE router also runs a "provider-wide" instance of PIM-SM, in
   which it 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 speaking of the provider-wide
   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 provider-wide 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 provider-wide 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 provider-wide 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



Rosen, et al.                                                   [Page 5]


Internet Draft        draft-rosen-vpn-mcast-05.txt            April 2003


   not be performed.)  The packet is then passed to the corresponding
   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



Rosen, et al.                                                   [Page 6]


Internet Draft        draft-rosen-vpn-mcast-05.txt            April 2003


   corresponding route.

   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.




Rosen, et al.                                                   [Page 7]


Internet Draft        draft-rosen-vpn-mcast-05.txt            April 2003


   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
   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



Rosen, et al.                                                   [Page 8]


Internet Draft        draft-rosen-vpn-mcast-05.txt            April 2003


   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
   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-05.txt            April 2003


     - 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 "provider-wide" 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
   provider-wide 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
   provider-wide 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-05.txt            April 2003


   So the (S,G) entry in the multicast VRF becomes an (RD:S,G) entry in
   the provider-wide 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 provider-wide 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.

   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-05.txt            April 2003


   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-05.txt            April 2003


   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-05.txt            April 2003


   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-05.txt            April 2003


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.






















Rosen, et al.                                                  [Page 15]


Internet Draft        draft-rosen-vpn-mcast-05.txt            April 2003


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.


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, Speakman, Vicisano, June 2002, <draft-ietf-pim-bidir-
   04.txt>

   [MPLS-PIM] "Using PIM to Distribute MPLS Labels for Multicast
   Routes", Farinacci, Rekhter, Rosen, Qian, November 2000, <draft-
   farinacci-mpls-multicast-03.txt>

   [PIMv2]  "Protocol Independent Multicast - Sparse Mode (PIM-SM)",
   Fenner, Handley, Holbrook, Kouvelas, December 2002, draft-ietf-pim-
   sm-v2-new-06.txt

   [RFC2547bis] "BGP/MPLS VPNs", Rosen, et. al., November 2002, draft-
   ietf-ppvpn-rfc2547bis-03.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



Rosen, et al.                                                  [Page 16]


Internet Draft        draft-rosen-vpn-mcast-05.txt            April 2003


   SAn Jose, CA, 95134
   E-mail: dino@procket.com

   Yakov Rekhter
   Juniper Networks
   1194 N. Mathilda Avenue
   Sunnyvale, CA 94089
   E-mail: yakov@juniper.net

   Eric C. Rosen
   Cisco Systems, Inc.
   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]