Editor's note: This is the first of a two-part series on SDN basics. Here we discuss the cornerstones of SDN,
Two major technologies adopted over the last decade have had an enormous effect on information technology: virtualization and cloud computing. These related technologies have given network engineers and application architects a great deal of flexibility in leveraging every cubic foot of data center space to get the most value from their hardware and provide high availability.
The underlying data network that applications ride on, however, has evolved comparatively little. In fact, while virtualization and cloud computing have changed the way most IT practitioners think about computing, networking as a discipline has been stagnant until recently. Most networking technology changes have been incremental upgrades to bandwidth rather than in fundamentally rethinking how networking could be done. Network design books written five or 10 years ago are still considered valid references by many networking professionals because, generally speaking, the network just hasn't changed that much. As James Hamilton, a distinguished engineer at Amazon Web Services, described it in 2010, "Data center networks are in my way."
Indeed, the lack of innovation in the networking space has put some constraints on application delivery designers. In a late but swelling response, networking vendors have been pushing to give networks the sort of flexibility and ease of use that service providers and enterprises need.
Specific areas of networking innovation over the last couple of years include centralized control, programmability, orchestration and virtualization. Classified broadly under the heading of software-defined networking (SDN), these innovations are meant to solve specific problems that businesses face as their virtualized infrastructures and cloud services push the boundaries of what their networks can deliver.
SDN basics: Centralized control
SDN aims to effectively program the network with software running on a central controller. Today's network switches and routers program their forwarding tables locally, which means that network devices make their own decisions internally about how to forward traffic. Traffic-forwarding decisions are informed by distributed control-plane protocols including spanning-tree, OSPF and BGP. But these traditional networking protocols have limited flexibility. In order for them to work, all network devices participating in the forwarding domain have to follow the same rules as defined by the protocol standard. That leaves little room for creativity or unusual business requirements.
An omniscient central controller allows network engineers to implement unique and flexible forwarding policies limited only by the ability of the software running on it.
SDN takes the control plane (how a network device will forward traffic) and separates it from the data or forwarding plane (a network device forwarding traffic based on the control-plane policy). With SDN, the separated control plane resides on a centralized controller that sees and knows all about the network, including where the hosts connect to the network and what the network topology connecting all of the hosts together looks like. An omniscient central controller allows network engineers to implement unique and flexible forwarding policies limited only by the ability of the software running on it.
The central controller idea is thematic when discussing SDN. Two important terms that come up in controller conversations are northbound and southbound. It is best to think of the controller as middleware. Applications that tell the controller how to program the network are northbound communications, while southbound communications program the network devices. The controller acts as an arbiter, abstracting the underlying physical network topology from the applications that wish to program them.
- Common examples of where the central controller programming the network forwarding tables is useful include the following:
- Creating an experimental network that runs on the same physical infrastructure as the production network, while still being logically isolated.
- Enforcing traffic policies where dynamically learned traffic flows have policies applied to them to maintain a defined Quality of Service (QoS).
- "Routing for dollars," where forwarding paths can shift based on the financial impact to the company.
- Intelligent network security, where particular flows could be shunted, for example, to an intrusion detection system for deep packet inspection, while others are allowed to flow freely based on operational policy.
- Network-wide traffic mirroring (e.g., spanning) where traffic flows from any point in the network can be copied to any other point in the network for logging, reporting or analysis. This is similar to the notion of a "tools network" or "visibility fabric."
SDN basics: Network programmability
Network engineers typically configure network devices using a command line interface (CLI) or graphical user interface (GUI). While this paradigm is normal, it's not without its problems. Implementing complex network configurations may require an engineer to configure several different network devices separately. This process is time-consuming, tedious and error-prone. Systems administrators have automation tools like Puppet to ease their workload. Despite the ubiquity of Simple Network Management Protocol (SNMP), network engineers have never had a predictable set of management tools that could handle provisioning tasks.
Network programmability aims to change that by exposing application programming interfaces (APIs) that allow network devices to be programmed through a powerful instruction set that uses an array of programming languages. The use of APIs means that network provisioning is not a task limited to a network engineer typing at a CLI, but rather that an array of tools could be used to program the network. Here are some examples:
- Scripts could be used by network engineers to automate provisioning tasks or gather network statistics. (While network engineers can use scripts today, they are often merely glorified interactions with the CLI or SNMP.) APIs promise to provide richer functionality and the possibility of ecosystems where engineers could collaborate.
- Orchestration tools could integrate network provisioning tasks with other tasks required to create a business application.
- Network applications, possibly running as plugins to the centralized controller, could add functionality to the network environment, conceptually like an application does a smartphone.
More on SDN and centralized control
Understanding the application tier of SDN
OpenFlow protocol guide: Speaking from controller to switches
A northbound API primer: The applications that control the network
OpenFlow configuration protocols: Controlling the controller
Many networking vendors have been hard at work producing custom APIs that leverage the full feature set of their network hardware. A couple of examples include Cisco and Juniper Networks. Although it's early in its lifecycle, Cisco's onePK offers a library of APIs that allows programming of a variety of Cisco network hardware running IOS, IOS-XR and NX-OS. Juniper's Junos has always had an XML API; even its CLI generates XML code to send to the underlying operating system.
It is hard to avoid mentioning OpenFlow when discussing network programmability. Under steady development by paying members of the Open Networking Foundation, OpenFlow is a leading example of how to implement network programming using a central controller. OpenFlow is a vendor-agnostic standard that describes how to program a network switch. It identifies specific flows using a variety of matching criteria (MAC address, IP destination address, etc.) and then performs actions on those flows (forward via port X, drop, etc.) A centralized OpenFlow controller with knowledge of the entire network topology programs this behavior for all network switches.
Open source OpenFlow controllers include Beacon and FloodLight. Network vendors supporting OpenFlow in their switches include HP, Juniper, Pica8, Cisco and many others. While OpenFlow is a conceptual slam-dunk, it has run into scaling and compatibility challenges, as OpenFlow operations frequently don't map well to networking silicon, causing "OpenFlow compatible" to mean different things to different vendors. As a result, OpenFlow's long-term future is unsettled.
About the author:
Ethan Banks, CCIE #20655, is a hands-on networking practitioner who has designed, built and maintained networks for higher education, state government, financial institutions and technology corporations. Banks has also been a host of the Packet Pushers Podcast, a technical program that covers practical network design, as well as cutting-edge topics like virtualization, OpenFlow, software-defined networking and overlay protocols. He is the editor for the independent community of bloggers at PacketPushers.net and can be followed @ecbanks.