PaperlayerView exact revision on arXiv

Source-linked AI summary

A Comprehensive Survey of Interface Protocols for Software Defined Networks

Zohaib Latif, Kashif Sharif, Fan Li, Md Monjurul Karim, Yu Wang

arXiv:1902.07913v1cs.NI

TL;DR

This paper presents a detailed, systematic survey of SDN interfaces, covering southbound, northbound, virtualization, inter-SDN, and SDN-to-traditional-network interfaces. The paper systematically surveys and classifies southbound, northbound, and east/westbound interfaces, including proposals involving virtualization and emerging technologies. OpenFlow is a de facto industry standard among southbound interfaces, while a mature and comprehensive northbound solution is still missing.

  • Problem

    This paper presents a detailed, systematic survey of SDN interfaces, covering southbound, northbound, virtualization, inter-SDN, and SDN-to-traditional-network interfaces.

    Source: §VIII · p. 27

  • Method

    The paper systematically surveys and classifies southbound, northbound, and east/westbound interfaces, including proposals involving virtualization and emerging technologies.

    Source: §I · pp. 1–2, §VIII · p. 27

  • Results

    OpenFlow is a de facto industry standard among southbound interfaces, while a mature and comprehensive northbound solution is still missing.

    Source: C. Controller-based and Intent-based… · p. 18, §VIII · p. 27

  • Takeaways & Limitations

    A single portability solution addressing both diverse data-plane devices and southbound protocols remains an open research challenge.

    Source: A. Portability in NBI · p. 15

Abstract

from arXiv · show

Software Defined Networks has seen tremendous growth and deployment in different types of networks. Compared to traditional networks it decouples the control logic from network layer devices, and centralizes it for efficient traffic forwarding and flow management across the domain. This multi-layered architecture has data forwarding devices at the bottom in data plane, which are programmed by controllers in the control plane. The high level application or management plane interacts with control layer to program the whole network and enforce different policies. The interaction among these layers is done through interfaces which work as communication/programming protocols. In this survey, we present a comprehensive study of such interfaces available for southbound, northbound, and east/westbound communication. We have classified each type into different categories based on their properties and capabilities. Virtualization of networks devices is a common practice in Software Defined Networks. This paper also analyzes interface solution which work with different virtualization schemes. In addition, the paper highlights a number of short term and long term research challenges and open issues related to SDN interfaces.

I. INTRODUCTION

Traditional network devices make policy configuration difficult and time-consuming, while SDN separates control from forwarding and connects its planes through distinct APIs. The paper surveys and classifies these interfaces, compares their proposals, and includes emerging technologies and virtualization; prior surveys address broader SDN topics but not interfaces in depth.

I. INTRODUCTION

  • Traditional ASIC-based devices make policy implementation time-consuming and difficult, while their application-specific nature reduces network flexibility and optimization.SDN shifts decision-making to a centralized controller and makes switches forwarding devices.Source: §I · p. 1
  • SDN's three planes communicate through southbound, northbound, and east/westbound APIs, serving device control, application programmability, and inter-domain communication.Westbound APIs connect legacy domains to SDN domains.Source: §I · p. 1

B. Related Work

  • Earlier SDN surveys covered architecture, components, applications, scalability, reliability, programming languages, and emerging technologies rather than surveying interface literature in depth.Examples include analyses of SDN planes and tools, architecture and applications, controller scalability and reliability, and programming languages.Source: A. Major Contributions · p. 2, B. Related Work · pp. 2–3

A. Major Contributions

  • The survey classifies each interface layer by architecture and properties, examines proposals in technical depth, and compares APIs using criteria suited to their different purposes.It also classifies interfaces involving virtualization separately and covers OpenFlow-independent and OpenFlow-dependent southbound proposals.Source: A. Major Contributions · p. 2
  • The survey extends its interface coverage to proposals for wireless sensor networks and the Internet of Things.It also groups interfaces for communication between SDN domains and with legacy networks.Source: A. Major Contributions · p. 2

C. Organization of Paper

