Versions Compared

Version Old Version 16 New Version 17
Changes made by

Guillaume Lambert

Guillaume Lambert

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

As OpenROADM MSA was selected for the initial implementation of TransportPCE, OLM shall respect the procedures defined in the Device White paper (Provisioning action use cases / Connection management) to set connections and power levels, as well as the OpenROADM specifications, both available at OpenROADM public site (Download)

Basic Renderer

Renderer description

The Renderer module is responsible for configuring the equipment after a service path has been defined by the Service Handler. The full process that we call “Renderer Service Operation” includes the management of connections implemented through the “Device Rendering” function, and power levels setting which relies on the OLM module, called by the Renderer.

The global process “Renderer Service Operation” relies on service-implementation-request and service-delete rpcs, defined in service-path 1.5 yang module to allow for RESTCONF service between the Service Handler and Renderer. These RPC could be used in case of future extension or development of additional modules that could remain external or be directly integrated in transportPCE.

The Device rendering function dedicated to connection setting inside the Renderer, relies on another rpc : service-path, defined in the server module of the rpc (transportpce-renderer). This last is used as an API for RESTCONF service between transportPCE internal modules : Topology Management, Service Handler, Renderer as well the Mapping Module bridging the abstracted topology used for path computation, (“path-description” of the service-path) with the detailed topology including device elements such as circuit-packs and ports (“topology” of the service as defined in the service Open ROADM model).

On service creation, the Service Handler uses service-implementation-request rpc to provide the path to the Renderer and trigger connections creation in the equipment. On service deletion, the Service Handler uses service-delete rpc. The path associated to the service is available in the service-list or the temp-service-list (depending on the type of service: regular versus temporary) of the MD-SAL DataStore. The Renderer then sets / deletes connections in the Netconf equipment according to the service path that has been defined for this specific service.

In the global path creation process, after connections have been correctly sets on the equipment across the path in the forward and the reverse direction, the Renderer relies on the OLM module to set the power levels on the equipment. If all connections cannot be set on the end to end path, the Rollback module is invoked to reset the different connections that were established during the path creation, so that equipment configuration goes back to its initial configuration.

Functional behavior of the renderer is based on D interface and device interface.

Renderer Implementation

In this section we focus on the description of the main classes of the Renderer bundle. Thus this description shall not be considered as exhaustive. It only provides information on the main building blocks of the Renderer, to clarify its purpose and give some high level details on its implementation.

Renderer Provider and RPC implementation

RendererProvider class, at initialization registers to the rpc service, and instantiates TransportPCEServicePathRPCImpl & DeviceRendererRPCImpl classes, which define the methods implementing the RESTCONF services associated with the external APIs into the Renderer application.


DeviceRendererRPCImpl implements RendererService interface (automatically generated from Yang models) . It includes three main methods :

  • servicePath used to provision (create operation), or de-provision (delete operation) the device for a given wavelength and a list of nodes with each node listing its termination points .
  • createOtsOms used to provision OTS and OMS interfaces on the ROADM to ROADM link if this was not performed during the initial commissioning of the WDM lines.
  • rendererRollback which rollbacks created interfaces and cross-connects if for some reason the service path could not be correctly created end to end.

TransportPCEServicePathRPCImpl implements transportpceServicepathService interface (automatically generated from Yang models) . It includes two main methods currently implemented : ServiceImplementationRequest and serviceDelete which corresponds to the rpcs defined in the Service-path 1.5 yang model. cancelresourceReserve method is currently not implemented. It is associated with the notion of temporary service that can be created between to ROADMs termination points, waiting until transponders are provisioned at both ends of the service path.

The Device Renderering service

