NDN, Technical Report NDN-0028, 2015. http://named-data.net/techreports.

html
Revision 2: November 11, 2016 1
Revision 1: January 27, 2015. (https://named-data.net/wp-content/uploads/2013/07/ndn-0028-1-ndnsim-v2.pdf)

ndnSIM 2: An updated NDN simulator for NS-3

Spyridon Mastorakis, Alexander Afanasyev, Ilya Moiseenko and Lixia Zhang
University of California, Los Angeles
{mastorakis, aa, iliamo, lixia}@cs.ucla.edu

Abstract—The fundamental departure of the Named-Data Networking the following major enhancements and features compared
(NDN) communication paradigm from the IP principles requires exten- to the first release:
sive evaluation through experimentation, and simulation is a necessary
• All NDN forwarding and management is implemented
tool to enable the experimentation at scale. We released the first ver-
directly using the source code of NFD and ndn-cxx.
sion of ndnSIM, an open source NS-3-based NDN simulator, back in
• The packet format changed to the latest NDN packet
June 2012. Since then, ndnSIM has undergone substantial development
resulting in ndnSIM 2, the first version of which was released in Jan- format [9].
uary 2015. This paper reports the design and features of the updated • Real applications written against the ndn-cxx library
simulator. The goal of the updated simulator is to match the simulation can be adapted to run inside the simulated environ-
platform to the latest advancements of NDN research. Therefore, it uses ment.
the ndn-cxx library (NDN C++ library with eXperimental eXtensions) and
This version of the simulator, just like the previous one,
the NDN Forwarding Daemon (NFD) to enable experiments with real
is implemented in a modular way using different C++
code in a simulation environment.
classes to model the behavior of each NDN entity: Faces
to communicate with local applications and other simulated
1 I NTRODUCTION nodes, NFD’s Forwarding Information Table (FIB), Pending
Interest Table (PIT) and Contest Store (CS), etc. This modular
Named Data Networking (NDN) [1, 2, 3, 4] represents a structure allows the easy modification or replacement of
fundamental departure from today’s Internet architecture any component with no or minimal impact on the other
which names the communication endpoints, and aspires components. In addition, the new release provides a more
to be the successor of the TCP/IP protocol stack. As a extensive collection of interfaces and helpers to perform
result, the various design options in the NDN architecture detailed tracing of every component, as well as of the NDN
needs to be evaluated in large-scale experimentation. How- traffic flow.
ever, it is infeasible to conduct such experimentation with In order to improve the user experience even more, we
real-world infrastructure and simulation-based evaluation encourage the community to provide us valuable feedback
becomes necessary. The main goal of ndnSIM has always by submitting bug reports. We also welcome requests for
been offering the NDN community a common, user-friendly, new feature development.1 More information about the
and open-source simulation platform based on the NS-3 simulator, basic examples, and tutorials are available on the
simulator framework [5]. ndnSIM website: http://www.ndnsim.net/.
The first public release of ndnSIM took place in June
2012 [6]. Since then, ndnSIM has become a popular tool
used by many researchers around the globe. At the time of 2 D ESIGN
this writing, ndnSIM mailing list has over 400 subscribers, The design for ndnSIM 2 has been directed by our aim
and more than 290 papers have been published based on to achieve full integration with Named Data Networking
research done using ndnSIM. Since the first ndnSIM release, Forwarder (NFD) [7, 8]. In this section, we present the
the NDN team has released an updated version of the proto- overall design of ndnSIM and demostrate its main structural
col, in part featured by the new modular NDN Forwarding components and the way that they interact with each other.
Daemon (NFD) [7, 8] and ndn-cxx library (NDN C++ library
with eXperimental eXtensions) [9] that supports NFD imple-
2.1 Design summary
mentation and is used in other C++ based applications.
The goal of this new ndnSIM release is to match the ndnSIM 2 provides integration with NFD, while it also
simulation platform to the latest advancements of NDN allows the simulation of applications written against the cxx
research and consolidate the code development efforts: the library. In this way, ndnSIM offers an integrated simulation
core of ndnSIM is now fully powered by NFD and ndn- environment for researchers and developers to deploy and
cxx code with a few minor updates. With this change, the evaluate their real-world applications at large-scale.
ndnSIM 2 offers the highest fidelity of the simulation results,
1. Bug reports and feature recommendations can be submitted
as well as allow simple transfer of simulation experiments to on the NDN project issue tracking system website: http://redmine.
the real world and vice versa. To summarize, ndnSIM 2 has named-data.net/projects/ndnsim
 2

TABLE 1: Comparison among the components of ndnSIM 2 and ndnSIM 1.0

Component of ndnSIM 2 Component existed in Features/Design principles inherited from Features/Design changes introduced in
ndnSIM 1.0? ndnSIM 1.0 ndnSIM 2
ndn::L3Protocol Yes The core component of ndnSIM NFD integration
nfd::Forwarder Existed as – As a result of integration with NFD, packet
ndn::ForwardingStrategy forwarding is split into forwarding pipelines
and forwarding strategy decisions
nfd::face::LinkService Existed as ndn::Face Base class for ndn::AppLinkService and Link service abstraction of a nfd::Face
ndn::NetDeviceLinkService implemented by NFD
ndn::AppLinkService Existed as ndn::AppFace Enables communication with applications Realization of nfd::face::LinkService
abstraction
ndn::NetDeviceLinkService Existed as Enables communication with other simulated Realization of nfd::face::LinkService
ndn::NetDeviceFace nodes abstraction
::ndn::Face No – Enables the simulation of real applications
written against the ndn-cxx library
ndn::cs Yes Same design NFD integration
nfd::Cs Existed as ndn::cs – 1) Interest selectors handling
2) Not yet flexible to cache policies
nfd::Pit Existed as ndn::pit – Abstraction implemented by NFD
nfd::Fib Existed as ndn::fib – Abstraction implemented by NFD
nfd::fw::Strategy Existed as – 1) Per namespace strategy
ndn::ForwardingStrategy 2) Different built-in strategies
Applications Yes Equivalent functionality Use of the ndn-cxx library
Trace helpers Yes Equivalent functionality Directly trace events from NFD

