This document outlines a tutorial on OpenDaylight focusing on SDN and NFV, detailing its architecture, essential tools, and components for application development. It includes hands-on exercises for creating a learning switch, flow programming through REST APIs, and building a traffic monitoring tap application. The tutorial emphasizes the use of Java, Maven, and OSGi for modular application development, demonstrating how to set up and run a project within a virtual machine environment.

1. OpenDaylight -
SDN-NFV Tutorial
Basics and Hands On
dec/2016
Prof. Christian Rothenberg (FEEC/UNICAMP)
PhD candidate Javier Quinto (UNICAMP & INICTEL-UNI)

2. Agenda
● Introduction to Open DayLight (ODL)
● Exercise 1: Learning-Switch
● Exercise 2: Flow Programming Through REST
● Exercise 3: TAP Application

3. Open DayLight
Introduction

4. High-level Architecture (versión 0.3)

5. 1. Get familiar with the Model-View-Control approach for app
development in a modular fashion
- YANG Model for data, RPC and notifications
- RESTconf View generated automatically
- Implementation in Java or Scala to handle data changes, notifications and
RPC call backs
2. Get familiar with platform essentials (maven, config
subsystem, dependencies) and useful tools
3. Learn about existing projects and reuse modules
- No need to change code of other projects. Just link them as binary libraries
What does it mean to program in ODL

6. Outdated Tutorial: This is focused solely on:
- OpenFlow based app development
- API driven SAL that is similar in spirit to what ONOS uses
OSGi based activation
Current Tutorial:
- Approaches app development from the perspective of
YANG modeling since it is core to OpenDaylight
- Model driven SAL (MD-SAL) for all state handling
Uses config subsystem for bundle activation
What’s new in this tutorial?

7. Java, Maven, OSGi, Interface
● Java chosen as an enterprise-grade,
cross-platform compatible language.
● Maven build system for Java, uses
pom.xml (Project Object Model for
this
bundle) to script the dependencies
between bundles and also to
describe
what bundles to load on start.
Developing OSGi Components for OpenDaylight
● OSGi
- Allows dynamically loading bundles.
- Allows registering dependencies and services exported.
- For exchanging information across bundles.
● Java Interfaces are used for event listening, specifications and forming patterns.
● Karaf: Karaf is a small OSGi based runtime which provides a lightweight container
for loading different modules.

8. The tutorial application that we will work with is located in
/home/tutorial/SDNHub_OpenDaylight_tutorial directory.
Open a Terminal tab (Ctrl-Shift-T) and go into the
SDNHub_Opendaylight_Tutorial folder where we have
included sample applications that this tutorial will focus on:
1) a Hub / L2 learning switch
2) a network traffic monitoring tap.
Setup

9. For a better handling of this tutorial, we have created six environment variable in
“.bashrc” file.
a) Go to controller path:
export
control=~/SDNHub_Opendaylight_Tutorial/distribution/opendaylight-karaf/target/assembly/bin/
b) Go to learning-switch code:
export
learn=~/SDNHub_Opendaylight_Tutorial/learning-switch/implementation/src/main/java/org/sdn
hub/odl/tutorial/learningswitch/impl/
c) Go to deploy folder:
export
deploy=~/SDNHub_Opendaylight_Tutorial/distribution/opendaylight-karaf/target/assembly/depl
oy
d) Go to target folder:
export target=~/SDNHub_Opendaylight_Tutorial/learning-switch/implementation/target
e) go to learning-switch folder:
export program1=~/SDNHub_Opendaylight_Tutorial/learning-switch
f) go to TAP folder:
export program2=~/SDNHub_Opendaylight_Tutorial/tapapp
Setup

10. To build Open DayLigth Tutorial in our VM, we have required JDK 1.8 and
Apache Maven 3.3.9. The following commands allow building maven and
install components in the controller:
$ cd ~/SDNHub_Opendaylight_Tutorial/ # Go to our working space
$ mvn clean install # Cleaning anything of maven and install again, (this
step is done, not repeat it again!)
$ cd $control # Go to the path from Open DayLigth controller
$ ./karaf debug # Start the controller
karaf> feature:install sdnhub-XYZ # Install any program available in the
controller
How to Build ( Not doing this step for now)

11. ● pom.xml: The POM in the main directory specifies all the
sub-POMs to build
● commons/parent: contains the parent pom.xml with all properties
defined for the subprojects.
● commons/utils: contains custom utilities built for OpenFlow
programming
● learning-switch: contains the tutorial L2 hub / switch
● tapapp: contains the traffic monitoring tap application
● features: defines the two features
"sdnhub-tutorial-learning-switch", "sdnhub-tutorial-tapapp"
that can be loaded in Karaf
● distribution/karaf-branding: contains karaf branner for SDN Hub
● distribution/opendaylight-karaf: contains packaging relevant pom
to generate a running directory
Directory Organization

12. Maven and project building
Let’s start with building the tutorial project in the VM using the following step:
~/SDNHub_Opendaylight_Tutorial$ mvn install -nsu
If at the end of the installation appears the message “BUILD SUCCESS”,
means that the build was sucessfully, otherwise the build will stop at the
module where it failed.
Maven compiles code based on the pom.xml file in that directory. “install” is
essential for compilation. It also accepts an optional argument “clean” if you
wish to clean the temporary build files.
Maven Configuration

13. Now that we compiled our sample project, let’s run the controller itself;
preferably in a different terminal. (<CTRL>+<SHIFT>+T)
cd $control
tutorial$ ./karaf debug
Karaf Parameters:
- List available features in ODL
feature:list # List all features available in ODL
feature:list | grep sdnhub # Filter a specific feature in ODL
- List avalable bundles in ODL
bundle:list -s | grep sdnhub # Filter a specific bundle in ODL
- Install our feature “sdnhub-tutorial-learning-switch”
feature:install sdnhub-tutorial-learning-switch
Karaf Configuration

14. Karaf Configuration

15. Mininet-based Topology

16. Hands-on

17. Learning-Switch

18. For the purposes of this tutorial, you should attempt to convert the hub learning
switch to a MAC learning switch that programs flows. Here, we give you the
steps to configure this first exercise:
1. Start the ODL controller in debug mode # Terminal 1
cd $control
./karaf debug
2. Verify if the feature “sdnhub-tutorial-learning-switch” is installed
> feature:list -i |grep sdnhub-tutorial-learning-switch
If it is not installed, install it
> feature:install sdnhub-tutorial-learning-switch
Wait 30 seconds until the Learning-Switch program is installed and active
> bundle:list -s |grep learning-switch
189 | Active | 80 | 1.0.0.SNAPSHOT org.sdnhub.odl.tutorial.learning-switch.impl
Setup Configuration

19. 3. Start mininet topology # Change to a second terminal (Terminal 2)
sudo mn --topo single,3 --mac --switch ovsk,protocols=OpenFlow13
--controller remote
* We wait until the controller is connected to the mininet topology:
is_connected: true
4. Try to do ping between “host1” and “host2”
mininet> h1 ping h2
From 10.0.0.1 icmp_seq=1 Destination Host Unreachable
Q1: Why is the Ping failing?
5. Add the next rule and verify the ping
mininet> s1 ovs-ofctl add-flow tcp:127.0.0.1:6654 -OOpenFlow13
priority=1,action=output:controller
mininet> h1 ping -c 10 h2
Setup Configuration

20. 6. Open the learning-switch program ($learn/TutorialL2Forwarding.java) and
pay attention in the lines #79 and #143
In the line #79 you may note that the default function of the code is in “hub
mode”. This means that our program (learning-switch) will act as hub, thus ping
between hosts would have a high RTT value, as you can see above. In the line
#143 you may note the code block related to the behavior of the program.
7. In the same file TutorialL2Forwarding.java, change the default function of
the program from “hub” to “switch”.
private String function = "hub"; # Line 79
to
private String function = "switch";
Setup Configuration

21. 8. Update maven from the path of the program and copy the “JAR” generated
by maven to the folder “deploy” of our controller
cd $program1 # Path of the learning-switch program
mvn install -nsu
cp $target/learning-switch-impl-1.0.0-SNAPSHOT.jar $deploy/
9. Restart “mininet” and the “controller” and do ping between h1 and h2 again:
> logout # Logout to the controller
./karaf debug # Start the controller again
mininet > exit # Exit to the mininet
$ mn -c # Clean mininet
$ sudo mn --topo single,3 --mac --switch ovsk,protocols=OpenFlow13
--controller remote
mininet > h1 ping -c 10 h2
Q2 Do you note changes in the RTT value obtained in the steps 5 and 9?
Setup Configuration

22. Flow Programming
Through REST

23. It is possible to use RESTconf to send static flows to the controller. The REST
input is based on the YANG model. For instance, post following 2 static flows
using XML tags
Exercise #2: Flow Programming Through
REST

