NSP system architecture

Overview

The following topics describe the multiple interoperating components that comprise an NSP system.

The core of an NSP system is the NSP cluster, which hosts a central set of shared system resources and controls operator access.

Depending on the management requirements; an NSP system may include additional components that are hosted outside the NSP cluster, see Additional NSP components for information.

NSP cluster

The NSP cluster is the core element of an NSP system and the source of the common NSP resource base, or nspOS. The nspOS enables system-wide functions such as Single Sign-On, or SSO, centralized logging, and operator access to the NSP. The nspOS also includes common services used by other NSP components.

The NSP cluster also hosts the central NSP management functions described below.

Model-driven Mediation (MDM)

MDM provides mediation between model-driven NSP applications and Nokia or third-party network devices. MDM provides an adaptation layer which uses adaptors to convert NSP application requests to device specific directives using standard protocols such as gRPC/gNMI, NETCONF, SNMP and CLI over SSH or Telnet. MDM is an optional component in an NSP deployment and can coexist with NFM-P and WS-NOC .

Workflows

NSP's workflows function allows for the creation and execution of workflows. A workflow consists of a sequence of tasks to create an automated procedure. A workflow can be executed on demand, scheduled, or triggered to run in response to a Kafka event notification. Some workflow examples include node software upgrades, service activation tests, service fulfillment with pre- and post-deployment workflows, and mass migration of services from one tunnel to another.

Note: The maximum number of tasks that can be executed concurrently across all workflows is 64.

Baseline Analytics

Baseline Analytics monitors network traffic to establish baselines and flag anomalous traffic patterns. Traffic patterns can be saved for analysis and comparison, and for automated corrective action by other NSP applications.

Path control

NSP's path control function is based on a Path Computation Element (PCE) architecture that integrates standard protocols such as PCEP to open up path computation to external control. This allows PCCs to be enhanced with various path optimization algorithms that ensure optimal path placement across the network. NSP's path control implementation is stateful in nature and will maintain an up-to-date Traffic Engineering Database (TED), as well as the current RSVP-based label switched paths (LSP) and the segment routing path (SRP) state. It tracks RSVP BW and manages BW for the Segment-Routed TE paths as a unified state.

An NSP deployment for path control requires the VSR-NRC; see Additional NSP components for information about the VSR-NRC..

Service management

NSP's service management function allows for service provisioning and activation across networks accessible to the NSP. Through the GUI, or through the northbound interface (RESTConf), NSP enables users to make service requests that deploy services to the network using the NSP’s mediation framework.

A library exists with a predefined set of service models (such as L3 VPN, EVPN, C-Line, E-LAN, E-TREE, E-Line and IES services) for both classic and model-mode SROS networks. These service models can be installed and utilized by the built-in, intent-based engine (NSP’s Network Intents views) to provide assurance that service configuration is as planned/requested, and also easy adaptability for custom service model requests. New service models to support custom needs can also be developed with aid of the NSP’s automation practice team — or, if your deployment includes the NSP’s programmability suite, self-development.

IP/optical coordination

NSP's IP/optical coordination function optimizes network resources across different layers in IP/MPLS and optical networks. NSP discovers the entire transport topology, including the cross-layer links between IP routers and optical switches.

Additional NSP components

An NSP system may also include one or more of the components described below, depending on the NSP functions or applications that you need to enable. Each component supports deployment in redundant, geographically separate data centers.

Path simulation

NSP's path simulation function is a traffic-engineering function that network engineers can use for network design or optimization. You can simulate failures in an existing network that you import to the tool from the NSP PCE.

Virtual Service Router - Network Resource Controller (VSR-NRC)

The VSR-NRC is required in order for NSP PCE to interface with IP NEs for PCE-PCEP communication and network topology discovery via IGP or BGP-LS. The VSR-NRC is a virtual network function of the VSR that uses the same software image as the VSR-I of the same SROS release number; the VSR-NRC license enables the PCE related features and additional interaction with the NSP. The VSR-NRC software is supported in a Linux KVM environment, or on VMware ESXi versions 6.5, 6.7, and 7.0.

The vSIM based deployment of the VSR-NRC is deprecated in NSP Release 23.4. The VSR-NRC is now based on a VSR-I deployment. Instructions for migrating from the older vSIM to the new VSR-I deployment can be found in SR OS 23.3.R1 Release Notes. For installation instructions, see the VSR Installation and Setup Guide.

Network Functions Manager - Packet (NFM-P)

The NFM-P, an evolution of the former 5620 SAM product, provides IP/MPLS and mobile network management using GUI, web, and OSS interfaces. See NFM-P architecture for more information.

Auxiliary database

An auxiliary database provides scalable, high-throughput storage capacity for specific data collection functions. An auxiliary database can be deployed on one station, or distributed in a cluster of at least three member nodes.

Note: BIOS CPU frequency scaling must be disabled on the NFM-P auxiliary database platform.

NSP Flow Collectors and Flow Collector Controllers

An NSP Flow Collector collects application assurance (AA) Cflowd data and system Cflowd data from managed NEs using protocols such as IPFIX, Netflow, and CGNAT. The collected flow data is stored in an NSP database, or forwarded to a remote server.

An NSP Flow Collector Controller extracts the network data from the NFM-P in order to assign NEs to the associated NSP Flow Collectors. Only one NSP Flow Collector Controller is active at any time, but multiple Flow Collectors may be active..

NSP analytics servers

An NSP analytics server generates predefined and custom analytics reports in graphical or tabular format. The reports are viewable from the NSP Analytics application.

WaveSuite Network Operations Center (WS-NOC )

The WS-NOC is an evolution of the former 1350 OMS product that provides end-to-end optical network management and operational support for all Nokia optical NEs.

NFM-P architecture

The NFM-P system architecture consists of the following components at a minimum:

Note: The NFM-P main server and main database support collocated installation on one station, in addition to distributed installation on separate stations.

Note: IPv6 connectivity is supported between NFM-P components, with the following exceptions:

Note: An NE can be managed by only one NFM-P system; multiple NFM-P systems managing the same NE is not supported, and can cause unexpected behavior.

Additional NFM-P components

The NFM-P can optionally include the following: