CCN中基于業(yè)務(wù)類型的多樣化內(nèi)容分發(fā)機(jī)制

葛國棟,郭云飛,劉彩霞,蘭巨龍

(1.中國人民解放軍75753部隊(duì)，廣東廣州 510600；2.國家數(shù)字交換系統(tǒng)工程技術(shù)研究中心,河南鄭州 450002)

?

CCN中基于業(yè)務(wù)類型的多樣化內(nèi)容分發(fā)機(jī)制

葛國棟1,郭云飛2,劉彩霞2,蘭巨龍2

(1.中國人民解放軍75753部隊(duì)，廣東廣州 510600；2.國家數(shù)字交換系統(tǒng)工程技術(shù)研究中心,河南鄭州 450002)

針對內(nèi)容中心網(wǎng)絡(luò)(Content Centric Networking,CCN)如何提供差異化的業(yè)務(wù)需求服務(wù)的問題,采用區(qū)分服務(wù)的思想,從內(nèi)容傳輸和緩存決策的角度出發(fā),提出了一種基于業(yè)務(wù)類型的多樣化內(nèi)容分發(fā)機(jī)制.該機(jī)制依據(jù)不同的業(yè)務(wù)請求特征,分別設(shè)計(jì)了持久推送、并行預(yù)測和逐包請求的數(shù)據(jù)分發(fā)模式,對應(yīng)提出了透明轉(zhuǎn)發(fā)、邊緣概率緩存和漸進(jìn)式推進(jìn)的沿途存儲(chǔ)策略,實(shí)現(xiàn)了內(nèi)容傳遞對于業(yè)務(wù)類型的感知和匹配.仿真結(jié)果表明,該機(jī)制減小了內(nèi)容請求時(shí)延,提高了緩存命中率,以少量額外的控制開銷提升了CCN網(wǎng)絡(luò)整體的內(nèi)容分發(fā)性能.

內(nèi)容中心網(wǎng)絡(luò);區(qū)分服務(wù);緩存策略;業(yè)務(wù)類型

1　引言

隨著互聯(lián)網(wǎng)技術(shù)與應(yīng)用的飛速發(fā)展,“寬帶化”、“內(nèi)容化”與“個(gè)性化”已成為網(wǎng)絡(luò)發(fā)展的主旋律,人們對于數(shù)據(jù)內(nèi)容的需求日益強(qiáng)烈,網(wǎng)絡(luò)應(yīng)用的主體逐步向內(nèi)容請求服務(wù)演進(jìn)[1].據(jù)Cisco VNI Mobile Forecast預(yù)測,到2014年互聯(lián)網(wǎng)上所有內(nèi)容相關(guān)的流量將占據(jù)超過97.5%的份額,傳統(tǒng)以主機(jī)為中心的網(wǎng)絡(luò)體系結(jié)構(gòu)難以滿足當(dāng)前網(wǎng)絡(luò)信息服務(wù)的要求.為了適應(yīng)不斷增長的數(shù)據(jù)內(nèi)容訪問需求,內(nèi)容中心網(wǎng)絡(luò)(Content Centric Networking,CCN)[2,3]作為一種革命式的未來互聯(lián)網(wǎng)設(shè)計(jì)思路,將網(wǎng)絡(luò)通信模式從關(guān)注“在哪”轉(zhuǎn)變?yōu)殛P(guān)注“是什么”,直接表達(dá)用戶和應(yīng)用的通信目的,成為未來互聯(lián)網(wǎng)設(shè)計(jì)的重要模式.在CCN設(shè)計(jì)中,直接以內(nèi)容名字進(jìn)行路由,當(dāng)沿途節(jié)點(diǎn)接收到興趣包(Interest Packet)請求后,依據(jù)內(nèi)容名字依次在內(nèi)容存儲(chǔ)器(Content Store,CS)、未決請求表(Pending Interest Table,PIT)和轉(zhuǎn)發(fā)信息庫(Forwarding Information Base,FIB)中進(jìn)行匹配查詢,實(shí)現(xiàn)點(diǎn)到多點(diǎn)的內(nèi)容分發(fā).

CCN采用沿途普遍緩存(Cache Everything Everywhere,CE2)的方式,應(yīng)答數(shù)據(jù)將在沿途轉(zhuǎn)發(fā)路徑的所有節(jié)點(diǎn)上進(jìn)行存儲(chǔ).內(nèi)容傳輸時(shí),采用請求者驅(qū)動(dòng)的一對一(one-request-one-data)分發(fā)模式,節(jié)點(diǎn)預(yù)先需要逐一發(fā)送Interest Packet,當(dāng)接收到Data Packet后,再發(fā)送后續(xù)內(nèi)容請求.在CCN請求和應(yīng)答過程中,對于所有業(yè)務(wù)請求,僅僅依據(jù)內(nèi)容名字,執(zhí)行相同的匹配查詢、路由轉(zhuǎn)發(fā)和緩存決策,缺乏對于業(yè)務(wù)請求特征的考慮,無法提供差異化的業(yè)務(wù)需求服務(wù)[4],主要體現(xiàn)在兩個(gè)方面:

(1)內(nèi)容傳輸時(shí),采用請求者驅(qū)動(dòng)的一對一分發(fā)模式,節(jié)點(diǎn)需要預(yù)先逐一發(fā)送內(nèi)容請求,產(chǎn)生大量興趣報(bào)文和控制開銷,浪費(fèi)了上行鏈路的帶寬資源.同時(shí),這種機(jī)械式的逐包請求方式,對于時(shí)延敏感的實(shí)時(shí)業(yè)務(wù),即時(shí)推送、通告類等業(yè)務(wù)類型,內(nèi)容產(chǎn)生后將無法及時(shí)發(fā)送給請求者,增大了內(nèi)容請求時(shí)延.

