There has been a lot of recent discussion about SD-WAN technology and its potential. Not surprisingly, most of it has been marred by our industry tendency to over-generalize, to seize on a term that describes a host of options and presume that all the options are really the same. SD-WAN is really important, but not all its options have the same mission or potential.
The common theme of SD-WAN is the use of edge devices to establish what are effectively VPN services. The earliest examples of SD-WAN focused on using Internet connectivity to supplement traditional (MPLS) VPNs in places where either there were no MPLS options or where MPLS VPN pricing was prohibitive. These SD-WANs usually supported multiple (MPLS and Internet) connectivity, and often also allowed their users to use multiple ISPs to improve performance and reliability.
This particular SD-WAN mission is clearly tied to arbitraging the price difference and SLA differences between MPLS VPNs and the Internet. That differential depends on a bunch of factors, perhaps the largest being the presumption that there will never be Internet QoS because there will never be paid prioritization on the Internet. That’s a regulatory policy issue, and in the US at least it’s likely that the mood of regulators is now shifting the other way.
You can state the SD-WAN mission another way, though. You could say that the goal of SD-WAN is to present a uniform IP-connective service over a variety of lower-level connectivity options. The MEF people told me over a year ago that SD-WAN could be a big part of a successful “Third Network” deployment because it could support consistent services as operators shifted from one underlayment (MPLS, Ethernet, whatever) to another.
It’s this second mission that I think will really shape SD-WAN over time. It doesn’t have radically different technology requirements, but it would weigh the requirements differently and would also be marketed and deployed based on different drivers. Today, the primary driver of the service is the control of VPN profit per bit. For the future, operators see it as a way of making network technology evolution more seamless.
Up to now, SD-WAN has been either a managed service play or an option for connectivity deployed by users themselves. There’s been, recently, just a hint of the broader second mission, driven according to operators I’ve talked with by the need to cope with continued price pressure on VPN services. One operator told me that in the last seven years, the capital cost of VPNs has declined by about 18% and the opex has almost doubled. A big part of this is related to the need to go down-market to sell new customers, given that current ones expect their services to get cheaper with every renewal of the contract.
This same profit-per-bit pressure is behind the drive to virtualize things, to build services a different way. SDN technology is a good way to create services that do essentially nothing but forwarding, for example. An SDN switch doesn’t really know anything about topology or even about IP, it has a forwarding table that it matches things against, and handles each packet accordingly. Is this an IP network? No, and Google among others has demonstrated that if you want to use SDN in place of IP you have to add in some things that an IP user would “see” that SDN won’t provide. You can do that if you have a piece of CPE that creates the VPN service edge, which means if you have SD-WAN.
If you have a piece of “new-age” SD-WAN CPE, you could say that it divides itself into two pieces. One is the user-side functionality, which is responsible for creating a network interface that looks like the kind of VPN or VLAN or whatever service the user expects to see. The other is the network-side functionality, which is primarily responsible for framing the connectivity of the service in the terms of the actual network capability. If your SD-WAN uses MPLS, this is where the MPLS link has to be made. If it uses some kind of secure tunnel over the Internet, it’s supported here. If it expects SDN connectivity, or optical virtual wires, it’s connected here.
It seems pretty likely to me that future services will tend to be constructed using SD-WAN technology like this, because future services will likely evolve from the use of different connection services at the network level. It also seems to me that there are many different SD-WAN technologies today that either don’t fit this approach at all, or fit it with significant limitations. Those may or may not be useful, depending on the way that connectivity evolves.
If the FCC in the US were to sweep away all restrictions on inter-ISP settlement and paid prioritization of traffic, we’d end up seeing an Internet that had QoS. That would quickly become the baseline for providing VPN services because it would be significantly less costly. In this scenario, we would see SD-WAN VPNs evolve to exploit IP features that are naturally visible at the edge, and you would want your boxes to have some form of box-to-box high-level (Level 4) signaling to mediate the services at the user level. If, on the other hand, we never see any QoS on the Internet, then it’s likely IMHO that VPNs will split off from IP to exploit SDN, NFV, agile optics, and so forth.
Logically, what we should want from SD-WAN is a kind of modular structure to handle both situations. You have a plugin for the user connection, and this is the feature set that defines the retail service. You have another for the network side, matched to the specific technology you’re exploiting there, and you mix and match them as needed. This would be easy if you had software plugins, features/functions that could be installed in an agile premises device.
This may be the future mission of vCPE, and the most powerful stimulus for NFV-like deployments. What users want and need on the premises, first and foremost, is a service interface to plug into. If there is only one option for service, then the value of agility is limited. If we’re in a serious state of network technology evolution, then agility is everything, and the SD-WAN model may be the best, even only, way to meet future goals.