As a result of the NFD integration, the installation of Applications ndnSIM-specific

Applications
Real-world
Applications

the NDN protocol stack (ndn::L3Protocol) on a simulated

node results in creating of NFD instance and associating ndnSIM
core ndn::AppLinkService ndn::NetDeviceLinkService

it with the node. The code used for any experiments with
NDN forwarding (e.g., custom forwarding strategies) can be NDN Protocol Stack
{ndn::L3Protocol}
directly used inside ndnSIM and vice versa. Moreover, the
ability to select different forwarding strategies for different Content Store ndn-cxx
namespaces, the full-featured support for Interest selectors {ndn::cs::*} Library

ndnSIM-specific
and crypto operations, and the use of the full-featured NDN NFD ndn::Face
{ndn::Face}
packet format ensure that the simulations are maximally NFD

realistic. With the added features, ndnSIM 2 has increased

memory and CPU requirements compared to ndnSIM 1.0, Face
Content
Store
PIT FIB
Forwarding
Strategy
LinkService
{nfd::Face} {nfd::Pit} {nfd::Fib} {nfd::face::LinkService}
but still allowing a large scale simulations on general- {nfd::Cs} {nfd::fw::*}

purpose hardware. The memory overhead per CS and PIT

NS-3
entry is presented in Table 2. ndnSIM 1.0 can process ap- NetDevice

proximately 53K packets (Interest and Data) per wall clock

second, while ndnSIM 2 can process approximately 17K Fig. 1: Structural diagram of the ndnSIM design components
packets (Interest and Data) per wall clock second.
ndnSIM’s NDN stack is implemented as a network-layer
protocol model and can run on top of any available link- – nfd::Forwarder: main class of NFD, which owns all
layer protocol model (point-to-point, CSMA, wireless, etc.). faces and tables of the NDN router node and imple-
In addition to that, the simulator provides an extensive ments NDN forwarding pipelines.
collection of helpers (NDN Stack, Application, FIB, Global – nfd::Face: NFD Face abstraction that implements the
Routing, Link Control, and Strategy Choice helpers) and required communication primitives to actually send
tracers (packet-level, application-level, content store) to per- and receive Interest and Data packets.
form detailed tracing behavior of every component, as well – nfd::face::LinkService: base class of NFD LinkSer-
as NDN traffic flow. vice abstraction. LinkService translates between net-
The basic components of this ndnSIM release are shown work layer packets (Interests, Data, and Nacks) and
in Figure 1 and a comparison among their design principles link layer packets (TLV blocks).
and features for the new and the previous release of the – nfd::face::Transport: base class of NFD Transport ab-
simulator is presented in Table 1. These components are also straction. Transport provides best-effort packet deliv-
listed below: ery service to the link service of a face.
• ndn::L3Protocol: NS-3 abstraction of the NDN stack – nfd::Cs: the cache of Data packets that is used by
implementation. Its main task is initialization of the NFD. The current release of ndnSIM also includes the
NFD instance of each node that participates in the old ndn::ContentStore abstraction (see below) ported
simulation scenario and provides tracing sources to from the previous release to enable richer options for
measure NDN performance (sent/received interest and simulation of content store operations (nfd::Cs is not
data, satisfied/unsatisfied interests). yet as flexible when it comes to cache replacement
• NFD: implementation of the Named Data Networking policies).
Forwarding Daemon, including: – nfd::Pit: the Pending Interest Table (PIT) of NFD
 3

