Optical & transport
Configuration management for optical networks
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
PROOF AT SCALE
rConfig brings the optical and transport layer up to the same standard as IP, across every vendor, on infrastructure you own.
- All
- optical vendors
- TL1
- spoken natively
- 1
- configuration standard
- 200k
- validated at scale
one neutral plane across every transport vendor in the estate
the legacy transport protocol most NCM tools cannot handle
IP and optical, core to edge, held to one standard
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 challenge
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.
Independence
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.
Capabilities
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.
TRANSPORT
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.
Learn morePROTOCOLS
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.
Learn moreBACKUP
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.
Learn moreOPERATIONS
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.
Learn moreCOMPLIANCE
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.
Learn moreINTEGRATION
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.
Learn more
Protocol depth
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.
Solutions and deeper reading
- 01In clusterTL1 configuration managementThe legacy transport command protocol in depth: TL1 quirks, why most NCM tools struggle, and how rConfig manages TL1 estates at scale.
- 02Solutionmulti-vendor configuration managementOne neutral plane across every vendor in the estate, IP and optical alike.
- 03ReferencerConfig reference architectureHow the platform is engineered to run 100k+ device fleets.
TALK TO US
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.
Tell us your device count, vendor mix, and project timeline, and we will map a rollout to your estate.