Building Multivendor Optical Link Planning, Design, and Simulation Platforms for Operators
A complete engineering reference for architecting an operator-grade vendor-neutral planning tool. Backend, frontend, equipment library, repository layout, and the GNPy QoT engine — covered end to end with the depth needed to ship a production system.
1. Abstract and Executive Summary
The optical transport industry has crossed a structural threshold. Networks are no longer built end-to-end from a single vendor's hardware and software; instead, operators source transponders, line systems, ROADMs, and management plane components from multiple suppliers and integrate them through open interfaces. This shift creates a planning problem that traditional vendor-supplied tools cannot solve. A planning tool tied to one vendor's hardware library cannot validate a service running over another vendor's transponder, on a third vendor's amplifier line, traversing a fourth vendor's ROADM. The operator needs a vendor-neutral planning, design, and simulation platform that treats the physical layer as a set of physically defined, calibrated components rather than as proprietary product configurations.
This article is an in-depth reference for engineers and architects building such a platform. It covers the physics that the platform must implement, the open-source GNPy library that supplies that physics, the surrounding software layers an operator-grade product needs, including project management, multi-tenant authentication, equipment library, reporting, and SDN integration. It includes the reference repository layout, the Python and JavaScript libraries to use, and the workflow an operator follows from topology entry to feasibility report. Performance benchmarks, real-world deployments, and the limits of the GN model are addressed in turn. By the end, a planning team has a complete blueprint for designing a system that supports multivendor service feasibility, accurate enough for real network deployment and flexible enough to grow with new transceivers, fiber types, and amplifier classes.
Three findings recur across the document. First, GNPy is the only credible foundation for a vendor-neutral physical layer engine; reimplementing the GN model in-house adds cost without adding accuracy or credibility. Second, GNPy is a library, not a product; the surrounding application — UI, backend services, project storage, equipment library curation, reporting — is where an operator's planning team adds its own value. Third, the multivendor problem is solved not by picking the best single tool but by combining a calibrated GN model, a curated equipment library, and disciplined margin policies that account for the irreducible uncertainty between vendor datasheets and field reality.
2. Introduction — Why This Tool, Why Now
For three decades, optical transport networks were built as monolithic single-vendor systems. The operator bought transponders, multiplexers, amplifiers, ROADMs, and a management plane from one supplier; planning was done in that supplier's proprietary tool with that supplier's equipment library. The model was effective when capacity grew predictably and one technology generation lasted a decade. It is no longer effective. As of 2026, three forces have made multivendor optical networks the dominant deployment model for new builds in the metro, regional, and data center interconnect (DCI) segments.
The first force is the rise of pluggable coherent optics. The OIF 400ZR specification, followed by the OpenZR+ multi-source agreement and now 800ZR/800LR work, separated the transponder from the line system. A 400ZR pluggable in a router or switch can light up a wavelength on any compliant open line system; the operator no longer has to buy the transponder from the line system vendor. The second force is the maturity of open APIs — TAPI, NETCONF/YANG, OpenROADM, OpenConfig — that let an operator's SDN controller talk to equipment from different vendors through the same management plane. The third force is operator economics. Buying every layer from one vendor delivers integration but at a 30 to 50 percent premium over best-of-breed multivendor. Hyperscalers proved the multivendor approach at scale; tier-1 operators followed; tier-2 and enterprise operators are following now.
The planning gap appears at the moment the operator commits to a multivendor build. The line system vendor's planner cannot model a third-party transponder properly. The third-party transponder vendor's planner cannot model the line system. Conservative spreadsheet rules of thumb produce designs that work but waste capacity — typical over-margining costs an operator 20 to 40 percent of theoretical maximum reach or capacity. To plan a multivendor network properly, the operator needs a tool that owns the physics and treats every component as a parameterized abstraction rather than a proprietary black box.
This is the problem GNPy was built to solve. Its physics engine implements the Gaussian Noise (GN) model — the consensus closed-form analytical model for nonlinear interference (NLI) in uncompensated coherent links — and produces a generalized signal-to-noise ratio (GSNR) that any transponder can be checked against. Its equipment library is a JSON file that the operator owns. Its inputs and outputs are open formats. The tool is open source under a BSD-3-Clause license, which means an operator can build commercial applications on top of it without constraint. For background on the physics, see the deep treatment of the Gaussian Noise model in modern optical systems on MapYourTech.
What GNPy does not provide, and what an operator's planning team must build, is the application around the engine. That application is the subject of this article. For a companion piece on why operators are taking this work in-house and what the build-versus-buy decision looks like in 2026, see MapYourTech's overview of in-house multivendor optical link planning, design, and simulation for operators. It includes a topology editor that lets a planner draw a network on a canvas; an equipment library that catalogs every transponder, amplifier, fiber, and ROADM the operator might use; a project management layer that handles versioning, multi-tenancy, and audit trail; a service request workflow; a simulation orchestrator that calls GNPy at scale and tracks job progress; a reporting module that produces documents engineering and operations teams can use; and an integration layer that talks to the operator's SDN controller and OSS systems.
Scope of this article. The reference architecture, library choices, repository layout, and code patterns described below are aimed at an operator planning team building an internal tool, or at a software vendor building a commercial product around GNPy. The article assumes Python 3.11+ on the backend and modern React on the frontend. Other stacks (Java/Spring, Go, Vue) work; the architectural decomposition is the same.
3. Industry Context and the Vendor-Neutral Imperative
The Telecom Infra Project (TIP) Open Optical and Packet Transport (OOPT) working group has driven the architectural standardization that makes multivendor optical networks practical. Three of its sub-projects matter for the planning tool. The OOPT MUST (Mandatory Use Case Requirements for SDN for Transport) workstream defined the SDN architecture operators target — a hierarchical controller stack with northbound TAPI, southbound NETCONF/YANG to equipment, and a vendor-neutral planning component. The OOPT MANTRA (Metaverse-ready Architecture for Open Transport) workstream extended the use cases to converged packet-and-optical scenarios. The OOPT PSE (Physical Simulation Environment) workstream produced GNPy itself.
Outside TIP, the OpenROADM Multi-Source Agreement (MSA) defined YANG models and physical specifications for ROADMs and metro transponders that allow true multivendor interoperability. The OpenZR+ MSA extended the OIF 400ZR specification with longer-haul performance modes. The OpenConfig collaboration produced vendor-neutral YANG models adopted by every major equipment vendor. As of 2026, an operator buying optical equipment can specify support for these standards in the RFP and get genuine multivendor compatibility from the major suppliers.
The planning gap remained because none of these standards specifies how performance is to be predicted across a multivendor path. OpenROADM defines what a ROADM exposes and how it is configured; it does not specify how to compute the GSNR of a service that crosses a ROADM from vendor A onto a fiber span instrumented with EDFAs from vendor B carrying a 400ZR pluggable from vendor C. That computation is the planning tool's job, and until GNPy reached production maturity around 2020, no shared, validated, vendor-neutral way to do it existed in open form. Field studies published by Microsoft, Orange, InterNexa, and several research networks have validated GNPy's predictions to within approximately 1 dB of measured GSNR for over 90 percent of test cases, which is the same accuracy band proprietary planning tools achieve on their own equipment.
Three architectural patterns dominate the industry as of 2026, and the planning tool must accommodate all three. The closed pattern, single vendor end-to-end, is in decline but still common in long-haul terrestrial and submarine. The open pattern with single open line system and multivendor transponders — the alien-wavelength model — is the dominant new-build pattern in metro, regional, and DCI; tools must model alien wavelengths first-class. The fully disaggregated pattern, where every element is independent, appears in hyperscaler and research networks and creates the hardest modeling problem because every span has its own vendor mix. For more on the operator perspective on these models, see MapYourTech's article on open line systems and multi-vendor coherent wavelengths.
3.1 What proprietary tools cannot do
Proprietary planning tools — Ciena's OneControl, Nokia's WaveSuite, Cisco's CONP, Infinera's TransNet, Ribbon's Muse Network Planner — are accurate within their own product families because the vendor knows its own equipment to the spec. They fail in three concrete ways for multivendor networks. They reject inputs that do not match the vendor's catalog, so a third-party transponder either cannot be entered or must be approximated as a generic transponder with hand-tuned penalties. They do not expose internal models, so an operator cannot calibrate the tool to measured field data the way the vendor's own engineers can. And they cannot interoperate with each other, so a service that crosses a multivendor boundary must be planned twice with conservative margins on each side, wasting reach and capacity.
Read the Full Analysis with Premium
The remaining 79% of this article — the design numbers, trade-offs and field guidance — is part of MapYourTech Premium, along with the full premium library, courses and professional tools.
Optical Communications & Network Automation Expert | Author of 3 Books for Optical Engineers | Founder, MapYourTech
Optical networking engineer with nearly two decades of experience across DWDM, OTN, coherent optics, submarine systems, and cloud infrastructure. Founder of MapYourTech. Read full bio →
Follow on LinkedInRelated Articles on MapYourTech
Share:
You May Also Like
-
Free
-
July 10, 2026
-
Free
-
July 10, 2026
-
Free
-
July 10, 2026