We now have a pretty good idea what SD-WAN looks like, at least in its basic form. We can infer, from things like the MEF draft SD-WAN standard, what some SD-WAN future developments might be. What we really need to do is explore the future of SD-WAN in a more formalized way. SD-WAN, as I’ve said, is a step toward Network-as-a-Service (NaaS), and so we could expect NaaS needs to drive SD-WAN evolution increasingly, as the relationship between the two becomes clearer.
NaaS is a concept of virtual networking where connectivity is created on demand. There are two inferences in that statement. First, it presumes that there are demands for connectivity that an open and promiscuous IP network cannot fulfill. Generally, that would mean that connection policies were a key part of the requirements. Second, it presumes that “connectivity” in both business and consumer applications involves building up what has been called “closed user groups”. These are communities that can interconnect with each other, but for which membership is an explicit requirement to that connectivity.
A traditional SD-WAN model involves the use of what I’ve called “SD-WAN nodes”, which form the boundary between SD-WAN services and legacy IP connectivity. These nodes are deployed, either as appliances or software instances, where on- and off-ramp capabilities are needed, and every SD-WAN user has its own unique set of nodes. This structure differs from that of IP networks, including the Internet, because the connectivity layer is deployed on a per-user basis, and any resource sharing among users happens below, in the transport infrastructure on which SD-WAN services ride.
The current SD-WAN model works fine as a company VPN, either based on combined Internet and MPLS VPN services or alone, as an overlay on Internet connectivity. Where it falls short of NaaS requirements is in its support for community services that either cross user boundaries or bind users to resources that are inherently shared among users. Partner connectivity is an example of the first, and things like content delivery networks an example of the second.
To make SD-WAN a full NaaS strategy, we’d need to look at three “needs”, in some combination. First, a standard way of connecting transport networks so that SD-WAN could overlay a mixture of such networks. Second, an SD-WAN node that could support multiple SD-WAN communities, and third a means of connecting users when the NaaS communities and SD-WAN networks aren’t in a 1:1 relationship. We’ll look at each of these in order.
Starting, of course, with the bridging requirement. Any NaaS that’s truly a NaaS has to be able to connect users wherever they are, which means whatever transport network they happen to be on. That means that there has to be a means for bridging multiple transport networks, ranging from the Internet, IP MPLS, Ethernet, and even in theory TDM. A bridging strategy of any sort has to have a node with an interface on the networks it bridges, but what exactly is happening in that node depends on the overall connectivity strategy.
One choice is to have an SD-WAN node that can support an overlay on any of the target transport technologies. There are “universal” pseudowire or tunneling protocols that will work over almost anything, and one of those could be used. Another option is to select a “transport protocol”, the logical option being IP, and bridge IP over the other transport options.
Those same two transport options could work if we had a specialized bridging node that was aware only of the transport choice and simply passed the SD-WAN overlays transparently. However, this choice would mean having the SD-WAN implementations zero in on a compatible transport mechanism that could overlay any physical network. IP would be the only universal option, so we’d need to decide how to create an IP-like transport overlay on which SD-WAN overlays could be hosted. The overhead of this could become an issue, and of course so could cooperation among SD-WAN vendors.
A special case of our last option is the answer to the second of my three “needs”, an SD-WAN node that could support multiple SD-WAN communities in parallel. Think of it as a “shared bridge” or “shared gateway”. There are two possible models of such a device, one that supports multiple communities based on the same SD-WAN implementation, and one that supports communities with diverse SD-WAN technology choices. The former option isn’t feasible in a market where there are already two dozen or more implementations, so we have to focus on the latter.
Supporting two different SD-WAN technologies within a device means mapping between them for connectivity, and the only practical way to do that in a market as diverse as SD-WAN is to presume you’re going to harmonize everything to a common standard. The MEF’s draft SD-WAN spec, while still only a draft, seems to have taken some useful steps in defining what such a standard would look like. SD-WAN is about forwarding application flows, so the MEF defines the notion of application flows and then allows policies to assign flow identities to packets that arrive. One could assume that if you harmonized both the on- and off-ramp for a flow to the MEF specs, you could enter from one implementation and exit onto another.
The fault in this happy picture lies in the fact that there are major variations in the way that current SD-WAN implementations treat the “application flow” concept. Most provide little real support for flows, allowing only a few assigning policies to operate. This is a problem because interworking nodes as I’ve been describing, even those that harmonize to a common standard, have to be able to harmonize both ingress and egress to that standard, which can’t happen if the features aren’t congruent.
They aren’t, and in particular they aren’t congruent with respect to connection policy controls. The specific NaaS issue is those closed user groups. If application flow policies can’t identify specific user/user or user/resource relationships, then there is no NaaS because there’s no closed user groups. In addition, there’s no natural security for shared-node resources because user sessions aren’t recognized and can’t be kept separate. Today perhaps three or four implementations of SD-WAN have any real relationship-or identity-based policy controls. Those can perhaps be made to interwork with each other, but for the rest? It’s going to be tough.
That’s a problem in gateways, but a greater problem with creating an explicit interworking approach among the SD-WAN implementations. The harmonize-through-convergence-on-a-standard model is also an answer to the third of our NaaS “needs”, the ability to map NaaS membership independent of SD-WAN technology. Any node could provide SD-WAN intermediation between vendors if the vendors would cooperate, which is doubtful in a competitive market. On the other hand, if the MEF approach is popular and credible, and if it actually defines the interworkings required fully, there would be pressure on SD-WAN vendors to support it, which would then make it possible to build a “harmonizer”. In fact, it’s not unreasonable to assume that there would be an open-source initiative to do just that, and each vendor could then contribute their own mapping interface.
The challenges all of this will face in a competitive market are clear, and it’s equally clear that time isn’t going to make matters easier. Thus, the pace of the MEF’s work is as important as its completely the mapping issues. I’m guessing it will probably be some point in 2020 before the final standards are available and the market can even assess whether the NaaS points I’ve made can be supported with it. If they aren’t, we may have to wait for some other approach to come along, and that will impact NaaS progress at a time when we really need progress to be made.