In my previous post, I explained what is Software Defined Networking (SDN). As I wanted to keep the introduction simple, I avoided discussing SDN internals in that post. Now that you understand what SDN is, let us get into other details.
SDN Internals
In SDN, sequence of packets exchanged between two end-points is known as ‘flow’. A ‘flow’ is uni-directional. A ‘flow’ is uniquely identified by various fields in the packet’s header. Each switch/router is configured to take specified actions for specified ‘flows’ in the network. The table containing all the flows is usually called Flow Table. An IP forwarding table can be called a Flow table where each IP route is a ‘flow’ with destination address as the only field to uniquely identify the flow.
A SDN network uses SDN-enabled switches/routers and a centralized controller. The controller communicates with switches/routers using a well defined protocol (open flow) to configures them with flows and actions. Take a look at figure-1. All the switches in this network are SDN enabled and controller controls all the switches.
How does controller knows about each flow in the network? There could be multiple ways. An application running on a server can ask controller to configure the specified flow on a given path or an administrator can statically configure all the known flows. In figure-1, an application can instruct controller to configure switch-1, switch-2 and switch-3 to create a path between client-1 and server-1 for e-mail exchange. Similarly, the administrator can statically configure switch-1, switch-2 and switch-4 to forward video data from server-2 to client-1. In these two cases, two flows are configured in switch-1 and switch-2 while one flow in each switch-3 and switch-4. Different action is taken at switch-2 which forward the video flow to switch-4 and e-mail flow to switch-3.
What happens if a switch does not find any flows for a packet? Controller can configure switch to either drop the packet or forward it to the controller. Controller would know how to handle this packet. For example: if client-1 sends out a packet for accessing ftp server in server-3 for which there is no flow configured in switch-1, switch-1 will send the packet to controller. Controller then figures out the optimum way for this flow and then configure the required switches with the flow and action. After this, the packets are switched normally.
SDN Benefits
Now that we understand what SDN is and how SDN works, I am sure you can see some of the benefits it provides. Let me help you by listing some of the benefits people claim it provides:
- SDN helps in achieving dynamically programmable networks. An application can program the network based on its own requirements. As mentioned in the previous post, a video server or a normal web server can configure two different path between the same client and server for these two services.
- SDN provides one single consistent way of configuring all the network elements. For example, in figure-1, switch-1 and switch-2 is of one vendor while other switches are from another vendor but the controller uses same configuration to configure all the switches. This reduces the overall operational expenses in managing a network.
- SDN helps in making IaaS (Infrastructure as a Service) more efficient.
- Controller has the complete view of the network and an administrator can manage all the switches/routers through one single controller, following benefits are possible:
- New services can be rolled out more efficiently
- A network administrator can plan and manage his network more efficiently and effectively.
- Network elements like switches/routers can be dynamically added/removed in the network without much changes in the network configuration.
- An administrator can manage the network wide policies including filters more efficiently.
Considerations
SDN is still evolving and it seems to be a great alternative for the traditional networking. But there are few things you need to consider before you decide to use SDN in your network:
- As more intelligence has been added into the controller, controller becomes a single point failure in the network. If controller fails or misbehave, it may affect the whole traffic in the network.
- As a single controller manages all the flows in the network, the network management may become more complex with higher number of flows.
- As a single controller configures the flows in all the switches/routers in the network, there could be scalability issues. Though there are studies that shows a controller can manage millions of flows.
- It is still not clear if there will be lots of applications which would want to manage/configure underline network.
Summary
So some people are suggesting that SDN is ready for deployment and couple of vendors are providing complete solution while some people are suggesting that SDN is still evolving and may not be useful for all types of networks. So please do some more research before you take a plunge in SDN world.
If you have deployed SDN, please let me know for what benefits and type of network you have deployed it.
8 comments
You have told that how SDN works on every system and how much important it is for every user. Really helpful because you have also shared some benefits by which people can judge the how much beneficial it is.
Just wanted to say that I enjoyed reading this
Thank you for the incite to SDN’s this is a whole new concept for me and I think this game me a good fundamental understanding of how it works from a “TOP LEVEL”
Thank you again.
I’m glad you like it! Join our newsletter to stay tuned on the new articles.
First. Thanks you for the information provided in this series of articles.
My question is this: Can an SDN controller compete with ASICs in terms of speed? In other words, can the software on the controller perform or out-perform the hardware in the routers/switches? And, what type of physical connections are required handle the traffic between the controller and the network devices?
Thank you.
John
SDN controller software usually runs on a normal server (Even a PC) and can connect to the SDN enabled Layer 2 Switches using Ethernet. SDN controller and switches use OpenFlow protocol to communicate. SDN controller is not involved in data forwarding and so it need not have Network Processors or ASICs. I hope this answers your question.
In my understanding, SDN moves the brain (which decides the forwarding rules) out of the routers/switches and put it into the controller. The brawn (which does the actual forwarding, based on the rules provided by the controller), is still the same router hardware.
Dear Vigneswaran,
Your understanding is right that brain (i.e control plane software) is moved to a controller. By doing this, the remaining part (i.e. data forwarding software) can run in a vendor independent hardware. This makes SDN very attractive.
Regards,
Bharat
Ok. Thanks for your clarification.
Vignesh