DeviceRendererServiceImpl implements DeviceRendererService Interface, with the following public methods :

  • setupServicePath : set's wavelength path, creating interfaces and cross connections in ROADMs. and creating a cross connect between source and destination tps. The path to configure is a list of Nodes with source and destination tps. This method first populates the service-node-lists in the Configuration Datastore for alarm-suppression with the all the nodes included in the service-path to configure through alarmSuppressionNodeRegistration method. It then sets in parallel on the different nodes all interfaces required to support the services on source and destination points (Och, OTU4 and ODU4 interfaces on the wavelength path, 100GE interfaces on the client side of transponders). To do this, it relies on OpenRoadmInterfaceFactory methods. After all interfaces have been created, it then sets unidirectional connections between tps (PP-TTP, TTP-TTP, TTP-PP) in the ROADMs; relying on CrossConnect postCrossConnect method. The successful creation of the connection is checked using CrossConnect.getConnectionPortTrail method which returns the ports used for the connection. When a cross-connection has been successfully created, the topology of the service (detailed list of the port resources that are used) is updated calling ServiceListTopology.updateAtoZTopologylist. A list of created interfaces and connections is also maintained in case a Rollback needs to be invoked (creation not fully successful across the whole path). At the end of the path creation it calls the private method setTopologyForService, which complements the description of the newly created service with the topology (detailed description of the path) in the service-list. It also removes from the service-node-lists for alarm-suppression all the nodes involved in the service-path creation.
  • deleteServicePath removes wavelength path on each node, first deleting cross connect between source and destination tps (in ROADMs), and in a second step deleting the interfaces on source and destination tps (in both ROADMs and Xponders).The path to remove is a list of Nodes with source and destination tps. This method deletes in parallel on the different nodes connections (on ROADM), and interfaces on source and destination points (ROADMs and Xponders). It relies on CrossConnect deleteCrossConnect method and OpenRoadmInterfaces deleteInterface methods.
  • rendererRollback allows getting to the original state of the nodes if the Renderer fails in creating a whole wavelength path from A to Z. To achieve this, it deletes created cross connects and interfaces specified by input. Interfaces are deleted in a specific order ending with interfaces that support the others.
  • alarmSuppressionNodeRegistration populates the service-node-lists in the Configuration Datastore for alarm-suppression with the all the nodes included in the service-path to configure.
  • alarmSuppressionNodeRemoval removes from the service-node-lists for alarm-suppression of the Configuration Datastore all the nodes included in the input of the service-path rpc
  • setTopologyForService, sets in the service-list of the operational DataStore, the topology (detailed description of the path) of a newly created service from the service-name and the topology provided as input argument..
  • createOtsOms creates the basis of ots and oms interfaces on a specific ROADM degree. This method is used during initial provisioning of a new WDM trunk.
  • isUsedByXc checks whether or not, a cross connection is present in the configuration DataStore of a Node and returns thrue if it is present and if one of the source or destination interface fits with the interface provided as an input argument.
  • isSupporting OtsPresent checks that for the provided input mapping object (Logical-connection-point, supporting circuit-pack and supporting interfaces), an OTS interface has already been created during the initial commissioning of the WDM line and is present in this object.

Global Rendering Service

RendererServiceOperationImpl implements RendererServiceOperations interface. Thus it provides the implementation of the two following public methods called in by the rpcs service-implementation-request and service-delete:

  • serviceImplementation : this method first launch the rollback processor. In a second step, service-path and service-power-setup rpc input are processed using relevant ModelMappingUtils methods. In a third step, it calls deviceRendering method to launch in parallel interfaces and connections setup on the A to Z and on the Z to A paths. In case of success it then calls olmPowerSetup method to set the power (in parallel on the A to Z and on the Z to A paths) in the different nodes. In a last step, it calls isServiceActivated to test service activation measuring the BER on both the source and the destination nodes. At the end of the process, if the service is successfully activated, it refresh the configuration of the nodes and tps followed by the service in the topology, according to the wavelength used to configure the service, relying on NetworkModelWavelengthService. The service-implementation-request result builder is processed using relevant ModelMappingUtils methods. At each step of the service setup process, Rollback processor is used to rollback in case of failure during the creation of interfaces, connections and power setup.
  • serviceDelete : this method first retrieves the service-path corresponding to the service-name and then sequentially sets the power down on the different nodes of the service path on the A to Z and Z to A paths. It relies on the corresponding private methods of the package : getPathDescriptionFromDatastore and olmPowerTurndown. The service-delete rpc input and result builders are processed using relevant ModelMappingUtils methods.

