OpenFlow Switch Specification Version 1.3.4
The flow tables of an OpenFlow switch are sequentially numbered, starting at 0. Pipeline processing
always starts at the first flow table: the packet is first matched against flow entries of flow table 0.
Other flow tables may be used depending on the outcome of the match in the first table.
When processed by a flow table, the packet is matched against the flow entries of the flow table to
select a flow entry (see 5.3). If a flow entry is found, the instruction set included in that flow entry is
executed. These instructions may explicitly direct the packet to another flow table (using the Goto-
Table Instruction, see 5.9), where the same process is repeated again. A flow entry can only direct a
packet to a flow table number which is greater than its own flow table number, in other words pipeline
processing can only go forward and not backward. Obviously, the flow entries of the last table of the
pipeline can not include the Goto-Table instruction. If the matching flow entry does not direct packets
to another flow table, pipeline processing stops at this table, the packet is processed with its associated
action set and usually forwarded (see 5.10).
If a packet does not match a flow entry in a flow table, this is a table miss. The behavior on a table miss
depends on the table configuration (see 5.4). The instructions included in the table-miss flow entry in
the flow table can flexibly specify how to process unmatched packets, useful options include dropping
them, passing them to another table or sending them to the controllers over the control channel via
packet-in messages (see 6.1.2).
There are few cases where a packet is not fully processed by a flow entry and pipeline processing stops
without processing the packet’s action set or directing it to another table. If no table-miss flow entry
is present, the packet is dropped (see 5.4). If an invalid TTL is found, the packet may be sent to the
controller (see 5.12).
The OpenFlow pipeline and various OpenFlow operations process packets of a specific type in con-
formance with the specifications defined for that packet type, unless the present specification or the
OpenFlow configuration specify otherwise. For example, the Ethernet header definition used by Open-
Flow must conform to IEEE specifications, and the TCP/IP header definition used by OpenFlow must
conform to RFC specifications. Additionally, packet reordering in an OpenFlow switch must conform
to the requirements of IEEE specifications, provided that the packets are processed by the same flow
entries, group bucket and meter band.
5.1.1 Pipeline Consistency
The OpenFlow pipeline is an abstraction that is mapped to the actual hardware of the switch. In some
cases, the OpenFlow switch is virtualised on the hardware, for example to support multiple OpenFlow
switch instances or in the case of an hybrid switch. Even if the OpenFlow switch is not virtualised, the
hardware typically will not correspond to the OpenFlow pipeline, for example OpenFlow assume packets
to be Ethernet, so non-Ethernet packets would have to be mapped to Ethernet, in another example some
switch may carry the VLAN information in some internal metadata while for the OpenFlow pipeline it
is logically part of the packet. Some OpenFlow switch may define logical ports implementing complex
encapsulations that extensively modify the packet headers. The consequence is that a packet on a link
or in hardware may be mapped differently in the OpenFlow pipeline.
However, the OpenFlow pipeline expect that the mapping to the hardware is consistent, and that the
OpenFlow pipeline behave consistently. In particular, this is what is expected :
16 © 2014; The Open Networking Foundation