Association algorithm

This page is being written and still needs more technical details

RouteFlow uses a configuration system that serves as the basis for allowing:

• Any virtual machine interface to be associated with any OpenFlow switch
• Arbitrary virtual interface to switch port mappings beyond 1:1
• Multiple controllers to manage the network

In this approach, the network administrator is required to inform RouteFlow about the desired mapping. This configuration is loaded and stored in a MongoDB collection. The table below details the possible states a mapping entry can assume:

Format	Type
vm id, vm port, -, -, -, -, -	idle client port
-, -, -, -, dp id, dp port, ct id	idle datapath port
vm id, vm port, dp id, dp port, -, -, ct id	client-datapath association
vm id, vm port, dp id, dp port, vs id, vs port, ct id	active client-datapath association

The figure below illustrates the default RFServer behavior upon network events:

Whenever a switch joins the network, RFProxy informs the RouteFlow server about each of its physical ports. These ports are registered by the server in one of two ways explicited by the table above: as an idle datapath port or as a client-datapath association. The former happens when there is either no configuration for the datapath port being registered or the configured client port to be associated with this datapath port has not been registered yet. The latter happens when the client port that is to be associated with this datapath (based on the configuration) is already registered as idle.

When a RFClient starts, it informs the RouteFlow server about each of its interfaces (ports). These ports are registered by the RFServer in one of two states shown by the table above: as an idle client port or a client-datapath association. The association behavior is analogous to the one described above for the datapath ports.

After the association, the RFServer asks the RFClient to trigger a message that will go through the virtual switch to which it is connected and reach the RFProxy. When this happens, the RFProxy becomes aware of the connection between the RFClient and its virtual switch, informing the RFServer. The RFServer then decides what to do with this information. Tipically, the RFProxy will be instructed to redirect all traffic coming from the a virtual machines to the physical switch associated with it, and vice-versa.

In the event of a switch leaving the network, all the associations involving the ports of the switch are removed, leaving idle client ports in case there was an association. In case the datapath comes back, RouteFlow will behave as if it were a new datapath, as described above, restoring the association configured by the operator.

An entry in the configuration file contains a subset of the fields identified in the table above: vm_id, vm_port, dp_id, dp_port, ct_id. These fields are enough for the association to be made, since remaining fields related to the virtual switch attachment (vs_*) are defined at runtime. The ct_id field identifies the controller to which the switch is connected. This mechanism allows RouteFlow to deal with multiple controllers, either managing parts of the same network or different networks altogether.