Software-Defined Networking (SDN)—a gentle introduction


Michał Mach

Reading time: 21 minutes

When doing research about modern network engineering, one comes across the term Software-Defined Networking (SDN). In a nutshell, SDN is an approach to networking that enables the programmatic and dynamic control of a network. Such approach is more congruent with a cloud computing than traditional rigid networking. One of the drivers behind SDN is a desire to transition from an old networking mindset to the new agile and more flexible approach so often used in software development practices. When implementing SDN in practice, automation and flexibility are key concepts.

The SDN approach to network architecture has been steadily gaining ground. More and more companies are designing their network infrastructure with this approach in mind. Hence the following introduction, which explains the basic ideas behind SDN technology, describes the current state of the art and looks at possible scenarios for the years to come.

The evolution to SDN

The evolution of networking has a good deal in common with the evolution of computers. In the early years of the computer era, computers were black boxes where operating systems, applications and hardware were vertically integrated. They were also guarded by strict proprietary laws prohibiting any third party modifications. Such an approach to computer architecture was a real innovation blocker and narrowed down the number of potential customers to specialized companies in the IT industry.

One bright day, however, somebody came up with the idea of decoupling hardware, the operating system (OS) and apps and enabling communication between them via open interfaces. So, instead of having one black box with all these elements sealed up, you could buy hardware, an OS and software separately, from different providers, or even develop your own specialized components and blend them into an innovative system. Disaggregation of the black box revolutionized the IT market, opening it up to new cohorts of customers. More companies could offer their products that were easy to integrate with other products on the market. No less significantly, the innovations could now be rapidly implemented and scaled (see Figure 1).

Evolution of computers

Fig. 1 The evolution of computers

The present stage of the networking, on the other hand, resembles the state computer architecture was in more than 30 years ago. Network services are today provided by a few specialized service providers whose operations are based on network devices that are very similar to early computers: black boxes that cannot be modified and are guarded by proprietary laws. As you’d imagine, such an infrastructure is very slow to adopt innovations, and only those functionalities that have been implemented by vendors can be used.

From this perspective, the SDN movement represents the same type of revolutionary change in the networking world as occurred in computer architecture many years ago. Instead of having an all-in-one solution, it is beneficial to decouple the components and use them separately (see Figure 2). They will communicate with each other via defined and standardized open interfaces. Thus different hardware and software providers can independently develop their own solutions that can be easily integrated into a network that better suits customers needs. Such an approach also considerably shortens the time-to-market for new solutions. Better still, modern service providers can compete by providing their own innovative networking functionalities that will differentiate their portfolio from others. This allows them to create a competitive advantage over competitors and spread fresh ideas across the networking market. This process is not unlike the innovative computer applications that flood the market every day.

Evolution of networks

Fig. 2 The evolution of networks

Control plane and data plane separation

Two notions are essential here: data plane and control plane separation. In the traditional network infrastructure that is most commonly applied today, there is a set of black boxes with dedicated hardware, an operating system and functionalities provided by networking vendors. This makes the whole infrastructure very difficult to manage (see Figure 3).

The traditional approach to network architecture--black boxes with hardware and network functions

Fig. 3 The traditional approach to network architecture

In the SDN approach, the underlying role of hardware is kept to maintain the definition of a data plane. Network functions, on the other hand, are moved to centralized software that defines the control plane by which, in turn, the data plane is defined. As Figure 4 shows, on the hardware there are only working agents that work as an interface between the hardware and the network operating system (NOS). The NOS, which in the previous model was installed on every device, has been moved to a higher layer. Network functions needed at a given moment can be installed on such an NOS. For example, if a routing application is called for, it is installed on the NOS, which in turn communicates with the hardware. The hardware behaves according to what has been defined in the app.

From an administrator’s point of view, this approach has very clear benefits (see Figure 4). First, the administrator has a good view of the network topology, which allows for better decision making, e.g. more efficient load balancing and better traffic distribution. Moreover, instead of configuring hundreds of devices, there is only one control plane to be configured, considerably minimizing the risk of mistakes being made. The configuration itself is compiled automatically, thus eliminating the human factor. To ensure that this configuration is error-free, more rigid automatic testing procedures can be applied, which adds the whole shebang of software testing methodologies. A good, automated test stack makes it possible to build networks with continuous integration/continuous deployment (CI/CD) methodology. And thus new functionalities and any network changes in the infrastructure can be deployed--with zero downtime.

