OpenFlow协议解读

OpenFlow通信流程解读前言接触了这么久的SDN，OpenFlow协议前前后后也读过好多遍，但是一直没有时间总结一下自己的一些见解。

现在有时间了，就写一写自己对OpenFlow协议通信流程的一些理解。

SDN中Switch和controller在SDN中很重要的两个实体是Switch跟Controller。

Controller在网络中相当于上帝，可以知道网络中所有的消息，可以给交换机下发指令。

Switch就是一个实现Controller指令的实体，只不过这个交换机跟传统的交换机不一样，他的转发规则由流表指定，而流表由控制器发送。

switch组成与传统交换机的差异switch组成switch由一个Secure Channel和一个flow table组成，of1.3之后table变成多级流表，有256级。

而of1.0中table只在table0中。

∙Secure Channel是与控制器通信的模块，switch和controller之间的连接时通过socket 连接实现。

∙Flow table里面存放这数据的转发规则，是switch的交换转发模块。

数据进入switch 之后，在table中寻找对应的flow进行匹配，并执行相应的action，若无匹配的flow 则产生packet_in（后面有讲）of中sw与传统交换机的差异∙匹配层次高达4层，可以匹配到端口，而传统交换机只是2层的设备。

∙运行of协议，实现许多路由器的功能，比如组播。

∙求补充！！（如果你知道，请告诉我，非常感谢！）OpenFlow的switch可以从以下方式获得∙实体of交换机，目前市场上有一些厂商已经制造出of交换机，但是普遍反映价格较贵！性能最好。

∙在实体机上安装OVS，OVS可以使计算机变成一个OpenFlow交换机。

性能相对稳定。

∙使用mininet模拟环境。

可以搭建许多交换机，任意拓扑，搭建拓扑具体教程本博客有一篇。

性能依赖虚拟机的性能。

controller组成控制器有许多种，不同的语言，如python写的pox,ryu，如java写的floodlight等等。

从功能层面controller分为以下几个模块：∙底层通信模块：OpenFlow中目前controller与switch之间使用的是socket连接，所以控制器底层的通信是socket。

∙OpenFlow协议。

socket收到的数据的处理规则需按照OpenFlow协议去处理。

∙上层应用：根据OpenFlow协议处理后的数据，开发上层应用，比如pox中就l2_learning,l3_learning等应用。

更多的应用需要用户自己去开发。

OpenFlow通信流程以下教程环境为：mininet+自编简单控制器+scapy封装建立连接首先启动mininet，mininet会自行启动一个default拓扑，你也可以自己建立你的拓扑。

sw 建立完成之后，会像controllerIP:controllerport发送数据。

controller启动之后，监听指定端口，默认6633，但是好像以后的都改了，因为该端口被其他协议占用。

3次握手之后，建立连接，这个是底层的通信，是整一套系统的基础设施。

OFPT_HELLO创建socket之后，sw跟controller会彼此发送hello数据包。

∙目的：协议协商。

∙内容：本方支持的最高版本的协议∙成果：使用双方都支持的最低版本协议。

∙成功：建立连接∙失败：OFPT_ERROR (TYPE:OFPT_HELLO_FAILED,CODE =0),终止连接。

OFPT_ERROR说到OFPT_ERROR,我们不妨先了解一下。

如TYPE:0 CODE:0为：OFPHFC_INCOMPATIBLE具体对应的关系，请自行查看OF协议。

OFPT_ECHO∙分类：对称信息OFPT_ECHO_REQUEST, OFPT_ECHO_REPLY∙作用：查询连接状态，确保通信通畅。

当没有其他的数据包进行交换时，controller会定期循环给sw发送OFPT_ECHO_REQUEST。

OFPT_FEATURES当sw跟controller完成连接之后，控制器会向交换机下发OFPT_FEATYRES_REQUEST的数据包，目的是请求交换机的信息。

∙发送时间：连接建立完成之后∙发送数据：OFPT_FEATURES_REQUEST∙对称数据：OFPT_FEATURES_REPLY∙目的：获取交换机的信息OFPT_FEATURES_REQUEST∙TYPE=5∙Without dataOFPT_FEATURES_REPLY∙TYPE =6∙[0:8]为header∙[8:32]长度24byte为sw的featuresfeatures里面提取相关的信息，如dpid,port_no，等在整个通信过程中多次被用到的重要数据。

所以，对这两个数据结构了然于心，对于研究OpenFlow来说，至关重要。

每一次交换机连到控制器，都会收到控制器的features_request,当sw将自己的features回复给控制器之后，控制器就对交换机有了一个全面的了解，从而为后面的控制提供的控制信息。

OFPT_PACKET_IN在控制器获取完交换机的特性之后，交换机开始处理数据。

对于进入交换机而没有匹配流表，不知道如何操作的数据包，交换机会将其封装在packet_in 中发给controller。

