Without a doubt, the primary focus for many networking executives in the coming year will be to implement an SDN strategy. Some will place their trust in single-vendor, or at least vendor-dominant, solutions. Others will chose to avail themselves of the full spectrum of solutions developed by OpenStack, CloudStack or other open platform communities.
The thing is, simply deploying an SDN layer on top of existing network infrastructure is only the first step in a lengthy and complicated process toward full network abstraction. The sheer number of ways a software-defined architecture can be designed and engineered is beyond count. So before we start building this novel new data environment, let’s pause for a moment to consider one basic question: What do we want to do with it?
Network engineer Terry Slattery, for one, hopes that virtual networking will do for the data center what virtual memory did for early computer programming: absorb many of the management functions so applications can focus more intently on serving the user. Wouldn’t it be nice, he wonders, if network admins no longer had to worry about VLAN number/name assignment, subnet/interface protocol management or MP-BGP/MPLS implementation? Of course, we would need a network definition language, rather than the common device-level solutions available today, but that will likely emerge over the next year or so.
This is, in part, what companies like Juniper envision with their SDN platforms. Juniper’s OpenContrail system essentially acts as a compiler of network resources, says SDN architect Bruno Rijsman, taking on such mundane tasks as route instance and target configuration, policy import/export and interface and protocol management. Since the platform is logically centralized but distributed on the physical layer, it can reach out to diverse network elements while maintaining a single management view. Plus, northbound APIs like REST function on the service layer, rather than the device layer, so admins can implement multiple network architectures at high levels of abstraction. It’s the difference between configuring the network piece-by-piece so it operates the way you want, and telling it your goals and letting it figure out the best path to success.
To give software defined networks the intelligence they’ll need to figure that out, the SDN community is already shifting its attention from the substrate to advanced software and services like network monitoring and analysis, said Dan Pitt, executive director of the Open Networking Foundation. New tools are under development that will mirror or direct traffic flows to key engineering, security or customer experience programs. Those will in turn use the gathered data to optimize network control, dynamically and in real time. To foster this effort, the ONF has established a Northbound Interfaces Working Group to establish the proper requirements, architecture and working code for northbound APIs.
The kind of change SDN promises can be unnerving, says Plexxi’s Mike Bushong. Not only will it require new tools and certifications, but an entire reimagining of the devices and infrastructure that support network architectures. To date, network devices have been designed and deployed to carry out specific functions, and if a need arises that falls beyond the device’s purview, a solution must come from somewhere else. Under SDN, routers and switches, even virtual ones, will exist solely to execute programs. And this means network operators will become “articulators of intent rather than masters of implementation.”
Ready or not, this is future is upon us. SDN is highly dynamic and has the potential to deliver an extremely streamlined, efficient networking environment, but that comes at the cost of a high degree of uncertainty when devising the appropriate environment to suit both users and administrative needs.
And if you’re not careful, you could wind up with all the complexity you have now duplicated across umpteen layers of network abstraction.
Photo courtesy of Shutterstock.