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.
A software-defined network infrastructure has two main key components:
- The SDN controller (only one, could be deployed in a highly available cluster)
- The SDN-enabled switches (multiple switches, mostly in a Clos topology in a data center) as shown in the following figure:
An SDN controller is the single brain of the SDN domain. In fact, an SDN domain is very similar to a chassis-based switch. You can imagine the supervisor or management module of a chassis-based switch as an SDN controller and the rest of the line card and I/O cards as SDN switches. The main difference between an SDN network and a chassis-based switch is that you can scale out the SDN with multiple switches, where in a chassis-based switch you are limited to the number of slots in that chassis:
It is very important that you understand the main technologies involved in SDN. These methods are used by SDN controllers to manage and control the SDN network.
In general, there are two methods available for controlling the fabric:
- Direct fabric programming: In this method, the SDN controller directly communicates with SDN-enabled switches via southbound protocols such as OpenFlow, NETCONF, and OVSDB. The SDN controller programs each switch member with related information about fabric, and how to forward the traffic. Direct fabric programming is the method used by OpenDaylight.
- Overlay: In the overlay method, the SDN controller doesn't rely on programming the network switches and routers. Instead it builds a virtual overlay network on top of the existing underlay network. The underlay network can be an L2 or L3 network with traditional network switches and router, just providing IP connectivity. The SDN controller uses this platform to build the overlay using encapsulation protocols such as VXLAN and NVGRE. VMware NSX uses overlay technology to build and control the virtual fabric.