Optical Control Plane and Automation

The optical control plane is what turns a static collection of fibres, EDFAs, ROADMs, and transponders into a programmable network — one where new circuits can be turned up in minutes rather than weeks, where restoration after a failure happens automatically, and where impairments are computed and respected as a routing constraint. Two parallel architectures dominate today: GMPLS (the IETF distributed-signalling lineage extended to lambda-switching, with WSON profiles) and SDN-style controllers (NETCONF/YANG over OpenConfig and OpenROADM, with PCE for path computation). This chapter covers the protocols, the data models, and the closed-loop automation patterns that ride on top of them.

Concept	What it says
GMPLS for the optical layer	Generalised MPLS extends RSVP-TE to signal Lambda-Switched Capable (LSC) LSPs and OSPF-TE to advertise wavelength-resource information across optical NEs. Distributed control, long-deployed in carrier networks.
WSON — Wavelength Switched Optical Network	The IETF profile specifically for impairment-aware optical-layer routing and wavelength assignment. RFC 6163 (framework), RFC 7689 (RWA), RFC 7581 (impairment-aware extensions).
NETCONF / YANG models	Configuration-and-state plane: NETCONF transports YANG-described data. The two main optical-domain model bodies are OpenConfig terminal-device (vendor-neutral transponder model) and OpenROADM device (vendor-neutral line-system NE model).
Closed-loop automation	The end goal: telemetry streams from optical NEs feed analytics, analytics produce intent (e.g. “raise OSNR margin on circuit X”), and a controller pushes configuration changes to act on that intent — without human intervention.

GMPLS for the Optical Layer

GMPLS — Generalized Multi-Protocol Label Switching, RFC 3945 et seq. — extends MPLS signalling and routing protocols to non-packet switching domains, including Lambda-Switched-Capable (LSC) interfaces where the “label” is an optical wavelength. The core extensions:

Protocol	Extension	Role
RSVP-TE for GMPLS (RFC 3473)	LABEL_SET, GENERALIZED_LABEL, BIDIRECTIONAL flag, EXPLICIT_ROUTE	Signal an LSC LSP — i.e., reserve a specific wavelength end-to-end
OSPF-TE for GMPLS (RFC 4203)	Link Local/Remote Identifiers, Interface Switching Capability Descriptor	Advertise per-link wavelength availability and switching capability
LMP Link Management Protocol (RFC 4204)	Hello, Link Property Correlation, Link Verification	Discover and verify optical adjacencies between non-IP-addressable optical interfaces

In a GMPLS-controlled WDM network, every NE runs an OSPF-TE instance advertising its links’ wavelength capabilities. When a new circuit must be established, the source NE (or an external PCE) computes an explicit route, then RSVP-TE signals the path hop-by-hop with each NE configuring its WSS or transponder to realise the requested wavelength.

Key Insight

The distinction between MPLS and GMPLS is not “more protocols” — it is what the label means. In MPLS, a label is a 20-bit number in a packet header. In GMPLS, a label can be a wavelength index, a TDM time-slot, or a fibre-port number. The signalling and routing protocols are the same RSVP-TE and OSPF-TE, with type-specific encodings.

WSON — Wavelength Switched Optical Network

WSON (RFC 6163, RFC 7449, RFC 7689, RFC 7581) is the IETF’s framework for applying GMPLS specifically to wavelength-routed optical networks, addressing two problems that vanilla GMPLS does not solve:

Routing and Wavelength Assignment (RWA) — picking a path is not enough; a specific wavelength must be selected, and a wavelength may not be reusable along a continuous path unless wavelength conversion is available at intermediate nodes.
Impairment-aware routing — the optical path must be physically feasible. OSNR, chromatic dispersion, PMD, and nonlinear penalties must all be within the receiver’s tolerance.

RFC	Topic	What it adds
RFC 6163	WSON framework	Architecture: PCE roles, optical-link advertisement, RWA models
RFC 7449	Information model for impairment-aware WSONs	Data model for per-link impairment characterisation
RFC 7581	Impairment-aware encoding	OSPF-TE / PCEP TLVs for impairment data
RFC 7689	Routing and Wavelength Assignment	RWA algorithms and signalling extensions
RFC 8780	Impairment-aware routing for WSON-IA	YANG-based impairment-data model

Warning

RWA is NP-hard in the general case. Production WSON implementations use heuristics (first-fit, most-used, least-used), not exhaustive search. The choice of heuristic affects how quickly the network defragments and how often a new wavelength request fails for “no continuous path” reasons even when capacity is available.

Path Computation Element

