Introduction to NSO

Cisco Network Services Orchestrator (NSO) enabled by Tail-f is an industry-leading orchestration platform for hybrid networks. It provides comprehensive lifecycle service automation to enable you to design and deliver high-quality services faster and more easily.

Creating and configuring network services is a complex task that often requires multiple configuration changes to all devices participating in the service. Additionally changes generally need to be made concurrently across all devices with the changes being either completely successful or rolled back to the starting configuration. And configuration need to be kept in sync across the system and the network devices. NSO approaches these challenges by acting as interface between people or software that want to configure the network, and the devices in the network.

The key features of NSO that comes into play includes:

Figure 1. NSO Overview

Network engineers use NSO as a central point of access to manage entire networks. They commonly do this using the NSO CLI or web UI. This document illustrates the use cases using CLI examples, but it is important to understand that any northbound interface can be used to achieve the same functionality.

All devices and services in the network can be accessed and configured using the NSO CLI, making it a powerful tool for network engineers. The CLI also provides an easy way to define roles and associated authorization policies limiting the engineers view of the devices under NSO control. Policies and integrity constraints can also be defined making sure the configuration adhere to operator standards.

The typical workflow when using the NSO CLI is as follows:

This section provides a broad overview of the NSO architecture and functionality.

Figure 2. NSO Architecture

NSO has two main layers: the Device Manager and the Service Manager. They serve different purposes but are tightly integrated with a transactional engine and database.

The purpose of the Device Manager is to manage device configurations in a transactional manner. It supports features like fine-grained configuration commands, bidirectional device configuration synchronization, device groups and templates, and compliance reporting.

The Service Manager makes it possible for an operator to manage high-level aspects of the network that are not supported by the devices directly, or is supported in a cumbersome way. With the appropriate service definition running in the Service Manager, an operator could for example configure the VLANs that should exist in the network in a single place, and the Service Manager compute the specific configuration changes required for each device in the network and push them out. This covers the whole life-cycle for a service: creation, modification and deletion. NSO has an intelligent and easy way to use a mapping layer so that network engineers can define how a service should be deployed in the network.

NSO uses a dedicated built-in storage Configuration Database (CDB) for all configuration data. NSO keeps the CDB in sync with the real network device configurations. Audit, to ensure configuration consistency, and reconciliation, to synchronize configuration with the devices, functions are supported. It also maintains the runtime relationships between service instances and the corresponding device configurations.

NSO uses Network Element Drivers, NEDs, to communicate with devices. NEDs are not closed hard-coded adapters. Rather, the device interface is modeled in a data-model using the YANG data modelling language. NSO can render the required commands or operations directly from this model. This includes support for legacy configuration interfaces like device CLIs. This means that the NEDs can easily be updated to support new commands just by extending the data-models with the appropriate model constructs which avoids any programming tasks as part of the change cycle.

NSO also comes with tooling for simulating the configuration aspects of a network. The netsim tool is used to simulate management interfaces like Cisco CLI and NETCONF for the purpose of examples and service development.

The industry is rapidly moving towards a service-oriented approach to network management, where complex services are supported by multi-vendor devices, physical and virtual. To manage these, operators are starting a transition from manually managing devices towards a situation where an operator is actively managing the various aspects of services.

Configuring the services and the affected devices are among the largest cost-drivers in provider networks. Still, the common orchestration and configuration management practice involves pervasive manual work or ad hoc scripting. Why do we still apply these sorts of techniques to the configuration management problem? Two of the primary reasons are the variations of services and the constant change of devices. These two underlying characteristics are, to some degree, blocking automated solutions, since it takes too long to update the solution to cope with daily changes.

Time-to-market requirements are critical for a new service to be deployed quickly and the delay in configuring the corresponding tools has a significant impact on revenue. There is an unserved need in provider networks for tools which address these complex and sometimes contradictory challenges while constructing service configurations.

NSO enables service providers to dynamically adopt the orchestration solution according to changes in the offered service portfolio. This is enabled by using a model-driven architecture where service definitions can be changed on the fly. Rather then a hard-coded orchestrator, NSO lears from the service models. Service models are written in YANG (RFC 6020).

NSO delivers an automated orchestration solution towards hybrid multi-vendor network. The network can be a mix of traditional equipment, virtual devices and SDN Controllers. This flexibility is managed by a Network Element Driver, NED, layer that abstracts the device interfaces and the Device Manager which enables generic device configuration functions.

Figure 3. NSO Logical Architecture

At the core of NSO is the configuration datastore, CDB, that is in sync with the actual device and service configuration. It also manages relationships between services and devices and can handle revisions of device interfaces.

The Service Manager addresses the following challenges:

The Device Manager supports the following overall features:

NSO provides user interfaces as well as northbound APIs for integration to other systems. The main user interface is the NSO network-wide CLI which gives a unified CLI towards the complete network including the network services. This User Guide will illustrate most of the functions using the CLI. NSO also provides a Web UI.

The northbound APIs are available in different language bindings (Java, Python), and as protocols, like NETCONF and REST.

In order to support dynamic updates of functionality as added or modified service models, support for a new device type etc, NSO manages extensions as well defined packages. Every NED is its own package with its own release life-cycle. Every service model with corresponding mapping is also a package of its own. These can be upgraded without upgrading NSO itself.

In order to learn how to use NSO and also to simplify development using NSO, NSO comes with a network simulator, ncs-netsim. Many of the examples will use netsim as the network.

NSO supports a 1:M high-availability mode. One NSO system can be primary and it can have any number of secondaries. Any configuration write has to go through the primary node. The configuration changes are replicated to the read-only secondaries. The replication can be done in asynchronous or synchronous mode. In the synchronous the transaction returns when the secondaries are in sync.

For large networks the network devices can be clustered across NSO systems. Say you have 100 000 devices split in two continents. You may choose to have 50 000 devices in one NSO and 50 000 in another. There are several options on how to configure clusters to see the whole network. The most common is a top NSO where also services are provisioned, and the top NSO sees the whole network.