Video: Proper Network Designs and Considerations for SMPTE ST-2110

Networks from SMPTE ST 2110 systems can be fairly simple, but the simplicity achieved hides a whole heap of careful considerations. By asking the right questions at the outset, a flexible, scalable network can be built with relative ease.

“No two networks are the same” cautions Robert Welch from Arista as he introduces the questions he asks at the beginning of the designs for a network to carry professional media such as uncompressed audio and video. His thinking focusses on the network interfaces (NICs) of the devices: How many are there? Which receive PTP? Which are for management and how do you want out-of-band/ILO access managed? All of these answers then feed into the workflows that are needed influencing how the rest of the network is created. The philosophy is to work backwards from the end-nodes that receive the network traffic.

Robert then shows how these answers influence the different networks at play. For resilience, it’s common to have two separate networks at work sending the same media to each end node. Each node then uses ST 2022-7 to find the packets it needs from both networks. This isn’t always possible as there are some devices which only have one interface or simply don’t have -7 support. Sometimes equipment has two management interfaces, so that can feed into the network design.

PTP is an essential service for professional media networks, so Robert discusses some aspects of implementation. When you have two networks delivering the same media simultaneously, they will both need PTP. For resilience, a network should operate with at least two Grand Masters – and usually, two is the best number. Ideally, your two media networks will have no connection between them except for PTP whereby the amber network can benefit from the PTP from the blue network’s grandmaster. Robert explains how to make this link a pure PTP-only link, stopping it from leaking other information between networks.

Multicast is a vital technology for 2110 media production, so Robert looks at its incarnation at both layer 2 and layer 3. With layer 2, multicast is handled using multicast MAC addresses. It works well with snooping and a querier except when it comes to scaling up to a large network or when using a number of switches. Robert explains that this because all multicast traffic needs to be sent through the rendez-vous point. If you would like more detail on this, check out Arista’s Gerard Phillips’ talk on network architecture.

Looking at JT-NM TR-1001, the guidelines outlining the best practices for deploying 2110 and associated technologies, Robert explains that multicast routing at layer 3 works much increases stability, enables resiliency and scalability. He also takes a close look at the difference between ‘all source’ multicasting supported by IGMP version 2 and the ability to filter for only specific sources using IGMP version 3.

Finishing off, Robert talks about the difficulties in scaling PTP since all the replies/requests go into the same multicast group which means that as the network scales, so does the traffic on that multicast group. This can be a problem for lower-end gear which needs to process and reject a lot of traffic.

Watch now!

Robert Welch Robert Welch
Technical Solutions Lead
Arista Networks

Video: IP Media Networks for Live Production

Building and controlling a network for SMPTE ST 2110 go hand in hand when it comes to planning an installation. As ST 2110 delivers all media essences separately, networks can easily end up carrying tens of thousands of flows emphasising the need for efficient network design and having a full understanding of the paths your media are using.

This video is co-presented by Nevion and Arista and starts by observing that the traditional difference between a LAN and WAN is being eroded leading as WANs get faster and better, we find that we can now deliver multi-location broadcast facilities which act similarly to if everything was co-located. Moreover, introduces Martin Walbum Media Function virtualisation which is enabled by network-connected equipment allowing for shared processing and shared control. For instance, it’s now possible to house all equipment in a datacentre and allow this to be used remotely maximising the utilisation of the equipment allowing a broadcaster to maximise the value of its purchases and minimise costs.

Arista’s Gerard Phillips takes a look at SDI systems to understand how we expect IP systems to behave and what we expect them to do. The system needs to deliver high throughput, instantaneous switching with low latency and no tolerance for failure. In order to do this, not only do we need to get the right software but to deliver the resilience we need, the network needs the correct architecture. Gerard takes us through the different options starting with a typical, flat, layer 2 networks and working up to leaf and spine along with a treatment of red, blue and purple networks.

Gerard recently did a deep dive on network design for live production for the IET. Take a look for much more detail on how to architect a network for uncompressed media.

Martin then looks at the need for orchestration. Broadcasters expect to deliver systems with, preferably, no downtime. As such, we’ve seen that network elements are typically duplicated as is the traffic which is delivered over two paths and SMPTE ST 2022-7. If you want to take something out of use for planned maintenance, it’s best to do that in a planned, ordered, way meaning you migrate flows away from it until it’s no longer in-circuit. Software-Defined Networks (SDNs), do exactly that. Martin walks us through the pros and cons of managing your network with IGMP and SDN. Gerard’s previous talk also looks at this in detail.

The video finishes with a look at which Arista switches can be used for media and a look at how Arista and Nevion implemented an ST 2110 network at Swiss broadcaster, tpc. This case study is presented in longer form in this video from the IP Showcase.

Watch now!
Free registration.

Gerard Phillips Gerard Phillips
Systems Engineer,
Martin Walbum Martin Walbum
Senior Vice President of Solution Strategy,

Video: Network Design for Live Production

The benefits of IP sound great, but many are held back with real-life concerns: Can we afford it? Can we plug the training gap? and how do we even do it? This video looks at the latter; how do you deploy a network good enough for uncompressed video, audio and metadata? The network needs to deal with a large number of flows, many of which are high bandwidth. If you’re putting it to air, you need reliability and redundancy. You need to distribute PTP timing, control and maintain it.

Gerard Philips from Arista talks to IET Media about the choices you need to make when designing your network. Gerard starts by reminding us of the benefits of moving to IP, the most tangible of which is the switching density possible. SDI routers can use a whole rack to switch over one thousand sources, but with IP Gerard says you can achieve a 4000-square router within just 7U. With increasingly complicated workflows and with the increasing scale of some broadcasters, this density is a major motivating factor in the move. Doubling down on the density message, Gerard then looks at the difference in connectivity available comparing SDI cables which have signal per cable, to 400Gb links which can carry 65 UHD signals per link.