PCE (RFC 4655) is a stateless or stateful entity that computes paths on behalf of NEs. In an optical network, PCE-based RWA is centralised — one or a few PCE instances see the whole topology, including impairment data, and can make globally-optimised decisions that a distributed RSVP-TE signalling cannot match.

PCE flavour	Specification	Role in optical
Stateless PCE	RFC 4655 / RFC 5440	Computes a path on request, has no persistent view of in-place LSPs
Stateful PCE	RFC 8231	Maintains an LSP database; can re-optimise existing LSPs
Stateful PCE-initiated	RFC 8281	Can also initiate, modify, and delete LSPs (full SDN-style control)
Impairment-aware PCE (IA-PCE)	RFC 7449/7581/8780	Knows per-link OSNR, CD, PMD; computes feasibility, not just shortest path

PCEP (RFC 5440) is the protocol between a Path Computation Client (PCC, typically a head-end NE) and the PCE. For optical networks it carries WSON-IA-specific TLVs describing impairment requirements and wavelength constraints.

Control-Plane Reference Architecture

flowchart TB
    subgraph DATAPLANE ["Data plane"]
        IPRTR["IP / MPLS router"]
        TRANS["Coherent transponder<br/>OpenConfig terminal-device"]
        ROADM1["ROADM A<br/>OpenROADM device"]
        ROADM2["ROADM B"]
        ROADM3["ROADM C"]
    end
    subgraph CONTROL ["Control plane / management"]
        OLS["OLS controller<br/>per-domain optical NMS<br/>OpenROADM / vendor SDN"]
        PCE["PCE / IA-PCE<br/>RWA + impairment-aware<br/>path computation"]
        ORCH["Multi-layer<br/>orchestrator<br/>IETF te-topology<br/>OpenConfig"]
        TELEM["Streaming telemetry<br/>+ analytics"]
    end
    IPRTR -->|"NETCONF/gNMI<br/>OpenConfig"| ORCH
    TRANS -->|"NETCONF/gNMI<br/>OpenConfig"| ORCH
    ROADM1 -->|"NETCONF<br/>OpenROADM"| OLS
    ROADM2 --> OLS
    ROADM3 --> OLS
    OLS -->|"abstracted<br/>topology"| ORCH
    ORCH -->|"PCEP"| PCE
    PCE -->|"computed paths"| ORCH
    TRANS -->|"streaming<br/>telemetry"| TELEM
    ROADM1 -.-> TELEM
    TELEM -->|"analytics<br/>findings"| ORCH
    style IPRTR fill:#378ADD,stroke:#185FA5,color:#fff
    style TRANS fill:#7F77DD,stroke:#534AB7,color:#fff
    style ROADM1 fill:#1D9E75,stroke:#0F6E56,color:#fff
    style ROADM2 fill:#1D9E75,stroke:#0F6E56,color:#fff
    style ROADM3 fill:#1D9E75,stroke:#0F6E56,color:#fff
    style OLS fill:#BA7517,stroke:#854F0B,color:#fff
    style PCE fill:#D85A30,stroke:#993C1D,color:#fff
    style ORCH fill:#E24B4A,stroke:#A32D2D,color:#fff
    style TELEM fill:#7F77DD,stroke:#534AB7,color:#fff

The two-tier model: domain controllers (OLS for optical, IGP/PCE for IP) abstract their domains; a multi-layer orchestrator stitches them together. Streaming telemetry feeds back into the orchestration loop.

GMPLS vs SDN-Controller Models

The industry has gradually moved from pure-distributed GMPLS toward centralised-SDN models, but neither has fully displaced the other.

Dimension	GMPLS distributed	SDN-controller centralised
Routing protocol	OSPF-TE / IS-IS-TE on every NE	None — controller has direct topology view
Signalling	RSVP-TE end-to-end	Direct NETCONF push to each NE
Path computation	Distributed (CSPF) or PCE-assisted	Always centralised PCE / orchestrator
Failure behaviour	Distributed reconvergence	Controller-driven restoration
Vendor diversity	Specified in RFCs but implementations diverge	YANG-model based (OpenROADM/OpenConfig) — better
Time-to-deploy new feature	Years (RFC + vendor implementation cycle)	Months (controller + YANG augmentation)
Operational maturity	Decades — battle-tested	~5–10 years — improving rapidly
Best fit	Existing brownfield carriers	Greenfield / disaggregated networks

In practice, large carriers run both: GMPLS for the photonic layer’s distributed restoration where it exists, with an SDN orchestrator on top providing service provisioning and impairment-aware path computation through a stateful PCE.

NETCONF / YANG Models