(2)緩存決策時(shí),泛濫式的沿途全部緩存方式CE2,致使節(jié)點(diǎn)緩存內(nèi)容趨于同質(zhì)化,導(dǎo)致大量的緩存冗余[5].盲目不加區(qū)分地將所有應(yīng)答內(nèi)容進(jìn)行緩存,既浪費(fèi)了節(jié)點(diǎn)有限的存儲(chǔ)空間,又增加了報(bào)文的轉(zhuǎn)發(fā)處理開銷.例如,對于實(shí)時(shí)流媒體,VoIP等業(yè)務(wù)類型,內(nèi)容共享度低,私有性強(qiáng),節(jié)點(diǎn)緩存內(nèi)容后,無法實(shí)現(xiàn)后續(xù)的有效利用,而且影響了其他業(yè)務(wù)內(nèi)容的正常存儲(chǔ).同時(shí),在內(nèi)容傳輸中,沿途節(jié)點(diǎn)逐跳的內(nèi)容緩存和CS查詢匹配,增大了節(jié)點(diǎn)的計(jì)算和處理開銷.

文獻(xiàn)[4,6]分析了信息中心網(wǎng)絡(luò)在支持多媒體業(yè)務(wù)傳輸?shù)膬?yōu)勢和不足,對現(xiàn)有方案進(jìn)行了對比分析,指出了目前存在的問題;文獻(xiàn)[7]在CCN中設(shè)計(jì)了一種支持VoIP業(yè)務(wù)的傳輸模式(VoCCN).請求者預(yù)先發(fā)送多個(gè)興趣請求,同時(shí)在數(shù)據(jù)源處形成未決狀態(tài),一旦內(nèi)容產(chǎn)生,便可立即發(fā)送.該方案增大了沿途節(jié)點(diǎn)PIT需要存儲(chǔ)的條目信息,逐包的內(nèi)容請求模式效率低下;文獻(xiàn)[8]針對實(shí)時(shí)業(yè)務(wù),采用一對多的請求方式(MERTS),通過發(fā)送特殊興趣包完成n個(gè)數(shù)據(jù)單元的同時(shí)請求.但是,該方案對于非實(shí)時(shí)業(yè)務(wù)采用的仍舊是沿途普遍緩存方式;文獻(xiàn)[9]針對視頻點(diǎn)播業(yè)務(wù),提出了一種沿途協(xié)作緩存算法,節(jié)點(diǎn)只存儲(chǔ)內(nèi)容索引與其標(biāo)簽值相等的數(shù)據(jù)單元,避免相同內(nèi)容的重復(fù)冗余緩存.文獻(xiàn)[10]依據(jù)可靠性和實(shí)時(shí)性指標(biāo),將內(nèi)容劃分為不同業(yè)務(wù)類型,設(shè)計(jì)了差異化的內(nèi)容請求模式.但是該方案缺乏對于緩存決策的考慮.文獻(xiàn)[11]提出了一種支持快速和正常轉(zhuǎn)發(fā)的雙模式傳輸策略.對于共享內(nèi)容,采用CCN原有的緩存和請求模式,對于私有內(nèi)容,直接依據(jù)FIB實(shí)現(xiàn)快速的路由轉(zhuǎn)發(fā).

為此,本文認(rèn)為在內(nèi)容請求時(shí),不僅要依據(jù)內(nèi)容名字,更需要結(jié)合具體的業(yè)務(wù)類型請求特征,設(shè)計(jì)差異化的緩存決策和數(shù)據(jù)傳輸模式.為此,為了支持多樣化的業(yè)務(wù)類型和服務(wù)需求,在CCN中提出了一種多樣化內(nèi)容分發(fā)機(jī)制(Diverse Content Delivery Scheme,DCDS).DCDS采用區(qū)分服務(wù)的思想,從內(nèi)容緩存和傳輸方式的角度出發(fā),研究業(yè)務(wù)請求特征驅(qū)動(dòng)的差異化內(nèi)容分發(fā)策略,實(shí)現(xiàn)內(nèi)容傳遞對于業(yè)務(wù)類型的感知和匹配.

2　多樣化內(nèi)容分發(fā)機(jī)制

為了實(shí)現(xiàn)對于多樣化業(yè)務(wù)類型的支持,在CCN原有的Interest Packet和Data Packet中添加業(yè)務(wù)類型(Type of Traffic,ToT)和報(bào)文類型(Type of Packet,ToP)字段.其中,ToT用于標(biāo)識(shí)的不同的請求業(yè)務(wù),ToP字段用于標(biāo)識(shí)和區(qū)分不同的請求和應(yīng)答報(bào)文.沿途節(jié)點(diǎn)依據(jù)ToT和ToP取值,執(zhí)行差異化的緩存策略和內(nèi)容傳輸模式.

本文考慮三種業(yè)務(wù)類型:(1)實(shí)時(shí)業(yè)務(wù).例如,實(shí)時(shí)流媒體業(yè)務(wù),VoIP等.該類業(yè)務(wù)實(shí)時(shí)性強(qiáng),內(nèi)容產(chǎn)生后必須立即發(fā)送給請求者,對于請求時(shí)延要求嚴(yán)格.同時(shí),內(nèi)容后續(xù)共享程度小,私有性強(qiáng).(2)非實(shí)時(shí)的流媒體業(yè)務(wù).例如視頻點(diǎn)播業(yè)務(wù).該類業(yè)務(wù)后續(xù)共享程度高,包含的內(nèi)容文件大,一般被劃分為多個(gè)數(shù)據(jù)塊單元(chunks),用戶按照順序逐次請求,連續(xù)內(nèi)容請求之間具有強(qiáng)的相關(guān)性[12],時(shí)延要求低于實(shí)時(shí)業(yè)務(wù),但對于帶寬資源要求大;(3)用戶自產(chǎn)生內(nèi)容(User Generate Content,UGC)[13,14].例如,靜態(tài)圖片、文本信息共享等.該類業(yè)務(wù)內(nèi)容文件小,內(nèi)容數(shù)量大,不同請求之間沒有明顯的相關(guān)性,對于時(shí)延和帶寬沒有明顯要求.

