TS检查器：SDN中的两步冲突检测整合机制

王 晗 叶家炜 严 明(复旦大学计算机科学技术学院 上海 200433)

0 引 言

软件定义网络(SDN)与OpenFlow[1]的出现和兴起为网络管理提供了便捷支持。在SDN架构中，数据平面和控制平面的解耦可以让网络开发者通过在Docker[2]容器或虚拟机中开发北向应用程序和调用SDN控制器提供的北向接口来操纵网络设备[3]。然而，这种高度可编程的架构也面临着一些问题，这些北向应用程序因为在开发中相互独立，故可能因为发出匹配域中有重叠的请求而动作域不一致从而造成网络状态的不一致，我们称这些匹配域中有重叠的请求为带有重叠域的请求。根据OpenFlow规范，当数据包到达某个交换机时，会在其流表中查找第一条匹配的流表项，所以如果这些带重叠域的请求直接发给SDN控制器时，会通过SDN控制器在交换机中生成相应流表项，当一个匹配重叠域的数据包到达交换机时它只会匹配到其中一条流表项并执行其动作指令，其他流表项的动作永远不会被执行[4]。

因此，北向应用程序发出的请求在被发送到SDN控制器之前需要经过检查和处理，以消除冲突并保证动作域的一致性。目前针对这种冲突检测的方案有基于资源粒度和基于流表项粒度两种方式。考虑到基于资源粒度的检测方法无法满足细粒度的需求，在本文中，我们提出了基于流表项粒度的TS(Two-Stage)检查器。TS检查器是位于应用层和控制层之间的检查层，负责过滤、处理北向应用程序发往控制器的所有请求。对于北向应用程序发出的请求，要经过TS检查器的两次检查，其中包括四个模块，经过这些模块处理，带有重叠域且动作行为冲突的请求会被检测并截断，动作行为一致的请求会被整合，之后发给SDN控制器。

本文提出的TS检查器支持基于最近最多匹配的部分检查算法完成冲突检测，使用基于RingBuffer实现的线程安全的请求队列来缓冲存储北向请求，在检查、合并带重叠域的请求时，使用字典树数据结构从而保证处理的高效性。我们在Mininet[5]环境下验证了TS检查器的部分检查算法的正确性和检查器各模块的性能。

1 相关研究

关于检测SDN环境下流冲突的方案大体可以分为基于资源粒度和基于流表项粒度两种。基于资源粒度的方案通过把来自北向应用程序的请求抽象成策略或意图从而在资源层次进行意图间的冲突检测，而基于流表项粒度的方案的思想则是检测每条流表项，通过和交换机中现有流表项逐一进行对比。

在基于资源粒度的方案中，AuYoung等[8-9]提出的Corybantic及其后续Athens，将Athens作为北向模块和控制器之间的拦截者和代理者，接收并处理应用程序模块发来的操作网络资源的抽象意图，例如虚拟机的放置等。这需要在对应用意图进行抽象且在Athens和应用之间建立新的通信接口，而且不能解决细粒度的资源分配问题。PGA团队[14]针对网络提出了新的抽象模型——图，但是这种抽象模型不支持set动作。Pyretic[7]在SDN环境下提出的新的开发语言和网络架构，通过引入顺序操作符和并行操作符解决冲突问题。但是Pyretic对网络开发人员带来的新技术的挑战，并且这种新型架构对于现存的网络应用而言难以迁移和扩展。

在基于流表项粒度的方案中，FortNOX[11]是针对NOX控制器的扩展，它通过基于角色的源认证和别名设置规则减少来实时检测流表项之间的冲突。VeriFlow[12]是位于SDN控制器和网络设备之间的一层，通过生成等价集和转发图来检测变量之间的冲突。FlowChecker[10]把流表编码成二分决策图并且使用模型检查器来检测单个交换机内的错误配置，但它也不支持set动作。Flover[13]使用Yices SMT解决器检查策略间的不一致，但仅限于网络安全，对功能一致性没有提及。

综上，相比于基于资源粒度的解决方案，基于流表项粒度的解决方案对北向应用的一致性可以进行更细粒度的控制和检测，而当前基于流表项粒度的解决方案中，尽管用到多种数学方法，但对于带有重叠域的请求大多按照先到先处理的方式，并且对动作域不同的请求进行丢弃。然而动作域不同不代表动作域的冲突，对某些带有重叠域的请求而言，其动作行为是可以无冲突共存的。上述基于流表项粒度的文章中没有明确给出对重叠域请求进行整合的方案，因此我们提出了TS检查器解决方案，对来自北向应用的请求进行冲突检测和整合。

