eBooks

SOLVING NFV'S DATA PLANE PARADOX Building NFV in the data plane The goals of Network Functions Virtualization (NFV) have been laid out clearly in the 24 months since a group of telecoms operators published the first NFV call to action document (1) in October 2012. By supporting a coordinated call to migrate networking equipment running on fixed-function hardware platforms to virtualized software functions running on open commercial server platforms, operators hoped to gain many of the operational and capital cost savings that virtualization had brought to the enterprise world. The operators were attracted by the promise of being able to take network functions that sat in dedicated appliances – routers, firewalls, gateways, WAN accelerators, SBCs – and relocate them as virtual instances running on industry standard server, switch and storage hardware that could be sited in data centers, network nodes or customer premises. THAT IN TURN WOULD GIVE THEM SEVERAL KEY BENEFITS • Increased flexibility and efficiency of deployment of resources through an ability to "turn up and scale down" resources according to demand. • Reduced capex through the ability to tap into a lower cost network equipment and appliance market. • Increased innovation through a lower risk environment for service introduction, and a much faster time to market for new services. • Reduced opex, with remote operation of multiple functions on the same hardware. Other opex reductions, such as reduced space and power requirements. The proposed path to these benefits is being laid out by operators and others in an ETSI working group that has since produced a series of specification documents detailing overall NFV architecture, and of the elements within it (e.g. compute domain, hypervisor domain, infrastructure network, security and trust guidance, VNF architecture). The latest batch of documents were released in July 2014. (2) The basic structural elements of NFV see an underlying layer of standardized hardware, a virtualization layer or hypervisor, and the application or network function running on top of that. As in a data-centre cloud environment, an orchestration layer manages the cloud elements, both the VNF (Virtual Network Functions) and the hardware infrastructure, hence parallel requirements are evolving for a next generation OSS architecture that can support and manage an NFV-based network. The ETSI-defined architecture for this aspect of NFV is known as MANO (Management and Orchestration). In overall terms, reduced management cost due to the increased automation that NFV offers is another key potential benefit of NFV. A TMN eBOOK: SOLVING NFV'S DATA PLANE PARADOX

• Cover