POLITECNICO DI MILANO using ONOS Controller.pdfSDN using ONOS Controller Slave Mitev Politecnico di Milano, 2016 2 | P a g e can do with ONOS, and software written to run on ONOS,

POLITECNICO DI MILANO

Scuola di Ingegneria Industriale e dell’Informazione - MI

Degree Program: TELECOMMUNICATION ENGINEERING - INGEGNERIA DELLE TELECOMUNICAZIONI

Program Type: Laurea Magistrale

SDN using ONOS Controller

Academic year 2015 - 2016

Mentor: Graduation Thesis of: Maier Guido Alberto Slave Mitev Marticola: 823436

SDN using ONOS Controller Slave Mitev Politecnico di Milano, 2016

i

Table of Contents 1. Abstract .............................................................................................................................................. 1

2. Introduction and ONOS Overview ..................................................................................................... 1

3. Segment Routing ................................................................................................................................ 3

4. MPLS Protocol .................................................................................................................................... 5

5. Prerequisites and Setup for ONOS ..................................................................................................... 6

6.1. Installing the VM ......................................................................................................................... 6

6.2. Creating a custom Environment (screen and putty) ................................................................. 12

6. Installing ONOS from scratch ........................................................................................................... 15

6.1. Installing the required Software ................................................................................................ 15

6.2. Setup the Build Environment ..................................................................................................... 17

6.3. Create a Custom Cell Definition ................................................................................................. 18

6.4. Package and Deploy ONOS......................................................................................................... 20

7. CORD: Leaf-Spine with Segment Routing ........................................................................................ 22

7.1. Overview .................................................................................................................................... 22

7.2. Software switch Installation guide (default) .............................................................................. 23

7.3. Custom Topology and Network Configuration .......................................................................... 27

8. Segment Routing Tests ..................................................................................................................... 33

8.1. Explanation for Test Creation and Application .......................................................................... 33

8.2. SR Switch Failure ........................................................................................................................ 34

8.3. SR Sanity ..................................................................................................................................... 35

8.4. SR Link Failure ............................................................................................................................ 36

8.5. SR ONOS Failure ......................................................................................................................... 37

8.6. Future Test: SR Cluster Restart .................................................................................................. 38

8.7. Test Execution Summary ............................................................................................................ 39

9. Packet Optical Use Case ................................................................................................................... 40

9.1. Introduction ............................................................................................................................... 40

9.2. Overview .................................................................................................................................... 40

9.3. Motivation .................................................................................................................................. 40

9.4. Optical Information Model ........................................................................................................ 41

9.5. Environment Setup .................................................................................................................... 43

9.6. Packet Optical Network Setup ................................................................................................... 43

9.7. LINQ Console ............................................................................................................................. 47

9.8. Monitoring CPQD Nodes ............................................................................................................ 47

9.9. Static BGP Routes ....................................................................................................................... 47


ii

9.10. Optical Utilities file Link ........................................................................................................... 48

9.11. Optical Intents .......................................................................................................................... 48

9.12. opticaltest.py Topology ............................................................................................................ 50

9.13. customPOtopo.py Topology .................................................................................................... 51

9.14. Optical Path Provisioning ......................................................................................................... 53

10. Packet Optical Tests ....................................................................................................................... 55

10.1. Packet Optical Switch Failure ................................................................................................... 55

10.2. Packet Optical Sanity ................................................................................................................ 56

10.3. Packet Optical ONOS Failure .................................................................................................... 56

10.4. Packet Optical Dynamic ........................................................................................................... 56

10.5. Packet Optical Tests Summary ................................................................................................. 57

11. Future Work ................................................................................................................................... 58

11.1. Future Work on Segment Routing .......................................................................................... 58

11.2. Future work on Packet Optical ................................................................................................. 58

11.3. Future work using TestON ....................................................................................................... 58

12. Conclusion ...................................................................................................................................... 58

14. References ...................................................................................................................................... 60


1 | P a g e

1. Abstract

In today’s world, the need to manage and customize the networks outgrows the physical capabilities of today’s technology. There are an everlasting number of users. From here, we can see that the size of the content that needs to be delivered from one “place” to another is growing. Also, the demand that the user has is also growing. Since the invention of the smart phone, we have seen the rise of the Internet of Things era. Hence, the user now wants to be connected with everything, constantly. Examples of these are: “I want to be able to control and monitor the temperature of my apartment from my smart-watch”; or “I want to check the contents of my fridge from my smart-phone”. These kinds of services additionally add traffic to the already heavily loaded networks. This is a problem. Why?

This is a problem because the physical capabilities of the enabling technology have become the bottleneck. The switches, routers, hubs and etc. have limitations that need time to be outgrown. This is why, in the last years, there is an intense research and work done regarding Software Defined Networks (SDN).

In this paper, we will see the importance of a controller that has been developed from 2014 and is an SDN Controller. The ONOS Controller is used in a number of different scenarios, but here we will see only two use-cases. The first use case is “CORD: Leaf-Spine with Segment Routing”. The second use-case is “Packet-Optical Networks”. Both use-cases are managed by the ONOS Controller.

Key-words: Bottleneck, Switches, Routers, Networks, SDN, ONOS Controller, Use-cases,

Segment Routing, Packet-Optical.

2. Introduction and ONOS Overview

ONOS stands for Open Network Operating System. ONOS provides the control plane for a software-defined network (SDN), managing network components, such as switches and links, and running software programs or modules to provide communication services to end hosts and neighboring networks.

If you are familiar with server operating systems, you will find that ONOS provides

some analogous types of functionality, including APIs and abstractions, resource allocation, and permissions, as well as user-facing software such as a CLI, a GUI, and system applications.

If you are familiar with traditional "inside the box" switch operating systems, you will

find that ONOS manages your entire network rather than a single device, which can dramatically simplify management, configuration, and deployment of new software, hardware and services.

If you are familiar with SDN controllers, you should feel right at home because the

ONOS platform and applications act as an extensible, modular, distributed SDN controller. The most important benefit of an operating system is that it provides a useful and

usable platform for software programs designed for a particular application or use case. ONOS applications and use cases often consist of customized communication routing, management, or monitoring services for software-defined networks. Some examples of things which you

https://wiki.onosproject.org/display/ONOS/The+ONOS+CLI

https://wiki.onosproject.org/display/ONOS/The+ONOS+Web+GUI


2 | P a g e

can do with ONOS, and software written to run on ONOS, may be found in Applications and Use Cases.

ONOS can run as a distributed system across multiple servers, allowing it to use the CPU and memory resources of multiple servers while providing fault tolerance in the face of server failure and potentially supporting live/rolling upgrades of hardware and software without interrupting network traffic.

The ONOS kernel and core services, as well as ONOS applications, are written in Java as bundles that are loaded into the Karaf OSGi container. OSGi is a component system for Java that allows modules to be installed and run dynamically in a single JVM. Since ONOS runs in the JVM, it can run on several underlying OS platforms such as Ubuntu or OS X. [1]

In this part, I will add what is my contribution to the already existing onos capabilities. As stated later, we will see 2 different use cases in this paper. The first one is CORD: Leaf-Spine with Segment Routing and the second will be the Packet-Optical Network.

There are already some networks that are created by the development team of the ONOS Controller, but since they are different than the networks that we need, I created a separate network for the Segment Routing and the Packet Optical use case.

In the Segment Routing Use-Case, we have host 1 that is the source host, and we have on the other side of the network 3 hosts: h2, h3 and h4 that are used as destinations. In this network, we have 2 Leaf and 4 Spine nodes. Using these nodes, we create different paths for each packet, depending on the source and destination. This is explained in part 7.3.1. Custom Topology.

After creating the topology and finish the customization of the same, we are left to do the tests on the specific network. There are already tests that are done on the default networks, and so I use the same tests for the custom network and obtain the results for the network.

In the Packet-Optical case, we have created the same network. But, instead of staying with only IP Layer nodes, we have also Optical nodes. The leaf nodes from the Segment Routing use case are the same, but the Spine nodes are now Optical (WDM) Routers. Since the methodologies of routing packets are different. We use IP Routers and WDM Routers in the same network. We can see how the connection between the Routers is achieved in Image 30.

After creating the network, we create all the path intents. After the customization of the network, we can start with the tests. But, there are still no tests available from the developers, so using the knowledge of the tests from the Segment-Routing Use-Case, I created some tests that are testing the network. We can see these tests ant the explanation for them in the 10. PACKET-OPTICAL Tests part of this paper.

The installation and the environment configuration is done by following the commands that are left from the ONOS development team. I have used the commands form the team, but in the same time I have added my own contribution to simplify the explanation and understanding better why and which commands we are using.

https://wiki.onosproject.org/display/ONOS/Applications+and+Use+Cases

https://wiki.onosproject.org/display/ONOS/Applications+and+Use+Cases

https://wiki.onosproject.org/display/ONOS/Distributed+ONOS


3 | P a g e

3. Segment Routing [2]

We have this paragraph, because, in the “7. CORD: Leaf-Spine with Segment Routing” we are relying on segment routing and we are using it to route the packets in the network. So, a basic introduction of Segment Routing is going to help us better understand the actions we take in the use case.

Segment Routing is a technology that is gaining traction with the idea that it is going to simplify the MPLS networks. The Multi-Protocol Label Switching is the main paradigm in the major Service Providers networks. MPLS, uses labels to forward the packets, thus providing the major advantage in the sense of a Border Gateway Protocol (BGP)-free core.

To be able to implement the Segment Routing (SR) framework, we need to define two different components of the architecture:

- Data Plane of SR defines how to encode the sequence of segments to be applied on a packet, and the forwarding semantics of segments.

- Control Plane of SR defines how segment identifiers are spread among the network devices and how network devices are instructed to apply a given sequence of segments on a flow.

A) SR Data Plane [3] A SR header contains a sequence of segments, and a pointer to the active

segment of the packet, being the instruction that needs to be executed by the device processing the packet. When the active segment has been executed, the following segment on the list becomes the active one. A segment ID (SID) is an identifier for a segment. Depending on its type, a SID can have domain wide significance or can be significant only locally to the router processing it. The main types of segments are the following:

a. Node SID: The forwarding semantic associated with Node SID is to forward the packet on the shortest path towards the Node associated with that Segment ID. The operator assigns a domain wide unique Node segment ID for each router in the network.

b. Adjacency SID: The forwarding semantic associated with an Adjacency SID is to forward the packet over the corresponding adjacency. Each router will assign a locally significant segment ID for each of its IGP adjacencies.

c. Service SID: The forwarding semantic associated with a Service SID is to deliver the packet to the corresponding service provided by the node processing the packet. Each node will assign a locally significant segment ID for each service that it provides to the network.

An SR-enabled node supports the following data plane operations: d. CONTINUE - Forwarding action performed based on active segment. e. PUSH - Add a segment ahead of the SR header of the packet and set that

segment as the active segment. f. NEXT - Mark the next segment as the active segment.


4 | P a g e

B) SR Control Plane The control-plane of SR defines how the segment ID information is

communicated among devices in the network. In a SR network, Node and Adjacency SIDs will be advertised via the link state IGP protocol. ISIS and OSPF, the most popular IGP protocols in service provider networks, were extended to support the distribution of segment IDs [4] [5] The extensions of IGP protocols would allow any router to maintain a database of all nodes and adjacency segments. Also, by leveraging the sub-second convergence properties of both IGPs, the segment database on each router can be quickly updated after any topology change. Note that using these extensions, end-to-end encapsulation can be performed in the network without requiring enabling and management of another protocol, such as LDP. Another element of the control-plane of SR deals with how an ingress router is instructed to select the SR path that a packet should follow. The following methods can be used for this purpose:

a) Distributed Constrained SPF (CSPF) calculation. In this approach, an ingress router calculates the shortest path for a destination, under the constraint that this path matches some criteria. It then computes a sequence of node and adjacency segments that encodes this path. b) SDN controller based approach. SR provides a scalable and resilient data-plane while allowing the flexibility of control commonly assumed for SDN environments. This aspect led to the planned support of SR into designs of some SDN oriented controllers. c) Statically defined by the operator. Static configuration of the tunnels might be used for specific purposes such as testing or troubleshooting, but it is typically not recommended for network operation in the long term, due to evident scaling, resiliency, and management limitations.


5 | P a g e

4. MPLS Protocol [6]

