Welcome to TransportPCE

Introduction

TransportPCE describes an application running on top of the OpenDaylight controller. Its primary function is to control an optical transport infrastructure using a non-proprietary South Bound Interface (SBI). It may be interconnected with Controllers of different layers (L2, L3 Controller…), a higher layer Controller and/or an Orchestrator through non-proprietary Application Programing Interfaces (APIs). Control includes the capability to configure the optical equipment, and to provision services according to a request coming from a higher layer controller and/or an orchestrator. This capability may rely on the controller only or it may be delegated to distributed (standardized) protocols.

It provides alarm/fault and performance monitoring, but this function might be externalized to improve the scalability. A Graphical User Interface could be developed in a later step, but is not considered as a priority since automated control does not imply user interactions at the transport controller level.

TransportPCE modular architecture is described on the next diagram. Each main function such as Topology management, Path Calculation Engine (PCE), Service handler, Renderer _responsible for the path configuration through optical equipment_ and Optical Line Management (OLM) is associated with a generic block relying on open models, each of them communicating through published APIs.

Image Modified

The controlled transport infrastructure includes a WDM layer and an OTN layer. The WDM layer is built from ROADMs with colourless (an add/drop port is not dedicated to one wavelength, it accepts potentially any wavelength coming from a tunable transponder), directionless (an added/dropped service can be optically switched to any degree, independently of the physical port it is launched through) and possibly contention-less (no restriction on the wavelength that can be added or dropped from any port) features. The OTN layer is built from transponders, muxponders or switchponders which include OTN switching functionalities

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 equipment coming from different suppliers. Thus, interoperability in the optical layer is a key element to get the benefit of automated control.

Initial 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

This choice does not prevent to extend the range of open-specifications supported by the controller, when they reach the level of maturity expected to launch heavy developments. Thanks to defined modular architecture, some additional modules dedicated to the configuration of other types of equipment could be added at a later step. Some others like the PCE or the Topology Management, less tightly coupled to the equipment models could be complemented to support the corresponding devices.

Another advantage of TransportPCE modular architecture is that, complementing Yang models defining East/West APIs that allows 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.