SDN: Not Just Another Three Letter Acronym

PITTSBURGH—Networking for media professionals continues its evolution as the broadcast industry gradually and incrementally moves from serial digital interface (SDI) infrastructures to one steeped in the world of Ethernet, IP, and software based managed.

With the 2017 year-end publication of SMPTE ST 2110—the new standard for IP video over a managed network—engineers, network administrators and broadcast technicians are now faced with learning how to address the growing features and capabilities found in a managed, high-bit-rate, real-time professional media network environment. Having the necessary tools at their fingertips, along with the understandings of how to build, operate and manage these systems using commercially available, common off-the-shelf hardware, will be essential in helping these new users adapt to a paradigm shift in the way media transport, at a stream/flow level, operates.

AMWA, NMOS AND SDN

In harmony with the physical network topology comes the software-based control and management platform we’ll be using in the future. Solutions such as those developed by the Advanced Media Workflow Association and identified as NMOS (Networked Media Open Specifications) Interface Specifications IS-04, IS-05, and IS-06 are built upon the foundations of software-defined-networking or “SDN.”

This overview introduces SDN and how it fits with IP video in a professional media network. The term SDN is not the marketing term augmented with extra letters and used by several manufacturers to describe their control/management solutions. Instead, and more succinctly, SDN is associated with the wide-ranging concepts for the network infrastructure and managed operations. In this context, SDN offers capabilities for the identification, registration, and flow management of the network—in its entirety. The principles of SDN therefore apply to the entire network and not just to controlling specific devices or components that live on that network.

ST 2110 standards clearly address the physicality of the network from the interoperability perspective. It ensures that those devices residing on the network can successfully send and receive packets in an unconstrained manor. None of the ST 2110 standards contend with the control or application planes of the network. Hence, significant work is still needed to achieve useful interoperability and automation in professional networked media environments.

MODELS AND BEST PRACTICES

In 2013, several industry bodies came together to formulate the Joint Task Force on Networked Media (JT-NM), which was tasked with coordinating how network control mechanisms and applications planes might be addressed. JT-NM’s output was the formation of a “reference architecture” (RA) for interoperability (i.e., “JT-NM RA”).

At its most basic level, the JT-NM RA identifies models and best practices for what may be needed at four layers: operation, application, platform and infrastructure. Those resolutions and their development are entirely software-based and bring forward the roots of SDN.

SDN is an emerging architecture that is dynamic, manageable and cost-effective and can adapt to the environment in which it is applied to, making it ideal for the high-bandwidth, dynamic nature of today’s applications. SDN is applicable to high-performance computing (HPC), asset management, to transaction management, and to media-centric environments—such as those found in the ST 2110 standards.

Fig. 1: Software Defined Network - Architecture

Fig. 1: Software Defined Network - Architecture

What is fundamental to SDN is that the architecture decouples the network control and forwarding functions, enabling the network control to become directly programmable (i.e., “programmatically enabled”) with an underlying infrastructure which is abstracted for applications and network services (Fig. 1).

SDN architectures are directly programmable. In other words, network control is directly programmable because it is decoupled from the forwarding actions found in other conventional network systems.

TRAFFIC FLOW

SDN by nature must be completely agile. By abstracting control from the forwarding elements, administrators can dynamically adjust the traffic flow on a network-wide basis. This means the administrator (which is likely an automation solution versus a human) can adjust the flow of the network traffic to meet changing needs. For example, if the network traffic flow for a signal system is built up for a 3G (1080p60) data packet flow, it means up to three 3G signal flows can be provisioned on a single 10G link. Should another signal be requested to flow through the same port, over-subscription (connecting multiple devices to the same switch port to optimize switch use) would occur. SDN would have knowledge of these limitations and reroute (as necessary) the traffic through an alternate, less congested port. Ideally this is done automatically, with the user never knowing the flow attributes or paths. Switches become an agile, flexible component of the overall network—something that in traditional networking might require reprogramming at the switch-console level.

Programmatic configuration is another key component in SDN. This allows network administrators the ability to configure, secure, manage and optimize all their resources quickly and dynamically. Utilizing automated SDN applications, programs which users can write themselves (or “interfaces” like those in NMOS) no longer depend on proprietary software or hardware controllers, such as those required in traditional SDI-video matrices. Configurations now become “vendor neutral” and applicable to multiple switch vendors, end-point devices and other resources. Fig. 2 summaries what SDN is and is not.

Fig. 2: Distinguishing what SDN is and is not.

Fig. 2: Distinguishing what SDN is and is not.

CLOUD-BASED

SDN need not necessarily be associated with cloud computing services; albeit most cloud services depend upon SDN to automate and manage their own resources dynamically. Essentially, SDN replaces those “static architectures” found in traditional networks, decentralizing the hard-set nature of the network and allowing for a flexible, adjustable and extensible architecture—further promoting the differences previously expected from the traditional SDI-video routing solutions.

Karl Paulsen is CTO at Diversified and a SMPTE Fellow. He is a frequent contributor to TV Technology, focusing on emerging technologies and workflows for the industry. Contact Karl atkpaulsen@diversifiedus.com.

Karl Paulsen
Contributor

Karl Paulsen recently retired as a CTO and has regularly contributed to TV Tech on topics related to media, networking, workflow, cloud and systemization for the media and entertainment industry. He is a SMPTE Fellow with more than 50 years of engineering and managerial experience in commercial TV and radio broadcasting. For over 25 years he has written on featured topics in TV Tech magazine—penning the magazine’s Storage and Media Technologies and Cloudspotter’s Journal columns.