Transport PCE is based on a modular structure. Some of the bundles are tightly connected to the type of equipment handled by the controller. This is the case of the Renderer and the OLM that allow configuring OpenROADM equipment. Thus the algorithms of the different functions they implement, respect the procedure defined in the OpenROADM Device white paper.

Some other modules are less tightly coupled to the type of controlled equipment, such as the PCE and the Topology discovery. To ease further evolution Transport PCE specific models are published on the following Github repository: https://github.com/transportPCE/transportPCE_Public

Published models define a common base allowing the different modules to share the information present in the DataStore and to communicate. They can be used as a reference by contributors to develop complementary/additional features. These new features as far as they rely on the reference model could be triggered from existing module, in place of others having the same functionality for different kind of equipment, or to complement existing functions.

As an example we could imagine extending the support of equipment following different models. This would imply to develop some specific OLM & Renderer to configure the devices and to extend the topology model through additional augmentations.

OpenROADM Device and Network Models have been presented by AT&T:  Open_ROADM_Models_v0_2.pdf
Full models can be retrieved following OpenROADM website (download section).

Orange (XP) review- Aditional review by other contributors is welcome.

Static information
Connectivity matrix
Section 4.1 specifies a connectivity matrix indicating which input port could possibly be connected to which output port. This is similar to the connectivity-map in openroadm network model with still some differences in presenting data.

ressource pool
As far as I understand this part, it is related to regenerators or wavelength converters. As far as Orange is concerned, these functions are not taken into consideration in ROADM modeling. If regeneration is needed/preferred, it is up to the PCE to decide where to make it taking into consideration ROADM, transponders, and OTN switches. One could say that two transponders back to back become a regen/converter, but the two transponders can also be used without being back to back. Therefore, it seems to me more adquate to have the granularity of transponder and let the PCE decide whether associating 2 of them or not.

Link information
This part is fundamental for PCE and shall be described in the link part of I2RS model structure. As far as OTN/WDM are concerned, links can either be OTUx or LO-ODUx. Most of the information described in section 6 is relevant. Port label restrictions are still vague to me.

Dynamic information
Agreed with dynamic link information even if bandwidth (for LO-ODU) should be added. For node information, it is related to resource pool and therefore probably not relevant.

Synthesis
Information related to links shall be modeled in the link part of I2RS model structure and there is no real reason for diverging with RFC 7446. It will however enriched with additional information in order to perform accurate path feasibility calculation or to ensure some service metrics are checked. Regarding node description, I am not sure to see how they can really converge. One model is de-aggregated for accurate path calculation (typically for disjointness requirements) while it may be diificult to derive one de-aggregated from RFC 7446. Besides, the notion of resource pool does probably not meet the needs for the reason given here above (transponder can be used for regen or not).

Ericsson (FL) comment

Actually, resource pool is a more complex and general concept, as it's a modular and versatile blocks based approach. Its aim is to model any connectivity limitation inside a node, and is applicable not only to ROADMs, but also to other technologies, typically to model connectivity limitations of multiple technologies NEs, like a NE having both OTN and WDM switching capabilities (e.g. Ericsson SPO family has exactly this capabilities, and also allows to add SDH and packet switching altogether).
When some ports can be connected with a subset of the other ports available inside the NE, and possibly the guaranteed connectivity has also limitations (e.g. there is a limit on the maximum switchable bandwidth) this model can be very useful.
Besides, resource pool is not limited to regeneration and wavelength conversion. There are other cases where this is useful :

• Modeling of transponders "add/drop" of a single line (fixed connectivity to the relevant line only)

• Modeling of transponder sharing mechanisms (connectivity to an intermediate stage allowing directionless/colorless/contentionless routing). Occupation of the intermediate sharing hardware must also be taken into account when assigning or verifying lambdas.

The intermediate sharing stage can be in turn connected to all or part of the line interfaces of the NE, and once again this can be done effectively with the resource pool mechanism.

• Lambda limitations on internal HW (beside the case highlighted at the previous point); e.g. lambda limitations due to transponder ports, filters or other equipment configured on the NE.

Resource pool concept is based on two types of objects:

• Resource blocks, representing a general set of internal NE resources, and keeping track of their capabilities, occupation and relationship with external interfaces (the traffic ports of the NE)

• Connectivity matrixes, representing actual connectivity between resource blocks.

This way it's possible in a very comprehensive and detailed way to model the internal structure of a generic NE with its real limitations, taking into account their current usage.
I understand that the other model is more focused on WDM NEs, and possibly less general. Deciding whether to use one of the other would require to do a more detailed use case analysis, taking into account real NE scenarios, not only in WDM domain but also in OTN (at least) as this is an additional target of the project.

The I2RS draft version (4) can be retrieved at https://tools.ietf.org/html/draft-ietf-i2rs-yang-network-topo-04

Open

The Path Computation Element (PCE) is the component inside TransportPCE project responsible for path computation. An interface allows other components of the TransportPCE to request a path computation and get a response from the PCE including the computed path(s) in case of success, or errors and indication of the reason for the failure in case the request cannot be satisfied. Additional parameters can be provided by the PCE in addition to the computed paths if requested by the client module. Additional interfaces allow to keep PCE aligned regarding topology and traffic deployed in the network.

