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+自编简单控制器

建立连接

首先启动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还会有对应的code.所以报错的格式为：

如 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 data

OFPT_FEATURES_REPLY

∙TYPE =6

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

交换机和端口的配置信息在整一个通信过程起着至关的作用，因为所有关于的操作都需要从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