孔祥彬，沈蘇彬，李 莉

(南京郵電大學(xué) 計算機學(xué)院、軟件學(xué)院，江蘇 南京 210003)

0 引 言

在IP網(wǎng)絡(luò)中，網(wǎng)絡(luò)設(shè)備變得越來越難以配置和安裝，從IP網(wǎng)絡(luò)中添加或移動一個設(shè)備需要耗費許多成本，信息技術(shù)(information technology，IT)人員也需要重新配置交換機、路由器并更新訪問控制列表(access control list，ACL)、虛擬局域網(wǎng)(virtual local area network，VLAN)和其他一些機制[1]。IP網(wǎng)絡(luò)最初設(shè)計的目標(biāo)只是為了實現(xiàn)端到端數(shù)據(jù)傳送，現(xiàn)在已經(jīng)很難滿足企業(yè)或用戶日益增加的復(fù)雜網(wǎng)絡(luò)需求。此外，在提供和管理包含多種技術(shù)的大型多供應(yīng)商網(wǎng)絡(luò)所涉及的運營成本也在不斷增加，而運營的收入?yún)s在減少。

為了解決上述問題，工業(yè)界提出了軟件定義聯(lián)網(wǎng)(software defined networking，SDN)的概念[2]。SDN是一種分離網(wǎng)絡(luò)控制與報文轉(zhuǎn)發(fā)功能的、動態(tài)、可適配的體系結(jié)構(gòu)[3]，這種邏輯集中式控制有助于網(wǎng)絡(luò)資源的統(tǒng)一管理與分配，而轉(zhuǎn)發(fā)層面只進行數(shù)據(jù)的轉(zhuǎn)發(fā)。編程人員能夠通過可編程接口實現(xiàn)對網(wǎng)絡(luò)設(shè)備的管理和網(wǎng)絡(luò)設(shè)備的報文轉(zhuǎn)發(fā)控制，通過這種更加方便靈活的網(wǎng)絡(luò)管理，從而達到簡化網(wǎng)絡(luò)運維、靈活管理調(diào)度的目標(biāo)。因此，研究新型的網(wǎng)絡(luò)架構(gòu)軟件定義聯(lián)網(wǎng)具有重要意義。

IP網(wǎng)絡(luò)報文在進行信息傳遞時會涉及到路由選擇的問題，為業(yè)務(wù)流選擇滿足QoS度量參數(shù)約束的路由一直是學(xué)術(shù)界和工業(yè)界研究的重點問題。IP網(wǎng)絡(luò)的路由協(xié)議(如RIP、OSPF)只針對跳數(shù)計算最短路由[4]，隨著業(yè)務(wù)對服務(wù)質(zhì)量(quality of service，QoS)[5]的要求越來越高，需要同時考慮多個QoS度量參數(shù)進行路由選擇。當(dāng)涉及到兩個及以上互相獨立的QoS度量參數(shù)的路由時，傳統(tǒng)網(wǎng)絡(luò)出現(xiàn)的問題主要有[6]：路由信息不準(zhǔn)確、算法復(fù)雜度高且選路效率較低，在分布式路由中還會產(chǎn)生回路問題。在具有集中式路由特點的SDN網(wǎng)絡(luò)中，控制器通過全局網(wǎng)絡(luò)拓?fù)錇闃I(yè)務(wù)流選擇路由，與IP網(wǎng)絡(luò)源路由不同的是，控制器能夠?qū)崟r收集鏈路信息，保證了鏈路信息的準(zhǔn)確性，為設(shè)計高效、快速的啟發(fā)式算法提供了有力保證。

文中通過SDN網(wǎng)絡(luò)控制器實時收集網(wǎng)絡(luò)資源，在此基礎(chǔ)上設(shè)計并實現(xiàn)了基于SDN網(wǎng)絡(luò)的QoS路由算法，并對算法的有效性進行了仿真測試。

1 相關(guān)技術(shù)分析

QoS路由[7]是指根據(jù)網(wǎng)絡(luò)中的可用資源和業(yè)務(wù)流對QoS的請求來決定流的路由的機制。QoS可用丟包率、延遲、延遲抖動、瓶頸帶寬等基本的性能指標(biāo)來描述。隨著IP網(wǎng)絡(luò)的發(fā)展，視頻會議、可視電話等多媒體業(yè)務(wù)不斷增加，這類實時業(yè)務(wù)需要足夠的帶寬以保證其服務(wù)質(zhì)量，因此，針對實時類業(yè)務(wù)流對帶寬提出的約束問題進行QoS路由算法的設(shè)計。