TABLE 2: Average memory overhead of ndnSIM 2 and ndnSIM 1.0

Entry Type ndnSIM 1.0 ndnSIM 2
Per CS Entry 1.3 Kb 2.8 Kb
Per PIT Entry 0.8 Kb 5.1 Kb

keeps track of Interest packets that were forwarded simulated node in a way simiar to other network protocol
upstream toward one (or more) content source(s). In stacks, such as IPv4 and IPv6. When it is installed on a NS-
this way, Data can be sent downstream to one (or 3 node, it performs the initialization of the NFD instance,
more) requester(s). creates the necessary NFD managers (FibManager, FaceM-
– nfd::Fib: the Forwarding Information Base (FIB) is anager, StrategyChoiceManager), tables (PIT, FIB, Strategy
used to forward Interest packets toward one (or Choice, Measurements), and special faces (i.e., Null Face,
more) potential source(s). Internal Face). In addition to that, the ndn::L3Protocol class
– nfd::fw::Strategy: the forwarding strategy in NFD defines an API to handle the registration of new nfd::Face
makes the decisions regarding whether, when, and instances to NFD using the AddFace method and provides
where the Interest packets will be forwarded. NS-3 TraceSource entry points of NDN-level packet tracing.
nfd::fw::Strategy is an abstract class that needs to be
implemented by all the built-in or custom forwarding 2.3 Named Data Networking Forwarding Daemon (NFD)
strategies. ndnSIM integrates the NFD codebase with a few small
– nfd::measurements::Measurements: the table, where adaptations to the simulation environment,2 . In the rest of
NFD stores measurement information regarding a this section we describe NFD structure and list the major
name prefix. It is used by the forwarding strategies. challenges we faced during the integration.
– nfd::strategy choice::StrategyChoice: this table con-
tains the forwarding strategy selected for each 2.3.1 NFD Internal Structure
namespace. The basic modules of NFD are the following [7]:
• ndn::AppLinkService: realization of the • ndn-cxx Library, Core, and Tools, which provides var-
nfd::face::LinkService abstraction to enable ious common services shared between different NFD
communication with applications. modules.
• ndn::NetDeviceLinkService: realization of the • Faces that implement communication abstraction on
nfd::face::LinkService abstraction to enable top of various lower level transport mechanisms.
communication with other simulated nodes. • Tables, realizing the Content Store (CS), the Pending
• ndn::cs::*: the Content Store (CS) structure as imple- Interest Table (PIT), the Forwarding Information Base
mented in ndnSIM 1.0. It includes a number of replace- (FIB), StrategyChoice, Measurements, and other data
ment policies and, in general, is more flexible than the structures to support forwarding of NDN Data and
current CS implementation of NFD. Interest packets.
• Basic NDN applications: implementation of built-in • Forwarding pipelines, a series of steps that operate
NDN consumer and producer applications that can on a packet or a PIT entry. Individual pipelines are
generate and sink NDN traffic. These applications in- triggered by a specific event, such as reception of the
clude parameters that can be configured by the user in Interest, detecting that the received Interest was looped,
the simulation scenario and thus generate NDN traffic when an Interest is ready to be forwarded out of the
according to a user-defined pattern. Face, etc.
• Trace helpers: a collection of trace helpers that simplify • Forwarding strategies, a decision maker about Interest
collection and aggregation of various necessary statis- forwarding, which is attached at the end or beginning
tical information about the simulation and write this of the pipelines.
information in text files. • Management, allowing applications to configure NFD
• ndnSIM helpers: a collection of helpers, which simplify and set/query NFD’s internal states.
the configuration of various parameters that will be
used during the simulation execution. 2.3.2 Challenges of NFD integration
We used the LinkService abstraction to implement the Towards this integration, we had to address the following
basic communication principles instead of implementing challenges:
our own Transport. This is a solution to optimize packet • We had to enable the use of simulation time in NFD.
processing and avoid unnecessary memory operations. Therefore, we took advantage of the CustomClock
Through this approach, we also managed to maintain the class provided by the ndn-cxx library in order to
NS3 packet tags attached to each packet sent/received by a convert ndnSIM time to system clock::time point and
simulated node, which otherwise would be lost. steady clock::time point.
• The scheduler of NFD was redirected to ns3::Simulator,
so that NFD can schedule events that will be executed
2.2 Core NDN protocol by the simulator.
The core component of the ndnSIM architecture is
2. Because of these required adaptations, the version of NFD that
ndn::L3Protocol. This component serves as a consolidator ndnSIM is based on tends to be slightly behind the latest version of
for the NDN protocol stack and can be installed in each NFD/ndn-cxx
 4

