Openflow协议通信流程解读

1、Openflow协议通信流程解读前言接触了这么久的SDN，Openflow协议前前后后也读过好多遍，但是一直没有时间总结一下自己的一些见解。现在有时间了，就写一写自己对Openflow协议通信流程的一些理解。SDN中Switch和controller在SDN中很重要的两个实体是Switch跟Controller。Controller在网络中相当于上帝，可以知道网络中所有的消息，可以给交换机下发指令。Switch就是一个实现Controller指令的实体，只不过这个交换机跟传统的交换机不一样，他的转发规则由流表指定，而流表由控制器发送。switch组成与传统交换机的差异switch组成switc

2、h由一个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层，可以

3、匹配到端口，而传统交换机只是2层的设备。· 运行of协议，实现许多路由器的功能，比如组播。· 求补充！（如果你知道，请告诉我，非常感谢！）openflow的switch可以从以下方式获得· 实体of交换机，目前市场上有一些厂商已经制造出of交换机，但是普遍反映价格较贵！性能最好。· 在实体机上安装OVS，OVS可以使计算机变成一个openflow交换机。性能相对稳定。· 使用mininet模拟环境。可以搭建许多交换机，任意拓扑，搭建拓扑具体教程本博客有一篇。性能依赖虚拟机的性能。controller组成控制器有许多种，不同的语言，如python

4、写的pox,ryu，如java写的floodlight等等。从功能层面controller分为以下几个模块：· 底层通信模块：openflow中目前controller与switch之间使用的是socket连接，所以控制器底层的通信是socket。· openflow协议。socket收到的数据的处理规则需按照openflow协议去处理。· 上层应用：根据openflow协议处理后的数据，开发上层应用，比如pox中就l2_learning,l3_learning等应用。更多的应用需要用户自己去开发。Openflow通信流程以下教程环境为：mininet+自编简单控

5、制器建立连接首先启动mininet，mininet会自行启动一个default拓扑，你也可以自己建立你的拓扑。sw建立完成之后，会像controllerIP:controllerport发送数据。controller启动之后，监听指定端口，默认6633，但是好像以后的都改了，因为该端口被其他协议占用。3次握手之后，建立连接，这个是底层的通信，是整一套系统的基础设施。OFPT_HELLO创建socket之后，sw跟controller会彼此发送hello数据包。· 目的：协议协商。· 内容：本方支持的最高版本的协议· 成果：使用双方都支持的最低版本协议。·

6、 成功：建立连接· 失败：OFPT_ERROR (TYPE:OFPT_HELLO_FAILED,CODE =0),终止连接。OFPT_ERROR说到OFPT_ERROR,我们不妨先了解一下。ofp_error_type = 0: "OFPET_HELLO_FAILED", 1: "OFPET_BAD_REQUEST", 2: "OFPET_BAD_ACTION", 3: "OFPET_FLOW_MOD_FAILED", 4: "OFPET_PORT_MOD_FAILED", 5: &q

7、uot;OFPET_QUEUE_OP_FAILED"错误类型如上所示。对应的type还会有对应的code.所以报错的格式为：OFPT_ERRORTYPE: CODE:PAYLOAD具体的错误信息。如 TYPE:0 CODE:0为：*OFPHFC_INCOMPATIBLE*具体对应的关系，请自行查看OF协议。OFPT_ECHO· 分类：对称信息 OFPT_ECHO_REQUEST, OFPT_ECHO_REPLY· 作用：查询连接状态，确保通信通畅。当没有其他的数据包进行交换时，controller会定期循环给sw发送OFPT_ECHO_REQUEST。OFPT_F

8、EATURES当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

