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:
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 , 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:
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.
Note 3: 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