圖1給出了DCDS工作流程,沿途節(jié)點(diǎn)依據(jù)ToT和ToP標(biāo)識(shí),判斷所屬業(yè)務(wù)類型,執(zhí)行對應(yīng)的內(nèi)容請求和緩存策略,具體包括持久推送,并行預(yù)測和逐包請求三種內(nèi)容分發(fā)模式.

2.1持久推送模式

對于該類業(yè)務(wù)請求:(1)實(shí)時(shí)性強(qiáng),對于時(shí)延要求嚴(yán)格,內(nèi)容產(chǎn)生后必須立即發(fā)送給請求者.CCN基于請求者驅(qū)動(dòng)的一對一傳輸模式無法保證內(nèi)容請求時(shí)延,而且會(huì)引入大量的請求報(bào)文開銷;(2)內(nèi)容私有性強(qiáng),共享度低.對于該類業(yè)務(wù)數(shù)據(jù)的存儲(chǔ),無法實(shí)現(xiàn)后續(xù)的有效利用,又浪費(fèi)了節(jié)點(diǎn)有限的存儲(chǔ)空間.

為此,對于該類業(yè)務(wù)請求采用持久推送,快速轉(zhuǎn)發(fā)的分發(fā)策略:(1)請求者發(fā)送持久興趣請求,建立與數(shù)據(jù)源之間穩(wěn)定的傳輸關(guān)系,避免逐一的報(bào)文請求,實(shí)現(xiàn)實(shí)時(shí)內(nèi)容的即時(shí)發(fā)送;(2)沿途節(jié)點(diǎn)對于該類業(yè)務(wù)數(shù)據(jù)不執(zhí)行緩存操作,無需進(jìn)行CS的查詢匹配,實(shí)現(xiàn)報(bào)文的透明轉(zhuǎn)發(fā),加快處理速度.

2.1.1內(nèi)容請求

業(yè)務(wù)類型ToT=00,報(bào)文類型ToP包括:(1)持久興趣包(00),PIP(Persistent Interest Packet);(2)持久數(shù)據(jù)包(01),PDP(Persistent Data Packet);(3)更新興趣包(10),UIP(Update Interest Packet);(4)注銷興趣包(11),UsIP(Un-subscribe Interest Packet).

在上行請求過程中,當(dāng)沿途節(jié)點(diǎn)接收到Interest Packet后,首先查看ToT和ToP字段,確定業(yè)務(wù)和報(bào)文類型.如圖2所示,如果ToT=00,ToP=00,則表示持久興趣請求PIP.沿途節(jié)點(diǎn)無需執(zhí)行CS查詢匹配,在PIT表項(xiàng)中添加請求條目,并標(biāo)記該請求接口為持久興趣請求,然后按照FIB表項(xiàng)執(zhí)行上行轉(zhuǎn)發(fā)(步驟①);如果該內(nèi)容已被請求,而來自不同接口,則在PIT條目中添加對應(yīng)接口信息(步驟②).當(dāng)數(shù)據(jù)源接收到持久請求PIP,每當(dāng)內(nèi)容產(chǎn)生后,立即向?qū)?yīng)的請求接口發(fā)送應(yīng)答內(nèi)容PDP,無需預(yù)先逐一的內(nèi)容請求(步驟③).沿途節(jié)點(diǎn)依據(jù)對應(yīng)的持久請求接口信息,實(shí)現(xiàn)應(yīng)答內(nèi)容的反向傳輸.

2.1.2數(shù)據(jù)應(yīng)答

當(dāng)下行節(jié)點(diǎn)接收到Data Packet后,查看ToT和ToP字段,如果接收到的是PDP報(bào)文,節(jié)點(diǎn)CS不執(zhí)行應(yīng)答內(nèi)容緩存,直接查詢PIT表項(xiàng),執(zhí)行PDP的下行轉(zhuǎn)發(fā)(步驟③),加快應(yīng)答報(bào)文回傳速度.如果請求接口為持久興趣請求,內(nèi)容應(yīng)答后,對應(yīng)的PIT條目并不進(jìn)行刪除,直至其過期或者接收到用戶主動(dòng)發(fā)送的UsIP取消操作,再進(jìn)行刪除操作.

2.1.3緩存決策

節(jié)點(diǎn)查看ToT字段,如果為第一類業(yè)務(wù)請求,在上行傳輸時(shí),無需執(zhí)行CS的逐跳匹配查詢,在下行應(yīng)答時(shí),沿途節(jié)點(diǎn)不執(zhí)行內(nèi)容緩存操作,直接依據(jù)PIT表項(xiàng)進(jìn)行PDP轉(zhuǎn)發(fā).對于該類業(yè)務(wù)請求,報(bào)文的透明傳輸和快速轉(zhuǎn)發(fā),減小了實(shí)時(shí)內(nèi)容的請求時(shí)延,同時(shí)也增大了其他業(yè)務(wù)內(nèi)容緩存概率,提升了節(jié)點(diǎn)緩存空間整體利用率.

2.2并行預(yù)測模式

對于該類業(yè)務(wù)請求:(1)內(nèi)容共享度高,可以被后續(xù)反復(fù)請求,沿途節(jié)點(diǎn)對于該類數(shù)據(jù)的緩存可以有效提高后續(xù)請求的就近響應(yīng);(2)內(nèi)容文件大,對于帶寬資源要求高.如果內(nèi)容請求都發(fā)送至內(nèi)容源處進(jìn)行響應(yīng),將消耗大量的網(wǎng)絡(luò)帶寬資源.為此,在緩存決策時(shí),如果能將該類業(yè)務(wù)內(nèi)容緩存至網(wǎng)絡(luò)邊緣,將大大減小網(wǎng)絡(luò)流量傳輸和帶寬需求;(3)內(nèi)容包含多個(gè)數(shù)據(jù)塊單元,用戶需要連續(xù)發(fā)送多個(gè)興趣請求.若能提前預(yù)測并執(zhí)行后續(xù)數(shù)據(jù)單元的并行請求,將大大減小內(nèi)容請求時(shí)延.

為此,對于該類業(yè)務(wù)請求采用并行預(yù)測,邊緣存儲(chǔ)的分發(fā)策略:(1)依據(jù)內(nèi)容請求序列間的相關(guān)性特征,主動(dòng)發(fā)送對后續(xù)相關(guān)數(shù)據(jù)單元的并行請求,預(yù)先獲取并緩存內(nèi)容;(2)將應(yīng)答內(nèi)容以概率方式推送至網(wǎng)絡(luò)邊緣進(jìn)行存儲(chǔ),減小沿途緩存冗余和網(wǎng)絡(luò)流量傳輸.

2.2.1內(nèi)容請求

業(yè)務(wù)類型碼ToT=01,報(bào)文類型包括:(1)興趣包(00);(2)數(shù)據(jù)包(01);(3)相關(guān)興趣包(10),CIP(CorrelatedInterestPacket);(4)相關(guān)數(shù)據(jù)包(11),CDP(CorrelatedDataPacket,CDP),其中CIP和CDP用于標(biāo)識(shí)節(jié)點(diǎn)基于相關(guān)性發(fā)出的預(yù)測請求和應(yīng)答報(bào)文.

定義1內(nèi)容請求相關(guān)系數(shù)ρcor:ρcor用于定量地描述內(nèi)容請求序列之間的相關(guān)性程度,表示同一內(nèi)容對象,相鄰chunk單元被連續(xù)請求的概率大小:

ρcor=P(rn+1=Ci+1|rn=Ci)

(1)其中,0≤ρcor≤1,rn+1,rn分別表示第n和n+1次發(fā)送的內(nèi)容請求,? i,Ci和Ci+1屬于同一內(nèi)容對象,且代表了連續(xù)的數(shù)據(jù)塊單元.ρcor取值越大,數(shù)據(jù)塊請求序列之間的相關(guān)性越強(qiáng),CIP報(bào)文請求的預(yù)測內(nèi)容命中率越高.

在上行內(nèi)容請求過程中,沿途節(jié)點(diǎn)接收到興趣包后,查看ToT和ToP字段,確定業(yè)務(wù)和報(bào)文類型.如圖3所示,如果ToT=01,ToP=00,則表示用戶發(fā)送的正常興趣請求(步驟①).當(dāng)緩存命中節(jié)點(diǎn)發(fā)送DataPacket對當(dāng)前請求應(yīng)答時(shí)(步驟②),主動(dòng)發(fā)送CIP報(bào)文,執(zhí)行下一相關(guān)數(shù)據(jù)單元的預(yù)測請求(步驟③).當(dāng)請求節(jié)點(diǎn)接收到CDP報(bào)文后,由于無法確定用戶是否會(huì)在短時(shí)間內(nèi)發(fā)送下一數(shù)據(jù)單元請求,對于預(yù)測內(nèi)容首先進(jìn)行臨時(shí)緩存(紅色方框所示),緩存時(shí)間設(shè)為ttem(步驟④).如果在ttem內(nèi),沒有接收到后續(xù)請求,說明該次請求預(yù)測錯(cuò)誤,在CS中標(biāo)記該內(nèi)容為“可替換”狀態(tài).當(dāng)節(jié)點(diǎn)執(zhí)行緩存替換時(shí),優(yōu)先淘汰“可替換”內(nèi)容.如果在ttem周期內(nèi),節(jié)點(diǎn)接收到用戶發(fā)送的興趣請求,在CS中正式緩存該預(yù)測內(nèi)容,其存儲(chǔ)位置更新為CS最頂層,并刪除臨時(shí)緩存時(shí)間選項(xiàng),執(zhí)行正常的LRU替換策略(圖3-3步驟④).

2.2.2數(shù)據(jù)應(yīng)答

當(dāng)下游節(jié)點(diǎn)接收到應(yīng)答數(shù)據(jù)后,查看ToP字段,如果為正常的應(yīng)答數(shù)據(jù)報(bào)文,按照2.2.3節(jié)提出的邊緣概率緩存策略確定內(nèi)容的目標(biāo)存儲(chǔ)節(jié)點(diǎn).當(dāng)節(jié)點(diǎn)執(zhí)行內(nèi)容緩存后,該內(nèi)容將被添加到CS最頂層.當(dāng)下游節(jié)點(diǎn)接收到相關(guān)數(shù)據(jù)報(bào)文CDP時(shí),由于該內(nèi)容是基于相關(guān)性發(fā)起的預(yù)測請求,沿途節(jié)點(diǎn)不進(jìn)行緩存,直接依據(jù)PIT表項(xiàng)將該內(nèi)容發(fā)送至請求節(jié)點(diǎn).

2.2.3緩存決策

沿途節(jié)點(diǎn)以概率方式執(zhí)行緩存決策,隨著應(yīng)答數(shù)據(jù)的逐跳下行傳輸,緩存概率不斷增大,將請求內(nèi)容推送至網(wǎng)絡(luò)邊緣進(jìn)行存儲(chǔ).同時(shí),采用累加和重置的方式,動(dòng)態(tài)調(diào)節(jié)緩存概率大小,避免沿途內(nèi)容的重復(fù)冗余緩存.

(1)內(nèi)容請求者(ContentConsumer)vc發(fā)送興趣請求,通過興趣包的上行逐跳傳輸,依次記錄并更新傳輸路徑長度l,每當(dāng)興趣包到達(dá)下一節(jié)點(diǎn),傳輸跳數(shù)加1.最終,當(dāng)InterestPacket到達(dá)內(nèi)容提供者(ContentProvider)vp后,l記錄的就是沿途傳輸路徑節(jié)點(diǎn)的個(gè)數(shù).

(2)當(dāng)vp發(fā)送數(shù)據(jù)包進(jìn)行應(yīng)答時(shí),依據(jù)l取值首先計(jì)算沿途節(jié)點(diǎn)的初始緩存概率ph:

