靳鵬飛 李 俊 吳海博 智 江
(*中國科學院計算機網(wǎng)絡信息中心 北京 100190) (**中國科學院大學 北京 100049)
?
基于訂閱推送的NDN實時通信機制①
靳鵬飛②***李 ?、?吳海博*智 江***
(*中國科學院計算機網(wǎng)絡信息中心 北京 100190) (**中國科學院大學 北京 100049)
研究了代表未來互聯(lián)網(wǎng)體系結構發(fā)展方向的命名數(shù)據(jù)網(wǎng)絡(NDN)的實時通信機制。研究發(fā)現(xiàn),NDN用戶通過發(fā)送請求包(Interest)獲得對應數(shù)據(jù)(Data),而對于實時通信類應用(如即時聊天、物聯(lián)網(wǎng)監(jiān)控等),由于數(shù)據(jù)源的數(shù)據(jù)產(chǎn)生存在突發(fā)性和隨機性,而且存在數(shù)據(jù)接收時延,傳統(tǒng)NDN用戶驅(qū)動的“拉”模式數(shù)據(jù)獲取方式,難以實現(xiàn)用戶請求速率與數(shù)據(jù)產(chǎn)生速率的同步,無法滿足實時通信應用需求。從減小數(shù)據(jù)接收延遲出發(fā),在不改變原NDN路由緩存機制的基礎上提出了一種基于訂閱推送的NDN實時通信機制,該機制通過提前在路由器中添加訂閱信息,實現(xiàn)實時數(shù)據(jù)源的即時推送。相關理論分析和仿真實驗表明,該機制在實時數(shù)據(jù)接收延遲上明顯優(yōu)于傳統(tǒng)NDN方法。
命名數(shù)據(jù)網(wǎng)絡(NDN), 實時通信, 訂閱, 推送
隨著互聯(lián)網(wǎng)的發(fā)展,現(xiàn)有TCP/IP通信模式面臨諸多問題[1],以命名數(shù)據(jù)網(wǎng)絡(named data networking, NDN)[2]為代表的未來網(wǎng)絡體系結構已得到學術界的廣泛關注和研究[3-5]。NDN以命名數(shù)據(jù)為中心,用戶只需關注信息(內(nèi)容)本身,而不必關注信息的來源,從而使網(wǎng)絡通信模式與應用需求相適應。對于實時通信類應用,由于數(shù)據(jù)源的數(shù)據(jù)產(chǎn)生存在突發(fā)性和隨機性,現(xiàn)有NDN方案難以很好地滿足實時通信需求。NDN即時通信研究[6,7]均討論了NDN下如何實現(xiàn)即時通信,最終NDN項目應用團隊設計了同步通信組件[8]。通信多方通過該組件周期性交換本地消息摘要實現(xiàn)最新消息的同步,當發(fā)現(xiàn)有消息更新后發(fā)送對應的請求包獲取相應實時數(shù)據(jù)。該方式可以保證消息傳輸?shù)目煽啃?,但是增加了?shù)據(jù)接收延時。對于物聯(lián)網(wǎng)傳感器數(shù)據(jù)傳輸、緊急報警通知等應用,其對網(wǎng)絡延遲敏感,基于請求者“拉”模式的通信無法滿足應用的需求。Carzaniga等人強調(diào)網(wǎng)絡中存在兩種應用通信模式[9],即內(nèi)容分發(fā)類應用和消息通知類應用,并提出了一種結合內(nèi)容中心網(wǎng)絡(content-centric networking, CCN)[10](content-centric networking,與NDN機制相同但所屬研究機構不同)和IP的解決方案,該方案在一定程度上解決了CCN中消息推送的問題,但在一定程度上增加了路由、安全等方面設計和管理的復雜性,此外該方案對于實時通信應用沒有很好利用命名數(shù)據(jù)網(wǎng)絡(NDN)設計思想中天然多播和網(wǎng)內(nèi)緩存的優(yōu)勢。Fran?ois等人[11]提出了一種消息推送機制,它將推送數(shù)據(jù)放在請求包中,直接查找轉發(fā)信息庫(forwarding information base,F(xiàn)IB)將消息推送出去。這種設計需要對CCN轉發(fā)模塊進行修改,對于推送數(shù)據(jù)量大的消息,內(nèi)容封裝在請求包中將變得不再可取。
本文在原NDN框架基礎上,提出了一種基于訂閱推送的實時通信傳輸機制,該機制通過擴展NDN包格式,利用Interest包攜帶訂閱信息,在不影響原有通信模式的前提下,在路由器中添加訂閱記錄表記錄訂閱信息,支持實時數(shù)據(jù)源數(shù)據(jù)的推送,減小數(shù)據(jù)接收延遲。本方案具有實現(xiàn)簡單,傳輸高效,易擴展等優(yōu)點。通過ndnSIM[12]仿真平臺驗證,該方案對于實時通信應用、數(shù)據(jù)接收延遲明顯優(yōu)于基于原NDN機制的設計。
NDN傳輸?shù)暮诵氖敲麛?shù)據(jù)對象,數(shù)據(jù)的標識采用特定的名字。NDN中有兩種類型的包:請求(Interest)包和數(shù)據(jù)(Data)包。數(shù)據(jù)請求者通過發(fā)送Interest包向數(shù)據(jù)產(chǎn)生(或擁有)者請求特定名字的數(shù)據(jù)。而數(shù)據(jù)產(chǎn)生(或擁有)者回復帶有相應名字的Data包。
NDN路由器為實現(xiàn)包的轉發(fā),需要維護3張表[2,13]:轉發(fā)信息庫(FIB)、待定Interest表(pendinginterest table,PIT)、緩存(content store,CS)。Interest包的轉發(fā)需要查找FIB表,F(xiàn)IB條目的維護由NDN路由協(xié)議[14,15]溝通實現(xiàn)。在路由器轉發(fā)Interest包前,需將Interest包的名字和入端口號記入PIT中,以便路由器收到對應Data包時,查找PIT并從相應端口轉發(fā)。在執(zhí)行完Data包轉發(fā)后,路由器會將該PIT表項刪除。因此,如果請求者沒有發(fā)送Interest包,數(shù)據(jù)源推送的數(shù)據(jù)因在PIT中無法找到匹配表項而被丟棄,從而防止惡意數(shù)據(jù)的推送。當多個用戶請求相同的內(nèi)容時,PIT會在同一條目下記錄多個端口,在Data包轉發(fā)時,以此實現(xiàn)類似多播的效果。CS用于有策略的緩存路由器收到的Data包,當其它用戶再次請求該數(shù)據(jù)時,路由器可以直接對其進行回復,從而減輕內(nèi)容源以及網(wǎng)絡傳輸?shù)呢摀?/p>
對于實時通信而言,數(shù)據(jù)的傳輸是由數(shù)據(jù)源驅(qū)動的。當數(shù)據(jù)源有數(shù)據(jù)產(chǎn)生時應該主動將數(shù)據(jù)推送給對應用戶。采用訂閱的方式具有兩個好處:(1)可以標識數(shù)據(jù)源應該將數(shù)據(jù)推送給哪些用戶;(2)如果用戶沒有進行訂閱,數(shù)據(jù)源不能主動將消息推送出去,即推送數(shù)據(jù)的傳輸與否由用戶決定。
該方案在兼容原有通信模式的前提下,通過擴展NDN包格式,利用Interest包攜帶訂閱信息,在路由器中添加訂閱記錄表記錄用戶訂閱信息,當實時數(shù)據(jù)源有新消息產(chǎn)生時,查找訂閱記錄表,將消息推送給訂閱用戶,減小實時應用數(shù)據(jù)接收延遲。
2.1 包格式擴展
如Carzaniga等人[9]所述,網(wǎng)絡通信中既有內(nèi)容分發(fā)為主的應用,又有實時通信類應用的存在,為支持這兩種通信模式的并存,方案設計通過擴展包格式增加類型字段對兩種應用進行區(qū)分。其中Interest包類型為三種,即原有普通Interest包、訂閱Interest包及取消訂閱Interest包。Data包也有三種,即普通類型、對訂閱Interest包的回復及推送數(shù)據(jù)。此外由于實時應用數(shù)據(jù)具有時序性,Interest包和Data包均增加序列號字段作為標記,增加字段及含義見表1、表2。
表1 Interest包增加字段及含義
表2 Data包增加字段及含義
訂閱Interest包同樣包含生存期字段,為防止鏈路出現(xiàn)異常,用戶需要周期性發(fā)送訂閱Interest包。
同時用戶每發(fā)送一個訂閱Interest包,數(shù)據(jù)源需要對其進行回復,以表示收到訂閱信息,該回復中同時包含數(shù)據(jù)源目前產(chǎn)生的最新序列號信息,用于實現(xiàn)數(shù)據(jù)同步。
此外,為方便對推送方數(shù)據(jù)進行流量控制,Interest包增加窗口值字段。
2.2 路由器添加訂閱記錄表
在NDN路由器中增加訂閱記錄表(subscribe pending interest table,SPIT)用于記錄用戶訂閱信息。SPIT的數(shù)據(jù)結構和原NDN路由器中特定Interest表(PIT)相似,當路由器收到用戶訂閱信息后在SPIT中添加表項,記錄訂閱內(nèi)容名字和Interest包入端口,當路由器收到數(shù)據(jù)源推送內(nèi)容后,查找SPIT,對推送內(nèi)容進行轉發(fā)。
SPIT和原PIT的不同在于:(1)原有機制中PIT在收到Data包后會對表項進行刪除,以此實現(xiàn)一個Interest包對應一個Data包,阻礙了后繼數(shù)據(jù)的推送,而本文設計機制在收到Data包后SPIT表項不做刪除,允許數(shù)據(jù)包的持續(xù)推送;(2)SPIT表項中增加序列號標記,每當路由器收到一個推送Data包后,判斷序列號是否大于該標記,并進行更新,防止數(shù)據(jù)的重復推送以及意外導致的推送環(huán)路的發(fā)生。
在路由器中,SPIT與原PIT并存,路由器在收到Data包后根據(jù)Data類型查找不同的表項。對于推送數(shù)據(jù)發(fā)生網(wǎng)絡丟包的情況,用戶可通過發(fā)送正常請求獲取丟失數(shù)據(jù),其會在PIT中建立表項。
2.3 方案命名設計
NDN中內(nèi)容的命名由應用決定[16]。對于實時通信應用,由于內(nèi)容具有時序性,因此內(nèi)容命名通常為數(shù)據(jù)源標識加序列號,如:/cstnet/chat/usrA/001;對于本文設計機制,訂閱Interest包的名字為用戶要訂閱的數(shù)據(jù)源標識,如:/cstnet/chat/usrA,路由器收到訂閱信息后將其記入SPIT中,當數(shù)據(jù)源推送數(shù)據(jù)時,路由器根據(jù)內(nèi)容名采用前綴匹配方式查找SPIT,將內(nèi)容從記錄端口轉發(fā)。
2.4 轉發(fā)流程設計
本文設計的NDN路由器包處理流程如圖1和圖2所示,轉發(fā)流程算法如表3和表4所示。
圖1 Interest包轉發(fā)流程
圖2 Data包轉發(fā)流程
1:/*Interest類型判斷*/ IFInterest類型=普通THEN Goto32:/*訂閱Interest包執(zhí)行操作*/ /*更新SPIT*/ IFInterest類型=取消訂閱THEN 查找SPIT,刪除對應表項 Exit ELSE /*Interest類型=訂閱*/ 查找SPIT: IF表項不存在THEN 添加SPIT表項記錄入端口號 ELSE SPIT表項添加入端口號 表項保留計時器=Interest包生存期 Goto43:原有Interest包處理流程4:查找FIB表,找到Interest包轉發(fā)端口5:根據(jù)轉發(fā)策略對Interest包進行處理6:轉發(fā)Interest包
表4 Data包處理算法
與文獻[9,11]的方案相比,本文方案設計的優(yōu)點在于沒有更改原NDN路由器中路由和緩存模塊,Interest包路由方式和原有方式相同,與NDN原有機制相比,該方案不僅保留原有請求者“拉”模式的數(shù)據(jù)獲取,還增加了對實時應用數(shù)據(jù)推送的支持。對于實時通信應用,請求者向數(shù)據(jù)源發(fā)送訂閱信息后,數(shù)據(jù)源有新的數(shù)據(jù)便可直接推送出去,大大減小了數(shù)據(jù)接收延遲和網(wǎng)絡傳輸代價。
2.5 網(wǎng)絡丟包處理
某些物聯(lián)網(wǎng)實時監(jiān)控應用,少量數(shù)據(jù)丟失不需要進行重復請求[9,11]。但是對于某些需要網(wǎng)絡可靠性保證的應用,數(shù)據(jù)丟失需要用戶重新請求。
針對網(wǎng)絡傳輸帶來的丟包問題,用戶端可以通過兩種方式發(fā)現(xiàn)丟失數(shù)據(jù):(1)根據(jù)收到的最新推送數(shù)據(jù)中的序列號判斷之前丟失序列號內(nèi)容;(2)根據(jù)數(shù)據(jù)源對用戶端周期性訂閱Interest包的回復判斷丟失序列號內(nèi)容,因為該回復中包含數(shù)據(jù)源最新產(chǎn)生數(shù)據(jù)的序列號。
用戶端在發(fā)現(xiàn)丟失數(shù)據(jù)后采用原有“拉”方式獲取丟失序列號的數(shù)據(jù)。而NDN網(wǎng)內(nèi)緩存將對數(shù)據(jù)的再次獲取帶來加速的效果。
本節(jié)主要分析原NDN傳輸機制與本文設計機制在實時數(shù)據(jù)傳輸中的數(shù)據(jù)接收延遲。對比方案包括3個:(1)同步方式[8],即用戶端周期性發(fā)送同步用Interest包,當發(fā)現(xiàn)數(shù)據(jù)源有新的消息產(chǎn)生時再分別請求對應的Data包;(2)滑動窗口數(shù)據(jù)請求機制[17],即用戶端發(fā)送固定窗口值的Interest包,當收到對應Data包后,發(fā)送窗口向后滑動,請求后繼Data包,如果超時沒有收到則重新請求;(3)本文設計訂閱推送機制,用戶端周期性發(fā)送訂閱Interest包,路由器SPIT記錄回送路徑,數(shù)據(jù)源有數(shù)據(jù)產(chǎn)生便直接推送。
3.1 數(shù)據(jù)接收延遲分析
對于同步傳輸方式,令同步用Interest包的發(fā)送時間間隔為1/λ,期間數(shù)據(jù)源產(chǎn)生數(shù)據(jù)的個數(shù)為μ/λ,則用戶端數(shù)據(jù)接收平均延遲為
αi∈[0, 1/λ] (1)
λ——Interest包平均發(fā)送速率
μ——Data包平均產(chǎn)生速率
αi——第i個數(shù)據(jù)產(chǎn)生到數(shù)據(jù)源收到下一個最近Interest包的時間間隔
tj——第j段鏈路的傳輸時延
k——從數(shù)據(jù)源到用戶的鏈路條數(shù)
n——數(shù)據(jù)源一段時間內(nèi)產(chǎn)生實時數(shù)據(jù)的個數(shù)
AD——一段時間內(nèi)平均數(shù)據(jù)接收延遲
對于滑動窗口傳輸方式,用戶端以λ的速率發(fā)送Interest包,當用戶端收到序列號i的Data包后,請求序列號向后滑動為i+1。其和同步方式不同點在于,如果λ<μ,用戶端接收到的數(shù)據(jù)將長期滯后于數(shù)據(jù)源的數(shù)據(jù)產(chǎn)生,數(shù)據(jù)接收延遲將逐漸增大,因此該方式如果要及時獲取最新的實時數(shù)據(jù),需保證λ≥μ。該方式用戶端數(shù)據(jù)接收平均延遲為
(2)
對于基于NDN原有通信模式的方案設計,增加Interest發(fā)送速率即λ,可以減小αi,從而減小平均接收延遲。
對于本文設計的訂閱推送通信模式,訂閱?;钣肐nterest包發(fā)送頻率為,當數(shù)據(jù)源收到用戶端發(fā)送的訂閱請求后,有實時數(shù)據(jù)產(chǎn)生便直接推送,用戶端數(shù)據(jù)接收平均延遲為
(3)
其中,由公式(1)、(2)、(3)可見,在λ相同的情況下,
(4)
(5)
由式(4)和式(5)可見,本文設計的方案在實時數(shù)據(jù)接收延遲上比NDN原有通信模式要低。
3.2 緩存和網(wǎng)絡丟包的影響
與內(nèi)容分發(fā)類應用不同,實時通信類應用中數(shù)據(jù)源和最新產(chǎn)生的實時數(shù)據(jù)具有唯一性。
對于NDN原有通信方式,單用戶在無網(wǎng)絡丟包的情況下,網(wǎng)內(nèi)緩存對實時數(shù)據(jù)傳輸沒有影響,因為網(wǎng)絡中沒有緩存用戶所需的數(shù)據(jù)。而在多用戶無網(wǎng)絡丟包的情況下,由于不同用戶Interest包的請求時刻不同,緩存對實時數(shù)據(jù)的獲取有一定的加速作用。同樣,對于網(wǎng)絡出現(xiàn)丟包的現(xiàn)象,對于用戶的重復請求,網(wǎng)內(nèi)緩存對于實時數(shù)據(jù)的獲取也會帶有一定的加速作用。
對于本文設計的通信方式,在網(wǎng)絡無丟包的情況下,網(wǎng)內(nèi)緩存對實時數(shù)據(jù)的推送沒有影響,但在網(wǎng)絡出現(xiàn)不同情況的丟包時,中間路由節(jié)點如果緩存有推送的數(shù)據(jù),緩存對用戶的重復請求將起到一定的加速作用。
本文設計機制沒有涉及原有NDN路由器緩存模塊的變動,因此不影響現(xiàn)有緩存模塊的擴展性需求。由于緩存對實時數(shù)據(jù)傳輸沒有帶來決定性影響,而具體緩存策略及大小設置因涉及因素較多,非本文機制探討的重點,有待后繼開展相關研究。
3.3 方案性能分析
在本文設計機制中,對于原有普通類型Interest包和Data包,路由器僅多一步類型判斷,其余處理流程仍按原有機制進行。對于訂閱Interest包和推送Data包,本文機制和原機制不同在于需要查找SPIT,執(zhí)行后繼操作,而SPIT的組織方法和查找算法與原機制中PIT完全相同,因此,本文機制在路由器處理時延上沒有帶來過多影響。
本文采用ndnSIM[12]進行相關實驗,實驗對比為第3節(jié)分析的基于原有NDN通信模式的同步方式和滑動窗口機制。為便于分析,設置數(shù)據(jù)源數(shù)據(jù)產(chǎn)生平均速率為1個/秒,對應設置滑動窗口機制的窗口值為1。實驗驗證結果表明:(1)在無緩存、無丟包情況下,本文設計的機制在數(shù)據(jù)接收時延上優(yōu)于原有傳輸方案設計;(2)網(wǎng)絡丟包和網(wǎng)內(nèi)緩存對數(shù)據(jù)接收延遲帶有影響,在該影響下本文設計的機制仍優(yōu)于原有傳輸方案;(3)用戶數(shù)量對NDN數(shù)據(jù)接收延遲帶有一定影響。
4.1 單用戶數(shù)據(jù)接收延遲
實驗拓撲如圖3所示,相關參數(shù)如表5所示。
圖3 單用戶實驗拓撲
參數(shù)取值每條鏈路帶寬100Mbps每條鏈路延遲50ms數(shù)據(jù)源數(shù)據(jù)產(chǎn)生速率均值1個/秒泊松分布數(shù)據(jù)產(chǎn)生個數(shù)1000數(shù)據(jù)包大小1024Byte緩存替換策略LRU[12]
在鏈路無丟包,并且不設置網(wǎng)內(nèi)緩存的情況下,三種方式用戶端數(shù)據(jù)接收延遲隨用戶端Interest包發(fā)送頻率變化如圖4所示。對于訂閱推送機制,數(shù)據(jù)源收到用戶訂閱Interest包后,有實時數(shù)據(jù)產(chǎn)生便直接推送,故數(shù)據(jù)接收延遲基本等于單向網(wǎng)絡傳輸時延,且不受發(fā)送速率影響。而基于原有NDN傳輸機制的同步方式和滑動窗口方式,數(shù)據(jù)接收延遲在一定范圍內(nèi)隨用戶端Interest包發(fā)送頻率增加而減小,但平均速率高于本文設計訂閱推送方式。圖5為三種方式在Interest發(fā)送速率為5個/秒時時延的累積概率密度曲線,其中本文設計訂閱推送機制基本所有數(shù)據(jù)的接收延遲都在0.2秒以內(nèi)。(由于實驗數(shù)據(jù)量較大,圖5及下文涉及概率密度曲線的圖片實驗數(shù)據(jù)均做按比例采樣展示)
圖4 數(shù)據(jù)接收延遲隨Interest發(fā)送速率變化
圖5 數(shù)據(jù)接收延遲累積概率分布
鏈路丟包對實時數(shù)據(jù)接收延遲帶來一定負面影響,圖6為用戶端Interest發(fā)送速率為5個/秒時,鏈路L1不同丟包率下三種方式數(shù)據(jù)接收平均延遲。其中隨著鏈路丟包率的上升,三種方式數(shù)據(jù)接收延遲增大。同步機制和本文設計機制均可通過周期性發(fā)送的同步Interest包獲取數(shù)據(jù)源目前最新產(chǎn)生的內(nèi)容名字,對丟失數(shù)據(jù)及時請求獲取,而滑動窗口機制因網(wǎng)絡丟包未獲取最新數(shù)據(jù)而延緩了窗口的向后滑動,增加了數(shù)據(jù)接收延遲,故隨鏈路丟包率的提高,數(shù)據(jù)接收延遲增大幅度比另兩種快。
圖6 數(shù)據(jù)接收延遲隨L1丟包率變化
由于實時通信類應用中數(shù)據(jù)源和最新產(chǎn)生的實時數(shù)據(jù)具有唯一性,因此在單用戶無丟包的情況下,NDN節(jié)點緩存對實時數(shù)據(jù)接收沒有影響。然而在網(wǎng)絡出現(xiàn)丟包時,緩存對于丟失數(shù)據(jù)的重復請求帶有一定的加速作用。圖7為用戶端Interest發(fā)送速率為5個/秒,鏈路L1丟包率為20%時,三種傳輸方式在節(jié)點有無緩存情況下數(shù)據(jù)接收延遲累積概率分布。其中對于訂閱推送方式,有80%左右的數(shù)據(jù)包通過推送方式到達用戶,所以延遲在0.15秒左右的數(shù)據(jù)占80%左右,其不受緩存大小的影響。有20%左右的推送數(shù)據(jù)出現(xiàn)了丟包,通過用戶端重新請求獲得,由于丟包數(shù)據(jù)需要用戶端發(fā)現(xiàn)并重新請求,用戶接收時延明顯增大,因此圖7中曲線出現(xiàn)了斷點,而該部分數(shù)據(jù)由于緩存的存在,數(shù)據(jù)接收延遲得到普遍降低,訂閱推送方式數(shù)據(jù)平均接收延遲比不帶緩存的降低了9.5%。
圖7 緩存及丟包影響下接收延遲累積概率分布
由此可見,在單用戶情況下,本文設計機制在實時數(shù)據(jù)接收延遲上優(yōu)于原有NDN傳輸模式,在出現(xiàn)網(wǎng)絡丟包的情況下,NDN網(wǎng)內(nèi)緩存對數(shù)據(jù)獲取帶有一定的加速作用。
4.2 多用戶影響下數(shù)據(jù)接收延遲
和現(xiàn)有TCP/IP相比,NDN的優(yōu)勢之一在于天然多播和網(wǎng)內(nèi)緩存,在原有機制中,由于不同用戶對最新實時數(shù)據(jù)的請求時刻不一定相同,存在有用戶先請求,數(shù)據(jù)被中間節(jié)點緩存,使得其它用戶數(shù)據(jù)請求獲得加速。因此針對單用戶實驗設計多用戶實驗拓撲,如圖8所示,其中用戶2、3作為實驗影響因子,對用戶1數(shù)據(jù)接收進行統(tǒng)計分析,相關實驗參數(shù)同表5。
圖8 多用戶實驗拓撲
作為對比實驗,圖9展示了在鏈路無丟包且不設節(jié)點緩存時的三種方式下,用戶1數(shù)據(jù)接收延遲隨Interest發(fā)送頻率變化的情況,圖10展示在無網(wǎng)內(nèi)緩存,Interest發(fā)送速率為5個/秒時,鏈路L1不同丟包率下,用戶1在三種方式下的數(shù)據(jù)平均接收延遲。圖11展示Interest發(fā)送速率為5個每秒,鏈路L1丟包率為20%,用戶1數(shù)據(jù)接收延遲隨節(jié)點緩存大小變化的情況。其中本文設計機制和基于原有NDN機制的設計方案相比,數(shù)據(jù)平均接收延遲降低41%~62%。
圖9 數(shù)據(jù)接收延遲隨Interest發(fā)送速率變化
圖10 數(shù)據(jù)接收延遲隨L1丟包率變化
圖11 緩存大小對接收延遲影響
圖12展示訂閱推送機制,Interest發(fā)送速率為5個/秒,鏈路L1丟包率為20%,用戶1數(shù)據(jù)接收延遲累積概率分布受多用戶、緩存的影響情況。由于80%未丟包數(shù)據(jù)不受緩存及用戶數(shù)量影響,圖中主要展示20%丟包部分的數(shù)據(jù)傳輸延遲。其中節(jié)點沒有緩存時,單用戶和多用戶影響下的訂閱推送機制基本沒有差異。而有緩存的情況下,多用戶影響的數(shù)據(jù)平均接收延遲比單用戶的數(shù)據(jù)接收平均延遲降低7.3%,因為之前丟包的數(shù)據(jù)可能被其它用戶獲取過而被中間節(jié)點緩存,當用戶請求該丟包數(shù)據(jù)時,延遲將被縮短。
圖12 多用戶及緩存影響下延遲累積分布
作為網(wǎng)絡通信傳輸機制,本文設計在路由選擇、鏈路異常、流量控制方面均有所考慮。
5.1 路由選擇
NDN中路由一方面通過路由協(xié)議如命名數(shù)據(jù)鏈路狀態(tài)路由(named-data Link State Routing, NLSR)協(xié)議[14]學習得到并記入FIB,另一方面通過基于端口狀態(tài)標記的自適應路由方式[15]。對于第一種方式,本文設計機制并不影響正常的路由學習,并且可以利用學習到的FIB信息轉發(fā)用戶端發(fā)送的訂閱Interest包。對于第二種方式,原有機制根據(jù)接口狀態(tài)(連接、斷開)以及發(fā)送的Interest包在正常往返時間內(nèi)是否收到對應Data包來標記端口狀態(tài),本文設計中,通過用戶端發(fā)送訂閱Interest包,數(shù)據(jù)源回復帶有數(shù)據(jù)源最新序列號的回復數(shù)據(jù)包也可實現(xiàn)端口狀態(tài)的鑒別,如果中間路由器收到訂閱Interest包但由于接口斷開等原因無法轉發(fā),同樣可以回復NACK包[15]告知前一跳此路不通,同時不添加SPIT表項。
因此,本文設計機制完全兼容原有NDN路由設計及實現(xiàn),且不會在性能上造成額外影響。
5.2 鏈路異常
當鏈路發(fā)生偶然的異常變動,用戶周期性發(fā)送的訂閱Interest包將按路由器路由規(guī)則和相應轉發(fā)策略選擇新的端口進行自適應轉發(fā),因此舊路徑上的路由器SPIT表項超時會被刪除,新路徑上的路由器SPIT表項會有相應記錄,數(shù)據(jù)源推送數(shù)據(jù)將沿新的路徑傳輸,舊的路徑上將不會再收到推送的數(shù)據(jù)。
5.3 流量控制
首先,在網(wǎng)絡帶寬及網(wǎng)絡節(jié)點處理能力充足的情況下不需要進行流量控制,但是如果網(wǎng)絡資源在短時間內(nèi)匱乏或者數(shù)據(jù)源受到攻擊者攻擊,這時數(shù)據(jù)源大量推送的數(shù)據(jù)應當受到抑制,以防加重網(wǎng)絡負擔。
本文通過在訂閱Interest包中增加窗口值字段,限定上游數(shù)據(jù)源推送數(shù)據(jù)速率。在轉發(fā)訂閱Interest包時,每跳節(jié)點可以根據(jù)網(wǎng)絡當前狀態(tài)更新窗口字段值,內(nèi)容為一段時間內(nèi)允許上游推送數(shù)據(jù)包個數(shù),上游節(jié)點在收到傳來的訂閱Interest包后會在SPIT中進行標記,限定向?qū)丝贒ata包的推送速率,以此實現(xiàn)推送流量控制。
實時通信類應用數(shù)據(jù)產(chǎn)生具有一定突發(fā)性和隨機性,且時延敏感,傳統(tǒng)命名數(shù)據(jù)網(wǎng)絡(NDN)用戶驅(qū)動的“拉”模式數(shù)據(jù)獲取方式無法滿足實時通信應用需求。本文設計了基于訂閱推送的NDN實時通信機制,該機制首先在NDN路由器增加訂閱記錄,隨后實時應用數(shù)據(jù)便可直接推送給訂閱用戶,從而大大減小數(shù)據(jù)的接收延遲。同時該機制可以和原NDN傳輸機制并存,借用網(wǎng)內(nèi)緩存減小因網(wǎng)絡丟包造成的接收延遲。相關實驗及分析表明,該機制在數(shù)據(jù)接收延遲上明顯優(yōu)于基于“拉”方式的傳統(tǒng)NDN傳輸方案。
[1] 謝高崗, 張玉軍, 李振宇等. 未來互聯(lián)網(wǎng)體系結構研究綜述. 計算機學報, 2012, 35(6): 1109-1119
[2] Zhang L, Afanasyev A, Burke J, et al. Named data networking.ACMSIGCOMMComputerCommunicationReview, 2014, 44(3): 66-73
[3] Ghodsi A, Shenker S, Koponen T, et al. Information-centric networking: seeing the forest for the trees. In: Proceedings of the 10th ACM Workshop on Hot Topics in Networks, Cambridge, USA, 2011. 1
[4] Ahlgren B, Dannewitz C, Imbrenda C, et al. A survey of information-centric networking.IEEECommunicationsMagazine, 2012, 50(7): 26-36
[5] Bari M F, Chowdhury S, Ahmed R, et al. A survey of naming and routing in information-centric networks.IEEECommunicationsMagazine, 2012, 50(12): 44-53
[6] Wang J, Peng C, Li C, et al. Implementing instant messaging using named data. In: Proceedings of the 6th Asian Internet Engineering Conference, Bangkok, Thailand, 2010. 40-47
[7] Zhu Z, Bian C, Afanasyev A, et al. Chronos: serverless multi-user chat over NDN, Technical Report NDN-0008. Los Angeles: University of Califorhia, 2012
[9] Carzaniga A, Papalini M, Wolf A L. Content-based publish/subscribe networking and information-centric networking. In: Proceedings of the ACM SIGCOMM Workshop on Information-centric Networking, Toronto, Canada, 2011. 56-61
[10] Jacobson V, Mosko M, Smetters D, et al. Content-centric networking.Whitepaper,PaloAltoResearchCenter, 2007: 2-4
[11] Fran?ois J, Cholez T, Engel T. CCN traffic optimization for IoT. In: Proceedings of the 4th International Conference on Network of the Future, Pohang, Korea, 2013
[12] Mastorakis S, Afanasyev A, Moiseenko I, et al. ndnSIM 2.0: a new version of the NDN simulator for NS-3. Technical Report NDN-0028. Los Angeles: University of Califorhia, 2015
[13] Afanasyev A, Shi J, Zhang B, et al. NFD developer’s guide. Technical Report NDN-0021. Los Angeles: University of Califorhia, 2014
[14] Hoque A K M, Amin S O, Alyyan A, et al. Nlsr: Named-data link state routing protocol. In: Proceedings of the 3rd ACM SIGCOMM Workshop on Information-centric Networking, Hong Kong, China, 2013. 15-20
[15] Yi C, Abraham J, Afanasyev A, et al. On the role of routing in Named Data Networking. In: Proceedings of the 1st International Conference on Information-centric Networking, Paris, France, 2014. 27-36
[16] Yu Y, Afanasyev A, Zhu Z, et al. Ndn technical memo: naming conventions. Technical Report NDN-0022. Los Angeles: University of Califorhia, 2014
[17] Jacobson V, Smetters D K, Briggs N H, et al. VoCCN: voice-over content-centric networks. In: Proceedings of the 2009 Workshop on Re-architecting the Internet, Rome, Italy, 2009. 1-6
Subscription push based real-time communication mechanism for NDN
Jin Pengfei***, Li Jun*, Wu Haibo*, Zhi Jiang***
(*Computer Network Information Center, Chinese Academy of Sciences, Beijing 100190) (**University of Chinese Academy of Sciences, Beijing 100049)
The study focused on the real-time communication mechanism of the promising Internet architecture of named data networking (NDN), and pointed out that NDN users obtain contents by sending out request messages, while for real-time communications such as instant chatting or monitoring Internet of things, the synchronization of the request rate of users and the data production rate is difficult to realize and the needs of real-time applications are unable to meet when using the conventional user-driven pull mode for data requiring because of data generation’s abruptness and randomness as well as the time delay of data receiving. For the purpose of reducing the data response delay, the study presented a subscription-push-based real-time communication mechanism on the basis of unmodifying conventional NDN routing and caching mechanisms. Under the new mechanism, the subscription information is added into NDN routers in advance, and later thereal-time producercould pushdata to the subscriber immediately. The experimental results show that this new mechanism can greatly reduce the reception delay compared with the original NDN design.
named data networking (NDN), real-time communication, subscribe, push
10.3772/j.issn.1002-0470.2016.06.006
①973計劃(2012CB315803),CNIC所級專項(CNIC_PY-1401)和中國科學院知識創(chuàng)新工程青年人才領域(CNIC_QN_1508)資助項目。
2015-12-01)
②男,1991年生,碩士生;研究方向:命名數(shù)據(jù)網(wǎng)絡;E-mail: jinpengfei@cstnet.cn
③通訊作者,E-mail: lijun@cnic.cn