Due to a ransomware attack, the wiki was reverted to a July 2022 version. . We apologize for the lack of a more recent valid backup.
This applies to the obsolete Junco (1.9) release
Please see Cluster Configuration in Owl (1.14) for an updated guide. For an up-to-date tutorial for ONOS see the NG-SDN tutorial
Welcome to the Distributed ONOS Tutorial.
In this tutorial, you will learn to write a distributed ONOS application. The application you will be writing is called BYON (Build Your Own Network). This tutorial will teach you how to implement an ONOS service, an ONOS store, and how to use parts of the CLI and Northbound API. 
(Here are some some slides that that can be used to accompany the tutorial: Slides)
| Table of Contents |
|---|
Introduction
...
Email us if you’re stuck, think you’ve found a bug, or just want to send some feedback. Please have a look at the guidelines to learn how to efficiently submit a bug report.
Setup Set up your environment
Install required software
You will need to acquire two files: a VirtualBox installer and the the latest Tutorial VM from the Downloads page.
After you have downloaded VirtualBox, install it, then go to the next section to verify that the VM is working on your system.
...
Double-click on the downloaded tutorial zipfile. This will give you an OVF file. Open the OVF file, this will open virtual box with an import dialog. Make sure you provision your VM with 4GB of RAM and if possible 4 CPUs if possible, if not 2 CPUs should be ok.
...
Click on import. When the import is finished start the VM and login using:
USERNAME: distributed
PASSWORD: distributed
you will be automatically logged in to a running desktop session as show below:
Important Command Prompt Notes
...
indicates that you are in mininet.
Setting up a 3-node ONOS cluster
There is already a 3-node LXC-based container cluster set up in the tutorial VM. We're now going to install and start ONOS on all 3 nodes to give us a cluster to work with.
First, let's start by making sure our environment is correctly setup.
| Code Block |
|---|
distributed@mininet-vm:~$ cell 3node
ONOS_CELL=3node
OCI=10.0.3.11
OC1=10.0.3.11
OC2=10.0.3.12
OC3=10.0.3.13
ONOS_FEATURES=webconsole,onos-api,onos-core,onos-cli,onos-rest,onos-gui,onos-openflow
ONOS_NIC=10.0.3.* |
Now we just need to package ONOS by running:
| Code Block |
|---|
distributed@mininet-vm:~$ onos-package
-rw-rw-r-- 1 distributed distributed 41940395 Dec 11 13:20 /tmp/onos-1.0.0.distributed.tar.gz |
This prepares an ONOS installations which can now be shipped to the remote instances:
| Code Block |
|---|
distributed@mininet-vm:~$ onos-install -f $OC1
onos start/running, process 308
distributed@mininet-vm:~$ onos-install -f $OC2
onos start/running, process 302
distributed@mininet-vm:~$ onos-install -f $OC3
onos start/running, process 300
distributed@mininet-vm:~$ |
This has now installed ONOS on your docker instances.
Verifying that ONOS is deployed
Now ONOS is installed let's quickly run some tests to make sure everything is ok. Let's start by connecting to the ONOS cli:
| Code Block |
|---|
distributed@mininet-vm:~$ onos -w $OC1
Connection to 172.17.0.2 closed.
Logging in as karaf
Welcome to Open Network Operating System (ONOS)!
____ _ ______ ____
/ __ \/ |/ / __ \/ __/
/ /_/ / / /_/ /\ \
\____/_/|_/\____/___/
Hit '<tab>' for a list of available commands
and '[cmd] --help' for help on a specific command.
Hit '<ctrl-d>' or type 'system:shutdown' or 'logout' to shutdown ONOS.
onos> |
You should drop into the cli. Now in another cli window let's start mininet.
| Code Block |
|---|
distributed@mininet-vm:~$ cd onos-byon && ./startmn.sh
mininet> |
Now let's see if we have switches that are connected to ONOS:
Connecting to your tutorial cell
Obtain the IP address of the tutorial cell on from your instructor and setup a PPTP VPN connection using onos as a user and onos as password. The method to this will vary depending on the operating system of the developer machine. The example below shows the setup on OS/X:
Then connect to the ONOS Cluster VPN.
Verifying that ONOS is deployed
Now let's quickly run some tests to make sure everything is ok. Let's start by openning a new terminal window and connecting to the ONOS cli by typing onos
| Code Block |
|---|
onos@onos-tutorial:~$ onos
Logging in as karaf
Welcome to Open Network Operating System (ONOS)!
____ _ ______ ____
/ __ \/ |/ / __ \/ __/
/ /_/ / / /_/ /\ \
\____/_/|_/\____/___/
Documentation: wiki.onosproject.org
Tutorials: tutorials.onosproject.org
Mailing lists: lists.onosproject.org
Come help out! Find out how at: contribute.onosproject.org
Hit '<tab>' for a list of available commands
and '[cmd] --help' for help on a specific command.
Hit '<ctrl-d>' or type 'system:shutdown' or 'logout' to shutdown ONOS.
onos> |
You should drop into the cli. Now open another terminal window and start mininet as shown:
| Code Block |
|---|
onos@onos-tutorial:~$ cd onos-byon && ./startmn.sh
...
...
mininet> |
Now let's see if we have switches that are connected to ONOS:
| Code Block |
|---|
onos> devices
id=of:0000000100000001, available=true, role=MASTER, type=SWITCH, mfr=Nicira, Inc., hw=Open vSwitch, sw=2.1.3, serial=None, protocol=OF_10
id=of:0000000100000002, available=true, role=STANDBY, type=SWITCH, mfr=Nicira, Inc., hw=Open vSwitch, sw=2.1.3, serial=None, protocol=OF_10
id=of:0000000200000001, available=true, role=MASTER, type=SWITCH, mfr=Nicira, Inc., hw=Open vSwitch, sw=2.1.3, serial=None, protocol=OF_10
id=of:0000000200000002, available=true, role=STANDBY, type=SWITCH, mfr=Nicira, Inc., hw=Open vSwitch, sw=2.1.3, serial=None, protocol=OF_10
id=of:0000000300000001, available=true, role=MASTER, type=SWITCH, mfr=Nicira, Inc., hw=Open vSwitch, sw=2.1.3, serial=None, protocol=OF_10
id=of:0000000300000002, available=true, role=STANDBY |
| Code Block |
onos> devices id=of:0000000100000001, available=true, role=MASTER, type=SWITCH, mfr=Nicira, Inc., hw=Open vSwitch, sw=2.1.3, serial=None, protocol=OF_10 id=of:00000001000000020000010100000000, available=true, role=STANDBY, type=SWITCH, mfr=Nicira, Inc., hw=Open vSwitch, sw=2.1.3, serial=None, protocol=OF_10 id=of:00000002000000010000010200000000, available=true, role=MASTERSTANDBY, type=SWITCH, mfr=Nicira, Inc., hw=Open vSwitch, sw=2.1.3, serial=None, protocol=OF_10 id=of:00000002000000020000020100000000, available=true, role=STANDBYMASTER, type=SWITCH, mfr=Nicira, Inc., hw=Open vSwitch, sw=2.1.3, serial=None, protocol=OF_10 id=of:00000003000000010000020200000000, available=true, role=MASTERSTANDBY, type=SWITCH, mfr=Nicira, Inc., hw=Open vSwitch, sw=2.1.3, serial=None, protocol=OF_10 id=of:00000003000000020000030100000000, available=true, role=STANDBY, type=SWITCH, mfr=Nicira, Inc., hw=Open vSwitch, sw=2.1.3, serial=None, protocol=OF_10 id=of:00000101000000000000030200000000, available=true, role=STANDBYMASTER, type=SWITCH, mfr=Nicira, Inc., hw=Open vSwitch, sw=2.1.3, serial=None, protocol=OF_10 id=of:00000102000000001111000000000000, available=true, role=STANDBY, type=SWITCH, mfr=Nicira, Inc., hw=Open vSwitch, sw=2.1.3, serial=None, protocol=OF_10 id=of:00000201000000002222000000000000, available=true, role=MASTERSTANDBY, type=SWITCH, mfr=Nicira, Inc., hw=Open vSwitch, sw=2.1.3, serial=None, protocol=OF_10 id=of:0000020200000000, available=true, role=STANDBY, type=SWITCH, mfr=Nicira, Inc., hw=Open vSwitch, sw=2.1.3, serial=None, protocol=OF_10 id=of:0000030100000000, available=true, role=STANDBY, type=SWITCH, mfr=Nicira, Inc., hw=Open vSwitch, sw=2.1.3, serial=None, protocol=OF_10 id=of:0000030200000000, available=true, role=MASTER, type=SWITCH, mfr=Nicira, Inc., hw=Open vSwitch, sw=2.1.3, serial=None, protocol=OF_10 id=of:1111000000000000, available=true, role=STANDBY, type=SWITCH, mfr=Nicira, Inc., hw=Open vSwitch, sw=2.1.3, serial=None, protocol=OF_10 id=of:2222000000000000, available=true, role=STANDBY, type=SWITCH, mfr=Nicira, Inc., hw=Open vSwitch, sw=2.1.3, serial=None, protocol=OF_10 |
Let's install reactive forwarding and see if we can forward traffic:
| Code Block |
|---|
onos> app activate org.onosproject.fwd |
In the mininet console:
| Code Block |
|---|
mininet> pingall
*** Ping: testing ping reachability
h111 -> h112 h121 h122 h211 h212 h221 h222 h311 h312 h321 h322
h112 -> h111 h121 h122 h211 h212 h221 h222 h311 h312 h321 h322
h121 -> h111 h112 h122 h211 h212 h221 h222 h311 h312 h321 h322
h122 -> h111 h112 h121 h211 h212 h221 h222 h311 h312 h321 h322
h211 -> h111 h112 h121 h122 h212 h221 h222 h311 h312 h321 h322
h212 -> h111 h112 h121 h122 h211 h221 h222 h311 h312 h321 h322
h221 -> h111 h112 h121 h122 h211 h212 h222 h311 h312 h321 h322
h222 -> h111 h112 h121 h122 h211 h212 h221 h311 h312 h321 h322
h311 -> h111 h112 h121 h122 h211 h212 h221 h222 h312 h321 h322
h312 -> h111 h112 h121 h122 h211 h212 h221 h222 h311 h321 h322
h321 -> h111 h112 h121 h122 h211 h212 h221 h222 h311 h312 h322
h322 -> h111 h112 h121 h122 h211 h212 h221 h222 h311 h312 h321
*** Results: 0% dropped (132/132 received) |
Finally let's see if we have switches connected to each instance of ONOS:
| Code Block |
|---|
onos> masters
172.17.0.2: 5 devices
of:0000000100000001
of:0000000200000001
of:0000000300000001
of:0000020100000000
of:0000030200000000
172.17.0.3: 2 devices
of:0000000100000002
of:0000000300000002
172.17.0.4: 7 devices
of:0000000200000002
of:0000010100000000
of:0000010200000000
of:0000020200000000
of:0000030100000000
of:1111000000000000
of:2222000000000000 |
The number of switches per ONOS instance may be different for you because mastership is simply obtained by the first controller which handshakes with the switch. If you would like to rebalance the switch-onos ratio simply run:
| Code Block |
|---|
onos> balance-masters |
And now the output of the masters command should give you something similar to this:
| Code Block |
|---|
onos> masters
172.17.0.2: 5 devices
of:0000000100000001
of:0000000200000001
of:0000000300000001
of:0000020100000000
of:0000030200000000
172.17.0.3: 4 devices
of:0000000100000002
of:0000000300000002
of:0000020200000000
of:1111000000000000
172.17.0.4: 5 devices
of:0000000200000002
of:0000010100000000
of:0000010200000000
of:0000030100000000
of:2222000000000000 |
Now we should uninstall reactive forwarding so it doesn't get in the way for the next part of the tutorial.
| Code Block |
|---|
onos> app deactivate org.onosproject.fwd |
At this point, you multi-instance ONOS deployment is functional. Let's move on to writing some code.
Writing 'Build Your Own Network'
We are now going to start building BYON. BYON is a service which allows you to spawn virtual networks in which each host is connected to every other host of that virtual network. Basically, each virtual network contains a full mesh of the hosts that make it up.
Lab 1: Importing and building an application
FIXME We have downloaded some starter code in the ~/onos-byon directory. It contains a root pom.xml file for the project, as well as a initial implementation of the CLI bundle. We can start by importing the entire project into IntelliJ.
Before we fetch stuff from git, run the following to make git happy.
| Code Block |
|---|
distributed@mininet-vm:~/onos-byon/ $ git config --global user.email "you@example.com"
distributed@mininet-vm:~/onos-byon/ $ git config --global user.name "Your Name" |
Before we start, make sure you have the latest version of the template code by running:
...
You can also see which switches are connected to each instance of the ONOS cluster:
| Code Block |
|---|
onos> masters
172.17.0.2: 5 devices
of:0000000100000001
of:0000000200000001
of:0000000300000001
of:0000020100000000
of:0000030200000000
172.17.0.3: 2 devices
of:0000000100000002
of:0000000300000002
172.17.0.4: 7 devices
of:0000000200000002
of:0000010100000000
of:0000010200000000
of:0000020200000000
of:0000030100000000
of:1111000000000000
of:2222000000000000 |
The number of switches per ONOS instance may be different for you because mastership is simply obtained by the first controller which handshakes with the switch. If you would like to rebalance the switch-onos ratio simply run:
| Code Block |
|---|
onos> balance-masters |
And now the output of the masters command should give you something similar to this:
| Code Block |
|---|
onos> masters
172.17.0.2: 5 devices
of:0000000100000001
of:0000000200000001
of:0000000300000001
of:0000020100000000
of:0000030200000000
172.17.0.3: 4 devices
of:0000000100000002
of:0000000300000002
of:0000020200000000
of:1111000000000000
172.17.0.4: 5 devices
of:0000000200000002
of:0000010100000000
of:0000010200000000
of:0000030100000000
of:2222000000000000 |
At this point, you multi-instance ONOS deployment is functional. Let's move on to writing some code.
Writing 'Build Your Own Network'
We are now going to start building BYON. BYON is a service which allows you to spawn virtual networks in which each host is connected to every other host of that virtual network. Basically, each virtual network contains a full mesh of the hosts that make it up.
Lab 1: Importing and building an application
We have downloaded some starter code in the ~/onos-byon directory. It contains a root pom.xml file for the project, as well as a initial implementation of the CLI bundle. We can start by importing the entire project into IntelliJ.
...
First start IntelliJ by double clicking on the IntelliJ icon on your desktop. When you get prompted with the following window.
...
Next, we can return to a tutorial to build the project.
| Code Block |
|---|
distributed@mininetonos@onos-vmtutorial:~/onos-byon$ mci [INFO] Scanning for projects... ... [INFO] byon .............................................. SUCCESS [1.104s] [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 6.719s [INFO] Finished at: Fri Dec 12 14:28:16 PST 2014 [INFO] Final Memory: 30M/303M [INFO] ------------------------------------------------------------------------ distributed@mininetonos@onos-vmtutorial:~/onos-byon$ |
mci is an alias for mvn clean install. Now, that your project has successfully built your project let's push it up to the ONOS cluster..
| Code Block |
|---|
distributed@mininetonos@onos-vmtutorial:~/onos-byon$ onos-app $OC1 install target/byon-1.0-SNAPSHOT.oar {"name":"org.onos.byon","id":3739,"version":"1.0.-SNAPSHOT", "description":"Build Your Own Network App", "origin":"Apps-R-Us LLC, Inc. GmbH","permissions":"[]", "featuresRepo":"mvn:org.onos.byon/byon/1.0-SNAPSHOT/xml/features","features":"[byon]", "state":"INSTALLED"} |
|
The onos-app command will take the oar file that is generated during the build and push it into the specified ONOS instance. The command can also activate the application if you replace install with install! as well as separately activate, deactivate, and uninstall the application. Every time you update your code you simply need to run onos-app $OC1 reinstall! target/byon-1.0-SNAPSHOT.org and oar and the new application will be loaded and started in the remote ONOS instances.
Let's check that everything works by heading into ONOS and running a couple commands:
| Code Block |
|---|
distributed@mininetonos@onos-vmtutorial:~/onos-byon$ onos -w Logging in as karaf Welcome to Open Network Operating System (ONOS)! ____ _ ______ ____ / __ \/ |/ / __ \/ __/ / /_/ / / /_/ /\ \ \____/_/|_/\____/___/ Hit '<tab>' for a list of available commands and '[cmd] --help' for help on a specific command. Hit '<ctrl-d>' or type 'system:shutdown' or 'logout' to shutdown ONOS. onos> apps -s ... 37 org.onos.byon 1.0.SNAPSHOT Build Your Own Network App |
The application has been successfully installed, but it has not yet been activated. Next, we will activate it:
| Code Block |
|---|
onos> app activate org.onos.byon onos> apps -s ... * 37 org.onos.byon 1.0.SNAPSHOT Build Your Own Network App |
The star next to the application indicates that it has been activated. We can try running the list-networks command to display the one fake network that is hard coded in the starter code.
...
In order to be able to use many of ONOS' services, the caller must supply an Application ID. An application ID allow allows ONOS to identify who is consuming which resources as well as track applications. To achieve this, we ask the CoreService for an application ID in the activate method. You should use the appId when constructing the intents for this part.
We will also need to get a reference to the IntentService. The reference will automatically be injected when the application is loaded after you uncomment the two lines near the top of the NetworkManager.
When addHost() is called, we will need to create an intent between the host and all other hosts that already exist in the network.
| Info |
|---|
You should only to add the intents if this is the first time that the host is added, so be sure to check the store's return value. true indicates that the add was successful i.e. this is the first time. |
For this exercise, we will be using HostToHostIntents and you can build one like this:
as track applications. To achieve this, we ask the CoreService for an application ID in the activate method. You should use the appId when constructing the intents for this part.
We will also need to get a reference to the IntentService. The reference will automatically be injected when the application is loaded after you uncomment the two lines near the top of the NetworkManager.
When addHost() is called, we will need to create an intent between the host and all other hosts that already exist in the network.
| Info |
|---|
You should only to add the intents if this is the first time that the host is added, so be sure to check the store's return value. true indicates that the add was successful i.e. this is the first time. |
For this exercise, we will be using HostToHostIntents and you can build one like this:
| Code Block |
|---|
Intent intent = HostToHostIntent.builder( |
| Code Block |
Intent intent = HostToHostIntent.builder() .appId(appId) .key(generateKey(network, src, dst)) .one(src) .twoappId(dstappId) .build(); intentService.submit(intent); |
Make sure to submit a HostToHostIntent between the newly added host, and all other hosts that are already in the virtual network.
It's time to make sure that everything works; build with mci and run onos-app $OC1 reinstall! target/byon-1.0-SNAPSHOT.oar
| Code Block |
|---|
onos> create-network test2
Created network test2
onos> add-host test2 00:00:00:00:00:01/-1
Added host 00:00:00:00:00:01/-1 to test2
onos> add-host test2 00:00:00:00:00:02/-1
Added host 00:00:00:00:00:02/-1 to test2
onos> list-networks
test2
00:00:00:00:00:01/-1
00:00:00:00:00:02/-1
onos> intents
id=0x0, state=INSTALLED, type=HostToHostIntent, appId=org.onos.byon
constraints=[LinkTypeConstraint{inclusive=false, types=[OPTICAL]}] |
Now check in mininet that you can actually communicated between the two hosts that you added to your virtual network.
| Code Block |
|---|
mininet> h1 ping 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=21.4 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.716 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=0.073 ms |
Lab 4: Implementing removal of hosts from a virtual network
When a host is removed from a network or a network is removed entirely, we need to remove the intent related to that host or network from the IntentService. There are Lab 4 TODOs in the removeHost() and removeNetwork() methods. The starter code also contains a removeIntents() method that you will need to complete. In this method, you will need to get the intents from the IntentService, filter the relevant ones to remove, and then instruct the IntentService to withdrawn them. Note: For your convenience, we have provided a helper method, matches(), that can be used to filter the relevant intents.
Next, we will need to construct some CLI commands so that you can test your work, specifically, one command to remove hosts and another to remove networks.
Start by creating two files in the byon-cli package "RemoveHostCommand.java" and "RemoveNetworkCommand.java". These CLI commands are simple and very similar to the add CLI commands, so do this now as an exercise. When you have written these commands, you will need to add the following XML to the 'shell-config.xml' under resources.
| Code Block |
|---|
<command>
<action class="org.onos.byon.cli.RemoveHostCommand"/>
<completers>
<ref component-id="networkCompleter"/>
<ref component-id="hostIdCompleter"/>
<null/>
</completers>
</command>
<command>
<action class="org.onos.byon.cli.RemoveNetwork"/>
<completers>
<ref component-id="networkCompleter"/>
<null/>
</completers>
</command> |
Once again if you recompile your code and use onos-app update your application on the ONOS instances. You should now be able to add and remove networks as well as hosts. Try it out!
Now, you should have a fairly complete implementation of the BYON app, but it will only work from one instance. (Try running list-networks on another instance! It will not show you any networks.)
Lab 5: Upgrading the store to make it distributed
The starter implementation of the DistributedNetworkStore uses a ConcurrentMap to store information about the virtual networks. This map only stores the data locally, and it knows nothing about other instances in the cluster. We will be replacing the map with a ConsistentMap which is cluster-aware, and one of the distributed primitives provided by ONOS.
Before we can instantiate a ConsistentMap, we need to get a reference to the StorageService; you can do this by uncommented in the StorageService reference near the top of the DistributedNetworkStore class.
Once you change the ConcurrentMap to a ConsistentMap, we will need to update the way the map is created in the activate() method. Here is how we can ask the storage service for a ConcurrentMap:
| Code Block |
|---|
networks = storageService.<String, Set<HostId>>consistentMapBuilder()
.withSerializer(Serializer.using(KryoNamespaces.API))
.withName("byon-networks")
.build(); |
You will notice a few compilation errors after making this change. This is because the ConcurrentMap returns a Versioned<Value>, rather than just a Value. You should fix the compilation errors marked by Lab 5 TODOs.
Next, let's recompile your application and push it to the ONOS cluster. You should now be able to create, update, and delete networks from any node, and your distributed store will the application running on all instances in sync. Open a few terminals and test this on the different instances.
Lab 6: Network Events
Components in ONOS can use events to asynchronously notify other components when their state has changed. We will demonstrate how this can be done by creating a new event type, NetworkEvent, to notify listeners when a virtual network has been updated. These events will be fired by the distributed store and forwarded by the manager to listeners in the peer ONOS instance.
Let's start by adding a NetworkEvent class:
| Code Block | ||
|---|---|---|
| ||
public class NetworkEvent extends AbstractEvent<NetworkEvent.Type, String> {
enum Type {
NETWORK_ADDED,
NETWORK_REMOVED,
NETWORK_UPDATED
}
public NetworkEvent(Type type, String subject) {
super(type, subject);
}
} |
We are also going to need a couple interfaces that will be needed by the listeners and the and the delegates. The listeners are components which have registered to obtain events from this service, these are usually local. A delegate is a manager which is receiving events from a neighbouring store for the purpose of either taking action on the store event or notifying listeners. So we are going to add NetworkListener.
| Code Block | ||
|---|---|---|
| ||
public interface NetworkListener extends EventListener<NetworkEvent> {} |
and a NetworkStoreDelegate interfaces
| Code Block | ||
|---|---|---|
| ||
public interface NetworkStoreDelegate extends StoreDelegate<NetworkEvent> {} |
Of course now if we want the store to be delegate-capable we need to make it extend the Store as shown below.
| Code Block | ||
|---|---|---|
| ||
public interface NetworkStore extends Store<NetworkEvent, NetworkStoreDelegate> {
|
And since we changed the interface of the Store we will have to add something to the implementation, namely DistributedNetworkStore. This abstract class is used to define the methods for posting event to its delegates.
| Code Block |
|---|
public class DistributedNetworkStore extends AbstractStore<NetworkEvent, NetworkStoreDelegate> |
We need to add the following methods to the NetworkService in order to allow components to add and remove listeners.
.key(generateKey(network, src, dst))
.one(src)
.two(dst)
.build();
intentService.submit(intent); |
Make sure to submit a HostToHostIntent between the newly added host, and all other hosts that are already in the virtual network.
It's time to make sure that everything works; build with mci and run onos-app $OC1 reinstall! target/byon-1.0-SNAPSHOT.oar
| Code Block |
|---|
onos> create-network test2
Created network test2
onos> add-host test2 00:00:00:00:00:01/-1
Added host 00:00:00:00:00:01/-1 to test2
onos> add-host test2 00:00:00:00:00:02/-1
Added host 00:00:00:00:00:02/-1 to test2
onos> list-networks
test2
00:00:00:00:00:01/-1
00:00:00:00:00:02/-1
onos> intents
id=0x0, state=INSTALLED, type=HostToHostIntent, appId=org.onos.byon
constraints=[LinkTypeConstraint{inclusive=false, types=[OPTICAL]}] |
Now check in mininet that you can actually communicated between the two hosts that you added to your virtual network.
| Code Block |
|---|
mininet> h1 ping 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=21.4 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.716 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=0.073 ms |
Lab 4: Implementing removal of hosts from a virtual network
When a host is removed from a network or a network is removed entirely, we need to remove the intent related to that host or network from the IntentService. There are Lab 4 TODOs in the removeHost() and removeNetwork() methods. The starter code also contains a removeIntents() method that you will need to complete. In this method, you will need to get the intents from the IntentService, filter the relevant ones to remove, and then instruct the IntentService to withdrawn them. Note: For your convenience, we have provided a helper method, matches(), that can be used to filter the relevant intents.
Next, we will need to construct some CLI commands so that you can test your work, specifically, one command to remove hosts and another to remove networks.
Start by creating two files in the byon-cli package 'RemoveHostCommand.java'. This CLI command is simple and very similar to the add host CLI command, so do this now as an exercise. When you have written this command, you will need to add the following XML to the 'shell-config.xml' under resources.
| Code Block |
|---|
<command>
<action class="org.onos.byon.cli.RemoveHostCommand"/>
<completers>
<ref component-id="networkCompleter"/>
<ref component-id="hostIdCompleter"/>
<null/>
</completers>
</command> |
Once again if you recompile your code and use onos-app update your application on the ONOS instances. You should now be able to add and remove networks as well as hosts. Try it out!
Now, you should have a fairly complete implementation of the BYON app, but it will only work from one instance. (Try running list-networks on another instance! It will not show you any networks.)
Lab 5: Upgrading the store to make it distributed
The starter implementation of the DistributedNetworkStore uses a ConcurrentMap to store information about the virtual networks. This map only stores the data locally, and it knows nothing about other instances in the cluster. We will be replacing the map with a ConsistentMap which is cluster-aware, and one of the distributed primitives provided by ONOS.
Before we can instantiate a ConsistentMap, we need to get a reference to the StorageService; you can do this by uncommented in the StorageService reference near the top of the DistributedNetworkStore class.
First, start by defining a couple fields:
| Code Block |
|---|
/*
* TODO Lab 5: Replace the ConcurrentMap with ConsistentMap
*/
private Map<String, Set<HostId>> networks;
private ConsistentMap<String, Set<HostId>> nets; |
Once you change the ConcurrentMap to a ConsistentMap, we will need to update the way the map is created in the activate() method. Here is how we can ask the storage service for a ConcurrentMap:
| Code Block |
|---|
/*
* TODO Lab 5: Replace the ConcurrentHashMap with ConsistentMap
*
* You should use storageService.consistentMapBuilder(), and the
* serializer: Serializer.using(KryoNamespaces.API)
*/
nets = storageService.<String, Set<HostId>>consistentMapBuilder()
.withSerializer(Serializer.using(KryoNamespaces.API))
.withName("byon-networks")
.build();
networks = nets.asJavaMap(); |
Now that you the networks field is a normal java map that is backed by a distributed map you do not have to change any code at all. And actually you can ignore all the lab 5 todos. 
Next, let's recompile your application and push it to the ONOS cluster. You should now be able to create, update, and delete networks from any node, and your distributed store will the application running on all instances in sync. Open a few terminals and test this on the different instances.
Lab 6: Network Events
Components in ONOS can use events to asynchronously notify other components when their state has changed. We will demonstrate how this can be done by creating a new event type, NetworkEvent, to notify listeners when a virtual network has been updated. These events will be fired by the distributed store and forwarded by the manager to listeners in the peer ONOS instance.
Let's start by inspecting the NetworkEvent class:
| Code Block | ||
|---|---|---|
| ||
public class NetworkEvent extends AbstractEvent<NetworkEvent.Type, String> {
enum Type {
NETWORK_ADDED,
NETWORK_REMOVED,
NETWORK_UPDATED
}
public NetworkEvent(Type type, String subject) {
super(type, subject);
}
} |
Let's also inspect the provided abstraction for listeners capable of receiving network events, which is the NetworkListener class:
| Code Block | ||
|---|---|---|
| ||
public interface NetworkListener extends EventListener<NetworkEvent> {} |
With ONOS being a clustered system, it needs to allow managers to learn about events that may have occurred on other cluster nodes. For this reason, in every ONOS subsystem the events are generated within the distributed stores and then are passed to the respective manager components via StoreDelegate interface. Upon receiving the event via the delegate interface, the manager can then take local action and then disseminate the event to its event listeners.
Let's inspect the provided NetworkStoreDelegate interface:
| Code Block | ||
|---|---|---|
| ||
public interface NetworkStoreDelegate extends StoreDelegate<NetworkEvent> {} |
To enable the store/manager delegate relationship, we need to make the existing store interface extend the abstract Store interface as shown below. It basically states that the NetworkStore is capable of having a NetworkStoreDelegate to which it will send NetworkEvent notifications:
| Code Block | ||
|---|---|---|
| ||
public interface NetworkStore extends Store<NetworkEvent, NetworkStoreDelegate> {
|
And since we changed the interface of the Store we will have to make sure that the implementation, namely DistributedNetworkStore, properly adheres the revised contract. The AbstractStore base class provides methods for setting delegate and for posting events to that delegate.
| Code Block | ||
|---|---|---|
public class DistributedNetworkStore extends AbstractStore<NetworkEvent, NetworkStoreDelegate> | ||
| Code Block | ||
| ||
/**
* Register a listener for network events.
*
* @param listener listener
*/
void addListener(NetworkListener listener);
/**
* Unregister a listener for network events.
*
* @param listener listener
*/
void removeListener(NetworkListener listener); |
The ConsistentMap will already generate notifications when updates are made locally and remotely, so we can mostly leverage that feature to regenerate our events.
To do this, we will need to create a MapEventListener<Stringa MapEventListener<String, Set<HostId>> class in the DistributedNetworkStore.
| Code Block |
|---|
private class InternalListener implements MapEventListener<String, Set<HostId>> {
@Override
public void event(MapEvent<String, Set<HostId>> mapEvent) {
final NetworkEvent.Type type;
switch (mapEvent.type()) {
case INSERT:
type = NETWORK_ADDED;
break;
case UPDATE:
type = NETWORK_UPDATED;
break;
case REMOVE:
default:
type = NETWORK_REMOVED;
break;
}
notifyDelegate(new NetworkEvent(type, mapEvent.key()));
}
} |
...
Alright, so now that the stores emit events the managers should be made to receive them. For this we are going to have to add a reference on the EventDeliveryService an AbstractListenerRegistry an ListenerRegistry to keep track of listeners and NetworkStoreDelegate as shown in the code snippet below.
| Code Block | ||
|---|---|---|
| ||
@Reference(cardinality = ReferenceCardinality.MANDATORY_UNARY)
protected EventDeliveryService eventDispatcher;
private final AbstractListenerRegistry<NetworkEventListenerRegistry<NetworkEvent, NetworkListener>
listenerRegistry = new AbstractListenerRegistry<>ListenerRegistry<>();
private final NetworkStoreDelegate delegate = new InternalStoreDelegate();
|
...
Congratulations! You have learned how to develop an ONOS distributed application on ONOS.
Source Code Download
If you wish to have access to the full source code with the complete solution, and without downloading the entire tutorial VM, you can download the source code directly from GitHub as follows:
| Code Block |
|---|
git clone https://github.com/bocon13/onos-byon.git && cd onos-byon && git checkout solution |