Mini-CCNx: Fast Prototyping for Named Data Networking

Carlos M. S. Cabral, Christian E. Rothenberg, Maurício F. MagalhãesFaculty of Electrical and Computer Engineering (FEEC)University of Campinas (UNICAMP), Sao Paulo, Brazil

{cabral,christian,mauricio}@dca.fee.unicamp.br

ABSTRACTExperimentally driven research in Information-Centric Net-working (ICN) is crucial to the evaluation of new proposalsthat bring named pieces of content as the main element ofnetworks. This paper presents a new fast prototyping tool forICN based on the NDN (Named Data Networking) model,Mini-CCNx, that aims at filling an existing gap in generallyavailable experimental platforms. Using container-based em-ulation and resource isolation techniques, Mini-CCNx ap-pears as a flexible, scalable, high-fidelity, and low-cost toolthat enables experiments on emulated networks with hun-dreds of NDN nodes in a commodity laptop. All those char-acteristics are highly desirable for the evaluation of openresearch issues in ICN, such as routing protocols, forward-ing strategies, caching techniques, content-centric applica-tion development, and so on.

1. INTRODUCTIONThe principles that guided the Internet development

in the 1960’s and 1970’s are not as relevant today asthey were in the past. If originally the main goal wasremote resource sharing and a mostly textual interac-tion between workstations and servers, today the focusis on content retrieval and access to multimedia ser-vices[19]. If originally the basic model was the com-munication between two hosts in fixed and well-definedgeographical locations, today the exact location of thecontent or service is not that relevant: the access tothem is what really matters. With current networkingtechnologies, when one wishes to retrieve a piece of con-tent, a mapping between what a user wants and wherethis content is hosted (with the usage of an IP address)is necessary, what brings several challenges such as mo-bility, security, multicast delivery and others that werenot originally predicted by Internet developers.

With this motivation, the Information-Centric Net-working (ICN) proposals aim to address this paradigmshift, putting the content as the main element of net-works. Proposals like DONA[11], NetInf[6], PSIRP[22]and CCN[10], among others, introduce several new con-cepts and strategies with this goal. Like in every newproposal, the experimentally driven research in ICN is

crucial to the evaluation of such new ideas. Further-more, specially in the Computer Networking area, re-quirements such as scalability and experimental fidelityare highly desirable.

When attempting to evaluate forwarding strategiesand new forwarding-state reduction techniques in ICNcore nodes, we identified an existing gap in generallyavailable tools in this area. We couldn’t find a low-cost, scalable, high-fidelity and sufficiently flexible toolto evaluate scenarios and ICN proposals.

This experimental issue motivated the developmentof Mini-CCNx, presented on this paper. Inspired by thewell-succeeded practices in fast prototyping for Software-Defined Networks (SDNs) [12], Mini-CCNx is able tobuild a complete content network, with hundreds ofnodes, in a simple laptop, with high flexibility, agilityand configurability. Furthermore, it provides a high-fidelity prototyping environment, what enables applica-tions and strategies tested on Mini-CCNx to smoothlymigrate to real environments. Mini-CCNx is based onthe Named Data Networking (NDN)[13] model and usesits official implementation, CCNx[3], what brings greaterrelevance to the tool and to the current project’s usercommunity.

The rest of this paper is organized as follows. Section2 analyses the existent tools in the field and outlinesMini-CCNx goals. Section 3 shows the tool’s architec-tural details. Section 4 brings a fidelity and perfor-mance analysis of Mini-CCNx. Section 5 shows sev-eral real scenarios reproduced using Mini-CCNx. Fi-nally, section 6 concludes the paper and outlines futureworks.

2. MOTIVATION AND GOALSThere are several platforms and tools that can be used

in ICN research, each with its pros and cons. Ideally,it would be interesting to have a tool combining thefollowing characteristics:Flexibility. It should be possible to rapidly create sev-eral scenarios using different configuration parameters.Scalability. It should be possible to create topologieswith a sufficiently high number of nodes.