2 问题描述

考虑如下场景，应用层的路由应用程序负责计算生成转发路径，监控应用程序负责统计数据包流通情况。它们在相同时刻都发起了向同一交换机S中插入流表项的请求。请求A和C由路由应用程序发出，请求B由监控应用程序发出，为了简化说明，我们把请求A、B、C抽象成表1所示的流表项，实际上应用请求一般是带有JSON或XML格式数据的POST请求，需要经过简单的解析处理才能转化成一条或多条对应的流表项。

表1 来自两个应用的三条请求

根据OpenFlow规范，每条流表项都隐式地包含一个计数器[4]，在本文中为了便于阐述问题，我们将计数器行为视为一个显式的count动作，实际上当动作域没有任何设定时就会执行count动作。

如果此时，交换机S中存在如表2所示的一条流表项。

表2 交换机S中的一条流表项

在这个场景下，如果对应用程序请求不作检测处理而直接交给控制器，那么会有两个问题：1)请求C和id=5的流表项存在冲突，对满足src_ip=192.0.0.1/32条件的数据流其动作行为不一致，现存流表项的动作是丢弃，而请求C的动作是转发到3号端口；2)请求A和请求B存在重叠域，即src_ip=20.0.0.1/32且dst_ip=20.0.0.2/32，对于满足重叠域条件的数据包，只能执行转发或计数其中一个动作，并且执行的具体动作也因请求A、B到达的先后顺序而未知，而实际上转发和计数分别是由路由应用和监控应用负责的，并且是两个互不冲突的动作，所以可以被整合，请求B和C同理。

因此，在上述场景下，对于这些带有重叠域并可能和现存流表项冲突的请求，我们可以归纳出在原有架构中存在如下所述的三个问题。

2.1 冲突问题

如果一个来自北向应用的请求交换机中某条现有流表项存在匹配域的交集并且因动作域不一致而产生冲突，我们称之为冲突问题。在上述场景中，请求C与id=5的流表项间存在冲突问题。冲突问题在文献[10-12]中得到了足够的重视。它们使用了不同的数学公式或方法以消除和当前网络状态有冲突的请求从而保证网络安全。在本文中，我们受到启发并提出更高效地解决冲突问题的方案。

2.2 不公平竞争

在请求A和B是几乎同时发出的前提下，受实际网络因素控制，最终到达控制器的顺序总有先后之分，按照先到先处理的原则，对于满足其重叠匹配域的数据包X而言，其最终动作取决于优先到达控制器并生成的相应流表项的请求。在这种情况下，对于后到达控制器的请求是不公平的，并且请求到达的先后顺序是受实际网络情况影响而不可预测的。我们称这种几乎同时发出却因到达时间的微小差别造成的现象为不公平竞争。在本文中，我们使用请求队列来存储短时间内到达的多个请求，通过批处理来解决部分不公平竞争的问题。

2.3 重叠问题

对于请求A和B而言，如果不进行处理而直接发往控制器，那么无论其到达顺序如何，对于数据包X而言，其最终只能执行一条流表项的动作。如果请求A优先到达，那么计数动作会被忽略；如果请求B优先到达，那么转发动作会被忽略。由此可见，数据包X的行为不能同时满足路由应用和监控应用的意图，并且可以看到只要请求中包含重叠域，则最终行为必不能满足原始意图。我们称这个由重叠域带来的问题为重叠问题，这也是被大多数基于流表项粒度的冲突解决方案所忽略的问题。

为了解决上述三个问题，我们提出了TS检查器。

3 架构设计

在本节中，我们将详细介绍TS检查器。SDN架构把网络抽象成三层，从北到南依次为：应用层、控制层、基础设备层。和位于控制层与基础设备层之间进行拦截的VeriFlow不同[12]，我们把TS检查器定位于应用层与控制层之间。如图1所示，在应用层有多个部署于Docker的独立应用向控制器发出请求，这些应用包括负载均衡应用、监控应用、路由应用等。在这些请求发往控制器之前，需要经过包括四个模块的检查层的处理，在检查层处理时，会根据策略判断当前请求被接受或被拒绝。被接受的请求将进一步发往控制器进行后续操作，而对于被拒绝的请求，会发送反馈给相应的应用。

