PaperlayerView exact revision on arXiv

Source-linked AI summary

A Survey on Software Defined Networking: Architecture for Next Generation Network

Sanjeev Singh, Rakesh Kumar Jha

arXiv:2001.10165v1cs.NI

TL;DR

Growing Internet traffic and demanding applications pose a challenge for efficient network delivery. The paper surveys SDN’s evolution, architecture, OpenFlow interfaces, and related work, and proposes a heterogeneous-network architecture. It concludes by describing SDN’s control/data-plane separation, proposed architecture, and movement toward standardization.

  • Problem

    Growing traffic and future Internet applications create a challenge for efficient and economical packet delivery using existing network technology.

    Source: §1 · p. 2

  • Method

    The paper surveys SDN concepts, architecture, historical development, OpenFlow interfaces, selected architectures, and research projects, and proposes an SDHN architecture.

    Source: §1 · p. 3, §11 · p. 45

  • Results

    The paper presents SDN’s control/data-plane separation and a proposed centralized-controller architecture spanning packet, optical, and wireless devices, alongside discussion of standardization activity.

    Source: §11 · p. 45

  • Takeaways & Limitations

    The paper describes a future Internet service model in which virtualization separates virtual-network providers and operators from service providers offering customized services.

    Source: §11 · p. 45

Abstract

from arXiv · show

The evolution of software defined networking (SDN) has played a significant role in the development of next-generation networks (NGN). SDN as a programmable network having service provisioning on the fly has induced a keen interest both in academic world and industry. In this article, a comprehensive survey is presented on SDN advancement over conventional network. The paper covers historical evolution in relation to SDN, functional architecture of the SDN and its related technologies, and OpenFlow standards/protocols, including the basic concept of interfacing of OpenFlow with network elements (NEs) such as optical switches. In addition a selective architecture survey has been conducted. Our proposed architecture on software defined heterogeneous network, points towards new technology enabling the opening of new vistas in the domain of network technology, which will facilitate in handling of huge internet traffic and helps infrastructure and service providers to customize their resources dynamically. Besides, current research projects and various activities as being carried out to standardize SDN as NGN by different standard development organizations (SODs) have been duly elaborated to judge how this technology moves towards standardization.

1 Introduction

The paper surveys SDN’s development and architecture as networking demands grow. It traces its history, explains its technologies and OpenFlow interfaces, and outlines a proposed heterogeneous-network architecture and standardization activity.

1 Introduction

  • Growing traffic and data-intensive applications make efficient, high-capacity network delivery a challenge, motivating interest in SDN.The introduction cites multimedia, big-data analysis, and future Internet applications as drivers of demand.Source: §1 · p. 2
  • SDN separates data forwarding from control decisions and provides unified programmatic control across multiple data-plane elements.The paper describes a network-wide view and changes made globally rather than device by device.Source: §1 · p. 2
  • The article surveys SDN’s basic concepts, architecture, historical evolution, OpenFlow, and related research and standardization activities.It also presents a proposed software-defined heterogeneous network architecture.Source: §1 · p. 3

2 SDN as an Advancement over Conventional Network

Conventional networks rely on device-level routing rules and configuration, while SDN separates control logic from packet forwarding. The paper presents this separation and software-based control as a way to manage traffic and network resources centrally.

2 SDN as an Advancement over Conventional Network

  • Conventional devices use embedded rules and protocols, which the paper associates with limited dynamism and difficulty reprogramming network operation.The cited constraints include performance in speed, scalability, security, and reliability under high traffic.Source: §2 · pp. 3–4
  • SDN moves control logic from individual network nodes into software, separating the control plane from the data plane.The data plane forwards packets using flow-table entries; the control plane governs network decisions.Source: §2 · pp. 3–4
  • Central software lets administrators change traffic flow and switching or routing characteristics without configuring each device individually.The described flow-table entries contain matching, counter, and instruction fields.Source: §2 · p. 4
  • The paper connects SDN and OpenFlow with virtualization for optical transport control and describes optical packet-and-circuit integration as a flexible, energy-efficient, high-speed approach.The cited optical network context is the metro/core network.Source: §2 · p. 4

3 Motivation