1

Low-Cost. The tool can be run in a commodity lap-top/desktop or in a single Amazon EC2 instance.Realism. As described in [9], we can define three re-alism dimensions for a tool: (i) functional realism (thesystem behaviour must be the same as the one of a realdeployment and the code executed within the tool mustbe the same code run on the real hardware), (ii) timingrealism (the performance must be close or indistinguish-able from the real behavior) and (iii) traffic realism (thesystem must be able to generate and receive real traf-fic, coming either from the Internet or from the localnetwork).

A researcher looking for such characteristics has twooptions: use an existing tool or develop a new one.

2.1 Existing toolsWe can group such tools and platforms in, at least,

three categories: simulators, testbeds and emulators.Simulators. They are flexible, scalable and, in gen-eral, have a low cost. ndnSIM[16] is a ns-3[17] mod-ule that implements the NDN model. It uses a mod-ular architecture, with classes representing the differ-ent model entities such as PIT (Pending Interest Ta-ble), FIB(Forwarding Information Base), CS (ContentStore), forwarding strategies and others. Another sim-ulator used in this context is OMNeT++[18]. Althoughnot specifically focused on NDN simulation, it can beextended to implement the model’s structures and pro-tocols, as done in ccnSim[2]. But both tools have thedisadvantages of any simulator: (i) they are not realis-tic (the code used in the simulator is different from theone that will be executed in a real deployment) and (ii)the hardware, protocol stack and traffic models used bysimulators may not have the best fidelity.Testbeds. They are experimental infrastructures thatprovide real resources for realistic test scenarios. Theycan be shared among researchers [8, 20, 7, 15] or specif-ically created for a local deployment. Testbeds are re-alists, that is, they run real code in scenarios with realprotocol stacks and real traffic. But, in general, they (i)have high creation and maintenance costs and (ii) theyhave reduced flexibility and scalability when it comesto custom topologies creation. Furthermore, the largestinternational testbeds are beyond the reach of most re-searchers.Emulators. Like simulators, they are flexible and, ingeneral, have low hardware costs. Like testbeds, theyare realistic because they run real code (applications,OS kernel, etc). Mini-CCNx, presented on this paper,appears as an emulator specifically focused on NDN.

Table 1 shows a summary of the analysed character-istics and adds other two: ease of configuration and thepossibility of configuring link parameters, such as delayand loss.

Since we couldn’t find a tool combining all the char-

Table 1: Summary of tools and its characteristicsSimulators Testbeds Emulators

Ex: ndnSIM/ccnSim Testbed NDN Mini-CCNxFlexibility High Low HighScalability High Low High

Cost Low High LowRealism No Yes YesEase of

Medium Low HighConfig.

LinkYes

WithYes

config. restrictions

acteristics above, we chose to develop a new tool, Mini-CCNx.

2.2 Mini-CCNx: a new tool for ICN prototyp-ing

Mini-CCNx combines all the characteristics above.With a simple configuration file, it can create differ-ent NDN topologies and scenarios in a flexible and fastway. Mini-CCNx is also a low-cost tool, enabling theinstatiation hundreds of NDN nodes in a simple lap-top. It is also realistic, that is, the same code run inMini-CCNx can be latter executed in a real hardwaredeployment with high-fidelity results. Furthermore, itis possible to easily configure link parameters such asdelay, bandwidth and loss.

3. MINI-CCNX ARCHITECTUREMini-CCNx is a Mininet-HiFi fork [9] (originally pro-

posed for OpenFlow networks) that adds several mech-anisms and classes for building NDN topologies. Eachnode in the tool emulates a NDN node and runs theCCNx Project’s official code.

3.1 OverviewMini-CCNx uses Container-Based Emulation (CBE)

