Move your VMware and KVM applications to the cloud without making any changes

  • January 31, 2016

NFV Orchestration: Increase service velocity with NFV (part 2 of 4 post series)

Matt Conran
Matt Conran is a Network Architect based out of Ireland and a prolific blogger at Network Insight. In his spare time he writes on topics ranging from SDN, OpenFlow, NFV, OpenStack, Cloud, Automation and Programming.

In this second part of a 4-post series around NFV orchestration we detail how NFV (Network Function Virtualization) can help alleviate multi-tenancy and network mobility challenges and increase service velocity (pace at which services can be rolled out) across enterprises and service providers.

Increasing the service velocity with NFV

In traditional networks, the time to deploy new services is very long. Physical network functions are contained in physical boxes and appliances. Traffic requiring service treatment must be physically wired to the box. In a multi tenant environment, deploying new services for new tenants was difficult and time consuming. It took a long time for product innovations and affected new service and product testing. There is a need to evolve the network and make it more cloud compatible. Networks need to move away from manual provisioning and respond to service insertion in an automated fashion. Service insertion should take minutes and not weeks.

How do we get the network to adapt to these new trends? One way to evolve your network is to employ network function virtualization. With NFV, ordering a new service can be done in seconds. For example, a consumer can request via a catalogue a number of tiers and certain traffic flows permitted between tiers. The network is automatically provisioned without human intervention.

NFV eliminates human intervention and drives policy automation.

NFV and SDN compliment each other but are used to satisfy separate functions. SDN is used to program network flow, while NFV is used to program network functions.

Network Function Virtualization decouples network functions from proprietary hardware and runs them in software. It employs virtualization techniques to manage network services in software as opposed to running these functions on static hardware devices. NFV gives the illusion to a tenant, the perception that they have an logically isolated network for themselves. It’s basically a software module running on x86 hardware. Proprietary hardware is cheap and you are paying for the software & maintenance costs. Why can’t you run network services on Intel x86?

The building blocks for NFV are Virtual Network Functions (VNF’s). VNF handle specific network function such as firewalling, intrusion protection, load balancing and caching. They run in one or more virtual machines and can be service chained by a SDN controller or some other mechanism. Once the network services are virtualized they can be dynamically chained to a required sequence by an SDN Controller, for example Contrail SDN Controller. The chain is usually carried out by creating dynamic tunnels between endpoints and routing traffic through the network function by changing the next hop. The chaining technology is not limited to the control of an SDN Controller. Locator/ID Separation Protocol (LISP) can also be used to implement service chaining with its encapsulation / decapsulation functions. Once the network functions are in place, LISP can be used to set up the encapsulations paths.

Please read Part 3 of this article where I go into how network automation, service chaining can help increase services velocity (roll out of services) in enterprises and service providers.

A special thanks to Jakub Pavlik and his team at tcpcloud - a leading private cloud builder - for collaborating on this post.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.