When you buy through affiliate links in our content, we may earn a commission at no extra cost to you. Learn 
Introduction to Software-Defined Networking
While it's fairly easy to get a generic description of what software-defined networking is, different sources are going to provide different descriptions, because this general IT architecture can be set up in many different ways. SDN isn't something that's monolithic in terms of its build – it's a central concept that companies are using to revolutionize IT products and services.
At the most basic level, software-defined networking is a networking technology that centralizes network management in a smaller number of components – the way that software-defined networking does this is to decouple the control plane from the data plane, which we will talk about more later.
Think of it this way – in more traditional networks, each individual network switch and component had its own decentralized control processes. By taking away this kind of atomized design and consolidating a lot of the control in a single “head” component – or a similar structure – vendors and other parties are able to help companies to scale hardware and software systems more easily. Instead of every single point of the network having all of its own controls, engineers place the control in a limited number of spots, saving key resources.
The key here is that this can be done in a variety of different hardware environments. Virtualization, a fairly new process of abstracting network components, has allowed for some of the innovations in software-defined networking, where smart applications or software programs run the networks. While smart hardware pieces can work together to offer software-defined networking systems, it's also possible to do away with a lot of the hardware completely and use virtualized setups instead.
Now, big companies have started to endorse the idea of SDN, and new products offer it through more sophisticated systems. Many “flavors” of SDN help companies to achieve efficiencies – to build networks that are, in some senses, “smarter” because they have smart software running their routing protocols.
The evolution of SDN is also taking place in a larger context – there's also the idea of a SD-WAN, which applies the same concept to a wide area network. With the emergence of cloud technologies, there's more of the SaaS model being applied to remotely manage systems, and “software-defined IT” is a new frontier.
It's important to understand that the world of SDN is diverse.
“In the broadest sense, any software that manages a network of dynamically assigned addresses – addresses which represent services provided or functions performed – is utilizing some variety of SDN,” writes Scott Fulton III at ZDNet, explaining that the term arises to distinguish new software-driven models from old hardware-driven ones and boiling down the idea of SDN into four words: “SDN is networking now.”
The Control Plane and the Data Plane
It's hard to move forward in explaining software-defined networking without getting into the control plane and the data plane – what they represent, how they work together and how they might be separated.
The data plane or “user plane” of the network manages the forwarding of packets through the network. In traditional systems, the controls were built into the same avenues as the data forwarding components. Now, that's no longer the case, and all the data plane nodes do is forward packets. By contrast, the control plane is the “routing” plane. The control plane will route packet data and configure how the network moves data.
Some experts refer to the control plane as the “brains” of the network and the data plane as the “muscle.” Certainly, the task of simply forwarding packets is much more of a rote process than routing, and untethering these two would lead to these sorts of comparisons.
Another way to look at this is to explore how control and data planes are used in the industrial process. Components like programmable logic controllers are applied to industrial processes to manage what goes on throughout these physically directed networks. Data plane functions relate to the use of SCADA protocol to, again, direct the forwarding of packets for the flow of information. The control plane is where the “head” resides; it's where data will be used, for example, to alert a human operator if sensors and programs in the distributed line architecture see a high incidence of defects coming through the line, or a need to alter or recalibrate techniques for sealing containers, etc.
That's SDN in a nutshell: by isolating the control plane, it's changing the game in terms of how we view, operate and use network resources. That doesn't tell the story of how each individual instance of SDN is set up – but it tells the story of how we figured out that splitting the control plane from the data plane has big potential in changing network infrastructure.
History of Software-Defined Networking
Another way to understand software-defined networking is to look at where it came from.
One of the earliest examples of this type of idea is early networking systems in which individual hosts were able to talk to a central mainframe. These setups, pioneered in the latter part of the 20th century, are pretty primitive by today's standards – you could describe them as “feedforward” in that the communications only went one way. The process of decoupling the control plane and data plane hadn't been done yet.
Some sources offer the example of the public switched telephone network as one of the first ways that engineers started to separate control and data planes and move toward what eventually became a software-defined networking strategy. Others will note the use of peer-to-peer networks in the 1980s and the rise of micro-computing as another part of the basis for our modern software-defined networking principles. Essentially, scientists started working with the idea that not every routing signal had to be resident in its node – and building that philosophy into diverse systems.
One of the simplest ways to explain this is that over time, the scientific and IT communities were able to slowly innovate how networks function, and where control processes are located. When big vendors like Cisco started to get on board, the whole process of enhancing software-defined networking got supercharged. Again, as cloud computing took off and virtualization became a standard, SDN became a more vibrant discipline in the tech community, within the general category of “software-defined IT.” As cloud computing was born and developed quickly as a revolutionary way to offer nearly any kind of service, network administrators saw the cloud paving the way for the software-defined network models – prior to cloud computing, all of those pieces had to be sourced in the same hardware location, so there wasn't the same focus on innovating some of these types of frameworks. Cloud computing, software as a service and virtualization generally spurred a lot of the design work that led the vanguard of data scientists to consider separating the control plane from the data plane in the precise ways that we're talking about with SDN.
Open SDN and OpenFlow
Before everyone jumped on the software-defined networking bandwagon, an early central standard emerged called OpenFlow. OpenFlow is an open-source communications protocol that does that fundamental job of separating control and data planes from one another.
In OpenFlow design, network controllers route traffic across a network. Part of this is done by making the OS layer 3 or network layer more versatile.
OpenFlow was pioneered in 2011 and maintained by the Open Networking Foundation.
One of the most important things to know about OpenFlow is that for a while, it was the only way to really practically pursue software-defined networking. However, as industry experts point out, today there are many vendor-specific protocols. The idea is that big tech companies wanted to be able to offer software-defined networking themselves – so they built their own ways to offer it. They wanted to compete with the idea that companies would move toward the open-source solution and away from their traditional products.
As for the benefits of OpenFlow, experts have identified several reasons for the popularity of OpenFlow, including a greater ability to swiftly introduce new network features and services, simple provisioning and optimized performance.
As an example of tech companies implementing OpenFlow, in response to the growth of OpenFlow adoption, Cisco came out with “Cisco OpenFlow” modeling using OpenFlow-enabled switches. Now, the SDN world is progressing “past OpenFlow” as new opportunities emerge, which we will talk about a little later.
Software-Defined Networking as a Service?
As mentioned before, software-defined networking exists in the context of new software-as-a-service and cloud computing paradigms. That leads to a lot of discussion about the future of software-defined networking and the emergence of new network-as-a-service or NaaS implementations.
The general idea is that the concept of software-defined networking is going to drive NaaS. As we get better at making SDN implementations, it will allow vendors to more effectively offer NaaS through the cloud.
Readers of our blog will know that we have been advocating for some time that SDN is a lot more than just the separation of the network’s control and data planes, and that OpenFlow is “merely” a mechanism (not the only one) for SDN controllers to pass forwarding instructions to the underlying infrastructure,” writes Steve Harriman in a Packet Design article in 2014, calling network as a service “the real promise of SDN.” Packet Design's SDN product won the 2016 SDN Product of the Year Award and provides unique evolutionary SDN design.
“Our industry often gets lost in the technology details and misses the point, which in this case is about creating malleable network infrastructures that flex efficiently with business demands. The really interesting, valuable, and … hard work is to supply the controllers with the intelligence they need to make smart infrastructure changes,” Harriman wrote, going on to talk about how to deliver NaaS in theory, requiring centralized intelligence.
The reality is that businesses have been making SDN-driven NaaS real – in reporting from Fierce Telecom at the end of 2016, we see Orange Business Services preparing to launch its own NaaS offering based on the premise of SDN.
Items like value-added network applications and IoT applications can also be evolved with SDN and SD-WAN technologies.
The Joint Path: Vendor and Open Source SDN
As some of the above businesses and other parties move toward proprietary NaaS solutions and other SDN implementations as commercial services, the open source community is also taking a hard look at software-defined networking through a new project called OpenDaylight.
Pioneered in 2013, the OpenDaylight project is hosted by the Linux Foundation, and supports open-source collaborative work on software-defined networking and network functions virtualization progress.
While OpenDaylight supports OpenFlow, it also inherits aspects from the proprietary code bases of big tech companies like Cisco that traditionally offered network switches and other gear.
In a blog post about OpenDaylight, Tom Nolle, president of CIMI Corp., makes three points about software defined networking – first noting that OpenFlow as a protocol is available to achieve SDN goals – secondly, pointing to a central mechanism for packet forwarding or routing – and thirdly, calling for a service conception around that control infrastructure.
“In the SDN world, we’ve seen a polarization of solutions based on which of these points are most important,” Nolle writes. “Can you build 'SDN' if you can create services—'Networking-as-a-Service' or NaaS—regardless of how you do it? Can you do SDN without central control, without OpenFlow? All valid questions, since buyers of next-gen networking will buy or do what is useful to them, which might be any or all of these things.”
Calling OpenDaylight a “mind-opening experience,” Nolle portrays this new standard as a controller model that opens up network protocols and diversifies the types of legacy devices supported.
This type of progress is another aspect of how SDN is “taking over” the networking world, and why traditional, static networks in individual hardware rooms might soon be a thing of the past.
For an interesting look at proprietary systems and OpenFlow, it's helpful to go back to the example of Cisco, a top provider in the space, and Cisco's campaign to develop what it called OpFlex several years ago.
In 2014, tech media outlets were churning out articles differing over whether OpFlex was an “OpenFlow killer” or not.
“Cisco’s OpFlex protocol is intended to maintain control intelligence in the network infrastructure itself instead of centralizing it in a separate controller, which is the essence of the OpenFlow control/forwarding decoupling model,” Jim Duffy wrote in Network World that April, further explaining that Cisco was “reinventing the OpenFlow wheel, proposing a new protocol where one already exists, though its objective is different.”
Michelle McNickle at TechTarget pointed out that OpFlex was “meant to be embedded in the device or host via the policy agent.”
Experts pointed out how OpFlex proposed a different connection to Application Centric Infrastructure (ACI) than what was already available with OpenFlow.
This case study shows how the two different kinds of systems have collaborated in offering software-defined networking alternatives as SDN progresses.
Software-Defined Networking and the Visual Dashboard
Let's talk a little bit about how software-defined networking works – practically.
Right now, we're in the age of the visual dashboard – where vendors and software producers are trying to make everything as visual as possible, to achieve the goals of offering 'intuitive interface.' People want to see pictures of what's going on in a highly complex digital environment. They don't want to have to read about how controllers work, or where data is going. They want that information at their fingertips in the form of visuals.
With that in mind, users often get a good picture of software-defined networking concepts through a visual dashboard that shows, for example, where the control plane “head” is and how it relates to the distributed control nodes or switches that have resident data plane structures built into them.
For example, an engineer might draw a dashboard with an SDN controller at the top, and lines to SDN agents embedded in Ethernet switches or network nodes. The visual dashboard may show the location of hosts within this architecture, and how information bounces through the network. Of course, the visual dashboard can also include all sorts of metrics and data about packet flow and what kind of information is moving through the system. The visual dashboard can show all sorts of protocols related to handling information or packet flow. You get the idea.
Because it's visual and not constrained to the archaic format of explaining something through paragraphs of text, the visual dashboard for software-defined networking can really be the network administrator's handbook. People can learn at a glance how the architecture is set up, how to change it, whether any inefficiencies or problems exist, and exactly what's going on inside the system at a given time. Think about pursuing a desired state, optimizing workflows and eliminating bottlenecks or silos. All of this is aided by intuitive interfaces that show users what SDN is doing. That's regardless of how much of a service is located in the cloud, whether any fiber-optic cable is involved, or whether the company is using containers, or vendor systems like AWS.
The idea of orienting SDN users with a visual dashboard goes back to the idea that SDN systems are diverse. There is no one-size-fits-all model. So it makes sense that these visuals, crafted by vendors or whoever is working on SDN, will orient everyone to not only how the system works, but how to control it, monitor it or otherwise manage these highly involved next-generation networks.
Conclusion … Thoughts on the Future of SDN
Looking at all of the choices that companies have right now to source “programmable” network technologies, you could say that the future of software-defined networking is already here.
However, that's kind of simplistic – like saying, for example, that the future of the cloud is “already here.” Cloud services are robust, but won't they continue to evolve?
Some of the things to look for with SDN are more of the popular “plug and play” network technologies that we already see in nascent NaaS architectures: for example, visual widgets to add things like firewall as a service or parental control as a service to a network.
Will the companies of the future subscribe to their networks, instead of building them in server rooms? In some cases, yes. In others, probably not. Certainly, the convenience of this method will stand out to busy startups.
One of the exciting things about SDN is its ability to simplify network design. If you order these things through a subscription, as a user, you may be able to see them as more transparent units – going back to that visual dashboard example, you can see them in a more visual way.
Lots of tech professionals have found that sometimes it's easier to visualize or imagine how technology works when it's ordered from a vendor (with good support) than when it's in some sort of a black box system in a hardware rack.
In other cases, software as a service shields the user from having to understand the true mechanics and what's behind the sheet. It frees them up to use the technologies without getting stuck in a loop trying to figure out why they do what they do. On the other side of the coin, it also can hinder someone's access to change if it abstracts the knowledge that they need to control the technology. That's why terms like “vendor lock-in” are so important when you're looking at something like an SDN service-level agreement.
Let's talk a little about IoT – the internet of things is now taking off in a big way. It's one of those new boundaries in IT. But SDN actually has quite a bit of application to the idea of IoT-connected devices in a very distributed and chaotic network.
With centralized control, it may be easier to design some of those big peer-to-peer or ad hoc networks that function in an IoT environment. With that in mind, software-defined networking has something to offer the engineers that are currently working on brand-new systems based on some different models than what we've been accustomed to in the past.
Going boldly into the 21st century means understanding how technologies like software-defined networking are going to be applied in enterprise environments, and what it's going to mean to really effectively manage a next-generation network.
