Transport Slicing Configuration and Operation Guidance
- Hesam Rahimi
In this page, we are listing the required configurations to setup an environment ready for trying the Transport Slicing use case in ONAP.
Below, is the SDNC operation guidance:
Step1: Upgrade your SDNC image version to 2.1.1
After installing the Guilin release of ONAP using oom, upgrade sdnc-image to 2.1.1 version so that it contains the required fixes. The following command is just an example of how this can be done. The values/parameters should be adjusted based on the specific environment configs. For example, the namespace "onap" which comes after "-n", and/or the name of "dev-sdnc", etc. After the following command, search for sdnc-image and change the version to 2.1.1. This operation would terminate the existing sdnc pod and will launch a new one with the new image.
kubectl -n onap edit statefulsets dev-sdnc
Step 2: Configure your SDNC to call a local Path Computation Engine
Since in Guilin release, we did not have a path computation engine (PCE), we rely on configuring a local PCE mechanism so that SDNC can call this PCE to get a path for creating a service from UNI port A (in domain A) to UNI port B (in domain B), depending on the topology that is loaded. For this, SDNC has to be configured in a way that it re-directs the calls to the mentioned local PCE mechanism. This can be done by going into the bash of the SDNC pod, and then by modifying the following parameter in one of the properties files. Here are the detailed steps:
1) Login to SDNC pod:
kubectl -n onap exec -it dev-sdnc-0 bash
2) Once in SDNC pod, go to the following directory:
cd /opt/sdnc/data/properties
3) Edit the following properties file:
vi generic-resource-api-dg.properties
4) Find the line which contains oof-url and edit it by replacing it's current value with the following new value. This is the local PCE system mentioned above. To know the details of how to run such a server, please refer to step 3 below.
restapi.connection-oof-url=${your-local-ip-where-your-local-pce-is-running:server-port}/oof/sotncalc
Step 3: Configure a local Path Computation Engine
Download the zip file that is attached to this wiki page (pce.zip) and unzip it. Then cd inside the "moco" directory and start the server with the following command. This would start this mock PCE server in the background, listening on port 1800 and all logs will be saved into a file named nohup.out:
nohup java -jar moco-runner-0.11.0-standalone.jar http -p 1800 -g main.json &
Note 1: Make sure your endpoint names are correct
Since we are running a mock PCE server, it is important to use the exact endpoint names as this PCE server expects to receive.
- For Domain A:
- tranportEp_src_ID_111_1
- tranportEp_src_ID_111_2
- tranportEp_src_ID_114_1
- For Domain B:
- tranportEp_src_ID_212_1
- tranportEp_src_ID_214_1
- tranportEp_src_ID_212_2
The recommended way to create the endpoints is doing it manually using the postman collection provided in this wiki page. This postman collection does have the required payloads for each of these endpoints (i.e. networkroutes). The payloads have correct "next-hop" values for each of these 6 endpoints. These "next-hop" values are based on our two topologies. Included in this postman collection is the URL and the payload required to create 3 logical links that are connecting these 6 endpoints, however, you do not need to create these logical-links manually because SO creates them for you. You only need to do it manually if you are not testing with SO and instead, you are calling SDNC directly (no SO involved). Please see the postman collection for details.
However, if a user needs to create them using the UUI way described in reference 
below, make sure to use the following values for AN and CN respectively:
UI Operation Guidance for Guilin
- AN: networkId-providerId-10-clientId-0-topologyId-2-nodeId-10.1.1.1-ltpId-512
- CN: networkId-providerId-20-clientId-0-topologyId-2-nodeId-10.2.1.2-ltpId-512
After you created the endpoints for AN and CN as stated above, the outcome is a logical-link that gets created in your AAI. Find which “logical-link” is created in your AAI: You can retrieve all of your logical-links by sending a GET request to your AAI:
- curl -k -u "AAI:AAI" -H "X-FromAppId:AAI" -H "Content-Type:application/json" -H "Accept: application/json" -H "X-TransactionId:99999" -X GET https://{{k8s}}:30233/aai/v21/network/logical-links
Among all the logical-links that you have in your AAI, find the logical-link that is created as a result of your UUI creation. This should be the one that has “TsciConnectionLink” as its link-type attribute.
Now the last step is to configure your mock PCE server (PCE.zip), to expect your newly created logical-link “link-name” attribute as a query parameter instead of the mentioned “tranportEp…”. To do so, find the file named config.json included in the following directory of this PCE.zip file: "./moco/Stubs/testcase/gso", and replace the “tranportEp_src_ID_111_1” query parameter with the new logical-link link-name uuid. Then re-run the java file for this mock PCE server to pickup the change.
Note 2: ESR registration of the third-party domain controllers and topology discovery operation
In order to register a domain controller (or a domain controller simulator as explained in reference (*) below) in the ESR (External System Register) portal of ONAP, a user can do so by entering the controller information in the following web portal:
https://{your-onap-host-ip-address}:30283/iui/aai-esr-gui/extsys/sdncontroller/sdncView.html
Once a third-party controller is being registered in ONAP, a "Topology Discovery" operation will be triggered and the domain controller will be called in order to retrieve the topology. SDNC then, will store the topology in AAI. Please follow the instructions written below in Note 3, for this ESR registration.
Note 3: A known issue with ESR registration of a 3rd party domain controller
The following photo shows the details of a 3rd party controller when a user is registering it in ESR portal. Adjust the URL info accordingly. The password to be used is "rocks" if you use ACTN simulator. There is a known issue in ESR portal which requires a quick fix in one of the DGs so that the topologies can be discovered properly. The issue is about the values shown in the registration web form under the attribute "Type". As can be seen in the following photo, the available types in ESR portal are either WAN or DC, however, SDNC discovery DG expects SOTN so that it can discover the topologies from the ACTN simulators. To fix this issue, please follow the following quick steps:
- Download the json file of the DG (directed graph) that is responsible for topology discovery from the following link:
- Modify this json file by changing the value of SOTN to WAN. SOTN value is in line 415 and 416 of the above file.
- You now need to upload this modified version of the DG into your system. This can be done using the dgbuilder graphical tool, available for us by ONAP to be used. This dgbuilder tool can be accessed by the following URL:
- https://{{k8s}}:30203 or http://{{k8s}}:30203, in case you cannot access it by https.
- once prompted, the default username/password for the dgbuilder tool is: dguser/test123
- You now need to import your modified version of the DG explained above into your dgbuilder. To do so, copy the contents of the modified DG's json file into your clipboard, and from the menu on the top right corner of the dgbuilder tool, click on "import" → "clipboard" and paste the contents of your clipboard into the box and click ok. See this photo for details:
- After importing the graph into the dgbuilder graphical tool, you need to "upload" it into your system/sdnc. To do so, click on the small square box next to the first node called "DGSTART", then click on "Upload XML", and then click on "VewDGList", and then make sure to "Activate" this modified version of the DG that you just uploaded. This is usually shown by "${project.version}" as its version.
- That's it! You now have a modified version of the discovery DG that expects to receive "WAN" from ESR as a type, instead of the mentioned "SOTN".
Note 4: A known issue with "delete slice" operation
There is an small issue in sdnc-image version 2.1.1 which prevents an automatic loading of the directed graph (DG) responsible for a slice deletion (deallocate). Because of that, the deletion DG has to be loaded manually in SDNC. This is an easy step and can be done using dgbuilder tool. The "delete" slice DG in 2.1.1 version of SDNC can be downloaded from the following link:
In case of any issues or in need of any support for the steps mentioned in this wiki page, you are welcome to send your inquiries to Huawei, and in particular to Hesam Rahimi: hesam.rahimi@huawei.com