✨ AI
Sign inBook a demo
Optical network management

TL1 configuration management

TL1 is still how most optical transport gets managed, and most configuration tools still pretend it isn’t there. rConfig backs up, versions and diffs TL1 network elements next to your routers and switches, in the same inventory, on the same schedule.

Native TL1 drivers for Ciena 6500, Cisco ONS 15454 and Infinera DTN-X, in rConfig 8.3 and later.

Book a demo

The protocol nobody else wants to handle

TL1, Transaction Language 1, came out of Bellcore in the 1980s and never left. SONET, SDH, DWDM and OTN kit from every major optical vendor still speaks it, and on plenty of shelves it is the only complete management interface there is.

It was designed for operators at terminals and the OSS systems that sat behind them, not for the scripts most configuration tools are built around. Commands are positional. Login happens inside the session. Responses arrive as quoted records, sometimes in pages, sometimes with alarms interleaved. Point a router-shaped tool at it and you get a backup file full of DENY.

So the optical layer ends up in a spreadsheet, or a folder of screenshots, or the head of the one engineer who knows the gateway TIDs. We think it belongs in the same place as the rest of the network.

How a TL1 backup runs in rConfig

Here is what actually happens when rConfig collects from a TL1 shelf. The session below is from a simulated Ciena 6500.

  1. Connect over SSH

    rConfig opens the session. On TL1 that gets you a pipe, not a login.

  2. Log in with ACT-USER

    Authentication is a TL1 command. rConfig sends it and checks for COMPLD before anything else runs. Until then the NE answers every command with DENY PLNA.

  3. Retrieve

    The driver runs its retrieval set for that platform, each command with its own CTAG, and matches every response on the CTAG rather than on arrival order.

  4. Walk the remotes

    On a gateway, rConfig discovers the remote NEs behind it and routes each one's commands through the TID. Every RNE gets its own entry, its own history and its own diff.

  5. Version and compare

    Each retrieval is stored as a new version and compared with the last. A DENY is recorded as a failed collection with its code, not saved as a backup.
Ciena 6500, simulated
ACT-USER::admin:CTAG002::admin;
   CIENA-LAX-1001 26-06-07 11:42:18
M  CTAG002 COMPLD
   /*AUTHTYPE=LOCAL*/
   /*USERID=ADMIN*/
;

RTRV-EQPT::ALL:CTAG003;
   CIENA-LAX-1001 26-06-07 11:42:25
M  CTAG003 COMPLD
   "SHELF-1::PROVISIONED,TYPE=6500-7SLOT,SN=LBCQ7F3K1P,SWVER=12.4,IP=127.0.0.1:IS-NR"
   "SLOT-1:OTR2,CLEI=WMOTH4K2NP,SN=LBCQ7F3K1P01,PN=NTK547C:IS-NR"
   "SLOT-2:WL3N,CLEI=WMOT8J3D0Q,SN=LBCR4T7Y2K02,PN=NTK583F:IS-NR"
   "SLOT-7::UNEQUIPPED:OOS-AUMA"
;

Simulated Ciena 6500 session from rConfig Sim. Names and serials are illustrative.

Supported TL1 platforms

Every vendor implemented TL1 a little differently, and the differences are where collection breaks. Each driver below handles its platform's quirks so you don't have to.

  • Ciena 6500

    Standalone shelves and gateway NEs with remote NEs behind them. rConfig discovers the remotes with RTRV-NE-LIST, adds the gateway itself (the list leaves it out), and routes each RNE’s retrievals through the TID.GNE/RNE routing on the 6500, with session outputCollectedRTRV-SYSRTRV-SW-VERRTRV-EQPTRTRV-ALM-ALLRTRV-COND-ALL

  • Cisco ONS 15454

    Gateway and ENE inventory comes from RTRV-MAP-NETWORK, which returns positional records with no keywords at all, and lists the gateway first. The driver parses by position and reads each element’s own product model from the record.CollectedRTRV-MAP-NETWORKRTRV-SW-VERRTRV-EQPTRTRV-ALM-ALLRTRV-COND-ALL

  • Infinera DTN-X

    The DTN-X prompts with > rather than <, pages its remote node map across several response blocks, and answers routed commands with the gateway’s own name in the header. The driver reads every page to the final COMPLD before sending the next command, so one long answer can’t throw the CTAG matching off for the rest of the session.CollectedRTRV-SYSRTRV-TIDMAPRTRV-SW-VERRTRV-EQPTRTRV-ALM-ALLRTRV-COND-ALL

