OpenFlow协议匹配流程演进
openflow 1.0
1.0匹配流程
作为第一个公示版本的OpenFlow协议，of1.0协议相对而言比较基础。of1.0的协议虽然表述的是单级流表的概念，但是在匹配流程图中就披露出多级流表的设计意图。或许openflow协议从始至终都打算设计多级流表，只是受限于当时的研究进度，所以在of1.0中介绍的是单级流表。of1.0详细介绍了设备解析数据包的过程，这也算是匹配中的一个环节吧。
包头解析
交换机接收到数据包后按照流程解析数据包，然后利用解析后的头部字段进行表查找。用于表查找的头部字段依赖于数据包的类型。解析数据包的过程如下所示：
1、初始化包头域，按照包头域的组成一一设置每个字段，其中入端口是接收数据包的物理端口。
2、如果数据包类型是VLAN（0x8100），那么就使用VLAN ID和PCP字段进行表查找。解封以太网类型为下面的以太网类型解析做准备。
3、（可选）如果是ARP数据包（0x0806），那么匹配字段就可能包含IP源和目的地址。
4、如果是IP数据包（0x800），那么匹配字段就会包含IP首部。如果IP数据包的分段偏移量不为0或者设置了多个分段bit位，那么将所有传输端口设为0。如果IP数据包在IP协议族中的编号为6或17(分别是TCP或UDP类型），那么匹配字段包含传输端口。如果编号为1（ICMP数据包）则包含Type和Code字段。
数据包解析后就开始匹配，从table 0 开始匹配，如果匹配成功则对该数据包执行相应的动作，更新相应的计数器。如果没有找到匹配项则将数据包交给控制器。
openflow 1.1 & 1.2
就匹配流程图而言，1.1与1.2匹配过程是一样的。从table0开始匹配，按照优先级高低依次匹配该流表中的流表项。如果匹配不成功则由流表决定是发送给控制器、发送给后续流表，还是丢弃。如果匹配成功则更新计数器，指令集（更新动作集、匹配字段、元数据），并且由指令决定是否继续查找后续流表，如果继续查找则按照更新后的匹配字段进行匹配，如果不继续查找流表则终止匹配并执行动作集。
1.2匹配流程
数据包只有与流表项中所有匹配项都匹配才算是匹配成功，如果一个流表的匹配项值为ANY则该流表项可以匹配包头域中的任意值。
从of1.2版本及以后，数据包解析流程图就略过了，毕竟随着版本升级of协议难度也越来越大，所涉及的东西也越来越多了，想必有些内容就不作赘述了。
openflow 1.3 & 1.4
of1.3匹配流程图与之前的版本相比多了一个table-miss流表项，事实上此前版本就已经存在table-miss概念了，只是没有在流程图中呈现出来而已。of1.3和1.4版本的匹配流程一致，都如下所述。
1.3匹配流程
首先解析进入设备的报文，然后从table 0开始匹配，按照优先级高低依次匹配该流表中的流表项，一个报文在一个流表中只会匹配上一条流表项。通常根据报文的类型，报文头的字段例如源MAC地址、目的MAC地址、源IP地址、目的IP地址等进行匹配，大部分匹配还支持掩码进行更精确、灵活的匹配。也可以通过报文的入端口或元数据信息来进行报文的匹配，一个流表项中可以同时存在多个匹配项，一个报文需要同时匹配流表项中所有匹配项才能匹配该流表项。报文匹配按照现有的报文字段进行，比如前一个流表通过apply actions改变了该报文的某个字段，则下一个表项按修改后的字段进行匹配。如果匹配成功，则按照指令集里的动作更新动作集，或更新报文/匹配集字段，或更新元数据和计数器。根据指令是否继续前往下一个流表，不继续则终止匹配流程执行动作集，如果指令要求继续前往下一个流表则继续匹配，下一个流表的ID需要比当前流表ID大。当报文匹配失败了，如果存在无匹配流表项（table miss）就按照该表项执行指令，一般是将报文转发给控制器、丢弃或转发给其他流表。如果没有table miss表项则默认丢弃该报文。
openflow 1.5
1.5匹配流程
OpenFlow1.5协议的匹配流程几乎没有改变，只是细化了action set的执行过程。其中着重细化了output动作。OpenFlow 1.5协议引进了Egress Tables，细化了output action，可以在输出端口处理数据包。当一个数据包输出到某个端口时，首先会从第一个egress table开始处理，由流表项定义处理方式并且转发给其他egress table。
此外，1.5协议还添加了一个数据包类型识别流程。之前版本的OpenFlow协议中表明交换机默认处理以太网数据包，1.5版本中交换机还可以处理PPP数据包。不过1.5协议中的数据包类型识别流程还处于研究阶段，每个交换机只能处理一种类型的数据包，相信后续协议中交换机必然可以同时处理多种数据包。
协议演进
从OpenFlow1.0到1.5，OpenFlow匹配流程在不断丰富，从中我们也可以琢磨出一丝OpenFlow协议的演进的痕迹。OpenFlow协议的发展演进一直都围绕着两个方面，一方面是增强控制面，让系统功能更丰富、更灵活；另一方面是增强转发层面，可以匹配更多的关键字，执行更多的动作。每一个后续版本的OpenFlow协议都在前一版本的基础上进行或多或少的改进，但是自OpenFlow1.1版本开始与之前版本不兼容，ONF为了保证产业界有一个稳定发展的平台，把OpenFlow1.0和1.3版本作为长期支持的稳定版本，因此一段时间内后续版本都要保持和稳定版本的兼容。
1.0版本中只有单流表，为了避免单流表膨胀，1.1版本采用多级流表，以流水线的形式提高数据包匹配效率。由于OpenFlow将所有的控制协议都集中到控制器中，导致控制器成为众矢之的，为了提高安全性和健壮性，1.2版本引进了多控制器的概念。为了处理多种类型的数据包，1.5版本添加了数据包类型识别流程。除此之外1.5还引进了egress table，原先由控制器指定output的相关操作，现在将这一功能下放到交换机中，一方面提高数据包的处理效率，另一方面改进OpenFlow“最初的偏激”。毕竟将所有控制功能都集中到控制器中是否合理还有待商榷，很明显的是这样的做法会导致控制器很累。OpenFlow正在一点一点摸索一个平衡点，既能保证控制器充分的控制器主权又让交换机有一定的自主功能。或许，最初的OpenFlow十分理想化，但是在其不断演进的过程中我们可以看出OpenFlow在不断向实际应用场景靠拢。
