Tip

How to make Network as a Service a real option

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

    Requires Free Membership to View

certainly seems to veer wildly between being redundant (what do service providers sell if not services?) and being undefined. It would be a mistake to discount it though, because it represents networking's future.

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

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.