Over the last several months, we have been watching the developments related to the latest buzzword in networking, Software-defined Networking or SDN in short, with great interest. Though at a relatively early stage of adoption and with major networking vendors just starting to define their strategy around SDN, it promises to be potentially the most disruptive development the field of networking has seen in a long time.
While the need for network virtualization in datacenters of major cloud providers has, in a way, driven this innovation in networking, it has become increasingly obvious how service providers and enterprise networks can benefit from SDN. It’s a given, that it is only a matter of time before the networking architectures of the future will be based on an SDN model.
As a network management vendor, we at WebNMS are curiously watching this space to enhance our product capabilities to align with the changes in the networking architecture brought about by SDN. From the perspective of network management, one of the major changes in SDN architecture revolves around the software-based SDN controller that is central to all things SDN. Technically, the network control layer is decoupled from the forwarding/data layer in the networking devices and centralized into a software component that is called SDN controllers. This migration of control traditionally built into the network devices is now centralized in SDN controllers which enable the underlying networking infrastructure to be abstracted for various applications and network services. This allows the SDN controllers to have central intelligence of the whole network and enables programmability, automation and control to build flexible, dynamic and scalable networks.
Of course, this will have an impact on how network management will be carried out on networks that are based on SDN architecture. Today, the FCAPS information must be queried by the network management softwares directly from each of the network devices. With SDN, data can simply be obtained from a single entity – the SDN controllers. This will impact how the information is modeled and manipulated in the network management systems, apart from the challenges of implementing southbound capabilities to talk to software controllers instead of networking devices.
While Openflow has emerged as the standard protocol for communication between the SDN controllers and network devices, which most of the networking vendors have either already implemented or are in the process of implementing, there is still no defacto standard defined on the northbound layer of SDN controllers. Thus, most of the northbound APIs instrumented by SDN controllers of today are all non-standard and proprietary. These APIs make it possible to implement network applications and services like policy, QOS, traffic engineering, security etc. and also expose data that can be used by network management applications for FCAPS functions.
WebNMS can talk to both the controllers as well as the devices
In an SDN environment, communicating with the controllers becomes crucial for network management applications. While many of the networking vendors are devising SDN solutions and building SDN controller components along with Openflow support in their network equipment, there are several open source SDN controllers that work with multi-vendor devices thanks to the adoption of the Openflow standard as control protocol.
At WebNMS, we are doing a reference implementation with one such SDN controller, namely Floodlight. Floodlight is an open-source SDN controller project backed by Big Switch Networks. This integration effort with Floodlight controller will serve as a reference for WebNMS customers for their future SDN implementations and will gear us up for the challenges of fitting into this changing networking landscape. Watch this space for more SDN related posts and updates on the work we are doing at WebNMS on SDN.