在IP網(wǎng)絡(luò)中，路由[8]一般由路由算法和路由協(xié)議構(gòu)成，而路由協(xié)議用來收集網(wǎng)絡(luò)狀態(tài)信息，從而為QoS路由算法提供必要的狀態(tài)信息。但是如果QoS路由算法[9]使用不準(zhǔn)確的路由信息，會嚴(yán)重?fù)p害QoS路由算法的性能。因此，IP網(wǎng)絡(luò)中期望在所有路由器維護最新的鏈路狀態(tài)信息，隨著網(wǎng)絡(luò)規(guī)模的增大，頻繁的鏈路狀態(tài)更新需要消耗大量的信令開銷。在SDN網(wǎng)絡(luò)中，OpenFlow協(xié)議可以主動或被動地收集鏈路狀態(tài)信息。文獻[10]即是利用控制器與交換機之間的packet-in和Flow-Removed消息被動地收集鏈路信息，雖然控制器與交換機之間的通信開銷較小，但是如果網(wǎng)絡(luò)中存在持續(xù)時間較大的流量時，該方法則無法提供準(zhǔn)確的鏈路信息。文獻[11]中的OpenSample使用sFlow采樣的方式收集基礎(chǔ)設(shè)施層的鏈路信息，但數(shù)據(jù)的準(zhǔn)確性受采樣率的限制，如果為了提高準(zhǔn)確率則同樣會增加網(wǎng)絡(luò)設(shè)備的CPU負(fù)載。為了能夠提供準(zhǔn)確的鏈路狀態(tài)信息，文中選擇OpenFlow協(xié)議以主動的方式采集鏈路狀態(tài)信息，即使用StatisticsRequest消息以輪詢的方式收集鏈路狀態(tài)信息。

針對多個QoS度量參數(shù)提出約束要求稱為多約束路徑(multi-constrained path，MCP)路由問題。在MCP問題中，每條鏈路對應(yīng)m個約束條件，一條滿足m個約束條件的路徑成為可行路徑，網(wǎng)絡(luò)拓?fù)渲锌赡艽嬖诙鄺l滿足約束條件的路徑，在多條可行路徑中選擇一條最小長度的路徑稱為多約束最優(yōu)路徑(multi-constrained optimal path，MCOP)問題。MCOP問題屬于NP難度問題，MCOP問題中典型的一個子問題為延遲約束代價最小問題(delay constrained least cost，DCLC)。為了降低算法復(fù)雜度，根據(jù)求解問題類型和求解方法，QoS路由算法可分為[12]：多項式非啟發(fā)類、偽多項式啟發(fā)類、探測類、限定QoS度量類、花費函數(shù)和概率求解類。

文獻[13]為了保證視頻的服務(wù)質(zhì)量，為業(yè)務(wù)流考慮了三個QoS度量參數(shù)，其中將延遲作為受限約束，將鏈路負(fù)載和延遲綜合成鏈路代價，針對這個受限最短路徑(restricted shortest path，RSP)問題采用拉格朗日松弛(Lagrangian relaxation)算法來為視頻流選擇QoS路由。文獻[14]只考慮鏈路剩余帶寬和延遲，將鏈路剩余帶寬作為鏈路代價，延遲作為約束條件進行選路，當(dāng)傳輸?shù)臉I(yè)務(wù)流對延遲比較敏感時，采用拉格朗日算法計算路由。當(dāng)傳輸?shù)氖菙?shù)據(jù)類非實時業(yè)務(wù)流時，其只考慮鏈路剩余帶寬，將鏈路剩余帶寬作為鏈路代價并使用Dijkstra算法實現(xiàn)業(yè)務(wù)流的QoS路由選擇。文獻[15]基于SDN技術(shù)提出的HiQoS系統(tǒng)引入了多路徑路由技術(shù)，其通過修改最短路徑路由算法，使其能夠計算滿足QoS度量參數(shù)約束的多條路徑并利用哈希表保存路徑，控制器以一定的周期檢查這些路徑的鏈路狀態(tài)，當(dāng)需要為業(yè)務(wù)流選擇路徑時，控制器根據(jù)帶寬使用情況和隊列狀態(tài)等選擇一條最優(yōu)的路徑給相應(yīng)的業(yè)務(wù)流。

