PaperlayerView exact revision on arXiv

Source-linked AI summary

Software-Defined Networking: A Comprehensive Survey

Diego Kreutz, Fernando M. V. Ramos, Paulo Verissimo, Christian Esteve Rothenberg, Siamak Azodolmolky, Steve Uhlig

arXiv:1406.0440v3cs.NI

TL;DR

Traditional networking is difficult to manage and evolve because control and forwarding are vertically integrated. This paper surveys SDN through a bottom-up, layered analysis of its architecture, components, applications, and challenges, concluding that SDN has advanced research and development across networking systems.

  • Problem

    Traditional networks are complex and difficult to manage, while existing SDN surveys lacked a single comprehensive treatment of the paradigm’s concepts, building blocks, and challenges.

  • Method

    The paper methodically surveys SDN using a bottom-up, layered approach covering hardware, interfaces, virtualization, controllers, programming languages, applications, and cross-layer issues.

  • Results

    The survey covers SDN’s major architectural facets and future directions, including switch and controller design, scalability, performance, security, and dependability.

  • Takeaways & Limitations

    SDN has helped establish an innovative research and development environment spanning switch and controller platforms, scalability, performance, security, and dependability.

Abstract

from arXiv · show

Software-Defined Networking (SDN) is an emerging paradigm that promises to change this state of affairs, by breaking vertical integration, separating the network's control logic from the underlying routers and switches, promoting (logical) centralization of network control, and introducing the ability to program the network. The separation of concerns introduced between the definition of network policies, their implementation in switching hardware, and the forwarding of traffic, is key to the desired flexibility: by breaking the network control problem into tractable pieces, SDN makes it easier to create and introduce new abstractions in networking, simplifying network management and facilitating network evolution. In this paper we present a comprehensive survey on SDN. We start by introducing the motivation for SDN, explain its main concepts and how it differs from traditional networking, its roots, and the standardization activities regarding this novel paradigm. Next, we present the key building blocks of an SDN infrastructure using a bottom-up, layered approach. We provide an in-depth analysis of the hardware infrastructure, southbound and northbound APIs, network virtualization layers, network operating systems (SDN controllers), network programming languages, and network applications. We also look at cross-layer problems such as debugging and troubleshooting. In an effort to anticipate the future evolution of this new paradigm, we discuss the main ongoing research efforts and challenges of SDN. In particular, we address the design of switches and control platforms -- with a focus on aspects such as resiliency, scalability, performance, security and dependability -- as well as new opportunities for carrier transport networks and cloud providers. Last but not least, we analyze the position of SDN as a key enabler of a software-defined environment.

I. INTRODUCTION

Traditional networks are vertically integrated, complex, and difficult to evolve, while SDN separates control from forwarding and introduces programmable, logically centralized control. The survey examines SDN’s concepts, architecture, building blocks, standardization, and challenges through a layered approach.

  • Motivation: Traditional IP networks require device-by-device configuration using low-level, often vendor-specific commands, making them complex to manage.Network environments must also adapt to faults and changing conditions.
  • Motivation: Bundling control and data planes inside network devices reduces flexibility, hinders innovation, and contributes to slow network evolution.The incomplete IPv4-to-IPv6 transition illustrates the difficulty of introducing even protocol updates.
  • SDN Principles: SDN separates network control logic from forwarding devices and implements control in a logically centralized controller or network operating system.Logical centralization does not require physical centralization; production designs distribute control for performance, scalability, and reliability.
  • SDN Principles: A defined controller-switch API, notably OpenFlow, lets the controller directly manage dataplane state through flow tables containing packet-matching rules and actions.Flow entries can drop, forward, or modify matching traffic.
  • SDN Principles: Separating policy definition, hardware implementation, and traffic forwarding breaks network control into tractable pieces, simplifying management and facilitating evolution.The separation also supports creating and introducing new networking abstractions.
  • Survey Scope: Existing SDN surveys were narrower, whereas this paper aims to provide a comprehensive treatment of SDN’s fundamental concepts and building blocks.The paper also discusses ongoing research efforts, challenges, and future opportunities.
  • Survey Scope: The survey addresses SDN’s motivation, concepts, roots, standardization, architecture, APIs, virtualization, controllers, programming languages, applications, and cross-layer troubleshooting.Its core analysis uses a bottom-up, layered approach spanning eight infrastructure components and cross-layer problems.

