Since networking is a kind of massive cooperative behavior set, it’s not surprising that the critical networking technology “revolutions” we face have a relationship. What is surprising is that the relationship isn’t all that clear. Software-defined networking (SDN), network functions virtualization (NFV), and software-defined wide-area networking (SD-WAN) share some technology elements and they may also be related in a business opportunity sense. In fact, that relationship might be critical and so we need to look at it a bit more deeply.
SDN, if we accept the “purist” notion of white-box switches or virtual switches controlled by the OpenFlow protocol, is really about using central device control to define routes in a network. Each device is told how to handle packets based on their header, and the combination of handling instructions creates the routes that carry traffic.
You can see that SDN is about routes, which means it’s about the connectivity that networks provide. You can use SDN if you “own” a network, whether it’s a LAN or WAN. That doesn’t necessarily mean that you have to own fiber and microwave and so forth, because SDN could be applied to networks built from tunnels as well as those built from real physical facilities. You don’t necessarily need white boxes either; many legacy switches/routers will accept OpenFlow, and you can use virtual switches or routers. You do need to own switching/routing elements. The largest SDN application today is inside the cloud, where SDN is used to connect cloud components in a data center.
NFV is about using software features, hosted on something, instead of using specialized devices or appliances to provide some network feature set. What NFV, as a standard or spec, does is describe how to deploy, connect, and manage these software features. What features? Generally, NFV targets either higher-layer network features like firewall, encryption, or VPN encapsulation. It could also be used to deploy service elements like DNS and DHCP, and even to deploy instances of virtual switches and routers.
NFV, then, is about service features/elements. It follows that you can deploy SDN elements using NFV, and if you think about it you can also presume that SDN could be used to connect NFV elements once they were deployed onto something like a server. In an NFV application, you could make use of SDN almost anywhere you needed a connection. The question is where NFV comes in. NFV was designed for network operators who deployed services made up of complex features. It could be used by enterprises in theory, and we’ll get a bit more into that below.
SD-WAN is a bit of an outrider here and perhaps the hardest of the three to actually understand. The basic principle of SD-WAN is that it’s possible to build a “virtual network” on top of one of many different physical networks or network services, and as long as that virtual-physical mapping works, the stuff on and inside the virtual network wouldn’t know what was being used. Thus, you could build a “VPN” with some sites connected via MPLS VPN services and others connected through Internet tunnels, or you could mix both services at some or all sites and use them to back up or augment each other, or for different classes of traffic.
Unlike SDN and NFV that are about putting stuff in the network in some way, SD-WAN relies on the stuff at the edge of the network. It’s the SD-WAN edge element that creates the virtual network, manages how it connects users/sites, and maps it to whatever physical/services connections are available. That includes not only traffic mapping virtual-to-physical, but also the management of the network service options so that virtual network users don’t get involved with the plumbing.
Interestingly, SD-WAN might exercise more SDN principles for enterprises than SDN does. The original SDN concept, from Nicira, was an overlay network that didn’t force any changes to the connection infrastructure in place, whether it was Level 2 or 3. Overlay networks let users manage connectivity independent of transport, segment networks without operations penalties, and accommodate multiple service choices. SD-WANs codify all of this.
The introductions here present the “basic” affinities among the three technologies, but we’re actually circling through some changes that could create even more affinities. We could look at these changes through the lens of any of these technologies, but I’m going to use SD-WAN as the framework for reasons that (I hope) will become obvious.
SD-WAN is an edge technology, as I’ve noted. Edge technologies can be deployed using NFV via what’s now called “service chaining” and “virtual CPE” (vCPE). The idea is that if you need an SD-WAN you could load that feature into an edge device, along with other security tools. This hasn’t been talked about much to date, but IMHO it might be the best argument you could make for vCPE because while most enterprise sites already have basic network features like security tools implemented in CPE, few have yet adopted SD-WAN.
Another reason operators should love SD-WAN as a vCPE mission is that SD-WAN builds on VPN services without nailing them to a specific implementation. You could build VPNs the current way with MPLS, or with Internet overlays, or with SDN and embedded virtual routers—you name it. This is useful for operators even in-region where they have to contend with multiple access options or where access is evolving. It’s critical out of region, of course, because you could offer Internet extensions to MPLS (or other provisioned VPN models).
SDN can also be used to provision the forwarding processes within an SD-WAN device, just as it is already to set up virtual switches. Since you can, as I just noted, use SDN inside an SD-WAN as a service option, that lets operators bridge between SDN-based and traditional implementations of business (or, in theory, residential) services. Some operators might see this bridging as a risk; buyers might adopt SD-WAN to wean away from MPLS-based VPNs, and that might be why we don’t see SD-WAN taking a leading role in NFV vCPE interests and trials.
In the longer term, I think that SD-WAN may need to be a bit more accommodating itself. The virtual-overlay-network nature of SD-WAN seems to get swept under the rug in a lot of SD-WAN product positioning. That may be because vendors fear other approaches, perhaps even growing out of more traditional vCPE VPN solutions, could steal their thunder. The problem with this protectionism is that if, as I believe, we’re moving toward a newer model of business networking based on virtual wires and virtual switch/routers, virtual overlay networking is then going to boom in its own right. It would be smart for the SD-WAN vendors to think about getting in on that now.
The fact that SD-WAN symbiosis with SDN and NFV hasn’t been developed so far isn’t a technical issue but one reflecting the complex business situation that prevails. Network operators and the major incumbent network equipment vendors alike have reason to fear SD-WAN because it could dilute spending on traditional VPNs and VPN-related equipment. It’s difficult now for a technology concept to gain traction without strong backing from big players who will pay for advertisements and analyst reports. We do have a number of credible SD-WAN solutions, though, and if some of these vendors can make the connection with SDN and NFV, they might be able to move the ball on this at last.