Northbound API, Southbound API, East/North – LAN Navigation in an OpenFlow World and an SDN Compass

I’ve previously written about Explaining L2 Multipath in Terms of North/South, East West Bandwidth where L2 Multipath technologies like TRILL have created a new term for describing the old and new designs, namely East/West oriented traffic flows instead of North/South traffic flows. Networks were alway determined by the Spanning Tree Protocol that forced a tree like structure from core to edge.

Today, we refer to this as North/South Alignment because traffic flows were predominantly Server to LAN Core to WAN Core to WAN Edge to Client.

In modern networks, virtualisation and VDI is driving a change in traffic flows to left to right in the data centre and this forces traffic, such as vMotion or VDI traffic, to take a long path through the network. This is commonly described as “east/west movement” to differentiate from North/South.

It’s also important to note that the Core Switches are a key weakness in this type of design.

bandwidth choke point in high bandwidth applications.

latency insertion in high bandwidth applications.

port density challenged on core switch in high “fan out” networks to support aggregation/distribution layers.

critical failure point (also hard to upgrade within ITIL change control processes)

Like so:

Layer 2 Multipathing networks based around TRILL started to arrive and the idea of North/South/East/West lost some of its meaning. After all, in a network that is uniform in any direction doesn’t really have any direction at all. This concept applies to Layer 2 networks only and lets pretend that large L2 domains don’t have any problems. Right ?

Northbound and Southbound

Recently, the SDN/OpenFlow discussions have started to talk about Northbound and Southbound API interfaces to the SDN controllers. What does that mean ?

An OpenFlow Controller is just one part of a working SDN solution. The Controller will use OpenFlow to communicate with the network devices while also presenting a User Interface to the user.

In fact, the Controller is a group of applications or a “platform” on which many applications might run. Thus a controller platform might run several smaller “applications” to provide services. Conceptually, this is similar to applications on your computer where the apps are running on the platform of the operating systems.

However, it’s also possible to use the OpenFlow controller as an API Endpoint and then it will form part of distributed computing cluster that forms a single control plane in the SDN system. In this situation, multiple controllers, or multiple applications are possible it becomes unclear just where the controller is in relation to ecosystem around it. Let look into that.

Building a Model

Lets go back to the beginning then and represent the network in a vertical plane. Here you can see that East/West LAN traffic needs to traverse a fairly typical Leaf/Spine LAN switch layout.

Now lets add the OpenFlow Controller to the network and show it communicating with the network hardware:

Still With Me ?

The SDN Application that provide overlay functions and integrates with the OpenFlow Controller are not just a single application. In fact there may be many. And each of those applications might have different purposes. For example, OpenStack has a application called Quantum that configures the Network and it might be used to deploy the network configuration as part of the OpenStack provisioning system.

Or a metering application might be used to capture “big data” form the OpenFlow controller to analyse traffic and provide charge back. Or some other type of Orchestration controller might be separate from (or integrated with the OpenStack – it’s not clear yet).

Then the network diagram looks something like this:

Northbound and Southbound APIs

At last we come to Northbound and Southbound APIs. In general terms, OpenFlow Controller to OpenFlow device is regarded as a Southbound API call. And Northbound APIs are those between the OpenFlow Controller and applications or higher layer control applications.

There are many important areas here to consider. The OpenFlow Controller is a platform on which the network management tools will form a dependency. In the future when vendors decide what sort of SDN they are willing to give us, the OpenFlow controller may be

in the hardware network device, or

in the orchestration platform,

be in several places

The final outcome does not change the high level layout of the network elements. In this layout, OpenFlow and NETCONF are the Southbound APIs used for most SDN implementations so far. For the incumbent networking vendors, Juniper will offer Junos Space, Cisco offers OnePK and Brocade has their OpenScript Engine that might offer viable alternatives if you like closed solutions.

Today, the vendor Southbound APIs offer some enhanced functionality. Whether they will survive the next couple of years remains to be seen

Northbound APIs remain completely closed. In this space, software is iterating rapidly and new ideas seem to float up every day and this makes it hard to envision, in my opinion, whether an open standard can be developed. I’ll take a long view here and wait for some convergence in the market. It’s unlikely that Northbound APIs will never standardise but I’m not aware of any initiatives in this area.

The EtherealMind View

Hopefully I’ve described the various directions used in networking jargon of the day. If it seems a bit confusing that because it is. Give it a couple of years and the things will be clearer because we might have converged onto a shared language. In the meantime, just keep thinking about the basics in the system and it’s always kind of obvious.

Feel free to leave a comment and I’ll do my best to respond to questions, queries etc.

Postscript

I had some spare time earlier this year and made solid start into writing a book on OpenFlow and SDN and most of these diagrams come from the draft of that book. I’m still hopeful that I can find time to finish the book but it makes sense to use some of the content here. Hope you find it worthwhile.

I hope I can find the time to finish the book as well but it seems unlikely at the moment. Sigh.

Disclosure

I have nothing to disclose in this article. My full disclosure statement is here

About Greg Ferro

Human Infrastructure for Data Networks. 25 year survivor of Corporate IT in many verticals, tens of employers working on a wide range of networking solutions and products.

Host of the Packet Pushers Podcast on data networking at http://packetpushers.net- now the largest networking podcast on the Internet.

Comments

Greg, I can’t wait for your book to come out. There is one thing I can not get clear in this post though. I have always learned that north and south is from the component perspective . So the north- and southbound API’s you’re describing are from the perspective of the SDN-controller. But, as an example, the NETCONF southbound call from the SDN-controller is talking to the Northbound API of an Openflow-switch. I think/hope that’s what you mean in your post, but I cannot get it clear from text and images, which are great by the way. But since this is material for your book I want to help eliminate confusion.

Just a doubt. In your “Building Model” design east – west traffic takes too many hops for the worst case because not every one connected to every one at the access layer. In this case reaching it via core seems to be the better option interms of number of hops. Now is the new design still provide better performance since it is L2?