2 問題分析與方案設(shè)計

(1)問題分析。

根據(jù)上一節(jié)對QoS度量參數(shù)收集、QoS路由算法的分析，可以看出IP網(wǎng)絡(luò)信息收集需要耗費大量的信令開銷來收集網(wǎng)絡(luò)狀態(tài)信息。當(dāng)網(wǎng)絡(luò)規(guī)模增大時，鏈路上的信令開銷也會呈現(xiàn)指數(shù)級增大，并且由于信令延遲問題導(dǎo)致鏈路信息不準(zhǔn)確，對QoS路由算法選路效率影響較大。因此，利用OpenFlow協(xié)議以主動的方式實時收集網(wǎng)絡(luò)鏈路狀態(tài)信息；此外，在IP網(wǎng)絡(luò)中QoS路由算法實現(xiàn)起來相對困難，算法復(fù)雜度較高，很難為業(yè)務(wù)流選擇端到端的QoS路由。而SDN網(wǎng)絡(luò)可以聚集出基礎(chǔ)設(shè)施層的網(wǎng)絡(luò)拓?fù)淝夷軌驅(qū)崟r收集鏈路狀態(tài)，控制器也可以提供集中式的路由服務(wù)。當(dāng)前SDN網(wǎng)絡(luò)中QoS路由方案是研究的熱點問題，因此針對業(yè)務(wù)流對帶寬提出的約束要求，設(shè)計了QoS路由算法以滿足業(yè)務(wù)流的QoS需求。

(2)基于SDN網(wǎng)絡(luò)的QoS路由方案。

基于SDN網(wǎng)絡(luò)的QoS路由方案的總體框架如圖1所示。

圖1 方案總體設(shè)計框架

該方案的設(shè)計依賴于SDN控制器提供的網(wǎng)絡(luò)基礎(chǔ)功能，如鏈路發(fā)現(xiàn)、拓?fù)涔芾?、流表下發(fā)等基礎(chǔ)功能，其中鏈路發(fā)現(xiàn)使用鏈路層發(fā)現(xiàn)協(xié)議(link layer discovery protocol，LLDP)實現(xiàn)底層網(wǎng)絡(luò)鏈路的發(fā)現(xiàn)與更新，拓?fù)涔芾碛糜跇?gòu)建SDN網(wǎng)絡(luò)的拓?fù)洳崟r更新網(wǎng)絡(luò)拓?fù)?，流表下發(fā)用于將路由策略下發(fā)給OpenFlow交換機。在此基礎(chǔ)上詳細闡述了QoS數(shù)據(jù)監(jiān)測方法、QoS路由算法，其中主要闡述了剩余帶寬監(jiān)測方法、基于Dijkstra的QoS路由算法，為業(yè)務(wù)流選擇滿足帶寬約束要求的QoS路由。

(3)QoS數(shù)據(jù)監(jiān)測設(shè)計。

QoS數(shù)據(jù)監(jiān)測是對鏈路上流量信息的收集以為QoS路由算法提供實時、準(zhǔn)確的鏈路狀態(tài)信息。在SDN網(wǎng)絡(luò)中能夠以被動方式或主動方式進行流量信息的收集。SDN網(wǎng)絡(luò)可以使用OpenFlow協(xié)議以主動的方式收集鏈路狀態(tài)信息，保證流量收集的準(zhǔn)確性。QoS數(shù)據(jù)監(jiān)測則是基于SDN網(wǎng)絡(luò)，主要用于剩余帶寬的收集?？刂破魍ㄟ^解析交換機發(fā)送的StatisticsReply消息獲取并解析端口流量的統(tǒng)計信息，通過不同時間端口接收字節(jié)數(shù)和發(fā)送字節(jié)數(shù)的不同來計算鏈路當(dāng)前流量占用的帶寬，最終通過端口最大帶寬減去端口當(dāng)前流量占用的帶寬得到鏈路剩余帶寬。

(4)QoS路由算法設(shè)計。