The paper surveys SDN’s planes and interfaces, then organizes reviews of southbound, northbound, virtualization, and inter-domain communication after introducing WSN, IoT, and NFV.

C. Organization of Paper

  • The survey introduces SDN architecture and emerging technologies, then reviews southbound and northbound interfaces, virtualization, inter-domain communication, and future directions.Its emerging-technology overview includes WSN, IoT, and NFV.Source: C. Organization of Paper · p. 3, §II · p. 3

A. SDN Architecture

  • SDN separates control functions from forwarding elements, addressing traditional devices’ vendor and language constraints and management difficulty as networks scale.Source: A. SDN Architecture · p. 3

1) Data Plane:

  • Data-plane switches match packet headers against flow-table entries, act on matches, and send unmatched packets to the controller or drop them.The controller can reply with a Packet OUT message and install a flow entry.Source: 1) Data Plane · pp. 3–4

2) Control Plane:

  • The control plane uses its domain-wide network view to manage switch flows and provide network-state information to management applications.Controllers gather statistics and inventory devices; their architectures and supported southbound interfaces vary.Source: 2) Control Plane · p. 4

3) Management Plane:

  • The management plane hosts applications such as routing, policy enforcement, load balancing, and firewalls, which SDN makes more straightforward to implement.Source: 3) Management Plane · p. 4

B. SDN Interfaces; 1) Southbound API:

  • SDN interfaces connect architectural planes, with the southbound API carrying configuration and flow entries to devices and abstracting device functionality for the controller.The survey describes southbound proposals as open and standardized, with OpenFlow considered a standard in SDN.Source: 1) Southbound API · p. 4, B. SDN Interfaces · p. 4

2) Northbound API:

The section surveys northbound and east/westbound roles alongside controllers and SDN use in emerging domains. It notes limited NBI standardization and the need for controller coordination in large or heterogeneous networks.

2) Northbound API:

  • Northbound APIs connect controllers with the management plane and support application development, but controller-specific offerings and limited standardization can constrain portability.Source: 2) Northbound API · p. 4

3) East/Westbound API:

  • Eastbound APIs exchange information among distributed controllers for a consistent global view, while westbound APIs connect controllers with legacy network devices.Source: 3) East/Westbound API · p. 4

C. SDN Controllers

  • Controllers share core services such as topology, statistics, notifications, and device management, while differing in architecture and interface support.Most support OpenFlow southbound; OpenDaylight supports several southbound interfaces, and northbound interfaces remain less standardized.Source: C. SDN Controllers · p. 5

D. SDN for Emerging Technologies

1) Wireless Sensor Networks:

  • In WSNs, limited device energy and low-level programming are challenges; SDN shifts energy-intensive routing to a controller and provides high-level programming abstractions.Source: 1) Wireless Sensor Networks · p. 5
  • Northbound management can make WSN policy changes more flexible, while radio resource management remains an area for improvement.Source: 1) Wireless Sensor Networks · p. 5

2) Internet of Things:

  • For IoT, centralized SDN control offers a mechanism for managing devices whose complex rules limit real-time response; distributed controllers can exchange information and share or balance load.Source: 2) Internet of Things · p. 5

E. Network Function Virtualization

The survey treats NFV as complementary to SDN and classifies southbound interfaces by their relationship to OpenFlow. It traces OpenFlow’s evolution from a single fixed-match table toward more flexible processing and control.

E. Network Function Virtualization

  • NFV can virtualize SDN controllers for tenants, while SDN can provide programmable connectivity between VNFs; the two technologies are complementary, not dependent.NFV virtualization can involve southbound interfaces for resource slices or northbound interfaces for controlling slices.Source: E. Network Function Virtualization · pp. 5–6

III. SOUTHBOUND INTERFACES (SBIS) IN SDN

  • Southbound proposals are classified as OpenFlow itself, OpenFlow-dependent or OpenFlow-independent, with separate proposals for sensor networks and IoT.OvSDB and OF-Config are OpenFlow companions; ForCES, OpFlex and NetConf are independent proposals.Source: §III · p. 6

