From Rosen to NG-mVPN: Evolving Multicast for Modern Networks

Multicast has always been the go-to technology for delivering content efficiently across service provider networks. From IPTV streams to real-time applications, it allows the same data to reach thousands—or even millions—of users without overwhelming the network. But as traffic volumes explode and applications demand lower latency and higher reliability, the classic multicast model is starting to show its age.

Traditionally, multicast VPNs were built on the Rosen draft, relying heavily on PIM and GRE tunnels. While this worked for early deployments, it quickly became complex and difficult to scale as services like IPTV grew in popularity. More protocols in the core meant more state to maintain, more operational headaches, and limits on how far multicast could really scale.

This is where Next-Generation Multicast VPN (NG mVPN) comes in. By extending the familiar MPLS L3VPN model, NG mVPN brings multicast into the same scalable, BGP-driven framework that engineers already use for unicast. No extra PIM in the core, more efficient use of resources, and better support for traffic engineering and protection—all while keeping operations simpler.

In this article, we’ll explore how NG mVPN works, the role of Multicast Distribution Trees (MDTs), the protocols available for signaling in the core, and how this model compares to the classic multicast VPN architecture. If you’ve ever struggled with scaling multicast services, NG mVPN might be the solution your network has been waiting for.

For unicast traffic, the MPLS L3VPN solution is well defined in RFCs 2547 and 4364. The Next-Generation Multicast VPN (NG MVPN) extends this model by providing an integrated MPLS L3VPN service that supports both unicast and multicast traffic, incorporating the following features:

• Single encapsulation technology
• Shared data and control planes
• Advanced Traffic Engineering (TE) capabilities
• Fast restoration (FR) and protection mechanisms
• No need to include additional protocols in the core (no PIM)
• Isolates core devices from customer multicast state data

The following sections introduce the basic concepts of Multicast Distribution Trees (MDTs) in the core, the protocols used for their construction, and the key differences between Classic and NG mVPN models to consider when designing a multicast solution.

Building the Highways for Multicast Traffic: Multicast Distribution Trees (MDTs)

This section analyzes Multicast Distribution Trees (MDTs), which serve as distribution structures interconnecting the Service Provider’s PE devices within the network core.twork core.

MDTs carry encapsulated customer multicast traffic across the core, between ingress and egress PEs that share at least one mVPN. MDTs are categorized into two main types:

• Inclusive Trees: One MDT per mVPN. All traffic from a given source is forwarded along the same tree to all egress PEs, regardless of whether they have interested receivers.
• Selective Trees: One MDT per mVPN per source. A separate MDT is built for each source in the mVPN, delivering traffic only to relevant egress PEs.

Selective Trees are more efficient, as Inclusive Trees may deliver unnecessary traffic to PEs without interested receivers. When underlay aggregation is supported, two additional types of aggregated trees may be used:

• Aggregate Inclusive Tree: A single MDT shared by all multicast groups across multiple mVPNs.
• Aggregate Selective Tree: A single MDT shared by multicast groups from different mVPNs.

The relationship between the three most common MDT classes in the core and their corresponding multicast tree types is shown in the following table.

Multicast Distribution Trees (MDTs) define how multicast traffic flows across the service provider core, and each type offers different trade-offs between efficiency and complexity. The Default MDT is always-on, bidirectional, and connects all Provider Edge (PE) devices within a multicast VPN. While it ensures connectivity, it also delivers unnecessary traffic to PEs without interested receivers, making it inefficient for large deployments. The Data MDT addresses this by building on-demand, unidirectional trees for specific sources, sending traffic only to the PEs that need it—greatly improving efficiency. The Partitioned MDT goes a step further, allowing more granular subsets of PEs to be connected in both directions, striking a balance between flexibility and optimization.

From an operational perspective, Default MDTs are simple but bandwidth-hungry, while Data and Partitioned MDTs reduce wasted traffic and improve scalability at the cost of additional signaling complexity. Choosing the right MDT type is key when designing NG mVPN solutions for efficiency and scale.

How Do We Build the Trees? Protocols That Power Multicast in the Core

A wide variety of protocols are available for signaling Multicast Distribution Trees (MDTs). The choice of protocol depends on business requirements and design constraints, such as available resources and scalability needs.

The main protocols used for MDT signaling and construction in the core (underlay) are PIM, mLDP, P2MP TE, and Ingress Replication (IR):

• PIM (Protocol Independent Multicast) is used when the MDT structure does not require modifications. It is the same signaling protocol used for Source Trees, Shared Trees, and Bidirectional Trees. Different PIM modes offer trade-offs between state and efficiency:

• PIM SSM (Source-Specific Multicast) builds optimal trees but requires more state in the network.

• PIM BiDir (Bidirectional PIM) reduces state requirements but may result in suboptimal paths.
• In PIM-based deployments, multicast replication is performed by routers in the core.

• mLDP (Multipoint Label Distribution Protocol) extends LDP to support multicast. It is typically used when link protection mechanisms are required in the core (e.g., MPLS TE or FRR). It supports both P2MP (Point-to-Multipoint) and MP2MP (Multipoint-to-Multipoint) tree types.

• P2MP TE (Point-to-Multipoint Traffic Engineering) leverages RSVP-TE and IGP extensions to build explicit P2MP trees in the data plane. It is ideal for scenarios that require bandwidth reservation, traffic engineering, or built-in link protection.

