Content-Centric Networking Packet Level Simulator

CCNPL-SIM

Introduction

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/

Designers and developers:

Luca Muscariello http://perso.rd.francetelecom.fr/muscariello/

Massimo Gallo http://perso.telecom-paristech.fr/~gallo

Contributors:

Antonio Carzaniga http://www.inf.usi.ch/carzaniga/

Michele Papalini http://www.people.usi.ch/papalinm/

    Download

    ccnpl-sim-1.0.0.tgz

    ccnpl-sim-latency.tgz (with latency aware caching)

    Simulation examples for latency aware caching

    Installation

    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.
    

    Workload generator

    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
    Example: 2 poisson 1

    columnsyntax example
    1 node_id 2
    2 request distribution poisson
    3 rate 1

    • prefix.dist: indicates which prefix(es) a node will serve.Example file @

    examples/caching_single_LRU/prefix.dist Example: 0 A = "Orange"

    columnsyntaxexample
    1node_id 0
    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 @

    examples/caching_single_LRU/final_names20000_constsize.dist

    Example: 0.4871169634416396 0.5 1 80000 0 0 100 0 A = "Orange" B = "dsaphonwmf" ;

    columnsyntaxexample
    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
    4chunk size [bit] 80000
    5node_id 0
    6,7,8unused
    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.

    Naming adaptation

    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.

    Workload syntax

    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.
    Example: sim_length 500000000000.0000000000 ;

    • 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" ;

    column syntax example
    1command publish_content
    2node_id 0
    3publication time 0.0000000000
    4file size [packets] 100
    5packet size [bit] 8000
    6class_id (popularity class in our settings) 1
    7,8unused 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" ;

    columnsyntaxexample
    1commanddownload_content
    2node_id2
    3download time1000000.0000000000
    4unused field0
    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" ;

    columnsyntaxexample
    1commandset_predicate
    2node_id0
    3time0.0000000000
    4unused field0
    5, .., ;content prefixA = "provider" ;

    Simulation run

    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_file

    The 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.
    Nodes:
    columnsyntaxexample
    1node_id 0
    2x coordinate 10
    3y coordinate 1
    4cache size [kbit] 160000
    5cache replacement policy 0
    6,7unused

    Links:

    columnsyntaxexample
    1link_id 0
    2from 0
    3to 1
    4queue size [kbit] 100000.0
    5link delay [s] 0.001
    6link capacity [kbps] 100000.0
    7,8unused

    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" ;

    columnsyntaxexample
    1node_id (from) 0
    2node_id (to) 1
    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

    Simulation outputs

    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:

    columnsyntaxexample
    1simulation time 3169053.0000000000
    2,3event closed socket
    4node id 2
    5 content_name+port_id /Orange/wgpfowikcv/port:0
    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
    10 keyword class
    11 popularity class 2
    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:

    columnsyntaxexample
    1keyword QUEUE [FINAL]
    2time (only if not final queue statistic) 1.0
    3keyword NODE
    4 node id 1
    5 keyword to
    6 node id 2
    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:

    columnsyntaxexample
    1keyword CACHE [FINAL] NODE
    2time (only if not final queue statistic) [sec] 2.0
    3node id 1
    4request miss rate 2
    5request hit rate 0.988
    6request rate 2.988
    7 miss probability (with filtered requests as miss) 0.6711
    8 hit probability 0.3289
    9 request filter probability 0
    10 miss probability (without filtered requests) 0.6711
    11 keyword class
    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:

    columnsyntaxexample
    1keyword SPLIT [FINAL] NODE
    2time (only if not final queue statistic) [sec] 2.0
    3keyword NODE
    4 node id 1
    5 keyword to
    6 node id 2
    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).