NFV to VNF to SDN - What Does It All MeanPosted By: Sharone Zitzman on March 22, 2015
Following the Mobile World Congress, which took place a couple of weeks ago in Barcelona, NFV and SDN are again all the buzz. While this is no new concept, I still find that I’m still often asked what the deal is with NFV and what it all means. A great starting reference can be found in this post “What is NFV?”, which demonstrates that this concept has been around for some time now. That said, NFV, SDN, VNFs and everything in between, have seen a lot of new developments from architecture, modeling languages, and requirements that have arisen or gained momentum since, and I’d love to recap and review some of the new terminology and trends.
So we’ll start from the top.
Pure-Play NFV Management & Orchestration with Cloudify. Download Free. Go
What is NFV? (Yes again. But slightly updated.)
This was summarized quite nicely in the previous post and has reached a much higher level of awareness since then, so I’ll touch on this briefly.
NFV can be summarized as the growing demand by Telecom companies and enterprises to deploy, manage and scale their networking functions, by decoupling and virtualizing all of their existing OSS, or in the case of enterprises legacy & dedicated hardware, and make them software driven on commodity, standardized hardware. These network services and functions have historically been complex black boxes based on proprietary hardware and software provided by vendors to these Telecom operators and enterprises, and on top of being costly & time-consuming to procure and manage with specialized teams, this model has inherent problems with scale, elasticity, and lock-in.
Needless to say, this static model simply doesn't fit into the dynamic cloud-based world we live in.
Like with all industries, Telecoms would like to increase their agility and create and introduce new services to the market as quickly as possible. Pre-NFV and pre-SDN these services could take more than a year to introduce, and hence NFV has become the enabler of growth and innovation in a matter of minutes, becoming a real game changer for this industry.
The crux of the matter is that typically network components require substantial code changes to turn an existing NF (network function) into a VNF (AKA virtualized network function) running on virtualized hardware & software, and then ultimately on a cloud. This becomes an even more daunting challenge when we want to do this in a standardized way and without losing control.
Ok, So What is SDN?
SDN (software defined networks or networking), introduces the concept of decoupling the control plane from the data plane in network equipment. In the context of network function virtualization, SDN complements NFV in the sense that SDN enables you to keep the “smartness” of the network or the network brain in the controller, while the network equipment which handles tons of data could essentially be “dumb” and just execute operations mandated by this controller. In this way, NFV moves proprietary hardware equipment into POTS (plain off the shelf) virtualized servers. This, coupled with SDN, now makes it possible to have sophisticated network functions and handle them in another place (the controller), and further simplify the network function implementation.
The combination of NFV plus SDN opens the door to new network models both from an architecture point of view and business point of view from support for network virtualization through provisioning of network equipment per customer (multi-tenancy) and a lot more.
NFV, SDN, ETSI & MANO...Enough acronyms?
ETSI, the European Telecommunications Standards Institute, defined a standard reference architecture in October 2013 to achieve NFV, which has since started to gain traction as the leading architecture for achieving VNF. An integral part of this architecture is the MANO - the NFV management and orchestration layer.
MANO in Brief
MANO is the layer defined by ETSI that manages and orchestrates the cloud infrastructure and resources, and it is comprised of the following elements:
- The VIM (Virtual Infrastructure Manager), essentially controls the interaction of the VNF with the compute, networking and storage resources of the chosen NFVI (i.e. cloud or virtualization layer).
- The VNFM (Virtual Network Function Manager), is responsible for the VNF lifecycle management - e.g. it takes action on instantiation, termination, failover, scaling in and out, and more.
- The Orchestrator, as its name implies, basically serves the purposes of orchestrating and managing the software and infrastructure resources of the VIM, and realizing the NFVI’s network services.
All of these together are intended to provide the full end-to-end lifecycle of NFV orchestration and management - from installation and deployment through post-deployment, or in the telecom industry terminology - Day 0 through Day 2 support.
NFV & Modeling Languages
With NFV and SDN becoming more and more application-oriented, this many times requires much more complex action to be taken, e.g. work with databases, records, processes, files, not to mention dependencies and the order between them and external entities, and even high availability capabilities for high performance loads. On top of this, with the border between applications and network functions becoming blurred in many cases, VNFs require support of application orchestration beyond network resource configuration, where managing the lifecycle of the NFVI has both aspects of application management and network equipment management. All this makes the need for standardization even more critical.
The telecom industry is known to be very standard driven, therefore, the alignment with MANO is an important element for NFV adoption, where many Telecoms and Enterprises these days are searching for modeling languages to help achieve the goal of application and network orchestration, and are betting on OpenStack and the nature of standards-driven open source cloud to help deliver this in the real world.
To this end, we’re seeing the importance and adoption of a standard like TOSCA becoming an important criterion in the choice of an orchestration platform. TOSCA, (Topology and Orchestration Specification for Cloud Applications), is a standard written by the Oasis Foundation(those who brought us XML), and is backed by some of the largest organizations in the world - including IBM, CA, HP, Huawei, Fujitsu, Alcatel-Lucent, as well as has been selected by one of the largest orchestration projects in the world to be the templating language of choice, OpenStack Heat, (that is working on integrating it into the main project via the Heat Translator project).
As a result, the formerly disparate IT worlds of NFV and enterprises are beginning to converge, and TOSCA has been playing a leading role in becoming the standard for NFV orchestration for both these industries. On top of TOSCA and MANO, many carriers and telecoms use YANG/Netconf for the purpose of service-chaining on the VNF level. With TOSCA as the pure-play orchestration specification, it is very easy to plugin to other standards, such as YANG to be able to minimize the learning curve, and leverage existing know-how among networking administrators.
TOSCA has the combination of declarative descriptions of the application topology with all its components - including the load balancer, network, the compute resources, software and everything else, along with an imperative set of workflows to describe the logic of any process we need to automate. What this means from an NFV perspective, is that TOSCA is very good when it comes to defining virtual application topologies, VNF dependencies and relationships, actions to be performed as part of a lifecycle. This significantly simplifies the complexities involved with exposing networking elements and end-to-end lifecycle management for NFV, by abstracting the networking piece of our deployment into an application blueprint.
In our next post we’ll dive into how to map ETSI and NFV to TOSCA to achieve NFV in the real world.