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

...

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.

...

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.

At present, the controller module is fairly basic and consists of the following main components:

...

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 module is not very sophisticated at this point, although it gets the job done for basic deployments. Existing Floodlight services like routing and the device manager need to be used to automate the discovery of clients, agents, and the calculation of some flows.Work also needs to be done to make it easier to turn SOS on, off, and whitelist the client connections we want to optimize. This can foreseeably be done by implementing a REST APIcontroller 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.