PaperlayerView exact revision on arXiv

Source-linked AI summary

Network Function Virtualization: State-of-the-art and Research Challenges

Rashid Mijumbi, Joan Serrat, Juan Luis Gorricho, Niels Bouten, Filip De Turck, Raouf Boutaba

arXiv:1509.07675v1cs.NI

TL;DR

NFV addresses the rigidity and hardware dependence of telecommunications provisioning by decoupling network functions from physical equipment. This paper surveys NFV’s architecture, related fields, projects, implementations, use cases, and standards, and identifies research challenges affecting its deployment. It concludes that interoperability, integrated management, orchestration, service automation, and standardization remain central gaps as NFV advances toward commercial deployment.

  • Problem

    NFV is still at an early stage, with incomplete standardization and unresolved challenges in interoperability, management, orchestration, security, energy efficiency, and performance.

  • Method

    The paper surveys NFV’s architecture, business model, relationships with SDN and cloud computing, projects, standards, implementations, use cases, products, and research challenges.

  • Results

    The survey identifies major research gaps and finds that current specifications remain too general for interoperability, legacy support, and management of mixed legacy and NFV-based systems.

  • Takeaways & Limitations

    NFV’s anticipated benefits depend on completing specifications and developing solutions for flexibility, interoperability, integrated management, orchestration, and service automation.

Abstract

from arXiv · show

Network Function Virtualization (NFV) has drawn significant attention from both industry and academia as an important shift in telecommunication service provisioning. By decoupling Network Functions (NFs) from the physical devices on which they run, NFV has the potential to lead to significant reductions in Operating Expenses (OPEX) and Capital Expenses (CAPEX) and facilitate the deployment of new services with increased agility and faster time-to-value. The NFV paradigm is still in its infancy and there is a large spectrum of opportunities for the research community to develop new architectures, systems and applications, and to evaluate alternatives and trade-offs in developing technologies for its successful deployment. In this paper, after discussing NFV and its relationship with complementary fields of Software Defined Networking (SDN) and cloud computing, we survey the state-of-the-art in NFV, and identify promising research directions in this area. We also overview key NFV projects, standardization efforts, early implementations, use cases and commercial products.

I. INTRODUCTION

Traditional telecommunications provisioning relies on dedicated proprietary hardware, producing costly, rigid services with long product cycles. NFV decouples network functions from physical equipment to support more flexible deployment, scaling, and service evolution.

  • Motivation: Dedicated devices and strict service-function ordering make telecommunications services hardware-dependent and slow to change.Changes may require modifying network topology or replacing specialized equipment.
  • Motivation: 14: Rising demand for diverse, short-lived, high-data-rate services forces providers to purchase and operate more physical equipment, increasing CAPEX and OPEX.Higher prices are constrained by competition and customer churn.
  • NFV concept: NFV decouples network functions from physical equipment, allowing functions such as firewalls to run as software on industry-standard servers.VNFs can be consolidated, relocated, and instantiated at data centers, distributed nodes, or customer premises.
  • NFV concept: NFV enables flexible deployment because infrastructure resources can be reassigned and shared across different functions and service connections.New services can be deployed over the same physical platform, with components instantiated at different NFV-enabled devices.
  • NFV concept: Dynamic scaling lets operators adjust VNF performance and capacity with finer granularity according to actual traffic requirements.The paper distinguishes NF decoupling from resource virtualization, while identifying flexibility and scaling as strong benefits of virtualization.
  • Standardization: NFV standardization and implementation work was organized through ETSI ISG NFV after operators called for industrial and research action in 2012.ETSI’s membership later exceeded 245 companies, and Phase 1 produced 11 group specifications.

B. NFV Examples