Multi-Protocol Label Switching (MPLS) was developed as a packet-based technology and is rapidly becoming key for use in core networks, including converged data and voice networks. MPLS does not replace IP routing, but works alongside existing and future routing technologies to provide very high-speed data forwarding between Label-Switched Routers (LSRs) together with reservation of bandwidth for traffic flows with differing Quality of Service (QoS) requirements. [6] [31]

The basic operation of an MPLS packet-switched network is shown in the diagram below.

Diagram 1 [6]

MPLS uses a technique known as label switching to forward data through the network.

A small, fixed-format label is inserted in front of each data packet on entry into the MPLS network. At each hop across the network, the packet is routed based on the value of the incoming interface and label, and dispatched to an outgoing interface with a new label value.

The path that data follows through a network is defined by the transition in label values as the label is swapped at each LSR. Since the mapping between labels is constant at each LSR, the complete path is determined by the initial label value. Such a path is called a Label Switched Path (LSP). A set of packets that should be labeled with the same label value on entry to the MPLS network, and that will therefore follow the same LSP, is known as a Forwarding Equivalence Class (FEC). [6] [31]


6 | P a g e

LSR A is the ingress point into the MPLS network for data from host X. When it receives packets from X, LSR A determines the FEC for each packet, deduces the LSP to use and adds a label to the packet. LSR A then forwards the packet on the appropriate interface for the LSP.

LSR B is an intermediate LSR in the MPLS network. It simply takes each labeled packet and uses the pairing {incoming interface, label value} to decide the pairing {outgoing interface, label value} with which to forward the packet. This procedure can use a simple lookup table and can be performed in hardware, along with the swapping of label value and forwarding of the packet. This allows MPLS networks to be built on existing label switching hardware such as ATM and Frame Relay. This way of forwarding data packets is potentially much faster than examining the full packet header to decide the next hop.

In the example, each packet with label value 21 will be dispatched out of the interface

towards LSR D, bearing label value 47. Packets with label value 17 will be re-labeled with value 11 and sent towards LSR C.

LSR C and LSR D act as egress LSRs from the MPLS network. These LSRs perform the same lookup as the intermediate LSRs, but the {outgoing interface, label value} pair marks the packet as exiting the LSP. The egress LSRs strip the labels from the packets and forward them using layer 3 routing.

So, if LSR A identifies all packets for host Z with the upper LSP and labels them with value 21, they will be successfully forwarded through the network.

Note that the exact format of a label and how it is added to the packet depends on the layer 2 link technology used in the MPLS network. For example, a label could correspond to an ATM VPI/VCI, a Frame Relay DLCI. For other layer 2 types (such as Ethernet and PPP) the label is added to the data packet in an MPLS “shim” header, which is placed between the layer 2 and layer 3 headers. [6]

5. Prerequisites and Setup for ONOS

This step is always the same. Here we are always having the same prerequisites and we have the same setup for the three different use-cases. For each use case we will start from this step. Installing the VM, installing the Ubuntu Server and then creating a custom environment.

5.1. Installing the VM. Are we using Ubuntu Desktop or Ubuntu Server

The first thing to do is to download the Virtual Machine. We can use both Oracle VM VirtualBox or we can use VMware Player. Since I have been working with the Oracle VM VirtualBox, I chose to go in this direction. It doesn’t matter what we choose, since in the end we get the same result. It is the preference of the user.

I will not explain in detail the installation process of the Oracle VM VirtualBox. For the download and installation, we can follow the link in the references [32]:


7 | P a g e

After we are done with the download (which is free) and installation of the Oracle VM VirtualBox, we need to configure it for our environment. We can create 2 different Virtual Machines. The first one is the Ubuntu Server 14.04 TLS 64 bit (now 16.04 LTS) and the second one is the Ubuntu 14.04 TLS 64-bit desktop (now 16.04 LTS). Here are the links, respectively:

http://www.ubuntu.com/download/desktop [7] http://www.ubuntu.com/download/server [8] Below the download, we need to check the Recommended System Requirements.

Here we can see that we need 2 GHz dual core processor or better, 2 GB system (RAM) memory (my recommendation is to have at-least 4 GB RAM memory), 25 GB of free hard drive space, either a DVD drive or a USB port for the installer media Internet access is helpful.

The first thing that we need to do is to do is add a new Host-Only Adapter. We will use

this adapter to access the virtual machine remotely (using putty). After this configuration, we will have 2 Network Adapters. Adapter 1 will be for NAT and Adapter 2 will be for Host-Only. To configure the Network Adapters, we can click on the Settings button. After this we go to Network and we recreate the images 1 and 2:

Image 1 [50]

http://www.ubuntu.com/download/desktop

http://www.ubuntu.com/download/server


8 | P a g e

Image 2 [50]

We can see that both adapters are set. After the installation of the Operating System is complete, we will need to activate the Second Adapter. This is going to be explained in part “5.2. Creating a custom environment”.

What we need to remember is that we need a x64 bit installation. Now we open the Oracle VM VirtualBox and we click on the “New” button. After clicking the next button, we need to insert the name of the Operating System in the new window that will appear:

Image 3 [50]


9 | P a g e

We need to choose Name: Ubuntu, Type: Linux and Version: Ubuntu (64 bit). We need to choose these names because we will need authentication for accessing the GUI. We click on the next button and we get the next window asking about Memory. See Image 1.

Image 4 [50]

It is recommended to use 768 MB, but I will be using 1024 MB so I will not have any memory issues.

The next step will be asking us about the hard disk. We will choose the “Create a virtual hard disk now”. Then click “Create”. See Image 2.

Image 5 [50]

The following question asks us about the “Hard Disk File Type”. We will choose VDI and click next. See Image 3.


10 | P a g e

Image 6 [50]

The next question will be about the Storage on the Physical Hard disk. It is default “Dynamically allocated” and this should be our choice. We click next. After this we will need to choose the File location and Size. The default choice for File location was acceptable for me, and the Size of the Virtual Disk is supposed to be 8 GB. We can see the choices in Image 4.

Image 7 [50]

After we have created our virtual machine, it will be listed in the left corner. We will select our machine and click the button Start. We will choose our Operating System Image and click Start. See Image 5.


11 | P a g e

Image 8 [50] During the Ubuntu Server 14.04 TLS 64-bit installation, we will be asked a few questions.

We will need to create a user named sdn, with password rocks, and confirm that you want to use this password. This will be the primary account used for this tutorial. We need these username and password to be specific, since we will need them later on for accessing the GUI.

When prompted for disk encryption, please select No. We don’t need encryption.

For the partitioning of the disk, please select Guided - use entire disk and follow the defaults provided.

For the configuration of the proxy information, follow what best suits your environment. My choice was no proxy.

When prompted to install additional software (Software Install) choose OpenSSH server.


12 | P a g e

5.2. Creating a custom environment (screen and putty) 5.2.1. Here we customize the Ubuntu Server 14.04 TLS 64bit

After the installation finishes, we will need to set up our environment. We will login using sdn and rocks. The first thing that we should do is to give the user a password-less sudo privileges. We can do this by running the command “sudo visudo” and writing the following command at the end of the file:

sdn ALL=(ALL) NOPASSWD:ALL After this we should check if we have both network interfaces. We can use the

following command and obtain the following result:

$ ifconfig -a eth0 Link encap:Ethernet HWaddr 08:00:27:15:7e:e1 inet addr:10.0.2.15 Bcast:10.0.2.255 Mask:255.255.255.0 inet6 addr: fe80::a00:27ff:fe15:7ee1/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:35 errors:0 dropped:0 overruns:0 frame:0 TX packets:43 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:3535 (3.5 KB) TX bytes:3749 (3.7 KB) eth1 Link encap:Ethernet HWaddr 08:00:27:b7:18:47 inet addr:192.168.56.101 Bcast:192.168.56.255 Mask:255.255.255.0 inet6 addr: fe80::a00:27ff:feb7:1847/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:157 errors:0 dropped:0 overruns:0 frame:0 TX packets:48 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:19323 (19.3 KB) TX bytes:7379 (7.3 KB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

If we do not get the same result (e.g. without eth1 assigned an inet address) we can

use the following command:

$ sudo ifconfig eth1 <IP address> up

For the <IP address> I chose the default 192.168.56.101. This will be used for the

connection with putty. The putty software is free for download and use from the link number [33], that is

provided in the references


13 | P a g e

If someone has a different preference than putty, there is no problem with the configuration of the environment.

5.2.2. Here we customize the Ubuntu 14.04 TLS 64bit Desktop

Before we start with the VM Ubuntu 14.04 TLS 64but Desktop, I will mention here that we can also use a Desktop Ubuntu version and install it on a fresh machine. We can download or buy the Ubuntu 14.04 TLS 64bit Desktop OS in the following link:

http://www.ubuntu.com/download/desktop [7]

To install the Ubuntu 14.04 TLS 64bit Desktop OS on a fresh machine, we can follow the following link:

https://builtvisible.com/the-ubuntu-installation-guide/ [34]

In this part we will see how we can customize our environment by using a VM Ubuntu 14.04 TLS 64bit Desktop. The first step we need to take is to install the Oracle VM VirtualBox. This is done previously in this paper, specifically in the “5.1. Installing the VM”. The next step is to download the Ubuntu 14.04 TLS 64bit Desktop using link [11] and install it using the Oracle VM VirtualBox.

Following, we will see the process of the installation of the VM Ubuntu 14.04 TLS 64bit

Desktop and the basic configuration.

We need to create a new VM. o We need to use the following for Name “build”, for Type “Linux”:

Select 2 GB of RAM For the Hard Disk we choose the default parameters:

8 GB and create a virtual disk now The Hard Disk type file: VDI The storage on the Physical Hard Disk: Dynamically allocated For the file location and size: for name enter “build”, then select at least

10 GB for the size of the Virtual Hard Disk for the “build” VM o Open (click) on the Settings button for the “build” VM

Storage:

Go to Controller IDE

Click on the disk with the “+” sign to add an Optical Drive.

Choose disk: Browse the location of the downloaded ISO file Add a second network adapter for host only network.

We can see this in Image 1 and Image 2 System – The Motherboard tab

Uncheck Floppy and move the optical to the top of the Boot Order Box.

o Install Ubuntu (we need to use the same credentials as the first ubuntu VM) o When the Installation is finished, power the machine on and Log in

Now we need to create a basic SSH public key on the “build” machine (in the case we haven’t done it before). To do this we need to login to the “build” machine and run the following command:

build:~$ ssh-keygen -t rsa

o The Default options and No Password are acceptable in this case.


https://builtvisible.com/the-ubuntu-installation-guide/


14 | P a g e

We need to Verify the connectivity. From the build machine we should be able to SSH to the onos-scratch VM using the IP address assigned to eth1 using the following command:

build:~$ ssh -l sdn 192.168.56.101

o If the ssh connection failed make sure that the openssh-server is installed by

running:

$ sudo apt-get install openssh-server

o We should check if we can also ping the onos-scratch VM by IP from the “build” machine and vice versa.

sdn@build:~$ ping 192.168.56.101

5.2.3. Customizing Putty or Terminal

Depending on weather we will work on Ubuntu 14.04 TLS 64bit Desktop or Ubuntu Server 14.04 TLS 64bit, we will have a bit different way of customization. In here, I will explain the customization of the Ubuntu Server 14.04 TLS 64bit. The customization is personal, and I am explaining my customized environment. If someone has different preferences, you can use it.

The first thing we do is to open the screenrc file with the following command:

$ vim /etc/screenrc

After opening the file, we need to change it. The things that need to be changed are the following:

#hardstatus string “%h%? users: %u%?” We do not need this row hardstatus alwayslastline hardstatus string '%{= kG}[ %{G}%H %{g}][%= %{= kw}%?%-Lw%?%{r}(%{W}%n*%f%t%?(%u)%?%{r})%{w}%?%+Lw%?%?%= %{g}][%{B} %m-%d %{W}%c %{g}]'

After changing the file, it should look something like in Image 9.

Image 9 [50] Since this is a protected file and it is not to be edited easily, we need to save it with a

special command:

:w !sudo tee %


15 | P a g e

6. Installing ONOS from scratch: For all the different use-cases, we have the same VM installation protocol. [9]

In this paper, I will be explaining the case of running onos locally on a development machine. We use the explanation from the ONOS team from link [9].

6.1. Installing the required software

The first thing that we need to do is install Git

sdn@build:~$ sudo apt-get install git-core

Next, we need to install Karaf and Maven o We will create 2 directories called /Downloads and /Applications

sdn@build:~$ cd; mkdir Downloads Applications

o We will download the Karaf 3.0.5 and Maven 3.3.9 binaries (the tar.gz versions of both) into /Download

sdn@build:~$ cd Downloads sdn@build:~$ wget

http://archive.apache.org/dist/karaf/3.0.5/apache-karaf-3.0.5.tar.gz sdn@build:~$ wget http://archive.apache.org/dist/maven/maven-

3/3.3.9/binaries/apache-maven-3.3.9-bin.tar.gz

We need to extract the Karaf 3.0.5 and Maven 3.3.9 binaries in /Applications

sdn@build:~$ tar -zxvf apache-karaf-3.0.5.tar.gz -C ../Applications/ sdn@build:~$ tar -zxvf apache-maven-3.3.9-bin.tar.gz -C

../Applications/

The next thing to install is the Oracle Java 8 o While installing, it will ask for acknowledgment of the license. When it does,

do so. Also, the second step may prompt he installation of the python-software-properties. If it does, do so.

sdn@build:~$ sudo apt-get install software-properties-common –y sdn@build:~$ sudo add-apt-repository ppa:webupd8team/java –y sdn@build:~$ sudo apt-get update sdn@build:~$ sudo apt-get install oracle-java8-installer oracle-java8-

set-default –y

Now, we need to clone the onos source: o We need to copy the repository in a new onos directory under the home

directory on the build machine. To navigate to the home directory and copy the repository, we can use the following commands:

sdn@build:~$ cd ~ sdn@build:~$ git clone https://gerrit.onosproject.org/onos sdn@build:~$ git clone https://gerrit.onosproject.org/onos -b 1.3.0

o We can use the commands to copy the last and specific version of onos. To check the version of the onos, we can use the following commands:

sdn@build:~$ cd ~ sdn@build:~$ cd onos sdn@build:~/onos$ vi pom.xml

http://archive.apache.org/dist/karaf/3.0.5/apache-karaf-3.0.5.tar.gz

http://archive.apache.org/dist/maven/maven-3/3.3.9/binaries/apache-maven-3.3.9-bin.tar.gz

http://archive.apache.org/dist/maven/maven-3/3.3.9/binaries/apache-maven-3.3.9-bin.tar.gz

https://gerrit.onosproject.org/onos

https://gerrit.onosproject.org/onos%20-b%201.3.0


16 | P a g e

Image 10 [50]

o To check if we have installed the Maven and Karaf correctly, we can use the following commands

sdn@build:~$ cd ~ sdn@build:~$ cd onos/tools/dev/ sdn@build:~/onos/tools/dev$ vi bash_profile

Image 11 [50]


17 | P a g e

6.2. Set up the build environment

Environment Variables o First off, we will need to export some environment variables. The ONOS source

comes with a sample bash_profile that can set these variables for us. This file can be sourced from the interactive portion of .bashrc, or .bash_aliases (or .profile if /bin/sh is bash) of user sdn by the following process:

sdn@build:~$ cd ~ sdn@build:~$ vi .bashrc

o After we open the .bashrc file, we should add at the end of the file the following line:

. ~/onos/tools/dev/bash_profile

o After entering the line, please press Ctrl+X to exit and Yes to save the new changes

o Warning from the onos developers: technically any bash-specific code should

not go in .profile. If you have a Debian-based system (e.g. Raspbian) where .profile may be executed by a shell that is not bash (e.g. /bin/sh is dash or some other POSIX-like shell), make sure you put the above line in .bash_aliases or the interactive portion of .bashrc rather than .profile to avoid problems (such as startx not working on Raspbian.)

o To avoid these problems, we can use the following commands:

sdn@build:~$ cd ~ sdn@build:~$ cat .bashrc #this is to see the .bashrc output sdn@build:~$ source .bashrc

o Once we run the above command, we will see in the output of env that several

new variables, such as ONOS_ROOT, OCI, and KARAF_ROOT, have been set. o We can check to see if everything we have done so far is correct with:

build:~$ Env | grep JAVA_HOME build:~$ Env | grep MAVEN

o These commands should yield a result. If they didn’t, we have done something wrong and we need to re-check our steps.

Building onos o We need to Edit ~/Applications/apache-karaf-3.0.5/etc/org.apache.karaf

.features.cfg file by appending the following line to featuresRepositories:

sdn@ build:~$ nano ~/Applications/apache-karaf-3.0.5/etc/org.apache.karaf.features.cfg

o We need to locate the featuresRepositories and append this line (will need a comma before appending the text to separate from the previous value)

mvn:org.onosproject/onos-features/<onosversion>/xml/features

o After these changes, we need to save and close the file. o Now we are ready to build ONOS with Maven.

sdn@build:~$ cd ~/onos sdn@build:~$ mvn clean install # or use the alias 'mci'


18 | P a g e

o We can also use the command “mcis” to skip the tests that are done while building ONOS with Maven.

o Now we are ready to start customizing, creating, and installing ONOS packages.

o If previous version of ONOS is running, the service should be stopped (sudo service onos stop) before building with mvn. Otherwise, the test on onlab.niopackage would fail with "address already in use" error.

6.3. Create a custom cell definition 6.3.1. A quick intro into cells

Under ONOS terminology, a cell is a collection of environment variables that are used:

by the utility scripts included with ONOS, including the ones that we are about to talk about

for telling the packaging process how we want to customize our ONOS package

Cells make it easy to use the utility scripts to package, configure, install, and run ONOS. Here we will create an ONOS package that, when installed and launched, starts up a single-instance (non-clustering) ONOS instance that uses the intent-based forwarding application

6.3.2. Create a cell definition file

A cell is defined into a cell definition file. When we will create a cell definition file we are supposed to be saved in the following location: ${ONOS_ROOT}/tools/test/cells/. We will be looking at the cell that is already created here called tutorial. There are a few in this location and all are specified for a use-case. To open the cell definition file we can use 2 ways: Firstly, we can use the following command from the home ${SDN_ROOT} location:

sdn@build:~$ cd ~

sdn@build:~$ nano onos/tools/test/cells/tutorial

The second way is to go to the location of the cells and open them from there. Both ways yield the same result:

sdn@build:~$ cd ~

sdn@build:~$ cd onos/tools/test/cells/

sdn@build:~$ vi tutorial


19 | P a g e

This is the output of both ways:

# ONOS from Scratch tutorial cell # the address of the VM to install the package onto export OC1="192.168.56.101" # the default address used by ONOS utilities when none are supplied export OCI="192.168.56.101" # the ONOS apps to load at startup export ONOS_APPS="drivers,openflow,fwd,proxyarp,mobility" # the Mininet VM (if you have one) export OCN="192.168.56.102" # pattern to specify which address to use for inter-ONOS node communication (not used with single-instance core) export ONOS_NIC="192.168.56.*"

We should take a look and bear in mind that:

OC1 and OCI are set to the address of eth1 in our VM (onos-scratch VM)

ONOS_APPS indicates the ONOS applications we want to activate, including OpenFlow protocol, reactive forwarding (fwd), proxy ARP, and mobility.

6.3.3. Applying a cell

We can use the already given cell to apply and build our environment with the following cell command:

sdn@build:~$ cell tutorial

Now any ONOS package you will build will take up the ONOS_APPS setting. Additionally, if you need to create packages with other configurations (i.e. different applications or install targets), all you need to do is to apply a different cell definition to your environment before package creation and deployment.

If you want to work with multiple terminals on the build machine, you should apply the cell to each new terminal you have, if you want the onos-* scripts (from the Create and Deploy the package sections below) to work from all of them.

You can also use the vicell utility to create and edit your cell file. For example, to create a new cell file:

sdn@build:~$ vicell -c -a mycell

The above command opens a new file named "mycell" in ${ONOS_ROOT}/tools/test/cells, either in the editor specified by the EDITOR env variable, or vi otherwise. When you exit out of the editor, the cell is automatically created and then applied to your session. See vicell -h for the list of options.


20 | P a g e

Another way to create a cell is to go to the cell location and use the vim text editor. We can create a new cell and save it there. After we create and save the cell, we can load it from the ${SDN_ROOT} location.

sdn@build:~$ cd onos/tools/test/cells sdn@build:~$ vim mycell

After we save the cell, we can load it from the ${SDN_ROOT} location with the following command:

sdn@build:~$ cell mycell

6.4. Package and Deploy ONOS 6.4.1. Password-less VM access

For our convenience, before we deploy anything to our Virtual Machine, we can configure a password-less login to the VM from our build machine with the onos-push-keys command:

build:~$ onos-push-keys 192.168.56.101 [email protected]'s password:

Older versions of the utility will ask you to authenticate multiple times; newer versions will require you to enter the password just once.

This tutorial deals with only 1 VM, but if you want to create a cluster of ONOS, cloning the 1st VM, onos-patch-vm script can be used to set the hostname, etc. to the cloned VM.

build:~$ onos-patch-vm $OC2 onos-scratch2 192.168.56.102: onos-scratch2

$OC is an abbreviation for ONOS Controller address. For example, $OC1=192.168.56.101, $OC2=192.168.56.102 and etc. This is defined by the cell definition file.

6.4.2. Creating a package

To create an ONOS binary, run onos-package (or op, for short):

build:~$ onos-package -rw-rw-r-- 1 onosuser onosuser 33395409 Dec 4 16:12 /tmp/onos-1.5.1.onosuser.tar.gz

This creates a tar archive in /tmp. We can use this package to install it t different VM’s without having to do all the previous work.

6.4.3. Deploying the package

After running the onos-package command, we can deploy it to our VM with the following command:

build:~$ onos-install -f $OC1 onos start/running, process 2028


21 | P a g e

Once onos-install returns with the last message in the code block above, we can try logging on from our build machine with the following command: onos $OC1

build:~$ onos $OC1 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>

We are now actually logged into the ONOS CLI of the instance that we have deployed

on the VM. Use apps to list all installed applications. The one with asterisk sign indicates that it is

activated (running).

onos> apps -a -s * 6 org.onosproject.drivers 1.5.1.SNAPSHOT Default device drivers * 35 org.onosproject.hostprovider 1.5.1.SNAPSHOT ONOS host location provider. * 50 org.onosproject.sdnip 1.5.1.SNAPSHOT SDN-IP peering application * 56 org.onosproject.lldpprovider 1.5.1.SNAPSHOT ONOS LLDP link provider. * 78 org.onosproject.openflow-base 1.5.1.SNAPSHOT OpenFlow protocol southbound providers * 82 org.onosproject.openflow 1.5.1.SNAPSHOT OpenFlow southbound meta application * 94 org.onosproject.proxyarp 1.5.1.SNAPSHOT Proxy ARP/NDP application. onos>

The argument $OC1 can be replaced with $OCI, or even omitted; when omitted, the scripts will fall back to using the value stored in OCI.

Warning: If by any chance the apps –a –s command yields no result, wait a few minutes than try again. If it doesn’t work after a few minutes, try:

build:~$ onos-install $OC1 onos start/running, process 2028


22 | P a g e

7. CORD: Leaf spine with Segment routing 7.1. Overview

Today’s IP/MPLS networks are complex and hard to manage. Label distribution, traffic engineering, and VPNs are very complex operations and services that depend on a collection of distributed protocols in the control plane. Furthermore debugging such networks is incredibly hard given synchronization and state-management issues between multiple protocols in the control plane and a locally-significant label-swapped data plane.[10]

The IETF has introduced the concept of Segment Routing (SR) for MPLS (known by its IETF name SPRING). It introduces globally-significant labels that don't need to be swapped at each hop. It also introduces source-routing based on labels, which eliminates dependence on complex protocols like LDP and RSVP for label distribution and LSP setup. Segment Routing thus simplifies both the control and data plane of MPLS networks. While SR continues to depend on an IGP for routing and label distribution, it opens the possibility for an external controller to program end to end tunnels originating at the source router.[10]

The use case on Segment Routing is being pursued in collaboration with the Open Networking Foundation's SPRING-OPEN project led by Saurav Das. The project demonstrates how SR can be realized using the SDN control plane implemented with ONOS and an SR application, working with bare-metal hardware routers built on merchant silicon that exists today. This solution does not use a distributed IGP embedded in the routers. Instead it uses a routing application on ONOS. And the application programs the edge-routers and core-routers for forwarding with segment routing rules for default routing and policy-based routing. With ONOS providing the control and an application managing the labels in the network, network operators can express their policy requirements to the controller, and the app together with ONOS implements the policy in the IP/MPLS network.[10]

Image 12 [51]


23 | P a g e

7.2. Software Switch installation guide (default): 7.2.1. Introduction

In this part, we are going to see how to setup the CORD Fabric environment with Mininet and CpqD software switches. This pure software environment allows us to develop and test the control logic (i.e. the Segment Routing app on ONOS) without any Hardware Switches.

7.2.2. ONOS installation

The installation will be always explained step by step on a fresh virtual machine. In this part, we can choose if we want to create an ONOS cluster with 1 or 3 instances. In this paper, we will be following the ONOS cluster with 1 instance. The installation will follow 4 basic steps.

I. Fetch and compile ONOS a. For this part, we will have to go and see part 2. Installing ONOS from Scratch.

II. We need to enable the segment routing application in our cell configuration. (load cell before screen)

a. Firstly, we need to have a text editor installed. I chose the same that was preinstalled in the Ubuntu Server 16.04 LTS, “vim text editor”.

i. If we do not have the vim text editor, we can use the following command to install it:

:~$ sudo apt-get install vim

b. To modify the cell configuration, we can use a few different ways: i. Load a cell that is already in the following location:

:~$ONOS_ROOT/tools/test/cells/

ii. Create a new cell (I created a new cell for 1 instance) and save it in the same location:

:~$ONOS_ROOT/tools/test/cells/mycordcell

iii. Here, I will load my cell with a text editor: vim mycordcell

#Local VirtualBox-based single ONOS instance & ONOS mininet box export ONOS_NIC=10.0.2.* export OC1="10.0.2.15" export OCN="10.0.2.15" export ONOS_WEB_USER=onos

export ONOS_WEB_PASS=rocks export ONOS_USER=sdn

export ONOS_GROUP=ubuntu export ONOS_APPS="drivers,openflow,segmentrouting" # WEB_USER, WEB_PASS, USER and GROUP are used for accessing the GUI #We activate only the needed APPS: drivers, openflow and segmentrouting

iv. To load the cell, we only use the following command:

:~$ cell mycordcell

Loading the cell needs to be done before we enter the “screen” command.


24 | P a g e

v. To check the cell of our environment, we can use the following command:

:~$ cell

ONOS_CELL=mycordcell OCI=10.0.2.15 OC1=10.0.2.15 OCN=10.0.2.15 ONOS_APPS=drivers,openflow,segmentrouting ONOS_GROUP=ubuntu ONOS_NIC=10.0.2.* ONOS_SCENARIOS=/home/sdn/onos/tools/test/scenarios ONOS_USER=sdn ONOS_WEB_PASS=rocks ONOS_WEB_USER=onos

III. Configure Segment Routing

We need to copy and modify the sample “network-cfg-fabric-2x2-min.json” file. We can find it in two different locations. Location 1:

:~$ ONOS_ROOT/tools/package/config/samples/network-cfg-fabric-2x2-min.json

Location 2:

:~$ ~/Applications/config/samples/network-cfg-fabric-2x2-min.json

We can open the network-cfg-fabric-2x2-min.json file and see it: Seeing the network-cfg-fabric-2x2-min.json, we can now configure the following:

a. Running Remotely: (1, 3+ instances) Push the sample json file to the remote machine using the onos-netcfg command

:~$ onos-netcfg <IP> $ONOS_ROOT/tools/package/config/samples/network-cfg-fabric-2x2-min.json

After this, we need to run “stc setup” to start ONOS with the new configuration b. Running Localy: (1 instance)

We need to copy the sample json file to the following location and then rename it to network-cfg.json: ~/Applications/config/network-cfg.json After copying and renaming it, we can use ok clean to start ONOS with the new configuration.

Segment routing (up until now), does not support dynamic configuration. After pushing a new configuration, we need to restart the segment routing app.


25 | P a g e

7.2.3. Mininet and CpqD Software Switch Installation

1. For detaied installation of Mininet, please follow the online native insallation from source code at http://mininet.org/download/

2. Copy and set the branch of Mininet: $ git clone git://github.com/mininet/mininet $cd mininet $git checkout –b 2.2.1 2.2.1

The first thing that is done here is we clone the git repository to the given folder in the home directory. Then we open the new folder that we created, called mininet. Then we need to update the files that are in the working tree to match the version in the index or the specified tree. The –b part in the last command does the following:

-b <new_branch> Creates a new branch named <new_branch> and starts it at <start_point>

3. Next, we need to Patch Mininet A patch multi_controller.patch is required to allow CpqD software switches to connect to multiple controller instances simultaneously. We are using a single controller here, so we do not need to use this patch. Even though we do not need this, for someone who needs it, the first thing to do is save the multi_controller.patch in the Mininet root directory.

We can apply the patch using the following command:

# In the Mininet Root directory :~$ git apply multi_controller.patch

4. Now, we install Mininet and CpqD Software Switch

$ sudo ./util/install.sh –n3f

7.2.4. Start the Fabric 1. Before starting the fabric, we should check the cell and see if the #OC[1-9] are

correctly set up. This is because the fabric reads controller information from the cell configuration.

2. We can use the Mininet script that is provided cord_fabric.py or we can use a custom script. The mininet script needs to be saved in a specific location: ~/mininet/custom/

3. To start the script, we use the following command:

http://mininet.org/download/


26 | P a g e

sudo –E ./cord_fabric.py --spine=2 --leaf=2

4. To start the custom topology, we use the following command:

sudo –E python mytopology.py

5. To check if we did a correct job, we need to ping.

mininet> pingall *** Ping: testing ping reachability h1 -> h2 h3 h4 h2 -> h1 h3 h4 h3 -> h1 h2 h4 h4 -> h1 h2 h3 *** Results: 0% dropped (12/12 received)

6. When we open the onos controller tab, we need to check the default apps. We will do this with the command: onos> apps –a –s * 6 org.onosproject.hostprovider 1.6.0.SNAPSHOT Host Location Provider * 21 org.onosproject.openflow-base 1.6.0.SNAPSHOT OpenFlow Provider * 22 org.onosproject.lldpprovider 1.6.0.SNAPSHOT LLDP Link Provider * 23 org.onosproject.openflow 1.6.0.SNAPSHOT OpenFlow Meta App * 60 org.onosproject.segmentrouting 1.6.0.SNAPSHOT Segment Routing App * 83 org.onosproject.drivers 1.6.0.SNAPSHOT Default Device Drivers onos>

7.2.5. (OPTIONAL) GUI configuration 1. Configure Sprites

To configure the sprites, we use the following command:

$ onos-upload-sprites $OC1 onos/web/gui/src/main/webapp/data/sprites/ segmentRouting. json

Then, access the URL via: http://<ONOS_IP>/onos/ui?sprites=segmentRouting We need to be careful with the command, it is case-sensitive. Or, access the URL via: http://<ONOS_IP>/onos/ui/; Use username=karaf, Password=karaf

2. Configure Topology view To configure the Topology view we use the following command:

$ onos-topo-cfg $OC1 onos/tools/test/topos/cord.json


27 | P a g e

7.3. Custom Topology and Network Configuration 7.3.1. Custom Topology

Here we use a custom topology. We need to have 2 separate files so our network will work. First we need to have a custom topology file. My file is named finaltopo.py. Second we need a network configuration file which should be named network-cfg.json and placed in the “~/Applications/config/” folder. We will see the custom topology and the custom network configuration. The file that is for the topology needs to be a python (.py) file and the file with the custom network configuration needs to be a Java Script (.json). Here, we can see what our topology will look like. We have decided to go with the same network topology that was proposed in the paper “SDN Control of Packet-over-Optical Networks” [11]

Image 13 [51] Here, I will try to explain how the creation of the network topology and its

configuration is done. The first thing that I will explain is the network topology creation in the mytopo.py file and then how it is connected to the network-cfg.json file. It is obvious that mytopo.py has a lot of similarities with the topology in Image 13. The only thing that we added is a link between the two leaf switches. This can be seen on Image 16, and is highlighted as a direct path from h1 to h3 in Image 19.

The first thing that we do is create the switches. We chose 6 switches (2 leaf and 4 spine routers). This is important, since we can see that in the networs-cfg.json file we have a variable for each router “isEdgeRouter” in which we have true for switches 1 and 2 and we have false for switches 3, 4, 5 and 6.

The next thing we do is create the hosts. We need to choose some parameters when we create the hosts. These parameters need to be coherent with the parameters in the network-cfg.json file.


28 | P a g e

The hosts IPs need to be in the same network as the switches they are connected to. Hence, h1 belongs in the network of Switch 1. Next, h2, h3 and h4 belong to the network of Switch 4. We can clearly see their IP addresses and their subnet masks. If they are not consistent, we will not be able to ping any of the hosts.

The following thing we need to do is to create the links between switches. We do this first, because we can have the same underlying topology, and then add more or decrease the number of hosts. We can see that we do not put the number of the port when we create the links. This way, when the link is created, for example self.addLink(s1,s2), the link will connect to Switch 1 and the first available port (in this case it is port 1, since this is the first link created). For Switch 2, it will do the same and take port 1. So the link will be defined like: S1/1 – S2/1.

The next link that is added is the self.addLink(s1,s3). Now, here we need to be careful because we know that port 1 on Switch 1 is assigned to the link S1-S2. So now, we take the next available port, which is 2. For Switch 3, we have no ports assigned, so we take port 1. So the link will look like S1/2 – S3/1.

The next link that is added is the self.addLink(s1,s4). Now, here we see that on Switch 1 we have ports 1 and 2 already assigned, so we take port 3. There are no ports assigned on Switch 4, so we take port number 2. The link will look like S1/3 – S4/1.

We continue on this path until we have all the links added. After adding all the links between the switches, we are going to add the links between host – switch.

Now we need to be very careful, because we need to have the port numbers in network-cfg.json and the port numbers that will be checked in the finaltopo.py file need to be coherent.

The first link is the self.addLink(h1,s1). For the host, we don’t have any port numbers, but for the routers, we will choose the first available. Host 1 is connected to Switch 1. Switch 1 has ports 1, 2, and 3 already assigned, so the first available port is the port number 4. So we will have the link h1 – S1/4.

The next link is the self.addLink(h2,s2). For the host, we don’t have any port numbers, but for the routers, we will choose the first available. Host 2 is connected to Switch 2. Switch 2 has ports 1, 2, and 3 already assigned, so the first available port is the port number 4. So we will have the link h1 – S2/4.

After this, we have a peculiar situation, where we firstly add host 4 then we add host 3. This is how we get the following links.

The next link is the self.addLink(h4,s2). For the host, we don’t have any port numbers, but for the routers, we will choose the first available. Host 4 is connected to Switch 2. Switch 2 has ports 1, 2, 3, and 4 already assigned, so the first available port is the port number 5. So we will have the link h1 – S2/5.

The next link is the self.addLink(h3,s2). For the host, we don’t have any port numbers, but for the routers, we will choose the first available. Host 3 is connected to Switch 2. Switch 2 has ports 1, 2, 3, 4 and 5 already assigned, so the first available port is the port number 6. So we will have the link h3 – S2/6.

There is no difference in adding first host 3 and then host 4 or vice versa. The only difference is in the network-cfg.json file. We will need to input the correct hosts and connect them in the correct switches/ports. If we mix this, we will not be able to send any packets to and from these hosts.

Also, as we can summarize, the network in image


29 | P a g e

First we will see some examples of how the commands work, and then we will see our custom commands.

The sr-tunnel-add command instantiates a tunnel called FASTPATH, that goes through routers 101, 105, 102, in that order [12]:

onos> sr-tunnel-add FASTPATH 101,105,102

The sr-policy-add command can be applied to a subset of traffic, for example: policy 1

= tcp_port=80 >> fwd(TUNNEL_1)

onos> sr-policy-add p1 1000 10.0.1.1/24 80 10.0.2.1/24 80 TCP TUNNEL FLOW FASTPATH

If we have some difficulties with the commands, we can use the help that onos is

providing. We can use the --help after a command to see the explanation for it. We can see this on the two following images:

Image 14 [50]

Image 15 [50]


30 | P a g e

We can check the number of nodes, devices, links, hosts, flows, SCC’s and intents with the following command:

onos> summary node=127.0.0.1, version=1.6.0.SNAPSHOT nodes=1, devices=6, links=18, hosts=0, SCC(s)=1, flows=148, intents=0 onos>

We can see here that we have 148 flows and we saw previously that we got 100% success or 0% dropped packets. The next thing we need to do is to see the network using a browser (we use chrome in this situation) and access it with http://<eth1 IP>:8181/onos/ui. We need to use the credentials of user=karaf and password=karaf to access the GUI. The following images show the network using the GUI.

Image 16 [50] To see the hosts, we can simply press on the button “H” on our keyboard. We will

not see the hosts if we have not pinged any of them before hitting the button “H”. After pinging the hosts, we can see the hosts clearly. See Image 17.

Image 17 [50]


31 | P a g e

In this paper, we want to change the paths that some packets take. Our idea was to make customized paths for each packet. We will take the default source to be host 1 with IP 10.0.1.1 and the destinations to be hosts 2, 3 and 4. The IP addresses of the hosts are the following: h2=10.0.2.1, h3=10.0.2.2, h4=10.0.2.3.

Each Router and Switch is identified by a label. The edge routers will encapsulate the IP Traffic with the MPLS label associated to the destination of the packet. The spines will simply forward the traffic based on the MPLS labels. The Segment Routing application allows the expression of policies through tunnels. We will define the tunnel as a set of labels. We start from the source router, and continue to the custom path, adding the labels of all the routers we encounter, until the final is the destination router. To create these flows, we will be using the sr-tunnel-add and sr-policy-add commands.

In the following images we will see the paths that the packets take depending on the destination. For packets going from h1h2, the packets will take the path number 1, or h1-

s1-s4-s6-s2-h2 and this is shown in Image 18. To create this flow, we will use the following commands:

onos> sr-tunnel-add t1 101,104,106,102 onos> sr-policy add p1 1000 10.0.1.1/24 80 10.0.2.1/24 80 TCP TUNNEL_FLOW t1

Image 18 [50] In Image 18, we can clearly see the path that is used for packets with source h1 with

IP 10.0.1.1 and with destination h2 with IP 10.0.2.1. We can choose different paths for different destinations. Vice versa, the packets going from source h2 with IP 10.0.2.1 with destination h1 with IP 10.0.1.1 will take the same path but in reverse: h2-s2-s6-s4-s1-h1.

For packets going from h1h3, the packets will take the path number 2, or h1-s1-s2-h3 and this is shown in Image 19.

To create this flow, we will use the following commands:

onos> sr-tunnel-add t2 101,102 onos> sr-policy add p2 1000 10.0.1.1/24 80 10.0.2.2/24 80 TCP TUNNEL_FLOW t2


32 | P a g e


IP 10.0.1.1 and with destination h3 with IP 10.0.2.2. Vice versa, the packets going from source h3 with IP 10.0.2.2 with destination h1 with IP 10.0.1.1 will take the same path but in reverse: h3-s2-s1-h1.

For packets going from h1h4, the packets will take the path number 3, or h1-s1-s3-s5-s2-h3 and this is shown in Image 20.

To create this flow, we will use the following commands:

onos> sr-tunnel-add t3 101,103,105,102 onos> sr-policy add 3 1000 10.0.1.1/24 80 10.0.2.3/24 80 TCP TUNNEL_FLOW t3


IP 10.0.1.1 and with destination h4 with IP 10.0.2.3. Vice versa, the packets going from source h4 with IP 10.0.2.3 with destination h1 with IP 10.0.1.1 will take the same path but in reverse: h3-s2-s5-s3-s1-h1.


33 | P a g e

8. Segment Routing Tests 8.1. Explanation for test creation and application

All the tests that are seen in this part are done in the same way that are done by the ONOS development team. The ONOS development team does their tests on a specific network which are designed for the purpose of testing the ONOS controller. Here, we can see the same tests done on a custom network that is can be seen in the part 8.3.1. Custom Topology. Because this network will be used in many instances, we can see in the part 8.3.1. Custom Topology, the network is named finaltopo.py.

After looking at the changes for the test, we will only look at a summary of what the

tests have achieved, starting form 10.1.SR Switch Failure.

Because there will be a lot of space used if I write all of the tests, I will explain just one of them, and give you an idea of how all of the other tests work. Let’s take the 10.3. SR Link Failure. The first thing that I did was to add the topology in the test “SRLinkFailure.py”. All the things that are default stay in normal fonts, but my contribution will be underlined, bold and italic. [13]

Then, in the SRLinkFailure.params i added the new test like:

<testcases>1,2,4,5,6</testcases>

Also in the SRLinkFailure.params we need to change which switch should be killed and which links will go down with it. Links 5 and 8 are indexed by order of creation. [13]

<kill> <switch> s6 </switch> <dpid> 0000000000000006</dpid> <links> 5 8 </links> </kill>

Next, in the SRLinkFailure.topo we need to change all the user and password parameters. From user=sdn to user=karaf, user=onos to user=karaf and from password=rocks to password=karaf

<user>sdn</user> <user>karaf</user> <user>onos</user> <user>karaf</user> <password>rocks</password> <password>karaf</password>

The results in Images 21, 22, 23, 24, 25 are from the tests that are being done by the ONOS Development Team. I will only put a graph in the end to show us my tests. I will be creating one graph in which I will show the summary of the tests. [13]


34 | P a g e

8.2. SR Switch Failure 8.2.1. This test verifies basic connectivity using Segment-Routing via

pingall, it should not fail. [14]

The test consists of:

1: Create and Apply cell file - PASS 2: Create and Install ONOS package - PASS 3: Starting ONOS service - PASS 4: Checking if ONOS CLI is ready - PASS 5: Starting Mininet Topology - PASS 6: Check whether the flow count is bigger than 350 - PASS 7: Check whether all flow statuses are ADDED - PASS 8: Check IP connectivity - PASS 9: Check VLAN connectivity - PASS 10: Kill Swtch3 - PASS 11: Check IP connectivity CASE2_Failure - FAIL IP connectivity failed 12: Check VLAN connectivity CASE2_Failure - PASS 13: Recovering Switch3 - PASS 14: Check whether the flow count is bigger than 350 - PASS 15: Check whether all flow statuses are ADDED - PASS 16: Check IP connectivity CASE2_Recovery - PASS 17: Check VLAN connectivity CASE2_Recovery - PASS

Requirements: An updated version of the CPQD switch has to be running to make sure it supports group chaining.

The test is executed using the netcfg subsystem: 1) APPS=openflow-base,netcfghostprovider,netcfglinksprovider