• To optimize the signing process used by NFD for the

FIB Helper Forward to
interaction with its managers through its management NFD’s FIB
AddRoute
protocol, we designed a custom keychain that provides Create Signed Sign manager
RemoveRoute Interest using
high performance (i.e., minor crypto overhead) during for /localhost/fib/ DummyKeyChain
the simulation. However, for simulations that need real
crypto operations, the use of a full-featured keychain
structure can be selected in the simulation scenario. Fig. 2: Operations of the FIB helper
• The forwarding pipeline of NFD had to be ex-
tended with the beforeSatisfyInterest and beforeEx-
pirePendingInterest signals, so that the tracing of the 2.3.7 Pending Interest Table (PIT)
SatisfiedInterests and TimedOutInterests events is en- In our implementation, the class nfd::Pit of NFD is used as
abled to the simulator. the PIT abstraction. PIT maintains the state for the Interest
• We enabled the configurability of NFD parameters in- packets that have been forwarded upstream toward one (or
ternally using specially designed configuration files to more) potential data source(s) of matching Data. It provides
avoid the overhead of parsing raw external files and directions for the reverse forwarding of the Data packets
thus optimize the simulation process. toward the data consumer(s). In addition to that, PIT also
contains recently satisfied Interest packets for the purposes
2.3.3 Face abstraction of loop prevention.
For more information about the PIT structure and the
It is similar to the corresponding abstraction of the previ-
operations performed on it, one can refer to [7].
ous ndnSIM version. This abstraction (nfd::Face) contains
the required low-level communication primitives to handle 2.3.8 Forwarding Information Base (FIB)
Interest and Data packets. As mentioned in [7], these primi-
The class nfd::Fib of NFD is used as the FIB abstraction.This
tives include functions to send an Interest/Data packet and
abstraction is used by the forwarding strategies for Interest
terminate the communication on a Face.
forwarding toward potential content source(s). For each
Interest that needs to be forwarded, a longest prefix match
2.3.4 ndnSIM specific ndn::Face
lookup is performed on the FIB.
The version of ndn-cxx library bundled with ndnSIM in- The FIB is updated only through the FIB management
cludes a modified version of ndn::Face to directly send and protocol, which is operated on the NDN forwarder side
receive Interest and Data packets to and from the simulated by the FIB manager. To simplify common operations, we
instances of NFD. With this modification, ndnSIM enables created a FIB helper that, for the high-level FIB operations,
support to simulate real NDN applications written against prepares special signed Interest commands and sends them
the ndn-cxx library. A detailed guide on how to simu- towards the FIB manager. Currently, the FIB helper imple-
late such applications is available on the ndnSIM website: ments two high-level operations (Figure 2):
http://ndnsim.net/2.1/guide-to-simulate-real-apps.html. • AddRoute: Create a new FIB entry, add a route to the
FIB entry, or update the cost of the existing record in
2.3.5 LinkService abstraction the FIB entry.
A link service of NFD must translate between net- • RemoveRoute: Remove a route record from the FIB
work layer packets (Interests, Data, and Nacks) and entry (a FIB entry with empty NextHop records will
link layer packets (TLV blocks). In ndnSIM, we be automatically deleted).
have implemented a special Link Service base class The Interest commands sent to the FIB manager are
(ndn::TracingLinkService), which is used by both the signed using the custom key chain mentioned in previous
ndnSIM applications (ndn::AppLinkService) and the layer section, which is specially designed to eliminate signing
2 devices (ndn::NetDeviceLinkService). crypto overhead for simulation purposes. If necessary, the
full featured crypto support can be re-enabled by switching
2.3.6 NFD’s Content Store to the standard KeyChain provided by the ndn-cxx library.
In the NDN communication model, Content Store offers in-
network caching for Data packets. Arriving Data packets 2.3.9 Forwarding Strategy abstraction
are placed in the cache as long as possible, so that to As mentioned before, the forwarding strategy abstraction of
satisfy future Interests that would request the same Data. NFD makes the decisions regarding the Interest forwarding.
In this way, the protocol performance is enhanced making That is to say, whether an Interest would be forwarded or
NDN robust against packet losses and errors and capable of not, the upstream face(s), where it would be forwarded,
inherent multi-casting. and when it would be forwarded to the selected upstream
As with many other forwarding components, this ver- face(s). ndnSIM/NFD features an abstract interface (strategy
sion of ndnSIM uses content store implementation from the API) that provides the basic implementation of the forward-
NFD codebase. This implementation takes full consideration ing strategies without the need of re-implementing the full
of Interest selectors, however is not yet flexible when it Interest processing pipeline. An overview of the forwarding
comes to cache replacement policies. The feature to extend pipeline is presented in Figure 3 and is described in detail
CS flexibility is currently in active development and, for the in the rest of this section.
time being, we have also ported the old ndnSIM 1.0 content The implemented forwarding pipeline allow per-
store to the new code base, which is discussed in 2.6. namespace selection of a specific forwarding strategy. This
 5

