基于OpenDaylight網絡感知和用戶需求的路徑選擇算法

劉 麒，王 璐，楊 曉，李 華，2

1(內蒙古大學 計算機學院，呼和浩特 010021) 2(內蒙古大學 圖書與信息技術部，呼和浩特 010021) E-mail ：cslihua@imu.edu.cn

1 引 言

隨著云計算的發展，數據和計算都放在云端，提高了資源的利用率，同時也使得支撐云的數據中心網絡承受了很大的壓力.而隨著各種新應用的出現，人們對網絡帶寬的靈活分配要求也更加突出，如何讓盡可能多的用戶在有限的資源內獲得好的網絡服務質量就成為一個嚴峻的問題.例如對于鏈路負載均衡來說，如何在網絡資源有限和滿足用戶需求的條件下，合理利用分配機制進行路徑選擇等.SDN技術將控制平面與數據平面分離，使得SDN控制器可以獲取網絡的全局靜態拓撲、動態轉發表信息、網絡設備資源利用率、故障狀態等信息，由此實現對網絡資源的統一管理，并采用規范化的北向接口為上層應用提供按需的網絡資源及服務[1].因此目前有很多研究工作利用SDN技術為云數據中心提供靈活的網絡服務.

傳統IP網絡主要使用流量監測工具來進行流量監測，但如果在控制器中使用這些工具進行大量測量與信息收集會增加控制器的額外負擔與開銷.在SDN網絡中，控制器與交換機通過OpenFlow協議交互，其中包含端口的統計信息，如發送接收數據包數、已發送字節、已接收字節等，并且可通過控制器REST API 查詢相關統計信息，因此 OpenFlow 網絡本身已經具備了一定的網絡狀態監測能力.

要想合理的利用網絡資源，就要充分的了解用戶的需求和網絡中的流量情況，然后才能進行合理的路徑選擇.基于SDN的路由算法一直是當前的研究熱點，目前大多研究都是利用SDN控制器可以監測底層網絡的狀態信息這一優勢，提出相關的算法找到滿足用戶需求的路徑，從而有效的利用寬帶資源、提高用戶滿意度，同時也提升了網絡運營商的收益.本文貢獻如下：

1)研究基于OpenDaylight網絡狀態的實時感知方法，有利于制定更合理的路徑選擇策略.

2)結合網絡實際情況和用戶需求進行路徑選擇，既滿足了用戶需求又提升了網絡性能.

3)基于SDN網絡進行路徑選擇策略的下發，提升了路徑選擇的實時性和靈活性.

本文組織如下：

第1節介紹了服務質量保證的重要性，并敘述了傳統網絡狀態感知的不足之處以及SDN網絡的優勢.第2節介紹了相關工作的研究.第3節介紹了在SDN網絡中進行網絡感知的方式與路徑選擇算法具體流程，并對提出的路徑選擇算法進行改進.第4節介紹了在OpenDaylight控制器中實現算法的步驟以及實驗結果.第5節對本文所做工作進行了總結，并敘述了未來的研究方向.

2 相關工作

