OpenFlow ALL Vs FLOOD Action

There has been always a confusion in my mind regarding the difference between OpenFlow ALL and FLOOD action. If you are one of them, go on!

Technically, the spec definition says:

FLOOD: Flood the packet along the minimum spanning tree, not including the incoming interface.

ALL: Send the packet out all interfaces, not including the incoming interface.

So, what’s the difference?

ALL action is pretty much clear in what it says. What is implied by saying “along the minimum spanning tree” is that flood the packet on all the ports where STP is disabled.

Now if we take a case of Juniper Junos OS with OpenFlow which do not support STP, in that case all the ports will have STP disabled due to lack of feature and both ALL & FLOOD actions will behave in the same way.

Hope it helps!


Example message exchange sequence between OpenFlow & SDN Controller

Further to understanding the OpenFlow messages that are exchanged between hardware and a SDN Controller in Understanding OpenFlow Communication Channel, I thought it will be nice to know the sequence in which these messages are exchanged.

Based on my understanding using wireshark, a OpenFlow switch and OpenDaylight, below is a visual sequence diagram explaining major message exchanges I could see.

OF Message Exchange Sequence


Understanding Openflow Communication Channel

The OpenFlow protocol (1.0.0) describes message exchanges that take place between an OpenFlow controller and an OpenFlow device. Typically, the protocol is implemented on top of SSL or Transport Layer Security (TLS), providing a secure OpenFlow channel.

The OpenFlow protocol enables the controller to perform add, update, and delete actions to the flow entries in the flow tables. It supports three types of messages:

  1. Controller-to-Device: These messages are initiated by the controller and, in some cases, require a response from the device.
  2. Asynchronous: These types of messages are sent without solicitation from the controller.
  3. Symmetric: These messages are sent without solicitation from either the controller or the device. They are simple yet helpful.

Below is the list of complete OpenFlow messages that any implementation needs to support.

OF Communication Messages