Do You Need an SDN Controller When You Already Have an NMS?
SDN Controller vs. NMS: Same, same but different?
The SDN Controller concept was originally developed as the intelligent centralized point of network control and programmability in an SDN environment. However, the name was very quickly adopted by several vendors who claimed that their traditional NMS was a “controller” because it allowed network-wide management and point-and-click provisioning of their equipment. As a result, for many people the line between an NMS and a Controller is blurred, resulting in confusion across the industry.
This confusion is even more prevalent in optical networking. Whereas the layer 2 and layer 3 industry has developed standards for interfaces such as OpenFlow, those standards have lagged in the optical domain. While some work is being done on a standard interface set and some proprietary models have been demonstrated, the larger communications industry has embraced the concept of domain controllers for optical elements.
So if there is such a thing as a vendor-specific controller, what makes it different from an NMS?
At a recent trade show panel on control architecture, a representative from one of the largest US carriers stated, “If you bring me an SDN controller and it only works with your equipment, then I call it an NMS”. He had a point in that the entire concept of SDN was supposed to eliminate single-vendor solution roadblocks, but he was a bit behind the times based on the new paradigm of ‘domain’ controllers and ‘parent’ controllers (or orchestrators).
Under the new paradigm, the standards bodies have said that it may be a long time before optical equipment has a standardized set of open protocols that can comprehensively control all possible options. Instead, carriers and vendors have agreed to support a tiered architecture where domain controllers understand specific parts of the network and a parent controller understands how all of the parts of the network fit together.
The parent controller need not, and indeed cannot, understand the underlying technology - just the endpoints and capabilities of the domains. This, in turn, diminishes significantly the ability of the overall solution to provide a significant multi-layer optimization. Popular multi-layer use cases such as router bypass and protection coordination rely heavily on awareness of the full multilayer topologies and not just of the endpoints, so basically only a single vendor solution may be really optimized. One can only guess who benefits from that.
An SDN controller – even if it only works in a limited domain - is a centralized, intelligent network controller with application-level awareness of the services being offered. As opposed to a traditional NMS, a controller has the ability to provide programmatic interfaces to network behavior and presents standard, application-level APIs as a northbound interface.
Moreover, a true SDN controller is based on a priori data model, meaning that both devices and controller need to adhere to an agreed upon data model so it is by definition vendor agnostic. This is the biggest difference conceptually between a traditional NMS and a controller.
An NMS is generally a transactional provisioning system – commands are delivered to the NMS and translated into provisioning operations within the network. The functionality provided by an SDN controller is significantly more sophisticated, with the ability to make complex network decisions, sometimes via an outside trigger initiated with a standard API and sometimes automatically.
The other significant difference between an SDN controller and an NMS is that the SDN controller is designed to operate within the “C” of the FCAPS model (configuration). The other parts of the model (fault management, accounting, performance management, and security) will still require a separate network manager of some sort (i.e., an NMS).
So, do you need a controller if you already have an NMS?
It depends on your network and your needs. If your network consists of a few elements from few vendors, you have a staff that is able to meet all of the management demands, and the network rarely changes, then an NMS may be sufficient. However, if your network is more complex, based on, if you would like to automate responses from internal and external demands, if you network has multiple layers that must be coordinated for restoration and load balancing, or if you have staffing limitations, then adding a true SDN controller may be the solution that you need.