[TRNSPRTPCE-609] Support of "non-standard" modes (service type/rate/width) Created: 07/Feb/22  Updated: 07/Feb/22

Status: Open
Project: transportpce
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Medium
Reporter: Balagangadhar Bathula Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Epic Link: Higher Rates

 Description   

Require changes to the PCE and service handler code

Rework in the PCE, the PostAlgoPathValidator.

 First we need Service Model 10.1 (pushed by Gilles) and Network Model 10.1 (ongoing). Having this, we will have the specification catalog in the datastore, and the supported Operational mode (for any kind of node) in the topology (if we complement the code). The plan is then to develop generic function to retrieve physical parameters from the catalog, pointing to an operational mode (which can be OR or Specific non-standard mode). Having this we will be able to derive width and spacing associated with any mode. Thus we will be able to change the way MC width is calculated (from OM rather than service type). It will be more generic, and will avoid hardcoding some functions. Update not only the PostAlgoPathvalidator but also the renderer accordingly.



 Comments   
Comment by Guillaume Lambert [ 07/Feb/22 ]

cf comments at https://git.opendaylight.org/gerrit/c/transportpce/+/99497/comment/7037d23f_87e427c8/

with ojnas and orenais

Generated at Wed Feb 07 20:43:33 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.