• Ingress Replication (IR) reuses existing unicast LSPs in the core. It is best suited for simple topologies, low-traffic multicast environments, or inter-AS scenarios. In this model, replication occurs at the ingress PE, which can limit scalability due to increased replication load at the edge.

The choice of protocol to signal Multicast Distribution Trees (MDTs) in the provider core depends on scalability, complexity, and service requirements. PIM with GRE encapsulation is the legacy option but quickly becomes complex at scale. mLDP is widely deployed today, offering MPLS-based multicast with support for protection and traffic engineering, though it introduces higher state in the core. P2MP TE provides the most control with bandwidth guarantees and explicit routing, but at the cost of high operational complexity. Ingress Replication (IR) is the simplest to deploy, relying on unicast tunnels, but places replication load on the edge and is best suited for smaller multicast scenarios or inter-AS designs.

Classic vs. Next-Gen mVPN: Two Very Different Roads to Multicast

There are two primary deployment models for multicast VPNs (mVPN): Classic mVPN and Next-Generation mVPN (NG mVPN).

• Classic mVPN (PIM/GRE) is based on the Rosen draft and relies on the PIM protocol in the provider core to support multicast traffic. It introduces additional complexity by requiring both PIM and mGRE encapsulation in the control and data planes. This model is less flexible and has limited scalability.
• NG mVPN (BGP/MPLS) extends the unicast MPLS Layer 3 VPN model (as defined in RFC 2547 and RFC 4364) to support multicast traffic. It preserves the scalability and flexibility of unicast VPNs, while integrating multicast support using BGP-based signaling and more efficient transport mechanisms.

The comparison between Classic and Next-Generation mVPN highlights why most operators are moving toward the new model. Classic mVPN, based on PIM and GRE, only supports multicast services, requires multiple overlays, and adds complexity in both control and data planes. It also lacks advanced capabilities such as bandwidth reservation and fast reroute, limiting its scalability for modern applications. NG mVPN, on the other hand, unifies unicast and multicast services under the MPLS L3VPN model. By using BGP for signaling and MPLS-based transport options like mLDP, P2MP TE, or Ingress Replication, it simplifies operations, reduces core state, and supports features like traffic engineering, protection, and partitioned multicast trees. This makes NG mVPN the scalable and future-proof choice for service providers delivering IPTV and other high-demand multicast services.

The Old Guard: Why Classic mVPN Struggles at Scale

In the Classic mVPN model, a separate PIM instance is established per mVPN between Provider Edge (PE) devices. This results in multiple control planes, numerous links, and multiple adjacencies per device. As the number of mVPNs grows, control-plane traffic generated by PIM increases significantly, limiting the solution’s scalability.

Additionally, the underlay also relies on PIM to configure multipoint GRE (mGRE) tunnels between PEs, tightly coupling the data and control planes and further reducing flexibility.

The Next-Generation Approach: BGP and MPLS Transforming Multicast

The Next-Generation mVPN model extends the unicast MPLS Layer 3 VPN architecture to support multicast. It employs an aggregated routing approach, where a single BGP instance handles routing for all mVPNs, improving scalability and operational simplicity.

Unlike PIM, BGP uses event-driven updates rather than periodic timers, resulting in a more stable control plane with only one adjacency per PE–Route Reflector (RR) pair. The data plane supports multiple transport options—mLDP, P2MP TE, and Ingress Replication (IR)—which allow separation of control and data planes and enable traffic aggregation.

NG mVPN also supports advanced multicast features, including:

• Auto-Discovery (AD)
• Automatic Tunnel Binding (ATB) These features are available via the multicast BGP Address Families (mVPNv4 / mVPNv6).

Taking Multicast Beyond Borders: Inter-AS mVPN Made Simple

Classic mVPN makes inter-AS integration complex, requiring direct PIM control–plane exchange and mGRE tunnels across SPs, emulating a LAN. NG mVPN, however, supports flexible inter-AS integration with varied tunneling and segmented trees, allows BGP/MPLS–based path selection, and doesn’t require PEs to appear directly connected.

Inter-AS integration is particularly complex in the Classic mVPN model. It requires direct PIM control-plane exchange and the use of mGRE tunnels across Service Provider boundaries, effectively emulating a shared LAN environment. This approach increases operational overhead and limits flexibility.

In contrast, NG mVPN supports more flexible and scalable inter-AS integration. It allows:

• Segmented or stitched multicast trees across AS boundaries
• BGP/MPLS-based path selection
• Decoupling of PE connectivity (PEs do not need to appear directly connected)

This design makes NG mVPN a better fit for modern, multi-provider environments.

Why NG mVPN Is Built for the Future

Multicast has come a long way from the early Rosen draft and PIM-based deployments. While Classic mVPN provided a functional start, its reliance on PIM in the core, mGRE tunnels, and multiple control planes makes it heavy, complex, and difficult to scale in today’s high-demand environments. Engineers know this pain well—growing state, operational overhead, and limited flexibility.

NG mVPN changes the game by aligning multicast with the proven MPLS L3VPN model. With BGP as the control plane and transport options like mLDP, P2MP TE, and Ingress Replication, it delivers scalability, simplicity, and advanced capabilities such as fast reroute, traffic engineering, and efficient inter-AS integration. Even better, it removes the need for PIM in the core, reducing state and making operations far more predictable.

Author: George Vela

Telecommunications engineer with solid experience in the implementation of telecommunications projects, working in the Latin American region. Specialized in Network, Cloud and Security technologies for Service Provider and Enterprise environments. Experience in design, implementation, O&M and troubleshooting in complex IP networks