SDN (Software Defined Networking) – SURPRISE!
Yes, since everyone seems to be talking about SDN these days, I guess we are not surprised to find SDN rear its head in the latest ICND2 from Cisco Systems. One thing that is surprising I suppose is that fact the three letters never appear in that section of the blueprint! 😉
5.5 Describe network programmability in enterprise network architecture
5.5.a Function of a controller
5.5.b Separation of control plane and data plane
5.5.c Northbound and southbound APIs
In fact, what is even a bit stranger is the fact that someone got the order of these a bit wrong I think. It makes more sense to me to first fully understand the separation of the control plane and the data plane. After that realize the function of a controller. Finally, discuss northbound and southbound APIs. Sigh.
In this quick post, let us take a high level look at these three points, and we can elaborate more in other posts (and perhaps for other certifications).
Separation of Control Plane and Data Plane
There is stuff in your router or switch that is great at building the little databases these devices need. For example, on a switch, we need a nice MAC address table built. On a router, we better have a nifty routing table that is accurate. It is the job of the Control Plane to build these things. A protocol like ARP helps big time with the MAC address table, while a protocol like OSPF helps big time with the routing table.
It helps make things super efficient if your separate that fancy stuff with the raw forwarding mechanics of the devices. Moving frames or packets from one interface to the next based on the information from the Control Plane is the job of the Data Plane (sometimes called the Forwarding Plane).
Function of a Controller
Separating the Control Plane stuff and the Data Plane stuff inside a device is old news and has been going on for a long time! What really gets exciting is in Software Defined Networking where you take the Control Plane intelligence needed and centrally locate it in a device called the Controller. This device can then handle (very efficiently) all the Control Plane items while the other networking devices just handle the Data Plane tasks! Cisco has a version of SDN termed Application Centric Infrastructure (ACI). Sure enough, a key component is the Controller. Of course, it needs a really fancy name, so the Marketing folks came up with – Application Policy Infrastructure Controller – Enterprise Module. Whew, that is a mouthful. What does it actually look like? Well, it is software that is running on a physical server or even a virtual (specially VMware) server in your network.
If you are having trouble sleeping later tonight and/or you are starving for the details on the APIC-EM – check this out.
Northbound and Southbound APIs
But wait – we have a potential problem here! How are all of these devices going to communicate. For example, if someone wants to write a program to control the network using the controller, what language will they use? And what language will the controller use to communicate to the network devices? The answer is in APIs application programming interfaces. These are basically standardized languages for communications between devices.
Think of the fancy Cisco controller sitting in the middle between two things. On top, you have a programmer that wants to develop a program to get information from the controller and provide the controller with instructions for controlling the devices. Because this is above the Controller in our diagram, we call the language options Northbound APIs. Cisco likes to use REST-based APIs. This allows the fancy discovery and control of the network elements using the HTTPs protocol.
What about the APIs that are used below the Controller? Those APIs for the Controller to actually command the network devices? These are Southbound APIs. Duh. 🙂 Cisco likes to keep it simple – they use the command-line interface (CLI) and Simple Network Management Protocol (SNMP).