Software defined networking is defined by a decoupling of the control and packet-forwarding planes in a network, an architecture that can slash operational costs and speed the time it takes to make changes or provision new services.
Since all the intelligence resides in software – not baked into monolithic specialty hardware – customers can replace traditional switches with commodity devices to save on capital costs. SDN also makes it possible for the network to interface with applications directly via APIs to improve security and application performance.
So what is SDN?
Traditional networks are made up of devices with integrated control and data-forwarding planes so each box needs to be configured and managed independently. Because of this, even simple changes to the network can take weeks or even months to complete because the changes have to be made to each device. This was acceptable when network changes were typically made independently from business changes.
But with the rise of the Internet of Things (IoT), cloud computing and mobility, businesses are now network-centric. Digital transformation is forcing companies to be agile and move with speed, and the network needs to be equally agile and fast. The separation of control and data planes enables control to be abstracted away from the device and centralized so a network administrator can issue a change that is propagated instantly across the entire network.
In the early days of SDN, this centralized control resided on a dedicated appliance aptly named the SDN controller, but that functionality can be delivered as a virtual appliance from the cloud or as a distributed function that runs across all the network endpoints. The key is that the separation of the control plane enables configuration and management tasks to be done from a central location.
Initially, SDN focused on enabling businesses to replace high value, premium-price hardware with commodity devices known more commonly as white-box switches. To adopt this option, an organization would write its own lightweight operating system and manage the software itself. This proved to be tremendously valuable to Web-scale organizations as they could build custom features to differentiate their services.
However, this can also be more expensive than using traditional network devices because of the additional cost involved in hiring the network-software talent. White-box switches can also be difficult to procure, as these are not readily available from traditional value-added resellers (VARs) or distributors.
An alternative to white-boxes are something called brite (BRanded whITE) boxes where vendors pre-load proven, validated operating systems and offer support and hardware maintenance. This provides some of the benefits of a white-box – like being a completely open platform – without the downside of hiring a team of people to write the operating system. Brite-boxes are typically built with Linux operating systems and are ideal for large organizations that want to align network operations with DevOps.
The past few years have seen the mainstream network vendors jump into SDN with both feet. They still offer feature-rich, turnkey switches with all the support and services mainstream enterprises have come to rely on but with a vendor-provided SDN controller. Many of the mainstream vendors also offer support for third-party controllers.
The primary value is in reduction of operational expenses through the automation of configuration and management tasks instead of focusing on hardware costs. In actuality, network hardware accounts for less than 10% of overall data-center spend, while personnel costs can be well over half of a data center’s total cost of ownership. A small reduction in operational costs can pay significant dividends for the business.
One of the most important distinctions between traditional networks and SDNs is that the SDN controllers (or controller functionality if not on a dedicated appliance) have northbound interfaces that can communicate with applications via application programming interfaces (APIs), which enables application developers to program the network directly.
For example, using APIs, a videoconferencing application could automatically create a dedicated path between the video endpoints to guarantee the highest performance. Once the call was finished, the application could let go of the reserved bandwidth. In the past, network operations would need to get involved to reserve the bandwidth and then release it post-call. Historically this could only be achieved if a network-savvy software developer could reprogram the network through CLI commands, but software developers who understand network protocols is rare.
Businesses that want to software-define a network without upgrading the network can choose a solution that operates as a pure software overlay. With this model, virtual network tunnels are initiated and terminated on devices such as firewalls, WAN optimizers or even hypervisors. The benefit of this model is that non-network teams, such as security or server operations can manage their own overlay. The downside is that troubleshooting network problems can be a challenge as the underlay and overlay are invisible to one other.