Infrastructure Software: SDN makes network management a first class citizen

Back in May 2012 Mike Fratto predicted in his blog that SDN will be “Reborn in Network Management”. There is a lot of truth to his statement. The words “software defined” in “Software Defined Networking (SDN)” inspired people to rethink the overall control plane architecture of the network making the case for infrastructure software that complements software already embedded in virtual and physical devices, (e.g., the software and protocols running in and between network elements).

We are evolving our treatment of the network.  What once was a discrete set of loosely coupled devices will now be interacted with as a system.  To get there means the network must be represented by an overall system model. Classic network management functions become an integral part of the infrastructure software, and will spawn their own management requirements. SDN makes network management a first class citizen. Effectively we’re past the time when network management was an afterthought, or when network management was an operational silo. The coming integration of network management into the larger network software domain means infrastructure managers will not only manage and operate, but also actively contribute to the overall business proposition of the IT infrastructure.

Infrastructure software is the heir to the network management software as we know it today.  It includes much more than just traditional network management software.  Infrastructure software will control static and ephemeral state as well as integrate traditional device management software, resource orchestration software, and other software to provide enhanced infrastructure services. These infrastructure value-added system services will subsume and integrate traditional functions like network analytics, location or positioning services, path computation services, policy and identity services etc.

When we as network engineers were asked to solve a new problem, we typically designed new features and protocols for network devices.  Our primary concerns were that solutions worked under all potential conditions and failure scenarios, and that we could get to market quickly. Network management, ease of use, or the ability to easily automate feature deployment were secondary considerations to be optimized after beachhead success.

“Software Defined Networking” has made us switch gears. “Software defined” means usability, automation, agility in deployment, and ease of integration with application software.  Success here means we must broaden our scope from being “device-centric” to “network and system centric”.  When undertaking feature design, which inevitably requires infrastructure software becoming part of the solution design process, operational considerations can’t be designed in later.

As a consequence, software-defined thinking also requires us to change our interpretation of our good old FCAPS framework for network management. Our view on Fault, Configuration, Accounting, Performance, and Security changes when we approach FCAPS with a different mind-set that emphasizes a distributed network of physical and virtual devices complemented by network-level and system-level software.  FCAPS evolves to a broader scope. Taking “fault” as an example: In case of a link failure, today we have two separate event handling mechanisms: (1) from a control plane perspective, we’ll trigger re-convergence of our routing protocol and (2) from a management plane perspective, we’ll likely send an alert (syslog) so that the management application might fetch further details from the device to allow an operator to take appropriate action. Taking the needs of infrastructure software into account, such failure events might need to be presented to several additional network functions – and the decisions of those functions might in turn directly impact the future behavior of the network. For example

• path computation functions could leverage such events to compute new optimum paths and install corresponding state in the forwarding plane.
• network positioning and demand engineering functions could react to such failure events with changes to future placement decisions.

Beyond failure events, similar considerations apply to performance management.  Key is looking beyond individual element performance and towards network wide performance parameters. “Network weather reports”, overall trends, anomalies, and predictions of future system behavior should be extractable from the network. Accounting, security and of course configuration similarly need to be rethought. We will evolve from pure device configuration, where the entire configuration resides on the individual device, to one where we combine device configuration with configuration statements that are broader than just a single device (often termed “network intent”).

When we end up thinking in terms of “software-defining” our viewpoint of the network control plane will now embed enhanced infrastructure management. FCAPS evolves and FCAPS for the infrastructure software layer itself defines our agenda. Network management changes from being an afterthought to top-of-mind thanks to SDN.

Share