肖军弼　隋萌萌　陈　松　任密林　万　里

1(中国石油大学(华东)计算机与通信工程学院　山东 青岛 266580) 2(下一代互联网重大应用技术(北京)工程研究中心有限公司　北京 100084)

0　引　言

校园专网是校园网络体系中的重要组成部分，其服务范围涵盖财务、安防、能源监管等校园生活的方方面面。在传统网络中，开通校园专网通常需要管理员进行大量的接口和ACL规则配置，过程十分繁琐。且专网一旦开通，一般不会发生大规模变化,若要开通新的专网业务，则需要执行大量配置变更以实现数据精准转发和流量安全隔离。受种种因素所限，传统网络体系结构下的校园专网存在安全性、灵活性、稳定性和可扩展性等方面的缺陷。软件定义网络SDN依靠其数控分离、集中管理的强大优势，通过控制器下发专网管理策略，从全局视角实现对专网的管控，能够实现新增设备的即插即用和配置策略的自动复制下发，简化管理运维负担，提高变更管理效率[1]。

然而，随着专网承载业务的日益增加，网络拥塞问题日趋严重。专网承载的大多是重要业务，或者在某时段内需要保障高优先级服务的业务(如视频会议等)。如何在一张有限的物理网络上承载更多的新业务并保障重要业务的服务质量不受干扰成为未来专网面临的新课题。当前，SDN中Floodlight控制器在路径选择和流量调度方面默认采用最短路径算法。这种单一的解决方式并未考虑到网络的当前带宽使用状态，也没有预防未来其他突发流量可能带来的冲击，更没有为各种业务不同的带宽需求提供有效的保障措施。为提高业务带宽需求的保障效果，增强网络的稳定性和健壮性，本文在OPPBG算法的基础之上，通过计算链路剩余带宽差值的方差改进路径选择算法，并融合端口队列设置方式，提出一种改进的路径选择与带宽保障策略。

1　设置端口队列与OPPBG算法

1.1　使用OpenFlow设置端口队列

OpenFlow是当前在控制平面和数据平面之间最具影响力的南向接口协议[2]。OpenFlow交换机通过简单的队列机制提供有限的QoS支持。交换机的一个端口上可添加一个或多个队列，这些队列用于映射流条目。映射到指定队列的流条目将依据队列配置(如最小速率、最大速率等)进行处理。根据端口队列这一特性，处理动作为Set Queue的流表将被推送至相关交换机中，从而将不同的业务流调度至不同队列中[3]以便进行下一步处理。

在设置队列和调度流量之前，文献[4]首先使用Dijkstra算法选择从源端到目的端的最短路径。然后沿此路径在一段适当的链路上，多个具有不同最大速率和最小速率配置的队列将设置在端口上用于限制最大传输速率并保障最小带宽需求。通过OpenFlow的流表下发策略，不同带宽需求的业务将被放入适当的队列中。流表的匹配字段表示需要保障带宽的业务，动作字段设置为Set Queue。

使用OpenFlow设置端口队列能够通过不同速率限制的队列有效区分不同带宽需求的业务，从而为重要业务提供有效的带宽保障，而且能够排除普通业务的干扰，对重要业务流具有较强的控制力。但是设置端口队列前的路径选择采用简单的最短路径方法，没有考虑当前链路状态和已存在于路径中的流量。当多条业务流的总带宽需求超过链路容量时，极易发生拥塞，导致重要业务的服务质量大大降低。

1.2　OPPBG算法

为了满足服务在不同时间尺度的不同带宽需求，文献[5]提出了OPPBG算法。在该算法中，基于北向接口[6]的SDN管理平台使用REST API收集全网信息，RBG(Routing with Bandwidth Guarantee)算法根据收集到的网络信息执行路由算法得到调度路径，最后根据计算结果生成或更新流表条目并将流表下发至相应的交换机中。

RBG算法将路径中当前存在的流量和链路容量纳入考虑范围。三元组fw(src,dst,ban)用于描述从源节点src发往目的节点dst、带宽需求为ban的业务流fw。该算法首先创建当前网络拓扑的副本，并删除剩余带宽不满足fw需求的链路。随后，在拓扑副本中，使用Dijkstra算法计算从源节点src到目的节点dst的最短路径(此最短路径的链路剩余带宽必定满足fw的带宽需求)，由此得出调度流量的最佳路径。

