PaperlayerView exact revision on arXiv

Source-linked AI summary

Survey on Network Virtualization Hypervisors for Software Defined Networking

Andreas Blenk, Arsany Basta, Martin Reisslein, Wolfgang Kellerer

arXiv:1506.07275v3cs.NI

TL;DR

SDN virtualization needs hypervisors that let multiple tenants share physical networks through isolated vSDNs while preserving programmable control. This survey classifies and compares existing SDN hypervisors, then outlines a comprehensive framework for evaluating their performance and resource effects. It finds incomplete abstraction and isolation coverage across existing designs and identifies unified benchmarking as a key research direction.

  • Problem

    Existing literature lacked a detailed survey of SDN hypervisors and comprehensive understanding of their abstraction and isolation features.

  • Method

    The paper comprehensively surveys SDN hypervisors, classifies their architectures and execution platforms, and outlines performance, resource-allocation, and adaptability evaluation directions.

  • Results

    Existing hypervisors generally provide incomplete network-attribute abstraction and isolation, with most focusing on only one or two attributes.

  • Takeaways & Limitations

    A unified performance benchmarking methodology with standard workloads and scenarios is needed to guide future SDN-hypervisor research.

Abstract

from arXiv · show

Software defined networking (SDN) has emerged as a promising paradigm for making the control of communication networks flexible. SDN separates the data packet forwarding plane, i.e., the data plane, from the control plane and employs a central controller. Network virtualization allows the flexible sharing of physical networking resources by multiple users (tenants). Each tenant runs its own applications over its virtual network, i.e., its slice of the actual physical network. The virtualization of SDN networks promises to allow networks to leverage the combined benefits of SDN networking and network virtualization and has therefore attracted significant research attention in recent years. A critical component for virtualizing SDN networks is an SDN hypervisor that abstracts the underlying physical SDN network into multiple logically isolated virtual SDN networks (vSDNs), each with its own controller. We comprehensively survey hypervisors for SDN networks in this article. We categorize the SDN hypervisors according to their architecture into centralized and distributed hypervisors. We furthermore sub-classify the hypervisors according to their execution platform into hypervisors running exclusively on general-purpose compute platforms, or on a combination of general-purpose compute platforms with general- or special-purpose network elements. We exhaustively compare the network attribute abstraction and isolation features of the existing SDN hypervisors. As part of the future research agenda, we outline the development of a performance evaluation framework for SDN hypervisors.

I. INTRODUCTION

Virtualization lets multiple tenants operate independent virtual networks over shared physical infrastructure, while SDN provides programmable centralized control. The article surveys SDN hypervisors and frames network virtualization around abstraction, isolation, and resource allocation.

  • Introduction: A hypervisor creates and monitors virtual SDN networks while allocating physical networking resources, including link and buffer capacity, to individual slices.Virtual Network Embedding assigns virtual nodes and paths to physical resources, and this problem is NP-hard.
  • Introduction: SDN separates control from forwarding, centralizes network control, and exposes open programmable interfaces for interacting with the physical network.OpenFlow provides a standardized control interface between the control plane and data plane.
  • Introduction: Virtual networks abstract underlying physical infrastructure so multiple tenants can independently operate slices with their own network operating systems.Virtualization can support new services, testbeds, and parallel deployment over shared infrastructure.
  • Introduction: The survey comprehensively reviews SDN hypervisors, classifying them as centralized or distributed and further by their execution platforms.The platform categories include general-purpose compute systems and combinations of compute platforms with general- or special-purpose network elements.

B. Software Defined Networking