文中將帶寬作為QoS度量參數(shù)，主要考慮業(yè)務(wù)流對帶寬提出的約束要求，因此，將帶寬轉(zhuǎn)換為鏈路代價并用cij表示，Bij剩余表示鏈路ij的剩余帶寬，Bmin表示業(yè)務(wù)流提出的最小帶寬要求。剩余帶寬越大，越能滿足業(yè)務(wù)流的帶寬要求，如果剩余帶寬小于最小帶寬要求，則無法滿足業(yè)務(wù)流提出的帶寬約束要求。如果剩余帶寬Bij剩余大于業(yè)務(wù)流提出的帶寬約束Bmin，則此時鏈路代價cij的值為鏈路剩余帶寬與業(yè)務(wù)流提出約束要求帶寬的差值；如果剩余帶寬小于業(yè)務(wù)流提出的帶寬約束要求，此時鏈路代價為負(fù)無窮。通過以上鏈路代價的初始化，從而為業(yè)務(wù)流選路時滿足業(yè)務(wù)流對帶寬提出的約束要求。

網(wǎng)絡(luò)拓?fù)鋱D用G(N,A)來描述，其中N表示網(wǎng)絡(luò)中的節(jié)點集合，A表示網(wǎng)絡(luò)中的鏈路集合。Link(i,j)表示一條從節(jié)點i到節(jié)點j的有向鏈路。Pst表示從源節(jié)點s到目的節(jié)點t的所有滿足帶寬約束的可行路徑，對于其中的路徑P∈Pst，定義滿足帶寬約束的可行路徑P的總代價fC，為路徑P上每條鏈路代價的和。

基于以上的鏈路代價，使用Dijkstra算法為業(yè)務(wù)流選擇滿足帶寬約束要求且代價最大的路徑，算法的偽代碼如下所示：

Dijkstra(G,s,t,c)//在圖G中，s為源節(jié)點，t為目的節(jié)點，c為鏈路代價

任意的v屬于節(jié)點集合N，dist[v]:=-∞,prev:=null;//初始化總代價為負(fù)無窮，前驅(qū)節(jié)點為空

dist[s]:=0;//設(shè)置源節(jié)點的總代價為0

S:=Ф//S表示保留了已知的所有d[v]的值已經(jīng)是最大代價路徑的值的頂點,集合S初始狀態(tài)為空

Q:=N//Q保留了其他所有頂點，其初始狀態(tài)為圖G中所有的頂點集合N

while(Q:≠Ф)//當(dāng)節(jié)點集Q不為空時進行循環(huán)操作

u:=Extract_Max(Q)//Q中dist[u]最大的頂點并將u從Q中刪除

S.append(u)//將節(jié)點u加入到S集合中

if(u==t)end;//如果節(jié)點u為目的節(jié)點，算法結(jié)束

For each edge outgoing from u as (u,v)

alt=dist[u]+c(u,v);//遍歷u的所有相鄰節(jié)點v并計算總代價

if(alt>dist[v])//如果計算的總代價比原來代價大，則更新v的總代價

dist[v]=alt;//更新節(jié)點v的總代價

prev[v]=u;//更新v的前驅(qū)節(jié)點為u

end//算法結(jié)束

以上基于Dijkstra算法的QoS路由算法根據(jù)鏈路代價為業(yè)務(wù)流選擇QoS路由，而鏈路代價cij考慮到了業(yè)務(wù)流對帶寬的最小約束要求。此外，基于SDN網(wǎng)絡(luò)的QoS算法較IP網(wǎng)絡(luò)QoS路由算法的優(yōu)勢為數(shù)據(jù)平面交換機之間不需要信令開銷。相較于IP網(wǎng)絡(luò)QoS源路由，利用SDN控制器能夠?qū)崿F(xiàn)實時的鏈路狀態(tài)更新，聚集出有效的鏈路狀態(tài)信息而不會產(chǎn)生陳舊信息，選路效率較高；算法能夠基于聚集的鏈路狀態(tài)信息利用SDN控制器進行集中式路由。因此利用SDN網(wǎng)絡(luò)實現(xiàn)QoS路由選擇技術(shù)使算法具有易擴展、適應(yīng)不同網(wǎng)絡(luò)拓?fù)涞忍攸c。

3 方案實現(xiàn)

