Part of:Cloud ushers in network-as-a-service model
Network-as-a-service business model options take shape
As network as a service gains traction, enterprises and service providers must consider multiple deployment models. SD-WAN, SASE, SDN and policy management could all play a role.
Implementing network as a service, or NaaS, could be game changing for enterprises. But, to be transformational, a network-as-a-service business model has to be more than a collection of marketing slogans boasting about changing network services and infrastructure. With multiple NaaS models emerging and multiple ways to assemble them, not every option will create the same outcome for network users or NaaS network operators. Here's a look at the options.
The majority of NaaS technologies use customer premises equipment (CPE) to deliver their features. Two specific flavors of CPE-based NaaS have emerged: one based on software-defined WAN (SD-WAN) technology and the other on security technology.
SD-WAN and SASE may enable NaaS
SD-WAN products and services are based on a virtual network, where CPE creates a network on top of IP. Typically, SD-WAN is used to extend VPNs to small sites or even to remote workers. The great majority of these links add a new network layer with its own headers and addressing, enabling SD-WAN to manage user and application connectivity. SD-WAN devices can prioritize users, applications or traffic types -- data, video and voice -- meshing with NaaS' ability to provide controllable quality of service (QoS). With the addition of other CPE features, like security, the SD-WAN devices can support the full spectrum of NaaS services.
In addition to SD-WAN, the recent marketing buzz around Secure Access Service Edge, or SASE, is amplifying another CPE-based NaaS strategy, this one based on security. SASE is normally built around tools like network firewalls or access control, so it doesn't require a virtual network technology, like SD-WAN. SASE can make use of SD-WAN features and prioritize traffic, but management of that traffic doesn't require a virtual network. Instead, it can also be based on policy.
With multiple NaaS models emerging and multiple ways to assemble them, not every option will create the same outcome for network users.
Universal CPE (uCPE) offers another option. It enables SD-WAN and SASE to converge on a single device and, if employed virtually, enables a provider to move CPE off the customer's premises and onto the network, usually near the network edge of the service provider's infrastructure.
UCPE is based on a generic piece of hardware -- hence the name universal -- that sits on the customer premises at the point of service connection, which is also where SD-WAN and SASE sit. Unlike SD-WAN and SASE, uCPE doesn't define a specific set of starting point features. The goal is to enable features needed by users to be loaded into uCPE instead.
Network-based NaaS CPE becomes virtual CPE
If CPE moves off the customer premises and into the network, usually near the network edge of the service provider's infrastructure, it becomes virtual CPE (VCPE), which is uCPE equipped with hosted features. The great majority of vCPE implementations are based on ETSI Network Functions Virtualization Industry Specification Group documents.
The primary advantage of the edge-based approaches to a network-as-a-service business model is that NaaS can be provided to users who want it without changing the workings of the internet, VPNs or network infrastructure. The primary disadvantage is that NaaS inherits any QoS and security issues associated with IP networks. User traffic can be prioritized at the CPE or vCPE point, but IP network QoS can't be altered. Similarly, a distributed denial-of-service attack on the IP addresses that connect CPE or vCPE can't be prevented.
Using SDN and policy management as NaaS alternatives
To make NaaS more effective, it's necessary to make the network itself more personalized for the user. We know it's not possible to have a large-scale IP network that recognizes every individual user's traffic and every application workflow. This means creating a deeper layer of user awareness but not through the entire network because user traffic can't be tracked when it's aggregated with that of thousands of other users. Two technologies can help meet that objective: software-defined networking (SDN) and policy management. SDN separates the forwarding or data plane of a network from the control plane that determines the best path from source to destination. SDN relies on OpenFlow, a protocol that enables a central controller to send forwarding table updates to each forwarding switch. The central controller has total control of routes. Without using adaptive routing protocols or route discovery, precise traffic engineering controls QoS.
When used near the edge, the number of user connections at a given forwarding device is smaller, so SDN could be used to extend user awareness deeper into the network. At the point where the number of user flows exceeds the capabilities of a device, traffic engineering would provide QoS, or traffic management could be handed off to an IP core based on MPLS.
Policy management can control QoS in SASE or even SD-WAN because it can support user and traffic-type awareness. In addition, policy management can extend more deeply into the network, understanding that, at some point, policy enforcement would be prohibitively processing-intensive as the number of users and traffic flows grows. The advantage of policy management is that, unlike SDN, it doesn't require much of a change to existing network equipment. Most routers are capable of policy management. The disadvantage is that it is difficult to scale policy management to the individual user level.
What NaaS strategy is likely to emerge?
NaaS strategy will almost certainly be based on uCPE. The edge is the best place to provide user awareness, and if that's the goal of NaaS, then the NaaS business model of the future will almost certainly be based on CPE.
