ACX6160 Universal Metro Router User

Guide

Published
2020-10-19
 ii

Juniper Networks, Inc.

1133 Innovation Way
Sunnyvale, California 94089
USA
408-745-2000
www.juniper.net

Juniper Networks, the Juniper Networks logo, Juniper, and Junos are registered trademarks of Juniper Networks, Inc. in
the United States and other countries. All other trademarks, service marks, registered marks, or registered service marks
are the property of their respective owners.

Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right
to change, modify, transfer, or otherwise revise this publication without notice.

ACX6160 Universal Metro Router User Guide

Copyright © 2020 Juniper Networks, Inc. All rights reserved.

The information in this document is current as of the date on the title page.

YEAR 2000 NOTICE

Juniper Networks hardware and software products are Year 2000 compliant. Junos OS has no known time-related
limitations through the year 2038. However, the NTP application is known to have some difficulty in the year 2036.

END USER LICENSE AGREEMENT

The Juniper Networks product that is the subject of this technical documentation consists of (or is intended for use with)
Juniper Networks software. Use of such software is subject to the terms and conditions of the End User License Agreement
(“EULA”) posted at https://support.juniper.net/support/eula/. By downloading, installing or using such software, you
agree to the terms and conditions of that EULA.
 iii

Table of Contents
About the Documentation | viii

Documentation and Release Notes | viii

Using the Examples in This Manual | viii

Merging a Full Example | ix

Merging a Snippet | ix

Documentation Conventions | x

Documentation Feedback | xiii

Requesting Technical Support | xiii

Self-Help Online Tools and Resources | xiv

Creating a Service Request with JTAC | xiv

1 Introduction
ACX6160 Overview | 16

ACX6160 Overview | 16

Interface Types Supported on Client and Line Ports | 16

Features | 17

Open ROADM Compliance | 18

Pluggable Optical Transceivers | 18

Performance Monitoring | 18

One-Touch Provisioning | 18

Forward Error Correction (FEC) | 19

Managing the ACX6160 | 19

Management Ports | 19

ACX6160 NETCONF Capabilities | 20

NETCONF API | 20

ACX6160 Default Username and Password | 20

Open ROADM YANG Model Support Summary | 20

Open ROADM Compliance Overview | 23

Introduction | 23

Open ROADM MSA Device Model Overview | 24

 iv

Open ROADM YANG Data Model | 25

Open ROADM Device YANG Model Support | 25

2 Management of Transport Services

System Commissioning | 28

Equipment Provisioning | 29

Open ROADM Chassis Information and Device Components | 29

ACX6160 Open ROADM Chassis Information | 30

ACX6160 Shelf Naming | 30

ACX6160 Circuit Packs | 30

ACX6160 Ports | 31

Open ROADM Device Info YANG Model Support | 31

Open ROADM Device Shelves YANG Model Support | 33

Open ROADM Device Circuit-Packs and Ports YANG Model Support | 35

Open ROADM Device Circuit-Pack YANG Model Support | 36

Open ROADM Device Circuit-Pack-Type YANG Model Support | 39

Open ROADM Device Circuit-Pack Port YANG Model Support | 40

Interfaces | 45

Understanding the Hierarchical Relationship Between Ports and Interfaces | 46

Configuring Client Port Interfaces | 47

Configuring Line Port Interfaces | 48

Open ROADM Device Interface YANG Model Support | 48

Open ROADM Device Ethernet Interface YANG Model Support | 50

Open ROADM Device Optical-Channel Interface YANG Model Support | 52

Open ROADM Device OTN ODU Interface YANG Model Support | 52

Open ROADM Device OTN OTU4 Interface YANG Model Support | 54

Connectivity | 56

ACX6160 Client to Line Port Fixed Mappings | 56

Open ROADM Connectivity YANG Model Support | 57

Transponder Information | 59
 v

Maintenance Testing | 61

Supported ACX6160 Loopbacks | 61

Open ROADM Loopback YANG Model Support | 62

PRBS | 62

Alarm Monitoring | 64

Interface Alarms and Notifications | 64

ACX6160 Circuit Pack and Interface Type Alarm Summaries | 65

Open ROADM Alarm YANG Model Support | 70

Performance Monitoring | 71

Performance Monitoring | 72

Open ROADM Performance Monitor YANG Model Support | 78

Open ROADM Historical Performance Monitoring YANG Model Support | 79

Open ROADM Clearing Performance Monitoring Data YANG Model Support | 81

NETCONF Notifications | 83

Notifications | 83

Interleave | 84

Replay | 84

3 System Administration
User Administration | 87

User Account Management | 87

Open ROADM User Account YANG Model Support | 87

File System Operations | 89

Device File Management | 89

SFTP Client | 90

Open ROADM RPC File Transfer YANG Model Support | 90

Open ROADM Show Files YANG Model Support | 91

Open ROADM Delete Files YANG Model Support | 92

Open ROADM File Operation Notifications YANG Model Support | 92

 vi

Software Upgrades | 93

Software Upgrade RPC Functions | 93

Manifest Files | 94

Open ROADM Pending Software YANG Model Support | 95

Open ROADM Software Stage YANG Model Support | 95

Open ROADM Software Activate YANG Model Support | 96

Open ROADM Software Cancel-Validation-Timer YANG Model Support | 97

Open ROADM Software Stage Notification YANG Model Support | 97

Open ROADM Software Activate Notification YANG Model Support | 98

Firmware Upgrades | 99

Firmware Upgrade | 99

Open ROADM Firmware Upgrade for Circuit-Packs YANG Model Support | 99

Database Save and Restore Operations | 100

Database Operations Open ROADM YANG Model Support | 101

Open ROADM Database Backup YANG Model Support | 101

Open ROADM Database Restore YANG Model Support | 102

Open ROADM Database Activate YANG Model Support | 103

Open ROADM Cancel Rollback Timer YANG Model Support | 103

Open ROADM Database Init YANG Model Support | 105

Device Operations | 106

Open ROADM Device Operations YANG Model Support | 106

Open ROADM LED Control YANG Model Support | 107

Open ROADM Tech Support Info YANG Model Support | 108

Open ROADM Create Tech Info Notification YANG Model Support | 109

Open ROADM Set Current Date and Time YANG Model Support | 109

One-Touch Factory Defaults Button | 110

 vii

4 Maintenance Signaling
Maintenance Signaling | 112

Interface Alarm Signalling | 112

SignalFail Signaling on the ACX6160 | 112

SignalFail Signaling on ACX6160 100 Gbps Ethernet Client Interfaces | 112

SignalFail Signaling on ACX6160 OTU4 Client and Line Interfaces | 113

Provisioning Related Signaling on the ACX6160 | 113

Provisioning Related Signaling on 100 Gbps Ethernet Client Interfaces | 113

Provisioning Related Signaling on OTU4 Client Interfaces | 113

Provisioning Related Signaling on OTU4 Line Interfaces | 113

Signal Transparency | 114

 viii

About the Documentation

IN THIS SECTION

Documentation and Release Notes | viii

Using the Examples in This Manual | viii

Documentation Conventions | x

Documentation Feedback | xiii

Requesting Technical Support | xiii

Use this guide to understand and configure the features of the ACX6160.

Documentation and Release Notes

®
To obtain the most current version of all Juniper Networks technical documentation, see the product
documentation page on the Juniper Networks website at https://www.juniper.net/documentation/.

If the information in the latest release notes differs from the information in the documentation, follow the
product Release Notes.

Juniper Networks Books publishes books by Juniper Networks engineers and subject matter experts.
These books go beyond the technical documentation to explore the nuances of network architecture,
deployment, and administration. The current list can be viewed at https://www.juniper.net/books.

Using the Examples in This Manual

If you want to use the examples in this manual, you can use the load merge or the load merge relative
command. These commands cause the software to merge the incoming configuration into the current
candidate configuration. The example does not become active until you commit the candidate configuration.

If the example configuration contains the top level of the hierarchy (or multiple hierarchies), the example
is a full example. In this case, use the load merge command.

If the example configuration does not start at the top level of the hierarchy, the example is a snippet. In
this case, use the load merge relative command. These procedures are described in the following sections.
 ix

Merging a Full Example

To merge a full example, follow these steps:

1. From the HTML or PDF version of the manual, copy a configuration example into a text file, save the
file with a name, and copy the file to a directory on your routing platform.

For example, copy the following configuration to a file and name the file ex-script.conf. Copy the
ex-script.conf file to the /var/tmp directory on your routing platform.

system {
scripts {
commit {
file ex-script.xsl;
}
}
}
interfaces {
fxp0 {
disable;
unit 0 {
family inet {
address 10.0.0.1/24;
}
}
}
}

2. Merge the contents of the file into your routing platform configuration by issuing the load merge
configuration mode command:

[edit]
user@host# load merge /var/tmp/ex-script.conf
load complete

Merging a Snippet

To merge a snippet, follow these steps:

1. From the HTML or PDF version of the manual, copy a configuration snippet into a text file, save the
file with a name, and copy the file to a directory on your routing platform.

For example, copy the following snippet to a file and name the file ex-script-snippet.conf. Copy the
ex-script-snippet.conf file to the /var/tmp directory on your routing platform.
 x

commit {
file ex-script-snippet.xsl; }

2. Move to the hierarchy level that is relevant for this snippet by issuing the following configuration mode
command:

[edit]
user@host# edit system scripts
[edit system scripts]

3. Merge the contents of the file into your routing platform configuration by issuing the load merge
relative configuration mode command:

[edit system scripts]

user@host# load merge relative /var/tmp/ex-script-snippet.conf
load complete

For more information about the load command, see CLI Explorer.

Documentation Conventions

Table 1 on page xi defines notice icons used in this guide.

 xi

Table 1: Notice Icons

Icon Meaning Description

Informational note Indicates important features or instructions.

Caution Indicates a situation that might result in loss of data or hardware

damage.

Warning Alerts you to the risk of personal injury or death.

Laser warning Alerts you to the risk of personal injury from a laser.

Tip Indicates helpful information.

Best practice Alerts you to a recommended use or implementation.

Table 2 on page xi defines the text and syntax conventions used in this guide.

Table 2: Text and Syntax Conventions

Convention Description Examples

Bold text like this Represents text that you type. To enter configuration mode, type
the configure command:

user@host> configure

Fixed-width text like this Represents output that appears on user@host> show chassis alarms
the terminal screen.
No alarms currently active

Italic text like this • Introduces or emphasizes important • A policy term is a named structure
new terms. that defines match conditions and
• Identifies guide names. actions.

• Identifies RFC and Internet draft • Junos OS CLI User Guide

titles. • RFC 1997, BGP Communities
Attribute
 xii

Table 2: Text and Syntax Conventions (continued)

Convention Description Examples

Italic text like this Represents variables (options for Configure the machine’s domain
which you substitute a value) in name:
commands or configuration
[edit]
statements.
root@# set system domain-name
domain-name

Text like this Represents names of configuration • To configure a stub area, include
statements, commands, files, and the stub statement at the [edit
directories; configuration hierarchy protocols ospf area area-id]
levels; or labels on routing platform hierarchy level.
components. • The console port is labeled
CONSOLE.

< > (angle brackets) Encloses optional keywords or stub <default-metric metric>;
variables.

| (pipe symbol) Indicates a choice between the broadcast | multicast

mutually exclusive keywords or
(string1 | string2 | string3)
variables on either side of the symbol.
The set of choices is often enclosed
in parentheses for clarity.

# (pound sign) Indicates a comment specified on the rsvp { # Required for dynamic MPLS
same line as the configuration only
statement to which it applies.

[ ] (square brackets) Encloses a variable for which you can community name members [
substitute one or more values. community-ids ]

Indention and braces ( { } ) Identifies a level in the configuration [edit]

hierarchy. routing-options {
static {
; (semicolon) Identifies a leaf statement at a route default {
configuration hierarchy level. nexthop address;
retain;
}
}
}

GUI Conventions
 xiii

Table 2: Text and Syntax Conventions (continued)

Convention Description Examples

Bold text like this Represents graphical user interface • In the Logical Interfaces box, select
(GUI) items you click or select. All Interfaces.
• To cancel the configuration, click
Cancel.

> (bold right angle bracket) Separates levels in a hierarchy of In the configuration editor hierarchy,
menu selections. select Protocols>Ospf.

Documentation Feedback

We encourage you to provide feedback so that we can improve our documentation. You can use either
of the following methods:

• Online feedback system—Click TechLibrary Feedback, on the lower right of any page on the Juniper
Networks TechLibrary site, and do one of the following:

• Click the thumbs-up icon if the information on the page was helpful to you.

• Click the thumbs-down icon if the information on the page was not helpful to you or if you have
suggestions for improvement, and use the pop-up form to provide feedback.

• E-mail—Send your comments to techpubs-comments@juniper.net. Include the document or topic name,

URL or page number, and software version (if applicable).

Requesting Technical Support

Technical product support is available through the Juniper Networks Technical Assistance Center (JTAC).
If you are a customer with an active Juniper Care or Partner Support Services support contract, or are
 xiv

covered under warranty, and need post-sales technical support, you can access our tools and resources
online or open a case with JTAC.

• JTAC policies—For a complete understanding of our JTAC procedures and policies, review the JTAC User
Guide located at https://www.juniper.net/us/en/local/pdf/resource-guides/7100059-en.pdf.

• Product warranties—For product warranty information, visit https://www.juniper.net/support/warranty/.

• JTAC hours of operation—The JTAC centers have resources available 24 hours a day, 7 days a week,
365 days a year.

Self-Help Online Tools and Resources

For quick and easy problem resolution, Juniper Networks has designed an online self-service portal called
the Customer Support Center (CSC) that provides you with the following features:

• Find CSC offerings: https://www.juniper.net/customers/support/

• Search for known bugs: https://prsearch.juniper.net/

• Find product documentation: https://www.juniper.net/documentation/

• Find solutions and answer questions using our Knowledge Base: https://kb.juniper.net/

• Download the latest versions of software and review release notes:

https://www.juniper.net/customers/csc/software/

• Search technical bulletins for relevant hardware and software notifications:

https://kb.juniper.net/InfoCenter/

• Join and participate in the Juniper Networks Community Forum:

https://www.juniper.net/company/communities/

• Create a service request online: https://myjuniper.juniper.net

To verify service entitlement by product serial number, use our Serial Number Entitlement (SNE) Tool:
https://entitlementsearch.juniper.net/entitlementsearch/

Creating a Service Request with JTAC

You can create a service request with JTAC on the Web or by telephone.

• Visit https://myjuniper.juniper.net.

• Call 1-888-314-JTAC (1-888-314-5822 toll-free in the USA, Canada, and Mexico).

For international or direct-dial options in countries without toll-free numbers, see

https://support.juniper.net/support/requesting-support/.
1CHAPTER

Introduction

ACX6160 Overview | 16

ACX6160 NETCONF Capabilities | 20

Open ROADM YANG Model Support Summary | 20

Open ROADM Compliance Overview | 23

 16

ACX6160 Overview

IN THIS SECTION

ACX6160 Overview | 16

Features | 17

Managing the ACX6160 | 19

This topic provides an overview of the ACX6160 transponder and its features.

ACX6160 Overview

The ACX6160 is an Open ROADM compliant disaggregated, multiport transponder solution that supports
the Client and Line ports described in Table 3 on page 16:

Table 3: ACX6160 Client and Line Ports

Client Ports Line Ports

• 8 Client ports • 4 Line ports

NOTE: This release supports only 4 Client ports.

Interface Types Supported on Client and Line Ports

TIP: It’s important to understand, in Open ROADM, Ports and Interfaces are two distinct entities.

• Ports are the physical ports on the device, in this case, the Client and Line ports on the ACX6160
front panel.

• Interfaces are configured on a supporting physical port (Client and Line). or another supporting
interface.
 17

ACX6160 Ports
The ACX6160 has eight Client ports (labeled 0/0 through 0/7 on the front panel) that support QSFP28
transceivers. These transceivers provide a speed of up to 100 Gbps, through four 25 Gbps channels. By
default, Client ports are configured as 100 Gigabit Ethernet ports.

The ACX6160 has four Line CFP2 ports (labeled 1/0 through 1/3 on the front panel) that support C
form-factor pluggable type 2 transceivers.

ACX6160 Interfaces
The Client and Line ports on the ACX6160 use pluggable optics, enabling you to run various interface
types on the ports. All Client ports use pluggable QSFP28 transceivers that are 100 Gbps. All Line ports
use pluggable CFP2-DCO transceivers that are 100 Gbps and support HGFEC.

Table 4 on page 17 describes the various interfaces available for the ACX6160 Client and Line ports and
the Management port, which is (1000BASE-T).

