![](https://csdnimg.cn/release/download_crawler_static/11802416/bg14.jpg)
OpenFlow Switch Specification Version 1.5.0
happens in two stages, ingress processing and egress processing. The separation of the two stages is
indicated by the first egress table (see 7.3.2), all tables with a number lower than the first egress table
must be used as ingress tables, and no table with a number higher than or equal to the first egress table
can be used as an ingress table.
Pipeline processing always starts with ingress processing at the first flow table: the packet must be
first matched against flow entries of flow table 0 (see Figure 3). Other ingress flow tables may be
used depending on the outcome of the match in the first table. If the outcome of ingress processing is
to forward the packet to an output port, the OpenFlow switch may perform egress processing in the
context of that output port. Egress processing is optional, a switch may not support any egress tables
or may not be configured to use them. If no valid egress table is configured as the first egress table (see
7.3.2), the packet must be process by the output port, and in most case the packet is forwarded out of
the switch. If a valid egress table is configured as the first egress table (see 7.3.2), the packet must be
matched against flow entries of that flow table, and other egress flow tables may be used depending on
the outcome of the match in that flow 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.5), 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 a
pipeline stage can not include the Goto-Table instruction. If the matching flow entry does not direct
packets to another flow table, the current stage of pipeline processing stops at this table, the packet is
processed with its associated action set and usually forwarded (see 5.6).
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.8).
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 buckets and meter bands.
20 © 2014; The Open Networking Foundation