1) OpenFlow Evolution:

  • OpenFlow 1.0 had one flow table and fixed matching fields, limiting switches to one forwarding operation per packet.Version 1.1 introduced multiple tables and a packet-processing pipeline.Source: 1) OpenFlow Evolution · p. 6, Table II · p. 7
  • OpenFlow 1.2 added flexible TLV-based matching, IPv6 support and controller role changes for multiple controllers.Version 1.3 added meter entries and table-miss handling; versions 1.4 and 1.5 added table synchronization, bundles and egress matching.Source: 1) OpenFlow Evolution · pp. 6–7

2) OpenFlow Architecture:

OpenFlow uses switch flow tables and controller messages to install rules, after which matching packets can be handled at line speed. The survey describes complementary configuration tools and proposals that extend, abstract or redistribute OpenFlow’s functions.

2) OpenFlow Architecture:

  • OpenFlow switches match packet headers against flow entries, send unmatched packets to the controller, and can process subsequent packets at line speed after receiving rules.The controller responds to Packet IN with Packet OUT and Flow Mod messages; counters produce per-rule, table, port, queue or timer statistics.Source: 2) OpenFlow Architecture · pp. 7–8

B. OpenFlow Dependent SBI Proposals

  • HAL hides hardware-specific control and management through abstraction and hardware-specific layers, while ROFL masks differences among OpenFlow versions with a reusable API.HAL also addresses multiple OpenFlow versions; ROFL describes support for versions 1.0, 1.2 and 1.3.Source: B. OpenFlow Dependent SBI Proposals · p. 8
  • DevoFlow devolves control of most flows to switches to reduce controller interactions, but requires costly switch-design modifications; OpenState supports local stateful tasks in forwarding devices.OpenState uses an Extended Finite State Machine abstraction for tasks such as port knocking and MAC learning.Source: B. OpenFlow Dependent SBI Proposals · p. 8
  • POF’s Flow Instruction Set aims to make forwarding devices protocol-oblivious, while PAD exposes programmable forwarding for devices such as optical switches.PAD processes packets through a search engine and execution engine; its optical-flow functions may use instructions without packet information.Source: B. OpenFlow Dependent SBI Proposals · p. 8
  • OvSDB manages virtual-switch instances, bridges, ports, QoS and statistics, while OF-Config remotely configures OpenFlow datapaths.OpenFlow modifies match-action rules; OF-Config addresses configuration on physical and virtual platforms.Source: B. OpenFlow Dependent SBI Proposals · p. 9
  • OpenFlow-dependent proposals address shortcomings, but support for multiple OpenFlow versions and protocol dependency remain open research challenges.OpenFlow hybrid supports both OpenFlow operations and traditional Ethernet switching; Stats-Trigger only partially addresses controller–data-plane overhead.Source: B. OpenFlow Dependent SBI Proposals · p. 9

C. OpenFlow Independent SBI Proposals

The survey contrasts independent southbound proposals with OpenFlow in their architectures and control models. It highlights ForCES’s extensibility, OpFlex’s distributed control, and NetConf’s focus on device configuration, while noting adoption and flexibility constraints.

C. OpenFlow Independent SBI Proposals

  • ForCES places Control Elements and Forwarding Elements in the same physical device, where Logical Function Blocks process packets under CE control.ForCES uses SCTP for FE–CE communication, citing reliability options and built-in failure recovery.Source: C. OpenFlow Independent SBI Proposals · pp. 9–10, Figure 7 · p. 10
  • ForCES supports extensibility without repeated standardization and does not restrict forwarding-element design, but it did not gain widespread vendor adoption.The survey attributes its limited industry confidence partly to OpenFlow’s broad deployment and developer support.Source: C. OpenFlow Independent SBI Proposals · p. 10, Table IV · p. 10
  • OpFlex centralizes policy management while distributing intelligence and control to forwarding devices, but restricts centralized network programming compared with OpenFlow.Its Policy Repository communicates with Policy Elements; endpoints register through an Endpoint Registry, while an Observer handles statistics, faults and events.Source: C. OpenFlow Independent SBI Proposals · p. 10, Figure 8 · p. 11
  • NetConf uses RPCs to retrieve, upload and manipulate device configuration, but the survey says it lacks the flexibility of an SDN-purpose-built interface.Its API can send and receive full or partial configuration datasets.Source: C. OpenFlow Independent SBI Proposals · p. 10, Table V · p. 10