NFV examples show how customer-premises functions and mobile-core functions can move from dedicated equipment to shared infrastructure. These deployments promise easier updates, independent scaling, and lower operating costs, but the field remains early-stage with unresolved interoperability and implementation challenges.

  • Customer Premises Equipment (CPE): 33: Traditional CPEs combine eight functions in a physical device at each customer premises, making additions, removals, or updates costly and potentially requiring technician visits or device replacement.The functions include DHCP, NAT, routing, UPnP, firewall, modem, radio, and switching.
  • Customer Premises Equipment (CPE): NFV-based CPE transfers some functions to shared ISP infrastructure, enabling centralized updates and simultaneous addition of services such as parental controls.This can reduce ISP operating costs and potentially lower CPE costs at scale.
  • Evolved Packet Core: 38: The LTE EPC contains four network functions—S-GW, P-GW, MME, and PCRF—whose proprietary equipment makes even minor changes or capacity adjustments difficult.The EPC provides subscriber tracking, mobility management, and session management.
  • Evolved Packet Core: Virtualized EPC functions can be transferred wholly or partly to shared cloud infrastructure and scaled independently according to control-plane or user-plane resource needs.This can improve resource utilization, simplify software upgrades, and support faster launch of innovative services.
  • Open questions: NFV research and deployment remain early-stage, with open challenges including testing, validation, resource management, interoperability, instantiation, and VNF performance.Existing literature was described as incomplete in scope, standardization analysis, and coverage of state-of-the-art efforts and research challenges.
  • Open questions: The paper surveys NFV’s state of the art, its relationships with SDN and cloud computing, and associated projects, implementations, use cases, products, and research directions.It presents this coverage as a comprehensive survey of NFV.

D. Organization

The paper organizes NFV around ETSI’s architecture, a proposed business model, and design considerations, while identifying unresolved modeling and deployment questions.

  • D. Organization: The paper surveys NFV architecture, business models, design considerations, related SDN and cloud-computing fields, projects, standards, implementations, use cases, and products.
  • A. NFV Infrastructure (NFVI): ETSI’s NFV architecture comprises NFVI, VNFs, and NFV MANO.
  • A. NFV Infrastructure (NFVI): NFVI combines physical and virtual computing, storage, and networking resources used to deploy VNFs.
  • C. NFV Management and Orchestration (NFV MANO): NFV MANO provisions and configures VNFs and infrastructure while managing resource and VNF lifecycles and their associated data models.
  • C. NFV Management and Orchestration (NFV MANO): NFV definitions and interfaces remain unsettled, including where functions should run, whether containers can host VNFs, resource needs, and coexistence with legacy equipment.
  • III. BUSINESS MODEL AND DESIGN CONSIDERATIONS: The paper proposes a reference business model identifying five NFV players and their possible business relationships.

2) Telecommunications Service Provider (TSP):

The NFV business model separates infrastructure, service, and function-provider roles while allowing brokerage and hybrid organizational arrangements. Its deployment must also meet demanding performance and user-facing service requirements.

  • 2) Telecommunications Service Provider (TSP):: TSPs lease virtual resources from InPs, chain VNFs into services, and may sub-lease resources to other TSPs.
  • 2) Telecommunications Service Provider (TSP):: NFV divides traditional equipment-vendor activities between VNFPs, which provide NF software, and SPs, which provide industry-standard servers.
  • 2) Telecommunications Service Provider (TSP):: Brokers may aggregate resources and functions from multiple InPs, VNFPs, and SPs when TSPs require composite services.
  • 2) Telecommunications Service Provider (TSP):: End users consume TSP services and may connect to multiple TSPs for different services.
  • Performance: NFV must evaluate and mitigate bottlenecks across the stack to approach dedicated-hardware performance, including high-bandwidth connections between VM-hosted VNFs.
  • Performance: Compute-intensive VNFs such as DPI may require NFVI hardware acceleration, while DPDK studies report near-native packet-processing performance.

2) Security and Resilience:

NFV must address security isolation, telecommunications-grade resilience, openness, backward compatibility, and scalability rather than merely placing network functions on virtualized infrastructure.

  • 2) Security and Resilience:: NFV security must isolate subscriber functions and services from one another and protect NFVI resources from subscriber services.
  • 3) Reliability and Availability:: Telecommunications services expect outages below recognizable levels, typically milliseconds, with automatic recovery and geographically limited impact.
  • 3) Reliability and Availability:: NFV frameworks should support multiple availability classes because resiliency requirements differ across services such as telephony and SMS.
  • 4) Support for Heterogeneity:: Acceptable NFV platforms must be open and shared, support heterogeneous hardware and technologies, and allow end-to-end services across multiple infrastructure domains.
  • Backward Compatibility: Operators need support for both physical and virtual network functions during gradual NFV transitions.
  • Scalability: NFV requires scalable, responsive networking capable of supporting millions of subscribers, rather than necessarily deploying one VM per function.

