论文阅读二：OpenFlow交换机流表溢出问题的缓解机制

名词解释：

Flow Table Sharing, FTS：流表共享方法

Least Recently Used, LRU：近期最少使用算法

Optional Replacement, OPT：最佳替换算法

“摘要：在软件新兴软件定义网络SDN、OpenFlow交换机中，为满足OpenFlow协议匹配域的需求，SDN交换设备需要更大的查找表存储容量．当流表溢出时，将导致控制报文数目爆炸性增长、数据包传输时延增大等危害网络正常运行的后果．然而考虑成本因素，高速查找表容量不可能无限增加．即使单纯地增加流表容量，并不能使溢出的概率降低为零，且极不经济．本文分析了网络流量的特征，提出了一种流表共享方法（Flow Table Sharing,FTS），针对流表溢出现象带来的危害，完善了Table-Miss处理机制，有效遏制了由于流表溢出而引发的危害网络正常运行的情况。相比目前的Table-Miss处理方式，FTS对流表溢出情况下控制消息数量和RTT时间的优化都达到两个数量级。此外，该文针对流表扩散方法设计了简单高效的基于OpenFlow组表的随机路由选择算法，系统结构实施简单，可以方便地降级为现行的通用Table-Miss处理模式。“

1 引言

1.1 背景介绍

OpenFlow 协议中描述：当数据包成功匹配一条流表项，其表项相应的动作集（Actions）将被执行。如果数据包没有 被任意一条流表项匹配，这种情形将被定义为 Table-Miss（未匹配）。目前，处理 Table-Miss 的方式为丢弃数据包或者将数据包发送到控制器端，再由控制器端最终决定此数据包的处理方法。

基于 TCAM 的流表容量通常比较小，并且极有溢出的可能，流表溢出会引发数据包 Table-Miss、数据包丢包现象，使得交换机转发性能大幅降低，甚至会产生 SDN 控制报文数量爆炸，给 SDN 控制器的安全造成隐患。

尽管增大流表容量可以减少流表对更新速率的需求，文章指出当流表容量以指数增大时，设备对流表更新速度需求的缓解并不显著。

在实际应用中，若 SDN 交换机的流表资源不足，对于最终来不及更新的那部分流，交换机会将它们以 Table-Miss 的形式处理。从目前的控制策略来看，每一个 Table-Miss 事件，SDN 交换机都会给 SDN 控制器发送一个 Packet-In 消息。当控制消息过多时，会引发控制器运算能力阻塞，阻碍控制平面对数据平面的即时控制能力，进而导致数据平面转发效率下降等问题。

1.2 相关工作

提升流表更新速率是解决 Table-Miss 问题的关键，优化由TCAM组成的高速查找器的更新时间是提升速率问题的核心。但TCAM的流表项删除、替换与更新操作都比较复杂，且TCAM有效容量低，能够存储的流表项条数也比较少。

研究提高流表更新速率的问题通常从两方面入手：

（1）提升流表项的数量；

（2）提高数据平面流表的更新速度：Kannan等人提出的一种更新机制，提前探测流表中的死流并将其删掉，为添加新流表项做空间预留工作，降低流表溢出的风险，提升更新速度。

但这些方法的核心目标是增加交换机有效流表空间，尽量拖延流表溢出的发生，没有考虑流表溢出后导致网络性能下降的问题。针对第一类问题，诸如分布式多控制器架构、控制器中间代理层等被提出，提升了控制器消息处理的能力。
因此本文提出一种流表共享机制FTS，其关键思路是借用邻居节点空闲流表资源缓解本地流拥塞。FTS部署简单，耗费硬件资源极小。同时为避免流表查找策略的冲突，FTS修改了OpenFlow协议中对Table-Miss 的处理方式，当流表溢出后对未匹配的流使用本地路由策略转发，无需立即请求控制器，也不会在本机内安装新流表项。

2 流表溢出问题分析

两个源于SDN架构的挑战：