(2)其中,h為當(dāng)前節(jié)點(diǎn)距離內(nèi)容提供者vp的路由跳數(shù),節(jié)點(diǎn)距離數(shù)據(jù)源越遠(yuǎn),緩存概率越大.當(dāng)下行節(jié)點(diǎn)接收到DataPacket后,以累加緩存概率ps決定是否緩存應(yīng)答內(nèi)容:

(3)

(1)如果緩存,將累加緩存概率ps置為0.當(dāng)后續(xù)節(jié)點(diǎn)接收到應(yīng)答包后,如果ps已被置0,說明上行節(jié)點(diǎn)已經(jīng)緩存了應(yīng)答內(nèi)容,后續(xù)節(jié)點(diǎn)將不執(zhí)行內(nèi)容存儲(chǔ),直接依據(jù)PIT表項(xiàng)進(jìn)行路由轉(zhuǎn)發(fā),避免相同內(nèi)容的重復(fù)存儲(chǔ);(2)否則,ps將不斷累加,更新為已有轉(zhuǎn)發(fā)節(jié)點(diǎn)的緩存概率之和,以增大后續(xù)節(jié)點(diǎn)的存儲(chǔ)概率.

2.3逐包請求模式

對于該類業(yè)務(wù)請求:(1)內(nèi)容共享程度高,可以被后續(xù)反復(fù)請求,沿途緩存可有效提高內(nèi)容請求的就近應(yīng)答;(2)對于帶寬和時(shí)延沒有嚴(yán)格要求,應(yīng)答內(nèi)容返回時(shí),可考慮向數(shù)據(jù)源側(cè)進(jìn)行緩存,與并行預(yù)測模式下提出的邊緣存儲(chǔ)策略實(shí)現(xiàn)存儲(chǔ)位置的相對分離和互相補(bǔ)充,提升網(wǎng)絡(luò)節(jié)點(diǎn)緩存空間的整體利用率.

為此,對于該類業(yè)務(wù)采用逐包請求,漸進(jìn)式緩存的分發(fā)策略:(1)初始請求時(shí),應(yīng)答數(shù)據(jù)優(yōu)先考慮向數(shù)據(jù)源側(cè)進(jìn)行存儲(chǔ),伴隨后續(xù)內(nèi)容的不斷請求,以漸進(jìn)式的方式逐步將流行內(nèi)容推送至網(wǎng)絡(luò)邊緣存儲(chǔ);(2)內(nèi)容請求時(shí),采用CCN逐包請求模式,當(dāng)請求者接收到應(yīng)答內(nèi)容后,再發(fā)送后續(xù)請求.

2.3.1內(nèi)容請求與數(shù)據(jù)應(yīng)答

業(yè)務(wù)類型碼ToT=10,報(bào)文類型碼ToP包括:(1)興趣包(00);(2)數(shù)據(jù)包(01).

內(nèi)容請求采用一對一逐包請求模式,用戶發(fā)送內(nèi)容請求,沿途任何存儲(chǔ)該請求內(nèi)容的節(jié)點(diǎn)都可發(fā)送DataPacket進(jìn)行響應(yīng),下行節(jié)點(diǎn)按照2.3.2節(jié)提出的漸進(jìn)式存儲(chǔ)策略執(zhí)行沿途內(nèi)容存儲(chǔ).當(dāng)請求節(jié)點(diǎn)接收到對應(yīng)的應(yīng)答內(nèi)容后,發(fā)送下一內(nèi)容請求.

2.3.2緩存決策

沿途節(jié)點(diǎn)以概率的方式執(zhí)行緩存決策,隨著DataPacket下行傳輸,緩存概率不斷減小,優(yōu)先在數(shù)據(jù)源側(cè)存儲(chǔ)應(yīng)答內(nèi)容;同時(shí),采用重置歸0的方式,動(dòng)態(tài)調(diào)整節(jié)點(diǎn)緩存概率,避免沿途內(nèi)容的重復(fù)冗余緩存.

內(nèi)容請求者vc發(fā)送Interestpacket請求,通過興趣包上行的逐跳傳輸,依次記錄并更新傳輸路徑長度l,每當(dāng)興趣包到達(dá)下一跳節(jié)點(diǎn),傳輸跳數(shù)加1.最終,當(dāng)InterestPacket到達(dá)vp后,l記錄的就是傳輸路徑節(jié)點(diǎn)的個(gè)數(shù).當(dāng)vp發(fā)送DataPacket進(jìn)行應(yīng)答時(shí),依據(jù)l首先計(jì)算沿途節(jié)點(diǎn)初始緩存概率ph:

(4)

當(dāng)下行節(jié)點(diǎn)接收到DataPacket后,以ph決定是否緩存該應(yīng)答內(nèi)容:(1)如果緩存,將緩存概率ph置為0.當(dāng)后續(xù)節(jié)點(diǎn)接收到應(yīng)答包后,如果ph已被置0,說明上行節(jié)點(diǎn)已經(jīng)緩存了應(yīng)答內(nèi)容,后續(xù)節(jié)點(diǎn)將不執(zhí)行內(nèi)容存儲(chǔ),直接依據(jù)PIT表項(xiàng)進(jìn)行路由轉(zhuǎn)發(fā);(2)否則,當(dāng)后續(xù)節(jié)點(diǎn)接收到DataPacket后,依據(jù)h重新計(jì)算ph大小,重復(fù)緩存決策過程.當(dāng)內(nèi)容初始請求時(shí),將以很大的概率被緩存到數(shù)據(jù)源側(cè),隨著后續(xù)內(nèi)容的不斷請求,存儲(chǔ)位置以漸進(jìn)式的方式逐跳下行推進(jìn).

3　仿真與性能分析

3.1仿真環(huán)境與參數(shù)設(shè)置

