Overview 27

• contains LC connections for all ports (connection validation not supported)

• provides total power measurement on all 16 channel input ports/Tx ports
(not supported on channel output ports/Rx ports)
For more information on the CCMD16 C-Band, refer to CCMD16 C-Band
Module (16-Channel Colorless Mux/Demux) (NTK834AA) on page 410.

see

L-Band ROADM Upgrade

The L-Band ROADM Upgrade Module (NTK852MA), also known as the LRU
32x1 L-Band, is a double-width module that can be paired with the RLA 32x1
C&L-Band (NTK852AC) through L-band upgrade ports.

The LRU 32x1 L-Band provides:

• a twin flexible grid WSS for route and select
• 32 mux/demux ports mapped into 8 MPO ports
• total power monitoring for all 32 ports
• internal loopback port for L-band transponder verification

Consider the following:

• The RLA 32x1 C&L-Band and the LRU 32x1 L-Band belonging to the
same degree must be located in the same shelf.
• The RLA 32x1 C&L-Band and the LRU 32x1 L-Band cannot be connected
to the same CFIM1 or CFIM2.
For more information on the LRU 32x1 L-Band, see “LRU Modules
(NTK852MA)” on page 385.

Compact Fiber Interconnect Module Type 1

The Compact Fiber Interconnect Module (CFIM) Type 1 (NTK504QA), also
known as the CFIM1, is a single-width 1-slot high module that provides
interconnect for 4 degrees and supports quad group scaling. CFIM1 provides
passthrough interconnections between RLAs in the same degree quad group.

For more information on the CFIM1, see “Compact Fiber Interconnect Module
(CFIM) (NTK504QA/NTK504QB/NTK504QC)” on page 416.

Compact Fiber Interconnect Module Type 2

The Compact Fiber Interconnect Module (CFIM) Type 2 (NTK504QB), also
known as the CFIM2, is a single-width 1-slot high module that provides
interconnect for 4 degrees and supports quad group scaling. CFIM2 provides
passthrough interconnections between RLAs in different degree quad groups
as well as add/drop interconnections between RLAs and CCMDs.

6500 Reconfigurable Line System 6500 RLS Planning Guide

Release 2.4 NTRN10VL Standard Issue 1
Copyright© 2019-2021 Ciena® Corporation July 2021
28 Overview

For more information on the CFIM2, see “Compact Fiber Interconnect Module
(CFIM) (NTK504QA/NTK504QB/NTK504QC)” on page 416.

Compact Fiber Interconnect Module Type 3

The Compact Fiber Interconnect Module (CFIM) Type 3 (NTK504QC), also
known as the CFIM3, is a single-width 1-slot high module that provides add/
drop interconnections between RLAs and CCMDs in a Colorless Direct Attach
(CDA) node configuration.

For more information on the CFIM3, see “Compact Fiber Interconnect Module
(CFIM) (NTK504QA/NTK504QB/NTK504QC)” on page 416.

Fiber Interconnect Module Type 4

The Fiber Interconnect Module (FIM) Type 4 (NTK504CD), also known as the
FIM Type 4, is a single-width 1-slot high module that can be used in place of
CFIMs for:
• passthrough interconnections between RLAs
• add/drop interconnections between RLAs and CCMDs

The FIM Type 4 has five fiber pairs.

For more information on the FIM Type 4, see “Fiber Interconnect Module
(FIM) Type 4 Module (NTK504CD)/Fiber Interconnect Module (FIM) Type 4A
(NTK504CX)” on page 425.

Fiber Interconnect Module Type 4A

The Fiber Interconnect Module (FIM) Type 4A (NTK504CX), also known as
the FIM Type 4A, is a single-width 1-slot high module that can be used in place
of CFIMs for:
• express channel interconnections between RLA 32x1 modules
• local add/drop interconnections between the CCMD8x24 C-band and RLA
32x1

The FIM Type 4A has four fiber pairs.

For more information on the FIM Type 4A, see Fiber Interconnect Module
(FIM) Type 4 Module (NTK504CD)/Fiber Interconnect Module (FIM) Type 4A
(NTK504CX).

2-Slot Optical Module Chassis

The 2-Slot Optical Module Chassis (NTK504NA), also known as the OMC2,
is a stand-alone passive chassis designed to accommodate up to two CFIMs.

For more information on the OMC2, see “2-Slot Optical Module Chassis
(OMC2) (NTK504NA)” on page 423.

6500 Reconfigurable Line System 6500 RLS Planning Guide

Release 2.4 NTRN10VL Standard Issue 1
Copyright© 2019-2021 Ciena® Corporation July 2021
 Overview 29

