In a software-defined network (SDN) architecture, the northbound application program interfaces (APIs) are usually SDN Rest APIs used to communicate between the SDN Controller and the services and applications running over the network. The northbound APIs can be used to facilitate innovation and enable efficient orchestration and automation of the network to align with the needs of different applications via SDN network programmability.
How Do Northbound APIs Work?
Northbound APIs are arguably the most critical APIs in the SDN environment, since the value of SDN is tied to the innovative applications it can potentially support and enable. Because they are so critical, northbound APIs must support a wide variety of applications, so one size will likely not fit all. This is possibly why SDN northbound APIs are currently the most nebulous component in a SDN environment — a variety of possible interfaces exist in different places up the stack to control different types of applications via an SDN Controller.
It is likely that quite a few different northbound APIs will exist before consolidation occurs – not unlike the early days of the mobile operating system (OS) wars. Examples of the types of network applications that could be optimized via the north bound interface include load balancers, firewalls or other software-defined security (SDSec) services, or orchestration applications across cloud resources.
SDN Northbound APIs (or SDN Rest APIs) are also used to integrate the SDN Controller with automation stacks, such as Puppet, Chef, SaltStack, Ansible and CFEngine, as well as orchestration platforms, such as OpenStack, VMware’s vCloudDirector or the open source CloudStack. The goal is to abstract the inner-workings of the network, so that application developers can ‘hook’ into the network and make changes to accommodate the needs of the application without having to understand exactly what that means for the network.
Recently, the Open Networking Foundation (ONF) turned its focus to the SDN northbound API. They have established a Northbound Working Group that will write code, develop prototypes and look at whether or not to create standards for the interface to drive clarity around what it is and what it can do. To learn more about the group’s current goals, visit its page here.