这种方法确保所选路径能够满足业务流的带宽需求，充足的链路资源可以防止网络中已有流量与新到流量的相互干扰。然而，如果采用最短路径算法后得出多条可用路径，如何在多条路径情况下进行调度操作或从中择优选用并没有进一步讨论。另一方面，当多个不同带宽需求的业务沿同一路径传输时，如果不采取有效的带宽保障措施，多个业务流将平分剩余可用带宽。在这种情况下，具有较大带宽需求的业务可能无法获得足够的带宽，造成高丢包率而使服务质量降低。因此，在选择流量调度路径时，我们必须综合考虑当前链路状态以及未来的潜在影响因素，尽可能降低对重要业务种种可能的干扰。

2　基于SDN的路径选择与带宽保障策略设计

2.1　路径选择算法描述

假定从源到目的地的路径p包含多段链路li，每段链路的容量为ci，已使用的带宽为bi，如式(1)和式(2)所示：

C=[c1,c2,…,ci,…,cn]

(1)

B=[b1,b2,…,bi,…,bn]

(2)

使用三元组f(src,dst,band)表示一条需要进行调度的新到业务，其源端为src，目的端为dst，带宽需求为band。为确保业务流能够从源端到达目的端，全路径算法首先将通过深度优先遍历获取从src到dst的所有可达路径。随后，使用式(3)计算所有路径中每段链路的剩余可用带宽ri，并将剩余可用带宽不满足业务流f需求的链路删除(该段链路所在的可达路径也随之删除)。

R=[r1,r2,…,ri,…,rn]=C-B

(3)

现在，所有可到达目的地且满足带宽需求的路径已被选出。接下来采用Dijkstra算法从中选择最短路径。如果仅存在一条最短路径，则选用该路径作为调度流量的最佳路径。

若存在多条最短路径，下一步计算得出每条路径包含的所有链路中剩余带宽的最小值，并将各条路径的链路最小剩余带宽进行比较，从中选取最小剩余带宽中的最大值。该最大值所在的路径具有更强的容纳能力，能够承载更多后续进入的流量，因而当前业务不易受到后续业务的干扰，路径更加稳定。

显然，在选出最大的链路最小剩余带宽之后，仍有可能存在多条路径，即可能会得到多条具有相同的链路最小剩余带宽的路径。为进一步确保系统的健壮性和业务的服务质量，算法对各条路径进行更深入的评估和比较，具体步骤如下：

第1步我们已经得到每条路径上每段链路的剩余带宽以及该路径上的链路最小剩余带宽。对于每条路径，将每段链路的剩余带宽与链路最小剩余带宽相减，得到一组差值。对于路径p上的链路li，该差值可依照式(4)表示为di。

di=ri-min(ri)

(4)

第2步对于路径p，所有差值di将被归为一个数据组，并使用式(5)计算该组数据的方差，从而评估这些差值的离散程度。

(5)

第3步计算出各组数据的方差后，方差值最小的一组数据所在的路径将选定为最终的最佳路径用于调度流量。方差最小意味着该条路径不会因某一段或某几段链路的突然拥塞而轻易受到干扰。对于重要业务而言，这样的路径能够提供更加稳定高质量的服务。

为直观描述整个算法流程，图1通过一个简单的示例对上述过程加以解释。在该示例中，从源节点S1到目的节点S8的业务流f的带宽需求为12 Mbit/s。在图1所示的拓扑中，每段链路上的数字表示该段链路的剩余可用带宽(假定所有链路长度相同)。图1(a)中，链路剩余带宽不满足f的带宽需求的链路(S2，S7)被删除，提取出的新拓扑中所有链路均能够满足f的带宽需求。图1(b)中，使用Dijkstra算法计算最短路径，较长的路径(S2，S5，S6，S7)被排除。此时得到两条最短路径，并且它们的链路最小剩余带宽相同(均为15 Mbit/s)。随后根据第1步得到两条路径的差值组(0,10,15,15)和(0,5,15,15)。使用式(5)计算两组数据的方差，第一组的方差为50，而第二组为56.25。经过以上路径选择过程，我们将选择方差较小的路径(S1，S2，S3，S7，S8)作为最佳路径。因为该条路径相比于其他路径更加稳定健壮，占用后的剩余可用带宽更多，不会因某段链路的其他突发流量而轻易造成链路拥塞(如可能出现从S2发往S3的突发流量，因该段链路带宽剩余更多，不会轻易拥塞)。