Topologies:

- finaltopo.py (custom topology)

Image 21 [52]


35 | P a g e

8.3. SR Sanity 8.3.1. This test verifies basic IP connectivity using Segment-Routing via

pingall [13]

The test consists of:

1) Configure and Install ONOS 2) Start Mininet and check flow state 3) Pingall

Requirements: An updated version of the CPQD switch has to be running to make sure it supports group chaining.

The test is executed using the netcfg subsystem:

1) APPS=openflow-base,netcfghostprovider,netcfglinksprovider

The test runs for different topologies:

- 2x2 Leaf-Spine and 1-node ONOS cluster - 4x4 Leaf-Spine and 1-node ONOS cluster - Single switch and 1-node ONOS cluster - 2x2 Leaf-Spine and 3-node ONOS cluster - 4x4 Leaf-Spine and 3-node ONOS cluster - Single switch and 3-node ONOS cluster - finaltopo.py

Image 22 [52]

In these tests, we have some of them failed. Why is this? This is because of the changes that the development team is making on the Controller. So, this is not a failed test because of the networks, this is a test failed because of the environment that the test is in. This is for SR Sanity and SR Switch Failure.


36 | P a g e

8.4. SR Link Failure 8.4.1. This test verifies basic connectivity using Segment-Routing via

pingall, it should not fail. [15]

It consists of:

1: Create and Apply cell file - PASS 2: Create and Install ONOS package - PASS 3: Starting ONOS service - PASS 4: Checking if ONOS CLI is ready - PASS 5: Starting Mininet Topology - PASS 6: Check whether the flow count is bigger than 350 - PASS 7: Check whether all flow statuses are ADDED - PASS 8: Check IP connectivity - PASS 9: Check VLAN connectivity - PASS 10: Kill link between Switch1 and Switch3 - PASS 11: Check IP connectivity CASE2_Failure - PASS 12: Check VLAN connectivity CASE2_Failure - PASS 13: Restore link between Switch1 and Switch3 - FAIL Failed to bring link up 14: Check IP connectivity CASE2_Recovery - PASS 15: Check VLAN connectivity CASE2_Recovery - PASS

Requirements:

An updated version of the CPQD switch has to be running to make sure it supports group chaining.

The test is executed using the netcfg subsystem:

1) APPS=openflow-base,netcfghostprovider,netcfglinksprovider

The topology is

- finaltopo.py

Image 23 [52]


37 | P a g e

As we can see here, if we have a link failure, the pinging between hosts will not happen. To be more precise, if we send packets form h1 to h3, and the route that h3 takes has a Link Failure, then h1 and h3 will not be able to speak. This is because we have static routes in place and if the route is not available, the packets will not get to their destination. This is because we do not have any secondary route from h1 to h3.

8.5. SR ONOS Failure 8.5.1. This test verifies basic control plane resilience from an ONOS

Instance failure using Segment-Routing via pingall [13]

It consists of:

1) Configure and Install ONOS 2) Start Mininet and check flow state 3) Pingall 4) Induce a ONOS failure 5) check flow state 6) Pingall

Requirements:




- 2x2 Leaf-Spine and 3-node ONOS cluster - 4x4 Leaf-Spine and 3-node ONOS cluster - Single switch and 3-node ONOS cluster - finaltopo.py

Image 24 [52]


38 | P a g e

Here we see a difference from the previous test (Link Failure). This is because the controller is left to create a secondary path, in the case of a node failure. But, in the case of Node 1 failing or Node 2 failing, we cannot have secondary paths, since they are the Nodes that are directly connected to the hosts.

8.6. Future Test: SR Cluster Restart 8.6.1. This test verifies control plane resilience from a CLUSTER restart [13]

It consists of:

1) Configure and Install ONOS 2) Start Mininet and check flow state 3) Pingall 4) Induce a CLUSTER restart 5) check flow state 6) Pingall

Requirements:




- 2x2 Leaf-Spine and 3-node ONOS cluster - 4x4 Leaf-Spine and 3-node ONOS cluster - Single switch and 3-node ONOS cluster - finaltopo.py

Image 25 [52]


39 | P a g e

Here we can see the results of Cluster Restart Tests. But, I am not going to have the same result as the results from the development team.

In my case, I am working with 1 cluster, not many, so the cluster restart will have 100% Failure and 0% Success in my case.

8.7. Test Execution Summary

Test Start : 03 Jun 2016 12:25:10 Test End : 03 Jun 2016 12:28:35 Execution Time : 0:03:24.365754 Total tests planned : 5 Total tests RUN : 5 Total Pass : 4 Total Fail : 1 Total No Result : 0 Success Percentage : 80% Execution Result : 20%

Chart 1 The failed test, as stated before, is the 9.5. Future Test: SR Cluster Restart.

Chart 2

0

1

2

3

4

5

6

Take 1 Take 2 Take 3 Take 4 Take 5

Summary of all the Tests taken Together

Tests Planned Tests Failed Tests Succedded

0

1

2

3

4

5

6

Test 1 Test 2 Test 3 Test 4 Test 5

Separate Test Results

Planned Failed Succedded


40 | P a g e

9. Packet-Optical Use-case 9.1. Introduction