Control plane and data plane separation

Fig. 4 Control plane and data plane separation

Business benefits of SDN

The advantages of SDN architecture naturally include business benefits of this new disaggregated model of network infrastructure. What are the main reasons companies invest in Software-Defined Networking solutions? The first, of course, is money: SDN helps bring down operating and capital expenses (OPEX and CAPEX). Secondly, such a network is more stable and at the same time more flexible, allowing updates and changes to be made faster. Moreover, the number of errors and downtime are reduced, as automation in many cases eliminates the human factor. Because admins have full topology visibility, SDN allows for more efficient network traffic allocation, especially when traffic peaks. It also enables the use of the full capabilities of expensive network equipment that in a traditional architecture may have been used only a fraction of the time. Last but not least, SDN creates an important technological advantage in networking. Introducing a new functionality in networks is extremely time-consuming and prohibitively expensive. Time-to-market is even worse, if there are multiple vendors in a network. So, if a company can introduce its innovations faster, it will gain considerable competitive advantage. This is precisely why tech giants including Google, Amazon or Facebook have adopted SDN in their production environments.

In 2011, The Internet Engineering Task Force (IETF), which coordinates the creation of new networking standards, received a request to make VXLAN protocol a standard. It took three years to review it, and only in 2014 was a version ready for productization created. VMware and Cisco were hard at work on this protocol, but had to wait a full three years before their innovation would be accepted as a networking standard. Other network device manufacturers, meanwhile, could start the long and complex process of implementing this protocol only after they were certain that it would be a new networking standard and its core would not change. No company can afford to wait for such a long time and expect to survive the rigors of the market. If such an innovation fails to become a standard, on the other hand, nobody will be able to use it without falling into the trap of vendor lock-in. This is one of the main problems SDN addresses.

SDN stack for one or more data centers

Consider the following example of SDN architecture for a single data center (see Figure 5). This is a traditional topology where there are servers on which virtual machines (VMs) are deployed. In the figure, the white rectangles stand for network elements, while the violet rectangles denote agents controlling hardware. Everything is controlled by Applications built on top of an SDN Controller Cluster. This control layer automatically configures hardware according to the current needs, e.g. when end points in the network want to communicate with each other, the SDN controller automatically configures hardware to enable or disable such communication depending on the applicable policies.

SDN stack for single data center

Fig. 5 Example of SDN stack for single data center

What if we want to orchestrate more than one data center and there are more types of control planes in these data centers that may not be compatible (see Figure 6)? In such a case we need an SDN Orchestrator. Currently, there are a few open source approaches to this problem, but none of them is ready to be deployed into production. However, there are commercial solutions already being used in production. SDN Orchestrators can communicate with different types of local SDN Controllers (that control networks in single data centers) to manage the connectivity and services across multiple DCs.

SDN software used to connect many data centers

Fig. 6 A SDN stack for a data center interconnection

Why isn’t SDN everywhere?

If Software-Defined Networking is such a good alternative to a traditional networking stack, why hasn’t every company with networking equipment deployed it? The answer is pretty straightforward: because it requires a huge investment. Of money, obviously, but also of time and effort, both of which are required when a company wants to develop a new skill set and train engineers and managers to properly use a complex new technology. I would say even more. To bring an SDN into production, it is necessary to move the standard network operation model to a software-like process; that is, to change the way we think about networks. This is a psychological barrier which is very difficult to overcome. Apart from that, to fully benefit from SDN deployment, at least partially compatible hardware is required, which also takes time and money.

Big business tends to favor stability and view new ‘revolutionary’ technologies with distrust. If something goes wrong with an SDN, the whole business may be at risk. Of course, nobody is going to just set out to create a totally new SDN infrastructure from scratch. It is much more probable that anyone with such a need will turn so-called brownfield deployments, where a new piece of infrastructure based on new technology is attached to an existing one. An SDN solution could be smart enough to communicate and manage the old networks. Last but not least, every automation makes sense only when used at scale. Given the amount of financial and organizational wherewithal required to deploy an SDN, it is simply not feasible for small organisations or small markets.

