4. Scaling Multicast with Layer 3 Routing

Increasing the Scale of Operations

As media networks increase in size, bandwidth and operational complexity, the operational considerations associated with large Layer 2 domains also increase. Broadcast facilities may contain:

• Hundreds or thousands of multicast streams
• Large numbers of endpoints
• Multiple equipment rooms and studios
• Distributed production environments
• Virtualised processing platforms
• Stringent resilience requirements

As a result, many organisations have adopted routed Layer 3 multicast architectures for their Streaming Media networks. Rather than extending large Layer 2 domains across multiple switches, routed multicast introduces Layer 3 boundaries throughout the fabric. This changes how multicast traffic is forwarded and provides several advantages in terms of scalability, fault isolation and operational visibility.

This chapter examines how routed multicast architectures operate and explains why they form the foundation of the LVN-AIS and LVN-MIS Streaming Media designs.

From Layer 2 to Layer 3 Multicast

In a Layer 2 multicast environment:

• Endpoints share VLANs that may span multiple switches
• IGMP Snooping controls multicast distribution
• Multicast forwarding occurs within Layer 2 domains

In a routed multicast environment:

• Media endpoints are connected to routed interfaces, typically configured with /30 IP addresses (explained in next chapter)
  • Each endpoint resides within its own Layer 3 network
• Switches participate in unicast and multicast routing
• Multicast traffic is forwarded between Layer 3 boundaries

This represents a fundamental shift in how multicast is forwarded throughout the Streaming Media networks. In a Layer 2 network, the question is:

In a routed multicast network, the question becomes:

That seemingly small change fundamentally alters how multicast forwarding state is built and maintained.

Layer 3 Spine-Leaf Basics

Layer 3 Spine-Leaf architectures retain the familiar Spine-Leaf topology used throughout the LVN portfolio. However, the forwarding model changes significantly. Each Leaf switch connects to every Spine switch (in its fabric) using Layer 3 routed interfaces. Endpoints are also connected to each switch using Layer 3 routed interfaces, and each switch uplink and media endpoint interface typically resides within its own dedicated subnet.

One important difference is that Layer 3 boundaries now exist throughout the fabric. Rather than extending large VLANs between switches, every routed interface forms a separate network. Multicast traffic therefore passes through multiple routing decisions as it traverses the network.  This provides:

• Smaller failure domains
• More predictable forwarding paths
• Reduced dependence on large Layer 2 domains
• Improved operational visibility

In a Layer 3 Spine-Leaf design:

• Endpoints connect to routed interfaces which act as gateways towards the rest of each Streaming Media fabric
• VLAN extension between switches is minimised or eliminated
• Spine and Leaf switches participate in routing
• Failure domains are reduced
• Traffic paths become more predictable

The result is a fabric that behaves less like a traditional Ethernet switching environment and more like a distributed routing system.

Dynamic Unicast Routing

As Layer 3 multicast architectures contain many routed interfaces, manually configuring static routes quickly becomes impractical. Instead, switches exchange reachability information using dynamic routing protocols. Common examples include:

• BGP
• OSPF

These protocols allow switches to learn:

• Which networks exist in each fabric (e.g. Broadcast Control, Streaming Media, PTP etc.)
• Which paths are available
• How traffic should be forwarded
• How alternative paths should be used during failures

Dynamic routing enables media fabrics to grow while maintaining operational simplicity.

Multicast Routing with PIM

The first step towards building a routed multicast network is to enable IP multicast routing. This configures a switch to act as a multicast router. It enables features such as:

• PIM (Sparse Mode, SSM etc.)
• Multicast routing table (mroute)
• Reverse Path Forwarding (RPF)
• Forwarding multicast traffic between VLANs/subnets
• Registering with Rendezvous Points (Sparse Mode)

In routed multicast networks, IGMP remains responsible for signalling receiver interest in multicast streams. However, multicast forwarding between Layer 3 networks requires an additional mechanism. This mechanism is typically Protocol Independent Multicast – Sparse Mode (PIM-SM). PIM-SM allows multicast traffic to be routed efficiently throughout the fabric. At a high level:

• A receiver joins a multicast group using IGMP
• The local Leaf switch learns the receiver’s interest
• PIM builds multicast forwarding state
• The multicast stream is forwarded only where required

Unlike IGMP, which operates only between receivers and their first-hop switch, PIM messages are exchanged between switches configured as multicast routers throughout the routed fabric. As receivers join multicast groups, neighbouring routers exchange PIM messages, progressively extending the multicast distribution tree back towards the sender.

In contrast to Layer 2 multicast forwarding, multicast distribution is now based upon information in a switch's routing table rather than VLAN membership and MAC address tables. PIM-SM is required on any Layer 3 routed switch interface which is required to participate in routing multicast traffic, therefore; PIM-SM is typically configured on each Streaming Media switch uplink and media endpoint interface.

The Journey of a Multicast Stream

Step 1 - A Receiver Requests a Stream

Consider an operator routing a signal from sender connected to a Spine switch to a receiver connected to a Leaf switch using VSM. The receiver knows (via retrieving the SDP data from the sender) the:

• Multicast Group
• Unicast source IP address of the sender

The receiver sends an IGMP Membership Report (join) message to the Leaf switch.

Step 2 - The Leaf Switch Learns the Receiver

The Leaf switch processes the IGMP Membership Report. It now knows, for example:

At this point:

• IGMP creates a forwarding entry
• The Leaf switch knows the receiver exists
• However, the stream may not exist on the switch yet

The Leaf switch therefore asks:

This is where multicast routing begins.

Step 3 - Building Multicast Distribution Trees

Rather than forwarding multicast blindly, the Leaf switch builds a multicast distribution tree through the routed network. This process is handled by: PIM-SM. PIM does not discover receivers as IGMP already did that - instead, PIM uses the unicast routing table information to build the network path that allows multicast traffic to reach those receivers.

One of the primary responsibilities of PIM is to construct a multicast distribution tree through the routed network. Unlike unicast routing, where a separate packet is forwarded towards each destination, multicast routing builds a shared forwarding structure that allows a single stream to be replicated only where necessary. Initially, a multicast stream exists only at the sender. As receivers join the multicast group, PIM progressively extends the distribution tree towards those receivers. As additional receivers join the same multicast group, the existing tree is reused wherever possible before branching only when traffic needs to follow different network paths.

This allows a single multicast stream to efficiently reach many receivers without transmitting multiple copies across the network.

Multicast Service Models

While PIM-SM describes the multicast routing protocol behaviour, there are two additional concepts that describe the multicast service model:

• Any Source Multicast
• Source Specific Multicast

The fundamental difference in each model is based on what information receivers provide when requesting to join a multicast group.

Any Source Multicast (ASM)

PIM-ASM was designed for environments where multiple devices may transmit to the same multicast group.

• A receiver requests a multicast group (G)
• The network forwards the request to a Rendezvous Point (RP)
• The RP receives registrations from multicast sources and join requests from receivers, allowing it to connect the two
• The receiver initially receives traffic via the RP and may later switch to a direct shortest-path tree (SPT)

Rendezvous Point (RP)

A Rendezvous Point is a switch in a fabric that acts as the meeting place for multicast sources and multicast receivers. It can be thought of as a multicast directory service:

• Senders tell the RP, “I’m sending multicast group 239.1.1.1.”
• Receivers tell the RP, “I’d like to receive multicast group 239.1.1.1.”

The RP acts as the place where senders and receivers 'meet' and traffic can be forwarded between them. In conventional PIM-SM Any Source Multicast, the RP provides the rendezvous mechanism that allows receivers and sources to find one another.

Source Specific Multicast (PIM-SSM)

PIM-SSM assumes that the receiver already knows both:

• The multicast group
• The source IP

Rather than joining only a group, receivers join a specific (Source, Group) pair.  Switches immediately build the shortest path directly back to that source. No RP is involved as PIM-SSM relies on IGMPv3 because receivers must specify the desired source.

Broadcast controllers such as Lawo VSM already know both the multicast group and the source IP address associated with every media flow. This makes Source Specific Multicast (PIM-SSM) particularly well suited to modern ST 2110 facilities, as receivers can request streams directly from the desired sender without relying on a Rendezvous Point.

Why Does PIM-SSM Require IGMPv3?

One important difference between the two multicast service models is the information that receivers provide when requesting a stream. With IGMPv2, a receiver can request only a multicast group. For example:

The receiver cannot identify which device should be sending that multicast group. As a result, the network must discover the source using a Rendezvous Point (RP), making IGMPv2 suitable for Any Source Multicast (ASM).

IGMPv3 extends this behaviour by allowing receivers to specify both the multicast group and the sender’s IP address. For example:

This additional source information allows the network to build a multicast distribution tree directly towards the required sender, eliminating the need for a Rendezvous Point. This is the foundation of Source Specific Multicast (SSM). Because ST 2110 broadcast controllers already know both the sender IP address and multicast group for every media flow, IGMPv3 and PIM-SSM are a natural combination for modern broadcast facilities.

Reverse Path Forwarding (RPF)

One of the key concepts within routed multicast architectures is Reverse Path Forwarding (RPF). Unlike unicast, multicast packets are replicated and sent to multiple destinations. Without a loop prevention mechanism, packets could circulate forever. RPF ensures:

• No multicast loops are created
• One accepted path back to the source
• Efficient multicast forwarding

When a multicast packet is received on a switch interface, the switch asks:

If the answer is yes:

• The packet arrived from the correct path and is accepted

If the answer is no:

• The packet must have taken an unexpected path and is discarded

RPF prevents multicast loops and ensures multicast traffic follows predictable paths through the network. This contributes significantly to network stability.

RPF Interfaces

An RPF interface is: the interface a router would use to reach the multicast source according to its unicast routing table.

Determining an RPF Interface

The switch checks its routing information, typically in this order:

1. Multicast Routing Information Base (MRIB) (if present)
2. Otherwise the Unicast Routing Information Base (RIB)

For example:

show ip mroute 239.1.1.1

239.1.1.1
  10.6.128.18, 20:26:52, flags: SLP
    Incoming interface: Ethernet1
    RPF route: [U] 10.6.128.16/30 [0/0]
    Outgoing interface list:
      Ethernet2

