CCN中基于业务类型的多样化内容分发机制

葛国栋,郭云飞,刘彩霞,兰巨龙

(1.中国人民解放军75753部队，广东广州 510600；2.国家数字交换系统工程技术研究中心,河南郑州 450002)



CCN中基于业务类型的多样化内容分发机制

葛国栋1,郭云飞2,刘彩霞2,兰巨龙2

(1.中国人民解放军75753部队，广东广州 510600；2.国家数字交换系统工程技术研究中心,河南郑州 450002)

针对内容中心网络(Content Centric Networking,CCN)如何提供差异化的业务需求服务的问题,采用区分服务的思想,从内容传输和缓存决策的角度出发,提出了一种基于业务类型的多样化内容分发机制.该机制依据不同的业务请求特征,分别设计了持久推送、并行预测和逐包请求的数据分发模式,对应提出了透明转发、边缘概率缓存和渐进式推进的沿途存储策略,实现了内容传递对于业务类型的感知和匹配.仿真结果表明,该机制减小了内容请求时延,提高了缓存命中率,以少量额外的控制开销提升了CCN网络整体的内容分发性能.

内容中心网络;区分服务;缓存策略;业务类型

1　引言

随着互联网技术与应用的飞速发展,“宽带化”、“内容化”与“个性化”已成为网络发展的主旋律,人们对于数据内容的需求日益强烈,网络应用的主体逐步向内容请求服务演进[1].据Cisco VNI Mobile Forecast预测,到2014年互联网上所有内容相关的流量将占据超过97.5%的份额,传统以主机为中心的网络体系结构难以满足当前网络信息服务的要求.为了适应不断增长的数据内容访问需求,内容中心网络(Content Centric Networking,CCN)[2,3]作为一种革命式的未来互联网设计思路,将网络通信模式从关注“在哪”转变为关注“是什么”,直接表达用户和应用的通信目的,成为未来互联网设计的重要模式.在CCN设计中,直接以内容名字进行路由,当沿途节点接收到兴趣包(Interest Packet)请求后,依据内容名字依次在内容存储器(Content Store,CS)、未决请求表(Pending Interest Table,PIT)和转发信息库(Forwarding Information Base,FIB)中进行匹配查询,实现点到多点的内容分发.

CCN采用沿途普遍缓存(Cache Everything Everywhere,CE2)的方式,应答数据将在沿途转发路径的所有节点上进行存储.内容传输时,采用请求者驱动的一对一(one-request-one-data)分发模式,节点预先需要逐一发送Interest Packet,当接收到Data Packet后,再发送后续内容请求.在CCN请求和应答过程中,对于所有业务请求,仅仅依据内容名字,执行相同的匹配查询、路由转发和缓存决策,缺乏对于业务请求特征的考虑,无法提供差异化的业务需求服务[4],主要体现在两个方面:

(1)内容传输时,采用请求者驱动的一对一分发模式,节点需要预先逐一发送内容请求,产生大量兴趣报文和控制开销,浪费了上行链路的带宽资源.同时,这种机械式的逐包请求方式,对于时延敏感的实时业务,即时推送、通告类等业务类型,内容产生后将无法及时发送给请求者,增大了内容请求时延.

(2)缓存决策时,泛滥式的沿途全部缓存方式CE2,致使节点缓存内容趋于同质化,导致大量的缓存冗余[5].盲目不加区分地将所有应答内容进行缓存,既浪费了节点有限的存储空间,又增加了报文的转发处理开销.例如,对于实时流媒体,VoIP等业务类型,内容共享度低,私有性强,节点缓存内容后,无法实现后续的有效利用,而且影响了其他业务内容的正常存储.同时,在内容传输中,沿途节点逐跳的内容缓存和CS查询匹配,增大了节点的计算和处理开销.