采用ndnSIM進(jìn)行仿真與性能分析,該工具對于CCN的基本數(shù)據(jù)單元結(jié)構(gòu)和路由轉(zhuǎn)發(fā)流程均已實(shí)現(xiàn),并提供了開放的源碼和運(yùn)行實(shí)例.在GT-ITM下采用Locality模型生成50個(gè)路由節(jié)點(diǎn)的平面隨機(jī)網(wǎng)絡(luò)拓?fù)?在網(wǎng)絡(luò)中設(shè)置2個(gè)內(nèi)容服務(wù)器,負(fù)責(zé)內(nèi)容集的存儲(chǔ)和實(shí)時(shí)數(shù)據(jù)流的產(chǎn)生,邊緣節(jié)點(diǎn)作為用戶接入節(jié)點(diǎn),發(fā)布內(nèi)容請求.

3.2性能分析

將本文提出的DCDS與CCN[2]和MERTS[8]進(jìn)行對比分析,性能評價(jià)指標(biāo)包括:平均請求時(shí)延(AverageRequestDelay,ARD),緩存命中率(CacheHitRatio,CHR)以及額外開銷對比.

3.2.1平均請求時(shí)延

圖4給出了γ=800kbps,ρcor=0.90和γ=1600kbps,ρcor=0.95時(shí),各方案的ARD對比,采樣時(shí)間間隔T=5s.仿真初始階段,由于所有節(jié)點(diǎn)存儲(chǔ)狀態(tài)為空,興趣包請求都需要轉(zhuǎn)發(fā)至內(nèi)容服務(wù)器進(jìn)行響應(yīng),ARD較大.但隨著內(nèi)容的不斷存儲(chǔ),節(jié)點(diǎn)緩存內(nèi)容的響應(yīng)概率逐漸增加,業(yè)務(wù)2、3對應(yīng)的ARD隨之減小.

在CCN中,一對一的逐包請求模式無法保證實(shí)時(shí)內(nèi)容的及時(shí)發(fā)送,ARD明顯大于DCDS的持久請求模式(圖4(a));對于業(yè)務(wù)2(圖4(b)),依據(jù)內(nèi)容請求序列的相關(guān)性,主動(dòng)發(fā)送對于后續(xù)關(guān)聯(lián)內(nèi)容的預(yù)測請求,增大了內(nèi)容請求的就近響應(yīng)概率,有效減小ARD;在業(yè)務(wù)3的緩存決策中,采用漸進(jìn)式的概率緩存策略,避免沿途相同內(nèi)容的重復(fù)冗余存儲(chǔ),增大了緩存內(nèi)容的利用率和就近響應(yīng)概率(圖4(c)).隨著γ的增大(800kbps到1600bps),由于DCDS和MERTS對于實(shí)時(shí)業(yè)務(wù)流不執(zhí)行緩存,可以節(jié)省更多的存儲(chǔ)空間用于其他業(yè)務(wù)內(nèi)容存儲(chǔ),ARD隨之減小.隨著ρcor取值增加,內(nèi)容請求序列相關(guān)性程度越強(qiáng),CIP報(bào)文請求的預(yù)測內(nèi)容命中率越高,業(yè)務(wù)2對應(yīng)的ARD越小(圖4(b)).

3.2.2緩存命中率

圖5給出了γ=800kbps,ρcor=0.90和γ=1600kbps,ρcor=0.95時(shí),整個(gè)仿真時(shí)間T=500s內(nèi),各方案CHR對比.由于CCN采用CE2的緩存方式,應(yīng)答內(nèi)容的重復(fù)冗余存儲(chǔ)將導(dǎo)致節(jié)點(diǎn)緩存內(nèi)容的頻繁替換更新.特別是對于實(shí)時(shí)數(shù)據(jù)的緩存,既浪費(fèi)了節(jié)點(diǎn)有限的存儲(chǔ)空間,又影響了其他業(yè)務(wù)內(nèi)容的正常緩存和后續(xù)利用,節(jié)點(diǎn)對應(yīng)的CHR明顯小于MERTS和DCDS.對于MERTS,對于實(shí)時(shí)內(nèi)容不執(zhí)行存儲(chǔ),但是對于其他業(yè)務(wù)采用的仍然是沿途普遍緩存的方式,CHR提升有限;DCDS中,在業(yè)務(wù)2、3的緩存決策中,分別采用邊緣概率和漸進(jìn)式的緩存方式,通過動(dòng)態(tài)調(diào)整緩存概率和重置歸零的方式,減小了沿途緩存冗余和內(nèi)容替換率.同時(shí),內(nèi)容存儲(chǔ)位置上的互補(bǔ)性,既增大了業(yè)務(wù)2內(nèi)容請求的就近響應(yīng)概率,又逐步將業(yè)務(wù)3對應(yīng)的流行內(nèi)容推送到網(wǎng)絡(luò)邊緣節(jié)點(diǎn),提升了緩存資源的整體利用率.圖6給出各方案平均CHR對比.

3.3開銷對比

3.3.1請求報(bào)文數(shù)量

圖7給出在實(shí)時(shí)內(nèi)容(業(yè)務(wù)1)分發(fā)時(shí),請求相同的數(shù)據(jù)流量(γ·T),各方案平均需要發(fā)送的興趣包數(shù)目,T=10s.

對于CCN,需要對每個(gè)數(shù)據(jù)包逐一發(fā)送興趣請求,發(fā)送的請求報(bào)文數(shù)量最多;MERTS執(zhí)行一對多的內(nèi)容請求模式,其發(fā)送的報(bào)文數(shù)量與具體n的取值大小緊密相關(guān);VoCCN初始時(shí)發(fā)送多個(gè)內(nèi)容請求,在數(shù)據(jù)源端使多個(gè)內(nèi)容請求同時(shí)處于未決狀態(tài),但該方案對于每一個(gè)數(shù)據(jù)包依然需要發(fā)送對應(yīng)的請求報(bào)文,產(chǎn)生的興趣包數(shù)量與CCN請求模式相當(dāng).對于DCDS,通過沿途節(jié)點(diǎn)PIT表型持久請求接口的逐條記錄,與數(shù)據(jù)源建立穩(wěn)定的傳輸關(guān)系,可實(shí)現(xiàn)實(shí)時(shí)內(nèi)容的持久接收,直到用戶發(fā)送UsIP進(jìn)行注銷操作,產(chǎn)生的興趣報(bào)文數(shù)量最小.

