Building An IP Studio: Connecting Cameras - Part 4 - Software Defined Networks

In the previous article in this series, we looked at layer-2 switching and layer-3 routing. In this article, we look at Software Defined Networks and why they are so appealing to broadcasters.


Other articles in this series:


Although SDNs (Software Defined Networks) may be a relatively new concept for the IT industry, broadcasters have been using this technology for many years.

In essence, an SDN is a system that separates the control and data planes within a computer network. In broadcasting, we use a similar system with solid state SDI and AES routers. An array of X-Y cross points, under the control of a user panel, routes signals from a source to a destination, or multiple destinations. In this context, the X-Y cross points are the data plane, and the user panel forms the control plane (albeit a primitive version).

IT networks have traditionally used various forms of automated signal switching and routing. As IP is a packet-based system with the source and destination addressing built into every packet, automated routing was built into the design from the beginning. This provides massive advantages for generalized networks as any human input into signal routing is kept to an absolute minimum. However, as networks become more complex with increasing numbers of devices attached to it then network administrators are needed to configure networks, but for the most part, small office networks generally look after themselves.

Broadcast IP networks introduce a significant level of complexity due to the relentless nature of streaming media. With ST2110 networks the packets must not only be evenly gapped, but also timed within very tight tolerances. Forward Error Correction (FEC) provides a level of data correction should a packet become corrupted but keeping latency low and determinate is critical for the reliable operation of the network. Consequently, relying on automatic routing of packets across networks is a far from ideal solution for broadcasters.

The Open Networking Foundation (ONF) is a nonprofit organization that is dedicated to standardizing and developing SDN networks and it provides a third plane in its SDN definition called the application plane. This is the highest layer in the architecture and provides various business applications. The use of these may not seem immediately obvious for broadcasters but the application plane is also responsible for adding an element of control logic to the network to change its behavior. This is particularly useful if the network dynamics need to be changed from a TCP/IP based NDI system to UDP/IP based ST2110 system as the two streams have subtly different requirements of the network.

Figure 1 - Overview of the SDN network showing the physical separation between the infrastructure and control and application layers.

Figure 1 - Overview of the SDN network showing the physical separation between the infrastructure and control and application layers.

Having the data, control, and application planes separated like this provides immense opportunity for provisioning the distribution of media streams in a network. Broadcast control traffic that deals with the operation of equipment such as play and stop on a media server, or switching inputs on a production switcher, requires low latency, symmetrical routing. That is, the send and receive paths must be similar in latency otherwise the TCP algorithm could enter its startup-phase due to round trip timeouts resulting in variable latency, which in turn would lead to a poor user experience for the operator.

These types of time sensitive short bursts of data that are indicative of control messages can be greatly affected by head-of-line blocking, in part, caused by long UDP/IP flows such as ST2110 media streaming. Currently, we deal with this sort of challenge by keeping the short message flows and long media flows separate on different logical and physical networks. This works but is highly inefficient and results in covering up some fairly substantial cracks in our design topologies.

Treating the data plane as a separate entity from the control and application planes allows the centralized management system to have a whole view of the network. Although the SDN technology is in its infancy, much research is being conducted into understanding the dynamics of networks. This includes understanding how ISPs differ from datacenters and even studios as each type of network has its own signature that describes the types of data flows. For example, a datacenter may transfer many long FTP/TCP flows due to regular server file access, but an ISP will be dealing with predominantly short bursts of HTTP/TCP flows from users accessing web sites. Both have different requirements of the network and hence would benefit from different routing. Centralized control facilitates this.

The control element of the SDN network is analogous to the control panel for the SDI and AES router. And the data plane is similar to the SDI and AES X-Y cross points. Data switching and routing occurs in both hardware and software and vendors including HP, NEC, Juniper and Cisco all have SDN supported protocols that facilitate control from a centralized management system. In effect, the management system makes entries into the tables of the switcher so that it knows which port to send the incoming data to without having to work out the switching or routing for itself. Instead of using metric- and load-based routing, the management system can specifically send packets along the path most suited to its application.

Software switches also exist and are often referred to as virtual switches. These run on operating systems such as Linux and several implementations exist including vSwitch, Indigo, and Pantou. Although they are much more versatile and flexible than hardware switches, they are much slower and have only limited use in a broadcast environment.

Switch metrics are also an important part of SDN as the management systems needs to know how the links in the network are performing. This allows them to be optimized, and in the context of a broadcast facility this means keeping congestion below the packet dropout threshold and routing short bursty traffic along different routes than long media streaming traffic. Vendor and open-source switches all provide metrics and relay these back to the controller using protocols such as OpenFlow, SNMP, and OVSDB (Open vSwitch Database Management Protocol). Therefore, the controller not only keeps a record of the switching but also has a deep “understanding” of the efficiency of the network.

SDNs are the natural selection for broadcasters and using distributed hardware switches in combination with centralized management control provides the perfect solution.

You might also like...

Vendor Spotlight: Telstra Broadcast Services

Telstra helps customers span the globe. Offering a myriad of content delivery, production and playout services, Telstra Broadcast Services allows businesses, governments, communities and individuals to connect and expand their business across the globe in the most cost-effective way.

Electricity: Part 8 - Electric OB Vans

We are told that in the future all cars will be electrically powered. It is therefore quite natural that a broadcaster should consider whether outside broadcast vehicles might follow suit.

Scalable Dynamic Software For Broadcasters: Part 1 - Introduction

IP has succeeded in abstracting away the media essence from the underlying transport stream, and in doing so is providing scalable and dynamic solutions that are facilitated through cloud technologies and software.

Compression: Part 2 - Moving On From Analog

Compression is almost taken for granted despite its incredible complexity. But it’s worth remembering how compression has developed so we can progress further.

Keeping Studio IP Media Streams Reliable - Part 2

Distributing error free IP media streams is only half the battle when building reliable broadcast infrastructures. SDP files must match their associated IP media essence or downstream equipment will not be able to decode it. In this article we dig…