Keep it simple – debating coherent plugs versus transponders misses the point
Interest in IP/Optical convergence is increasing, and evaluations are underway, yet many in the industry are still debating the value of coherent plugs versus transponders. The point is coherent plugs and transponders will exist in most real networks, and the pertinent question is how to effectively operationalize this emerging paradigm. On the surface it seems simple: routers have always supported plugs and the introduction of QSFP-DD based coherent pluggable transceivers should be an extension of that capability. That is at best a simplistic view and at worst disingenuous (aka self-serving).
Coherent wavelengths originating on routers will run over an existing photonic ROADM infrastructure that has end-to-end spectrum planning, path viability calculations, as well as in-service operational models and tools to optimize optical performance for both new and existing services. Ignoring all those existing optical operational models is unlikely to be a long-term success path. However, with some simple operational rules in place, the requirements to effectively deploy coherent plugs can be quite straightforward.
Step 1: Align the ownership of photonic services planning to a single team
This does not mean the IP routing network operations center (NOC) team “gives up” ownership of their IP network and devices. It does mean that the planning of the coherent waves on the router should be done by the same team that manages wavelength services today since they have the optical domain expertise and knowledge. In many deployments, using interoperable modes of the coherent pluggables may not provide the performance required for target use cases and vendor-specific high-performance modes need to be accessed on the plugs to gain maximum reach and performance. This level of understanding is the domain of the optical experts within many organizations, and there is no value in duplicating this within an IP routing team.
Once the key parameters of transmission mode, power settings, frequency, guard bands etc. have been established within the context of the end-to-end spectrum plan, those settings can be handed off to the IP NOC team which can then go ahead and provision and manage the coherent plug. It can be as simple as that – two teams working together and leveraging their domain expertise to achieve a common goal. That is the bare minimum any organization should expect. This can be achieved with the current operational software toolset.
It can be as simple as that – two teams working together and leveraging their domain expertise to achieve a common goal.
Step 2: Integrate plug monitoring and troubleshooting into optical workflows
A simple and optional extension to this model is to allow the optical NOC team, and their corresponding management software, read-only access to the coherent pluggable as it will allow them a complete view of all optical services in the network and provide opportunities for an integrated troubleshooting model which would reduce mean time to identify and repair (MTTI / MTTR) issues in the network. Optional but very powerful if implemented correctly. For this, the optical controller needs some ability to see the router interface and have access to coherent plug metrics and configurations, either via native router APIs or the industry-recognized OpenConfig specification.
Figure: Open APIs are key to operationalizing Coherent Routing architectures
Note, at no point did I mention any other dramatic redesigns, such as organizational restructuring, redesigning the network to remove ROADMs, requiring all services be converted to IP, or setting up complex hierarchies of different management or control platforms. Coherent plugs should be viewed as a cost-effective solution to some transport workloads in the network, and their rollout in existing networks can be achieved with a couple of straightforward steps. Keeping the goals and deployment policies simple will allow any CSP to deploy Coherent Routing solutions with confidence.
