OpenROADM Network Architecture Overview

Figure 1: Complete OpenROADM network architecture showing SDN controller managing multiple device types via NETCONF

Commissioning Workflow:

1. Pre-plan device template loaded into controller (offline)
2. Physical equipment installation and power-on
3. Device auto-initialization with DHCP client enabled
4. Temporary IP address assignment via DHCP
5. Controller discovers new IP and attempts NETCONF connection
6. Field technician correlates discovered device with planned template
7. Controller pushes configuration (node-id, permanent IP, user accounts)
8. Device restart and permanent discovery
9. OMS link discovery via LLDP over OSC

Termination Point Types:

ODU-TTP (Trail Termination Point): Represents high-order ODU facing the line side. Terminated PM layer with tributary slot capability (PT-20/21/22). Contains MSI table for multiplexing structure.

ODU-CTP (Connection Termination Point): Low-order ODU for cross-connection. Non-terminated path facing line side under OTU or ODU-TTP. Defines cross-connect endpoints.

ODU-TTP-CTP: Combined termination for client interface mapping. Both terminates the path and provides cross-connection capability for client-to-network services.

Implementation Aspects:

• Vendor-specific Extensions: Some capabilities utilize vendorExtension containers, requiring additional integration effort for multi-vendor deployments.
• Testing Requirements: Comprehensive interoperability testing between vendor combinations is essential before production deployment.
• Performance Variability: While optical specifications are standardized, actual performance may vary based on implementation quality and environmental factors.
• Feature Support Differences: Optional features (unidirectional ODU connections, specific PM types) may not be universally available across all implementations.
• Upgrade Coordination: Multi-vendor networks require careful planning for MSA version migrations to maintain interoperability.

OpenROADM Interface Hierarchy: ROADM and Transponder

Figure 2: Complete interface hierarchy showing ROADM degree/add-drop ports and transponder client/network interfaces

Interface Hierarchy and Creation Workflow

OpenROADM implements a sophisticated interface hierarchy where higher-layer interfaces depend on lower-layer supporting interfaces. Understanding this hierarchy is critical for proper service provisioning:

Transponder Interface Hierarchy (TX Direction):

This hierarchical structure ensures proper dependency management. Deleting a supporting interface automatically removes dependent interfaces, maintaining configuration consistency. When provisioning services, controllers must create interfaces in the correct bottom-up sequence.

Phase 1: Transponder A Network Interface Creation (TX)

1. Retrieve port capabilities from network port to validate supported frequencies and power ranges
2. Set equipment-state of circuit-pack to "not-reserved-inuse"
3. Set administrative-state of network port to "inService"
4. Create OCH interface with parameters:
   • Frequency: 193.1 THz (or desired C-band frequency)
   • Rate: 100G
   • Modulation format: dp-qpsk
   • Transmit power: calculated based on path budget
5. Create OTU4 interface on supporting OCH interface
6. Create ODU4 interface on supporting OTU4 interface
7. Verify output power reaches target value via PM retrieval

Phase 2: ROADM 1 Add-Link Creation

1. Verify SRG port capabilities support required frequency
2. Create NMC-CTP interface on SRG add port:
   • Frequency: 193.1 THz (matching transponder)
   • Width: 40 GHz (for 100G signal with guard bands)
3. Check if OTS interface exists on degree TTP, create if absent
4. Check if OMS interface exists on degree TTP, create if absent
5. Create MC-TTP interface on degree TTP:
   • Min-freq: 193.075 THz (frequency - 25 GHz)
   • Max-freq: 193.125 THz (frequency + 25 GHz)
6. Create NMC-CTP interface on degree TTP (matching SRG parameters)
7. Create ROADM connection from SRG NMC-CTP to Degree NMC-CTP
8. Set optical control mode to "power" and configure target output power
9. Monitor PM until output power stabilizes
10. Switch optical control mode to "gainLoss" for operational state

Phase 3: ROADM 1 to ROADM 2 Express Link Creation

1. On ROADM 1 egress degree (connecting to ROADM 2):
   • Create OTS interface on TTP port (RX direction)
   • Create OMS interface on supporting OTS
   • Create MC-TTP interface with matching spectral parameters
   • Create NMC-CTP interface within MC-TTP
   • Verify input power is within expected range (span loss + preceding output power)