D. Southbound APIs for Wireless Sensor Networks

Southbound APIs for wireless sensor and IoT networks must accommodate constrained, diverse devices and communication technologies that standard OpenFlow assumptions do not fit. The survey compares proposed adaptations and architectures, while emphasizing unresolved evaluation and interface-design needs.

D. Southbound APIs for Wireless Sensor Networks

  • WSN flow creation is difficult because OpenFlow matches IP addresses while sensor networks are data-centric and often non-IP, and flow updates can burden constrained devices and communication channels.The survey also notes that TCP/IP-based secure channels are hard to establish in SDWSNs.Source: D. Southbound APIs for Wireless Sensor… · p. 11
  • SOF adapts OpenFlow for low-capacity sensor nodes with specialized flow tables, addressing, secure-channel options, and Control-Message Quenching, but provides no performance evaluation.Its two table classes cover compact network-unique addresses and concatenated attribute-value pairs.Source: D. Southbound APIs for Wireless Sensor… · p. 11
  • SDWN uses duty cycles, in-network aggregation, flexible rules, and a virtualizer for topology collection, but its architectural proposal lacks performance evaluation.Its sink nodes have greater computational and communication capacity than generic nodes.Source: D. Southbound APIs for Wireless Sensor… · p. 11
  • SDN-WISE uses a finite-state-machine model, topology and node metrics, and in-network processing; the survey identifies movement, changing membership, and metric-based path building as continuing WSN challenges.The survey calls for interfaces to gather the information needed by controllers to manage these changes.Source: D. Southbound APIs for Wireless Sensor… · pp. 11–12

E. Southbound APIs for Internet of Things

  • IoT proposals include an OpenFlow 1.0 extension with flags for data format and caching, while the survey finds that many works emphasize controller design and leave SBI operation underspecified.Li et al. describe data conversion and selective storage; the survey concludes that a lightweight, customized interface may be needed after evaluating OpenFlow communication performance.Source: E. Southbound APIs for Internet of… · pp. 12–13
  • IoT interfaces must address device heterogeneity, multiple access technologies and topologies, and diverse packet formats and processing rules; the survey calls for IoT-specific SBIs and evaluation of OpenFlow in such networks.It also identifies reaching IoT devices beyond SDN gateways and supporting functions beyond flow installation as research areas.Source: E. Southbound APIs for Internet of… · pp. 12–13

IV. NORTHBOUND INTERFACES (NBI) IN SDN

Northbound interfaces connect applications and management to network control, but their lack of standardization and the diversity of controllers and devices complicate application development and portability. The survey groups NBIs by properties and reviews portability approaches, concluding that a solution spanning both devices and protocols remains open.

IV. NORTHBOUND INTERFACES (NBI) IN SDN

  • NBIs provide high-level abstractions for application development, yet the absence of a standard leaves controllers with ad hoc or controller-specific APIs and REST is commonly used.The survey groups NBI approaches by portability, programmability, controller-based, intent-based, and virtualization properties.Source: §IV · pp. 13–14

A. Portability in NBI

  • SFNet hides lower-level protocols while translating application requirements into network services, including congestion reporting and bandwidth requests.Applications may choose to back off during congestion; bandwidth requests can be granted or denied based on availability.Source: A. Portability in NBI · p. 14
  • NOSIX maps application-defined virtual flow-table pipelines onto switch pipelines, while tinyNBI handles OpenFlow-version and capability differences through emulation, offloading, or error indications.tinyNBI distinguishes configuration, capability, and statistics data in its abstractions.Source: A. Portability in NBI · pp. 14–15
  • Portability addresses compatibility across diverse switches and southbound protocols, whose varying pipelines and interactions complicate correct packet processing across devices.The survey concludes that existing solutions focus on either data-plane devices or protocols; a single solution for both remains an open challenge.Source: A. Portability in NBI · pp. 14–15

