SDN puzzle

I remember a parable about six blind me trying to describe an elephant based only on their own touch sense. Each one of these men, had the chance to express how that “thing” could really be like… one feels the tail and says the elephant is a rope, one feels the trunk and thinks it’s a wall.  Another feels the leg and thinks it is a tree.  Eventually, the men realize they have to discuss what they have learned to get the bigger picture of what an elephant truly is.  As you have likely guessed, there is a lot here that applies to SDN as well.


 Each IT professional creates its own ideas of every technology that passes through his hands or mind, according to the role that the engineer plays in the organization. For example… based on my wider experience on networking stuff, I’m most interested on orchestration, automation and controller-based features of protocols like Openflow to lower the daily operations tasks; but that could be a completely different pic to a DevOps engineer, for whom the focus aspect would be programmability.

However, if you concentrate on the parts of SDN that is most familiar, you’ll probably miss out on the bigger picture. Just as an elephant is more than just a trunk or a tail, SDN is more than the individual pieces.  Programmable interfaces and orchestration hooks are means to an end.  The goal is to take all the pieces and make them into something greater.

The term “software-defined networking” is not as new as many of us would think, but just since few months ago it has been literally a “boom”.

Before we can have a better idea of the SDN concept, we must first examine how typical networks are conformed. Since most networks are based on routing and switching equipments, we could classify each data flow process as one of three different planes:

  • Forwarding Plane – Moves packets from input to output
  • Control Plane – Determines how packets should be forwarded
  • Management Plane – Methods of configuring the control plane (CLI, SNMP, etc.)

For example, if you are planning a weekend trip and want to make it by car, there are some tasks you must do to get to your final destination.  You must get into your car, sit on the driver’s seat (management plane), configure the GPS system to trace the route you might follow (control plane), and finally start the car’s engine and begin driving (forwarding plane). All this operations take place within the same “device” (car), but while you are driving along the way, any other car on the street operates independently based on its “local configuration” (driver skills, car type and features) . Having said that, it’s important to recognize that, although we could have a premium top of line car, with the best engine, wheels, suspension, chassis, sound system and bodywork, the end result of you trip depends on a whole mix of factors: weather, transit density, highways usage, accidents, other drivers’ skills, etc, which could be seen as “independent configurations” within the whole environment. If I could think about the previous story as a controller-based environment, I could imagine a dedicated person seated on a cabin, with a laptop connected to a real time satellite streaming… and this person is simultaneously broadcasting by radio the weather status, traffic density, and location of car crashes, so that, every car driver on every highway could choose the less crowded highways, and the routes with the safest weather so they could arrive to their destinations as soon, safe and happy as possible.


In the simplest possible terms, SDN entails the decoupling of the control plane from the forwarding plane and offloads its functions to a centralized controller. Rather than each node in the network making its own forwarding decisions, a centralized software-based controller (likely running on commodity server hardware) is responsible for instructing subordinate hardware nodes on how to forward traffic. Because the controller effectively maintains the forwarding tables on all nodes across the network, SDN-enabled nodes don’t need to run control protocols among themselves and instead rely upon the controller to make all forwarding decisions for them. The network, as such, is said to be defined by software running on the controller.