I regularly hear the packet pushers and others discussing Northbound and Southbound APIs and keep forgetting which does what. Here is a summary, comments and corrections welcome.
First a few definitions for context:
- SDN – Somewhat Defined Networking
![😉]()
Or Software.. - SDN Management Plane – here is the realm of the applications, where network orchestration takes place
- SDN Control Plane – interacts with the SDN Management Plane and Data Plane. The realm of APIs. In classic SDN this lives on the SDN Contoller
- SDN Data Plane – where traffic is forwarded, the realm of hardware
- SDN Controller – Platform on which Applications run. That platform may be a single server, collection of distributed devices in your network or hosted in the cloud
Or Software..Southbound API
Communication between the SDN Controller (or possibly simply an administrators workstation running C, Java, Phython,… scripts) and network switches, routers and other devices happens via the Southbound API.
Open Standards
- Openflow – maintained by the Open Network Foundation (ONF)
- NETCONF – IETF RFC 6241. Standard for managing Network Device Configuration
- Often used with the YANG modelling language defined in RFC 6020
As an example I might write a Python Script ‘StandardSNMP’ which takes a switch IP as an argument and uses an appropriate southbound API to retrieve and correct its SNMP config based on my companies best practice.
Vendor Proprietary
- Cisco onePK
- Junos Space
- Brocade OpenScript
Northbound / External API
Communication between applications (possibly running on the SDN Controller) and the controller itself. It is a network abstraction presented to high level applications or management systems. This enables developers to write apps for the network without needing to call the southbound API directly. This could mean the same code could be re-used across multiple network devices, from a variety of vendors.
Disclaimer: This is only an example of how I *think* things may work. It doesn’t reflect operational experience.
Say I am writing a configuration application ‘NetConfPLS'[1] which includes a standardisation feature. In my network are a few switches and routers from multiple vendors, all of which support OpenFlow. Once again, I want to verify whether my companies SNMP standard is adhered to across my network and correct it where it is not.
NetConfPLS would make a Northbound API call to the controller such as ‘give me the SNMP state of all devices’. The Controller then makes a Southbound API call to each network device to pull that config and presents this data to NetConfPLS in a standardised way. NetConfPLS then presents this data to the application user. Perhaps the actual config of each device would be shown together with the proposed replacement if running in debug mode.
The user then selects which devices to standardise. NetConfPLS would issue a second Northbound call to the controller like ‘standardise the following devices’. The controller would then issue a southbound call to each device containing the API version of the appropriate configuration commands.
[1] Potential LawSuit
Diagram
Summary
Hopefully you can start to see the appeal for developers. Just as we used to write Perl libraries (e.g. Net::Appliance::Session) to communicate with devices, now we can use the device manufacturer’s (or the Open Standard) API to do this. Whereas before the script and library were tightly coupled, now the developer can make use of their programming language of choice to communicate with a network abstraction provided by the controller. Scripts or Applications written in one environment could be more easily ported, given to the community or commercialised.
Of course, as ever, each vendor has their own story to sell. I suspect the road to an Open Source controller playing nicely across all platforms is long and perilous. For example, I can’t imagine Cisco would allow a third party controller access to its Northbound APIs. More likely you’ll be forced to buy a Cisco eXtensible Network Controller (XNC) to program your Openflow switches and onePK switches from one place, protecting that revenue stream for Cisco.
