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]