24. 1. Start and configure the ODL controller (Terminal #1)
cd $control
./karaf clean # Clean features and bundles
Install the features that are needed to use for Restconf
> feature:install odl-restconf odl-mdsal-apidocs odl-dlux-core
2. Start the mininet topology (Terminal #2)
sudo mn -c # Clean mininet configuration
sudo mn --topo single,3 --mac --switch ovsk,protocols=OpenFlow13
--controller remote
3. Two files “forward.xml” and “reverse.xml” are stored in the ~/XML folder.
By using Postman application, create two OpenFlow rules to send static flows to
the controller. See the next steps:
Flow Programming

25. 4. Open Postman application and enter Request URL in PUT mode and
configure header parameters needed, such as is shown in Figure below:
Postman Configuration

26. 5. XML Configuration for forward ping (See the file ~/XML/forward.xml). Note
that the XML information is added in the “Body” tag
Postman Configuration

27. 6. XML Configuration for reverse ping (See the file ~/XML/reverse.xml)
Postman Configuration

28. 7. Dump flows from mininet (same terminal #2)
mininet> sh ovs-ofctl dump-flows s1 -O OpenFlow13
OFPST_FLOW reply (OF1.3) (xid=0x2):
cookie=0x0, duration=5264.052s, table=0, n_packets=20, n_bytes=1624, in_port=1 actions=output:2
cookie=0x0, duration=4983.190s, table=0, n_packets=17, n_bytes=1498, in_port=2 actions=output:1
8. Testing connectivity between hosts h1 and h2
mininet> h1 ping -c 3 h2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.432 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.118 ms
Postman Configuration
Q3: By using Postman and DELETE mode, how can you delete the flows
previously created? (see the file ~XML/delete.xml)

29. TAP Application

30. The traffic monitoring tap application is a simple proactive flow programmer that
deals with source, sinks and traffic types. We will follow the steps described earlier to
build this application. The model of the tap configuration data was described earlier
in the slide above. Based on that model, we perform following to make the tap work:
1. Extract header details from the tap object during the onDataChanged() event
handling
2. For each source-port, perform following steps to create a flow
- Create match object using appropriate builders
- Create action list with a list of actions specifying output to sink-port
- Create flow object with match and action list. Write this flow object to the Flow
table of the node
Note that the traffic type is a special enum field defined in the YANG model to allow
user to specific important traffic types worth monitoring, like ARP, ICMP, DNS,
DHCP, TCP, UDP. For converting the enum to actual values for the dl_type,
nw_proto and tp_port, one can use the following switch statement:
Network Traffic Monitoring Tap

31. Karaf Parameters:
- Install the features that are needed to use for Restconf
feature:install odl-restconf-all
- List the installed programs in Karaf
feature:list -i |grep odl-restconf-all
feature:list -i |grep tapapp
- List avalable bundles in ODL
bundle:list -s | grep sdnhub # Filter a specific bundle in ODL
Karaf Configuration

32. 1. Start the controller again
$ ./karaf debug
2. Start mininet
$ sudo mn --topo single,3 --mac --switch ovsk,protocols=OpenFlow13
--controller remote
Once you add the model, you can build the project and run Karaf to
immediately verify if your model is sufficient for your application. For
instance, when we run karaf, even without any implementation or event
handlers defined, you will be able to store data in the data store as follows:
Network Traffic Monitoring Tap

33. 3. Add flows using RESTFul. Open a terminal in the VM and copy the box
below
$ curl -u admin:admin -H "Content-Type:application/json" -X PUT -d '{"tap-spec":
{"tap":[
{"id":"1",
"node":"openflow:1",
"traffic-match":"HTTP",
"src-node-connector":["openflow:1:1"],
"sink-node-connector":["openflow:1:2"]
}
]
}
}' http://localhost:8181/restconf/config/tap:tap-spec
Network Traffic Monitoring Tap
You can open a browser and inspect the data store at
http://localhost:8181/restconf/config/tap:tap-spec

34. 4. Open Postman and import the XML file stored in the path
~/XML/tap.xml
Network Traffic Monitoring Tap
In each Tag added you should configure the Authorization Type as “Basic
Auth” and then click in “Update Request”

35. Q4: By using Postman, could you add two new rules to match traffics
ARP and ICMP?
Q5: What happens if the controller goes down? Are the flows removed?
5. Using Postman, install the two addition rules (Tap1 addition and Tap2
addition) on OVS, clicking in the bottom “Send”.
6. Inspect the data stored:
http://127.0.0.1:8181/restconf/config/tap:tap-spec
7. Now, send the two deletion rules clicking in the bottom “Send”. Repeat
step 6.
8. Now, send the two Create dummy rules. Go to mininet and type:
mininet> sh ovs-ofctl dump-flows s1 -O OpenFlow13
mininet> h1 ping h2
9. Finally, delete those flows with the Delete dummy rules
Network Traffic Monitoring Tap

36. Thanks!