Nov 11 2009
MVPN
Overview
An SP determines whether a particular VPN is multicast-enabled. If it is, it corresponds to a “Multicast Domain”. A PE which attaches to a particular multicast-enabled VPN is said to belong to the corresponding Multicast Domain. For each Multicast Domain, there is a default “Multicast Distribution Tree (MDT)” through the backbone, connecting ALL of the PEs that belong to that Multicast Domain. A given PE may be in as many Multicast Domains as there are VPNs attached to that PE. However, each Multicast Domain has its own MDT. The MDTs are created by running PIM in the backbone.
In a departure from the usual multicast tree distribution procedures, the Default MDT for a Multicast Domain is constructed automatically as the PEs in the domain come up. Construction of the Default MDT does not depend on the existence of multicast traffic in the domain; it will exist before any such multicast traffic is seen. Default MDTs correspond to the “MI-PMSIs” of [MVPN-ARCH].
Inclusive and Selective PMSIs
We will distinguish between two different kinds of PMSI(there is a third type of PMSI but I haven’t covered it here):
“Multidirectional Inclusive” PMSI (MI-PMSI) – [Also known as default mdt]: A Multidirectional Inclusive PMSI is one that enables ANY PE attaching to a particular MVPN to transmit a message such that it will be received by EVERY other PE attaching to that MVPN. There is at most one MI-PMSI per MVPN. An MI-PMSI can be thought of as an overlay broadcast network connecting the set of PEs supporting a particular MVPN.
“Selective” PMSI (S-PMSI) [Also known as data mdt]: A Selective PMSI is one that provides a mechanism wherein a particular PE in an MVPN can multicast messages so that they will be received by a subset of the other PEs of that MVPN. There may be an arbitrary number of S-PMSIs per PE per MVPN.
In BGP/IP MPLS VPNs, each CE router is a unicast routing adjacency of a PE router, but CE routers at different sites do NOT become unicast routing adjacencies of each other. This important characteristic is retained for multicast routing — a CE router becomes a PIM adjacency of a PE router, but CE routers at different sites do NOT become PIM adjacencies of each other. Multicast packets from within a VPN are received from a CE router by an ingress PE router. The ingress PE encapsulates the multicast packets and (initially) forwards them along the Default MDT tree to all the PE routers connected to sites of the given VPN. Every PE router attached to a site of the given VPN thus receives all multicast packets from within that VPN. If a particular PE routers is not on the path to any receiver of that multicast group, the PE simply discards that packet.
If a large amount of traffic is being sent to a particular multicast group, but that group does not have receivers at all the VPN sites it can be wasteful to forward that group’s traffic along the Default MDT. Therefore, we also specify a method for establishing individual MDTs for specific multicast groups. We call these “Data MDTs”. A Data MDT delivers VPN data traffic for a particular multicast group only to those PE routers which are on the path to receivers of that multicast group. Using a Data MDT has the benefit of reducing the amount of multicast traffic on the backbone, as well reducing the load on some of the PEs; it has the disadvantage of increasing the amount of state that must be maintained by the P routers. The SP has complete control over this tradeoff. Data MDTs correspond to the S-PMSIs.
Multicast VRFs
The notion of a “VRF”, defined in [RFC4364], is extended to include multicast routing entries as well as unicast routing entries. 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”, or “PIM C-instances”.
Each PE router also runs a “provider-wide” instance of PIM-SM (a “PIM P-instance”), 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). The P routers also run the P-instance of PIM, but do NOT run a C-instance.
In order to help clarify when we are speaking of the PIM P-instance and when we are speaking of a a PIM C-instance, we will also apply the prefixes “P-” and “C-” respectively to control messages, addresses, etc. Thus a P-Join would be a PIM Join which is processed by the PIM P-instance, and a C-Join would be a PIM Join which is processed by a C-instance. A P-group address would be a group address in the SP’s address space, and a C-group address would be group address in a VPN’s address space.
Multicast Domains
Model of Operation
A “Multicast Domain (MD)” is essentially a set of VRFs associated with interfaces that can send multicast traffic to each other. From the standpoint of PIM C-instance, a multicast domain is equivalent to a multi-access interface. The PE routers in a given MD become PIM adjacencies of each other in the PIM C-instance.
Each multicast VRF is assigned to one MD. Each MD is configured with a distinct, multicast P-group address, called the “Default MDT group address”. This address is used to build the Default MDT for the MD.
When a PE router needs to send PIM C-instance control traffic to the other PE routers in the MD, it encapsulates the control traffic, with its own IPv4 address as source IP address and the Default MDT group address as destination IP address. Note that the Default MDT is part of P-instance of PIM, whereas the PEs that communicate over the Default MDT are PIM adjacencies in a C-instance. Within the C-instance, the Default MDT appears to be a multi-access network to which all the PEs are attached.
The Default MDT does not only carry the PIM control traffic of the MD’s PIM C-instance. It also, by default, carries the multicast data traffic of the C-instance. In some cases though, multicast data traffic in a particular MD will be sent on a Data MDT rather than on the Default MDT.
Multicast Tunnels
An MD can be thought of as a set of PE routers connected by a “multicast tunnel (MT)”. From the perspective of a VPN-specific PIM instance, an MT is a single multi-access interface. In the SP network, a single MT is realized as a Default MDT combined with zero or more Data MDTs.
Auto-Discovery
Any of the variants of PIM may be used to set up the Default MDT: PIM-SM, Bidirectional PIM [BIDIR], or PIM-SSM [SSM]. Except in the case of PIM-SSM, the PEs need only know the proper P-group address in order to begin setting up the Default MDTs. The PEs will then discover each others’ addresses by virtue of receiving PIM control traffic, e.g., PIM Hellos, sourced (and encapsulated) by each other. However, in the case of PIM-SSM, the necessary MDTs for an MD cannot be set up until each PE in the MD knows the source address of each of the other PEs in that same MD. This information needs to be auto-discovered.
A new BGP Address Family, MDT-SAFI is defined. The NLRI for this address family consists of an:
- RD
- IPv4 unicast address
- multicast group address
A given PE router in a given MD constructs an NLRI in this family from:
- Its own IPv4 address. If it has several, it uses the one which it will be placing in the IP source address field of multicast packets that it will be sending over the MDT.
- An RD which has been assigned to the MD.
- The P-group address, an IPv4 multicast address which is to be used as the IP destination address field of multicast packets that will be sent over the MDT.
When a PE distributes this NLRI via BGP, it may include a Route Target Extended Communities attribute. This RT must be an “Import RT” [RFC4364] of each VRF in the MD. The ordinary BGP distribution procedures used by [RFC4364] will then ensure that each PE learns the MDT-SAFI “address” of each of the other PEs in the MD, and that the learned MDT-SAFI addresses get associated with the right VRFs.
The encoding of the MDT-SAFI is specified in the following
subsection:
MDT-SAFI
BGP messages in which:-
- AFI=1 and
- SAFI=66
are “MDT-SAFI” messages.
The NLRI format is 8-byte-RD:IPv4-address followed by the MDT group address. i.e. The MP_REACH attribute for this SAFI will contain one or more tuples of the following form :
+——————————-+
| |
| RD:IPv4-address (12 octets) |
| |
+——————————-+
| Group Address (4 octets) |
+——————————-+
The IPv4 address identifies the PE that originated this route, and the RD identifies a VRF in that PE. The group address must be an IPv4 multicast group address, and is used to build the P-tunnels. All PEs attached to a given MVPN must specify the same group-address, even if the group is an SSM group. MDT-SAFI routes do not carry RTs, and the group address is used to associated a received MDT-SAFI route with a VRF.
More detail in MVPN can be found in draft-rosen-vpn-mcast-12.txt