2. On ROADM 2 ingress degree (connecting from ROADM 1):
   • Create OTS interface on TTP port (TX direction)
   • Create OMS interface on supporting OTS
   • Create MC-TTP interface with matching spectral parameters
   • Create NMC-CTP interface within MC-TTP
3. On ROADM 1: Create ROADM connection from ingress NMC-CTP to egress NMC-CTP
4. Configure output power based on span loss calculations
5. Monitor and validate output power, then switch to gainLoss mode

Phase 4: ROADM 2 Drop-Link Creation

1. On ROADM 2 ingress degree (from span):
   • Verify OTS, OMS, MC-TTP, and NMC-CTP interfaces exist from express link creation
   • Validate input power is within specification
2. On ROADM 2 SRG drop port:
   • Create NMC-CTP interface with matching frequency and width
   • Set administrative state to inService
3. Create ROADM connection from Degree NMC-CTP to SRG NMC-CTP
4. Set optical control mode to power and configure target
5. Verify SRG output power via PM retrieval

Phase 5: Transponder B Network Interface Creation (RX)

1. Verify ROADM 2 SRG output power is within transponder RX port power capability
2. Set equipment-state of circuit-pack to "not-reserved-inuse"
3. Set administrative-state of network port to "inService"
4. Create OCH interface (RX) with matching frequency parameters
5. Create OTU4 interface on supporting OCH
6. Create ODU4 interface on supporting OTU4
7. Verify connection map links network and client ports

Phase 6: Client Interface Creation (Both Transponders)

1. Set equipment-state of client circuit-pack to "not-reserved-inuse"
2. Set administrative-state of client port to "inService"
3. Create 100GE Ethernet interface on client port with parameters:
   • Speed: 100000
   • FEC: RS-FEC or as required
   • Duplex: full
   • MTU: 9000 (or as required)
   • Auto-negotiation: enabled/disabled as needed
4. Verify interface operational state transitions to inService

10x10G Muxponder Architecture & Tributary Slot Mapping

Figure 3: 10x10G Muxponder showing fixed tributary slot mapping from client ports to ODU4 network line

10x10G Muxponder Detailed Configuration

Hardware Configuration:

• 10 client ports with SFP+ pluggables supporting 10GBASE-R
• 1 network port with CFP-DCO supporting 100G DWDM
• OTN switching fabric supporting ODU2/ODU2e into ODU4 multiplexing

Interface Creation Sequence for Client Port 1:

1. Create 10GE Ethernet interface on client port 1
2. Create ODU2 interface (ODU-TTP-CTP type) for client mapping:
   • Supporting interface: 10GE interface
   • Mapping: GFP-F or bit-synchronous (ODU2e)
   • Payload type: PT=05 (GFP-F) or PT=03 (CBR10G3)
3. Create network-side ODU4 interface (ODU-TTP type) on network port (if not already created)
4. Create ODU2 interface (ODU-CTP type) on network side:
   • Supporting interface: ODU4 interface
   • Tributary port number: 1
   • Tributary slots: 1-8 (for ODU2)
5. Create bi-directional ODU-connection:
   • Source interface: client-side ODU2 (ODU-TTP-CTP)
   • Destination interface: network-side ODU2 (ODU-CTP)
   • Direction: bidirectional

Tributary Slot Mapping for All 10 Clients:

Switching Pool Advertisement:

The muxponder advertises a blocking switching pool with 10 non-blocking lists. Each list contains one client port and the common network port, with interconnect bandwidth set to 0 (preventing client-to-client cross-connections).

Switchponder Architecture and Capabilities

Port Configuration:

• 4 network ports: Each supporting ODU4 (100G)
• 40 client ports: Each supporting ODU2 (10G) or ODU2e (10.3G)
• Total switching capacity: 400G full-duplex
• Non-blocking switching fabric: Any client can connect to any network port up to available bandwidth

Switching Pool Model:

A single non-blocking switching pool with one non-blocking list containing all 44 ports (4 network + 40 client). This configuration indicates that any port can be cross-connected to any other port without restriction, up to the interface bandwidth limits.

Port Capability Advertisement:

• Network ports support ODU4 trail termination (ODU-TTP)
• Client ports support ODU-TTP-CTP for client signal mapping
• All ports support both PM and TCM ODU monitoring
• Proactive delay measurement supported on PM and TCM1-6 layers

Example Cross-Connection Scenario:

Creating a 10G service from Client Port 5 to Network Port 2, then dropping at another node to Client Port 15:

