NSTAT SDN Controller Handlers

NSTAT SDN controller handlers are autonomous scripts which perform certain operations required by NSTAT. We currently support controller handlers for the following versions of OpenDaylight

• OpenDaylight Boron SR2 controller
• OpenDaylight Boron controller
• OpenDaylight Beryllium SR3 controller
• OpenDaylight Beryllium controller
• OpenDaylight Lithium SR3 controller
• OpenDaylight Lithium SR2 controller
• OpenDaylight Lithium SR1 controller
• OpenDaylight Helium SR3 controller

However, similar handlers for other SDN controllers (i.e ONOS) are about to be introduced in future releases of this repository. Users are strongly encouraged to submit their own handlers both for ODL or other SDN controllers.

Controller node deployment

Controller handlers can be directly executed on your local machine provided that necessary tools/libraries, prerequisite for the *.sh, *.py handler files are properly installed. However. for keeping your local machine clean, a container based testing environment is provided or can be built as desrcibed below.

The container based testing environment provided, can either be downloaded directly from dockerhub or built from the tools available within the <PROJECT_DIR>/deploy folder.

In both cases, the docker platform must be installed on the host side.

• essential tool: docker (v.1.12.1 or later)

and the actions below have to be followed

• Give non-root access to docker daemon
  • Add the docker group if it doesn't already exist sudo groupadd docker
  • Add the connected user "${USER}" to the docker group. Change the user name to match your preferred user

  sudo gpasswd -a ${USER} docker

  • Restart the Docker daemon:

  sudo service docker restart

Download the pre-built enviroment

Once docker platform is installed, the user can pull the pre-built enviroment as follows

docker pull intracom/nstat-sdn-controllers

Once the image pull operation is complete, check locally the existence of the image

docker images

which should list the intracom/nstat-sdn-controllers:latest image. For running a container out of the intracom/nstat-sdn-controllers:latest image

docker run -it intracom/nstat-sdn-controllers /bin/bash

password: root123

Once logging in the container make a

git clone https://github.com/intracom-telecom-sdn/nstat-sdn-controllers.git nstat-sdn-controllers
git --git-dir=nstat-sdn-controllers/.git --work-tree=nstat-sdn-controllers checkout v.1.0

and start testing all available controller handlers which are present under <PROJECT_DIR>/controllers/ directory

Build your own container based testing environment

Once the docker platform is installed on the host machine, the user can build locally the testing enviroment as follows

Make a git clone of the nstat-sdn-controllers repository within the host machine

git clone https://github.com/intracom-telecom-sdn/nstat-sdn-controllers.git nstat-sdn-controllers
git --git-dir=nstat-sdn-controllers/.git --work-tree=nstat-sdn-controllers checkout v.1.0

Navigate to

<PROJECT_DIR>/deploy/docker/no_proxy directory. Enter the command below to start building locally your own image based on the existing Dockerfile.

docker build -t intracom/nstat-sdn-controllers:latest .

Once the build process is over, verify that the image exists locally

docker images

should list intracom/nstat-sdn-controllers:latest image. Start your own container as mentioned in the previous section.

Controller handling features

Currently the supported controller is OpenDaylight. There is a common API in the controller handling logic, followed by all versions of this controller. Next, we describe this common API logic for the controller handlers.

1. change_persistence.py:
   • expected behaviour: handler disabling the persistence mode in the configuration of the controller. Changes the persistence attribute to false which is present at the org.opendaylight.controller.cluster.datastore.cfg of OpenDaylight. In this case the controller will not backup datastore on the disk. Run the ./get_controller.sh handler before running this handler
   • prereqs: should be executable
   • input arguments: none
   • exit status: 0 in case of success, 1 otherwise
   • usage example: python3.4 change_persistence.py
2. change_stats_period.py:
   • expected behaviour: changes controller statistics interval. Run the ./get_controller.sh handler before running this handler.
   • prereqs: should be executable
   • input arguments: statistic period (in ms)
   • exit status: not checked
   • usage example: python3.4 change_stats_period.py 500
