IP/Optical hardware convergence is well underway, but is that enough to deliver on the promise of cost-effective, sustainable network scalability? Ciena’s Tim Pearson explains why multi-layer controllers are best suited to help you plan, operate, and optimize optical performance in a converged IP/Optical architecture.

The networking industry is evolving to IP/Optical convergence from the hardware perspective, in the form of coherent plugs deployed in router devices. The footprint, power, and cost savings are apparent. Yet, on the operations side of the house, there are some misperceptions about the approach to convergence. Some groups are advocating that IP domain controllers manage coherent pluggables, primarily because the pluggables are hosted in the router platform. There is also the stance that hierarchical controllers are a necessity. But do those approaches truly enable the multi-layer optimization benefits that operators hope to achieve with IP/Optical convergence?

I’ve already discussed a reasonable operational approach to getting started on coherent plug deployments, based on leveraging domain expertise and domain processes:

  1. Align the ownership of photonic services planning to a single team with domain expertise
  2. Continue to integrate monitoring and troubleshooting of the transponder function into optical workflows, whether or not deployed as coherent pluggables
  3. Automate the provisioning of coherent pluggables and photonic services
  4. Optimize the utilization of photonic infrastructure

This approach allows service providers to move forward with Coherent Routing deployments with minimal effort, without re-architecting their operational models! Nevertheless, there is debate about which deployment model is best and what product realizations are possible. Let’s explore.

Models for control and management of pluggables

Several deployment models for the management of pluggables exist. Within the IETF industry standards organization, IETF draft-poidt-ccamp-actn-poi-pluggable has proposed two architectural options, namely:

  • Option 1: Dual southbound interface (SBI) management of packet devices (i.e., IP routers), with the optical controller having read-only access to the pluggable
  • Option 2: Single SBI management of packet devices by the IP controller, with optical controller having no access to the pluggable

IETF draft-davis-ccamp-photonic-plug-control-arch-02 introduces a third option:

  • Option 3: Dual SBI management of packet devices, with the optical controller having read-write access to the pluggable

Alternative models for management of pluggables_Option 1Alternative models for management of pluggables_Option 2

Alternative models for management of pluggables_Option 3

Alternative models for management of pluggables

Note that all these options are viable, depending on the operator’s scenario. Unlike Option 1 or 2, which require a higher layer controller to coordinate between domain controllers, in the Option 3 model, a higher layer controller could exist but is not necessary.

Since automation of multi-layer, multi-domain, packet over optical networks is an area which captures the attention of most service providers, any control architecture which covers full automation of such networks should address the group of requirements covered in IETF draft-davis-ccamp-photonic-plug-control-arch-02.

Control should be where the intelligence is

The end objective of a controller is to optimize utilization of infrastructure assets in order to achieve a high level of network performance and resiliency. Operations teams rely on control software to keep network devices running and supporting end customer services, even when faults occur. And they must do so as cost-efficiently as possible – no one can afford to have expensive hardware lying underutilized.

An optical domain controller inherently has detailed knowledge of the key parameters that need to be tuned to achieve desired reach and bandwidth within the context of the end-to-end spectrum plan, which include: transmission mode, power settings, frequency, guard bands, amplifier settings, etc. Moreover, it has detailed insights into the performance of the optical layer based on real-time telemetry from the photonic infrastructure and thereby can assess the state of the optical network and its potential to support additional wavelengths. This holistic visibility is required whether the coherent transceiver capability is provided by a transponder or by a pluggable.

Whilst initial deployments focusing on simple optical networks may be able to operate with a basic discovery of optical parameters and manual control of basic optical settings, it is vital that the proposed architecture does not block more sophisticated deployments. It is up to service providers to make it abundantly clear that, in some deployments, packet devices will need to give the optical controller unimpeded control access to the photonic plugs.

Some vendors have suggested that such an approach – having the optical controller manage the coherent pluggables – would cause serious issues. Not true!

  • Since each controller has independent control parameters, there is a separation of concerns and avoidance of race conditions.
  • Coordination of key parameters is necessary across the optical network, but there is no need to synchronize with the IP network – the IP layer simply gets the optical link when it is running and loses it when it is not, just as is the case with traditional transponders.
  • Security is preserved with a proper access list on the management interfaces ensuring the IP operations team only controls the IP elements and the optical team only controls the photonic elements.
  • Practically speaking, there will likely be multiple regional IP controllers and a single optical controller for the core transport network, so there is a clean scope of control for fine-tuning network performance.
  • The higher layer controller should be optional – today, most IP over optical deployments do not have, or need, a higher layer controller. Forcing the addition of a higher layer controller makes the deployment more complex.
  • Existing operational practices should be supported. It is important that the IP and optical control architecture can deal with any network deployment and administration use cases as coherent plugs are deployed, without imposing significant change to the operator's current operational practices (including network planning, commissioning, provisioning, assurance, optimization, and protection/restoration).

On the other hand, fragmenting optical visibility by having the IP domain controller manage coherent pluggables means that transceiver/line system network design validation, channel margin monitoring and optimization, and fault management would be dependent on the assistance of a hierarchical controller. Such complexity is avoidable by granting the optical controller full and unhindered access to all properties of the coherent plug, to do what it does best.

Functional components versus product realization

In general, the industry agrees on the functional components that are needed for converged operations: there is benefit from a higher layer controller that spans both the IP and Optical domains to synthesize data from both domains and make optimal decisions regarding utilization of assets to deliver high-resiliency and high-performance network services. There is however a difference between a functional component and product realization – there are different ways service providers can choose to deploy products to realize a solution that works in their specific operational environment.

Below are two scenarios that could be realized by a multi-layer controller product that maintains a holistic information model, correlating IP and optical layers, and enables coordination of lifecycle operations for planning, design, assurance, audit, and optimization.

Controller product realizations while maintaining specialized control functions_1

Controller product realizations while maintaining specialized control functions_2

Controller product realizations while maintaining specialized control functions

Integrated IP/Optical control enables optimization at scale

Coherent pluggables are not set-and-forget devices, except in the most basic environments. There needs to be periodic control and adjustment. Necessitating indirect communications between IP and optical controllers via a distinct hierarchical controller for lifecycle operations does not scale. All state information from both IP and optical domain controllers needs to be sent to the hierarchical controller. That requires a lot of messaging across interfaces that need to be well-defined. A multi-layer controller realization – as depicted above – would eliminate the need for that overhead.

Consider assurance of optical services and troubleshooting of faults. Telemetry needs to be collected in near-real-time from coherent pluggables and optical devices in order to have end-to-end assurance across the optical link from pluggable to pluggable. Also, consider the scenario of congestion at the IP layer. A multi-layer controller has knowledge of latent capacity at the photonic layer that could be deployed to create extra capacity at IP layer and alleviate the congestion. For improved network resiliency, protection and restoration, a multi-layer controller can leverage the capabilities of IP and optical layers to intelligently restore data traffic and having direct access to coherent plugs is essential.

The choice is yours – hierarchical or integrated operations

When it comes to managing coherent pluggables within a Coherent Routing architecture, there are a few deployment models. One thing, however, is non-negotiable – control needs to rest in the hands of the system that has the most accurate, real-time intelligence to take informed actions across its domain. Optical domain controllers are the best equipped to manage coherent pluggables, provided they have transparent access to the full capabilities of the plug. Control functions specializing in one layer should control the devices of that layer. That’s what you expect. And furthermore, you can realize a converged management model most effectively with a multi-layer controller. You depend on controllers to do their job well, so you can do yours.