1. Node A - Client ingress:
   • Create 10GE interface on Client Port 5
   • Create ODU2-TTP-CTP for client mapping
2. Node A - Network egress:
   • Create/verify ODU4-TTP on Network Port 2
   • Create ODU2-CTP within ODU4 (select available tributary slots, e.g., TPN 3, TS 17-24)
   • Create bi-directional ODU-connection from Client ODU2 to Network ODU2
3. Node B - Network ingress:
   • Create/verify ODU4-TTP on Network Port (matching tributary slots from Node A)
   • Create ODU2-CTP within ODU4
4. Node B - Client egress:
   • Create 10GE interface on Client Port 15
   • Create ODU2-TTP-CTP for client demapping
   • Create bi-directional ODU-connection from Network ODU2 to Client ODU2

Optical Layer Performance Monitoring

Optical Power Measurements:

OSC Performance Parameters:

• OPT-OSC / OPR-OSC: OSC transmit and receive power measurements at MW ports, critical for verifying OSC link budget
• CV-PCS: Code violations at PCS layer (8B/10B errors), indicates OSC signal quality issues
• ES-PCS: Errored seconds at PCS layer, tracks periods of significant OSC errors
• SES-PCS: Severely errored seconds, indicates serious OSC degradation
• UAS-PCS: Unavailable seconds, counts time when OSC is completely unavailable

OTN Layer Performance Monitoring

OTU/ODU Performance Parameters:

1. FEC Performance Monitoring:

• pFECcorrErr: Pre-FEC corrected errors, the total number of errors corrected by FEC. This is a critical health indicator - increasing trends suggest degrading optical SNR.
• FECCorrectableBlocks: Count of FEC blocks that contained errors but were successfully corrected. Available in RX direction.
• FECUncorrectableBlocks: Count of FEC blocks with uncorrectable errors. Any non-zero value indicates serious link degradation requiring immediate attention.

2. BIP Error Monitoring:

• pN_EBC (Near-End): Errored block count based on BIP-8 calculation. Monitored at OTU-IF and ODU-IF layers, plus TCM1-6 levels.
• pF_EBC (Far-End): Far-end errored block count received via BEI (Backward Error Indication). Provides visibility into far-end signal quality.
• Both parameters available at PM and TCM layers, enabling segment-level fault isolation

3. Delay Measurement:

• pN_delay: Proactive delay measurement at PM and TCM1-6 layers
• Measured in number of frames between DMValue toggle and received DMp signal toggle
• Enables precise latency tracking for SLA compliance
• Can detect asymmetric routing or fiber path changes

4. Ethernet Layer PM (100GE clients):

Current PM List Operations

The current PM list provides real-time access to performance data being actively collected across three granularities:

15-Minute Granularity:

• Bins align to UTC time boundaries: :00, :15, :30, :45
• Partial validity during active collection period
• Transitions to complete/suspect when bin completes
• Used for near-real-time monitoring and short-term trend analysis

24-Hour Granularity:

• Bin starts at 00:00:00 UTC, ends at 23:59:59 UTC
• Provides daily performance summaries
• Critical for SLA reporting and long-term trend analysis
• Analog PM records snapshot at bin end time

Untimed Granularity (NA):

• Runs continuously from interface creation or last reset
• No time boundaries, accumulates until cleared
• Used for total error accumulation and long-term statistics
• Only applicable to current PM list (not historical)

Retrieval Example - NETCONF XML:

<get>
  <filter>
    <currentPmlist xmlns="http://org/openroadm/pm">
      <currentPm>
        <resource>
          <device/>
          <resource>
            <circuit-pack-name>1/1</circuit-pack-name>
            <port-name>C1</port-name>
          </resource>
          <resourceType>
            <type>port</type>
            <extension>och</extension>
          </resourceType>
        </resource>
        <granularity>15min</granularity>
      </currentPm>
    </currentPmlist>
  </filter>
</get>

Historical PM Management

Data Model Access (Optional):

Implementations may support direct YANG data tree access to historical bins via NETCONF get operations. This allows querying specific bins by bin-number:

• Bin 1: Most recent completed bin
• Bin 2-96: Previous 15-minute bins (24 hours of history)
• Bin 1-7: Previous 24-hour bins (1 week of history)

File-Based Retrieval (Mandatory):

