参考

• 李呈：

OpenFlow protocol version 1.0 通信过程

通信双方：

OpenFlow控制器，OpenFlow交换机。

通信模块：

Secure Channel(基于TCP)。

通信基础：

socket。

通信过程：

1.TCP三次握手(基于TCP协议)。

2.控制器交换机互发Hello包，也是三次，无论控制器还是交换机均可先发送。目的是为了协商OpenFlow协议的版本号。

3.控制器 => 交换机：Feature_Request数据报，目的是为了获取交换机的信息。

4.交换机 => 控制器：Feature_Reply数据报，主要是回复交换机的端口信息，长度与端口数成正比，存放port的信息。每一个port信息长度为48byte。

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

5.在控制器获取完交换机的信息之后，交换机就开始处理数据了，在遇到没有匹配到流表的流量时，交换机将该流的第一个数据报封装成packet-in发送至控制器端进行决策和处理。控制器基于网络拓扑进行计算，并返回packet-out决定交换机如何处理流量。

6.控制器下发Flow_Mod，该类型的数据报是OpenFlow控制器用于配置OpenFlow交换机的数据报，非常重要。其结构由header+match+flow_mod+action[]组成，具体细节请参考文首的参考博客。

7.控制器下发Packet_Out，携带LLDP报文，用于发现底层网络链路情况，具体细节请参考：。

8.控制器下发BARRIER_REQUEST，交换机返回...REPLY，作用是在控制器下发Flow_Mod之后，判断流表是否成功写入交换机，如果收到Reply则确认成功。

9.控制器下发STATS_REQUEST，交换机返回...REPLY，作用是获取交换机内部的统计信息。

10.控制器和交换机在运行时不断互相发心跳ECHO包，确认连接存在。

2017.8