The paper motivates SDN as a response to growing traffic and the complexity of managing large, heterogeneous networks. It also discusses controller capacity, mobility, flexible spectrum use, and integration across transport technologies.

3 Motivation

  • Manual configuration and heterogeneous equipment make network management complex, while traditional configuration, optimization, and troubleshooting can become inefficient or insufficient.The proposed response is to separate control logic from the data plane and manage network operation through software.Source: §3 · pp. 4–5
  • A study of 100,000 endpoints and 256 switches reports at least 50,000 new flow requests per second managed by several OpenFlow controllers.The passage names NOX-MT, Maestro, and Beacon among the implementations.Source: §3 · p. 5
  • Optical SDN is presented as supporting on-demand service mobility and migration through programmable traffic control and load balancing that consider bandwidth and latency.The passage places this use in data centers.Source: §3 · p. 6
  • Elastic optical networking allocates flexible spectrum to individual links rather than using a static wavelength grid, with spare spectrum available for rerouted signals.The paper also notes that SDN can integrate multiple transport technologies and network domains.Source: §3 · p. 6

4 Literature Survey on Historical Evolution of SDN

The paper organizes SDN’s history into successive stages, from active networking to control/data-plane separation and then OpenFlow APIs and network operating systems. It describes network virtualization as advancing alongside those stages.

4 Literature Survey on Historical Evolution of SDN

  • The paper dates active networking to 1995–2001 and associates it with introducing programmable functions for network operators.The figure presents a selective historical evolution over roughly 20 years.Source: §4 · p. 6, Figure 2 · p. 7
  • Control and data-plane separation is dated 1998–2007, when open interfaces for communication between the planes were developed.Source: §4 · p. 7
  • The 2007–2014 stage features wider use of open interfaces and network operating systems, including NOX, Onix, and ONOS.The passage says these developments made control/data-plane segregation and scalability practicable.Source: §4 · p. 7
  • Network virtualization advanced alongside the historical stages, focusing on routing traffic flow and supporting a wide range of applications.The paper says Table 2 summarizes the progression from active networking to OpenFlow-based SDN and virtualization.Source: §4 · p. 7

5 Literature Survey on SDN Technology and Architecture

The survey traces SDN’s development and reviews architectures, protocols, and technologies relevant to its use. It describes SDN as a framework for managing network devices and traffic through programmable control.

5 Literature Survey on SDN Technology and Architecture

  • SDN is presented as a framework for dynamically managing network devices, topology, services, QoS, and traffic-path policies through high-level languages and APIs.Its listed features include separating data and control planes, giving controllers a global network view, and enabling programming by external applications.Source: §5 · pp. 7, 10, 11
  • Table 2 gives a brief, selective account of the historical evolution of SDN architecture in chronological order.Source: Table 2 · p. 8
  • OpenFlow is described as a standard for communication between a unified controller and switches in SDN.The review also lists earlier work on centralized policy control, including Ethane, and on network configuration management, including NETCONF.Source: §5 · p. 9
  • The reviewed control platforms include NOX, Onix, and ONOS, with descriptions emphasizing coordination, distributed control, or scale and availability.The passages characterize Onix as a distributed control platform for large-scale production networks and ONOS as designed for scale and availability.Source: §5 · p. 9
  • The survey also covers virtualization and evaluation approaches, including Mininet, FlowVisor, and virtual network infrastructures such as PlanetLab and VINI.These examples support testing, network slicing, or evaluation of services and protocols.Source: §5 · p. 10

5.1 Infrastructure Layer

The infrastructure layer comprises physical network elements and transmission media, while SDN switches forward packets under controller-provided rules. The section also surveys constraints and technologies across switching, optical, virtual, wired, and wireless infrastructure.

5.1 Infrastructure Layer

  • The infrastructure layer contains physical network elements, including Ethernet, router, optical, and virtual switches and wireless access points, interconnected over wired, wireless, or optical media.Its operational focus includes efficient switching and transmission-media utilization.Source: §5.1 · p. 11