In this article traffic-engineering issues regarding coordination among multiple layers of network architecture will be reviewed for next-generation optical networks based on wavelength-division multiplexing (WDM). Due to the recent progress and development of WDM technology, increasing traffic demands can be readily accommodated in the next-generation optical networks. In spite of the huge amount of capacity (e.g., OC-192) provided by a WDM channel, enhanced network services and network performance improvement can only be achieved with efficient traffic-engineering mechanisms. The fault-tolerant function is essential in order to provide seamless services to users by protecting their traffic against failures in the optical network because many connections can be carried on a fiber. Because the capacity of a WDM channel is very large, its bandwidth may not be efficiently utilized by a single connection. Hence, low-rate user connections need to be efficiently aggregated through the traffic-grooming scheme. An intelligent routing algorithm is especially necessary in the optical network where signal impairments due to device imperfections might degrade the signal quality. In addition, the virtual network connectivity (topology) should be flexibly maintained such that dynamic changes to the traffic demands can be easily absorbed, which can be implemented by the virtual-topology engineering method in a WDM network. As the dominant usage of Internet protocol (IP) of the Internet is expected to reside directly above the WDM layer in the future network, the coordinated traffic-engineering scheme should be deliberately designed for the multi-layer network by judiciously choosing where to put many overlapping functions in the different network layers. [16]

9.2. Overview

ONOS (Open Networking Operating System) is purpose-built for service providers. These typically operate large and complex multi-layer networks. ONOS has native support for the most common type of multi-layer network, namely the packet/optical network. It does so by offering an innovative converged topology view, allowing rapid introduction of new services and unprecedented optimization in an environment which has been dominated by a legacy mindset. [17]

9.3. Motivation

Service Provider Networks are complex and multi-layer in nature. Each of these layers, including packet and optical, is provisioned and managed independently. Sometimes, the provisioning and adding of capacity or new services requires order of days if not months. A converged SDN control plane for packet and optical networks can help address all of these inefficiencies. Service providers can optimize across packet and optical layers in real-time for availability and economics, thereby reducing over-provisioning. They can add capacity based on traffic and other considerations in minutes instead of days or months. [17]

Typical optical transport networks are made up of ROADMs (Reconfigurable Optical Add Drop Multiplexers) that switch wavelengths and sub-wavelength circuits (OTN), while multiple IP layer connections are carried over the same wavelength. Provisioning of these optical wavelengths or lambdas is a labor-intensive and manual task that requires physically


41 | P a g e

fibering of tunable lasers to the correct port. Adding on-demand connections or shifting capacity must be planned well in advance, and at significant operational expenses, ultimately creating an optical layer which is static and inflexible. [17]

Additionally, due to this inflexible nature of current transport networks, a great deal of spare packet and optical capacity is deployed to cover all possible failure points. This is combined with the need to support busy hour scenarios with overcapacity to minimize packet loss. Capacity planning and traffic engineering must consider all possible traffic load and failure scenarios because the optical network cannot be reconfigured at will. Furthermore, optical impairments are complex and require careful planning and traffic optimization practices. For example, optical reach must be carefully considered when paths are set up by the path computation elements/Engines. [17]

Our goal is to build an open source solution that allows effective multi-layer network programmability using novel abstractions such as intent-based networking and converged topology graphs.[17]

9.4. Optical Information Model [18]

9.4.1. ONOS Topology Information model

Image 26 [17]

Topology information model elements, relevant to transport network, consist from Device, Port, and Link.

- Device represents network infrastructure devices, such as (Packet) switch, ROADM, etc.

- Port represents a port on a Device. - Link represents a connectivity between Ports.

