SDN is definitely a buzzword in the networking world. Software-defined networks are now gaining momentum among enterprises. But is this a truly disruptive technology that is going to replace legacy networks? Or is it a logical step forward in the evolution of the network? In this blog post I will discuss these questions.
As I see it, SDN is an evolutionary step for networks, not a revolution. Considering the benefits SDN technology offers or even starting to adopt it does not mean sweeping aside the traditional network as we know it. SDNs are not there to replace existing networks, but to add value to what we already have. In terms of conceptualization, if we take the networking ideas and solutions that have been in place for years and throw automation into the mix, we are in a good position to discuss SDNs.
While I won’t be providing a definition of SDN here, as there is no single definition everyone will agree on, I will discuss the core concepts behind SDN.
One of the most important concepts in SDN is Control Plane and Data Plane separation. Of course, one can argue that this is nothing new—it has been used commonly in traditional network hardware for years. Carrier grade routers have separate control cards for making routing decisions and a set of linecards to forward the traffic based on what was sent by the control card.
However, SDNs employ this concept in an evolved form. Here you can see a controller as a separate entity, residing remotely, making decisions from a distance (as it sees the network as a whole and makes decisions based on its overall state) and sending the instructions to forwarders. The difference is on what basis the decisions are made.
The second issue that probably comes to mind is that of having underlay and overlay networks. But again, are these networks actually something new? If we look at the provider’s networks, where all kinds of transport are used, with MPLS being very common among them, can we say the idea of separating the transport from the transmitted information itself is something different? Do VPNs do something else? In my opinion, they do not. In fact, look at the protocols used in Data Centers today and you’ll see BGP, EVPN, VXLAN, MPLS. So the concepts known and used for years have been adopted for a new use.
In a summary and comparison of SDNs to traditional networks, three areas stand out.
First, the idea of Control Plane and Data Plane separation was leveraged in the WAN. This resulted in the creation of controllers that look at the network from a helicopter view and intelligently route the traffic. This, the overall management, would not be possible without a central brain.
Secondly, in DCs, introducing underlay and overlay together with a spine and leaf topology and using the well-known BGP and EVPN protocols with VXLAN helped optimize resource use in the data center. Adding an external controller to manage both the underlay and overlay allows us to easily build a resilient, resource-optimized network.
Finally, the VMs/containers where SDN controllers have been introduced and integrated with platforms like Openstack or Kubernetes allow for advanced virtual network creation across all computes. Tungsten Fabric is a good example of such a solution.
In addition to these three issues, there is yet another angle to SDNs that has not been discussed: the ability by users to program the network devices. Again, the idea of running custom script on the routers is not revolutionary, as doing so has been possible for some time. But here we are discussing the idea of programming a completely new feature and applying it on the hardware.
As you see, adopting SDNs comes with a host of benefits. As we have discussed in the latter example*,* you need not wait for a vendor to develop a new feature when it can be done in-house or by a third party. A huge decrease in time-to-market (TTM) is the expected payoff here.
As the other cases have illustrated, resource usage optimization (and thus cost optimization), increased network resilience (and thus quality improvement) and agility in responding to changing needs are among the other benefits to arise.
CodiLime specializes in networks, both traditional and SDNs, and we ourselves see SDN technology as the evolution of traditional networking. The flagship SDN we work with is Tungsten Fabric, though we have expertise in a number of others. For example, we integrate P4-programmable SmartNICs with ONOS, an open-source SDN controller developed under the umbrella of the Linux Foundation.
Tungsten Fabric is an open-source network and security orchestrator which provides secure connectivity for cloud-native environments. More simply, it is a tool for managing both physical and virtual resources, including the implementation of service chaining, to create network connectivity dynamically and in an automated way and to assure the separation of traffic for different tenants.
To achieve that, well-known network protocols and concepts are used, including BGP protocol, VRFs, MPLS labels and VXLANs, all of which are commonly and successfully used in traditional networks. Using them in Tungsten Fabric makes it easier to understand a network’s design, architecture and operation for network engineers.
Tungsten Fabric provides a way to interconnect different workloads across a data center where different orchestrators reside, while taking into account resilience and security. Let’s imagine that we have a set of servers with workloads located on them and everything is managed by OpenStack. This setup has already been there for a while; and it’s stable and working, so we want to keep it for the time being.
On the other hand, we are building a new set of computes that will be managed by Kubernetes, which we want to migrate to eventually. In this case the goal is to seamlessly migrate from one environment to the other. This can be done with TF, as the virtual network created can span across different orchestrators and connect workloads between them. Such an approach allows for a step-by-step migration, and at the pace of one’s choice.
SDN technology brings a number of benefits to your traditional networks:
- Allows you to develop new network features independently of your vendor, thus reducing the expected time-to-market
- Optimizes resource usage to cut costs
- Increases network resilience to improve its quality
- Responds flexibly to the changing needs of clients and the market