[Paper Review] tinyNBI: Distilling an API from essential OpenFlow abstractions

C. Jasson Casey, Andrew M. Sutton+1 more|arXiv (Cornell University)|Mar 26, 2014

Software-Defined Networks and 5G4 references4 citations

TL;DR

This paper proposes tinyNBI, a minimal, version-agnostic Northbound Interface (NBI) that distills core OpenFlow abstractions from five OpenFlow versions into a clean, low-level C API. By abstracting away version-specific complexities, tinyNBI enables reliable, portable configuration of flow tables, matches, actions, and instructions across diverse switches, reducing application complexity and improving maintainability for SDN developers.

ABSTRACT

If simplicity is a key strategy for success as a network protocol OpenFlow is not winning. At its core OpenFlow presents a simple idea, which is a network switch data plane abstraction along with a control protocol for manipulating that abstraction. The result of this idea has been far from simple: a new version released each year, five active versions, com- plex feature dependencies, unstable version negotiation, lack of state machine definition, etc. This complexity represents roadblocks for network, software, and hardware engineers. We have distilled the core abstractions present in 5 existing versions of OpenFlow and refactored them into a simple API called tinyNBI. Our work does not provide high-level network abstractions (address pools, VPN maps, etc.), instead it focuses on providing a clean low level interface that supports the development of these higher layer abstractions. The goal of tinyNBI is to allow configuration of all existing OpenFlow abstractions without having to deal with the unique personalities of each version of OpenFlow or their level of support in target switches.

Motivation & Objective

• To address the growing complexity and version fragmentation in OpenFlow, which burdens developers with managing protocol and switch variability.
• To design a minimal, stable API that exposes only essential OpenFlow abstractions common across all versions.
• To decouple application logic from OpenFlow version differences and switch-specific feature support.
• To enable reliable, portable configuration of flow tables, actions, matches, and instructions across heterogeneous OpenFlow switches.
• To provide a foundation for building higher-level network abstractions without re-implementing low-level protocol complexity.

Proposed method

• The authors abstracted core abstractions from five OpenFlow versions (1.0 to 1.3.1), identifying common primitives such as datapath, flow table, match, action, instruction, port, group, queue, and meter.
• They designed a C-based API with a small set of functions—such as ofp_add, ofp_del, ofp_build_match, ofp_build_action, and ofp_build_instruction—for constructing and managing switch configurations.
• The API enforces a switch-independent model where flow configuration is expressed through structured data types (e.g., ofp_flow) that bind match and instruction sets.
• It supports feature declaration via requirements, allowing applications to declare required primitives and capabilities before execution.
• Experimenter extensions are handled via binary data blocks, with OFP_EXTENSION as a selector for vendor-specific messages.
• The API supports querying, configuration, and statistics through standardized operations like ofp_get and ofp_stats, ensuring consistent interaction across switches.

Experimental results

Research questions

• RQ1 How can a minimal, version-agnostic API be designed to abstract the core abstractions of multiple OpenFlow versions?
• RQ2 What core abstractions are common across all OpenFlow 1.x versions and can serve as a stable foundation for SDN application development?
• RQ3 How can application developers be shielded from version-specific feature support and negotiation complexities in OpenFlow switches?
• RQ4 Can a low-level NBI reduce the need for multiple application variants per switch type or OpenFlow version?
• RQ5 How can experimenter extensions be uniformly supported within a simplified, portable API?

Key findings

• tinyNBI successfully abstracts the essential OpenFlow abstractions from five versions into a single, consistent C API, eliminating version-specific logic in applications.
• The API enables flow configuration through structured data types (e.g., ofp_flow) that bind match and instruction sets, simplifying flow installation and deletion.
• Applications can now declare required features and capabilities up front, ensuring compatibility before execution, reducing runtime errors.
• Experimenter extensions are uniformly supported via binary data blocks, with no validation, enabling vendor-specific functionality without breaking the abstraction.
• The interface supports all major OpenFlow operations—configuration, querying, statistics, and modification—through a small, consistent function set.
• By decoupling application logic from OpenFlow versioning and switch variability, tinyNBI reduces code complexity and improves maintainability.