NETCONF (RFC 6241) is the transport protocol; YANG (RFC 7950) is the data-modelling language. The combination replaces SNMP+CLI for configuration and state retrieval. For optical, three model bodies matter:

Model body	Maintained by	Scope	Maturity
OpenConfig terminal-device	OpenConfig Working Group (operator-led)	Coherent transponders, IPoDWDM line interfaces	Production at hyperscale, large carriers
OpenROADM device	OpenROADM MSA	Line-system NEs (ROADMs, EDFAs, OLAs)	Production at AT&T, growing adoption
IETF te-topology + ietf-te + ietf-network	IETF TEAS/CCAMP WGs	Topology and TE-LSP modelling, network-level abstraction	Reference for orchestrator-NE interfaces
Vendor-native YANG	Each vendor	Everything the model bodies above don’t yet cover	Universal but non-portable

YANG-Model Coverage Matrix

Concern	OpenConfig	OpenROADM	IETF te-topology	Notes
Coherent transponder (frequency, modulation, FEC)	yes (terminal-device)	partial	no	OC strongest here
ROADM / WSS / OLA (line-system)	no	yes (device model)	no	ORM strongest here
Network-level topology abstraction	partial	partial	yes	te-topology is the lingua franca
Optical impairment data	gap	partial (per-port spectral)	gap	Active IETF/OC work
Streaming telemetry path	yes (gNMI)	partial	n/a	gNMI dominant
Multi-vendor disaggregated line system	gap	yes	n/a	ORM is the open-line-system standard
Inventory / hardware components	yes (oc-platform)	yes	n/a	Broad parity
Service provisioning (L1 EVC)	gap	partial	yes (ietf-te)	Orchestrator territory

Note

The two model bodies are not in direct competition — OpenConfig is transponder-centric (terminal-device endpoints), OpenROADM is line-system-centric (ROADM/EDFA/OLA NEs in the middle). A complete disaggregated network uses both: OpenConfig on the transponders, OpenROADM on the line system, IETF te-topology to abstract the whole thing for an orchestrator.

Telemetry and Closed-Loop Automation

The control plane configures; telemetry observes and feeds the next configuration cycle. Modern optical NEs support gNMI (gRPC Network Management Interface) streaming subscriptions on a curated set of metrics:

Metric	Source	Use case
Pre-FEC BER	Coherent transponder DSP	Q-margin tracking, modulation-format eligibility
OSNR (in-band, DSP-derived)	Coherent transponder	Fault detection, reach prediction
Channel power per channel	OPM at every ROADM degree	Tilt detection, EDFA gain control
Fibre input power	EDFA / OLA	Span-loss creep detection
Polarisation rotation rate	DSP	Detection of cable disturbance, vibration alerts
Equaliser tap coefficients	DSP	Subtle impairment fingerprinting

The closed-loop pattern:

flowchart LR
    NE["Optical NE<br/>transponder + ROADM"] -->|"gNMI streaming<br/>1 s cadence"| COLLECTOR["Collector<br/>+ time-series DB"]
    COLLECTOR --> ANALYTICS["Analytics<br/>anomaly detection<br/>trend analysis"]
    ANALYTICS -->|"finding:<br/>OSNR margin<br/>declining 0.3 dB/month"| INTENT["Intent layer<br/>'raise margin on circuit X'"]
    INTENT --> PCE["PCE / orchestrator<br/>compute remediation"]
    PCE -->|"new path?<br/>modulation step?<br/>power tweak?"| ACTION["NETCONF push<br/>to NEs"]
    ACTION --> NE
    style NE fill:#1D9E75,stroke:#0F6E56,color:#fff
    style COLLECTOR fill:#7F77DD,stroke:#534AB7,color:#fff
    style ANALYTICS fill:#BA7517,stroke:#854F0B,color:#fff
    style INTENT fill:#D85A30,stroke:#993C1D,color:#fff
    style PCE fill:#E24B4A,stroke:#A32D2D,color:#fff
    style ACTION fill:#378ADD,stroke:#185FA5,color:#fff

Rule of Thumb

The closed loop’s biggest practical risk is oscillation — the controller corrects, telemetry reports the change, the controller over-corrects, telemetry reports again, and the system hunts. Damping (large hysteresis margins, slow integration windows) and rate-limiting (no more than one action per circuit per hour) are mandatory before letting a closed loop write to production NEs.

Control Plane vs Management Plane

The two terms are sometimes conflated, but the distinction matters operationally:

Aspect	Control plane	Management plane
What it does	Live signalling: establish, restore, tear down LSPs in real time	Configuration push, inventory, fault collection
Time horizon	Milliseconds to seconds	Minutes to hours
Protocol examples	RSVP-TE, OSPF-TE, LMP, PCEP	NETCONF, gNMI, RESTCONF, SNMP
Failure-handling	Reactive — switches in place	Audit and remediation
State location	In-NE FIB / TE-LSDB	Centralised orchestrator DB
Operates without controller?	Yes, if distributed (GMPLS)	No
Trust boundary	Inside the network	Operator’s NMS / OSS

In a fully SDN-controlled disaggregated optical network the line blurs — both planes flow through the same NETCONF/YANG pipe. But the conceptual separation is still useful: live signalling decisions need to be sub-second and survive controller outages, while configuration push can take minutes and assume controller availability.

References

Standards (IETF) — GMPLS

RFC 3945 — Generalized Multi-Protocol Label Switching (GMPLS) Architecture (10/2004). https://www.rfc-editor.org/rfc/rfc3945
RFC 3473 — Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions (01/2003). https://www.rfc-editor.org/rfc/rfc3473
RFC 4203 — OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) (10/2005). https://www.rfc-editor.org/rfc/rfc4203
RFC 4204 — Link Management Protocol (LMP) (10/2005). https://www.rfc-editor.org/rfc/rfc4204

Standards (IETF) — WSON / PCE

RFC 4655 — A Path Computation Element (PCE)-Based Architecture (08/2006). https://www.rfc-editor.org/rfc/rfc4655
RFC 5440 — Path Computation Element (PCE) Communication Protocol (PCEP) (03/2009). https://www.rfc-editor.org/rfc/rfc5440
RFC 6163 — Framework for GMPLS and Path Computation Element (PCE) Control of Wavelength Switched Optical Networks (WSONs) (04/2011). https://www.rfc-editor.org/rfc/rfc6163
RFC 7449 — Path Computation Element Communication Protocol (PCEP) Requirements for the Support of GMPLS (08/2014). https://www.rfc-editor.org/rfc/rfc7449
RFC 7581 — Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks (06/2015). https://www.rfc-editor.org/rfc/rfc7581
RFC 7689 — Signaling Extensions for Wavelength Switched Optical Networks (11/2015). https://www.rfc-editor.org/rfc/rfc7689
RFC 8231 — Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE (09/2017). https://www.rfc-editor.org/rfc/rfc8231
RFC 8281 — Path Computation Element Communication Protocol (PCEP) Extensions for PCE-initiated LSP Setup in a Stateful PCE Model (12/2017). https://www.rfc-editor.org/rfc/rfc8281
RFC 8780 — YANG Data Model for Routing and Wavelength Assignment (RWA) Networks (07/2020). https://www.rfc-editor.org/rfc/rfc8780

Standards (IETF) — NETCONF / YANG

RFC 6241 — Network Configuration Protocol (NETCONF) (06/2011). https://www.rfc-editor.org/rfc/rfc6241
RFC 7950 — The YANG 1.1 Data Modeling Language (08/2016). https://www.rfc-editor.org/rfc/rfc7950
RFC 8345 — A YANG Data Model for Network Topologies (03/2018). https://www.rfc-editor.org/rfc/rfc8345
RFC 8795 — YANG Data Model for Traffic Engineering (TE) Topologies (08/2020). https://www.rfc-editor.org/rfc/rfc8795

Industry consortia

OpenConfig — terminal-device YANG models. https://www.openconfig.net/
OpenROADM MSA — device YANG models. http://openroadm.org/
Telecom Infra Project (TIP) Open Optical & Packet Transport — Reference architecture for disaggregated optical. https://telecominfraproject.com/

Books

R. Ramaswami, K. N. Sivarajan, G. H. Sasaki, Optical Networks: A Practical Perspective, 3rd ed., Morgan Kaufmann, 2009.
A. Farrel, J.-P. Vasseur, Network Recovery: Protection and Restoration of Optical, SONET-SDH, IP, and MPLS, Morgan Kaufmann, 2004.

Transport Network Guide

Explorer

Ch 12 — Optical Control Plane and Automation

Optical Control Plane and Automation

GMPLS for the Optical Layer

WSON — Wavelength Switched Optical Network

Path Computation Element

Control-Plane Reference Architecture

GMPLS vs SDN-Controller Models

NETCONF / YANG Models

YANG-Model Coverage Matrix

Telemetry and Closed-Loop Automation

Control Plane vs Management Plane

See Also

References

Standards (IETF) — GMPLS

Standards (IETF) — WSON / PCE

Standards (IETF) — NETCONF / YANG

Industry consortia

Books

Graph View

Table of Contents

Backlinks