B. Programmability of NBI

The survey frames NBI programmability as a response to OpenFlow’s low-level abstractions, task conflicts, and two-tier programming demands. It classifies language features and reviews SDN-specific languages, while noting that their libraries and community contributions remain limited.

B. Programmability of NBI

  • OpenFlow’s low-level instruction set and controller handling of unknown flows make high-level programming difficult and can require separate programming for controller- and switch-processed packets.Network elements may run routing, monitoring, and access control simultaneously, with packet rules that can conflict.Source: B. Programmability of NBI · p. 15

1) NBI Programming Language Feature Classification:

2) Programming Languages for NBI:

  • SDN languages offer varied abstractions, including Frenetic’s declarative rule handling, Procera’s dynamic policies, NetKAT’s formal semantics, and Kinetic’s finite-state-machine policy updates and verification.Other examples include Merlin’s policy partitioning and SCOR’s constrained-programming approach to QoS routing.Source: 2) Programming Languages for NBI · pp. 15–17
  • The survey describes SDN languages as evolving, but says their libraries and community contributions are limited and identifies further development as an active area.Source: 2) Programming Languages for NBI · p. 17

C. Controller-based and Intent-based NBIs

Controller-based NBIs expose controller-specific APIs, while intent-based interfaces express high-level policies rather than detailed mechanisms. The survey describes examples across PANE, Onix, ONOS, and OpenDaylight, and concludes that NBIs still lack a mature, comprehensive solution.

C. Controller-based and Intent-based NBIs

  • ONOS intents express network-control requirements as policies that are compiled and installed as forwarding rules, while OpenDaylight renderers translate intents into network modifications.The survey describes intent interfaces as a way to declare high-level policies instead of specifying networking mechanisms.Source: C. Controller-based and Intent-based… · p. 18
  • PANE and Onix provide their own controller APIs, while ONOS and OpenDaylight use multiple APIs; the survey notes that applications built for one controller may not work with another.PANE supports network-state queries and resource requests; Onix exposes network-element state through a data model and Network Information Base.Source: C. Controller-based and Intent-based… · pp. 17–18
  • The survey finds that intent-based NBIs are supported by only a few controllers and that a mature, comprehensive northbound-interface solution is still missing.Source: C. Controller-based and Intent-based… · p. 18

V. VIRTUALIZATION AND SDN INTERFACES

Virtualization schemes place abstraction at different points between network hardware, controllers, and applications, using southbound or northbound interfaces. The section also introduces east/westbound interfaces for communication among SDN domains or between SDN and legacy networks.

V. VIRTUALIZATION AND SDN INTERFACES

  • Network function virtualization with SDN is presented as a way to reduce manual configuration complexity and cost while improving network resource utilization.Purpose-built hardware can make service upgrades time-consuming and error-prone.Source: §V · p. 18
  • FlowVisor partitions flow tables into flowspaces and proxies OpenFlow messages so multiple users can independently control network slices.The survey also describes alternatives including AutoSlice, OpenVirteX, AutoVFlow, FlowN, Network Hypervisor, NVP, and libNetVirt, with northbound and southbound interface choices varying by scheme.Source: §V · p. 19
  • Virtualization schemes use either a hypervisor between switches and controllers or virtual-controller slices that let tenants run applications on a shared controller.The survey summarizes these techniques and their associated interfaces in Table XI.Source: §V · pp. 18–20, Table XI · p. 20

VI. EAST/WESTBOUND INTERFACE (E/WBIS) IN SDN

  • Eastbound interfaces connect distinct SDN domains, while westbound interfaces support communication between SDN and traditional network domains.BGP is a common information-sharing method, while PCEP and GMPLS are also used as makeshift solutions not designed specifically for SDN.Source: §VI · p. 20