Running something else that speaks TL1? Drivers are template-based and can be extended. Talk to us.

TL1 automation without the scripts

Most TL1 automation in the wild is an expect script someone wrote in 2009, still running from cron on a box nobody wants to reboot. It works until the person who wrote it leaves.

rConfig replaces that with scheduled, parallel collection across every TL1 network element, each retrieval versioned and diffable, every failure recorded with its DENY code. The same scheduler, RBAC and audit trail you use for the IP side cover the optical side.

  • Versioned TL1 backup

    Scheduled, parallel collection keeps every TL1 network element backed up on a tight cadence. Each retrieval is versioned and diffable from the first poll, so a known-good config is always one click away.

  • Change you can prove

    Every TL1 change is captured with a before and after, attributed to a user, and held in a full audit trail. The transport layer answers to the same RBAC and evidence standard as the rest of the estate.

  • Legacy sessions at scale

    TL1 sessions are slow and stateful, and older gear is easily overwhelmed. Queue-driven, rate-aware collection holds thousands of network elements to a backup cadence without flooding the management plane.

  • Every vendor's dialect

    No two vendors implement TL1 quite the same way, Cisco ONS and Infinera DTN-X included. Template-driven, customer-extensible drivers absorb the dialect differences, so adding a new transport platform is a configuration change, not a wait for a roadmap.

PROOF AT SCALE

Tested against thousands of simulated NEs

  • TL1native support

    Ciena 6500, Cisco ONS 15454 and Infinera DTN-X

  • 1platform

    TL1 alongside CLI, NETCONF and REST, one estate, one standard

  • 1,000ssimulated TL1 elements

    protocol behaviour tested at scale with rConfig Sim

  • 24/7scheduled collection

    versioned TL1 backup on a tight, parallel cadence

Every driver is tested against rConfig Sim, our open source device simulator, which models each platform’s quirks: in-band login, GNE/RNE routing, paged responses and all.

rConfig Sim on GitHub · TL1 driver reference

Scale figures are approximate and validated against simulated estates with rConfig Sim.

TL1 questions

Can rConfig back up TL1 devices?

Yes. rConfig 8.3 and later includes native TL1 drivers for Ciena 6500, Cisco ONS 15454 and Infinera DTN-X. Retrievals are scheduled, versioned and diffed like any other device in rConfig.

Does rConfig support Ciena GNE/RNE topologies?

Yes. rConfig connects to the gateway NE, discovers the remote NEs behind it with RTRV-NE-LIST, and routes each remote's retrievals through the TID. Each remote NE is stored and versioned as its own device.

How does rConfig connect to TL1 network elements?

Over SSH, with TL1 login handled in-band by ACT-USER once the session is up. rConfig checks for a COMPLD login before running any retrieval.

What happens when a TL1 command is denied?

The collection is marked as failed and the DENY code is recorded, for example PLNA for a failed login or IIAC for an unreachable remote NE. A denied response is never saved as a configuration version.

Which TL1 commands does rConfig run?

It depends on the platform. On a Ciena 6500 the driver collects RTRV-SYS, RTRV-SW-VER, RTRV-EQPT, RTRV-ALM-ALL and RTRV-COND-ALL, plus RTRV-NE-LIST on gateways. Cisco ONS 15454 and Infinera DTN-X use their own equivalents for network discovery.

Can I manage TL1 and IP devices in the same rConfig instance?

Yes. TL1 network elements sit in the same inventory as your routers, switches and firewalls, under the same schedules, RBAC and audit trail.

Bring TL1 into one standard

See rConfig manage a TL1-speaking transport estate, backed up, audited, and controlled. Book a working demo, or talk to our team about your network.

Book a demo