[?], a lightweight OS-level virtualization technique. Eachcontainer allows groups of processes to have indepen-dent views of system resources, such as process IDs,file systems and network interfaces while still using thesame kernel. Each container is a NDN node, with itsown network namespace, virtual network interface(s),NDN-specific data structures implemented by the ccnddaemon (PIT, FIB and CS) and repositories (as imple-mented by the ccnr daemon). These nodes are con-nected to each other using virtual Ethernet links in thekernel space. In this point there’s a substantial dif-ference between Mininet-HiFi and Mini-CCNx: insteadof connecting virtual hosts with software switches[?],Mini-CCNx connects NDN nodes (containers) in a point-to-point fashion, in adherence to the model.

CBE enables a higher scalability when compared toa system using full-virtualization because it trades theability to run multiple OS kernels for lower overall over-head using a single kernel [21]. But such higher scala-

2

n1(NDN container)

ccnd1(FIB,PIT,CS)ccnr1 (repo)

ccnd3 (FIB,PIT,CS)ccnr2 (repo)ccnd2 (FIB,PIT,CS)

n2(NDN container)

n3(NDN container)

private network namespace

n1-eth0 n2-eth0 n2-eth1 n3-eth0

isolated point-to-point link(e.g. 1Mbps, 10ms)

isolated point-to-point link(e.g. 100Mbps, 10% loss)

Isolated NDN nodes(e.g. 50% CPU and 20% mem each) user space

private network namespace

private network namespace

Kernel space

Figure 1: Three NDN nodes connected linearlyusing Mini-CCNx containers

bility has its price: isolation may be compromised. Theresources are shared by all the NDN nodes and theymay interfere with each other. For example, if a misbe-having content-oriented application in a node begins toindefinitely allocate memory, at a certain time there willbe no memory left for the other nodes and the overallexperiment results will surely be compromised. There-fore, Mini-CCNx uses isolation techniques in order tolimit the resources available for each node and link andthus providing better results.

Like Mininet-HiFi, Mini-CCNx uses Linux cgroups[5]to limit CPU bandwidth for each node. Mini-CCNxalso extends this concept adding memory limits, be-cause memory is a very important subject for NDNwhen it comes to caching and content storage. Finally,using tc, it is possible to configure several link proper-ties such as bandwidth, delay and packet loss. Figure1 shows a summary of CBE and isolation features usedby Mini-CCNx.

3.2 Fast prototypingMini-CCNx aims to be an easy and fast tool for build-

ing different NDN topologies and scenarios. In order toachieve this, all the initial configuration is done eitherby editing a simple text file or using a provided GUI:no extra coding is required. The typical Mini-CCNxworkflow is explained below.1. First, the user specifies the desired topology by edit-ing the Mini-CCNx configuration text file, describingthe NDN nodes and the links between them (1a in Fig-ure 2). Optionally, the provided GUI (miniccnxedit)can be used to generate a configuration file template (1bin Figure 2). In general, using the GUI is recommendedfor smaller topologies, when one wants to have a visualconcept of the scenario. For scenarios with hundreds ofnodes, you can directly edit the configuration file or usescripting (Bash, Python) for it.2. Next, still in the configuration file, the user specifiesthe CPU and memory limits for each node.

1a. Textual topology

specification

1b. GUI topology specification

2. CPU/Mem limits

3. FIB entries

4. Link parameters

configuration

5. miniccnx is started

6. miniccnx instantiates

nodes, links and configurations

7. Complete environment

executing [hosts]h1: app ccnx:/,s1h2: app2 ccnx:/,s1[routers]s1: ccnx:/video,h1 ccnx:/music,h2[links]h1:s1 bw=1000h2:s1 loss=5 delay=100ms

Figure 2: Typical Mini-CCNx workflow