文献[4,6]分析了信息中心网络在支持多媒体业务传输的优势和不足,对现有方案进行了对比分析,指出了目前存在的问题;文献[7]在CCN中设计了一种支持VoIP业务的传输模式(VoCCN).请求者预先发送多个兴趣请求,同时在数据源处形成未决状态,一旦内容产生,便可立即发送.该方案增大了沿途节点PIT需要存储的条目信息,逐包的内容请求模式效率低下;文献[8]针对实时业务,采用一对多的请求方式(MERTS),通过发送特殊兴趣包完成n个数据单元的同时请求.但是,该方案对于非实时业务采用的仍旧是沿途普遍缓存方式;文献[9]针对视频点播业务,提出了一种沿途协作缓存算法,节点只存储内容索引与其标签值相等的数据单元,避免相同内容的重复冗余缓存.文献[10]依据可靠性和实时性指标,将内容划分为不同业务类型,设计了差异化的内容请求模式.但是该方案缺乏对于缓存决策的考虑.文献[11]提出了一种支持快速和正常转发的双模式传输策略.对于共享内容,采用CCN原有的缓存和请求模式,对于私有内容,直接依据FIB实现快速的路由转发.

为此,本文认为在内容请求时,不仅要依据内容名字,更需要结合具体的业务类型请求特征,设计差异化的缓存决策和数据传输模式.为此,为了支持多样化的业务类型和服务需求,在CCN中提出了一种多样化内容分发机制(Diverse Content Delivery Scheme,DCDS).DCDS采用区分服务的思想,从内容缓存和传输方式的角度出发,研究业务请求特征驱动的差异化内容分发策略,实现内容传递对于业务类型的感知和匹配.

2　多样化内容分发机制

为了实现对于多样化业务类型的支持,在CCN原有的Interest Packet和Data Packet中添加业务类型(Type of Traffic,ToT)和报文类型(Type of Packet,ToP)字段.其中,ToT用于标识的不同的请求业务,ToP字段用于标识和区分不同的请求和应答报文.沿途节点依据ToT和ToP取值,执行差异化的缓存策略和内容传输模式.

本文考虑三种业务类型:(1)实时业务.例如,实时流媒体业务,VoIP等.该类业务实时性强,内容产生后必须立即发送给请求者,对于请求时延要求严格.同时,内容后续共享程度小,私有性强.(2)非实时的流媒体业务.例如视频点播业务.该类业务后续共享程度高,包含的内容文件大,一般被划分为多个数据块单元(chunks),用户按照顺序逐次请求,连续内容请求之间具有强的相关性[12],时延要求低于实时业务,但对于带宽资源要求大;(3)用户自产生内容(User Generate Content,UGC)[13,14].例如,静态图片、文本信息共享等.该类业务内容文件小,内容数量大,不同请求之间没有明显的相关性,对于时延和带宽没有明显要求.

图1给出了DCDS工作流程,沿途节点依据ToT和ToP标识,判断所属业务类型,执行对应的内容请求和缓存策略,具体包括持久推送,并行预测和逐包请求三种内容分发模式.

2.1持久推送模式

对于该类业务请求:(1)实时性强,对于时延要求严格,内容产生后必须立即发送给请求者.CCN基于请求者驱动的一对一传输模式无法保证内容请求时延,而且会引入大量的请求报文开销;(2)内容私有性强,共享度低.对于该类业务数据的存储,无法实现后续的有效利用,又浪费了节点有限的存储空间.

为此,对于该类业务请求采用持久推送,快速转发的分发策略:(1)请求者发送持久兴趣请求,建立与数据源之间稳定的传输关系,避免逐一的报文请求,实现实时内容的即时发送;(2)沿途节点对于该类业务数据不执行缓存操作,无需进行CS的查询匹配,实现报文的透明转发,加快处理速度.

2.1.1内容请求

业务类型ToT=00,报文类型ToP包括:(1)持久兴趣包(00),PIP(Persistent Interest Packet);(2)持久数据包(01),PDP(Persistent Data Packet);(3)更新兴趣包(10),UIP(Update Interest Packet);(4)注销兴趣包(11),UsIP(Un-subscribe Interest Packet).

在上行请求过程中,当沿途节点接收到Interest Packet后,首先查看ToT和ToP字段,确定业务和报文类型.如图2所示,如果ToT=00,ToP=00,则表示持久兴趣请求PIP.沿途节点无需执行CS查询匹配,在PIT表项中添加请求条目,并标记该请求接口为持久兴趣请求,然后按照FIB表项执行上行转发(步骤①);如果该内容已被请求,而来自不同接口,则在PIT条目中添加对应接口信息(步骤②).当数据源接收到持久请求PIP,每当内容产生后,立即向对应的请求接口发送应答内容PDP,无需预先逐一的内容请求(步骤③).沿途节点依据对应的持久请求接口信息,实现应答内容的反向传输.

