OpenFlow Switch Specification 1.3.0 (ii) __openflow

Five, OpenFlow table

This section describes the components that make up the flow table and the group table, and also includes the mechanism of the flow table "matching" and "action" processing.
5.1 Pipeline processing Process

The switches that obey the OpenFlow protocol can be divided into two categories: one is openflow-only, the other is Openflow-hybrid. The openflow-only switch supports only OpenFlow operations, in which all packets are handled by the OpenFlow pipeline, otherwise they cannot be processed.
The Openflow-hybrid switch supports both OpenFlow operations and normal (normal) Ethernet switching operations (Ethernet switching operation), such as traditional L2 Ethernet switches, VLAN isolation, L3 Routing (IPv4 routing, IPv6 routing ...) ), ACLs, and QoS processing processes. In addition to being positioned as a OpenFlow category, such switches should also provide a sorting mechanism to indicate whether the switch routes traffic to the OpenFlow pipeline or the normal pipeline. For example, a switch can decide how to handle this packet by using the VLAN tag or the input port of the packet: using the pipeline or the pipeline, or sending all packets to the OpenFlow pipeline. This classification mechanism does not belong to the description scope of this document. A openflow-hybrid switch should also allow the retention of ports through normal and FLOOD to implement the way in which packets are passed from the OpenFlow pipeline to the normal pipeline that is, the traditional network processing mode. (see section 4.5)
The OpenFlow pipeline in each OpenFlow switch contains multiple flow tables, with each flow table containing multiple flow table entries. The OpenFlow pipeline processing process defines how packets interact with these flow tables (see Figure 2). A switch requires at least one flow table or multiple flow tables. A OpenFlow switch has only one flow table that is legitimate, in which case the pipeline processing process is greatly simplified.

The flow table in the OpenFlow switch is numbered consecutively, numbering starting from 0. The pipeline processing process usually starts with the first flow table: that is, the packet first matches the flow table entry in the No. 0 stream table. The use of other flow tables depends on the results of the first flow table.
When the packet is processed by the flow table, the packet matches the flow table entry in the Flow table, and selects a flow table entry (see section 5.3). If a stream table entry is matched, the instruction set contained in the Flow table entry (instruction set) is executed, which explicitly forwards the packet to another stream table (using the goto instruction, see section 5.9), and so on. A flow table entry can only forward packets to a stream table that is larger than the current flow table number, in other words, the pipeline processing process can only be forward and not back. Obviously, the flow table entry for the last flow table of the pipeline cannot have a goto instruction. If the matching Stream table Entry no longer forwards the packet to another flow table, the pipeline processing process stops on this table. When the pipeline process stops, the packet is processed by the action set associated with it, usually the action set is forwarding (see section 5.10).
If a packet does not match a flow table entry in a flow table, it is called "Table Miss". The processing behavior of table loss depends on table configuration (see section 5.4). In a flow table, a stream table entry named Table-miss can specify how to handle a packet that does not match: the actions that can be selected include "Delete Packet", "Send to another flow table", or "control channel". Use the packet-in message to packages the data to the controller (see Section 6.1.2).
5.2 Flow Table

The flow table consists of a stream table entry. Each flow table entry (see table 1) contains: * Match fields: used to match packets. This field consists of "input port" and "Data Baoshin headers", as well as "metadata" (this entry is optional) specified by the previous flow table. * Priority: Matching priority for flow table entries * Counters: When matching to a packet, update this item * instructions: Used to modify the action set (action set) or pipeline process * Timeouts: The maximum idle time for the stream table entry, Invalid * Cookie for this time flow table entry: Opaque data value selected by the Controller (date value). The controller can be used as the filter flow policy, modify stream (flow modification), and delete stream (flow deletion) and do not use this field when processing packets. (Annotation: I think "stream" in the "Modify Flow" and "delete stream" here refers to "flow table entries")
A flow table entry is determined by its matching field (Match fields) and precedence (priority): matching fields and precedence identifies the only flow table entry in the Flow table. When matching fields in a flow table entry pass all fields (that is, all fields are ignored) and have priority 0 o'clock, the flow table entry is called the "Table-miss" Flow table entry (see section 5.4).
5.3 Match


