一种面向应用QoS保障的OpenFlow网络流量控制方法

摘要

本发明给出了一种面向应用QoS保障的OpenFlow网络流量控制方法，包括如下步骤：用户向服务器请求服务，服务器向SDN控制器发送QoS请求消息，控制器收到消息后，根据网络资源使用情况为其计算出传输的最佳路径并预留资源，同时在服务器传输QoS数据流的过程中，监测其传输状态及网络链路情况，以保证QoS流的可靠，稳定的传输。该系统针对严格保障应用服务的QoS传输，并利用服务对网络资源要求的差异性，为应用服务提供需求的网络资源，不仅有效地保证了应用的QoS，同时达到了网络资源的高效利用。

说明书

技术领域

本发明涉及网络保障应用QoS(QualityofService，服务质量)的方法，特别是OpenFlow网络中为应用QoS提供保障的流量控制方法。

背景技术

多媒体，在线交互等新型业务对于传输有着较高的QoS要求，通常要求足够的传输带宽，尽可能低的时延等，不同于“尽力而为”类型的服务。目前提供QoS保障的方法集中在资源预留，队列优先级调度等方面，但都建立在传统的网络体系上，存在许多不足，如资源预留要求路由器具有高性能，导致了开销大，扩展性差等缺点，队列管理与调度针对的是汇聚流，存在控制粒度粗等缺点，并且由于大多方法都是采用逐跳转发的机制，难以达到对全局资源的有效利用。SDN网络体系的数据层和控制层分离思想提供了全新的解决方案，控制器提供逻辑控制功能，数据层只需执行对应的操作的这种方式大大提高了网络的扩展性和流量控制的灵活性。

OpenFlow协议是本发明中至关重要的协议。OpenFlow是一种新型网络协议，起源于斯坦福大学的CleanSlate项目组，用于进行网络创新性实验。其主要思想是将网络设备的控制层和数据层进行分离，控制功能全部集中在控制层，从而可以简化底层设备的功能，增强了网络的可扩展性。自2009年底发布第一个正式版本v1.0以来，OpenFlow协议已经经历了1.1、1.2、1.3以及最新发布的1.4等版本的演进过程。OpenFlow协议中定义了控制器和交换机之间通信的方式，包括控制器如何获得底层网络信息，控制交换机的数据转发等一系列相关操作。因此建立在控制器上的应用层可以间接与控制器进行通信来获取底层网络信息，并利用这些信息来提高应用的服务质量。

发明内容

本文所要解决的技术问题是在SDN网络中提供一种按需分配资源，为应用提供高质量QoS传输策略，使网络可以根据应用流的QoS传输要求，为其分配网络资源，同时合理规划传输路径，达到网络资源利用的最大化。

为解决上述技术问题，本发明提出一种应用服务与控制器之间的通信模式，其基本技术构思是：当用户请求应用服务时，应用服务器首先与控制器进行通信，将服务的传输要求发给控制器。控制器收到服务器消息后，为该QoS流收集目前网络链路信息，计算出最佳路由，预留带宽资源，同时通知服务器开始流传输，之后对传输的QoS流和链路状态进行监测，根据网络资源情况及时调整策略保证QoS流的可靠、稳定传输。

基于上述构思，本发明的特征采用的技术方案如下：

一种面向应用QoS保障的OpenFlow网络流量控制方法，其特征在于，包括以下步骤：

(1)服务器收到用户服务请求后，向SDN控制器发送QoS传输请求消息，传递服务传输QoS要求参数，SDN控制器对QoS传输请求消息进行解析，并为其分配QoSID；其中QoS要求参数包括带宽需求、服务传输允许最大时延、端到端允许最大时延抖动、允许的最大丢包率；

(2)SDN控制器向交换机发送消息，查询当前网络流量信息，得到SDN控制器所在网络内交换机节点和链路的流量信息，包括每条链路的剩余带宽、每条数据流的传输速率、交换机端口转发速率、平均时延；

(3)计算数据流路由，判别数据流是否为为非QoS流数据，是则采用最短路径算法计算路由，转步骤(4)；否则按以下步骤进行QoS流的路由计算：

SDN控制器将步骤(1)中的QoS要求参数和步骤(2)中获得的交换机节点和链路流量信息作为路由计算的参数，采用基于时延约束的最小代价路由算法，判断是否能计算出满足时延要求的路径，是则SDN控制器初始化流表，设定流的QoSID号、具体路径和保证带宽的队列优先级信息，下发至交换机，并向服务器回复消息，通知服务器开始传输数据流，转步骤(4)；否则回复延迟传输数据流消息，控制器重新等待服务器的QoS传输请求消息，转步骤(1)；