2.1.2数据应答

当下行节点接收到Data Packet后,查看ToT和ToP字段,如果接收到的是PDP报文,节点CS不执行应答内容缓存,直接查询PIT表项,执行PDP的下行转发(步骤③),加快应答报文回传速度.如果请求接口为持久兴趣请求,内容应答后,对应的PIT条目并不进行删除,直至其过期或者接收到用户主动发送的UsIP取消操作,再进行删除操作.

2.1.3缓存决策

节点查看ToT字段,如果为第一类业务请求,在上行传输时,无需执行CS的逐跳匹配查询,在下行应答时,沿途节点不执行内容缓存操作,直接依据PIT表项进行PDP转发.对于该类业务请求,报文的透明传输和快速转发,减小了实时内容的请求时延,同时也增大了其他业务内容缓存概率,提升了节点缓存空间整体利用率.

2.2并行预测模式

对于该类业务请求:(1)内容共享度高,可以被后续反复请求,沿途节点对于该类数据的缓存可以有效提高后续请求的就近响应;(2)内容文件大,对于带宽资源要求高.如果内容请求都发送至内容源处进行响应,将消耗大量的网络带宽资源.为此,在缓存决策时,如果能将该类业务内容缓存至网络边缘,将大大减小网络流量传输和带宽需求;(3)内容包含多个数据块单元,用户需要连续发送多个兴趣请求.若能提前预测并执行后续数据单元的并行请求,将大大减小内容请求时延.

为此,对于该类业务请求采用并行预测,边缘存储的分发策略:(1)依据内容请求序列间的相关性特征,主动发送对后续相关数据单元的并行请求,预先获取并缓存内容;(2)将应答内容以概率方式推送至网络边缘进行存储,减小沿途缓存冗余和网络流量传输.

2.2.1内容请求

业务类型码ToT=01,报文类型包括:(1)兴趣包(00);(2)数据包(01);(3)相关兴趣包(10),CIP(CorrelatedInterestPacket);(4)相关数据包(11),CDP(CorrelatedDataPacket,CDP),其中CIP和CDP用于标识节点基于相关性发出的预测请求和应答报文.

定义1内容请求相关系数ρcor:ρcor用于定量地描述内容请求序列之间的相关性程度,表示同一内容对象,相邻chunk单元被连续请求的概率大小:

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

(1)其中,0≤ρcor≤1,rn+1,rn分别表示第n和n+1次发送的内容请求,∀ i,Ci和Ci+1属于同一内容对象,且代表了连续的数据块单元.ρcor取值越大,数据块请求序列之间的相关性越强,CIP报文请求的预测内容命中率越高.

在上行内容请求过程中,沿途节点接收到兴趣包后,查看ToT和ToP字段,确定业务和报文类型.如图3所示,如果ToT=01,ToP=00,则表示用户发送的正常兴趣请求(步骤①).当缓存命中节点发送DataPacket对当前请求应答时(步骤②),主动发送CIP报文,执行下一相关数据单元的预测请求(步骤③).当请求节点接收到CDP报文后,由于无法确定用户是否会在短时间内发送下一数据单元请求,对于预测内容首先进行临时缓存(红色方框所示),缓存时间设为ttem(步骤④).如果在ttem内,没有接收到后续请求,说明该次请求预测错误,在CS中标记该内容为“可替换”状态.当节点执行缓存替换时,优先淘汰“可替换”内容.如果在ttem周期内,节点接收到用户发送的兴趣请求,在CS中正式缓存该预测内容,其存储位置更新为CS最顶层,并删除临时缓存时间选项,执行正常的LRU替换策略(图3-3步骤④).

2.2.2数据应答

当下游节点接收到应答数据后,查看ToP字段,如果为正常的应答数据报文,按照2.2.3节提出的边缘概率缓存策略确定内容的目标存储节点.当节点执行内容缓存后,该内容将被添加到CS最顶层.当下游节点接收到相关数据报文CDP时,由于该内容是基于相关性发起的预测请求,沿途节点不进行缓存,直接依据PIT表项将该内容发送至请求节点.