A. Terminology

SDN terminology distinguishes forwarding devices, data and control components, interfaces, and broader interpretations of the paradigm. The survey also situates SDN standardization across formal organizations and industry consortia.

  • Core terminology: Forwarding devices execute instructions installed by SDN controllers through southbound protocols, while the data plane comprises interconnected forwarding devices.
  • Definitions of SDN: The survey notes that SDN’s scope has broadened beyond architectures with a cleanly decoupled control-plane interface.
  • Definitions of SDN: Overlay SDN dynamically programs network edges to manage tunnels while leaving the distributed underlay control plane unchanged.
  • Standardization: SDN-related standardization spans standards-development organizations, industrial consortia, and open-source projects that may produce de facto standards.
  • Standardization: Organizations including ONF, IETF, IRTF, ITU-T, BBF, MEF, IEEE, OIF, ODCA, ATIS, ETSI, and 3GPP pursue SDN or related initiatives.

D. History of Software-Defined Networking

SDN builds on earlier work in programmable networks, control/data-plane separation, virtualization, and network operating systems. The survey organizes these antecedents into historical categories and connects them to recent SDN developments.

  • Origins: SDN leverages earlier programmable-network efforts such as active networks, programmable ATM networks, and control/data-plane separation proposals.
  • Historical synthesis: The survey summarizes SDN-related history by separating pre-SDN initiatives from recent developments across five categories.
  • Programmable networks: Active networks proposed programmable switches and capsules, allowing nodes to compute on or modify packet contents.
  • Programmable data planes: ForCES, OpenFlow, and POF dynamically configure flow tables in forwarding devices through remote rule operations.
  • Control/data separation: NCP and related initiatives separated control and data-plane signaling to improve network management, innovation, efficiency, or global visibility.
  • Recent developments: Recent solutions such as SANE, Ethane, OpenFlow, NOX, and POF decoupled Ethernet control and data planes without requiring significant forwarding-device modifications.
  • Virtualization and NOSs: Network virtualization and network operating systems also predate SDN, with switchlets, Cisco IOS, and later OpenFlow-based systems providing historical precedents.

IV. SOFTWARE-DEFINED NETWORKS: BOTTOM-UP

The survey presents SDN bottom-up through layered, plane-oriented, and system-design views. It covers architecture components, OpenFlow device behavior, hardware evolution, software switches, and openness in the switching market.

  • Architecture views: An SDN architecture includes core layers such as southbound APIs, network operating systems, northbound APIs, and applications, with virtualization layers optional by deployment.
  • Architecture views: Figure 6 combines plane-oriented, layered, and system-design perspectives on SDN.
  • Architecture views: The survey introduces each layer bottom-up and also discusses cross-layer debugging and troubleshooting techniques.
  • System design: SDN removes embedded control intelligence from physical devices, turning them into forwarding elements governed by a logically centralized control system.
  • SDN devices: OpenFlow devices use flow-table pipelines whose entries contain matching rules, actions, and counters.
  • SDN devices: OpenFlow revisions added match fields, statistics, and capabilities, while required and optional features increased across versions.
  • Hardware infrastructure: Commercial and open-source OpenFlow equipment ranges from business switches to high-density devices with 100GbE connectivity and tens of Tbps capacity.
  • Software and market: Software switches support data-center and virtualized infrastructures, while whitebox switching separates software from hardware and gives users operating-system choice.

B. Layer II: Southbound Interfaces

Southbound interfaces connect SDN control and forwarding elements, with OpenFlow providing the most widely accepted open standard. Alternative interfaces trade off programmability, abstraction, device complexity, or scalability.

  • Interface role: Southbound interfaces bridge control elements and forwarding elements, defining communication and device instruction mechanisms.
  • Limitations: Southbound APIs remain tightly tied to the forwarding elements of the underlying physical or virtual infrastructure.
  • Adoption barriers: New switches can require two years for commercialization, with upgrade cycles up to nine months and software development lasting six months to one year.
  • OpenFlow: OpenFlow is the most widely accepted and deployed open southbound standard, specifying forwarding devices and communication between switches and controllers.
  • OpenFlow: OpenFlow supplies controllers with device events, flow statistics, and packet-in messages for flow-level network information.
  • Alternative interfaces: OVSDB complements OpenFlow by managing Open vSwitch functions including virtual instances, QoS, tunnels, queues, interfaces, and statistics.
  • Alternative interfaces: POF makes forwarding protocol-oblivious by moving packet parsing to the controller and installing generic keys and table-lookup instructions.
  • Alternative interfaces: OpFlex distributes some network-management complexity to forwarding devices to improve scalability while retaining logically centralized policies.