Therefore, the RPF interface or IIF is interface Ethernet1. Multicast packets are only accepted if they come from the direction of the sender. The RPF interface is the interface that points toward the sender, as determined by the switches routing table.

RPF Summary

Multicast State Throughout the Fabric

One of the major advantages of routed multicast is that every switch builds its own multicast forwarding state. Rather than maintaining only IGMP Snooping Groups, switches also maintain:

• Unicast Routing Table
• Multicast Routing Table (mroute)
• Multicast Forwarding Information Base (MFIB)
• RPF information
• PIM neighbours

Reduced Failure Domains

One of the most significant advantages of routed Layer 3 architectures is the reduction in network failure domains. In a Layer 2 network, every device within a VLAN shares the same broadcast and multicast domain. Although technologies such as IGMP Snooping help constrain multicast forwarding, the underlying Layer 2 domain still spans every switch carrying that VLAN. As the network grows, so too does the number of devices that may be affected by a configuration error, software fault or unexpected multicast behaviour.

In contrast, a Layer 3 architecture introduces routing boundaries throughout the network. Each media endpoint is connected to its own routed subnet, and multicast traffic is forwarded only after explicit routing decisions have been made. This naturally limits the scope of many network events to a much smaller portion of the overall infrastructure.

Layer 2 Failure Domain

Consider a Layer 2 media network where a Streaming Media VLAN spans multiple Leaf switches.

If a multicast forwarding issue occurs within this VLAN—for example:

• An incorrect IGMP configuration
• Excessive unknown multicast flooding
• Misconfigured mrouter port
• A software defect affecting multicast forwarding

The impact may extend across every switch participating in that Layer 2 domain. Although the fault may originate at a single location, the shared nature of the VLAN allows its effects to propagate much further. This large area of potential impact is commonly referred to as the failure domain or blast radius.

Layer 3 Failure Domain

In a routed architecture, each endpoint resides within its own Layer 3 subnet and multicast forwarding occurs between routing boundaries rather than across a shared Layer 2 domain.

If a fault occurs—for example:

• A misconfigured endpoint
• An incorrect multicast route
• Loss of a routed interface
• Failure of a single Leaf switch

The impact is typically limited to the affected subnet or routing path. The remainder of the routed fabric continues forwarding traffic independently. Rather than one large shared failure domain, the network becomes divided into many small, isolated routing domains.

The Benefits Matter

Reducing the failure domain provides several practical advantages for broadcast operations.

• Faults are easier to isolate and troubleshoot.
• Configuration changes affect fewer devices.
• Maintenance activities carry lower operational risk.
• Routing protocols automatically reconverge around many network failures.
• Problems are less likely to propagate throughout the entire media network.

These characteristics become increasingly important as facilities expand to support hundreds of endpoints and thousands of simultaneous media flows. For this reason, reducing the network blast radius has become one of the defining design principles of modern routed media networks and is a key reason why the LVN-AIS and LVN-MIS Streaming Media architectures adopt Layer 3 multicast as their default forwarding model.

Improved Operational Visibility

One of the most significant advantages of routed multicast architectures is visibility. When troubleshooting a missing ST 2110 flow, engineers can determine:

• Whether the receiver successfully joined the multicast group
• Whether PIM successfully built the multicast distribution tree
• Whether Reverse Path Forwarding checks are succeeding
• Whether multicast packets are reaching each switch along the path

This level of visibility is considerably more difficult to achieve in large Layer 2 multicast domains. This information can also be used to inform monitoring dashboards, making multicast health and forwarding behaviour more visible during normal operations and fault conditions.

Why LVNs Use Routed Multicast

Routed multicast does not replace IGMP; rather, it builds upon it. IGMP remains responsible for signalling receiver interest in multicast groups, while PIM, dynamic routing and Reverse Path Forwarding work together to distribute multicast traffic efficiently throughout the routed fabric. This combination provides the scalability, resilience and operational visibility required by modern ST 2110 facilities and forms the architectural foundation of the LVN-AIS and LVN-MIS Streaming Media designs.

The LVN-AIS and LVN-MIS architectures deliberately adopt routed multicast as their default forwarding model. This decision is not based on the assumption that Layer 2 multicast is inherently unsuitable, but rather on the operational advantages that routed architectures provide as facilities increase in scale. Smaller failure domains, deterministic forwarding, improved troubleshooting and richer operational visibility all contribute to more resilient and maintainable Streaming Media networks.

Preparing for Software-Defined Networking

Routed multicast architectures address many of the challenges associated with large Layer 2 deployments. However, they also introduce their own operational considerations:

• Additional routing protocols
• Increased configuration complexity
• Larger routing tables
• Greater dependence on network expertise

As facilities continue to scale, some organisations seek further simplification through Software Defined Networking (SDN). Rather than relying solely on distributed multicast control protocols, SDN introduces centralised awareness and control of multicast state.

In the next chapter, the guide explains why modern routed media networks commonly use /30 and /31 subnets for endpoint and switch-to-switch connections.

Continue to Chapter 5