All implementations must support file-based historical PM retrieval via the collect-historical-pm-file RPC:

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <collect-historical-pm-file xmlns="http://org/openroadm/pm">
    <from-bin-number>1</from-bin-number>
    <to-bin-number>96</to-bin-number>
    <granularity>15min</granularity>
  </collect-historical-pm-file>
</rpc>

File-Based Retrieval Workflow:

1. Controller issues collect-historical-pm-file RPC with bin range and granularity
2. Device validates request and returns RPC response with auto-generated filename
3. Device collects requested PM data in background and writes to file
4. Device issues historical-pm-collect-results notification upon completion
5. Controller initiates file transfer using transfer RPC (upload from device)
6. Controller processes PM data from transferred file
7. Controller deletes PM file from device to free storage space

Benefits of File-Based Approach:

• Efficient bulk data transfer for large time ranges
• Reduces NETCONF session load and timeout risks
• Enables parallel processing of multiple device PM files
• Supports standardized file formats for analytics platforms

TCA Framework and Implementation

TCAs provide proactive fault detection by generating notifications when PM values cross configured thresholds. OpenROADM supports both high and low thresholds for analog parameters and high thresholds for digital counters.

TCA Configuration via Potential TCA List:

The potential-tca-list container provides the interface for threshold configuration:

<edit-config>
  <target><running/></target>
  <config>
    <potential-tca-list xmlns="http://org/openroadm/pm">
      <id>OCH-1-1-C1-opticalPowerOutput</id>
      <resource>
        <device/>
        <resource>
          <circuit-pack-name>1/1</circuit-pack-name>
          <port-name>C1</port-name>
        </resource>
        <resourceType>
          <type>port</type>
          <extension>och</extension>
        </resourceType>
      </resource>
      <pmParameterName>
        <type>opticalPowerOutput</type>
        <extension/>
      </pmParameterName>
      <granularity>15min</granularity>
      <threshold-value-high>2.0</threshold-value-high>
      <threshold-value-low>-2.0</threshold-value-low>
      <enable>true</enable>
    </potential-tca-list>
  </config>
</edit-config>

TCA Notification Behavior:

• Analog PM (Raw values):
  • Set against 15-minute granularity only
  • Transient notification issued when value exceeds high threshold or drops below low threshold
  • Maximum one notification per threshold (high or low) per 15-minute period
  • If threshold violation continues in subsequent bins, notifications reissue
  • Min/max values must align with threshold crossings (if max > high threshold, TCA must have been issued)
• Digital PM (Counters):
  • Can be set independently on 15-minute or 24-hour granularity
  • High threshold only (counters are non-decreasing)
  • Notification issued when counter exceeds threshold within the bin
  • One notification per bin period if threshold exceeded

TCA Notification Example:

<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
  <eventTime>2025-11-15T14:23:45Z</eventTime>
  <tca-notification xmlns="http://org/openroadm/pm">
    <id>OCH-1-1-C1-opticalPowerOutput</id>
    <resource>
      <device/>
      <resource>
        <circuit-pack-name>1/1</circuit-pack-name>
        <port-name>C1</port-name>
      </resource>
      <resourceType>
        <type>port</type>
        <extension>och</extension>
      </resourceType>
    </resource>
    <pmParameterName>
      <type>opticalPowerOutput</type>
    </pmParameterName>
    <granularity>15min</granularity>
    <threshold-type>high</threshold-type>
    <threshold-value>2.0</threshold-value>
    <pmParameterValue>2.5</pmParameterValue>
  </tca-notification>
</notification>

Practical TCA Configuration Strategies:

• Optical Power: Set thresholds ±1-2 dB from nominal to detect fiber degradation or connector issues
• Pre-FEC Errors: Configure threshold based on baseline + 2x standard deviation to detect degrading optical SNR
• OSC Errors: Very low threshold (near zero) since OSC should be error-free under normal conditions
• OTU/ODU Errors: Threshold based on error rate tolerance (e.g., 10^-9 BER equivalent)

Alarm Severity Levels and Interpretation

Critical Optical Layer Alarms:

1. Loss of Signal (LOS) Alarms:

• portLossOfLight: Physical layer LOS at port level, indicates no optical input power detected
• lossOfSignal (OTS): Multiplex level LOS including OSC, raised on ROADM degree RX ports
• lossOfSignal (OMS): DWDM multiplex LOS excluding OSC, masked by OTS LOS when both present
• lossOfSignal (OCH): Individual channel LOS, masked by OTS LOS at ROADM, used by controller for service tracking
• lossOfSignalOSC: OSC channel specific LOS, not masked by OTS LOS, indicates OSC failure