2.2.3缓存决策

沿途节点以概率方式执行缓存决策,随着应答数据的逐跳下行传输,缓存概率不断增大,将请求内容推送至网络边缘进行存储.同时,采用累加和重置的方式,动态调节缓存概率大小,避免沿途内容的重复冗余缓存.

(1)内容请求者(ContentConsumer)vc发送兴趣请求,通过兴趣包的上行逐跳传输,依次记录并更新传输路径长度l,每当兴趣包到达下一节点,传输跳数加1.最终,当InterestPacket到达内容提供者(ContentProvider)vp后,l记录的就是沿途传输路径节点的个数.

(2)当vp发送数据包进行应答时,依据l取值首先计算沿途节点的初始缓存概率ph:

(2)其中,h为当前节点距离内容提供者vp的路由跳数,节点距离数据源越远,缓存概率越大.当下行节点接收到DataPacket后,以累加缓存概率ps决定是否缓存应答内容:

(3)

(1)如果缓存,将累加缓存概率ps置为0.当后续节点接收到应答包后,如果ps已被置0,说明上行节点已经缓存了应答内容,后续节点将不执行内容存储,直接依据PIT表项进行路由转发,避免相同内容的重复存储;(2)否则,ps将不断累加,更新为已有转发节点的缓存概率之和,以增大后续节点的存储概率.

2.3逐包请求模式

对于该类业务请求:(1)内容共享程度高,可以被后续反复请求,沿途缓存可有效提高内容请求的就近应答;(2)对于带宽和时延没有严格要求,应答内容返回时,可考虑向数据源侧进行缓存,与并行预测模式下提出的边缘存储策略实现存储位置的相对分离和互相补充,提升网络节点缓存空间的整体利用率.

为此,对于该类业务采用逐包请求,渐进式缓存的分发策略:(1)初始请求时,应答数据优先考虑向数据源侧进行存储,伴随后续内容的不断请求,以渐进式的方式逐步将流行内容推送至网络边缘存储;(2)内容请求时,采用CCN逐包请求模式,当请求者接收到应答内容后,再发送后续请求.

2.3.1内容请求与数据应答

业务类型码ToT=10,报文类型码ToP包括:(1)兴趣包(00);(2)数据包(01).

内容请求采用一对一逐包请求模式,用户发送内容请求,沿途任何存储该请求内容的节点都可发送DataPacket进行响应,下行节点按照2.3.2节提出的渐进式存储策略执行沿途内容存储.当请求节点接收到对应的应答内容后,发送下一内容请求.

2.3.2缓存决策

沿途节点以概率的方式执行缓存决策,随着DataPacket下行传输,缓存概率不断减小,优先在数据源侧存储应答内容;同时,采用重置归0的方式,动态调整节点缓存概率,避免沿途内容的重复冗余缓存.

内容请求者vc发送Interestpacket请求,通过兴趣包上行的逐跳传输,依次记录并更新传输路径长度l,每当兴趣包到达下一跳节点,传输跳数加1.最终,当InterestPacket到达vp后,l记录的就是传输路径节点的个数.当vp发送DataPacket进行应答时,依据l首先计算沿途节点初始缓存概率ph:

(4)

当下行节点接收到DataPacket后,以ph决定是否缓存该应答内容:(1)如果缓存,将缓存概率ph置为0.当后续节点接收到应答包后,如果ph已被置0,说明上行节点已经缓存了应答内容,后续节点将不执行内容存储,直接依据PIT表项进行路由转发;(2)否则,当后续节点接收到DataPacket后,依据h重新计算ph大小,重复缓存决策过程.当内容初始请求时,将以很大的概率被缓存到数据源侧,随着后续内容的不断请求,存储位置以渐进式的方式逐跳下行推进.

3　仿真与性能分析

3.1仿真环境与参数设置

采用ndnSIM进行仿真与性能分析,该工具对于CCN的基本数据单元结构和路由转发流程均已实现,并提供了开放的源码和运行实例.在GT-ITM下采用Locality模型生成50个路由节点的平面随机网络拓扑,在网络中设置2个内容服务器,负责内容集的存储和实时数据流的产生,边缘节点作为用户接入节点,发布内容请求.

