Telecommunication products were traditionally based on dedicated HW. A collection of technology changes and market requirements have caused many of these products to move away from dedicated HW and to run on x86 platforms.
These include:Many companies have made the effort to move their products to SW platforms.
Does SW mean virtual? Does virtual mean NFV?
NO
The move from a HW product to a SW one is probably perceived as the most complicated milestone to achieve on the road to NFV.
The effort involved in executing this shift depends a lot on the type of application. There are some things that HW just used to do better - things such as media processing and encryption. Acceleration features of CPU vendors like Intel have helped to significantly reduce this gap.
The move to SW means that your application can run on top of a specific OS installed on a dedicated x86 platform. If you have more than one application they compete for the same resources and you are at the mercy of the OS to give you the performance your application needs.
This is where virtualization comes in.
The next step in going virtual means that you are not going to run directly over an x86 platform with an OS that you install but rather you will have a layer in-between that will utilize the compute, storage and network resources of the system. This layer is a virtual machine.
Virtualization was first introduced by IBM for their Mainframes some 30 years ago. Given the price of those computers, there was great value in being able to utilize the same HW for several environments.
The virtual machine shares these resources with other virtual machines running on the same platform. This will allow you to have different OS/environments on the same physical HW. Some applications use modified OS versions with application specific modifications for improved performance or security. With virtualization, each application can use its own dedicated OS version sharing the same physical HW.
With the commoditization of computers, the motivation for virtualization stems from efficiency and agility requirements. To achieve these goals it is not enough to have a virtual machine on each computer. There is a need to automate the management of these resources.
Clouds already exist for several years and what they bring on top of the virtual machine is this automation. It provides the ability to bring up machines and applications, move an instance from one place to the other and make sure service availability is maintained.
Solutions for such high level management of clouds is offered by virtual machine vendors such as vCloud of VMware as well as Open Source initiatives such as OpenStack that support all major VM vendors but mainly shine in KVM setups.
There is a lot of complexity involved in managing networks (the main driver for SDN) and compute and storage resources within the data center. But even when all of this is available, it is still at the resources level and doesn’t include the application and service logic nor integration with the systems used by service providers to start/modify a service for a specific user.
That is exactly where NFV kicks-in.
The motivation for NFV came mainly from service providers. With their struggle to compete with the agility of OTTs, they strived to find ways to reduce the cost and time of launching new services and supporting peek service load demand efficiently.
Defined by ETSI’s Industry Specification Group for Network Function Virtualization, NFV is based on the basic virtualization elements mentioned above that virtualize the compute, storage and network resources through the NFVI. On top of these elements run multiple VNFs which are actually the applications. Each VNF has also a monitoring and alarms element (EMS).
One key part of the ETSI specification is management and orchestration (MANO) which comprise of 3 components:
Two common use cases for NFV are service provider cloud services and vCPE.
In the service provider cloud, new services can be quickly launched and scaled up as usage increases or is terminated if not successful.
In the vCPE case, deployment can happen in several architectures where typically the first phase is of an on-premise CPE device that runs multiple services such as FW, NAT, Security and VoIP communications.
Later in the vCPE deployment cycle, some of these functions are moved to the service provider cloud. Moving some of the network functions to the central service provider cloud allows the service provider to have better control over the system and by that, improves the support offered to the end customer while reducing cost.
In both of these cases, the orchestration capabilities of NFV and its close integration with OSS/BSS systems are imperative as new customers can be quickly added to the service through the service provider systems and service packages can be changed and implemented instantly (e.g. adding features or capacity to a customer’s service package).
Running an application in a virtual environment is still far from being fully integrated and compliant with NFV. The benefits of NFV go beyond the automation of a single application. It integrates with OSS/BSS systems and brings an end-user service view to the system, something that is not possible in virtual environments.
AudioCodes recently announced the launch of its SBC VNF for vE-CPE and high capacity cloud deployments. This is in context of the adoption of NFV and vE-CPE that we see today in the market and our work with NFV orchestration and vCPE vendors.