2. Reflection and Return Loss Alarms:

• reflectionTooHigh: Raised when measured ORL exceeds threshold (typically < 24 dB indicates problem)
• Can trigger automatic power reduction or automatic laser shutdown based on severity
• Reported on OTS-IF (with OSC) or OMS-IF (without OSC) depending on implementation
• Common causes: dirty connectors, sharp fiber bends, improper splices, back reflections from unterminated fibers

3. Power Level Alarms:

• opticalPowerDegraded: Power level outside expected range but not total loss
• powerOutOfSpecificationHigh/Low: Power levels exceed equipment specifications
• automaticLaserShutdown: Laser shut off due to safety mechanisms (high reflection, fiber break)
• automaticShutoffDisabled: Standing alarm indicating laser safety was manually disabled via RPC

OTN Layer Alarms:

• lossOfFrame (LOF): OTU framing lost, cannot maintain frame alignment
• lossOfMultiframe (LOM): OTU multiframe alignment lost
• backwardsDefectIndication (BDI): Far end detected defect and signaling via backward direction
• degradedEffect (DEG): Signal quality degraded beyond threshold (based on errored block count)
• trailTraceIdentifierMismatch (TTI): Expected vs actual TTI string mismatch
• alarmIndicationSignal (AIS): Upstream failure indication propagated downstream
• openConnectionIndication (OCI): ODU path not connected
• lockedDefect (LCK): Administrative lock signal received
• All OTN alarms available at PM layer and independently at TCM1-6 layers for granular fault isolation

Typical Alarm Correlation Scenarios

Scenario 1: Fiber Cut Detection

When a fiber is cut between two ROADM nodes, a cascade of alarms occurs. Understanding the correlation helps identify root cause:

1. Immediate Alarms (< 100ms):
   • OTS LOS at ROADM RX port (downstream of cut)
   • Automatic Laser Shutdown at ROADM TX port (upstream of cut, due to high reflection)
   • linkDown on OSC interface (LLDP neighbor loss)
2. Secondary Alarms (100ms - 1s):
   • OMS LOS at ROADM RX (masked if OTS LOS present)
   • OCH LOS for all wavelengths at ROADM RX
   • Optical Line Fail (composite alarm at ROADM)
3. Propagated Alarms (1-10s):
   • OCH LOS at transponder network port
   • OTU LOF at transponder (loss of framing)
   • ODU AIS propagated to client side
   • Client interface link down

Root Cause Identification: The combination of OTS LOS at downstream ROADM plus Automatic Laser Shutdown at upstream ROADM pinpoints fiber cut location. All other alarms are consequences.

Scenario 2: Degraded Optical Path

Gradual signal degradation from dirty connectors or fiber stress:

1. Early Warning (Days to Weeks Before Failure):
   • Pre-FEC error TCA threshold crossing
   • Optical power degraded warning
   • Gradual increase in BIP errors at OTU/ODU layer
2. Degraded Service (Hours Before Failure):
   • DEG alarm at OTU layer (error rate threshold exceeded)
   • FEC uncorrectable blocks appearing intermittently
   • BDI signaled from far end
3. Service Failure:
   • OTU LOF (cannot maintain FEC decoding)
   • OCH LOS (power dropped below threshold)
   • Full service outage

Root Cause Identification: The progression from TCA to DEG to LOF indicates gradual degradation rather than sudden failure. Pre-FEC error trends point to optical layer issues (connectors, fiber stress) rather than equipment failure.

Scenario 3: OSC Communication Failure

OSC link failure impacts management but data channels may continue operating:

• Symptoms:
  • lossOfSignalOSC alarm (OSC power below threshold)
  • linkDown on OSC Ethernet interface
  • Loss of LLDP neighbor on OSC
  • Unable to reach adjacent node via DCN over OSC
  • Data channels (OMS) still operational
• Impact:
  • Loss of topology discovery between nodes
  • Cannot reach remote node for management (if no alternate DCN path)
  • Laser safety coordination impaired
  • Services continue but node is partially isolated
• Root Causes: OSC pluggable failure, OSC wavelength attenuated (bad filter), OSC connector dirty, dedicated OSC fiber cut (in systems with separate OSC fiber)

