The whole data communication industry is bullish about Software Defined Networking (SDN). What is SDN? Is it really a game changer? I think nobody knows that for sure because it is still evolving. While there have been some companies which have deployed SDN in their Data Centers, it is still not clear how and when it will be used in enterprises and service provider’s network.
Quest for SDN started with a very simple question researchers from Stanford University asked. What is the best way for researchers to test their newly proposed protocols in a production environment? There were various network simulators (ns-2), virtual network builder (core-emu) at researcher’s disposal but none could provide the production environment. Researchers realized that the best possible way is to run their newly proposed protocol implementation in the existing network without affecting the production environment. So what does this really means? This means that switches/routers should allow a third-party software to run in their switches/routers which add forwarding rules. This in-turn means that a third-party vendor agnostic Software is Defining the Networking in your network.
How does SDN work?
Let me touch upon little bit on how a switch/router works in existing networks. This will be useful to bring out the key differences between SDN and traditional networks. A switch/router consist of three separate planes i.e. management plane, control plane and data plane. Please look at figure-1. Management plane consist of protocols to provides management access to a network administrator using EMS or CLI. In control plane, switch/router uses switching/routing protocols to exachange switching/routing information. Control plane uses this switching/routing information to create the forwarding table in data plane through a proprietary communication mechanism. Data plane uses the forwarding table to forward data packets.
In all switches/routers, control plane and data plane communication is proprietary and it will be difficult to create a third-party software which can interact with data plane of different devices seamlessly. So researchers came up with another alternative. They decided to keep their software in a server and use a reliable communication protocol to add/remove forwarding rules in the device. In other words, control plane of the device is moved to a server and this control plane configures the data plane with forwarding rules. Look at figure-2 to see what it means for a network.
Now let us assume that control plane of all devices are moved to one single server application (can be called controller) and this single server application manages forwarding rules in all the switches/routers in the network. Look at figure-3 to see the difference in existing network and SDN.
Some of the points to note are:
- In existing network, each switch/router runs a protocol to calculate forwarding rules while in SDN, a software running in a server calculates the forwarding rules.
- In existing network, each switch/router uses a proprietary communication mechanism to manage forwarding rules in data plane while in SDN, the server communicates with the switch/router using a well-defined protocol to manage forwarding rules in data plane.
SDN use cases
Let us take it a little further. With what we learned till now, an application can configure required forwarding rules in all switches/routers with the help of central controller application. Can you think of situations where it helps? Let me help you with a couple of them I could think of.
- Take a look at figure 4, an application wants a video feed from server S1 to go through switch-1, switch-2, switch-4 and switch-6 to reach client C1 while another application wants a normal web page access to go through switch-1, switch-3, switch-5 and switch-6 to reach client C1. This can be very easily done using SDN where application will ask controller to create two flows and configure them in these switches accordingly. Can it be done today with existing networks? Yes. But is it easy to do? I don’t think so.
- In the same network, let us assume you want to change the network level policy on all the switches because a new application is being deployed, SDN makes it easier to manage such operations.
- In the same network, let us assume you want to add/remove a switch in your network. In the existing network, you will have to reconfigure the adjacent switches one-by-one but with SDN it can be done by controller software.
What’s next
I hope you can now answer “What is SDN?” but I think you would still have couple of questions in your mind:
- How does SDN helps a network administrator?
- How is a packet forwarded through the network?
- What happens if a switch/router does not have a forwarding rule for a packet?
- As there are no switching/routing protocol, how does controller software finds what forwarding rules to add/remove on a switch?
- Can SDN really scale?
I will try to answer some of these questions in my next post. After reading this, if you want me to cover any of your questions, please do leave a comment.
6 comments
What I still have a problem understanding is how the control plane messages make it back to the “network server” without an underlying existing network infrastructure. For instance, my vision for how SDN operates is much like how we see wireless networks operate today. All traffic goes back to a central controller which then helps make forwarding decisions. But we all know, a wireless AP does not automatically come up without you first configuring it on the correct vlan, and then configuring that vlan IP interface to point to the correct dhcp server, I could continue for a long time. The bottom line and point I am trying to make is how does SDN differ from this? Can we expect that new switches automatically configure uplinks as trunks, stp priorities, default gateways, etc based on the initial connection to the network. Or is there still an underlying traditional network with more or less “network apps” running on top.
Nice intro Sir, great reading.
thanks for clearly explaining some of the mystery behind SDN…I look forward to the next post.
very easy to understand article, thanks for sharing!
Pingback: Interview with Liz Burn, Juniper Networks Certification Program Director : Router Freak
Pingback: Why get a Juniper Networks Certification? Interview with Liz Burn, Certification Program Director : Router Freak