9、为sw的features· 32:长度与端口数成正比，存放port的信息。每一个port信息长度为48byte。· class ofp_features_reply(Packet):· name = "OpenFlow Switch Features Reply"· fields_desc= BitFieldLenField('datapath_id', None, 64, length_of='varfield'),· BitFieldLenField('n_buffers'

10、, None, 32, length_of='varfield'),· XByteField("n_tables", 0),· X3BytesField("pad", 0),· #features· BitField("NOT DEFINED", 0, 24),· BitField("OFPC_ARP_MATCH_IP", 0, 1), #1<<7 Match IP address in ARP packets· BitFiel

11、d("OFPC_QUEUE_STATS", 0, 1), #1<<6 Queue statistics· BitField("OFPC_IP_STREAM", 0, 1), #1<<5 Can reassemble IP fragments· BitField("OFPC_RESERVED", 0, 1), #1<<4 Reserved, must be zero· BitField("OFPC_STP", 0, 1), #1<<3 80

12、2.1d spanning tree· BitField("OFPC_PORT_STATS", 0, 1), #1<<2 Port statistics· BitField("OFPC_TABLE_STATS", 0, 1), #1<<1 Table statistics· BitField("OFPC_FLOW_STATS", 0, 1), #1<<0 Flow statistics· BitFieldLenField('actions',

13、None, 32, length_of='varfield'),· bind_layers( ofp_header, ofp_features_reply, type=6 )以上的结构是交换机的features,紧跟在后面的是端口的结构：class ofp_phy_port(Packet): name = "OpenFlow Port" fields_desc= ShortEnumField("port_no", 0, ofp_port), MACField("hw_addr", "00:00:00

14、:00:00:00"), StrFixedLenField("port_name", None, length=16), BitField("not_defined", 0, 25), BitField("OFPPC_NO_PACKET_IN", 0, 1), BitField("OFPPC_NO_FWD", 0, 1), BitField("OFPPC_NO_FLOOD", 0, 1), BitField("OFPPC_NO_RECV_STP",0, 1), Bi

15、tField("OFPPC_NO_RECV", 0, 1), BitField("OFPPC_NO_STP", 0, 1), BitField("OFPPC_PORT_DOWN", 0, 1), #uint32_t for state BitField("else", 0, 31), BitField("OFPPS_LINK_DOWN", 0, 1), #uint32_t for Current features BitField("not_defined", 0, 20),

16、 BitField("OFPPF_PAUSE_ASYM", 0, 1), BitField("OFPPF_PAUSE", 0, 1), BitField("OFPPF_AUTONEG", 0, 1), BitField("OFPPF_FIBER", 0, 1), BitField("OFPPF_COPPER", 0, 1), BitField("OFPPF_10GB_FD", 0, 1), BitField("OFPPF_1GB_FD", 0, 1), B

17、itField("OFPPF_1GB_HD", 0, 1), BitField("OFPPF_100MB_FD", 0, 1), BitField("OFPPF_100MB_HD", 0, 1), BitField("OFPPF_10MB_FD", 0, 1), BitField("OFPPF_10MB_HD", 0, 1), #uint32_t for features being advised by the port BitField("advertised", 0,

18、32), #uint32_t for features supported by the port BitField("supported", 0, 32), #uint32_t for features advertised by peer BitField("peer", 0, 32)交换机和端口的配置信息在整一个通信过程起着至关的作用，因为所有关于的操作都需要从features里面提取相关的信息，如dpid,port_no，等在整个通信过程中多次被用到的重要数据。所以，对这两个数据结构了然于心，对于研究openflow来说，至关重要。每一次交换机连

19、到控制器，都会收到控制器的features_request,当sw将自己的features回复给控制器之后，控制器就对交换机有了一个全面的了解，从而为后面的控制提供的控制信息。OFPT_PACKET_IN在控制器获取完交换机的特性之后，交换机开始处理数据。对于进入交换机而没有匹配流表，不知道如何操作的数据包，交换机会将其封装在packet_in中发给controller。包含在packet_in中的数据可能是很多种类型，arp和icmp是最常见的类型。当然产生packet_in的原因不止一种，产生packet_in的原因主要有一下两种：· OFPR_NO_MATCH· OF

20、PR_ACTION无法匹配的数据包会产生packet_in,action也可以指定将数据包发给packet_in,也就是说我们可以利用这一点，将需要的数据包发给控制器。packet_in事件之后，一般会触发两类事件：· packet_out· flow_mod如果是广播包，如arp，控制器一般会将其包装起来，封装成packet_out数据包，将其发给交换机，让其flood,flood操作是将数据包往除去in_port以外的所有端口发送数据包。OFPT_PACKET_OUT很多人不是特别了解packet_out的作用。· 作用：通过控制器发送交换机希望发送的数据&#

21、183; 例子：arp在广播的时候，在ofsw中不能直接将arp广播，而是，将其封装在packet_out里面，交换机泛洪的是packet_out。我个人观点，这个数据包，是一个兼容性之的数据包，为了实现信令，不得不处理arp，但是arp又不能直接处理，所以将其封装在packet_out,从而能够在of的sw中传播，从而在openflow里实现arp等IP网的功能。OFPT_FLOW_MODOFPT_FLOW_MOD是整一个Openflow协议中最重要的数据结构，没有之一。OFPT_FLOW_MOD由header+match+flow_mod+action组成。为了操作简单，以下的结构是将wi

22、ldcards和match分开的形式，形成两个结构，在编程的时候能更方便一些。由于这个数据包很重要，所以，我将把这个数据包仔细拆分解读。flow_mod = of.ofp_header(type=14,length=72)/of.ofp_flow_wildcards(OFPFW_NW_TOS=1, OFPFW_DL_VLAN_PCP=1, OFPFW_NW_DST_MASK=0, OFPFW_NW_SRC_MASK=0, OFPFW_TP_DST=1, OFPFW_TP_SRC=1, OFPFW_NW_PROTO=1, OFPFW_DL_TYPE=1, OFPFW_DL_VLAN=1, OFP

23、FW_IN_PORT=1, OFPFW_DL_DST=1, OFPFW_DL_SRC=1) /of.ofp_match(in_port=msg.payload.payload.payload.in_port, dl_src=pkt_parsed.src, dl_dst=pkt_parsed.dst, dl_type=pkt_parsed.type, dl_vlan=pkt_parsed.payload.vlan, nw_tos=pkt_parsed.payload.tos, nw_proto=pkt_to, nw_src=pkt_parsed.payload

24、.src, nw_dst=pkt_parsed.payload.dst, tp_src = 0, tp_dst = 0) /of.ofp_flow_mod(cookie=0, command=0, idle_timeout=10, hard_timeout=30, out_port=msg.payload.payload.payload.payload.port, buffer_id=buffer_id, flags=1)OFP_HEADERheader是所有数据包的报头，有三个参数：· type:类型· length:整个数据包的长度· xid：数据包的编号比如

25、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精

26、确指定，即所有12元组都匹配。当然高兴的是，在1.3的时候，这个逻辑改成了正常的与逻辑。即1为使能匹配，0为默认不匹配。MATCH这个数据结构会出现在几乎所有重要的数据包中，因为他存的就是控制信息。如有packet_in引发的下发流表，则match部分应对应填上对应的数据，这样下发的流表才是正确的。但是在下发的时候还需要注意许多细节，比如：· 并不是所有的数据包都有vlan_tag。如0×0800就是纯IP，并没有携带vlan_tag，所以填充式应根据packet_in的具体情况填充。· 并不是所有的数据都有四层端口，所以四层的源端口，目的端口都不是任何时候都能由

27、packet_in去填充的。不去管就好了，默认的会填充一个默认值，匹配的时候不去匹配4层端口就没有问题。FLOW_MOD这里面的信息也是至关重要的。class ofp_flow_mod(Packet): name = "OpenFlow Flow Modify" fields_desc= BitField("cookie", 0, 64), #Opaque controller-issued identifier ShortEnumField("command", 0, ofp_flow_mod_command), ShortFiel