图1 总体架构

与Athens和Pyretic方案不同，我们的检查层方案仅需对现有应用进行微小改动——添加反馈处理模块，而这可以通过补丁或扩展的方式实现。

整个检查层包括四个模块，其中进行了两次检查，由冲突检查模块和重叠检查模块分别负责不同的检查任务。为了便于阐述，我们把北向应用发起的请求抽象成带有负载的POST请求，并用如下所示的JSON对象进行描述。

“requests”: [{

“id”: “00070”,

“idle_time”: “3600”,

“hard_time”: “3600”,

“priority”: “20”,

“match”: {

“src_ip”: “192.168.1.1/32”

“eth_type”: “0x800”

},

“actions”: “drop”

},]

下面将分别描述四个模块的主要功能。

3.1 冲突检查模块

这是第一个检查步骤，负责检查到来的请求是否与交换机中现有流表项(表示了当前网络状态)之间是否存在冲突。和当前网络状态一致的请求将被转发到下一步骤(请求队列)进行后续处理，而与当前网络状态冲突的请求则会被丢弃并发送相应反馈。

3.2 请求队列

请求队列是一个基于环形队列实现的先进先出的队列，用于存放被冲突检查模块过滤后的请求。

3.3 重叠检查模块

在此模块中执行第二次检查，负责检查队列中的请求之间是否存在重叠域，若有重叠域存在，则请求被发往下一个模块，否则会被标志为有效请求并跳过整合模块被直接发往SDN控制器。上述三个模块共同构成了消费者- 生产者模式，冲突检查模块负责向请求队列中输入数据，而重叠检查模块负责批量消费请求队列中的数据。

3.4 整合模块

尝试整合带有重叠域的请求。如果这些带重叠域请求的动作域指令是相互冲突的，则被丢弃并发送相应反馈，否则就通过策略去整合请求，将整合之后的请求发给SDN控制器。

四个步骤的处理流程可以用图2概括。

图2 TS检查器处理流程

4 系统实现

4.1 冲突检测算法

在检查层对请求进行的第一步处理是进行冲突检测。冲突检测用于检测一个新到来的请求是否与交换机中现有流表项规则有冲突。因为交换机中现有流表项规则表示了当前网络状态，这个步骤对于消除与网络状态冲突的请求从而维护网络状态一致性必不可少。

文献[10-13]各自使用了不同的方法去完成冲突检测的任务，它们全部基于检查新插入请求或流表项与交换机中所有流表项之间的冲突。这些方法很完善但在某些场景下并非必要且是低效的。根据网络局部性理论[15]可知，近期内被命中的流表项短时间内很可能被再次命中。所以对于某些对时延性要求较高而对网络状态一致性并不具有严格要求的场景而言，我们提出了用户可配置的基于最近最多匹配的部分检查这一折衷算法，使用者可以根据场景需求选择部分检查的覆盖率，当覆盖率为100%时退化为全部检查。

部分检查算法基于网络局部性，如果交换机中的某条流表项被一个数据包命中过，那么短期内它有很大的概率会被再次匹配。基于此，我们在冲突检查器中设计了最近最多匹配的缓存数据结构(LRM)，它用于保存每个交换机最近最频繁被匹配到的流表项。为找到最近最多匹配的流表项，可使用流表项中的idle字段。根据OpenFlow规范，idle字段表示距离上一次被匹配的时间间隔，这反映了此条流表项的活跃度。

在冲突检测算法中，我们使用Trie字典树数据结构存储匹配域中的IP地址，以保证在O(n)时间内完成检测。具体的冲突检测算法如算法1所示。冲突检测器的输出结果为接受或拒绝某个请求，对于被接受的请求将会发往请求队列模块。

算法1 冲突检测算法input：acomingrequest，flowentries’idstoredinLRMforfidinLRM： flow=get＿flow(fid) trie=build＿trie(flow->match)ifrequest．matchisintrie： request＿queue．push(request)else： reject(request)

4.2 使用请求队列解决不公平竞争问题

