实验3：OpenFlow协议分析实践
（一）基本要求
1. 搭建拓扑
如图，用mininet搭建拓扑后并运行。注意mininet搭建拓扑时需要设置主机IP地址和全局IP base，否则会报错。而且应该先开启wireshark再运行搭建好的拓扑文件，否则抓不到hello包。
2. 抓包分析
· HELLO
可以看出是从控制器的6633 端口到交换机的46224端口，最高支持OpenFlow 1.0 协议
之前有一次没抓PORT_STATUS包，再次实验抓到后却忘记截V6的图了，用之前的代替，理论上这里应该是从交换机的46224端口到控制器的6633 端口，最高支持OpenFlow 1.5 协议
于是双方约定用openflow 1.0协议进行通信
·Features Request/ Set Config
从控制器的6633 端口到交换机的46224端口，代表控制器向交换机请求特征信息。
从控制器的6633 端口到交换机的46224端口，控制器要求交换机按照他给的flag和max bytes of packet进行配置。flag：指示交换机如何处理 IP 分片数据包。max bytes of packet：当交换机无法处理到达的数据包时，向控制器发送如何处理的最大字节数，本实验中控制器发送的值是0x0080，即128字节。
·Port_Status
用于当交换机端口发生变化时，告知控制器相应的端口状态。从控制器的6633 端口到交换机的46234端口
·FEATURES_REPLY
从交换机的46224端口到控制器的6633 端口。交换机告知控制器它的特征信息。
·PACKET_IN
从交换机46234端口到控制器6633端口（请求指示）。当1.不存在与流表项一致的项目时（table-miss）
2.匹配的流表项中记载的行动为“发送至Openflow控制器”会触发packet_in消息
·PACKET_OUT
从控制器的6633 端口到交换机的46234端口。控制器要求交换机按照它指定的要求处理。
·FLOW_MOD
从控制器的6633 端口到交换机的46234端口。控制器向交换机下发流表项，指导数据的转发处理。
·ECHO REQUEST/ECHO REPLY
当没有其他的数据包进行交换时，交换机会定期循环给控制器发送OFPT_ECHO_REQUEST来确保与控制器的连接。控制器对交换机进行回应，确保连接没有问题。
3. 流程图
4. 采用TCP协议
Transmission Control Protocol，即TCP协议
（二）进阶要求
·通用字段
/* Header on all OpenFlow packets. */
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. */
};
OpenFlow数据包头的通用字段，分别是版本号，消息类型，长度，ID
·HELLO
struct ofp_hello {
struct ofp_header header;
};
HELLO报文用于协商协议，双方发送本方支持的最高版本的协议。最终会使用双方都支持的最低版本协议建立连接。type处会被置为OFPT_HELLO
·FEATURES REQUEST
struct ofp_hello {
struct ofp_header header;
};
结构与HELLO一致。
·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. */
};
除了通用的数据包头字段外，还有：
flags:告知交换机如何处理IP分片数据包
miss_send_len:一个交换机无法处理的数据包到达时，将数据包发给控制器的最大字节数
·PORT STATUS
/* A physical port has changed in the datapath */
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;
};
当交换机端口发生变化时，告知控制器相应的端口状态。
·FEATURES_REPLY
/* Switch features. */
struct ofp_switch_features {
struct ofp_header header;
uint64_t datapath_id; /* Datapath unique ID. The lower 48-bits are for
a MAC address, while the upper 16-bits are
implementer-defined. */
uint32_t n_buffers; /* Max packets buffered at once. */
uint8_t n_tables; /* Number of tables supported by datapath. */
uint8_t pad[3]; /* Align to 64-bits. */
/* Features. */
uint32_t capabilities; /* Bitmap of support "ofp_capabilities". */
uint32_t actions; /* Bitmap of supported "ofp_action_type"s. */
/* Port info.*/
struct ofp_phy_port ports[0]; /* Port definitions. The number of ports
is inferred from the length field in
the header. */
};
除了通用头文件，还多了：
datapath_id：唯一标识符；
n_buffers：交换机缓冲区可以
缓存的最大数据包个数；
n_tables：流表数量；
pad：可以理解为填充值；
capabilities：支持的特殊功能；
actions：支持的动作；
port data：物理端口描述列表。
·PACKET_IN
enum ofp_packet_in_reason {
OFPR_NO_MATCH, /* No matching flow. */
OFPR_ACTION /* Action explicitly output to controller. */
};
/* Packet received on port (datapath -> controller). */
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. */
};
当1.不存在与流表项一致的项目时（table-miss）
2.匹配的流表项中记载的行动为“发送至Openflow控制器”会触发packet_in消息
·PACKET_OUT
/* Send packet (controller -> datapath). */
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.) */
};
除通用头文件，还包括动作列表、缓冲区ID，进入的端口。
·FLOW_MOD
/* Flow setup and teardown (controller -> datapath). */
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. */
};
包含一些cookie，命令（command有0-4五种操作）。
个人总结
本次实验难度不大。但实验过程中确实也遇到了一些困难，一开始用miniedit编辑时忘了设置IP base，导致出错，漏了一些包没收到。后来用miniedit编辑好拓扑后直接点Run运行，虽然pingall等连通性测试都挺好的，但就是抓不到PORT_STATUS的包，目前还是不清楚为什么会这样。后来是保存为py文件后用sudo python再来抓包，就顺利抓到了所有种类的包。
本次实验让我体会到了sdn中是如何实现数据转发与路由控制的分离。数据转发不单单由switch操控，而是引入了controller来指导数据转发。除此之外，在分析源码的过程中，我也更深入地了解了openflow中各种消息的数据结构，了解了openflow中主要的消息类型。