SDN centralizes logical network control while separating control and forwarding through standardized interfaces. An SDN hypervisor uses these interfaces to expose isolated virtual networks to multiple controllers over one physical network.

  • Software Defined Networking: SDN decouples the control plane from the data plane and centralizes control of the physical network in a single logical controller.The data plane forwards payload data, while the control plane configures switch operation.
  • Software Defined Networking: The data-controller plane interface connects the physical forwarding plane to the SDN control plane through a standardized instruction set such as OpenFlow.ForCES is identified as an alternative instruction set.
  • Software Defined Networking: The hypervisor creates logically isolated vSDNs from one physical network, allowing tenants to operate their own controllers independently.The conceptual architecture places the hypervisor between the physical SDN network and control plane.
  • Software Defined Networking: A hypervisor interacts with the physical network and multiple virtual SDN controllers through D-CPI interfaces, which defines its virtualization role.The hypervisor abstracts the physical network into distinct views for the virtual controllers.
  • Software Defined Networking: This article addresses a previously unsurveyed area by comprehensively reviewing hypervisors that virtualize SDN networks into vSDNs.The survey focuses on the abstraction and isolation functions of SDN hypervisors.

B. Network Attribute Virtualization

SDN hypervisors virtualize topology, node resources, and link resources at different granularities. They must also isolate control-plane, data-plane, and addressing attributes among virtual networks.

  • Network Attribute Virtualization: The three principal abstraction targets are physical topology, node resources, and link resources, each supporting different virtualization levels.These dimensions determine how much physical-network detail is exposed to vSDN controllers.
  • Network Attribute Virtualization: Link virtualization can combine multiple physical links and an intermediate node into one virtual link, while node virtualization can combine physical nodes and their link into one virtual node.These transformations hide portions of the physical topology from virtual controllers.
  • Network Attribute Virtualization: Topology virtualization ranges from transparent 1-to-1 physical mappings to representing the entire physical topology as one virtual link or node.Intermediate granularities provide progressively more abstract virtual topologies.
  • Network Attribute Virtualization: Node-resource abstraction represents switch CPU and flow-table resources at varying levels of detail.Examples include assigned CPU cores, percentage of single-core capacity, and TCAM resources for flow-table processing.
  • Network Attribute Virtualization: Link-resource abstraction concerns bandwidth, available queues, and link buffers.These resources define the virtualization level exposed for physical network links.
  • Network Attribute Virtualization: Isolation must cover the control plane, data plane, and vSDN addressing so each virtual network has unique flow identifiers.The isolation requirements apply to vSDNs sharing the same physical SDN network.

1) Control Plane Isolation:

SDN hypervisors must isolate tenant control planes and the physical resources that affect their performance. The survey classifies hypervisors by architecture and execution platform, highlighting trade-offs among portability, performance, functionality, cost, and migration effort.

  • Tenant control-plane isolation ensures each vSDN controller appears to control its own network without interference from other vSDNs.
  • Hypervisor performance depends on compute, storage, and network resources available on its hosting platforms.
  • Flow-table isolation requires assigning each vSDN a specific amount of switch TCAM capacity for storing and matching rules.
  • Transmission-rate isolation supports QoS by assigning tenants prescribed link capacity, potentially using mechanisms such as WFQ.
  • Classification: The survey classifies hypervisors first as centralized or distributed, then by whether execution uses compute platforms alone or with general- or special-purpose network elements.
  • Execution-platform trade-offs: Software implementations provide portability, while network-element implementations can improve performance but may lack required hypervisor functions.
  • Execution-platform trade-offs: Replacing commodity network elements with special-purpose elements can be prohibitive because of additional equipment costs and migration effort.

V. CENTRALIZED HYPERVISORS

Centralized hypervisors run as central software components between tenant controllers and physical SDN switches. FlowVisor established core mechanisms for flowspace, topology, switch-CPU, flow-entry, bandwidth, and control-channel isolation, including nested virtualization.

  • Existing centralized hypervisors execute on a central general-purpose computing platform, with FlowVisor serving as the seminal SDN virtualization system.
  • FlowVisor: FlowVisor allocates each tenant a non-overlapping flowspace, allowing its controller to operate on a dedicated subset of OpenFlow header fields.
  • FlowVisor: FlowVisor uses prioritized header-field policies to isolate tenant slices, as illustrated by separate HTTPS, HTTP, and UDP control policies.
  • FlowVisor: FlowVisor provides bandwidth, topology, switch-CPU, flowspace, flow-entry, and OpenFlow control-channel isolation.
  • FlowVisor: Topology isolation exposes only slice-associated ports and switches by rewriting OpenFlow messages sent to tenant controllers.
  • FlowVisor: Nested FlowVisor instances provide different abstraction levels and policies for controllers operating over subordinate virtual networks.