對于SDN網絡感知問題，國內外研究者提出了不同的解決方案.文獻[2]中提出一種網絡流量矩陣系統——OpenTM，通過OpenFlow協議中的計數器來實現，它定時從OpenFlow交換機中獲取各個流表項的匹配數據包數與字節數，并通過流表項的統計數據來計算主機之間流量的估計值.但這種周期性的查詢方法會給網絡帶來大量開銷.文獻[3]提出了一種以低開銷的被動的方式進行網絡狀態測量的方法，通過交換機向控制器發送PacketIn消息和流規則到期后的FlowRemoved消息來計算交換機的利用率.但是這種方法只有當一個流表項被刪除之后才能獲取統計信息.在文獻[4]中提出基于SDN的監測框架PayLess，它提供了一個靈活的Restful API在不同整合階段可以對數據流進行收集.這個框架使用合適的數據收集算法，提取出精確度較高的信息并且不會產生顯著的網絡開銷.但是這種方法統計數據的開銷取決于時間間隔的大小，時間間隔越小，網絡開銷越大.文獻[5]定義了一個類似OpenFlow協議的網絡流量測量框架——OpenSketch，通過對交換機進行簡單且靈活的配置就可以實現滿足不同需求的網絡測量.但是需要在控制器與交換機之間實現與OpenFlow協議完全不同的另一種通信協議，所以實現這種方法的代價很大.在文獻[6]中，IBM提出一種OpenSample測量方案，利用sFlow 進行網絡負載和單個流的實時測量，采用了較高的采樣率，但是這樣仍然會限制測量的準確性，并且可能會給網絡設備造成一定負擔.文獻[7]提出利用同一個流中相鄰兩個采樣包中TCP 頭部的序號差，除以sFlow采樣數據中自帶的對應采樣時間戳的差值，來得到TCP 流在該測量窗口中的準確速率值.

在QoS方面，文獻[8]中提出一種基于SDN的QoS控制框架，它能夠通過準確的網絡模型計算并分配資源.文獻[9]中提出了基于OpenFlow的QoS流量控制方法，主要包括網絡資源監視模塊、QoS策略及要求解析模塊、QoS路由計算模塊和QoS路由管理及資源分配模塊.文獻[10]中提出一種在SDN下的Autonomic QoS管理機制AQSDN.在AQSDN中各種QoS等級能夠通過OpenFlow和Of-Config被自動的配置在OpenFlow交換機中.文獻[11]將應用感知路由作為一個多約束優化路徑問題，提出一種在SDN環境下支持動態QoS的應用感知路由架構.SDN控制器可以動態地下發路由決策，充分提高網絡資源的利用率.文獻[12]設計并實現了一個資源預留系統，該系統可以為業務流提前預留帶寬，保證有帶寬需求的業務可以分配到足夠的帶寬.同時提出了帶寬預留的蟻群算法BRACO(Ant Colony Optimization of Bandwidth Reservation)，該系統以BRACO 作為路由算法為數據流計算路徑，得到的路徑可以滿足一定的時延和丟包率的要求.但這種預留會給網絡帶寬帶來極大的浪費.

對于OpenDaylight控制器，文獻[13]將OpenDaylight控制器與POTN網絡進行結合，實現拓撲管理、資源管理、隧道業務管理等功能.文獻[14]通過蟻群算法在OpenDaylight和Mininet環境下實現了最小負載鏈路的選擇.文獻[15]實現了一種基于蟻群優化算法的負載均衡系統，并通過編寫OpenDaylight模塊的方式實現該系統.但以上研究都基于網絡的實時狀態，在具體的策略制定中并沒有考慮用戶的實際需求.

3 網絡感知與路徑選擇

網絡感知是路徑選擇的前提，只有掌握網絡的實時狀態(如網絡靜態拓撲、底層設備轉發策略和鏈路的時延以及丟包率等)才能做出更加有效的路徑選擇策略.而SDN控制器的優勢是轉發與控制分離使得控制邏輯集中，控制器擁有網絡的全局靜態拓撲、全網的動態轉發表信息、全網絡的資源利用率、故障狀態等信息，因此控制器可以依靠其掌握的整個網絡的實時狀況，利用路由算法對底層網絡資源進行合理的使用，創建合理的路徑選擇策略，進而有效的提高網絡資源的利用率.所以本文的網絡感知主要對底層網絡流量情況進行監測和分析.

3.1 網絡感知

OpenDaylight控制器中包括一些基本的網絡服務模塊，如圖1所示.本文主要通過TopologyManager、ForwardingRulesManager和StatisticsManager模塊實時監測流量信息.

圖1 基本網絡服務模塊Fig.1 Basic network service module

圖1中的StatisticsManager模塊可以獲取網絡中交換節點的統計數據.使用其FlowOnNode類獲取交換節點的端口數據包數量、端口字節數，通過這些數據可以計算QoS的三個約束值：帶寬、時延和丟包率.本文主要使用的函數如下所示.