When the switch receives the packet, the process shown in Figure 3 is executed. Switches are first queried in the first flow table, and may execute queries from other flow tables depending on the pipeline process (see section 5.1).
The fields used for package matching are extracted from the packet. Depending on the type of packet, the Package matching field (packet match fields) is used for table queries, where typical matching fields include "Various data Baoshin headers" such as Ethernet origin or IPV4 destination address (see a.2.3). In addition to the packet header, you can also match the packet's input port and metadata field (metadata fields). Metadata can be used to pass information between different tables in the switch. "Package Match field" represents the current state of the packet, and if the actions previously used in the flow table are useful to apply-actions to change the header, these changes will be reflected in the package matching field.
If the value of the packet matching field for the packet matches the value already defined in the Flow table entry, the packet matches to a stream table entry. If the Flow table entry field has any value (the field is ignored), the flow table entry matches all values in the data Baoshin header. If the switch can support a "packet matching field" arbitrary mask, these masks will facilitate more precise indication of the match.
When a packet matches a flow table, only the top-priority stream table entries that are matched are selected. The counters associated with their stream table entries must be updated, and the instructions must be executed. If there are multiple flow table entries that match and have the same priority, it is not explicitly defined which flow table entry is executed. This situation only occurs when the controller's application writer does not set the OFPFF_CHECK_OVERLAP bit in stream mode message (flow mod messages) and adds overlapping flow table entries.
When the switch configuration contains the ofpc_frag_reasm tag (see a.3.2), the IP fragment must be reassembled before the "Pipeline processing process" can be performed.
This version of the specification does not define the handling behavior of the switch receiving "malformed packets" and "corrupted packets". 5.4 Table-miss