(4)控制器对传输的QoS流及链路状况进行监测，当链路出现拥塞并且拥塞链路中存在QoS流或QoS流传输的速率与步骤(1)中带宽需求不一致时，执行预设的调节策略，以保证QoS流的正常传输和网络资源的有效利用；

(5)QoS流传输完毕后，服务器向SDN控制器发送资源释放消息，结束。

所述的网络流量控制方法中，所述服务器是为用户提供应用服务的设备，所述SDN控制器在软件定义网络(SDN)中负责流量控制；所述交换机是指能支持OpenFlow协议的交换机；所述流表是OpenFLow网络中控制器生成的一组规则，下发至交换机执行，用于流量控制；将服务器已发送QoS-Request消息的数据流，称作QoS流，未发送QoS-Request的数据流为非QoS流。服务器和控制器通信消息均为http消息，其中QoS要求参数以XML或JSON的格式封装在消息中。

进一步的，所述的网络流量控制方法中，SDN控制器向交换机发送的消息具体是OpenFLow协议中定义的OFPT_STATS_REQUEST消息，其包括单流请求消息、单流请求消息、流表请求消息、端口请求消息、队列请求消息等多种类型，此步骤中涉及的是单流请求OFPFlowStatsRequest和端口请求OFPPortStatsRequest，其中主要参数包括流表号、输出端口号、流匹配域。交换机回复的OFPT_STATS_REPLY消息主要包括OFPFlowStatsReply和OFPPortStatsReply消息，与请求消息一致。OFPFlowStatsReply消息主要参数包括流优先级，数据流已传输数据包数量packet_count和数据流已传输字节数byte_count，数据流已传输时间duration_sec。流速率可表示为单位时间内传输的字节数时延可表示为传输单个数据包所需要的时间OFPPortStatsReply消息主要参数包括端口传输时间duration_sec，端口已收到数据包数量rx_packets，端口发送的数据包数量tx_packets，端口已收到字节数rx_bytes，端口已发送字节数tx_bytes，则端口上下行转发速率可分别表示为

进一步的，所述的网络流量控制方法中，对非QoS流的路由计算，将链路带宽作为权值，将链路权值设置为将该链路权值代入Dijkstra算法计算出最短传输路径；其中C_e表示链路e的带宽容量，U_e表示链路e已使用的带宽，e表示其中一条链路。其中Dijkstra算法是典型的最短路径路由算法，用于计算一个节点到其他节点的最短路径。主要特点是以起始点为中心向外层层扩展。计算时需要为每条链路设置参数，参数可以是链路的带宽，时延，丢包率或其他组合值。这里选取链路的容量和剩余带宽的比值作为链路的参数，主要是为了达到网络流量的负载均衡，

进一步的，所述的网络流量控制方法中，计算路由的DCLC算法也可以针对具体情况选取其他QoS路由算法，其能够在多项式时间内计算出满足时延约束，且时延抖动和丢包率代价最小的路径，其中代价参数设置可变参数，能够根据应用的具体类型取不同的值来处理不同要求的QoS流，并且算法的时间复杂度降为O([m+nlogn]²)，其中n代表节点数，m代表链路数，与其他QoS路由算法相比时间复杂度低，其具体过程如下：

(3.1)构造链路代价参数：

C_ij＝(1-β)g_ij+βp_ij，0＜β＜1；

其中i，j表示链路中相邻的两个节点，g_ij代表i，j之间的延时抖动，p_ij代表节点i，j之间的丢包率；β为比例系数，其值可变，如对延迟抖动要求高的QoS流应取小，对丢包率要求更高的应取大一些；

(3.2)建立满足时延约束且代价最小的路由r*的数学模型：

r*＝arg_rmin{f_c(r)|r∈r_st,f_d(r)≤d_max}；

其中r_st表示源节点s和目的节点t之间的所有路由集合，r∈r_st表示其中的一条路由，为路径r的总代价，d_ij代表相邻节点i，j之间链路的时延，路径r的总时延，d_max为QoS流允许最大时延，其值为步骤(1)确定的服务传输允许最大时延；

(3.3)采用拉格朗日松弛算法对上述QoS路由模型进行求解，具体过程为：

