# Software-Defined Networking: Categories, Analysis, and Future Directions
### Application Programming Interfaces  
Application programming interfaces (APIs) [16] are very important in SDN; they provide communication between the data, control and management planes. The well-known APIs are southbound APIs (SBI), northbound APIs (NBI), and in the case of distributed controllers, east/westbound APIs. These APIs are architectural components of SDN, and they are used to configure forwarding devices or network applications. The SDN layered architecture, including APIs, is shown in Figure 1.  
1. Southbound API: This is an SDN enabler that provides a communication protocol between the control plane and data plane. It is used to push configuration information and install flow rules at the data plane. It also provides an abstraction of the network device's functionality to the control plane. Moreover, it allows the discovery of network topology, defines network flows, and implements requests sent by the management plane. SBI is critical with respect to its availability as well as secure communication. In absence of any one of these parameters, it may result in the malfunctioning of forwarding devices. It faces challenges of heterogeneity, vendor-specific forwarding devices, and programming languages. OFP is commonly used as an SBI that provides secure channel between the control and data plane to install flow rules. SBI proposals are categorized based on whether they are OpenFlow-dependent, OpenFlow-independent, or emerging technology, all of which are shown in Figure 2.  
Figure 1: SDN system architecture. Figure 2: Southbound API proposals. OpenFlow-Dependent SBI Proposals: These include OpenFlow-based SBI proposals with the addition of new features or in its newer versions. DevoFlow [17] modifies the OpenFlow model to permit network operators to focus on flow rules, which are essential for network management, by breaking the coupling between network control and global visibility. It helps to reduce internal communication between the control and data planes. The Revised OpenFlow Library (ROFL) [18] provides an API that offers much better usability by hiding details of OFP versions to make application development easier. It utilizes the extensible datapath daemon (xDPd) framework, which facilitates creating SDN data path elements. The hardware abstraction layer (HAL) [19] separates hardware-specific control and management functionalities from the forwarding devices in order to make legacy network nodes such as OpenFlow compliant. It results in decreasing the complexity of network devices, and the problem of vendor-specific features is resolved. OpenState [20] states that a central controller should not be provided with full control. It also proposes that the programmers can implement states in the forwarding devices instead of the central controller. Protocol-oblivious forwarding (POF) [21] offers a reactive mechanism that requires forwarding devices to extract keys and process packets by using packet headers, which leads to overhead. The programming abstraction datapath (PAD) [22] reveals the programmability of switch capabilities and offers SBI for optical switches. The open virtual switch database (OvSDB) [23] and OpenFlow configuration protocol (OF-Config) [24] build an association between the control and data planes and facilitate configurations in OpenFlow. * OpenFlow-Independent SBI Proposals: P4 runtime SBI [25] helps to solve the problem of OFP. It is an open, extensible, customizable platform that offers a new way for the control plane to control forwarding devices and solves the limitations of OFP. Forwarding and control element separation (ForCES) [26] aimed to replace OpenFlow. It enables the separation of control and forwarding elements that are in the same physical device without modifying the traditional networking architecture and without involvement of an external controller using a logical function block. OpFlex [27] supports communication between the controller and data plane; however, its provision of service is different in comparison with OpenFlow.