Cisco Routed Optical Networking Solution Guide, Release 4.0

IOS-XR software components

Updated: May 5, 2026

Want to summarize with AI?

On this page

Overview

Features of NETCONF protocol

Types and functions of YANG data models in Routed Optical Networking

Types of YANG models
Functions of YANG models in Routed Optical Networking

DCO configuration using OIF CMIS AppSel code

AppSel applicability
Displaying AppSel information in IOS-XR using CLI
CLI AppSel configuration In IOS-XR
OpenConfig AppSel configuration

Features of model-driven telemetry

Capabilities of gNMI

Overview

This section provides details about the IOS XR software capabilities used in Routed Optical Networking. It introduces programmable interfaces and telemetry mechanisms that help automate configuration, retrieve operational data, and monitor router and optic behavior.

Cisco IOS XR is a modern and flexible network operating system. IOS XR improves operational efficiency by integrating management APIs. This integration enables automated configuration and delivers actionable telemetry data in near real time.

The features utilized to help ensure modern standards-based management of Routed Optical Networking are:

YANG-modeled management layer APIs: Automate device provisioning and management using both native IOS XR and OpenConfig models.
Streaming telemetry capabilities: Provide cadence-based or event-driven monitoring of network data derived from YANG-modeled paths in the manageability layer over gRPC, TCP, or UDP.
Configuration of Digital Coherent Optics using CMIS Application Selection Code: Enables configuration of Digital Coherent Optics using CMIS Application Selection Code.

Features of NETCONF protocol

Network Configuration (NETCONF) is a standards-based and XML-encoded protocol. NETCONF provides a transport mechanism to send YANG-formatted configuration or operational data requests from an application running on a centralized management platform to a Cisco device. You can use NETCONF to send requests for configuration or operational data retrieval.

NETCONF provides transaction-based services. For example, if part of a configuration request fails, the entire request is aborted.

NETCONF uses a simple Remote Procedure Call based mechanism to enable communication between clients, such as centralized management platform scripts or applications, and servers, such as Cisco switches or routers. NETCONF uses SSH as the transport layer for communication between network devices.

Types and functions of YANG data models in Routed Optical Networking

Data models provide an alternate centralized way to configure devices instead of using the CLI or SNMP and to collect operational data from Cisco devices. Because the data models are standards-based, you can use the same procedures to configure or collect data from non-Cisco devices. This ability makes them ideal for customers that support multiple vendors. You can use a centralized management platform to configure or collect data from multiple Cisco devices. The data model architecture allows for automating these procedures.

Yet Another Next Generation (YANG) is a standards-based data modeling language. You can use YANG to create requests for device configuration or operational data. It has a structured, human-readable format similar to a computer program. To create configuration and operational data requests, several applications are available that can run on a centralized management platform.

Types of YANG models

There are two types of YANG models:

Standard (common): YANG data model that applies to all vendors. For example, a request to disable or shut down an Ethernet interface is identical for Cisco and non-Cisco devices.
Device (native, vendor-specific): YANG data model that facilitates configuration or that collects of operational data related to proprietary vendor features.

Functions of YANG models in Routed Optical Networking

This table lists Cisco native models, their Open Config equivalents used in the Routed Optical Networking solution, and their functions.


Unified model	Open Config	Function
Cisco-IOS-XR-platform-oper	openconfig-platform	Retrieve line card information for flex-port mapping
Cisco-IOS-XR-optics-port-mode-cfg	No equivalent	Configure flex port modes
Cisco-IOS-XR-controller-optics-oper	openconfig-platform openconfig-platform-transceiver	Retrieve optics PID information
Cisco-IOS-XR-um-cont-optics-cfg	openconfig-terminal-device openconfig-platform-transceiver	Configure ZR optical parameters
Cisco-IOS-XR-um-if-bundle-cfg	openconfig-if-aggregate	Bundle configuration
Cisco-IOS-XR-um-interface-cfg	openconfig-interfaces	IPv4 and IPv6 interface configuration
Controller-otu-oper	No equivalent	Coherent DSP operation data
Cisco-IOS-XR-um-dac-rate-cfg	No equivalent	DAC rate configuration
Cisco-IOS-XR-um-cont-breakout-cfg	No equivalent	Breakout configuration

Note

The openconfig-terminal-device model configures the logical hierarchy of connections from ingress to egress. For Cisco optical devices, you can use OpenConfig to configure nx100G muxponder or transponder modes, and trunk rate.

Use the openconfig-platform model to configure the physical layer parameters:

Frequency

TX power

Operational-mode (Modulation, FEC, and TX shaping)

See Managing OpenZR+ and OIF ZR transceivers on Cisco routers using OpenConfig for information about managing pluggable digital coherent optics using OpenConfig.

DCO configuration using OIF CMIS AppSel code

Common Management Interface Specification (CMIS) from the Optical Internetworking Forum (OIF) is the management specification for modern transceivers. CMIS covers both traditional gray optics as well as newer Digital Coherent Optics. A transceiver consists of two sides: an electrical host side, which connects by its electrical pins to the port on the router, and an optical media side, which connects to the external fiber