3. flowmods_configure.py:
   • expected behaviour: configures OpenDaylight controller for flow modifications. It currently changes controller configuration files in order to achieve mac-to-mac flow installation for Packet_INs with ARP payload. Run the ./get_controller.sh handler before running this handler
     • <controller base dir>/etc/opendaylight/karaf/54-arphandler.xml: changes the value of key is-proactive-flood-mode from true to false.
     • <controller base dir>/etc/opendaylight/karaf/58-l2switchmain.xml: changes the values of keys reactive-flow-idle-timeout and reactive-flow-hard-timeout to 1. Run the ./get_controller.sh handler before running this handler.
   • prereqs: should be executable
   • input arguments: no input arguments required
   • exit status: not checked
   • usage example: ``python3.4 flowmods_configure.py`
4. get_controller.sh:
   • expected behaviour: gets the pre-built specified version of the OpenDaylight controller.
   • prereqs: should be executable
   • input arguments: none
   • exit status: 0 in case of success, non-zero otherwise
   • usage example: ./get_controller.sh
5. get_flows.py:
   • expected behaviour: returns the number of installed flows of a topology, connected to the controller. This information is extracted from the controller's operational datastore, using RESTCONF. Run the ./get_controller.sh handler before running this handler.
   • prereqs: should be executable
   • input arguments: controller IP address in str form, controller restconf port number in int form, username for restconf authorization in str form password for restconf authorization in str form
   • exit status: not checked
   • usage example: python3.4 get_flows.py '127.0.0.1' 8181 'admin' 'admin'
6. get_hosts.py:
   • expected behaviour: returns the number of hosts of a topology, connected to the controller. This information is extracted from the controller's operational datastore, using RESTCONF. Run the ./get_controller.sh handler before running this handler.
   • prereqs:
   • input arguments: controller IP address in str form, controller restconf port number in int form, username for restconf authorization in str form password for restconf authorization in str form
   • exit status: not checked
   • usage example: python3.4 get_flows.py '127.0.0.1' 8181 'admin' 'admin'
7. get_links.py:
   • expected behaviour: returns the number of links of a topology, connected to the controller. This information is extracted from the controller's datastore, using RESTCONF. Run the ./get_controller.sh handler before running this handler.
   • prereqs:
   • input arguments: controller IP address in str form, controller restconf port number in int form, username for restconf authorization in str form password for restconf authorization in str form
   • exit status: not checked
   • usage example: python3.4 get_flows.py '127.0.0.1' 8181 'admin' 'admin'
8. get_switches.py:
   • expected behaviour: returns the number of switches of a topology, connected to the controller. This information is extracted from the controller's datastore, using RESTCONF. Run the ./get_controller.sh handler before running this handler.
   • prereqs:
   • input arguments: controller IP address in str form, controller restconf port number in int form, username for restconf authorization in str form password for restconf authorization in str form
   • exit status:
   • usage example: python3.4 get_flows.py '127.0.0.1' 8181 'admin' 'admin'
9. start.sh:
   • expected behaviour: starts the controller so that a switch can connect to it. Run the ./get_controller.sh handler before running this handler.
   • prereqs: should be executable
   • input arguments: none
   • exit status: 0 in case of success, non-zero otherwise
   • usage example: ./start.sh
10. status.sh:
    • expected behaviour: queries the controller status. Run the ./get_controller.sh handler before running this handler.
    • prereqs: should be executable
    • input arguments: none
    • output: 1 if controller is running, 0 otherwise
    • exit status: not checked
    • usage example: ./status.sh
11. stop.sh:
    • expected behaviour: stops the controller so that no switch can connect to it. Run the ./get_controller.sh handler before running this handler.
    • prereqs: should be executable
    • input arguments: none
    • exit status: 0 in case of success, non-zero otherwise
    • usage example: ./stop.sh