Interest   Strategy  callback   Interest  

loop   reject  
A9er  receive  
Interest  

Incoming   Outgoing  
Interest   Interest  

Faces   Timer   Before  expire   Faces  

Interest  
Interest  
Strategy  callbacks   Incoming  
unsa2sfied  
Data  
Before  sa2sfy  
Interest  

Outgoing   Data  
Data   unsolicited  

1  

Fig. 3: Overview of ndnSIM/NFD forwarding pipeline

per-namespace forwarding strategy is registered and main- the same model. If timers are needed, EventId fields need to
tained at the Strategy Choice table. The Strategy Choice ta- be added to such data structure(s).
ble is updated through the management protocol, operated The final step is to implement at least the “After Receive
by the Strategy Choice manager. Similarly to FIB operations, Interest” trigger and any (or none) of the three other triggers
we created a Strategy Choice helper that prepares and sends listed below:
special signed Interest commands to the manager when • After Receive Interest: When an Interest is received,
strategy selection is requested in the simulation scenario. passes necessary checks, and needs to be forwarded,
The following built-in forwarding strategies are cur- the Incoming Interest pipeline invokes this trigger with
rently available: the PIT entry, incoming Interest packet, and FIB entry.
• Broadcast: Forwards every Interest to all upstream • Before Satisfy Interest: When a PIT entry is satisfied,
faces. before Data is sent to downstream faces (if any), the
• Client Control Strategy: Allows a local consumer ap- Incoming Data pipeline invokes this trigger with the
plication to choose the outgoing face of each sent Inter- PIT entry, the Data packet, and its incoming face.
est packet. • Before Expire Interest: When a PIT entry expires be-
• Best Route: Forwards an Interest packet to the up- cause it has not been satisfied before all in-records
stream face with the lowest routing cost. expire, before it is deleted, Interest Unsatisfied pipeline
• NCC: Re-implementation of the CCNx 0.7.2 default invokes this trigger with the PIT entry.
strategy. Actions are the forwarding decisions made by each
A new forwarding strategy can implement a completely forwarding strategy and are implemented as non-virtual
custom processing or override specific actions in the existing protected methods of the nfd::Strategy class. The provided
forwarding strategy. The initial step in creating a new strat- actions are listed below:
egy is to create a class, say MyStrategy that is derived from • Send Interest: It triggers when entering the Outgoing
the nfd::Strategy class. This subclass must at least override Interest pipeline.
the triggers that are marked as pure virtual and implement • Reject Pending Interest: It triggers when entering the
them with the desired strategy logic. It may also override Interest reject pipeline.
any other available triggers that are marked as just virtual. To simplify the operations of specifying the desired per-
If the strategy needs to store information, it is needed to name prefix forwarding strategy for one, more or all the
decide whether the information is related to a namespace topology nodes, we provide a Strategy Choice helper that
or an Interest. Information related to a namespace but not interacts with the Strategy Choice manager of NFD by
specific to an Interest should be stored in Measurements sending special signed Interest commands to the manager.
entries; information related to an Interest should be stored The operations of this helper are illustrated in Figure 4
in PIT entries, PIT downstream records, or PIT upstream
records. After this decision is made, a data structure derived
from StrategyInfo class needs to be declared. In the existing 2.4 Application Link Service
implementation, such data structures are declared as nested This class enables the communication of the simulated ap-
classes as it provides natural grouping and scope protection plications with the NDN network. Specifically, this abstrac-
of the strategy-specific entity, but it is not required to follow tion provides functions for sending interests, data packets
 6

StrategyChoice 2.7 Basic NDN applications

