For a couple of years already, the term Software Defined Network (SDN) has been gaining popularity and it is slowly trending quite a lot. We also hear about the decreasing role of “classic” network engineers, who gained their knowledge a couple of years ago, mastering packet networks theory, such as Ethernet, OSI / ISO model, and learning network device configuration commands, like switchport access vlan or ip route. Articles, such as “Sorry, network jobs are changing“, or “Do Network Professionals Need To Be Programmers?” may bother professionals, who are constantly learning from textbooks about networks, or want to choose their career path. I see, among my fellow engineers and network administrators a little worry about how SDN can shake the market. What does this mean for them?
Contrary to how it may appear, the answer to this question is not trivial. I have come across a lot of definitions, and more importantly, interpretations of what SDN is, which are largely dictated by someone’s idea of SDN. Vendors play a significant role in creating these definitions, claiming that they are ready for SDN era or even that they already have a ready product. In the meantime, one can say, that the No 1 principle of SDN is to separate the device abstraction that transports the network traffic (forwarding plane) from control plane abstraction, in such a way that it enables control the network functions by the means of a software layer. In practice, it can be systems, web applications or scripts. We also see this idea is called disaggregation-like services disaggregation (you can watch here a nice talk about disaggregation with Russ, Jeff and Pete). The described mechanism is intended to enable the programming of the network layer independently of the manufacturer’s operating systems. Hence, SDN is often referred to as network programmability and open networking. Interactions between layers of such a system, i.e. management application, SDN controller, and network devices, I would draw like this:
It’s good to take a look on the communication scheme. Between SDN Application and SDN Controller, the “communication language” is API (Application Programming Interface) of the controller. So, in theory, on this link, we can use any SDN controller with API documentation and we are good to go with writing our own applications or scripts for SDN. Further down, the communication between SDN controller and network devices is done via e.g. OpenFlow protocol (if supported by the hardware manufacturer). This then means, that what happens with packets on the network devices depends on the given scenario, de facto, controlled from the Management Application Layer (aka SDN Orchestrator).
OpenFlow is a protocol, which directly influences the data plane of the device, which means that it causes a direct entry in the routing table or switching table. Another common protocol is Netconf. By using Netconf, we can change the device configuration using protocols different than SSH (did you try to parse ssh and telnet outputs from Linux srcipt perspective? me, yes). Taking this into account, we can say, to fulfil the principle of separation of control from data plane in SDN one can either use OpenFlow, with OpenFlow we cannot save the changes on the devices, or Netconf which doesn’t have this disadvantage. Of course, which of those protocols you will use in your implementation, is your choice.
An infrastructure consisting of 6 Switches and 2 Routers may not need the SDN revolution, but administrating an infrastructure of several dozens of company branches and a thousand network devices, and integration with your private cloud or something at hyper-scale is a great opportunity to utilize SDN achievements. SDN in this case can solve an issue with network order, automatic diagnosis, immediate reconfiguration and integration of many IT areas (e.g., systems, network, storage).
Is then SDN a threat for “classical” network engineers? Maybe the lovers of pure CLI form and BGP session configuration will not happily invite the SDN solution, as it will in some sense be taking away their playground, which is the command line. On the other hand, it can be a start for a new, fascinating adventure for SDN architects, who could use their skills of IP network design to design and deploy such a network. Let’s take a look also at the newly open areas and new specializations, such as Network Automation engineering, SDN Engineer, which will require engineers to have programming skills (not necessarily top-notch) and knowledge of IP/Ethernet theory as writing scripts and developing SDN Management Applications will be an inevitable element of the SDN eco-system.
By it’s “openness” and “programmability”, it is SDN that opens the door to full utilization of the network devices’ potential, which by now, were still being limited by the configuration language dictated by the given producer. Let’s imagine that by using our script and NetFlow, we are able to develop an interesting functionality for us in the data plane layer. This approach to the above concept seems to be an opening more than a closing!
This broad issue combines in an obvious way, the programming knowledge along with the knowledge on the network architecture and Ethernet/IP. A SDN course, which we today call “Coding the Network (practicing SDN)” is something that will soon show up on our training map, so STAY CONNECTED!
[1] “Software Defined Networks, A Comprehensive Approach”, P. Goransson, C. Black, T. Culver, Elsevier, http://shop.oreilly.com/product/9780128045558.do
[2] Vendors documentation examples: Cisco APIC, Juniper Contrail, OpenStack documents
Awesome and easy to understand . Thank you !