Software-defined networking (SDN) is a network management technique that centralizes control of network appliances in software. SDN makes network management easier in two ways: it allows networks to be administered as a whole, rather than on a device-by-device basis, and it allows for administrative work to be automated and conducted on the fly in response to changing network needs and conditions.
The first SDN system to gain traction was the open source OpenFlow protocol, which rolled out in 2011. There are now a number of possible SDN models, each providing significant benefits when compared to traditional networking.
SDN vs. traditional networking
In a traditional network structure, decisions on how network packets get transmitted from one computer to another are made by the physical routers, switches, and firewalls that make up the network infrastructure. The functionality of these network devices is divided conceptually into elements called planes, including the data plane (sometimes called the forwarding plane), the control plane, and the management plane.
The data plane forwards incoming network packets to the appropriate destination. It needs to do so very quickly in order to maintain high network speeds, and so rather than doing any real "thinking," it compares routing information in the packet headers to information stored in routing tables, forward information bases, and other similar data structures.
The data in these tables is populated by the control plane, which determines the best routes that packets should take across the network. The control plane uses a number of sources of information to do this, including communication with other nearby routers using standard network protocols. Its decision-making can also be guided directly by human intervention, which takes place via the management pane.
In a traditional network, devices work independently, and administrators need to log into each one to manage it and set network policies. With SDN, the control plane is abstracted away from these individual devices into a centralized, software-based controller that can run in a server in the data center. This controller communicates with the data planes on all network devices.
How does SDN work?
There are three main components to a software-defined network: controller, applications, and devices. The controller has taken over the role of the control plane on each individual network device. It populates the tables that the data planes on those devices use to do their work. There are various communication protocols that can be used for this purpose, including OpenFlow, though some vendors use proprietary protocols. Communication between the controller and devices is referred to as southbound APIs.
The software controller is, in turn, managed by applications, which can fulfill any number of network administration roles, including load balancers, software-defined security services, orchestration applications, or analytics applications that keep tabs on what's going on in the network.
These applications communicate with the controller (northbound APIs) through well-documented REST APIs that allow applications from different vendors to communicate with ease. The application could allow administrators to send commands directly to the controller; but, more typically, the applications are configured with policy settings and allowed to dynamically adapt to conditions.
SDN vs. virtual networks
In broad terms, an SDN and a virtual network are similar in that they both aim to decouple the management of a network from the underlying physical devices; however, in practice they take different approaches.
In a virtual network, network devices are simulated as virtual machines running on servers or in the cloud, creating a logical network that overlays the physical one. A hypervisor mediates between the two and translates virtual network activity into instructions for the physical routers that transmit packets. In this scenario, even if a network device is running entirely virtually in software, it's still a self-contained entity with its own control and data planes.
In an SDN, in contrast, the controller function is moved from individual devices to centralized software running on a server, which is a different paradigm. That doesn't mean the two can't work together, an SDN controller can manage virtual network devices just as easily as it can physical ones.
SDNs vs. SD-WAN
SDNs are primarily used on LANs. Software-defined WANs, or SD-WANs, also separate control and data planes and use many of the same techniques as SDN, but extend over the open internet to connect branches to main offices or the cloud.
Benefits and challenges of SDN
Separating the control and data planes is the core of what an SDN is. Doing so unlocks significant benefits, says Mike Capuano, former chief marketing officer for Pluribus Networks. “At its heart, SDN has a centralized or distributed intelligent entity that has an entire view of the network, that can make routing and switching decisions based on that view,” Capuano says.
He adds, “Typically, network routers and switches only know about their neighboring network gear. But with a properly configured SDN environment, that central entity can control everything, from easily changing policies to simplifying configuration and automation across the enterprise.”
SDN delivers a number of specific advantages:
- Network programmability. By opening up network infrastructure not just to human intervention but to programmatic interactions via APIs, SDN brings networking into the increasingly automated IT shop of today. In particular, NetOps—the application of the automated CI/CD techniques at the heart of DevOps to the world of networking—is only possible in a world where the network can be provisioned and managed via code.
- Ease in establishing and changing policies. By centralizing administration of the whole network, SDN makes it possible to roll out new network policies around security, QoS, and more, across all devices all at once. Combined with the power of automation, this makes it possible for the network to adapt itself quickly and automatically as conditions change. SDN also allows general policies to be established that can be applied to a heterogenous underlying network, which is important in scenarios where an SDN controller is managing standard computing equipment, edge devices and IoT sensors.
- Network visibility. While individual physical network devices can communicate with one another, on a traditionally managed LAN they do not work together to create a "big picture" of the network. By centralizing controller functions, SDN provides network admins with better visibility into the network, and there are any number of analytics applications that can use to take in that data to help plan and understand underlying network health.
- Reduced expenses. One of the big pitches from SDN vendors is that their solutions will help achieve all these benefits while at the same time reducing costs. SDN promises to reduce operating expenses by making it simpler (and thus requiring fewer person-hours) to administer networks, and reduce capital expenses by allowing you to replace expensive proprietary network hardware with virtualized switches running on commodity boxes (the hardware requires less computing power, since the control plane has been abstracted away). Of course, this has to be balanced against the cost of the SDN solutions themselves.
That said, there are challenges to an SDN rollout:
- A big lift. In general, rolling out a software-defined network requires major restructuring of the network, which can require a lot of staff hours and offset some of the promised OPEX savings.
- A steep learning curve. While SDN applications can unlock powerful monitoring and management capabilities, they also can take a while for staff to learn how to use—particularly if they're part of a proprietary vendor solution. If you're rolling out an SDN as part of a shift to NetOps, there's also a whole new culture and philosophy the network team is going to have to learn about, on top of the new tools.
- A single point of failure. In the SDN model, the controller becomes absolutely crucial to the functioning of the whole network. If the controller, or the server it's running on goes down, you could lose network connectivity across the whole office. You need to plan for high availability and disaster recovery.
- Performance problems. One of the promises of SDN is that the holistic view of the network will help improve network performance. But dependence on a single controller can also result in network latency, particularly as the size of the network scales up.
- In theory an SDN can be just as secure as a traditional network, thanks to the variety of software network security applications available. In practice, SDN deployments often shift from dedicated hardware firewalls to commodity hardware for the underlying network devices, so network admins trade dedicated built-in security features for security they need to administer themselves—which can have negative consequences.
It's important to go into an SDN rollout with your eyes open to potential pitfalls. But for many, the benefits far outweigh the costs.