Skip to content


Switch branches/tags

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

Latest commit


Git stats


Failed to load latest commit information.
Latest commit message
Commit time


###WAN Infrastructure and Connectivity Manager

WICM is an implementation of the ETSI MANO defined WIM (WAN Infrastructure Manager) for the T-Nova project.

WIM is described ETSI ETSI GS NFV-MAN 001 V1.1.1 as:

Interface with the underlying Network Controllers to request virtual connectivity services. In such a case, the VIMs/WIMs interface with the Network Controllers over the Nf-Vi reference point. There could be multiple Network Controllers under a VIM (for example, if different virtual network partitioning techniques are used within the domain); in this case, the VIM is responsible to request virtual networks from each underlying Network Controller and setup the interworking function between them. This acknowledges the fact that there might be existing Network Controllers in the NFVI already deployed and in use for connectivity prior to the instantiation of the VIM/NFVO.

Establish the connectivity services directly by configuring the forwarding tables of the underlying Network Functions, hence becoming the Network Controller part of the VIM (although it is not explicitly shown in the figure). In such a case, the VIM directly controls some elements, for example, a software switch (a.k.a. vSwitch). This could also be the case if there are Network Functions that do not fall within the Administrative Domain of a Network Controller.

WICM in T-Nova

WICM in T-Nova works as an enabler for allowing the clients to acquire/use virtual network functions as a service. It is responsible for redirecting traffic from a client into a or several NFVI-PoP(s), by means of SDN switches. The switches are connected using VxLAN tunnels when direct cable connections are unavailable.

Consider the base scenery for IP/MPLS VPN:


PE stands for Provider Edge and CE for Client Edge. Client Site 1 has vlan 100 for its attachment circuit to the PE router, while Client Site 2 has vlan 200.

Client 1 would like to use some network virtual functions provided by it's network provider, available at the NFVI-PoPs: nfvi1 and nfvi2. nfvi1 is close to client 1 while nvfi2 if farther away. Which one to use is negotiated by the client and the provider, even both can be used. In this example traffic from the client site 1 to the internet will go first to the nfvi1 while traffic comming in from the internet will go first to the nfvi2 and then nfvi1.

To redirect the traffic from client 1 to the NFVI-PoPs we will use a SDN switch:


Now the orchestrator may request WICM to redirect traffic from client 1 into the nfvi-pops, WICM is also in charge to configure the SDN switches to send processed packets to their original destination.

This request is done in a two-step process:

  1. Orchestrator requests WICM to reserve vlans for each of the NFVI-PoP(3 vlans in this case) that are going to be used for the client.

  2. WICM answers with a vlan per nfvi pop per direction requested. These vlans are now reserved for that client.

  3. Orchestrator instantiates the respective services in the correct vlans in order to receive the redirected traffic. And then, once the VNFs are ready requests WICM to start redirecting traffic.

  4. Traffic redirection is enabled!

####For example if WICM reserved vlan 400@nfvi1 for direction ce->pe and vlan 400@nfvi2 for direction pe->ce the traffic would flow like this:

From the Client site to the Internet:


From the Internet to the Client site:


The whole process is transparent to both the PE and CE routers involved, with them only seeing vlan 100. Ensuring compatibility with legacy networks with minimum cost.

SDN switches modify the vlans assuring that packets enter both the routers and the nfvi-pops with correct vlans.

One nfvi-pop can be shared by several clients, just as long as vlans are available.



WICM uses OpenDaylight plus the VTN (Virtual Tenant Network) plugin to control the SDN switches and handle the low level redirection details.


WICM uses MariaDB or mySQL for persistence.


WICM is presented as a self-contained docker-compose file incorporating WICM, OpenDaylight and MariaDB. To run do on the WICM folder:

docker-compose build
docker-compose up -d

Then you will need to initiate the database:

curl -X DELETE  WICM_IP:12891/reset_db

In a production deployment this option should be disabled.

WICM will be available on port 12891.

Running just WICM

To do so use the wicm.dockerfile found in the WICM directory. Make sure to update the configuration file (wicm.ini).


To test WICM you can use the Vagrantfile(demo/Vagrantfile) provided. It will create a virtual machine containing WICM and a simple test network:


Switches 3 and 4 simulate the NFVI-PoPs, are pre-programmed and not controlled by the WICM. Hosts h1 and h2 simulate the CE and PE, respectively.