4) Evaluation Results:

Evaluations show that centralized hypervisor extensions improve abstraction, flexibility, and isolation, but can introduce overhead or hardware and scalability constraints. Reported FlowVisor measurements demonstrate both effective resource isolation and measurable control-operation latency.

  • 16 ms for adding new flows and 0.48 ms for requesting port status are the average latency overheads reported for FlowVisor control operations.
  • With bandwidth isolation, a TCP slice received close to its prescribed bit rate, whereas without isolation it received only about one percent of the link bit rate.
  • FlowVisor’s CPU isolation limited switch CPU utilization to less than 20 %, while a malicious slice could otherwise saturate the CPU with about 256 port-status requests per second.
  • AdVisor: AdVisor hides intermediate physical nodes and links, allowing tenant controllers to see only the endpoints of a virtual path.
  • AdVisor: AdVisor shares flowspace through Layer-2 slice tags, but labeling adds processing overhead and VLAN identifiers limit the number of distinguishable slices.
  • VeRTIGO: VeRTIGO lets controllers select abstraction from full assigned-resource control to a single abstract resource, increasing average new-flow latency by roughly 35 % versus FlowVisor.
  • Other extensions: Enhanced FlowVisor adds flow-based bandwidth guarantees and admission control to address FlowVisor’s basic bandwidth allocation and admission-control limitations.
  • Other extensions: Slices Isolator provides configurable isolation of interfaces, packet processing, and buffer memory across virtual slices.

5) Double-FlowVisors:

Double-FlowVisors virtualize both the physical network and the vSDN control layer, while specialized hypervisors adapt slicing to wireless, optical, enterprise, and heterogeneous-controller settings. Policy-based systems compose rules rather than strictly isolating traffic.

  • Double-FlowVisors: Double-FlowVisors place one FlowVisor between tenant controllers and physical switches and another between applications and the vSDN controller layer.
  • Special network types: CellVisor extends FlowVisor to slice cellular wireless resources according to subscriber demands.
  • Special network types: RadioVisor periodically slices a three-dimensional space-time-frequency resource grid to assign radio resources among controllers.
  • Special network types: MobileVisor integrates FlowVisor functionality into virtual mobile packet networks spanning potentially multiple underlying physical mobile networks.
  • Special network types: Optical FlowVisor creates virtual optical networks from an optical circuit-switched network while considering optical physical-layer impairments.
  • Special network types: EnterpriseVisor monitors FlowVisor operation and assists resource allocation using deployment information stored in a database.
  • Policy-based hypervisors: Policy-based hypervisors support heterogeneous controllers by composing OpenFlow rules from multiple network applications and their controllers.
  • Policy-based hypervisors: The Compositional Hypervisor evaluates computation and rule-update overhead when controllers add, update, or delete OpenFlow rules.

2) CoVisor:

CoVisor composes policies from heterogeneous SDN controllers while abstracting topology and protecting the physical network. The surrounding designs distribute virtualization workload, support cross-infrastructure slices, and evaluate trade-offs in latency and throughput.

  • CoVisor: CoVisor composes prioritized policies from heterogeneous SDN controllers into one correct physical flow-table policy.It targets flow-table savings and controller performance through policy composition and topology abstraction.
  • CoVisor: Two to three orders of magnitude improvement was reported for CoVisor policy updates over the Compositional Hypervisor algorithm.The improvement was attributed to more sophisticated flow-table updates and topology abstraction.
  • FlowN: FlowN is a distributed hypervisor that uses container-based virtualization for tenant controllers, limiting users to extensions of NOX.Tenants cannot employ arbitrary vSDN controllers.
  • FlowN: FlowN abstracts complete physical networks into virtual topologies, hiding node migration and presenting tenants with virtual address spaces.Edge switches use VLAN tagging, while reserved flowspace and one processing thread per container support separation.
  • FlowN: With up to 100 virtual networks, FlowN maintained constant latency overhead, while FlowVisor overhead increased steadily.FlowVisor had lower overhead from 0 to 80 virtual networks than FlowN.
  • Network Hypervisor and AutoSlice: The Network Hypervisor stitches vSDN slices across heterogeneous physical infrastructures through abstraction and a higher-level API.AutoSlice similarly distributes a logically centralized hypervisor across domains and supports topology abstraction, message rewriting, and migration.

B. Computing Platform + General-Purpose NE based

This group of designs virtualizes addresses, topologies, data-center switches, and wide-area domains across heterogeneous infrastructures. Their evaluations show varied latency and throughput behavior, while some designs retain explicit scalability or isolation limitations.

  • OpenVirteX: OpenVirteX provides address and topology virtualization as an intermediate layer between vSDNs and controllers.It gives tenants the full OpenFlow header-field space by rewriting virtual addresses at network edges.
  • OpenVirteX: OpenVirteX added only 0.2 ms of control-plane latency relative to the non-virtualized reference in a Cbench evaluation.The comparison included FlowVisor and FlowN using five switch instances.
  • AutoVFlow: AutoVFlow removes a central administrator by delegating configuration to distributed domain administrators that exchange slice state and policies.In a two-domain evaluation, FLOW MOD messages incurred 5.85 ms latency overhead.
  • Carrier-grade: Carrier-grade reduces centralized-hypervisor overhead through direct vSDN-controller access, but adds processing complexity to the physical network.Its evaluation used a baseline with only one virtual network, limiting conclusions about interference and overload.

2) Datapath Centric:

Datapath Centric moves virtualization functions into switch extensions to address FlowVisor’s single point of failure and performance concerns. Related frameworks distribute virtualization, support heterogeneous protocols and optical networks, and expose explicit control-plane isolation trade-offs.

  • Datapath Centric: Datapath Centric implements virtualization functions as switch extensions to address FlowVisor’s single point of failure and improve virtualization-layer performance.Its xDPd basis supports physical networks containing switches using OpenFlow versions 1.0 through 1.2.
  • Datapath Centric: Datapath Centric combines one Virtualization Agent Orchestrator with one Virtualization Agent per switch for configuration, monitoring, slicing, translation, and resource abstraction.The agents communicate directly with vSDN controllers.
  • Datapath Centric: The Virtualization Agent added 18% latency overhead over the xDPd reference, with an average 0.429 ms gap from FlowVisor.A second evaluation examined scalability from 500 to 10000 rules and reported constant additional latency.
  • Distributed FlowVisor: Distributed FlowVisor places local slicing and tunneling modules on enhanced OpenFlow switches and synchronizes local databases with a global database.The global database provides an interface to vSDN controllers without requiring access to individual switch databases.
  • OpenSlice: OpenSlice extends OpenFlow and controller functionality to carry optical parameters and assign frequencies, slots, and modulation formats in elastic optical networks.Its centralized SDN control showed nearly constant path-provisioning latency as hop count increased, unlike hop-by-hop GMPLS control.
  • Advanced Capabilities and HyperFlex: The Advanced Capabilities framework supports vSDNs spanning switches with different OpenFlow versions and accommodates flexible forwarding and matching.HyperFlex further composes virtualization functions and supports centralized or distributed control-plane virtualization.
  • HyperFlex: Software and hardware control-plane isolation trade off OF control-message loss against latency.Hardware policing can trigger TCP retransmission backlog and higher latency, whereas software filtering can drop OF packets earlier.