LLDP Implementation Details

LLDP TLV Usage:

LLDP Discovery Workflow:

1. Each ROADM/ILA node transmits LLDP frames on all OSC interfaces at regular intervals (typically 30 seconds)
2. LLDP frame contains node-id (SysName TLV) and local OSC interface name (PortID TLV)
3. Adjacent node receives LLDP frame and stores neighbor information locally
4. Device issues lldp-nbr-info-change notification to controller when neighbor information changes (new neighbor, neighbor lost, or neighbor info updated)
5. Controller correlates transmitted LLDP information (node A, interface X) with received LLDP information (node B, interface Y) to determine link connectivity: Node A Interface X ↔ Node B Interface Y
6. Controller builds complete network topology by aggregating all LLDP neighbor relationships

Example LLDP Neighbor Notification:

<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
  <eventTime>2025-11-15T15:30:22Z</eventTime>
  <lldp-nbr-info-change xmlns="http://org/openroadm/lldp">
    <if-name>OSC-DEG1-TTP-TX</if-name>
    <remote-system-name>ROADM-NodeB</remote-system-name>
    <remote-port-id>OSC-DEG2-TTP-RX</remote-port-id>
    <remote-chassis-id>00:11:22:33:44:55</remote-chassis-id>
  </lldp-nbr-info-change>
</notification>

Topology Validation:

Controllers validate discovered topology against planned topology (OMS links provisioned on controller). Mismatches indicate incorrect cabling and generate alarms:

• Expected link not discovered via LLDP → fiber not connected or OSC failure
• Unexpected link discovered → incorrect fiber connection
• Node-id mismatch → wrong equipment installed at site

DCN Architecture with RSTP

Bridge Port Configuration:

• OAMP Port: Out-of-band management port, typically connected to operator's management LAN
• OSC Ports: In-band management over DWDM infrastructure, one OSC per degree
• All ports participate in single RSTP bridge instance
• RSTP selects one root bridge and computes loop-free paths

RSTP Benefits for OpenROADM:

• Prevents Layer 2 loops that would cause broadcast storms and network instability
• Enables redundant DCN paths for higher availability
• Automatically reconfigures upon link or node failure (fast convergence < 10 seconds)
• Allows flexible DCN topology design (mesh, ring, hybrid)

RSTP Notifications:

Devices issue notifications for significant spanning tree events:

• rstp-topology-change: Spanning tree topology has changed (port state transitions)
• rstp-new-root: New root bridge elected (significant topology change or root bridge failure)

Controllers monitor these notifications to track DCN topology health and detect potential issues.

Manifest File Architecture

The manifest file is a YANG-modeled document provided by equipment vendors to guide controllers through software operations. It defines a series of instruction-sets, each containing operations to be executed sequentially.

Manifest File Structure:

manifest {
  vendor: "VendorName"
  model: "ModelX-ROADM"
  sw-version: "2.0.5"
  
  instruction-set[1] {
    from-sw-version: "1.2.1"
    operation[1] {
      instruction: "transfer"
      parameters: {
        action: "download"
        remote-file-path: "sftp://user@server/sw/main_image.pkg"
        local-file-path: "/tmp/main_image.pkg"
      }
    }
    operation[2] {
      instruction: "sw-stage"
      parameters: {
        filename: "/tmp/main_image.pkg"
      }
    }
    operation[3] {
      instruction: "delete-file"
      parameters: {
        filename: "/tmp/main_image.pkg"
      }
    }
    operation[4] {
      instruction: "sw-activate"
      parameters: {
        version: "2.0.5"
        validationTimer: "01:00:00"
        rebootType: "automatic"
      }
    }
  }
}

Software Download Operation Sequence:

1. Pre-Download Validation:
   • Controller identifies target software version
   • Retrieves manifest file for target version from vendor (out-of-band)
   • Queries device current software version
   • Selects instruction-set matching current version in manifest
   • Validates available disk space on device
2. File Transfer Phase:
   • Controller issues transfer RPC (download action) as specified in manifest
   • Device initiates SFTP connection to controller's SFTP server
   • Device retrieves software file(s) to local storage
   • Device issues transfer-notification upon completion
3. Staging Phase:
   • Controller issues sw-stage RPC with software filename
   • Device validates software package integrity (checksums, signatures)
   • Device extracts software components to staging area
   • Device may download additional files from SFTP server (sub-packages, configuration files)
   • Device prepares for activation (database migration scripts, etc.)
   • Device issues sw-stage-notification upon completion
