CCNPL-SIM is a packet level simulator of the content-centric networking protocol stack. It is based in part on CBCBsim developed by Antonio Carzaniga et al from which it imports part of the forwarding layer and the name-based routing protocol. The CCN protocol features are developed from scratch.
The development has been funded by
Orange Labs, France Telecom, http://perso.rd.francetelecom.fr/muscariello/
Bell Labs, Alcatel-Lucent, http://www3.alcatel-lucent.fr/wps/portal/belllabs
ANR Connect Project http://www.anr-connect.org
EIT ICT Labs activity Smart Ubiquitous Content http://www.eitictlabs.eu/
Luca Muscariello http://perso.rd.francetelecom.fr/muscariello/
Massimo Gallo http://perso.telecom-paristech.fr/~gallo
Antonio Carzaniga http://www.inf.usi.ch/carzaniga/
Michele Papalini http://www.people.usi.ch/papalinm/
The installation procedure downloads the required packages and checkout the source code of the simulator from the svn repository. The simulator is written in C++ and you need automake, gcc and the boost library in your system.
To retrieve the installation script do
wget http://systemx.enst.fr/archives/ccnpl-sim-1.0.0.tgz; tar xvzf ccnpl-sim-1.0.0.tgz; cd ccnpl-sim-1.0.0; sh install.sh;
To get some examples with simulation scripts and output post processing.
wget http://systemx.enst.fr/archives/examples.tgz We have included four examples for different scenarios: examples/ ├── caching_binary_tree_RND │ ├── caching_single_LRU │ ├── flow_control_multipath │ └── flow_control_single_path A simple run can be made by using the scripts included in the package. From the folder ccnpl-sim-1.0.0/ download and open the archive example.tgz. cd examples/caching_single_LRU; sh batch.sh real 0m49.545s user 0m47.619s sys 0m1.862 sh plot.sh The script generates graph in pmiss.eps output using gnuplot. The graph below reports the miss probablity of a single LRU cache using a request workload with Zipf content popularity, log(q) = alpha log(k) + log(c) with shape alpha = 1.7. The value q represents the probability to request content object with rank k. The miss probability is reported as a function of the rank k.
In this section we introduce the workload generator tool that is directly derived by the one used in the original CBCBSim. The workload generator takes as input different files that indicates servers, clients and the list of available files. In particular:
- clients.dist: indicates the nodes that will request and the file request rate e.g. Poisson of rate λ. Example file at examples/caching_single_LRU/clients.dist
- prefix.dist: indicates which prefix(es) a node will serve.Example file @
examples/caching_single_LRU/prefix.dist Example: 0 A = "Orange"
|2, .., ;||content prefix||A = "provider" ;|
- contents.dist: indicates the contents that will be available for the download, their permanent location, their popularity and their size. Example file @
Example: 0.4871169634416396 0.5 1 80000 0 0 100 0 A = "Orange" B = "dsaphonwmf" ;
|1||class request cumulative probability (multiple entries with the same cum. prob. belongs to the same class)||0.4871169634416396|
|2||file request cumulative probability (cum. probability of requesting a file in the given class)||0.5|
|3||file size [packets]||1|
|4||chunk size [bit]||80000|
|9, .., ;||content name||A = "Orange" B = "dsaphonwmf" ;|
During the workload generation process, time_unit and the sim_length are written at the beginning of the workload file. Then, publish_content commands are generated and written in the workload while reading the contents.dist input file. At this stage, if not otherwise specified to the generator, set_predicate commands are generated through the prefix.dist input file. Finally, using the input information given by contents.dist and clients.dist, the download_content commands are generated according to the request rate/law (i.e. Poisson(λ), λ = 1) and content popularity specified to the workload generator. This is an example of the command used in order to automatically generate a workload file:
../../ccnpl-sim/cbnsim/bin/cbnwlgen -l 500e+03 -wtu 1e-06 -man_routing -files files.dist -prefix prefix.dist -clients clients.dist
options of the workload generation command are:
- -l sim length [sec];
- -wtu time unit [sec];
- -man_routing if present omit the automatic routing (from CBN simulator);
- -files specify the files published in the network, their probability, etc.;
- -prefix specify the prefixes at the servers (not needed if manual routing);
- -clients specify the clients, their request rate, etc.
In wl_example a workload example file is reported.
In order to better understand the workload construction, let us first introduce the naming schema used in the simulator. CBCBSim makes use of the naming defined by the CBN architecture. CBN names basically consists in a set of attribute/value pairs constituting the flat content-based address (name). In order to be compliant to the current hierarchical URI-like naming schema adopted by CCN, we use the CBN names with some additional constraints. The CBN names are of the type:
message: [class="warning", severity=1, device-type="hard-drive"]
selection predicate: [(class="warning") ∨ (alert-type="software-error" ∧ severity=1)]
in which a message is composed by a set of attribute-value pairs called constraints and the selection predicate is composed by a disjunction (filters) of conjunctions (predicate) of constraints i.e. the selection predicate presented before is composed by two filters: [class="warning"] and [alert-type="software-error" ∧ severity=1]. In order to have URI-like addresses, we impose that:
- each constraint corresponds to an element of the URI address i.e. /constraint1/constrant2/../
- constraints are listed in alphabetical order to represent a URI-like address i.e. the message A = "provider", B ="video", C = "video.mpg" is converted in /provider/video/video.mpg. Notice that also numbers can be used as constraints’ name.
- selection predicates (prefixes used in the interest forwarding process) are composed by a single filter.
The workload file is composed of a set of commands that we briefly introduce in this section. Here is the list of the accepted commands in the workload with their syntax and an example:
- time_unit: indicates the workload’s time unit i.e. if the time unit is 0.0000010000 all the times in the workload file are indicated in μs.
Example: time_unit 0.0000010000 ;
- sim_length: indicates the length of the simulation expressed using the workload’s time unit. Notice that the simulation length is overridden if a length is specified to the simulator.
- publish_content: indicates that the specified node in the topology will be the server for the specified content. Notice that a file can be published in different network nodes.
Example: publish_content 0 0.0000000000 100 8000 1 100 0 A = "provider" B = "video.mpg" ;
|4||file size [packets]||100|
|5||packet size [bit]||8000|
|6||class_id (popularity class in our settings)||1|
|7,8||unused fields||100 0|
|9, .., ;||content name||A = "provider" B = "video.mpg" ;|
- download_content: indicates the beginning of the downloading process of the specified content from a particular node.
Example: download_content 2 1000000.0000000000 0 A = "provider" B = "video.mpg" ;
|5, .., ;||content prefix||A = "provider" B = "video.mpg" ;|
- set_predicate: this command has been inherited from the CBCBSim. It constructs the shortest path to deliver interest messages from all the potential requester to the node indicated by the command. The command specifies the prefix that will be used during the interest forwarding phase in order to compute the longest prefix match. Notice that this primitive can also be omitted. In this case, routing tables need to be manually specified while launching the simulation run.
Example: set_predicate: 0 0.0000000000 0 A = "provider" ;
|5, .., ;||content prefix||A = "provider" ;|
In this section we introduce the simulator structure and briefly describe the implementation of the CCN data structures. The simulator needs some parameters including the topology file and the workload file. This is an example of the command used to launch the simulation:
ccnpl-sim/bin/cbcbsim -input option_file > stderr.log
with the option file used in the caching_single_LRU example examples/caching_single_LRU/option_fileThe option file specify three input files. The first one is the workload file that we described before. The other two are respectively the topology and the routing file that we briefly explain hereafter.
- topo.brite: used to describe the topology to the simulator. The file is divided in two parts (nodes and edges) that we describe in the next two tables.
|4||cache size [kbit]||160000|
|5||cache replacement policy||0|
|4||queue size [kbit]||100000.0|
|5||link delay [s]||0.001|
|6||link capacity [kbps]||100000.0|
Example @ examples/caching_single_LRU/topo.brite
roting.dist: used to manually specify the routing tables. Automatic routing is written in the workload and can be omitted using the -man_routing option during the workload generation process. Example: 0 0 A = "Orange" ;
|3, .., ;||content prefix||A = "provider" ;|
Notice that if from and to node_id coincide this means that the node serves the specified prefix (if this is not present, the node will not reply to interests). Example @ examples/caching_single_LRU/option_file/routing.dist
The simulator produces two different output files. The first one is directly printed in stdout and records runtime events e.g. the termination of a content download process. Notice that in principle each event handled by the simulator (packet received, packet sent, packet lost, etc.) can be printed to stdout. However print operations significantly increment the simulation execution time and the stdout statistics collected by the released version of the simulator are limited to events that represent the end of a content download process. The syntax of the stdout output file is represented in the following table:
|6||delivery time [sec]||1.023|
|7||file size [bits]||80000|
|8||average RTT [sec]||0.0010|
|9||average packaet delay (take into account retransmissions) [sec]||0.0015|
|12||sockets still opened in this node||10|
|13||avg receiver interest window size||5.4|
|14||number of exploited routes||5|
|15||average number of exploited routes||2.4|
The second output file is a log saved to the path/file name specified to the simulator through the outputfile input parameter. The statistics collected in this file are of three different types. The first one represents network performance as the average queue occupancy) and is preceded by the QUEUE stats: keyword. The following table present an example QUEUE statistics:
|2||time (only if not final queue statistic)||1.0|
|7||average queue size packets?||10.43|
The second set of statistics collected in the outputfile represents per popularity class cache performance (miss, hit, input/output request rate) and is preceded by the Stats: keyword. The following table present an example CACHE statistics:
|1||keyword||CACHE [FINAL] NODE|
|2||time (only if not final queue statistic) [sec]||2.0|
|4||request miss rate||2|
|5||request hit rate||0.988|
|7||miss probability (with filtered requests as miss)||0.6711|
|9||request filter probability||0|
|10||miss probability (without filtered requests)||0.6711|
|12||calass_id (popularity class in our settings)||1|
The third and last set of statistic represents per node and per forwarding prefix split ratio/rate in case of multipath scenario. An example of the split statistic is represented in the following table:
|1||keyword||SPLIT [FINAL] NODE|
|2||time (only if not final queue statistic) [sec]||2.0|
|7||forwarded requests [\%]||23.3|
|8||forwarded requests [rate]||1.4|
Notice that the three groups of statistics are printed out each ti seconds as specified by the parameter dci (data collection interval) and at the end of the simulation (if ti = 0 only final statistics are collected).