PceConstraintsCalc class parses constraints calling calcHardConstraints and readConstraints methods and saves them for a quick use. Open ROADM service model defines both soft and hard constraints. Only hard constraints are considered in current implementation. Routing constraints handled are the following:

• General constraints: exclude Node/SRLG, maximum latency

• Diversity constraints: with respect to the path(s) of a specific service or a list of service

Co-routing constraints are not handled at this stage. The exclusion of Diversity constraints is handled in 2 steps. readDiversityNodes recovers the path description(s) of the service or the service list from the Service-path DataStore. From the path description, getAtoZNodeList extracts the nodes and converts the diversity constraint to a general node exclusion constraint.

PceCalculation is dedicated to the topology analysis and pruning before the path computation is launched. It performs this in 2 steps relying on the following 2 main methods:

• readMdSal : Reads the topology layer of the Open ROADM Network topology built in the MD-SAL by the Topology Management module. This layer includes the disagregated nodes (SRGs, Degrees, Xponders) as well as the links between these nodes.

• analyzeNW : minimizes the amount of nodes/links extracted from the topology to use in the graph according to the arguments of the PCE request. From all the nodes present in the initial topology, validateNode removes all Xponder nodes that do not correspond to A or Z end of the demand, as well as all the Nodes that correspond to a hard exclude constraint through validateNodeConstraints.

PceGraph class is dedicated to the path calculation. Current solution in a first step populates graph with relevant nodes (degrees, SRGs, Xponders) and links from the pruned topology using populateGraph method.

In a second step, it relies on CalcPath which calculates the path according to 2 tracks. In the fast track it attempts to calculate the path calling runGraph and indirectly calcAlgo methods which returns a Dijkstra Shortest path according to the selected metric. Currently supported metrics are hop-count and propagation-delay. Graph algorithm finds K shortest AtoZ paths. chooseWavelength method checks that a wavelength continuity can be found for the returned paths. The first (best) AtoZ path with single wavelength is chosen. ZtoA path is derived from AtoZ.

If no wavelength continuity can be provided for the shortest path, a second track is explored. Before populating the graph, extractWLs extracts the list of available wavelengths for each node of the pruned topology, and for each wavelength creates a list of the nodes for which this wavelength is available. The path calculation is still performed calling runGraph and calcAlgo methods, this time scanning all the wavelength on a topology which considers wavelength availability.

PceLink and PceNode create objects with all the attributes needed for pathcalculation. PceLink includes methods to retrieve the link-type, the associated opposite-link, the latency and the source and destination tps. PceNode includes the methods to retrieve available wavelengths, client tails and outgoing links.

PceSendingPceRPCs defines all methods required to handle the RPCs associated with Path computation and the cancellation of resource reservation. This includes the error handling and the construction of the output of rpc with the response codes and the path-description when required. The main methods defined in this Class are :

• cancelResouceReserve :

• pathComputation : first launches constraint calculation from hard and soft constraints contains in the input of path-computation-request rpc. In a second step reads and analyse the topology (PceCalculation readMdSal and analyseNW). In a third step launches the graph and the path calculation (Graph calcPath). In case path calculation based on hop-count metric (by default) fails because path's latency exceeds the defined constraint, changes the metric to propagation-delay and launches a new path calculation using the following method.

• patchRerunGraph : launches the graph and the path calculation (Graph calcPath) after the metric was changed to propagation-delay.

PcePathDescription is the class used to build the path-description returned in the output of the path-computation-request rpc and the service-path-rpc-result notification. This path description is built as a succession of SourceTp & (SouceNode)-Node-tp-link-tp-Node....link-tp-DestinationTp & DestinationNode.

PathComputationServiceImpl defines the handling of path-computation-request and cancel-resource-reserve RPCs, overriding the 2 corresponding methods defined in the PathComputationService interface. It computes the messages of the output of the rpcs according to the context and the result obtained through the path calculation. It also handles notification service-path-rpc-result providing the status of the path calculation (pending, successful, failed).

The following table describes the requirements for the PCE module. The scope is limited to the path computation related operations, as the topology is covered by another section of the TransportPCE project.

The columns of the table are :

• Id - an identifier of the requirement. The idea is to use a structured identifier in order to build a hierarchy of requirements; see the table below

• Slogan - a short title of the requirement

• Description - a detailed description of the requirement

• Reference - If the requirement is derived from or refers to an external document (e.g. an IETF RFC or draft) this column includes the relevant information

• Priority - The priority of the requirement as agreed between the TransportPCE contributors. Here we propose a simple number like 1 = Mandatory requirement and increasing numbers to indicate lower priority or optional requirements. Range of values to be decided.

Proposed range: 1 = Mandatory 2 = Second priority 3 = Nice to have

• Agreed - A "Yes" in this columns means that the requirement is agreed among the contributors and therefore is a valid requirement for the project.

• Comments - Comments from TransportPCE contributors