2.2　带宽保障过程

根据当前网络状态和未来变化影响，采用一定的算法为业务选择最佳调度路径。但确定最佳路径之后，当前尚无有效机制保障业务的不同带宽需求。例如，如果两条业务流使用路径选择算法选择了同一路径进行传输，但这两条业务流的带宽需求不同。如果不采取一定的带宽保障措施，它们将平分剩余可用带宽，这将导致带宽需求较高的业务流在传输中大量丢包，影响业务服务质量[7]。

在选定最佳调度路径之后，我们将沿该路径在每台交换机靠近目的端的端口上为业务流设置端口队列。队列包含对业务流的最大传输速率和最小传输速率的限制，并指定处理该业务数据包的方式(从某个端口将业务流转发出去，或者将其丢弃)。

同时，为了确保多个重要业务在传输过程中均能获得足够的带宽，每个业务都会被添加到单独的队列中。即使可能有多个带宽需求相同或相近的业务，它们原本可以被添加到同一个队列中，但我们仍然选择创建多个相同的队列，将每个业务独立添加到一个队列中。这种处理方式将防止同一队列中的多个业务平分剩余可用带宽，避免出现一个或多个业务带宽分配不足的情况。对于整个系统而言，总体处理流程如图2所示。

图2　系统总体流程图

3　实　验

本实验设计了两个模拟场景，分别通过两条先后发出的不同业务流，将本文提出的算法与OPPBG算法和端口队列设置方法在保障业务带宽需求、降低干扰等方面进行比较。

3.1　实验环境

实验在运行于Linux系统(安装在VMware 10.0中的Ubuntu 16.04)的Mininet[8]中创建的虚拟环境下进行。SDN控制器选用运行于Ubuntu的Floodlight控制器[9]。为生成UDP测试流量，实验选用Iperf软件测试工具，以生成稳定的测试流量并提供包括传输带宽在内的反馈信息。

实验所用的网络拓扑如图3所示。该网络由7台OpenFlow交换机和6台主机组成，每段链路的容量(即链路带宽)为100 Mbit/s。在图3中，每段链路上的数字表示该段链路的剩余可用带宽。所有OpenFlow交换机均连接到Floodlight控制器。

图3　实验采用的网络拓扑

3.2　场景1：对比端口队列设置方法

在此场景中，本文提出的算法与使用OpenFlow在端口上设置队列的方法进行带宽保障性能方面的对比，以验证路径选择算法的合理性和有效性。假定有两条需要保障带宽需求的业务流，二者的带宽需求均为65 Mbit/s，且均从h1发往h2，第二条业务流在第一条业务流发出10秒后开始发送。当采用OpenFlow设置端口队列的保障方法时，首先选择网络中的最短路径(h1,S1,S2,S7,h2)，并沿该路径在每台交换机上靠近目的端h2的端口上设置最小速率60 Mbit/s、最大速率为70 Mbit/s的队列。由于两条业务流的总带宽需求(130 Mbit/s)超过链路容量(100 Mbit/s)，因而沿该路径将发生拥塞，两条业务流发生冲突，各自实际的流量传输速率将约为40 Mbit/s到50 Mbit/s，如图4所示。

采用本文提出的路径选择算法，当第一条带宽需求为65 Mbit/s的业务流进入网络中后，仍将选取(h1,S1,S2,S7,h2)作为调度路径。之后该路径的剩余带宽为35 Mbit/s，不能满足第二条带宽需求为65 Mbit/s的业务流的需求，因而进行下一次调度前，(h1,S1,S2,S7,h2)将被删除。随后依据算法流程进行一系列计算，最终将得到第二条业务流的最佳调度路径为(h1,S1,S4,S6,S7,h2)，并沿该路径设置端口队列。根据测试，两条业务流的带宽需求均可得到有效的保障，而不会互相干扰，如图5所示。