public void setPacketCount(long count)//發送數據包的數量

public void setByteCount(long count)//發送字節

public long getPacketCount()//獲取端口數據包的數量

public long getByteCount()//獲取端口的字節數

public int getDurationSeconds()//獲取端口的持續時間

List getFlows(Node node)//獲取指定節點上的所有流數據

public void setDurationSeconds(int durationSeconds)//獲取持續時間

Map>

getFlowStatisticsForFlowList(List flows)//獲取流鏈表中指定流的統計數據

NodeConnectorStatistics getNodeConnectorStatistics(NodeConnector nodeConnector) //返回指定nodeconnector的統計數據

ListgetNodeConnectorStatistics(Nodenode)

//指定節點上所有nodeconnector的統計數據鏈表

通過圖1中的Topologymanager模塊可以獲取所有節點之間的連接以及它們的屬性信息，進而獲取網絡拓撲信息.本文主要使用的函數如下所示.

public Map>

getEdges()//獲得一個map集，是由所有節點之間已知的連接以及它們的屬性組成的

public Set getNodeConnectorWithHost()//返回有主機相連的NodeConnector 的set集

public List getHostsAttachedToNodeConnector(NodeConnector p)//返回連接到一個nodeconnector的主機list集合

public Map>

getNodesWithNodeConnectorHost()//返回map集，所有含有nodeconnector相連的node

org.opendaylight.controller.sal.topology：TopoEdgeUpdate；一個類，代表一個邊，以及邊的屬性集，和更新類型

public TopoEdgeUpdate(Edge e，Set p，UpdateType t)；//更新一個topology 邊的元素接口

通過StatisticsManager模塊和TopologyManager模塊就可以獲取到SDN網絡中交換節點的流表、端口、隊列等統計信息.其中端口的統計信息主要包括發送數據包數、接受數據包數、發送字節數、接收字節數.計算剩余可用帶寬，時延和丟包率的方法如下：

1)計算鏈路的已使用帶寬和剩余可用帶寬

通過在OpenFlow 交換機端口的計數器，獲取該端口接收或者發送的比特數.假設在startime 時刻統計到該端口接收的比特數量為sByteCount，在endtime 時刻統計到該端口接收的比特數量為tByteCount.該端口的最大帶寬為totalbw，可通過控制器獲取.已使用帶寬usedbw的計算方式為：

usedbw=(sByteCount-tByteCount)/(endtime-startime)

剩余可用帶寬remainbw的計算方式為：remainbw=totalbw-usedbw

2)計算時延

將統計數據包的平均時延作為近似時延，將一條路徑上的所有交換機中記錄的持續時間的和作為這條鏈路上的時延.例如某條鏈路只經過交換機S1和S2，數據包在交換機S1端口的持續時間為sDurationSecondsSum交換機S2的持續時間為tDurationSecondsSum，則這條路上的時延dWeight為：

dWeight=sDurationSecondsSum+tDurationSecondsSum；

即S1到S2的持續時間之和，為當前路徑的時延.

3)計算丟包率

已知源交換機發送的數據包數tPacketCountsSum，目的節點接收的數據包數為sPacketCountsSum，那么丟包率dWeight計算方式如下：

dWeight=(tPacketCountsSum-sPacketCountsSum)/tPacketCountsSum；

3.2 路徑選擇算法1

獲取網絡信息的同時也需要充分的了解用戶需求，才能能制定更加優化的策略進行路徑選擇.本文將QoS參數作為約束條件改進基本路由算法，從而可以有效的利用寬帶資源并提高服務質量.本文中的用戶需求是指用戶的硬性要求，可以是用戶對于帶寬、網絡延時和丟包率的容忍度.考慮到底層網絡的情況和用戶需求，在滿足多個QoS約束的前提下找出一條從源節點到目的節點代價最小的路徑.