Each flow table must support a "Table-miss" flow table entry to handle "table loss." When a packet cannot match all of the other flow tables in the flow table, the "Table lost" flow table entry is executed (see section 5.1) and, in most cases, "action" for "table loss" is to send the packet to the controller. Other actions include deleting packets, or sending packets directly to the next stream table.
The Table-miss Flow table entry is determined by its matching field and precedence (see Section 5.2), which matches all fields (that is, ignoring all fields) and has the lowest permission (0). The matching of Table-miss flow table entries may fall outside the range of normal matches supported by the flow table, for example, an exact flow table may not support some redundant flow table entries, but must support the "Table-miss" flow table entries for all fields. The "Table-miss" flow table entry may not have the same capabilities as a regular flow table item (see A.3.5.5). The designer of the switch, when designing a "Table-miss" flow table entry process, it is best to support at least several of the capabilities described in this document: sending packets to the controller, deleting the packets, or sending the packets to the next flow table.
The performance of the "Table-miss" flow table entries is essentially the same as that of other stream tables: It is not the default in the Flow table, The controller can add or remove it at any time (see section 6.4), and he may also be deleted (see section 5.5), which is used to match all other flow tables in the flow table can not match the packet (see 5.9 chapters). If the "Table-miss" stream table entry packages the data directly to the controller by using the CONTROLLER port (see section 4.5), the reason for the "packe-in" message to occur must be recognized as "Table-miss" (see A. 4.1).
If the "Table-miss" flow table entry does not exist, the mismatched packets under the default condition should be deleted (discarded). The switch can use the OpenFlow configuration Protocol to reconfigure this default operation, specifying additional behavior.
5.5 Deletion of Flow table entries
Flow table entries are removed from the flow table in two ways: one from the controller's deletion request and the other through the switch time-out mechanism.
The "flow expiry" mechanism of the switch is independent of the controller execution. Its execution is based on the state information of the flow table entry and the configuration information of the flow table entry. Each Stream table Item Association has a "idle_timeout" and a "hard_timeout". If two values are Non-zero, the switch must pay attention to the "arrival time" of the Flow table entry (that is, when the stream table entry is inserted into the flow table) so that it is removed later. A Non-zero "hard_timeout" field causes the flow table to be deleted after a given number of seconds, regardless of the number of packets it matches. The meaning of the "idle_timeout" field is that the stream table entry is deleted when the stream table entry does not match to the packet within the given number of seconds. The switch must implement a "flow expiry", and the flow table entry must be deleted when these two set time fields exceed.
The controller may actively remove the stream table entry from the flow table and implement it by sending a "delete" stream table to modify the message (Flow table modification messages) (Ofpfc_delete or ofpfc_delete_strict see section 6.4).
When a stream table entry is deleted, whether the switch is actively deleted or the flow expiry mechanism, the switch must check the "Ofpff_send_flow_rem" tag of the flow table entry. If this tag is set, the switch must send a "stream deletion message" to the controller (flow removed messages). Each "Stream deletion message" contains a complete description of the flow table entry, including the reason for the deletion (timeout or controller deletion), deletion of the Shireu table entry, and deletion of the Shireu table entry statistics.
5.6 Group Table
The group table consists of group entries. A flow table entry that points to group so that OpenFlow has additional forwarding processing (for example, select and all).
Each group table entry (see table 2) is identified by its group identifier, and contains: * Group identifier: A 32-bit unsigned integer that uniquely identifies the group: The group is used to determine groups semantics Semantics) (see 5.6.1 chapters) * Counters: When the packet is processed by this group, update this field * Action buckets: An ordered "action bucket" (Action buckets) list, each action bucket (action Bucket) contains a collection of actions that are used to execute and correlate parameters.
5.6.1 Group Type
The switch does not have to support all the group types, just select the "must" tag below to support it. The controller can query which "optional" group types the switch supports.
* Must: All: "Bucket" (buckets) in the execution group. Use this group for multicast or broadcast forwarding. In this case, the packets are efficiently copied to each bucket, and the packets are manipulated by each bucket in the group. If a "bucket" explicitly forwards a packet to its input port, the "copy" of the packet will be deleted. If the controller application writer wants to send the packet to the input port of the packet, the "group" should also contain a "bucket" containing the "output to reserved port Ofpp_in_port" action.
* Optional: Select: a "bucket" in the execution group. Based on a "switch-computed selection" algorithm (for example, a hash of a user-registered "Ganso (tuple)" or a simple "poll"), the packet is processed by the only bucket in the group. All registrations and statuses related to this selection algorithm have nothing to do with OpenFlow. Selection algorithm as far as possible to consider the "bucket" load equal sharing, can also be based on "bucket" weight. When a "bucket" of a selected group, if its specified port is closed, the switch should be "bucket selection" (bucket selection) to the remaining (remaining) "Bucket set" (set, which should be the meaning of the bucket collection), rather than the packet that will be sent to this port. This sample can reduce the link line and switch off the damage caused by the wire.
* Must: Indirect: "bucket" defined in the execution group. This group only supports a single "bucket". Allows multiple "flow table entries" or "groups" to point to a common group identifier to support fast and efficient convergence. (for example, IP next hop forwarding). This group type is actually equivalent to a group of "all" types that have only one bucket.
* Optional: Fast failover: Executes the first surviving (live) bucket. Each action bucket (action bucket) is associated with a specific port and/or group (which controls its lifetime). These "buckets" will be evaluated according to the order in which the group is defined, and the first bucket associated with "live Port/group" will be selected. This type of group allows the switch to change the forwarding mode without asking the controller. If there is no surviving "bucket", then the packet will be deleted. This group type must implement a "survival state mechanism" (liveness mechanism) (see section 6.5).
5.7 Meter table (meter table)
A meter consists of "meter table items" (meter table) that defines the measurement of each stream (Per-flow). Per-flow metering allows OpenFlow to implement a variety of simple QoS operations, such as rate limiting (rate-limiting), or a combination of queues (queues) for each port (Per-port) (see 5.12) to implement a complex QoS framework, such as DiffServ.
A "meter" (meter) measures the rate of packets allocated to it, so as to control the rate of those packets. The meter is directly bound to the Flow table entry (in contrast to the queues on the port that are not directly bound to the port). Any flow table entry can specify a "meter" in its "Instructions" (see section 5.9), which is used to measure and control the total rate of all the flow table item collections that are bound to it. Multiple "gauges" can be used in the same flow table, but are used in disjoint flow table item collections (that is, the stream table entries do not match to the same packet). Multiple flow table entries can also be used on the same packet aggregation, as long as the meter is used in the next flow table that processes this packet collection.
Each "meter table item" (Meter entry) (see table 3) is identified by its meter identifier and contains: *meter identifer: A 32-bit unsigned integer number that uniquely identifies this "metering device" *meter bands: a "metering bandwidth" Unordered list of (meter bands), each "gauge bandwidth" specifies the rate of "bandwidth" and how packets are processed. *counters: Update this value when the packet is processed by a "metering device"
5.7.1 Metering Device Bandwidth
Each "metering device" can have one or more "meter bandwidth". Each "bandwidth" indicates the rate at which this "bandwidth" is applied and how the packet should be handled. Packet processing is based on a separate "meter bandwidth" currently measured by the "meter" rate. When the meter is performing "metering bandwidth" (meter band) processing, it is the maximum rate at which the current measured meter rate exceeds the configuration.                  If the current rate is below the specified "meter bandwidth" rate, there is no "metering bandwidth" processing executable.  Each "gauge bandwidth" (see table 4) is identified by its rate, which contains: * Band type: Defines how the package handles * Rate: for "metering" to select "meter bandwidth", defines the lowest rate when using this "metering bandwidth". *counters: When "metering bandwidth" is used to process packets, update this count * Type specific arguments: Some optional parameters for the counter bandwidth type
In this document description, there is no "required" bandwidth type (band type). The controller can query the switch to support the following "optional" bandwidth types: * Optional: Drop: Delete (or discard) packets. Can be used to define a "rate limit" bandwidth. * Optional: DSCP remark (differential service code point re-tag): Reduces the deletion of packets with the Priority DSCP field on the IP header. Can be used to define a simple DiffServ (differentiated service) policy.
5.8 counter
Each flow table, stream table entry (flow entry), ports (port), queues (queue), groups (group), barrel (group bucket), metering (meter), and meter bandwidth (meter Band) maintains a number of counters (counters). A counter that obeys OpenFlow may be implemented by software and maintained by polling a limited hardware counter. Table 5 covers the counters defined by the OpenFlow specification. There is no need for the switch to support all counters. Only those marked "must" in table 5 must have.