To start the demo, on the demo directory do:

vagrant up

Once the machine is up it can be accessed:

vagrant ssh 

Enter the mininet and try:

sudo screen -rx
h1 ping h2
mininet> h1 ping h2
PING ( 56(84) bytes of data.
From icmp_seq=1 Destination Host Unreachable
From icmp_seq=2 Destination Host Unreachable
From icmp_seq=3 Destination Host Unreachable

The ping fails because the NAP(Network Access Point) is not yet registered, to register it issue the following command on the virtual machine:

curl -X POST localhost:12891/nap \
    -H "Content-type: application/json"  \

The payload in a read friendly format:


Meaning that client c1 has a NAP identified by c1_nap1 on SDN switch openflow:1. In the switch's port 1 with vlan 100 is connected the CE and on port 2 is connected the PE also with vlan 100. Only vlans are supported at the moment. The ids fields are assign/used by orchestrator (TeNOR).

This allows WICM to configure the SDN switch to allow the client site to access the internet and later this will be the point where the redirection to the NFVI-PoP(s) will occur.

Now the ping will work.

mininet> h1 ping h2 
PING ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=64 time=1.95 ms
64 bytes from icmp_seq=2 ttl=64 time=0.183 ms
64 bytes from icmp_seq=3 ttl=64 time=0.261 ms

Now that the basic connectivity is up, redirection is the next step. First we register the NFVI-PoPs, in this case switches s3 and s4 that will circulate the packets in the assigned vlans:

curl -X POST localhost:12891/nfvi \
    -H "Content-type: application/json"  \
    -d '{"nfvi":{"mkt_id":"nfvi1","switch":"openflow:1","port":3}}'

curl -X POST localhost:12891/nfvi \
    -H "Content-type: application/json"  \
    -d '{"nfvi":{"mkt_id":"nfvi2","switch":"openflow:2","port":1}}'

The payload in a read friendly format:


Meaning that NFVI-PoP nfvi1 is available in SDN switch openflow:1, in port 3. The NFVI-PoP has no client associated because it belongs to the service provider and may hold VNFs for several clients. Payload for the second request is similar.

We are now ready to start redirecting from NAP c1_nap1 to the NFVI-PoPs:

The first step of the process:

curl -X POST localhost:12891/vnf-connectivity \
    -H "Content-type: application/json" \


The payload in a read friendly format:


Requesting a redirection from c1->nfvi1->nfvi2->Internt and from the Internet->nfvi1->c1.

Once we make this request to WICM it returns:

  "allocated": {
    "pe_ce": [
        "nfvi_id": "nfvi1", 
        "transport": {
          "type": "vlan", 
          "vlan_id": 400
        "nfvi_id": "nfvi2", 
        "transport": {
          "type": "vlan", 
          "vlan_id": 400
    "ns_instance_id": "service1", 
    "ce_pe": [
        "nfvi_id": "nfvi1", 
        "transport": {
          "type": "vlan", 
          "vlan_id": 401

Meaning vlans 400@nfvi1 for direction ce->pe and vlans 400@nfvi2 and 401@nfvi1 for direction pe->ce are reserved for the request service1, keep in mind that at this time no redirection is occurring. The vlans are reserved so TeNOR may instantiate the VNFs at nfvi1/nfvi2 correctly to receive the traffic on the assign vlans.

Once the VNFs are ready, TeNOR request WICM to start the traffic redirection. As mentioned before the nfvi-pops are already configured, so one can immediately:

curl -X PUT localhost:12891/vnf-connectivity/service1

You can use, on the virtual machine, to confirm that the packets are passing through nfvi1 while h1 is pinging h2.

watch sudo ovs-ofctl -Oopenflow13 dump-flows s3

Notice that the n_packets will increase when the redirection is up.

Finally to stop the redirection use:

curl -X DELETE localhost:12891/vnf-connectivity/service1

Rest Of the API

Check all NAPs:

curl localhost:12891/nap

Delete a NAP

curl -X DELETE localhost:12891/nap/<NAP_ID>

Check all NFVI-PoPs:

curl localhost:12891/nfvi

Delete a NFVI-PoPs:

curl -X DELETE localhost:12891/nfvi/<NFVI_ID>

Check all redirections

curl localhost:12891/vnf-connectivity


WAN Infrastructure and Connectivity Manager






No releases published


No packages published