- no need to explicitly log exceptions that are about to be raised
- kill some extra commented-out prints
Change-Id: I73bae5a2456644c4d4ff45bd984d44c27bc22ec4
TODO: a path containing only transceivers and no roadms leads to no oms
this has not been properly taken into account. (single link w/o ROADM
has no SA complexity and is out of the scope)
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
Create an exception in case of an error due to spectrum problem
eg if spectrum request is not correct
if values are not correct.
use it instead of exit
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
in path assignment function, path elements and reversed path
elements are concatenated to compute the overall spectrum
availability on all elements
in main program, assignment is performed after computing reversed paths
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
reversed_oms is introdused in order to identify which oms correspond
to the reversed direction of a given oms. Indeed for spectrum assignment
it is mandatory to mark spectrum resources occupation on both directions
(requests are supposed bidirectional in WDM).
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
N is the center frequency index (on G694.1 grid) and M the number of slots M,
required by the request according to the computation.
for convenience, we use N and M = 0 when request are blocked. Note that N= 0 is
a valid index when M is not 0.
If the number of slot required by a request is not feasible, the request is marked
as blocked with 'NO_SPECTRUM' as blocking reason
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
Before continuing on spectrum assignment we need to clearly identify blocking reasons:
implicit previous way (a path is missing) is not satisfactory because in case of
spectrum blocking a path was possible. So we introduce a 'blocking_reason' attribute
on requests, that will only exist if the path is blocked during the process.
The 'blocking_reason' attribute refflects the blocking reason.
Commit defines blocking types and group them depending on the existence of path or
feasibility:
'NO_PATH': no path was computed,
'NO_PATH_WITH_CONSTRAINT': no path was computed with this constraint
'NO_FEASIBLE_BAUDRATE_WITH_SPACING': no path was computed due to the spacing constraint
'NO_COMPUTED_SNR': the computed path could not give any SNR result
'NO_FEASIBLE_MODE': the user let the program choose a mode and path was computed but
no mode was feasible for the set of constraints
'MODE_NOT_FEASIBLE': the user imposed a mode, a path was computed but this mode
is not feasible
'NO_SPECTRUM': a path, a mode were selected but there is not enough spectrum available on
this path
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
this is a first function that assigns spectrum following the order
of requests according to the selected mode and nb of channels computed
based on requested path_bandwidth
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
oms_list contains the list of OMS and each OMS contains the list
of uid of each crossed elements (ordered)
each element is updated with the oms_id to which it belongs
each oms contains a bitmap with frequency slots according to
frequency min max defined in eqpt_config.json (SI) and in case oms
are defined elsewhere, there is an alignment of grids to ease computation
the build_OMS_list function builds the OMS list and implements oms attributes
in all network elements
Commit also contains basic functions to handle spectrum bitmap and indexes
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