Table 4: ACX6160 Supported Interface Types

Interfaces Available On Interfaces Available On

Transponder Client Ports Transporter Line Ports On Management Port

100 Gigabit Ethernet interface Optical Channel interface (OCH) Ethernet interface

OTN OTU4 (100 Gbps) interface OTN OTU4 (100 Gbps) interface

OTU4 (100 Gbps) interface OTN ODU4 (100 Gbps) interface

Features

IN THIS SECTION

Open ROADM Compliance | 18

Pluggable Optical Transceivers | 18

Performance Monitoring | 18

One-Touch Provisioning | 18

Forward Error Correction (FEC) | 19

This section describes the features of the ACX6160.

 18

Open ROADM Compliance

The ACX6160 is an Open ROADM Multi-Source Agreement (MSA) compliant device. This means it complies
with the specifications described in the agreement for transponder devices. It is compatible with other
devices that comply to this agreement and with Open ROADM controllers.

The Open ROADM MSA device model is a management model defined by the Open ROADM organization.
Its goal is to provide a common management model to simplify the management of multi-vendor optical
network architectures. It defines optical interoperability requirements for the device hardware
Reconfigurable Optical Add/Drop Multiplexers (ROADM), transponders and pluggable optics) and a
NETCONF API that uses Yet Another Next Generation (YANG)-based data models that abstract the
management, control and provisioning of multi-vendor optical devices.

Pluggable Optical Transceivers

The ACX6160 uses pluggable optics for both the Client and Line ports. The eight Client ports use QSFP28
(100 Gbps) pluggable transceivers and the Line ports use CFP2-DCO (100 Gbps) Coherent DWDM pluggable
transceivers with HGFEC support.

NOTE: Only Juniper Networks branded transceivers are supported on the ports of the ACX6160.
The Juniper Part Number (JPN-SKU).

Performance Monitoring

The ACX6160 includes a rich set of performance monitors that monitor the health of the device and notify
you of any problems. It includes both current and historical performance monitoring and supports the
Open ROADM YANG models for both currentPmlist and historyPmlist.

The ACX6160 supports the performance monitoring capability per the Open ROADM MSA specification
version 2.00, release 2 Device white paper v0.3.

One-Touch Provisioning

The ACX6160 supports one-touch provisioning. All that’s needed to deploy it, is to bring it to the site,
cable the device Ethernet (1000BASE-T) management port to the LAN on which your Open ROADM
controller resides, cable the device power and power it up. The ACX6160 automatically receives a temporary
IP address from your DHCP server, which must also be on same LAN. After the controller recognizes the
ACX6160 as an Open ROADM device, you can assign a permanent IP address and configure the device
using your Open ROADM controller and the Open ROADM YANG data models described in this guide.
 19

Forward Error Correction (FEC)

The ACX6160 supports HGFEC (QPSK-100G) FEC.

NOTE: Configuring the FEC mode is mandatory. You must configure the ACX6160 interface for
the HGFEC (QPSK-100G) FEC mode in order to activate the interface. If you do not configure
it, the corresponding CFP2-DCO module is not activated

Managing the ACX6160

You can manage the ACX6160 through its NETCONF API using an Open ROADM compliant controller
and the Open ROADM YANG data models described in this guide.

As an Open ROADM-compliant device, the configuration and management of the ACX6160 is controlled
through the Open ROADM controller and stored in the controller server infrastructure and not on the
ACX6160 itself.

Management Ports

You manage the ACX6160 through the Ethernet MGMT port on the front panel. Connect this port to the
same LAN that your Open ROADM controller is on.

RELATED DOCUMENTATION

ACX6160 NETCONF Capabilities | 20

Open ROADM Compliance Overview | 23
System Commissioning | 28
 20

ACX6160 NETCONF Capabilities

NETCONF API

Per the Open ROADM requirement, the ACX6160 supports a NETCONF API that allows you to control
and manage the ACX6160 using the NETCONF protocol [RFC 6241] on TCP port 830 through your Open
ROADM controller. To control and manage the ACX6160, your Open ROADM controller uses the NETCONF
API and the Open ROADM YANG data models described in this guide.

ACX6160 Default Username and Password

Per the Open ROADM requirement, the ACX6160 default username and password are:
openroadm/openroadm.

RELATED DOCUMENTATION

ACX6160 Overview | 16
Open ROADM Compliance Overview | 23
System Commissioning | 28

Open ROADM YANG Model Support Summary

The ACX6160 supports YANG model v1 defined in RFC 6020.

Table 5 on page 20 lists the Open ROADM YANG data model support on the ACX6160.

Table 5: Summary of Open ROADM YANG Model Support on ACX6160

Module Description

org-openroadm-alarm Active alarm list and notification

See, “Alarm Monitoring” on page 64

org-openroadm-common-types Common type definitions

 21

Table 5: Summary of Open ROADM YANG Model Support on ACX6160 (continued)

Module Description

org-openroadm-database Database save and restore actions

See, “Database Save and Restore Operations”

on page 100.

org-openroadm-de-operations Device restart actions

See, “Device Operations” on page 106 Root and main structure of the device tree, defines major lists and
containers for entities such as shelves, circuit-packs, slots, ports,
interfaces, users, xponder, and so forth.

org-openroadm-equipment-states-types Equipment states that describe planning, commissioning, and

deployment status of equipment.
“Equipment Provisioning” on page 29and
“System Commissioning” on page 28.

org-openroadm-ethernet-interfaces Ethernet attributes augmented onto interface list

“Interfaces” on page 45

org-openroadm-file-transfer Asynchronous SFTP transfer actions

See, “File System Operations” on page 89

“Interfaces” on page 45 Interface type identities

org-openroadm-maintenance-loopback Maintenance loopback definitions

See, “Maintenance Testing” on page 61

org-openroadm-maintenance-testsignal Maintenance test signal groups and attributes.

See, “Maintenance Testing” on page 61

org-openroadm-maintenance Maintenance list of terminalLoopback, facilityLoopback, testSignal

operations.
See, “Maintenance Testing” on page 61

org-openroadm-network-types Node and link type definitions, supported interfaces capability list.

org-openroadm-optical-channel-interfaces Augments interface with optical channel och container and

attributes.
See, “Interfaces” on page 45

org-openroadm-otn-common-types OTU and ODU rate and type identities and payload type def
 22

Table 5: Summary of Open ROADM YANG Model Support on ACX6160 (continued)

Module Description

org-openroadm-otn-common Trail-trace degree-threshold attributes grouping

org-openroadm-otn-odu-interfaces Augments interface with ODU attributes such as msi, trail-trace,

parent odu allocation, deg-threshold, tcm opu, and so forth.
“Interfaces” on page 45

org-openroadm-otn-otu-interfaces Augments interface with OTU attributes such as trail-trace, fec,

tcm and so forth.
“Interfaces” on page 45

org-openroadm-physical-types Definitions for Physical types

org-openroadm-pluggable-optics-holder-capability Pluggable optics holder capabilities lists supported circuit packs,

port references, port capabilities.

org-openroadm-pm-types Defines PM types and grouping of PM attributes

See, “Performance Monitoring” on page 71

org-openroadm-pm Current and historical PM lists, clear PMs and collect historical file
actions.
See, “Performance Monitoring” on page 71

org-openroadm-port-capability Augments circuit-packs ports with port capabilities, augments device

with port-group-restrictions

org-openroadm-port-types Definitions for port types

org-openroadm-probable-cause Probable cause attributes and grouping

“Alarm Monitoring” on page 64

org-openroadm-resource-types Definitions for resource types

org-openroadm-resource Defines resource-type which is a choice of circuit-pack, port, shelf,

physical-link, xponder, and so forth.

org-openroadm-swdl Software download/installation module

See, “Software Upgrades” on page 93

 23

Table 5: Summary of Open ROADM YANG Model Support on ACX6160 (continued)

Module Description

org-openroadm-syslog System logging module

See, “Device Operations” on page 106 and “File

System Operations” on page 89.

org-openroadm-user-mgmt User account management module

See, “User Administration” on page 87

org-openroadm-xponder Syslog container, attributes, and selector

See, “Transponder Information” on page 59

org-openroadm-wavelength-map Wavelength map

RELATED DOCUMENTATION

Open ROADM Compliance Overview | 23

ACX6160 NETCONF Capabilities | 20
ACX6160 Overview | 16

Open ROADM Compliance Overview

Introduction

Starting with Junos OS 19.2R2-evo, an Open ROADM Multi-Source Agreement (MSA) device model is
added to Junos to support the ACX6160. This capability allows you to control and manage the ACX6160
using an Open ROADM compliant controller.

NOTE: There is no Junos CLI support for the ACX6160 in the Junos OS 19.2R2-evo release. All
control and management of the ACX6160 is through an Open ROADM controller.
 24

The Open ROADM MSA device model is a management model defined by the Open ROADM organization.
Its goal is to provide a common management model to simplify the management of multi-vender optical
network architectures. It defines optical interoperability requirements for the device hardware
(Reconfigurable Optical Add/Drop Multiplexers (ROADM), transponders and pluggable optics) and a
NETCONF API that uses Yet Another Next Generation (YANG)-based data models that abstract the
management, control and provisioning of multi-vendor optical devices.

The interoperability requirements defined by the Open ROADM organization call for the control and
management of the devices in the optical network be extracted from the device hardware and completely
controlled by the Open ROADM controller. A one-touch provisioning process enables you simply cable
and power-up the ACX6160, which then receives a temporary IP address from your DHCP server. After
your controller discovers the ACX6160, you can define a permanent IP address to it and configure it using
the ACX6160 YANG data models are described this guide.

Open ROADM MSA Device Model Overview

The Open ROADM MSA defines a transponder device capable of mapping a single 100 Gbps Ethernet or
OTU4 client signal into a 100 Gbps OTU4 DWDM signal for transport across an Open ROADM
infrastructure. Table 6 on page 24 describes each requirement and how the ACX6160 meets that
requirement.

Table 6: Open ROADM YANG Model Requirements and ACX6160 Capabilities

Open ROADM MSA Requirement ACX6160 Capability

API using a NETCONF interface with a YANG-based data The ACX6160 supports a NETCONF API interface that
model that abstracts the control management and enables you to use an Open ROADM controller to
provisioning of multi-vendor transponder devices control and manage the ACX6160. We describe the
YANG models for the ACX6160 in this guide.

Single-wave (W) interface which defines the optical The four Line ports on the ACX6160 are 100 Gbps/200
specifications for the full C-band tunable DWDM optical line Gbps CFP2-DCO coherent DWDM pluggable
interface of the transponder that connects to a Wr add/drop transceivers using LC connectors
port on the ROADM device. Line-side pluggable type must
NOTE: This release supports only 100 Gbps Line ports.
be CFP-DCO, CFP2-ACO or CFP2-DCO with LC connectors

Client ports must be pluggable QSFP28 with LC connectors The eight 100 Gbps Ethernet Client ports use pluggable
and support 100GBASE-R mapped into OPU4 using PCS QSFP28 transceivers
codeword transparent Ethernet mapping
NOTE: This release supports only four Client ports

For complete details, see the Open ROADM MSA transponder specification at Open ROADM.org.
 25

Open ROADM YANG Data Model

The ACX6160 supports YANG model v1 defined in RFC 6020. Table 7 on page 25 describes the Open
ROADM YANG data model.

Table 7: Open ROADM YANG Data Model

What Example

Database Nodes defined by configuration and operational data and, Shelf commissioning data, wavelength
which you can query using your controller. Some nodes are read/write connections, and so forth.
(configuration node), while others are read-only (operational data).

Notifications for the purposes of reporting autonomous events to Alarms, inventory changes, restarts, and so
the controller. forth.

Remote Procedure Calls (RPC) that do not effect a change in the Get operations, file transfers, database backup,
device configuration data and so forth.

Open ROADM Device YANG Model Support

The Open ROADM device YANG model defines the YANG nodes, described in Table 8 on page 25, to
abstract the implementation of the ROADM and transponder device.

Table 8: Open ROADM Device YANG Data Model Support

YANG node Description

Information Provides general node information including node name, IP address, and so forth

Shelves Provide shelf information. A node can consist of one or more shelves

Circuit Packs Represents a physical piece of equipment which contains a group of hardware
functional blocks such as common equipment, cards, plug-in-units and/or pluggable
optics.

Ports The Ports container defines the ports associated with a circuit pack or pluggable optics
and the associated port attributes

Internal Links Reflect the connectivity within each circuit pack. These YANG nodes are read only
and report attributes of the circuit pack themselves

Physical Links Reflect the connectivity between ports across different circuit packs. The controller
pushes this data to the device and reflects the actual inter-card fibering/cabling
 26

Table 8: Open ROADM Device YANG Data Model Support (continued)

YANG node Description

External Links External link YANG nodes are placeholders for data about the far end device. Data
for these YANG nodes is pushed from the controller

Degrees Define the grouping of circuit packs that form a line degree

Shared Risk Groups Define the grouping of circuit packs that form a colorless/ directionless add/drop bank

Wavelength Map Defines the wavelength channel number and wavelength map

Connection Map Wavelength agnostic and reflects any connectivity restrictions / blocking in the device
(not wavelength contention)

Interfaces Defines supported interface types and are associated with Port YANG nodes

RELATED DOCUMENTATION

ACX6160 Overview | 16
Open ROADM YANG Model Support Summary | 20
System Commissioning | 28
2 CHAPTER

Management of Transport Services

System Commissioning | 28

Equipment Provisioning | 29

Interfaces | 45

Connectivity | 56

Transponder Information | 59

Maintenance Testing | 61

Alarm Monitoring | 64

Performance Monitoring | 71

NETCONF Notifications | 83
 28

System Commissioning

According to the Open ROADM organization, when a ROADM or transponder is powered up, it runs IPv4
and IPv6 DHCP clients and receives an IP address from the DHCP server sitting on the same LAN. The IP
address may be either IPv4 or IPv6 depending on the operator’s DCN configuration. This IP address is
called temporary IP address. When a DHCP server allocates temporary IP address for a device, the controller
is notified about this new IP address allocation. Now, the controller can log in to the device using a temporary
address and define the permanent IP address for the device. The device also allows you to provision the
default gateway, and that the IP address, prefix length and default gateway should be specified in the same
edit configuration operation.

The ACX6160 supports the Open ROADM one-touch discovery procedure.

The Open ROADM organization describes device commissioning steps as:

1. The controller is loaded with the pre-planned device template for the device (node) that is to be
commissioned. The template contains the information to provision the node beyond the auto-provisioning
behavior, including: the final node-id, permanent IP address, shelf/circuit-pack/port attributes, and so
forth. The device planning template is loaded into the Open ROADM controller. The planning template
is not standardized by Open ROADM but provides data to the controller on how to commission the
node using the Open ROADM device model. The planning template is a JSON file containing a subset
of the device model, which you need to configure the Open ROADM device (ACX6160).

2. The Open ROADM controller may then generate inventory information.

3. A field technician installs and powers the equipment.

4. The Open ROADM device initializes, auto-provisions and requests an IP address from your DHCP
server. The DHCP server responds with a temporary IP address.

5. The controller discovers the new IP address assignment by the DHCP server and attempts to connect
and log into the device as an Open ROADM network element (NE). If the device is an Open ROADM
device, then the controller discovers the Open ROADM NE as a temporary NE.

6. The field technician provides the correlation between the controller discovered temporary NE and the
pre-loaded planning template [One Touch] by identifying the node based on its node-id being installed.

7. The controller then pushes device planning template configuration to the node and rediscovers the
node (permanent node). Once the correlation is made, the controller begins to provision the node.

The planning template information is pushed to the node using the NETCONF edit-config RPC with
the merge operation. There may be processing involved in the controller, which takes both the template
and the current state of the device as input and determines the set of operations that need to be
performed on the device. The use of the merge operation allows the provisioning to succeed even if
the entity (for example, shelf, circuit-pack, port) was auto-provisioned due to the idempotent behavior.

To support the Open ROADM discovery and commissioning process:

 29

• The default settings on the ACX6160 are:

• The node-id is: openroadm

• A user account with: username=openroadm and password=openroadm

• DHCP is enabled by default on the management (MGMT) port of the ACX6160

• A reset button on the ACX6160, when pressed, reverts the device back to its default state as described
above. This enables you to easily re-commission an ACX6160 after it has been used.

• The ACX6160 supports a NETCONF edit-config RPC function with the merge operation

• The ACX6160 exhibits idempotent behavior when it processes the edit-config merge RPC

• The ACX6160 supports the Open ROADM restart operation

RELATED DOCUMENTATION

Open ROADM Compliance Overview | 23

