Ethernet-based Self-Learning using SDN Controller Solution

In this project you will learn how to use Mininet to create virtual networks and run simple experiments.  You will also learn about  the SDN Controllers  and OpenFlow protocol.  There are 4 sections in this programming assignment.  Please read the description and requirements carefully.

 

 

1    Design

 

 

The topology in Figure 1 has three hosts h1, h2, and h3 connected to switch s1. The switch is connected  to the controller  c0. Switch s1 maintains  a flow table  which contains  match- action rules that  are are added/removed/updated by the controller.  At the beginning, there are no rules installed  in the flow table.  When packets are sent by hosts to one another,  the controller extracts  information from these packets and builds certain internal  data structures (such as a hashmap, etc.)  to represent the topology.  The controller  will use these internal data  structures to decide what rules should be installed  in the switch’s flow table.

 

 

Controller c0

 

 

 

port #


Switch s1

 

1                  3

2

 

 

 

 

h1                h2              h3

 

 

Figure 1: Figure for Section 1

 

 

As an example, consider host h1 wants to send a packet to h2. When switch s1 receives this packet from h1, it checks if there is any corresponding match-action rule (or flow entry) for this packet  in its flow table.  If there  is no entry,  the switch will encapsulate  the packet and  send it inside as an OFPacketIn message to the  controller  c0.  On the  other  hand,  if

there  is a flow entry,  switch s1 will execute the action  associated  with the  rule.  However, as discussed earlier, the flow table is initially empty.  Therefore,  the switch will forward the packet to the controller.

When the controller receives the OFPacketIn message from switch s1, a packet-in event is triggered.  Two tasks are performed due to a packet-in  event:  1) using the information  from packet headers/event, the controller  may update  its internal  state  (e.g.  it learns something new about  the topology),  2) using the internal  state,  it makes a decision on what  action(s) s1 should take  to send this packet  to h2. If the controller  knows what  interface  s1 should forward the packet to, it will inform s1 and also install a flow entry which could be used for future  packet  transmissions  of similar kind.  If the controller  does not know what  interface s1 should forward to, then it will instruct  the switch to flood the packet to all the interfaces except the one. This flooding instruction  is a one-time action without  installing any rules in the switch.

Your task is to come up with an Ethernet-based self-learning algorithm  at the controller that  does not unnecessarily  flood packets.  More specifically, you need to decide what  kind of internal  data  structures should be maintained  by the controller to represent the topology and  later  make  decisions on how to  forward  packets.   These  internal  data  structures are populated  by the controller by extracting  information from the packet-in events (e.g. packet headers).

Name your submission file as q1 pseudo code.txt – it should include:

 

1. Detailed information  of the data  structures and its purpose.

 

2. Pseudo code which specifies how your algorithm works, how the internal data structures are used and  updated,  which fields from the  packets/events are used by your logic. Please be clear, concise and explicit!

 

HINT: Try to test your algorithm under multiple scenarios  such that the controller is able to learn the whole topology quickly without unnecessarily  flooding packets.  For example, one such scenario  could be h1 sends a packet to h2, then h2 sends a packet to h1, then h3 sends a packet to h1. Another direction  to think about is if your algorithm should be source-based, destination-based, or a combination  of multiple packet header fields.

 

 

2    Implementation

 

 

In this section, you should implement a controller module that  uses the same algorithm/pseudo code that  you proposed in the  earlier section.  However, we will test  it on a new topology (see Figure 2 for topology).  Note, if your proposed algorithm  in the previous section is cor- rect, it should work for this new topology as well without  any modification.  A Mininet-based Python  script (proj3 topo.py) is provided which constructs  the required topology.  For your implementation, you can either  use Python-based POX controller  or Java-based  Floodlight controller.

Controller c0

 

 

 

 

 

 

 

 

s1                 s2                   s3   3


 

2               h6 s4

3             1

h5

3        2           3              2

L1                            L2                                                 s5

1      2                     1                           1

4            3

 

1    2

h9 h1       h2           h3                 h4                 h7

h8

 

Figure 2: Figure for Section 2

 

 

• POX Controller: To run your module in POX, you should put ethernet learning.py file in the directory pox/pox/samples. You will then run the controller and your mod- ule using the following commands:

you@yourmachine$ cd pox

you@yourmachine$ ./pox.py samples.ethernet learning

 

• Floodlight Controller: To run your own module in Floodlight, put EthernetLearning.java

file in src/main/java/net/floodlightcontroller/ethernetlearning/ .

 

We need to tell Floodlight  to load the  module on startup.  First  we have to tell the loader that  the module exists.  This is done by adding the fully qualified module name on it’s own line in src/main/resources/META-INF/services/net.floodlightcontr- oller.core.module.IFloodlightModule.  We open that  file and append  this line to the file: net.floodlightcontroller.ethernetlearning.EthernetLearning

 

 

Then we tell the module to be loaded.  We modify the Floodlight module configuration file to append the EthernetLearning module. The default one is src/main/resources/ floodlightdefault.properties.  The key is floodlight.modules and the value is a comma separated  list of fully qualified module names.

 

floodlight.modules = <leave the default list of modules in place, net. floodlightcontroller.ethernetlearning.EthernetLearning

Proceed with re-building the controller using: you@yourmachine$ cd floodlight/target you@yourmachine$ ant

Finally,  run  the  controller  by using the  floodlight.jar file produced  by ant from within the floodlight directory:

 

you@yourmachine$ java -jar target/floodlight.jar

 

Floodlight will start  running  and print log and debug output  to your console.

 

 

 