Northbound interfaces
RLS is managed through the following northbound interfaces (NBI):
• Command Line Interface (CLI), a text-based command interface used to
configure and view system information.
• Network Configuration Protocol (NETCONF), an XML-based network
management protocol specification. You can use NETCONF to install,
manipulate, and delete network device configurations, and to provision
and activate network services.
• Remote Procedure Call (gRPC), a communication protocol that supports
the development of applications and scripts to interact with and monitor
the RLS system. gRPC is an open source framework which facilitates
communication between a client and server (RLS system).
• Representational State Transfer Application Programming Interface
(REST API), to configure RLS and view system information. REST
systems typically communicate over the Hypertext Transfer Protocol
(HTTP) or secure HTTP (HTTPs) using the same HTTP/HTTPs methods
that web browsers use to retrieve and send data to remote servers.
• Simple Network Management Protocol (SNMP), which provides the basis
to manage network devices using a Network Management System (NMS)
interface, such as a Management Information Base (MIB) browser. The
NMS interface acts as an SNMP manager and sends messages to the
device in the form of an SNMP Protocol Data Unit (PDU). RLS supports
SNMP v2c for trap viewing.

Regardless of the NBI, a common data model is used for interaction with the
system. The data model is defined using YANG models, which define the
configuration data, state data, and capabilities available on a device. RLS
supports both an RLS data model and an OpenConfig data model. CLI,
NETCONF, gRPC, and REST can interact with either data model.

OpenConfig is a collaborative effort by network operators and vendors to

develop a common set of APIs for managing a multi-vendor network. The
models are vendor neutral and allow the service provider to configure,
manage and monitor devices from different vendors using a common
interface. Models are defined using YANG.

The common data model specifies the object hierarchy that the user traverses
through the selected NBI to both query and configure the system. Refer to the
following figure.

6500 Reconfigurable Line System 6500 RLS Planning Guide

Release 2.4 NTRN10VL Standard Issue 1
Copyright© 2019-2021 Ciena® Corporation July 2021
30 Overview

Figure 1 RLS NBIs

For more information, refer to:

• “CLI description” on page 117
• “NETCONF description” on page 127
• “gRPC description” on page 145
• “SNMP description” on page 177
• “REST API description” on page 167
• “OpenConfig” on page 171

Software feature overview

Platform features:
• Equipment and facility management
• OAM communications
• Security and user management
• Licensing
• Zero Touch Provisioning (ZTP)
• Backup and restore
• Alarm management
• Syslog
• CTM redundancy
• Network boot
• Restarts
• Reset to factory default
• Secure erase
• YANG action support
• Software upgrades

6500 Reconfigurable Line System 6500 RLS Planning Guide

Release 2.4 NTRN10VL Standard Issue 1
Copyright© 2019-2021 Ciena® Corporation July 2021
 Overview 31

Photonic features:
• Photonic Functional Group
• Links
• Service and Photonic Layer Interoperability (SPLI)
• Passive Terminal controller
• Automatic link calibration
• Manual link re-calibration
• Fiber loss compensation
• Closed loop loss and power control
• Span loss calculation
• ASE channel holders
• ASE replacement
• Connection Validation
• Automatic Laser Shut Off (ALSO)
• Optical Time Domain Reflectometry (OTDR)
• Photonic service provisioning
• Stretched spans
• Performance monitoring

Platform features
Equipment and facility management
Equipment and facility management allows you to query and manage RLS
functionality. All RLS equipment and facilities are represented in the object
model which can be queried or edited through the NBIs. Equipment and
facility management includes:
• inventory retrieval of all or individual modules. Inventory information
includes the module's PEC, CLEI, serial number, manufacturing date,
hardware release, in-service time, and current temperature.
• manual provisioning of modules
• auto-provisioning of modules as they are inserted into the shelf
• editing of a module’s administrative state
• retrieval and editing of a module’s user-configurable parameters
For more information, refer to the “Equipment Management” and “Facilities”
sections in the 6500 RLS User Guide, 323-2051-100.

6500 Reconfigurable Line System 6500 RLS Planning Guide

Release 2.4 NTRN10VL Standard Issue 1
Copyright© 2019-2021 Ciena® Corporation July 2021
32 Overview

OAM communications
RLS supports:
• The following physical interface ports.
— COLAN for connection to DCN
— ILAN for DCN interconnection of co-located shelves
— OSC for remote shelf interconnection for DCN and control
— Craft ports for local access to RLS
— Console ports for serial communication between RLS and a terminal
(for example, laptop)
— Wayside ports for access to a transparent user channel on the OSC
— Telemetry input for external alarming

• Firewall/port filtering functionality on COLAN, ILAN, and craft ports