RendererServiceOperationImpl defines the following private methods :

  • getPathDescriptionFromDatastore retrieve the path description corresponding to the service-name provided as an input from the MDSAL Operational DataStore
  • deviceRendering launches in parallel interfaces and connections setup on the A to Z and on the Z to A paths relying on DeviceRenderingTask. In case the interfaces and/or connections cannot be set up on the different nodes of the path in both directions, the methods calls the rollback processor to roll back interfaces and connections setup in the 2 directions of the path (relying on DeviceRenderingRollbackTask).
  • olmPowerTurndown calls the OLM module remote procedure servicePowerTurndown through olmService.servicePowerTurndown method.
  • olmPowerSetup relies on ServicePowerSetup rpc of the OLM module to set the power in the different nodes of the service path. It launches in parallel the power setup on the A to Z and on the Z to A paths relying on OlmPowerSetupTask. In case the power cannot be set up on the different nodes of the path in both directions, the methods calls the rollback processor to roll back the power setup in the 2 directions of the path (relying on OlmPowerSetupRollbackTask).
  • isServiceActivated check for a node and a tp provided as input parameters that some PMs are available, and that from this PM a valid value can be retrieved to calculate the BER. To perform this, it relies on getMeasurements and verifyPreFecBer methods. Three iterations are performed according to a SERVICE_ACTIVATION_TEST_RETRY TIME, so that the controller let the equipment the time to accumulate enough values for BER calculation
  • getMeasurements calls GetPM rpc of the OLM module. It processes the inputBuilder of the RPC from the nodeId and the tp input parameters, and retrieves current PMs of 15 minutes granularity corresponding to the OTU interface of the node.
  • verifyPreFecBer parse a list of measurements, from which it extracts FEC uncorrectable Blocks value, and pre FEC corrected errors number. It returns an error if there are some uncorrectable Error blocks. Otherwise it provides an information LOG with the value of the BER it has computed.

The Device Rendering Tasks

“XXXX Task” classes are used to call the different remote procedures involved in the communication between the modules and/or to handle the rpc results messages, relying on “YYYY Result” classes
  • OlmPowerSetupTask calls service-power-setup procedure of the OLM service and provides message relying on OLMRenderingResult
  • OlmPowerSetupRollbackTask calls service-power-turndown procedure of the OLM service and provides message on the progress of the operation.
  • DeviceRenderingTask overrides DeviceRenderingResult, calling DeviceRendererService.setupServicePath. It provides message on the progress of the rendering operation. In case of success of the service path setup, it provides a list of the nodes and interfaces successfully configured by the Renderer.
  • DeviceRenderingRollbackTask, extends RollbackTask abstracted class and creates the input and the output builder of the rendererRollback rpc. In case of roll back failure, the output includes the list of node-interfaces (nodes, interfaces, connections) which the Rollback process failed to remove or set back in their original state.

Rollback

RollbackProcessor collects tasks in a double ended queue for later rollback. This is a public class, and the implementation is not thread safe, thus it must be called from single orchestration thread. The rollback order is: last added task is rolled back first. After rollback, each task is removed from rollback processor. All rollback tasks are executed in single thread. RollbackProcessor defines several methods :

  • addtask, to add a task in the queue of the rollback processor
  • rollbackAll, rolls back all tasks previously added to the processor. All previously added tasks will be rolled back and removed from the processor.
  • isRollbackNecessary, checks if any previously added task requires rollback. Rollback is considered as necessary if just single task requires rollback : the method returns true as soon as one task requires rollback.
  • rollbackAllIfNecessary, rolls back all tasks previously added to the processor in case any of the tasks has failde. All previously added tasks will be rolled back and removed from the processor.

Utilities

Model mapping utility

ModelMapping utils includes all utilities needed to generate builders for inputs or outputs of the different rpcs involved in communications between the Renderer and OLM & Service Handler modules:

  • OLM rpcs get-pm, service-power-turndown and service-power-setup (input):
  • Renderer rpcs : service-path used to either create or delete or service ( rendererCreateServiceInputAToZ & rendererCreateServiceInputZToA, & rendererDeleteServiceInput methods are used to generate the input), renderer-rollback and create-ots-oms,
  • Service Handler rpcs : service-delete and service-implementation-request (output)
  • Open ROADM rpcs defined in the service model : createCommonResponse method creates a generic response builder for ConfigurationresponseCommon

getNodeListZtoA and getNodeListAtoZ methods allow to retrieve from the service-path description the different nodes and tps to create the list of node-id, src-tp and dest-tp defined in the input of the service-path rpc. DeviceRendererServiceImpl implements DeviceRendererService Interface, with the following public methods :

Wavelength use in Topology management utility

NetworkModelWavelengthServiceImpl defines the methods associated with the management of the wavelengths in the path description list, as well as the management of the wavelengths in the devices.

NetworkModelWavelengthServiceImpl implements NetworkModelWavelengthService Interface, with the following public methods :

  • useWavelength : for a specific service-path, removes the used wavelength from the nodes available-wavelength list, for the different nodes of the path; and adds this wavelength to the list of used-wavelength for the different tps of the same nodes.
  • freeWavelength : this method is used when a service is released and does the opposite of the previous method.

