for codacy report:
removing extra spces before , and :
adding spaces after , :
adding spaces around < > =
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
- use a new jsontopath_metric function to collect metrics
out of a json response.
- path metrics must be shown also for reversed path if this
is requested. This function avoids repeading code here
- add reversed metrics on the last columns of the CSV
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
- Instead applying bidir option independantly from service demands (json or xls)
the "bidirectional" attribute is introduced per request in the json.
This enables bidirectional option per requests.
if --bidir option is used on the main program, the field is set
to true for all demands in case demands are expressed in an excel
sheet. --bidir option does not change bidir field if the service
file is in json format.
Default value of "bidirectional" attribute is False.
- As a result the reversed path is propagated only if the birectional
field of the request is True. (remember that the reversed path must
be computed whatever the option because it is needed to compute
spectral occupation on both directions).
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 was introdused in order to identify which oms correspond
to the reversed direction of a given oms.
with this commit we make use of this functionality and avoid the cumbersome
way that recovered the reversed path by computing shortest path in the
reversed way for each roadm. This function could not support multiple links
in parallel between two roadms, and was adding computation time.
The function first lists the oms of the pth in the reversed order and then
appends all its elements to the path. the first and last elements are transponder
and are append separately.
Unidir topology are not supported: if there is no reversed path, this raises an error
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>
The couple (N,M) is added on the last column only for non blocked requests
an empty string is used instead
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
The label object is added in the response. It contains center index N value
and number of slots M, required by the request according to the computation.
The label object directly follows the hop attribute as detailed in
draft-ietf-teas-yang-path-computation.
If the path is not blocked this changes the index of the last hop information
(-3 instead of -2) and the index of the transponder for the first hop
(2 instead of 1)
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>
creation of a function to avoid code duplication: json_param creates
the relevant parameters to show on the csv based on json input
replace try/except by a test on keys:
previous way tried to get pth_el['no-path'] and is the path was
not blocked this raised a key error. Now the there is a simple check if
the key is present.
Besides, as the no-path has been change to 'no-path' container containing
a 'no-path' attribute with the blocking reason, the test is made on the
attribute so on pth_el['no-path']['no-path'].
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
if the path is empty NO_PATH reason or NO_PATH_WITH_CONSTRAINT reason
is returned in the blocking_reason attribute
if no mode is feasible, the last explored mode is returned with the path (and
implicitly the last computed SNR). The baud_rate is derived from this last
mode
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
if path could be computed: gives details of the path and on the propagation.
- the 'no-path' attribute is changed to a 'no-path' container that contains:
o the 'response-id' attribute
o a 'no-path' attribute with blocking reason
o if a path could be computed, the 'path-properties' of the path that
was computed with the metrics
Note that this proposal to add information for blocking in the json output (instead
of a bare NO PATH) corresponds to the way PCEp is working in general, but is not yet
integrated in draft-ietf-teas-yang-path-computation model. Returning the whole path
in case of blocking in addition to blocking reason is a novelty from GNPy and was a
request from the users
TODO : use correct ietf model when ready
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>
if name of the constraint input from user is not part of networks names
(typically in the case of excel input), then the program try to find a
name that is clode to the user name and that is in the network list of
names. This list must not include trnasponder names (because transponder
end points are already listed as constraints and transponder in the
middle of a path are not supported yet)
This will be improved in the PR Ila names in constraints #278
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
add a no path case (request 6) in requests and expected responses.
response is also generated if path is not feasible: checks
that it is correctly handled in csv and json responses
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
previously reported the requested bandwidth, now fill it with an
empty string, same as the other fields.
This will be updated in a later PR when different kind of blocking
will be supported
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
previously contained the user-given source name in excel file,
but could differ from effective transponder source/destination
now both source and src-tp-id contain the same info (gnpy does
not make difference between node and ports)
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
previous way used a wrong interpretation of hop-type. in ietf model,
hop-type is reserved for LOOSE or STRICT constraint description.
Instead, transponder info , according to ietf usual way, should be
included aas a new path-route-object type. such object is not yet
defined in IETF so this is a GNPY proposal to use a 'transponder' object
with type and mode attributes.
this is what has been ecncoded in reques.py for requests and for answers
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
in case no path could be computed, the answer is changed according to
ietf path-computation model to a simple 'no-path' object
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
+ removing (currently) unused direction attribute.
This will be added again in a later PR when it will be used
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
- removing empty objects (if no content , removes the object),
especially
- removing empty synchronization vector if no disjunction
constraint exists
- removing optional power and nb of channel fields, if user
did not specify any
when reading, first try if the object exists : try:/except to catch
this case
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
- changes concerning names due to ietf path-computation draft changes:
- 'unnumbered-hop' changed to 'num-unnum-hop'
- suppression of 'label-hop'
- 'link-diverse' and 'node-diverse' changed to 'disjointness'
- correction because of previously wrong interpretation of the model:
- detailed succession on include nodes moved from
'optimisation /explicit-route-include-objects'
to 'route-object-include-exclude'
in 'explicit-route-objects' attribute
- correction of keywords
- n and m replaced by N and M
- strict and loose replaces by STRICT and LOOSE strings
- change the name of respponse from 'path' to 'response'
example service file corrected accordingly
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
I think that this SNR value represents the most important output of this
example. There's plenty of debugging info on display already, so let's
make this one more prominent.
I was thinking about moving the highlighting to elements' each __str__()
function, but that felt a bit like layering violation to me. I could
have also changed just the transponder's __str__(). In the end, I think
that repeating just the final GSNR at the link-end transponder makes
most sense here. This is aligned with what we talked about at
yesterday's (on 2019-09-18 -- note that this is a backport from #261)
demo for Microsoft, after all.
This is inspired by #293. The original issue was that the transponder
OSNR was not accounted for. Rather than making the propagate() and
propagate2() more complex, let's move the actual path printing to the
demo code. There's no secret sauce in there, it's just a simple
for-each-print thingy, so let's remove it from the library code.
fixes#262
The Raman engine computes NLI just for a subset of channels; this is an
important speed optimization because the computation is rather CPU
heavy. However, the code just left NaNs in place for NLI of those
channels which were not explicitly simulated.
This is wrong because these NaNs propagate all the way to the total
input/output powers per the whole spectrum, etc, leading to NaNs being
shown to the user.
This patch uses a very simple linear approximation just in order to
prevent these NaNs.
fixes#288
Both of these places referred to "eq. 123 from arXiv:1209.0394", the
only difference (apart from the source of the input parameters, beta2
and asymptotic_length) was calling the two branches "SCI" and "XCI" vs.
"SPM" and "XPM".
In this commit I've only moved the code to a single implementation. The
input data are still being read from the same parameters, of course.
Conceptually, this is just about propagating the input parameters (which
drive the simulation) into all RamanFiber instances. The network module
already contains similar functions, let's move it there.
