实验3：OpenFlow协议分析实践

基础要求只需要提交导入到/home/用户名/学号/lab3/目录下的拓扑文件，wireshark抓包的结果截图和对应的文字说明；
Hello
控制器6633端口（我最高能支持OpenFlow 1.0） ---> 交换机47796端口

交换机47796端口（我最高能支持OpenFlow 1.0） ---> 控制器6633端口

Features Request
控制器6633端口（我需要你的特征信息） ---> 交换机47796端口

Set Config
控制器6633端口（请按照我给你的flag和max bytes of packet进行配置） ---> 交换机47796端口

Port Status
当交换机端口发生变化时，告知控制器相应的端口状态。

Features Reply
Features Reply消息包括Openflow Header 和Features Reply Message
交换机47796端口（这是我的特征信息，请查收） ---> 控制器6633端口

Packet in
有两种情况会触发交换机向控制器发送 Packet-in 消息：
当交换机收到一个数据包后，查找流表。如果流表中有匹配条目，则交换机按照流表所指示的 action 列表处理数据包。如果没有，则交换机将数据包封装在 Packet-in 消息中发送给控制器处理，注意这时候数据包仍然会被放进缓冲区等待处理而不是被丢弃。
数据包在流表中有匹配的条目，但是其中所指示的 action 列表中包含转发给控制器的动作（Output = CONTROLLER），注意这时候数据包不会被放进缓冲区。
交换机47796端口（有数据包进来，请指示）--- 控制器6633端口

Packet out
不是所有的数据包都需要向交换机中添加一条流表项来匹配处理，网络中有些数据包出现的数量很少（如ARP、 IGMP等），没必要通过流表项来指定这一类数据包的处理方法。此时可使用 Packet-Out 消息，告诉交换机某一个数据包如何处理。控制器6633端口（请按照我给你的action进行处理） ---> 交换机47796端口

Flow mod
控制器收到 Packet‐in 消息后，可以发送 Flow‐Mod 消息向交换机写一个流表项。并且将 Flow‐Mod 消息中的 buffer_id 字段设置为 Packet‐in 消息中的 buffer_id 值。从而控制器向交换机写入了一条与数据包相关的流表项，并且指定该数据包按照此流表项的 action 列表处理。
Flow-Mod 消息共有五种类型：
ADD，用来添加一条新的流表项
DELETE，用来删除所有符合一定条件的流表项
DELETE-STRICT，用来删除某一条指定的流表项
MODIFY，用来修改所有符合一定条件的流表项
MODIFY-STRICT，用来修改某一条指定的流表项
以上五种类型对应的数值分别为0-4
控制器通过6633端口向交换机47796端口下发流表项，指导数据的转发处理


c)OpenFlow协议中交换机与控制器的消息交互过程，画出相关交互图或流程图

d)交换机与控制器建立通信时是使用TCP协议还是UDP协议？
使用的是TCP协议

进阶要求为选做，有完成的同学请提交相关截图对应的OpenFlow代码，加以注释说明，有完成比未完成的上机分数更高。
hello