D. Layer IV: Network Operating Systems / Controllers

SDN controllers provide abstractions and services that separate application-level network policies from forwarding-device details. The survey compares centralized and distributed designs, emphasizing scalability, resilience, interoperability, and fault tolerance.

  • Controller role: Network operating systems abstract device-specific forwarding details and provide services such as network state, topology, discovery, and configuration distribution.
  • Centralized vs. Distributed: Centralized controllers manage all forwarding devices but introduce a single point of failure and may face scaling limitations.
  • Centralized vs. Distributed: Distributed controllers can scale across environments, improve resilience to failures, and support hybrid deployments spanning multiple data centers.
  • Consistency and fault tolerance: Most distributed controllers offer weak consistency, allowing distinct nodes to temporarily read different values for the same property.
  • Consistency and fault tolerance: Existing controllers may tolerate crash failures but generally do not tolerate arbitrary failures caused by abnormal node behavior.
  • Controller analysis: The survey analyzes production-level controllers by comparing architectural components, services, interfaces, consistency models, and fault-tolerance properties.
  • Interoperability: Interoperability and standardized multi-controller, multi-domain APIs remain critical challenges because networking environments use diverse technologies and control platforms.

E. Layer V: Northbound Interfaces

Northbound interfaces connect SDN applications with controller capabilities, but unlike southbound APIs, they remain diverse and lack a common standard. The survey reviews proposed abstractions and highlights interoperability and portability as central concerns.

  • Northbound interface status: A common northbound interface remains an open issue because SDN use cases are still being developed.
  • Northbound interface status: Northbound APIs are primarily software abstractions, whereas southbound APIs interface more directly with network hardware.
  • Portability and interoperability: Open and standardized northbound interfaces could promote application portability and interoperability across control platforms.
  • Existing approaches: Existing controllers and programming languages define diverse northbound abstractions for hiding controller and dataplane implementation details.
  • Standardization challenges: A single northbound interface may not emerge because security, routing, and financial applications have different requirements.
  • Existing approaches: PANE lets administrators define module-specific quotas and access policies while allowing end-host applications to request network resources dynamically.

F. Layer VI: Language-based Virtualization

Language-based virtualization uses abstractions and compilation to represent virtual network topologies, policies, and slices without exposing all forwarding-device details. The survey compares static slicing, heterogeneous virtualization, and programming-language approaches for modular network control.

  • Virtualization abstractions: Virtualization solutions express modularity and multiple abstraction levels while preserving properties such as protection and enabling different views of one physical infrastructure.
  • Virtualization abstractions: Pyretic represents abstract network topologies and their policies as network objects that hide information while exposing required services.
  • Static slicing: Static slicing compiles application-layer definitions into a monolithic control program containing slice definitions and network configuration commands.
  • Static slicing: Splendid isolation defines each slice through a topology, mappings onto infrastructure, and packet predicates associated with edge ports.
  • Virtualization technologies: Only libNetVirt supports heterogeneous technologies, while FlowVisor, AutoSlice, and OpenVirteX allow multiple controllers across network slices.
  • Programming-language abstractions: Programming languages address interference among network-control tasks, rule conflicts, distributed races, modularity, and code reuse.
  • Programming-language abstractions: High-level SDN languages target abstractions for network-wide structures, distributed updates, modular composition, virtualization, and formal verification.

H. Layer VIII: Network Applications