3. The user can also add default FIB entries (nameprefix and next hop tuples) for each node.4. The user can specify link parameters such as band-width (1-1000Mbps), loss (in percentage) and delay (inmiliseconds) for each link in the topology. At the endof this step, the configuration file is complete.5. The user runs the miniccnx tool, using the createdconfiguration file as a parameter.6. The tool parses the configuration file, instantiatesthe nodes, automatically inserts FIB entries using theccndc application and applies the specified link param-eters.7. Finally, the environment set up is over and nowthe user can dynamically interact with the nodes, startapplications, use routing, etc. He can also collect anyneeded metrics or logs. Figure 3 shows an example ofan executing Mini-CCNx environment.

Figure 3: Mini-CCNx is up and running

Currently, ccnx connections run over a TCP or UDPconnection. Mini-CCNx automatically and transpar-ently adds such connectivity so the researcher has only

3

to be concerned about the FIB entries. Also, it isimportant to note that if the user updates the ccnx

code, Mini-CCNx will transparently use this new ver-sion, without any further updates or recompilation.

4. PERFORMANCE AND FIDELITYAll the tests in this subsection were done using an av-

erage laptop, representing a typical hardware configura-tion (Intel Core I5 2410M processor with 4GB RAM).The point here is analysing Mini-CCNx’s fidelity andperformance using a low-cost hardware, largely avail-able to most researchers and students. The ccnx versionused in all cases is the 0.7.0. We will analyse the follow-ing performance aspects: (i) scalability, (ii) coherence,(iii) fidelity and (iv) isolation.

4.1 ScalabilityThe scalability will be analysed with regards to the

number of nodes and links Mini-CCNx can simultane-ously instantiate and run. Thus, two representativetopologies were chosen, full mesh (all nodes have toconnections to all other nodes) and linear (nodes con-nected in a simple linear fashion). These topologies werechosen because they represent the two conectivity lim-its/edges between nodes - any other topology will havea connectivity level within this range.

Table 2: Scalability. Linear topology# of Mini-CCNx ccnd Total # of Set upnodes Mem.(MB) Mem.(MB) Mem.(MB) links time(s)

4 15.0 7.2 22.2 3 <116 15.1 28.9 44.0 15 164 15.7 113.8 129.5 63 6256 18.1 458.6 476.7 255 36512 21.6 918.5 940.1 511 951024 27.8 1835.4 1863.2 1023 2281536 35.3 2754.2 2789.6 1535 320

Table 3: Scalability. Full mesh topology# of Mini-CCNx ccnd Total # of Set upnodes Mem.(MB) Mem.(MB) Mem.(MB) links time(s)

4 15.1 7.2 22.3 6 <18 15.3 13.7 29.0 28 316 15.7 28.9 44.6 120 1132 18.2 57.1 75.3 496 4864 26.0 114.5 140.6 2016 118128 62.0 229.8 291.8 8128 753

Tables 2 and 3 show the number of instantiated NDNnodes, the memory used by Mini-CCNx only, the totalmemory used by the ccnd daemon instances runningin each node, the total overall memory (Mini-CCNx +ccnd), the number of links and the set up time of eachscenario. Note that the largest part of memory usagescomes from the ccnd daemons and this memory usagegrows linearly with the number of nodes. The set uptime is strongly related to the number of instantiated

links. Thus, we note a longer set up time in the fullmesh topology in comparison to the linear topology.

4.2 CoherenceA coherence analysis with regards to the experimen-

