Software-defined WAN is one of those terms that’s vague enough to be applicable to a lot of things, but the core reality is a fairly classic “overlay model” of networking. An overlay network is a layer on top of the “network protocol” of a real network, an overlay that provides the connectivity service to the user and uses the real network protocol (or protocols) as a kind of physical layer or virtual wire.
We’ve had SD-WAN overlay concepts around for many years. In a very limited sense, many IP networks are overlays that add an IP layer to Ethernet or another Level 2 technology. The whole OSI model in fact is a series of overlays. But the SD-WAN concept’s real birth was probably the work done by Nicira, the cloud-network player who was bought by VMware. Nicira recognized that you could use overlay networks to build connectivity for cloud data centers without the constraints that exist in “real” network protocols and without the need to involve physical network devices in what was “virtual connectivity”. SD-WAN technology extends this model, one of the forms of software-defined networking or SDN, to the WAN.
The early SD-WAN products aim at one of several major goals. First, they create a very agile connection-layer service that can easily build a virtual private network without the headaches and costs of something like MPLS. Second, they can build a unified virtual network across locations that don’t have a common real-network connection. Users like this because they can use traditional MPLS VPNs in major sites and add in minor sites or even transient locations through an SD-WAN that supports both underlayments. Finally, they can use the Internet as an adjunct to private VPNs or to create a wider pipe for a period of time.
SD-WAN has carved out a nice but not enormous market in these areas, and while all of them are valuable it’s not likely that these three drivers would result in explosive growth. That doesn’t mean that SD-WAN doesn’t have potential—it may end up being as important or more important than SDN or NFV, and in fact be a critical enabler of both.
One obvious mission for SD-WAN is the creation of agile virtual networks over a combination of traditional L2/L3 technology and SDN. Using SD-WAN I can build a VPN by creating SD-WAN tunnel meshes of all my endpoints over a common, evolving, or disparate underlayment. If I use NFV to deploy interior router instances, I can create a virtual topology of nodes and trunks (both virtual, of course) that aggregates traffic and eliminates the potential inefficiency or lack of route control that meshing could create.
The use of SD-WAN could mean that connectivity, meaning the service connection layer, resides only in endpoints or in hosted instances that are dedicated to a service or user. This would make provisioning new endpoints or changing services trivial; no real hardware would even have to know. If my underlayment offered grades of service representing QoS and availability options, I could offer various SLAs from this, and change QoS and SLAs easily without interrupting anything.
If I used SDN to build only virtual wire tunnels, I could build services entirely from software elements. This would clearly scale to support VPN/VLAN services and probably also to support content delivery networks, mobile Evolved Packet Core, and even IoT. With some reasonable way of managing Internet services as predictable sessions, I could probably support most of the demanding Internet applications for content delivery and ecommerce.
In both SDN and NFV and in the cloud, you have a presumptive “virtual network” built in data centers and across data center interconnect (DCI) trunks. In the cloud, these virtual networks are most often subnetworks linked to the Internet or a VPN, meaning that they’re a homogeneous part of a larger network. In NFV, the presumption is that these networks are truly private, with only selected ports adapted into a broader address space. SDN and SD-WAN could create a hybrid of these models.
Suppose I build an SDN network to link application components in a data center complex. Yes, I can gate these to a larger address space like always, but suppose that instead I consider these to be a series of separate networks, independent. Now suppose that I have a bunch of users and organizations out there. With the proper software (SD-WAN, in some form) I link users or groups of users (themselves formed into a separate network) with applications selectively. I don’t have a uniform address space for every user, I have a composed address space.
Composed address spaces may seem hokey, but they go back a long way conceptually. When switched-virtual-circuit services like frame relay and ATM came along, there were a number of initiatives launched to exploit these (if they became widespread, which they did not) for IP. One of the protocols invented for this was called the “next-hop resolution protocol” or NHRP. With NHRP you surrounded an SVC network of any sort (the standard calls these networks “NBMAs” meaning non-broadcast multi-access to show that traditional IP subnet processes won’t work) with a kind of IP ring, where each ring element maintained a table that showed the NBMA address for each remote subnet. When traffic arrived there, the ring station simply looked to see if the associated ring station for the subnet was already connected, and if not connected it. SD-WAN composed address spaces could be similar, except that they translate a remote application address in its own space to the address space being composed.
These features all make SD-WAN the perfect companion to SDN and NFV because they illustrate that SD-WAN can virtualize the service layer independent of what’s happening to layers below. That’s the value of overlay technology. The agility benefits, and the ability to decouple service-layer connectivity from transport infrastructure, are so profound that I think it’s fair to say that SD-WAN technology is the best option for VPN/VLAN services. In addition, its linkage to cloud data center connectivity means that it could revolutionize NFV managed services, cloud computing service delivery, and even (by creating explicit connectivity versus permissive networking) security.
Obviously SD-WAN is a threat to established service-layer paradigms, particularly box-based IP, and for that reason it’s going to be heavily opposed by the big-name players like Cisco. The question is whether those who could benefit from it, including obviously the SD-WAN vendors but less obviously companies like Brocade who have world-class software routers and Nokia whose Nuage SDN architecture has all the right interior components, will position their assets better. Complementing SD-WAN or (in the case of Nuage, offering an alternative implementation model) could be a big win for them, and ultimately for the market.
The big question will be whether the network operators or managed service providers jump on SD-WAN technology in a big way. Verizon has launched an SD-WAN service and MetTel has a competitive-carrier SD-WAN service aimed at the MPLS VPN space. None of these has so far created a serious threat to incumbent VPN technology, but the potential is there, and a big shift could come literally at any moment. SD-WAN could even be a first-deployed technology, paving the way for adoption of SDN and NFV by disconnecting the service layer from infrastructure. We’ll have to watch for developments, and I’ll blog on the important ones as they occur.
