参考
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报文,用于发现底层网络链路情况,具体细节请参考:SDN控制器的拓扑管理与LLDP链路发现。
8.控制器下发BARRIER_REQUEST
,交换机返回...REPLY
,作用是在控制器下发Flow_Mod
之后,判断流表是否成功写入交换机,如果收到Reply则确认成功。
9.控制器下发STATS_REQUEST
,交换机返回...REPLY
,作用是获取交换机内部的统计信息。
10.控制器和交换机在运行时不断互相发心跳ECHO
包,确认连接存在。
2017.8