1) Essential Characteristics of Cloud Computing:

Cloud computing provides shared, elastic, measured resources through SaaS, PaaS, and IaaS models, while NFV maps these abstractions onto network-function infrastructure and services. Cloud deployment offers flexibility and scalability, but telecom NFV requires carrier-grade adaptations for performance, reliability, and operational demands.

  • Essential Characteristics: Cloud capabilities include broad network access, resource pooling, rapid elasticity, and measured service.Resources are accessed through standard mechanisms, dynamically assigned across consumers, scaled with demand, and metered for optimization.
  • Service Models: The three cloud service models are SaaS, PaaS, and IaaS.SaaS provides provider-run applications, PaaS supports deployment of consumer applications, and IaaS provisions fundamental compute, storage, and networking resources.
  • NFV Mapping: NFV maps its infrastructure to IaaS and its services and VNFs to SaaS-like functionality.The mapping relates cloud service abstractions to portions of the NFV reference architecture.
  • Cloud-based NFV: Cloud-based NFV proof-of-concepts commonly deploy network functions on dedicated virtual machines because cloud deployment is flexible, scalable, and inexpensive to test.These properties support rapid service deployment, reduced duplication, and potential efficiency and expense reductions for telecommunications providers.
  • Carrier-grade Requirements: Telecom NFV differs from ordinary cloud computing through high-performance data-plane workloads, demanding network topologies, and carrier-grade scalability and availability requirements.The paper therefore argues that cloud environments must be adapted rather than simply used as-is for carrier-class network functions.
  • Infrastructure Requirements: Cloud-based NFV infrastructure requires functions spanning scheduling, networking, orchestration, and monitoring, while OpenStack does not yet satisfy all NFV requirements.Reported performance degradation and specialized acceleration efforts further indicate implementation gaps.

B. Software Defined Networking (SDN)

SDN separates network control from packet forwarding, making control programmable, agile, centrally managed, and vendor-neutral. NFV and SDN share software, virtualization, automation, and commodity-hardware goals, but they address different abstractions and network functions.

  • SDN Architecture: SDN decouples network control and forwarding functions through open interfaces such as ForCES and OpenFlow.The forwarding infrastructure can operate as programmable packet-forwarding devices, while control becomes directly programmable.
  • SDN Characteristics: SDN is programmable, agile, centrally managed, and open standards-based and vendor-neutral.These properties support automated configuration, dynamic traffic adjustment, global network views, and reduced dependence on vendor-specific protocols.
  • Relationship to NFV: NFV and SDN both promote open software, standard hardware, automation, and virtualization.NFV targets network functions on industry-standard hardware, while SDN implements its control plane as software on such hardware.
  • Complementarity: The paper presents SDN and NFV as complementary rather than interchangeable approaches.Their shared goals create opportunities for integration, but the expected advantages remain largely unproven promises.
  • Conceptual Distinction: SDN and NFV address different aspects of software-driven networking: NFV separates network functions from specialized hardware, whereas SDN separates packet handling from network control.NFV can operate over existing networks, while SDN requires a network construct separating data and control planes.

2) Research on SDN-based NFV:

Research on SDN-based NFV focuses on combining programmable control with virtualized network functions while addressing protocol, scalability, distributed-management, and carrier-grade cloud challenges. The paper emphasizes that integration can improve deployment and operations, but substantial technical work remains.

  • Southbound API: OpenFlow lacks application-layer support and has limitations in QoS, classification, tunneling, charging, and switch-oriented flow control for NFV.The paper reports that support must extend through layers L5-L7 and that enhanced OpenFlow implementations have been investigated.
  • Distributed Control: Current SDN deployments relying on a single controller face scalability and reliability concerns, while NFVI services require collaboration among network devices.Distributed SDN architectures remain an identified requirement for NFV support.
  • Controller Design: OpenNF redistributes packet processing across NF instances and provides controller communication for configuration and decision-making.Its event and forwarding-update combination addresses race conditions and bounds overhead.
  • Cross-technology Relationship: NFV, SDN, and cloud computing abstract different resources—functions, networks, and compute—while pursuing similar benefits such as agility, automation, and scaling.The paper frames their relationship as coordinated resource abstraction rather than a single unified technology.
  • Cloud-based NFV: Cloud-based NFV must become carrier-grade in performance, reliability, security, and communication between functions.Telecom deployment choices include public clouds and private clouds distributed across provider infrastructure.
  • Integration Scope: NFV can achieve its goals without SDN, although SDN may enhance performance, compatibility, and operations while NFV supplies infrastructure for SDN software.Their interaction also supports automated data-center services such as network as a service, load balancing, firewalls, and VPNs.

