State Machine

Finite State Machine Models

OpenFlow has a very simplified protocol that has a simple finite machine model. Almost all the messages in this protocol are asynchronous, which does not require a state to handle. However, the connection establishment procedure involves some version and capability negotiation which has to be done before any other messages can be exchanged. Therefore we capture the connection establishment procedure mainly in the state machine to well handle them.

The state machines described hereby are:

Controller, main connection

Controller, auxiliary connection (from v1.3)

Switch, main connection

Switch, auxiliary connection (from v1.3)

Sequence of Connection Establishment

The connection establishment procedure between the switch and the controller mainly consistes of two phases:

Version negotiation

Version negotiation is the procedure for different applications to agree on the version of application to be used. Up to now there have been five released versions of OpenFlow protocol: v1.0, v1.1, v1.2, v1.3, v1.3.1. Some products may only support a subset of the five versions. Version negotiation between the switch and controller determines which of the five versions of OpenFlow protocol is to be used for the ensuing messages. It is also possible that version negotiation determines that the versions between the switch and the controller are not compatible and no further communication is necessary.

Version negotiation procedure starts right after the lower level (TCP/TLS) connection is established. Both ends of the connection send a Hello message to the other end immediately after the lower layer connection establishment. After receiving Hello message from the other end, the device determines which version is the negotiated version. For OpenFlow versions before v1.3.1, the negotiated version is the lower version between the switch and the controller. For OpenFlow versions after v1.3.1, the negotiated version is the highest version that is supported by both the switch and the controller. The negotiated version must be the same on both ends of the connection by definition. Version negotiation succeeds if both ends support the negotiated version. Version negotiation fails if any end does not support the negotiated version or any end fails to receive the Hello message from the other end.

If the version negotiation is successful, the state machine of two ends enter the next phase, feature discovery. If it fails, lower layer connection is terminated and the state machine on both ends is reset to initial state.

The sequence diagram for a normal version negotiation:

The sequence diagram when one of the two ends does not support the negotiated version:

The sequence diagram when one of the two ends fail to receive transmission from the other end:

Feature discovery

The purpose of feature discovery is to make the controller aware of the capabilities of the switch. It is required by every version of OpenFlow protocol and is referred to as ‘Handshake’.

In feature discovery procedure, the controller sends a Features Request message to the switch and receives a Features Reply message from the switch that contains switch capability. If the Features Reply message is not received by the controller, then the controller disconnects the lower layer connection from the switch.

The sequence diagram of a normal feature discovery procedure:

The sequence diagram of a failed feature discovery procedure: