NSO Introduction

Cisco Network Service Orchestrator (NSO) version 5.7.19 is an evolution of the Tail-f Network Control System (NCS). Tail-f was acquired by Cisco in 2014. The product has been enhanced and forms the base for Cisco NSO. Note that the terms 'ncs' and 'tail-f' are used extensively in file names, command-line command names, YANG models, application programming interfaces (API), etc. Throughout this document we will use NSO to mean the product, which consists of a number of tools and executables. These executable components will be referred to by their command line name, e.g. ncs, ncs-netsim, ncs_cli, etc.

The Orchestration Challenge

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.

How NSO Addresses the Orchestration Challenge

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 1. 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:

Transaction-safe activation of services across different multi-vendor devices.
What-if scenarios, (dry-run), showing the effects on the network for a service creation/change.
Maintaining relationships between services and corresponding device configurations and vice versa.
Modeling of services
Short development and turn-around time for new services.
Mapping the service model to device models.

The Device Manager supports the following overall features:

Deploy configuration changes to multiple devices in a fail-safe way using distributed transactions.
Validate the integrity of configurations before deploying to the network.
Apply configuration changes to named device groups.
Apply templates (with variables) to named device groups.
Easily roll back changes, if needed.
Configuration audits: Check if device configurations are in synch with the NSO database. If they are not, what is the diff?
Synchronize the NSO database and the configurations on devices, in case they are not in synch. This can be done in either direction (import the diff to the NSO database or deploy the diff on devices).

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.

Note

When running NSO against real devices, (not just the NSO network simulator for educational purposes), make sure you have the correct NED package version from the delivery repository.

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.

High-Availability and Clustering

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.