The transition to IP-based workflows has brought greater flexibility and scalability, particularly with the adoption of the SMPTE ST-2110 standard. The IT industry has for decades used virtualisation – which allows multiple virtual machines (VMs) to run on a single physical server – enhancing flexibility and scalability, allowing broadcasters to optimise their resource usage and efficiently scale operations. More recently containerisation has provided similar flexibility, without the complexity of VMs.
So logically, one would assume that combining the strengths of SMPTE 2110 and virtualisation would multiply flexibility, scalability, and resource efficiency.
However, virtualising 2110 streams is not easy – especially in multi-vendor environments. In this article, we’ll explore why that is and what the possible solutions are.
Understanding 2110 versus SDI Implementations
The traditional SDI (Serial Digital Interface) approach allowed a single device to have multiple SDI receivers. If a receiver needed to receive multiple copies of the same signal, it can, as they are separate electrical signals. Usually this is done with an SDI router, replicating the signal electrically.
In ST-2110 implementations, facilities instead use IP multicast technology, with a network switch replicating packets in order to copy the same stream to any subscribing devices. Unfortunately a limitation of multicast is that a receiving device can only receive a single copy of a multicast stream, even if that multicast stream is requested by multiple VMs/containers on a device.
The Challenges of Virtualisation
In a virtualised environment, a single device may run multiple virtual machines or containers from different vendors. But, as we saw above, there is only one copy of the stream available per device. This means that something has to replicate the stream on the device. The challenge then becomes: how and where do you replicate the packets if multiple VMs/containers needed to access the same multicast stream?
Options for Packet Replication
To address the replication challenge, three options have emerged. Let’s examine these options along with their advantages and drawbacks.
Option 1: VLAN-Based Replication
One approach is to use VLANs (Virtual Local Area Networks) for stream replication. With careful network and system design it is possible to put each VM/container on a different VLAN. It is then possible to route traffic between different VLANs. In the process of routing between VLANs, packets are replicated. VMs/containers receive individual copies of the same stream from the network. However, it requires a complex and difficult to manage network infrastructure.
Option 2: eSwitch on the Network Card
A second option involves using an eSwitch (embedded switch) that runs on most modern Network Interface Cards (NICs). One flow is sent to the NIC, which then replicates to however many VMs need it. Because replication is performed directly in the NIC, this method can enhance performance by reducing CPU load. However, it comes with a significant downside: vendor lock-in. The two main NIC vendors have solutions for this, NVIDIA Holoscan and Intel Tiber. However, this forces broadcasters to use a single vendor for NICs. For application developers, the challenge is that these are huge monolithic ecosystems and require using all sorts of other features in the ecosystem (e.g vendor specific kernel bypass technology) that they may not want or need.
There is unfortunately a lack of a standardised approach for configuring eSwitches across different vendors. Ideally there would be a simple method for a VM/container to issue an IGMP join and the host program the eSwitch accordingly.
Option 3: vSwitch for Packet Replication
The third option is to use a virtual switch (vSwitch) for packet replication, which operates at the software level. While this approach is common in IT environments, it poses significant challenges in broadcasting due to the high packet rates involved and the demands of a 24/7, 365 workload. The sheer volume of data, combined with low throughput, leads to high CPU usage, making it costly for the CPU to manage such extensive replication. Furthermore, the reliance on software-based processing can result in packet reordering, which is detrimental in broadcasting applications where the integrity and timing of the media stream are critical. These factors make this option unviable for professional broadcasting applications.
Evaluating the Options
So, which option is best?
Each option has its own limitations:
- Option 1, VLAN-based replication is complicated and often impractical, requiring extensive network redesign.
- Option 2, eSwitch on the Network Card, is the most viable, although the downside is it currently locks end-users into a specific vendor ecosystem.
- Option 3, vSwitch for packet replication, though appealing in theory, fails to meet the demands of high-bandwidth, 24/7 broadcasting environments.
Virtualising 2110 Streams: No Easy Task
While workarounds do exist, virtualising 2110 streams remains a challenge. The only viable solution is to run an eSwitch in a NIC – which today means being locked-in to a single vendor’s hardware and software. Ideally, there would be a vendor neutral solution for configuring eSwitches to perform packet replication.
Note, there is another similar issue we haven’t explored. How does a VM/container consume a stream created by another VM/container on the same host. The challenges are similar.
We have led the way for nearly a decade in high-performance, software based Uncompressed IP technology. Recently we released 100Gigabit support in our low-latency encoders and decoders. Learn more about how our low-latency encoders and decoders:
