论文笔记 |【sosr 16】CacheFlow：Dependency-Aware Rule-Caching for Software-Defined Networks

作者：新熊君
知乎：新熊君

---

ABSTRACT

SDN允许控制应用程序在基础交换机中安装细粒度的转发策略， TCAM可以使用灵活的通配规则模式在硬件交换机上实现规则的快速查找，但是TCAM的高成本和高功耗限制了交换机可以支持的规则数量，同时也无法支持规则表的快速更新。

这篇论文（CacheFlow）展示了如何通过结合硬件和软件的优点来实现高速转发，支持大规模的规则表及快速更新。

CacheFlow缓存了小型TCAM中最热的规则，同时依靠软件来处理少量的“cache miss”流量。然而，因为规则直接存在重叠和依赖，我们不能直接应用现有的cache替换算法。同时CacheFlow不会缓存大量的依赖规则链，而是“拼接”长的依赖链以缓存较小的规则组，同时保留策略的语义。

通过实验，证明了规则拼接可以有效利用有限的TCAM空间，同时可以快速适应规则和流量需求的改变。

INTRODUCTION

在SDN中，有一个逻辑集中的控制器通过在基础交换机中安装简单的数据包处理规则来管理流量。这些规则可以在大量的包头字段进行匹配，并执行简单的操作，例如forwarding, flooding, 修改headers和将数据包定向到控制器。

这种灵活性允许启用SDN的交换机来当防火墙，服务器负载均衡器，网络地址转换器，以太网交换机，路由器等。然而，细粒度的转发策略导致了底层交换机存在大量的规则。

硬件交换机

在现代硬件交换机中，规则都存储在TCAM中。一个TCAM可以在线性时间内将一个数据包与所有规则的模式并行比较。然而，商业交换机只能支持较少的规则，通常只有几千或几万。

毫无疑问，未来的交换机将支持更大的规则表，但是TCAM仍然在规则表大小与其他考虑因素(例如成本和功耗)之间进行了基本的权衡。与传统的RAM相比，TCAM带来的成本和功耗约高出100倍。

此外，在TCAM中更新规则是一个相当缓慢的过程，今天的硬件交换机每秒仅支持40-50个规则表更新，这很容易通过动态策略来限制大型网络。

软件交换机

软件交换机看起来似乎是一个充满吸引力的替换选择。运行在商用服务器上的软件交换机可以在四核计算机上以大约40Gbps的速度处理数据包，并且可以将大型规则表存储在在主内存中，并将较小的规则表存储在L1 和L2 cache。

此外软件交换机可以比硬件交换机快十倍的速度更新规则表。
但是，支持在许多头字段上匹配的通配符规则对软件交换机造成了负担，软件交换机必须使用用户空间的慢处理（例如线性扫描）来解决每个流当中的第一个数据包。因此，他们无法与提供数百Gbps数据包处理（和高密度端口）的硬件交换机进行比较。

幸运的是，流量是服从齐夫分布，其中绝大多数流只匹配相当少数量的规则。

哈佛的语言学家zipf在研究语料库的时候发现的，所以也叫齐夫定律，按照单词在语料库中出现的次数排序，则该单词的排序数与其在语料库中出现频数成反比，或者说，二者乘积为一个常数。

因此，我们可以利用小型的TCAM来转发大多数流量，并依靠软件交换机来处理其余的流量。
例如，一个800 Gbps的硬件交换机以及40 Gbps的软件处理器可以轻松地以5%的 "miss rate"来处理TCAM中的流量。
将硬件和软件处理结合将支持控制程序实现高速数据包转发、更大型规则表和快速的规则更新。

CacheFlow 架构

CacheFlow架构包含了一个TCAM和一组 软件交换机，如下图所示

软件交换机可以在数据层的CPU（例如，网络处理器）上运行，作为硬件交换机上软件代理的一部分，也可以在单独的服务器上运行。

CacheFlow包含一个CacheMaster模块，用来接收来自未修改的SDN控制器的OpenFlow命令。CacheMaster保留了OepnFlow接口的语义，包括更新规则，查询计数器等。CacheMaster使用了OpenFlow协议将规则分发到未修改的商用硬件和软件交换机。CacheMaster是一个纯粹的控制层组件，控制会话以虚线显示和数据层转发以实线显示。

规则依赖性

正如其名字，CacheFlow将TCAM视作一个存储最大热度规则的缓存。然而，我们不能简单地应用现在的cache替代算法，因为规则可以在重叠的数据包集合上进行匹配，从而导致多个规则之间的依赖性。

实验中使用的交换机恰好就犯了这个错误，这也是新系统现在解决的错误。此外，尽管IP路由缓存的早期工作考虑了规则依赖性，但IP前缀仅有简单的“包含”关系，而不是部分重叠的模式。
部分重叠也可能导致较长的依赖链，而结合了多种功能的应用程序（例如服务器负载平衡和路由）会加剧这个问题。

