Scalable Aggregation-based Packet Forwarding inContent Centric NetworkingAnselme Ndikumana, Saeed Ullah and Choong Seon Hong*

Department of Computer Science and Engineering, Kyung Hee University, Rep. of Korea{anselme, saeed, cshong}@khu.ac.kr

Abstract— Content Centric Networking (CCN) is one of theFuture Internet architectures that aims at improving contentdistribution and retrieval, where content is requested by namerather than IP address. Each content is partitioned into smallunits, namely chunks. In CCN, the consumer sends Interestpacket in order to get a chunk of Data. Upon successful receptionof the requested chunk, the consumer sends the next Interestpacket. This policy of send Interest, wait for the Data to reach andgenerate next Interest makes the situation worst in case of largesized content. The result is uplink underutilization. To overcomethe above highlighted issue, we propose Interest forwarding inCCN, which is based on packet aggregation through combiningmultiple chunk requests in one Interest packet, and content nameaggregation. The Interest packet aggregation will reduce thenumber of Interest packets need to be sent in the network anddownsize Pending Interest Table (PIT), while organizing contentbased on aggregated name reduces Content Store (CS) entries.The simulation results show that our proposal achieves highperformance with throughput improvement, reduced number ofInterest packets in network, PIT and CS entries over otherexisting proposal in the literature.

Index Terms—Content Centric Networking, CCN Forwarding,packet aggregation, Content Store, Pending Interest Table.

I. INTRODUCTION

MAny research projects such as NSF GENI, EU FIA,etc., were supported for defining new Future Internet

(FI) architecture [1]. Content Centric Networking (CCN) [2]is one of the FI architectures that aims at improving contentdistribution and retrieval, where content is forwarded androuted by name rather than IP address, as the replacementof currently IP-based Internet Architecture.

In CCN, they are two types of packets: (1) the Interestpacket, which is used to request chunk, and (2) the Datapacket (chunk), which is transmitted back to the end-userin reverse path of the Interest packet, as a response to therequested chunk. Each node on transmission path can cachethe chunks, in order to serve future requests for the samechunks from other end-users/ consumers. With the help ofthree main CCN Data structures, namely Content Store (CS)or memory, Pending Interest Table (PIT) and ForwardingInformation Base (FIB), when a node receives Interest packet,it checks if the requested chunk is stored in its CS; in caseof hit, it forwards chunk to the consumer through the reverse

This work was supported by Institute for Information & communicationsTechnology Promotion (IITP) grant funded by the Korea government (MSIP)(B0190-16-2017, Resilient/Fault-Tolerant Autonomic Networking Based onPhysicality, Relationship and Service Semantic of IoT Devices). *Dr. CS Hongis the corresponding author.

path of Interest packet. Otherwise, the node checks in PIT,which records unsatisfied Interest packets and their incomingfaces. If the node finds similar entry in PIT, it appends Interestto the existing entry, otherwise it creates new PIT entry. Aftercreating a new entry, the node checks FIB to determine whereand how to forward Interest packet through the use forwardingstrategy [2].

In CCN, we consider forwarding as a process of receivingpackets from incoming face(s), processing them through theuse of CS, FIB, PIT, and forwarding them to the output face(s).In other words, on receiving Interest packet from incomingface, node forwards Interest packet to the outgoing face(s)after missing requested chunk in CS or similar entry in PIT.As PIT and CS contribute in limiting the number of Interestpackets need to be forwarded to the outgoing face(s). In thispaper, we focus on reducing the number of Interest packetsneed to be sent in the network, PIT and CS entries throughInterest packet and content name aggregation.

The rest of the paper is organized as follows, section IIcontains a description of the problem statement and motiva-tion. Section III discusses CCN forwarding overview, whileaggregation-based packet forwarding is discussed in sectionIV. Section V provides evaluation of the proposed forwardingmechanism. We conclude the paper with conclusion and futuredirections in section VI.

II. PROBLEM STATEMENT AND MOTIVATION

In name-based packet forwarding, each content is parti-tioned into small units, namely chunks. The consumer sendsInterest packet in order to get a chunk of Data. Upon suc-cessful reception of the requested chunk, the consumer sendsthe next Interest packet. This policy of send Interest, waitfor the Data to reach and generate next Interest makes thesituation worst in case of large sized content. The result isuplink underutilization. To overcome this issue, in [3], theauthors proposed the use of one Interest packet to request aspecific number of segments within a range, where segmentrange is specified in the range field called window size.When a node received the Interest packet with range field, itgenerates self-generated Interest packets, which may increasethe processing time, and then processes each self-generatedInterest separately. The proposed pipeline method in [2] andsliding window in [4] can adjust the sending rates, but do notreduce the number of Interest packets need to be sent in thenetwork.