（1）控制平面——超多消息，导致控制系统庞大复杂、性能要求极高；

（2）数据平面——因流表空间不足产生转发性能瓶颈。

针对第一类问题，诸如分布式多控制器架构、控制器中间代理层等被提出，提升了控制器消息处理的能力。而第二个问题最根本的原因是流量的起伏波动，流数目暂时越过了交换机容量的上限，导致单个交换机性能下降，进而导致整体网络服务质量下降。

3 流表共享机制设计

目标：缓解由于流表溢出而造成的转发能力下降或暂时无法提供服务的现象。从两方面进行优化：（1）允许流表溢出的交换机转发新流；（2）减小重复控制消息的数量。

3.1 允许流表溢出的交换机转发新流

问题：没有建立流表的流无法被交换机转发。经典的（匹配-执行）操作方式规定数据包在被匹配成功之后才能被处理，当交换机内没有容纳新流的流表空间时，新流匹配表项无法被安装，交换机也无法对新流执行任何操作。

目标：当交换机流表溢出时允许转发。

解决思路：为交换机增加随机转发模式，将流量随机地转发到邻居节点，只要转发方向不等于入端口以避免路由环路的产生即可。邻居节点和本节点同时发生流表溢出的概率很小，即这条流会有更大的可能性成功地在邻居节点上建立正确的策略性转发路径。

3.2 减小重复控制消息的数量

问题：新流的频繁到来引发重复的Packet-In消息。Packet-In消息携带了包头信息给控制器，对交换机而言，当前时间段内无法处理的包都可归为新流，导致携带相同包头信息的控制消息反复在安全通道内传递，降低有效控制信息通信效率。

解决思路：将通配转发引入到随机转发模式，通配任何数据包包头，保证数据包被处理而不产生重复的Packet-In消息。

4 随机路由策略与实现

假设网络中流表溢出只存在于随机的少量的转发节点中，采用缓解机制后的网络结构图如下：

若交换机S2流表溢出，此时新流到达，匹配为Table-Miss且交换机不产生Packet-In消息，即在交换机流表溢出后，仅在本地执行离线策略，通过本地计算快速得到新流的转发动作，从而避免将新流的数据包丢弃。

4.1 随机路由离线策略设计

数据包到达交换机首先查找流表，匹配成功后执行已经设定的处理操作如更新计数器、执行指令集等，之后判断流表是否处于溢出状态并且是否需要触发Table-Miss事件；如果没有溢出则直接执行最终的动作集，包括但不限于触发Packet-In消息；如果流表溢出，则在交换机本地计算数据包的转发端口。

包含缓解机制的交换机与经典SDN交换机的区别只在发现Table-Miss事件时，判断交换机是否处于流表溢出状态；以及在交换机离线处理策略中的out_port端口计算算法的实施。

总体流程设计如下：

（1）流表匹配，得到packet是否为Table-Miss。

（2）根据metadata以及交换机自身判断提供的流表使用率，判断是否需要本地计算。

（3）流水线内的out_port算法计算数据包的转发端口。

（4）执行动作集。

其中必须满足的限制条件：

（1）随机转发之后的出端口out_port不能等于入端口in_port，否则会产生环路。

（2）为满足吞吐率，out_port随机算法必须简洁高效。

硬件实施上的挑战：

（1）实现随机，没有现成的指令集可以完成随机指定动作集。

（2）目前OpenFlow协议规定的硬件流水线还没有明确判断流表是否溢出的流水线级，修改SDN交换机流水线则改变了标准的协议，会导致交换机可扩展性差的缺点。

基于以上，选择以组表作为SDN交换机实施随机转发的关键组件。

4.2 随机路由策略组表方式实现

 组表时交换机流水线动作集的一种形式，将多个动作集内容通过一定算法联系到一起，给数据包带来更灵活的操作方式。OpenFlow协议规定组表的SELECT算法可以由外部用户自己定义，此选择算法用来选择任意一个可执行的桶；当属于一个选定桶的动作集出端口丢失连接，逻辑会自动将桶范围缩小至剩余的可用桶并重新选择，即利用随机选择桶算法实现随机。