Open ROADM YANG Model Support Summary | 20
Interfaces | 45

Equipment Provisioning

Open ROADM Chassis Information and Device Components

Open ROADM organizes device components in a hierarchical structure starting with the top level info
container:

• Info

• Shelves — Each shelf has one or more slots that contain hardware components called circuit-packs.

• circuit-packs — Provide slots for other circuit-packs to plug into, creating a hierarchy of components.

• ports

• port containers

It’s important to understand this hierarchical structure because you’ll need to follow this hierarchical
structure when you configure the your transponding circuits on the ACX6160.
 30

ACX6160 Open ROADM Chassis Information

The info container provides top level device information representing the ACX6160 node itself. This
information includes the node name, ip-address, default-gateway that identifies and describes a specific
ACX6160 chassis.

ACX6160 Shelf Naming

The ACX6160 is a simple 1 RU platform, so there is only a single shelf for the ACX6160: shelf-0 as described
in. Table 9 on page 30.

Table 9: ACX6160 Shelf Naming Convention

Name Description QTY Meta-Tree Name

shelf-0 ACX6160 1 Chassis

ACX6160 Circuit Packs

The ACX6160 consists of a single shelf (shelf-0). The shelf is populated with the hardwired components
that, collectively make up the ACX6160 circuit-packs.

The ACX6160 supports one shelf with seven slots and several circuit-packs. The circuit-packs are made
up of Flexible PIC Concentrator (FPC), Physical Interface Card (PIC)s, transceivers, power supply units
(PSU), and fan tray units (FTU) components. Many of the circuit-pack components are hardwired in the
ACX6160 chassis and are not assigned Model and Serial numbers. In the ACX6160 Open ROADM device
model these circuit-packs simply inherit the Model and Serial number from the ACX6160 chassis.

Table 10 on page 30 describes the ACX6160 circuit-pack naming convention.

Table 10: ACX6160 Circuit-Pack Naming Convention

Name Description Quantity Meta-Tree Name

fpc-0 FPC 1 FPC0

(Hardwired)

pic-0/[0-1] PIC 2 FPC0:PIC[0-1]

(Hardwired)
 31

Table 10: ACX6160 Circuit-Pack Naming Convention (continued)

Name Description Quantity Meta-Tree Name

xcvr-0/0/[0-7] Eight Client ports 8 FPC0:PIC0:PORT[0-7]

pluggable QSFP28
transceiver on PIC-0/0

xcvr-0/1/[0-3] Four Line port pluggable 4 FPC0:PIC1:PORT[0-3]

CFP2-DCO transceiver on
PIC-0/1

psu-[0-1] Power Supply Unit 2 Power Supply[0-1]

ftu-[0-4] Fan Tray Unit (Hardwired) 5 Fan Tray

ACX6160 Ports

Table 11 on page 31 describes the ACX6160 port naming conventions.

Table 11: ACX6160 Port Naming Conventions

Name Description Meta-Tree Name

qsfp28-port QSFP28 transceiver port qsfp28-port

cfp2dco-port CFP2DCO transceiver port cfp2dco-port

Open ROADM Device Info YANG Model Support

The info container provides top level device information representing the ACX6160 node itself. This
information includes the node name, ip-address, default-gateway that identifies and describes a specific
ACX6160 chassis.

Table 12 on page 32 describes YANG nodes in the info container. The columns in Table 12 on page 32
are defined as:

• YANG node — The node from the Open ROADM YANG model.

• Access — Access properties of the node. Can be:

 32

• rw — read/write

• ro — read-only

• w — write-only

• x — RPC function

• n — notification

• Supported — Indicates ACX6160 support for the node.

• Yes — ACX6160 supports the node

• No — ACX6160 does not support the node

• N/A — Node is not applicable to transponder device

• Supported Values — Describes the range of supported values on ACX6160.

Table 12 on page 32 describes ACX6160 compliance with the content of the Open ROADM info YANG
model. The location within the Open ROADM YANG model of the nodes listed in the table is
/org-openroadm-device/info.

Table 12: Open ROADM Device Info YANG Model Support

YANG Node Access Supported Supported Values

node-id rw yes Value assigned by customer.

node-number rw yes User-specified

node-type rw yes Set to: xpdr

clli rw yes Common Language Location Identifier

vendor ro yes Hard coded value

model ro yes Return chassis model number

serial-id ro yes Return chassis serial number

ipAddress rw yes Management port IP address

prefix-length rw yes Management port subnet length

defaultGateway rw yes Management network default gateway

source ro yes How management IP was set by either: static or

dhcp
 33

Table 12: Open ROADM Device Info YANG Model Support (continued)

YANG Node Access Supported Supported Values

current-ipAddress ro yes Management port IP address

current-prefix-length ro yes Management port subnet length

current-defaultGateway ro yes Management network default gateway

macAddress ro yes Management port MAC address

softwareVersion ro yes JUNOS software version

openroadm-version ro yes Version for Open ROADM package

template rw yes JSON filename that contains the template

current-datetime ro yes Current timestamp

geoLocation rw yes Container

- latitude rw yes User-specified

- longitude rw yes User-specified

max-degrees ro yes Not supported

max-srgs ro yes Not supported

max-num-bin-15min-historical-pm ro yes Hard coded value

max-num-bin-24hour-historical-pm ro yes Hard coded value

Open ROADM Device Shelves YANG Model Support

The Open ROADM model describes a device as having one or more shelves. To satisfy the Open ROADM
model, the ACX6160 creates an abstraction of a single shelf called: shelf-0. The shelf slots are populated
with top level entities such as FPC, PIC, XCVR, PSU, FTU that make up the ACX6160. All of the top level
entities are hardwired into the chassis and are assigned a fixed slot position within the shelf. In the Open
ROADM model, these entities are called circuit-packs.
 34

Table 13 on page 34 describes ACX6160 compliance with the content of the Open ROADM shelves YANG
model. The location within the Open ROADM YANG model of the nodes listed in the table is
/org-openroadm-device/info/shelves.

Table 13: Open ROADM Device Shelves YANG Model Support

YANG Node Access Supported Supported Values

shelf-name rw yes Set to: shelf-0

shelf-type rw yes Set to: SHELF

Rack rw yes User-specified

shelf-position rw yes Set to: 0

Administrative-state rw yes Set to:

• inService
• outOfService
• maintenance

NOTE: For ACX6160 ports to operate, the

Administrative-state and the Operational-state must
both = inService

vendor ro yes Set to: Juniper Networks

model ro yes Return chassis model number ACX6160

serial-id ro yes Chassis serial-id

type ro yes Hard coded to: SHELF

product-code ro yes

manufacture-date ro yes Chassis manufacture date

clei ro yes

hardware-version ro yes Chassis hardware version

 35

Table 13: Open ROADM Device Shelves YANG Model Support (continued)

YANG Node Access Supported Supported Values

operational-state ro yes Return:

• inService – when administrativeStatus = inService

• outOfService – when administrativeStatus =
outOfService or maintenance
• degraded – when faults are present

equipment-state rw yes User-specified

due-date rw yes User-specified

slots ro yes list

- slot-name ro yes String value of position: 0 through 7

- label ro yes Face plate label or "" if not no faceplate

- provisioned-circuit-pack ro yes Reference to circuit-pack provisioned in this slot or

unset.

- slot-status ro yes Return:

• installed-not-prov
• installed-prov-match
• installed-prov-mismatch

Open ROADM Device Circuit-Packs and Ports YANG Model Support

The Open ROADM models FRUs and hard-wired components of a chassis as circuit-packs. A circuit-pack
can have an arbitrary number of slots called cp-slots. Circuit-packs provide a hierarchical organization of
hardware components. Each circuit-pack is either contained within a shelf slot or within a circuit-pack slot.
When a circuit-pack’s type is an XCVR it has a port and in this case the port container should be included
in the configuration. Circuit packs are analogous to the OpenConfig components list.
 36

Open ROADM Device Circuit-Pack YANG Model Support

Table 14 on page 36 describes ACX6160 compliance with the content of the Open ROADM circuit-pack
YANG model. The location within the Open ROADM YANG model of the nodes listed in the table is
/org-openroadm-device/circuit-pack.

Table 14: Open ROADM Device Circuit-Pack YANG Model Support

YANG Node Access Supported Supported Values

circuit-pack-name rw yes Name of circuit-pack, must be name from

vendor list of components

administrative-state rw yes User-specified administrative state. Set to:

• inService
• outOfService
• maintenance

vendor ro yes Return "Juniper Networks" for built-in

components, vendor from FRU if pluggable.

model ro yes Component model

serial-id ro yes Component serial-id

type ro yes Hard coded to FPC, PIC, XCVR, ETC.

product-code ro yes

manufacture-date ro yes Component manufacture date

clei ro yes

hardware-version ro yes Component’s hardware version

operational-state ro yes Return:

• inService – when administrativeStatus =

inService and up
• outOfService – when administrativeStatus
= outOfService or maintenance or down
• degraded – when administrativeStatus =
inService and up and faults are present

circuit-pack-category ro yes Enum

 37

Table 14: Open ROADM Device Circuit-Pack YANG Model Support (continued)

YANG Node Access Supported Supported Values

- type ro yes Derive from components part-number

- extension ro yes

equipment-state rw yes User-specified

circuit-pack-mode rw yes

shelf rw yes Reference to shelf-0

slot rw yes Shelf slot

subSlot rw yes Slot of parent circuit-pack

is-pluggable-optics rw yes True for transceivers, otherwise false

due-date rw yes User-specified

parent-circuit-pack rw yes Container

- circuit-pack-name rw yes Parent circuit pack name

- cp-slot-name rw yes Slot position in parent circuit-pack

cp-slots[slot-name] ro yes List

- slot-name ro yes String value of position: 0 through 7

- label ro yes Face plate label or "" if not no faceplate

- provisioned-circuit-pack ro yes Reference to circuit-pack provisioned in this

slot or unset.

- slot-status ro yes Return:

• empty-not-prov
• empty-prov-match
• empty-prov-mismatch
• installed-not-prov
• installed-prov-match
• installed-prov-mismatch
 38

Table 14: Open ROADM Device Circuit-Pack YANG Model Support (continued)

YANG Node Access Supported Supported Values

- slot-type ro yes Return:

• pluggable-optics-holder
• other

software-load-version ro yes String: software version running on the

circuit-pack. Return the JUNOS image
version.

circuit-pack-features ro n/a This list is empty.

ACX6160 circuit packs provide a single

transponding feature.

- feature ro n/a Container:

- - description ro n/a String:

- - activated ro n/a Boolean:

circuit-pack-components ro n/a This list is empty.

- component ro n/a Container

- - name ro Name of component on the circuit-pack.

- - current-version ro n/a String: current version

- - version-to-apply ro n/a String: target version. Version that is activated

after a cold boot

ports rw yes list, see ports list

circuit-pack-type rw yes Mandatory string: Type of circuit-pack such

as FPC, FTU, PSU, PIC, XCVR.

circuit-pack-product-code rw yes Product-code

 39

Open ROADM Device Circuit-Pack-Type YANG Model Support

Table 15 on page 39 describes ACX6160 compliance with the content of the Open ROADM circuit-pack
type YANG model. The location within the Open ROADM YANG model of the nodes listed in the table is:
org-openroadm-device/circuit-packs[circuit-pack-name]/slots/
pluggable-optics-holder-capability/supported-circuit-pack-types[supported-circuit-pack-type].

Table 15: Open ROADM Device Circuit-Pack-Type YANG Model Support

YANG Node Access Supported Supported Values

supported-circuit-pack-type ro yes Return "QSFP28" or "CFP2DCO"

ports* [port-name] ro yes List

- port-name ro yes Return "port-0/<PIC>/<XCVR>"

- port-capabilities ro yes Container

- supported-interface-capability ro yes List

- if-cap-type ro yes Return:

• CLIENT: , ,
• if-100GE
• if-OTU4-ODU4
• LINE:
• if-OCH-OTU4-ODU4

- otn-capability ro yes Container

- - if-protection-capability ro n/a odu-one-plus-one – only

identity-ref

- - - proactive-DMp ro yes Boolean ODU PM delay

measurement (DMp) (G.709
06-2016 15.8.2.1.6), hard code
to false

- tcm-capable ro yes false

- mpdr-client-restriction ro n/a Container

 40

Table 15: Open ROADM Device Circuit-Pack-Type YANG Model Support (continued)

YANG Node Access Supported Supported Values

- network-ho-odu-circuit-pack-name ro n/a Circuit-Pack identifier. Unique

within the context of a device.

- - network-ho-odu-port-name ro n/a port identifier.

- odtu-type ro n/a ODTU type, part of the MSI

(Multiplex Structure Identifier)

- network-ho-odu-trib-port-number ro n/a Tributary port number

- network-ho-odu-trib-slots ro n/a Not supported

- odu-mux-hierarchy ro n/a Not supported

- mux-capability ro n/a Not supported

Open ROADM Device Circuit-Pack Port YANG Model Support

Table 16 on page 41 describes ACX6160 compliance with the content of the Open ROADM circuit-pack
port name. The location within the Open ROADM YANG model of the nodes listed in the table is:
org-openroadm-device/circuit-packs[circuit-pack-name]/ports[port-name].
 41

Table 16: Open ROADM Device Circuit-Pack Port YANG Model Support

YANG Node Access Supported Supported Values

port-name rw yes Key string: name of port.

Example Client ports:

port-0/0/0, port-0/0/2, … port-0/0/7

Example Line ports:

port-0/1/0, port-0/1/1, port-0/1/2, and

port-0/1/3

NOTE: In this release, the ACX6160

supports Client ports on:

• 0/0
• 0/2
• 0/4
• 0/6
Clients ports 0/1, 0/3, 0/5, and 0/7 are
not used in this release.

port-type rw yes Set to: QSFP28, CFP2DCO

port-qual rw yes Indicates if port is Line or Client. Used in

When statement to select
transponder-port container.

• For Line port, set to: xpdr-network

• For a Client port, set to: xpdr-client

port-wavelength-type ro yes Type of wavelength.

Set to: "wavelength" or

"multi-wavelength" always "wavelength".

port-direction ro yes Set to:

• tx
• rx
• bidirectional
• notApplicable
Return hard coded value "bidirectional".
 42

Table 16: Open ROADM Device Circuit-Pack Port YANG Model Support (continued)

YANG Node Access Supported Supported Values

label ro yes Faceplate label example "0/1"

circuit-id rw yes User-specified, you can use for alarm

correlation and/or connection
management.

administrative-state rw yes User set administrative state:

• inService
• outOfService
• maintenance

operational-state ro yes Return:

• inService – when administrativeStatus

= inService and up
• outOfService – when
administrativeStatus = outOfService or
maintenance or down
• degraded – when administrativeStatus
= inService and up status, and faults are
present

supported-interface-capability ro yes Leaf-list identity ref: if-100GE, if-OCH,

if-100GE-ODU4, etc.

logical-connection-point rw String: The controller sets this value to

the following format:

Line port:

XPDR<n>-NETWORK<m>

Client port:

XPDR<n>N-xpdrETWORK<m>

Where:

n is set to xpdr-number, key into xponder

list

partner-port ro Not applicable for bidirectional port.

 43

Table 16: Open ROADM Device Circuit-Pack Port YANG Model Support (continued)

YANG Node Access Supported Supported Values

- circuit-pack-name ro n/a Not applicable for bidirectional port.

Reference to transceiver circuit pack

hosting the partner-port.

- port-name ro n/a Not applicable for bidirectional port.

Reference to the port-name of the

partner-port

parent-port ro n/a Not applicable, ACX6160 does not have

nested ports.

- circuit-pack-name ro n/a Not applicable.

- port-name ro n/a Not applicable.

interfaces ro yes List of supported interface names

- interface-name ro yes

transponder-port rw yes Container describing port attributes on a

transponder device.

- port-power-capability-min-rx ro yes Hard coded value based on the type of

port-type

- port-power-capability-min-tx ro yes Hard coded value based on the type of

port-type

- port-power-capability-max-rx ro yes Hard coded value based on the type of

port-type

- port-power-capability-max-tx ro yes Hard code value based on the type of

port-type

otdr-port rw n/a Container Otdr is not supported. Excluded

by when statement

- launch-cable-length rw n/a Excluded with otdr-port

- port-direction rw n/a Excluded with otdr-port

 44

Table 16: Open ROADM Device Circuit-Pack Port YANG Model Support (continued)

YANG Node Access Supported Supported Values

port-capabilities ro yes container

- supported-interface-capability ro yes list

-- if-cap-type ro yes Return

CLIENT: if-100GE, if-OTU4-ODU4,

LINE: if-OCH-OTU4-ODU4