3.2性能分析

将本文提出的DCDS与CCN[2]和MERTS[8]进行对比分析,性能评价指标包括:平均请求时延(AverageRequestDelay,ARD),缓存命中率(CacheHitRatio,CHR)以及额外开销对比.

3.2.1平均请求时延

图4给出了γ=800kbps,ρcor=0.90和γ=1600kbps,ρcor=0.95时,各方案的ARD对比,采样时间间隔T=5s.仿真初始阶段,由于所有节点存储状态为空,兴趣包请求都需要转发至内容服务器进行响应,ARD较大.但随着内容的不断存储,节点缓存内容的响应概率逐渐增加,业务2、3对应的ARD随之减小.

在CCN中,一对一的逐包请求模式无法保证实时内容的及时发送,ARD明显大于DCDS的持久请求模式(图4(a));对于业务2(图4(b)),依据内容请求序列的相关性,主动发送对于后续关联内容的预测请求,增大了内容请求的就近响应概率,有效减小ARD;在业务3的缓存决策中,采用渐进式的概率缓存策略,避免沿途相同内容的重复冗余存储,增大了缓存内容的利用率和就近响应概率(图4(c)).随着γ的增大(800kbps到1600bps),由于DCDS和MERTS对于实时业务流不执行缓存,可以节省更多的存储空间用于其他业务内容存储,ARD随之减小.随着ρcor取值增加,内容请求序列相关性程度越强,CIP报文请求的预测内容命中率越高,业务2对应的ARD越小(图4(b)).

3.2.2缓存命中率

图5给出了γ=800kbps,ρcor=0.90和γ=1600kbps,ρcor=0.95时,整个仿真时间T=500s内,各方案CHR对比.由于CCN采用CE2的缓存方式,应答内容的重复冗余存储将导致节点缓存内容的频繁替换更新.特别是对于实时数据的缓存,既浪费了节点有限的存储空间,又影响了其他业务内容的正常缓存和后续利用,节点对应的CHR明显小于MERTS和DCDS.对于MERTS,对于实时内容不执行存储,但是对于其他业务采用的仍然是沿途普遍缓存的方式,CHR提升有限;DCDS中,在业务2、3的缓存决策中,分别采用边缘概率和渐进式的缓存方式,通过动态调整缓存概率和重置归零的方式,减小了沿途缓存冗余和内容替换率.同时,内容存储位置上的互补性,既增大了业务2内容请求的就近响应概率,又逐步将业务3对应的流行内容推送到网络边缘节点,提升了缓存资源的整体利用率.图6给出各方案平均CHR对比.

3.3开销对比

3.3.1请求报文数量

图7给出在实时内容(业务1)分发时,请求相同的数据流量(γ·T),各方案平均需要发送的兴趣包数目,T=10s.

对于CCN,需要对每个数据包逐一发送兴趣请求,发送的请求报文数量最多;MERTS执行一对多的内容请求模式,其发送的报文数量与具体n的取值大小紧密相关;VoCCN初始时发送多个内容请求,在数据源端使多个内容请求同时处于未决状态,但该方案对于每一个数据包依然需要发送对应的请求报文,产生的兴趣包数量与CCN请求模式相当.对于DCDS,通过沿途节点PIT表型持久请求接口的逐条记录,与数据源建立稳定的传输关系,可实现实时内容的持久接收,直到用户发送UsIP进行注销操作,产生的兴趣报文数量最小.

3.3.2业务控制开销

(1)业务控制开销(CC):DCDS为了提供对于多样化业务需求的支持,在CCN原始的InterestPacket和DataPacket中增加了额外的ToT(8bits)和ToP(8bits)控制字段,以匹配不同的业务类型.代价开销定义为额外控制字段长度(Pexa)与其传输路由跳数(hop)的乘积,CC=Pexa·hop,单位为bits·hops.

(2)内容传输开销(CT):定义为内容请求过程中,请求兴趣包和应答数据包分别与其传输距离的乘积之和,大小取决于具体的报文长度和内容请求传输的路由跳数,CT=(PInt+PDat)·hop.其中,PInt,PDat分别表示兴趣包和数据包的报文长度.

