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)
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.
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.
I have nothing to disclose in this article. My full disclosure statement is here