Each element has fixed basic attributes common across variant of its kind. (e.g., Port's portspeed). Additional information about elements can also be added as String-String annotations by each Providers. This mechanism should be used to add relatively read-heavy information specific to certain technology, domain.


42 | P a g e

9.4.2. Optical Information Model (Ports carrying extra attributes) - OduCLt port

Representation of ODU client port (Optical channel Data Unit). - Och port

Representation of OCh port (Optical Channel) - OMS port

Representation of OMS port (Optical Multiplexing Section) - OTU port

Representation OTU port (Optical channel Transport Unit)

9.4.3. Vertically Integrated ROADM model Following is vertically integrated ROADM used in the Packet-Optical demo at ONS2015,

represented using ONOS optical information model.

Image 27 [17] 9.4.4. Disaggregated ROADM model (a.k.a. OpenROADM)

Following is disaggregated ROADM (OpenROADM) used in the E-CORD/OpenROADM demo at ONS2016/OFC2016, represented using ONOS optical information model.

Image 28 [17]


43 | P a g e

9.5. Environment setup 9.5.1. Overview

One of the key drivers for this use case is that network designers can spin up a relatively large emulated packet-optical network on their personal computer, and develop applications without relying on a hardware optical network, which may be expensive and/or difficult to come by.

Mininet is the emulation tool that will create all network switches, links, and hosts. The forwarding behavior of the switches is controlled by ONOS using the OpenFlow protocol. The packet switches are based on Open vSwitch and use OpenFlow 1.0, while the optical switches rely on LINC-OE and use OpenFlow 1.3 (with vendor extensions as defined by the Optical Transport Working Group in ONF). [17]

9.6. Packet Optical Network Setup 9.6.1. Installation

The following are the necessary steps to install the required software to emulate a multi-domain network as described above. The setup assumed here is:

A host for emulating a multilayer network with Mininet and Linc-OE

One or more hosts running an ONOS instance each

A deployment host where the ONOS images are built, and deployed from, onto the ONOS hosts

A common way to realize the above is to host the Mininet and ONOS hosts as VM (or container) guests on the deployment host. The minimum requirement is that all hosts above be able to communicate with one another, and have Internet connectivity.

9.6.2. Mininet [19]

The steps here are based on the instructions for installing Mininet natively found at the mininet home address. [20] These instructions assume that the Mininet host runs Ubuntu 14.04, x86_64, and a user: password of mininet: mininet has been set up.

A. Install Required Packages

$ sudo apt-get update $ sudo apt-get install erlang git-core bridge-utils libpcap0.8 libpcap-dev

libcap2-bin uml-utilities curl vlan

B. Patch and Install Mininet. This is required to connect the CPqD switches to

multiple controllers from Mininet.

http://openvswitch.org/

https://github.com/FlowForwarding/LINC-Switch

https://www.opennetworking.org/


44 | P a g e

$ cd $ git clone git://github.com/mininet/mininet $ cd mininet $ wget 'https://wiki.onosproject.org/download/attachments/4164175/multi_controller.patch?version=1&modificationDate=1443649770762&api=v2' -O multi_controller.patch $ git apply multi_controller.patch $ sudo ./util/install.sh -3fnv # role back CPqD to a version known to work $ cd $ cd ~/ofsoftswitch13/ $ make clean $ git reset --hard 8d3df820f7487f541b3f5862081a939aad76d8b5 $ sudo make install $ cd $ sudo mn --test pingall # this should work

C. Install Linc-OE

$ cd $ git clone https://github.com/FlowForwarding/LINC-Switch.git linc-oe $ cd linc-oe $ sed -i s/3000/300000/ rel/files/vm.args $ cp rel/files/sys.config.orig rel/files/sys.config $ make $ cd $ git clone https://github.com/FlowForwarding/LINC-config-generator.git $ cd LINC-config-generator $ cp priv/* . $ make

D. Here we configure an ONOS development environment. This is required for the Linc-OE portion of the network emulation.

$ cd $ git clone https://github.com/opennetworkinglab/onos $ printf '%s\n' '. onos/tools/dev/bash_profile' >> .profile $ . .profile

E. To be more convenient for us, we can set-up a cell and set the OC variables to the clusters IPs.

vicell -c optical export ONOS_NIC=192.168.64.*

export OC1="192.168.64.45" # ONOS instance 1



export OCI=$OC1 # default instance set to instance 1

https://wiki.onosproject.org/download/attachments/4164175/multi_controller.patch?version=1&modificationDate=1443649770762&api=v2%27

https://wiki.onosproject.org/download/attachments/4164175/multi_controller.patch?version=1&modificationDate=1443649770762&api=v2%27

https://github.com/opennetworkinglab/onos


45 | P a g e

9.6.3. ONOS A. The first thing we need to do here is follow Paragraph 7. When we are

done with the installation there, we can continue with the following installation

B. Get ONOS and sample application sources and build them. [17]

$ git clone https://github.com/opennetworkinglab/onos $ cd onos $ mvn install -DskipTests -Dcheckstyle.skip $ cd .. $ git clone https://github.com/opennetworkinglab/onos-app-samples $ cd onos-app-samples $ mvn install

C. Create and apply a cell environment for the ONOS cluster as in Step 5 of

the previous section. It should specify onos-app-optical and onos-app-proxyarp (or onos-app-fwd) as a required applications by exporting the value ONOS_APPS. [17]

# Another cell called 'optical' created with vicell export ONOS_NIC=192.168.64.* export OC1="192.168.64.45" # ONOS instance 1 export OC2="192.168.64.46" # ONOS instance 2 export OC3="192.168.64.47" # ONOS instance 3 export OCI=$OC1 # default instance set to instance 1 export ONOS_APPS="drivers,drivers.optical,openflow,proxyarp,optical"

9.6.4. Deployment

Deploy the ONOS instance(s). From the deployment host: After building the ONOS package with onos-package, or its shorthand, op, deploy the

image onto the ONOS hosts. If multiple cells exist, the following must be repeated for each cell. [17]

$ cell optical $ onos-install -f


46 | P a g e

Start the network emulation. The ONOS source tree comes with two example scripts that create a multi-layer topology. These can be found inonos/tools/test/topos/ and are called opticalTest.py and opticalTestBig.py. Try running either; For example, to create spawn a large packet-optical topology, run the following command (note the -E parameter passed to sudo which preserves the environment variables) from the Mininet host:

$ cell optical $ sudo -E python onos/tools/test/topos/opticalTestBig.py $OC1 $OC2 $OC3

The above command uses the three ONOS instances defined in the cell file that has

been set up and applied in the Mininet environment. Specifically this ensures that all switches (both packet and optical) will be configured to use the listed instances as their OpenFlow controller(s). [17]

If, for some reason, the script fails to inject the optical topology in ONOS, onos-topo-

cfg can be used to manually push the topology file generated by the script:

$ ~/onos/tools/test/bin/onos-topo-cfg $OC1 Topology.json $ # Or alternatively, manually against the network config system API e.g. using `curl` $ curl --user onos:rocks -X POST -H "Content-Type:

application/json" http://192.168.56.111:8181/onos/v1/network/configuration/ -d @Topology.json

9.6.5. Verification To check if we did everything correctly, we can use the following link on our browser

$ OC1/onos/ui If we get an error, we might have to change some properties in the opticalUtils.py and in

the bash_profile. The ONOS_WEB_USER and ONOS_WEB_PASS variables in bash_profile should get the

following values: ONOS_WEB_USER =karaf, ONOS_WEB_PASS=karaf. The REST_USR and REST_PW variables in opticalUtils.py should get the following values:

REST_USR=karaf and REST_PW=karaf


47 | P a g e

9.7. LINC Console

You can attach to the console of a running LINC instance as follows:

$ sudo linc-oe/rel/linc/bin/linc attach

In the LINC console, the following commands are available. Please note that Erlang is very picky regarding syntax, so make sure you are not missing any spaces or the dot ('.') at the end of each command. [17]

Command Description

rp(application:get_all_key(linc)). With this, we can get the running configuration

linc_logic:get_datapath_id(SwitchId). With this command, we can get the DPID (DataPath ID)

linc:stop_switch(SwitchId). With this command, we can stop a logical switch

linc:port_down(SwitchId, PortId). With this command, we can Disable a port

linc:port_up(SwitchId, PortId). With this command, we can Enable a port

linc:ports(SwitchId). With this command, we can List the ports on logical switches

linc_us4_oe_flow:get_flow_table(switchId, tableId).

With this command, we can get the flow table of the logical Switch (use tableId 0)

9.8. Monitoring CpQD nodes The CO fabric is emulated with CpQD software switches, since OpenvSwitch doesn't

support some features needed by the fabric. Under certain conditions, CpQD nodes may fail silently, removing its UNIX socket file(s) from /tmp/ and becoming unresponsive. For a node named leaf101, the files are named leaf101 and leaf101.listen, the former being the control channel socket, the latter, the datapath listen socket. Attaching to a CpQD port with tcpdump seems to increase the chance of silent failure. Therefore, it seems best to monitor CpQD nodes from its logging system, by piping debug output for its packet processing modules to i.e. syslog:[19]

#within the script that is build()ing the topology self.addSwitch('leaf101', cls=UserSwitch, dpopts=current_opts+' --verbose=<VLOG_MODULE>:SYSLOG:DEBUG')

9.9. Static BGP Routes Running the BGP router application requires you to configure and run a local BGP

speaker (e.g., Quagga). To eliminate this, we created the option to inject static routes directly into the app. [19]

First, deactivate the running BGP router application, and its router component. The order is important here, unless you like exceptions in your logs. [19]

onos> scr:deactivate org.onosproject.bgprouter.BgpRouter onos> scr:deactivate org.onosproject.routing.impl.Router


48 | P a g e

Then activate the static router component, after which you can reactivate the BGP router app. Again, note the order. [19]

onos> scr:activate org.onosproject.routing.impl.StaticRouter onos> scr:activate org.onosproject.bgprouter.BgpRouter

From now on, you can inject static routes into ONOS as follows. The arguments to the

add-route call are (1) the routing prefix, (2) the next hop's IP, and (3) the next hop's MAC address. For instance: [19]

onos> add-route 12.1.1.0/24 192.168.101.1 00:00:C0:A8:65:01

Be careful though, as the static router component currently does not implement the

full RoutingService interface. This means that, for instance, the routes command will not work. [19]

9.10. We will not have the opticalUtils.py in this paper. We can see the file in the following link: https://github.com/opennetworkinglab/onos/blob/master/tools/test/topos/opticalUtils.py

9.11. Optical Intents [21] 9.11.1. Overview of Optical Intents

One of the key requirements for the converged packet/optical use case is the ability to set up connectivity across a network composed of two layers. The applications that are part of this (and the E-CORD) use case rely on callbacks from the Intent subsystem, and optical Intents and Intent compilers for setting up cross-layer paths.

9.11.2. Path Setup The diagram below summarizes the actions associated with path setup, and the ONOS

components that it involves.

Image 29 [21]

https://github.com/opennetworkinglab/onos/blob/master/tools/test/topos/opticalUtils.py

https://github.com/opennetworkinglab/onos/blob/master/tools/test/topos/opticalUtils.py


49 | P a g e

The color convention follows those of the layering in ONOS (blue: applications, grey: core, red: southbound). Elaborating on the diagram above:

- The path provisioner (OpticalPathProvisioner) is the primary application responsible for initiating optical path setup, and listens for IntentEvents.

- Path calculation occurs twice (each time the Topology subsystem is touched).

- The compilers logically reside in the Intent Framework, and are responsible for transforming Intents from high-level Intents such as OpticalCircuitIntent, into installable Intents, like FlowRuleIntents.

To summarize, setting up connectivity in a multi-layer network involves the following steps:

- A user or application submits a Host-to-Host or Point-to-Point intent. - The Intent subsystem fails to find a packet path and broadcasts a FAILED

IntentEvent to its subscribers. - The optical path provisioner submits the appropriate optical Intents for the

missing portions of the path. - The optical Intents are processed into installable Intents by the optical

Intent compilers.

- The installation of the optical Intents allows the Host/Point Intents to be installed, resulting in the INSTALLED IntentEvent. [21]

9.11.3. Optical Intents and Compilers

As described in 9.4. Optical Information Model, there are several port types specific to the packet/optical and E-CORD use cases, and the different optical Intents handle these different port types. The port types in a multilayer path change at different points in the path. The following example illustrates the different port types identified by ONOS for a path across a simple Linc-OE -emulated network.

Image 30 [21] The blue nodes and orange links represent entities in the packet layer, and the pink nodes

and purple links, cross-connects and optical layer entities. A caveat with the port types shown above is that Linc-OE does not support OduClt ports, as hardware optical devices do; However, the fact that port types change with each link in the path remains the same.

As such, the path provisioner must choose the correct optical intent for each section of the path, based on the type of the ports that it finds. The logic can be found in getIntents(List<ConnectPoint>) in OpticalPathProvisioner.

The following are the current list of optical Intents available to use case -related applications, their description, and their type-specific parameters.

Now we can see some working intents and some intents that are developed. [21]


50 | P a g e

Name Description Syntax

OpticalCircuitIntent For links between two OduClt ports. Compiled into OpticalConnectivityIntents and FlowRuleIntents by the OpticalCircuitIntentCompiler.

ConnectPoint src, dst; OduSignalType signalType; boolean isBidirectional;

OpticalConnectivityIntent For links between two OCh ports. Compiled into OpticalPathIntents by the OpticalConnectivityIntentCompiler.

ConnectPoint src, dst; CltSignalType signalType; boolean isBidirectional;

OpticalPathIntent Future work

For explicitly selected path through the optical layer (Oms ports). Currently only generated by compilers. Compiled into FlowRuleIntents by the OpticalPathIntentCompiler.

ConnectPoint src, dst; Path path; OchSignalType signalType; OchSignal lambda; boolean isBidirectional;

9.12. We can see here the default topology in this paper. This is the topology that was developed by the ONOS developers and the name of this topology is opticalTest.py [21]

Image 31 Packet Optical [50]


51 | P a g e

9.13. Here, we can see the custom topology, called customPOtopo.py

Image 32 [50] In the previous image we can see how I have configured the packet-optical network

topology. It is a custom network that is intended to be similar to the one that is done in the Segment Routing part of this paper. The difference here is that we have the CORE routers from the Segment Routing part changed to Optical Routers in this part. The Optical routers work in the Optical Plane, and links between switches can only be as in Image 30.

The first thing that is done is adding the LINC Swiches. These switches use WDM to send packets, which is different than what IP switches use.

o1ann = { "latitude": 37.6, "longitude": -122.3, "optical.regens": 0 } O1 = self.addSwitch( 'SFO-W10', dpid='0000ffffffffff01', annotations=o1ann,

cls=LINCSwitch )

Here we can see that the first thing we do is input the position of the switch. We have

latitude, longitude. The next thing we do is to add the switch with its position, name, its ID, and type. After adding all the LINC Switches, the IP switches are added. We can see the addition

of the Packet Switch in the following command:

CHGR10= self.addSwitch( 'CHG-R10', dpid='0000ffffffff0001', annotations={"latitude": 37.6, "longitude": -122.3} )

Here we can see the name of the switch, the ID of the switch and the Position of the switch.

After this, we need to connect both the packet-optical and optical-optical switches. For this we use 2 types of links. The first type of link is between two LINC switches.

self.addLink( O1, O2, port1=20, port2=30, annotations={ "optical.waves": 80, "optical.type": "WDM", "optical.kms": 1000, "durable": "true" }, cls=LINCLink )

The second type of link is between Packet and LINC switch. For this, we use the

following command:


52 | P a g e

self.addLink( CHGR10, O1, port1=2, port2=10, speed1=10000, annotations={ "bandwidth": 100000, "optical.type": "cross-connect", "durable": "true" }, cls=LINCLink )

After adding the Switches and the links between them, we need to add the hosts. All

the hosts are connected to Packet Switches, and are not connected to any optical switch directly. The following commands shows us how host 1 is added and connected to switch CHGR10:

h1 = self.addHost( 'h1' ) self.addLink( CHGR10, h1, port1=1 )

To open the topology, we can use the following command:

sudo -E python opticalTest.py (<Controller IP>)+

Also, if we have only one controller, we do not to use the <Controller IP>, since it will

connect automatically to the only one available. This command serves for the case of more than one controller (which is not what is needed for this paper).

There are also left some instructions in the customPOtopo.py on how to add a new

host (if it is needed).

#self.addLink( CHGR10, h3, port1=X )

In Image 32, we can see that we have links from coperoptical, opticaloptical and

opticalcopper. But, if we try to ping, we will not be able to. This is because, even though we can see the links, the Controller and the Routers have not any knowledge of how to send them. So, what we need to do is create an intent which will show the routers how and where to send the packets.

Let’s take an intent that is from h1 to h2. As seen at 10.11.3. Optical Intents and Compilers, we can only have 2 types of intents. The third type of intent which gives us a greater power in controlling the path, is still in development.

In Image 34 we can see how the new intent creates a flow that enables hosts h1 and h2 to talk with one another.

To do this, we use the following command:

add-host-intent 00:00:00:00:00:01/None 00:00:00:00:00:02/None

If we write the command: onos> intents, we will get the following:

Image 33 [50] If we want to remove the intents, we can use the “remove-intent” command.


53 | P a g e

onos>remove-intent org.onosproject.gui 0x0 onos>remove-intent org.onosproject.optical 0x1

.

Image 34 [50]

9.14. Optical Path Provisioning 9.14.1. Overview

This page describes the details of optical path provisioner: functions of the module, internal structure, and how to use the module. If you only need to try the module, read 10.14.2. “How to use” section first. [16]

9.14.2. Functions

Main functions of optical path provisioner are listed below.

- Installation of optical connectivity o Based on the received request, optical path provisioner calculates

optical path between given two ports, and sets up the connectivity along the calculated path.

o Connectivity request consists from src port, dst port, required bandwidth and latency.

o For each optical path, provisioner assigns a unique ID (optical connectivity ID).

- Removal of optical path o Optical path provisioner removes an installed optical path.

- Notification of installation status o Optical path provisioner notifies the registered listeners the

installation status of optical path. For now, “installed” and “removed” events are notified. [16]


54 | P a g e

9.14.3. Path Setup Flow

Image 35 [16]

- Receive optical connectivity request - Calculate path - Considering available bandwidth - Reserve bandwidth along the path - Find optical cross connect points in the path - Create and install OpticalConnectivityIntent/OpticalCircuitIntent - Get notified all of intents installed - Notify listeners that path is established [16]

9.14.4. Path Removal Flow

Image 36 [16]

- Receive optical connectivity removal request - Find existing optical connectivity - Remove related optical intents - Get notified all of intents removed - Remove bandwidth allocations - Notify listeners that path is withdrawn [16]


55 | P a g e

9.14.5. How to Use - Build package

$ cd ~/onos/apps/newoptical

$ mci

- Run ONOS

$ op

$ ok clean

- Connect Devices Download https://raw.githubusercontent.com/akoshibe/ecord-topos/master/ectest.py and copy it to ~/onos/tools/test/topos/

$ sudo -E python ~/onos/tools/test/topos/ectest.py 127.0.0.1 127.0.0.1 127.0.0.1

- GUI: Open http://127.0.0.1:8181/onos/ui/ in web browser and Enter karaf/karaf for username/password.

- CUI

To add connectivity between port of:000000000000000b/ and of:0000000000000015/1, use CLI command as following.

onos> add-optical-connectivity of:000000000000000b/2 of:0000000000000015/1 1000000 1000

To remove installed connectivity with ID 1, use CLI command as following. [16]

onos> remove-optical-connectivity 1

10. PACKET-OPTICAL Tests 10.1. Packet-Optical Switch Failure

This test verifies basic connectivity using Segment-Routing via pingall, it should not fail. The test consists of:

1) Configure and Install ONOS 2) Start Mininet and Packet Optical network 3) Pingall

The test is executed using: 1) APPS= hostprovider, lldpprovider, optical-model, openflow-base, openflow, optical, fwd, drivers, drivers.optical, proxyarp, mobility

Topologies: - opticalTest.py (default topology) - opticalTestBig.py (default topology) - customPOtopo.py (custom topology)


56 | P a g e

10.2. Packet-Optical Sanity

This test verifies basic IP connectivity using Optical via pingall The test consists of:

1) Configure and Install ONOS 2) Start Mininet and check flow state 3) Pingall


The test runs for different topologies: - opticalTest.py (default topology) - opticalTestBig.py (default topology) - customPOtopo.py (custom topology)

10.3. Packet-Optical ONOS Failure

This test verifies basic control plane resilience from an ONOS Instance failure using Packet-Optical via pingall.

It consists of:

1) Configure and Install ONOS 2) Start Mininet and check flow state 3) Pingall 4) Induce a ONOS failure 5) check flow state 6) Pingall



10.4. Packet-Optical Dynamic

This test verifies connectivity in face of dynamic configuration and Onos failures using Packet-Optical use case

It consists of:

1) Configure and Install ONOS 2) Start Mininet and check flow state 3) Connectivity test 4) Add Optical Link 5) Connectivity test 6) Onos Failure 7) Remove Optical Link

The test is executed using:


57 | P a g e

1) APPS= hostprovider, lldpprovider, optical-model, openflow-base, openflow, optical, fwd, drivers, drivers.optical, proxyarp, mobility


We can see here that the tests have 100% success rate. This is because the Packet Optical Tests are done in a newer and much more stable version of the ONOS Controller. Also, it is fair to say that the Packet-Optical Network or the Use-Case is much more flexible than the one of the Segment Routing. Adding or deleting a link or a node, does not give us any problems. In fact, adding a node in the Optical Layer gives us more opportunities for paths and can make the network less congested. Next, we have the charts from the tests results.

