|Table of Contents|
The goal in this tutorial is to construct a shortest path forwarding application on top of POX. In _/pox/ext/routing/_ you will find a file named routing.py. This file is a skeleton of the entire applications. So, clearly the idea is to complete the holes. There are many comments in the code which should guide you throughout the entire process. On top of the comments, this document is intended to give you more hints about each area that needs to be completed. Each which needs to be completed is labelled TODO followed by a number, we will refer to these labels in this document. Note: That the TODO items are in no particular order other than the order they appear in the code, ie. The TODO number does not signal an ordering of the completion of one or other item. Also, feel free to inspect the code before starting the exercise and ask any questions you may have.
As for the API used in POX, refer to the POX manual here for more information.
Starting Mininet and POX
To start mininet, run the following command in your terminal:
openflow@TutorialVM:~/coder$ sudo mn --custom eth-topo.py --topo eth-topo --mac --controller=remote
The sudo password is *********.
In another terminal, start POX:
openflow@TutorialVM:~/coder$ cd pox openflow@TutorialVM:~/coder/pox$ ./pox.py --no-cli openflow.discovery routing.routing
Topology used during this exercise.
Areas to complete
Handling Switch connection (TODO 1)
When an OpenFlow switch boots up and is configured properly, it attempts to connect to a controller. In this section we are going to handle these incoming connections, by storing a reference to the connecting switch so that we can later send that switch messages. Also this may be a good place to initialise variables that are going to be needed on a per switch basis.
Flooding (TODO 2)
The idea here is to construct a function that is able to flood packets at the network edge i.e. not on the switch to switch links. This sort of flooding is done to avoid broadcasting of our core network where there may be loops. Also, at this point your controller does not know where a particular hosts lives and therefore we must relay a message at every network edge to make sure the destination see it. Have a look at the switch class (on line 257), it contains code that will partially do this but it needs some input, namely a list of switch to switch links.
Constructing and sending an ARP reply (TODO 3)
At this point, you controller has probably resolved the ARP request on its own since it previously memorised a host MAC and/or IP address. So rather than forwarding an ARP request to its recipient, you controller should construct the ARP reply and send it straight back to the sending host.
ARP learning (TODO 4)
In order to speed things up and also forward IP packets around the network, we need to build ourselves an ARP table. This is probably a good location to add entries to such a table.
Handling ARP requests (TODO 5)
Upon receiving an ARP request, your controller should verify whether it can fulfil this request itself or if the request should be forwarded to very host in the network.
ARP/IP re-learning (TODO 6)
This is subtle point when using OpenFlow enabled networks. First, the requirement to re-learn the location of end-hosts when dealing with IP packets originates from the fact that if the end hosts already know the MAC address of their desired destination, they will start sending IP packets directly. Unfortunately, but this time you controller has no idea where your end-host sits and therefore will flood the packet. If no learning occurs at this stage the behaviour of the network is unaffected by communication latency is severely impacted. Once your controller is working, run it with and without this section and observe the effects.
Installing flowtable rules (TODO 7)
Depending on whether your controller knows where the destination is, it should install the rules for this flow of flood the packet. The actual act of installing the rules will be done by the install_path function a few lines below.
Constructing a match object (TODO 8)
When installing rules on an OpenFlow network, you need to specify which headers your rule should match on. Fortunately, this can be done automatically from a packet in object. See the POX WIKI for more details.
Destination on same DPID (TODO 9)
If the destination is on the same DPID then it should be pretty straight forward to install the rule give that you only need to install the rule at one switch/DPID.
Destination on remote DPID (TODO 10)
In order to avoid having PacketIns for every switch/DPID on the path to the destination, you should probably install rules from the destination to the source (i.e. in reverse order). This will involve computing the DPIDs on the path and the port pairs they will be travelling through. Fortunately, each switch object maintains a paths variable which provides the entire path to every destination.