2014/03/26 by C. Jasson Casey, Andrew M. Sutton, Casey, C. Jasson +4
Computer Science · Engineering · #FOS: Computer and information sciences #Networking and Internet Architecture (cs.NI) #Radiation Effects in Electronics #Software Engineering (cs.SE) #Software System Performance and Reliability #Software-Defined Networks and 5G #cs.NI #cs.SE
paper · pdf · doi:10.48550/arxiv.1403.6644
arxiv created 2014/03/26 · openalex publication_date 2014/03/26 · arxiv updated 2014/03/27 · openalex created_date 2025/10/10 · openalex updated_date 2026/07/28
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.