Everything You Always Wanted to Know About SD-WAN Architecture (But Were Afraid to Ask)
Woody Allen directed and starred in a film with a similar name in 1972 that got a lot of attention and was a commercial success.1
Like SD-WAN (software-defined wide area networking), the benefits of this topic (e.g. agility, performance) were well marketed. And many of the functional aspects were generally understood: single-click setup and simple yet powerful workflows, for example. Read why Forrester thinks the future of the WAN is software-defined >
As with new products and technologies, many potential adopters were keenly interested but hesitant to commit to a proof of concept without learning more. So, they went to the movie.
I’ve been curious about the architectural underpinnings of SD-WAN for some time. But afraid to ask. Eventually, I got up the nerve and went looking. Here’s what I found. Brace yourself.
“I mistakenly assumed that control planes and data planes would always be wedded in monogamous relationships and reside happily together in suburban network nodes.”
Liberation of the control plane
A key architectural feature of SD-WAN is that the control plane is, shall we say, divorced from the data plane of the network element (i.e. router). This unshackles the control plane to function in a centralized manner and direct the flow of packets through many, many network nodes.
Take a moment to let this sink in if you mistakenly assumed, like I did, that control planes and data planes would always be wedded in monogamous relationships and reside happily together in suburban network nodes. Don’t get me wrong, though. I’m not saying the control plane is operating promiscuously. It’s just liberated.
With SD-WAN, the control plane lives in a luxury IT flat where it “has a broader perspective of the resources under its control, and can potentially make better decisions about how to deploy them,” according to the SDN Architecture Overview published by the Open Network Foundation. “Scalability is improved both by decoupling and centralizing control, allowing for increasingly global but less detailed views of network resources.”2
Not something most of us would say in polite company, eh?
SD-WAN data plane devices live by a list of dos and don’ts. In the normal course of operation, they route traffic according to rules previously passed from the controller. Packets will be forwarded down one path or another depending on the associated application, users, etc. as coded into the rules.
When an unfamiliar packet arrives at an SD-WAN device, like the odd bloke or woman chatting it up in a pub, a data plane will issue a route request to its controller as if consulting with a friend.
“It’s a charming packet but I’m concerned about security and not sure whether I should forward it. / You know the family? Well, that makes me feel better. / I’ll get a phone number and send it through an Internet connection.”
The SD-WAN controller also keeps tabs on network capacity and demand. When a link gets congested it will direct the data planes to re-route packets to keep traffic flowing smoothly.
“Hello VoIP. It’s data plane. / About our dinner date this evening… The MPLS Bistro won’t have a table until 8:45 PM. Let’s go to Café Broadband instead. It has an excellent menu and a low-latency atmosphere. / Wonderful! Ta-ta for now…”
In the dominant position
At this point, you might think the control plane is calling the shots in the SD-WAN architecture but there’s a third layer, the application plane, that actually dominates the hierarchy. SD-WAN applications direct management, security and other specific functions through the control plane. So, while the data plane is entirely submissive, the control plane switches between dominant and submissive roles.
Information collected by a controller from network devices, including statistics and events, is passed up to applications that build an abstracted view of the network for reporting and decision making purposes.3
“Researchers found that SD-WAN enables much quicker “hook-ups” between nodes and increases the likelihood that full-mesh topologies will be deployed.”
Network data can also be used to facilitate academic research. Analytics software running in the application plane provided key insights to a pair of pioneering scientists. They developed a four-stage model of network response during the business day: network arousal, traffic plateau, peak activity, and resolution. Some WANs, like those associated with securities trading, can experience multiple peaks of activity without a refractory period.
The researchers also contrasted behavior of network nodes with/without SD-WAN in various configurations. They found that SD-WAN enables much quicker “hook-ups” between nodes and increases the likelihood that full-mesh topologies will be deployed.
Climbing down from the ivory tower
That’s enough about academic research. In the real world, an administrator can use an SD-WAN management application to visualize what is happening on the network and make changes as needed.
For example, he may configure the SD-WAN policy engine to give unified communications traffic a high priority and forward it along low-latency paths throughout the network. A second policy could be established to protect confidential information by sending packets associated with financial applications or executive users through only the most secure pathways. These business intent policies are translated into rules sent to a controller and then to physical network devices.
Another example of an SD-WAN application is an analytics engine that crunches through network data looking for suspicious activity. This intrusion detection system recognizes malware traffic based on the flows tracked by a controller and sends instructions to automatically isolate those packets before they can infect the network.4
Other things you always wanted to know
The functional separation of application, control, and data planes is just the architectural starting point for SD-WAN. Technologies needed to make it all work include protocols for inter-layer (inter-plane) communication, network virtualization, automation and orchestration through programmability, and others.5 Network virtualization is an especially interesting subject with tunneling in virtual privacy, overlays, etc. But those topics will have to wait for another day, another blog post, and another quirky theme.
Inspiration and references
1“Everything You Always Wanted to Know About Sex* (*But Were Afraid to Ask)”, Film. Wikipedia.
2“SDN Architecture Overview v1.1”. Open Networking Foundation, November 2014
3“What’s Software Defined Networking?”. SDxCentral.com
4“The Application Tier of a Software-defined Networking Architecture”. Amy Larson DeCarlo. TechTarget Search SDN, January 2012