经过冲突检测器过滤的请求被发往请求队列。请求队列在检查层的作用是存储请求便于后续的重叠检查器进行处理。请求队列的上游是冲突检测器，下游是重叠检测器，上游的处理时间是O(n)，并且在实际实现中可以将冲突检测器实现为多线程并行处理，而下游处理时间是O(n2)。一方面请求队列可以作为缓冲队列去缓解消费速度落后于生产速度的情况，另一方面，正如在第3节中提到的，请求队列可以通过缓存极短时间内到达的多个请求，在满足实时性要求的同时便于下游进行批处理从而消除部分不公平竞争的问题。即对于被处理的同一批请求，在其优先级相同的情况下，不会因为其到达时间先后的微小差距而被区别对待。当请求队列中有数据时，便会通过信号量方式通知下游重叠检查器，重叠检查器会取出当前请求队列中所有请求，进行后续处理。

Corybantic和Athens解决方案对于何时进行一次策略整合没有给出明确的说明[8-9]，它们的重点在于整合的决策算法。而请求队列可以解决这个问题。

为实现请求队列，我们底层使用了RingBuffer环形队列结构，配合锁和信号量以保证线程安全和对下游线程的唤醒。

4.3 重叠检测算法

在冲突检查步骤中，仅仅筛选出了与当前网络状态不冲突的应用请求，而面对在短时间内收到的一批应用请求时，其匹配域中很可能存在重叠从而导致需要进行进一步整合。重叠检测器就是为了解决这个问题。

在实现算法上，重叠检测算法与冲突检测算法相似，不同的是，冲突检测算法是比较单个输入请求与交换机流表项，而重叠检测算法的输入是一批请求，重叠检测器需要从这些请求中过滤掉其动作指令相互矛盾的请求，将可整合的请求发往之后的整合步骤进行进一步处理。

因为大多数重叠域是由于IP地址的交集造成的，我们这里以源IP地址为例进行说明。IPv4地址为32位，而在OpenFlow协议中可以使用通配符匹配，故在字典树中我们使用高度最多为32位的字典树即可存储IP地址。

起初，字典树数据结构为空，当收到请求队列的唤醒信号时，它去获取请求队列中的全部请求，假设此时共有k个请求，重叠检查器会去遍历这k个请求，尝试向字典树中插入每个请求的源IP地址，并用tag位记录其优先级。在插入前，检查器会检测当前字典树中是否有其前缀IP地址。若没有，则直接插入；若已有前缀IP地址发现，当前请求则会被记录到由其前缀IP地址的请求构成的集合中。即当k个请求遍历结束之后，会有多个集合生成，每个集合中至少有一条或多条应用请求，同一集合中的应用请求之间具有重叠域关系，称之为重叠集。若重叠集中只有一条请求，说明不存在与之重叠的请求。

经过重叠检测器之后，内部数量大于1的重叠集会被送到整合器进行整合，内部数量等于1的重叠集即只有一条请求的集合将被直接发到SDN控制器，提前结束了整个检查流程。重叠检测算法见算法2。

算法2 重叠检测算法input：queuedrequestsfromRequestQueuetrie=Noneoverlap＿sets=Noneforrequestinqueued＿requests： node=in＿trie(trie，request) ifnode： overlap＿sets．set＿of＿(node)．append(request) else： overlap＿sets．add({request}) trie=insert＿trie(trie，request)forr＿setinoverlap＿sets： iflen(r＿set)is1： transfer＿to＿controller(r＿set) else： transfer＿to＿next＿stage(r＿set)

4.4 整合算法

重叠检查器挑选出了需要被整合的重叠集，其中的应用请求需要接受整合器的进一步处理。整合器会尝试去整合每个重叠集中的应用请求，它与重叠检查器一起可以解决第2节提到的重叠问题。

在整合含有重叠域的请求时，需要分析每个请求的action字段以判断请求之间是否存在相互矛盾的动作。根据OpenFlow规范，有drop、forward、set等显式的动作，如表3所示[4]。如果我们把count动作也视为显式动作，那么这四种动作之间的动作域关系表可以用表4展示。

表3 OpenFlow协议动作域

续表3

表4 动作域关系表

正如表4所示，对任意两个请求的动作关系存在三种可能情况。No表示不存在矛盾，所以请求可以被整合。Yes表示存在矛盾，所以相关请求要么被丢弃要么按照预先约定的策略进行处理。Maybe表示需要根据具体的动作目标来进一步判断是否存在矛盾冲突。例如forward动作，它可能有多个目标端口，当其目标端口不同时，则相互冲突，否则就视为一致。