为了处理规则依赖性，我们将优先级规则表表示成一个带注释的有向无环图（DAG），并设计用于往此数据结构增加和删除规则的增量算法。我们的cache替换算法使用了DAG来决定将哪些规则放进TCAM中。

为了为匹配大部分流量的规则保留空间，我们设计了一种新的拼接技术，该技术可以打破较长的依赖链。首先会创建少量的新规则来覆盖大量的不怎么被匹配的规则，来避免cache被污染。

该技术可以拓展到处理规则更新及规则随时间的改变。

贡献

• 增量规则依赖性分析：设计了一个算法用于增量分析和维护规则依赖性。

• 新的cache替换策略：我们开发了新的算法，只cache heavy-hitting rules以及少量的依赖项。

• 实验和评估：我们讨论了CacheFlow如何保留OpenFlow接口的语义。实验表明，通过缓存低于5%的规则，缓存命中率达到了流量的90%。

识别规则依赖

在本节中，我们展示了规则依赖是如何影响rule-caching技术的正确性以及依赖性是怎么发生作用的，同时展示了如何将跨规则依赖关系表示为图，并展示了可用于增量计算图的有效算法。

规则依赖性

交换机上的OpenFlow策略由一组数据包处理规则组成。 每个规则都有一个模式，一个优先级，一组操作和计数器。当数据包到达时，交换机将识别优先级最高的规则进行匹配，执行关联的操作并增加计数器。
CacheFlow通过将规则集分成两组来实现这些策略，一组驻留在TCAM中，另一组留在软件交换机中。

CacheFlow的语义是指：

• apply TCAM中最高优先级的匹配规则
• 如果TCAM中不存在匹配的规则，则apply 软件交换机中的最高优先级规则。

如果我们没有在TCAM中正确缓存规则，应该匹配TCAM中规则的数据包可能匹配到了软件交换机，从而导致数据包处理不正确。

如下图所示，不同优先级的规则之间可能存在依赖关系：

如果TCAM可以存储四个规则，则我们不能选择四个具有最高流量的规则（即R2，R3，R5和R6），因为应该匹配R1（具有模式000）的数据包将匹配R2 （模式00*)，即规则R2依赖于R1，从R1到R2存在依赖性，具体的表现形式为：
如果R2 被 cache 在TCAM中，R1同样应该在TCAM中，来保护策略的语义

当一个规则cache在TCAM中时，与其存在依赖性的规则也应该放进TCAM中。但是，仅检查是否相交并不能准确发现所有具有依赖性的规则。
例如，规则R6仅取决于规则R5。但是，如果TCAM仅存储R5和R6，应该匹配R4的数据包将匹配到R5，从而被错误地处理。故依赖存在链的性质，虽然R6不直接依赖R4，但是R6依赖R5，R5依赖R4，所以需要正确处理复杂的依赖关系情况。

复杂的依赖关系会出现在哪里？

部分重叠

在传统的destination prefix转发中，不会出现复杂的依赖关系，因为前缀仅依赖于其自身严格的子集的前缀。然而，在规则具有优先级并且可以匹配多个头字段的OpenFlow规则表中，由于规则之间的部分重叠而发生了间接依赖关系例如R4和R6，它们具有间接依赖性。

策略组成

Frenetic, Pyretic, CoVisor和其他高级的SDN编程平台支持从一组简单组件中构建复杂的网络策略。尽管单独的组建可能显示很少依赖关系，但是当它们一起编译时，复合规则表可能会包含许多复杂的依赖关系。

例如图3（c）中展示了一个从CoVisor项目中提取的说明性规则表：

规则的相应依赖图展示在图3(d)：

在此，定义高级策略的两个单独的组件中未看到规则R3和R4之间的依赖关系，但在它们组合时确实会出现。

REANNZ策略的依赖关系

图3(a)中的依赖关系可以转化为依赖图，如下3(b)所示：

一个可能的优化方式是现在网络运营商可以手动重写策略以减少依赖项的数量，从而优化cache。
但是，这样做必然非常繁琐且极易出错。 此外，良好的分割可能取决于网络流量的动态属性。 我们认为这样的任务最好由算法来决定，例如我们在本文中提出的方法，这样也更加可靠。

构造依赖DAG

清楚表示规则表中所有依赖关系的一种方法是构造一个有向图，其中每个规则都是一个节点，并且每个边代表一对规则之间的直接依赖关系，如图2（b）所示。

在子规则$R_i$和父规则$R_j$直接的依赖关系是指：
如果将$R_i$从规则表中删除，则原本应该命中$R_i$的数据包将命中规则 R j R_j