通过对比以上实验结果可以看出，采用路径选择算法后，最初的业务流不会受后来业务流的干扰，并且后续业务流的带宽需求也将得到保障。

3.3　场景2：对比OPPBG算法

在本场景中，本文提出的算法与OPPBG算法进行带宽保障性能比较。假定有两条需要保障带宽需求的业务流量，均从h1发往h2。第一条业务的带宽需求为65 Mbit/s，第二条业务流量在第一条业务流发出10秒后开始发送，其带宽需求为25 Mbit/s。在这一场景中，无论选用本文提出的算法，还是选用OPPBG算法进行路径选择，最佳路径均为(h1,S1,S2,S7,h2)。然而，在选出最佳路径之后，OPPBG算法将直接调度流量至所选路径，并不为不同的业务流量设置端口队列以保障其带宽。因此，这两条业务流将平分链路剩余带宽，其传输速率大约为45 Mbit/s到50 Mbit/s。显然，第一条业务65 Mbit/s的带宽需求将无法得到满足，其传输速率将受到影响，如图6所示。

图6　未设置端口队列时的传输速率

采用本文提出的方法，当选择出最佳调度路径之后，将沿调度路径在交换机靠近目的端的端口上为各业务流设置不同限速的队列。为第一条业务流设置最小速率为60 Mbit/s、最大速率为80 Mbit/s的队列，为第二条业务流设置最小速率为20 Mbit/s、最大速率为30 Mbit/s的队列，分别保障两条业务的带宽需求。通过测试，这两条业务流均能够达到其所需的传输速率，业务服务质量不受影响，如图7所示。

图7　设置端口队列时的传输速率

通过实验对比可以看出，采用路径选择与设置端口队列结合的方式，后来的业务流量不会影响网络中已存在的业务流的服务质量。二者可以分别独立地正常传输，而不会互相干扰冲突。

4　结　语

本文对使用OpenFlow设置端口队列的方法以及OPPBG算法的不足进行了分析，并提出了融合改进的方案。通过实验结果对比分析，改进后的基于SDN的路径选择与带宽保障策略能够有效保障每条业务流的传输速率，避免拥塞并提高网络的稳定性。在未来的工作中，我们将针对不同的服务目标，尝试在更为复杂的网络环境和真实网络环境中对本文提出的算法进行测试和优化，从而使算法适用性更强。

[1] Thomas D N, Gray K. SDN: Software Defined Networks[M]. O’Reilly Media, 2013.

[2] 黄韬，刘江，魏亮，等. 软件定义网络核心原理与应用实践[M]. 北京:人民邮电出版社，2014.

[3] Open Networking Foundation. OpenFlow switch specification version 1.3.0 [EB/OL]. [2016-12-30]. https://www.opennetworking.org/.

[4] 肖军弼,隋萌萌,李芃. 基于SDN的网络带宽保障系统[J]. 计算机系统应用, 2016, 25(6):48-52.

[5] Tang W, Liu G, Yang X M, et al. OpenFlow-based path-planning with bandwidth guarantee in the inter-datacenter network[J]. Journal of South-Central University for Nationalities (Nat. Sci. Edition), 2016, 35(2): 128-134.

[6] Agarwal S, Kodialam M, Lakshman T V. Traffic engineering in software defined networks[C]// INFOCOM, 2013 Proceedings IEEE. IEEE, 2013:2211-2219.

[7] Nagaraj K, Bharadia D, Mao H, et al. NUMFabric: fast and flexible bandwidth allocation in datacenters[C]// Proceedings of the ACM SIGCOMM 2016 Conference, 2016:188-201.

[8] Mininet Team. Mininet [EB/OL]. [2016-12-21]. http://mininet.org/.

[9] Project Floodlight. Floodlight controller [EB/OL]. [2016-12-12]. http://www.projectfloodlight.org/.