PATHLET ROUTING SOURCE CODE There are two packages of code, available at: http://www.cs.illinois.edu/~pbg/pathlets/ You should be aware of a warning up front: The code was research code, and remained as such, and may be quite messy. (1) Simulator from the SIGCOMM 2009 paper. Some notes from Igor Ganichev, author of the simulator: The simulator uses networkx 0.99 (later versions won't work) and twisted (I am not sure which versions it works with, but it should work with whatever was the current version back in late 2008). The configuration file format is stupid and has a lot of unused info (was designed very early in the process and did not change). So, don't try to look for logic if it seems stupid because it is stupid. There are a lot of src files that are not used for the same reason as above. First, you will need to install twisted. The main src file is pl_router.py. It starts one router. There is a script pl_start.py which I used to start many routers. If you just run it from its directory, it will start 5 routers using a small topology. Look into the file for details on how to start routers individually. I included some scripts that you might find useful. There is a single configuration file and all routers read it and get info relevant to them. You will need to understand twisted a little bit to understand some of the code. This is a figure in the sigcomm paper showing the structure of the implementation. (2) Adaptive routing demo in GEC 9, October 2010. In this demo, we showed a client streaming a video between two servers on either coast of the United States. The sender had access to two paths, and could either stream down both simultaneously, or switch adaptively, to respond to failures. The video stream would then continue without interruption. The multiple paths were implemented by a prototype version of pathlet routing's data plane, implemented on OpenFlow in the GENI network. However, as you will see, the most useful code in this package is probably the code written by Ashish Vulimiri, which does adaptive path-switching underneath arbitrary unmodified Linux applications (via the Tun utility). Details follow. The multiple paths were implemented by a prototype version of pathlet routing's data plane, implemented on OpenFlow in the GENI network. However it was a somewhat crippled prototype. This was because (1) the OpenFlow switches available in GENI at the time did not support fast-path in-flight modification of packets, such as pushing and popping forwarding identifiers, and (2) only a limited number of packet fields were available to co-opt into using as a source route. The solution adopted used a fixed identifier stuffed into the source port. This identifier was a compact list of forwarding identifiers, pre-pended with an identifier of the starting location in the network (i.e. the sending host). This information was enough to uniquely identify the end-to-end path and use static flow table entries for forwarding at each hop. So, you might say this is less like pathlet routing and more like a simple static multipath setup. The OpenFlow controller itself is not included in this package. There is a controller 'front-end' written in Perl, which was then attached to the controller itself using code not included here. The more useful code in this package is probably the adaptive routing code and application-level setup written by Ashish Vulimiri, which does adaptive path-switching underneath arbitrary applications. Below are notes from Ashish. In the archive, pathlet_openflow_controller contains the controller code, and is probably the only directory you need. Brighten's included some documentation, but let me know if you have any questions about the code. The others are: openflow-multistream: adaptation agent running at the source node. Keeps probing all available paths and maintains a score indicating the "best" path at any time. openflow-multistream-controller: management code to configure e.g. which algorithm openflow-multistream uses to compute path scores. tunnel-multistream: TUN code, intercepts packets on the source node and forwards them along the best path according to openflow-multistream.