Each flow entry is associated with zero or more actions that instruct the OpenFlow switch on how to handle matching packets. If no forward actions are present, the packet is dropped. Action lists must be processed in the specified order. However, there is no guaranteed packet output ordering within an individual port. For instance, two packets that are generated and destined to a single output port as part of the action processing may be arbitrarily reordered.

Pure OpenFlow switches support only the Required Actions, while hybrid OpenFlow switches may also support the NORMAL action. Either type of switches can also support the FLOOD action. The Required Actions are as follows:

• Forward: OpenFlow switches must support forwarding the packet to physical ports and the following virtual ones:
  • ALL: Sends the packet to all interfaces, excluding the incoming port
  • CONTROLLER: Encapsulates and sends the packet to the controller
  • LOCAL: Sends the packet to the local networking stack of the switch
  • TABLE: Performs the action in the flow table (only for the packet-out message)
  • IN_PORT: Sends the packet to the input port
• Drop: This indicates that all the matching packets should be dropped. A flow entry with no specified action is considered a Drop action.

The Optional Actions are as follows:

• Forward: A switch may optionally support the following virtual ports for forward action:
  • NORMAL: Process the packet using the traditional forwarding path supported by the switch (that is, traditional L2, VLAN, and/or L3 processing)
  • FLOOD: Flood the packet along the minimum spanning tree, not including the incoming interface.
  • Enqueue: This forwards a packet through a queue attached to a port. The forwarding behavior is dictated by the configuration of the queue and is used to provide the basic QoS support.
• Modify field: The optional (recommended) field modification actions are as follows:
  • Setting VLAN ID: If no VLAN is present, a new header is added with the specified VLAN ID (12-bit associated data) and a priority of zero. If a VLAN header already exists, the VLAN ID is replaced with the specified value.
  • Setting VLAN priority: If no VLAN is present, a new header is added with the specified priority (3-bit associated data) and the VLAN ID of zero. If a VLAN ID header already exists, the priority field is replaced with the specified value.
  • Striping the VLAN header: This strips the VLAN header, if present.
  • Modifying the Ethernet source/destination MAC address: This replaces the existing Ethernet source/destination MAC address with the new value (specified as a 48-bits data).
  • Modifying the IPv4 source/destination address: This replaces the existing IP source/destination address with a new value (associated with 32-bits data) and updates the IP checksum (and TCP/UDP checksum if applicable). This action is only applicable to IPv4 packets.
  • Modifying the IPv4 ToS bits: This replaces the existing IP ToS field with the 6-bits associated data. This action is applicable only to IPv4 packets.
  • Modifying the transport source/destination port: This replaces the existing TCP/UDP source/destination port with associated 16-bits data and updates the TCP/UDP checksum. This action is only applicable to TCP and UDP packets.

Upon a packet arriving at the OpenFlow switch, the packet header fields are extracted and matched against the matching fields' portion of the flow table entries. This matching starts at the first flow table entry and continues through subsequent flow table entries. If a matching entry is found, the switch applies the appropriate set of instructions associated with the matched flow entry. For each packet that matches a flow entry, the associated counters for that entry are updated. If the flow table look-up procedure does not result in a match, the action taken by the switch will depend on the instructions defined at the table-miss flow entry. The flow table must contain a table-miss entry in order to handle table misses. This particular entry specifies a set of actions to be performed when no match is found for an incoming packet. These actions include dropping the packet, sending the packet out on all interfaces, or forwarding the packet to the controller over the secure OpenFlow channel. Header fields used for the table lookup depend on the packet parameters as described as follows:

• Rules specifying an ingress port are matched against the physical port that received the packet
• The Ethernet headers as specified in the first figure and are used for all packets
• If the packet is a VLAN (Ethernet type 0x8100)), the VLAN ID and PCP fields are used in the lookup
• For IP packets (Ethernet type equal to 0x0800)), the lookup fields also include those in the IP header
• For IP packets that are TCP or UDP (IP protocol equal to 6 or 17), the lookup includes the transport ports
• For IP packets that are ICMP (IP protocol equal to 1), the lookup includes the Type and Code fields
• For IP packets with nonzero fragment offset or more fragment bit sets, the transport ports are set to zero for the lookup
• Optionally, for ARP packets (Ethernet type equal to 0x0806)), the lookup fields may also include the contained IP source and destination fields