2.1 第二章 OpenFlow1.0中的流表和流表项
- 流表项的构成因素因OpenFlow版本的不同而有所差异。在OpenFlow 1.0中，构成三要素为头字段、计数器、行动；在OpenFlow 1.1中，构成要素为匹配字段、计数器、指令集；OpenFlow 1.3中的构成要素为6个。
- 即使OpenFlow交换机有多个流表，在OpenFlow 1.0中，匹配的流表项也只有1个。而在OpenFlow 1.1以上的版本中，规范已发生变更，数据包可以在各流表中与流表项匹配，即可以与多个流表项匹配。
2.2 流表项
- OpenFlow中可以存在多个流表，但必须从流表0开始匹配。若编号为0的流表中不存在与数据包相匹配的流表项，而其他流表中存在的话，则前进到下一流表中执行匹配。但是OpenFlow规范并未对“下一流表”进行明确说明，这一概念需依据OpenFlow交换机的实现来决定。
- OpenFlow交换机可通过建立安全通道时的Features消息确认自身所支持的流表个数。有的OpenFlow交换机只有一个0号流表。
- 数据包与OpenFlow交换机中任何一个流表项都不匹配的情况称为Table-miss。发生Table-miss时，利用Packet-In消息将数据包转发至控制器，或丢弃数据包。具体是发送Packet-In消息还是进行丢弃操作要根据设置来决定。在OpenFlow1.2及其以前的版本中，发送Table-miss时的默认设置为发送Packet-In消息，但在OpenFlow1.3中，变更为了将数据包丢弃。
- OpenFlow 1.0中规定了要按照数据包的种类去执行头字段解析：
- 在OpenFlow1.0的规范中，及时数据包可能与多个流表项匹配，最终匹配的流表项也只有1个。若数据包与多个流表项匹配，则按照流表项的优先级执行匹配。行动优先级相同时，则根据交换机的具体实现来执行。
- OpenFlow1.1规范对头字段解析的规范进行了修订，OpenFlow1.2则废除了该规范。
- 在OpenFlow1.0中有4种计数器：各流表的Per Table 计数器、各物理端口的Per Port计数器、各流表项的Per Flow计数器、各队列的Per Queue计数器。
- Per Table计数器：
-
Per Port计数器：
-
Per Flow计数器：
-
Per Queue计数器：
2.3 行动
- OpenFlow1.0 中定义了如下四种行动。转发Forward（必备）、丢弃Drop（必备）、向队列转发数据包Enqueue（Optional）、改写数据包内容Modify-Field（Optional）。
- OpenFlow1.1版本以后的Forward行动更名为Out-put行动。详见第七章。
- OpenFlow1.0 中的Forward行动包含多种动作，如下表：
-
在OpenFlow规范说明书中，将Forward行动标记为OFPAT_OUTPUT。另外将ALL、CONTROLLER、LOCAL、TABLE、NORMAL、IN_PORT、FLOOD作为表示输出目的地的虚拟端口，分配了如下表所示的16 bit的数值（在OpenFlow1.1中，虚拟端口由16 bit变为32 bit）。
- Forward行动是指“向指定的端口发送数据包”的行动。在OpenFlow1.0中，端口号的识别用16 bit来表示，物理端口和虚拟端口都可以用该字段表示。举例：
- 将数据包Forward至物理端口1：Forward 1；
- 将数据包Forward至所有物理端口：Forward 0xfffc；
- 将数据包Forward至控制器：Forward 0xfffd。
- 根据虚拟端口的定义，OpenFlow交换机可使用的物理端口号上限为OFPP_MAX（0xff00）。因此在OpenFlow规范中，1台SW交换机可配置65280各物理端口（序号从1开始）。
- Drop行动：只有Drop行动能丢弃与未指定Forward行动的流表项相匹配的数据包。
- 除Drop行动外，在OpenFlow规范中还存在明确丢弃特定种类数据包的规范，例如，丢弃在端口设置过程中用于STP的数据包以及丢弃IP碎片等。
- Enqueue行动：是指将数据包转发至现有的已设定的队列中，就是在等待队列的末尾添加数据包。（不是很理解这个队列的用途，书中的意思是队列可用于支持实现Qos等功能，先挖个坑。）
- 从OpenFlow 1.1开始，Enqueue行动改名为Set-Queue行动。
- Modify-Field行动：在OpenFlow规范中，Modify-Field虽然是可选行动，但它属于OpenFlow非常重要的特征，强烈建议进行实现。其行动一览如表所示：
- 在OpenFlow 1.0中，不能执行上表以外的Modify-Field行动。在OpenFlow 1.1中已增加了变更IPv4头所包含的TTL数值的规定，但在OpenFlow1.0 中无法变更。
- 从OpenFlow 1.1 开始，Modify-Field行动更名为“Set-Field行动”
2.4 控制器和交换机之间的消息
- OpenFlow交换机是通过安全通道和OpenFlow控制器连接的。安全通道通过控制面网络来建立，不受OpenFlow交换机中的流表项的影响。
- 在OpenFlow规范中，安全通道通过TLS来实现。OpenFlow控制器和OpenFlow交换机使用服务器证书和客户端证书进行认证。不过有时也会通过TCP明文来建立。
- 建立安全通道的TCP端口号默认使用6633号。2013年IANA分配了用于OpenFlow的TCP/UDP端口6653，因此在这之后制定的OpenFlow 1.0.2/1.3.3/1.4中，建立安全通道的TCP端口号默认使用6653号。
- 为了建立连接，需要事先对OpenFlow交换机设置OpenFlow控制器的IP地址及TCP端口号。（这个在【培训实验记录】锐捷SDN交换机和控制器部署中有提到相应的配置命令）
- OpenFlow消息由64bit （8个八位字节）组成。所有OpenFlow消息都是由OpenFlow头开始。
- OpenFlow头的格式为：
- OpenFlow头的各字段内容：
- OpenFlow头的type字段所指定的OpenFlow消息的类型：
- 控制器与SW的安全通道的建立步骤：由OpenFlow交换机对控制器建立未加密的TCP连接或基于TLS的连接 -> 确定安全通道中要使用的OpenFlow版本（互发Hello包）-> 握手（控制器发Features_Request包，交换机回Feature_Reply包）-> 交换其它必要的设置等（控制器向交换机发送SET_CONFIG消息以发送设置信息，或发送GET_CONFIG请求消息以查询OpenFlow交换机的设置状态）。
- Flow-Mod消息：控制器对交换机设置流表项的消息。通过Flow-Mod消息，可对流表项进行添加、删除、变更设置等操作。在OpenFlow 1.0中将基于Flow-Mod的命令种类定义为ofp_folw_mod_command，具体分为五种：
- 在OpenFlow交换机中，若已存在与OFPEC_ADD命令的Flow-Mod消息描述的内容完全相同的流表项，OpenFlow交换机会删除相应的流表项，同时将相应的计数器清零，并重新设置新的流表项来替代旧的。
- OFPEC_MODIFY将变更匹配流表项的设置内容，但在OpenFlow交换机中如果不存在相应的流表项时，OFPEC_MODIFY将与OFPEC_ADD采取相同的处理，在OpenFlow交换机中设置新的流表项。在OpenFlow1.2中删除了这一规范，在1.2以上的版本中，OFPEC_MODIFY不再添加新的流表项。
- 不带有_STRICT的命令其对象可能是多个流表项。带有_SRTICT时，则要求包含通配符数值在内的所有字段保持完全一致，因此只以单一流表项为对象。
- 流超时处理是另一种删除流表项的方法。在添加流表项时设置idle_timeout及hard_timeout的值，当与流表项匹配的数据包超过idle_timeout值或者流表项添加后超过hard_timeout值时就删除流表项，单位为秒。
- Flow-Mod消息的结构：
- Packet-In消息：目的是为了将到达OpenFlow交换机的数据包发送至OpenFlow控制器。以下两种情况即可发送Packet-In消息：1.Table-miss（OpenFlow 1.3中默认动作改成Drop了，这里姑且先记录1.0的机制）2.匹配的流表项中记载的行动为“发送值OpenFlow控制器”。
- 发送Packet-In消息时交换机可以分为缓存数据包或不缓存数据包两种情况。不缓存时buffer_id字段设为-1，并将整个数据包发送至控制器。
- 不存在通知交换机中缓存数据包已经被删除的机制。如果要使用交换机中的缓存，就要把握删除缓存数据包的时机，要么就还是不使用OpenFlow交换机中的缓存比较好。
- Packet-In消息及其各字段内容：
- Packet-Out消息：从控制器向交换机发送的消息，包含数据包发送命令。若交换机的缓存中已存在数据包，而控制器发出“发送该数据包”的命令时，这条消息指定了表示相应数据包的buffer_id。
- 使用Packet-Out消息还可以将OpenFlow控制器创建的数据包发送至OpenFlow交换机。此时buffer_id置为-1，而Packet-Out消息的最后添加数据包数据。
- Packet-Out消息及其各字段内容：
- Port-Status消息：在OpenFlow交换机中添加、删除或修改物理端口时，需要发送Port-Status消息来通知控制器。（交换机 -> 控制器）
- Flow-Removed消息：当OpenFlow交换机中设置的流表项超时时，交换机要向控制器发送Flow-Removed消息。为了保证OpenFlow控制器收到该消息，仅在其发出请求时才发送。
- Error消息：通知出现了某种错误。交换机和控制器都可发送Error消息。
- Error消息包括表示错误类型的type字段和表示错误详情的code字段。Code字段之后的数据部分根据type和code的组合不同而发生变化。
- Error消息的类型（type字段）：
- Barrier消息：使用安全通道发生消息的一方有时并不知道接收信息方处理消息的程度。为了解决类似问题，在OpenFlow协议中备有称为Barrier消息的机制。Barrier消息的目的是掌握消息的处理程度，虽然很普通，但它是OpenFlow协议的重要机制之一。
- Barrier请求消息和与其相对应的Barrier响应信息都只有OpenFlow消息头，不包含消息体。
- 下图为Barrier消息的使用示例。接收Barrier请求消息的一方在收到消息后，结束对在此之前所收到的所有消息的处理，通过返回Barrier请求消息中携带的xid，通知消息发送方消息处理的完成程度。发送Barrier请求消息的一方，通过确认Barrier响应消息，掌握对方消息处理的完成程度。
- Echo消息：OpenFlow控制器和OpenFlow交换机可以通过发送Echo请求消息来确认二者之间是否连接、检测通信延迟、测量通信带宽等。接收Echo请求一定会向对方返回Echo响应消息，如下图。
- 在很多系统中，为了确认安全通道是否连接而使用Echo消息。如果一定时间内未收到对Echo请求所作出的响应，则视为在安全通道中发生了故障。
总结：
阅读本章的时候听学姐说这本书讲的并不是很好，而且大多基于OpenFlow1.0展开描述，推荐我直接看openflow-spec-v1.3.0。的确看得过程中我也一直更想知道，现在更常用的协议1.3内容是改成什么样了。不过开始看这本书也是因为想准备一下SDN比赛的理论部分，之后可能快速的浏览完后面的章节，就不作记录了。