5.1.1 Switching Devices

  • SDN switches forward packets using rules supplied by a controller, and can match on TCP or UDP ports, VLAN tags, and ingress ports as well as IP or MAC addresses.Pure OpenFlow switches depend on the controller; hybrid switches also support traditional operation and protocols.Source: §5.1.1 · pp. 11–12
  • Limited switch memory can lead to packet drops or repeated controller queries, while route aggregation and cache replacement are described as ways to use it more efficiently.SRAM is characterized as more flexible to scale, whereas TCAM offers faster packet classification but is expensive and power hungry.Source: §5.1.1 · p. 12

5.1.2 Optical Switching

  • Optical switches can replace electronic network elements to avoid optical-to-electrical-to-optical conversion stages and their associated transmission delay.The passage also characterizes optical switching as inexpensive because it does not require extensive high-speed electronics.Source: §5.1.2 · p. 12

5.1.3 Virtual Switches

  • Open vSwitch connects virtual machines to physical interfaces and manages traffic between them, rather than connecting the VMs directly to network interface cards.The passage names Linux-based virtualization environments including QEMU, Xen, KVM, and XenServer.Source: §5.1.3 · p. 13

5.1.4 Transmission Media

  • SDN’s support for wired, wireless, and optical media requires integration with wireless and optical technologies because each medium has distinct configuration and management needs.The passage frames such integration as necessary to increase SDN’s service area.Source: §5.1.4 · p. 13

5.1.5 Wireless Access Point

  • A central SDN controller can manage wireless link association, channel selection, transmission rate, and traffic shaping using current and historical measurements.The listed measurements include packet count, packet size, and airtime utilization.Source: §5.1.5 · p. 13

5.1.6 Optical Fibers

  • Optical-fiber networks use ROADMs for software reconfiguration, giving the SDN controller control over packet forwarding, wireless modes or channels, and optical wavelengths.The passage describes optical fibers as high-capacity and low-power media used in network backbones.Source: §5.1.6 · p. 13

5.2 Controller Layer

The controller translates application policies into forwarding rules while collecting and synchronizing network status. The section also surveys controller-performance techniques, southbound protocols, optical-network interfaces, and coordination with applications and other controllers.

5.2 Controller Layer

  • The controller translates application policies into forwarding rules and synchronizes infrastructure status into a global network view.Its four components are a high-level language, rule update, network-status collection, and network-status synchronization processes.Source: §5.2 · p. 14, Figure 4 · p. 14

5.2.1 High Level Language

  • Network-programming languages should expose network state, express and reconcile application policies, and preserve access control and forwarding invariants during updates.Frenetic, Pyretic, and Procera are cited as examples.Source: §5.2.1 · pp. 14–15

5.2.2 Rules Update

  • Strict consistency applies either the original or updated rule set per packet or flow, while eventual consistency permits old-flow packets during an update.Rules must adapt to configuration changes while maintaining loop-free, black-hole-free, and secure operation.Source: §5.2.2 · p. 15

5.2.3 Network Status Collection

  • Switches store local traffic statistics, which controllers retrieve by pull or push to construct a network-topology view for applications.Collected statistics include packet count, duration, data size, and bandwidth share.Source: §5.2.3 · p. 15

5.2.4 Network Status Synchronization

  • Multiple controllers can address centralized-controller bottlenecks, but must synchronize their collected status to maintain a shared global network view.HyperFlow is described as sharing that view among controllers.Source: §5.2.4 · pp. 15–16

5.3 Control Layer Performance

  • Controller scalability is constrained by repeated switch requests and status exchanges, which consume bandwidth and add communication latency.The survey names parallelism and batch processing, request reduction through authority switches or device organization, and Cbench and OFCbench benchmarking.Source: §5.3 · p. 16, §5.3.1 · p. 16, §5.3.2 · p. 16

5.4.1 Protocol Options for the Southbound Interface

  • OpenFlow is the commonly used southbound interface; ForCES offers more flexible modes and richer protocol features but is less widely adopted.PCE is another option: a path-computation client requests a path from a PCE that may hold the traffic-engineering database and may be centralized or distributed.Source: §5.4.1 · p. 17

5.4.2 OpenFlow Protocol Extension for Optical NEs Interface in OpenFlow-Based Optical Network

  • For optical equipment, OpenFlow rules direct switch forwarding, while proposed alternatives include GMPLS and a hybrid OpenFlow-agent/GMPLS approach.The northbound interface connects applications to the controller, and east-west interfaces support distributed controllers; HyperFlow shares network-status changes through publish/subscribe events.Source: §5.4.2 · pp. 18–20, §5.4.3 · p. 20, §5.4.4 · p. 21

