EIGHTY FOUR, PA.—Internet protocol technologies developed and implemented globally are now found in equipment rooms and network applications for broadcast. We’re at the cusp of seeing just how technologies like virtualization, IP, real-time transport protocols and software-based network management impact real-time broadcast systems. Of the many enabling datacenter technologies, “software defined networking” (SDN) is now integral to next-generation IP video transport.
SDN is the core technology present in the controlling of IP video on professional media networks (PMN). To understand how SDN fits into real-time transport protocol (RTP), UTP (user datagram protocol) and live-studio video—i.e., Studio Video over IP (SVIP as SMPTE 2110)—we will explore portions of networking evolution; see where the differences are; and provide examples of how SDN is being applied to broadcast infrastructures and IP-network management.
PACKET FORWARDING PLANES
Networks are all about packet forwarding. Networks are largely built of three integral components: a control plane, a data plane and a management plane.
Planes are implemented in the firmware found in routers and switches. The control plane makes decisions about where network traffic is sent; and, the data plane (or forwarding plane) is what moves traffic to the next hop—i.e., which packets go through the router with a path that is determined by the control plane logic. The management plane configures the interfaces, IP subnets, and routing protocols.
SDN changes how the control plane and data plane interact. SDN is a technology where the network control is decoupled from data forwarding and becomes directly programmable. SDN moves away from distributed configurations to controlling the network via a logically centralized high-level controller. Insulating the control plane from network hardware and implementing control in software enables programmatic access, making network administration more flexible.
Fig. 1: Classic network model with details of each network component detailed in the green inset.
TRADITIONAL NETWORKS VS. SDN
Classic networks are built whereby the data planes move traffic using a “state distribution mechanism” (“protocols”) layered onto forwarding hardware, with an operating system in the control plane set between them. Fig. 1 represents how protocols interconnect the components.
Fig. 2: Traditional networking model where each network component has a control plane coupled directly with the data plane of each section.
Fig. 3: In SDN, the data planes exchange the packets, but a single control plane manages the data planes directly.
Using designated protocol(s), vertically integrated practices guarantee consistent interoperability, but unfortunately also produces a closed platform. In the “traditional networking model” (Fig. 2), control planes and data planes are coupled to network elements and endpoints. In the SDN paradigm (Fig. 3), the control plane API is decoupled from each individual data plane using a network topology abstraction with high-level access to programmable switching.
SDN models allow features such as host tracking or shortest path routing; with intelligence to know about and control each data plane element accordingly; and alleviates the former need to land control software applications on each peripheral hardware endpoint. SDN lets the control system become aware of all the network’s activities.
BASIS OF CONTROL
SVIP products leverage SDN capabilities, emulating similar functionality to what broadcasters have in existing SDI-based routing. Since SDI routing is constrained to specific bandwidths (1.5G, 3G, 6G and 12G) with a fixed point-to-point unidirectional signal architecture, all SDI data flows are governed by strict standardized hardware parameters, which send and receive SMPTE standardized signals. For IP-video broadcast networks, flow management is an essential component, which is unnecessary in SDI-routing environments.
IP networks may utilize either TCP (transmission control protocol) or UDP (user datagram protocol); but unlike SDI, IP connectivity is point-to-multipoint. In real-time IP-networks, especially for broadcast applications, “flows” and “connections” are managed via capabilities built into the SDN; providing both intelligence and protection against over-subscription of the network. With SDN, network controllers know of the signals, where they came from, and who gets what data sent to which end-point.
Excessive flows will oversubscribe any network, and may collapse the network in unpredictable ways. By applying SDN’s intelligence, flows are better understood because control on the network becomes centrally managed.
UNDER THE SDN HOOD
Understanding SDN helps users of media networks know how control, automation and network management can be achieved and maintained. We should be clear though, SDN is not virtualization—rather it is the logically controlling of the network from a central high-level program (e.g., the network ‘Controller’)—much like an SDI-router’s controller does today.
In networking, lower layer routing protocols, i.e., layer 3 and layer 2 of the Open Systems Interconnection (OSI), Table 1, won’t understand the infrastructure of the network much further than the next hop in the topology. By themselves, flows are not necessarily fault tolerant, nor do they possess intelligence about the overall systemization or user-interfaces on the network.
Table 1: The classic OSI reference model with examples of the various networking standards, applications or protocols associated to each Layer name and number.
For television broadcast and production, an SDI “router controller” executes the video switches (i.e., routes the signals through the crosspoints to output ports). SDI routers may control audio channel-pairing, shuffling, perform tie-line management between routers, act on specific policies (i.e., user access control), and set up control panels based upon sources, destinations and availabilities.
In networking, the “network controller” is tasked with those management functions. Controllers utilize SDN to “steering packets” across the network from sources to destinations. Since multiple signals are carried on the same physical media (copper Ethernet cable or optical fiber), something must track what is on that media; understanding what is going to or coming from any port on the switch or end-points. Not all switches are SDN capable, so be aware you can’t pick any switch and expect it to handle SDN functions.
SDN AND ORCHESTRATION
SDN enables network agility; helping automate the pathing of packets through switches throughout the network, processes known as “orchestration,” based on what the end-points on the network need or expect. Orchestration is equivalent to the broadcast SDI router control system, (except in network terminologies), and together with SDN, are the basis of control for PMNs.
Applications and SDN handle IP multicast join or leave requests. They aid in port management to prevent packets from oversaturating links or receiver end-points. IP-routing decisions are dynamic and continually changing, so SDN-based network control must understand network changes based upon potential activities throughout the network, contrary to single streams on a single cable in an SDI router.
Network control application software, such as OpenFlow (an open standard-based piece of an SDN system), enable network controllers to know about and steer packets across the network switches. Since SDN separates control from forwarding, a sophisticated and intelligent flow management schema is created.
HYBRID SYSTEMS LIVING TOGETHER
Hybrid systems are where network (IP) and digital video (SDI) topologies share the features of SDN-based controllers to manage real-time transport (RTP) of IP video with legacy SDI-based equipment on the network. Broadcast equipment manufacturers seamlessly integrate these “network controllers” with their SDI-router controllers—which is essentially the SDI/IP architecture we expect to see for several years.
Karl Paulsen is CTO at Diversified (www.diversifiedus.com) and a SMPTE Fellow. Read more about this and other storage topics in his book “Moving Media Storage Technologies.” Contact Karl at firstname.lastname@example.org.