实际环境中在一个重叠集中可能会存在超过两条的应用请求，但在本文中，我们的目标是先解决两个含重叠域的请求的整合，后续的工作将会将重点放在对三条及以上的请求的整合处理。因此在整合器这一步中我们暂时只处理包含两条请求的重叠集。

假设重叠集中含有A、B两个请求，直接将A和B请求发往SDN控制器会引起问题，正如第2节所描述的。整合器会按照策略生成一条新的请求C，请求C通过计算A和B的匹配域交集作为C的匹配域，A和B的动作域并集作为C的动作域，A和B中较高的优先级作为C的优先级。然后将请求三元组发给SDN控制器。至此，TS检查器结束。

为了更清楚地解释整合算法，我们以表5中的请求A和B为例，首先forward动作和set动作可以共存，所以两个请求可以被整合。根据整合算法，请求A和请求B的匹配域交集为{src_ip=192.0.0.1/32, dst_ip=192.0.0.0/16}，其动作域的并集为{set_field:401->vlan_id, forward:1}。于是新生成的请求C和原请求A和B如表6所示。整合算法见算法3。

表5 原始请求

表6 整合后的请求

算法3 整合算法input：overlappingsetswhichhavetworequestsaccepted＿requests={}forrequestsinoverlappingsets： a，b=request ifcontradict(a．actions，b．actions)： reject(a，b) sendfeedbacktoapplicationsofa，b else： c=newrequest common＿match=intersection(a．match，b．match) c．match=common＿match c．actions=Union(a．actions，b．actions) c．priority=max(a．priority，b．priority) accepted＿requests．append([c，a，b])transfer＿to＿controller(accepted＿requests)

到目前为止，TS检查器结束所有检查步骤。新到来的请求必须经过冲突检查器以保证其行为和当前流表项一致，然后经过重叠检查器进行请求间的重叠检测。经过这两个步骤的检查，被接受的请求会被发往SDN控制器，而带有重叠域的请求被送往整合器，其会选择具有可合并动作域的请求进行整合，随即将整合结果发往SDN控制器，对于不可进行整合的请求将会被拒绝并且发送反馈给相应应用。

5 实验验证

在本节中，我们使用Ryu控制器[3]和Mininet评估TS检查器的性能。Ryu控制器是提供RESTFul接口的轻量级控制器。Mininet提供了生成OpenFlow虚拟交换机、虚拟主机和网络拓扑的环境。在实验环境中，为了模拟北向应用发出的请求，我们构建了软件请求生成器去模拟应用发出的POST请求，这些请求先经过解析器解析后可以映射成多条即将插入到交换机中的流表项，之后经过TS检查器层过滤，将过滤结果发给SDN控制器。在实验环境中，我们使用的服务器为Dell R730，搭配了2个主频为2.4 GHz的Intel Xeon CPU，并划分成24个逻辑CPU。

5.1 正确性验证

在正确性验证中，我们主要验证了基于最近最多匹配的部分检查算法。因为对匹配百分比的设定取决于实际场景，在实验中，用图3所示的拓扑环境，分别模拟了以下场景。

图3 拓扑结构

场景1：数据包流量平均分布于6台主机之间。

场景2：50%的流量集中于主机A与主机D之间，50%的数据包流量平均分布于其他主机通信。

场景3：90%的流量集中于主机A与D之间，10%的流量平均分布于其他主机间。

在三种场景中，我们先后设置冲突检测器的匹配百分比为60%和100%，并对比了三种场景下冲突检测器的过滤结果，如图4所示，纵坐标为检测出有冲突的请求数。

图4 过滤结果对比

可以看出，在场景3中60%和100%的匹配百分比过滤结果相差无几，而在场景1和场景2中，却存在明显差距。由此可以看到基于最近最多匹配的部分检查算法适用于流量集中于部分链路的情况。

5.2 性能验证

在性能验证中，我们对TS检查器层的冲突检测器和重叠检测器及整合器分别进行了不同流表项和请求数量时的测试。我们构建了一个SDN控制器、三个ovs交换机，每个交换机分别连接2个主机的拓扑环境。

