我对OpenFlow的理解

写下来，总结一下了解的东西。

谈到OpenFlow，首先不得不提一下软件定义网络（SDN），在SDN中有两个重要的元素一个是交换机，一个是控制器。在网络设备上还有一个“上帝”，也就是控制器，它知道所有网络信息，负责指挥设备如何工作，而交换机什么都不知道，只会按照控制器的命令进行工作，在SND中，网络设备之间不运行任何的网络协议，设备的转发表是由控制器产生的，那么问题来了，控制器和网络设备之间怎样进行通信呢，就是通过OpenFlow协议，属于南向协议，但是南向协议不只有OpenFlow协议，现在我们就知道了OpenFlow协议是干什么的了，就是用来让控制器与网络设备之间进行互相通信用的；用一个图表示：

OpenFlow交换机中的交换机成为流表（Flow table），其中包括数据包匹配特征和数据包的处理方法：

我们来看看OpenFlow1.0流表数据包匹配特征的结构：

第一层：交换机入端口，即消息在哪个端口进入交换机（Ingress Port）；

第二层：源MAC地址（Ether source），目的MAC地址（Ether dst），以太网类型（Ether Type），VLAN标签（VLAN id），VLAN优先级（VLAN priority）；

第三层：源IP（IP src），目的IP（IP dst），IP协议字段（IP Proto），IP服务类型（IP Tosbits）；

第四层：TCP/UDP源端口号（TCP/UCP src port），TCP/UDP目的端口号（TCP/UDP dst port）。

数据包处理方法包括转发，修改包头，每一个处理叫做一个Action。

Openflow消息的类型可以总体分为三大类：

1. Controller-to-Switch（控制器到交换机的消息，由控制器主动发出）

• Features用来获取交换机特性
• Configuration用来配置OpenFlow交换机
• Modify-State用来修改交换机状态（修改流表）
• Read-Stats用来读取交换机状态
• Send-Packet用来发送数据包
• Barrier阻塞消息

2. Asynchronous（异步消息，此类消息由交换机主动发出）

• Packet-in用来告知控制器，交换机接收到数据包
• Flow-Removed用来告知控制器交换机流表被删除
• Port-Status用来告知控制器交换机端口状态更新
• Error用来告知控制器交换机发生错误

3.Symmetric(对称消息，可以由控制器或交换机主动发出)

• Hello用来建立OpenFlow连接
• Echo用来确认交换机与控制器之间的连接状态
• Vendor厂商自定义消息

OpenFlow协议数据包包括Header和Message；Header中主要是协议版本，数据包长度等，message是具体的数据包内容。

下面我们来看一下OpenFlow的通信流程：

1. 控制器首先与交换机进行三次握手，完成socket连接，然后控制器和交换机之间相互发送OFPT_Hello消息，Hello消息中只包含OpenFlow Header，其中Header中的version字段为发送发所支持的最高版本的OpenFlow协议，双方选取Hello消息中最低版本的协议作为通信的协议，如果有一方不支持OpenFlow协议版本，则发送OFPT_ERROR消息，然后断开连接，否则协商成功后，两者之间建立OpenFlow连接成功；

总结：OFPT_HELLO

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

2. 获取交换机特性（Features）信息，Openflow连接建立后，控制器最需要获得交换机的特性信息，交换机的特性信息包括交换机的ID(DPID)，交换机缓冲区数量，交换机
端口及端口属性等等。控制器向交换机发送Features Request消息查询交换机特性，Features Request消息只包含Openflow Header。交换机在收到Features Request消息后返回Features Reply消息，Features Reply消息包括Openflow Header 和Features Reply Message；

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

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

备注：

Features Reply Message机构如图所示：

• datapath_id为交换机独一无二的ID号
• n_buffers为交换机可以同时缓存的最大数据包个数
• n_tables为交换机的流表数量
• Capabilities表示交换机支持的特殊功能
• Actions表示交换机支持的动作（见ofp_action_type）
• ofp_phy_ports为交换机的物理端口描述列表，具体结构如下图