-- otn-capability ro yes Container

--- if-protection-capability ro no Leaf list: odu-one-plus-one – only

identity-ref

--- proactive-DMp ro yes Boolean ODU PM delay measurement

(DMp) (G.709 06-2016 15.8.2.1.6), hard
coded to false

--- tcm-capable ro yes false

TCM – Tandom Connection Monitoring

--- proactive-DMt ro yes Boolean

--- tcm-direction-capability ro n/a Enum "up-tcm", "down-tcm",

"up-down-tcm"

--- opu-payload-type-mapping ro n/a Description "OPU payload-type mapping

OPU."

Length 2 pattern "[0-9a-fA-F]*"

--- mpdr-client-restriction ro n/a Container Analysis "N/A – Capabilities

that apply only to ports that support OTN
multiplexing."

---- network-ho-odu-circuit-pack-name ro n/a Mandatory leafref:

---- network-ho-odu-port-name ro n/a Mandatory leafref:

---- odtu-type ro odtu-type-identity

 45

Table 16: Open ROADM Device Circuit-Pack Port YANG Model Support (continued)

YANG Node Access Supported Supported Values

---- network-ho-odu-trib-port-number ro n/a uint16

---- network-ho-odu-trib-slots ro n/a uint16

--- odu-mux-hierarchy ro yes Container

Not supported

RELATED DOCUMENTATION

Open ROADM Compliance Overview | 23

Interfaces | 45
Connectivity | 56

Interfaces

IN THIS SECTION

Understanding the Hierarchical Relationship Between Ports and Interfaces | 46

Configuring Client Port Interfaces | 47

Configuring Line Port Interfaces | 48

Open ROADM Device Interface YANG Model Support | 48

Open ROADM Device Ethernet Interface YANG Model Support | 50

Open ROADM Device Optical-Channel Interface YANG Model Support | 52

Open ROADM Device OTN ODU Interface YANG Model Support | 52

Open ROADM Device OTN OTU4 Interface YANG Model Support | 54

This section describes how to configure Client and Line port interfaces on the ACX6160 through your
Open ROADM controller. It also describes the Open ROADM YANG model support for each interface
type available on the ACX6160 Client and Line ports.
 46

Understanding the Hierarchical Relationship Between Ports and Interfaces

TIP: It’s important to understand, in Open ROADM, Ports and Interfaces are two distinct entities,
which have a hierarchical relationship to each other.