tal parameters such as link delay, link bandwidth andnumber of hops is also important. The tool can be con-sidered to be coherent if, for example, the total delaylinearly increases with the number of hops. For thisanalysis, two simple NDN scenarios were used. In thefirst (Figure 4(a), the RTT was measured using theccnping[1] tool for different hop numbers and differ-ent link delay values. In the second (Figure 4(b)), theaverage download time of a 100MB file was measuredfor different numbers of hops, that is, making the con-tent producer get increasingly farther from the client.Still in this second scenario, two cases were analysed:the no-caching (in which the Interest messages have togo through all the nodes until the producer) and thecaching (in which pieces of content are already locatedin the nodes closer to the client) cases. In both graphsthe data is presented in a 95% confidence interval.

RT

T (

ms)

# of Hops

No delay5ms

10ms50ms

0

200

400

600

800

1000

1200

1 2 3 4 5 6 7 8 9 10

(a) RTT vs # of hops for different link delayvalues

20

40

60

80

100

120

140

1 2 3 4 5 6

Dow

nlo

ad tim

e (

s)

# of Hops

Without cachingWith caching

(b) Average download time vs # of hops

Figure 4: Coherence analysis

In the first scenario, one can note the RTT linear in-crease with the number of hops, as expected. Besides,for different link delay values, the RTT behavior is con-sistent. For example, if all the links have a 10 ms delayand the number of hops is 2, the ping takes 20 ms in

4

the upstream, plus 20 ms in the downstream, plus theprocessing time in each node, what we can observe. Inthe second scenario, one can note the increase in thedownload time when the distance between client andproducer is increasead for the no-caching case, as ex-pected. With caching though, we can observe that theaverage download time is lower and loosely related tohe number of hops; in this case, the download time ishighly influenced by the amount of content present inthe cache of the nodes closer to the client.

4.3 FidelityMini-CCNx must be able to reproduce real experi-

ments with high-fidelity. To show that, a simple topol-ogy has been created with two real desktops connecteddirectly, both with FastEthernet interfaces and with na-tive ccnx installations. Then, using the traffic genera-tor ccntraffic[4], the first desktop constantly sendsInterest messages asking for different contents and thesecond answers with 1024-bytes Content Objects. Thesame scenario was reproduced using Mini-CCNx, with100Mbps and a delay of 200 µs as link parameters. Fig-ure 5 shows the Interest and Content Objects (Data)traffic for both cases.

Bandw

idth

(K

bps)

Time (s)

Content Objects - RealContent Objects - Mini-CCNx

Interests - RealInterests - Mini-CCNx

0

200

400

600

800

1000

1200

1400

0 5 10 15 20 25 30 35

Figure 5: Bandwidth comparison between Mini-CCNx and a real deployment

Note that the bandwidth behavior in Mini-CCNx isvery close to the real deployment behavior.

4.4 IsolationTypically, a NDN test scenario has several content

flows and nodes running in different regions of the net-work. One should expect that the traffic in a networkregion shouldn’t affect the results of another region thathas no connections to the first one. As obvious as thislooks, isolation is a challenge for Mini-CCNx becausedifferent nodes and flows running on it will be usingbasically the same kernel, process scheduler and linkscheduler. But using the isolation techniques describedin Section 3 and carefully limiting CPU, memory andlink bandwidth and delay, it is possible to achieve greatresults.

To show this, a topology with 4 NDN nodes was built.Nodes h1 and h2 are directly connected to each otherand constantly send ccnpings to each other. Nodesh3 and h4 are also directly connected and constantlyexchange NDN traffic. We will call this traffic a back-ground traffic. Please note that there is no connectionbetween the two networks. RTT values between h1and h2 will be observed in the presence and absenceof the background traffic between h3 and h4. Becausethey are in separate networks, one should expect that,in a real network, the presence or absence of the back-ground traffic shouldn’t affect the RTT values observedin the h1-h2 network. Figure 6 shows the describedtopology and the RTT behavior for the cases with andwithout resource limiting. The data is represented ina 95% confidence interval. Note that, in the presence

(a) Topology

10.5

11

11.5

12

12.5

13

13.5

14

With Limiting Without Limiting

RT

T (

ms)

Without background trafficWith background traffic

(b) RTT with and without resource limiting

Figure 6: Isolation analysis

of background traffic, the RTT value drops without re-source limiting, that is, there’s no isolation in this case.Even if we consider the error bars, there’s no overlap-ping between them, so such values are, indeed, different.With resource limiting though, the average RTT valueis much closer and the error bars overlap and thus weconsider that isolation has been preserved.

To further analyse this isolation issue, a couple ofextra scenarios were tested. The topology is the sameof the previous case. Each host has a 50% CPU limit(of the total 400% available in our Quad-Core test ma-chine). For different bandwidth and delay values, theRTT was measured always comparing the behavior withand without background traffic. The average backgroundtraffic value was always around 60% of the total avail-

5

able bandwidth in the link. Figure 7 shows graphs withdifferent parameter combinations and all the values arepresented in a 95% confidence interval.

In all the cases there’s overlapping among the errorbars. Therefore, we can see that if correctly configured,Mini-CCNx can provide a test environment with isola-tion.

5. REPRODUCING REAL EXPERIMENTS

5.1 Reproducing behavior from the originalCCN paper

1. Content Distribution Efficiency. The originalpaper also shows how CCN shines when it comes tocontent distribution. The data sharing performance be-tween TCP and CCN was compared by measuring thetotal time taken to simultaneously retrieve a 6MB datafile over a network bottleneck. The test used a sourcenode over a 10 Mbps shared link (the bottleneck) con-nected to a cluster of consumers all interconnected with1Gbps links. The consumers simultaneously pulled thedata file from the source. The original paper showedthat CCN outperformed TCP with two consumers ormore due to its caching characteristic that avoided theconstant usage of the bottleneck link.

We used Mini-CCNx to reproduce such behavior. ForTCP, the file was retrieved with wget from a HTTPserver in the source. For CCN, the file was retrievedwith the ccnx’s built-in tool ccngetfile. Figure 8shows the results.

Avera

ge d

ow

nlo

ad tim

e(s

)

# of consumers

TCPCCN

0

5

10

15

20

25

30

35

40

0 1 2 3 4 5 6 7

Figure 8: Distribution efficiency

As we can see, CCN indeed outperformed TCP withtwo consumers or more. Furthermore, TCP presents alinear behavior according to the number of consumers.But CCN don’t: it efficiently caches popular contentand thus reduces the overall traffic in the network links.2. Strategy/Forwarding layer behavior. The orig-inal paper shows how a CCN node behaves when it hasmultiple FIB entries for the same prefix. Basically, it isshown that the strategy layer chooses the best face atthe time and if the current used link fails, for example,the CCN stack automatically chooses a second face to

send the packets through.Here, we show the exact same behavior with Mini-

CCNx. Two hosts are directly connected through twolinks with the same configuration (100Mbps and 1msdelay), link 1 and link 2. The first host constantly sendsInterest packets while the second replies with Data pack-ets. In Figure 9 we show the bandwidth in each ofthese links according to time. We see that in the begin-ning, the strategy layer chooses mostly link 1 but con-stantly sends prospection packets through link 2. Ap-proximately at 40s the strategy seems to choose mostlylink 2 but, at 45s, we disconnect link 2 until about 70seconds. Mini-CCNx can easily and dynamically bringlinks down and up, at the time the user desires. We seethat the strategy automatically chooses link 1 again.At approximately 110s we bring link 1 down until 125s.Again, we see link 2 being automatically chosen by thestrategy layer. Therefore, with Mini-CCNx we couldsuccessfully reproduce the automatic failover behaviorof the model.

0

100

200

300

400

500

0 20 40 60 80 100 120 140 160 180

Packets

/second

Time (s)

Link 1Link 2

Figure 9: Automatic Failover Behavior

5.2 Reproducing the Technical ReportsThe NDN Project Technical Reports[14] bring several

experiments that aim at showing the behavior of realNDN applications under real conditions. In this sec-tion, we’ll try to reproduce some of those experimentsusing Mini-CCNx. If we can get the same results, thenperhaps the real experiments could have been benefitedfrom a prior usage of Mini-CCNx. We’re not claimingthat one should not use real deployments - we’re justsaying that some results and application characteristicscan be detected earlier using Mini-CCNx and thus re-duce the time and cost spent on real environments.1-NDNVideo: NDNVideo[?] is a video streamingapplication that is able to play live and pre-recordedvideos with random access and no session negotiation.During the tests, the developers detected an interestingbehavior in a deploy with multiple consumers, a centralcontent router (borges) and a video producer(hydra):each consumer got slightly more data than the hydraprovides. We used Mini-CCNx with the same topology

6

11

11.5

12

12.5

13

13.5

14

1Mbps 10Mbps 100Mbps

RT

T (

ms)

Without background trafficWith background traffic

(a) Delay=5ms

21

21.5

22

22.5

23

23.5

1Mbps 10Mbps 100Mbps

RT

T (

ms)

Without background trafficWith background traffic

(b) Delay=10ms

201

201.5

202

202.5

203

203.5

1Mbps 10Mbps 100Mbps

RT

T (

ms)

Without background trafficWith background traffic

(c) Delay=100ms

Figure 7: Isolation analysis for different bandwidth and delay values

and with 5 consumers and we could reproduce this (Fig-ure 10(a)). The authors detected large spikes in RTTmeasurement and concluded this was caused by an In-terest reordering done by CCNx. They made severalclient-side improvements to address this (estimation oftimeouts, retry issuing Interests, usage of an interval-based pipeline) and they shown this approach seems towork well. In Figure 10(b), we show the RTT behaviorof this latter approach using Mini-CCNx and the re-sults are really close to the ones shown in the originaltechnical report.

0

10000

20000

30000

40000

50000

# o

f C

onte

nt O

bje

cts

sent

25 Seconds(since start) 90

hydra

borges

cons-1

cons-2

cons-3

cons-4

cons-5

(a) Content Objects sent per node

RT

T (

seconds)

Segment Number

RTT

0

0.05

0.1

0.15

0.2

0.25

0.3

0 500 1000 1500 2000

(b) RTT with interval-based pipeline

Figure 10: Behavior of NDNVideo in Mini-CCNx

2-NDN Testbed and OSPFN: The user can run thecommand sudo miniccnx -testbed and Mini-CCNx

will automatically load 17 nodes representing all theNDN Testbed’s routers and the point-to-point links be-tween them 1. The propagation delays were estimatedusing straight geographical distances between the nodes(a snapshot can be seen in Figure 11(a)). Further-more, each node runs its own instance of the ospfn[?]daemon (and also the required ospfd and zebra dae-mons from Quagga[?]) and we can see how the rout-ing scheme converges, the time spent and the FIB en-tries being automatically inserted in each node’s FIB(as seen with ccndstatus). Each node is configured toannounce exactly the same name prefixes outlined inthe testbed website 2. For instance, the CAIDA/UCSDrouter announces the /ndn/caida.org/ prefix and thePARC router announces the /ndn/parc.com and the/ndn/opschat prefixes. Figure 11(b) shows an exam-ple of a connection between two nodes of the topology(namely CAIDA/UCSD and UA), the daemons runningon them and the prefix announcement.

Mini-CCNx uses different IP addresses from those ofthe real testbed (basically, we allocated sequential /30network addresses for each link starting with 1.0.0.0/30).With Mini-CCNx, one can easily bring any link up ordown in the topology and thus we can dynamically anal-yse OSPFN’s convergence time and multipath behaviorwith greater agility and flexibility than we could achievein the real testbed.

6. CONCLUSIONInspired by the well-succeeded experience in fast pro-

totyping for SDN, Mini-CCNx appears as a innovativetool that aims at filling an existing gap in the currentlyavailable NDN experimental platforms. Mini-CCNx isrealistic, low-cost and scalable: a whole content-orientednetwork, with hundreds of nodes, can be run in a simplelaptop, with easy configuration and high-fidelity results.

7. REFERENCES[1] CCN Ping. NDN-Routing/ccnping - GitHub.

https://github.com/NDN-Routing/ccnping.1As seen on March 8th 2013[15]

7

(a) Estimating the distance between NDNTestbed’s routers

CAIDA/UCSD Node(Container)

ccnd

OSPFN

ospfdOLSA,

queries, routes

FIB entries

UA Node(Container)

ccnd

OSPFN

ospfdOLSA,

queries, routes

FIB entries

isolated point-to-point link(estimated delay: ~3ms)

OLSA(e.g. /ndn/caida.org/)

to UCLA

to CSU

to UM

to SPP-HOUS

to UCLA

to UCI

(b) Overall view of the OSPFN routing scheme over NDNTestbed’s routers

Figure 11: NDN Testbed and OSPFN

[2] ccnSim. Scalable chunk-level CCN simulator.http://perso.telecom-paristech.fr/

~drossi/index.php?n=Software.ccnSim.[3] CCNx. Official implementation of the CCN

model. https://www.ccnx.org/.[4] CCNx Traffic. CCNx: traffic generation - ARL

ONL Wiki. http://wiki.arl.wustl.edu/onl/index.php/CCNx:_traffic_generation.

[5] cgroups. Linux Control Groups.https://www.kernel.org/doc/Documentation/

cgroups/cgroups.txt.[6] C. Dannewitz, D. Kutscher, B. Ohlman,

S. Farrell, B. Ahlgren, and H. Karl. Network ofInformation (NetInf) - An Information-CentricNetworking Architecture. ComputerCommunications, null(null), Jan. 2013.

[7] Emulab. Network Emulation Testbed.http://emulab.net/.

[8] GENI. Global Environment for NetworkInnovations. http://www.geni.net/.

[9] N. Handigol, B. Heller, V. Jeyakumar, B. Lantz,and N. McKeown. Reproducible networkexperiments using container-based emulation.Proceedings of the 8th international conference onEmerging networking experiments andtechnologies - CoNEXT ’12, page 253, 2012.

[10] 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 Emergingnetworking experiments and technologies -CoNEXT ’09, page 1, New York, New York, USA,Dec. 2009. ACM Press.

[11] T. Koponen, M. Chawla, B.-G. Chun,A. Ermolinskiy, K. H. Kim, S. Shenker, andI. Stoica. A data-oriented (and beyond) networkarchitecture. ACM SIGCOMM ComputerCommunication Review, 37(4):181, Oct. 2007.

[12] B. Lantz, B. Heller, and N. McKeown. A networkin a laptop. In Proceedings of the Ninth ACMSIGCOMM Workshop on Hot Topics in Networks- Hotnets ’10, pages 1–6, New York, New York,USA, Oct. 2010. ACM Press.

[13] NDN Project. Named Data Networking.http://www.named-data.net/.

[14] NDN Project. NDN Technical Reports. http://www.named-data.net/techreports.html.

[15] NDN Testbed. NDN Routing Topology.http://netlab.cs.memphis.edu/script/htm/

topology.html.[16] ndnSIM. NS-3 based NDN simulator.

http://ndnsim.net/.[17] ns-3. Network Simulator.

http://www.nsnam.org/.[18] OMNeT++. Network Simulation Framework.

http://www.omnetpp.org/.[19] T. Plagemann, V. Goebel, A. Mauthe, L. Mathy,

T. Turletti, and G. Urvoy-Keller. From contentdistribution networks to content networks - issuesand challenges. Computer Communications,29(5):551–562, Mar. 2006.

[20] PlanetLab. An open platform for developing,deploying, and accessing planetary-scale services.http://www.planet-lab.org/.

[21] S. Soltesz, H. Potzl, M. E. Fiuczynski, A. Bavier,and L. Peterson. Container-based operatingsystem virtualization. ACM SIGOPS OperatingSystems Review, 41(3):275, June 2007.

[22] S. Tarkoma, M. Ain, and K. Visala. ThePublish/Subscribe Internet Routing Paradigm(PSIRP): Designing the Future InternetArchitecture. In Towards the Future Internet - AEuropean Research Perspective, 2009, pages102–111, 2009.

8