/* 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. */
};
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;
  };
  Features Request
  控制器6633端口（我需要你的特征信息） ---> 交换机47796端口
  
  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. /
  };
  Set Config
  控制器6633端口（请按照我给你的flag和max bytes of packet进行配置） ---> 交换机47796端口
  
  enum ofp_config_flags {
  / Handling of IP fragments. /
  OFPC_FRAG_NORMAL = 0, / No special handling for fragments. /
  OFPC_FRAG_DROP = 1, / Drop fragments. /
  OFPC_FRAG_REASM = 2, / Reassemble (only if OFPC_IP_REASM set). /
  OFPC_FRAG_MASK = 3
  };
  //flag不同的值代表不同的处理方式
  / Switch configuration. /
  struct ofp_switch_config {
  struct ofp_header header;
  uint16_t flags; //用来指示交换机如何处理 IP 分片数据包 / OFPC_* flags. /
  uint16_t miss_send_len; //用来指示当一个交换机无法处理的数据包到达时，将数据包发给控制器的最大字节数。 / Max bytes of new flow that datapath should
  send to the controller. /
  };
  OFP_ASSERT(sizeof(struct ofp_switch_config) == 12);
  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;
  };
  OFP_ASSERT(sizeof(struct ofp_port_status) == 64);
  //这个是当交换机端口发生变化时，告知控制器相应的端口状态
  //发生变化包括增加、删除、修改物理端口，则需发送port status来告知
  Features Reply
  Features Reply消息包括Openflow Header 和Features Reply Message
  交换机6633端口（这是我的特征信息，请查收） ---> 控制器47796端口
  
  / Switch features. /
  struct ofp_switch_features {
  struct ofp_header header;
  uint64_t datapath_id; //唯一标识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. /
  };
  OFP_ASSERT(sizeof(struct ofp_switch_features) == 32);
  物理端口描述列表如下图
  
  Packet in
  
  / Why is this packet being sent to the controller? /
  enum ofp_packet_in_reason {
  OFPR_NO_MATCH, / No matching flow. /
  OFPR_ACTION / Action explicitly output to controller. /
  };
  //分析抓取的数据包，可以发现是因为交换机发现此时自己并没有匹配的流表（Reason: No matching flow (table-miss flow entry) (0)）,所以要问控制器如何处理
  //第一行是没有匹配的条目，第二行是action列表中包含转发给控制器的动作。
  //两种情况：1.交换机查找流表，发现没有匹配条目,但是这种包没有抓到过2.有匹配条目,对应的action是OUTPUT=CONTROLLER,固定收到向控制器发送包（分别是这上下两段代码）
  / Packet received on port (datapath -> controller). /
  struct ofp_packet_in {
  struct ofp_header header;
  uint32_t buffer_id; //Packet-in消息所携带的数据包在交换机缓存区中的ID / ID assigned by datapath. /
  uint16_t total_len; //data字段的长度 / Full length of frame. /
  uint16_t in_port; //数据包进入交换机时的端口号 / Port on which frame was received. /
  uint8_t reason; //发送Packet-in消息的原因 / 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);
  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; //可以是ADD,DELETE,DELETE-STRICT,MODIFY,MODIFY-STRICT / 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; //缓存区ID ,用于指定缓存区中的一个数据包按这个消息的action列表处理 / 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; //标志位，可以用来指示流表删除后是否发送flow‐removed消息，添加流表时是否检查流表重复项，添加的流表项是否为应急流表项。 / One of OFPFF_*. /
  struct ofp_action_header actions[0]; //action列表/ The action length is inferred
  from the length field in the
  header. /
  };
  OFP_ASSERT(sizeof(struct ofp_flow_mod) == 72);
  packet-out
  
  / Send packet (controller -> datapath). /
  struct ofp_packet_out {
  struct ofp_header header;
  uint32_t buffer_id; //交换机缓存区id，如果为-1则指定的为packet-out消息携带的data字段 / ID assigned by datapath (-1 if none). /
  uint16_t in_port; //如果buffer_id为‐1，并且action列表中指定了Output=TABLE的动作,in_port将作为data段数据包的额外匹配信息进行流表查询
  / Packet's input port (OFPP_NONE if none). /
  uint16_t actions_len; //action列表的长度，可以用来区分actions和data段 / 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);
  个人总结，包括但不限于实验难度、实验过程遇到的困难及解决办法，个人感想，不少于200字。
  这次的实验和上次实验非常像，在抓包对照分析过程的时候我感觉并不是很难，最大的难点是在于从openflow.h中找到各自报文的源代码，并加以分析，在这其中我把一个顺序问题弄错了，导致不能完整的抓到包，最后，我也终于明白了，抓包的时候需要先开启wireshark在去启动openflow，这样才可以讲所有报文都抓到，