一、写在前面
SDN的出现，使控制层与转发层相分离，方便了对网络的配置和管理。通过抽象的思想，在数据中心、校园网乃至城域网，我们将转发层设备（不管是你是什么设备，思科还是华为，是交换机还是路由器）都抽象成一个大的switch，并提供接口，隐藏其复杂性。这样，用户不需要关心低层的细节，只需要实现高层的策略。就像几千条的汇编语言只需一两条python语句就可以完成，大大简化了操作。
——>如何将你的策略（你对网络的管理思想）实现到这个大的switch？
应用层：策略（policy，高水平） —转化下发—> 转发层：规则（rule，转发层）
可以看出规则是其关键，可以把规则看成是管理员和网络之间的搬运工，而OpenFlow是实现其的桥梁（桥梁可以有许多种，这里我们研究的是基于openflow 的规则）。而如何构造搬运工（如何定义规则）？如何解决搬运工到网络设备中的工作（怎么放置规则）？是我们需要考虑的。要实现对网络管理的应用化就需要有规则放置的解决方案，规则放置问题的重要性自然不言而喻。
二、提出问题
规则放置面对以下的挑战需要解决：
1、资源限制，尤其是内存容量限制
- TCAM：规则匹配灵活、可以快速查找，但是成本高、功率消耗大导致容量有限
- software switch：容量大但是查找和转发能力有限
2、信道开销（Signaling Overhead，控制层和转发层的带宽开销）
- 规则的安装和更新需要信道开销
- 对网络的管理和预测也需要信道开销
3、规则依赖
三、放置问题模型
F是流的集合，R是规则的集合。 将网络抽象成一个有向图G = (V, E)。O是端点的集合（流能的终点，每个流不止一个终点），P是流的路径（以O为终点）。
输出：某个节点（switch）在某个T时刻 FT(v, t)产生的流表 FT(v, t) = [r1, r2,… ] ⊂ R。也就是规则集r1, r2,…
输入：
- 流（Traffic flows F）：这里流定义了粗细粒度。①是同类数据包的集合；②也是策略的执行者
- 策略（Policies）
- 端点策略（EP）：F → O。某个流F的方向，从哪个端口进，到哪个端口口O。其形式：(dst ip = 00∗, ingress = H1 : Permit, egress = H2)
- 路由策略（RP）：F → P 。流的转发路径，通常是最短路径
- 在相关论文中，策略EP和RP可以得到流空间D（规则空间R的子集）
- 规则空间（Rule space R）：所有可能的规则集，就是其表示整个矩形的大小
- 限制条件（Resource constraints）：比如内存、带宽、交换机或控制器的性能。。。
——>一句话：最优化模型，NP-hard问题。不同的研究针对不同的目标函数，比如最小化所有节点的规则数∑v∈V |FT(v, t)|，等。得到适合的流表FT，也就是可以安放的规则集。
——>两个网络规则的例子：
eg1：访问控制（Access Control）规则放置
如何将大量的访问控制规则放入容量有限的入口交换机？
- 一种是在入口端使用software switch。——>满足容量限制但是处理速度不够
- 另一种是将规则集放入整个网络中（入口端交换机集群）——>需要将规则分配但保持其语义不变
eg2：转发（ Traffic Engineering）规则放置
通常就是将转发规则放入最短路径中，以使数据包转发到相应的端点O。但是由于其容量的限制。需要找到其他合适的路径并选择规则集放入。
虽然两个例子的具体研究不同，但都有相似的问题：如何将无限的规则放到有限的交换机流表中
规则——>交换机
- 对规则：缩小规则，分割规则，部分放置。。。。
- 对交换机流表：扩大交换机容量、交换机集群。。。。
四、针对交换机容量管理的解决方案
- 回收（eviction）
- 压缩（compression）
- 分割与分配（split and distribution ）（组成相互关联的交换机集群）
（一）eviction
eviction mechanisms can be used to recover the memory occupied by inactive or less important rules to be able to insert new rules.
由于交换机容量限制，回收机制用于替换那些不活跃的规则。
——>如何替换呢？
替换方法：
1、常规替换算法（Replacement Algorithms）
- LRU、FIFO、RR等算法，可以依据规则活跃时间和重要性来替换
- ①通过交换机设置置换标志位来实现，但需要交换机的支持
- ②通过控制器删除控制消息来实现，OpenFlow1.4版的控制器可以提前知道交换机容量信息，避免交换机满。
缺陷：
- ①违反了应将决策权交给控制器的OpenFlow规范
- ②增加了控制信道的开销
- LRU虽然命中效果最好。但是实际网络中如在大量的老鼠流（ mice flow），造成重要的大象流（elephant flow）缺失
2、基于流状态的替换（ Flow State-Based Eviction）
实际网络中流的大小和持续时间是动态变化的。对流状态的监控可以提前预测流的变化，以便替换规则。
缺陷：其全局监测和预测需要大量的信道开销。
3、超时机制（Timeout Mechanisms）
OpenFlow交换机中两类超时时间参数：固定时间（hard_timeout）和空闲时间（idle_timeout）。主要基于空闲时间参数。
- 根据调查，使用已有的静态超时时间管理规则。
- 根据不同指标，动态设置超时时间规则规则。好处是交换机自主完成规则删除，充分利用内存。缺陷是监测个指标的开销大。
- 通过对空闲时间进行计数器累计设置，可以利用规则的时间局限性
（二）Compression
Compression (or aggregation) is a technique that reduces the number of required rules while preserving the original semantics, by using wildcard rules. As a result, an original list of rules might be replaced by a smaller one that fits the flow table.
利用通配符，将规则集进行压缩得到更小的规则集，并使规则的语义保持不变。
——>通配符是什么？怎么压缩规则？
Pass
——>压缩规则需要考虑的问题：
- 规则依赖性：当域不同时，压缩的规则们都有优先权需要解决依赖性，避免匹配冲突
- 压缩的部位多种，不一定局限在IP
- 保持适当的流量视图，并达到最佳的压缩比和计算时间之间的权衡。
——>分类：基于控制访问和转发规则的压缩：
1、控制访问规则压缩：
- 允许与拒绝字段互补，因此只需用拒绝字段的规则压缩
2、转发规则压缩：
- 转发规则通常比访问控制规则简单，但是①有更多的动作域；②对时间要求更严格
- 一些有效的方法：
- 在多重路由策略中（即到一个端口O可以有几条不同的路径，不一定选择最短路径，以适应负载均衡），选择路径重叠的交换机，可以压缩规则。因为多条路径都可以使用。
- 如果和默认规则具有相同的动作域，可以一起压缩。
- 对多维动作域进行压缩。
- 只压缩老鼠流，对大象流进行精确规则匹配。
- 在一条路径中，只需在第一个软件交换机备份精确规则，因为其有足够的容量。在其他交换机依旧压缩规则。
——>缺陷：
- 导致流不可见性，压缩后不能对具体流监控，如限速。
- 计算高压缩比，即选择合适的压缩需要时间。
- 更新规则后可能导致错误的转发。因此，大多数更新时规则是不会压缩的。在更新完成后再计算受影响的规则。
以上都是在规则上进行考虑，要么缩小规则集，要么在单交换机上对规则进行折腾。下面对交换机考虑，因为不能扩大单个交换机的容量，但是可以通过交换机集群的方式来扩大交换机容量
（三）Split and Distribution
——>交换机集群就是选择一条路径上的所有交换机，可以安装规则（通过上面的两个例子可以看出来）
要满足的必要条件：在合适的一条路径上所安装的规则应使每个流F都能顺利匹配（不管是执行相应策略还是转发到下一跳节点），保持规则的语义不变。可以说就是使流F能感到就像在一个交换机上。
——>如何将规则集放置到路径上呢？
一般是先分割，在分配的思想。不同的方案模型有具体的实现。后面会具体分析一部分规则分配模型。
- 注意：一般的规则都具有依赖关系，分割时需要注意
——>然后我们将该类分配问题分为两类：
- 一类是只基于TCAM的商业交换机的规则分配（Rules Distribution Among Commodity Switches）
- 一类是可以通过软件交换机或其它网络设备以减少开销的前提下，通过OpenFlow控制器提供管理的灵活性。（Rules Distribution Among Commodity Switches and Additional Resources）
1、Rules Distribution Among Commodity Switches
（1）以访问控制规则分配为例
当前的主要研究模型有： [19], [28], [45], [46], [57].（见引用的论文一）
——>需要具体实现先分割，在分配的思想。所以面对两种挑战怎么更好的分割规则？怎么更好的分配规则到各节点？
1）分割成小规则：
- 对DAG图进行分割
- 对多维空间矩形进行分割
- 其他一些的方法：如Palette模型的PBD算法
2）分配规则到各节点（交换机）
我们将该问题抽象成最优化的线性规划模型，以决定规则应该放到哪个节）。
约束条件：比如节点容量，规则依赖关系，策略限制等
目标函数：不同的模型有不同的针对，如最小化规则数、最小化消耗的能量、最大化网络交通满意度等
**例1：**Palette模型的规则分配方案
- 在每次迭代中，我们总选择那些①占有最多路径的（理解为最重要的交汇点，贪心思想）②所在路径还有未被颜色c染色的节点v（switch），用颜色c进行染色（即将子表放入switch中），直到每条路径都染上了颜色c，然后进行下一次迭代。若发现某条路径上节点都已被染色完，即颜色c染不上了，则终止迭代，方案失败。
**例2：**OneBigSwitch模型的规则分配方案
- 详见http://blog.csdn.net/u013480581/article/details/58346883
- 该模型对Palette模型的规则分配提出了两点缺陷：①端点策略O到达的所有路径都要染色②由于近似均匀分割规则，路径中节点的利用率不足
- 于是将规则分割与分配的步骤同时进行。首先估计流表Di中的规则数，匹配满足的路径（LP问题）。然后再对路径染色。具体如下：
（2）以转发规则分配为例
当前的主要研究模型有：[20]–[23], [33], [34],[56]（见引用的论文一）
——>面对的挑战：是如何选择路径来安装转发规则，满足政策和网络约束？
- 通常考虑规则数最少，则选择最短路径
- 通过路由策略P来染色可以得到一些好的性能。但是可能会遇到路径容量不够的情况，所以，有时路径不是预先的策略。需要路径算法来产出，这就需要对网络的监控。
2、Rules Distribution Among Commodity Switches and Additional Resources
实际中流对时间、性能的敏感度都不相同。作为一个结果，可以允许一些流量进行低性能处理，并允许在高性能路径的处理关键流量。
这样，可以使用将TCAM和software switch相结合的模型。——>规则缓存的思想（以前的笔记介绍过）
——>如何选择放入TCAM的规则，使性能（就是规则的优先级）和成本（就是规则的依赖程度）达到最佳的平衡？
Pass
3、规则分割与分配模型的缺陷：
- 重定向规则的开销
- 计算最优的开销
- 由于规则依赖，分割规则需要对规则复制
- 主动模式下发规则，需要对网络监控和预测的开销
五、针对交降低信道开销的解决方案
1、被动规则放置与主动规则放置
前面介绍的规则放置模型都是基于主动放置的，需要放置的规则集预先给定，所以只适用于可以精确预测的流。主要应用于访问控制，因为访问控制规则可以通过运营商预先给定。其他情况需要对网络监测来预测规则，也会增加信道开销
而被动规则放置是一种特例。通过流响应事件来动态的填充交换机中的规则。这种情况无疑带来了巨大的信道开销。n个节点就需要2n流响应消息。当然一旦这些相对应的规则被安置就不需要响应事件的开销了。
2、通过扩展交换机功能来减少信道开销
- 保留交换机的基本功能可以减少信道的开销，也可以保障当控制器故障后网络的正常运行。
- 允许交换机规则克隆
- 允许交换机改变动作域
- 授权交换机的DEFINE模型
- 交换机自主删除规则来降低信道开销
- 优化预测及计数器的情况来降低信道开销
以上会带来交换机的复杂性、异构性的问题，不利于OpenFlow的发展。
六、未来研究方向
- 混合模式的规则放置：将主动和被动模式相结合
- 规则更新问题的研究，提高规则放置的稳定性和容错率
- 对其他设备的规则放置研究，如控制器，软件交换机
- 多级流表的放置研究
- 在NFV上研究规则放置问题
七、引用：
- Nguyen, Xuan Nam, et al. “Rules Placement Problem in OpenFlow Networks: A Survey.” IEEE Communications Surveys & Tutorials 18.2(2016):1273-1286.
- Kreutz, D, et al. “Software-Defined Networking: A Comprehensive Survey.” Proceedings of the IEEE 103.1(2014):10-13.
- Kanizo, Yossi, D. Hay, and I. Keslassy. “Palette: Distributing tables in software-defined networks.” INFOCOM, 2013 Proceedings IEEE IEEE, 2013:545-549.
- Kang, Nanxi, et al. “Optimizing the “one big switch” abstraction in software-defined networks.” ACM Conference on Emerging NETWORKING Experiments and Technologies ACM, 2013:13-24.