在OpenDaylight控制器中，routing模塊中已有Dijkstra算法的實現，主要繼承Irouting和 ITopologymanagerClusterWideAware接口，其中IRouting是為了查找路徑，ITopologymanagerClusterWideAware是為了保存拓撲，以便路徑更新.在IRouting接口中的相關方法如下所示.

public Path getRoute(Node src，Node dst)；//獲取從源節點src到目的節點dst的一條路徑

public Path getMaxThroughputRoute(Node src，Node dst)；//獲取一條從源節點src到目的節點dst的最大吞吐量的路徑.

public Path getRoute(Node src，Node dst，Short Bw)；//獲取一條從源節點到目的節點的滿足具體設置的帶寬BW的一條路徑

Opendaylight控制器中的尋路算法包括以下三種：

1)選出從源節點到目的節點經過節點最少的一條路徑.

2)選出從源節點到目的節點鏈路吞吐量最大的一條路徑.

3)選出從源節點到目的節點滿足帶寬要求的一條路徑.

但是OpenDaylight中的路徑選擇算法并不能實現滿足用戶多QoS約束的算法.

本文實現的多QoS約束算法是指通過路由算法在滿足用戶QoS需求的前提下，計算出一條代價最小的可行路徑.為了完全滿足用戶的需求，將帶寬BQoS、時延DQoS、丟包率LQoS分別作為權重，進行路徑選擇，算法思想描述如下：

Step1.根據用戶需要的BQoS作為權值，計算路徑，篩選出大于BQoS的所有路徑P，構成集合PB.

Step2.從篩選出滿足大于BQoS的路徑集PB中，根據用戶需求的DQoS作為權值來計算路徑，篩選出小于DQoS的所有路徑集，構成集合PD.

Step3.從篩選出滿足小于DQoS的路徑集合PD中，根據用戶需求的LQoS作為權值來計算路徑，求得滿足三種QoS參數的的路徑PL.

由于各個QoS的參數取最優的時候可能會出現PD、PL不存在，這時可以求該網絡中的次優解，求得滿足Step1和Step2的路徑集PD，若此時PD仍不存在，求只滿足Step1的路徑PB.只保留step1是因為本文至少要保障帶寬的約束能滿足需求.

算法1.多QoS約束路徑選擇算法

輸入：Bandwidth為用戶要求的帶寬、Delay為用戶需求的時延、loss_parket_rate為用戶需求的丟包率，起始頂點Vs、目的頂點Ve.

輸出：滿足用戶需求的路徑

//設bw表示Bandwidth，dl表示Delay，lp表示loss_parket_rate

BEGIN

pathList=getPathList(Vs，Ve)；

/*獲取所有從源到目的的路徑，集合pathList存放所有從源節點到目的節點的路徑*/

procedure alloc_path(Vs，Ve，pathList，bw，dl，lp)

/*集合pathList1、pathList2和pathList3存放所有滿足當前條件的路徑*/

IFpathListNOTNULL

pathList1=getbw(pathList，bw)；

ELSE

ReturnNULL；

IFpathList1NOTNULL

pathList2=getdl(pathList1，dl)；

ELSE

ReturnpathList；

IFpathList2NOTNULL

pathList3=getlp(pathList2，lp)；

ELSE

ReturnpathList1；

IFpathList3NOTNULL

ReturnpathList3；

ELSE

ReturnpathList2；

END

本算法考慮了當找不到一條滿足用戶所有需求的路經時，盡可能再給出一個滿足用戶大多數需求的解，例如算法找不到同時滿足用戶所要求的帶寬、時延和丟包率的路徑，會給出同時滿足帶寬、時延的路徑，如果仍然無法找到則找出僅滿足帶寬的路徑.用戶對帶寬、時延和丟包率側重程度不同，算法中getbw()、getdl()和getlp()執行的先后順序也會不同.

3.3 路徑選擇算法2