"Duration" counts the flow table entries, a port, a group, a queue, or the time a meter is installed in the switch. Must be tracked with the precision of seconds. The "Receive Error" field defined in table 5 is used to count all receive errors and conflict errors. Other similar counters mentioned in table 5 are similar in meaning.
The counter is an unsigned integer that grows and does not have an overflow indicator. If the number specified for a counter in the switch is too large, the value of the counter is set to the maximum value for the field (the binary form and the signed 11).
5.9 Instructions
Each flow table entry contains instructions that are executed when a packet is matched to a stream table entry. These directives result in changes to the packet, set action, and pipeline processing process.
Switches do not have to support all instruction types, only the following must be marked with "must command" (required instruction). The controller can also query which optional instructions the switch supports (optional instruction).
*optional instruction:meter meter_id: Directs the packet to a specified meter. Depending on the rate rule of the meter, this packet may be deleted. *optional instruction:apply-actions Action (s): immediately apply the specified action (s) and make no changes to the action set. This instruction can be used to modify a packet between two tables, or to perform multiple actions of the same type. The action (s) is listed in the action list (see 5.11). *optional instruction:clear-actions Action (s): Clears all actions in the action set immediately. *required instruction:write-actions Action (s): Adds the specified action (action (s)) to the current action set (see 5.10). If this action exists in the current action collection, override it, or add the action. *optional Instruction:write-metadata Metadata/mask: Writes the Mask's metadata (masked Metadata value) value to the Metadata field (Metadata field). This mask indicates which bits of the metadata register need to be modified (for example, New_metadata = old_metadata & ~mask | Value & Mask). *required instruction:goto-table Next-table-id: Indicates the next table for the pipeline processing process. The Table-id must be larger than the current table-id. The Flow table entry for the last table cannot contain this directive (see Section 5.1).
The instruction set of a flow table entry can contain the maximum number of instructions for each type of instruction. The order of instruction execution in the instruction collection is the same as the order specified in the list. In practice, the only limitation is that the Meter instruction executes before the apply-actions instruction, the clear-aactions instruction executes before the write-actions instruction, and the goto-table instruction is finally executed.
The switch can reject the installation of a stream table entry that occurs when the instruction for this flow table entry cannot be executed by the switch. In this case, the switch must return a "Unsupported flow error" (see section 6.4). The flow table cannot support all matches, all instructions, and all actions (actions).
5.10 Action Set (action set)