The SOS controller is considered beta quality and is still under active development. 

Downloading, Installing, and Running

The SOS controller is hosted on GitHub as a special extended version of Floodlight and can be cloned using git. In a Linux terminal, get the source code:

Then, install any Floodlight prerequisites:

After the prerequisites are installed, change directories into the cloned repository, and build the controller:

If you would like to develop or run the controller within Eclipse, refer to these instructions.

To kill the controller (e.g. to stop and restart it), which is simply a Java process, use your favorite way of killing processes.

Playing with the Source Code

All source code for SOS can be found in the net.floodlightcontroller.sos Java package. The SOS module is located in net.floodlightcontroller.sos.SOS.java. All other classes in the package are data types defined for use in the SOS module.

The SOS controller received a rather nice set of upgrades from the sos-13 branch to the smart-1.3 branch (both in the GitHub repository).

• A comprehensive REST API is exposed for configuration of the controller, including the whitelisting of clients, agent operations, and statistics gathering.
• Agent discovery allows the controller to learn the location of agents in the network provided only their IP addresses.
• Client and server discovery allows the controller to learn the location of the client/server provided only their IP addresses.
• Automated agent selection is performed per SOS transfer. The default algorithm is to select the agent closest to the client/server given a L2 hop count.
• Automated client-to-agent, agent-to-agent, and server-to-agent route calculation and flow insertion is performed. Different routing algorithms can be installed in a plug-and-play fashion. The default routing algorithm assumes the use of an in-network switch and an OVS onboard the agents. This is to account for the relatively limited action sets exposed by hardware switches.

Future Plans

The SOS controller is rather robust for most applications. It can handle arbitrary network topologies assuming the topology is capable of supporting SOS. However, some work still needs to be done:

• Flows need to be more precise to allow for simultaneous SOS transfers to exist without any overlap in the flow matches.
• Agents need to inform the controller when they are done with a transfer. This will allow the controller to remove the installed flows rather than having to rely on and wait for an idle timeout to occur.
• Clusters of agents need to be supported. The present bottleneck is the compute resources of a single agent and their inability to keep up with the line rate of the network (for 5Gbps+ speeds). The use of multiple agents in parallel can help to alleviate such a bottleneck by distributing the load.