If Network-as-a-Service (Naas) is the right approach, what would it look like? There’s a surprising amount of variability in the approaches being taken, and each option has its own unique positives and negatives. Not to mention whether NaaS as a concept is the right approach, or an approach that’s a practical option for operators now. Today, we’ll look at NaaS and see what we can pull out of the technology mist.
The essential notion of NaaS is that it presents a user not so much with access to a collective network, but rather access to a network that looks like they need it to look. Features that are additional to traditional IP networks (cache, DNS, security, etc.) can be integrated into NaaS, and NaaS services can be easily expanded and contracted in both scope and bandwidth. The value of this is that operators offering NaaS can displace cost and complexity at the user level, making the service more attractive and thus commanding a higher price and profit margin.
The figure above shows the range of technology models that could, at least in theory, deliver NaaS. There are three basic hardware models for the data plane—white-box with chip optimization, hosted, or monolithic proprietary traditional. The monolithic model presumes hosting the control plane in the same device, where other models could introduce a separate control plane. In all cases, there are the NaaS features themselves, and on top the interfaces that allow those features to be accessed.
We could map these various boxes to what’s available or proposed today, to tie theory to buyable products. That’s how we’ll start our exploration.
Traditional monolithic routers will implement control and data planes in a combined way, within a device. These devices could be supplied with NaaS capabilities by adding something above the box, as we see today with the implementation of 5G UPFs, content delivery networks (CDNs), and even the DNS/DHCP IP addressing features. We could also integrate “hooks” to these features with the control plane of the boxes, which is based on adaptive topology and status discovery. We could add an additional functional layer that provided for improved general integration of NaaS features.
SDN in the classic OpenFlow form would build a centralized controller and manage optimized white-box flow switches with it. The control plane’s connectivity is adaptive via “northbound APIs” presented by the controller, and any NaaS logic would be hosted above the controller and manipulate connectivity via those APIs.
The NFV model would suggest that both data plane and control plane are hosted on general-purpose servers or at least on pooled resources. The model could support centralized or adaptive control of forwarding tables, and in the adaptive case, it could be separated from data forwarding or integrated with it in a single “router instance”. NaaS features could be integrated with the control plane and presented through any of the interface options.
What’s the “white-box” model? At one level, you could consider white boxes to implement either the monolithic classic router, the SDN approach, or the NFV hosted-function approach. White boxes could also be used in a cluster (as DriveNets has done) to create a complex of devices that act as a single box but provide more resilience and flexibility in deployment and upgrading. That means that the white-box approach has, in theory, the ability to implement any of the control-plane options, integrate any feature set with the control plane, and provide any sort of interface through which the NaaS services can be accessed.
Having laid out the basic options, let’s dig a bit deeper into the best way to deploy NaaS, and see how our options relate to the optimums.
There seem to be three general approaches to NaaS. The first is what could be called “connected Naas”, which is what we have today. Additional service elements and features are added by making them a destination on the IP network (including VPNs). This is how 5G proposes to add its own mobility features, how CDNs work, and so forth. Obviously, this approach fits the monolithic router model that dominates today.
The second NaaS approach is what might be called “overlay Naas”. This model adds an additional connection layer above IP, and through that connection layer it has more specific service and feature control than IP provides by itself. We have this today in the various overlay SDN models and SD-WAN. This is the easiest way to augment traditional router networks to support NaaS, but it doesn’t provide any real integration between the overlay and the IP network, which means that its ability to control the connection experience is limited.
The final approach is “integrated NaaS”. This is a broad model that differs from the others in that there would be explicit tight integration between NaaS services and the IP control plane. This would mean that, via the integrating API, NaaS could draw on topology and traffic information available to the control plane, and could also influence packet forwarding and even the IP control-packet exchanges with adjacent devices.
Connected NaaS isn’t a new capability, but it’s applicable to current infrastructure. NFV was arguably aimed at creating this model through “service chaining” and “universal CPE”, but even though it uses existing interfaces to routers, it’s not necessarily easy to integrate, as the NFV service-chaining experience illustrates. However, if the goal is to provide a means for NaaS features, hosted somewhere in the cloud, to influence forwarding behavior, even connected NaaS can work. All that’s needed is a pathway to forwarding control, asserted via a management interface.
The overlay NaaS model is the logical way to transition from vanilla IP and VPNs to NaaS. In almost every case, this approach will start with an SDN/SD-WAN facility that creates a universal VPN model that works even from home. This model creates, in at least some implementations, a kind of closed-user-group capability where users can connect only to resources assigned to them. Zero-trust security, in other words, or a “secure access service edge” (SASE). Since security is the most common NaaS feature offered today, this is a powerful starting point. Some implementations also prioritize traffic, which is another highly valuable feature.
Integrated NaaS, the final approach, is where I think things are heading, but each of the major NaaS models (monolithic/traditional, hosted, white-box) are likely to approach it in a different way, so we’ll have to dig into them all, referring to the earlier figure.
If we assumed that we had a white-box model of networking with a separate control plane, likely cloud-hosted, the integrated NaaS model would allow new service features to be dropped right into the control plane implementation, which is a potentially powerful capability. Even without that, the control plane could assert APIs that would tightly couple features to the control plane, which gives them at least the potential for manipulating forwarding, impacting traffic engineering, and so forth. This means that NaaS wouldn’t be a subset of what the underlying IP network could do. Instead, it would be able to control that underlying network, perhaps even in detail. This white-box-separate-control-plane approach would then be the ultimate NaaS.
Not necessarily in a material way, though. The OpenFlow SDN model of transformed network could do something almost exactly the same, using those northbound APIs. Even a monolithic router could, with the addition of an interface to “the cloud”, offer tight integration between forwarding and a separate NaaS feature set. Many routers already support OpenFlow, for example, and any router vendor could directly expose forwarding table control via a secure separate interface or API.
I’ve talked about two specific vendors as candidates for a true NaaS platform, Juniper and DriveNets. Neither of the two have actually committed to all the pieces needed to fulfill NaaS potential, but as the old military adage says, “Judge an enemy by its capabilities and not its intentions”. I think both would be capable of implementing NaaS, via different models and requiring different steps to advance their position.
Juniper’s acquisition of Mist, 128 Technology, and Apstra gives them the foundation of what would arguably be a “NaaS ecosystem. One of the negatives of NaaS is support; customization of services creates a greater burden on traditional network operations practices, and Juniper has this covered (potentially) with Mist. 128 Technology adds connectivity control, VPN extension to pretty much anywhere, and zero-trust security and prioritization. Apstra extends all of this into the data center, and adds in the intent modeling that’s absolutely critical for management of pooled resources and mixed technologies.
DriveNets is the most fascinating startup in the space. They use a collection of white boxes assembled into a cluster connected by the white-box fabric elements. They separate the control plane, and they provide (in their management and orchestration) for the deployment of third-party elements into what becomes an extension of the control plane. They can also couple elements via traditional interfaces and through a wide range of APIs.
Do these two then vie to shape the future of networking and NaaS? Obviously other direct competitors could emerge if neither of these two moves quickly, but that’s not the only way another competing approach could emerge.
The challenge for both Juniper and DriveNets is that they’re network companies not cloud companies, and the cloud is inevitably the platform for any “service” beyond simple connectivity. A big piece of 5G and CDN belong there, and almost any value-add from IoT. VMware is a cloud player, a player who could potentially be waiting for the opportunity to arrive. The company recently promised to “pave the earth” with their Tanzu cloud platform.
The “waiting” point is VMware’s challenge. They need to move to great NaaS, to embrace where it’s heading. In the near term, that means generalizing forwarding control so they can connect with white-box data-plane elements, and in the long term it means visualizing what an “IoT service” would really look like.
These three vendors would present three different pathways to NaaS, each having its own strengths and limitations. I think that the winner is likely to be the player that gets out there first with credible positioning and an early feature set that justifies operator consideration. That could be any of these three, and it’s even possible that someone else will jump out if all three of my choices take too long to get to the starting line. Whatever happens, I think NaaS is the only salvation of operator business models, so the operators better hope at least one player does the NaaS deed.