3) ATIS NFV Forum:

NFV standardization and implementation involve telecom, cloud, networking, open-source, and industry organizations with complementary objectives. Projects such as OPNFV and OpenMANO translate these efforts into carrier-grade platforms and ETSI-aligned management frameworks.

  • ATIS NFV Forum: The ATIS NFV Forum develops specifications for inter-carrier interoperability, service descriptions, and automated inter-provider processes.It also supports open-source implementation activities for these capabilities.
  • Related Industry Efforts: The Broadband Forum collaborates with ETSI on applying NFV to multi-service broadband networks.Its membership spans network operators, providers, vendors, consultants, and testing laboratories.
  • Adjacent Standards: Related standardization includes OVF for portable, secure distribution of virtual machines and appliances and OpenFlow for SDN control-forwarding communication.These technologies may contribute to NFV portability, deployment, and networking interoperability.
  • Standardization Landscape: Standards organizations show substantial involvement in NFV, with several bodies addressing aspects not yet sufficiently developed by ETSI.The paper leaves open whether the resulting standards will match the field’s needs.
  • Projects: ZOOM defines an operations environment for delivering and managing VNFs while exploring security approaches for NFVI and VNFs.Its catalyst projects use hands-on technology demonstrations sponsored by network operators.
  • Projects: OPNFV aims to provide a carrier-grade, integrated, open-source reference platform with consistency, performance, and interoperability across components.Its initial Arno release supplied an early NFVI and virtual-infrastructure build.
  • Projects: OpenMANO implements ETSI’s NFV MANO framework with emphasis on performance and portability through Enhanced Platform Awareness.Its architecture includes openmano, openvim, and a graphical user interface.

5) UNIFY:

The surveyed NFV projects target automated, dynamic service provisioning across network and cloud domains, while early implementations align with emerging standards and emphasize orchestration. The projects and implementations show NFV’s ecosystem spanning virtualization, SDN, cloud management, and open collaboration.

  • UNIFY: UNIFY researches automated orchestration, verification, and observation of end-to-end service delivery across home, enterprise, aggregation, core, and data-center networks.Its planned platform uses fine-grained service chaining, service abstraction, and a service creation language for dynamic placement.
  • T-NOVA: T-NOVA combines SDN and cloud management to automate the provision, configuration, monitoring, and optimization of Network Functions-as-a-Service.It also enables operators to deploy VNFs for themselves or offer them to customers as value-added services.
  • CONTENT: CONTENT proposes cross-domain virtualization for infrastructure slices and dynamic end-to-end service provisioning with variable QoS guarantees.The approach integrates subsets of network and computational physical resources across network segments.
  • Project landscape: The surveyed projects are guided by ETSI, 3GPP, and DMTF proposals, while industrial projects such as ZOOM, OPNFV, and OpenMANO focus on MANO.The survey identifies MANO as critical for operating NFVI and VNFs and for shifting from device-driven management toward lifecycle management of physical and virtualized functions.
  • Early implementations: Early NFV use cases implemented virtual routing, BRAS, policy servers, deep packet inspection, EPC, RAN, monitoring, CPE, GPRS, and access control in cloud environments.Commercial and collaborative efforts include HP OpenNFV, Huawei’s NFV Open Lab, and platforms aligned with ETSI functional blocks.

3) Intel Open Network Platform (Intel ONP):

