In OpenFlow protocol we have a flow table (or multiple flow tables). Each flow table in the switich contains a set of flow entries. Each flow entry contains header fields, counters and a set of instructions or actions to be applied. Instrucions are like "add this action to action set" (write-actions instruction) or "clear action set" (clear-actions instruction), and actions are like "output to port X" (output action) or "drop this packet" (drop action). But how does work ? what exactly is in the flow entry, an action or an instruction ? or maybe both are ? what exactly is an action set ? could someone give me a little exmaple that uses these terms ?
"Actions can discard, modify, queue, or forward the packet. In version 1.0 of the OpenFlow protocol the Action set is modified directly by the Actions list in the FlowMod message; however, in 1.1.0 and subsequent versions the the protocol, the Action set is modified by the Instruction structure carried in the FlowMod. An Instruction may carry an Actions list to update the Action set, or be applied immediately to the packet bypassing the Action set".
ref. (http://flowgrammable.org/sdn/openflow/actions/#ofp_1_4)
In other words, when a packet matches a particular OpenFlow flow, the switch running OpenFlow v1.0 applies a set of actions to the packet. Now, with the new OpenFlow version, instead of applying a set of actions, the switch applies a flow instruction to a matching packet.
According to OpenFlow specification 1.5.1 (https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-switch-v1.5.1.pdf), the instruction set associated with a flow entry contains a maximum of one instruction of each type, following the order:
Apply-Actions, Clear-Actions, Write-Actions, Write-Metadata, Stat-Trigger or Goto-Table.
Related
I mean, write metadata is implemented by the instructions in openflow, on the other side, set field in action can also set the metadata ,what is the differences between them?
As far as I can see, WRITE_METADATA and SET_FIELD for metadata do the same in Open vSwitch.
I'm guessing both are exposed by Open vSwitch to follow the OpenFlow specifications as much as possible. OpenFlow has a clear distinction between Actions and Instructions (cf. Sections 5.5 and 5.6 of OpenFlow v1.5.1): Instructions are attached to rules and applied at the end of each table, whereas Actions are attached to packets (using the Write-Actions Instruction) and applied at the end of the pipeline (or before if the Apply-Actions Instruction is executed). In Open vSwitch, the distinction is not as clear: Actions can be attached to both packets and rules.
Thus, while WRITE_METADATA is different from SET_FIELD in the OpenFlow specification because the first is an Instruction, the second an Action, you can do the same as WRITE_METADATA with a SET_FIELD Action.
According to described here
http://flowgrammable.org/sdn/openflow/message-layer/flowmod/
and in the OpenFlow switch specifications, the flow_mod message is not acknowledgeable.
Is there any way for the controller (POX, ODL, or any other) to receive a confirmation for installed flow match or to retrieve the installed flows in the switch's flow table?
Thank you
There is a concept in openflow called "barrier" where the controller
can send a barrier request to have the switch acknowledge the flow_mod.
In OpenDaylight, the default openflowplugin stats collection will poll
the connected switches and will store the config (including the flow table)
in OpenDaylight's operational store.
I am trying to use the POX controller to control the path of flows. I know that the Open vSwitch will choose the forwarding rules that have the highest priority. But what will happen if I insert a new forwarding rule for the existing flow with the same priority. Will the Open vSwitch randomly choose one rule to match?
The OpenFlow 1.3 specification says:
If there are multiple matching flow entries with the same highest priority, the selected flow entry is explicitly undefined.
The older OpenFlow 1.0 specification states that:
If multiple entries have the same priority, the switch is free to choose any ordering.
Open vSwitch docs and this other source here says:
OpenFlow leaves behavior undefined when two or more flows with the same priority can match a single packet. Some users expect "sensible" behavior, such as more specific flows taking precedence over less specific flows, but OpenFlow does not specify this and Open vSwitch does not implement it. Users should therefore take care to use priorities to ensure the behavior that they expect.
It is unclear, I know, but based on these sources, it is up to the user to deal with situations where a flow entry overlap with same priorities occurs. The user should take care of setting the right priorities and the switch is free to implement a way to deal with this as the vendor desires. The switch may, for instance, select the newest flow entry, as you said it happened in your case.
I'm using Mininet and POX controller. The network topology has multiple switches.
Whenever I install flow for some switch, and afterwards I check the flow table in that switch, its actions set is empty.
dump-flows shows actions=
However, when there's only one switch in the network, the actions set is not empty.
What may be the reason for the actions set being empty ?
Thank you
After looking in OpenFlow specifications again,
I learned that an empty actions set in a flow entry is a drop flow.
From OpenFlow Switch Specifications v1.3.1
Drop. There is no explicit action to represent drops. Instead, packets whose action
sets have no output actions should be dropped.
Afterwards, I realized where was the error in the code which made the incorrect flow entry installed.
This Question is extension of the following
OpenFlow Rule Metadata
I would like to have this clarified, on my question about Metadata
Let us say, I have an Open Flow rules, as below
Cookie=0x8000001, duration=228925.445s, table=17, n_packets=350, n_bytes=32424, priority=10,metadata=0xc000f30000000000/0xffffff0000000000 actions=goto_table:19
I wanted to understand the following
Do we have certain rule/ Algorithm , to determine these Metadata from a Packet.
because the Packet in OVS is actually switched based on Matching Metadata, Is that correct ?? ( At least according to the above flow rule )
And the Packet itself does not carry the Metadata, then how exactly
the packet hitting a flow matched against the Metadata.
So, If I understood it correctly the Packets those are traversed between the flow-tables, are within the OVS application itself or Handled #OVS Application level, until it had determined Egress Port
So in that Case, the MetaData are handled #OVS-Application level, until the Packets is send via Egress Port.
Is this correct??
Finally which Module in ODL is responsible for determine the Metadata, and I would like to understand from the code how exactly it was done.
The OpenFlow metadata field starts with a value of zero for every packets. Tables can then writes to this field and you can match on it in subsequent tables. It is only used to carry information from one table to the next, as explained in the OpenFlow specifications:
Metadata: a maskable register that is used to carry information from one table to the next.
first of all you can try Ryu instead, its code is more easy to read and understand.
Then, I think metadata/instructions/actions.... these things are belong to the processing of OVS forwarding, but these things needs to attach to something and that is the packet that OVS received. About the question "Do we have certain rule/ Algorithm , to determine these Metadata from a Packet. " I think the value of the Metadata is determind by the controller, which means that it depends on 'how do you design your own network instance using some(e.g. RYU) controller application'.