TransportPCE primary function is to control a WDM optical transport infrastructure using the non-proprietary OpenROADM MSA standard. Control includes the capability to configure the optical equipment using Netconf and to provision services according to RESTconf or Netconf requests coming from a higher layer controller and/or an orchestrator.
This first release provides a usable but limited set of features as a Proof-Of-Concept that is not necessarily intended for all production uses (at least without some modifications).

TransportPCE uses a modular architecture. Each component is associated with a generic block relying on open models and API:

• Topology management

• Renderer (responsible for the path configuration through optical equipment)

• Optical Line Management (OLM)

• Path Calculation Engine (PCE)

• Service Handler

Complementing Yang models defining East/West APIs that allows those module communications, it could be easily interconnected to external applications, or could host specific plugins provided that they support the published APIs, avoiding to deploy Controller dedicated to specific equipment in silos.

The interest of using a controller to provision automatically services strongly relies on its ability to handle end to end optical services that spans through the different network domains, potentially equipped with devices coming from different suppliers. Thus, interoperability in the optical layer is a key element to get the benefit of automated control.

The design of TransportPCE leverages OpenROADM Multi-Source-Agreement (MSA) which defines interoperability specifications, consisting of both Optical interoperability and Yang data models. North API, interconnecting the Service Handler to higher level applications relies on the Service Model defined in the MSA. The Renderer and the OLM are developed to allow configuring OpenROADM devices through a southbound Netconf/Yang interface and rely on the MSA’s device model. Topology Management is also based on the Network model defined in the MSA.