The implementation survey describes platforms that combine open hardware or software ecosystems with NFV orchestration, management, SDN control, and cloud infrastructure. These efforts target programmable, scalable, and dynamically managed virtualized network services.

  • Intel ONP: Intel ONP advances open NFV and SDN solutions through product development, open-source participation, standardization, and industry proof-of-concept trials.Its ecosystem includes the Intel ONP Server as a reference architecture optimized for SDN/NFV.
  • CloudNFV: CloudNFV organizes its platform around active virtualization, an NFV orchestrator, and an NFV Manager.The orchestrator uses policies, service orders, and resource status to determine function placement and inter-function connections.
  • CloudBand: CloudBand separates virtual resource nodes from a management system that distributes work and makes hosting and connection decisions through cloud-management APIs.Virtual functions are deployed with recipes specifying deployable components and their connections.
  • Broadcom Open NFV: Broadcom’s Open NFV platform supports virtual-function migration across vendor platforms and uses open APIs to access acceleration components for scaling and reducing time-to-market.The platform targets NFV applications across multiple system-on-chip processors.
  • Cisco OPN: Cisco’s Open Network Strategy combines a service orchestrator, VNF manager, and SDN controller for lifecycle management, dynamic scaling, resource provisioning, and service connectivity.Its components use cloud resource managers such as OpenStack and VMware at the VIM layer and are designed around open standards and APIs.
  • Application and IMS platforms: F5 SDAS provides programmable Layer 4–7 application services with service injection, consumption, automation, and orchestration across pooled resources.ClearWater applies scalable web-application patterns to IMS services, with horizontally scaling stateless components and externalized long-lived state.

10) Overture Virtual Service Edge (vSE):

Overture vSE illustrates NFV at the service edge by hosting VNFs on an open carrier Ethernet platform and dynamically adjusting resources to demand. The broader survey presents NFV as promising but still emerging, with unresolved management, interoperability, and energy-efficiency questions.

  • Overture vSE: Overture vSE hosts VNFs at the service edge and enables on-demand deployment at customer premises.Its platform combines carrier Ethernet access with virtualization, openness, and software-defined services.
  • Overture vSE: Overture vSE dynamically turns VNFs up, down, expands them, or removes them so compute and storage resources are used only when needed.The platform uses Linux KVM/QEMU, an optimized virtual switch, and OpenStack integration with the Ensemble Service Orchestrator.
  • State of the field: NFV remains an emerging technology, and final-specification solutions and widespread end-user deployments may take several years to appear.Early implementations repeatedly emphasize open source and the ability of existing SDN and cloud technologies to support NFV.
  • A. Management and Orchestration: Current NFV management approaches do not fully address combined NFV and SDN dynamics, where traffic flows and function locations can change simultaneously.NFV deployment may scatter functions serving one customer across different server pools, challenging existing management systems.
  • A. Management and Orchestration: ETSI MANO lacks clear interoperability guidelines, contributing to vendor products that use custom models despite claiming alignment with the framework.The relationship between virtualized-function management and traditional OSS/BSS is also not fully defined.
  • B. Energy Efficiency: NFV’s energy benefit remains uncertain because reduced device operation may be offset by increasing data-center energy consumption.The paper calls for energy-aware hardware, placement, scheduling, and chaining while preserving function performance and service-level agreements.
  • B. Energy Efficiency: 41% power-consumption reduction was observed in a China Mobile C-RAN test, while cloud migration of selected U.S. business software was estimated to reduce primary energy footprint by as much as 87%.These figures concern specific deployments and software categories rather than NFV as a whole.
  • B. Energy Efficiency: G.W.A.T.T. models energy effects across six network domains and estimates 24,044.1 MWATTS of savings from virtualizing the EPC under its default 2015 settings.The same use case estimates 5.0×10^9 GJ of total energy savings over five years using 2013 as baseline.

C. NFV Performance