Apart from all that, there is one important hardware problem to solve. Programmable data plane, which will unlock the full potential of SDN, has not been proven in production yet. Currently, the field of open source solutions that enable the programmatic installation of network functions on network hardware by an SDN control plane is not as mature as SDN controllers. Nevertheless, there is a lot going on here, as there are promising open-source movements tackling the challenge. As an example, Barefoot Networks proposed a P4 programming language to define a standard language for data plane programs that run on merchant silicon chips. The P4 standard has been quickly adopted by networking hardware vendors and is currently maintained by Open Networking Foundation. Currently, P4-enabled switching chips are delivered by the biggest hardware suppliers including Broadcom, Mellanox, Netronome and Barefoot Networks itself.

SDN solutions currently available

So, If you’d like to use SDN now, what will you find on the market? To successfully use SDN, you’ll need hardware on which an open-source operating system can be installed. On this OS it should be possible to install an agent that will communicate with the control layer. Of course, you’ll need an SDN controller, too. Fortunately, the Open Networking Foundation (ONF) handles all of these. A good example of a full stack of fully functional, open-source SDN components is Project Trellis, which was recently and successfully deployed in a production environment. The foundation is currently working on the Stratum project, an open source silicon-independent switch operating system for software-defined networks that can be installed on white box switches. The ONF has also developed a standardized communication protocol running between the controller and hardware. Network switches are provided by multiple vendors in brite box model, i.e. branded products. Brite boxes are production ready and built by experienced network hardware vendors. They can be used with open operating systems delivered by other software companies, e.g. NOS from Pica8 can be run on top of Edge-core, Dell and other brite-box hardware.

Moving to high-level software components, there is also integration with the Controller's northbound interfaces, which are the entry point for SDN orchestrators. At least two open source orchestrators are worth noting: XOS, an SDN orchestrator for mobile, enterprise and access networks (part of the ONF’s CORD platform); and ONAP, a high-level orchestrator and lifecycle manager that has yet to hit the production stage.

SDN production deployments

A bit of spot research to find out who has deployed SDN solutions, and on what scale, yielded up an impressive list. First and foremost there is VMWare’s NSX, a commercial SDN solution. According to the company, by the end of 2018 it was being used by more than 1700 companies among which almost 400 with 1 billion USD or more in annual revenue. Facebook, Amazon and Google have all long had proprietary SDN solutions, but Google is also cooperating with ONF on open-source solutions. Then there is Equinix, which offers a solution to create a private connection from one continent to another in just 5 minutes. Comcast, on the other hand, has deployed a complete open source SDN fabric called Trellis, which went into production in September. Using open source products to create a production deployment saves considerable amounts of money, as the cost of networking solutions can be sky high. When it comes to a programmable data plane, it is also interesting that Cisco is using Barefoot Network’s Tofino chip for its Nexus 3400 series switches. The chip has an open-source standard P4 interface that can be controlled by a higher control layer.

The future of SDN

The main challenge related to SDN is the psychological barrier in deploying it for production. Nobody is willing to take too much risk, leaving everyone fretting over what competitors are doing to get out the first production deployments. The big players are currently working on open source-based deployments and, if they prove successful, companies large and small will doubtlessly follow suit. That one of the biggest network equipment vendors has decided to use the merchant silicon chip, the very symbol of data plane freedom, speaks volumes. On the other hand, the big telcos deploy open-source SDN fabric and cloud service providers have been using proprietary SDN technologies for years now. All these developments lead to the conclusion that SDN is the future of networking, and that’s that. Every enterprise, telecom, Internet service provider--heck, basically all big companies will eventually have to migrate their infrastructure to an SDN.

SDN and NFV CodiLime services

About the author


Michał Mach

SDN/NFV Solution Architect
CodiLime’s SDN and NFV Architect, Michał is passionate about bringing networking and software together. He has delivered multiple SDN/NFV projects at global R&D centers and has worked closely with Open Source SDN projects. After hours he’s a newbie father, a reader of fantasy novels and an audiophile.

Contact us

For more information see our Privacy policy