前面給出了一種同時滿足帶寬、時延和丟包率三個QoS約束條件的算法過程，但是該算法會存在路徑p不滿足任何一個QoS約束的情形，即無法找到滿足用戶需求的路徑.并且當有多個滿足用戶需求的路徑時，無法很好判斷哪一條路徑更優.所以改進算法中將多QoS約束的算法問題轉化為一個線性規劃的問題.為了便于描述，給出如下定義.

定義1.假設底層網絡是一個帶權有向圖G(V、E)，其中，V為結點集合V={vi|i=1…n}，E為鏈路集合E={e(i，j)|1<=i，j<=m且i<>j}，每條鏈路e(i，j)的權值由三元組表示(b(i，j)，d(i，j)，l(i，j))分別表示鏈路的帶寬、時延和丟包率.

定義2.假設p是圖G的路徑，表示為p(v1…vn)，其中的vi 為網絡節點，e(i，j)是p上的一條邊，p的3個QoS參數分別是路徑的帶寬B(p)、路徑的時延D(p)和路徑丟包率L(p)，用戶需求中的3個QoS參數分別為用戶所要求的帶寬BQoS、時延DQoS和丟包率LQoS.根據用戶需求和路徑的情況，對于路徑p，假設它的目標函數是f(p)，其定義如下所示：

f(p)= a*(BQoS/B(p))+b*(D(p)*DQoS)+

c*(L(p)/LQoS)

s.t.(0≤a≤1，0≤b≤1，0≤c≤1)

其中，B(p)≥BQoS，D(p)≤DQoS，L(p)≤LQoS，并且a+b+c=1，a、b和c分別表示用戶需求中對于帶寬、延時和丟包率的側重權值，并且當a 、b和c中某個為0時，表明用戶不需要該項約束.另外f(p)作為路徑的目標函數，其值越小，則說明p這條路徑越優.符合上述形式化定義的計算路徑的算法如下：

算法2.符合多QoS約束的路徑選擇算法

輸入：用戶需求的帶寬、時延和丟包率分別為BQoS、DQoS和LQoS，網絡拓撲圖為G(vertexs，edges)，用戶需求中對于丟包率、路徑時延和路徑帶寬的側重權值a、b、c，起始頂點Vs，結束頂點Ve

輸出：符合條件的最佳path

BEGIN

pathList=DFS(Vs，Ve，G(vertexs，edges))； /*利用圖的深度優先遍歷算法獲得所有Vs到Ve的路徑*/

pathListMeetDemand=alloc_path(Vs，Ve，pathList，bw，dl，lp)； /*調用算法1，求出所有滿足用戶需求的路徑*/

FORpathMeetDemandINpathListMeetDemand

f(pathMeetDemand)=a*(BQoS/B(pathMeetDemand))+b*(DQoS/D(pathMeetDemand))+c*(LQoS/L(pathMeetDemand))；

IF(min > f(pathMeetDemand))

min=f(pathMeetDemand)；

path=pathMeetDemand；

ENDIF

ENDFOR

RETURNpath；

END

算法根據用戶需求模塊中獲取到的用戶要求的帶寬BQoS、時延DQoS、丟包率LQoS和網絡感知模塊中獲取到的帶寬BMatrix、時延DMatrix和丟包率LMatrix，使用算法2，如果B(path_temp)≥BQoS且D(path_temp)≤DQoS且L(path_temp) ≤LQoS，找出f(path)值最小的那條路，作為最優解.該算法對算法1的執行結果繼續進行優化，對于滿足用戶帶寬、時延和丟包率需求的多條路徑，計算每條路徑的f(p)值并進行排序，總會找到一個f(p)最小的路徑作為最優解.

3.4 路徑選擇算法3

盡管算法1和算法2可以找出滿足用戶需求且開銷最小的路徑，但是其時間復雜度呈指數級增長，當節點數量很多時會花費大量時間和計算開銷選擇路徑.所以算法3選擇一種折中方案進行路徑選擇，其思想是使用目標函數初始化圖中的每一條邊，賦予每一條邊一個新的權值，再通過Dijkstra算法找出目標函數值相加最小的一條路徑.算法描述如下所示：

