（一）基本要求：
1.搭建下图所示拓扑，完成相关 IP 配置，并实现主机与主机之间的 IP 通信。用抓包软件获取控制器与交换机之间的通信数据。
2.查看抓包结果，分析OpenFlow协议中交换机与控制器的消息交互过程，画出相关交互图或流程图。
流程图：
1).hello:35084和6633相互发hello包，然后双方建立连接，并使用OpenFlow 1.0。
2).Features Request / Set Conig：
控制器6633端口（我需要你的特征信息） ---> 交换机35084端口
控制器6633端口（请按照我给你的flag和max bytes of packet进行配置） ---> 交换机35084端口
3).Features Reply：
⚫ datapath_id：唯一标识符；
⚫ n_buffers：交换机缓冲区可以缓存的最大数据包个数；
⚫ n_tables：流表数量；
⚫ pad：可以理解为填充值；
⚫ capabilities：支持的特殊功能；
⚫ actions：支持的动作；
⚫ port data：物理端口描述列表。
交换机35082端口（这是我的特征信息，请查收） ---> 控制器6633端口
4).Packet_in：
有两种情况：
• 交换机查找流表，发现没有匹配条目时
• 有匹配条目但是对应的action是OUTPUT=CONTROLLER时
交换机35082端口（有数据包进来，请指示）---> 控制器6633端口
5).Flow_mod：
控制器收到 Packet‐in 消息后，可以发送 Flow‐Mod 消息向交换机写一个流表项。并且将 Flow‐Mod 消息中的 buffer_id 字段设置为 Packet‐in 消息中的 buffer_id 值。从而控制器向交换机写入了一条与数据包相关的流表项，并且指定该数据包按照此流表项的 action 列表处理
分析抓取的flow_mod数据包，控制器通过6633端口向交换机35084端口
下发流表项，指导数据的转发处理
6).Packet_out:
Packet-Out消息是从OpenFlow控制器向OpenFlow交换机发送的消息，是包含数据包发送命令的消息”。
若OpenFlow交换机的缓存中已存在数据包，而OpenFlow控制器发出“发送该数据包”的命令时，该消息指定了表示相应数据包的buffer_id。使用Packet-Out消息还可将OpenFlow控制器创建的数据包发送至OpenFlow交换机。此时，buffer_id置为-1，在Packet-Out消息的最后添加数据包数据。
7).交互图：
Title: OpenFlow协议中交换机与控制器的消息交互过程
Note left of 6633: 控制器
Note right of 35082: 交换机
6633->35082:Hello
35082->6633:Hello
35082->6633:Features Request
6633->35082:Set Config
35082->6633:Port Status
35082->6633:Features Reply
35082->6633:Packet in
6633->35082:Flow mod
6633->35082:Packet out
3.回答问题：交换机与控制器建立通信时是使用TCP协议还是UDP协议？
答：是TCP协议。
（二）进阶要求:将抓包基础要求第2步的抓包结果对照OpenFlow源码，了解OpenFlow主要消息类型对应的数据结构定义。
1).hello
struct ofp_header {
uint8_t version; /* OFP_VERSION. */
uint8_t type; /* One of the OFPT_ constants. */
uint16_t length; /* Length including this ofp_header. */
uint32_t xid; /* Transaction id associated with this packet.
Replies use the same id as was in the request
to facilitate pairing. */
};
OFP_ASSERT(sizeof(struct ofp_header) == 8);
/* OFPT_HELLO. This message has an empty body, but implementations must
* ignore any data included in the body, to allow for future extensions. */
struct ofp_hello {
struct ofp_header header;
};
2).Features Request:
struct ofp_header {
uint8_t version; /* OFP_VERSION. */
uint8_t type; /* One of the OFPT_ constants. */
uint16_t length; /* Length including this ofp_header. */
uint32_t xid; /* Transaction id associated with this packet.
Replies use the same id as was in the request
to facilitate pairing. */
};
3).Set Config:
/* Switch configuration. */
struct ofp_switch_config {
struct ofp_header header;
uint16_t flags; /* OFPC_* flags. */
uint16_t miss_send_len; /* Max bytes of new flow that datapath should
send to the controller. */
};
4).Port Status:
struct ofp_port_status {
struct ofp_header header;
uint8_t reason; /* One of OFPPR_*. */
uint8_t pad[7]; /* Align to 64-bits. */
struct ofp_phy_port desc;
};
5).Port Reply:
struct ofp_stats_reply {
struct ofp_header header;
uint16_t type; /* One of the OFPST_* constants. */
uint16_t flags; /* OFPSF_REPLY_* flags. */
uint8_t body[0]; /* Body of the reply. */
};
6).Packet in:
struct ofp_packet_in {
struct ofp_header header;
uint32_t buffer_id; /* ID assigned by datapath. */
uint16_t total_len; /* Full length of frame. */
uint16_t in_port; /* Port on which frame was received. */
uint8_t reason; /* Reason packet is being sent (one of OFPR_*) */
uint8_t pad;
uint8_t data[0]; /* Ethernet frame, halfway through 32-bit word,
so the IP header is 32-bit aligned. The
amount of data is inferred from the length
field in the header. Because of padding,
offsetof(struct ofp_packet_in, data) ==
sizeof(struct ofp_packet_in) - 2. */
};
OFP_ASSERT(sizeof(struct ofp_packet_in) == 20);
7).Flow mod:
struct ofp_flow_mod {
struct ofp_header header;
struct ofp_match match; /* Fields to match */
uint64_t cookie; /* Opaque controller-issued identifier. */
/* Flow actions. */
uint16_t command; /* One of OFPFC_*. */
uint16_t idle_timeout; /* Idle time before discarding (seconds). */
uint16_t hard_timeout; /* Max time before discarding (seconds). */
uint16_t priority; /* Priority level of flow entry. */
uint32_t buffer_id; /* Buffered packet to apply to (or -1).
Not meaningful for OFPFC_DELETE*. */
uint16_t out_port; /* For OFPFC_DELETE* commands, require
matching entries to include this as an
output port. A value of OFPP_NONE
indicates no restriction. */
uint16_t flags; /* One of OFPFF_*. */
struct ofp_action_header actions[0]; /* The action length is inferred
from the length field in the
header. */
};
OFP_ASSERT(sizeof(struct ofp_flow_mod) == 72);
8).Packet out:
struct ofp_packet_out {
struct ofp_header header;
uint32_t buffer_id; /* ID assigned by datapath (-1 if none). */
uint16_t in_port; /* Packet's input port (OFPP_NONE if none). */
uint16_t actions_len; /* Size of action array in bytes. */
struct ofp_action_header actions[0]; /* Actions. */
/* uint8_t data[0]; */ /* Packet data. The length is inferred
from the length field in the header.
(Only meaningful if buffer_id == -1.) */
};
OFP_ASSERT(sizeof(struct ofp_packet_out) == 16);
三、心得体会：
本次实践不算太难，主要就是分析抓包的结果，跟着pdf就可以做出来，对这个OpenFlow 交换机与控制器交互过程有所了解。对于hello，对wireshark抓包的过程更加熟悉。进阶的时候需要打开openflow.h里面查看数据结构，代码量还是挺多的，在里面找结构有点困难，找了很长时间才找出主要消息类型的结构构成。
遇到的主要的问题就是有可能会出现抓包找不到HELLO的情况，问题在于要先开启wires hark然后点出any，再构建拓扑，没打开any后面抓包是抓不到HELLO的，因为可能在抓包之前就已经进行过HELLO了，所以要先打开wires hark的any再构建拓扑。