NFV to VNF to SDN – What Does it All Mean

Despite its popularity in the networking space, the question still arises: what is NFV? Of course, I would say that Cloudify’s NFV page is a great starting reference, giving an overview and demonstration of the concept of NFV.

That said, there is still a lot of space to discuss NFV, SDN, and VNFs (and everything in between), which have seen wide adoption and development over the past few years, and I’d love to take this opportunity to review some of these terms and trends.

Let’s start from the top:

What is NFV?

NFV – Network Function Virtualization – is an approach widely adopted by Telecom companies and enterprise organizations for the deployment, management, and scaling of network functions. NFV allows for decoupling and virtualization of existing OSS or legacy and dedicated hardware, to make them software-driven on using standardized hardware. Historically, these services and functions on the network have used complex black boxes and proprietary hardware and software, provided by vendors. Not only was this legacy approach costly and time-consuming to procure and manage, it required specialist teams and brought with it barriers to scalability and elasticity.

It goes without saying that this model has faded into the rearview mirror as we have moved into a more dynamic, cloud-based world.

As with other industries, Telecom companies are looking to be agile, and to be able to bring new services to market as quickly as possible. Before NFV and SDN (Software Defined Networking), it could take more than a year to introduce new services, making NFV a game changer in enabling growth and innovation.

At the heart of the matter, is the general requirement for significant changes to existing code in order to convert a NF (network function) into a VNF (or, Virtualized Network Function), running on virtualized software and hardware and, ultimately, a cloud. Adding to the complexity is the demand to achieve this in a standardized way, without losing control. 

We’ll discuss ETSI a bit later on, but here is a quick note about NFV vs VNF: NFV refers to an overarching concept as a framework for running software-defined network functions; VNF is the implementation of a network function by utilizing a software decoupled from the underlying hardware infrastructure. Effectively, that’s the difference between VNF and NFV.

Ok, So What is SDN?

SDN (Software Defined Network/Networking) is an approach that decouples the control plane from the data plane in networking equipment. When it comes to NFV (Network Function Virtualization), SDN is complimentary, as it enables you to keep the “intelligence” of the network or the network brain within the controller, leaving the network equipment handling data would effectively be “dumb” – simply executing operations mandated by the controller. This dynamic means NVF transforms proprietary hardware into POTS (Plain, Off the Shelf) virtualized servers. And, coupled with SDN, it is now possible to handle sophisticated network functions in the controller, further simplifying the network function implementation. 

With this combination of NFV and SDN, a door opens to new network models – both from an architecture standpoint as well as a business one, with support for network virtualization by provisioning equipment per customer (multi-tenancy), and much more.

NFV, SDN, ETSI & MANO…Enough acronyms?

ETSI – the European Telecommunications Standards Institute – defined a standard reference architecture to achieve NFV, which was adopted as the leading approach. Integral in this architecture is MANO – the management and orchestration layer of NFV.

MANO in Brief

MANO is defined by ETSI as the layer that manages and orchestrates the cloud resources and infrastructure. It is comprised by these elements:

• VIM (Virtual Infrastructure Manager) – Controls the intersection of the VNF with the compute, storage, and networking resources of the chosen NFVI (such as the cloud or virtualization layer)
• VNFM (Virtual Network Function Manager) – Responsible for VNF lifecycle management (takes action on termination, scaling in and out, instantiation, failover, and more)
• Orchestrator – As the name suggests, this element basically serves to orchestrate and manage the software and infrastructure resources of the VIM, and to realize the NFVI’s network services.

Together, these elements are intended to provide a full end-to-end lifecycle solution of NFV orchestration and management – from installation, deployment, and through to post-deployment. If we’re talking MANO and NFV in Telecom speak – Day 0 through Day 2 support.

NFV & Modeling Languages

As NFV and SDN have become more application-oriented, more complex actions often need to be taken, such as working databases, processes, records, files, and of course dependencies and the order between them and external entities. There is also ever-increasing demand for high availability capabilities for high performance loads.

On top of all of that, with the (not uncommon) blurred line between applications and network functions, VNFs also require the support of application orchestration beyond network resource configuration, when managing the NFVI lifecycle carries both aspects of application management as well as network equipment management.

All of these elements mean the need for standardization is critical.

Known to be very standard-driven, the Telecom industry will find alignment with MANO to be an important element for NFV adoption. These days, Telecoms and Enterprises alike are seeking modeling languages which help to achieve the goal of network and application orchestration. This makes OpenStack a good bet along with the nature of standards-driven open source cloud for real world scenarios.

For this reason, TOSCA was developed, and has become an important criterion when seeking an orchestration platform. TOSCA (Topology and Orchestration Specification for Cloud Applications) is a standard written by the Oasis Foundation (you may have heard their name, as the creators of XML, and more recently in their development of a privacy-enabled blockchain platform). TOSCA is backed by some global giants, such as IBM, HP, Huawei, and many more, and is the templating language of choice in one of the world’s largest orchestration projects, OpenStack Heat (via the Heat Translator Project).

The IT realms of Telecoms and Enterprises – formerly quite disparate – have converged, and TOSCA has played a strong role in becoming the NFV orchestration standard for both industries.

On top of TOSCA and MANO, many telecoms and carriers utilize YANG/Netfon for service-chaining on the VNF level. TOSCA is a pure-play orchestration specification, making it very easy to plug in to order standards (including YANG), minimizing the learning curve and leveraging existing know-how amongst Network Admins.

TOSCA brings a combination of application topology and declarative descriptions with all of its components – including the network, load balancer, compute resources, software, etc – along with an imperative set of workflows for describing the logic of any process that needs to be automated. 

From an NFV perspective, this means that TOSCA is a clear choice when it comes to defining virtual application topologies, dependencies and relationships, and actions to be performed within a lifecycle. This simplifies complexities that arise when exposing network elements and end-to-end lifecycle management for NFV, though abstraction of the networking piece of deployment into application blueprints.

In a future post, we’ll explore how to map ETSI and NFV to TOSCA to achieve NFV in the Real World.