• IPv4 and IPv6 addressing and protocols on the management network
interfaces.
• Static routes on the COLAN (IPv4/IPv6), ILAN (IPv4/IPv6), and OSC
interfaces (IPv4/IPv6).
• Dynamic Host Configuration Protocol (DHCP) for IP address
management. RLS supports DHCP client and server options. Client and
server options are enabled by default. Supported for IPv4 and IPv6
addressing.
• DHCP relay agent support on COLAN, ILAN, and OSC ports. For each
port, agent information can be enabled or disabled (disabled by default).
OSC and ILAN ports also support a ZTP option. If enabled (default
setting), ZTP is performed through the port, in addition to relay agent
functions. If disabled, only relay agent functions are performed through the
port.
• Link Layer Discovery Protocol (LLDP) for network topology discovery.
LLDP is supported on COLAN, ILAN, and OSC ports and is enabled by
default.
• Open Shortest Path First (OSPF), an Interior Gateway Protocol (IGP)
used to distribute routing information between RLS sites or between an
RLS site and the external data communications network (DCN). OSPF is
supported on COLAN, ILAN, and OSC ports and is disabled by default.
• Network Time Protocol (NTP), which allows the system to automatically
obtain the system time from an NTP server in the customer DCN. Manual
configuration of the system time is also supported if the NTP server is
disabled. RLS supports the Universal Time Coordinated (UTC) timezone
only.

6500 Reconfigurable Line System 6500 RLS Planning Guide

Release 2.4 NTRN10VL Standard Issue 1
Copyright© 2019-2021 Ciena® Corporation July 2021
 Overview 33

• Border Gateway Protocol (BGP), an Exterior Gateway Protocol (EGP)

used to distribute routing information between RLS and the external
customer DCN. RLS supports BGP4, per RFC 4271, for use in IPv4
networks.
• The following protocols for the transfer of files between the RLS and an
external file server:
— unsecure: File Transfer Protocol (FTP), Trivial File Transfer Protocol
(TFTP), Hyper Text Transfer Protocol (HTTP), secure HTTP (HTTPs)
— secure (using SSH): Secure Copy Protocol (SCP) and Secure File
Transfer Protocol (SFTP)
RLS supports both client (FTP, TFTP, HTTP, HTTPs, SFTP, SCP)
functionality and server (SFTP) functionality. Servers are enabled by
default.
• IPv4 proxy ARP on an IPv4 numbered interface. The interface can be the
COLAN-X or COLAN-A.
• Viewing of the following IPv4 and IPv6 packet statistics for the COLAN,
ILAN, OSC, and WSC interfaces:
— RX: in-pkts, in-octets, in-error-pkts, in-forwarded-octets, in-forwarded-
octets, in-discarded-pkts
— TX: out-pkts, out-octets, out-error-pkts, out-forwarded-octets, out-
forwarded-octets, out-discarded-pkts

• Auto-negotiation of baud rates on console ports

For more information, refer to the “OAM comms” section in the 6500 RLS User
Guide, 323-2051-100.

Security and user management

Security and user management features include:
• local user account authentication
• centralized authentication through Terminal Access Controller Access
Control System (TACACS+). TACACS+ provides an industry standard
security protocol for controlling authentication, authorization, and
accounting (AAA) functions. RLS supports authentication, authorization,
and accounting functions and up to eight TACACS+ servers. You can
enable/disable authorization and accounting functions on individual CLI
commands and commands within a batch/commit.
• Remote Authentication Dial-In User Service (RADIUS) support. RADIUS
provides user management for a collection of networked devices through
one or more centralized servers. RADIUS comprises a set of security
protocols that provides authentication, authorization, and accounting
(AAA) services.

6500 Reconfigurable Line System 6500 RLS Planning Guide

Release 2.4 NTRN10VL Standard Issue 1
Copyright© 2019-2021 Ciena® Corporation July 2021
34 Overview

• intrusion detection and intrusion attempt handling

• provisionable security banner
• raising of security-related alarms and logs
• local password expiry and password warning periods
• session force-out of an active session by a user with Super or Diag access
level. A session force-out will terminate the specified user session to the
RLS. Applies to CLI, NETCONF, gNMI streaming, gRPC login, and REST
sessions.
• Secure Shell version 2 (SSHv2), providing secure, encrypted access to
RLS using CLI or NETCONF
• Transport Layer Security (TLS), providing secure, encrypted access to
RLS using gRPC and REST. Includes certificate manager for uploading a
host certificate to the TLS server or the option of creating a self-signed
certificate. A self-signed certificate is automatically generated upon a
CTM restart/switchover if no certificate is present on the system. Super or
Diag users can also regenerate a self-signed certificate at any point.
• ingress firewall/port filtering functionality on the COLAN, ILAN, and Craft
ports. By default, all ports that are not required for external OAM
management of the RLS system are filtered/blocked. When filtered, the
port does not respond to external requests and appears inactive. RLS
supports the user configuration of the firewall using IP access control lists
(ACL).
Note: Manually configured ACL rule sets supersede the RLS default
firewall. Therefore, blocking of ports can cause internal or external RLS
communication issues.

