这次我们主要讨论下OpenFlow Switch的核心组件之一——Flow Tables，以了解其内部的 matching 以及 action handling 机制。下文将会分为几个部分来逐步详述OpenFlow Switch内部数据包的流转机制。
1、Pipeline Processing
遵循OpenFlow Switch规范的OpenFlow交换机大致分为 OpenFlow-only 和 OpenFlow-hybrid 两类。OpenFlow-only 交换机仅仅只支持OpenFlow规范定义的操作，所有经过该类交换机的数据包仅仅只能被 OpenFlow Pipeline 处理，而不能被其他方式处理。而 OpenFlow-hybrid 交换机既支持OpenFlow规范定义的操作，又支持传统交换机规定的操作，比如传统的L2交换、VLAN隔离、L3路由、ACL以及QoS处理等。该类交换机必须要提供一种除OpenFlow Switch规范约定的能将经过它的数据包转发到OpenFlow Pipeline处理，也能转发到Normal Pipeline处理特性之外的分类机制，比如交换机可以根据数据包的VLAN tag或者ingress port来决定使用某个Pipeline来处理，或者可能将所有的数据包直接转发到OpenFlow Pipeline处理。OpenFlow-hybrid 交换机也可能将来自于 OpenFlow Pipeline 处理后的数据包通过 NORMAL 或者 FLOOD Reserved Port 转发到 Normal Pipeline 继续处理。
OpenFlow Pipeline由多个Flow Tables组成，而每个Flow Table又包含有多个Flow Entries。Pipeline Processing定义了数据包如何与这些Flow Tables进行交互，一个OpenFlow Switch至少得有一个Flow Table，或者有多个。当Pipeline有多个Flow Tables时，这些Flow Tables是按照数字顺序排列的，起始索引号从 0 开始，任何进入到OpenFlow Switch的数据包都会从Pipeline的第一个Flow Table，即 Table 0 开始处理，后续的Flow Table可能会被使用到，而这依赖于Table 0中匹配成功的Flow Entry的输出结果。
当一个数据包被一个Flow Table处理时，数据包会被逐次地依据Priority与该Flow Table里的所有Flow Entry进行匹配，当发现匹配成功的Flow Entry时，该Flow Entry相关联的Instructions Set将会被执行，这些Instructions可能会将该数据包显示地直接转发到后续的其他Flow Table里（通过Goto指令）继续处理，在那里继续采取同样的方式来处理数据包。这里需要注意的是，Flow Entry只会将数据包继续往前（往索引号比当前大的Flow Table）转发，而不会倒序转发，因此，OpenFlow Pipeline的最后一个Flow Table不能再包含Goto指令，如果某个匹配成功的Flow Entry不能将数据包继续转发到后续的Flow Table，那么整个Pipeline Processing将在此终止，此时与该数据包关联的Actions将会被执行，通常是数据包被转发走。
假若一个数据包在一个Flow Table里没有发现能够匹配成功的Flow Entry，那么这叫作一次Table Miss，至于发生Table Miss后的动作取决于这个Flow Table的配置：1）直接丢弃，2）继续转发给后续的Flow Table，3）封装成 packet-in 消息发送给Remote Controller。
2、Flow Table
一个Flow Table大致包含如下几部分：
Match Fields：匹配域，可能包含ingress port、数据包头信息以及前继Flow Table传过来的Metadata值域等
Priority：匹配优先级
Counters：计数器，统计与该Flow Entry成功匹配的包数量
Instructions：指令集，应用到与该Flow Entry成功匹配的数据包
Timeouts：在该Flow Entry过期前的最大有效时间或者空闲时间
Cookie：被Remote Controller用来筛选Flow Statistics、Flow Modification或者Flow Deletion行为的指示值
一个Flow Entry在Flow Table中通过Match Fields和Priority两个字段来唯一标识（或称为联合主键）。这里注意，每个Flow Table中可能会有一个Table Miss Flow Entry，它是专门用来处理该Flow Table中没有其他Flow Entry能否匹配成功的数据包的，它的特点是它的Match Fields能够匹配任何数据包，并且Priority一定是0。
3、Flow Removal
Flow Entry可以通过三种方式从Flow Table里被移除：1）通过Remote Controller直接发送移除Flow Entry的消息，2）通过OpenFlow Switch的过期机制，3）OpenFlow Switch的逐出机制。OpenFlow Switch过期机制的运行行为独立于Remote Controller，仅依赖于当前Flow Entries的状态和配置。每一个Flow Entry有一个与之关联的 idle_timeout 和 hard_timeout，如果 hard_timeout 值不为 0 ，那么OpenFlow Switch需要记住这条Flow Entry的生成时间，当其生存时间达到指定的 hard_timeout 时间时，将被逐出Flow Table，而不管之前有多少个数据包与之成功匹配；如果 idle_timeout 值不为 0 ，那么OpenFlow Switch需要记住最后一次与该Flow Entry成功匹配的时间，当超过指定 idle_timeout 时间仍未有能成功匹配的数据包，那么该Flow Entry将会被逐出Flow Table。
Remote Controller也可以发送 Flow Deletion 消息（OFPFC_DELETE 或者 OFPFC_DELETE_STRICT）给OpenFlow Switch；Flow Entries 也可能是由于Group或者Meter的移除而被移除。
当OpenFlow Switch需要回收资源时，Flow Entries 也有可能被逐出Flow Table。该机制对于OpenFlow Switch实现者来说是一个可选的特性，其必须按照规范来决定哪些Flow Entries被逐出，可能会依照Flow Entry参数、资源映射关系或者其他内部约束等。
当一个Flow Entry会移除时，OpenFlow Switch必须检查该Flow Entry的 OFPFF_SEND_FLOW_REM 值，如果该值被设置了，那么必须发送一个Flow Removal消息给Remote Controller，每一个Flow Removal消息都包含一个完整的Flow Entry描述以及被移除的原因说明（过期、主要删除或者被逐出）、直到删除这刻该Flow Entry的生存时间以及统计数据等。