A. Interaction between SDN Domains (Eastbound APIs)

Eastbound interfaces support communication across SDN domains, where distributed controller designs address scalability, security, and availability concerns. The survey describes flat and hierarchical arrangements and reviews protocols and systems for inter-controller coordination.

A. Interaction between SDN Domains (Eastbound APIs)

  • Large-scale SDN faces controller scalability, security, and availability concerns, including bottlenecks, single-node failure risk, and reduced response capacity under load.NOX is reported to handle 30K flow requests with response time below 10ms, with response time potentially higher in larger networks.Source: A. Interaction between SDN Domains… · p. 20
  • Distributed controllers may have equal rights and share network information, whereas hierarchical designs use domain controllers that report to a root controller.The survey's Table XII covers protocols, network types, and languages used, including distributed, hierarchical, and mixed proposals.Source: A. Interaction between SDN Domains… · p. 20

1) Distributed Architecture Interfaces:

  • HyperFlow uses event sharing to maintain a consistent global view, while Onix uses a network information base with partitioning and cluster aggregation for distributed control.The survey notes that Onix's network information base is not distributed and can exhaust memory or saturate CPU; algorithm details for claimed consistency and durability are missing.Source: 1) Distributed Architecture Interfaces · p. 21
  • Elasticon dynamically expands or shrinks a controller pool based on load, while ONOS uses publish-subscribe communication to address delays and CPU load from periodic database polling.Elasticon also supports master-slave switch connections for fault tolerance.Source: 1) Distributed Architecture Interfaces · pp. 21–22
  • Distributed proposals exchange controller state through mechanisms including INT messages, JGroups leader messaging, DISCO's AMQP publish-subscribe, and SDNi customized messages.The INT module covers session control, capability exchange, and path setup; DISCO agents provide network-wide functions such as connectivity and reachability.Source: 1) Distributed Architecture Interfaces · pp. 21–22

2) Hierarchical Architecture Interfaces:

Hierarchical designs divide control between domain-level controllers and an upper-level root or broker, while hybrid approaches combine distributed and hierarchical elements. The survey describes their coordination mechanisms and notes continuing concerns about consistency, resource use, and overhead.

2) Hierarchical Architecture Interfaces:

  • Hierarchical architectures assign domain controllers to local networks and a root controller to manage them, reducing control information relative to flat designs but retaining some single-node failure risk.Source: 2) Hierarchical Architecture Interfaces · p. 22
  • Kandoo places frequent local events at lower-level controllers and rare, network-wide events at a root controller, using Appdetect and Appreroute applications to detect and route elephant flows.Source: 2) Hierarchical Architecture Interfaces · p. 22
  • 50% fewer traffic is handled by a controller in the described hierarchical setting than by one in a non-hierarchical environment, according to the authors.The broker gathers domain reachability and QoS paths, computes inter-domain routes, and directs domains to reserve QoS values.Source: 2) Hierarchical Architecture Interfaces · pp. 22–23
  • Other proposals coordinate heterogeneous controllers through a coordinating controller, protocol interpreter, and unified northbound topology and service APIs.The surveyed approaches also include D-SDN's authenticated delegation from a main controller to secondary controllers and Zebra's separation of dissemination and decision layers.Source: 2) Hierarchical Architecture Interfaces · pp. 23–24

3) Hybrid Architecture Interfaces:

  • Orion combines area and domain controller layers to address path stretch and super-linear computation complexity associated with hierarchical and flat designs, respectively.Area controllers communicate with domain controllers over TCP; FlowBroker is another hybrid proposal, using brokers, reputation-based assignment, and keep-alive and table-backup messages for failover.Source: 3) Hybrid Architecture Interfaces · p. 24
  • The survey identifies interface standardization, consistent global views, and control overhead as continuing challenges for distributed controllers.It also notes that lightweight access-point controllers could benefit flow management in mobile wireless networks.Source: 3) Hybrid Architecture Interfaces · p. 24