Helper Forward to NFD’s
Install send StrategyChoice
command Create Signed Interest manager
InstallAll
Install the helper
in each specified node
for /localhost/nfd/
strategy-choice
Sign
using DummyKeyChain The basic applications included in the current ndnSIM re-
lease are the same applications that have been included in its
previous release with minor changes due to the introduction
of the ndn-cxx library:
Fig. 4: Operations of the StrategyChoice helper
• ConsumerCbr: a consumer application that generates
Interest traffic according to a user-defined pattern (e.g.,
and NACKs as well as methods to receive packets from the predefined frequency, constant rate, constant average
NDN stack. It extends the ndnSIM specific link service class rate with inter-Interest gap distributed uniformly at
(ndn::TracingLinkService). We should note that the wording random, exponentially at random, etc.). A user-defined
”send” refers to packets that are sent from the NDN stack Interest name prefix and sequence number are avail-
and thus are received from the application. able. Moreover, this application provides Interest re-
transmission according to an RTT-based timeout period
similar to the TCP RTO.
2.5 Network Device Link Service
• ConsumerBatches: a consumer application that gener-
This component enables the communication between the ates a specified number of Interest packets at specified
simulated nodes. Each ndn::NetDeviceLinkService instance time points of the simulation.
is permanently associated with a NetDevice object and this • ConsumerWindow: a consumer application that gener-
object cannot be changed for the lifetime of this face. For ates Interest traffic of variable rate. It implements a sim-
sending packets between simulated nodes, Interest, Data ple sliding-window-based Interest generation mecha-
and NACK packets are converted into the NDN packet nism.
format, using routines of the ndn-cxx library, and then are • ConsumerZipfMandelbrot: a consumer application
encapsulated to a packet instance of NS-3. It extends the that requests contents (i.e., names in the requests) fol-
ndnSIM specific link service class (ndn::TracingLinkService). lowing the Zipf-Mandelbrot distribution.
• Producer: a simple application that sinks Interest traffic
and generates Data traffic. Specifically, it responds to
2.6 ”Old” Content Store each incoming Interest packet with a Data packet that
As mentioned above, because of the fact that NFD’s Content has the same size and name as the corresponding
Store is not yet flexible when it comes to cache replacement incoming Interest packet.
policies, we have also ported the old ndnSIM 1.0 content
The interaction of the applications with the core of
store implementations to the new code base (Table 3). These
the simulator is achieved using the ndn::AppLinkService
implementations feature different cache replacement poli-
realization of the nfd::face::LinkService abstraction. The base
cies, but have limited support for Interest selectors.
class ndn::App is responsible for the creation/deletion of the
TABLE 3: “Old” Content Store Implementations ndn::AppLinkService instances and their registration in the
protocol stack.
Simple content stores
cs::Lru Least recently used (LRU) (default)
cs::Fifo First-in-first-Out (FIFO)
cs::Lfu Least frequently used (LFU)
2.8 Trace helpers
cs::Random Random
cs::Nocache Policy that completely disables caching
Content stores with entry lifetime tracking
The trace helpers simplify the collection and aggregation
These policies allow the evaluation of CS enties lifetime (i.e., how of various necessary statistical information about the sim-
long entries stay in CS) ulation and write this information in text files. In our im-
cs::Stats::Lru Least recently used (LRU) plementation, the capability of tracing events directly from
cs::Stats::Fifo First-In-First-Out (FIFO)
cs::Stats::Lfu Least frequently used (LFU) NFD has been added to the tracers. There are three sorts of
cs::Stats::Random Random such helpers:
Content stores respecting freshness field of Data packets
These policies cache Data packets only for the time indicated by
• Packet-level trace helpers: This group includes
FreshnessPeriod. L3RateTracer and L2Tracer. The former traces the rate
cs::Freshness::Lru Least recently used (LRU) in bytes and in number of packets of Interest/Data
cs::Freshness::Fifo First-In-First-Out (FIFO) packets forwarded by an NDN node, while the latter
cs::Freshness::Lfu Least frequently used (LFU)
cs::Freshness::Random Random traces only packets that are dropped on layer 2 (e.g.,
Content store realization that probabilistically accepts data packet due to a transmission queue overflow).
into CS (placement policy) • Content store trace helper: With the use of CsTracer, it
These policies cache Data packets only for the time indicated by is possible to obtain statistics of cache hits/misses on
FreshnessPeriod. the Content Store of the simulated nodes.
cs::Probability::Lru Least recently used (LRU)
cs::Probability::Fifo First-In-First-Out (FIFO) • Application-level trace helper: With the use of Ap-
cs::Probability::Lfu Least frequently used (LFU) pDelayTracer, it is possible to obtain data regarding
cs::Probability::Random Random delays between issuing Interest packets and receiving
the corresponding Data packet.
 7