• Ports are the physical ports on the device, the Client and Line ports on the ACX6160 front
panel. Client ports are labeled 0/0 through 0/7. Line ports (labeled 1/0 through 1/3.

• Interfaces are configured on a supporting physical port (or another supporting interface).

When configuring a transponding circuit, the required interfaces need to be configured in the hierarchical
order, beginning with the interface directly supported by the port, then working upwards in the interface
stack. For each interface configured, the supporting circuit pack, supporting port and supporting interface
must be provisioned appropriately to reflect the hierarchical relationships. Additional details are provided
in Table 17 on page 46 below.

Client and Line ports on the ACX6160 use pluggable optics. All Client ports use pluggable QSFP28
transceivers that are 100 Gbps. All Line ports use pluggable CFP2-DCO transceivers that are 100 Gbps
and support HGFEC.

Table 17 on page 46 describes the various interfaces available for the ACX6160 Client and Line ports and
the Management port, which is (1000BASE-T). The ACX6160 supports the Open ROADM model for
interface configuration and status data. You can provision and monitor the all of these interface types on
the ACX6160.

Table 17: ACX6160 Supported Interface Types

Interfaces Available On
Transponder Client Port On Transporter Line Port On Management Port

100 Gigabit Ethernet interface Optical Channel interface Ethernet interface

See, see Table 19 on page 51 See, see Table 20 on page 52

OTN OTU4 interface OTN OTU4 interface

See, Table 22 on page 55 See, Table 22 on page 55

OTN OTU4 (100 Gbps) interface OTN ODU4 interface

See, Table 21 on page 53 See, Table 21 on page 53

An OTU4 interface, with an ODU4

interface supported by the OTU4
interface.
 47

Configuring Client Port Interfaces

The ACX6160 has eight Client ports (labeled 0/0 through 0/7 on the front panel) that support QSFP28
transceivers. These transceivers provide a speed of up to 100 Gbps, through four 25-Gbps channels. By
default, Client ports are configured as 100-Gigabit Ethernet ports.

On Client ports, the interfaces that are provisioned depend on the transponding application required. To
configure a 100 Gigabit Ethernet transponding circuit, an ethernet interface is provisioned on the Client
port. To configure a OTU4 transponding circuit, both an OTU interface and an ODU interface are configured
on the Client port. In the case of a 100 Gigabit Ethernet Client, the Ethernet interface is provisioned to
be directly supported by the Client port. For an OTU4 Client, the OTU interface is supported by the port
and the ODU interface is supported by the OTU interface.

As an example, let’s look at what it would take to configure a 100 Gigabit Ethernet transponding circuit
on the Client port of the ACX6160, again, looking at Table 17 on page 46:

1. Configure the Shelf

2. Configure the FPC circuit-pack

3. Configure the PIC circuit-pack

4. Configure the XCVR circuit-pack (pluggable optics)

5. Configure the port on the XCVR

You must perform these steps in the order shown using your Open ROADM controller.

Again, referring to Table 17 on page 46, let’s look at what steps you need to take to configure an OTU4
Client:

1. Configure the port on the XCVR

2. Configure the XCVR circuit-pack (pluggable optics)

3. Configure the PIC circuit-pack

4. Configure the FPC circuit-pack

5. Configure the Shelf

In addition you’ll need to configure:

• A single 100GE interface supported by the provisioned port

• A single OTU4 interface supported by the provisioned port

• A single ODU4 interface supported by the OTU4 interface.

 48

Configuring Line Port Interfaces

The ACX6160 has four Line CFP2 ports (labeled 1/0 through 1/3 on the front panel) that support C
form-factor pluggable type 2 transceivers.

To configure a Line port”

1. Configure the port on the XCVR

2. Configure the XCVR circuit-pack (pluggable optics)

3. Configure the PIC circuit-pack

4. Configure the FPC circuit-pack

5. Configure the Shelf

These Line interfaces have a hierarchical relationship, with the optical channel interface (OCH) directly
supported by the Line port, the OTU interface supported by the optical channel interface, and the ODU
interface supported by the OTU interface.

These three interfaces are configured together on the Line side. It is the only arrangement of interfaces
that is configured on the Line side.

On Line ports, you must provision all three interfaces:

1. A single OCH interface supported by the provisioned port

2. A single OTU4 interface supported by the OCH interface

3. A single ODU4 interface supported by the OTU4 interface

You must provision these Line interfaces in the order shown.

Open ROADM Device Interface YANG Model Support

Table 18 on page 49 describes ACX6160 compliance with the content of the Open ROADM device interface
YANG model that is common to all interface types. The location within the Open ROADM YANG model
of the nodes listed in the table is /org-openroadm-device/interface.

The columns in Table 18 on page 49 are defined as:

• YANG node — The node from the Open ROADM YANG model.

• Access — Access properties of the node. Can be:

• rw — read/write

• ro — read-only
 49

• x — RPC function

• n — notification

• Supported — Indicates ACX6160 support for the node.

• Yes — ACX6160 supports the node

• No — ACX6160 does not support the node

• N/A — Node is not applicable to transponder device

• Supported Values — Describes the range of supported values on ACX6160.

Table 18 on page 49 describes ACX6160 compliance with the content of the Open ROADM interface
YANG model that is common to all interface types. The location within the Open ROADM YANG model
of the nodes listed in the table is /org-openroadm-device/interface.

Table 18: Open ROADM Device Interface YANG Model Support

YANG Node Access Supported Supported Values

name rw yes User-specified string.

description rw yes User-specified string.

type rw yes • opticalChannel — for

optical-channel interfaces
• otnOtu — for OTU4 Line and Client
interfaces
• otnOdu — for ODU4 Line and
Client interfaces
• ethernetCsmacd — for Client 100
Gigabit Ethernet interfaces and the
management port interface

administrative-state rw yes • inService — normal service enabled,

alarm reporting enabled
• outOfService — service disabled,
alarm reporting disabled
• maintenance — normal service
enabled, alarm reporting disabled
 50

Table 18: Open ROADM Device Interface YANG Model Support (continued)

YANG Node Access Supported Supported Values

operational-state ro yes • inService — interface is able to

perform in normal function
• outOfService — interface is unable
to perform its normal function
• degraded — ability of interface to
perform its normal function is
degraded

circuit-id rw yes User-specified string.

supporting-interface rw yes If interface type is otnOdu, this field

must be set to name field of the
supporting interface, which must be
type otnOtu.

If interface type is otnOtu on the

Line-side port, this field must be set
to name field of the supporting
interface, which must be type
opticalChannel.

For all other interfaces, this attribute

must not be configured.

supporting-circuit-pack-name rw yes If supporting-interface field is not

specified, this attribute must be
configured as the name of the
interface’s supporting circuit-pack.

supporting-port rw yes If supporting-interface field is not

specified, this attribute must be
configured as the name of the
interface’s supporting port.

Open ROADM Device Ethernet Interface YANG Model Support

Table 19 on page 51 describes ACX6160 compliance with the content of the augmentation for ethernet
interfaces to the Open ROADM interface YANG model. The location within the Open ROADM YANG
model of the nodes listed in the table is /org-openroadm-device/interface/ethernet.
 51

NOTE: In the column on supported values, the information that applies to 100 Gigabit Ethernet
client interfaces is prefixed by “100GE” and the information that applies to the management
port interface is prefixed by “Mgmt IF”.

Table 19: Open ROADM Device Ethernet Interface YANG Model Support

YANG Node Access Supported Supported Values

ethernet rw yes

- speed rw yes • 100GE – 100000

• Mgmt IF – 10, 100,
1000, 10000

- fec rw yes • 100GE – off

• Mgmt IF - off

- duplex rw yes • 100GE – full

• Mgmt IF – half, full

- mtu rw no • 100GE – not

supported
• Mgmt IF – 1518
through 9000

- auto-negotiation rw no • 100GE – not

supported
• Mgmt IF – enabled,
disabled

- curr-speed ro yes • 100GE – 100000

• Mgmt IF – 10, 100,
1000, 10000

- curr-duplex ro yes • 100GE – full

• Mgmt IF – half, full
 52

Open ROADM Device Optical-Channel Interface YANG Model Support

Table 20 on page 52 describes ACX6160 compliance with the content of the augmentation for
optical-channel interfaces to the Open ROADM interface YANG model. The location within the Open
ROADM YANG model of the nodes listed in the table is /org-openroadm-device/interface/och.

Table 20: Open ROADM Device Optical-Channel Interface YANG Model Support

YANG Node Access Supported Supported Values

Och rw yes

- rate rw yes R100G

- frequency rw yes ITU 50 GHz grid

frequency within range
191.35 to 196.10

- width ro yes 50.00000 (for 50 GHz

spacing)

- modulation-format rw yes qpsk

- transmit-power rw yes Range: -35.0 through

+10.0

(power in dBm)

Open ROADM Device OTN ODU Interface YANG Model Support

Table 21 on page 53 describes ACX6160 compliance with the content of the augmentation for OTN ODU
interfaces to the Open ROADM interface YANG model. The location within the Open ROADM YANG
model of the nodes listed in the table is /org-openroadm-device/interface/odu.

Where the level of support differs between line-port and client-port ODU4 interfaces, the port-specific
support is identified by “ODU4 line interface” and “ODU4 client interface” respectively.

NOTE: Descriptions for the maint-testsignal container within the odu container are excluded
from this section and discussed in a later section of this document.
 53

Table 21: Open ROADM Device OTN ODU Interface YANG Model Support

YANG Node Access Supported Supported Values

Odu rw yes Container

- rate rw yes ODU4

- odu-function rw no Not supported

- monitoring-mode rw yes • For Line-side ODU interface with 100GE

Client interface – terminated
• For Line-side ODU interface with OTU4
Client interface – monitored
• For Client-side ODU interface - monitored

- no-oam-function ro yes This node is always absent.

- rw yes False.
proactive-delay-measurement-enabled

- parent-odu-allocation rw no Not supported.

- tx-sapi rw yes User-specific string, up to 15 characters

- tx-dapi rw yes User-specific string, up to 15 characters

- tx-operator rw yes User-specific string, up to 32 characters

- accepted-sapi ro yes User-specific string, up to 15 characters

- accepted-dapi ro yes User-specific string, up to 15 characters

- accepted-operator ro yes User-specific string, up to 32 characters

- expected-sapi rw yes User-specific string, up to 15 characters

- expected-dapi rw yes User-specific string, up to 15 characters

- tim-act-enabled rw yes True/false.

- tim-detect-mode rw yes Disabled, SAPI, DAPI. SAPI-and-DAPI

- degm-intervals rw yes Range: 2 through 10

 54

Table 21: Open ROADM Device OTN ODU Interface YANG Model Support (continued)

- degthr-percentage rw yes Range: 1 through 10000

- tcm rw no Not supported

- opu rw yes Container

-- payload-type rw yes • For Line-side ODU interface with 100GE

Client interface – 07
• For Line-side ODU interface with OTU4
Client interface – not supported
• For Client-side ODU interface – not
supported

-- rx-payload-type ro no Not supported

-- exp-payload-type rw yes • For Line-side ODU interface with 100GE

Client interface – 07
• For other ODU interfaces, range: 00 through
FF

-- payload-interface rw yes User-specified string

-- msi rw no Not supported

Open ROADM Device OTN OTU4 Interface YANG Model Support

Table 22 on page 55 describes ACX6160 compliance with the content of the augmentation for OTN OTU
interfaces to the Open ROADM interface YANG model. The location within the Open ROADM YANG
model of the nodes listed in the table is /org-openroadm-device/interface/otu.

Where the level of support differs between Line-port and Client-port OTU4 interfaces, the port-specific
support is identified by “OTU4 Line interface” and “OTU4 Client interface” respectively.

NOTE: Descriptions for the maint-loopback container within the otu container are excluded
from this section and discussed in a later section of this document.
 55

Table 22: Open ROADM Device OTN OTU4 Interface YANG Model Support

YANG Node Access Supported Supported Values

Otu rw yes Container

- rate rw yes OTU4

- fec rw yes OTU4 Line interface – scfec

OTU4 Client interface – rsfec, off

- tx-sapi rw yes User-specific string, up to 15 characters

- tx-dapi rw yes User-specific string, up to 15 characters

- tx-operator rw yes User-specific string, up to 32 characters

- accepted-sapi ro yes User-specific string, up to 15 characters

- accepted-dapi ro yes User-specific string, up to 15 characters

- accepted-operator ro yes User-specific string, up to 32 characters

- expected-sapi rw yes User-specific string, up to 15 characters

- expected-dapi rw yes User-specific string, up to 15 characters

- tim-act-enabled rw yes True, false

- tim-detect-mode rw yes Disabled, SAPI, DAPI. SAPI-and-DAPI

- degm-intervals rw yes Range: 2 through 10

- degthr-percentage rw yes Range: 1 through 10000

RELATED DOCUMENTATION

Maintenance Testing | 61
Connectivity | 56
Alarm Monitoring | 64
 56

Connectivity

The Open ROADM device YANG model contains a number of lists and an RPC for configuring and retrieving
connectivity information. This section describes the extent of support for this connectivity modeling on
ACX6160.

internal-link – This list is not supported. All internal connectivity information is provided by the
connection-map.

physical-link – This list is not supported. There are no links required to be setup between circuit packs on
the ACX6160, thus there is nothing to configure for this list.

external-link – This list is supported. You can provision any data you wish to record on links between the
ACX6160 and external devices.

connection-map – This list is supported. The connection-map list reports the traffic path connections
between ACX6160 transponder Client and Line ports, identifying which Client and Line ports are paired
together to provide 100 gigabit transponder units.

get-connection-port-trail – This RPC is not supported, because there are no internal or physical links required
on ACX6160, the connection port trail is trivial and thus there is no need for this RPC. You can reference
all internal connectivity information from the connection-map.

ACX6160 Client to Line Port Fixed Mappings

Consistent with the Open ROADM connectivity model, there is a fixed linkage between Client and Line
ports that is reported by the read-only connection-map list from the Open ROADM YANG model.. The
ACX6160 supports the fixed port mapping described in Table 23 on page 57.

NOTE: Although there are eight QSFP28 Client ports, only four of these ports, along with four
Line ports are reported in the connection-map. These are the only ports that are available for
use as Open ROADM transponder configurations.
 57

Table 23: ACX6160 Client to Line Port Fixed Mapping

Client Side Ports Line Side Port

Labeled: 0/0 - 0/7 Labeled 1/0-1/3

Client ports: 0/0/[0-7] Line Ports: 0/1/[0-3]

Client port: 0/0/0 Line port: 0/1/0

Client port: 0/0/1

NOTE: Not used in this release.

Client port: 0/0/2 Line port: 0/1/1

Client port: 0/0/3

NOTE: Not used in this release.

Client port: 0/0/4 Line port: 0/1/2

Client port: 0/0/5

NOTE: Not used in this release.

Client port: 0/0/6 Line port: 0/1/3

Client port: 0/0/7

NOTE: Not used in this release.

Open ROADM Connectivity YANG Model Support

The columns in the Table 24 on page 58 are defined as:

• YANG node — The node from the Open ROADM YANG model.

• Access — Access properties of the node. Can be:

• rw — read/write

• ro — read-only

• x — RPC function

• n — notification
 58

• Supported — Indicates ACX6160 support for the node.

• Yes — ACX6160 supports the node

• No — ACX6160 does not support the node

• N/A — Node is not applicable to transponder device

• Supported Values — Describes the range of supported values on ACX6160.

Table 24 on page 58 describes ACX6160 compliance with the connectivity-related lists of the Open
ROADM YANG model. The location within the Open ROADM YANG model of the YANG nodes listed in
the table is /org-openroadm-device.

Table 24: Open ROADM Device Connectivity YANG Model Support

YANG Node Access Supported Supported Values

internal-link list ro no Not supported

physical-link list rw no Not supported

external-link list rw yes User-specified string

- external-link-name

- source rw yes User-specified string

• - node-id
• - circuit-pack-name
• - port-name

- destination rw yes User-specified string

• - node-id
• - circuit-pack-name
• - port-name

connection-map list ro yes Returns fixed mapping of Client to Line ports.

- connection-map-number ro yes Unsigned integer key into this table. This key
is generated by the ACX6160.

- source ro yes The source container identifies the Client

circuit-pack and port for this connection-map
• - circuit-pack-name list entry.
• - port-name
 59

Table 24: Open ROADM Device Connectivity YANG Model Support (continued)

YANG Node Access Supported Supported Values

- destination ro yes The destination container identifies the Line

circuit-pack and port for this connection-map
• - circuit-pack-name list entry.
• - port-name

RELATED DOCUMENTATION

Open ROADM Compliance Overview | 23

Equipment Provisioning | 29
Interfaces | 45

Transponder Information

This section describes the ACX6160 compliance with the transponder list in the Open ROADM device
YANG model.

The columns in the Table 25 on page 60 are defined as:

• YANG node — The node from the Open ROADM YANG model.

• Access — Access properties of the node. Can be:

• rw — read/write

• ro — read-only

• x — RPC function

• n — notification

• Supported — Indicates ACX6160 support for the node.

• Yes — ACX6160 supports the node

• No — ACX6160 does not support the node

• N/A — Node is not applicable to transponder device

• Supported Values — Describes the range of supported values on ACX6160.

Table 25 on page 60 describes ACX6160 compliance with the device transponder in the Open ROADM
YANG model.
 60

Table 25: Open ROADM Transponder YANG Model Support

YANG Node Access Supported Supported Values

xponder rw yes

xpdr-number rw yes Unsigned integer greater than 0

xpdr-type rw yes Must be set to: tpdr

recolor ro yes False

xpdr-port rw yes

xpdr-port/index rw yes Unsigned integer

xpdr-port/circuit-pack-name rw yes Must match the name of an entry

in the circuit-pack list. On ACX6160,
all transponder ports are on
transceiver circuit packs with names
matching the pattern xcvr-0/X/Y

xpdr-port/port-name rw yes Must match the name of an entry

in the ports list that is nested within
the circuit-pack entry identified by
the circuit-pack-name field above.
On ACX6160, all transponder ports
are on transceiver circuit packs with
names matching the pattern
port-0/X/Y

xpdr-port/eqpt-srg-id rw yes Unsigned integer

RELATED DOCUMENTATION

Open ROADM Compliance Overview | 23

Equipment Provisioning | 29
Connectivity | 56
 61

Maintenance Testing

This section describes the maintenance testing support on ACX6160. The ACX6160 provides support for
activation of traffic loopbacks on OTU interfaces, and supports the execution of Pseudo Random Binary
Sequence (PRBS) tests on ODU interfaces.

Supported ACX6160 Loopbacks

The ACX6160 supports facility and terminal loopbacks on OTU interfaces. You can activate loopbacks on
both Client and Line OTU interfaces. For facility loopbacks, the loopback occurs post FEC termination.

NOTE: Note that for a Client port and Line port that are paired in a transponder circuit, you can
only activate one loopback at a time on the interfaces in this transponder.

Table 26 on page 61 describes the loopbacks supported by the ACX6160 and the interfaces they can be
used on to diagnose problems.

Table 26: Supported ACX6160 Loopbacks

Interface Type Loopback Type Description

Line OTU fac Loops back OTU traffic received from network on line side after
FEC termination back towards traffic path transmitted to
network direction.

Line OTU term Loops back traffic from host system back towards host and
forwards as transmitted traffic on connected client interface.

Client OTU fac Loops back OTU traffic received from network on client side
after FEC termination back towards traffic path transmitted to
network direction.

Client OTU term Loops back traffic from host system back towards host and
forwards as transmitted traffic on connected line client interface.
 62

Open ROADM Loopback YANG Model Support

The columns in Table 27 on page 62 are defined as:

• YANG node — The node from the Open ROADM YANG model.

• Access — Access properties of the node. Can be:

• rw — read/write

• ro — read-only

• x — RPC function

• n — notification

• Supported — Indicates ACX6160 support for the node.

• Yes — ACX6160 supports the node

• No — ACX6160 does not support the node

• N/A — Node is not applicable to transponder device

• Supported Values — Describes the range of supported values on ACX6160.

Table 27 on page 62 describes ACX6160 compliance with the content of the maint-loopback augmentation
for OTU interfaces to the Open ROADM interface YANG model. The location within the Open ROADM
YANG model of the nodes listed in the table is /org-openroadm-device/interface/otu.

Table 27: Open ROADM Loopback YANG Model Support

YANG Node Access Supported Supported Values

- maint-loopback rw yes container

-- maint-testsignal/enabled rw yes true, false

-- maint-testsignal/type rw yes fac2, term (fac loopback type not

supported)

PRBS

The ACX6160 supports the conducting of PRBS tests on ODU interfaces. PRBS test signals and monitoring
can be activated on both client and line ODU interfaces when a transponder circuit is configured for an
OTU4 client. Note that due to a hardware limitation, PRBS tests are not supported for either the client or
line side interfaces when the transponder client interface is configured as 100GE. Note that for a client
 63

port and line port that are paired in a transponder circuit, only one PRBS test at a time can be activated
on the interfaces in this transponder.

Table 28 on page 63 describes the PRBS tests supported by the ACX6160.

Table 28: Supported ACX6160 PRBS Tests

PRBS Test
Interface Type Type Description

Line ODU Fac Transmits a generated PRBS test signal towards the network direction on the
line side and monitors for a matching PRBS test signal on the traffic received
from the network direction.

Line ODU Term Transmits a generated PRBS test signal towards the host direction which is
forwarded as transmitted traffic on the connected client interface, and monitors
for a matching PRBS test signal on the traffic received from the host direction.

Client ODU Fac Transmits a generated PRBS test signal towards the network direction on the
client side and monitors for a matching PRBS test signal on the traffic received
from the network direction.

Client ODU Term Transmits a generated PRBS test signal towards the host direction which is
forwarded as transmitted traffic on the connected line interface, and monitors
for a matching PRBS test signal on the traffic received from the host direction.

Table 29 on page 63 describes ACX6160 compliance with the content of the maint-testsignal augmentation
for ODU interfaces to the Open ROADM interface YANG model. The location within the Open ROADM
YANG model of the nodes listed in the table is /org-openroadm-device/interface/odu.

Table 29: Open ROADM PRBS Tests YANG Model

YANG Node Access Supported Supported Values

- maint-testsignal rw yes Container

- maint-testsignal/enabled rw yes true, false

- maint-testsignal/testPattern rw yes PRBS, PRBS31

- maint-testsignal/type rw yes fac, term

- maint-testsignal/bitErrors ro yes Unsigned integer

- maint-testsignal/bitErrorsTerminal ro yes Unsigned integer

 64

Table 29: Open ROADM PRBS Tests YANG Model (continued)

YANG Node Access Supported Supported Values

- maint-testsignal/syncSeconds ro yes Unsigned integer

- ro yes Unsigned integer

maint-testsignal/syncSecondsTerminal

RELATED DOCUMENTATION

Interfaces | 45
Alarm Monitoring | 64
Performance Monitoring | 71

Alarm Monitoring

IN THIS SECTION

Interface Alarms and Notifications | 64

ACX6160 Circuit Pack and Interface Type Alarm Summaries | 65

Open ROADM Alarm YANG Model Support | 70

This section describes the alarm reporting functionality on the ACX6160. Alarm monitoring is conducted
for the ACX6160’s provisioned circuit-packs, port and interfaces. The ACX6160 supports Open ROADM
notifications for alarm raise and clear events, as well as the Open ROADM active-alarm-list, so that you
can poll the list of currently active alarms.

Interface Alarms and Notifications

An alarm notification is sent with the same information as stored in an alarm list entry. The notification
sends the entire alarm structure. Alarm notifications contain all the same YANG nodes described in the
tables below.
 65

A cleared alarm has a severity level of clear.

ACX6160 Circuit Pack and Interface Type Alarm Summaries

The tables in this section list the alarms and conditions modeled by Open ROADM specifications for circuit
packs that are replaceable on the ACX6160, for circuit-pack ports, and for each ACX6160 interface type.
For each alarm there is an indication of whether or not it is supported on the ACX6160.

All supported alarms and conditions are listed in the Open ROADM active-alarm-list container when the
alarm or condition is active for a configured Open ROADM resource instance.

Active alarms/conditions are listed only if the resource instance they are active on is administratively
In-Service, otherwise they are suppressed. An active alarm or condition may also be suppressed if a
higher-severity alarm is also active.

Notifications are generated when each alarm or condition is raised and cleared. If an alarm/condition
becomes suppressed due to the resource instance changing administrative status to Out-of-Service or a
higher-severity alarm being raised, a notification is generated indicating that the alarm is cleared. Conversely,
if a suppressed alarm/condition transitions to no longer being suppressed, a notification for the raising of
that alarm is generated.

The following alarms are supported on the ACX6160:

• Table 30 on page 66

• Table 31 on page 66

• Table 32 on page 67

• Table 33 on page 67

• Table 34 on page 68

• Table 35 on page 69

Table 30 on page 66 lists the OpenRoadm probableCause values that are supported for alarms that are
raised against provisioned circuit-packs. Circuit-pack alarms are raised only against removable circuit-packs,
which, on the ACX6160 system, include CFP2-DCO transceivers, QSFP28 transceivers, fan modules and
power modules. The table explicitly indicates which alarms are supported for each removable circuit-pack
type.
 66

Table 30: Circuit-Pack Alarms

Probable Cause Support by circuit-pack type Severity Notes

Fan Power
CFP2-DCO QSFP-28 Mod. Mod.

equipmentFault Yes No No No Critical

equipmentRemoved Yes Yes Yes Yes Critical

equipmentMismatch Yes Yes No No Critical This alarm is

evaluated if the
circuit-pack-product-code
is configured. If the
configured product
code does not match
the actual product
code read from the
physical circuit pack,
the alarm is raised.

firmwareInitInProgress Yes No No No Minor

firmwareDownloadOrActivationFailure Yes No No No Major

Table 31 on page 66 lists the OpenRoadm probableCause values that are supported for alarms that are
raised against port objects.

Table 31: Port Alarms

Supported on Supported on
Probable Cause Client Port Line Port Severity Notes

portLossOfLight No Yes N/A This alarm signifies a total

absence of received
optical power on the port
at any frequency

Table 32 on page 67 lists the OpenRoadm probableCause values that are supported for alarms that are
raised against opticalChannel type interfaces, which can be configured only on the Line side ports of the
ACX6160.
 67

Table 32: OCH Interface Alarms

Supported on Supported on
Probable Cause Client Port Line Port Severity Notes

lossOfSignal N/A Yes Critical This alarm indicates that

no optical channel is
received for the
configured frequency

Table 33 on page 67 lists the OpenRoadm probableCause values that are supported for alarms that are
raised against otnOtu type interfaces.

Table 33: OTU Interface Alarms

Supported on Supported on
Probable Cause Client Port Line Port Severity Notes

lossOfSignal N/A Yes Critical OTN: Indicates the input power

has dropped.

Ethernet: (Ref IEEE 802.3ba)

NOTE: Indicates that received

signal power has fallen below
signal detection level.

lossOfFrame Yes Yes Critical (Ref G798: 6.2.5.1)

lossOfMultiframe Yes Yes Critical (Ref G798: 6.2.5.2)

backwardsDefectIndication Yes Yes Major (Ref G798: 6.2.6.6)

degradedDefect Yes Yes Major (Ref G798: 6.2.3.4)

backwardIncomingAlignmentError Yes Yes Warning (Ref G798: 6.2.6.11)

incomingAlignmentError Yes Yes Warning (Ref G798: 6.2.6.10)

trailTraceIdentifierMismatch Yes Yes Critical (Ref G798: 6.2.2.1)

alarmIndicationSignal No No Major (Ref G798: 6.2.6.3.2)

serverSignalFail No No N/A
 68

Table 33: OTU Interface Alarms (continued)

Supported on Supported on
Probable Cause Client Port Line Port Severity Notes

facilityLoopback2Active Yes Yes Minor Raised when fac loopback

configured

terminalLoopbackActive Yes Yes Minor Raised when terminal loopback

configured

Table 34 on page 68 lists the OpenRoadm probableCause values that are supported for alarms that are
raised against otnOdu type interfaces.

Table 34: ODU Interface Alarms

Supported on Supported on
Probable Cause Client Port Line Port Severity Notes

backwardsDefectIndication Yes Yes Major (Ref G798: 6.2.6.6)

degradedDefect Yes Yes Major (Ref G798: 6.2.3.4)

trailTraceIdentifierMismatch Yes Yes Critical (Ref G798: 6.2.2.1)

alarmIndicationSignal Yes Yes Major (Ref G798: 6.2.6.3.2)

openConnectionIndication Yes Yes Major (Ref G798: 6.2.6.8)

lockedDefect Yes Yes Critical (Ref G798: 6.2.6.9)

payloadMismatch Yes Yes Critical (Ref) G798: 6.2.4.1)

clientSignalFailDefect No No Critical (Ref G798: 6.2.10)

facilityTestsignalActive Yes Yes Minor Raised when facility PRBS

enabled.

terminalTestsignalActive Yes Yes Minor Raised when terminal PRBS

enabled.

Table 35 on page 69 lists the OpenRoadm probableCause values that are supported for alarms that are
raised against ethernetCsmacd type interfaces.
 69

Table 35: Ethernet Interface Alarms

Supported on Supported on Line

Probable Cause Client Port Port Severity Notes

lossOfSignal Yes N/A Critical Indicates that

received signal power
has fallen below
signal detection level.

linkDown No N/A N/A

lossOfFECAlignment No N/A N/A Ethernet interface

FEC is not supported
on ACX6160

lossOfSynchronization - Rx Yes N/A Critical (Ref IEEE 802.3ba:

45.2.3.11.5)

highBER - Rx Yes N/A Major (Ref IEEE 802.3ba:

45.2.3.11.4)

localFault - Rx Yes N/A Critical (Ref IEEE 802.3ba:

81.3.4)

remoteFault - Rx Yes N/A Critical (Ref IEEE 802.3ba:

81.3.4)

lossOfAlignment - Rx Yes N/A Critical (Ref IEEE 802.3ba:

45.2.3.16c/d/e/f)

lossOfSynchronization - Tx Yes N/A Critical (Ref IEEE 802.3ba:

45.2.3.11.5)

highBER - Tx No N/A Major (Ref IEEE 802.3ba:

45.2.3.11.4)

localFault - Tx Yes N/A Critical (Ref IEEE 802.3ba:

81.3.4)

remoteFault - Tx Yes N/A Critical (Ref IEEE 802.3ba:

81.3.4)

lossOfAlignment – Tx Yes N/A Critical (Ref IEEE 802.3ba:

45.2.3.16c/d/e/f)
 70

Open ROADM Alarm YANG Model Support

The columns in Table 36 on page 70 are defined as:

