Of all the elements needed to implement a next-generation SDN architecture, none is considered more crucial than the controller. After all, in a software defined network, the software’s magic lies in the controller, and now that we have separate implementations of the control and data planes, the controllers need to do some fancy footwork to keep everything coordinated.
But as the number of SDN implementations continues to proliferate, nearly all of them incorporating different controllers and controller functions, do we run the risk of losing our grasp of what is and is not SDN? Or is it that we never had a firm grasp in the first place?
Of late, much of the activity surrounding the controller is the establishment of a vibrant northbound interface. As this is the API that allows the controller to talk to network management systems, orchestration software and even the applications themselves, the northbound interface plays a vital role in the ultimate utility of any given SDN platform. And with the southbound API that links to switches and routers largely dominated by OpenFlow, it’s no wonder top platform providers are looking to pack as much functionality and ease of use into the north-facing side as they can. In fact, there are so many northbound APIs out there that the Open Networking Foundation has taken upon itself the task of evaluating and categorizing them all, not to oversee their development, but to provide some guidance as to which APIs are appropriate for which workloads.
One of the newest solutions on the market is Anuta Networks’ NCX Enterprise system, which utilizes a central controller to coordinate the activities of any number of NCX agents spread across geographically distributed infrastructure. The system offers a self-service portal that allows users to define their own network requirements, which the company says can be activated in minutes, even across multi-vendor L2-L7 infrastructure. And since it’s an all-software solution, the system can incorporate new tools and functionality through simple upgrades.
But by placing such critical functionality upon a single network component, does the enterprise run the risk of creating an all-new single point of failure that, if debilitated, could bring data activity to its knees? This is one of the top threats that Radware expects once the hacker community learns the ins and outs of SDN. Traditional network devices are largely autonomous, so even if one is compromised, it would result in minimal network disruption. But once the SDN controller is tied to a variety of network components, thus increasing its accessibility, anyone compromising the control plane could wreak significant havoc.
Is it possible, though, that the enterprise industry is so caught up in controller-based SDN solutions that it fails to see other, equally intriguing alternative means of implementing advanced, dynamic network architectures? As Plexxi’s Michael Bushong notes, you can separate control and forwarding using a policy server, an OSS/BSS system or even a sophisticated Perl script. Purists might argue that these are not real SDN solutions, but ultimately it should be the way in which a particular protocol is used that determines “SDN-ness,” not the technology that houses it.
So in the SDN future, the controller will either be the most important piece of the stack, or it will fade to nothingness as network applications, services and functionality in general are distributed across diverse architectures. There are undoubtedly strong opinions as to which way it will be, but the decisive factor will be the enterprise’s willingness to shed tried-and-true infrastructure for a still largely undefined networking environment.
Photo courtesy of Shutterstock.