• port_no为物理端口的编号
• hw_addr为端口的MAC地址
• name为端口的名称
• config为端口的配置
• State为端口状态
• curr, advertised supported,peer为端口物理属性

3. Packet- in事件（ 交换机接收数据包）， 在控制器获取完交换机的特性之后 ， 交换机开始处理数据。对于进入交换机而没有匹配流表，不知道如何操作的数据包，交换机会将其封装在packet_in中发给controller 。包含在packet_in中的数据可能是很多种类型，arp和icmp是最常见的类型。当然产生packet_in的原因不止一种产生packet_in的原因主要有一下两种：

• OFPR_NO_MATCH：当交换机收到一个数据包后，会查找流表，找出与数据包包头相匹配的条目。如果流表中有匹配条目，则交换机按照流表所指示的action列表处理数据包。如果流表中没有匹配条目，则交换机会将数据包封装在Packet‐in消息中发送给控制器处理。此时数据包会被缓存在交换机中等待处理。
  
• OFPR_ACTION：交换机流表所指示的action列表中包含转发给控制器的动作（Output=CONTROLLER）。此时数据包不会被缓存在交换机中。
  

packet-in的消息格式

• buffer_id为packet‐in事件所携带的数据包在交换机中的缓存区ID
• total_len为data段的长度
• in_port数据包进入交换机的入接口号
• Reason为packet‐in事件产生的原因

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

4. OFPT_PACKET_OUT

并不是所有的数据包都需要向交换机中添加一条流表项来匹配处理，网络中还存在多种数据包，它出现的数量很少（如ARP、IGMP等），以至于没有必要通过流表项来指定这一类数据包的处理方法。此时，控制器可以使用PacketOut消息，告诉交换机某一个数据包如何处理。

比如，arp在广播的时候，在ofsw中不能直接将arp广播，然后将该数据包发送给控制器，控制器将其封装在packet_out里面发给交换机，交换机泛洪的是packet_out。

5. OFPT_FLOW_MOD

当交换机收到一个数据包并且交换机中没有与该数据包匹配的流表项时，交换机将此数据包封装到Packet-in消息中发送给控制器，并且交换机会将该数据包
缓存。控制器收到Packet-in消息后，可以发送flow-mod消向交换机写一个流表项。并且将flow-mod消息中的buffer_id字段设置为packet-in消息中的buffer_id值。从而
控制器向交换机写入了一条与数据包相关的流表项，并且指定该数据包按照此流表项的aciton列表处理。

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

OFP_HEADER：header是所有数据包的报头，有三个参数：

• type:类型
• ength:整个数据包的长度
• 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部分应对应填上对应的数据，这样下发的流表才是正确的。

FLOW_MOD：用来添加、删除、修改Openflow交换机的流表信息

两个时间参数idle_timeout & idle_timeout：

• idle_timeout:如值为10，则某条流在10秒之内没有被匹配，则删除，可以称之为活跃时间吧。
• hard_timeout:如值为30，则30秒到达的时候，一定删除这条流，即使他还活跃，即被匹配。
• priority是流的优先级的字段，字数越大则优先级越高，存放在号数越小的table中。
• buffer_id是由交换机指定的buffei_id,准确的说是由dpid指定的。如果是手动下发的流，buffer_id应填-1，即0xffff,告诉交换机这个数据包并没有缓存在队列中。
• out_port为删除流表的flow_mod消息提供额外的匹配参数
• command用来指定操作的类型，共有五种类型：ADD、DELETE、DELETE‐STRICT、MODIFY、MODIFY‐STRICT

6. OFPT_ECHO：当没有其他的数据包进行交换时，controller会定期循环给sw发送OFPT_ECHO_REQUEST，sw回复OFPT_ECHO_REPLY，用来查询连接状态，确保通信通畅。

大致就这些了，在学习的过程中，参考了许多好的文章，今天的这篇文章主要参考 http://www.sdnlab.com/sdn-guide/14812.html/