• YANG node — The node from the Open ROADM YANG model.

• Access — Access properties of the node. Can be:

• rw — read/write

• ro — read-only

• x — RPC function

• n — notification

• Supported — Indicates ACX6160 support for the node.

• Yes — ACX6160 supports the node

• No — ACX6160 does not support the node

• N/A — Node is not applicable to transponder device

• Supported Values — Describes the range of supported values on ACX6160.

Table 36 on page 70 describes ACX6160 compliance with the content of the active-alarm-list within the
org-openroadm-alarm YANG module. This list will contain a row for each actively reported alarm on the
ACX6160.

When alarms are raised or cleared an instance of the alarm-notification notification, defined in
org-openroadm-alarm YANG module, is generated with same content as is provided in the corresponding
active-alarm-list listing, but with severity reported as “clear” for alarm clearing notifications.

Table 36: Open ROADM Alarm YANG Model Support

YANG Node Access Supported Supported Values

id ro Yes Unique id for this alarm. This is a string set by the device.

resource ro Yes Resource under alarm, specifies instance of a resource.

Format depends on the resource type.

probableCause ro Yes Enumeration of probable causes. This is the alarm name.

riseTime ro Yes Timestamp alarm was raised.

severity ro Yes Enumerated value of critical, major, minor, warning, clear,

indeterminate.
 71

Table 36: Open ROADM Alarm YANG Model Support (continued)

YANG Node Access Supported Supported Values

circuit-id ro Yes Circuit-id for alarm correlation. Reported only for alarms
raised against interfaces, if a circuit-id value is configured
for the interface.

additional-detail ro Yes Provides additional descriptive text about the probable

cause.

corrective-action ro No

RELATED DOCUMENTATION

Interfaces | 45
Maintenance Testing | 61
Performance Monitoring | 71

Performance Monitoring

IN THIS SECTION

Performance Monitoring | 72

Open ROADM Performance Monitor YANG Model Support | 78

The ACX6160 supports the Open ROADM performance monitoring YANG data model for reporting current
PM data. It also provides support for retrieving historical PM data by way of file transfer, and support for
clearing PM data.

There are two main categories of performance monitoring parameter types:

• Counter performance monitors (PMs)

• Gauge PMs
 72

Counter type PMs are collected for current 15-minute and 1-day granularities. You can also retrieve
historical counter bins by way of file transfer. You can retrieve up to the last ninety-six 15-minute bins,
as well as the previous 1-day bin.

Gauge type PMs report the current instantaneous value, as well as the minimum, maximum, and average
value over the duration of the reported interval (15-minute or 1-day). For gauge type PMs, only the
minimum, maximum and average values are reported for historical bins.

NOTE: For current instantaneous gauge-type PM values, use the bin granularity type of
“notApplicable”.

Performance Monitoring

This section provides the list of supported performance metrics (PMs) for each type of entity on the
ACX6160 that supports performance monitoring.

The ACX6160 supports the following PMs:

• Table 37 on page 72

• Table 38 on page 73

• Table 39 on page 73

• Table 40 on page 75

• Table 41 on page 77

Table 37 on page 72 lists the OpenRoadm performance monitoring parameters that are supported for
transponder ports on the ACX6160.

Table 37: Open ROADM Port Performance Monitor Support on ACX6160

Support

Open ROADM PM Name Location Direction Line/Client Comments

opticalPowerOutput Near-end Transmit Yes/No

opticalPowerOutputMin Near-end Transmit Yes/No

opticalPowerOutputMax Near-end Transmit Yes/No

opticalPowerOutputAvg Near-end Transmit Yes/No

 73

Table 37: Open ROADM Port Performance Monitor Support on ACX6160 (continued)

Support

Open ROADM PM Name Location Direction Line/Client Comments

totalOpticalPowerInput Near-end Receive Yes/No These PMs report

on total optical
totalOpticalPowerInputMin Near-end Receive Yes/No input power,
including signal and
totalOpticalPowerInputMax Near-end Receive Yes/No noise power.

totalOpticalPowerInputAvg Near-end Receive Yes/No

Table 38 on page 73 lists the OpenRoadm performance monitoring parameters that are supported for
optical channel interfaces on the ACX6160.

Table 38: Open ROADM OCH Interface Performance Monitor Support

Open ROADM PM Name Location Direction Support Comments

opticalPowerInput Near-end Receive Yes These PMs report on

signal optical input
opticalPowerInputMin Near-end Receive Yes power.

opticalPowerInputMax Near-end Receive Yes

opticalPowerInputAvg Near-end Receive Yes

Table 39 on page 73 lists the OpenRoadm performance monitoring parameters that are supported for
OTU interfaces on the ACX6160.

Table 39: Open ROADM OTU Interface Performance Monitor Support on ACX6160

Support

Open ROADM PM Name Location Direction Line/Client Comments

preFECCorrectedErrors Near-end Receive Yes/No These FEC

PMs are
FECCorrectableBlocks Near-end Receive No/No available only
when FEC is
FECUncorrectableBlocks Near-end Receive Yes/No not set to “off”.
FECCorrectableBlocks
PM is not
supported.
 74

Table 39: Open ROADM OTU Interface Performance Monitor Support on ACX6160 (continued)

Support

Open ROADM PM Name Location Direction Line/Client Comments

erroredBlockCount Near-end Receive Yes/Yes Count of BIP-8

errors.
Counting
suppressed
during SES
seconds.

backgroundBlockErrors Near-end Receive Yes/Yes Reported as a

vendor
extension.

erroredSeconds Near-end Receive Yes/Yes Count of

seconds with
BIP-8 errors or
SES.

severelyErroredSeconds Near-end Receive Yes/Yes Count of

seconds in
which signal
failure
observed.

unavailableSeconds Near-end Receive No/No Not supported

this release.

erroredBlockCount Far-end Receive Yes/Yes Count of BIP-8

errors.
Counting
suppressed
during SES
seconds.

backgroundBlockErrors Far-end Receive Yes/Yes Reported as a

vendor
extension.

erroredSeconds Far-end Receive Yes/Yes Count of

seconds with
BIP-8 errors or
SES.
 75

Table 39: Open ROADM OTU Interface Performance Monitor Support on ACX6160 (continued)

Support

Open ROADM PM Name Location Direction Line/Client Comments

severelyErroredSeconds Far-end Receive Yes/Yes Count of

seconds in
which signal
failure
observed.

unavailableSeconds Far-end Receive No/No Not supported

this release.

Table 40 on page 75 lists the OpenRoadm performance monitoring parameters that are supported for
ODU interfaces on the ACX6160.

Table 40: Open ROADM ODU Interface Performance Monitors on ACX6160

Supported

Open ROADM PM Name Location Direction Line/Client Comments

erroredBlockCount Near-end Receive Yes/yes Count of BIP-8

errors.
Counting
suppressed
during SES
seconds.

backgroundBlockErrors Near-end Receive Yes/yes Reported as a

vendor
extension.

erroredSeconds Near-end Receive Yes/yes Count of

seconds with
BIP-8 errors or
SES.

severelyErroredSeconds Near-end Receive Yes/yes Count of

seconds in
which signal
failure
observed.
 76

Table 40: Open ROADM ODU Interface Performance Monitors on ACX6160 (continued)

Supported

Open ROADM PM Name Location Direction Line/Client Comments

unavailableSeconds Near-end Receive No/no Not supported

this release.

erroredBlockCount Far-end Receive Yes/yes Count of BIP-8

errors.
Counting
suppressed
during SES
seconds.

backgroundBlockErrors Far-end Receive Yes/yes Reported as a

vendor
extension.

erroredSeconds Far-end Receive Yes/yes Count of

seconds with
BIP-8 errors or
SES.

severelyErroredSeconds Far-end Receive Yes/yes Count of

seconds in
which signal
failure
observed.

unavailableSeconds Far-end Receive No/no Not supported

this release.

delay Near-end Transmit No/no Not supported

this release.

Table 41 on page 77 lists the OpenRoadm performance monitoring parameters that are supported for
100GE Client interfaces on the ACX6160.
 77

Table 41: Open ROADM Ethernet Interface Performance Monitors on ACX6160

Open ROADM PM Name Location Direction Support Comments

erroredBlockCount Near-end Receive No (Ref IEEE

802.3ba:
45.2.3.12.4)

BIPErrorCounter Near-end Receive Yes (Ref IEEE

802.3ba:
45.2.3.36)

erroredSecondsEthernet Near-end Receive Yes Count of seconds

with errored
blocks or BIP
errors or SES.

severelyErroredSecondsEthernet Near-end Receive Yes Count of seconds

in which signal
failure observed.

unavailableSecondsEthernet Near-end Receive No Not supported

this release.

erroredBlockCount Near-end Transmit No (Ref IEEE

802.3ba:
45.2.3.12.4)

BIPErrorCounter Near-end Transmit Yes (Ref IEEE

802.3ba:
45.2.3.36)

erroredSecondsEthernet Near-end Transmit Yes Count of seconds

with errored
blocks or BIP
errors or SES.

severelyErroredSecondsEthernet Near-end Transmit Yes Count of seconds

in which signal
failure observed.

unavailableSecondsEthernet Near-end Transmit No Not supported

this release.
 78

Open ROADM Performance Monitor YANG Model Support

The columns in Table 42 on page 78 are defined as:

• YANG node — The node from the Open ROADM YANG model.

• Access — Access properties of the node. Can be:

• rw — read/write

• ro — read-only

• x — rpc function

• n — notification

• Supported — Indicates ACX6160 support for the node.

• Yes — ACX6160 supports the node

• No — ACX6160 does not support the node

• N/A — Node is not applicable to transponder device

• Supported Values — Describes the range of supported values on ACX6160.

Table 42 on page 78 describes ACX6160 compliance with the content of the current-pm-list list definition
within the org-openroadm-pm YANG module. The location within the Open ROADM YANG model of the
nodes listed in the table is /org-openroadm-pm/current-pm-list/current-pm-entry.

Table 42: Open ROADM Current Performance Monitoring YANG Model Support

YANG Node Access Supported Supported Values

pm-resource-instance ro yes Identifies specific resource

instance reporting the PM
data.

pm-resource-type ro yes Port, interface

pm-resource-type-extension ro yes None

retrieval-time ro yes Time when data was read,

does not include bin start or
end time.

current-pm ro yes List of PMs collected for this

resource
 79

Table 42: Open ROADM Current Performance Monitoring YANG Model Support (continued)

YANG Node Access Supported Supported Values

- type ro yes Enumerated value from Open

ROADM pm-names-enum

- extension ro yes Identifies ACX6160-specific

extension to pm-names-enum
or “none” if Open ROADM
defined pm-name-enum
reported for type value above.

- location ro yes notApplicable, nearEnd, farEnd

- direction ro yes tx, rx, bidirectional,

notApplicable

- measurement ro yes List of PM measurements for

different granularities

-- granularity ro yes notApplicable, 15min, 24Hour

-- pmParameterValue ro yes • Union uint64

• int64
• decimal64

-- pmParameterUnit ro yes String-valued indicator of units

of the value reported, if
applicable, for example “dBm”,
“count”

-- validity ro yes partial, suspect

Open ROADM Historical Performance Monitoring YANG Model Support

The ACX6160 provides support for retrieval of historical PM data through the collect-historical-pm-file
RPC, defined in the org-openroadm-pm.yang module. Open ROADM users can invoke this RPC to generate
an output file containing the historical PM data that is queried, then download this file using the Open
ROADM file transfer RPC.

See, “File System Operations” on page 89

 80

NOTE: The ACX6160 does not provide support for retrieving historical PM data by Netconf get
requests that target the historical-pm-list container.

Table 43 on page 80 describes ACX6160 compliance with the collect-historical-pm-file RPC definition
within the org-openroadm-pm YANG module.

Table 43: Open ROADM Historical Performance Monitoring RPC YANG Model Support

YANG Node Access Supported Supported Values

collect-historical-pm-file x Yes

Input

- from-bin-number w Yes 1 through 96

- to-bin-number w Yes 1 through 96

- granularity w Yes 15min, 24Hour

Output

- pm-filename ro Yes Name of file in which rpc output data is

recorded

- status ro Yes Successful, Failed

- status-message ro Yes Textual description of rpc execution result

The output of the collect-historical-pm-file RPC is saved to a file in XML format based on the
historical-pm-list definition, and the file is gzip compressed, as per the definition of the
collect-historical-pm-file RPC.

Table 44 on page 80 describes ACX6160 compliance with the defined output data content as defined
within the org-openroadm-pm YANG module.

Table 44: Open ROADM Defined Output Data Content Support

YANG Node Access Supported Supported Values

historical-pm-list ro Yes

- historical-pm-entry ro Yes
 81

Table 44: Open ROADM Defined Output Data Content Support (continued)

YANG Node Access Supported Supported Values

-- pm-resource-instance ro Yes Name of port or interface instance

-- pm-resource-type ro Yes Port, interface

-- pm-resource-type-extension ro Yes

-- historical-pm ro Yes

--- type ro Yes Enumerated value from Open ROADM

pm-names-enum

--- extension ro Yes Identifies ACX6160-specific extension to

pm-names-enum or “none” if Open ROADM
defined pm-name-enum reported for type value
above.

--- location ro Yes notApplicable, nearEnd, farEnd

--- direction ro Yes tx, rx, bidirectional, notApplicable

--- measurement ro Yes

---- granularity ro Yes 15min, 24Hour

---- bin-number ro Yes 1 through 96

---- pmParameterValue ro Yes Union of uint64, int64 and descimal64

---- pmParameterUnit ro Yes String-valued indicator of units of the value

reported, if applicable, for example “dBm”,
“count”

---- validity ro Yes complete, suspect

---- completion-time ro Yes Timestamp of end of bin time

Open ROADM Clearing Performance Monitoring Data YANG Model Support

The ACX6160 provides support for clearing current and historical PM data through the clear-pm RPC
defined in the org-openroadm-pm.yang module.
 82

Table 45 on page 82 describes ACX6160 compliance with the clear-pm RPC definition within the
org-openroadm-pm YANG module.

Table 45: Open ROADM Clearing Performance Monitoring Data RPC YANG Model Support

YANG Node Access Supported Supported Values

clear-pm x Yes

Input

- device/node-id w Yes If specified, must match configured ACX6160 node-id

- resource/port

-- circuit-pack-name w Yes If targeting a port, this field must be specified to match

the name of a configured pluggable transceiver with
traffic-bearing port, with name matching pattern
xcvr-0/X/Y

-- port-name w Yes If targeting a port, this field must be specified to match

the name of a configured port on a pluggable transceiver,
with name matching pattern port-0/X/Y

- resource/interface-name w Yes If targeting an interface, this field must match the name
of the interface as configured in the interface list

- resource-type w Yes

-- type w Yes Port, interface

-- extension w Yes None, or leave unspecified

- pm-type w Yes Current, all

- granularity w Yes 15min, 24Hour

Output

- status ro Yes Successful, Failed

- status-message ro Yes Textual description of rpc execution result

RELATED DOCUMENTATION
 83

Alarm Monitoring | 64
Connectivity | 56
Maintenance Testing | 61

NETCONF Notifications

IN THIS SECTION

Notifications | 83

Interleave | 84

Replay | 84

Notifications

The ACX6160 supports NETCONF notifications (RFC5277), an asynchronous event notification service
between a NETCONF server and a NETCONF client. The ACX6160 acts a NETCONF server and sends
device event notifications, asynchronously as the events occur, to all NETCONF clients that subscribe to
the notification service.

To subscribe to the notifications service for events that occur on a specific ACX6160 device, a NETCONF
client sends a <create-subscription> rpc to the ACX6160 indicating the following:

• <stream> - The name of the stream that the client is interested in. If this parameter is missing, the
ACX6160 treats the subscription request as a request for the NETCONF stream, which is the only stream
that the ACX6160 supports. The ACX6160 returns an error if the subscription request is for any other
stream.

• <filter> - A subtree filter that indicates the subtree of interest. If this parameter is present, only those
events passed by the filter are sent. If this parameter is missing, all events are sent. The ACX6160 does
not support XPATH filters.

• <startTime> and <stopTime> - Indicates that the subscription request is for a replay. See “Replay” on
page 84. If the <startTime> parameter is not present, then the subscription request is for new notifications
and not for a replay.

For a subscription that is not a replay, the ACX6160 sends event notifications as they occur. The notifications
continue until the subscription or the session is terminated.
 84

Interleave

The ACX6160 supports the interleave capability for NETCONF notifications. The interleave capability
allows the client and the ACX6160 to exchange regular NETCONF commands and responses within the
same NETCONF session used for sending notifications. This reduces the total number of NETCONF
sessions used because a dedicated NETCONF session for notifications is not required.

