These messages are sent by the controller to manage the state of the switches. They are used to add/delete or modify flow table entries or set switch port priorities. Flow table modification messages can have the following types:

• ADD: For ADD requests with the OFPFF_CHECK_OVERLAP flag set, the switch must first check for any overlapping flow entries. Two flow entries overlap if a single packet may match both, and both entries have the same priority. If an overlap conflict exists between an existing flow entry and the ADD request, the switch must refuse the addition and respond with ofp_error_msg with the OFPET_FLOW_MODE_FAILED error type and the OFPFMFC_OVERLAP error code. For the valid (non-overlapping) ADD requests, or those with no overlap checking flag set, the switch must insert the flow entry at the lowest numbered table entry for which the switch supports all wildcards set in the flow_match struct and for which the priority would be observed during the matching process. If a flow entry with identical header fields and priority already resides in a flow table, then that entry, including its counters, must be removed and the new flow entry must be added. If a switch cannot find any table entry to add the incoming flow entry, the switch should send ofp_error_msg with the OFPET_FLOW_MOD_FAILD type and the PFOFMFC_ALL_TABLES_FULL error code. If the action list in a flow modifies message references a port that will never be valid on a switch, the switch must return ofp_error_msg with the OFPET_BAD_ACTION type and the OFPBAC_BAD_OUT code. If the referenced port may be valid in the future (for example, when a line card is added to a chassis), the switch can either silently drop packets sent to the referenced port or immediately return an OFPBAC_BAD_PORT error and refuse the flow to modify the message.
• MODIFY: If a flow entry with identical header field does not reside in the flow table at the time the modify command arrives from the controller, the MODIFY command acts like an ADD command, and the new flow entry must be inserted with zeroed counters. Otherwise, the actions field is changed in the existing entry and its counters and idle timeout fields are left unchanged.
• DELETE: For delete requests, if no flow entry matches, no error is recorded and no flow table modification occurs. If a flow entry matches, the entry must be deleted, and then each normal entry with the OFPFF_SEND_FLOW_REM flag set should generate a flow removal message. Deleted emergency flow entries generate no flow removal messages. DELETE and DELETE_STRICT (refer to the next bullet point) commands can be optionally filtered by the output port. If the out_port field contains a value other than OFPP_NONE, it introduces a constraint when matching. This constraint is that the rule must contain an output action directed at that port. This field is ignored by the ADD, MODIFY, and MODIFY_STRICT messages.
• MODIFY and DELETE: These flow mode commands have corresponding _STRICT versions. In versions that are not RESTRICT, the wildcards are active and all flows that match the description are modified or removed. In _STRICT versions, all fields, including the wildcards and priority, are strictly matched against the entry and only an identical flow is modified or removed. For instance, if a message to remove entries is sent to the switch that has all wildcard flags set, the DELETE command would delete all flows from all tables. However, the DELETE_STRICT command would delete only a rule that applies to all packets at the specified priority. For the non-strict MODIFY and DELETE commands that contain wildcards, a match will occur when a flow entry exactly matches or is more specific than the description in the flow_mod command. For example, if a DELETE command says to delete all flows with a destination port of 80, then a flow entry that has all wildcards will not be deleted. However, a DELETE command that has all wildcards will delete an entry that matches all port 80 traffic.