Different optics modes are called Applications in CMIS. The Application is selected using a specific Application Selection code. The Application Selection code table includes two additional codes: the Media ID code and the Host ID code. The Media ID and Host ID codes can use either vendor proprietary or standards-based codes. In most cases the Host ID will always use a standard code defined by SFF (Small Form Factor Pluggable Consortium). The Host ID configures the transceiver properties to the host. The Media ID configures several line side properties. In the current XR CLI these are covered as separate properties, or configured automatically for a specific breakout mode.

AppSel applicability

The DP04QSDD-ULH-A1 optics introduced in XR 25.2.1 and RON 4.0 only support configuration using AppSel. Other DCO such as the QDD-400G-ZRP-S and DP04QSDD-HE0 will support AppSel based configuration in a future release, and should be configured using the existing methods in this release.

Displaying AppSel information in IOS-XR using CLI

The “show controller optics <R/S/I/P> appsel advertised” command displays the AppSel values supported by the optics. This table is for a DP04QSDD-ULH-A1 optic.


RP/0/RP0/CPU0:ron-poc-8201-1#show controllers optics 0/0/0/16 appsel advertised
Tue May 20 13:10:27.650 UTC
------------------------------------------------------------------------------------------------------------------------------------------
  App-ID  |  Host-ID                        |  Media-ID                       |  Standard                 |  Host     |  Power           |
          |                                 |                                 |                           |  Supported|  Consumption(W)  |