Replay

The ACX6160 supports the notification replay feature. The replay feature enables a client to request the
ACX6160 to send or resend notifications that have occurred in the past, subject to any <filter> parameters.

The replay is defined by the following parameters in the <create-subscription> rpc:

• <startTime> - Indicates that the subscription request is for a replay of the event notifications starting
at the specified <startTime>. The <startTime> must not be later than the current time.

• <stopTime> - Indicates the end time of the replay request. The <stopTime> must not be earlier than
the <startTime> but can refer to a time in the future.

If both the <startTime> and <stopTime> parameters are present, the subscription request is for a replay
of the event notifications starting at the specified <startTime> and ending at the specified <stopTime>.
Once the replay is complete (that is, once the replay has reached the indicated <stopTime>), the subscription
terminates but the NETCONF session remains up, reverting to a normal NETCONF command-response
session.

If the <startTime> parameter is present but the <stopTime> parameter is missing, the subscription request
is for a replay followed by new notifications. The replay covers the period from the specified <startTime>
up until the time the subscription request was received by the device. After the replay finishes, the device
sends any event notifications that have occurred since the subscription request was received as well as
all future event notifications as they occur. The notifications continue until the subscription or session is
terminated.

It is invalid for <stopTime> to exist without the corresponding <startTime>.

In some situations, the client might want to know prior to creating a replay subscription how far back in
time that the ACX6160 has stored event notifications. To get this information, the client can perform a
<get> request on the <streams> element. Among other information, the ACX6160 responds with a message
containing the following timestamps:

• <replayLogCreationTime> - The timestamp of the creation of the log storing the notifications to be
replayed. This places a bound on the earliest notification stored.
 85

• <replayLogAgedTime> - The timestamp of the last notification aged out of the log. If this parameter is
missing, no notifications have been aged out.
3 CHAPTER

System Administration

User Administration | 87

File System Operations | 89

Software Upgrades | 93

Firmware Upgrades | 99

Database Save and Restore Operations | 100

Device Operations | 106

One-Touch Factory Defaults Button | 110

 87

User Administration

User Account Management

ACX6160 user accounts are managed in the users container holding a list of user entries. You can add and
delete user entries from this table. Adding a user to this table creates the user in the underlying Open
ROADM controller’s operating system. Deleting an entry in this table removes a user from the underlying
operating system. The underlying operating system’s user account database should remain in sync with
this table so long as no back-door management takes place.

When you add or update a user entry, the password and group are validated against the data-model
specified in the YANG data model.

Per the Open ROADM requirement, the ACX6160 default username and password are: .

• Username= openroadm

• Password= openroadm

Open ROADM User Account YANG Model Support

When you add or update a user entry the password and group are validated against the data-model specified
in the YANG model.

Table 46: Open ROADM User Account Support on ACX6160

Operation Config OS Action

Set No-exist No-exist User is created in the OS and in the Configuration

Set No-exist Exists User account is updated in the OS with any changes to
password or group. User is added to the configuration.

Set Exists No-exists User is created in the OS and configuration is updated with
any changes to password or group.

Set Exists Exists User account and configuration is updated with any changes
to password or group.

Delete No-exist Don’t care Netconf will error back.

 88

Table 46: Open ROADM User Account Support on ACX6160 (continued)

Operation Config OS Action

Delete Exists No-exists Entry in the configuration is removed, no error is generated.

Delete Exists Exists Entry in OS and Configuration is deleted

If the action results in an error from the OS, the operation fails and the configuration is unchanged. An
error is returned in the set or delete response.

The columns Table 47 on page 88 are defined as:

• YANG node — The node from the Open ROADM YANG model.

• Access — Access properties of the node. Can be:

• rw — read/write

• ro — read-only

• x — RPC function

• n — notification

• Supported — Indicates ACX6160 support for the node.

• Yes — ACX6160 supports the node

• No — ACX6160 does not support the node

• N/A — Node is not applicable to transponder device

• Supported Values — Describes the range of supported values on ACX6160.

Table 47 on page 88 describes ACX6160 compliance with the content of the Open ROADM user account
YANG model.

Table 47: Open ROADM User Account YANG Model Support

YANG Node Access Supported Supported Values

users rw yes container

- user rw yes list

-- name rw yes String: User-specified name

-- password rw yes String: User-specified password

-- group rw yes Enumeration: Must be set to "sudo"

 89

RELATED DOCUMENTATION

File System Operations | 89

Firmware Upgrades | 99
Software Upgrades | 93

File System Operations

IN THIS SECTION

Device File Management | 89

Open ROADM RPC File Transfer YANG Model Support | 90

Open ROADM Show Files YANG Model Support | 91

Open ROADM Delete Files YANG Model Support | 92

Open ROADM File Operation Notifications YANG Model Support | 92

This topic describes the device file management YANG model supported by the ACX6160.

Device File Management

The Open ROADM device model specifies a flat file structure on the device with no subdirectories that
support simple file operations with the controller. When an operation generates multiple files, they are
placed in a tarball and zipped in a single file which is stored locally in the flat file structure on the ACX6160.
Examples of files that may reside in this flat file structure include debug, syslogs, database, software images,
and so forth.

For Open ROADM a single directory or file system is created for the purpose of providing this flat directory
structure. The controller accesses the ACX6160 flat directory structure through RPC calls. The ACX6160
supports the following RPC calls:

• transfer — provides file upload and download using an asynchronous SFTP from or to the ACX6160
respectively

• show-file — retrieves list of files from the ACX6160

• delete-file — deletes the specified file from the ACX6160

 90

SFTP Client

An asynchronous SFTP client is included that allows you to initiate long file transfers while allowing you
to continue management of the device within the same session.

Open ROADM RPC File Transfer YANG Model Support

The columns in Table 48 on page 90, Table 49 on page 91, Table 50 on page 92 and Table 51 on page 92
are defined as:

• YANG node — The node from the Open ROADM YANG model.

• Access — Access properties of the node. Can be:

• rw — read/write

• ro — read-only

• x — RPC function

• n — notification

• Supported — Indicates ACX6160 support for the node.

• Yes — ACX6160 supports the node

• No — ACX6160 does not support the node

• N/A — Node is not applicable to transponder device

• Supported Values — Describes the range of supported values on ACX6160.

Table 48 on page 90 describes ACX6160 compliance with the content of the Open ROADM RPC file
transfer YANG model.

Table 48: Open ROADM RPC File Transfer YANG Model Support

YANG Node Access Supported Supported Values

transfer x yes Action

- input w yes

action w yes Enumeration: upload, download

 91

Table 48: Open ROADM RPC File Transfer YANG Model Support (continued)

YANG Node Access Supported Supported Values

-- local-file-path w yes String: local file to be source of upload or

destination of download.

Description: Local file path. Ex:

/var/shared/example.txt

-- remote-file-path w yes String: remote file to be destination of upload or

source of download.

- output ro yes

-- status ro yes Returns: Successful, Failed

-- status-message ro yes String: provides more detail on status

Open ROADM Show Files YANG Model Support

Table 49 on page 91 describes ACX6160 compliance with the content of the Open ROADM RPC show-files
YANG model.

Table 49: Open ROADM Show Files YANG Model Support

YANG Node Access Supported Supported Values

show-file x yes Action

- input w yes

-- filename w yes String: files to be listed (* is allowed wild-card)

-- remote-file-path w yes String: remote file to be destination of upload or source

of download.

- output ro yes

-- status ro yes Successful, Failed

-- status-message ro yes String: provides more detail on status

 92

Open ROADM Delete Files YANG Model Support

Table 50 on page 92 describes ACX6160 compliance with the content of the Open ROADM RPC delete-file
YANG model.

Table 50: Open ROADM Delete Files YANG Model Support

YANG Node Access Supported Supported Values

delete-file x yes Action

- input w yes

-- filename w yes String: local file to be deleted (* wild-card is not allowed).

- output ro yes

-- status ro yes Successful, Failed

-- status-message ro yes String: provides more detail on status

Open ROADM File Operation Notifications YANG Model Support

Table 51 on page 92 describes ACX6160 compliance with the content of the Open ROADM RPC file
operation notification YANG model.

Table 51: Open ROADM File Operation Notifications YANG Model Support

YANG Node Access Supported Supported Values

transfer-notification n yes Notification

- local-file-path ro yes String: local file to be deleted.

- status ro yes Successful, Failed, In-progress

- status-message ro yes String: provides more detail on status

- progress ro yes

-- bytes-transferred ro yes Count of bytes transferred

 93

Table 51: Open ROADM File Operation Notifications YANG Model Support (continued)

YANG Node Access Supported Supported Values

-- percentage-complete ro yes Percent complete, 100% is done

RELATED DOCUMENTATION

User Administration | 87
Software Upgrades | 93
Database Save and Restore Operations | 100

Software Upgrades

IN THIS SECTION

Software Upgrade RPC Functions | 93

Manifest Files | 94

Software Upgrade RPC Functions

The ACX6160 uses the following RPC functions for software upgrades:

• Pending software container — specifies the software version.

• Software stage RPC — stages the specified software package into the in-active software bank. This is
done to prepare for software activation when the in-active bank is activated and for the new software
package to take effect.

• Software activate RPC — activates the software previously staged to the in-active bank by switching the
role of the software banks and reboots the device.

• Software cancel validation timer RPC — cancels the validation timer. The input parameter accept determines
whether the load is committed or if the device reverts back to the previous load (cancel-validation-timer).
 94

• Software stage notification — returns a success or fail notification.

• Software activate notification — returns the following notifications:

• Activate — software image has been activated. This is sent upon successful completion of the sw-activate
request.

• Commit — software load has been committed. This is sent after a cancel-validation-timer request has
been sent with accept = true.

• Cancel — software load has been cancelled. This is sent after a cancel-validation-timer request has
been sent with accept = false or expiration of the cancel-validation-timer.

Manifest Files

IN THIS SECTION

Open ROADM Pending Software YANG Model Support | 95

Open ROADM Software Stage YANG Model Support | 95

Open ROADM Software Activate YANG Model Support | 96

Open ROADM Software Cancel-Validation-Timer YANG Model Support | 97

Open ROADM Software Stage Notification YANG Model Support | 97

Open ROADM Software Activate Notification YANG Model Support | 98

Per the Open ROADM MSA, the ACX6160 uses manifest files to describe how the ACX6160 performs a
software download, database backup, and database restore operations. This allows the controller to adapt
to variations in how devices handle these operations. For each operation the manifest file provides a basic
set of attributes and then an instruction set that describes the sequence of RPC requests required to
perform the operation.

This section describes the various manifest files used for the ACX6160.

The columns in Table 52 on page 95, Table 53 on page 96, Table 54 on page 96, Table 55 on page 97,
Table 56 on page 98Table 57 on page 98are defined as:

• YANG node — The node from the Open ROADM YANG model.

• Access — Access properties of the node. Can be:

 95

• rw — read/write

• ro — read-only

• x — RPC function

• n — notification

• Supported — Indicates ACX6160 support for the node.

• Yes — ACX6160 supports the node

• No — ACX6160 does not support the node

• N/A — Node is not applicable to transponder device

• Supported Values — Describes the range of supported values on ACX6160.

Open ROADM Pending Software YANG Model Support

Table 52 on page 95 describes ACX6160 compliance with the content of the Open ROADM RPC pending
software YANG model..

Table 52: Open ROADM Pending Software YANG Model Support

YANG Node Access Supported Supported Values

Pending-software ro yes container

- sw-version ro yes Package version in this bank

- sw-validation-timer ro yes String: value of validation timer hh-mm-ss

- activation-date-time ro yes date-and-time: Activation date and time

Open ROADM Software Stage YANG Model Support

The software stage RPC function stages (installs) the specified software package into the in-active software
bank. This is done to prepare for software activation when the in-active bank is activated and for the new
software package to take effect.

The software package is validated prior to writing to the software bank to avoid installation of corrupted
software into the in-active bank. If this operation fails an error is returned and no change is made to the
contents of the in-active software bank or the device state.

Table 53 on page 96 describes ACX6160 compliance with the content of the Open ROADM RPC software
stage YANG model.
 96

Table 53: Open ROADM Software Stage YANG Model Support

YANG Node Access Supported Supported Values

Software-stage x yes Stages software package into the in-active software bank

- input w yes

-- filename w yes String: name of package file to be staged.

- output ro yes

-- status ro yes Returns: Successful, Failed

-- status-message ro yes String: provides more detail on status

Open ROADM Software Activate YANG Model Support

This RPC activates the software previously staged to the in-active bank by switching the role of the software
banks and reboots the device. The device comes up with the banks switched so that the software from
the previously in-active bank takes effect.

If this operation fails an error is returned and the device is not be rebooted and no change is made to the
ACX6160 device state.

describes ACX6160 compliance with the content of the Open ROADM RPC software activate YANG
model.

Table 54: Open ROADM Software Activate YANG Model Support

YANG Node Access Supported Supported Values

activate x yes Activates software previously staged to the in-active

bank.

- input w yes

-- version w yes String: version of the software to be activated

-- validationTimer w yes String: specifies time hh-mm-ss the user has to validate
the software and cancel this timer.

- output ro yes

-- status ro yes Returns: Successful, Failed

 97

Table 54: Open ROADM Software Activate YANG Model Support (continued)

YANG Node Access Supported Supported Values

-- status-message ro yes String: provides more detail on status

Open ROADM Software Cancel-Validation-Timer YANG Model Support

Table 55 on page 97 describes the software cancel-validation-timer RPC YANG Model. This RPC cancels
the validation timer on the ACX6160. The input parameter: accept, determines if the software load is
committed or if the device reverts back to the previous load.

If this operation fails, you can try again, the ACX6160 software does not prevent subsequent attempts.
Failure to complete this operation results in the cancel-validation-timer expiry at which time the ACX6160
reverts back to the previous software load.

Table 55 on page 97 describes ACX6160 compliance with the content of the Open ROADM RPC software
cancel-validation-timer YANG model.

Table 55: Open ROADM Software Cancel-Validation-Timer YANG Model Support

YANG Node Access Supported Supported Values

cancel-validation-timer x yes Cancels the validation timer

- input w yes

-- accept w yes True - to accept the software load

False - to reject the software load, this reverts the

software back to the previously installed version by
switching the roles of the software banks and rebooting
the device.

- output ro yes

-- status ro yes Returns: Successful, Failed

-- status-message ro yes String: provides more detail on status

Open ROADM Software Stage Notification YANG Model Support

Table 56 on page 98 describes ACX6160 compliance with the content of the Open ROADM RPC software
stage notification YANG model. This RPC function returns a success or fail notification (sw-stage
notification).
 98

Table 56: Open ROADM Software Stage Notification YANG Model Support

YANG Node Access Supported Supported Values

sw-stage-notification n yes Notification

- status ro yes Returns: Successful, Failed

- status-message ro yes String: provides more detail on status

Open ROADM Software Activate Notification YANG Model Support

Table 57 on page 98 describes ACX6160 compliance with the content of the Open ROADM RPC software
activate notification YANG model.

Table 57: Open ROADM Software Activate Notification YANG Model Support

YANG node Access Support Description

sw-stage-notification n yes Notification

sw-active-notification-type ro yes Returns:

• activate – Notification that the software

image has been activated. This is sent
upon successful completion of the
sw-activate request.
• commit – Notification that software load
has been committed. This is sent after a
cancel-validation-timer request has been
sent with accept = true.
• cancel – Notification that software load
has been cancelled. This is sent after a
cancel-validation-timer request has been
sent with accept = false or expiration of
the cancel-validation-timer.

- status ro yes Returns: Successful, Failed, or In-progress

- status-message ro yes String: provides more detail on status

RELATED DOCUMENTATION
 99

Firmware Upgrades | 99
File System Operations | 89
Database Save and Restore Operations | 100

Firmware Upgrades

Firmware Upgrade

A firmware upgrade upgrades the firmware on the specified ACX6160 circuit pack.

NOTE: Firmware upgrades are service impacting and interrupt traffic.

Open ROADM Firmware Upgrade for Circuit-Packs YANG Model Support

Firmware upgrade will upgrade firmware on the specified circuit pack. This operation is service impacting
and can interrupt traffic.

The columns in Table 58 on page 100 are defined as:

• YANG node — The node from the Open ROADM YANG model.

• Access — Access properties of the node. Can be:

• rw — read/write

• ro — read-only

• x — RPC function

• n — notification

• Supported — Indicates ACX6160 support for the node.

• Yes — ACX6160 supports the node

• No — ACX6160 does not support the node

• N/A — Node is not applicable to transponder device