3.3.2業(yè)務(wù)控制開銷

(1)業(yè)務(wù)控制開銷(CC):DCDS為了提供對于多樣化業(yè)務(wù)需求的支持,在CCN原始的InterestPacket和DataPacket中增加了額外的ToT(8bits)和ToP(8bits)控制字段,以匹配不同的業(yè)務(wù)類型.代價(jià)開銷定義為額外控制字段長度(Pexa)與其傳輸路由跳數(shù)(hop)的乘積,CC=Pexa·hop,單位為bits·hops.

(2)內(nèi)容傳輸開銷(CT):定義為內(nèi)容請求過程中,請求興趣包和應(yīng)答數(shù)據(jù)包分別與其傳輸距離的乘積之和,大小取決于具體的報(bào)文長度和內(nèi)容請求傳輸?shù)穆酚商鴶?shù),CT=(PInt+PDat)·hop.其中,PInt,PDat分別表示興趣包和數(shù)據(jù)包的報(bào)文長度.

表1　代價(jià)開銷對比(業(yè)務(wù)2:α=1.2,業(yè)務(wù)3:α=0.8)

表2　代價(jià)開銷對比(業(yè)務(wù)2:α=1.4,業(yè)務(wù)3:α=1.0)

表1給出在ρcor=0.95,γ取值分別為800kbps和1600bps時(shí),各方案對應(yīng)的代價(jià)開銷對比,T=5s.在CCN中,沒有提供針對業(yè)務(wù)類型的差異化服務(wù)機(jī)制,所以不會(huì)引入額外的控制開銷,CC為0.但是,在內(nèi)容請求時(shí),單一地內(nèi)容請求和緩存模式,無法實(shí)現(xiàn)高效的內(nèi)容分發(fā),對應(yīng)的內(nèi)容傳輸開銷CT明顯大于MERTS和DCDS.在DCDS中,對于不同的業(yè)務(wù)類型,采用差異化的內(nèi)容請求和緩存方式,有效的減小了CT.相比CCN,DCDS通過少量額外控制開銷CC的付出,換取了CT的有效下降(48.8%).

分別增大業(yè)務(wù)2、3對應(yīng)的Zipf分布指數(shù)α,表2給出了對應(yīng)的代價(jià)開銷對比.隨著α指數(shù)的增大,業(yè)務(wù)2、3對應(yīng)的請求內(nèi)容更加集中在少數(shù)流行資源上,DCDS對應(yīng)的內(nèi)容請求開銷CT和控制開銷CC都得到不同程度減小.3.4適應(yīng)性討論

圖8給出了在ρcor=0.95,γ=1600kbps時(shí),各方案ARD隨節(jié)點(diǎn)緩存容量的變化趨勢.隨著節(jié)點(diǎn)緩存空間的不斷增加,更多的請求內(nèi)容可以被存儲(chǔ)在沿途節(jié)點(diǎn)上,提高了CHR,各方案對應(yīng)的ARD不斷減小.當(dāng)節(jié)點(diǎn)緩存空間較小時(shí),DCDS對于實(shí)時(shí)內(nèi)容不執(zhí)行沿途存儲(chǔ),節(jié)省了節(jié)點(diǎn)有限的存儲(chǔ)資源,增大了其他業(yè)務(wù)的緩存概率.同時(shí),在緩存決策時(shí),對于業(yè)務(wù)2和3的應(yīng)答內(nèi)容,分別采用邊緣概率和漸進(jìn)式的存儲(chǔ)方式,避免了相同內(nèi)容的重復(fù)冗余存儲(chǔ).DCDS可以有效利用節(jié)點(diǎn)的緩存空間,對于緩存容量的變化具有良好的適應(yīng)性.

圖9給出了在ρcor=0.95,γ=1600kbps時(shí),內(nèi)容請求(業(yè)務(wù)2和3)在不同的Zipf指數(shù)α取值下,各方案ARD的變化趨勢.圖9當(dāng)α取值較小時(shí),內(nèi)容請求分布不能有效集中,在α取值為0.2和0.4時(shí),業(yè)務(wù)2、3對應(yīng)的最大流行內(nèi)容請求概率僅為0.0018、0.0063和0.0005、0.0024,多樣化的內(nèi)容請求和存儲(chǔ)將導(dǎo)致緩存內(nèi)容的頻繁替換更新,增大了ARD.隨著α的增大,內(nèi)容請求的集中性不斷加強(qiáng),流行資源在緩存中的駐留概率和響應(yīng)率明顯增大,ARD逐步減小.特別是當(dāng)α取值位于0.8到1.2區(qū)間時(shí),內(nèi)容請求的集中性顯著增大,ARD大幅下降.DCDS依據(jù)業(yè)務(wù)類型,采用多樣化的內(nèi)容分發(fā)模式,有效的減小了ARD,對于α取值變化具有良好的適應(yīng)性.

4　結(jié)束語

在CCN的設(shè)計(jì)中,對于不同業(yè)務(wù)請求,單一地執(zhí)行相同的緩存決策和請求應(yīng)答模式,難以保證差異化的業(yè)務(wù)服務(wù)需求.本文從區(qū)分服務(wù)的思想出發(fā),提出了基于業(yè)務(wù)類型的多樣化內(nèi)容分發(fā)機(jī)制.DCDS依據(jù)具體的業(yè)務(wù)請求特征,分別設(shè)計(jì)了持久推送、并行預(yù)測和逐包請求的內(nèi)容分發(fā)模式,提出了透明轉(zhuǎn)發(fā)、邊緣概率緩存和漸進(jìn)式推進(jìn)的沿途存儲(chǔ)策略,實(shí)現(xiàn)了內(nèi)容傳遞對于業(yè)務(wù)類型的感知和匹配,仿真結(jié)果和對比分析顯示了其有效性.后續(xù)研究工作主要是完善、擴(kuò)展DCDS的設(shè)計(jì)思想,研究面向CCN的區(qū)分服務(wù)協(xié)議.