28、d("idle_timeout", 60), ShortField("hard_timeout", 0), ShortField("priority", 0), IntField("buffer_id", 0), ShortField("out_port", 0), #flags are important, the 1<<0 bit is OFPFF_SEND_FLOW_REM, send OFPT_FLOW_REMOVED #1<<1 bit is OFPFF_CHE

29、CK_OVERLAP, checking if the entries' field overlaps(among same priority) #1<<2 bit is OFPFF_EMERG, used only switch disconnected with controller) ShortField("flags", 0)command里面的类型决定了flow_mod的操作是添加，修改还是删除等。类型如下ofp_flow_mod_command = 0: "OFPFC_ADD", # New flow 1: "O

30、FPFC_MODIFY", # Modify all matching flows 2: "OFPFC_MODIFY_STRICT", # Modify entry strictly matching wildcards 3: "OFPFC_DELETE", # Delete all matching flows 4: "OFPFC_DELETE_STRICT" # Strictly match wildcards and priority例如：如果要添加一条新流，command=0。两个时间参数idle_timeout &

31、amp; idle_timeout：· idle_timeout:如值为10，则某条流在10秒之内没有被匹配，则删除，可以称之为活跃时间吧。· hard_timeout:如值为30，则30秒到达的时候，一定删除这条流，即使他还活跃，即被匹配。prioritypriority是流的优先级的字段，字数越大则优先级越高，存放在号数越小的table中。buffer_id由交换机指定的buffei_id,准确的说是由dpid指定的。如果是手动下发的流，buffer_id应填-1，即0xffff,告诉交换机这个数据包并没有缓存在队列中。out_port指定流的出口，但是这个出口并不是直

32、接指导流转发的，至少我是这么觉得，指导流转发的出口会在action里面添加，这个端口是为了在flow_removed的时候查询，并返回控制器的作用。（求纠正！）有一些端口是很特殊的，如flood，local等。具体分类如下：ofp_port = 0xff00: "OFPP_MAX", 0xfff8: "OFPP_IN_PORT", 0xfff9: "OFPP_TABLE", 0xfffa: "OFPP_NORMAL", 0xfffb: "OFPP_FLOOD", 0xfffc: "OF

33、PP_ALL", 0xfffd: "OFPP_CONTROLLER", 0xfffe: "OFPP_LOCAL", 0xffff: "OFPP_NONE"如果你不知道端口是多少，最好填flood,也就是0xfffb。flags在上面的注释中也说得比较清楚了。如果没有特殊用处，请将他置1，因为这样能让交换机在删除一条流的时候给交换机上报flow_removed信息。ACTIONaction是openflow里面最重要的结构。对，他也是最重要的。每一条流都必须指定必要的action,不然匹配上之后，没有指定action，交换机会

34、默认执行drop操作。action有2种类型：· 必备行动: Forward and Drop· 选择行动:FLOOD,NALMAL 等如添加output就是一个必须要添加的action.每一个action最好有一个action_header(),然后再接一个实体。如：ofp_action_header(type=0)/ofp_action_output(type =0, port =oxfffb,len =8)具体的action类型如下：ofp_action_type = 0: "OFPAT_OUTPUT", 1: "OFPAT_SET_VL

35、AN_VID", 2: "OFPAT_SET_VLAN_PCP", 3: "OFPAT_STRIP_VLAN", 4: "OFPAT_SET_DL_SRC", 5: "OFPAT_SET_DL_DST", 6: "OFPAT_SET_NW_SRC", 7: "OFPAT_SET_NW_DST", 8: "OFPAT_SET_NW_TOS", 9: "OFPAT_SET_TP_SRC", 10: "OFPAT_SET_

36、TP_DST", 11: "OFPAT_ENQUEUE" action不仅仅会出现在flow_mod中，也会出现在如stats_reply中。OFPT_BARRIER_REQUEST && REPLY这个数据包可以的作用很简单，交换机在收到OFPT_BARRIER_REQUEST的时候，会回复控制器一个OFPT_BARRIER_REPLY。我们默认数据下发的顺序不会在传输中发生变化，在进入消息队列之后处理也是按照FIFO进行的，那么只要在flow_mod之后发送这个数据，当收到reply之后，交换机默认flow已经写成功。也许你会问他只是保证了fl