輸入：用戶需求的帶寬、時延和丟包率分別為BQoS、DQoS和LQoS，網絡拓撲圖為G(vertexs，edges)，當前路徑的帶寬BMatrix、時延DMatrix和丟包率LMatrix，用戶需求中對于丟包率、路徑時延和路徑帶寬的側重權值a、b、c，起始頂點Vs、結束頂點Ve

輸出：符合條件的最佳path

BEGIN

FORi

FORj

IFBQoS≤BMatrix(i，j)ANDDqoS≥DMatrix(i，j)ANDLQoS≥LMatrix(i，j)

newGraph(i，j)=a*(BQoS/BMatrix(i，j))+b*(DQoS/DMatrix(i，j))+c*(LQoS/LMatrix(i，j))；

ELSEnewGraph(i，j)=MAX；

ENDFOR

ENDFOR

path=Dijkstra(newGraph，Vs，Ve)；

RETURNpath；

END

算法3的時間復雜度為T(n)=O(n2).算法可以保證所選路徑的每一條邊都是最優的，但是不能保證最后選出的路徑是全局最優.因為所選擇的路徑上每一條邊的目標函數值之和最小，并不能保證整條路徑的目標函數值最小.但是其優點是可以在合理的時間內計算出較為優化的路徑.

4 實 驗

為了進行實驗仿真，首先需要分析用戶需求，同時要獲取當前網絡中帶寬、時延和丟包率的信息，然后根據用戶需求和當前網絡情況，計算滿足多QoS約束的路徑，控制器根據算法計算所得的路徑下發流規則給交換機，底層交換機根據流規則進行轉發，這樣在滿足用戶需求的同時能合理的利用資源.具體的仿真實驗執行過程如圖2所示.

圖2 用戶需求到形成規則的過程Fig.2 Process of transforming user requirements into rules

4.1 實驗過程

4.1.1 YANG語言描述用戶需求

用戶需求可通過SLA進行形式化描述，但是SLA屬于高層策略，SDN控制器不能直接接收和理解用戶的SLA需求，所以需要將SLA需求轉換為控制器可以識別的語言.CNL是受控自然語言，它主要用來改善高級語言翻譯為低級語言的能力或為正式符號提供自然和直觀的表示.所以本文采用CNL來描述SLA，并將其轉換為控制器可以識別的語言，從而使得控制器能夠按照用戶的需求來進行工作.CNL的語法描述如表1所示.

一條SLA：“Video services should receive bandwidth higher than 100kbp or delay lower than 300ms”，對應于CNL格式中的Requirement，SLA中bandwidth higher than 100kbp or delay lower than 300ms對應CNL格式中Expression，SLA中bandwidth higher than 100kbp和delay lower than 300ms對應CNL格式中2個Term.

本文用DemandModel模型來描述一條SLA，其中使用import關鍵字將expression模型導入進來，使用grouping關鍵詞來增強模型的重用性.用YANG來刻畫一條SLA如表2所示.

表2 YANG描述的CNL格式模型Table 2 CNL format model described by YANG

同時我們也使用YANG語言對SLA中的Term和expression進行描述.并通過YANG語言描述系統的RPC接口，使得其他程序可以通過REST API對程序進行調用.

4.1.2 模塊實現

.本文將算法2實現為4個模塊，分別是path-model、path-plugin、path-service和path-nourthbound模塊.在path-model模塊中，用YANG對用戶需求CNL進行建模，同時通過YANG Tools生成相應的java接口、類及方法等，將SLA具體參數傳入到YANG模型生成的Java接口的input方法中；path-plugin模塊實現具體算法；path-service模塊中，根據模型生成的Java Service接口，自定義API服務接口，提供可以用于北向接口調用的服務；path-nourthbound 模塊定義REST API服務接口，對外提供服務.

