mirror of
https://github.com/Telecominfraproject/oopt-gnpy.git
synced 2025-11-02 11:07:57 +00:00
docs: Move the gnpy-path-requests into README
This looks like something that's been "always" part of the Excel guide. I think it is better placed in the README. After the releae we migth want to improve the docs even more, but hey, that's something which should be done after some discussion, not via these commits that I'm going to self-approve shortly. Change-Id: Icd73f4bb3a43f1a684ec7a364e4ebcc9b8e6af88
This commit is contained in:
Jan Kundrát
@@ -138,6 +138,14 @@ This program requires a list of connections to be estimated and the equipment
|
|||||||
library. The program computes performances for the list of services (accepts
|
library. The program computes performances for the list of services (accepts
|
||||||
`JSON <docs/json.rst>`__ or `Excel <docs/excel.rst>`__ format) using the same spectrum propagation modules as
|
`JSON <docs/json.rst>`__ or `Excel <docs/excel.rst>`__ format) using the same spectrum propagation modules as
|
||||||
``gnpy-transmission-example``.
|
``gnpy-transmission-example``.
|
||||||
|
The output format is based on `draft-ietf-teas-yang-path-computation-01 <https://tools.ietf.org/html/draft-ietf-teas-yang-path-computation-01>`_ with custom extensions (e.g., for transponder modes).
|
||||||
|
An example of the JSON input is provided in file `service-template.json`, while results are shown in `path_result_template.json`.
|
||||||
|
|
||||||
|
Important note: ``gnpy-path-request`` is not a network dimensionning tool: each service does not reserve spectrum, or occupy ressources such as transponders. It only computes path feasibility assuming the spectrum (between defined frequencies) is loaded with "nb of channels" spaced by "spacing" values as specified in the system parameters input in the service file, each cannel having the same characteristics in terms of baudrate, format,... as the service transponder. The transceiver element acts as a "logical starting/stopping point" for the spectral information propagation. At that point it is not meant to represent the capacity of add drop ports.
|
||||||
|
As a result transponder type is not part of the network info. it is related to the list of services requests.
|
||||||
|
|
||||||
|
The current version includes a spectrum assigment features that enables to compute a candidate spectrum assignment for each service based on a first fit policy. Spectrum is assigned based on service specified spacing value, path_bandwidth value and selected mode for the transceiver. This spectrum assignment includes a basic capacity planning capability so that the spectrum resource is limited by the frequency min and max values defined for the links. If the requested services reach the link spectrum capacity, additional services feasibility are computed but marked as blocked due to spectrum reason.
|
||||||
|
|
||||||
|
|
||||||
Contributing
|
Contributing
|
||||||
------------
|
------------
|
||||||
|
|||||||
@@ -226,44 +226,3 @@ Service sheet must contain 11 columns::
|
|||||||
- is loose? 'no' value means that the list of nodes should be strictly followed, while any other value means that the constraint may be relaxed if the node is not reachable.
|
- is loose? 'no' value means that the list of nodes should be strictly followed, while any other value means that the constraint may be relaxed if the node is not reachable.
|
||||||
|
|
||||||
- **path bandwidth** is mandatory. It is the amount of capacity required between source and destination in Gbit/s. Value should be positive (non zero). It is used to compute the amount of required spectrum for the service.
|
- **path bandwidth** is mandatory. It is the amount of capacity required between source and destination in Gbit/s. Value should be positive (non zero). It is used to compute the amount of required spectrum for the service.
|
||||||
|
|
||||||
gnpy-path_request
|
|
||||||
-----------------
|
|
||||||
|
|
||||||
**Usage**: gnpy-path-request [-h] [-bi] [-v] [-o OUTPUT]
|
|
||||||
[network_filename xls or json] [service_filename xls or json] [eqpt_filename json]
|
|
||||||
|
|
||||||
optional arguments::
|
|
||||||
|
|
||||||
-h, --help show the help message and exit
|
|
||||||
-bi, --bidir considers that all demands are bidir
|
|
||||||
-v, --verbose increases verbosity for each occurence
|
|
||||||
-o OUTPUT, --output OUTPUT file to record results (.json and .csv formats are created)
|
|
||||||
|
|
||||||
.. code-block:: shell
|
|
||||||
|
|
||||||
$ cd $(gnpy-example-data)
|
|
||||||
$ gnpy-path-request meshTopologyExampleV2.xls service_file.json eqpt_file -o output_file.json
|
|
||||||
|
|
||||||
A function that computes performances for a list of services provided in the service file (accepts json or excel format.
|
|
||||||
|
|
||||||
if the service <file.xls> is in xls format, ``gnpy-path-request`` converts it to a json file <file_services.json> following the Yang model for requesting Path Computation defined in `draft-ietf-teas-yang-path-computation-01.txt <https://www.ietf.org/id/draft-ietf-teas-yang-path-computation-01.pdf>`_. For PSE use, additional fields with trx type and mode have been added to the te-bandwidth field.
|
|
||||||
|
|
||||||
A template for the json file can be found here: `service_template.json <service_template.json>`_
|
|
||||||
|
|
||||||
|
|
||||||
If no output file is given, the computation is shown on standard output for demo.
|
|
||||||
If a file is specified with the optional -o argument, the result of the computation is converted into a json format following the Yang model for requesting Path Computation defined in `draft-ietf-teas-yang-path-computation-01.txt <https://www.ietf.org/id/draft-ietf-teas-yang-path-computation-01.pdf>`_. TODO: verify that this implementation is correct + give feedback to ietf on what is missing for our specific application.
|
|
||||||
|
|
||||||
A template for the result of computation json file can be found here: `path_result_template.json <path_result_template.json>`_
|
|
||||||
|
|
||||||
Important note: ``gnpy-path-request`` is not a network dimensionning tool : each service does not reserve spectrum, or occupy ressources such as transponders. It only computes path feasibility assuming the spectrum (between defined frequencies) is loaded with "nb of channels" spaced by "spacing" values as specified in the system parameters input in the service file, each cannel having the same characteristics in terms of baudrate, format, ... as the service transponder. The transceiver element acts as a "logical starting/stopping point" for the spectral information propagation. At that point it is not meant to represent the capacity of add drop ports
|
|
||||||
As a result transponder type is not part of the network info. it is related to the list of services requests.
|
|
||||||
|
|
||||||
The current version includes a spectrum assigment features that enables to compute a candidate spectrum assignment for each service based on a first fit policy. Spectrum is assigned based on service specified spacing value, path_bandwidth value and selected mode for the transceiver. This spectrum assignment includes a basic capacity planning capability so that the spectrum resource is limited by the frequency min and max values defined for the links. If the requested services reach the link spectrum capacity, additional services feasibility are computed but marked as blocked due to spectrum reason.
|
|
||||||
|
|
||||||
In a next step we plan to provide required features to enable dimensionning : alocation of ressources, counting channels, limitation of the number of channels, ...
|
|
||||||
|
|
||||||
(in progress)
|
|
||||||
|
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user