37、ow_mod命令执行了，写入的结果如何并没有保证，如何确定确实写入流表了呢？· 如果非逻辑错误，那么交换机在处理flow_mod的时候会报错。所以我们会知道写入结果。· 如果是逻辑错误，那么会写进去，但是逻辑错误应该是人的问题，所以barrier还是有他的功能的。OFPT_FLOW_REMOVED如果flow_mod的flags填成1，则该流在失效之后会回复控制器一条OFPT_FLOW_REMOVED信息。· 结构：header()/wildcards()/match()/flow_removed()· 作用：在流失效的时候回复控制器，并携带若干统计数据

38、。· class ofp_flow_removed(Packet):· name = "Openflow flow removed"· fields_desc = BitField("cookie", 0, 64),· BitField("priority", 0,16),· BitField("reason", 0, 8),· ByteField("pad", None),· BitField("duration_

39、sec", 0, 32),· BitField("duration_nsec", 0, 32),· BitField("idle_timeout", 0, 16),· ByteField("pad", 0),· ByteField("pad", 0),· BitField("packet_count", 0, 64),· BitField("byte_count", 0, 64) 其实的duration_s

40、ec是流存在的时间，单位为秒，duration_nsec单位为纳秒。OFPT_STATS_REQUEST && REPLY以上的数据都是通信过程中必须的部分。还有一些数据包是为了某些目的而设计的，如OFPT_STATS_REQUEST && REPLY可以获得统计信息，我们可以利用统计信息做的事情就太多了。如：负载平衡， 流量监控等基于流量的操作。OFPT_STATS_REQUESTOFPT_STATS_REQUEST类型有很多，回复的类型也很多。class ofp_stats_request(Packet): name = "OpenFlow Sta

41、ts Request" fields_desc= ShortEnumField("type", 0, ofp_stats_types), ShortField("flag", 0)Type· 0:请求交换机版本信息，制造商家等信息。· 1:单流请求信息· 2:多流请求信息· 3:流表请求信息· 4:端口信息请求· 5:队列请求信息· 6:vendor请求信息，有时候没有定义。· msg = 0: of.ofp_header(type = 16, length = 1

42、2)/of.ofp_stats_request(type = 0), #Type of OFPST_DESC (0) · 1: of.ofp_header(type = 16, length = 56)/of.ofp_stats_request(type =1)/ofp_flow_wildcards/ofp_match/of.ofp_flow_stats_request(out_port = ofp_flow_mod.out_port), #flow stats· 2: of.ofp_header(type = 16, length =56)/of.ofp_stats_re

43、quest(type = 2)/ofp_flow_wildcards/of.ofp_match/of.ofp_aggregate_stats_request(), # aggregate stats request· 3: of.ofp_header(type = 16, length = 12)/of.ofp_stats_request(type = 3), #Type of OFPST_TABLE (0) · 4: of.ofp_header(type = 16, length =20)/of.ofp_stats_request(type = 4)/of.ofp_por

44、t_stats_request(port_no = port), # port stats request · 5: of.ofp_header(type = 16, length =20)/of.ofp_stats_request(type =5)/of.ofp_queue_stats_request(), #queue request· 6: of.ofp_header(type = 16, length = 12)/of.ofp_stats_request(type = 0xffff) #vendor request OFPT_STATS_REPLY每一种请求信息都会

45、对应一种回复信息。我们只介绍最重要的flow_stats_reply。· 结构：header(type=17)/reply_header()/flow_stats/wildcards/match/ flow_stats_data· 作用：携带流的统计信息，如通过的数据包个数，字节数。ofp_flow_stats(body4:8)里面会有的table_id字段表明该流存放在哪一个流表里。flow_stats_data里面有packet_count和byte_count是最有价值的字段，流量统计就是由这两个字段提供的信息。如想统计某条流的速率：前后两个reply的字节数相减除以

