1 实验目的
- 熟悉wireshark的用法。
- 熟悉controller和交换机之间的通信流程，理解常见的OpenFlow消息的含义
2 实验原理
在sdn网络环境中，控制器和交换机之间采用标准的OpenFlow协议通信。通过控制平面和数据平面的分离，使得控制器掌握全局的网络信息，交换机专注于数据的转发。
3实验任务：
控制器：OpenDayligth，版本Boron-SR3
交换机：Pica8
实验拓扑如下： 
4.实验步骤：
4.1 实验设备
一台主机安装OpenDaylight控制器，一台测试主机，一台pica8 交换机。
4.2 搭建实验环境
controller 配置静态IP为：192.168.1.70/24。 pica8 交换机配置mgmt port静态IP为：192.168.1.80/24。 交换机主动发起与控制器的连接。
4.3 抓包分析：
TCP message：
先是三层握手，建立tcp连接，这个是底层的通信。这个连接是由交换机发起的，连接建立成功后，交换机和控制器之间立即互发OFTP_HELLO message. 
OFPT_HELLO message
交换机先向控制器发送Hello message，该消息用于协议协商。该消息头部的version字段设定为交换机所支持的最高OpenFlow协议版本。Hello message只含有of消息包头（of_header），包括版本、类型和长度三个子段，没有of_message body部分： 
OpenFlow 包Header格式： 
控制器向交换机连续发送了两个消息，分别是Hello message和OFPT_FEATURES_REQUEST message，如图所示： 
最终双方使用都支持的最低版本协议通信。
OFPT_FEATURES_* message
控制器向交换机下发OFTP_FEATURES_REQUEST 消息，这是一条交换机的配置请求消息。该消息只有Of header,没有 message body。 
交换机向控制器回复一个OFPT_FEATURES_REPLY消息。 
of1.3 协议中定义的OFPT_FEATURES_REPLY消息格式如下： 
of1.3 协议中定义的capabilities结构如下： 
注意：OFPT_FEATURES_REPLY消息中的DPID是用来唯一标识交换机的48位编号，其中低32位为交换机的MAC地址，高16位为of协议实现设备自定义的。
OFPT_BARRIER_*
控制器先发送OFPT_BARRIER_REQUEST message。
这个消息的作用就是让交换机执行完这个消息之前的所有命名再执行此消息之后的请求。当controller需要确定消息的依赖是否满足，或者确定交换机已经完成了操作，它可能会使用OFPT_BARRIER_REQUEST message。 
该消息只有of header,当交换机收到这个消息后，必须完成对之前所有消息的处理，然后再执行Barrier Request之后的消息。当完成这个过程后，交换机向控制器发送OFPT_BARRIER_REPLY消息。 
OFPT_ROLE_*
控制器向交换机发送了一个OFPT_ROLE_REQUEST消息。
当控制器想改变它的role时，它会向交换机发送OFPT_ROLE_REQUEST。 
当交换机接收到消息后，必须返回一个OFPT_ROLE_REPLY消息，其中role字段表明了控制器当前的角色。 
当控制器收到交换机发送的OFPT_ROLE_REPLY消息后，它又发送了OFPT_ROLE_REQUEST 消息，交换机也回复了。 
OFPT_MULTIPART_* 消息
OFPMP_DESC
控制器向交换机发送OFPT_MULTIPART_REQUEST,OFPMP_DESC message. 
当控制器请求数据平面的状态时，会使用OFPT_MULITART_REQUEST message。
当前OFPT_MULTIPART_REQUEST message的 type字段为OFPMP_DESC，控制器在请求交换机的制造商、硬件版本、软件版本、***等信息。
交换机会响应一个或者多个OFPT_MULTPART_REPLY message。
交换机将控制器请求的信息发给它。 
OFPMP_METER_FEATURES、OFPMP_GROUP_REATURES、OFPMP_PORT_DESC
控制器向交换机连续发送三个Openflow消息，分别为OFPT_MULTIPART_REQUEST,OFPMP_METER_FEATURES 、OFPT_MULTIPART_REQUEST,OFPMP_GROUP_REATURES、OFPT_MULTIPART_REQUEST,OFPMP_PORT_DESC message。 
OFPMP_METER_FEATURES
请求metering subsytem的特性 
OFPMP_GROUP_REATURES
groups Capabilities和对应的 bucket actions信息 
OFPMP_PORT_DESC
Of1.3 协议中将switch_feature消息中的ofp_phy_port[]字段去掉了。控制器通过这个消息来请求交换机上所有支持OpenFlow模式的端口描述信息。 
交换机向控制器分开发送三次reply message，分别为OFPT_MULTIPART_REPLY,OFPMP_METER_FEATURES、OFPT_MULTIPART_REPLY,OFPMP_GROUP_FEATURES、以及OFPT_MULTIPART_REPLY,OFPMP_PORT_DESC，回应控制器的请求。
控制器和交换机又交换了两次关于Role信息的消息，不再展开。
这次信息的交流，交换机最后的回复如下，这是OFPT_ROLE_REPLY消息： 
OFPT_MULTIPART_REQUEST,OFPMP_TABLE
请求table信息
OFPT_MULTIPART_REPLY,OFPMP_TABLE
回复消息。
OFPT_MULTIPART_REQUEST,OFPMP_FLOW
请求单条流表项的信息
OFPT_MULTIPART_REPLY, OFPMP_FLOW
回复消息。
OFPT_MULTIPART_REQUEST,OFPMP_GROUP_DESC
OFPT_MULTIPART_REPLY,OFPMP_GROUP_DESC
OFPT_MULTIPART_REQUEST,OFPMP_GROUP
OFPT_MULTIPART_REPLY,OFPMP_GROUP
OFPT_MULTIPART_REQUEST,OFPMP_METER_CONFIG
OFPT_MULTIPART_REPLY,OFPMP_METER_CONFIG
OFPT_MULTIPART_REQUEST,OFPMP_METER
OFPT_MULTIPART_REPLY,OFPMP_METER
OFPT_MULTIPART_REQUEST,OFPMP_PORT_STATS
控制器通过ofpmp_port_stats消息来查询交换机端口上的统计信息。 
交换机回复OFPT_MULTIPART_REPLY,OFPMP_PORT_STATS消息给控制器， 
向控制器报告端口的统计信息。
OFPT_SET_CONFIG
控制器向交换机发送OFPT_SET_CONFIG消息。用来在交换机上设置配置参数。交换机不用回复这条消息。 
ofp_set_config消息的格式： 
OFPT_PACKET_OUT
控制器将LLDP数据包封装在Packet-out数据包中通过数据平面转发出去。
控制器向交换机下发OFPT_PACKET_OUT消息。当控制器希望通过数据平面将一个数据包发送出去时，会使用OFPT_PACKET_OUT 消息。 
从上图中不难看出内部封装的数据类型是LLDP数据包。
OFPT_FLOW_MOD
OFPT_FlOW_MOD由header+match+flow_mod+action[]组成。
控制器向交换机下发OFPT_FLOW_MOD消息。该消息用于修改流表。 
length长度为64。
command里面的类型决定了flow_mod的操作是添加、修改还是删除等。当前的类型为：OFPFC_ADD。
buffer_id：由交换机指定的buffer_id，准确地说是由dpid指定的。如果是手动下发的流，buffer_id应填-1，即Oxffff，告诉交换机这个数据包并没有缓存在队列中。
OFPT_PACKET_IN
交换机向控制器发送packet-in消息，有三种情况：没有匹配的流表项；action要求发送给控制器；无效的TTL字段。
of1.3中规定的packet-in消息产生的三种原因。 
包含在packet_in中的数据可能是很多种类型，arp和icmp是最常见的类型。
packet-in消息可能会触发packet-out消息，也有可能触发flow-mod消息等。
交换机向控制器上报OFPT_PACKET_IN消息，如下图所示。当数据平面收到数据包后，该数据包通过packet_In消息发给控制器。 
5.总结
6参考资料：
OpenFlow1.3协议解析：http://blog.csdn.net/sherkyoung/article/details/44098497
OpenFlow协议通信流程解读http://www.sdnlab.com/sdn-guide/14812.html