3 L IMITATIONS OF CURRENT VERSION AND FU - impossible thus limiting the experimental scope of this
TURE PLAN simulator.
Another recently introduced effort is Mini-CCNx [17].
Despite the fact that we provide an API to developers in Mini-CCNx is a fork of Mininet-HiFi specially customized
order to simulate real applications using ndnSIM, these to support the emulation of CCNx-NDNx nodes. Its main
applications have to satisfy certain requirements. These goal is to add a realistic behavior to the executed tests.
requirements are primarily posed by the different logic Mini-CCNx offers flexibility, because of the Container-Based
between real and simulated apps (as they need to be im- Emulation features of Mininet, and a simple configuration
plemented in NS3 and ndnSIM). A detailed list of those GUI interface. However, it is based on the packet format of
requirements is available on our website: http://ndnsim. NDNx, which is an outdated version of the NDN communi-
net/guide-to-simulate-real-apps.html#requirements. cation model. It also mainly focuses on emulating the node
NFD versions 0.4 and above handle and process NACKs hardware instead of the communication model itself.
and, thus, support NDNLPv2. In this version, ndnSIM does The affluence of computing resources across the existing
not support NDNLPv2 and, as a result, cannot be yet used research network testbeds/infrastructures (e.g., GENI [18],
to simulate network-level NACKs across simulated nodes. Open Network Lab (ONL) [19], Emulab [20], etc.) also offers
This will be addressed in the next release of ndnSIM. a valuable option for the conduction of real-time research
experiments. These testbeds provide both the hardware and
the software systems needed by researchers to evaluate their
4 R ELATED W ORK
design. However, the complexity that is introduced in order
Within the recent years, the interest for NDN research has to configure and manage all the delegated resources along
grown. As a consequence, the development of common with the limited experimental scale are two crucial reasons
and handy ways for the evaluation of the proposed NDN that lead researchers to resort to simulations.
research approaches has been absolutely necessary.
One of the first and popular approaches towards that
goal is the previous version of ndnSIM [6]. This version, 5 S UMMARY
exactly like the current one, is implemented in a modular In this updated simulator, we have focused our efforts
way and was optimized for simulation purposes. However, on providing a more realistic simulation behavior by inte-
the previous version included an independent implemen- grating the Named Data Networking Forwarding Daemon
tation of NDN packet forwarding and used a deprecated (NFD) with ndnSIM and using directly the ndn-cxx library
NDN packet format. Moreover, the ndnSIM 1.0 never imple- and the latest NDN packet format. ndnSIM provides the
mented the full-featured processing of NDN selectors and, framework for large-scale experimentation, while its modu-
as a result, has limitations regarding the accuracy of the lar design offers the flexibility to the researchers to modify
simulation results. its components with minimal, if any, changes to other parts
Another existing effort is presented by Chioccheti et of its implementation. Detailed information about the cur-
al. [10, 11]. ccnSim is a scalable chunk-level simulator rent release and additional documentation is available on
suitable for the analysis of caching performance of NDN the ndnSIM webstite: http://ndnsim.net.
networks. It is developed using the OMNeT++ framework We really hope that the NDN community will find
in C++. However, it is mainly optimized for the experi- ndnSIM a valuable tool and we are looking forward to
mentation on various cache replacement policies for NDN receiving the community’s priceless feedback in order to
routers and does not provide any flexibility of the forward- further improve the simulator.
ing process. As a result, ccnSim cannot be used for the
experimentation on a vital core component of the NDN
architecture, which is the forwarding strategy layer. 6 A PPENDIX
CCN-lite [12] is a lightweight implementation of the In this section, we present the revision history of this docu-
CCNx-NDNx protocol. It offers a simulation mode using the ment.
OMNeT++ simulation platform. CCN-lite supports schedul-
ing, both at chunk and at packet level, and packet fragmen-
6.1 Revision History
tation. It also supports possible native deployment without
any IP layer. However, this effort is mainly intended to run • Revision 2 (November 11, 2016): Updates for ndnSIM
on resource constrained devices and is not optimized to 2.1 and 2.2:
offer high performance as its data structures rely on linked – Added description of the simulation of applications
lists. written against the ndn-cxx library and the ndnSIM
The Content Centric Networking Packet Level Simulator specific ndn::Face.
(CCNPL-Sim) [13] is another NDN simulator developed – Renamed the AppFace and NetDeviceFace classes of
at Orange Labs. CCNPL-Sim makes use of the Combined ndnSIM to AppLinkService and NetDeviceLinkSer-
Broadcast and Content-Based routing scheme (CBCB) [14] vice and updated the description of each one.
implementation within the SSim simulator to handle event – Added description on the configurability support of
management and name based forwarding and routing. De- the various parameters of NFD.
spite the effectiveness of the SSim simulation scheduler, – Updated Table 1 and Figure 1 to add the
the mandatory usage of CCNB makes the evaluation of nfd::face::LinkService, ndn::AppLinkService and
other routing protocols, such as OSPFN [15] and NLSR [16], ndn::NetDeviceLinkService classes.
 8

