Introduction

Cisco Network Service Orchestrator (NSO) version 6.2.8 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.

This chapter describes the various northbound programmatic APIs in NSO NETCONF, REST, and SNMP. These APIs are used by external systems that need to communicate with NSO, such as portals, OSS, or BSS systems.

NSO has two northbound interfaces intended for human usage, the CLI and the WebUI. These interfaces are described in NSO CLI in User Guide and Web User Interface in User Guide respectively.

There are also programmatic Java, Python, and Erlang APIs intended to be used by applications integrated with NSO itself. See the section called “Running Application Code” in Development Guide for more information about these APIs.

Integrating an External System with NSO

There are two APIs to choose from when an external system should communicate with NSO: NETCONF and REST. Which one to choose is mostly a subjective matter. REST may at first sight appear to be simpler to use, but is not as feature-rich as NETCONF. By using a NETCONF client library such as the open source Java library JNC or Python library ncclient, the integration task is significantly reduced.

Both NETCONF and REST provide functions for manipulating the configuration (including creating services) and reading operational state from NSO. NETCONF provides more powerful filtering functions than REST.

NETCONF and SNMP can be used to receive alarms as notifications from NSO. NETCONF provides a reliable mechanism to receive notifications over SSH, whereas SNMP notifications are sent over UDP.

Regardless of the protocol you choose for integration, please keep in mind all of them communicate with the NSO server over network sockets, which may be unreliable. Additionally, write transactions in NSO can fail if they conflict with another, concurrent transaction. As a best practice, the client implementation should be able to gracefully handle such errors and be prepared to retry requests. For details on the NSO concurrency, please refer to NSO Concurrency Model in Development Guide.