Openflow协议通信流程解读.docx
《Openflow协议通信流程解读.docx》由会员分享，可在线阅读，更多相关《Openflow协议通信流程解读.docx（21页珍藏版）》请在冰豆网上搜索。
Openflow协议通信流程解读
Openflow协议通信流程解读
前言
接触了这么久的SDN，Openflow协议前前后后也读过好多遍，但是一直没有时间总结一下自己的一些见解。
现在有时间了，就写一写自己对Openflow协议通信流程的一些理解.
SDN中Switch和controller
在SDN中很重要的两个实体是Switch跟Controller.Controller在网络中相当于上帝，可以知道网络中所有的消息，可以给交换机下发指令。
Switch就是一个实现Controller指令的实体，只不过这个交换机跟传统的交换机不一样，他的转发规则由流表指定,而流表由控制器发送。
switch组成与传统交换机的差异
switch组成
switch由一个SecureChannel和一个flowtable组成，of1。
3之后table变成多级流表,有256级。
而of1。
0中table只在table0中。
∙SecureChannel是与控制器通信的模块，switch和controller之间的连接时通过socket连接实现.
∙Flowtable里面存放这数据的转发规则，是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+自编简单控制器
建立连接
首先启动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,我们不妨先了解一下。
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:
”OFPET_QUEUE_OP_FAILED"｝
错误类型如上所示.对应的type还会有对应的code。
所以报错的格式为：
OFPT_ERROR
TYPE:
CODE:
［PAYLOAD]具体的错误信息。
如TYPE：
0CODE:
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
∙Withoutdata
OFPT_FEATURES_REPLY
∙TYPE=6
∙［0:
8]为header
∙［8：
32]长度24byte为sw的features
∙［32：
］长度与端口数成正比,存放port的信息。
每一个port信息长度为48byte。
∙classofp_features_reply（Packet）:
∙name="OpenFlowSwitchFeaturesReply”
∙fields_desc=［BitFieldLenField（'datapath_id',None,64，length_of=’varfield’），
∙BitFieldLenField（’n_buffers’,None,32,length_of=’varfield'），
∙XByteField（”n_tables"，0），
∙X3BytesField（”pad”，0）,
∙#features
∙BitField（"NOTDEFINED"，0，24），
∙BitField（"OFPC_ARP_MATCH_IP"，0,1）,＃1<〈7MatchIPaddressinARPpackets
∙BitField（"OFPC_QUEUE_STATS"，0，1），＃1〈<6Queuestatistics
∙BitField（"OFPC_IP_STREAM”,0,1），#1<<5CanreassembleIPfragments
∙BitField（”OFPC_RESERVED”,0，1）,＃1〈<4Reserved,mustbezero
∙BitField（”OFPC_STP”,0,1）,＃1<<3802。
1dspanningtree
∙BitField（”OFPC_PORT_STATS",0，1），＃1<<2Portstatistics
∙BitField（"OFPC_TABLE_STATS”，0，1）,＃1〈〈1Tablestatistics
∙BitField（"OFPC_FLOW_STATS”,0,1）,#1〈〈0Flowstatistics
∙BitFieldLenField（'actions',None,32，length_of=’varfield'），
∙]
bind_layers（ofp_header,ofp_features_reply,type=6）
以上的结构是交换机的features,紧跟在后面的是端口的结构：
classofp_phy_port（Packet）：
name="OpenFlowPort"
fields_desc=[ShortEnumField（"port_no”,0,ofp_port），
MACField（”hw_addr”，”00:
00：
00：
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），
BitField（”OFPPC_NO_RECV"，0,1）,
BitField（"OFPPC_NO_STP”,0,1）,
BitField（"OFPPC_PORT_DOWN”,0，1）,
＃uint32_tforstate
BitField（”else",0，31）,
BitField（”OFPPS_LINK_DOWN",0,1）,
＃uint32_tforCurrentfeatures
BitField（"not_defined",0，20）,
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）,
BitField（"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_tforfeaturesbeingadvisedbytheport
BitField（”advertised”，0，32），
#uint32_tforfeaturessupportedbytheport
BitField（”supported”,0,32），
＃uint32_tforfeaturesadvertisedbypeer
BitField（”peer”，0，32）］
交换机和端口的配置信息在整一个通信过程起着至关的作用，因为所有关于的操作都需要从features里面提取相关的信息,如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的作用.
∙作用：
通过控制器发送交换机希望发送的数据
∙例子：
arp在广播的时候，在ofsw中不能直接将arp广播，而是，将其封装在packet_out里面,交换机泛洪的是packet_out。
我个人观点,这个数据包，是一个兼容性之的数据包，为了实现信令，不得不处理arp，但是arp又不能直接处理，所以将其封装在packet_out，从而能够在of的sw中传播，从而在openflow里实现arp等IP网的功能。
OFPT_FLOW_MOD
OFPT_FLOW_MOD是整一个Openflow协议中最重要的数据结构，没有之一.
OFPT_FLOW_MOD由header+match+flow_mod+action［]组成。
为了操作简单，以下的结构是将wildcards和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，
OFPFW_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_parsed.payload.proto,
nw_src=pkt_parsed。
payload.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_HEADER
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。
如0×0800就是纯IP，并没有携带vlan_tag，所以填充式应根据packet_in的具体情况填充。
∙并不是所有的数据都有四层端口，所以四层的源端口,目的端口都不是任何时候都能由packet_in去填充的。
不去管就好了，默认的会填充一个默认值，匹配的时候不去匹配4层端口就没有问题。
FLOW_MOD
这里面的信息也是至关重要的。
classofp_flow_mod（Packet）:
name=”OpenFlowFlowModify”
fields_desc=［BitField（"cookie”，0，64）,#Opaquecontroller—issuedidentifier
ShortEnumField（"command",0,ofp_flow_mod_command），
ShortField（"idle_timeout",60）,
ShortField（”hard_timeout”,0），
ShortField（”priority"，0）,
IntField（”buffer_id”,0）,
ShortField（”out_port”,0）,
#flagsareimportant,the1<<0bitisOFPFF_SEND_FLOW_REM，sendOFPT_FLOW_REMOVED
#1〈<1bitisOFPFF_CHECK_OVERLAP,checkingiftheentries’fieldoverlaps（amongsamepriority）
#1<<2bitisOFPFF_EMERG,usedonlyswitchdisconnectedwithcontroller）
ShortField（”flags",0）］
command里面的类型决定了flow_mod的操作是添加,修改还是删除等。
类型如下
ofp_flow_mod_command={0:
"OFPFC_ADD”，＃Newflow
1:
"OFPFC_MODIFY”，#Modifyallmatchingflows
2:
"OFPFC_MODIFY_STRICT”,＃Modifyentrystrictlymatchingwildcards
3：
"OFPFC_DELETE”,＃Deleteallmatchingflows
4:
"OFPFC_DELETE_STRICT”｝#Strictlymatchwildcardsandpriority
例如：
如果要添加一条新流，command=0.
两个时间参数idle_timeout＆idle_timeout：
∙idle_timeout:
如值为10，则某条流在10秒之内没有被匹配，则删除，可以称之为活跃时间吧.
∙hard_timeout:
如值为30，则30秒到达的时候,一定删除这条流，即使他还活跃，即被匹配.
priority
priority是流的优先级的字段,字数越大则优先级越高，存放在号数越小的table中。
buffer_id
由交换机指定的buffei_id，准确的说是由dpid指定的。
如果是手动下发的流,buffer_id应填—1，即0xffff,告诉交换机这个数据包并没有缓存在队列中。
out_port
指定流的出口，但是这个出口并不是直接指导流转发的，至少我是这么觉得，指导流转发的出口会在action里面添加，这个端口是为了在flow_removed的时候查询，并返回控制器的作用。
（求纠正！
）
有一些端口是很特殊的，如flood，local等。
具体分类如下:
ofp_port={0xff00：
”OFPP_MAX",
0xfff8：
"OFPP_IN_PORT”，
0xfff9：
”OFPP_TABLE"，
0xfffa：
”OFPP_NORMAL”,
0xfffb：
"OFPP_FLOOD”,
0xfffc：
”OFPP_ALL"，
0xfffd:
"OFPP_CONTROLLER"，
0xfffe：
"OFPP_LOCAL",
0xffff:
"OFPP_NONE”}
如果你不知道端口是多少,最好填flood,也就是0xfffb。
flags
在上面的注释中也说得比较清楚了。
如果没有特殊用处,请将他置1,因为这样能让交换机在删除一条流的时候给交换机上报flow_removed信息。
ACTION
action是openflow里面最重要的结构。
对，他也是最重要的。
每一条流都必须指定必要的action，不然匹配上之后，没有指定action，交换机会默认执行drop操作。
action有2种类型：
∙必备行动:
ForwardandDrop
∙选择行动:
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_VLAN_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_TP_DST”，
11：
”OFPAT_ENQUEUE"
｝
action不仅仅会出现在flow_mod中，也会出现在如stats_reply中。
OFPT_BARRIER_REQUEST&＆REPLY
这个数据包可以的作用很简单，交换机在收到OFPT_BARRIER_REQUEST的时候,会回复控制器一个OFPT_BARRIER_REPLY。
我们默认数据下发的顺序不会在传输中发生变化，在进入消息队列之后处理也是按照FIFO进行的，那么只要在flow_mod之后发送这个
升级会员 