4. Optional File Cleanup:
   • Controller issues delete-file RPC for downloaded software package
   • Frees disk space while staged software remains available
5. Activation Phase:
   • Controller issues sw-activate RPC with version and optional validationTimer
   • Device marks new software version as active
   • Device performs automatic reboot (if specified in manifest)
   • Device boots into new software version
   • If validationTimer specified, software runs in validation mode
6. Validation Period (Optional):
   • Device operates with new software but maintains rollback capability
   • Some provisioning operations may be restricted during validation
   • Operator performs validation testing
   • validationTimer counts down from specified duration
7. Acceptance or Reversion:
   • If software acceptable: Controller issues cancel-validation-timer RPC, device commits to new software permanently
   • If software problematic: Validation timer expires or controller issues manual revert, device reboots back to previous software version

Service Impact Considerations:

• File transfer and staging: Non-service affecting (NE continues normal operation)
• Activation: Service affecting during reboot (typically 5-15 minutes downtime)
• Validation mode: Services operational but new service creation may be restricted
• Rollback: Service affecting during reboot

Database Backup Process

Database backup operations preserve device configuration for disaster recovery and migration scenarios:

1. Backup Initiation:
   • Controller determines backup filename (e.g., ROADM-Node1-20251115-backup.db)
   • Controller issues db-backup RPC with filename
2. Backup Execution:
   • Device creates snapshot of running configuration
   • Device serializes database to file format
   • Device stores file in local flat directory structure
   • Device issues db-backup-notification upon completion (success or failure)
3. File Transfer to SFTP Server:
   • Controller issues transfer RPC (upload action)
   • Device initiates SFTP connection and transfers file
   • Device issues transfer-notification upon completion
4. Local File Cleanup:
   • Controller issues delete-file RPC to remove backup from device
   • Backup remains archived on SFTP server

Backup Manifest Example:

manifest {
  vendor: "VendorName"
  model: "ModelX-ROADM"
  sw-version: "2.0.5"
  
  db-backup-instruction {
    operation[1] {
      instruction: "db-backup"
      parameters: {
        filename: "__LOCAL-FILE-PATH"
      }
    }
    operation[2] {
      instruction: "transfer"
      parameters: {
        action: "upload"
        local-file-path: "__LOCAL-FILE-PATH"
        remote-file-path: "sftp://user@server/backups/__REMOTE-FILENAME"
      }
    }
    operation[3] {
      instruction: "delete-file"
      parameters: {
        filename: "__LOCAL-FILE-PATH"
      }
    }
  }
}

Note: __LOCAL-FILE-PATH and __REMOTE-FILENAME are variables populated by controller at runtime.

Database Restore Process

Database restore enables recovery from configuration corruption or restoration to known-good state:

1. File Transfer from SFTP Server:
   • Controller issues transfer RPC (download action) with archived backup filename
   • Device retrieves database file from SFTP server
   • Device stores file locally
2. Restore Initiation:
   • Controller issues db-restore RPC with filename and optional node-id-check parameter
   • Device validates database file integrity
   • If node-id-check enabled, device verifies node-id in backup matches current node-id
3. Database Restoration:
   • Device loads database from file into memory
   • Device performs data validation and migration if necessary
   • Device issues db-restore-notification
4. Activation with Rollback Protection:
   • Controller issues db-activate RPC with optional rollbackTimer
   • Device commits restored database to persistent storage
   • Device performs automatic reboot
   • Device boots with restored configuration
5. Rollback Period (Optional):
   • Device operates with restored database but can rollback
   • Some operations restricted during rollback period
   • Operator validates restored configuration
6. Commit or Rollback:
   • If acceptable: Controller issues cancel-rollback-timer RPC, restoration permanent
   • If problematic: Timer expires or manual rollback issued, device reverts to pre-restore state

Critical Considerations:

• Node-ID Validation: Essential to prevent restoring wrong node's configuration
• Software Version Compatibility: Restored database must be compatible with current software version
• IP Address Impact: Restored database may contain different IP address, causing connectivity change
• Service Impact: Full service outage during restore and reboot process

Transport Layer Security

SSH v2 Implementation:

