Why are we going towards SDN?

Everyone who is hearing about SDN should ask the question why we are talking about SDN? What problem is it trying to solve?

If we look at traditional networking (layer 2 and layer 3 with routing protocols such as BGP and OSPF), we are completely dominated by what is called protocols.

These protocols in fact have been very helpful to the industry. They are mostly standard. Different vendors and products can communicate using standard protocols with each other. A Cisco router can establish a BGP session with a Huawei switch or an open source Quagga router can exchange OSPF routes with a Juniper firewall.

The routing protocol is a constant standard with solid bases. If you need to override something in your network routing, you have to find a trick to use protocols, even by using a static route.

Further more the legacy networking and switching gears are based on a tied control plane and forwarding plane on a single box. Each switch or router runs a control software (AKA firmware or operating system) which includes components such as spanning tree, BGP, OSPF, link aggregation, LLD, and so on. Each device uses these protocols to build a network from its own perspective.

This tide integration between software and hardware, or control and data plane limits the scalability of the network because of a lack of having a single, know all, network brain.

This integration also has a cost impact as each vendor will charge extra for a software running on their switches.

One of the main objectives of SDN is to dis-aggregate the control and data plane. That means to have a single control plane software (the SDN controller) and multiple bare metal SDN-enabled data plane gears (such as pure OpenFlow switches).

SDN can help us to come out of the routing protocol cage, look at different ways to forward traffic. SDN can directly program each switch or even override a route that is installed by routing protocols.

There are high-level benefits of using SDN, a few of which we have explained in the following list:

• An integrated network: We used to have a standalone concept in traditional networks. Each switch was managed separately; each switch was running its own routing protocol instance and was processing routing information messages from other neighbors. In SDN, we are migrating to a centralized model, where the SDN controller becomes the single point of configuration of the network, where you will apply the policies and configuration.
• Scalable layer 2 across layer 3: Having a layer 2 network across multiple layer 3 networks is something that all network architects are interested in and until now we have been using proprietary methods such as OTV or by using a service provider VPLS service. With SDN, we can create layer 2 networks across multiple switches or layer 3 domains (using VXLAN) and expand the layer 2 networks. In many cloud environments, where the virtual machines are distributed across different hosts in different data centers, this is a major requirement.
• Third-party application programmability: This is a very generic term, isn't it? But what I'm referring to is to let other applications communicate with your network. For example, in many new distributed IP storage systems, the IP storage controller has the ability to talk to networks to provide the best, shortest path to the storage node. With SDN we are letting other applications control the network. Of course this control has limitations and SDN doesn't allow an application to scrap the whole network.
• Flexible application based network: In SDN, everything is an application. L2/L3, BGP, VMware Integration, and so on all are applications running in the SDN controller.
• Service chaining: On the fly you add a firewall in the path or a load balancer. This is service insertion.
• Unified wired and wireless: This is an ideal benefit, to have a controller that supports both wired and wireless network. OpenDaylight is the only controller that supports CAPWAP protocols that allows integration with wireless access points.