10.5. Packet Optical Tests Summary

Chart 3

Chart 4

0

1

2

3

4

5

6

Test 1 Test 2 Test 3 Test 4

Summary of Packet Optical Use Case Tests

Tests Planned Tests Failed Tests Succedded

0

1

2

3

4

5

6

Take 1 Take 2 Take 3 Take 4 Take 5

Summary of All Tests Taken Together

Tests Planned Tests Failed Tests Succeeded


58 | P a g e

11. Future Work 11.1. Future work on Segment Routing

For Segment Routing, in the future, there is a possibility for creating a bigger network that will be tested with a new number of tests.

Also, the Configuration of the network will be more in depth.

Another Future Work consists on creating this network using Real Hardware (Routers and Switches).

11.2. Future Work on Packet-Optical For the Packet-Optical Case, the future work is more specified.

First, we can make the Use-Case on a Real (Physical) Network, Using Physical Hardware (Routers and Switches).

Next, there is the possibility of configuring the Optical Layer. 1) Configuring the Optical Layer in a Static Way 2) Creating a specific Path that the packets will take in the Optical

Layer 3) Optical Router Configuration

11.3. Future work Using TestON [22] These tests demonstrate several simple actions using TestON. The test is

successful if all test cases succeed. - CASE0: Pulls ONOS code and builds ONOS. This is usually skipped in the

production environment for flexibility to handle testing different versions of ONOS

- CASE1: Sets up global test variables and removes existing instances of ONOS in the test cell

- CASE2: Reports errors, warnings, and exceptions in ONOS - CASE10: Starts ONOS on the cell - CASE11: Start mininet and assign mastership of switches to ONOS

controllers - CASE12: Tests some basic ONOS commands using the ONOS cli handle - CASE22: Tests some basic ONOS commands using the REST API handle - CASE32: Configure fwd app and run pingall

12. Conclusion

We are witnesses of the high paced evolution of technology. In today’s world, we are not competing with other people for data, we are competing to be faster, easier, simpler, more reliable and with better accessibility. We have seen in this paper the power that Software Defined Networking has, even with a Controller that is still in an early stage of development.


59 | P a g e

As we have seen in this paper, the SDN’s using ONOS controller have a lot of advantages over other networks. But, also, there are a lot of disadvantages since the ONOS controller is still in development and a lot of the functionalities are not available. Software Defined Networking (SDN) is changing the way we build, design and operate the networks. We can see that, using SDN, the networks are no longer difficult to program, they are no longer closed and they are no longer marketed and protected by a company or a registered trade name.

Due to the inflexible nature of current transport networks, a great deal of spare packet and optical capacity is deployed to cover all possible failure points. This is combined with the need to support busy hour scenarios with overcapacity to minimize packet loss. Capacity planning and traffic engineering must consider all possible traffic load and failure scenarios because the optical network cannot be reconfigured at will. Furthermore, optical impairments are complex and require careful planning and traffic optimization practices. [23]

As seen and discussed before, the Segment Routing use case is revolved around a simple network. But as seen in the explanation of MPLS, we can scale up the network and we can have a lot of benefits from static configuration of the routes.

In the Packet Optical use case, we have seen one custom and one default small network, but there is a network test that have 75 optical and 17 packet switches. Even with this scaling up, the tests give the same results as in the smaller and more compact networks. This shows us that SDN is the right way to go and even if we scale up the networks, we will have optimal performances from the network.

The poor balancing characteristics of the RSVP-TE model do not fit the true nature of IP, which is based on networks offering abundant Equal-Cost Multi- Paths (ECMP). [24] With SR, traffic can be steered using forwarding constructs, which benefit from ECMP, so that a single SR tunnel configuration can capture a set of paths. Control-plane and data-plane scalability issues are caused by the state required at each hop along any explicit path. [25] This is a lot worse for merged networks that offer a large portfolio of services.

The RSVP-TE deployment model until now is based on distributed computation. This leads to unpredictable placement of the traffic, non-optimal use of the resources, and slow re-optimization [26]. This is why the IETF started works on standardizing an architecture aimed at fulfilling these requirements, called Segment Routing (SR) [27] [28] [29].

To support large production networks, a NOS has to meet demanding requirements for scalability, performance and availability. Based on discussions with network operators, and considering the use case of traffic engineering in service provider networks, we have identified several mutually challenging requirements: [30]

- High Throughput: up to 1M requests/second - Low Latency: 10 - 100 ms event processing - Global Network State Size: up to 1TB of data - High Availability: 99.99% service availability

We can see that the requirements are high, but the path that SDN is taking, and especially using the ONOS Controller, gives us a great hope that these requirements will be met and exceeded. [27] [28] [29]


60 | P a g e

13. References [1] Author: Bob Lantz, Welcome to ONOS, last modified on Dec 07, 2015; https://wiki.onosproject.org/pages/viewpage.action?pageId=2851517 Last accessed on 19/09/2016 [2] Segment Routing, Cisco, Clarence Filsfils, Cisco Fellow @ Cisco Systems, Kris Michielsen, Technical Leader Engineering @ Cisco Systems, November 2015 [3] The Segment Routing Architecture, Clarence Filsfils, Nagendra Kumar Nainar, Carlos Pignataro, Juan Camilo Cardonay, Pierre Francois, Cisco Systems, Inc. IMDEA Networks Institute / UC3M [4] Stefano Previdi, et al. IS-IS Extensions for Segment Routing. draftietf-isis-segment-routing-extensions-05. IETF Draft, 2015. [5] Peter Psenak, et al. OSPF Extensions for Segment Routing. draftpsenak-ospf-segment-routing-extensions-05. IETF Draft, 2014. [6] MPLS in Optical Networks, An analysis of the features of MPLS and Generalized MPLS and their Application to Optical Networks, with reference to Link Management Protocol and Optical UNI, Neil Jerram, [email protected], Adrian Farrel, [email protected], first issued October 2001 [7] Authors: Canonical Ltd., Title: Download Ubuntu Desktop, 2016; http://www.ubuntu.com/download/desktop Last accessed on 19/09/2016 [8] Authors: Canonical Ltd., Title: Download Ubuntu Server, 2016; http://www.ubuntu.com/download/server Last accessed on 19/09/2016 [9] Author: Ayaka Koshibe, last modified by Joe Falconer on Jul 11, 2016, ONOS from Scratch, https://wiki.onosproject.org/display/ONOS/ONOS+from+Scratch Last accessed on 19/09/2016 [10] Introducing ONOS - a SDN network operating system for Service Providers, Whitepaper by ON.Lab [11] SDN Control of Packet-over-Optical Networks, Marc De Leenheer ON.lab, Guru Parulkar Stanford University and ON.Lab, Tom Tofigh AT&T [12] https://wiki.onosproject.org/display/ONOS/Archived+Content%3A+VM+Tutorial Last accessed on 20/07/2016 [13] Author: 2016 GitHub, Inc.; Title: Segment Routing Test Examples, 2016 https://github.com/opennetworkinglab/OnosSystemTest/tree/master/TestON/tests/USECASE/SegmentRouting Last accessed on 19/09/2016 [14] Author: Jenkins Technical User, Title: SR Switch Failure, 04/09/2016; https://wiki.onosproject.org/display/ONOS/1.6+-+SR+Switch+Failure Last accessed on 19/09/2016 [15] Author: Jenkins Technical User, Title: SR Link Failure, 04/09/2016; https://wiki.onosproject.org/display/ONOS/1.6+-+SR+Link+Failure Last accessed on 19/09/2016 [16] Author: Naoki Shiota, Title: Optical Path Provisioner; 18/07/2016; https://wiki.onosproject.org/display/ONOS/Optical+Path+Provisioner Last accessed on 19/09/2016 [17] Author: Ayaka Koshibe, Title: Packet Optical Convergence, 14/04/2016; https://wiki.onosproject.org/display/ONOS/Packet+Optical+Convergence Last accessed on 19/09/2016

https://wiki.onosproject.org/pages/viewpage.action?pageId=2851517

mailto:[email protected]

mailto:[email protected]


http://www.ubuntu.com/download/server

https://wiki.onosproject.org/display/ONOS/Archived+Content%3A+VM+Tutorial

https://wiki.onosproject.org/display/ONOS/Packet+Optical+Convergence


61 | P a g e

[18] Author: Yuta Higuchi,Title: Optical Information Model, 31/03/2016; https://wiki.onosproject.org/display/ONOS/Optical+Information+Model Last accessed on 19/09/2016 [19] Author: Ayaka Koshibe, Title: Packet Optical Dev Environment, 27/05/2016 https://wiki.onosproject.org/display/ONOS/The+Packet+Optical+Dev+Environment [20] Authors: Mininet Team, Title: Download/Get started with Mininet, 2016; http://mininet.org/download/ Last accessed on 19/09/2016 [21] Author: Ayaka Koshibe, Title: Optical Intents, 01/04/2016; https://wiki.onosproject.org/display/ONOS/Optical+Intents Last accessed on 19/09/2016 [22] Author: Kelvin Flores, Title: TestON Files, 28/01/2016; https://wiki.onosproject.org/display/ONOS/TestON+Files Last accessed on 19/09/2016 [23] Author: ONOS, Title: Global ONOS and SDN-IP deployment, 2015; http://onosproject.org/wp-content/uploads/2015/06/PoC_global-deploy.pdf Last accessed on 19/09/2016 [24] R. Shakir. Spring Forward(ing) - Evolving IP/MPLS Networks with Segment Routing. In UKNOF27. 2014. [25] Seisho Yasukawa, et al. An Analysis of Scaling Issues in MPLS-TE Core Networks. IETF RFC 5439, 2009. [26] C. Filsfils. Segment Routing: Update and Future Evolution. In MPLS SDN World 2014. 2014. [27] IETF. Source Packet Routing in Networking (spring) Working group. https://datatracker.ietf.org/wg/spring/charter/, 2013. [28] Thomas D Nadeau et al. SDN: Software Defined Networks. O’Reilly Media, Inc., 2013. [29] Clarence Filsfils, et al. Segment Routing Architecture. draft-ietf-springsegment-routing-01. IETF Draft, 2014. [30] ONOS: Towards an Open, Distributed SDN OS; Pankaj Berde, Matteo Gerola, Jonathan Hart, Yuta Higuchi, Masayoshi Kobayashi, Toshio Koide, Bob Lantz, Brian O’Connor, Pavlin Radoslavov, William Snow, Guru Parulkar, Open Networking Laboratory, USA NEC Corporation of America, USA Create-Net, Italy [31] Segment Routing MPLS Data Plane, Cisco, Clarence Filsfils, Cisco Fellow @ Cisco Systems, Kris Michielsen, Technical Leader Engineering @ Cisco Systems [32] Authors: WikiHow team, Title: How to install Ubuntu on Virtual Box, 2016; http://www.wikihow.com/Install-Ubuntu-on-VirtualBox Last accessed on 19/09/2016 [33] Authors: PuTTy Team, Title: PuTTY Download Page, 10/03/2016 http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html Last accessed on 19/09/2016 [34] Author: Daniel Butler, Title: How to install Ubuntu, The Ubuntu Installation Guide, 2016; https://builtvisible.com/the-ubuntu-installation-guide/ Last accessed on 19/09/2016 References for images: [50] Images are taken from screenshots from my PC [51] Author: Administrator, Title: Wiki Home, 26/07/2016; wiki.onosproject.org/display/ONOS 19/09/2016 [52] Author: Jenkins Technical User, Title: Segment Routing, 07/07/2016; https://wiki.onosproject.org/display/ONOS/1.6-Segment+Routing Last accessed on 19/09/2016

https://wiki.onosproject.org/display/ONOS/The+Packet+Optical+Dev+Environment

http://mininet.org/download/

http://www.wikihow.com/Install-Ubuntu-on-VirtualBox

http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html

https://builtvisible.com/the-ubuntu-installation-guide/

https://wiki.onosproject.org/display/ONOS/1.6-Segment+Routing

Documents

POLITECNICO DI MILANO using ONOS Controller.pdfSDN using ONOS Controller Slave Mitev Politecnico di Milano, 2016 2 | P a g e can do with ONOS, and software written to run on ONOS,