Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 13 Next »

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. Therefore, a user needs to make sure that the endpoint names created in previous steps mentioned in reference (*) below, are with these names:

(star) UI Operation Guidance for Guilin


  • 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

If you are not creating the endpoints using the UUI way described in the above reference (star) , then you can call AAI's RESTFUL API using postman or a curl command to create these endpoints (i.e. networkroute) and the payloads for each of these 6 REST requests as well as the URLs can be found in the postman collection that is attached to this wiki page. Included in this postman collection is the URL and the payload required to create 3 logical links that are representing these 6 endpoints. Please see the postman collection for details.


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:

(star) ACTN Simulator User Guide

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:

  1. Download the json file of the DG (directed graph) that is responsible for topology discovery from the following link:
    1. https://gerrit.onap.org/r/gitweb?p=sdnc/oam.git;a=blob;f=platform-logic/datachange/src/main/json/DataChange_esr-thirdparty-sdnc-discovery.json;h=862817a3732bd8a74bfc1852a768e684fa3a3e8b;hb=093a4df8b8ab3bf56bb5ddc26d5c70fa4d442d6b
  2. Modify this json file by changing the value of SOTN to WAN. SOTN value is in line 415 and 416 of the above file.
  3. 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:
    1. https://{{k8s}}:30203 or http://{{k8s}}:30203, in case you cannot access it by https.
    2. once prompted, the default username/password for the dgbuilder tool is: dguser/test123
  4. 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:
  5. 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.
  6. 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:

https://gerrit.onap.org/r/gitweb?p=sdnc/oam.git;a=blob;f=platform-logic/generic-resource-api/src/main/json/trans_slicing/GENERIC-RESOURCE-API_tsli-vnf-topology-operation-trans-slice-delete.json;h=fc756b8b31c72a1d39c699a51461d1b995ec5f9a;hb=093a4df8b8ab3bf56bb5ddc26d5c70fa4d442d6b


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 









  • No labels