Controller-OVS Interaction

Once the controller and OVS are connected, a set of messages will be exchanged. For example, the OVS sends an OFPT_HELLO message to the controller. The hello message is captured on the wireshark screen. The first byte of the message is the version number and the second byte is the OFPT_TYPE. OFTP_HELLO message is type 0.

After the hello message from the switch, the controller sends OFPT_FEATURES_REQUEST (type=5) to retrieve the switch capabilities, including the supported open flow version, switch configuration, port hardware address, etc. The switch sends OFPT_FEATURES_REPLY (type=6) to provide the feature information. The message is shown on both the controller console and switch console.

Figure 8 – OFPT_HELLO message

The switch console information is provided by the snoop option of the ovs-ofctl command. The command is ovs-ofctl snoop br0. It shows the feature request from the controller and the feature reply with the bridge information. User can compare the switch console information with the controller console information to get a better understanding of the message exchange.

Figure 9 – ovs-ofctl snoop br0

The wireshark also captured the information. Notice the message type in the second byte is 6 representing the OFPT_FEATURES_REPLY. After the feature reply, the controller sends an OFPT_SET_CONFIG message to set the message parameters such as max length, etc. Once the controller is connected, the OVS changes its default behavior from a layer 2 switch to an OVS switch. It means the flooding is disabled and open flow packet processing starts. Each packet is processed based on the flow table entry. Unmatched packets are forwarded to the controller for analysis unless a rule is defined to drop the packet.
During initial start up with the controller, the flow table is empty. Therefore, packets received from any port are forwarded to the controller. The next message from the switch is type OFPT_PACKET_IN (type=10/0x0a).

Figure 10 – OFPT_FEATURE_REPLY message

 
In this exercise, the RYU-manager does not have any application to receive and process the OFPT_PACKET_IN message. Therefore, on the controller screen, a bunch of unhandled_events are printed on the console. At this point, the RYU-OVS open flow session is established and ready for Open Flow application to take over the event handling and flow configuration.