NetworkModelWavelengthServiceImpldefines the following private methods :

  • getAtoZTpList/ getZtoATpList : this methods returns NodeIdPairs (NodeId, TpId) contains in a path description AtoZ or ZtoAfield
  • createNode1IID / createTerminationPoint1IIDBuilder : for a Node/tp identified by its nodeId/ NodeId+tpId, creates an Instance Identifier targeting the corresponding node in the overlay topology.
  • getNode1FromDatastore / getTerminationPoint1FromDatastore : for a Node/tp identified by its nodeId/NodeId+tpId, retrieves in the Overlay Topology (configuration DataStore of the MDSAL) the Open RAODM node and its attributes.
  • addAvailableWL : for a list of Node identified by their nodeId and a specific wavelength, adds in the overlay topology (configuration DataStore of the MDSAL), the wavelength to the list of available/used wavelengths for the nodes (SRG or Degree).
  • deleteAvailableWL : for a list of Node identified by their nodeId and a specific wavelength, removes in the overlay topology (configuration DataStore of the MDSAL), the wavelength from the list of available wavelengths for the nodes (SRG or Degree).
  • addUsedWL : for a list of NodeIdPairs (NodeId/tpId) and a specific wavelength, adds in the overlay topology (configuration DataStore of the MDSAL), the wavelength to the list of available wavelengths for the tps (SRG, Degree or XPonder).
  • deleteUsedWL : for a list of NodeIdPairs (NodeId/tpId) and a specific wavelength, removes in the overlay topology (configuration DataStore of the MDSAL), the wavelength from the list of available wavelengths for the tps (SRG, Degree or XPonder).
ServiceList update utility

ServiceListTopology provides 2 methods to update the topology of a service (detailed list of the port resources that are used) : .updateAtoZTopologylist and .updateZtoATopologylist. These methods are called during the path creation by DeviceRendererServiceImpl.setupServicePath, when a unidirectional connection between tps in the ROADMs has been successfully created, so that the topology of the service can be dynamically maintained

Common Modules

OpenROAM Interface management

OpenRoadmInterfaceFactory class includes all utilities need to create OpenROADM interfaces :

  • createGenericInterfaceBuilder private method, creates a generic builder from the information it gets from a mapping element (logical connection point, supporting port and circuit-pack). This method is used by all methods of the class creating specific interfaces as the first step of the InterfaceBuilder creation.
  • createOpenRoadmOmsInterface generates an OMS interface Builder, and create the interface on a device identified through its nodeId, in case an OTS interface already exists on the supporting port, using OpenRoadmInterfaces.postInterface method. Updates the mapping elements for which the interface was created.
  • createOpenRoadmOtsInterface generates an OTS interface Builder, and create the interface on a port (supporting port of mapping object provided as an input parameter) of a device (nodeId) using OpenRoadmInterfaces.postInterface method. Currently sets the fiber type to SMF. Updates the mapping elements for which the interface was created.
  • createOpenRoadmOtu4Interface generates an OTU4 interface Builder, and create the interface on a on a port (supporting port of mapping object provided as an input parameter) of a device (nodeId) using OpenRoadmInterfaces.postInterface method. FEC OTU attribute is configured to Scfec (Staircase FEC). Supporting interface is set to supportOchInterface provided as an input parameter. Updates the mapping elements for which the interface was created.
  • createOpenRoadmOdu4Interface generates an ODU4 interface Builder (monitoring mode terminated, payload and expected payload types 07), and create the interface on a on a port (supporting port of mapping object provided as an input parameter) of a device (nodeId) using OpenRoadmInterfaces.postInterface method. Supporting interface is set to supportOtuInterface provided as an input parameter. Updates the mapping elements for which the interface was created.
  • createOpenRoadmOchInterface generates an OCh interface Builder (wavelength set to wavenumber input parameter) and create the interface on a on a Network port of a device (nodeId) using OpenRoadmInterfaces.postInterface method. In the case of a ROADM port the supporting OMS interface is retrieved from the mapping object). In the case of a transponder port, the rate and modulation format are set to corresponding input parameters, transmit-power is set to -5dBm. Updates the mapping elements for which the interface was created.
  • createOpenRoadmEthernetInterface generates an Ethernet interface Builder (auto negociation enabled, full duplex, fec off, MTU size of 9000L), and create the interface on a on a port of a device (nodeId) using OpenRoadmInterfaces.postInterface method. Updates the mapping elements for which the interface was created.
PortMapping

To be completed

Cross-Connect

To be completed

Render Initial requirements

Renderer logic

proposal ongoing...

Topology management

Topology management description

...