1. SDN Lecture 5 Layer V: Northbound Interfaces

2. The North- and Southbound interfaces are two key abstractions of the SDN ecosystem. The southbound interface has already a widely accepted proposal (OpenFlow), but a common northbound interface is still an open issue. At this moment it may still be a bit too early to define a standard northbound interface, as use-cases are still being worked out [236]. Anyway, it is to be expected a common (or a de facto) northbound interface to arise as SDN evolves. An abstraction that would allow network applications not to depend on specific implementations is important to explore the full potential of SDN The northbound interface is mostly a software ecosystem, not a hardware one as is the case of the southbound APIs.

3. Layer V: Northbound Interfaces In these ecosystems, the implementation is commonly the forefront driver, while standards emerge later and are essentially driven by wide adoption [237]. Nevertheless, an initial and minimal standard for northbound interfaces can still play an important role for the future of SDN. Discussions about this issue have already begun [236], [237], [238], [239], [240], [241], [242], [243], and a common consensus is that northbound APIs are indeed important but that it is indeed too early to define a single standard right now. The experience from the development of different controllers will certainly be the basis for coming up with a common application level interface.

4. Layer V: Northbound Interfaces Open and standard northbound interfaces are crucial to promote application portability and interoperability among the different the control platforms. A northbound API can be compared to the POSIX standard [244] in operating systems, representing an abstraction that guarantees programming lan- guage and controller independence. NOSIX [245] is one of the first examples of an effort in this direction. It tries to define portable low-level (e.g., flow model) application interfaces, making southbound APIs such as OpenFlow look like “device drivers”. However, NOSIX is not exactly a general purpose northbound interface, but rather a higher-level abstraction for southbound interfaces. Indeed, it could be part of the common abstraction layer in a control platform as the one described in Section IV-D.

5. Layer V: Northbound Interfaces Existing controllers such as Floodlight, Trema, NOX, Onix, and OpenDaylight propose and define their own northbound APIs [238], [246]. However, each of them has its own specific definitions. Programming languages such as Frenetic [204], Nettle [223], NetCore [205], Procera [224], Pyretic [247] and NetKAT [226] also abstract the inner details of the controller functions and data plane behavior from the application devel- opers. Moreover, as we explain in Section IV-G, programming languages can provide a wide range of powerful abstractions and mechanisms such as application composition, transparent data plane fault tolerance, and a variety of basic building blocks to ease software module and application development.

6. Layer V: Northbound Interfaces SFNet [248] is another example of a northbound interface. It is a high-level API that translates application requirements into lower level service requests. However, SFNet has a limited scope, targeting queries to request the congestion state of the network and services such as bandwidth reservation and multicast.

7. Layer V: Northbound Interfaces Other proposals use different approaches to allow applications to interact with controllers. The yanc control plat- form [196] explores this idea by proposing a general control platform based on Linux and abstractions such as the virtual file system (VFS). This approach simplifies the development of SDN applications as programmers are able to use a traditional concept (files) to communicate with lower level devices and sub-systems.

8. Layer V: Northbound Interfaces Eventually, it is unlikely that a single northbound interface emerges as the winner, as the requirements for different network applications are quite different. APIs for security applications are likely to be different from those for routing or financial applications. One possible path of evolution for northbound APIs are vertically-oriented proposals, before any type of standardization occurs, a challenge the ONF has started to undertake in the NBI WG in parallel to open- source SDN developments [50]. The ONF architectural work [218] includes the possibility of northbound APIs providing resources to enable dynamic and granular control of the network resources from customer applications, eventually across different busi- ness and organizational boundaries.

9. Layer V: Northbound Interfaces There are also other kind of APIs, such as those provided by the PANE controller [197]. Designed to be suitable for the concept of participatory networking, PANE allows network administrators to define module-specific quotas and access control policies on network resources. The controller provides an API that allows end- host applications to dynamically and autonomously request network resources. For example, audio (e.g., VoIP) and video applications can easily be modified to use the PANE API to reserve bandwidth for certain quality guarantees during the communication session. PANE includes a compiler and verification engine to ensure that bandwidth requests do not exceed the limits set by the administrator and to avoid starvation, i.e., other applications shall not be impaired by new resource requests.