5.5 Application Layer

The application layer uses network information and programming languages to support network functions. The survey discusses adaptive routing, roaming, maintenance, security, virtualization, and energy-aware networking.

5.5 Application Layer

  • SDN applications use global network status and programming languages to manipulate network elements for functions such as traffic engineering, security, and path computation.The section identifies ALTO and XSP/XMPP among the protocols used to access network information.Source: §5.5 · p. 22

5.5.1 Adaptive Routing

  • SDN's closed-loop use of global status supports adaptive routing, including load balancing and cross-layer design.The survey describes load balancing as directing client requests among servers and cites differentiated handling of web and email traffic.Source: §5.5.1 · p. 22, §5.5.1.1 · p. 22

5.5.1.2 Cross-Layer Design

  • Cross-layer design can use SDN application access to network status to dynamically configure network elements, including optical switches.The cited approach aims to increase integration among entities at different network layers.Source: §5.5.1.2 · p. 22

5.5.2 Boundless Roaming

  • SDN's unified control plane across carriers and technologies is presented as a route toward boundless mobility beyond same-technology handover.The cited Odin approach reports low-delay reassociation, no throughput degradation, and minimal HTTP-download impact during single or multiple handovers.Source: §5.5.2 · p. 23

5.5.3 Networking Maintenance

  • Centralized automated management can reduce configuration errors, and a cited restoration technique has the controller calculate a new path after failure detection.Source: §5.5.3 · p. 23

5.5.4 Network Security

  • The survey presents centralized SDN control as a way to implement and check merged security policies across heterogeneous networks.Source: §5.5.4 · p. 23

5.5.5 Network Virtualization

  • FlowVisor slices physical-network resources—including topology, flow space, bandwidth, switch CPU, and control channel—for virtual research networks.Source: §5.5.5 · p. 23

5.5.6 Green Network

  • An energy-aware data-link adaptation mechanism is cited for selecting a minimum data link and switching devices in data-center networks.Source: §5.5.6 · pp. 23–24

6 OpenFlow

OpenFlow separates control from forwarding through a controller connected to switches over a secure channel. Switches match packets against flow-table entries and consult the controller when no entry matches.

6 OpenFlow

  • OpenFlow comprises data-plane switches, one or more controllers, and a secure OpenFlow control channel.Source: §6 · p. 24
  • OpenFlow switches forward packets using flow-table entries containing match fields, counters, and instructions; unmatched packets are sent to the controller for rules.The controller can install, remove, or modify entries and set paths through multiple switches.Source: §6 · pp. 24–26
  • The section presents OpenFlow's advancement chronologically and identifies selective controllers in a table.Source: Table 5 · p. 24, Figure 8 · p. 26

7 Working of SDN

The controller manages network functions and uses an abstract topology view to optimize flow management and support service requirements. Switches forward matching flows locally and send unmatched packets to the controller for rule installation.

7 Working of SDN

  • The controller performs route management, network visibility, provisioning, virtualization, and network-overlay orchestration.It receives information through a southbound API and can allocate bandwidth dynamically from the application layer to the data plane.Source: §7 · pp. 26–27
  • When a switch has no matching flow-table entry, it sends the packet to the controller, which updates rules along the path before forwarding resumes.The described sequence uses a secured channel and southbound APIs such as OpenFlow, ForCES, or PCE.Source: §7 · p. 27

8 Architecture Survey

The survey reviews selected SDN architectures that connect packet and optical networks, from OpenFlow-controlled lightpaths to multi-domain and application-aware resource coordination.