对于数据包出端口不能包括入端口，采用额外组表选择算法剔除入端口，即如果算法判断交换机流表使用正常没有溢出，直接选择转发向CONTROLLER的桶；在溢出的情况下，选择out_port时同时比较in_port，一旦发现out_port与in_port相同则向后跳一个桶执行。这种方法空间复杂度低：流表O(1)、组表O(N)，初始化无延迟，但需要更换组表内的选择算法。

---

算法1 外部选择算法

---

组表结构：（1）组表编号；（2）组表类型；（3）计数器；（4）一个或多个桶；（5）随机选择算法；（6）外部选择算法。其中随机选择算法默认为硬件令牌环算法。

如图7所示，想要除能扩散算法，只需要将前N个buckets的权重设置为0或设置某些buckets的权重为0，即可关闭向对应邻居扩散。

5 实验

实验测试：（1）利用软件仿真平台，对比FTS与优化之前转发性能的优劣；（2）在真实拓扑上测试流表共享机制的实际部署开销。

5.1 性能测试：转发时延与控制消息数量

实验平台：x86服务器、Intel i3 CPU、8GB内存、ubuntu14.04、远程ryu控制器

实验过程：使用MININET仿真工具建立单节点转发拓扑，用iperf工具分别测试RTT以及转发速率，利用wireshark抓包工具分析安全通道内控制消息的数量。

实验结果：经过多次iperf流量导入测试后得到结果，当流表溢出时UDP数据包有15%的丢包率，TCP数据包没有丢包。同时，当经过FTS优化后，再次发生流表溢出时，转发延迟从768ms下降到8ms以内，优化了2个数量级。这是因为FTS机制寻找到其他转发路径并建立转发，大大降低控制器的反复控制操作次数，且最多只需要多耗费建立一次流表项的时间。

5.2 代价测试：额外消耗流表项资源与路径

基本思路：

（1）流量仿真，生成拓扑的端口到端口完全覆盖所有点对点的流，可以保证点点之间互达，流表信息也最完整。（实际情况下同一时间内网络流量不是点点互达。）

（2）溢出仿真，假设每次仿真均有一个节点发生流表溢出，针对这个节点实施流表共享算法。分别得到向所有邻居节点随机转发后的变量结果，得出统计值后归一化，以表示统计数据的概率密度。

由于FTS借用了邻居交换机的流表项，流表总使用率与邻居个数成正相关。如图a：三角图线是正常情况下的流表使用数量，圆形线条是对新流实施FTS所需要的流表项数量，方块线条是对正常流突然中断后使用FTS立即恢复通信所需要的流表项数量。

 图b显示了FTS对数据包跳数的影响，三角图线是正常情况下数据包的跳数，圆形图线表示FTS会增加到达路径的平均长度，方形图线表示FTS的流对正常情况下多出的跳数。95%的概率FTS增加的跳数不会高于2跳。

图12显示：在95%的情况下路径增长率不会达到最短路径长度的199%。

6 总结

FTS扩展了OpenFlow交换机的Table-Miss处理方式，有效缓解流表溢出现象带来的巨大的网络通信性能损失。FTS有以下三个优点：

（1）在流表溢出时段内，FTS相比于现在常用的Table-Miss处理方式可有效降低控制消息数量和RTT时延2个数量级；

（2）提出一种有效的快速的外部组表选择算法；

（3）FTS易于在真实交换机上实施和控制，占用硬件资源少，现行Table-Miss处理模式是FTS机制的一种特殊形式。

后续：提高实验精度以发现FTS机制存在的问题。

7 补充（论文阅读一）

OPT，替换下次访问距当前时间最长的页，它需要知道操作系统将来的事件，显然不可能实现，只能作为一种衡量其他算法的标准。