Service Layer API is a model-driven API over Google-defined remote procedure call (gRPC).

gRPC enables you to bring your applications, routing protocols, controllers in a rich set of languages including C++, Python, GO, and many more.

Service Layer API is available out of the box and no extra packages required.

In IOS XR, routing protocols use RIB, the MPLS label manager, BFD, and other modules, to program the forwarding plane. You can expose these protocols through the service layer API.

Benefits

The Service Layer API gives direct access to the Network Infrastructure Layer (Service-Adaptation Layer). Therefore, you have the following advantages:

• High Performance: Direct access to the Network Infrastructure Layer, without going through a Network state database, results in higher performance than equivalent Management APIs.

  For example, Batch updates straight to the Label Switching Data Base (LSDB), the Routing Information Base (RIB) (over gRPC). The LSDB stores label-to-address mappings for efficient traffic routing in Label-switching routers. And, RIB contains the active and potential routes to various network destinations.

• Flexibility: The Service Layer API gives you the flexibility to bring your Protocol or Controller over gRPC.

• Offload low-level tasks to IOS XR: IOS XR infrastructure layer handles the following. Hence, you can focus on higher-layer protocols and controller logic:

  • Conflict resolution

  • Transactional notifications

  • Data plane abstraction

Components of Service Layer API

The following are the components of the Service Layer API architecture:

• Functionality Verticals/Domains: The verticals define the broader capability categories supported by the API. The following are the supported verticals. Each vertical supports data structure and RPCs defined in gpb

  • Initialization: Handles global initialization, sets up an event notification channel using GRPC streaming capabilities.

    The initialization RPCs are mandatory. Use the initialization RPCs to connect a client to the gRPC server on the router. Also, to send heartbeats and termination requests from the server to the client.

  • IPv4, IPv6 Route (RIB): Handles route manipulations (add, update, delete) for a certain VRF.

  • MPLS: Handles allocation of label blocks and any incoming MPLS label mapping to a forwarding function.

  • Interface: Handles subscription of the registered clients to the interface state event notifications.

  • IPv4, IPv6 BFD: Manages BFD sessions, and corresponding BFD session state notifications.

  • Policy-Based Routing (PBR): Manages routing decisions based on user-defined policies rather than the default routing table.

• Protobuf Schema/Model: Use gRPC to model the service layer API.

• gRPC: gRPC utilizes GPB protobuf IDL by default to convert the models into bindings in various languages (c++, python, golang, and more). The gRPC server (running on the router) and the gRPC client use the generated bindings to serialize data and encode or decode the request or response between the server and the client.

• Service Layer gRPC clients: Based on the business needs, the gRPC clients for service layer can exist in one of the following ways:

  • On-box (agents runnning on their own sand-boxed third-party containers)

  • Off-box (within Controllers or other open-source tools)

• gRPC Authentication Modes:

  gRPC supports the following authentication modes to secure communication between clients and servers. These authentication modes help ensure that only authorized entities can access the gRPC services, like gNOI, gRIBI, and P4RT. Upon receiving a gRPC request, the device will authenticate the user and perform various authorization checks to validate the user.

  The following table lists the authentication type and configuration requirements:

  Table 1. Types of Authentication with Configuration

  Type	Authentication Method	Authorization Method	Configuration Requirement	Requirement From Client
  Metadata with TLS	username, password	username	grpc	username, password, and CA
  Metadata without TLS	username, password	username	grpc no-tls	username, password
  Metadata with Mutual TLS	username, password	username	grpc tls-mutual	username, password, client certificate, client key, and CA
  Certificate based Authentication	client certificate's common name field	username from client certificate's common name field	grpc tls-mutual and grpc certificate authentication	client certificate, client key, and CA

Bring your controller

To bring your controller on IOS XR, first, enable the service layer on the router and then write your Service Layer Client API.

1. Enable Service Layer

2. Write Your Service Layer Client API.

Secure TPM Enrollment and Attestation Workflow for Network Devices

The EnrollZ and AttestZ gNSI services provide a secure method for verifying the identity and integrity of network devices. The EnrollZ service handles the TPM 2.0 enrollment workflow, involving cryptographic verification of the device's TPM-rooted identity and provisioning of attestation and Transport Layer Security (TLS) certificates by the device owner. This ensures that the device is under the control of the owner and not dependent on external vendor Certificate Authorities (CAs) during the attestation process. The AttestZ service manages the TPM 2.0 attestation workflow, confirming the device's integrity throughout the boot process by comparing observed Platform Configuration Register (PCR) values against expected ones to verify the device's boot state. This approach simplifies the TPM enrollment process for device owners, enhances control over certificate management, and eliminates external dependencies, while aligning with Trusted Computing Group (TCG) specifications.