Setting the OpenFlow Version

In Floodlight v1.2 and above, you can set the specific OpenFlow protocol versions you want Floodlight to be able to speak. Of course, you can't set a version not implemented within the underlying OpenFlowJ-Loxi library (e.g. OpenFlow 1.5 is not supported). However, you can precisely define the versions of OpenFlow you want Floodlight to be able to speak from OpenFlow 1.0 through OpenFlow 1.4 (through OpenFlow 1.5 in Floodlight master). By default, Floodlight is configured to allow all these protocol versions.

Through experience, we've found that many OpenFlow switches do not correctly implement version negotiation. You can circumnavigate these problems by customizing the OpenFlow versions used by Floodlight.

There are two types of OpenFlow version negotiation:

(1) For OpenFlow 1.0 through 1.3.0, the lesser of the two advertised versions in the OpenFlow hello messages from the controller and from the switch should be chosen by each side. For example, if a switch tries to connect with a hello of version 1.3 and Floodlight responds with a hello of version 1.4, both (in theory) should choose 1.3, since it's the lesser of the two versions.

Switch							Floodlight
 
hello(v1.3)			-->			
					<--			hello(v1.4)
v1.3 < v1.4						v1.3 < v1.4
choose v1.3						choose v1.3
					<--			feat_req(v1.3)
feat_reply(v1.3)	-->			
...					...			...

This algorithm has a fatal flaw in that it assumes both the controller and the switch support all versions of OpenFlow less than that advertised. In practice, many switches and controllers might, for example, only support OpenFlow 1.3 and not 1.2, 1.1, and 1.0 – implied via the aforementioned algorithm. Furthermore, many switches, for some reason, do not choose the lower of the two versions (even if it's the switch's own version) and either disconnect or report an error. Instead, these switches tend to want the controller to advertise the same version as it speaks and do not try to negotiate a version if the advertised versions are different.

(2) To address these issues, OpenFlow versions 1.3.1 and above include a version bitmap in the header of the hello message. This bitmap contains a flag bit for every OpenFlow version. The switch and the controller will each set the corresponding flag for each version of OpenFlow they support. Upon receipt of a version bitmap, the controller and switch will compare the bitmap received to its own version bitmap. A simple AND bit mask operation will reveal the highest, common supported version. This version will be chosen as the version to use in the handshake.

If you find that a switch has trouble handshaking with Floodlight due to an explicit version negotiation error or through a less-revealing pattern of connect, disconnect, connect, disconnect, etc., then try and more precisely define the OpenFlow protocol versions Floodlight will attempt to handshake with. The problem might be that the switch does not like Floodlight advertising a higher OpenFlow version than the switch supports itself.

In src/main/resources/floodlightdefault.properties, modify the following line:

net.floodlightcontroller.core.internal.OFSwitchManager.supportedOpenFlowVersions=1.0, 1.1, 1.2, 1.3, 1.4

to include only the OpenFlow versions you want to use, e.g:

net.floodlightcontroller.core.internal.OFSwitchManager.supportedOpenFlowVersions=1.0, 1.1, 1.2, 1.3

The highest of these versions will be advertised as the version in Floodlight's hello message. In the example above, we can modify our supported versions to exclude OpenFlow 1.4. This will force Floodlight to advertise it's highest version as OpenFlow 1.3. This will then be seen by the switch as equal to its own version, which will result in a successful handshake.