3    Link Latency and Throughput

 

 

After completing  Section 2, consider the  same topology in Figure  2.  The  names of hosts, switches and the controller in Mininet match as depicted in the figure. The hosts are assigned IP  addresses 10.0.0.1 through  10.0.0.9; the last  number  in the  IP  address  matches  the host ID. Link labels are depicted  in Figure  2.  To run Mininet  with the provided  topology (written  in a Python  script proj3 topo.py) using sudo privileges:

sudo python proj3 topo.py

To answer this section, you are allowed to use tools such as ping and iperf.

Is it  possible for you to  estimate  the  throughput and  latency  of individual  links between switches, viz, L1, L2, L3 and L4? If your answer is yes, please provide the estimated  through- put  and latency  for each of the  four links and describe the  process in estimating  them.   If your  answer  is no, then  justify  your  response.   Feel free to  state  any  reasonable  assump- tions  you want  to  make  in answering  this  section.   Write  your  response  in a file named q3 topo response.txt and if there are any other supplementary files you would like to sub- mit,  please name such files with q3 topo as prefix along with a descriptive  file name (e.g. q3 topo <DescriptiveFileName.<extension).

 

 

4    Building your own  Topology

 

 

As shown in Figure  3, data  center  networks  typically have a tree-like topology.  End-hosts connect to top-of-rack switches, which form the leaves (edges) of the tree; one or more core switches form the root; and one or more layers of aggregation switches form the middle of the tree.  In a basic tree topology, each switch (except the core switch) has a single parent switch. Additional  switches and links may be added to construct more complex tree topologies (e.g., fat  tree)  in an effort to improve  fault  tolerance  or increase inter-rack  bandwidth.  In this section, your task is to create a simple tree topology by updating  the skeleton code provided in the  q4 tree topo.py file.  You will assume  each level i.e., core, aggregation,  edge and host to be composed of a single layer of switches/hosts.

For creating  this topology, you should consider that  links at  the same levels have some specified performance parameter. For example, all links between hosts and edge switches will have the same predefined performance parameter. Here there are 3 types of links, the links between  core and  aggregation  switches,  the  links between  aggregation  and  edge switches, links between edge switches and host.  Your logic should support  whatever  bandwidth and

 

 

Figure 3: Figure for Section 4

 

 

delay parameter you set for each link.  The  parameters are given in the  q4 tree topo.py file. After building your topology, try pinging all hosts to see if the connections are working. Store the output to q4 tree topo output.txt file. Submit  both  the files for this section – q4 tree topo.py and q4 tree topo output.txt.

 

 

Methods you need in creating  and testing  a topology:

 

• Topo: the base class for Mininet topologies

 

• addSwitch(): adds a switch to a topology and returns  the switch name

 

• addHost(): adds a host to a topology and returns  the hostname

 

• addLink(): adds a bidirectional  link to a topology (and returns  a link key, but this is not important). Links in Mininet are bidirectional  unless noted otherwise.

 

• Mininet: main class to create and manage a network

 

• start(): starts  your network

 

• pingAll(): tests  connectivity  by trying to have all nodes ping each other

 

• stop(): stops your network

 

• net.hosts: all the hosts in a network

 

• dumpNodeConnections(): dumps connections to/from a set of nodes.

 Setting up  the Environment

 

We recommend two ways to install the experiment testbed.

 

 

1. Setting up  a Virtual Machine (VM) on  your local/personal machine

This is the easiest and fastest way to get started as this VM will have all the necessary software/tools installed.

 

• You can download the VM using the following link: Link: https://z.umn.edu/csci4211s18proj3vm

• You will find Mininet-VM.ova file downloaded.

 

• You can use any virtualization system of your choice, but we recommend installing VirtualBox.    It  is free and  runs  on  Windows,  Linux  and  macOS.  VirtualBox Download Link: https://www.virtualbox.org/wiki/Downloads (we have tried and tested on the latest version of Virtual  Box 5.2.8)

 

• Install  Oracle VM VirtualBox  and start  it.

 

• In the File menu, select Import Appliance.

 

• The Appliance Import  wizard is displayed in a new window.

 

• Click Choose, browse to the  location  containing  Mininet-VM.ova file, and click

Open, and click Continue.

 

• The Appliance Import  Settings  step is displayed.

 

• Click Import and then  select the imported  virtual  machine.

 

• Click the Start button.

 

• If you get a prompt to change the network settings, click Change Network Settings.

It should open up a window with the network adapter  settings.  We recommend you to set “Attached to” parameter to Bridged Adapter  and set “Name” to the network interface that  you use to connect to the Internet. Then click OK.

• The VM may take sometime to boot up.  Login credentials  to the VM:

username: mininet

password:  mininet

 

• You are all set, enjoy!

 

2. Connect to a VM  installed in  CSE Lab  machines

You can use virtual  machines  that  are spread  across a cluster  of network-accessible machines run by CSE Labs.  Send an email to the varya001@umn.edu with your group number  requesting  access to a remote  VM. You’ll get a reply with unique passwords for your group to access the remote VM along with the instructions of how to connect to it.

 What to Submit?

You should upload the project  files to the Moodle site.  Your submission should be one zip file using the format groupID project3.zip (e.g. group3 project3.zip for Group 3). This file should contain  the following:

 

1. q1 pseudo code.txt

 

2. For POX based code - ethernet learning.py

For Floodlight based code - EthernetLearning.java

 

3. q3 topo response.txt and other supplementary files for Section 3.

 

4. q4 tree topo.py

q4 tree topo response.txt

 

5. README or comments you would like the TA to know.