• All NETCONF sessions encrypted using SSH v2 (RFC 6242)
• Strong cipher suites recommended (AES-256, ChaCha20)
• Public key authentication supported in addition to password authentication
• Host key verification prevents man-in-the-middle attacks

SFTP for File Operations:

• All file transfers (software, database, PM files) use SFTP
• Device acts as SFTP client, controller/server acts as SFTP server
• Credentials embedded in URI or configured separately
• Default SFTP port 22, configurable port support optional

Authentication and Authorization

User Account Management:

• Default Account:
  • Username: openroadm
  • Password: openroadm
  • Must be changed during commissioning
  • Default account deleted after new accounts created
• Production Accounts:
  • Username: 3-32 characters, starts with lowercase letter, letters/numbers only
  • Password: 8-128 characters, letters/numbers/special characters (!$%^()_+~{}[].)
  • Forbidden characters: \ | ? # @ &
  • Currently single group: "sudo" (full access)

Role-Based Access Control Philosophy:

OpenROADM assumes RBAC is enforced at the controller level, not on individual devices. This aligns with SDN architecture where the controller mediates all interactions:

• Controller authenticates users and enforces role-based policies
• Controller uses single technical account for device communication
• Audit trails maintained at controller level
• Devices provide only basic account management

Session Management and Hardening

NETCONF Session Security:

• Each NETCONF session requires separate SSH tunnel
• No shared SSH connections for multiple NETCONF sessions
• Idle timeout configuration recommended to close inactive sessions
• Keep-alive messages prevent unintended timeout of active sessions

Physical Security Considerations:

• Factory reset mechanism must be physically protected (hidden button with clear labeling)
• No craft interface terminal functionality specified (reduces attack surface)
• Physical access to equipment should be controlled per site security policies

Automatic Laser Shutdown (ALS)

ALS provides rapid laser power reduction or shutdown when dangerous conditions are detected:

Trigger Conditions:

• High Reflection / Low ORL: When optical return loss drops below safe threshold (typically < 24 dB)
• OSC Communication Loss: Cannot coordinate with adjacent node for safe operation
• Fiber Break Detection: Sudden loss of far-end signal indicating possible fiber cut

ALS Response Behavior:

• Data channel lasers reduced to safe power levels or shut off completely
• OSC laser never shut off (required for restoration coordination)
• automaticLaserShutdown alarm raised immediately
• Automatic restoration when safe conditions restored

Manual ALS Disable:

Controllers can temporarily disable ALS during maintenance operations:

<rpc message-id="301">
  <disable-automatic-shutoff xmlns="http://org/openroadm/de/operations">
    <degree-number>1</degree-number>
    <timer>01:00:00</timer>
  </disable-automatic-shutoff>
</rpc>

Critical ALS Disable Rules:

• automaticShutoffDisabled standing alarm raised when ALS disabled
• Mandatory timer parameter (maximum duration vendor-dependent)
• ALS automatically re-enables when timer expires
• Only authorized personnel should disable ALS
• Maintenance personnel must use appropriate laser safety equipment

Automatic Power Reduction (Optional)

Some implementations support gradual power reduction rather than complete shutdown:

• Reduces optical power to safe levels during high reflection events
• Maintains reduced-capacity service rather than complete outage
• automaticPowerReduction alarm indicates reduced power state
• Automatically restores full power when conditions normalize

Conclusion

OpenROADM represents a transformative approach to optical network infrastructure, breaking down traditional barriers between equipment vendors and enabling true disaggregation of optical networks. Through standardized interfaces (W, Wr, MW, MWi, OSC), comprehensive YANG-based device models, and sophisticated management protocols via NETCONF, OpenROADM empowers network operators to build flexible, scalable, and cost-effective optical transport networks.

The framework's support for colorless/directionless ROADMs, flexible grid architectures, advanced OTN switching, and comprehensive performance monitoring provides operators with powerful tools for network optimization and service delivery. The standardized discovery and commissioning procedures, combined with detailed provisioning workflows, enable rapid deployment and automation at scale.

As the MSA continues to evolve through collaborative development and vendor implementations mature, OpenROADM is positioned to become the foundational standard for next-generation optical networking, driving innovation while reducing costs and operational complexity for network operators worldwide.

Note: This guide is based on industry standards, best practices, and real-world implementation experiences. Specific implementations may vary based on equipment vendors, network topology, and regulatory requirements. Always consult with qualified network engineers and follow vendor documentation for actual deployments.