Software Defined Networking (SDN) explained for beginners
Over the past few years, Software Defined Networking (SDN) has been a key buzz in the computer networking/IT industry. Today, more and more companies are discussing SDN to leverage it for their business and future growth plans. Reason being, SDN reduces CAPEX (capital expenses of network equipment) and OPEX (operational and maintenance expenses) of a network, and that’s what every business in the networking industry wants at the end of the day.eval(ez_write_tag([[728,90],’howtoforge_com-box-3′,’ezslot_5′,106,’0′,’0′]));
That brings us to the question, what is so special about SDN that existing or legacy networking is not able to deliver?eval(ez_write_tag([[580,400],’howtoforge_com-medrectangle-3′,’ezslot_2′,121,’0′,’0′]));
Basically, traditional networks can’t cope up and meet current networking requirements like dynamic scalability, central control and management, on the fly changes or experiments, lesser error-prone manual configurations on each networking node, handling of network traffic (which has massively increased due to boom of mobile data), and server virtualization traffic in data centres.
What’s more, traditional networks are tightly coupled with highly expensive network elements that don’t offer any kind of openness or ability to customize internals. To deal with such issues, open source communities came together to define a networking approach for future. And that’s how the concept of SDN came to life.
As an approach, SDN is evolving over the time. Talking of implementation, as its name suggests, SDN is implemented through software.
Since SDN is a software layer, it provides advantages such as reduced manual efforts, dynamic scalability, and central management of network devices. To understand better, consider the following: In traditional networks, each network device in enterprise or data centre is configured manually, something which is not only error-prone, but also requires manual reconfiguration (a highly tedious and time-consuming task) whenever there’s a change in network.
SDN, on the other hand, aims to have a holistic view of the network – you can configure/monitor/troubleshoot network devices with ease from central point, avoiding a lot of manual effort, hence saving time and money in the process.
As software layer is virtual, it would help in virtualizing the networks that will be created on top. These virtual networks are mapped to existing physical networks. Network Virtualization was very much needed since server virtualization brought revolution in the IT industry to virtualize storage and computing entities, something which played a key role in efficiently utilizing resources. Similarly, network elements in traditional networks are highly expensive with endless features, but those features were not getting completely utilized, and that’s the problem SDN aims to solve.
SDN at its core and as a one-liner, is nothing but separation of control plane from data plane (or forwarding plane) in traditional network elements (switches, routers).
For the uninitiated, control plane is the intelligent logic in network equipment that controls how the data traffic (that’s hitting the equipment) is managed and handled. On the other hand, data plane is the forwarding plane which manages forwarding/manipulating/dropping of the network data traffic. You can also understand about control plane and data plane here.eval(ez_write_tag([[580,400],’howtoforge_com-medrectangle-4′,’ezslot_1′,108,’0′,’0′]));
With this separation, core intelligence of network elements (i.e. control plane) can be moved to a central place which usually carries any of the following monikers: ‘control system’, ‘controller,’ or ‘network operating system’.
The following diagram depicts how, in case of switches, SDN will realize the separation of control plane into controller.
Control separation has many benefits like:
- Central management: You can configure, monitor, and troubleshoot the network and can also get a complete view of it (network topology) from the controller.
- Light-weighted network equipments: Network elements like switches and routers can be slimmed down, which in turn can help them becoming less expensive over the time. Intelligence would be at the controller where control plane (i.e. control logic) would reside, allowing control of underlying network elements by pushing rules over them through a common channel (i.e. protocols).
- Network virtualization: Virtualization of network leads to multi-tenancy (an architecture where-in a single software instance runs on a server and serves multiple tenants), which in turn helps leverage full potential of network elements. SDN controller can abstract underlying physical network and allow network administrators to program virtual networks corresponding to each tenant. A real life example of a place where network virtualization is used is data centres – the architecture is used to share common physical network among many customers.
SDN controllers are being sold in market by many big networking vendors/companies. Some examples of these controllers are Cisco Open SDN controller, Juniper Contrail, Brocade SDN controller, and PFC SDN controller from NEC. Many Open source SDN controllers like Opendaylight, Floodlight, Beacon, Ryu etc. are also present in market. What’s good about such controllers is that they provide a good understanding of how SDN solutions are being designed.
In broader scheme of things, SDN solution will have SDN controller as the middle layer, not only controlling and managing the underlying network infrastructure layer, but also collecting network state and information and exposing it to the top application layer through APIs.
In SDN world, over the time, majority of network vendors and open source communities have accepted Openflow as the communication protocol between control plane and data plane. Needless to say, an SDN solution with OpenFlow requires the protocol to be implemented in both controller and network elements. We will discuss more about Openflow and SDN in general in our upcoming articles.
Read more on the Architecture of OpenFlow in the second part of the article.
This article is co-authored by Tarun Thakur.