Audio is always ahead of video when it comes to IP transitions so there are many established audio-over-IP protocols, many of which work at Layer 2 over the network stack. Using Layer 2 has great benefits because there is no routing which means that discovering everything on the network is as simple as broadcasting a question and waiting for answers. Discovery is very simple and is one reason for the ‘plug and play’ ease of NDI, being a layer 2 protocol, it can use mDNS or similar to query the network and display sources and destinations available within seconds. Layer 3-based protocols don’t have this luxury as some resources can be on a separate network which won’t receive a discovery request that’s simply broadcast on the local network.

Gerard examines the benefits of layer 2 and explains how IGMP multicast works detailing the need for an IGMP querier to be in one location and receiving all the traffic. This is a limiting factor in scaling a network, particularly with high-bandwidth flows. Layer 3, we hear, is the solution to this scaling problem bringing with it more control of the size of ‘failure domains’ – how much of your network breaks if there’s a problem.

The next section of the video gets down to the meat of network design and explains the 3 main types of architecture: Monolithic, Hub and spoke and leaf and spoke. Gerard takes time to discuss the validity of all these architectures before discussing coloured networks. Two identical networks dubbed ‘Red’ and ‘Blue’ are often used to provide redundancy in SMPTE ST 2110, and similar uncompressed, networks with the idea that the source generates two identical streams and feeds them over these two identical networks. The receiver receives both streams and uses SMPTE ST 2022-7 to seamlessly deal with packet loss. Gerard then introduces ‘purple’ networks, ones where all switch infrastructure is in the same network and the network orchestrator ensures that each of the two essence flows from the source takes a separate route through the infrastructure. This means that for each flow there is a ‘red’ and a ‘blue’ route, but overall each switch is carrying a mixture of ‘red’ and ‘blue’ traffic.

The beauty of using IGMP/PIM for managing traffic over your networks is that the network itself decides how the flows move over the infrastructure. This makes for a low-footprint, simple installation. However, without the ability to take into account individual link capacity, the capacity of the network in general, bitrate of individual flows and understanding the overall topology, there is very control over where your traffic is which makes maintenance and fault-finding hard and, more generally, what’s the right decision for one small part of the network is not necessarily the right decision for the flow or for the network as a whole. Gerard explains how Software-Defined Networking (SDN) address this and give absolute control over the path your flows take.

Lastly, Gerard looks at PTP, the Precision Time Protocol. 2110 relies on having the PTP in the flow, in the essence allowing flows of separate audio and video to have good lip-sync and to avoid phase errors when audio is mixed together (where PTP has been used for some time). We see different architectures which include two grandmaster clocks (GMs), discuss whether boundary clocks (BCs) or transparent clocks (TCs) are the way to go and examine the little security that is available to stop rogue end-points taking charge and becoming grandmaster themselves.

Watch now!

Gerard Phillips Gerard Phillips
Systems Engineer,

Video: Red and Blue, or Purple; Your IP Media Network, Your Way

Leaf & spine networks have started taking over data centres in the last few years. It’s no secret that people prefer scale-out over scale-up solutions and you can see a similar approach in ST 2110 networks, when large monolithic video switches are replaced with smaller leaf and spine switches.

Leaf and spine refers to networks where a number of main, high throughput switches link to a number of smaller switches. These smaller switches tend to be aggregators and offer the promise of cheaper ports delivered closer to your equipment. The alternative to leaf & spine is monolithic switches which do have their merits, but are certainly not always the right choice.

To provide non-blocking switching in leaf & spine networks you need an SDN controller that orchestrates media flows. Advances in SDN capabilities have led to the emergence of “Purple” network architectures. In this video Gerard Phillips from Arista shows how it differs from a “Red/Blue” architecture, how path diversity is maintained and how ST 2110 IP live production or playout applications could benefit from it.

It’s important to be aware of the different uses of Layer 2 vs Layer 3:

    • Layer 2 devices are typically used for audio networks like Dante and RAVENNA. A layer 2 network is a simple, scalable and affordable choice for audio flows where there are no challenges in terms of bandwidth. However, this type of network doesn’t really work for high bit rate live production video multicast since all multicasts need to be delivered to the IGMP querier which isn’t scalable.

    • Layer 3 have distributed IGMP management since PIM is used on each router to route multicast traffic, so there is no more flooding network with unnecessary traffic. This type of network works well with high bit rate video multicasts, but as IGMP is not bandwidth aware, it’s best to use an SDN system for flow orchestration.

Gerard then looks at resilience:

  • Using 2022-7 seamless switching (plus a robust monitoring system that can provide quick, accurate information to resolve the issue)
  • Choosing quality components (switches, NOS, fibres etc.)
  • Providing redundancy (redundant PSU, fans, fabric modules etc., redundant links between switches, ensuring that routing protocol or SDN can use these “spares”)
  • Dividing up failure domains
  • Using leaf and spine architecture (routing around failed components with SDN)
  • Using resilient IP protocols (BGP, ECMP)

The talk finishes up discussing the pros and cons of the different architectures available:

  • Monolithic systems which are non-blocking, but have a wide failure domain
  • Monolithic – expansion toward spine and leaf with SDN for non-blocking switching
  • Leaf & spine with air-gapped Red and Blue networks
  • Leaf & spine hybrid with Purple switches connected to both Red and Blue spines to support single homed devices
  • Leaf & spine Purple. Here, red and blue flows are connected to physically separate switches, but the switches are not identified as red and blue anymore. This is a converged network and an SDN controller is required to provide diverse paths flows to go to two different spines.

You can download the slides from here.

Watch now!


Gerard Phillips Gerard Phillips
Systems Engineer
Arista Networks