© Copyright IEICE – The 18th Asia-Pacific Network Operations and Management Symposium (APNOMS) 2016

In this paper, we propose CCN forwarding, which isbased on packet and content name aggregation by combiningmultiple chunk requests in one Interest packet. The packetaggregation will reduce the number of packets need to besent over the network, downsize Pending Interest Table (PIT),while organizing content based on aggregated content namereduces Content Store (CS) entries. In our proposal, thereis no need for self-generated Interest, once Interest packetreaches a node which has requested Data chunk(s), nodereturns corresponding chunk(s) to consumer (s), and forwardsunsatisfied chunk request(s) to upstream node.

III. CCN FORWARDING OVERVIEW

Forwarding process consists of receiving the packet frominput link, and forwarding or moving it to the appropriateoutput link. In CCN, taking a packet from input link andmove it to an output link requires some internal process, whichinvolves the use of three main Data structures; Content Store,which caches Data chunks, Pending Interest Table, whichrecords unserved Interest packets and their incoming faces,and Forwarding Information Base, which store forwardingdirectives [5].

Each content is partitioned into small chunks, where eachchunk is requested by name. To request a chunk of thecontent, the chunk number must be added to content name.The objective of using chunk numbers is to identify the chunksbelongs to the same content. In additional to that, the chunksize is too small, which result in its fast forwarding and routingover the network. Each packet has a unique name which isused in forwarding decision. In the name includes object name,chunk number and other fields such as nonce number, Interestlifetime, and signature, etc. All chunks with the same objectname belongs to the same content, in which can be used todistinguish flows belongs to different contents [6] during theforwarding process.

Forwarding Interest packet requires a sequential name orprefix lookup in CS, PIT and FIB, while forwarding Datapacket requires lookup in PIT and CS. Longest Prefix Match(LPM) is used in FIB lookup, while Exact Matching (EM)is used in CS and PIT lookup [7]. In CCN, we do not havesource and destination addresses like in current IP network, allforwarding process is based on packet name. On reception ofInterest packet node performs sequential lookup starting fromCS, when it does not find requested content in CS, it checksin PIT to see if there is a similar request from other consumer;in case of the absence of similar request, it continues thechecking in FIB. In FIB, forwarding strategy takes a decisionon which face to use for forwarding Interest packet to upstreamnode. The Forwarding decision is based on available outgoingfaces, and network condition such as delay, etc. In the absenceof available face to use, node discards Interest packet. Oncethe upstream node finds requested chunk in its CS, it returnschunk in the reverse path of Interest packet.

IV. AGGREGATION-BASED PACKET FORWARDING

In CCN, user requests content partitioned into chunks, andone Interest packet is issued for one chunk. When the Interest

packet is sent-out, after receiving the corresponding chunk,the next Interest packet requesting next chunk is transmitted.For the content with big size, requires users to emit manyInterest packets, which results in uplink underutilization andunnecessary increase of delay. To overcome these issues,in this section, we present in details our proposed scalableaggregation-based packet forwarding for CCN, which is basedon Interest packet and content name aggregation.

A. Content naming

In CCN, each chunk is requested and retrieved by name,where content name plays an important role in forwarding androuting. There are three main categories of naming schemes,namely hierarchical, flat and attribute value based naming. Asof now, there is no standard for CCN naming; the choice ofappropriate naming scheme among them raises an importantchoice question, whether we should use human affable namessuch as hierarchical name rather than flat or attributes valuebased names [8]. Consequently, each publisher is free tochoose the appropriate names for his contents. However, thelength of content name has to be in reasonable size for makingsure that CS, PIT and FIB do not become too large.

In this paper, for content naming, we use hierarchicalnaming, where content name is composed of sequence of com-ponents separated by delimiter /. The size of components mayvary, depends on content publisher and content organization.We use reserved domain name and directory path as contentname [7], such as kr/ac/ce/ccn/, which is the reverse domainof ce.ac.kr, and /ccn as directory name. As described in oursystem architecture, figure 1, for getting the content, consumersends Interest packet kr/ac/ce/ccn/1/2/...../n, where / isused as components delimiter, and /1/2/...../n representschunk numbers requested in one Interest packet.

On reception of Interest packet, node checks in CS, incase of miss, it continues in PIT, where all PIT entries aretemporally stored based on Interest name which combiningmany chunk requests together. In figure 2, as an example,

Fig. 1. Aggregation-based packet forwarding

instead of having three entries such as kr/ac/ce/ccn/1,kr/ac/ce/ccn/2, kr/ac/ce/ccn/3, we can have one entry