QoS路由選擇的實現(xiàn)主要基于開源控制器Floodlight，其中依賴于Floodlight控制器實現(xiàn)了鏈路發(fā)現(xiàn)模塊、拓?fù)涔芾砟K、流規(guī)則下發(fā)模塊。鏈路發(fā)現(xiàn)模塊實現(xiàn)了底層網(wǎng)絡(luò)鏈路的發(fā)現(xiàn)與更新，拓?fù)涔芾砟K實現(xiàn)了網(wǎng)絡(luò)拓?fù)涞臉?gòu)建及更新，流規(guī)則下發(fā)模塊實現(xiàn)了SDN網(wǎng)絡(luò)控制器將路由策略下發(fā)給OpenFlow交換機。而QoS數(shù)據(jù)監(jiān)測主要實現(xiàn)底層網(wǎng)絡(luò)剩余帶寬的收集。QoS路由算法主要實現(xiàn)業(yè)務(wù)流的QoS路由選擇。

(1)QoS數(shù)據(jù)監(jiān)測實現(xiàn)。

本節(jié)主要實現(xiàn)對剩余帶寬的監(jiān)測。基于Floodlight開源控制器設(shè)計了DataMonitor模塊，該模塊需要調(diào)用IFloodlightService、IFloodlightModule、IOFMessageListener提供的服務(wù)。其中IFloodlightService是Floodlight能夠提供服務(wù)的模塊的基本接口，IFloodlightModule定義了Floodlight能夠加載的模塊的接口。Floodlight控制器通過IOFMessageListener來監(jiān)聽OpenFlow消息。

DataMonitor模塊中的主要類和接口如下：

IDataMonitor接口為DataMonitor中的一個服務(wù)，繼承module模塊即Floodlight能夠提供服務(wù)的模塊的基本接口IFloodlightService，主要方法為getLink，用于計算剩余帶寬。通過IDataMonitorService接口向QoS路由模塊提供剩余帶寬信息。

DataMonitor類主要實現(xiàn)了剩余帶寬的計算，實現(xiàn)了IFloodlightModule、IOFMessageListener兩個接口中的getModuleServices、getServiceImpls等方法。IFloodlightModule標(biāo)識了DataMonitor模塊是Floodlight的一個模塊，在Floodlight啟動過程中，該類以模塊形式加載。IOFMessageListener接口用于監(jiān)聽Floodlight控制器與OpenFlow交換機之間的消息，如Packet-in、Flow-Mod、Stat-Reply等。DataMonitor類除了實現(xiàn)getLink方法以外，還實現(xiàn)了receive方法，其主要是對Stat_Reply消息的處理。方法Precess_stat_reply功能是對OpenFlow消息Stat_Reply進行處理，創(chuàng)建一個Flow_Table_Entry，并將這個流表項作為getLink方法的一個參數(shù)。

計算剩余帶寬的主要方法為getLink，在DataMonitor中實現(xiàn)。首先通過receive方法處理OpenFlow消息，然后通過Precess_stat_reply方法將統(tǒng)計的消息轉(zhuǎn)化成一個流表項供getLink方法使用。getLink方法通過獲取的當(dāng)前端口的狀態(tài)信息，計算出剩余帶寬。

(2)QoS路由算法實現(xiàn)。

QoS路由選擇的實現(xiàn)依賴于Floodlight控制器，首先在Eclipse中導(dǎo)入Floodlight源碼和依賴包，然后在Eclipse中創(chuàng)建QoS路由選擇模塊，之后在resources META-INF/services/net.Floodlight.core.module.IFloodlightModule中指定新增模塊名,添加模塊配置信息。文中路由計算模塊實現(xiàn)調(diào)用TopologyManager模塊類以實現(xiàn)全局網(wǎng)絡(luò)拓?fù)涞木S護，并且根據(jù)QoS數(shù)據(jù)監(jiān)測模塊提供的服務(wù)，為業(yè)務(wù)流選擇QoS路由；然后調(diào)用Floodlight控制器的Forwarding模塊給交換機安裝流表項，最終實現(xiàn)業(yè)務(wù)流的轉(zhuǎn)發(fā)。

下文對QoSRouting模塊各個接口及類進行說明，并重點闡述了與QoS路由算法實現(xiàn)相關(guān)的方法。

其中QoSRouting模塊主要的接口和類為：IFloodlightModule、MasterTopologyInstance類、TopologyManager類、IQoSRoutingService，各個類及接口之間的關(guān)系如圖2所示。

