Configuration

In order to achieve functionality with the WICM Application, the following configuration steps must be done first.

Opendaylight and VTN Manager Configuration

The DEMI-WICM is an application able to steer data traffic whenever a new service is instantiated from the NFVO, across multiple NFVI PoPs. In order to achieve this an SDN switch, managed by an SDN controller is required. The SDN controller that the WICM node synergises is Opendaylight (version Beryllium SR2) with VTN Manager module installed.

OpenDaylight Virtual Tenant Network (VTN) is an application that provides multi-tenant virtual network on an SDN controller. VTN allows the users to define the network with a look and feel of conventional L2/L3 network. Once the network is designed on VTN, it will automatically be mapped into underlying physical network, and then configured on the individual switch leveraging SDN control protocol. The definition of logical plane makes it possible not only to hide the complexity of the underlying network but also to better manage network resources. A guide to the installation of the components can be found here:

https://wiki.opendaylight.org/view/VTN:Beryllium:Installation_Guide#VTN_Manager

Once VTN Manager is installed the underlying physical components have to be mapped into the module. At first, a VTN tenant has to be created, in which an appropriate, depending on your infrastructure,  number of vBridges has to be also provided. This can be done following the examples here:

1.Create the  Virtual Tenant 


curl --user "admin":"admin" -H "Content-type: application/json" -X POST \ http://controller-IP-address:8181/restconf/operations/vtn:update-vtn \ -d '{"input":{"tenant-name":"vtn1"}}'

2.Create the vBridge (as many as is appropriate)
:

curl --user "admin":"admin" -H "Content-type: application/json" -X POST \ http://controller-IP-address:8181/restconf/operations/vtn-vbridge:update-vbridge -d '{"input":{"tenant-name":"vtn1","bridge-name":"vbr1"}}

Each vBridge created should correspond to a switch created in the SDN switch and then assigned to Opendaylight controller. When this steps are completed, the naming of each switch, needed for the next steps can be found on the GUI Opendaylight provides.

The next step is to create the interfaces on each vbridge. This process should be repeated for all the interfaces that need to be created, for each vbridge separately. Note, that the naming is arbitrary.

3.Create the interfaces: 
 curl --user "admin":"admin" -H "Content-type: application/json" -X POST \
http://localhost:8181/restconf/operations/vtn-vinterface:update-vinterface -d '{"input":{"tenant-name":"vtn1","bridge-name":"vbr1","interface-name":"if1"}}'

4.Map each port and interface to the switches
:

curl --user "admin":"admin" -H "Content-type: application/json" -X POST \ http://localhost:8181/restconf/operations/vtn-port-map:set-port-map \ -d '{"input":{"tenant-name":"vtn1", "bridge-name":"vbr1", "interface-name":"if2", "node":"openflow:1190155840745766944", “port-name":"ge-1/1/2"}}'

In this last step of the VTN configuration, the mapping of each interface created with the actual ports has to be performed. In this case the naming of each node and port-name should correspond to actual values already defined. For each node in the controller, there should be a different vbridge with as many interfaces as the node has. Then for the specific id of each node, there should be a number of ports with unique names.

The information can be taken, by going to the nodes tab, and clicking on each of the nodes presented there. In the request made to the VTN, the field “node” should be that of the node id, as seen above. In the field “port-name”, the port’s name as presented should be given. The process should be done for all the ports, corresponding to different interfaces, with each node being a different vbridge.

WICM Configuration

The WICM application consists of three modules, the REST API, the Traffic Redirection Services and the WICM Database. In order for the application to function properly, the Database must be preconfigured in order to contain the underlying physical network configuration attributed to the Opendaylight controller.

The first step towards the configuration is to run a helper python script packaged with the project that creates the sqlite database and provides an easy way to populate. Note that even if one wishes to use another tool to populate it, the script still needs to be run in order for the database to be created. Run the script, from the root folder, with the command: python3 wicm/database/insert_info.py

The information that needs to be provided are: Network segment, VIM name (if applicable, must be the same with that defined in NFVO), Vbridge (as defined earlier), and interface id(the arbitrary name given earlier)

For example if there is a VIM named SOFTFIRE-pop, located at IP: 192.168.20.1, and we know is located in the vBridge vbr1, created earlier, and interface_id: if2, mapped to port: ge-1/1/2, the following data have to be inserted to the allocated fields:

Segment : 192.168.20.1/32
VIM Name : SOFTFIRE-pop Bridge Name : vbr1 Interface ID : if2

Then the script will show the info provided, and if agreed it will store them to the db. Proceed for all the interface and ports mapped earlier. Note, that for each vBridge, the port that allocates to the vlan entry/exit, the port that essentially connects the switch to the rest of the WAN, the segment to be provided should be. 0.0.0.0/0 . Also, for the other cases, remember to always enter the entire network segment and not just the IP. This has to be done for every interface of each vBridge that is the one that the vlan corresponds.

Once the database is properly configured then the WICM application is ready to run. In order to achieve this the following command from root folder has to be executed:

python3 wicm/wicm.py -v vtnHostIP -u username -p userpassword -n VTN_name

For example, if Opendaylight is running at IP 192.168.30.13 , with username: admin, password: admin, and the VTN name: VTN1 (as created earlier in the configuration), the command would be:

python3 wicm/wicm.py -v 192.168.30.13. -u admin -p admin -n VTN1

At this point the WICM application should be running. If any issue arises, it can be located through the log file, wicm.log, which will be created inside the folder wicm. However, the configuration is still not done, the source of the traffic data, as well as the target, has to be registered, as the NFVO doesn’t send this information. This can be achieved with two simple API calls. If the WICM runs at localhost, the source of the traffic is 192.168.20.20, and the target is 192.168.40.20, then the following requests must be send:

For the source:

curl -X PUT http://localhost:5000/api/v1/source -d ‘{“source”: “192.168.20.20/32” }’

And for the target:

curl -X PUT http://localhost:5000/api/v1/target -d ‘{“target”: “192.168.40.20/32” }’

Finally, in order to for the WICM to receive the NSR from the NFVO, either to deploy a new service or delete an existing one, its respectively REST interfaces have to be subscribed to the NFVO’s events. This can be easily achieved by finding the tab events, under tab Orchestrate NS at the Openbaton graphical interface. There, a button “Add a new Event” can be found and when clicked it prompts to fill some fields. A name of our choice can be given to each event registered. Note, that in order to register successfully to an event the WICM should be running at the time, so the NFVO will have access to it

To subscribe to the event of an successful NSR deployment, choose event: “INSTATIATE_FINISH”, type: “REST”, leave the other fields empty and add as endpoint the following: wicm_ip:5000/api/v1/nfvo/init To subscribe to the event of an successful NSR delete, choose event: “RELEASE_RESOURCES_FINISH”, type: “REST”, leave the other fields empty and add as endpoint the following: wicm_ip:5000/api/v1/nfvo/delete