...
- Get Next Link : all the links of the current node (the one referred in the current SPFI) are visited.
- Check node connectivity : as before, it's assessed the possibility to interconnect the incoming link (the one referred in the current SPFI) to the outgoing link (the one just selected by the "Get Next Link" operation).
- Check Boolean constraints : check if there is some attribute of the outgoing link which makes it not suitable to be used by the candidate path (e.g. link disabled, or locked, or with affinities not in compliance with the requirements, and more)
- Check path feasibility : invoke the path feasibility function against the current candidate path (from ingress up to the outgoing link/node). If the path is not feasible no propagation happens through the outgoing link. This is the place where this operation happens (only for optical networks of course). Doing it during the path computation, allows to guarantee the end-to-end feasibility, if it's possible.
- Check additive constraints : check constraints against metrics or other cumulative attributes. E.g. bounds on # of hops, or TE-metric, or latency. Here it's also done the check against lambda availability (to run the RWA exercise).
- Create new SPFI : if the outgoing link passes all the check, a new SPFI is created and populated with the new link and the relevant target node, the new computed metrics, and other attributes. It is then stored in the heap in the order of cost (the metric selected for optimization).
Optical Line Management
Basic Renderer
...
OLM description
Optical Line Management module implements two main features : it is responsible for setting up the optical power levels on the different interfaces, and is in charge of adjusting these settings across the life of the optical infrastructure.
After the different connections have been established in the ROADMS, between 2 Degrees for an express path, or between a SRG and a Degree for an Add or Drop path; meaning the devices have set WSS and all other required elements to provide path continuity, power setting are provided as attributes of these connections. This allows the device to set all complementary elements such as VOAs, to guaranty that the signal is launched at a correct power level (in accordance to the specifications) in the fiber span. This also applies to X-Ponders, as their output power must comply with the specifications defined for the Add/Drop ports (SRG) of the ROADM. OLM has the responsibility of calculating the right power settings, sending it to the device, and check the PM retrieved from the device to verify that the setting was correctly applied and the configuration was successfully completed.
OLM requirements
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
Topology management
Topology management description
Transport PCE Topology management module builds the Topology according to the Network model defined in OpenROADM. This guaranties that an OpenROADM optical infrastructure is supported, but does not prevent further extensions to support additional equipment (legacy or new equipment that are not OpenROADM compliant). The topology is aligned with I2RS model. It includes several network layers:
- CLLI layer corresponds to the locations that host equipment
- Network layer corresponds to a first level of disaggregation where we separate Xponders (transponder, muxponders or switchponders) from ROADMs
- Topology layer introduces a second level of disaggregation where ROADMs Add/Drop modules ("SRGs") are separated from the degrees which includes line amplifiers and WSS that switch wavelengths from one to another degree
- OTN layer includes OTN elements having or not the ability to switch OTN containers from client to line cards
OpenROADM Topology
The topology is built retrieving information of all NETCONF Devices. ROADM to ROADM link are discovered using the lldp information embedded in the device (neighbors).
Topology management implementation
The topology is built dynamically as NETCONF OpenROADM nodes appear or disappear. As soon as the information to reach a NETCONF Node is provided to the controller, this last tries to establish a session with the corresponding node. If the connection is successful (connected status) the mounted node will be added automatically to the OpenRoadm topology through the Topology Management bundle. In this section we focus on the description of the main classes of the Topology Management bundle. Thus this description shall not be considered as exhaustive. It only provides information on the main building blocks of the Topology Management bundle, to clarify its purpose and give some high level details on its implementation.
NetworkModelprovider class, at initialization creates the different layers of the OpenROADM topology calling create<Clli / OpenRoadmNetwork / Topo>Layer methods NetconfTopologyListener class implements DataTreeChangeListener for the nodes. It defines several methods to handle all operations that shall be trigged when a new NETCONF OpenROADM node is connected/disconnected. OnDataTreeChanged method is overridden so that on a modification of a DataTree, corresponding LOG are produced, OndeviceConnected or OndeviceDisconnected methods are called. In the case a new device is connected, it also calls networkModelService.createOpenROADMNode method which will lead to the creation of the node at the level of the Topology. OnDeviceConnected method tries to get a mountpoint for the node, and instantiate all required listener : AlarmNotification, DeOperations, Device and TCA. It also launches RPC service for the node. OndeviceDisconnected removes node registration and close Listener registration services.
NetworkModelService.impl implements NetworkModelService interface and overrides createOpenROADMNode method. As explained above, this last is called when The NETCONF Topology listener detects a change in a DataTree for a specific node. It launches the creation of mapping data (mapping between device data such as Circuit-pack, ports… and abstracted data used by the Path Computation Engine as nodes, Logical connection points and links), and the creation of the node at the different level of the topology (CLLI, UNDERLAY, OVERLAY). It also calls R2RLink Discovery.readLLDP method to get information about identified lldp neighbors, and create the corresponding ROADM to ROADM link through createR2Rlink method.
ClliNetwork, OpenROADMNetwork and OpenROADMTopology are the three classes used to build the multi-layer topology. They are structured in the same way:
- a method create<Clli/OpenRoadmNetwork/Topo>Layer is used to create an object for the corresponding empty layer (CLLI, UNDERLAY & OVERLAY Layers, OTN layer will being addressed at a later step) in the MDSAL CONFIGURATION DataStore.
- a method create<Network/OpenRoadmNetwork/OpenRoadmTopology> is used to create an object for the corresponding empty network (CLLI, UNDERLAY & OVERLAY Networks, OTN network being addressed at a later step) in the MD-SAL CONFIGURATION DataStore.
- For CLLI and Underlay Network, a method createNode is used to create a single Node entry for the corresponding Network/layer. Information about the node are retrieved directly from the node DataStore using the DeviceTransactionManager. For overlay Network where we do not only separate Xponders from ROADM but where ROAD nodes are fully disaggregated, a method createTopologyShard is used to create all the elements corresponding to the disaggregated node in the MD-SAL CONFIGURATION DataStore. For ROADMs, this methods create all SRGs and Degrees, as well as all links interconnecting these disaggregated elements: express, add and drop links. For xpdr nodes, the method creates all required nodes. In the current implementation, only transponders nodes are created: as many nodes as client interfaces are created. Next implementation will address muxponders, and switchponders will be addressed at a later step. The method createTopologyShard relies on different methods to create the corresponding elements: createXpdr, createSrgNode, create DegreeNode, createExpressLinks and createAddDropLinks, which both rely on createLink. Additional methods are used to create the specific elements of the topology tree: ROADM’s TPs (TTPs, CTPs, CPs and PPS).
These Classes allow to initiate the different layers and to populate them with OpenROADM nodes. They are complemented by the classes handling Link discovery and creation, and are instanciated through NetworkModelServiceImpl.
R2RLinkDiscovery class is used to discover ROADM to ROADM links, from the lldp information stored in the nodes, and to populate the topology with this link (indirectly through the OrdLink class). It includes different utility methods that allow getting the degree, connection ports and their characteristics (uni/bi-directional) from the information of the interfaces (local/neighbor) embedded in the lldp info. The 3 main methods used to get lldp node information, and to create and delete ROADM to ROADM nodes are the following:
- readLLDP reads information related to lldp protocols in the devices. If a neighbor is present in the lldp tree, it calls another method to create the link from the node to the neighbor in the OVERLAY topology. If a neighbor has disappeared, it calls the another method to remove the link associated with a specific interface from the OVERLAY topology.
- createR2Rlink method, from information on A (local) and Z (remote or “neighbor”) nodes, checks the nature of the source and destination ports (uni/bi-directional) and a creates a Builder for the input of the RPC initRoadmNodes. Indeed, the creation of link in the OVERLAY topology involves two different processes: the link itself as existing between 2 operational nodes can be populated in the MD-SAL topology model from the information gathered through lldp protocol, but the OMS attributes includes some information that is not available in the device, but comes from external database (list of successive sections with corresponding cable/fiber-trunk, Shared Risk Link Groups, measured attenuations and PMD…). The OMS attributes is populated in the topology, through the REST Northbound interface, using the RPC initRoadmNodes.
- deleteR2Rlink method deletes from the OVERLAY topology in the CONFIGURATION Data Store the link from the node to neighbor.
OrdLink class includes the method createRdm2RdmLinks which creates a builder for the ROADM to ROADM link in the OVERLAY topology and post the new link in CONFIGURATION Data Store
Rdm2XpdrLink class includes the methods createXpdr2RdmLinks and createRdm2XpdrLinks which creates the links between ROADMs and Xponders in the OVERLAY topology (CONFIGURATION Data Store). They both rely on createNetworkBuilder method to create the builders. NetworkUtilsImpl publishes the different RPC associated with link creation. Link creation implies some actions from operational staff using RESTCONF northbound interface. For ROADM to ROADM link the OMS attributes must be entered to provide information about the structure of the OMS link and describe the succession of fiber/cables it is made of. As Xponders may be provisioned after the WDM infrastructure has been put in place, it is also necessary to populate the planned links in the topology database after the Xponders are in place .
The RPC initRoadmNodes, is used to create ROADM to ROADM links and populate the OMS attributes. The RPC initXpdrRdmLinks and initRdmXpdrlinks are used to create the XPONDER-ROADMs link that cannot be discovered through lldp. ....
Topology management initial requirements
To be completed