– Revised the overall paper to refer to ndnSIM 2 in [9] ——, “NDN Packet Format Specification,” Online: http:
general instead of ndnSIM 2.0. //named-data.net/doc/ndn-tlv/, 2014.
• Revision 1 (January 27, 2015): Initial release [10] D. Rossi, G. Rossini, “Caching performance of content
centric networksunder multi-path routing (and more),”
Telecom ParisTech, Tech. Rep., 2011.
R EFERENCES [11] G. Rossini and D. Rossi, “ccnSim: an highly scalable
[1] V. Jacobson, D. K. Smetters, J. D. Thornton, M. F. Plass, CCN simulator,” in IEEE ICC, 2013.
N. H. Briggs, and R. L. Braynard, “Networking named [12] C. Scherb, M. Sifalakis, and C. Tschudin, “CCN-lite,”
content,” in Proceedings of ACM CoNEXT, 2009. Available: http://www.ccn-lite.net, 2013.
[2] L. Zhang et al., “Named data networking (NDN) [13] L. Muscariello. (2011) Content centric net-
project 2010 - 2011 progress summary,” PARC, working packet level simulator. Orange Labs.
http://www.named-data.net/ndn-ar2011.html, Tech. [Online]. Available: http://perso.rd.francetelecom.fr/
Rep., November 2011. muscariello/sim.html
[3] L. Zhang et al., “Named data networking (NDN) [14] A. Carzaniga, M.J. Rutherford, and A.L. Wolf, Ed., A
project,” PARC, Tech. Rep. NDN-0001, October 2010. Routing Scheme for Content-Based Networking. IEEE
[4] L. Zhang, A. Afanasyev, J. Burke, V. Jacobson, K. Claffy, INFOCOM, March 2004.
P. Crowley, C. Papadopoulos, L. Wang, and B. Zhang, [15] L. Wang, A. Hoque, C. Yi, A. Alyyan, and B. Zhang,
“Named data networking,” ACM SIGCOMM Computer “OSPFN: An OSPF based routing protocol for Named
Communication Review, July 2014. Data Networking,” NDN, Tech. Rep NDN-0003, 2012.
[5] (2012, May) ns-3. [Online]. Available: http://www. [16] NDN Project, “NLSR - Named Data Link State Rout-
nsnam.org/ ing Protocol,” Online: http://named-data.net/doc/
[6] A. Afanasyev, I. Moiseenko, and L. Zhang, “ndnSIM: NLSR/0.1.0/, 2014.
NDN simulator for NS-3,” NDN, Technical Report [17] C. Cabral, C. E. Rothenberg, and M. F. Magalhães, “Re-
NDN-0005, October 2012. [Online]. Available: http: producing real NDN experiments using mini-CCNx,”
//named-data.net/techreports.html in Proceedings of the 3rd ACM SIGCOMM workshop on
[7] A. Afanasyev, J. Shi, B. Zhang, L. Zhang, I. Moi- Information-centric networking, 2013.
seenko, Y. Yu, W. Shang, Y. Huang, J. P. Abraham, [18] (2015, January) GENI (Global Environment for
S. DiBenedetto, C. Fan, C. Papadopoulos, D. Pesavento, Network Innovations). [Online]. Available: http:
G. Grassi, G. Pau, H. Zhang, T. Song, H. Yuan, H. B. //www.geni.net
Abraham, P. Crowley, S. O. Amin, V. Lehman, , and [19] (2015, January) Open Networking Lab. [Online].
L. Wang, “NFD developers guide,” NDN Project, Tech. Available: http://onlab.us
Rep. NDN-0021, July 2014. [20] (2015, January) Emulab - Network Emulation Testbed.
[8] NDN Project, “NFD - named data networking for- [Online]. Available: http://www.emulab.net
warding daemon,” Online: http://named-data.net/
doc/NFD/0.2.0/, 2014.