Service providers globally are converging on a control model to achieve the significant goal of automating service creation and assurance from data centers, through the network, to customer premises equipment. In this model, a centralized network controller delivers end-to-end network abstraction, automation, and service awareness, thus considerably simplifying the work of service orchestrators.
Realization of this vision, in practice, has many challenges however. In this post, we review the model and the challenges, and show a pragmatic three-phase approach to support the successful implementation of a service-aware network – a critical component of the complete solution. This approach builds on recent architectural work by service providers and standards bodies.
Control Model Overview
At the highest level of this control structure, a service orchestrator interacts with three controllers (Datacenter, Network, and CPE) to establish services between customer sites and datacenters through the IP/optical network. This is illustrated in the figure above. Each of the controllers understands and controls their respective areas (data center, network, and CPE) and provides a simplified abstract view to the service orchestrator. This allows the service orchestrator to create services without having to understand specific details of each of the areas.
The network controller (the focus of this post) interfaces with domain controllers for the packet layers (IP, MPLS) and transport layers (WDM, OTN, Microwave) to create a coherent view of the entire network, to enable automation of its functions, and to support simplified abstracted interaction with Service Orchestrators and OSS tools. Some of the specific capabilities/functions of the network controller are as follows:
- Discovers and generates a complete abstracted view of the entire IP/Optical network, including cross-domain links
- Provides single interface to Service Orchestrators
- Provides single “pane of glass” for network engineers
- Visualizes, analyzes, and operates the network
- Maintains network policies
- Manages network resources as a pool – especially cross-domain resources
- Automates network optimization, and restoration
- Adjusts and optimizes the network for the specific needs of each service, rather than focusing only on traffic engineering
Network domain controllers typically have similar capabilities to the network controller, but limited to a single domain consisting of one vendor or layer (IP or Optical). In a sizeable service provider network, metro, regional, and long-haul networks are often separate domains.
Challenges to Realizing Service-Aware Network Control
Fulfilling the role of network controller in a large carrier network is an extremely complex task, requiring not only understanding and control across multiple network layers (primarily IP/MPLS and Optical), but also across multiple vendor and geographical islands. Understanding the complex relationships and dependencies between these layers and islands is an essential requirement for implementing a successful network controller.
Complicating this further is that carriers cannot upgrade 100% of their networks overnight – both economic and practical deployment constraints make this impossible. From a pragmatic perspective, this mandates that deploying a network controller must happen in multiple stages as the network evolves from legacy software and systems to next-generation hardware systems and SDN controllers.
Service providers are also understandably reluctant to handover full control of their networks to software, without an incremental deployment path to generate confidence and trust.
A Pragmatic Three-Phase Approach to Implementing Service Aware Network Control
There is a solution to these challenges. As a result of in-depth work performed with large service providers in EMEA and the Americas as they architect and deploy our NetFusion network controller in their networks, Sedona has developed a three-phase approach to make the service-aware network control dream a reality. The approach is as follows:
Phase 1 – Discovery and Analytics: Before service providers build trust in a control system to automate key network functions, they must first trust that the system is able to understand their existing network accurately and in detail, even with ongoing planned and unplanned changes in the network. This includes the resources in each layer and also the connectivity between the layers. Without this understanding, automation can lead to disastrous results. As an example, the system might decide to reroute one optical path, but accidentally reroute a different path. Therefore, the current network configuration must be automatically learned from the network itself in real time, and not from manually fed inventory systems, as is the practice today.
When this solid foundation is in place, service providers can already enjoy many benefits. Examples include:
- Analysis of the network to determine if policies are adhered to (e.g. diversity policy).
- Reduced service-order fallout.
- Ability to troubleshoot the network across all layers.
- Identifying IP links that share optical layer risks.
- Planning the network more accurately, based on actual network data – reducing unnecessary spending on capacity and spares.
An important requirement for any network controller in this first phase, is that it must be able to extract network data not only from recent generation network equipment and SDN controllers, but also from legacy equipment and management systems. Similarly, the controller must support real networks that are inherently multivendor and multidomain in nature. Unless the complete network is able to be understood, the benefits of this first phase are limited and there may not be sufficient foundation for subsequent phases to be realized.
Phase 2 – Traffic-Aware Automation: Once the service provider has confidence in the accuracy of the network data, they can proceed to the next stage to enable progressively more automation across the IP and optical layers. A natural starting point is to allow the network controller to notify the IP layer about common optical risks, allowing it to find diverse paths for MPLS tunnels (SRLG sharing). Another small step is to move traffic away from a to-be-maintained optical link or node in a hitless fashion (Coordinated Maintenance). A further step is to automatically grow or shrink capacity on IP links based on traffic needs (part of Multilayer Optimization). Finally, the system can be used to restore IP traffic in the optical domain, saving considerable network costs (Multilayer Restoration).
Note that this second phase is focused on improving traffic flow as a whole, without understanding the specific services carried over the IP links.
Phase 3 – Service-Aware Automation: The third and final phase is to enable an intent API from the network controller to the Service Orchestrator, which allows the operator to set up services in the network in a coordinated fashion, with SLAs assured. This includes not only an understanding of all the network layers to ensure the SLA can be met, but also sophisticated multilayer actions – such as exploiting optical switching to add new capacity to the IP layer when it cannot support the service.
This considerably simplifies the role of the Service Orchestrator, which now only has to work with an abstracted view of the network. Another very important benefit is that the network controller is now able to understand traffic at a much more detailed level – down to each service and its properties. It can now adjust and optimize the network for the specific needs of each service, rather than focusing only on traffic engineering. This is a fundamental departure from even the most sophisticated traffic engineering practices of today and enables, for the first time, a network that is fully aware of its services.
It should be noted that each of these three phases of the evolution builds on the capabilities of the previous phases. For example, it is almost impossible to implement phase 2 without first implementing phase 1, since the details of the network need to be understood before fully automating it. Moreover phase 1 needs to be widely deployed even if only part of the network will be automated in phase 2, since a change in one part of the network (e.g. the new SDN part) affects the rest of the network, including the legacy part.
In the excitement of moving towards service-aware automation, it’s also very important not to forget the critical hands-on human efforts that are critical to success. Sedona is working on-site with customers step by step, helping them to plan their migration from legacy to SDN-based networks. This starts with the deep network understanding delivered by “Discovery” in Phase 1. During this phase, we work closely with our customers on the overall thinking, understanding of required use cases, consideration of specific needs, and planning the desired network accordingly.
The approach described in this post represents a practical path to achieving the goal of an automated service aware network, with economic and operational benefits delivered by each of the three implementation phases. Importantly, it also allows service providers to develop confidence in automating their networks by taking incremental low-risk steps at every stage.
Sedona Systems NetFusion is a fully-featured network controller developed from the outset to support the three-phase approach outlined above. Key to its success as a network controller is its unique and field-proven ability to extract real-time network data and to build a 100% accurate and dynamic network model spanning all equipment vendors, domains, and layers (0-3). NetFusion is deployed in multiple Tier 1 carrier production networks globally.