3 Issues Service Providers Face with Disparate SDN Domains

At this early stage in SDN's evolution, service providers tend to roll out the technology one domain at a time, with each domain typically managed through a distinct SDN controller. It is rare at this point to find a single master transport SDN controller that coordinates and synchronizes multiple SDN domains. Yet the service environment is becoming increasingly dynamic and less predictable, especially as large enterprises roll out applications that generate real-time transactions and dozens of API calls.

As service providers move SDN out of smaller trials and into large-scale production networks, SDN silos and dynamic services will run counter to one another. The now disparate domains will need to be synchronized and coordinated. Here are three major challenges that will arise as a result of utilizing disparately managed SDN domains:

1. Operating Networks in Silos Undermines Service Providers' Ability to Compete

Customers don't care about domain distinctions. They care about their service experience, and their expectations are rising fast. Customers want self-serve access to network and service configuration, on-demand application performance and the ability to scale up and tear down network resources on an as-needed basis. Networks that don't enable these service characteristics in a synchronized way among layers and across domains ultimately will not meet evolving expectations. If service providers don't step up to the challenge, their native digital competitors most certainly will.

2. Offline Traffic Engineering Won't Suffice in a Dynamic Service Environment

Most traffic engineering is still conducted offline and after the fact. Historical models are studied and this information is fed back into the network in the form of changes to configurations, thresholds and resource availability on a periodic basis. With connected car companies and users of IoT device networks pushing out software updates and configuration changes as soon as they are available, it becomes very difficult to predict when resource demand will spike. Similarly, as large enterprises base mission-critical processes more on API-driven applications and multiparty, real-time exchanges of data, images and video, resource demand will grow exponentially, sometimes within hours. Traffic management needs to occur in near real-time because unpredictable traffic spikes and shifts must be accommodated and network resources need to be readily available and optimized.

3. Without Centralized Network Management, Service Providers Can't Visualize, Optimize and Automate

The three-legged stool of network management is made up of visualization, optimization and automation; none of these can be achieved while running disparate SDN domains without centralized, end-to-end network management. Without a single view of the network, substantially more effort is expended within NOCs to resolve customer-facing problems and automated path restoration cannot be implemented from end to end. Similarly, static provisioning continues to persist, which is unsuitable for a dynamic service environment. Without end-to-end visibility, dynamic provisioning and automated restoration, service providers end up over-provisioning capacity by 30 to 50 percent, meaning SDN's optimization goals aren't achieved. Finally, service providers can't automate service assurance. They struggle to offer—much less support—the robust SLAs enterprises require to support their real-time, API-driven business applications. This means service providers must adapt in order to compete for that high-value business.

To overcome these types of challenges and become highly competitive in the dynamic service marketplace, some service providers are turning to master transport SDN controller solutions. These solutions need to be multivendor, multidomain and multilayer in nature in order to be effective. They must also provide an end-to-end view and hybrid orchestration capabilities across both SDN-controlled and legacy networks.