唐文萱 劉星宇 楊雪芹 梁勇
摘要:隨著互聯(lián)網(wǎng)視頻組播業(yè)務(wù)需求以及結(jié)合SDN網(wǎng)絡(luò)的優(yōu)越性,設(shè)計(jì)并仿真了面向SDN網(wǎng)絡(luò)視頻組播系統(tǒng)。本系統(tǒng)采用模塊化設(shè)計(jì)思想,并結(jié)合一種跳數(shù)、帶寬和鏈路狀態(tài)相結(jié)合的組播路由控制策略,實(shí)現(xiàn)了系統(tǒng)的組播系統(tǒng)模塊的搭建過程以及視頻流媒體的播放過程。最后驗(yàn)證組播路由控制策略和SDN在視頻組播系統(tǒng)上的結(jié)合,不僅能夠提高系統(tǒng)組播的流暢性和穩(wěn)定性,而且也克服由于網(wǎng)絡(luò)擁塞、丟包等原因造成的視頻通信效果不穩(wěn)定的問題。
Abstract: With the demand of Internet video multicast service and the superiority of SDN network, SDN network video multicast system is designed and simulated. This system adopts modular design idea, and combines a multicast routing control strategy that combines the number of jumps, bandwidth, and link state, and realizes the construction process of the multicast system module and the video streaming media playback process. Finally, the combination of multicast routing control strategy and SDN on video multicast system can not only improve the fluency and stability of system multicast, but also overcome the instability of video communication due to network congestion and packet loss.
關(guān)鍵詞:SDN;Ryu控制器;流媒體;組播;路由選擇
Key words: SDN;Ryu controller;streaming media;multicast;routing selection
中圖分類號:TP393.1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 文獻(xiàn)標(biāo)識碼:A ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?文章編號:1006-4311(2019)23-0234-04
0 ?引言
多媒體業(yè)務(wù)的快速普及使網(wǎng)絡(luò)中視頻應(yīng)用的數(shù)量呈爆炸性增長,視頻通信正成為多媒體業(yè)務(wù)中發(fā)展最為迅速的領(lǐng)域。隨著新興的網(wǎng)絡(luò)架構(gòu)軟件定義網(wǎng)絡(luò)(SDN)的出現(xiàn),在SDN網(wǎng)絡(luò)架構(gòu)下有許多以高帶寬網(wǎng)絡(luò)資源為需求的多媒體業(yè)務(wù),這就需要SDN網(wǎng)絡(luò)中能提供組播業(yè)務(wù),解決傳統(tǒng)IP挽留過由于網(wǎng)絡(luò)擁塞、丟包等原因造成的視頻通信效果不穩(wěn)定的問題。
SDN架構(gòu)為視頻組播提供的許多優(yōu)勢,目前已經(jīng)有了很多基于SDN的組播相關(guān)研究。如向熊研究在組播中實(shí)現(xiàn)基于流量的負(fù)載均衡,來避免鏈路擁塞;高強(qiáng)研究在控制層支持路由動態(tài)選擇,來達(dá)到明顯提升分層視頻流媒體傳輸質(zhì)量的效果。陳亮研究設(shè)計(jì)具備IP組播功能的控制器,來生成多棵組播樹;張凱琳研究利用SDN中SVC組播實(shí)現(xiàn)的視頻會議架構(gòu),來滿足不同終端設(shè)備對于視頻會議系統(tǒng)的需求;這些文獻(xiàn)研究雖然是基于SDN網(wǎng)絡(luò),但都是考慮影響組播路由的單一參數(shù),并沒有綜合考慮多個(gè)因素(如組播的路由的跳數(shù)、時(shí)延、帶寬、負(fù)載均衡等),文章是根據(jù)SDN架構(gòu)特點(diǎn),設(shè)計(jì)并實(shí)現(xiàn)SDN網(wǎng)絡(luò)視頻組播系統(tǒng),采用了跳數(shù)、帶寬和鏈路狀態(tài)相結(jié)合的路由控制策略,實(shí)現(xiàn)系統(tǒng)的多個(gè)模塊,并通過視頻播放效果驗(yàn)證了該系統(tǒng)能克服的由于網(wǎng)絡(luò)擁塞、丟包等原因造成的視頻通信效果不穩(wěn)定的問題。
1 ?SDN的架構(gòu)
SDN的核心思想在于轉(zhuǎn)發(fā)平面與控制平面的分離,不再將紛繁復(fù)雜的軟件代碼與網(wǎng)絡(luò)硬件設(shè)備綁定,取而代之的是集中控制,網(wǎng)絡(luò)硬件設(shè)備只完成接收控制器指令并根據(jù)要求進(jìn)行轉(zhuǎn)發(fā)的工作,從而達(dá)到控制器在上層視角,對網(wǎng)絡(luò)進(jìn)行全局性控制的目的?;镜腟DN 的三層式模型自下而上分別為設(shè)備層、控制層和應(yīng)用層,如圖1所示。
2 ?面向SDN網(wǎng)絡(luò)視頻組播系統(tǒng)設(shè)計(jì)
2.1 SDN視頻組播系統(tǒng)架構(gòu)設(shè)計(jì)
對應(yīng)于SDN三層架構(gòu),基于SDN實(shí)現(xiàn)的流媒體組播系統(tǒng)架構(gòu)如圖2所示,也分為三層,第一層設(shè)備層是基礎(chǔ)的網(wǎng)絡(luò)轉(zhuǎn)發(fā)設(shè)備,如OVS交換機(jī)、可以作為客戶端(組播成員)的虛擬用戶主機(jī)以及可以作為視頻服務(wù)器(組播源)的虛擬主機(jī);第二層控制層是一個(gè)Ryu控制器,它提供與下層設(shè)備層和上層應(yīng)用層進(jìn)行通信的南向接口和北向接口;第三層應(yīng)用層,主要包括了要實(shí)現(xiàn)路由功能的最重要的兩個(gè)部分,組播管理程序以及根據(jù)實(shí)際需求給出的路由控制策略,并將這個(gè)策略用于組播網(wǎng)絡(luò)設(shè)備上,實(shí)現(xiàn)對整個(gè)網(wǎng)絡(luò)路由的控制。
在圖2中,具體的視頻組播系統(tǒng)架構(gòu)模塊完成功能如下:
①控制器:本組播系統(tǒng)選擇使用開源控制器Ryu作為控制層設(shè)備,RYU控制器作為整個(gè)系統(tǒng)的控制中心,完成組成員管理、信息維護(hù)、流表下發(fā)、組表下發(fā)、路由策略通知下發(fā)等工作。同時(shí)通過北向接口向應(yīng)用層調(diào)用兩個(gè)主要組播管理程序(igmplib管理庫[15])以及組播路由控制策略,組播管理程序提供實(shí)現(xiàn)組播所需要的組表管理、流表管理、組管理、組成員管理等功能,并進(jìn)行流媒體傳輸,而組播路由控制策略是所有組播內(nèi)的成員按照此策略進(jìn)行路由選擇。
②交換機(jī):交換機(jī)指支持Openflow1.3版本協(xié)議的OVS交換機(jī)。交換機(jī)與上層Ryu控制器直接通過Openflow協(xié)議進(jìn)行下發(fā)流表項(xiàng)與組表項(xiàng)信息,所有的信息管理全部在控制層中完成,OVS交換機(jī)負(fù)責(zé)接收并按照要求進(jìn)行數(shù)據(jù)轉(zhuǎn)發(fā)即可。
③設(shè)備層:主要有視頻服務(wù)器(組播源)和客戶端(組播組成員),在視頻發(fā)送端,利用VLC播放器制作用于網(wǎng)絡(luò)流媒體數(shù)據(jù)。當(dāng)一個(gè)客戶端(組播成員)想要加入進(jìn)本次組播組內(nèi)時(shí),需要程序加入組播地址。
2.2 SDN視頻組播系統(tǒng)模塊功能設(shè)計(jì)
根據(jù)圖2中SDN視頻組播系統(tǒng)架構(gòu)和功能,本文采用模塊化方法,將系統(tǒng)分為組播網(wǎng)絡(luò)拓?fù)淠K、組播管理模塊、路由控制策略模塊、視頻傳輸發(fā)送和接收模塊以及控制器監(jiān)控模塊。
2.2.1 系統(tǒng)網(wǎng)絡(luò)拓?fù)淠K設(shè)計(jì)
首先通過Mininet建立實(shí)現(xiàn)組播系統(tǒng)的網(wǎng)絡(luò)拓?fù)淙鐖D3所示,其中 c0為Ryu控制器,s1-s10是三層結(jié)構(gòu),s1-s2為核心交換機(jī),s3-s6為匯聚交換機(jī),s7-s10為邊緣交換機(jī),均為OVS交換機(jī),h1-h8是8個(gè)虛擬主機(jī),虛擬主機(jī)h1為視頻播放源,h2-h8為組播組內(nèi)成員, h3、h6、h8作為用戶依次加入組播組,從視頻服務(wù)器h1獲取視頻流媒體的傳輸。
2.2.2 系統(tǒng)組播管理模塊設(shè)計(jì)
本系統(tǒng)的控制器是Ryu,而igmplib庫是由Ryu研發(fā)公司開發(fā)的一款組播管理庫,主要完成組管理、組成員管理、流表管理等組播功能。
系統(tǒng)在igmplib庫的組管理的流表項(xiàng)的進(jìn)行設(shè)置,當(dāng)有主機(jī)在加入組播組時(shí)會發(fā)送report消息,離開組的時(shí)候會發(fā)送leave消息。一旦控制器收到report消息后,首先把接口加入到組里面,如果是第一次收到report消息就會下發(fā)流表項(xiàng)和組表項(xiàng);如果在收到leave消息之后,因?yàn)椴荒艽_定是否有組成員連接到這個(gè)交換機(jī),所以對流表項(xiàng)和組表項(xiàng)的操作查詢組成員接口,先刪除或者修改相關(guān)接口的流表項(xiàng),然后修改或者刪除現(xiàn)有組表項(xiàng)。如果igmplib庫組管理的流表項(xiàng)設(shè)置成功,控制器直接可以通過app調(diào)用。
2.2.3 組播路由控制模塊設(shè)計(jì)
應(yīng)用層的組播路由控制模塊是設(shè)計(jì)組播路由選擇算法。本系統(tǒng)采用帶寬、跳數(shù)和鏈路狀態(tài)綜合考慮的策略,組播路由控制的基本思想是,假如有一個(gè)數(shù)據(jù)流需要從S1交換機(jī)發(fā)送到S2交換機(jī),首先在路徑空閑的狀態(tài)下,選取所有可能的達(dá)到路徑n條;接著,在所有的路徑下選取可能最小跳數(shù)的路徑,最后計(jì)算每一條最小跳數(shù)路徑的最小帶寬,然后比較路徑的最小帶寬的最大值,選取最大的帶寬的路徑進(jìn)行數(shù)據(jù)傳輸,同時(shí)這條路徑標(biāo)注為忙,并記錄到網(wǎng)絡(luò)拓?fù)湟晥D表。如果選取的路徑標(biāo)狀態(tài)為忙,則選取狀態(tài)為空閑的次優(yōu)路徑。
如圖4中S1到S2交換機(jī)的可能路徑為上、中、下三條,上路為3跳,每跳帶寬為2,5,8;中路為4跳,每跳帶寬為3,4,6,3;下路為3跳,每跳帶寬為4,5,6;先選取最短跳數(shù)的路徑上路和下路;接著選取最短路徑中最小帶寬值,即就是上路和下路的每一段帶寬的最小值,上路為2,下路為4;比較最小帶寬的最大值,上路為2小于下路的4,所以選出路徑為下路,同時(shí)標(biāo)注所選取路徑的狀態(tài)為1,并記錄到網(wǎng)絡(luò)拓?fù)湟晥D中。
2.2.4 視頻傳輸發(fā)送和接收模塊
①視頻服務(wù)器(組播源)。在視頻發(fā)送端,利用VLC播放器制作用于網(wǎng)絡(luò)流媒體數(shù)據(jù),同時(shí)在視頻發(fā)送端程序中,設(shè)置了IP網(wǎng)關(guān)地址(10.0.0.X),本系統(tǒng)SDN實(shí)現(xiàn)組播采用原IP網(wǎng)絡(luò)的D類組播地址,設(shè)置為224.1.1.1,進(jìn)程端口號為1234,同時(shí)設(shè)置發(fā)送視頻的屬性。
②客戶端(組播組成員)。當(dāng)一個(gè)客戶端(組播成員)想要加入進(jìn)本組播組時(shí),在該主機(jī)的終端接收端文件中只需指明其想要加入的組播地址和端口號224.1.1.1:1234。
2.2.5 控制器監(jiān)控模塊
前4個(gè)模塊設(shè)計(jì)好之后,組播客戶端也能正常播放視頻,那么可以通過Ryu控制器端查看組播測試結(jié)果,不僅包括組播成員的加入,組播成員的變化情況,組播成員的離開等信息,而且還能查看中間交換機(jī)的流表項(xiàng)的狀態(tài)以及行為。
3 ?SDN視頻組播系統(tǒng)實(shí)現(xiàn)步驟
文章的仿真環(huán)境采用的是仿真軟件為Mininet(用來模擬網(wǎng)絡(luò)拓?fù)洌?、Ryu(控制器)和Python語言,同時(shí)在Ryu控制器中用igmplib庫來實(shí)現(xiàn)組播,并進(jìn)行流媒體傳輸。根據(jù)設(shè)計(jì)的5個(gè)功能模塊,SDN視頻組播系統(tǒng)實(shí)現(xiàn)按照啟動控制器、啟動拓?fù)渚W(wǎng)絡(luò)(設(shè)備層各基礎(chǔ)網(wǎng)絡(luò)設(shè)備)、啟動組播源服務(wù)器、啟動客戶端接收、系統(tǒng)視頻播放結(jié)果以及控制器的監(jiān)控的步驟進(jìn)行,如圖5所示。
3.1 啟動控制器組播模塊
開啟Ryu控制器時(shí)控制器終端的進(jìn)程如圖6所示,其中第1行multiple.py為組播路由控制策略模塊算法(路由算法的調(diào)用函數(shù)已寫進(jìn)multiple.py,啟動時(shí)一并開啟),第2行ryu.controller.ofp_handler代表正在加載負(fù)責(zé)處理交換機(jī)管理以及基礎(chǔ)的Openflow事件管理的線程,例如下發(fā)流表、組表以及上下層信息通信的實(shí)現(xiàn)就依賴于這個(gè)進(jìn)程。緊接著的兩行代表已經(jīng)可以使用igmplib庫,后兩行代表著加載的前兩個(gè)進(jìn)程已經(jīng)加載完畢。此時(shí)只是控制器開啟了,還并未連通圖3系統(tǒng)拓?fù)渚W(wǎng)絡(luò)(未連通設(shè)備層)。
3.2 啟動拓?fù)渚W(wǎng)絡(luò)
啟動圖3設(shè)計(jì)的拓?fù)渚W(wǎng)絡(luò)時(shí),Mininet的終端顯示內(nèi)容如圖7所示,其中通過Adding controller、Adding host、Adding switches、Adding link的形式表現(xiàn)拓?fù)?。其中的h1-h8為主機(jī)信息,s1-s10為交換機(jī)信息,(h1,s7)…(s8,s4)為鏈路連接信息,c0代表啟動控制器c0,Starting CLI出現(xiàn)以后可以進(jìn)行命令行操作。
3.3 連通拓?fù)渚W(wǎng)絡(luò)
針對圖3的網(wǎng)絡(luò)拓?fù)鋱D,圖8的交換機(jī)與控制器之間已經(jīng)連通,控制器終端信息更新,c0為Ryu控制器,s1-s10為OVS交換機(jī),h1-h8是虛擬主機(jī)。其中顯示交換機(jī)s1-s10已連接(例如Switch 1 connected!),并開始產(chǎn)生正常的query問詢行為。
3.4 組播源發(fā)送和客戶端接收
接下來是組播源發(fā)送和客戶端接收,本系統(tǒng)選取主機(jī)h1作為組播源,則在h1的終端,發(fā)送視頻流過程如圖9所示。首先設(shè)置了網(wǎng)關(guān),隨后的內(nèi)容是生成流媒體的控制代碼,其中sout意為串行輸出,vcodec=h264是視頻轉(zhuǎn)碼要求,acodec=mpga為音頻轉(zhuǎn)碼要求,字符串長度128,采用雙工通信方式,采樣頻率為44100Hz,sout-keep代表持續(xù)性串流傳輸。h3、h6、h8加入組播組進(jìn)行接收如圖10所示,只需把D類地址224.1.1.1:1234加入組播組即可。
3.5 系統(tǒng)視頻播放結(jié)果
若組播源為h1,客戶端h3、h6、h8需要加入組播組,h3、h6、h8接收到視頻的畫面如圖11和圖12所示。
圖11中組播源h1是黑屏、沒有圖像和聲音,是因?yàn)榻M播源視頻文件在源端被采樣、壓縮、編碼而變成數(shù)據(jù)包流,所以在源端的視頻文件是已經(jīng)經(jīng)過處理的,因而無法播放;圖11黃色方框①處,因?yàn)樵炊藫碛型暾牧髅襟w文件,因此在源端有視頻總時(shí)長,并可以顯示進(jìn)度條;而在方框②處,接收端因?yàn)槭菍?shí)時(shí)流式接收,并不能得知視頻的總時(shí)長,所以并沒有進(jìn)度顯示;在方框③處,客戶端通過D類組播地址加入組播組,h8的視頻播放器標(biāo)題抬頭即為組播組地址以及相應(yīng)進(jìn)程端口號。
圖12是當(dāng)h1作為組播源,每隔一段時(shí)間分別有一個(gè)、兩個(gè)、三個(gè)客戶端加入組播組時(shí),整個(gè)視頻播放流暢,網(wǎng)絡(luò)穩(wěn)定性高。這是因?yàn)榛赟DN網(wǎng)絡(luò),不會隨著客戶端的增多影響播放效果。同時(shí),通過圖12的播放進(jìn)度表明,源端h1播放進(jìn)度都不會由其成員加入的時(shí)間早晚決定,而是不論何時(shí)加入的組播組,都是以組播源的播放進(jìn)度為準(zhǔn)。這就是實(shí)時(shí)流媒體傳輸。
由此可見實(shí)時(shí)流媒體傳播時(shí),客戶端的接收具有實(shí)時(shí)性,當(dāng)前接收的數(shù)據(jù)流不會因?yàn)槌蓡T新加入而從頭開始播放,始終以組播源的播放情況為準(zhǔn)。
3.6 控制器監(jiān)控信息
在實(shí)現(xiàn)組播的過程中,在控制器的終端不僅可以查看組播測試結(jié)果,而且可以看到組成員的信息變更如圖13所示,其中第1行為有新成員加入(Added),加入的地址為224.1.1.1,首次收到該信息,組播組成員數(shù)量暫時(shí)不明確,hosts[ ]為空;第2行為組播組成員變動,有新成員加入,加入的地址為224.1.1.1,首次收到該信息,目前組播組成員為3個(gè)(不包括組播源),hosts[3]為3;第3行為組播組成員變動,有組內(nèi)成員離開(removed),離開的地址為224.1.1.1,首次收到該信息,目前組播組成員數(shù)量有待于確定,hosts[ ]為空;第4行為問詢網(wǎng)絡(luò)鏈路狀況,交換機(jī)s2的第3端口報(bào)告IGMP報(bào)文信息并被控制器接收成功;第5行為問詢網(wǎng)絡(luò)鏈路狀況,控制器向交換機(jī)的第2端口下發(fā)問詢消息并被交換機(jī)接收成功。至此整個(gè)面向SDN網(wǎng)絡(luò)的視頻組播系統(tǒng)仿真完成。
4 ?結(jié)論
本文研究面向SDN網(wǎng)絡(luò)視頻組播系統(tǒng)的設(shè)計(jì)與仿真,闡述了該系統(tǒng)的設(shè)計(jì)思想,模塊組成,同時(shí),結(jié)合一種跳數(shù)、帶寬和鏈路狀態(tài)相結(jié)合的路由控制策略,最終展現(xiàn)了該系統(tǒng)搭建的過程以及最終的演示效果。該系統(tǒng)驗(yàn)證了路由控制策略和SDN在視頻組播系統(tǒng)上的結(jié)合,能夠提高整個(gè)系統(tǒng)組播播放流暢度和網(wǎng)絡(luò)穩(wěn)定性,而且也克服由于網(wǎng)絡(luò)擁塞、丟包等原因造成的視頻通信效果不穩(wěn)定的問題。
參考文獻(xiàn):
[1]黎亮,王彥昱,黎明.SDN分層組播視頻會議系統(tǒng)的實(shí)現(xiàn)與技術(shù)分析[J].通訊世界,2019,26(03):229-230.
[2]向熊.基于SDN網(wǎng)絡(luò)的流媒體阻比實(shí)現(xiàn)[J].信息技術(shù),2018(10):121-125.
[3]陳量,瞿輝.基于SDN思路的組播實(shí)現(xiàn)[J].微處理機(jī),2016,37(02):31-36,40.
[4]尤子揚(yáng).P2P流媒體視頻點(diǎn)播系統(tǒng)設(shè)計(jì)和研究[D].蘭州理工大學(xué),2017.
[5]謝永斌,張宸.基于SDN的IP組播研究[J].信息通信,2015(02):202-203.
[6]高永順.面向SDN網(wǎng)絡(luò)組播路由問題研究[D].西南交通大學(xué),2017.
[7]孫超.軟件定義網(wǎng)絡(luò)中流媒體QoE控制技術(shù)研究[D].山東大學(xué),2018.