The cloud computing explosion has created a parallel explosion in the use of the term "as-a-service," to the point where it can be hard to take the classification seriously. The term Network-as-a-Service
The Network as a Service concept emerged from cloud computing, as well as from the specific support for virtual networking in OpenStack, where the Quantum interface describes how network connection services can be created to support connecting cloud compute and storage services.
The Network as a Service relationship to the physical network
In this context, Network as a Service is a virtual network created to support an application. This is a critical distinction from traditional networks that connect fixed locations like headquarters to branch offices, servers to servers and servers to storage, etc.
If NaaS is an application network, an important question is how it relates to network infrastructure and network services. The answer is the key point in separating "real" NaaS approaches from just wishful thinking.
If Network as a Service has its roots on the cloud, the first practical NaaS option is the virtual overlay network. Network software vendor Nicira (acquired by VMware in 2012) developed the completely software-based Nicira NVP virtual network architecture that could be controlled by cloud APIs. Virtual overlay networks are a combination of tunnels (using one of a number of suitable tunnel protocols, including GRE) and virtual switches, which create a network "on top" of physical network equipment (switches and routers).
Given that Network as a Service is implemented and controlled by software, these application networks are basically transparent additions to the actual network equipment and services that create connectivity. Virtual overlay networks subdivide connectivity produced by real services and infrastructure but don't create connectivity or change service-contract relationships. This is the perfect approach for users who want dynamic application network control but don't want to change how their sites are connected, how their site networks are built or how their network service contracts are written.
Options for creating virtual network segments
If the network service itself needs to be more flexible and more application-driven, more development is needed to make that happen.
That fact that virtual overlay networks don't create real services is an important limitation, because many see Network as a Service as creating a new and flexible network service, when, in fact, the virtual overlay form of NaaS can only segment the connectivity that the real network/service offers.
Virtual overlay networks aren't the only way to create virtual network segments that control connectivity. In Ethernet networks, standards like VLAN and VxLAN enable segmenting real infrastructure into virtual networks, and network operators also offer virtual LAN and virtual private network (VPN) services. The virtual network is less virtual here because it is created by real devices with real features. The features have to be invoked via a management application program interface (API), which has both benefits and disadvantages.
The obvious disadvantage of creating device-specific NaaS is the need to control the devices from the software/cloud. While this may require coordination between the software/cloud and network management systems (Quantum provides facilities for this customization), it can be done. It is important to ensure that device-specific Network as a Service includes all of the critical elements in an application network. An application virtual network will normally need access to DHCP services for address assignment, DNS for address resolution and a default gateway (router) to connect the application network to users.
Integrating Network as a Service with WAN services
Both virtual network overlay and device-specific forms of NaaS still work with a static set of underlying wide area network (WAN) services, so many believe that the full flexibility of the NaaS model has not been achieved. All of the traffic on NaaS services must be within the capacity of the real network beneath them, including the WAN links. For some, the fact that virtual network overlay forms of NaaS are not integrated with devices makes them more difficult to manage. NMS tools only "see" NaaS services as traffic. But making NaaS totally flexible means integrating NaaS concepts with WAN services.
If there is a last frontier of Network as a Service, it's the ability to order NaaS from service operators, but there are formidable issues in making this work. At the technology level, it's possible for operators to provide users with a management portal that could let them build, modify and remove virtual networks at the LAN (VLAN, VxLAN) or VPN level, but this kind of dynamism would collide with long-standing industry practices of pricing services based on the volume of traffic, the number of sites connected and the duration of contracts.
More Network as a Service resources
SDN vs. overlay networks: What's the difference?
Cloud API questions answered
Can Virtual Extensible LAN solve the VLAN problem?
Will users accept higher prices for NaaS, or will operators offer attractive pricing on services that don't really commit the customer? The marketplace has yet to vote on these points.
The issues don't stop there, however. Both virtual network overlay and device-based NaaS can create problems with Quality of Service (QoS) for all network users if virtual networks are spun up without considering the impact of their traffic on the "real" network beneath. Carrier-based NaaS could expose businesses to enormous charges if internal departments launching their own application networks inadvertently ordered something massively expensive. All of this implies that NaaS services in general may have to be fulfilled through some form of policy management system to control their misuse, regardless of how they are fulfilled. That would help ensure that NaaS evolves to something more than a hopeful, more flexible network model.
This was first published in May 2013