kr/ac/ce/ccn/1/2/3, which combining three chunks 1, 2,and 3 together. This aggregation results in reducing PITentries, and depends on Interest arrival time. After creatingPIT entry, node continues in FIB through the use of LPM,in order to determine the outgoing face that will be usedto forward Interest packet. Through the use of forwardingstrategy, node forwards Interest packet to upstream nodebased on prefix name (eg. kr/ac/ce/ccn/). For routing theInterest packets, Name-data Link State Routing Protocol [9]can be used for creating routing table, where each publisherannounces the name prefix of his content. Then based on prefixname, each node can select the appropriate outgoing face thatwill be used for forwarding Interest packet to outgoing face.In FIB, the node uses abject name as prefix name such askr/ac/ce/ccn/ instead of kr/ac/ce/ccn/1/2/...../n. In otherwords, forwarding packets to outgoing face is based on abjectname and not on full packet name. In order to satisfy the future

Fig. 2. Proposed content name aggregation

requests of the same chunk from other consumers, on receptionof chunk from upstream node, node caches chunk in CS. Forcaching chunks, node combines also many chunks togetherbased on their names such as kr/ac/ce/ccn/1/2/....../nrather that storing each chunk separately; i.e. in aggregatedname based caching, one or many chunks with the sameobject name are combined together. This results in reducingCS entries without affecting cache hit.

B. Forwarding based on packet aggregation

In this sub-section, we present in details our forwardingbased on packet aggregation, which combine multiple chunkrequests together in one Interest packet. The objective of thiscombination is to reduce the number of Interest packets needto be sent over the network, this result in downsizing PIT,while content name aggregation contributes in reducing CSentries.

During the packet aggregation, many chunk requests areaggregated in one Interest packet. In general, the InterestPacket is too small, and combining many chunk requests in one

Interest packet will not create any problem in uplink, becausemost of the problems happens in CCN network such bufferoverflow, delay, and packet loss are caused by returning chunksin downlink. For improving CCN forwarding efficiency via

Algorithm 1 Algorithm for Interest packet aggregation1: Input: InterestPacket, MaxAggregationSize,

SequenceNumber, InterestLifetime2: while InterestPacket ≤MaxAggregationSize do3: if InterestLifetime = 0 then4: RetransmitInterestPacket5: exit6: else7: ChunkNumber = SequenceNumber8: ChunkNumber ++9: InterestPacket.add(ChunkNumber)

10: end if11: end while12: SendInterestPacket

combining many chunk requests into one Interest packet, wedefined a procedure presented in algorithm 1 for Interestpacket aggregation, which is implementable at the end-user/consumer node. Each request has chunk number, with the useof chunk number, node combines many chunks belongs tothe same object together. The node appends chunk numbersto the initial interest name with the use of / componentdelimiter. The objective of using component delimiter / be-tween chunk numbers is to facilitate name-based lookup, andhash table operations such as insertion, search, etc. From thebeginning, consumer initiates request with one chunk request,then the consumer node increases the number of chunks up ton − 1, combines them in one Interest packet, and forwardsit to the outgoing faces. Each Interest packet requestingmany chunks must be less or equal to maximum aggregationsize (MaxAggregationSize). Our proposed CCN forwardingmechanism can work alone or combined with sliding window(pipeline) for adjusting requests, where one Interest packetrequesting many chunks can be used as initial window.

V. PERFORMANCE EVALUATION

In this section, we present performance evaluation of ourforwarding proposal, represented by Prop Forward in thefigures; by comparing it with original CCN flooding or multi-casting, represented by Orig CCN in the figures. In flooding,after receiving an Interest packet needs to be forwarded, nodeforwards Interest to all its upstream node(s). We use ns-3 basedsimulator, namely ndnSIM [10] [11].

In our network topology, we use nine nodes with oneconsumer, one publisher, and seven intermediate nodes. Eachlink has 10Mbps of symmetric bandwidth and 1 ms ofpropagation delay. Each node has buffer size of 200 packetswith First-In First-Out (FIFO) queue discipline. The pay-load size is 1040 bytes and MaxAggregationSize is 1040.For routing the packets, we use an automatic shortest pathrouting algorithm, namely global routing helper, which issimilar to IPv4GlobalRoutingHelperndnSIM [10]. Consumernode generates 1000 Interest packets per second. Each Interest

packet has 2 seconds of Interest lifetime. For caching content,each node has a cache capacity of 1000 chunks. For cachingreplacement policy, we use Least Recently Used (LRU).

A. Experimental Results

Figure 3 presents the average PIT entries. We compare ourproposal with original CCN proposal in terms of PIT entries.Our proposal reduces 16.37% of the total number of PITentries as compared to the original CCN.

Fig. 3. Average number of PIT entries

