Network control and management is a complex task, incorporating cloud operations, core and metro transport, mobile fronthaul and backhaul connectivity all the way to user applications. Setting aside optimizations and assurance mechanisms, running applications on such a diverse and distributed infrastructure is a challenging task in itself. With localized and highly engineered network operational tools, it typically takes several days or even weeks for any changes, upgrades or service deployments to take effect.

Enter software-defined networking (SDN)! SDN introduces centrally controlled network programmability and is considered a game-changer by many owing to its software-centric flexibility in contrast to traditional network management platforms. SDN evolves device-based network operations to resource-driven control, enabling centralized, programmable and automated services across multiple domains. While many network operators – telecom and cloud alike – are deploying SDN platforms for control agility and network abstraction, the real potential of SDN remains rather murky and inaccessible.

The key issue is that, while SDN is progressively getting adopted by various market players, the ecosystem around centralized SDN platforms is largely focused on static and hardware-centric network operations. The bottleneck doesn’t necessitate the introduction of entirely new tools, but rather an upgrade of legacy technologies – service provisioning, activation, fault management, etc. In order to attain self-driven networking (SeDN), centralized SDN control needs to be augmented with instantaneous data-driven decision making using advanced monitoring concepts and machine learning (ML) tools, feeding the management and control plane alike.

So let’s look at the architecture of such an evolved platform, together with two of its core components: streaming telemetry and ML-driven analytics.

Architectural integration

The discussion and debate around SDN have almost exclusively focused on separation of the data and control planes, with little to no attention on overall operational cycle, including monitoring, intelligence and management functionalities. Figure 1 captures this theme in an SeDN architecture, where network resources, physical or virtual, are continuously monitored using a telemetry engine, exposing real-time network states to the analytics stage, which in turn feeds into the control and management planes. This holistic platform not only caters for centralized and programmable control, but also makes ML-driven decisions to trigger actions, essentially connecting data-driven automation with policy-based orchestration and management.

It’s worth highlighting the importance of closed-loop operation (CLO) for SeDN as it fundamentally changes the way networks are operated today, empowering truly dynamic and autonomous operation. Consider the example of a path computation element, which identifies paths through the network based on a given set of constraints. SeDN, through its closed-loop interactions and consolidated view of both infrastructure and services would rather aim to discover, and enforce, intent-driven and application-aware routes based on historical, current and predicted state information.

Figure 1

Telemetry aspects

SeDN-enabled networks would represent a wide variety of rapidly evolving application stacks, consuming both physical and virtual resources. However, traditional network management tools are unable to efficiently tap into this goldmine since they lack the capabilities to probe network states in real-time; among other issues related to scalability, vendor lock-in, etc. For instance, monitoring based on Simple Network Management Protocol (SNMP) largely relies on data monitoring at fixed intervals, and is managed using traps triggering alarms or actions. While SNMP has served the industry long and well, network monitoring needs to rise to the new visibility requirements.

On the other hand, model-driven streaming telemetry is not about a fancy way of data monitoring, rather it’s defined by operational needs and requirements set by telecom network operators (e.g., OpenConfig). It enables vendor-agnostic network state monitoring on a continuous basis using time series streams, and abstracts data modelling from data transport, allowing unique open source initiatives, like YANG (model), GRPC (transport), etc, to be leveraged. Furthermore, one of the key differentiators in moving from legacy monitoring to model-driven telemetry is the use of subscription-based data access, as opposed to request or trap-based desired data selection. Figure 2 depicts and enlists a few key differences between a legacy and a streaming solution.

Figure 2

ML-based analytics

The capability to achieve a state-full view of the network based on streaming data monitoring is a must for SeDN, however it’s the analytics engine which enforces network behaviour, and enables use cases like traffic engineering, proactive maintenance, capacity planning, etc. The goal of this engine is to incorporate intelligence via various ML and big data toolsets, learning hidden relationships, discovering traffic patterns, finding anomalous events, etc., and recommending actions. Figure 3 lists a few architectural and algorithmic considerations for the analytics environment, together with several applications.

Let’s consider a specific example of capacity management. The SeDN platform will receive business and operational policies as an input, and use abstracted network topology and telemetry data (e.g., traffic load, performance, deployed bandwidth, etc.) to adapt deployed network capacity. The policy may crank up resiliency levels for certain segments and shift the traffic, or simply maximize the usage at a given point in time. Leveraging the CLO, described earlier, SeDN could achieve the aforementioned goal, minimizing engineering and testing efforts, and in fact enabling substantial cost savings.

Figure 3

The diversity of the modern networking stack, and the dynamic nature of both the application and infrastructure layers require that conventional SDN solutions are augmented with advanced monitoring and ML-driven analytics functionalities for end-to-end network management. The challenges remain in terms of the lack of standardization or reference architectures on how these technologies may be coupled. Furthermore, issues related to data integrity, multi-vendor coexistence, and common data models need to be addressed, together with security aspects. 

Nonetheless, it’s clear that self-driven networking will significantly simplify network operations, not only leading to OPEX savings, but also enhanced customer experience. This complex and heterogeneous architecture will almost certainly be multi-domain, compelling policy and analytics to become mission critical in the context of holistic network management.

While a step-by-step integration approach is reasonable, introducing SDN-based control, followed up by SeDN, the technology roadmap should be clearly laid out, together with managed expectations. If not, the progress in SDN deployments may stall owing to overly hyped deployment scenarios and commitments beyond capabilities.