------------------------------------------------------------------------------------------------------------------------------------------
  1       |  17    ETH 400GAUI-8 C2M (Annex |  100   OpenROADM FLEXO-4e-DO-QP |  OpenROADM                |  Yes      |  n/a             |
  2       |  15    ETH 200GAUI-4 C2M (Annex |  100   OpenROADM FLEXO-4e-DO-QP |  OpenROADM                |  Yes      |  n/a             |
  3       |  13    ETH 100GAUI-2 C2M (Annex |  100   OpenROADM FLEXO-4e-DO-QP |  OpenROADM                |  Yes      |  n/a             |
  4       |  17    ETH 400GAUI-8 C2M (Annex |  216   ACA FlexO-4e-MPCS098-OS  |  ACA                      |  Yes      |  n/a             |
  5       |  15    ETH 200GAUI-4 C2M (Annex |  216   ACA FlexO-4e-MPCS098-OS  |  ACA                      |  Yes      |  n/a             |
  6       |  13    ETH 100GAUI-2 C2M (Annex |  216   ACA FlexO-4e-MPCS098-OS  |  ACA                      |  Yes      |  n/a             |
  7       |  17    ETH 400GAUI-8 C2M (Annex |  201   ACA FlexO-4e-MPCS087-OS  |  ACA                      |  Yes      |  n/a             |
  8       |  15    ETH 200GAUI-4 C2M (Annex |  201   ACA FlexO-4e-MPCS087-OS  |  ACA                      |  Yes      |  n/a             |
  9       |  13    ETH 100GAUI-2 C2M (Annex |  201   ACA FlexO-4e-MPCS087-OS  |  ACA                      |  Yes      |  n/a             |
  10      |  17    ETH 400GAUI-8 C2M (Annex |  194   ACA FlexO-4e-MPCS075-OS  |  ACA                      |  Yes      |  n/a             |
  11      |  15    ETH 200GAUI-4 C2M (Annex |  194   ACA FlexO-4e-MPCS075-OS  |  ACA                      |  Yes      |  n/a             |
  12      |  13    ETH 100GAUI-2 C2M (Annex |  194   ACA FlexO-4e-MPCS075-OS  |  ACA                      |  Yes      |  n/a             |
  13      |  17    ETH 400GAUI-8 C2M (Annex |  192   ACA FlexO-4e-MPCS066-OS  |  ACA                      |  Yes      |  n/a             |
  14      |  15    ETH 200GAUI-4 C2M (Annex |  192   ACA FlexO-4e-MPCS066-OS  |  ACA                      |  Yes      |  n/a             |
  15      |  13    ETH 100GAUI-2 C2M (Annex |  192   ACA FlexO-4e-MPCS066-OS  |  ACA                      |  Yes      |  n/a             |
  16      |  17    ETH 400GAUI-8 C2M (Annex |  198   ACA OpenZR400-16QAM-OS-E |  ACA                      |  Yes      |  n/a             |
  17      |  15    ETH 200GAUI-4 C2M (Annex |  198   ACA OpenZR400-16QAM-OS-E |  ACA                      |  Yes      |  n/a             |
  18      |  13    ETH 100GAUI-2 C2M (Annex |  198   ACA OpenZR400-16QAM-OS-E |  ACA                      |  Yes      |  n/a             |
  19      |  17    ETH 400GAUI-8 C2M (Annex |  70    OpenZR+ ZR400-OFEC-16QAM |  OpenZR+                  |  Yes      |  n/a             |
  20      |  15    ETH 200GAUI-4 C2M (Annex |  70    OpenZR+ ZR400-OFEC-16QAM |  OpenZR+                  |  Yes      |  n/a             |
  21      |  13    ETH 100GAUI-2 C2M (Annex |  70    OpenZR+ ZR400-OFEC-16QAM |  OpenZR+                  |  Yes      |  n/a             |
  22      |  17    ETH 400GAUI-8 C2M (Annex |  54    OpenZR+ ZR400-OFEC-16QAM |  OpenZR+                  |  Yes      |  n/a             |
  23      |  15    ETH 200GAUI-4 C2M (Annex |  54    OpenZR+ ZR400-OFEC-16QAM |  OpenZR+                  |  Yes      |  n/a             |
  24      |  13    ETH 100GAUI-2 C2M (Annex |  54    OpenZR+ ZR400-OFEC-16QAM |  OpenZR+                  |  Yes      |  n/a             |
  25      |  60    OTN-ITU-T FOIC1.2 (ITU-T |  220   ACA FlexO-4-MPCS101-OS   |  ACA                      |  No       |  n/a             |
  26      |  60    OTN-ITU-T FOIC1.2 (ITU-T |  202   ACA FlexO-4-MPCS087-OS   |  ACA                      |  No       |  n/a             |
  27      |  60    OTN-ITU-T FOIC1.2 (ITU-T |  196   ACA FlexO-4-MPCS079-OS   |  ACA                      |  No       |  n/a             |
  28      |  60    OTN-ITU-T FOIC1.2 (ITU-T |  193   ACA FlexO-4-MPCS069-OS   |  ACA                      |  No       |  n/a             |

The ““show controller optics <R/S/I/P> appsel active” command will display the current AppSel programmed into the transceiver.

RP/0/RP0/CPU0:ron-poc-8201-1#show controllers optics 0/0/0/16 appsel active
Tue May 20 13:12:09.599 UTC

 Instance           :1
 App-ID             :19
 Host-ID            :17  ETH 400GAUI-8 C2M (Annex 120E)
 Media-ID           :70  OpenZR+ ZR400-OFEC-16QAM
 Host Lane Count    :8
 Media Lane Count   :1
 Host Lane Assign   :0x1
 Media Lane Assign  :0x0

CLI AppSel configuration In IOS-XR

controller optics R/S/I/P appsel simple code <1-5000>
controller optics R/S/I/P appsel simple descriptor
media-id <1-5000>, 
host-id <1-5000>

The “simple” mode uses the defined AppSel code to configure the media and line side of the optics for all lanes. The AppSel code used is determined by the user based on the AppSel code values stored within the transceiver firmware.

The “descriptor” mode allows the user to select the appropriate AppSel based on the media and host ID values represented by the AppSel. The appropriate AppSel code will be configured on the transceiver based on the combination of <media-id, host-id>. One reason to use this method of configuration is the media-id and host-id values are standardized, whereas the AppSel code values are not.

The AppSel configuration does not configure the NPU side of the configuration. Changing the NPU configuration is required when using different line rates. Using AppSel to configure the transceiver still requires configuring the NPU using the “breakout” or “hw-module” platform specific commands. In RON 4.0 the only speed supported is 400G, however some platforms with flexible ports may default to 100G, so commands are necessary to configure the NPU in 400G mode.

When configuring optics using automation tools such as Crosswork HCO and the NSO RON Function Pack, they will configure the optics using the “simple” method of configuration.

OpenConfig AppSel configuration

OpenConfig terminal-device models utilize the “operational-mode” value to configure line side optical parameters, similar to the AppSel media ID. In XR 25.2.1 OpenConfig models can be used with AppSel by using an operational-mode of 6xxx where xxx is the AppSel value.

Features of model-driven telemetry

Telemetry is an automated communications process used to collect measurements and other data at remote or inaccessible points and transmit them to receiving equipment for monitoring. Model-Driven Telemetry (MDT) streams YANG-modeled data to a data collector. Model-Driven telemetry enables network devices to continuously stream real-time configuration and operating state information to subscribers.

Applications can subscribe to specific data items using standards-based YANG data models over Network Configuration Protocol (NETCONF), RESTCONF, or gRPC Network Management Interface (gNMI) protocol. You can also create configured subscriptions using CLIs. Devices publish structured data at a defined cadence or when changes occur, based on the subscription criteria and data type. For information about telemetry sensor paths and corresponding data fields, see Troubleshoot provisioning issues on ZR or ZR+ optics.

MDT uses structured data models supported by the networking device. MDT provides critical data that is defined in those data models. Telemetry helps you manage your multivendor network by using a common network management system, standardized processes, and applications. The data collected from the network is standards-based and uniform across vendor implementations.

Capabilities of gNMI

IOS-XR supports configuration management using the gRPC Network Management Interface (gNMI).

gNMI offers these capabilities:

provides high-performance remote procedure calls and functions for managing network devices.
supports Cisco native models and OpenConfig models for configuration.

Need help?

Open a support case

(Requires a Cisco Service Contract)

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.