SDN applications span established network functions and newer capabilities across diverse environments. The survey groups them into five categories and illustrates benefits including automation, traffic optimization, energy savings, wireless management, and measurement.

  • Measurement and monitoring: Network applications translate control logic into dataplane commands, while OpenSketch supports concurrent measurement tasks through hashing, classification, and counting stages.
  • Application scope: SDN applications span home, enterprise, data-center, and exchange-point networks, covering routing, load balancing, security, reliability, and power reduction.
  • Application categories: Most SDN applications fall into traffic engineering, mobility and wireless, measurement and monitoring, security and dependability, or data-center networking.
  • Measurement and data centers: SDN-based monitoring and optimization can reduce network energy consumption by up to 50% under normal traffic conditions.
  • Traffic engineering: Traffic optimization supports dynamic VPN provisioning, application-aware networking, quality of service, and cellular-core signaling reduction of up to 70%.
  • Mobility and wireless: Wireless SDN enables seamless mobility, load balancing, virtual access points, spectrum management, interference coordination, and device-to-device offloading.
  • Mobility and wireless: Odin’s per-client LVAP abstraction isolates control logic between slices and supports mobility management, load balancing, channel selection, and troubleshooting.
  • Implementation patterns: NOX and OpenFlow dominate existing deployments, while security-related applications are especially numerous and alternative APIs are emerging.

I. Cross-layer issues

The survey treats debugging, verification, testing, and simulation as cross-layer SDN concerns. SDN enables richer tools, but large-scale verification remains difficult because network state changes frequently.

  • Debugging and troubleshooting: Traditional network debugging relies on primitive tools such as ping, traceroute, tcpdump, nmap, NetFlow, and SNMP statistics.
  • Debugging and troubleshooting: SDN’s hardware-agnostic control and open communication standards create opportunities for improved debugging, troubleshooting, verification, and testing tools.
  • Debugging and troubleshooting: Early OpenFlow tools identify faulty firmware, inconsistent flow rules, reachability failures, and routing faults through debugging actions or event replay.
  • Debugging and troubleshooting: NetSight-based tools monitor invariants and inspect packet histories, including hop-level ports and header values.
  • Verification and testing: Verification tools detect forwarding loops, black holes, security violations, reachability errors, and configuration problems through offline or online analysis.
  • Verification and testing: NICE generates diverse packet streams for corner cases, OFLOPS measures control and forwarding bottlenecks, and Alloy identifies unexpected protocol behavior.
  • Verification and testing: Large-scale forwarding-table verification is challenging because frequent routing changes prevent assuming a consistent network snapshot.
  • Simulation and emulation: Mininet enables rapid SDN prototyping and evaluation using software OpenFlow switches in virtualized containers with hardware-switch semantics.

V. ONGOING RESEARCH EFFORTS AND CHALLENGES

The survey’s ongoing-research discussion focuses on efforts to realize SDN’s vision and fulfill its promises. It highlights research directions warranting attention beyond the layered SDN-stack analysis.

  • The survey identifies ongoing research efforts as necessary to overcome challenges in realizing SDN’s vision and fulfilling its promises.

A. Switch Designs

SDN switch research addresses heterogeneous hardware, limited flow-table resources, low flow-modification throughput, and evolving programmability. Proposed solutions range from abstraction layers and compression to native and compiler-based designs.

  • Heterogeneous implementations: Commercial OpenFlow switches differ in features, performance, protocol adherence, and hardware or software architecture, complicating portability and behavior.
  • Heterogeneous implementations: NOSIX, tinyNBI, and TTPs address switch heterogeneity by translating application expectations or standardizing behavioral abstractions across implementations.
  • Flow-table capacity: TCAM flow tables provide flexible matching but are costly and typically small, with common capacities of 4K to 32K entries.
  • Flow-table capacity: The Espresso heuristic reduces inter-domain routing FIB size by 17%, saving up to 40,000 flow-table entries.
  • Switch performance: Commercial OpenFlow switches process 38 to 1000 flow-mod per second, with most below 500 flow-mod per second.
  • Evolving switch designs: Research explores specialized hardware combinations, stateful data-plane modules, caching, programmable chips, and CPU-based packet processing to improve SDN capabilities.
  • Native SDN switch designs: Forwarding metamorphosis and Protocol-Oblivious Forwarding pursue flexible, programmable hardware data planes beyond retrofitted OpenFlow designs.
  • Heterogeneous implementations: P4 uses a high-level compiler so programmers can specify packet-processing pipelines, parsing, and matching independently of target-switch implementation details.