Figure 4 presents the total number of Interest packetsemitted by consumer node during the simulation period (40seconds). Many chunk requests are combined into one Interestpacket, except the Interest packets need to be retransmitted dueto timeout or expiration of the Interest lifetime. Our proposalreduces 26.71% of the total number of Interest packets ascompared to the original CCN.

Fig. 4. Comparison of total number of transmitted interests

For the average number of CS entries, where averagenumber of CS entries represents the total content cached intransmission path between Consumer and publisher. There isno too much difference between our proposal and originalCCN proposal, given the fact that MaxAggregationSize isset to be equal to chunk size. This results in limiting thenumber of chunks need to be combined in one chunk, in orderto avoid congestion in down-link.

We compared the throughput of our proposed forwardingmechanism with original CCN forwarding, the simulationresults show that our proposal performs better than existingCCN proposal. On the other side, the original CCN has lowerdelay (0.427%) than our proposed forwarding mechanism dueto the packet aggregation. Even throughput improvement hasto go with an increase of delay, as Interest packet must waitwhile many chunk requests are being combined in one Interestpacket. We plan to extend ndnSIM and perform more analysisin bid of reducing packet delay during the packet aggregation.

VI. CONCLUSION AND FUTURE DIRECTIONS

In this paper, we solved the problem related to the retrievingcontent with big size, where consumer sends Interest, waits forthe Data to reach and generates next Interest, which results inuplink underutilization. We propose a scalable aggregation-based packet forwarding for Content Centric Networking,which is based on packet aggregation for reducing the numberof Interest packets need to be sent over the network, throughcombining multiple chunk requests in one Interest packet. Thepacket and content name aggregation results in improving linkutilization, downsizing Pending Interest Table and ContentStore. The simulation results show that our proposal reducesthe number of Interest packets sent in network, downsizesPending Interest Table, while organizing content based onname aggregation reduces Content Store entries. In the future,we aim to extend our work with more analysis.

REFERENCES

[1] G. Carofiglio, M. Gallo, L. Muscariello, and D. Perino, “Modelingdata transfer in content-centric networking,” in Proceedings of the 23rdinternational teletraffic congress. International Teletraffic Congress,2011, pp. 111–118.

[2] V. Jacobson, D. K. Smetters, J. D. Thornton, M. F. Plass, N. H. Briggs,and R. L. Braynard, “Networking named content,” in Proceedings of the5th international conference on Emerging networking experiments andtechnologies. ACM, 2009, pp. 1–12.

[3] D. Byun, B.-J. Lee, and M.-W. Jang, “Adaptive flow control via interestaggregation in ccn,” in Communications (ICC), 2013 IEEE InternationalConference on. IEEE, 2013, pp. 3738–3742.

[4] A. Ndikumana, S. Ullah, R. Kamal, K. Thar, H. S. Kang, S. I. Moon, andC. S. Hong, “Network-assisted congestion control for information cen-tric networking,” in Network Operations and Management Symposium(APNOMS), 2015 17th Asia-Pacific. IEEE, 2015, pp. 464–467.

[5] H. Yuan, T. Song, and P. Crowley, “Scalable ndn forwarding: Concepts,issues and principles,” in Computer Communications and Networks(ICCCN), 2012 21st International Conference on. IEEE, 2012, pp.1–9.

[6] S. Oueslati, J. Roberts, and N. Sbihi, “Flow-aware traffic control fora content-centric network,” in INFOCOM, 2012 Proceedings IEEE.IEEE, 2012, pp. 2417–2425.

[7] H. Dai, J. Lu, Y. Wang, and B. Liu, “Bfast: Unified and scalableindex for ndn forwarding architecture,” in Computer Communications(INFOCOM), 2015 IEEE Conference on. IEEE, 2015, pp. 2290–2298.

[8] M. F. Bari, S. R. Chowdhury, R. Ahmed, R. Boutaba, and B. Mathieu,“A survey of naming and routing in information-centric networks,”Communications Magazine, IEEE, vol. 50, no. 12, pp. 44–53, 2012.

[9] A. Hoque, S. O. Amin, A. Alyyan, B. Zhang, L. Zhang, and L. Wang,“Nlsr: named-data link state routing protocol,” in Proceedings of the 3rdACM SIGCOMM workshop on Information-centric networking. ACM,2013, pp. 15–20.

[10] A. Afanasyev, I. Moiseenko, and L. Zhang, “ndnSIM: NDN simulatorfor NS-3,” NDN, Technical Report NDN-0005, October 2012. [Online].Available: http://named-data.net/techreports.html

[11] S. Mastorakis, A. Afanasyev, I. Moiseenko, and L. Zhang, “ndnSIM 2.0:A new version of the NDN simulator for NS-3,” NDN, Technical ReportNDN-0028, January 2015.