Al Kovalick
By now you have likely heard some of the hype about “Software Defined Everything.” SDx is a collective term that describes an infrastructure that is programmable and driven by policy, automation and strict resource management. The “x” can refer to the entire data center (SDDC) or for storage (SDS) or networking (SDN) or other targets.
The value proposition is twofold; (1) hardware resources are virtualized and treated as a utility, and (2) application requirements drive the utilization of these resources. So, rather than manually configure the compute, storage and network resources for a range of apps, the needs of the apps “program the resources” for action. This may sound rather abstract so let’s consider an example using SDN. Today, many cloud and some private data center implementations use SDN principles.
SDN CONCEPTS
Fig. 1: Software-defined networking environment To appreciate how SDN functions let’s first review the operation of a traditional layer 3 packet switch. A newly installed switch looks at its connected neighbors and builds a topology map of what it thinks are all the IP routes to other switches in its locality. It uses protocols such as Open Shortest Path First to incrementally build its internal flow table. The flow table is part of the control plane of the switch and the packet-forwarding path is part of the data plane. Each switch acts independently and has a somewhat myopic view of the network totality. As a good network citizen it forwards packets based on its flow table view of the world.
Now let’s turn to SDN. In this case, the control plane is completely separated from the data plane (Fig. 1). In practice, this means that the flow tables are populated not by local investigative protocols such as OSPF but rather by a “know-it-all” external controller. This controller has a grand view of the topology and can best determine how to route packets across the network and use the network resources to maximum efficiency.
In addition, SDN-based routing gives more power to the actual business needs of the applications layer. Some call this “application fluency.” For example, the switching layer could be divided into two completely separate virtual networks (i.e., accounting department and real-time media) with absolutely no connections between them if desired. Yes, this can be done today using VLANs but SDN methods provide the ability to load balance based on application needs. Or, if duplicate links are needed for reliability on select paths, these can be created and torn-down on demand using SDN. Finally, system-wide QoS can be centrally managed, a valuable feature for a media facility. Bottom line, the improved degrees of network utilization, reliability and resource management are strategic SDN value propositions.
THE SDN ENVIRONMENT
Let’s parse Fig. 1. At the bottom is a mesh of network switches, each with a flow table. Switches can be traditional but with added SDN support or, at the other end of the spectrum, “bare-metal, white box, open” versions. Many bare-metal versions support SDN semantics but are not burdened with mountains of legacy protocols. Google, for example, has created an enormous network based on SDN-friendly bare-metal switches.
The control layer is multifaceted. The core is the network operating system (NOS). This software mediates the requests from the application layer and programs each switch’s flow table based on app needs. Some popular open source controllers include OpenDaylight (Linux Foundation), Floodlight (Big Switch) and POX (Stanford). Seehttp://goo.gl/o6tI3P for a comparison. Plus, there are many proprietary vendor-supported controllers.
By way of illustration, the control plane is sometimes called the “north/south” plane while the packet flow is considered “west/east.” In this context, the northbound API enables higher-level systems to request routing connectivity and QoS. For example, a connection management system (think SDI routing control), at the app layer can request the NOS to create a 3 Gbps video path from a camera to a recorder or from a playout server to a monitor.
The NOS communicates to the switches via the southbound API. A popular method to communicate with switches uses the OpenFlow protocol. Most modern switches support OpenFlow semantics and other methods. The Open Networking Foundation (ONF) promotes the adoption of SDN and manages the OpenFlow standard. Think of OpenFlow as a command language for the programming of flow tables. A flow table has two entries per row (plus a stats entry): the first entry is “header or rule” and the second is “action.” For example, if a switch receives a packet header Dest_IP address set to 10.2.1.1, then the action is to forward this packet to outbound port X. You can investigate OpenFlow and command line dialogs by interfacing and experimenting with an open vSwitch instance. In fact, I keep an Amazon EC2 instance alive on my desktop to research OpenFlow with different vSwitch-based network topologies.
Of course, there are tradeoffs to an SDN-only approach. Few networks are islands and most need to communicate with non-SDN switches at some point. For this reason most switches support a minimum of traditional protocols to interoperate. Legacy routing methods are very durable under a switch fault. Likewise, it’s a danger to rely on a single NOS controller in the case of its failure. To compensate, SDN can use cluster-based High Availability models with N controllers appearing as one logical controller. Finally, SDN casts a wide net including NOS/OpenFlow as described above; VXLAN; and generic tunneling overlay means to create virtual LANs. These other methods are out of scope for this article.
Why should you care?
SDN has the promise to enable total network resource control; think one controller with a “know-it-all” approach to system-wide management. As video SDI transitions to Ethernet some designs will use SDN to build networks with beneficial agility, reliability and flow control. Keep current in this area and SDx in general since they will likely help define future media facilities.
Al Kovalick is the founder of Media Systems consulting in Silicon Valley. He is the author of “Video Systems in an IT Environment (2nd ed).” He is a frequent speaker at industry events and a SMPTE Fellow. For a complete bio and contact information, visitwww.theAVITbook.com.