46、duration_time只差就可以求得速率由速率我们可以做很多基于流量的app，如流量监控，负载均衡等等。值得注意的是，在这些数据之后，其实还有一些action,但是目前我还没有查看这些action到底是干什么用的。后续写到这里，我使用到的数据包都写了一遍，其他的报文其实道理也是一样的。如OFPT_GET_CONFIG_REQUEST和REPLY，道理应该和stats一样，只是数据结构不一样罢了。不再多说。最后把我们用的一些比较多的信息帖出来让大家更好的学习。ERROR在调试的过程中遇到错误是再所难免的，前面也提到了error的结构。这里就贴一下type跟code吧。Typeofp_erro

47、r_type = 0: "OFPET_HELLO_FAILED", 1: "OFPET_BAD_REQUEST", 2: "OFPET_BAD_ACTION", 3: "OFPET_FLOW_MOD_FAILED", 4: "OFPET_PORT_MOD_FAILED", 5: "OFPET_QUEUE_OP_FAILED"Code：ofp_hello_failed_code = 0: "OFPHFC_INCOMPATIBLE", 1: "OFP

48、HFC_EPERM"ofp_bad_request_code = 0: "OFPBRC_BAD_VERSION", 1: "OFPBRC_BAD_TYPE", 2: "OFPBRC_BAD_STAT", 3: "OFPBRC_BAD_VENDOR", 4: "OFPBRC_BAD_SUBTYPE", 5: "OFPBRC_EPERM", 6: "OFPBRC_BAD_LEN", 7: "OFPBRC_BUFFER_EMPTY"

49、, 8: "OFPBRC_BUFFER_UNKNOWN"ofp_bad_action_code = 0: "OFPBAC_BAD_TYPE", 1: "OFPBAC_BAD_LEN", 2: "OFPBAC_BAD_VENDOR", 3: "OFPBAC_BAD_VENDOR_TYPE", 4: "OFPBAC_BAD_OUT_PORT", 6: "OFPBAC_BAD_ARGUMENT", 7: "OFPBAC_EPERM", #pe

50、rmissions error 8: "OFPBAC_TOOMANY", 9: "OFPBAC_BAD_QUEUE"ofp_flow_mod_failed_code = 0: "OFPFMFC_ALL_TABLES_FULL", 1: "OFPFMFC_OVERLAP", 2: "OFPFMFC_EPERM", 3: "OFPFMFC_BAD_EMERG_TIMEOUT", 4: "OFPFMFC_BAD_COMMAND", 5: "OFPFMF

51、C_UNSUPPORT"ofp_port_mod_failed_code = 0: "OFPPMFC_BAD_PORT", 1: "OFPPFMC_BAD_HW_ADDR"ofp_queue_op_failed_code = 0: "OFPQOFC_BAD_PORT", 1: "OFPQOFC_BAD_QUEUE"第二章 理论基础2.1软件定义网络SDN软件定义网络（英语：Software-defined networking，缩写为SDN），一种网络虚拟化（Network virtualization）

52、技术，由美国史丹佛大学Clean State提出。利用OpenFlow协定，把路由器的控制平面（control plane）从数据平面（data plane）中分离出来，以软件方式实做。这个架构可以让网络管理员，在不更动硬件装置的前提下，以中央控制方式，用程式重新规划网络，为控制网络流量提供了新的方法，也提供了核心网络及应用创新的良好平台。2.2 openflow网络架构OpenFlow网络由OpenFlow交换机、FlowVisor和Controller三部分组成。OpenFlow交换机进行数据层的转发；FlowVisor对网络进行虚拟化；Controller对网络进行集中控制，实现控制层的功能。如下图所示：2.2.1 openflow交换机OpenFlow交换机由流表、安全通