流表 FlowTable --- OpenFlow的核心
问题3 流表项 Flow Entry
单流表(OpenFlow 1.0版本) -> 多流表(OpenFlow 1.3版本)
组成1(OpenFlow 1.0)：Header Fields | Counters | Actions
不同版本的OpenFlow协议的流表项 不一样。OpenFlow 1.0版本包括了包头域，计数器，动作三个部分。
流表项包头域 --- 匹配
可以看出来，除了进接口，传统OSI七层模型中2-4层的寻址信息都包含在报头域中了：目的IP地址，源IP地址，目的MAC地址，源MAC地址，端口号···
因此，流表约等于 路由表 + MAC地址表 + 端口号··· 包含了原有OSI七层所有的寻址信息。
也就是说：OpenFlow交换机 相比 传统网络的交换机 是一个比较模糊的概念，不再区分交换和路由；所以 OpenFlow交换机 可以广义理解为 OpenFlow转发设备 (路由器，交换机，防火墙)。
从小的方面来看，SDN交换机是一个传统意义上的OSI二层设备；从大的方面来看，它是一个”具有七层结构“(指的是 具有所有七层寻址信息)的交换机。
有新意的地方：取消了传统网络 中间路由 的分层结构 分层次进行匹配；把所有的信息一次性进行匹配。
计数器 --- 流量可视化
传统网络的计数器这一方面，是一个弱项；虽然TCP有 四个定时器：重传定时器，坚持定时器，2MSL定时器，保活定时器，IP有TTL字段，但是没有比较多的技术支持对数据流进行计数。
也就是说，在传统网络里面，你不知道通过每一个接口的流量具体有多少，在这条链路上已经跑了多少流量。
简单来说，就是流量可视化。
SDN需要支持流量可视化，方便管理人员和用户根据可视化的流量来指定一些策略：比如拥塞控制，提高链路带宽的利用率等等。
计数器 Counters 主要对每张表，每个端口，每个流进行计数：方便监管流量。
比如：经过这个端口已经有多少流量了？匹配这个流表项的数据报有多少了？这个表项 或者这张表 查找多少次了？
如果所有的交换机支持计数器，那么每一个交换机都根据计数器向控制器汇总流量信息，那么控制器就很容易生成一张全局的流量图，方便用户对流量进行监控和制定策略。
这是 SDN 中很核心的一点，很有新意的一点。
Actions 动作 流表项的关键 --- 按需修改
Action 动作 是对匹配该表项的流的操作。
传统网络的动作，就两种：要么进行转发，要么进行丢弃。而SDN中的动作，非常的多。
原因：OpenFlow协议需要支持 源目IP地址，源目MAC地址等等的 按需修改。
OpenFlow 1.0规定了必备动作(Required Actions)，和可选动作(Optional Actions)。
必备行动1 -转发 Forward
- 泛洪选项，ALL -转发到所有出口(但不包括入口)，相当于往所有接口泛洪。
- 给控制器，CONTROLLER -封装并转发给控制器
- 找本地，LOCAL -转发给本地网络栈
- 按表执行，TABLE -对要发出去的包执行流表内的动作
- 从哪里来从哪里去，IN_PORT -从入口发出
必备行动2 -丢弃 Drop
没有明确指明 处理行动 的表项，将匹配的所有分组默认丢弃。
可选行动1 -转发 Forward
- NORMAL -按照传统OSI七层模型中的第二层(源目MAC)，或者是第三层(源目IP)进行转发。
- FLOOD -通过最小生成树从出口泛洪发出，不包括入口。
可选行动2 -入列 Enqueue
将包转发到 绑定某个端口的队列 中去；常用于管道限速。
非常重要的 可选行动3 -修改域 Modify-field
修改报头内容 这是和传统网络最大的区别：OpenFlow能够对报头信息进行修改。
很明显，OpenFlow所提供的流表，表项比传统网络路由表等 更加丰富，操作，执行动作比以前更加繁多。
组成2(OpenFlow 1.3)：Match Fields | Priority | Counters | Instructions | Timeouts | Cookie
在1.3版本中：流表项包头域 -> 匹配域；多了一个 优先级；动作 -> 指令；增加了 超时时间 和 缓存信息。
从1.0版本开始，OpenFlow支持多流表：每张流表都有独立的序号，从序号最小的流表开始匹配，每张表进行独立的处理操作。
匹配域 -匹配
匹配域是之前1.0包头域的拓展，匹配内容除了OSI二到四层的寻址信息(MAC，IP，PORT)之外，多了MPLS，IPv6，PBB，Tunnel ID 等支持；1.0版本能匹配12个信息，1.3版本能够匹配39个信息。
这样做的原因，是为了尽量减小传统网络协议对SDN的影响；如果还有OpenFlow尚未支持的协议，那么就通过混合型网络来支持。当OpenFlow发展到支持匹配所有路由信息的时候，那么就可以摒弃掉原来传统网络路由转发的机制了。
趋势：传统路由选择协议 -> 混合协议(OpenFlow 与 传统路由选择协议 共存) -> OpenFlow协议 SDN时代。
优先级 -优先匹配
顾名思义，用于标志流表项匹配的优先次序，优先级越高 越早匹配，默认为0。
计数器 -流量可视化
和之前类似，主要对 流，表，端口 做统计，方便进行流量监管。
在原有基础上，加入了 每组，每个动作集的计数。
指令(这里只列举部分指令) 是之前动作的抽象 增加了非常多的内容
需要弄明白：动作，动作集，指令。
在新的版本中，指令相比动作增加了非常多的内容，因为引入了多流表的概念，所以多了很多的指令(动作，动作集，指令)。
必备指令：Write-Actions action(s)：将指定的命令添加到命令集中。也就是说，命令不一定要马上执行，可以积累到命令集中，类似一个脚本，然后一起共同执行。
附加指令：Apply-Actions action(s)：立即执行指定的动作，不改变行动集。
在1.3中，命令不一定马上执行：比如Drop，Next Table，Forward等等，它可以直接执行，也可以先 预缓存 到一个动作缓存中(或者说，动作集)。
附加指令：Clear-Actions：在动作集中 立即清除所有的行动。
举个例子，在 流 匹配了多个流表表项之后，通过指令积累了一定的动作，如果感觉到不是特别满意，就可以在下一个流匹配的表项中加入 Clear-Action 这个指令，清除掉之前积累的所有动作。
总的来说，1.3版本的流表项，所支持的逻辑需求 更加丰富。
在1.0版本的时候，动作是一个一个执行的，没办法集中处理；而1.3的话，允许动作集中执行，通过命令形成动作集，或者看这些动作不顺眼，用一个Clean-Actions清空命令集。
注意：
在1.3中，需要清楚的概念是：流表项中有指令Institution和动作Action之分，流表项中的指令 是用于影响动作的：比如通过指令将动作添加到动作集中，或者通过指令清空动作集。
而动作则是一系列对流的操作，比如丢弃，封装之后交给交换机，或者是转递到哪一条链路等等。
这也体现了SDN的一个理念：在原有平面上抽象出一个抽象层，比如我们这里就是从动作中抽象出指令，通过这个抽象层更加方便的进行管理与操作，就像图形界面之于命令行一样。
引用一段话，源自一篇博文SDN：软件定义网络
纵观计算机的发展历程，各方面都可以看到通过增加类似的虚拟化层次来提高生产效率的案例。比如高级语言之于汇编，比如图形界面之于命令行。这种添加层次的解决方案，总是能让问题得到更清晰的解决。回到指令
在视频教学内，指令分成四块内容：第一块是指令，第二块是动作，它们之间的关系在上面的 注意 已经提及了。
那么第三块，是用来干嘛的呢？
既然，我们使用了第一块的指令，让第二块的动作添加或者是删除到动作集中，目的是为了更好的管理动作；那么当动作需要统一进行的时候，如何确定 动作集中的动作 的先后顺序呢？
比如动作集中 有两个动作添加了进来，一个是将流A封装交给控制器，另外一个是将流B丢弃，哪一个先执行呢？
类比于BGP协议，动态选路确定最优路的时候，有那么多的影响因素，如何确定这些因素影响的优秀级？
指令的第三块内容，就是用来干这个的：它们确定了动作集中动作执行的优先顺序。
指令部分 总结
行动集与每个报文相关，默认为空。
一个流表项可以通过 Clear-Action 和 Write-Action 两个指令来对行动集进行操作。
当一个表项的指令集没有包含 Goto-Table 指令的时候，流水线就停止了(即不用再去查找另外一张流表)，然后报文的行动集就被执行。
注意：多张表的查找，叫做流水线处理。
交换机可以通过 Apply-Actions 修改动作执行顺序。
行动集包括所有的行动，无论它们以什么样的顺序加入到集中，执行的顺序始终按照优先级来进行。
我的理解：流找到对应的表项 -> 表项的指令 将表项的动作添加到动作集中/将动作执行 -> 由表项中的优先顺序(上面的第三部分)确定动作的执行顺序 -> 指令集中没有遇到 Goto-Table指令 按照顺序执行动作集中的动作
也就是说，表项中(1)有指令集，指令集中有 将动作抽象成逻辑层集中处理的指令(Write-Action & Clear-Action) 还有 定义先后顺序的指令；(2)有匹配执行的动作
超时时间 Timeout
用于标志该流表项的 老化时间，到了超时时间限制就删除，目的：节省内存资源。
附属信息 Cookies
由控制器选择的 不透明数据值，控制器使用Cookies来进行 过滤流的统计数据(计数器的相关信息)，流改变，流删除。
但是，当处理单个数据报的时候，不能使用。