In our last blog post, we outlined the foundational elements that are the framework for Nokia optical network automation. We also explained that this automation approach is based on use cases that are focused on key business outcomes and address all aspects of the network and services life cycle. Now, let’s concentrate on specific parts of that life cycle: network topology and service discovery.

Having full topological visibility into the deployed infrastructure and services allows for full inventory of the optical network and also enables better:

• Provisioning of new services
• Insights into network utilization
• Discovery of shared risk link groups (SRLGs) or other traffic engineering parameters, and export to northbound applications
• Provisioning of services that use SRLGs to achieve better resiliency.

Nokia intent-based automation provides automated discovery of the network and services and automated export of the topology and services to any northbound application. The numerous available northbound applications include:

• Operations support systems (OSS)
• Inventory databases
• Hierarchical software-defined network (SDN) controllers for IP/optical operation
• Any other business-aware software application (for example, applications for subscriber service fulfillment).  

This automation is even more relevant for multi-vendor or multi-layer deployments where the combined topology and the interdomain links also need to be discovered.  

Importance of open interfaces

Automation uses open interfaces on both the northbound interface (NBI) and the southbound interface (SBI) side of the SDN controller as the mechanism required for abstraction. Through this abstraction, automation becomes the foundation for intent-driven networking as well as model-driven networking.

Automation also uses open interfaces for service provisioning, where there is a need to first discover deployed network topology and services, and then provision the services according to their service-level agreements (SLAs). In addition, automated service provisioning can use automation workflows to enable bulk service provisioning or to fully automate path computation, provisioning and verification with adherence to SLAs.

Key ingredients for automated service provisioning

Building the roads of a highway is easy when you know you have the materials required. The same is true for automation. As shown in Figure 1, several key ingredients are required for automated service provisioning.

Figure 1. Ingredients for automated service provisioning that is business-outcome oriented

Abstraction

Abstraction uses YANG data models to configure and extract topology from the optical network. The abstracted data models are targeted primarily towards a specific open NBI, to:

• The operator’s OSS
• A hierarchical SDN controller
• An orchestrator platform
• Other northbound applications.

Abstracted data models enable much simpler configuration with a minimum set of instructions. These are then passed on to the SDN controller or network management system where more detailed configurations, including the configuration of all the impacted hardware, takes place.
 

Open interfaces

Open interfaces provide automated machine-to-machine communication and also allow seamless integration of optical network functional applications and workflows into the OSS without customizations. They also enable better risk mitigation for operators by providing efficient multi-vendor and multi-layer network operations.  

YANG data models facilitate the machine-to-machine operations that open interfaces help interconnect. Two key open interfaces, NETCONF and RESTCONF, are used for configuration and verification.  

Initiatives by Nokia and the telecom industry are using two SBIs, NETCONF and gNMI, along with OpenConfig models to provide a basic set of operations to edit and query configuration on network devices. The SBIs and OpenConfig models also retrieve key performance indicators (KPIs) from the network, such as performance monitors and fault alarm monitors. And the SBIs also enable streaming telemetry—a means to measure performance KPIs with timestamping.  

Similar initiatives by Nokia and the industry are using two NBIs, RESTCONF and the ONF Transport API (TAPI).
TAPI enables two essential use cases for automation: topology export (inventory and abstracted optical network models) and service provisioning from either the OSS or the hierarchical SDN controller. For this reason, we are using our experiences to lead, develop and mature the ONF standards. Nokia is also involved in demonstrating the interoperability of the NETCONF and RESTCONF open interfaces at the OIF.
 

SLAs and path computation

Subscribing to SLAs is a very important feature of service provisioning because it allows for the introduction of specific advanced service characteristics. By knowing and exporting the SRLGs or latency it is possible to configure services with gold or even platinum SLA characteristics. These include latency optimized services, link disjoint services and even protected and restored services.  

At Nokia we believe it’s important to use latency as a constraint for path computation. Moreover, combining path computation with link disjoint path awareness featuring various exclude and include metrics more efficiently guarantees that SLAs are being met. Our algorithmic path computation solution is further enhanced by its capability to be coordinated with the distributed GMPLS control logic used for restored services or for protected and restored combined services.

Multi-vendor and open line systems

Multi-vendor deployments of open line systems (OLS) is becoming ubiquitous and is therefore one of the most important elements to incorporate in automation. The most common scenario has third-party terminal devices (including OpenZR+ DCO pluggable transceivers) supported over another vendor’s optical line system—an optical line that uses standardized, open interfaces.  

The Nokia solution for interoperability uses NETCONF or gNMI open interfaces to configure and manage third-party devices and employs OpenConfig data models on the terminal devices.

Multi-vendor OLS also require tuning power levels of the terminal device to ensure optimal performance throughout the line system. Our solution is centralized power control, including for third-party devices. In addition, an automated mechanism performs interdomain link discovery: Layer 0 discovery of the connectivity between the terminal device and the ROADM card. TAPI is then used to connect to an either an OSS or a hierarchical SDN controller for topology export and for provisioning—including IP/optical provisioning.

What’s next?

Now that we know the key ingredients needed for automated service provisioning, the next blog post in our series will discuss how specific automation use cases can reduce network TCO and protect SLAs by learning from network KPIs—to maximize network performance from existing network assets. Stay tuned.