Architecture Survey

  • The delay approach establishes the optical lightpath before ingress flow entries, enabling end-to-end transmission without packet loss; passive release latency increases as optical-network complexity grows.The comparison is with sequential setup and active release, respectively.Source: §8 · p. 30
  • An integrated OpenFlow-GMPLS control plane uses OpenFlow for packet networks and GMPLS for optical lightpaths, coordinating on-demand UHD video access [97].The controller requests optical setup through an OpenFlow gateway and updates ingress and egress flow tables after the lightpath is established.Source: §8 · pp. 30–31, Figure 13 · p. 31
  • A multi-domain architecture combines packet, fixed-grid, and flexible-grid optical networks; experiments found its hybrid GMPLS/OpenFlow approach better than standalone OpenFlow agents.It selects RSA for flexible-grid requests and RWA for fixed-grid requests.Source: §8 · pp. 32–33, Figure 15 · p. 32
  • An extended SDN controller adds performance-monitoring, flow-convergence, and rate-control modules; experiments reported improved bandwidth utilization and reduced transfer time, latency, and packet loss.It uses GMPLS for optical switches and OpenFlow for packet switches.Source: §8 · pp. 33–34, Figure 16 · p. 34
  • For data-center migration over elastic-grid networks, eSDN applies TA-CSO across application and network resources; under dense traffic, it reduced blocking probability versus CSO and PLA.The architecture divides control between an application controller and a transport controller.Source: §8 · pp. 34–35, Figure 17 · p. 35

9 Software Defined Heterogeneous Network (SDHN) Architecture

The proposed SDHN architecture unifies packet, optical, and wireless network elements under a centralized SDN controller. OpenFlow and OpenFlow-agent/GMPLS interfaces connect the controller to the heterogeneous data plane.

Software Defined Heterogeneous Network (SDHN) Architecture

  • The SDHN combines a centralized unified controller with packet switching, optical circuit switching, and wireless devices, including base stations or access points for clients.The controller manages routes, network visibility, and network overlays through OpenFlow and OpenFlow-agent/GMPLS southbound interfaces.Source: §9 · pp. 35–36
  • The architecture also illustrates a client requesting on-demand UHD video access from a server.The figure labels this request as a sequence of events.Source: Figure 19 · p. 37, §9 · p. 37
  • For unmatched flows, the controller calculates a route, installs flow entries, and sends OpenFlow messages to OpenFlow-agent/GMPLS, which translates them into TL1 commands for ROADM lightpath setup.Matched packets are forwarded according to existing flow-table entries.Source: §9 · pp. 36–37

10 Current Research and Standardization of SDN as NGN

The survey describes ongoing SDN research and standardization activity, spanning OpenFlow deployments, WAN and wireless networking, and efforts by multiple standards organizations.

10 Current Research and Standardization of SDN as NGN

  • The survey describes OpenFlow's expanding specifications, compliant switches and controllers, and an ecosystem promoted by the ONF, established in 2011 by major technology and telecommunications companies.Tables 5 and 6 are identified as inventories of compliant controllers and switches.Source: §10 · pp. 37–38

10.1 Ongoing Research Efforts

  • Ongoing research includes OpenFlow-based WAN deployment and SDN approaches for wireless mobility, spectrum allocation, virtual access points, handovers, and cellular resource management.The survey also points to OpenRoad and PhoneNet examples and lists current research projects in Table 7.Source: §10.1 · p. 38, Table 7 · p. 41

10.2 Standardization Efforts

  • The paper reports ongoing efforts to standardize SDN-based networks through SDOs and community consortia, with activity details in Table 8; SG 11 focuses on protocols and broadband access.SG 13 focuses on architecture and functional requirement of FNs.Source: §10.2 · pp. 38, 44

11 Conclusion

The conclusion presents SDN as an advancement over conventional networks and recaps the survey's review of architectures, OpenFlow interfaces, and optical-network control approaches.

Conclusion

  • The survey reviews SDN's evolution, architecture, OpenFlow standards, and selective architectures, including alternatives for optical devices that do not support OpenFlow.The alternatives named include veths, OpenFlow agents, GMPLS, and hybrid techniques.Source: §11 · p. 45
  • The proposed SDHN uses a centralized unified controller to manage packet, optical, and wireless devices and coordinate route management, network visibility, and overlays.The conclusion also notes current projects and standardization activity.Source: §11 · p. 45
  • SDN with network virtualization separates infrastructure, virtual-network, and service-provider roles, and may let providers customize infrastructure dynamically while optimizing resource use and reducing capital and operating costs.The paper states that wider-scale applications and implementations remain to be fully exploited.Source: §11 · p. 45
Loading 2001.10165v1…