OpenFlow通信流程解读

pt-sdn-of1.0-10-14

1 前言

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

2 SDN中Switch和controller

在SDN中很重要的两个实体是Switch跟Controller。Controller在网络中相当于上帝,可以知道网络中所有的消息,可以给交换机下发指令。Switch就是一个实现Controller指令的实体,只不过这个交换机跟传统的交换机不一样,他的转发规则由流表指定,而流表由控制器发送。

2.1 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模拟环境。可以搭建许多交换机,任意拓扑,搭建拓扑具体教程本博客有一篇。性能依赖虚拟机的性能。

2.2 controller组成

控制器有许多种,不同的语言,如python写的pox、ryu,如java写的Floodlight等等。从功能层面controller分为以下几个模块:

  • 底层通信模块:OpenFlow中目前controller与switch之间使用的是socket连接,所以控制器底层的通信是socket。
  • OpenFlow协议。socket收到的数据的处理规则需按照OpenFlow协议去处理。
  • 上层应用:根据OpenFlow协议处理后的数据,开发上层应用,比如pox中就l2_learning、l3_learning等应用。更多的应用需要用户自己去开发。

3 OpenFlow通信流程

以下教程环境为:Mininet+自编简单控制器+scapy封装

3.1 建立连接

首先启动Mininet,Mininet会自行启动一个default拓扑,你也可以自己建立你的拓扑。sw建立完成之后,会像controllerIP:controllerport发送数据。

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

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

3.2 OFPT_HELLO

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

  • 目的:协议协商。
  • 内容:本方支持的最高版本的协议
  • 成果:使用双方都支持的最低版本协议。
  • 成功:建立连接
  • 失败:OFPT_ERROR (TYPE:OFPT_HELLO_FAILED,CODE =0),终止连接。

3.3 OFPT_ERROR

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

错误类型如上所示。对应的type还会有对应的code。所以报错的格式为:

如 TYPE:0 CODE:0为:OFPHFC_INCOMPATIBLE

具体对应的关系,请自行查看OF协议。

3.4 OFPT_ECHO

  • 分类:对称信息 OFPT_ECHO_REQUEST, OFPT_ECHO_REPLY
  • 作用:查询连接状态,确保通信通畅。

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

3.5 OFPT_FEATURES

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

  • 发送时间:连接建立完成之后
  • 发送数据:OFPT_FEATURES_REQUEST
  • 对称数据:OFPT_FEATURES_REPLY
  • 目的:获取交换机的信息

OFPT_FEATURES_REQUEST

  • TYPE=5
  • Without data

OFPT_FEATURES_REPLY

  • TYPE =6
  • [0:8]为header
  • [8:32]长度24byte为sw的features
  • [32:]长度与端口数成正比,存放port的信息。每一个port信息长度为48byte。

以上的结构是交换机的features,紧跟在后面的是端口的结构:

交换机和端口的配置信息在整一个通信过程起着至关的作用,因为所有关于的操作都需要从features里面提取相关的信息,如dpid、port_no,等在整个通信过程中多次被用到的重要数据。所以,对这两个数据结构了然于心,对于研究OpenFlow来说,至关重要。每一次交换机连到控制器,都会收到控制器的features_request,当sw将自己的features回复给控制器之后,控制器就对交换机有了一个全面的了解,从而为后面的控制提供的控制信息。

3.6 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以外的所有端口发送数据包。

3.7 OFPT_PACKET_OUT

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

  • 作用:通过控制器发送交换机希望发送的数据
  • 例子:arp在广播的时候,在ofsw中不能直接将arp广播,需要上报控制器,控制器下发packet_out,指定交换机对该数据包做泛洪操作。

PS:前一个版本此处有误:特此声明。packet_out的作用在与指导交换机做flood操作,并把ARP包广播出去,packet_out本身并不携带arp数据包。

3.8 OFPT_FLOW_MOD

OFPT_FLOW_MOD是整个OpenFlow协议中最重要的数据结构,没有之一。

OFPT_FLOW_MOD由header+match+flow_mod+action[]组成。为了操作简单,以下的结构是将wildcards和match分开的形式,形成两个结构,在编程的时候能更方便一些。由于这个数据包很重要,所以,我将把这个数据包仔细拆分解读。

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。如0x0800就是纯IP,并没有携带vlan_tag,所以填充式应根据packet_in的具体情况填充。
  • 并不是所有的数据都有四层端口,所以四层的源端口,目的端口都不是任何时候都能由packet_in去填充的。不去管就好了,默认的会填充一个默认值,匹配的时候不去匹配4层端口就没有问题。

FLOW_MOD

这里面的信息也是至关重要的。

command里面的类型决定了flow_mod的操作是添加,修改还是删除等。类型如下

例如:如果要添加一条新流,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等。具体分类如下:

如果你不知道端口是多少,最好填flood,也就是0xfffb。

flags

在上面的注释中也说得比较清楚了。如果没有特殊用处,请将他置1,因为这样能让交换机在删除一条流的时候给交换机上报flow_removed信息。

3.9 ACTION

action是OpenFlow里面最重要的结构。对,他也是最重要的。每一条流都必须指定必要的action,不然匹配上之后,没有指定action,交换机会默认执行drop操作。

action有2种类型:

  • 必备行动:Forward and Drop
  • 选择行动:FLOOD、NALMAL 等

如添加output就是一个必须要添加的action。每一个action最好有一个action_header(),然后再接一个实体。如:

具体的action类型如下:

action不仅仅会出现在flow_mod中,也会出现在如stats_reply中。

3.10 OFPT_BARRIER_REQUEST && REPLY

这个数据包可以的作用很简单,交换机在收到OFPT_BARRIER_REQUEST的时候,会回复控制器一个OFPT_BARRIER_REPLY。我们默认数据下发的顺序不会在传输中发生变化,在进入消息队列之后处理也是按照FIFO进行的,那么只要在flow_mod之后发送这个数据,当收到reply之后,交换机默认flow已经写成功。也许你会问他只是保证了flow_mod命令执行了,写入的结果如何并没有保证,如何确定确实写入流表了呢?

  • 如果非逻辑错误,那么交换机在处理flow_mod的时候会报错。所以我们会知道写入结果。
  • 如果是逻辑错误,那么会写进去,但是逻辑错误应该是人的问题,所以barrier还是有他的功能的。

3.11 OFPT_FLOW_REMOVED

如果flow_mod的flags填成1,则该流在失效之后会回复控制器一条OFPT_FLOW_REMOVED信息。

  • 结构:header()/wildcards()/match()/flow_removed()
  • 作用:在流失效的时候回复控制器,并携带若干统计数据。

其实的duration_sec是流存在的时间,单位为秒,duration_nsec单位为纳秒。

3.12 OFPT_STATS_REQUEST && REPLY

以上的数据都是通信过程中必须的部分。还有一些数据包是为了某些目的而设计的,如OFPT_STATS_REQUEST && REPLY可以获得统计信息,我们可以利用统计信息做的事情就太多了。如:负载平衡, 流量监控等基于流量的操作。

OFPT_STATS_REQUEST

OFPT_STATS_REQUEST类型有很多,回复的类型也很多。

Type

  • 0:请求交换机版本信息,制造商家等信息。
  • 1:单流请求信息
  • 2:多流请求信息
  • 3:流表请求信息
  • 4:端口信息请求
  • 5:队列请求信息
  • 6:vendor请求信息,有时候没有定义。

OFPT_STATS_REPLY

每一种请求信息都会对应一种回复信息。我们只介绍最重要的flow_stats_reply。

  • 结构:header(type=17)/reply_header()/flow_stats/wildcards/match/ flow_stats_data
  • 作用:携带流的统计信息,如通过的数据包个数,字节数。

ofp_flow_stats(body[4:8])里面会有的table_id字段表明该流存放在哪一个流表里。flow_stats_data里面有packet_count和byte_count是最有价值的字段,流量统计就是由这两个字段提供的信息。如想统计某条流的速率:前后两个reply的字节数相减除以duration_time只差就可以求得速率。由速率我们可以做很多基于流量的app,如流量监控,负载均衡等等。

值得注意的是,在这些数据之后,其实还有一些action,但是目前我还没有查看这些action到底是干什么用的。

4 后续

写到这里,我使用到的数据包都写了一遍,其他的报文其实道理也是一样的。如OFPT_GET_CONFIG_REQUEST和REPLY,道理应该和stats一样,只是数据结构不一样罢了。不再多说。

最后把我们用的一些比较多的信息帖出来让大家更好的学习。
ERROR
在调试的过程中遇到错误是再所难免的,前面也提到了error的结构。这里就贴一下type跟code吧。
Type

相关的code:

谢谢我的两个师傅richardzhao,kimi带我走进OpenFlow的世界。整篇文档均为牧紫星原创,转载请声明告知。希望能给你带来一些帮助。
 
 
 
转载自:李呈微博@李呈,http://www.muzixing.com/pages/2013/12/12/yuan-chuang-openflowtong-xin-liu-cheng-jie-du.html


  • 本站原创文章仅代表作者观点,不代表SDNLAB立场。所有原创内容版权均属SDNLAB,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用,转载须注明来自 SDNLAB并附上本文链接。 本站中所有编译类文章仅用于学习和交流目的,编译工作遵照 CC 协议,如果有侵犯到您权益的地方,请及时联系我们。
  • 本文链接https://www.sdnlab.com/1479.html
分享到:
相关文章
条评论

登录后才可以评论

李呈 发表于14-09-25
2