Home / Cisco SP / Introduction to Multicast over VPN or mVPN

Introduction to Multicast over VPN or mVPN

Today I am going to talk about  the one of the topic where we are going to discuss on the scenario of using multicast over the VPN or many of you know this as mVPN. The reason being used the multicast over the VPN is to carry the IP multicast traffic over the MPLS backbone.

The model consisted of having PIM in the MPLS core as the multicast routing protocol, having PIM as the multicast routing protocol in the VPN, between the PE and CE routers and running PIM between the PE routers in the VRF context. The PE routers were directly connected PIM-wise by a Default Multicast Distribution Tree (MDT) formed between the PE routers, per VPN where multicast was enabled. This Default MDT was always there, as soon as it was configured. The PE routers saw each other as PIM neighbors across this Default MDT. 

The Default MDT was nothing else than a multicast tree in the core of the MPLS VPN network. So, there was multicast in the core of the MPLS VPN network and multicast in the multicast-enabled VPN. The IP multicast traffic was forwarded between the PE routers as GRE-encapsulated traffic and not as MPLS traffic!


As a summary, there were two planes of multicast/PIM routing: one, there was the plane in the global context, where multicast routing/PIM was used to build the MDTs between the PE routers where the VRF was multicast-enabled and two, there was the plane in the VRF/VPN context, where multicast routing/PIM was used to build the trees to deliver the customer/VRF multicast traffic across the PE-CE links on the PE routers and forward the customer/VRF multicast traffic between the PE routers in the VRF/VPN context.

Fig 1.1- The core plane and the VPN plane
The request came in to have multicast traffic forwarded across the MPLS core as MPLS encapsulated traffic. This lead to several new solutions with new backbone protocols, replacing multicast/PIM in the core of the MPLS network. These newer protocols to signal multicast MPLS in the core network are mLDP (Multipoint LDP) and Point-to-Multipoint (P2MP) MPLS Traffic Engineering (TE). Also, PIM is no longer the only signaling protocol in overlay, between the PE routers. BGP, but also in-band signaling and no signaling or static mapping, became available. The core signaling protocols mLDP and P2MP TE can also be used to carry multicast traffic in the core in global context, hence there is noVRF/VPN on the edge (PE) routers.

A new kind of tree type in the core was invented. Whereas IP multicast has point-to-multipoint (P2MP) trees, mLDP can also support Multipoint-to-Multipoint (MP2MP) trees. These are trees where multicast traffic can flow bidirectionally, up and down the tree.

These newer backbone signaling protocols and BGP as an overlay signaling protocol lead to the Next Generation (NG) mVPN Deployment Models.

The possible combinations of the different core tree protocols, tree types, overly signaling method and VRF context or global context, lead to several deployment models or profiles. To easily identify them , they have a number, starting with 0 for the oldest mVPN model (Default MDT GRE). The old model was commonly referred to as the Rosen model or Draft Rosen model. Because the Rosen model has been renamed to the Default MDT model, throughout this document, the Default MDT model means the same as the Rosen model.

There was a need to carry multicast traffic over an MPLS backbone in newer ways. This is referred to as the Next Generation mVPN Deployment Models. The main point is that multicast can be encapsulated in MPLS. This is refered to as Label Switched Multicast (LSM). 


For the encapsulating as MPLS packets and the forwarding with MPLS labels, four mechanisms in the core can be used: mLDP, P2MP MPLS Traffic Engineering (TE) and Ingress Replication (IR). The benefits of using MPLS are:
  • sharing the control plane and forwarding plane
  • less protocols to manage in the core (PIM is removed from the core)
  • no need to run IP multicast/PIM in the core
  • Fast Reroute (FRR) is possible to protect the multicast traffic
  • Bandwidth Reservation and source routing is possible with P2MP MPLS TE