包含在packet_in中的数据可能是很多种类型，arp和icmp是最常见的类型。

当然产生packet_in的原因不止一种，产生packet_in的原因主要有一下两种：∙OFPR_NO_MATCH∙OFPR_ACTION无法匹配的数据包会产生packet_in,action也可以指定将数据包发给packet_in,也就是说我们可以利用这一点，将需要的数据包发给控制器。

packet_in事件之后，一般会触发两类事件：∙packet_out∙flow_mod如果是广播包，如arp，控制器一般会将其包装起来，封装成packet_out数据包，将其发给交换机，让其flood,flood操作是将数据包往除去in_port以外的所有端口发送数据包。

OFPT_PACKET_OUT很多人不是特别了解packet_out的作用。

∙作用：通过控制器发送交换机希望发送的数据∙例子：当一个没有匹配上流表项的数据上报控制器时，控制器可以下发packet_out，指定交换机对该数据包做泛洪或丢弃动作。

当packet_out中的buffer_id=-1时，指明该数据并不在交换机的buffer中，而在packet_out 的data。

当buffer_id不为-1时，指明要操作的数据包是交换机中该buffer_id的数据。

OFPT_FLOW_MODOFPT_FLOW_MOD是整一个OpenFlow协议中最重要的数据结构。

OFPT_FLOW_MOD由header+match+flow_mod+action[]组成。

为了操作简单，以下的结构是将wildcards和match分开的形式，形成两个结构，在编程的时候能更方便一些。

由于这个数据包很重要，所以，我将把这个数据包仔细拆分解读。

header是所有数据包的报头，有三个参数：∙type:类型∙length:整个数据包的长度∙xid：数据包的编号比如ofp_flow_mod的type就是14，具体的哪一种数据的类型将在文章最后给出。

length最基本长度为72，每一个action长度为8。

所以长度必定为8的倍数才是一个正确的数据长度。

WILDCARDS这是从match域提取出来的前32bit。

在of1.0中这里的0，1意义跟我们平时接触的如子网掩码等意义相反，如OFPFW_NW_DST_MASK=0则表示全匹配目标IP。

如果为63，则表示不匹配IP。

为什么拿这个举例？原因就在于，他的长度是6bit，最大是63，需要将数值转变成对应2进制数值才是我们想要的匹配规则，且注意，1是忽略，0是匹配。

如果wildcards全0，则表示由match 精确指定，即所有12元组都匹配。

当然高兴的是，在1.3的时候，这个逻辑改成了正常的与逻辑。

即1为使能匹配，0为默认不匹配。

MATCH这个数据结构会出现在机会所有重要的数据包中，因为他存的就是控制信息。

如有packet_in引发的下发流表，则match部分应对应填上对应的数据，这样下发的流表才是正确的。

但是在下发的时候还需要注意许多细节，比如：∙并不是所有的数据包都有vlan_tag。

如0x0800就是纯IP，并没有携带vlan_tag，所以填充式应根据packet_in的具体情况填充。

∙并不是所有的数据都有四层端口，所以四层的源端口，目的端口都不是任何时候都能由packet_in去填充的。

不去管就好了，默认的会填充一个默认值，匹配的时候不去匹配4层端口就没有问题。

FLOW_MOD两个时间参数idle_timeout & idle_timeout：∙idle_timeout:如值为10，则某条流在10秒之内没有被匹配，则删除，可以称之为活跃时间吧。

∙hard_timeout:如值为30，则30秒到达的时候，一定删除这条流，即使他还活跃，即被匹配。

prioritypriority是流的优先级的字段，字数越大则优先级越高，存放在号数越小的table中。

buffer_id由交换机指定的buffe_id,准确的说是由dpid指定的。

如果是手动下发的流，buffer_id应填-1，即0xffff,告诉交换机这个数据包并没有缓存在队列中。

out_port指定流的出口，但是这个出口并不是直接指导流转发的，至少我是这么觉得，指导流转发的出口会在action里面添加，这个端口是为了在flow_removed的时候查询，并返回控制器的作用。

（求纠正！）有一些端口是很特殊的，如flood，local等。

具体分类如下：如果你不知道端口是多少，最好填flood,也就是0xfffb。

flags在上面的注释中也说得比较清楚了。

如果没有特殊用处，请将他置1，因为这样能让交换机在删除一条流的时候给交换机上报flow_removed信息。

ACTIONaction是OpenFlow里面最重要的结构。

对，他也是最重要的。

每一条流都必须指定必要的action,不然匹配上之后，没有指定action，交换机会默认执行drop操作。

action有2种类型：∙必备行动: Forward and Drop∙选择行动:FLOOD,NALMAL 等如添加output就是一个必须要添加的action.每一个action最好有一个action_header(),然后再接一个实体。