(3.3.1)将C_ij作为链路权值，代入Dijkstra算法求解出代价最小的路径r_c；

(3.3.2)判断路径r_c的延时是否小于d_max，是则将r_c作为所求路径，返回r_c路由，转(3.3.8)；否则转(3.3.3)；

(3.3.3)将d_ij作为链路权值，代入Dijkstra算法求解出时延最小的路径r_d；

(3.3.4)判断路径r_d的时延是否大于d_max，是则表明无法计算出符合要求的路径，向服务器回复延迟发送消息，转(3.3.8)；否则转(6.3.5)；

(3.3.5)令松弛参数其中f_c(r_c)是路径r_c的代价值，f_c(r_d)是路径r_d的代价值，f_d(r_d)是路径r_d的总时延，f_d(r_c)是路径r_c的总时延；将链路权值设置为代价参数和延时参数的组合参数值，即C_λ＝C_ij+λd_ij，代入Dijkstra算法求解出链路权值为C_λ时最小的路径r_λ；

(3.3.6)判断f_λ(r_λ)和f_λ(r_c)是否相等，是则将r_d作为所求路径，转(3.3.8)；否则转(3.3.7)，其中f_λ(r_λ)，f_λ(r_c)分别是路径r_λ和r_c以C_λ作为路径中每条链路权值的路径总组合参数值，和链路总时延概念一致，只是总时延是将链路的时延作为链路的权值；

(3.3.7)判断路径r_c的延时是否小于d_max，是则令r_d＝r_λ，转(3.3.5)；否则令r_c＝r_λ，转(3.3.5)；

(3.3.8)结束。

进一步的，所述的网络流量控制方法中，步骤(4)中的调节策略具体过程以下：

(4.1)对数据流采样，判断数据流传输速率是否大于请求带宽，是则在流入口处执行限速策略，即在入口之间限制其速率，使其与请求的带宽一致，转(4.3)；否则转(4.2)；

(4.2)缩小步骤(3)为其预留的带宽，将其设置为目前QoS流传输速率大小；

(4.3)对链路采样，判断链路带宽使用率是否达到80％且链路上存在QoS流传输，是则代表链路拥塞状态，转(4.4)；否则转(4.7)；

(4.4)判断链路上的所有数据流中是否存在非QoS数据流，是则执行(4.5)；否则执行(4.6)；

(4.5)选择传输速率最大的非QoS流，删除拥塞链路后采用最短路径算法重新计算路由，转(4.3)；

(4.6)选择传输速率最大的QoS流，删除拥塞链路后采用DCLC算法重新计算路由，转(4.3)；

(4.7)延迟T秒后转(4.1)；T根据网络具体情况确定，一般为1-3秒。

本发明通过在控制器与应用服务器之间建立了一种有效的消息机制，使控制器能根据应用服务提出的QoS-Request要求和QoS-Release消息，来对网络资源进行合理的分配，同时采用时延约束的最小代价QoS路由算法保证了QoS流的正常稳定传输，并且在QoS流传输过程中采用了流量采样监测的方法，使控制器能够及时调整资源分配和QoS流控制策略以保证用户可以获得高质量的QoS服务，同时使网络资源得到有效的利用。

与现有技术相比，本发明具有以下优点：通过控制器和应用服务器之间的消息机制，使控制器能够按需分配网络资源，保证了网络资源利用的最大化。同时采用基于的时延约束最小代价路由算法和QoS流及链路状态监测算法为QoS流传输提供了严格的QoS保证，使交换机不必实现复杂的协议，提供额外的功能，实现简单，部署容易。

附图说明

图1为本发明流程示意图；

图2为本发明工作时序图；

图3为本发明实施例的拓扑图；

图4为本发明实施例的QoS流传输拓扑图；

图5为本发明实施例的非QoS流传输拓扑图；

图6为本发明链路状态监视流程图。

具体实施方式

下面结合附图对本发明作进一步说明。为了解决网络中应用QoS流传输得不到有效的保障和网络的资源得不到有效的利用问题，本发明提出了一种面向应用QoS保障的OpenFlow网络流量控制方法，该方法包括以下几个步骤，如图1所示：

(1)服务器收到用户服务请求后，向SDN控制器发送QoS传输请求消息，传递服务传输QoS要求参数，SDN控制器对QoS传输请求消息进行解析，并为其分配QoSID；其中QoS要求参数包括带宽需求、服务传输允许最大时延、端到端允许最大时延抖动、允许的最大丢包率；