B. Interaction between SDN and Traditional Networks (Westbound APIs)

Westbound interfaces support SDN coexistence with traditional networks during migration, and the survey reviews BGP-based and other interconnection approaches. It also identifies open interface research needs, including southbound challenges in sensor and IoT networks.

B. Interaction between SDN and Traditional Networks (Westbound APIs)

  • During migration, SDN domains need to exchange reachability, forward traffic, and express routing policies with traditional networks through gateways.The survey notes that BGP is used for legacy inter-domain communication, while newer OpenFlow versions can communicate with both SDN elements and traditional switches.Source: B. Interaction between SDN and… · pp. 24–25
  • RouteFlow connects OpenFlow-based IP routing to legacy networks through a custom protocol between its server and legacy-network slave.Its messages include commands and events, with some messages drawn from OpenFlow.Source: B. Interaction between SDN and… · p. 25
  • SDN-IP exchanges BGP routes with neighboring legacy domains and uses learned routes to install flow entries in the SDN domain.Its Route Information Base is reported to scale to 10,000 entries.Source: B. Interaction between SDN and… · p. 25
  • BTSDN uses iBGP and eBGP with border-connected OpenFlow switches acting as proxies, supporting incremental SDN deployment alongside traditional networks.The controller cannot directly control border routers, but can install flow entries on the connected SDN switches.Source: B. Interaction between SDN and… · p. 25
  • Software Defined eXchange lets participants use Pyretic applications to specify flexible forwarding policies and isolate their traffic at Internet exchange points.The surveyed motivation is that destination-prefix routing alone does not provide application- or sender-specific decisions or let networks express inbound and outbound paths.Source: B. Interaction between SDN and… · p. 25
  • The survey calls for further westbound research during network transition and identifies interoperability as important for large-scale SDN deployment.Source: B. Interaction between SDN and… · p. 25

A. Southbound Interface

  • OpenFlow's long matching headers increase rule storage needs and processing time, while combining interface features may add complexity and overhead.The survey calls for evaluating interface performance and flow-installation effects; it distinguishes proactive setup overhead from reactive setup latency.Source: A. Southbound Interface · pp. 25–26
  • Southbound-interface research remains open on sink-failure robustness, sensor-node memory limits, security, mobility, and energy management, as well as support for heterogeneous multi-hop IoT devices.Source: A. Southbound Interface · p. 26

B. Northbound Interface

The section identifies interface challenges across northbound APIs, virtualization, and controller communication, then situates them within a survey of SDN interface classes and future research directions.

B. Northbound Interface

  • The absence of a standardized API and diversity in network elements and protocol versions make portable northbound application development difficult.The section calls for a flexible interface to remove underlying complexity.Source: B. Northbound Interface · p. 26
  • Only FatTire incorporates OpenFlow 1.1 group tables, while SDN programming languages lack shared libraries and extensions, leaving developers to write applications from scratch.Source: B. Northbound Interface · p. 26

C. Virtualization

  • vSDN research lacks tenant specification of control-plane and OpenFlow-message demands, which could support finer-grained virtualization and API configuration.Source: C. Virtualization · p. 26
  • Virtualization research also needs hypervisor fault recovery, scalable distributed designs, and optimized placement.Source: C. Virtualization · p. 26

D. East/Westbound Interface

  • Controller heterogeneity and the lack of a unified east/west interface complicate low-overhead communication, which can affect SBI flow installation; multi-controller safety and suspicious-traffic detection also remain concerns.Source: D. East/Westbound Interface · pp. 26–27
  • Traditional-network westbound integration may require router software that translates flow entries into routing paths and vice versa.Source: D. East/Westbound Interface · p. 27

VIII. CONCLUSION

  • The survey classifies southbound and northbound interfaces, treats virtualization-related interfaces separately, analyzes inter-domain and traditional-network interfaces, and outlines future research directions.Source: §VIII · p. 27
Loading 1902.07913v1…