B. Controller Platforms

SDN controller platforms are central to performance, scalability, reliability, modularity, interoperability, and safe application composition. The survey highlights distributed-control challenges and mechanisms for improving controller operation and reducing control-plane overhead.

  • Controller requirements: Controller platforms must become high-performance, scalable, distributed, modular, highly available, and programmer-friendly.Key distributed-platform concerns include latency, fault tolerance, load balancing, consistency, and synchronization.
  • Modularity: Controller modularity remains limited, forcing developers to reimplement basic network services and making platforms difficult to build, maintain, and extend.The survey links this lack of modularity to resistance against further innovation.
  • Interoperability: Interoperability efforts include portable programming languages and east/westbound interfaces, but controller interoperability remains far from fully realized.Examples include Pyretic, SDNi, and ForCES mechanisms.
  • Application composition: Statesman enables loosely coupled network applications to coexist on one control plane without compromising network safety and performance.It addresses application coexistence beyond approaches restricted to traffic engineering or application-level conflict resolution.
  • Distributed control: Distributed controller designs must balance consistency, fault tolerance, scalability, locality, synchronization, and application needs.Controller locality can support low latency and high availability, while state consistency introduces performance tradeoffs.
  • Availability: Connecting forwarding devices to two or three controllers can achieve up to five nines of availability and robust control-plane connectivity.The required controller count depends more on topology than network size, with fewer than ten often sufficient for common cases.
  • Data-plane delegation: Delegating suitable low-level functions to forwarding devices reduces control-plane traffic and computing overhead while improving network efficiency.Candidates include OAM, ICMP processing, MAC learning, neighbor discovery, and defect recognition.

C. Resilience

SDN resilience depends on preventing control-plane failures from disabling forwarding and on addressing scalability bottlenecks created by control/data-plane separation. The survey reviews distributed controllers, data-plane protection, and scaling strategies, while noting limits in current evaluations.

  • Resilience: Fault-tolerant SDN research and operational experience remain insufficient, although Google B4 provides evidence that SDN can be resilient at scale.Distributed controller architectures expose tradeoffs among consistency, durability, and scalability.
  • Failure recovery: Reactive failure recovery increases restoration time and control-channel load because switches must notify controllers and receive updated flow entries.The sequence includes failure notification, reroute computation or backup lookup, and rule installation.
  • Protection: Carrier-grade requirements such as 50 ms recovery motivate pre-established backup paths and fast-failover actions in forwarding devices.OpenFlow group tables can implement protection without waiting for controller intervention.
  • Scalability: Scalability concerns arise because reactive configurations send new-flow packets to controllers, increasing control traffic, load, and latency.Real-time external flow-table configuration also makes the control plane a potential bottleneck.
  • Scaling strategies: Scaling proposals divide into data-plane, control-plane, and hybrid approaches that delegate work, improve controller throughput, or split logic between devices and controllers.Examples use forwarding-device processing, buffering, pipelining, parallelism, or authoritative switches.
  • Evaluation caveat: Some scalability evaluations report up to 20M flows/s, but they often measure simple packet-in and packet-out workloads rather than full application and security complexity.Controller performance can change with application count, application complexity, and security mechanisms.

E. Performance evaluation

The survey finds that SDN performance depends strongly on implementation choices, controller placement, workload, and rule-installation strategy. It emphasizes analytical and experimental evaluation while cautioning that simplified benchmarks may not represent production behavior.

  • Evaluation motivation: Few performance studies had properly investigated OpenFlow and SDN architecture, motivating analytical models, simulations, and experiments.Closed-form models can provide quick approximate performance estimates before detailed simulation or experimental data is available.
  • Switch performance: 25% higher packet-switching throughput is reported for commodity network hardware compared with soft OpenFlow switching in Linux.The passage attributes the comparison to lookup-performance design choices using standard commodity network interface cards.
  • Hardware acceleration: 20% lower packet delay is reported for network-processor hardware acceleration compared with conventional OpenFlow switching designs.These are described as early reports on hardware-accelerated switching.
  • Flow setup: Reactive flow-rule installation can produce unacceptable data-center performance when one OpenFlow controller handles only eight switches.The survey therefore recommends combining proactive and reactive flow setup for large-scale deployments.
  • Benchmark limitations: Controller benchmarks can report impressive throughput while omitting effects from complex applications, security mechanisms, and per-switch behavior.Cbench is single-threaded, and aggregated measurements may obscure individual-switch responses.
  • Controller placement: Controller placement and count depend on topology, reliability, latency, and scalability requirements rather than network size alone.One controller may often maintain reasonable latency, while WANs may require more controllers for reliability and low control-plane latency.
  • Distributed control: Distributed controllers support logical centralization because full physical centralization conflicts with responsiveness, reliability, and scalability.Inconsistent global state can reduce application optimality, whereas awareness of state distribution can improve robustness.

