2.2.1. Modular network applications

As a Linux-based NOS, SR Linux uses modular applications that are isolated into their own failure domains. A central application manager is responsible for the lifecycle of each application and provides full control of the protocols running on the system.

On SR Linux, each protocol (BGP, IS-IS, and so on) runs as its own application. These applications may be configured using external APIs, including CLI, gNMI, and JSON-RPC. The applications run like any others do in Linux. As well, users can integrate their own applications into SR Linux.

SR Linux uses an unmodified Linux kernel as its foundation to build a suite of network applications. This provides benefits such as reliability, portability, and ease of application development. Using an unmodified kernel also speeds the availability of non-Nokia applications (for example OpenSSH) and security patches for operating system components.

2.2.2. Model-driven architecture

SR Linux makes extensive use of structured data models. Each application has a YANG model that drives its configuration and state. SR Linux exposes the YANG models to the supported management APIs. For example, the command tree in the CLI is derived from the SR Linux YANG models loaded into the system, and a gNMI client can use set RPCs to configure an application based on its YANG model. When a configuration is committed, the SR Linux management server validates the YANG models and translates them into protocol buffers for the impart database (IDB).

Figure 2:  SR Linux infrastructure 

See the SR Linux architecture overview chapter for details about the relationship between IDB and SR Linux components).

2.2.3. IDB publish/subscribe model for messaging

IDB is a lightweight database that controls messaging between SR Linux applications, using a publish/subscribe (pub/sub) model. To do this, the IDB database is split up into topics. Each application owns a set of topics, to which it publishes information, and can subscribe to topics published by other applications. Applications subscribe to topics when they open a session to the IDB, and publish messages to their own topics for other applications to consume.

2.2.4. Protocol buffers and gRPC for inter-process communication

IDB stores data as protocol buffers (protobufs). Protobufs are a language-neutral, platform-neutral mechanism for serializing structured data. Each protocol buffer message is a small logical record of information, containing a series of name-value pairs.

SR Linux uses gRPC for inter-process communication. gRPC is a client application that can directly calls methods on a server application on a different machine as if it was a local object. The supported external APIs (CLI, gNMI, and JSON-RPC) communicate with the SR Linux and retrieve state information using gRPC.

SR Linux applications share state details with each other using the pub/sub model (see Figure 2).

2.2.5. Third-party application support

Third-party applications can be fully integrated into the SR Linux with the same functionality as Nokia applications. This includes configuration using YANG, telemetry support, and life-cycle management. Because third-party applications are not managed independently, it allows a reduction in operational overhead.

2.2.6. CLI plugins

The SR Linux CLI is itself an application that can load dynamic plugins from other applications. You can develop custom show commands and run them from the SR Linux CLI. The CLI plugins allow for integration with remote systems, supporting retrieval of state information.

2.2.7. Hardware extensibility

SR Linux supports a variety of network chipsets through the Nokia eXtensible Data Path (XDP). XDP serves as a hardware abstraction layer that facilitates adoption of new or different network chipsets. It provides a common set of software instructions that northbound applications use so they are not directly dependent on ASIC vendor SDKs. XDP borrows from the development experience for high-performance VNFs and makes use of user space acceleration for traffic destined to the control plane and any non-ASIC interfaces.

2.2.8. Software extensibility

Every SR Linux application, including third-party applications, supports its own YANG model, which can be loaded into the system. Operators can see and define the syntax and semantics of their application in a simple and standardized form. With this design, the YANG data model is defined first, and then the CLI, APIs, and show output formats are derived from it.

SR Linux handles management and operations using the gRPC Network Management Interface (gNMI). Because SR Linux is natively model-driven, it can stream telemetry without requiring any translation layers. Telemetry is supported using POLL, ON_CHANGE and ONCE streaming.

Third-party applications have access to the full streaming telemetry framework. This allows these applications to operate and be monitored, configured, and debugged the same as any other application on the system (see Figure 3).

In addition to the gNMI interface, SR Linux includes a CLI and a JSON-RPC API for management. The CLI provides a framework for accessing the system’s underlying data models. The JSON-RPC API interface supports requests against the data models, as well as allowing a programmable interface access to the extensible plugin framework in the CLI.

Figure 3:  SR Linux software extensibility