OpenFlow是SDN控制器和交换之间交流的协议，在SDN领域有着十分重要的地位。

OpenFlow协议发展到现在已经经过了1.0、1.3、1.4等版本。其中1.0和1.3版本使用的是最为广泛的。

本篇博文主要分析1.0版本和1.3版本OpenFLow协议在控制器和交换机之间的交互流程。

OpenFlow1.0协议交互

OpenFlow协议1.0的交互过程如下：

交互过程：

1. 交换机或控制器首先发送hello报文,确定openflow通信版本。
2. 交换机或控制器收到hello报文之后，回复一个hello报文，协商版本。
3. 控制器发送feature_request报文，查询交换机具体信息。
4. 交换机收到feature_request报文之后，回复feature_reply，报告自己的详细信息给控制器。
5. 工作过程中控制器会不断发送echo_request给交换机，交换机回复echo_reply消息给控制器，确认连接。

OpenFlow协议1.0版本在交换机和控制器信息交互过程中，一共有如下的消息类型：

1.    Enum ofp_type {  
1.    /* Immutable messages. */  
2.    OFPT_HELLO, /* Symmetric message */  
3.    OFPT_ERROR, /* Symmetric message */  
4.    OFPT_ECHO_REQUEST, /* Symmetric message */  
5.    OFPT_ECHO_REPLY, /* Symmetric message */  
6.    OFPT_VENDOR, /* Symmetric message */  

/* Switch configuration messages. */  
7.    OFPT_FEATURES_REQUEST, /* Controller/switch message */
8.    OFPT_FEATURES_REPLY, /* Controller/switch message */  
9.    OFPT_GET_CONFIG_REQUEST, /* Controller/switch message
10.    OFPT_GET_CONFIG_REPLY, /* Controller/switch message *
11.    OFPT_SET_CONFIG, /* Controller/switch message */  

/* Asynchronous messages. */  
12.    OFPT_PACKET_IN, /* Async message */  
13.    OFPT_FLOW_REMOVED, /* Async message */  
14.    OFPT_PORT_STATUS, /* Async message */  

/* Controller command messages. */  
15.    OFPT_PACKET_OUT, /* Controller/switch message */  
16.    OFPT_FLOW_MOD, /* Controller/switch message */  
17.    OFPT_PORT_MOD, /* Controller/switch message */  

/* Statistics messages. */  
18.    OFPT_STATS_REQUEST, /* Controller/switch message */  
19.    OFPT_STATS_REPLY, /* Controller/switch message */  

/* Barrier messages. */  
20.    OFPT_BARRIER_REQUEST, /* Controller/switch message */
21.    OFPT_BARRIER_REPLY, /* Controller/switch message */  

/* Queue Configuration messages. */  
22.    OFPT_QUEUE_GET_CONFIG_REQUEST, /* Controller/switch m
23.    OFPT_QUEUE_GET_CONFIG_REPLY /* Controller/switch mess
24.    };  

 其中红色为常用消息，整理如下：

Hello

Feature_request

Feature_reply

Stats_request

Stats_reply

Flow_mod

Set_config

Packet_in

Packet_out

下面分别介绍以上报文信息。

HELLO

hello 是使用来协商控制器和交换机之间openflow协议的版本号的消息。当控制器和交换机都支持openflow1.0时，使用1.0版本进行交流；

如果都支持1.3版本则使用OpenFlow1.3版本进行交流。

0x01代表版本1，即openflow1.0

Type类型为hello，表示为0

FEATURE_REQUEST

feature_request消息是控制器用来查询交换机特性消息，如交换机ID，缓冲区数量，端口及端口属性等。该消息只有头部，没有消息体。

Type类型为feature_request,标识为5

Type表示为5，代表feature_request消息。

length 代表消息长度，出去消息报头。

Transation ID  事件ID，用来表示同一个事件。Feature——requesthe feature_reply事件ID相同。

FEATURE_REPLY

交换机收到feature_request消息之后会回复feature_reply消息来报告自己的特性。具体来说，会有交换机自身支持的流表数量，最多能缓存的数据包数量，端口特性等。

交换机报告自身的特性之后，控制器能够更具这些特性下发指令。

datapath id 数据通道标识符，用来表示交换机的身份。在每一个控制器中独一无二。

n_buffers 一次最多缓存的数据包数量，即交换机自己的缓存能力。

n_tables 表示交换机支持的流表数量。

capabilities 交换机端口所支持的功能,有流表，端口，STP，队列，ARP等。

actions 该bitmask表示交换机所支持的actions，有转发和修改包头两种。

port 交换机连接的端口消息。端口MAC地址，链路数据等。

FLOW_MOD

flow_mod消息是OpenFlow协议的核心消息之一。flow_mod消息的作用是下发流表项。通过Flow-Mod消息可以对流表进行添加、删除、变更设置等操作。

command 表示flow-mod消息的动作。一共五种，实现对流表的增、删、改操作。

idle_time  流表匹配数据计时器，如果该时间内流表匹配信息还未到达则删除流表。

hard_time  流表项老化时间。一项流表在交换机中存在的时间超过该时间则删除流表项。

priroity  流表项优先级，数字越大越优先。

buffer_id  交换机上保存的，发送至控制器请求处理的流表的编号。

actions  该流表的动作，有转发，修改两大类。具体见feature_reply消息中capabilities。

SET_CONFIG

set_config消息是控制器对交换机进行配置的消息。控制器可以配置交换机的MTU，报文分片处理等能力。

控制器通过向交换机发送OFPT_SET_CONFIG 和OFPT_GET_CONFIG_REQUEST

消息（该消息仅有头部）来配置和查询交换机配置。对于查询消息，交换机必须回复

OFPT_GET_CONFIG_REPLY 消息。

config flags  标志用来指示该如何处理IP 碎片：正常、丢弃还是重组。

 max byte of packet  类似MTU，交换机一个数据帧能最大的数据存储量。

 PACKET_IN

当交换机遇到不知道如何转发的报文时，使用packet_in消息将无法处理的报文封装起来发送给控制器，交给控制器去判断处理。并且交换机会将该数据包
缓存。

该消息的另一个触发是当交换机接收到制定报文，该报文的匹配动作就是发送给控制器，这时交换机也会将该报文用packet_in消息封装，发送给控制器。

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

buffer_id packet-in消息所携带的数据包在交换机中的缓存ID。

Total_len  帧的长度。

In_port  数据包进入交换机的入端口号。

Reason  packet-in事件的产生原因,分为两种：OFPR_NO_MATCH和OFPR_ACTION。

data  需要处理的未知数据包。

PACKET_OUT

并不是所有的数据包都需要向交换机中添加一条流表项来匹配处理，网络中还

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

In_port  数据包进入交换机的入端口号。

action_len  动作信息的长度。和flow_mod相同。

 STATS_REQUEST

OFPT_STATS_REQUEST && REPLY可以获得统计信息，可以实现：负载平衡， 流量监控等基于流量的操作。
OFPT_STATS_REQUEST类型有很多，回复的类型也很多。
Type：
        0:请求交换机版本信息，制造商家等信息。
        1:单流请求信息
        2:多流请求信息
        3:流表请求信息
        4:端口信息请求
        5:队列请求信息

 STATS_REPLYstats_reply是对stats_request消息的回复。回复具体内容视查询内容而定。

Type 该字段决定传递的消息类型。类型如下：

OFPST_DESC 整体信息。请求类型提供了制造商、软件、硬件版本、序列号等整体信息。

OFPST_FLOW 请求类型则可以获取针对某个流的单独信息。

OFPST_AGGREGATE 请求类型可以获取多流信息。

OFPST_TABLE  表统计信息请求，请求信息回复为数组，包括流统计表，动作，时间等。

OFPST_PORT 端口状态的请求消息类型。

OFPST_QUEUE 队列消息请求，需要查询的端口和队列。端口和对列。

OFPST_VENDOR  生产商信息请求类型。

OpenFLow协议1.3版本

OpenFLow协议1.3版本的交互过程如下：

从下图可以看出，1.3版本比1.0版本常用协议增加了两个：MULTIPART_REQUEST MULTIPART_REPLY.

OpenFlow 1.3协议将‘stats’框架更名为‘multipart’框架，并且将端口描述移植到multipart消息中。

MULTIPART_REQUEST

multipart_request是控制器用来查询交换机的端口信息的消息。如下图可见消息体为：OFPMP_PORT_DESC。

 请求的类型和stats类似，一共有五种。具体参见stats类型消息。

 MULTIPART_REPLY

multipart_reply用来回复控制器的查询，回复的内容交换机端口的性能，特性等。

port  端口信息

state   端口状态，up或者down

current  方向，数据包方向

supported  支持的操作