[1]Xylomenos G,Ververidis C,Siris V,et al.A survey of information-centric networking research[J].IEEE Commu-nications Surveys & Tutorials,2014,16(2):1024-1049.

[2]Jacobson V,Smetters D K,Thornton J D,et al.Networking named content[J].Communications of the ACM,2012,55(1):117-124.

[3]郜帥,王洪超,王凱,等.智慧網(wǎng)絡(luò)組件協(xié)同機(jī)制研究[J].電子學(xué)報(bào),2013,41(7):1261-1267.Gao Shuai,Wang Hong-chao,Wang Kai,et al.Research on cooperation mechanism of smart network component[J].Acta Electronica Sinica,2013,41(7):1261-1267.(in Chinese)

[4]Piro G,Grieco L A,Boggia G,et al.Information-centric networking and multimedia services:present and future challenges[J].Transactions on Emerging Telecommunications Technologies,2014,25(4):392-406.

[5]張國強(qiáng),李楊,林濤,等.信息中心網(wǎng)絡(luò)中的內(nèi)置緩存技術(shù)研究[J].軟件學(xué)報(bào),2014,25(1):154-175.

[6]Tsilopoulos C,Xylomenos G,and Polyzos G C.Are information-centric networks video-ready[A].IEEE International Packet Video Workshop[C].San Jose:IEEE Press,2013.1-8.

[7]Jacobson V,Smetters D K,Briggs N H,et al.VoCCN:voice-over content-centric networks[A].Proceedings of the 2009 workshop on Re-architecture the internet[C].Rome:ACM,2009.1-6.

[8]Li H B,Li Y,and Lin T.MERTS:a more efficient real-time traffic support scheme for content centric networking[A].IEEE International Computer Sciences and Convergence Information Technology[C].Seogwipo:IEEE Press,2011.528-533.

[9]Li Z and Simon G.Cooperative caching in a content centric network for video stream delivery[J].Journal of Network and Systems Management,2014:1-29.DOI:10.1007/s10-922-014-9300-1.

[10]Tsilopoulos C and Xylomenos G.Supporting diverse traffic Types in information centric networks[A].ACM SIGCOMM Workshop on Information-Centric Networking[C].Toronto:ACM,2011.13-18.

[11]Ravindran R,Wang G,Zhang X W,et al.Supporting dual-mode forwarding in content-centric network[A].IEEE International conference on Advanced Networks and Telecommunications Systems[C].Bangalore:IEEE Press,2012.55-60.

[12]朱軼,糜正琨,王文鼐.一種基于內(nèi)容流行度的內(nèi)容中心網(wǎng)絡(luò)緩存概率置換策略[J].電子與信息學(xué)報(bào),2013,35(6):1305-1310.

[13]Fricker C,Robert P,Roberts J,et al.Impact of traffic mix on caching performance in a content-centric network[A].IEEE Conference on Computer Communications Workshops[C].Orlando:IEEE Press,2012.310-315.

[14]Carofiglio G,Gallo M,Muscariello L,et al.Evaluating per-application storage management in content-centric networks[J].Computer Communications,2013,36(7):750-757.

[15]Psaras I,Clegg R G,Landa R,et al.Modelling and evaluation of ccn-caching trees[A].Proceedings of IFIP Networking[C].Valencia:Springer,2011.78-91.

[16]Kim Y,Yeom I.Performance analysis of in-network caching for content-centric networking[J].Computer Networks,2013,57(13):2465-2482.

葛國棟男,1985年生于陜西咸陽.中國人民解放軍75753部隊(duì)工程師.研究方向?yàn)樾滦途W(wǎng)絡(luò)體系結(jié)構(gòu)、內(nèi)容中心網(wǎng)絡(luò).

E-mail:ggd@mail.ndsc.com.cn

郭云飛男,1963年生于河南鄭州.國家數(shù)字交換系統(tǒng)工程技術(shù)研究中心教授、博士生導(dǎo)師.研究方向?yàn)樾滦途W(wǎng)絡(luò)體系結(jié)構(gòu)、內(nèi)容中心網(wǎng)絡(luò).

A Diverse Content Delivery Scheme Based on Traffic Types in Content Centric Networking

GE Guo-dong1,GUO Yun-fei2,LIU Cai-xia2,LAN Ju-long2

(1.Troop75753,People′sLiberationArmy,Guangzhou,Guangdong510600,China;2.NationalDigitalSwitchingSystemEngineering&TechnologicalResearchCenter,Zhengzhou,Henan450002,China)

How to provide differentiated services for diverse types of traffic poses challenges to the retrieval process of Content Centric Networking (CCN).Inspired from the idea of differentiated service,a diverse content delivery scheme based on traffic types is proposed.When requesting contents,three delivery models,namely,persistent push,parallel prediction and one-one request,are proposed according to the characteristics of the requested traffic.When making the caching decision,three on-path caching policies,including transparent forwarding,probabilistic edge caching and gradual push are implemented respectively to match the delivery models.The simulation results show that the scheme can decrease the request latency,achieve higher cache hit ratio,while improving the overall performance of content delivery with a small amount of additional control overhead.

content centric networking;differentiated service;caching strategy;traffic type

2014-09-23;

2014-11-24;責(zé)任編輯：藍(lán)紅杰

國家973重點(diǎn)基礎(chǔ)研究發(fā)展計(jì)劃(No.2012CB315901，No.2013CB329104);國家自然科學(xué)基金(No.61372121，No.61309020);國家863高技術(shù)研究發(fā)展計(jì)劃(No.2011AA01A101)

TP393

A

0372-2112 (2016)05-1124-08

電子學(xué)報(bào)URL:http://www.ejournal.org.cn10.3969/j.issn.0372-2112.2016.05.016