圖3 控制器中安裝的jar包Fig.3 Jar packages installed in controller

完成上述四個模塊的開發之后，啟動OpenDaylight控制器，在控制器中安裝以上4個jar包，執行結果如圖3所示.

然后使用Mininet配置文件創建SDN底層物理網絡拓撲，如圖4所示.

圖4 網絡拓撲圖Fig.4 Network topology

當有用戶提出SLA需求，通過CNL的格式劃分將用戶需求的QoS信息傳入到YANG模型產生的RPC的input[17]，然后系統從OpenDaylght中獲取網絡的帶寬矩陣、時延矩陣和丟包率矩陣，根據多約束QoS算法自動進行路徑選擇，并通過REST API返回選擇結果.

4.2 實驗結果

根據網絡感知模塊獲取交換機端口字節數、數據包持續時間等信息統計，并進行分析，得到交換機端口的流量分布情況，如圖5所示.

圖5 交換機端口流量Fig.5 Port flow of switches

在圖5中s1、s2、s3、s4、s5、s6表示為圖4中網絡的交換機，縱坐標表示為交換機端口的流量信息，橫坐標表示為時間.

根據用戶不同需求，得到REST API的返回結果并進行分析，如表3所示.

表3 測試用例結果Table 3 Results of testing use case

表3中success表示找到了滿足用戶需求的路徑或者在當前網絡環境中，網絡的帶寬、時延和丟包率都不滿足用戶需求時，根據算法計算目標函數f(p)，選擇最優或者較優的路徑給用戶提供服務，REST API返回success.

同時，為了將算法更好的融入OpenDaylight控制器，我們也將算法寫入到OpenDaylight控制器中，替換其原有的Routing模塊，對于指定源和目的路徑采用本文所提出的算法，其他的路徑依然沿用系統本身的Dijkstra算法.改進后程序架構圖如圖6所示.

圖6 改進后程序架構圖Fig.6 Architecture of improved program

如圖6所示，OpenDaylght中包括很多網絡服務功能，其中Routing模塊負責任意兩點間最短路徑的計算，該模塊使用的圖的數據結構和Dijkstra算法依賴于開源庫JUNG.我們修改該模塊源碼并生成相應的JAR文件，替換至OpenDaylight的OSGI框架中.對比調用OpenDaylight中最短路徑算法(Dijkstra算法)和改進后的路徑選擇算法所用時間，以驗證算法的耗時.本文實驗選取包含7到12個交換機的拓撲結構，分別測量對OpenDaylight改進前后初始化網絡拓撲所用時間，結果如圖7所示.

圖7 對OpenDaylight改進前后對比圖Fig.7 Comparison before and after improving open daylight

從圖7中可以看到，改進后算法相對于沒有改進的算法耗時僅增加0.2到0.4毫秒，并且總的初始化時間均小于或等于1毫秒.雖然改進OpenDaylight后，網絡拓撲初始化耗時增加，但增加的幅度顯然是可以接受的，同時也驗證了本文所提出的路徑選擇算法的可行性.

5 總結與展望

本文基于OpenDaylight控制器對SDN網絡狀態進行實時感知，給出帶寬、時延和丟包率的具體計算方法，該方法有助于根據網絡實時狀況動態作出路徑選擇決策；結合網絡狀態和用戶對網絡的具體需求，選出最優或較優路徑，充分利用了SDN網絡的靈活性，在網絡資源有限的情況下提高了網絡資源利用率；在OpenDaylight控制器中實現了相應的模塊，增強了控制器的網絡感知能力，并可以滿足更多用戶對于服務質量的需求；對控制器中Dijkstra算法進行擴充，進一步提升了算法的運行效率，使其為用戶提供更加優質的服務.

未來將會對更多的網絡狀態進行細粒度地感知，動態智能地調整策略提升網絡資源的利用率.進一步研究OpenDaylight其他版本中進行網絡感知的方法，并在真實的SDN網絡環境中進行實驗驗證.