CSE561 Problem Set #1

out: Tuesday October 8th, 2013
due: Monday October 28th, 2013 by 5:00pm.

[ summary | background | tutorials | assignment | turn-in | grading | solution ]

Summary

Software-Defined Networking (SDN) refactors the network control plane to enable programmatic control of packet forwarding and increase network flexibility. Instead of having a switch-resident control plane define a forwarding (or routing) information base (e.g., using RIP, OSPF, etc.), the forwarding information base used by each switch's data plane is established by applications running atop a logically centralized SDN controller. These applications operate on a (abstract) view of the network topology to define the forwarding behavior of each (virtual) network switch. The controller translates these directives into forwarding rules which are installed in a flow table at each physical switch. The data plane in each switch matches packets against the rules in the flow table (based on fields in the Ethernet, IP, and transport headers) and the actions (forward, flood, drop, etc.) defined in the matching rule are applied to the packets.

These SDN projects will expose you to how to write SDN applications to achieved some desired control over the forwarding behavior of a network. You will be introduced to OpenFlow (the current industry-wide standard for SDN), common SDN controllers (POX and Floodlight), tools for testing and debugging applications, and the typical software and hardware components included in an actual SDN deployment. Using this knowledge, you will be able to develop several SDN applications that implement basic control over network forwarding and leverage the key capabilities exposed by SDN controllers.

Background material

The two key technologies that we will use in the projects are: (a) OpenFlow: a standardized API that exposes routing/switching functions to a controller, and (b) centralized network controller written using Floodlight or POX that allows you to install appropriate rules in the switches using the OpenFlow API. We will discuss some of this material in class, but there is a wealth of information available on the Web that you can read up on in order to get the context for this work. Here are some such links:

Tutorials

You will be using the Mininet VM based system developed by the OpenFlow group to do your assignments. For the controller, we recommend either Floodlight or POX. Here are some tutorials to install Mininet and start using it with Floodlight/POX.

Assignment

As part of the assignment, you will build a learning switch. You might find it useful to look at the Hub code for Floodlight. We also provide you a floodlight skeleton and a pox skeleton on top of which to implement your Learning Switch applications.

Application Design

We will develop a simple learning switch application which will handle the unicast traffic. The controller application will examine the packets and will learn the "source mac address" and "input port". If the destination of the packet is already associated with some port, a flow entry will be installed in the switch and the packet will be sent to the given output port, otherwise the packet will be flooded on all the ports.

Write Learning Switch Application

The learning switch learns the source mac address and the port of hosts from the packets it receive. Following is a naive algorithm for simple learning switch application:
if (source mac address is new)
    record the source mac and input port mapping
if (destination mac address is known)
    install a flow table rule
    forward the packet to the destination
else
    FLOOD the packet

Test Learning Switch Application

We assume that all of you have mininet and your favorite controller (you can have any controller as long as it's Floodlight or POX) on your machines. Launch Mininet with following command:
sudo mn --topo single,10 --mac --arp --switch ovsk --controller remote,ip=<host_ip> 
To test the performance of your switch applications, run a ping test and measure the average rtt latency.
mininet> h1 ping -c 10 h10
Next, run a throughput performance test as following:
mininet> h10 iperf -s &
mininet> h1 iperf -c h10
You should compare the performance of the hub and learning switch implementations in terms of rtt latency and throughput. What do you observe ? Why do you see such discrepancy among them ? Remember that you can use 'dpctl' command with 'dump-flows' option to see whether packets are hitting the rules, when is the case.
dpctl dump-flows tcp:127.0.0.1:6634 

Useful notes

Turn in instructions

Please turn in a tarball or a zip file at https://catalyst.uw.edu/collectit/dropbox/summary/arvindk/29361.
The archive should have following files:

Grading

We will be basing your grade on several elements:

Solution

Learning Switch: FloodLight, Pox