G. Migration and Hybrid deployments

Migration beyond greenfield or isolated deployments requires hybrid SDN that interoperates with legacy control planes, devices, protocols, and domains. The survey presents multiple hybrid models and early frameworks for incremental deployment, while noting added complexity.

  • Adoption boundary: Broader SDN adoption requires integration with legacy switching, routing, and operations infrastructure beyond greenfield data-center deployments.Early deployments were mainly greenfield or tightly controlled single administrative domains.
  • Incremental deployment: Hybrid networking can apply OpenFlow to selected flows, devices, or ports while interacting with legacy devices, OAM protocols, and neighboring domains.Migration paths are presented as critical where forklift upgrades are impractical.
  • Hybrid devices: Hybrid switches can operate as legacy switches, OpenFlow switches, or both by partitioning their ports between control paradigms.The ONF Migration Working Group addresses coexistence of hybrid architectures and hybrid devices.
  • Controller integration: Controllers such as OpenDaylight, HP VAN SDN, and OpenContrail integrate protocols including SNMP, PCEP, BGP, NETCONF, OpenFlow, and OVSDB.ClosedFlow instead brings SDN-like programming capabilities to traditional infrastructures.
  • Hybrid models: Hybrid SDN models partition control by topology, service, traffic class, or integration through traditional protocols such as BGP.These models assign different forwarding responsibilities to SDN and legacy mechanisms.
  • Trade-offs: Initial trade-off analyses suggest that combining centralized and distributed paradigms may provide mutual benefits, but interaction mechanisms must limit added complexity.Further work is required to maximize the benefits of paradigm coexistence.

H. Meeting carrier-grade and cloud requirements

SDN offers carrier and cloud providers more flexible, manageable, and cost-effective infrastructure, while large-scale deployments still require protocol extensions and resiliency mechanisms.

  • Carrier networks are exploring SDN for mobile-core migration, network virtualization, and network-as-a-service capabilities.
  • Large-scale wide-area SDN requires extensions for technology-specific functions, failure recovery, and integration across network components.
  • Cloud providers can use logically centralized control to improve datacenter networking, traffic engineering, fault tolerance, resource migration, and reliability.
  • SDN can reduce infrastructure costs by replacing complex, expensive hardware with simpler forwarding devices.
  • Carrier and cloud providers view SDN as an opportunity for flexibility, cost-effectiveness, and easier network management, although many expectations remain open issues.

I. SDN: the missing piece towards Software-Defined Environments

Software-Defined Environments extend programmability across compute, storage, management, networking, and applications, with SDN supplying the programmable network control needed for complete infrastructure automation.

  • Software-Defined Environments dynamically configure and reconfigure the IT stack to respond to workload changes and optimize resource use.
  • SDE workloads are independent of specific systems or vendors and can access the environment programmatically while enforcing policies.
  • The four essential SDE building blocks are Software-Defined Networks, Storage, Compute, and Management.
  • Existing virtualization and orchestration advances enabled software-defined storage, compute, and management, but lacking programmable network control hindered complete SDE realization.
  • An SDE focuses infrastructure reconfiguration on business-defined workload needs rather than on underlying infrastructure limitations.
  • The survey uses a bottom-up layered approach to analyze SDN hardware, interfaces, virtualization, controllers, programming abstractions, applications, and challenges.
  • SDN has promoted research and development in switch and controller design, scalability, performance, security, and dependability.
  • Migration, carrier transport, network-as-a-service, and software-defined environments remain areas requiring further research.
Loading 1406.0440v3…