(2)SDN控制器向交换机发送消息，查询当前网络流量信息，得到SDN控制器所在网络内交换机节点和链路的流量信息，包括每条链路的剩余带宽、每条数据流的传输速率、交换机端口转发速率、平均时延；

(3)计算数据流路由，对非QoS流数据，采用最短路径算法计算路由，转步骤(4)；对QoS流的路由计算，SDN控制器将步骤(1)中的QoS要求参数和步骤(2)中获得的交换机节点和链路流量信息作为路由计算的参数，采用基于时延约束的最小代价路由算法(DCLC算法)，判断是否能计算出满足时延要求的路径，是则SDN控制器初始化流表，设定流的QoSID号、具体路径和保证带宽的队列优先级信息，下发至交换机，并向服务器回复消息，通知服务器开始传输数据流，转步骤(4)；否则回复延迟传输数据流消息，转步骤(1)；

(4)控制器对传输的QoS流及链路状况进行监测，当链路出现拥塞且拥塞链路中存在QoS流或QoS流传输的速率与步骤(1)中带宽需求不一致时，执行预设的调节策略，以保证QoS流的正常传输和网络资源的有效利用；

(5)QoS流传输完毕后，服务器向SDN控制器发送资源释放消息，结束。

图2为本发明系统的工作时序图，也是本发明中的核心消息机制，其主要包括对http消息进行扩展的QoS请求消息、开始传输消息、传输完毕消息及流表删除成功消息，分别用于传输QoS参数，通知服务器开始传输，通知控制器删除流表消息，流表删除成功信号；另外包括OpenFlow协议中定义的由控制器发起的流及链路流量情况查询消息分别用于查询QoS流状态信息及端口链路信息，控制器向交换机下发流表信息，以及由于网络链路拥塞或流传输速率变化时的进行流表修改的消息。

为了进一步说明本发明的具体实现方法，现以图3实施例进行说明。本实施例中T取2秒，控制器选取的是由社区主导的开源框架OpenDaylight，应用服务是视频服务(不考虑具体视频编解码)，其作为传输的QoS流，FTP服务作为非QoS流，网络拓扑链路带宽为10Mbps。

步骤一、SDN控制器收到应用服务器的QoS要求,普通视频流QoS要求至少2M带宽,允许最大时延为50ms,丢包率不大于5％，时延抖动不超过10ms，FTP作为本实施例中的非QoS流，没有QoS要求参数。

步骤二、SDN控制器获取当前全网拓扑链路及流量信息(假设此时拓扑中还不存在QoS流，只有非QoS再传输)，如图4所示链路上的各分量依次代表每条链路的剩余带宽，延时，抖动及丢包情况，现采用基于时延的最小代价路由算法为视频流计算路由，以链路时延作为约束条件，时延抖动和丢包率作为代价参数计算出视频流传输路径。其首先删除不满足带宽要求的链路S3-S4，S4-S0，S2-S0，接着利用Dijkstra算法从剩余拓扑中找出代价最小的路径为S6-S5-S1-S0，其延时为29ms，满足延时要求(此为该路由计算的最好情况，否则必须不断进行迭代计算)，则为路径为视频流的起始传输路径，并通知视频服务器可开始传输。

步骤三、同时用户请求FTP服务，则FTP服务器也开始传输其非QoS流，此时网络拓扑带宽信息为图5所示，由于为非QoS流计算路由时只关心链路的剩余带宽。此时控制器将利用链路带宽权值Dijkstra算法为其计算路由，此时路径S6-S2-S1-S0的总链路权值和为为所有的路径中最小，作为其传输路由。当非QoS流的传输速率为2M以下时，此时若对链路S6-S5-S1-S0进行检测，链路并不满足拥塞判决条件。但达到2M以上时导致链路S1-S0超过8M，造成拥塞，此时需要对该非QoS流进行重路由。首先删除拥塞链路S0-S1，重新用链路带宽权值Dijkstra算法为其计算路由，计算出路径为S6-S2-S0，这样既保证了QoS流的正常传输，同时又使网络流量达到了负载均衡。

最后所应说明的是，以上具体实施方式仅用以说明本发明的技术方案，尽管从各个角度对本发明的每个部分进行了详细的阐述，本领域的普通技术人员应当理解，可以对本发明的技术方案进行修改或者等同替换，而不脱离本发明技术方案的精神和范围，其均应涵盖在本发明的权利要求范围当中。