Optical Network Operations at Scale
Back up, audit, and control the optical and transport layer the way you already manage IP, across every vendor's kit, TL1 and all, on one platform with no hardware to sell you.
roadm-lhr-00 ·Ciena ·TL1 ok
- WAVELENGTHS
- 80
- VENDORS
- 8
- PROTOCOLS
- 4
- STANDARD
- 1
rConfig brings the optical and transport layer up to the same standard as IP, across every vendor, on infrastructure you own.
- Alloptical vendors
one neutral plane across every transport vendor in the estate
- TL1spoken natively
the legacy transport protocol most NCM tools cannot handle
- 1configuration standard
IP and optical, core to edge, held to one standard
- 200kvalidated at scale
platform behaviour proven against estates of up to 200,000 simulated devices
Scale figures are approximate and validated against simulated estates with rConfig Sim.
The layer everyone else buries
The optical and transport layer carries everything above it, yet it is the layer most network configuration tools treat as out of scope. Generic NCM platforms model routers and switches well and then stop at the transport boundary, leaving DWDM, OTN, SONET and SDH gear to whatever element manager shipped with the hardware.
That gap has a cost. Optical configuration drifts unnoticed because nothing outside the vendor’s own tooling is watching it. Backups live in a silo, change is manual, and an audit of the transport estate means logging into a different system for every vendor. The optical layer ends up managed to a lower standard than the IP layer that depends on it, which is exactly backwards.
Manage the network you have, not the one a vendor wants you to buy
An optical estate is multi-vendor by necessity. It is built up over years of procurement cycles, and the transport gear in the ground spans Ciena, Nokia, Infinera, Adtran, Cisco, Juniper, Ribbon and Fujitsu, often several of them in the same metro. Managing all of it to one standard only works if the management layer is genuinely neutral.
rConfig sells no network hardware. There is no transport line to protect and no reason to favour one optical vendor over another, so neutrality here is structural, not a marketing promise. Driver support is template-driven and customer-extensible, which means a new optical platform is a configuration change rather than a feature request you wait a release cycle for. Every vendor’s kit lands in one inventory, under one configuration standard, on one neutral plane.
That breadth is the proof, not the claim. See multi-vendor configuration management for how the same neutral model holds across the whole estate, IP and optical alike.
What it has to do
The same disciplines you expect on the IP layer, brought to the transport layer and held without manual effort across every vendor in the estate, at the carrier scale covered in managing 100,000 network devices.
Every optical vendor, one plane
Manage transport configuration across DWDM, OTN, SONET and SDH gear from every vendor in the estate. Drivers are template-driven and customer-extensible, so a new optical platform is a config change, not a wait for a vendor roadmap.
TL1, CLI, NETCONF, REST
Reach the transport layer however it speaks, including TL1, the legacy command protocol most generic NCM tools cannot handle. IP and optical live in one inventory, on one configuration standard.
Versioned transport backup
Scheduled, parallel collection keeps every optical node backed up on a tight cadence. Every config is versioned and diffable from the first poll, so you always have a known-good to compare against and restore.
Drift and change observability
See what changed on the transport layer, where, by whom, and when. Real-time change detection turns silent optical drift into an alert operations can act on before it becomes a service-affecting fault.
Policy checks and audit trails
Run continuous policy checks against every collected optical config, flag drift on change, and hold the transport estate to the same RBAC and audit standard regulators expect of the IP layer.
Into your existing stack
An open API and webhook model means optical configuration data flows into the OSS, ticketing, and automation you already run. The transport layer stops being a silo only the vendor's element manager can see.
Down to TL1, the protocol others avoid
Much of the installed transport base still speaks TL1, the legacy command protocol of SONET, SDH, DWDM and OTN gear. It is verbose, quirky, and unlike anything a modern CLI parser expects, which is a large part of why generic NCM tools quietly leave optical alone. rConfig handles TL1 natively, as a first-class protocol alongside CLI, NETCONF and REST.
If your transport estate lives or dies on TL1, that depth is the detail worth reading next. See TL1 configuration management for the protocol’s quirks, why most tools struggle with it, and how rConfig manages TL1 estates at scale.
Bring the optical layer up to one standard
See rConfig manage a multi-vendor optical and transport estate, TL1 and all. Book a working demo, or talk to our team about your network.