VII. SUMMARY COMPARISON OF SURVEYED HYPERVISORS

The survey compares SDN hypervisors by the physical network attributes they abstract and identifies substantial variation in abstraction coverage. Topology abstraction is uncommon, especially alongside node and link resource abstraction, and distributed designs make deriving abstract topology views more difficult.

  • The comparison evaluates hypervisors by their abstraction of topology, node resources, and link resources.
  • Topology Abstraction: VeRTIGO and CoVisor are the only centralized hypervisors identified as abstracting physical topology, while FlowN, Network Hypervisor, AutoSlice, and OpenVirteX do so among decentralized hypervisors.
  • Topology Abstraction: Topology abstraction hides physical mappings while providing end-to-end virtual-node and virtual-link embeddings, simplifying slice operation and reducing exposure of physical topology.
  • Physical Node and Link Resource Abstraction: VeRTIGO and CoVisor combine topology abstraction with node and link abstraction, whereas other hypervisors may abstract node and link resources without abstracting topology.
  • Summary: Distributed hypervisor designs complicate abstraction because processing the entire topology is needed to derive an abstract view of a virtual slice.
  • Summary: Less than half of Table II cells indicate abstraction, and many studies address only one or two network attributes.

1) Control Plane Isolation:

The survey finds uneven isolation across control-plane, data-plane, and addressing resources. Existing designs typically isolate only selected attributes, while a small group isolates three considered attributes.

  • Control Plane Isolation: Only a few hypervisors isolate control-plane instances, including Compositional Hypervisor, FlowN, and HyperFlex.
  • Control Plane Isolation: FlowN assigns each slice a processing thread, while Network Hypervisor isolates slices through the APIs used to interact with physical SDN infrastructure.
  • Data Plane Isolation: FlowVisor and ADVisor isolate physical node resources by splitting flow tables and assigning CPU resources through control of OpenFlow messages.
  • Data Plane Isolation: Slices Isolator and Advanced Capabilities provide bandwidth guarantees and separate queues or buffers for virtual slices.
  • vSDN Address Isolation: Addressing proposals use fields such as VLAN tags, MPLS labels, and GRE labels as identifiers, but restricting controllers’ full flowspace remains a limitation.
  • Summary: None of the existing hypervisors fully isolates all network attributes; FlowVisor, OpenVirteX, and Carrier-grade isolate three considered attributes.

1) SDN Switch Benchmarking:

SDN switch and controller benchmarking uses direct connections in conventional networks and hypervisor-mediated control-plane paths in virtualized networks. The measurements cover protocol operations, packet processing, monitoring, cross-effects, throughput, and delay.

  • SDN Switch Benchmarking: In non-virtualized SDN, switch benchmark tools connect directly to switches and can measure OpenFlow status-request delay under varying loads.
  • In virtualized switch and controller setups, the evaluated hypervisor lies on the control-plane channel between benchmark tools and the network element.
  • SDN Switch Benchmarking: Switch tools can measure end-to-end packet processing from injection into the data plane through controller processing to forwarding.
  • SDN Switch Benchmarking: Switch evaluation includes OpenFlow packet processing, flow-table updates, monitoring capabilities, cross-effects, data-plane throughput, and processing delay.
  • SDN Controller Benchmarking: Controller benchmark tools emulate arbitrary numbers of switches and measure controller OpenFlow message throughput and response time.
  • SDN Controller Benchmarking: Controller throughput and response time should be evaluated in both single-message best-effort scenarios and mixed scenarios with multiple simultaneous message types.

1) vSDN Embedding Considerations:

The proposed framework evaluates hypervisors at system and individual-function levels, comparing virtualized setups with non-virtualized baselines and testing multi-tenancy effects. It covers abstraction and isolation under relevant workloads.

  • The framework uses two steps: benchmark the hypervisor system as a whole, then benchmark each hypervisor function separately.
  • vSDN Switch Evaluation: Single-vSDN-switch measurements are compared with non-virtualized switch results to quantify hypervisor overhead.
  • vSDN Switch Evaluation: Multi-tenancy testing connects one benchmark tool per emulated vSDN controller and compares each measurement with the single-vSDN-switch case to reveal cross-effects.
  • vSDN Controller Evaluation: Controller evaluation compares hypervisor-activated and hypervisor-deactivated setups, then uses multiple controllers to expose multi-tenancy cross-effects.
  • Multi-Tenancy: Multi-tenancy overhead arises from processing by each virtualizing function and from sharing hypervisor resources across vSDNs.
  • Abstraction Benchmarking: Detailed evaluation benchmarks topology, node-resource, and link-resource abstraction, including N-to-1 mappings and runtime filtering of resource information.
  • Isolation Benchmarking: Isolation benchmarking covers control-plane, data-plane, and addressing resources, with data-plane workload variation required when hypervisor functions share resources with data-plane functions.

IX. FUTURE RESEARCH DIRECTIONS

Future work for SDN hypervisors spans performance evaluation, resource allocation, reliability, hardware virtualization, and switch heterogeneity. The survey emphasizes that diverse designs and attribute choices create trade-offs, while rigorous comparative evidence remains limited.

  • Research gaps: The survey finds no single best hypervisor design and calls for rigorous, comprehensive performance evaluations and comparisons.Existing studies demonstrate feasibility but provide mainly general, vague lessons about abstraction and isolation.
  • Resource and performance requirements: Tenants may need to specify control-plane demands alongside virtual node and link demands because control-plane performance can affect the data plane.
  • Operational foundations: A standardized bootstrapping procedure is missing for connecting controllers, instantiating slices, and preparing vSDNs for use.
  • Resource allocation: Future VNE algorithms should model hypervisor-specific resource requirements when assigning physical resources to vSDNs.Different virtualization functions can require different physical resources, but existing studies largely neglect the hypervisor realization.
  • Reliability: Reliable deployment requires failure recovery and redundancy, although redundancy can increase management and processing overhead during normal operation.
  • Hardware virtualization: Hardware virtualization needs further study because switch capabilities vary and some switches cannot instantiate an OF agent for every virtual slice.
  • Switch abstraction: Vendor heterogeneity causes switch-performance variation, motivating hypervisor integration of deterministic performance models and online benchmarks such as Tango.

F. Scalable Hypervisor Design

Scalable hypervisor design must address distribution, placement, changing network types and demands, security, and adaptation. The survey concludes that comprehensive evaluation is needed to improve abstraction and isolation while keeping hypervisor overhead low.

  • F. Scalable Hypervisor Design: Practical deployments may require distributed hypervisors, creating open problems in scalability and efficient tenant-to-hypervisor and switch-to-hypervisor assignment.
  • F. Scalable Hypervisor Design: Hypervisor placement must account for physical-network geography, vSDN switch locations, and tenant-controller locations.
  • H. Hypervisors for Special Network Types: Hypervisor designs for wireless, optical, access, and sensor networks must accommodate their distinctive transmission, deployment, or resource constraints.
  • H. Hypervisors for Special Network Types: Future hypervisors must adapt to evolving networking techniques and match designs to specific network types and scales.
  • I. Self-configuring and Self-optimizing Hypervisors: Self-configuration and self-optimization should react on short timescales to changing demands while pursuing objectives such as energy awareness, load balance, and reliability.
  • Security: Security requires trusted encryption, key management across multiple hypervisors, attack protection, and benchmarking of security-induced processing overhead.
  • X. CONCLUSION: The survey classifies hypervisors as centralized or distributed and further distinguishes distributed designs by their execution platforms.
  • X. CONCLUSION: A unified evaluation methodology could guide improvements in abstraction and isolation while keeping hypervisor overhead low.
Loading 1506.07275v3…