• Supported Values — Describes the range of supported values on ACX6160.

 100

Table 58 on page 100 describes ACX6160 compliance with the content of the Open ROADM RPC software
firmware upgrade for circuit-packs YANG model.

Table 58: Open ROADM Firmware Upgrade for Circuit-Packs YANG Model Support

YANG Node Access Supported Supported Values

fw-update x yes Updates firmware on the specified circuit pack

- input w yes

-- circuit-pack-name w yes String: name of circuit-pack to upgrade

firmware

- output ro yes

-- status ro yes Returns: Successful, Failed

-- status-message ro yes String: provides more detail on status

RELATED DOCUMENTATION

File System Operations | 89

Database Save and Restore Operations | 100
Software Upgrades | 93

Database Save and Restore Operations

IN THIS SECTION

Database Operations Open ROADM YANG Model Support | 101

The ACX6160 database operations Open ROADM YANG model provides configuration database
management operations for backing up the ACX6160 configuration to a file, to restore the configuration
from a file, and restore to factory default.
 101

Database Operations Open ROADM YANG Model Support

The ACX6160 database operations Open ROADM YANG data models provide configuration database
management RPC functions for backing up the ACX6160 configuration to a file, restoring the ACX6160
configuration from a file, and restoring the ACX6160 to factory default. Factory default returns the device
configuration back to factory default.

• Database backup RPC — writes the current running configuration to the specified file.

• Database restore RPC — restores the configuration from the specified filename.

• Database activate RPC — activates the new configuration that was read in from a db-restore or from
db-init (factory-default)

• Cancel rollback timer — sets candidate configuration to factory default.

• Database init RPC — Sets the candidate configuration to the factory default.

The columns in Table 59 on page 102, Table 60 on page 102Table 61 on page 103, Table 59 on page 102,
Table 62 on page 104, and Table 63 on page 105, are defined as:

• YANG node — The node from the Open ROADM YANG model.

• Access — Access properties of the node. Can be:

• rw — read/write

• ro — read-only

• x — RPC function

• n — notification

• Supported — Indicates ACX6160 support for the node.

• Yes — ACX6160 supports the node

• No — ACX6160 does not support the node

• N/A — Node is not applicable to transponder device

• Supported Values — Describes the range of supported values on ACX6160.

Open ROADM Database Backup YANG Model Support

Table 59 on page 102 describes ACX6160 compliance with the content of the Open ROADM RPC database
backup YANG model. This RPC writes the current running configuration to the specified file.
 102

Table 59: Open ROADM Database Backup YANG Model Support

YANG Node Access Supported Supported Values

db-backup x yes Write configuration database to specified

file.

Format in XML.

- input w yes

-- filename w yes String: name of file to save database

- output ro yes

-- status ro yes Returns: Successful, Failed

-- status-message ro yes String: provides more detail on status

Open ROADM Database Restore YANG Model Support

Table 60 on page 102 describes ACX6160 compliance with the content of the Open ROADM RPC database
restore YANG model. This RPC restores the configuration from the specified filename.

If the nodIDCheck is enabled, it compares the nodeId in the specified file to the current nodeId and the
operation is rejected if they do not match.

Table 60: Open ROADM Database Restore YANG Model Support

YANG Node Access Supported Supported Values

db-restore x yes Read configuration from specified file into

candidate configuration database.

NOTE: A db-activate is required to commit

the factory default configuration.

- input w yes

-- filename w yes String: name of file to restore database from

-- nodeIDCheck w yes True - sysNameCheck required. Verifies

sysName in specified file matches the current
sysName.

False – no check required

 103

Table 60: Open ROADM Database Restore YANG Model Support (continued)

YANG Node Access Supported Supported Values

- output ro yes

-- status ro yes Returns: Successful, Failed

-- status-message ro yes String: provides more detail on status

Open ROADM Database Activate YANG Model Support

Table 61 on page 103 describes ACX6160 compliance with the content of the Open ROADM RPC database
activate YANG model. This RPC activates the new configuration, which must previously be read in from
a db-restore or from db-init (factory-default) RPC.

You can use the optional rollback timer (rollBackTimer) to rollback the configuration if not cancelled with
accept=true prior to expiration.

Table 61: Open ROADM Database Activate YANG Model Support

YANG Node Access Supported Supported Values

db-activate x yes Activates the candidate configuration by

performing a commit.

- input w yes

-- rollBackTimer w yes String: hh:mm:ss time which configuration is

reverted.

NOTE: You must verify system is operational

and cancel the rollback timer.

- output ro yes

-- status ro yes Returns: Successful, Failed

-- status-message ro yes String: provides more detail on status

Open ROADM Cancel Rollback Timer YANG Model Support

Table 62 on page 104 describes the cancel rollback timer RPC YANG model.
 104

NOTE: This RPC sets the candidate configuration to factory default.

Restoring to factory default returns the ACX6160 configuration back to factory defaults and:

• The static IP management address is deleted from the ACX6160

• DHCP is enabled, so that the device can receive a temporary IP address

NOTE: Activation of restore to factory default, results in loss of connectivity over the static IP
address. You may want to re-configure the static IP address and disable DHCP on the management
interface prior to activating the restore to factory default.

Table 62 on page 104 describes ACX6160 compliance with the content of the Open ROADM RPC cancel
rollback timer YANG model.

Table 62: Open ROADM Cancel Rollback Timer YANG Model Support

YANG Node Access Supported Supported Values

cancel-rollback-timer x yes Set candidate configuration to factory

default.

NOTE: A db-activate is required to

commit the factory default
configuration.

- input w yes

-- accept w yes True – accept activated configuration

False – revert configuration back to

previous configuration.

- output ro yes

-- status ro yes Returns: Successful, Failed

-- status-message ro yes String: provides more detail on status

 105

Open ROADM Database Init YANG Model Support

Table 63 on page 105 describes ACX6160 compliance with the content of the Open ROADM RPC database
init YANG model.

WARNING: This RPC sets the candidate configuration to factory default.

Activation of this RPC, results in loss of connectivity over the static IP address. You
may want to re-configure the static IP address and disable DHCP on the management
interface prior to activating the restore to factory default.

NOTE:

Restoring to factory default returns the ACX6160 configuration back to factory defaults and:

• The static IP management address is deleted from the ACX6160

• DHCP is enabled, so that the device can receive a temporary IP address

Table 63: Open ROADM Database init YANG Model Support

YANG Node Access Supported Supported Values

db-init x yes Set candidate configuration to factory default.

NOTE: A db-activate is required to commit the

factory default configuration.

- input w yes

-- filename w yes String: name of file to restore database from

- output ro yes

-- status ro yes Returns: Successful, Failed

-- status-message ro yes String: provides more detail on status

RELATED DOCUMENTATION

Firmware Upgrades | 99
 106

Device Operations | 106

File System Operations | 89

Device Operations

IN THIS SECTION

Open ROADM Device Operations YANG Model Support | 106

Open ROADM LED Control YANG Model Support | 107

Open ROADM Tech Support Info YANG Model Support | 108

Open ROADM Create Tech Info Notification YANG Model Support | 109

Open ROADM Set Current Date and Time YANG Model Support | 109

Open ROADM Device Operations YANG Model Support

The ACX6160 device operations Open ROADM YANG model includes RPC functions that control the
ACX6160 LEDs, date and time, and restart functions. The following RPCs are available:

• LED control RPC function — controls the ACX6160 LEDs

• Tech support information RPC function — collects all log data for debugging and places it in a location
accessible via FTP/SFTP.

• Create tech info notification RPC function — notification is sent when the create-tech-info RPC completes.

• Set current datetime RPC function — sets the current date and time on the ACX6160

The columns in Table 64 on page 107, Table 65 on page 108, and Table 66 on page 109, are defined as:

• YANG node — The node from the Open ROADM YANG model.

• Access — Access properties of the node. Can be:

• rw — read/write

• ro — read-only
 107

• x — RPC function

• n — notification

• Supported — Indicates ACX6160 support for the node.

• Yes — ACX6160 supports the node

• No — ACX6160 does not support the node

• N/A — Node is not applicable to transponder device

• Supported Values — Describes the range of supported values on ACX6160.

Open ROADM LED Control YANG Model Support

Table 64 on page 107 describes ACX6160 compliance with the content of the Open ROADM LED control
YANG model. This RPC function is used to flash LED on the ACX6160 to help the technician find the
device and entity in the device that needs service.

Table 64: Open ROADM LED Control YANG Model Support

YANG Node Access Supported Supported Values

led-control x yes RPC to flash LEDs to identify device/components

equipmentLedOn alarm is rased and cleared to

provide this indication.

- input w yes container

-- shelf yes Case shelf

--- shelf-name w yes Set to shelf-0

-- circuit-pack yes Case circuit pack

--- circuit-pack-name w yes Circuit pack name

-- enabled w yes True — equipmentLedOn is raised

False — equipmentLedOn is cleared

- output ro yes

-- status ro yes Returns: Successful, Failed

 108

Table 64: Open ROADM LED Control YANG Model Support (continued)

YANG Node Access Supported Supported Values

-- status-message ro yes String: provides more detail on status

Open ROADM Tech Support Info YANG Model Support

Table 65 on page 108 describes the tech support info RPC YANG model. This RPC collects all log data for
debugging and places it in a location accessible via FTP/SFTP. This model assumes ASYNC operation, in
other words, the command is returned after the ACX6160 accepts the command, A
create-tech-info-notification is sent out later for the result of the operation. The log-file is cleared at the
start of every create-tech-info operation in order to ensure the up-to-date logs are collected.

Table 65 on page 108describes ACX6160 compliance with the content of the Open ROADM RPC tech
support info YANG model.

Table 65: Open ROADM Tech Support Info YANG Model Support

YANG Node Access Supported Supported Values

create-tech-info x yes Collect logs for debugging and places in

location accessible via FTP/SFTP.

- input w yes container

-- shelf-id w yes Set to: shelf-0

-- log-option w yes Set to all, to get all logs.

- output ro yes

-- shelf-id ro yes Returns shelf-id

-- log-file-name ro yes Return "log-files.tgz"

-- status ro yes Returns: Successful, Failed

-- status-message ro yes String: provides more detail on status

 109

Open ROADM Create Tech Info Notification YANG Model Support

Table 66 on page 109 describes ACX6160 compliance with the content of the Open ROADM RPC create
tech info notification YANG model. This notification is sent when the create-tech-info RPC completes.

Table 66: Open ROADM Create Tech Info Notification YANG Model Support

YANG Node Access Supported Supported Values

create-tech-info-notification x yes Collect logs for debugging and places in

location accessible via FTP/SFTP.

- output ro yes

-- shelf-id ro yes Returns shelf-id

-- log-file-name ro yes Return "log-files.tgz"

-- status ro yes Returns: Successful, Failed

-- status-message ro yes String: provides more detail on status

Open ROADM Set Current Date and Time YANG Model Support

Table 67 on page 109 describes ACX6160 compliance with the content of the Open ROADM RPC set
current data and time YANG model. This RPC sets the current date and time on the ACX6160.

Table 67: Open ROADM Set Current Date and Time YANG Model Support

YANG Node Access Supported Supported Values

set-current-datetime

- input w yes container

-- current-datetime w yes ietf-yang-types:date-and-time

- output ro yes

-- status ro yes Returns: Successful, Failed

-- status-message ro yes String: provides more detail on status

 110

RELATED DOCUMENTATION

Database Save and Restore Operations | 100

File System Operations | 89
One-Touch Factory Defaults Button | 110

One-Touch Factory Defaults Button

The Reset button on the ACX6160 Management Panel allows you to easily return the device to the factory
default configuration. This configuration contains just enough configuration needed for commissioning
the ACX6160, and no more.

For the ACX6160, the factory default configuration is set so that the devices receives a temporary IP
address from your DHCP server. Your Open ROADM controller takes over from there and sets a permanent
IP address and configures the ACX6160 using the Open ROADM controller and the ACX6160 YANG data
models.

RELATED DOCUMENTATION

Database Save and Restore Operations | 100

File System Operations | 89
Maintenance Testing | 61
4 CHAPTER

Maintenance Signaling

Maintenance Signaling | 112

 112

Maintenance Signaling

IN THIS SECTION

Interface Alarm Signalling | 112

SignalFail Signaling on the ACX6160 | 112

Provisioning Related Signaling on the ACX6160 | 113

Interface Alarm Signalling

On the ACX6160 Client and Line port interface alarm signaling involves three areas:

• Signals generated during SignalFail conditions

• Signals generated during provisioning

• Signals passed from source to destination transparently

SignalFail Signaling on the ACX6160

When an ACX6160 interface is fully provisioned, cross-connected, and administratively up, if a SignalFail
condition is declared on a Client or Line interface, upstream and downstream alarm signals are generated
to inform the upstream and downstream ACX6160 nodes.

SignalFail Signaling on ACX6160 100 Gbps Ethernet Client Interfaces

100 Gbps Ethernet clients use GMP mapping to insert/retrieve Ethernet signaling within the Line side
OTN OPU framing.

If SignalFail (Loss Of Signal, Loss Of Sync) is declared on the Client side 100 Gbps Ethernet interface, LFOS
(Local Fault Ordered set) is sent over the Line side OTU4 interface.

If SignalFail (Loss Of Signal, Loss Of Frame) is declared on the Line side OTU4 interface, LF (Local Fault)
is sent over the Client side 100 Gbps Ethernet interface, and BDI (Backward Defect Indication) is sent over
the Line side OTU4 interface.
 113

If BDI is received on the Line side OTU4 interface, LF (Local Fault) is sent over the Client side 100 Gbps
Ethernet interface.

SignalFail Signaling on ACX6160 OTU4 Client and Line Interfaces

If SignalFail (Loss Of Signal, Loss Of Frame) is declared on the Client side OTU4 interface, Alarm Indication
Signal (ODU-AIS) is sent over the Line side of the OTU4 interface, and BDI is sent over the Client side of
the OTU4 interface.

If SignalFail (Loss Of Signal, Loss Of Frame) is declared on the Line side OTU4 interface, ODU-AIS (Alarm
Indication Signal) is sent over the Client side OTU4 interface, and BDI is sent over the Line side OTU4
interface.

If BDI is received on the Line side OTU4 interface, BDI is sent on the Client side OTU4 interface.

Provisioning Related Signaling on the ACX6160

Provisioning Related Signaling on 100 Gbps Ethernet Client Interfaces

If a Client side 100 Gbps Ethernet interface is administratively disabled, RF is sent on the Client side 100
GE interface, and LFOS is sent on the Line side OTU4 interface.

If Client side 100GE interface is then put into a loopback mode, the RF on the Client side 100 GE interface
is removed.

Provisioning Related Signaling on OTU4 Client Interfaces

If a Client side OTU4 interface is administratively disabled, ODU-LCK is sent on the Client side OTU4
interface, and ODU-LCK is sent on the Line side OTU4 interface.

If Client side OTU4 interface is then put into a loopback mode, ODU-LCK on the Client side OTU4 interface
is removed, and ODU-LCK on the Line side OTU4 interface is removed

If a Client side OTU4 interface has been fully provisioned, and set administratively up, but NOT
cross-connected (not carrying traffic), ODU-OCI (Open Connection Indication) is sent over the Client side
OTU4 interface. When the cross-connect is provisioned, the ODU-OCI signal will stop being sent.

Provisioning Related Signaling on OTU4 Line Interfaces

If a Line side OTU4 interface is administratively disabled, ODU-LCK is sent on the Line side OTU4 interface,
and ODU-LCK is sent on the Client side OTU4 interface.
 114

If Line side OTU4 interface is then put into a loopback mode, ODU-LCK on the Line side OTU4 interface
is removed.

If a Line side OTU4 interface has been fully provisioned, and set administratively up, but NOT
cross-connected (not carrying traffic), ODU-OCI is sent over the Line side OTU4 interface. When the
cross-connect is provisioned, the ODU-OCI signal will stop being sent.

Signal Transparency

Signal Transparency on 100GE Client Interfaces

Any LF/RF signals received on the Client side 100GE interface are mapped into LF/RFOS (OrderedSets)
on the Line side OTU4 interface. Any LF/RFOS received on the Line side OTU4 Client are mapped into
LF/RF signals on the Client side 100GE interface.

Signal Transparency on OTU4 Client Interfaces

Any ODU signals received on the Client side OTU4 interface are transparently mapped into ODU signals
on the Line side OTU4 interface. Any ODU signals received on the Line side OTU4 interface are
transparently mapped into ODU signals on the Client side OTU4 interface.

RELATED DOCUMENTATION

Interfaces | 45
Maintenance Testing | 61
Alarm Monitoring | 64