Network function Virtualization(NFV) refers to Services running on commodity hardware(compute, storage, network) which replaces functions that are done in specialized boxes currently. This applies mainly to Telecom sector, but the same concept can be extended into other areas as well. If we look at current products in the Telecom sector, there are separate hardware systems for each functionality. Examples of these systems are CPE switches, BRAS, LTE, mobile backhaul, firewall, load balancer etc. In all these systems, there is a tight coupling between the software stack and the hardware supplied. This causes multiple issues to the carrier/operator like high capital cost, multiple management systems, dependency on few select vendors etc. In the initial days, one of the reasons for using specialized hardware was that general purpose servers did not have enough horsepower. Newer generation servers pack in a lot of horse power that allows both control and data plane functionality to be done with commodity servers. This in addition to the maturity of Virtualization technologies(compute, storage and network) have made NFV more practically possible now. There will still be some scenarios where it is necessary to use hardware systems with ASICs for high throughput and distributed processing needs etc.
In this blog, I will cover the following:
- NFV Overview
- NFV architecture Components
- Use cases
- Standards and Opensource components
- NFV in relation to SDN and white box switches
- Comparison to data center application
In the next blog, I will cover popular NFV implementations available in the market today.
The following picture from ETSI NFV White paper gives a high level picture of the common services that are being considered for NFV and how they will be implemented in the NFV model.
Following picture from ETSI NFV white paper gives the intersection of different blocks of NFV.
Other than creating Network functions, there is a need to deploy the Network functions in a Virtualized infrastructure and to maintain them. Orchestration software is a critical piece of NFV.
NFV Architecture components
ETSI NFV architecture framework document gives details of different blocks that are needed to create NFV system. Following 2 pictures gives high level picture of the blocks and how they need to interact with each other.
Some notes on above 2 pictures:
- The first picture shows that NFV framework consists of NFV infrastructure, Network functions and NFV Orchestration software.
- The second picture breaks the above blocks into further details. NFV infrastructure consists of virtual compute, storage and network. Network function layer consists of Virtual Network function(VNF) along with its individual management system. NFV management software consists of NFV infrastructure manager that manages the virtual infrastructure, VNF manager and Orchestration software that manages the VNF lifecycle.
- A Network service can be implemented by connecting multiple VNFs together in some combination and that is called as NF forwarding graph. This is similar to the concept of Service chaining used in Data center world.
- Following are some examples: Virtualized infrastructure manager(VIM) can be Openstack, Cloudstack. Virtual Network function can be services like Firewall, Vcpe etc.
ETSI NFV Use cases document gives details on initial use cases. The use cases are spread between mobile network, home network, content delivery services, edge services etc. There are more use cases that can come in the future. The goal here is to keep the architecture generic enough so that any new applications/use cases can be developed easily.
Standards and Open source components
ETSI NFV ISG group is developing a set of architecture specifications that operators and vendors can use to develop standards and implementations. The first set of drafts from ETSI are available now and the second set of drafts would be published by end of year 2014. There are also multiple PoCs that are happening under ETSI guidance. As of now, the plan is to dissolve the NFV ISG group early 2015. The goal for implementation seems like a combination of standards and open source components to speed up the NFV adoption. Following open source projects like Openstack, Opendaylight, Openflow, Opencompute will play an important role in NFV.
NFV in relation to SDN and white box switches
SDN facilitates NFV deployment. Since Virtual network functions can be distributed, it is necessary for the network to be flexible and Network virtualization technologies gives that flexibility. ETSI defines NFV Infrastructure to consist of commodity servers with hypervisors for compute, Hypervisor switch as well as networking switches for networking and both internal and external storage. The goal here is to do both control and data plane processing completely in software. For data plane intensive packet processing, packet processing ASIC would give higher throughput than software based packet processing. In my personal opinion, it should be possible to have NFV over commodity white box switches for applications that are data plane intensive. In this model, it is not needed to have a vertical lock-in with the hardware but still have standard interfaces between the hardware and software. 1 possible interface could be Openflow. I feel that there is room for this hybrid model for some applications.
Comparison to data center application
I feel that NFV resembles a Data center application in many ways. Following are some comparisons.
- Data center application runs over Private or Public clouds. The cloud is composed of compute, storage and network. Similarly NFV runs over NFV infrastructure which is a virtualized compute, network and storage domain.
- A typical data center application has many tiers like web tier, app tier, database tier. Between each of the tiers there could be policies and the tiers are tied using Service chaining. Similarly NFV application can have multiple VNFs. For example, NFV CDN application can have multiple VNFs like cache server, firewall, load balancer etc and by using NF forwarding graphs, the different VNFs are tied together.
I feel NFV can leverage a lot of the Data center technologies and related Open source project developments. The additional effort for NFV would lie in Orchestration of NFV application and also to adapt to some of the stringent Telecom requirements related to Performance and Scalability needed for NFV application.
The main challenges I see are:
- Interworking with current deployed equipment – NFV cannot be a rip and replace model, it needs to interwork with current equipments and orchestration software needs to facilitate this.
- Performance – Commodity servers have a limit on throughput. There are some innovations possible here in terms of distributing/load balancing NFV application to increase throughput.
- Security – Since the applications are distributed, it is important that data is secure. For example, in Vcpe NFV application, CPE packet processing functions are placed in a central location and the subscriber devices provides just physical connectivity, it is important to make sure that the data exchanged between subscriber and the central end point is secure.
- Reliability – Telecom applications have stringent HA and six nine requirement. It is needed to move the reliability from hardware to software.
Some final thoughts
NFV is here to stay. Telecom operators are making lot of NFV investments. I feel that NFV should leverage data center technologies as much as possible. Also, there could be a possibility of hybrid model where NFV can be deployed on a combination of commodity servers and white box switches where white box switches can be used for data plane intensive applications.
- ETSI NFV
- ETSI NFV documents
- NFV Unbound – Openstack summit presentation
- NFV webcasts from Layer1,2,3
Pictures used in the above blog are from the references.