The primary appeal of software defined networking (SDN) is that it separates the control and data planes to make it easier to reconfigure network architectures on the fly. This opens up all kinds of possibilities, from network resource pooling and aggregation to highly dynamic virtual network fabrics that can be scaled and configured as part of a completely virtualized data environment.
So far, the implication is that SDN will allow human operators to do all these wonderful things. However, in reality, the powers behind SDN development are already looking past mere mortals for network management in favor of application-level control and configuration.
These “application-aware” networks are unlike anything the enterprise has encountered in the past. For the first time, modules within the application will be able to query the network controller and other devices, and vice versa, and between the two of them configure the optimal network configuration for the highest level of productivity.
What’s wrong with that? Well, nothing really, provided there are ample safeguards against resource consumption system overload. After all, who wouldn’t want a more responsive, self-governing network that can deliver all manner of services with minimal oversight? As experts like HP’s Brian Quah describe it, with just a little information from the application, network switches will be able to instantly establish paired end points for a real-time flow and then set up a completely separate data path to allow them to communicate with each other. This is a far cry over the current process, in which CoS/QoS marking bits are processed at each switch and quite often dropped if even a single switch is overloaded. In the meantime, endpoint communication is usually carried over a dedicated STP or OSPF connection.
While application-aware functionality has been part of the SDN movement from the beginning, it’s only lately that we are seeing how it would work in practice. Cisco and Citrix recently announced an expansion of its joint SDN strategy by integrating the NetScaler application delivery controller (ADC) into the Cisco Unified Fabric Cloud Network Services portfolio. In this way, you can have applications with a dynamically provisioned virtual controller, deployed as a vPath-based service, capable of providing intelligent network management across on-premise and cloud-based external infrastructure.
The key to this level of functionality, of course, is the ability to see what is happening within these self-functioning network environments. The network management community, in fact, is already way ahead in the application-aware sphere, with new platforms like Compuware’s Application-Aware Network Performance Monitoring (AA-NPM) and User Experience Management (UEM) systems offering new insights into the relationships between applications and networks. The system provides passive collection of network data, such as latency measurements and packet loss rates, across VDI, WAN, VoIP and application-layer infrastructure to provide fault detection and performance optimization for web, middleware, database and even network applications themselves. In essence, what you wind up with is a network environment that enables not only dynamic provisioning and resource optimization, but self-correction as well.
This level of functionality may be beneficial in virtual network environments, but we should think long and hard before we push it onto the physical layer, says Cumulus Networks CEO J.R. Rivers and VMware’s Bruce Davies and Martin Casado. In the first place, such a setup would probably be overkill. Most IP networks today are based on rich multipath architectures and feature advanced load-balancing capabilities, so it’s unlikely that an application will be denied a proper working environment on the physical layer. More importantly, though, this kind of dynamic network engineering could prove to be counterproductive given the highly unpredictable nature of modern data traffic.
As I said, we are heading into uncharted waters here, and it will fall to every CIO to make the call as to how much of the enterprise data environment should be put on auto-pilot. Applications can certainly be programmed to devise their own optimal network configuration, but they aren’t likely to take the health or performance of other applications into consideration in the process.