圖2 QoSRouting類及接口圖

圖中，DataMonitor類實現(xiàn)剩余帶寬的監(jiān)測，MasterTopologyInstance類實現(xiàn)QoS路由算法。其中IQoSRoutingService為Floodlight中其他模塊提供服務(wù)的接口，其中主要方法為getRoutes，F(xiàn)orwarding模塊可以通過該方法獲取QoS路由路徑。TopologyManager用于維護網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)。MasterTopologyInstance類為QoS路由模塊的核心類，完成路徑計算，其中主要方法為Path Dijkstra(Cluster c,Map>links,DatapathId src, DatapathId dst,Map linkCost)。通過源節(jié)點和目的節(jié)點以及鏈路代價來計算具有鏈路代價的路徑，其中Path類保存了所計算路徑的鏈路信息以及所計算出的代價，如Dijkstra算法中返回的Path類型，包含了路徑上的鏈路信息和這條路徑的總代價，Cluster表示OpenFlow交換機簇。

4 實驗環(huán)境搭建與結(jié)果分析

(1)測試環(huán)境。

采用Floodlight控制器與網(wǎng)絡(luò)仿真工具Mininet對QoS路由方案的有效性進行測試。首先使用java-jar target/floodlight .jar命令開啟改進后的Floodlight控制器，此時Floodlight根據(jù)其配置文件信息加載基本模塊，拓?fù)淠K、鏈路發(fā)現(xiàn)模塊在Floodlight控制器啟動即開始監(jiān)聽事件，但是此時Mininet并沒有開啟，F(xiàn)loodlight控制器的UI界面暫時沒有網(wǎng)絡(luò)設(shè)備。通過Mininet創(chuàng)建的自定義拓?fù)?，連接Floodlight控制器，鏈路發(fā)現(xiàn)模塊和拓?fù)涔芾砟K處理packetin消息構(gòu)建整個網(wǎng)絡(luò)的拓?fù)洹?/p>

實驗中涉及兩臺物理主機，在其中一臺物理主機(地址為192.168.1.110)上安裝Floodlight控制器作為控制層設(shè)備。在另一臺物理主機(地址為192.168.1.111)上安裝Mininet網(wǎng)絡(luò)仿真軟件，用來構(gòu)建網(wǎng)絡(luò)拓?fù)洹？刂茖雍徒粨Q層物理主機上運行的環(huán)境為ubuntu12.04，在Mininet上使用iperf網(wǎng)絡(luò)性能測試工具發(fā)送UDP數(shù)據(jù)包。實驗拓?fù)鋱D如圖3所示。使用Mininet自定義拓?fù)涔δ?，將鏈?s1,s5>,,上的帶寬設(shè)置為20 Mbits，其他交換機間鏈路帶寬設(shè)置為5 Mbits。

圖3 實驗拓?fù)鋱D

(2)測試步驟與結(jié)果分析。

根據(jù)實驗拓?fù)鋱D，設(shè)置業(yè)務(wù)流最小帶寬約束為6 Mbits，利用iperf網(wǎng)絡(luò)性能測試工具進行發(fā)送UDP報文的測試，以驗證算法的有效性。步驟如下：

①Mininet連接最短路算法的Floodlight控制器，通過Mininet的xterm命令打開h1和h3虛擬終端，以h1為iperf客戶端，h3為iperf服務(wù)端，h1通過如下命令向h3發(fā)送UDP報文：

iperf-c10.0.0.3-S0x10-u-i5-t30-b6M

通過Floodlight控制器的UI界面查看交換機的流表項可知，業(yè)務(wù)流的傳輸路徑為，并未考慮鏈路的任何代價，只進行最短路路由。

②啟動添加了QoS路由方案的Floodlight控制器，首先需要在floodlight.modules配置參數(shù)后添加QoSRouting模塊名，以讓模塊在Floodlight啟動時必須加載，然后再次運行Ant命令重新編譯版本，最后執(zhí)行floodlight.sh啟動Floodlight控制器。通過Mininet的xterm命令開啟h1和h3的虛擬終端，以h1為iperf客戶端，h3為iperf服務(wù)端，h1通過如下命令向h3發(fā)送UDP報文：

iperf-c10.0.0.3-S0x10-u-i5-t30-b6M

