Page Comparison

...

Service Handler

Optical validation

This section gives an overview of how optical validation function is invoked in different implementations of the PCE.

Ericsson implementation

In the following flowchart the optical validation function is highlighted inside the process of path computation (please note that the detail is very rough in gives only a superficial idea of the actual algorithm). The base is the Dijkstra algorithm, which is augmented with the logic needed to cope with additional constraints, including optical validation, as needed.

Image Added

• Initialize parameters : Initialize the path computation parameters, checking for the correctness of the path computation request, verifying conditions preventing successful path computation. A first SPFI (see below) is generated and inserted in the heap used by the Dijkstra algorithm.
• Extract top SPFI : The relaxation step of the Dijkstra algorithm (that is the propagation of the algorithm along the links of the topology) is named SPFI (Shortest Path First Information). It's used to transport information related to the path computation, like all the cumulative attributes (including metrics) and links with other SPFI, allowing to build the tree of the equal cost optimal paths between source and destination. SPFIs are maintained inside a heap (a priority queue) ordered by the objective metric used during the path computation. The best candidate SPFI is therefore always available on top of the heap.
• Check node connectivity : in optical (and also in other technologies where NEs don't provide full connectivity among their interfaces) it's needed to check that two interfaces can be connected each other. Doing so, it's also possible to collect information about which optical equipment (amplifiers, dcms and more) is traversed.
• Add path : performs operation on the current SPFI in order to link it to previous and sibling SPFIs, with the objective to build the equal cost path tree.
• Expand node : does the visit of the network according to Dijkstra algorithm. Details of this step in the following schema:

Image Added

• 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

...