首先，我们评估了冲突检测器的计算时间。因为冲突检测器中使用了基于最近最多匹配的部分检查算法，所以其处理时间取决于不同场景下指定的匹配百分比。我们分别测试了100%匹配、66%匹配、33%匹配和20%匹配。从图5可以看出，随着流表项数量的增加，所耗费的检查时间呈线性增长。并且随着匹配百分比的升高，耗费的检查时间也逐渐增长。

图5 流表项数量与冲突检测时间的关系

之后我们验证了重叠检测器和整合器这两个步骤共同耗费的处理时间。如图6所示，随着重叠集数量的增加，处理时间线性增加。这其中大部分时间用于构建和更新字典树，也就是在重叠检测器这一步骤中，而整合器步骤耗时很短。

图6 请求数量和重叠检测与整合时间的关系

最后我们测试了一个完整的处理流程，使用三个请求生成器分别模拟三个应用先后生成了1 000个请求，三个交换机中的流表项数量分别为6 000，并且设置冲突检测器的匹配百分比为30%。如表7所示，在此环境中，对于每个请求而言冲突检测器处理耗时小于1 ms，重叠检测器和整合器耗时略多，但仍然小于1 ms。

表7 检查步骤与耗费时间

6 结 语

我们设计、实现并评估了TS检查器——一个用于在SDN架构中检测冲突并进行整合以保证网络状态一致性的机制。TS检查器作为检查层位于应用层与控制层之间，为高效完成冲突检测，使用字典树数据结构和基于最近最多匹配的部分检查算法来减少某些场景下的平均检查时间。设计了请求队列以辅助下游实现请求间的重叠检查和整合。在整合阶段，我们提出了整合两个含重叠域请求的方法。最后使用Mininet验证了设计，并进行了性能评估。

下一步我们计划探索用于三条及以上请求之间的整合机制，并且将TS检查器扩展到多控制器环境中。

[1] OpenFlow: a southbound protocol[OL]. https://www.opennetworking.org/sdn-resources/openflow.

[2] Docker: an app engine[OL]. https://www.docker.com/.

[3] Ryu controller: an open source SDN controller[OL]. https://osrg.github.io/ryu/.

[4] OpenFlow switch specification[OL]. https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-spec-v1.4.0.pdf.

[5] Mininet[OL]. http://mininet.org/.

[6] Anderson C J, Foster N, Guha A, et al. NetKAT: semantic foundations for networks[C]// ACM Sigplan-Sigact Symposium on Principles of Programming Languages. ACM, 2014:113- 126.

[7] Monsanto C, Reich J, Foster N, et al. Composing software-defined networks[C]// Usenix Conference on Networked Systems Design and Implementation. USENIX Association, 2013:1- 14.

[8] Mogul J C, AuYoung A, Banerjee S, et al. Corybantic: towards the modular composition of SDN control programs[C]//Proceedings of the Twelfth ACM Workshop on Hot Topics in Networks. ACM, 2013: 1- 7.

[9] AuYoung A, Ma Y, Banerjee S, et al. Democratic resolution of resource conflicts between sdn control programs[C]//Proceedings of the 10th ACM International on Conference on emerging Networking Experiments and Technologies. ACM, 2014: 391- 402.

[10] Al-Shaer E, Al-Haj S. FlowChecker: Configuration analysis and verification of federated OpenFlow infrastructures[C]//Proceedings of the 3rd ACM workshop on Assurable and usable security configuration. ACM, 2010: 37- 44.

[11] Porras P, Shin S, Yegneswaran V, et al. A security enforcement kernel for OpenFlow networks[C]//Proceedings of the first workshop on Hot topics in software defined networks. ACM, 2012: 121- 126.

[12] Khurshid A, Zhou W, Caesar M, et al. Veriflow: Verifying network-wide invariants in real time[J]. ACM SIGCOMM Computer Communication Review, 2012, 42(4): 467- 472.

[13] Son S, Shin S, Yegneswaran V, et al. Model checking invariant security properties in OpenFlow[C]//Communications (ICC), 2013 IEEE International Conference on. IEEE, 2013: 1974- 1979.

[14] Prakash C, Lee J, Turner Y, et al. Pga: Using graphs to express and automatically reconcile network policies[J]. ACM SIGCOMM Computer Communication Review, 2015, 45(4): 29- 42.

[15] Jain R. Characteristics of destination address locality in computer networks: a comparison of caching schemes[J]. Computer networks and ISDN systems, 1990, 18(4): 243- 254.