通過查看Floodlight控制器的UI界面中的交換機流表項，分析UDP報文的轉(zhuǎn)發(fā)路徑為，部分交換機的流表項如圖4所示。

圖4 s5交換機部分流表項

由自定義拓?fù)渲墟溌返膸挔顟B(tài)可知，最短路路徑和次短路路徑的鏈路帶寬無法滿足業(yè)務(wù)流的最小帶寬約束要求，而對于路徑的鏈路能夠滿足業(yè)務(wù)流的帶寬約束要求，QoS路由算法能夠選擇剩余帶寬較大的路徑。

5 結(jié)束語

基于SDN網(wǎng)絡(luò)設(shè)計了QoS路由選擇方案，利用OpenFlow協(xié)議收集網(wǎng)絡(luò)狀態(tài)信息，根據(jù)SDN控制器的集中控制優(yōu)勢，設(shè)計并實現(xiàn)了QoS路由算法，為有QoS要求的業(yè)務(wù)流選擇QoS路由，最后對該方案進行了測試。結(jié)果驗證了QoS路由算法的有效性。接下來的工作將對算法滿足帶寬約束進行更深入的測試，并且利用SDN網(wǎng)絡(luò)控制器的集中控制優(yōu)勢，通過合理的資源分配滿足業(yè)務(wù)流服務(wù)質(zhì)量要求。

[1] 左青云,陳 鳴,趙廣松,等.基于OpenFlow的SDN技術(shù)研究[J].軟件學(xué)報,2013,24(5):1078-1097.

[2] Open Networking Foundation.Software-defined networking:the new norm for networks[EB/OL].2012-04-01.https://www.opennetworking.org/sdn-resources/sdn-library/whitepapers.

[3] 沈蘇彬.軟件定義聯(lián)網(wǎng)的建模與分析[J].南京郵電大學(xué)學(xué)報:自然科學(xué)版,2014,34(3):1-9.

[4] 林玉俠,朱慧玲,馬正新,等.QoS路由度量參數(shù)的選擇問

題研究[J].電信科學(xué),2003,19(7):22-27.

[5] 楊勝文,史美林.一種支持QoS約束的Web服務(wù)發(fā)現(xiàn)模型[J].計算機學(xué)報,2005,28(4):589-594.

[6] KUIPERS F A.Quality of service routing in the internet:theory,complexity and algorithms[M].[s.l.]:IOS Publisher,2004.

[7] 朱慧玲,杭大明,馬正新,等.QoS路由選擇:問題與解決方法綜述[J].電子學(xué)報,2003,31(1):109-116.

[8] 閔應(yīng)驊.計算機網(wǎng)絡(luò)路由研究綜述[J].計算機學(xué)報,2003,26(6):641-649.

[9] MASIP-BRUIN X,YANNUZZI M,DOMINGO-PASCUAL J,et al.Research challenges in QoS routing[J].Computer Communications,2006,29(5):563-581.

[10] YU C,LUMEZANU C,ZHANG Y,et al.FlowSense:monitoring network utilization with zero measurement cost[C]//International conference on passive and active network measurement.Berlin:Springer,2013:31-41.

[11] SUH J,KWON T T,DIXON C,et al.OpenSample:a low-latency,sampling-based measurement platform for commodity SDN[C]//International conference on distributed computing systems.Madrid,Spain:IEEE,2014:228-237.

[12] 崔 勇,吳建平,徐 恪,等.互聯(lián)網(wǎng)絡(luò)服務(wù)質(zhì)量路由算法研究綜述[J].軟件學(xué)報,2002,13(11):2065-2075.

[13] EGILMEZ H E,DANE S T,BAGCI K T,et al.OpenQoS:An OpenFlow controller design for multimedia delivery with end-to-end quality of service over software-defined networks[C]//Signal & information processing association summit and conference.Hollywood,California,USA:IEEE,2012.

[14] CUI H Y,ZHU Y,YAO Y,et al.Design of intelligent capabilities in SDN[C]//International conference on wireless communications,vehicular technology,information theory and aerospace & electronic systems.Aalborg,Denmark:[s.n.],2014:1-5.

[15] YAN Jinyao,ZHANG Hailong,SHUAI Qianjun.HiQoS:an SDN-based multipath QoS solution[J].China Communications,2015,12(5):123-133.