Service providers must operate increasingly complex networks that support multiple services with varying and often conflicting requirements. They must also process a higher volume and rate of requests for network resources that need to be provisioned rapidly, often within seconds. While network virtualization and SDN technologies are making it possible to create dynamic, flexible IP/MPLS networks that can be reconfigured quickly to accommodate different business requirements, they lack the management intelligence to fulfill the promise of autonomous networking.

Another layer of management is required to create truly adaptive networks. This management and orchestration (MANO) layer needs real-time telemetry, analytics, optimization, and policy to enable intelligent provisioning of network services. It will facilitate the network that is needed, restoring operator visibility into changes taking place in the network and instilling engineering know-how in SDN applications for increased business agility, optimal use of capital investments, and improved operational efficiency.

Today’s service provider networks are complex, because they must support many applications – Internet access, streaming video, voice-over-IP, Layer 2 and Layer 3 VPNs, 3GPP mobile backhaul and core transport, cloud services, and more. This is in contrast to networks of the past, which typically were dedicated for different applications. For example, a service provider may have operated a Frame Relay network for enterprises, a Sonet-ring-based metro-area network for mobile backhaul traffic, and a best-effort IP network for Internet access, etc.

Obviously, running multiple networks required higher capex and opex investments than does a single, multiservice network. In addition, many of the traditional networks used circuit-switching technologies and were expensive to scale, since they wasted allocated but unused capacity. Many applications now run as a service on top of converged IP/MPLS packet-switching networks, which are much more efficient, scalable, and fault tolerant. However, their performance is less predictable and requires closer monitoring of service paths.

Running multiple applications on a converged network presents management challenges because each application has unique performance requirements, growth rates, and fault-tolerance characteristics. For example, a financial services enterprise may be willing to pay premium prices for very short delay paths to support its time-sensitive trading application. To provide this service, the service provider may need to find these short delay paths, segregate the application traffic from other traffic, and fully protect it from link and router failures.

In contrast, services offered to residential customers for over-the-top streaming video (such as Netflix and YouTube) have quality requirements that, if not met, will cause pixilation and playback pauses that may lead to customer churn. So low jitter paths are most suitable for this type of traffic. As streaming video is adaptive to available bandwidth within limits, an operator may provision for optimum video quality under normal conditions but allow it to degrade within acceptable levels during a demand surge or under failure conditions.

Optimizing the network for any service is hard and requires significant time investment by expensive engineers. Typically, a traffic demand matrix is created, mapping the volume of external traffic entering the network at each ingress router and then to each egress router where that traffic exits the network. An optimization algorithm uses this matrix and the network topology to recommend paths for each ingress-egress pair in the traffic matrix to minimize the maximum link utilization in the network. Once the paths are computed, they are provisioned in the network devices. This last step can be simplified and automated by an SDN controller that abstracts vendor-specific provisioning mechanisms.

Optimizing a multiservice network is much more difficult and probably not achievable without automation, due to each service’s specific requirements. Each service requires a traffic matrix and an appropriate optimization algorithm, which must run concurrently with those for all other services. Again, an SDN controller can simplify and speed provisioning, but topology, traffic, and performance analytics are needed to make intelligent, automated traffic engineering possible.

Figure 1 illustrates a simple two-tier architecture in which SDN applications control network behavior. Network devices (both physical and virtual) are not configured; rather they are programmed via southbound APIs by one or more SDN controllers . The controllers provide access to applications via northbound APIs, enabling the applications to modify network behavior to meet their needs. WAN SDN applications are only now being developed, such as traffic engineering, demand placement, bandwidth calendaring, and risk mitigation and remediation.

Although SDN controllers provide the means to change network configurations through software, it is clear that they lack management intelligence. In other words, to build networks that can adapt automatically to business demands requires another tier in the SDN architecture – one for intelligent MANO.

If applications can change network behavior without human intervention, what governs whether or not these programmatic changes should be made and what their impact on the network will be? Answering these questions is the role of analytics software. SDN analytics – infused with and guided by human intelligence – can determine the impact of requested changes and govern whether or not they should be allowed.

There are two important functions for SDN analytics. The first is to maintain management visibility into the network even while changes are being made programmatically. With no traditional work order process to follow, operators may be unaware of changes being made. When programmatic changes work and have the desired results, this lack of visibility may be acceptable, but when changes are problematic, how does the operator diagnose the problem or find the application culprit, buggy controller, or failing network device that is causing the issue?

SDN analytics should provide visibility into the network – the devices and the controllers – by recording real-time telemetry from the network’s control plane protocols, including the topology, performance metrics, and traffic flow data. The recorded data can be very helpful for back-in-time forensics to identify the root cause of issues.

The second and more important function of SDN analytics is to provide management intelligence. Traditionally, when an operator needs to make a significant change to the network, a planning group is responsible for assessing the network’s readiness for the change. For example, when a service provider acquires a new enterprise customer, or an enterprise turns on a new service, the planning group must determine whether the network has sufficient capacity to accommodate it. If not, they will try to find paths in the network that may satisfy the needs. For viable, programmatic SDN orchestration, this planning know-how must be replicated in analytics software. The basis of this intelligence is a combination of real-time and historical telemetry, projections, and algorithms.

Given the importance of SDN analytics, therefore, the two-tier SDN architecture shown in Figure 1 needs to be expanded to include an analytics-based MANO layer, as shown in Figure 2. This new layer delivers both management visibility and intelligence to SDN applications.

With the new management challenges created by SDN, traditional management processes and tools must be reevaluated and updated. For example, if programmatic changes are being made to network configurations every few minutes or seconds, the periodical collection of metrics by polling devices or reliance solely on flow data is inadequate.

When software is making decisions that engineers traditionally have made, that software needs to be powered by the same know-how and ensure that all changes are transparent to human operators. Dynamic networks require real-time analytics, consisting of network topology, traffic and performance telemetry, projections, and algorithms. These should be delivered via an SDN management and orchestration layer between the SDN controller and SDN applications. Only then can they facilitate multiservice networks.