A switch with a single flow table is specified in Specification 1.0.0. But the problem with this single-table implementation is that it does not scale. To remedy the limitations of a single-table switch, 1.1.0 introduced multiple tables and a mechanism, call pipeline processing which allow the user to create a hierarchy of processing using a sort of "if then goto" logic. As you could show the following picture.
The OpenFlow pipeline is a series of flow tables, number sequentially starting with 0. All incoming packets to the switch must be processed through table 0, and then may be forwarded to some numerically higher table along with metadata that can be matched at the next table.
The following picture illustrates how pipeline processing works. When a packet arrives on some port, the ingress port is recorded and the packet is sent to flow table 0. Ac Action Set is associated with the flow, which is initially an empty set. If a matching flow entry is found, the associated instructions in that entry are either executed or add to the Action set.
The process is repeated at each table, and after the last table in the pipeline has processed the packet, the instructions in the Action Set are executed sequentially.
A table-miss occurs if a packet does not match any flow entry at a given table. If a Table-miss entry is not included in the table, the default action when no match is found in the table is to drop the packet.
The single pipeline process illustrated in the last Figure is linear. But the follwoing picture shows how different match conditions can point to different tables, creating a complex series of processing actions.
The OpenFlow pipeline is a series of flow tables, number sequentially starting with 0. All incoming packets to the switch must be processed through table 0, and then may be forwarded to some numerically higher table along with metadata that can be matched at the next table.
The following picture illustrates how pipeline processing works. When a packet arrives on some port, the ingress port is recorded and the packet is sent to flow table 0. Ac Action Set is associated with the flow, which is initially an empty set. If a matching flow entry is found, the associated instructions in that entry are either executed or add to the Action set.
The process is repeated at each table, and after the last table in the pipeline has processed the packet, the instructions in the Action Set are executed sequentially.
A table-miss occurs if a packet does not match any flow entry at a given table. If a Table-miss entry is not included in the table, the default action when no match is found in the table is to drop the packet.
The single pipeline process illustrated in the last Figure is linear. But the follwoing picture shows how different match conditions can point to different tables, creating a complex series of processing actions.
No comments:
Post a Comment