表1　代价开销对比(业务2:α=1.2,业务3:α=0.8)

表2　代价开销对比(业务2:α=1.4,业务3:α=1.0)

表1给出在ρcor=0.95,γ取值分别为800kbps和1600bps时,各方案对应的代价开销对比,T=5s.在CCN中,没有提供针对业务类型的差异化服务机制,所以不会引入额外的控制开销,CC为0.但是,在内容请求时,单一地内容请求和缓存模式,无法实现高效的内容分发,对应的内容传输开销CT明显大于MERTS和DCDS.在DCDS中,对于不同的业务类型,采用差异化的内容请求和缓存方式,有效的减小了CT.相比CCN,DCDS通过少量额外控制开销CC的付出,换取了CT的有效下降(48.8%).

分别增大业务2、3对应的Zipf分布指数α,表2给出了对应的代价开销对比.随着α指数的增大,业务2、3对应的请求内容更加集中在少数流行资源上,DCDS对应的内容请求开销CT和控制开销CC都得到不同程度减小.3.4适应性讨论

图8给出了在ρcor=0.95,γ=1600kbps时,各方案ARD随节点缓存容量的变化趋势.随着节点缓存空间的不断增加,更多的请求内容可以被存储在沿途节点上,提高了CHR,各方案对应的ARD不断减小.当节点缓存空间较小时,DCDS对于实时内容不执行沿途存储,节省了节点有限的存储资源,增大了其他业务的缓存概率.同时,在缓存决策时,对于业务2和3的应答内容,分别采用边缘概率和渐进式的存储方式,避免了相同内容的重复冗余存储.DCDS可以有效利用节点的缓存空间,对于缓存容量的变化具有良好的适应性.

图9给出了在ρcor=0.95,γ=1600kbps时,内容请求(业务2和3)在不同的Zipf指数α取值下,各方案ARD的变化趋势.图9当α取值较小时,内容请求分布不能有效集中,在α取值为0.2和0.4时,业务2、3对应的最大流行内容请求概率仅为0.0018、0.0063和0.0005、0.0024,多样化的内容请求和存储将导致缓存内容的频繁替换更新,增大了ARD.随着α的增大,内容请求的集中性不断加强,流行资源在缓存中的驻留概率和响应率明显增大,ARD逐步减小.特别是当α取值位于0.8到1.2区间时,内容请求的集中性显著增大,ARD大幅下降.DCDS依据业务类型,采用多样化的内容分发模式,有效的减小了ARD,对于α取值变化具有良好的适应性.

4　结束语

在CCN的设计中,对于不同业务请求,单一地执行相同的缓存决策和请求应答模式,难以保证差异化的业务服务需求.本文从区分服务的思想出发,提出了基于业务类型的多样化内容分发机制.DCDS依据具体的业务请求特征,分别设计了持久推送、并行预测和逐包请求的内容分发模式,提出了透明转发、边缘概率缓存和渐进式推进的沿途存储策略,实现了内容传递对于业务类型的感知和匹配,仿真结果和对比分析显示了其有效性.后续研究工作主要是完善、扩展DCDS的设计思想,研究面向CCN的区分服务协议.

[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]郜帅,王洪超,王凯,等.智慧网络组件协同机制研究[J].电子学报,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]张国强,李杨,林涛,等.信息中心网络中的内置缓存技术研究[J].软件学报,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]朱轶,糜正琨,王文鼐.一种基于内容流行度的内容中心网络缓存概率置换策略[J].电子与信息学报,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部队工程师.研究方向为新型网络体系结构、内容中心网络.

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

郭云飞男,1963年生于河南郑州.国家数字交换系统工程技术研究中心教授、博士生导师.研究方向为新型网络体系结构、内容中心网络.

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;责任编辑：蓝红杰

国家973重点基础研究发展计划(No.2012CB315901，No.2013CB329104);国家自然科学基金(No.61372121，No.61309020);国家863高技术研究发展计划(No.2011AA01A101)

TP393

A

0372-2112 (2016)05-1124-08

电子学报URL:http://www.ejournal.org.cn10.3969/j.issn.0372-2112.2016.05.016