For more information, refer to the “Security and user management” section in
the 6500 RLS User Guide, 323-2051-100.

Licensing
RLS uses a software licensing mechanism in which shelves acquire licenses
from a license manager to enable the use of system software and certain
additional features. The licensing model establishes a single process for
ordering, managing, and deploying licenses.

RLS supports:
• Manual installation of a local license file
• Download and installation of a license from an external server
• Mixing of both locally applied and downloaded licenses
For more information, refer to the “Licensing” section in the 6500 RLS User
Guide, 323-2051-100.

6500 Reconfigurable Line System 6500 RLS Planning Guide

Release 2.4 NTRN10VL Standard Issue 1
Copyright© 2019-2021 Ciena® Corporation July 2021
 Overview 35

Zero Touch Provisioning (ZTP)

Zero Touch Provisioning (ZTP) enables automatic configuration of RLS after
the shelf is powered up and able to communicate, reducing turn-up time and
configuration errors. With ZTP, the RLS shelf retrieves its provisioning
information from a Dynamic Host Configuration Protocol (DHCP) server and
subsequently provisions itself automatically, eliminating the need for lengthy
commissioning operations. ZTP is enabled by default.

RLS supports IPv4 and IPv6.

With IPv4 or IPv6, ZTP is supported over COLAN-X, ILAN, and OSC ports.
ZTP over ILAN and OSC ports requires the use of a DHCP relay agent on the
upstream RLS chassis. Use of a DHCP relay agent on OSC or ILAN interfaces
allows remote RLS nodes not connected directly to the DCN to be
commissioned using ZTP.

For more information, refer to the “Zero touch provisioning” section in the 6500
RLS User Guide, 323-2051-100.

Backup and restore

RLS provides the following backup and restore functionality:
• automatic by the system through local configuration file redundancy
— CTM which maintains local backups of system provisioning for the
recovery of the system.
— Access Panel which provides FLASH storage for local backups to
support redundancy and CTM replacements.
• user initiated through the following
— CLI: system configuration retrieval and provisioning
— CLI: backup and restore of the internal RLS database using database-
backup, database-restore, database-commit, and database-cancel
commands
— NETCONF and gRPC: declarative configuration
— REST: GET and PUT operations
The CLI system configuration, NETCONF, and gRPC configuration files
contain data which is human readable. The files can be used to restore
services on the node from which they were created or used as a baseline
configuration from which edited configuration files are created and used to
provision other nodes.
Internal database files transferred from a system are for restoration to the
node on which they were created. These files should not be edited by the
user.

6500 Reconfigurable Line System 6500 RLS Planning Guide

Release 2.4 NTRN10VL Standard Issue 1
Copyright© 2019-2021 Ciena® Corporation July 2021
36 Overview

RLS backup files stored locally on RLS are automatically compressed when
a backup is performed and uncompressed during the restore operation.

You can:
• Query the backup files that exist on an RLS shelf
• Query if a restore operation is in progress by checking the system backup
status
• Cancel a pending restore using the database-cancel command

The system prevents restoring a backup file to a shelf running a different

release than the backup file or with a different node name from the backup file.

The system notifies the user if the specified database file does not exist on the
system.

For more information, refer to the “Backup and restore” section in the 6500
RLS User Guide, 323-2051-100.

Alarm management
RLS raises alarms to indicate equipment issues, operational issues, and
hardware failures. RLS supports:
• retrieval of the active alarms and event history through the CLI,
NETCONF, gRPC, and REST
• alarm streaming through NETCONF, gNMI, and REST
• retrieval of historical alarms through the CLI, NETCONF, gRPC, and
REST
• alarm correlation between alarms on a given module (for example, port-
level facility alarms mask service-level facility alarms on a port, and
equipment alarms mask facility alarms associated with the equipment)
• alarm correlation at the shelf-level and network-level (can be enabled or
disabled)
• editing of alarm templates

The alarm correlation feature must be enabled for alarm correlation to take
effect.

For more information, refer to the “Alarms” section in the 6500 RLS User
Guide, 323-2051-100.

Syslog
Syslog is a communication protocol used to automatically send system
events/messages to an external Syslog server. Using the protocol, the
software that generates system messages can be separated from the
software that stores, reports, and analyzes the messages. RLS uses Syslog

6500 Reconfigurable Line System 6500 RLS Planning Guide

Release 2.4 NTRN10VL Standard Issue 1
Copyright© 2019-2021 Ciena® Corporation July 2021