Designing IP Broadcast Systems: Software Defined Networking
SDNs are relatively new to IT and are making great milestones into optimizing networks to improve their performance, especially for heavy hitting media flows.
All 18 articles in this series are now available in our free 84 page eBook ‘Designing IP Broadcast Systems’ – download it HERE.
All articles are also available individually:
Traditional SDI and AES broadcast networks fundamentally differ from IP networks as the former are circuit switched and the latter are packet switched. Both have good reasons for their respective methods due to the data applications and the technological advances available at the time they were introduced.
For example, an uncompressed video or audio stream transfers continuous and time invariant data so benefits from synchronous circuit switched networks, whereas a data feed generated by a computer server is often bursty and is the result of an event trigger such as user requests and benefits from asynchronous packet switched networks. During the 1980s when 270Mb/s SDI was first introduced, packet switched networks worked at speeds in the order of tens of megabits per second, which was clearly inadequate for uncompressed broadcast video.
The IT industry has seen a massive increase in network speeds in recent years to the point where 400Gb/s switch backbones are available and 10Gb/s to 40Gb/s network links are becoming a regular occurrence. These links swamp the data bandwidth requirements of uncompressed SD and HD video and audio media streams thus making IP networks a reality for broadcast television.
Networks use packet switching as they were (and still are) the most efficient method of transferring the data needed in computer systems. Packet switched networks (except for Time Division Multiplex) are asynchronous due to the interactions of the servers operating systems and user requests. A computer will process and therefore generate data in response to an event, this might be a user request, such as a mouse click on a web page, or an automated timed event from a Linux CRON job, but in any case, the data created will be bursty. Keeping packets of data short allows for more efficient statistical multiplexing which in turn provides optimal and reliable data delivery.
Another fundamental aspect of circuit switched SDI/AES and packet switched IP/Ethernet networks is that IP/Ethernet has the equipment source and destination information built into every packet and frame using IP and MAC source and destination addressing. This means the switches and routers can make decisions about where the data should be sent on a packet-by-packet basis thus decentralizing delivery information. This is completely different from the SDI/AES circuit switched network as a higher-level centralized control system must dictate the delivery of the streams.
The broadcast SDI/AES router very closely follows the configuration of the SDN system found in IT networks as the controller and data plane are separated. On the control panel the operator will select the destination of the video and audio feed, and then select the source, which results in a circuit connecting the source and destination devices, such as routing a camera output to a monitor. This works perfectly well for broadcasters as we are generally concerned with where a media signal has come from and where it is going to. Also, the network is heavily resource limited as historically the number of cameras, production switchers, microphones, and sound consoles etc., has been relatively fixed. Due to the technological barrier to entry of making a TV station work, highly specialized engineers and technologists were regularly called upon to add additional functionality, such as cameras and production switchers, and this resulted in slow change often resulting in static workflows.
IT infrastructures are dynamic in nature due to the multiple asynchronous devices that create seemingly random data packets on networks that interconnect across many different geographical areas. To build resilience into the network automatic routing methods have been developed such as Equal Cost Multi-Path Routing (ECMP) where traffic is balanced over multiple links to better utilize and optimize the network capacity. This results in IP packets with the same source and destination IP addresses being sent over different links across a network. Although this method works well for IT type traffic such as file transfers and database queries as packet re-ordering and indeterminate latency has minimal impact on the TCP data deliver, this method can cause havoc for long live media flows where TCP is undesirable due to the variable and unpredictable latency that is caused by the operation of TCP.
Researchers are finding that optimal routing strategies across networks can be compromised when relying on evaluating the header parts of the data packet such as the source and destination addresses. This method can be effective and forms the core of any network routing method, but the approach is somewhat naive as it takes no notice of the contents of the data packets. Traditionally this has not been much of a concern for network operators, but as more application specific data is transferred across a network that is time and bandwidth sensitive, network researchers and engineers are having to dig deeper into the contents of the data packets.
This is nothing new for broadcasters as we’ve been sending media specific data flows across networks since the inception of SDI as a wealth of SMPTE and AES specifications specifically tune circuits to transfer video, audio, and metadata. However, in the IT world, this is relatively new, consequently network operators are having to look at the contents of the data packets to determine the optimal circuit routing, hence the reason SDN is starting to appear in IP networks. In effect, network engineers are looking at data packets not as individual entities, but as part of a larger connected flow called “per-flow”.
Figure 1 - SDNs abstract the control plane from the data plane to facilitate optimized network routing. In this example, the camera output will need to be sent to the monitor via different network links than the camera OCP controls so that the iris and other camera controls achieve better responsivity and are not held up by the heavy hitting media flows in the switch and router buffers. Software control systems can manually provide this and as research improves optimized and highly resilient network routing will be able to be provided automatically.
From a network operators’ perspective having to analyze and decode every flow to determine the best routing strategy is impossible, specifically due to the number of different flow types and encryption methods employed. The whole point of end-to-end encryption is that man-in-the-middle attacks cannot occur, so decoding per-flow streams in a network defeats the object of encryption. Therefore, network operators look at other parameters such as the temporal length and shape of the data packet distribution, and from these they can determine the optimal routing.
For example, large flows containing evenly gapped packets will keep switch and router buffers occupied at a steady rate, and any short bursty flows will be unnecessarily delayed, therefore, it would be better to send the short bursty flows over a different link.
We are some time off being able to completely automatically optimize networks based on per-flow routing but the operation of SDN networks facilitates manual intervention. From the perspective of the broadcaster this gives a greater opportunity to route heavy hitting media flows across different network links than temporally sensitive bursty flows such as OCP iris controls or microphone gain controls etc. As the SDN abstracts the control from the network fabric, much greater control can be applied to the network, so we don’t have to rely on the seemingly unpredictable chance of ECMP and similar protocols.
Part of a series supported by
You might also like...
Designing IP Broadcast Systems - The Book
Designing IP Broadcast Systems is another massive body of research driven work - with over 27,000 words in 18 articles, in a free 84 page eBook. It provides extensive insight into the technology and engineering methodology required to create practical IP based broadcast…
Demands On Production With HDR & WCG
The adoption of HDR requires adjustments in workflow that place different requirements on both people and technology, especially when multiple formats are required simultaneously.
If It Ain’t Broke Still Fix It: Part 2 - Security
The old broadcasting adage: ‘if it ain’t broke don’t fix it’ is no longer relevant and potentially highly dangerous, especially when we consider the security implications of not updating software and operating systems.
Standards: Part 21 - The MPEG, AES & Other Containers
Here we discuss how raw essence data needs to be serialized so it can be stored in media container files. We also describe the various media container file formats and their evolution.
NDI For Broadcast: Part 3 – Bridging The Gap
This third and for now, final part of our mini-series exploring NDI and its place in broadcast infrastructure moves on to a trio of tools released with NDI 5.0 which are all aimed at facilitating remote and collaborative workflows; NDI Audio,…