NFV performance can be high and predictable on commodity servers when best practices are followed, but some high-performance functions still require specialized acceleration. Efficient resource placement, migration, scheduling, and sharing remain open challenges, with placement and chaining becoming computationally intractable at scale.

  • Performance: Up to 80 Gbps per server was achieved in fully virtualized environments when NFV best practices were followed.The reported performance was predictable, consistent, and vendor-agnostic across use cases including DPI, C-RAN, and BRAS.
  • Performance: General-purpose platforms supported a C-RAN prototype with up to 90 TD-LTE carriers and 15 FDD-LTE carriers.China Mobile’s deployment also reported no impact on radio performance and verified NFV feasibility on general-purpose platforms.
  • Performance: High-speed processing remains difficult for some VNFs because industry-standard servers may not meet required performance levels.A virtualized Dedup function reached at most 267 Mbps throughput per core in reported tests, while hardware acceleration improved performance for some functions.
  • Resource allocation: Function placement and chaining form an NP-hard binary integer program, motivating heuristics for large instances.A greedy heuristic prioritizes VNFs with the highest resource demands to improve computational efficiency.
  • Resource allocation: Allocating a separate VM per subscriber or function can create excessive VM footprints, making finer-grained resource sharing necessary.Scheduling approaches include resource-constrained project scheduling, greedy criteria, tabu search, and existing cluster schedulers such as Borg and Mesos.
  • Resource allocation: NFV resource management requires algorithms for placement, migration, load balancing, energy saving, failure recovery, and dynamic sharing among VNFs.Research directions include online allocation, multi-domain and distributed VNFs, survivability, dynamic management, containers, and scheduling.

E. Security, Privacy and Trust

NFV introduces security, privacy, and trust concerns alongside the use of virtualized subscriber functions and cloud resources. Existing models and standards provide starting points, but interoperability, runtime management, and NFV-specific security processes remain incomplete.

  • Security, privacy and trust: Moving subscriber functions to public clouds can expose personally identifiable information and intensify privacy, security, and trust concerns.These concerns are especially relevant because virtualized functions represent subscriber services.
  • Security, privacy and trust: ETSI’s security evaluation confirmed that NFV creates new security concerns and produced NFV-specific security and trust guidance.The guidance identifies threats and proposed solutions but does not prescribe specific requirements or implementation details.
  • Security, privacy and trust: Some NFV security solutions exist without operational processes, while topology validation, network performance isolation, and multi-administrator isolation still lack solutions.Available solutions would also add procedural complexity once processes are established.
  • Modeling and interoperability: NFV’s automation and flexibility depend on open, standardized descriptors for multi-vendor resources, functions, and services across deployment and lifecycle management.The models must support both initial deployment and subsequent reconfiguration.
  • Modeling and interoperability: TOSCA can describe VNF definitions, monitoring, healing, and scaling, but existing models require further evolution for NFV-specific needs.Outstanding needs include portability, federated services, runtime management, and integration across modeling approaches.
  • Modeling and interoperability: Different vendors use different modeling languages, including TOSCA and YANG, creating potential interoperability problems across NFVI, VNFs, and MANO.The surveyed models may therefore serve as starting points rather than complete NFV solutions.

G. Research Directions in Selected NFV Use Cases

NFV research extends into IoT and information-centric networking, where virtualization and flexible placement address emerging scale and service challenges. The survey finds substantial open questions in data handling, interoperability, standardization, and the completeness of current performance evidence.

  • Internet of Things: NFV and SDN have been proposed as enablers for IoT architectures by virtualizing security, intelligence, computation, and storage near devices.These approaches aim to exploit NFV’s scalable distribution and SDN’s configuration flexibility.
  • Internet of Things: Managing large volumes of IoT-generated data requires efficient transport over softwarized networks and evaluation of real-time cloud data platforms.The cited open question concerns whether systems such as Hadoop and Cassandra can support real-time requirements.
  • Information-Centric Networking: NFV’s separation of information processing from forwarding is related to ICN and SDN, while the NFV–ICN relationship remains comparatively underexplored.ICN may help determine where network functions should be placed, including through function-centric service chaining.
  • Cross-cutting research challenges: Current NFV standardization leaves major gaps in interoperability, legacy support, and integrated management of legacy and NFV-based systems.These gaps may slow NFV deployment and undermine its anticipated business case.
  • Cross-cutting research challenges: Vendor-specific modeling languages and implementations can produce interoperability problems across NFVI, VNFs, and MANO.Examples include TOSCA-based, YANG-based, and proprietary descriptors.
  • Cross-cutting research challenges: Most proof-of-concept evaluations cover only a limited set of ETSI use cases, leaving performance and benefits across broader end-to-end services incompletely assessed.Research on NFV enablers such as ICN and application areas such as IoT also remains largely unexplored.
Loading 1509.07675v1…