See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/318487817

A new NS3 Implementation of CCNx 1.0 Protocol

Article · July 2017

CITATIONS READS
0 76

5 authors, including:

Marc Mosko
Palo Alto Research Center
53 PUBLICATIONS   212 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Content Centric Networking View project

All content following this page was uploaded by Marc Mosko on 18 June 2019.

The user has requested enhancement of the downloaded file.

 networking and distributed systems
computing science laboratory
copyright 2016

A new NS3 Implementation of CCNx 1.0

Protocol
Marc Mosko*, Ramesh Ayyagari, Priti Goel, Eric Holmberg, Mark Konezny

Abstract
The ccns3Sim project is an open source implementation of the CCNx 1.0 protocols for the NS3 simulator. We
describe the implementation and several important features including modularity and process delay simulation.
The ccns3Sim implementation is a fresh NS3-specific implementation. Like NS3 itself, it uses C++98 standard,
NS3 code style, NS3 smart pointers, NS3 xUnit, and integrates with the NS3 documentation and manual. A
user or developer does not need to learn two systems. If one knows NS3, one should be able to get started with
the CCNx code right away. A developer can easily use their own implementation of the layer 3 protocol, layer
4 protocol, forwarder, routing protocol, Pending Interest Table (PIT) or Forwarding Information Base (FIB) or
Content Store (CS). A user may configure or specify a new implementation for any of these features at runtime
in the simulation script. In this paper, we describe the software architecture and give examples of using the
simulator. We evaluate the implementation with several example experiments on ICN caching.
keywords
ICN, CCNx, NS3, Simulation
Computing Science Laboratory, PARC
*corresponding author: [email protected]

Contents 1. Introduction
1 Introduction 1 The ccns3Sim [1] open source project is an NS3 [2] im-
plementation of the CCNx 1.0 protocol specifications
2 Node Architecture 2
[8, 7]. It is released as a source code module for the
2.1 Modeling delays . . . . . . . . . . . . . . . . . . . . . . .4 NS3 simulator. It runs with an unmodified NS3 simu-
2.2 CCNxL3Protocol (Layer 3) . . . . . . . . . . . . . . . .5 lator, though one patch is required to add an Ethertype
2.3 CCNxStandardForwarder . . . . . . . . . . . . . . . . .5 to the PPP implementation. ccns3Sim includes many
2.4 CCNxPortal (Layer 4) . . . . . . . . . . . . . . . . . . .6 examples and documentation.
The ccns3Sim implementation is a fresh NS3-
3 Routing 6
specific implementation. Like NS3 itself, it uses C++98
3.1 Installing a routing protocol . . . . . . . . . . . . . . . 7 standard, NS3 code style, NS3 smart pointers, NS3 xU-
3.2 Name Flooding Protocol Routing . . . . . . . . . . . 7 nit, and integrates with the NS3 documentation and
4 Applications 8 manual. A user or developer does not need to learn two
systems. If one knows NS3, one should be able to get
4.1 Consumer-Producer . . . . . . . . . . . . . . . . . . . . 8
started with the CCNx code right away. A developer
5 Experiments 8 can easily use their own implementation of the layer 3
6 Conclusions 9 protocol, layer 4 protocol, forwarder, routing protocol,
References 9
Pending Interest Table (PIT) or Forwarding Information
Base (FIB) or Content Store (CS). A user may config-
ure or specify a new implementation for any of these
 A new NS3 Implementation of CCNx 1.0 Protocol — 2/9

features at runtime in the simulation script. Sim.

The general architectural model of ccns3Sim is to The remainder of the paper is organized as follows.
use an abstract base class as an interface and then pro- Section 2 describes ccns3Sim’s software architecture.
vide an implementation class of that interface. For It also describes the robust delay model and shows how
example, the CCNxPit abstract base class defines the to implement both input delays and processing delays.
API of the PIT table and the implementation class CC- Section 2.2 describes the layer 3 components, and in par-
NxStandardPit realizes a PIT based on the current ticular the forwarder and associated tables. Section 2.4
specifications. Because the abstract class inherits from describes the layer 4 components, which we call the
ns3::Object, one can use run-time binding, making CCNxPortal interface. Section 3 describes the routing
it easy for a user to substitute new implementations. protocol and the details of NFP. Section 4 describes the
We introduce the Name Flooding Protocol (NFP), application model and the example consumer-producer
a simple distance-vector routing protocol for CCNx. It app. Section 5 presents several experiments conducted
provides basic loop-free equal-cost multipath routing for with ccns3Sim. Section 6 concludes the paper and
CCNx names. Each anchor for a prefix (device advertis- summarizes it’s contributions.
ing a prefix) uses its own sequence number for each ad-
vertisement, which are then ordered by distance. Each 2. Node Architecture
anchor is an independent successor graph for the prefix ccns3Sim is designed such that a single ns3::Node
and will induce its own equal-cost multipath graph. If may have zero or more CCNx applications running on
two or more anchors advertise the same prefix, NFP it, plus a forwarder and routing protocol. An applica-
allows unequal cost multipath to each anchor. tion running on a node uses one or more CCNxPortal
The ndnSim project [6] is a customized NS3 distribu- interfaces to pass messages to the local forwarder. Each
tion that uses the regular NDN open source code ndn- application instantiates its own Portals, similar to how
cxx (NDN C++ library with eXperimental eXtensions) an Internet application uses Sockets. A routing proto-
and nfd (NDN Forwarding Daemon). This approach has col is similar to an application in that it uses one or
a significant advantage in that it uses the same libraries more Portals to communicate with peers, but it derives
as regular NDN applications and forwarders, so there from CCNxRoutingProtocol instead of CCNxAppli-
is high code re-use and the simulator stays up-to-date cation. A routing protocol also uses the CCNxFor-
with the non-simulation release. The disadvantage of warder interface on a node to manipulate the FIB in-
this approach is that simulation must use the production side the forwarder. ccns3Sim can operate with any
code, it introduces two object models, two memory man- NS3 NetDevice. We have tested with point-to-point,
agement models, and two coding style models. It may CSMA, WiFi, and virtual devices using UDP tunnels.
also make certain instrumentation that one would like The CCNx NS3 architecture is shown in Fig. 1. Every
to see in simulation difficult, because the ndn-cxx and major component is described by an interface (abstract
nfd libraries were not designed with simulation in mind. base class) and inherits from the ns3::Object. This
For example, it can be difficult to simulate processing allows run-time late binding of each piece to a user-
delays in data structures. specified implementation in the simulation script. The
ccnSim [3] is a C++ simulator implemented in Om- core of the architecture is the CCNxL3Protocol, which
net++. The authors claim it is a highly scalable simulator is the switching fabric for the layer 3 protocol. It is con-
able to support content stores with up to 106 chunks and nected to network devices below and layer 4 protocols
catalogs of up to 108 files. The current version, ccnsim- above. There is also a special interface CCNxForwarder
v0.4, may support much larger catalogs and operates to the forwarding engine, which is responsible for se-
up to 100x faster than the previous version. ccnSim sup- lecting the egress connection of each input packet. We
ports several caching mechanisms (decision strategies), describe each of these components in more detail below.
such as leave copy everywhere, leave copy down, and The CCNx node architecture differs from the NS3
betweeness centrality. It also supports several cost and Internet model in that we have separated the routing
replacement functions to determine if a content is cached protocol from the forwarding process. In the NS3 model,
what what gets evicted. Our present work, ccns3Sim, the routing protocol, in addition to exchanging routing
is a more general purpose simulator for transport proto- messages with peers and executing a routing process,
cols, routing protocols, and other protoocol features, it is also handles calls to RouteInput() and RouteOut-
not a highly optimized for content caching simulations. put(). In the CCNx architecture, the routing protocol
NS3’s operational model of serializing and deserializing only exchanges messages with peers and executes a rout-
each packet at each hop means that content store copies ing process. It maintains a Routing Information Base
are not memory references to a common repository. This (RIB). Using the CCNxForwarder interface, the rout-
makes the initial code release of ccns3Sim inefficient ing protocol calls AddRoute() and RemoveRoute()
for large content caching experiments compared to ccn- to manage the Forwarding Information Base (FIB) in-
 A new NS3 Implementation of CCNx 1.0 Protocol — 3/9

the NFP routing protocol.

• CCNxStandardLayer3Helper: Used to configure and
install the standard Layer3. This component man-
ages the set of Layer 2 interfaces, the Layer 3 peers
and Layer 4 protocols.
• CCNxStandardForwarderHelper: The forwarder hel-
per installs the RFC-draft compliant forwarder,
which its associated PIT, FIB, and Content Store.
Note that the table factories are specific to the for-
warder helper implementation. A label-swapping
forwarder, for example, that does not have a PIT
table does not need to expose an ObjectFactory
Figure 1. CCNx Class Architecture for creating a PIT.
• CCNxStandardPitFactory: The factory from which
CCNxStackHelper PIT tables are created with a given set of parame-
ters and implementation.
CCNxAsciiTraceHelper
<<instanceof>>
• CCNxStandardFibFactory: The factory from which
FIB tables are created with a given set of parame-
CCNxRou8ngHelper CCNxLayer3Helper CCNxForwardingHelper ters and implementation.
<<extends>> <<extends>> <<extends>> • CCNxStandardContentStoreFactory: The factory
CCNxStandard from which Content Stores are created with a
NfpRou8ngHelper NfpRou8ngHelper
ForwarderHelper
given set of parameters and implementation.
<<instanceof>>
The code snippit in Listing 1 shows a portion of a
ObjectFactory ObjectFactory ObjectFactory
simulation script that uses the CCNxStackHelper to
CCNxStandard CCNxStandard CCNxStandard
PitFactory FibFactory ContentStoreFactory install the CCNx protocol on all the nodes in a Node-
Figure 2. CCNxStackHelper Container.

1 NodeContainer nodes ;
side the forwarder. The forwarder, via the CCNxFor-
2 nodes . Create ( 5 ) ;
warder interface, handles calls to RouteInput() and 3
RouteOutput(). 4 CCNxStackHelper ccnx ;
The user selects each component via the simulation 5 ccnx . Install ( nodes ) ;
script. Figure 2 shows the set of “helpers” for use in Listing 1. Installing CCNx on NodeContainer
the simulation script. The top-most helper is the CCNx-
StackHelper. It is responsible for the overall instal- The CCNxPortal abstraction is the layer 4 protocol
lation of CCNx on an ns3::Node or ns3::NodeCon- from the applications’s point of view. It has functions
tainer. Each major architectural component – the layer to Send(), SendTo(), Recv(), and RecvFrom() using a
3 implementation, the forwarder implementation, and CCNxMessage. We provide one implementation class,
the routing protocol – has its own helper. CCNxMessagePortal, which is a simple 1-for-1 pro-
In NS3 terminology, a Helper is a factory that can tocol without any transport features (like a UDP). The
create an object and then aggregates it to an NS3 node. CCNxMessage class is the base for CCNxInterest and
Aggregating an object to a node makes an association CCNxContentObject. The class CCNxL4Protocol is
between the class and the node, so at a later time one the layer 4 abstraction from the layer 3 point of view. An
can ask a node for a specific implementation. This is, implementation class like CCNxMessagePortal inher-
for example, how the NfpRoutingProtocol uses the its from both CCNxPortal and CCNxL4Protocol.
CCNxForwarder interface without needing to know ex- One can run CCNxL3Protocol over any Layer 2 Net-
actly which implementation is being used. When the for- Devices. We have used it over point-to-point, CSMA,
warder implementation, such as CCNxStandardFor- WiFi, and VirtualNetDevice in our unit tests. One
warder aggregates on to a node, it can be retrieved via could use CCNx over IP tunnels (e.g. UDP tunnels)
its base class. using a VirtualNetDevice wrapping a UDP socket.
ccns3Sim’s packet coding is wire-format compati-
• NfpRoutingHelper: Used to configure and install ble with the standard CCNx 1.0 TLV format. We have,
 Message pipeline delays CCNxDelayQueue<T>
A new NS3 Implementation of CCNx 1.0 Protocol — 4/9

Delayed
StandardLayer3 GetServiceTime(T item)
No Delay

StandardForwarder
NetDevice
NetDevice
NetDevice
ProcessDelay PIT
InputDelay
InputDelay
MessagePortal push_back(T item) DequeueCallback(T item)
ProcessDelay FIB
InputDelays
App

ProcessDelay CS
ns3 Timer
Figure 4. Delaydelay
Queue
Figure 3. Layer delays

number of parallel servers of the queue (which enforces

for example, taken PCAP traces from NS3 and replayed
the delay) and two functions. The first function GetSer-
them on real networks to our software forwarders. The
viceTime(T item) is called whenever a queue item
current NS3 implementation is only partially config-
is moved to the head-of-line and there is a free server for
urable for modular codecs, but we expect to have fully
it. The second function DequeueCallback(T item)
configurable codecs in the near future. Because CCNx
is called after the service time is over. It dequeues the
1.0 uses the hierarchical nesting of TLV types to deter-
item back to the user’s code.
mine containment, we will use a notation like SNMP
MIB OIDs to specify codecs. For example, TLV type 1 is
Interest message and TLV type 0 is it’s CCNxName, so 1 Time GetServiceTime ( T item ) {
“.1.0” would specify the codec for the name. TLV type 1 2 r e t u r n MicroSeconds ( 2 ) ;
3 }
is the Payload of the Interest, so “.1.1” is used to lookup 4 void DequeueCallback ( T item ) {
the payload’s codec, and so on. This model allows a 5 MyResultClass result = lookup ( item ) ;
user to either replace a specific codec or introduce new 6 callNextStage ( item , result ) ;
TLV types and new codecs at run time. A codec may be 7 }
used by multiple OIDs. For example “.1.0” and “.2.0” Listing 2. Modeling input delay
are both CCNxName codecs. The first is for an Interest
message and the second is for a Content Object message. When used to model input delay, the GetService-
Time(T item) function only depends on the input to
2.1 Modeling delays the function. It could be a constant, or some function of
The CCNxDelayQueue is a general queuing class to de- the queue item. The delay, for example, could be linear
lay events. Several of the major CCNx forwarding com- in the number of bytes of the packet or some function
ponents have delay queues to model computation time. of the number of name components. An example of a
We use the terminology input delay to mean a delay that constant delay using this model is in Listing 2. Once the
only depends on the input to the delay queue, not the service time is over, the DequeueCallback(T item)
processing done. The term processing delay means a de- function carries on processing the queue item.
lay that depends on the processing, such as the number
of tables consulted or the number of name components 1 Time GetServiceTime ( T item ) {
searched. Both use the same data structure, it is only a 2 MyResultClass result = lookup ( item )
difference of where the processing is done. 3 item−>SetResult ( result ) ;
4 r e t u r n result−>GetServiceTime ( ) ;
We provide examples of using both input delay and 5 }
processing delay models. Input delay models are useful 6
for layers where the delay only depends on the item 7 void DequeueCallback ( T item ) {
being delayed. One example is the delay in CCNxStan- 8 callNextStage ( item ) ;
9 }
dardL3, which is only a fixed delay. Another example is
CCNxStandardPit, which uses a linear function of the Listing 3. Modeling processing delay
CCNxName byte length. Processing delay models are
useful for cases where the delay depends on the result of When used to model processing delay, the delay
the processing. CCNxStandardFib, for example, uses calculation depends on the processing function. A FIB
a linear function of the number of FIB lookups done to lookup delay, for example, might depend on the number
find the longest matching prefix. CCNxStandardCon- of name components and the length of each component.
tentStore uses a constant delay if no match is found The typical usage pattern is for GetServiceTime(T
and a linear delay in terms of the size of the Content item) to perform the processing on item and put the
Object matched otherwise. result back in item (e.g. item->SetResult(...))
A CCNxDelayQueue<T> is constructed with the and then return the amount of simulation delay to wait.
 A new NS3 Implementation of CCNx 1.0 Protocol — 5/9

Once the delay is over and the item is passed to De- 2.3 CCNxStandardForwarder
queueCallback(T item), no further calculation is The CCNxForwarder abstract base class represents the
done and item is passed to the next step in the service interface to a forwarder. A forwarder manages all the
pipeline. Listing 3 shows an example of this usage. state necessary to find the next hop for packet. In a
standard implementation, this means it has a FIB to
2.2 CCNxL3Protocol (Layer 3) forward Interest and a PIT to forward Content Objects.
As shown in Figure 1, the CCNxL3Protocol interface The class CCNxStandardForwarder implements the
(abstract base class), implemented by CCNxStandard- standards-based forwarder. The principle function of
layer3 class, is the central glue between the network the forwarder is to service calls to RouteInput() and
and the node. Besides the necessary APIs to send and RouteOutput(). These functions, whose names are
receive packets, it also performs these functions: taken from the NS3 Internet module, are the interface
to forward a packet. CCNxL3Protocol calls the first
• Layer 3 Interfaces: It maintains a layer 3 abstraction
when it receives a packet from a network device and
of network devices via the CCNxL3Interface
calls the second when it receives a packet from a Layer
class. This maintains layer 3 data about an inter-
4 protocol. The result of those functions is a vector of
face, such as if CCNx is forwarding on it or if the
CCNxConnections on which forward the packet.
interface is administratively up or down. It also
A user may configure the forwarder via the CC-
tracks how to broadcast on a network device.
NxStandardForwarderHelper, which implements
• Connection Table: The connection table stores infor- the CCNxForwarderHelper abstract base class. A
mation about each adjacency using the CCNxCon- user may entirely replace the forwarder by im-
nection abstract base class. It is implemented plementing their own forwarder and forwarder
by CCNxConnectionDevice for layer 2 devices helper. For example, as shown in Listing 5,
and CCNxConnectionL4 for layer 4 transport the class acme::AcmeForwarder implements the
connections. Each individual peer on a network CCNxForwarder interface and is configured via
interface has its own connection. Each layer 2 acme::AcmeForwarderHelper.
interface that supports broadcast has a special con-
nection in the connection table for its broadcast 1 AcmeForwarderHelper forwarder ;
address. 2 forwarder . UseTwoCopy ( t r u e ) ;
3
• Prefixes: Registering a prefix from Layer 4 means 4 CCNxStackHelper ccnx ;
the FIB will be updated to add to a specific CC- 5 ccnx . SetForwardingHelper ( forwarder ) ;
6 ccnx . Install ( nodes ) ;
NxConnectionL4 for the prefix. Unregistering a
prefix removes that connection from the FIB. Listing 5. Using a custom forwarder
• Anchors: Anchors are like registering and unregis- The CCNxStandardForwarderHelper exposes
tering a prefix, but in addition the routing protocol three factories to allow a user to customize or replace
will be notified that the local node is an anchor. the three main functional components: PIT, FIB, and
The routing protocol will then begin advertising ContentStore. This abstraction is specific to the CC-
the prefix as locally reachable. NxStandardForwarderHelper, not the CCNxFor-
warderingHelper because those tables may not exist
in other forwarders, such as a label-swapping forwarder.
1 AcmeLayer3Helper layer3 ; The tables are represented by an
2
3 CCNxStackHelper ccnx ; ns3::ObjectFactory, not a helper. This is be-
4 ccnx . SetLayer3Helper ( layer3 ) ; cause, in ns3 usage, a helper not only creates an
5 ccnx . Install ( nodes ) ; ns3::Object, it also aggregates it to a node. The
Listing 4. Using a custom Forwarder factories for the forwarder tables do not perform an
aggregation step; they are a pure factory, so we call them
The CCNxL3Protocol is replaceable via the sim- a factory not a helper. Suppose you have AcmePit
ulation script. A user could create, for example, the that implements the CCNxPit interface. One may use
AcmeLayer3 that implements the CCNxL3Protocol code similar to Listing 6 to replace the PIT used by the
interface and the AcmeLayer3Helper that im- standard forwarder.
plements the CCNxLayer3Helper abstract base Similar to the PIT, CCNxStandardForwarder-
class. A user may then instantiate the helper in Helper takes an ObjectFactory for the FIB and Con-
the simulation script and pass it to CCNxStack- tent Store. A user may provide their own implementa-
Helper::SetLayer3Helper(), as shown in List- tions by creating their own factory and passing it to the
ing 4. CCNxStandardForwarderHelper.
 A new NS3 Implementation of CCNx 1.0 Protocol — 6/9

1 AcmePitFactory acmePitFactory ; 1 // L o c a l forwarder only

2 acmePitFactory . SetMaxEntries ( 1 0 0 0 ) ; 2 v i r t u a l bool RegisterPrefix ( Ptr<c o n s t CCNxName>←-
3 prefix ) = 0 ;
4 CCNxStandardForwarderHelper forwarder ; 3 v i r t u a l void UnregisterPrefix ( Ptr<c o n s t ←-
5 forwarder . SetPitFactory ( acmePitFactory ) ; CCNxName> prefix ) = 0 ;
6 4
7 CCNxStackHelper ccnx ; 5 // L o c a l forwarder and r o u t i n g p r o t o c o l
8 ccnx . SetForwardingHelper ( forwarder ) ; 6 v i r t u a l bool RegisterAnchor ( Ptr<c o n s t CCNxName>←-
9 ccnx . Install ( nodes ) ; prefix ) = 0 ;
7 v i r t u a l void UnregisterAnchor ( Ptr<c o n s t ←-
Listing 6. Using a custom PIT CCNxName> prefix ) = 0 ;
8
9 // SendTo ( ) should change t o t a k e CCNxConnection
2.4 CCNxPortal (Layer 4) 10 v i r t u a l bool Send ( Ptr<CCNxPacket> packet ) = 0 ;
The ccns3Sim layer 4 is the CCNxPortal. It is mod- 11 v i r t u a l bool SendTo ( Ptr<CCNxPacket> packet , ←-
eled after the ns3::Socket, which has specializations uint32_t connid ) = 0 ;
12
for UDP and TCP. Likewise, Portal has a specialization 13 v i r t u a l Ptr<CCNxPacket> Recv ( void ) = 0 ;
CCNxMessagePortal, which is a simple Interest and 14 v i r t u a l Ptr<CCNxPacket> RecvFrom ( Ptr<←-
Content Object passing portal that does no processing CCNxConnection> & incoming ) = 0 ;
on the messages. Future specializations are a Manifest
Listing 9. CCNxPortal data API
portal and a Chunked portal that provides reliable, in-
order congestion control.
Listing 8 illustrates a common way to use a Portal
inside a class. The class defines a private variable m por-
1 ObjectFactory f ( ” ns3 : : ccnx : : ←- tal that is instantiated in the method Labore. After
CCNxMessagePortalFactory ” ) ;
2 Ptr<Object> p = f . Create<Object> ( ) ;
the portal is created from its portal factory, the method
3 node−>AggregateObject ( p ) ; must also set the data receive callback, which in this case
is Tempor::ReceiveNotify(). This design is simi-
Listing 7. Binding a Portal Factory
lar to how the NS3 Socket class works. When a packet
arrives in a portal, it will call the receive notify method
to inform the owner of the portal that data is ready. The
1 c l a s s Tempor
2 {
owner of the portal may begin reading immediately (in
3 private : the callback) or could defer reading to a later time.
4 Ptr<CCNxPortal> m_portal ;
5
6 void ReceiveNotify ( Ptr<CCNxPortal> p ) {
7 Ptr<CCNxPacket> packet ;
3. Routing
8 while ( ( packet = p−>Recv ( ) ) ) {
9 // use pac ket ccns3Sim provides two ways to do routing. The first
10 } is to use the CCNxStaticRoutingHelper to create
11 } static routes between two nodes. The second is to use
12 public :
13 void Labore ( Ptr<Node> node ) {
the NFP routing protocol (Section 3.2), which is dynamic
14 m_portal = CCNxPortal : : CreatePortal ( node , ←- routing protocol. A user may also provide their own
TypeId : : LookupByName ( ” ns3 : : ccnx : : ←- routing protocol by implementing the CCNxRouting-
CCNxMessagePortalFactory ” ) ) ; Protocol interface.
15
16 m_portal−>SetRecvCallback ( MakeCallback (&←- A routing protocol uses one or more CCNxPortals
Tempor : : ReceiveNotify , t h i s ) ) ; to send and receive packets from peers. It may also use
17 } CCNxProtal::SendTo() to send a packet to a specific
18 };
connection or rely on the FIB. A routing protocol uses
Listing 8. Using a Portal the CCNxForwarder interface to call AddRoute() and
RemoveRoute() on the forwarder, which allows a very
Similar to ns3::Socket, when CCNx is instanti- loose coupling between the routing protocol and the
ated on a node via CCNxStackHelper, it creates a CC- forwarder.
NxPortalFactory for each portal type (in this case
A user specifies which routing protocol to use as
just a message portal) and aggregates it to the node.
shown in Listing 10. As with other components, the
This allows applications to ask for the portal factory by
user instantiates a routing helper, such as NfpRout-
name and create an instance of CCNxPortal with the
ingHelper, sets any desired parameters on it, then
desired implementation. This method also allows the
passes the helper to the CCNxStackHelper.
user to aggregate their own factories from the simulation
script and use those portals in the same way.
 A new NS3 Implementation of CCNx 1.0 Protocol — 7/9

3.1 Installing a routing protocol its sequence number is larger than the currently known
Instantiating a routing protocol uses the NfpRout- sequence number and it came from a current predeces-
ingHelper, as shown in Listing 10. Once the script sets sor for the (prefix, achorName) pair. A withdraw has no
optional parameters, such as the HelloInterval, it distance associated with it. This feasibility criteria al-
then adds it to the CCNxStackHelper before installing lows equal-cost multipath to each anchor. Periodically
the stack helper on nodes. (e.g. every 10 seconds) the anchor advertises its prefixes.
Each link (neighbor adjacency) has a positive cost. We
use “1” for all link costs.
1 NfpRoutingHelper nfp ;
2 nfp . Set ( ” H e l l o I n t e r v a l ” , TimeValue ( Seconds ( 1 ) ) ) ←- Each routing node will accept only feasible adver-
; tisements. When a node receives a strictly better adver-
3
tisement, it erases all prior predecessors for the (prefix,
4 CCNxStackHelper ccnx ;
5 ccnx . SetRoutingHelper ( nfp ) ; achorName) pair and uses only the strictly better adver-
6 ccnx . Install ( nodes ) ; tisement. It immediately (with jitter) forwards the adver-
tisement with increased cost to its peers. When a node
Listing 10. Installing a routing protocol
receives an equal advertisement, it adds the predecessor
to the list of equal cost multi-paths for the (prefix, achor-
Name) pair and does not forward the advertisement. If a
3.2 Name Flooding Protocol Routing
withdraw message changes the state of a (prefix, achor-
The Name Flooding Protocol (NFP) is a distance vector
Name) pair to unreachable, it is forwarded immediately
routing protocol for CCNx names. It creates indepen-
(with jitter). If it does not change the state, its only ef-
dent directed acyclic graphs (DAGs) for each pair ( an-
fect is to remove a specific predecessor from the set of
chorName, prefix ). An anchor name is a unique identifier
multi-path predecessors.
for a node that advertises a prefix. We use a CCNxName
for both the anchorName and prefix. The prefix is a NFP uses two routing messages: an advertisement
CCNx name prefix for matching against Interest mes- and a withdraw. If a node loses reachability for a route,
sages to determine where to send them. This construc- it may immediately send a withdraw message to its
tion allows each node to keep the maximum information neighbors. Routes use soft state and will timeout after
about prefix reachability at the expense of extra signal- 3x the advertisement period. Advertisements and with-
ing and storage costs. Node should still forward only draws are sent in a routing message, which is in turn
towards the least cost anchor, as there is no guarantee carried in the payload of a Interest message. Each rout-
that two anchor paths will not cause a loop for the same ing message has a 1-hop MessageSeqnum specific to that
prefix. NFP is intended as a demonstration of a CCNx 1-hop message. A message is only accepted if (Router-
routing protocol, and exhibits worse performance than Name, MessageSeqnum) is greater than the previously
other protocols, such as in [5]. heard (RouterName, MessageSeqnum). A routing message
NFP advertises the tuple (prefix, anchorName, anchor- is also an implicit Hello from that neighbor. It may be
PrefixSeqnum, distance). Each (prefix, anchorName) pair is sent with no advertisements or withdraws to function
considered independently from other advertisements. simply as a Hello.
This means that NFP maintains routes to all anchors that The neighbor table tracks Hello status for each neigh-
advertise a specific name prefix. Each anchor is respon- bor. It has a callback to NeighborStateChanged()
sible for incrementing its own anchorPrefixSeqnum with whenever the state of a neighbor changes (UP, DOWN,
each new advertisement. As the advertisement travels DEAD). We use a 3-state model for neighbors so we do
over the network, its distance is always increasing with not erase their messageSeqnum right away when they go
each hop. We do not require min-hop link costs, it could DOWN. They have to timeout a second time to DEAD
be any positive distance per hop. state before we erase the record. If a neighbor goes to
Each anchor has a unique name, for example a cryp- DOWN state, we erase all next hops that use that neigh-
tographic hash of a public key. In our experiments, we bor. That may cause PrefixStateChanged() to be
use a name that is a 32-byte value, similar to what a called if a (prefix, anchorName) becomes unreachable. On
SHA-256 hash of a public key would be. a DEAD change, we simply erase the record.
An advertisement for (pref ix, anchorN ame) is con- The prefix table stores the best advertisements we
sidered feasible if the anchorPrefixSeqnumis greater than have seen for each (prefix, anchorName) pair. It has a
any previously seen sequence number, or anchorPrefixSe- callback to PrefixStateChanged() when a (prefix,
qnum being equal to a previous advertisement and the anchorName) becomes reachable or unreachable. There
distance is no greater than any previous advertisement currently is not a method to prune DEAD records like
seen at the node. An advertisement is strictly better if there is for neighbors.
the sequence number is larger or begin equal the dis-
tance is strictly less. A withdraw message is feasible if
 A new NS3 Implementation of CCNx 1.0 Protocol — 8/9

Computational Cost (Link Failure)

100x103
4. Applications 90x103
NFP

80x103
CCNx applications inherit from the CCNxApplica-

Computational Cost
70x103
tion base class, which in turn inherits from ns3::App- 60x103
lication. This means that CCNx applications can use 50x103
40x103
the ns3::ApplicationContainer, which provides
30x103
easy mechanisms to start and stop applications on a 20x103
node. We provide two example applications: a con- 10x103
sumer and a producer. 0x100
1 2 3 4 5
Number of Replicas
4.1 Consumer-Producer Figure 5. Computational Cost after Link Failure
The consumer-producer example applications use a CC-
NxRepository. The repository is a name prefix plus a
fixed number of content objects all of a fixed size. One 5. Experiments
repository may be shared between all producers (repli-
cas), so there is no duplication of state. Each CCNx- This section presents results of some experiments with
Producer will register as an anchor for the repository the NFP routing protocol (see Section 3.2). The pur-
prefix (and thus advertise it via a routing protocol) and pose is to illustrate using the simulator on a non-trivial
serve the repositories content via a CCNxMessagePor- topology with real routing traffic. These experiments
tal. Each CCNxConsumer will request names from the are not a thorough evaluation of the NFP routing pro-
repository with a fixed request rate. For each request, it tocol, though they do show some of its characteristics.
uses CCNxRepository::GetRandomName() to pick As mentioned in the prior section on NFP, because it
a name from the repository. Currently, the repository treats each pair (anchorN ame, pref ix) as an indepen-
only supports a uniform name distribution. A node may dent routing process, it will scale worse than LSCR [5]
have zero or more producers on it. or DCR [4], which only advertise the best anchor for a
prefix.
We used a similar methodology as in [5], which
1 Ptr <c o n s t CCNxName> prefix = Create <CCNxName> ←-
( ” ccnx : / name= p r e f i x ” ) ; presents the routing protocol LSCR. The simulations
2 uint32_t bytes = 1 2 4 ; are done on the 154 node AT&T topology using the sim-
3 uint32_t count = 1 0 0 0 ; ulator’s NFP protocol. Because NFP is a distance vector
4 Ptr <CCNxContentRepository> repo = Create <←-
CCNxContentRepository> ( prefix , bytes , count←-
protocol, the comparison is not exactly apples to apples.
); Instead of measuring link state advertisements (LSAs),
we measure advertisement and withdraw routing up-
Listing 11. Creating a repository date messages. We measure computational complexity
Listing 11 shows how to create a content repository the same: it is each call for an event (e.g. a timer or ta-
with a given prefix. In this example, each content ob- ble operation) and each iteration through a loop control
ject, which will have its own individual name under structure. We have not implemented the NLSR or LSCR
the name ccnx:/name=prefix, will be 124 bytes of protocols in our simulator, so we cannot directly com-
payload, and there will be 1,000 of them. The Ptr<> pare results. The methodology in [5] uses 30 random
reference to the repo is then shared between producer nodes as anchors and randomly distributed 210 name
nodes and consumer nodes (see the next listing). prefixes among them. We repeat each experiment 20
Listing 12 shows how to create a set of consumer times.
nodes for a repository repo. Because the CCNxAp- Figure 5 shows the computation cost associated with
plication class follows the standard NS3 application a single link failure. After an initial period (30 seconds),
model, we can use the ApplicationContainer to a single link is selected and failed by introducing a 100%
schedule starting and stopping an application. The same packet loss. After 3 seconds, the Hello protocol times
process applies to the CCNxProducer. out and the peers on the link remove each other. Be-
cause the topology has a few nodes of high degree and
many nodes of low degree, this usually results in one or
1 CCNxConsumerHelper consumer ( repo ) ; a small number of nodes being disconnected. The com-
2 consumer . SetAttribute ( ” R e q u e s t I n t e r v a l ” , ←-
TimeValue ( MilliSeconds ( 5 ) ) ) ;
putational cost is almost linear in the number of replicas
3 ApplicationContainer consumerApps = consumer . ←- because each (anchorN ame, pref ix) pair is propagated,
Install ( consumerNodes ) ; so when a leaf node has its link cut, it will lose a number
4 consumerApps . Start ( Seconds ( 2 ) ) ; of routes proportional to the number of replicas.
5 consumerApps . Stop ( Seconds ( 1 2 ) ) ;
Figure 6 shows the number of routing update mes-
Listing 12. Configuring a consumer sages triggered by a link failure. As with the computa-
 A new NS3 Implementation of CCNx 1.0 Protocol — 9/9

Messages (Link Failure)

3x103 simulations more efficient. We will also implement sev-
NFP
2x103 eral different routing protocols and new transport pro-
2x103
tocols, including a chunk based reliable transport and a
Messages

manifest based reliable transport.

2x103

1x103
References
500x100
[1]
ccns3Sim open source project. https://github.
0x100
1 2 3 4 5 com/PARC/ccns3Sim/wiki. Accessed: 2016-05-
Number of Replicas 05.
Figure 6. Routing messages after Link Failure [2]
NS3 simulator. http://nsnam.org. Accessed:
2016-05-05.
[3]
tional cost, the number of withdraw messages will scale R. Chiocchetti, D. Rossi, and G. Rossini. ccnsim: An
linearly with the number of replicas. highly scalable ccn simulator. In 2013 IEEE Inter-
In terms of processing efficiency, ccns3Sim executes national Conference on Communications (ICC), pages
these 50 second virtual time examples in under 40.1 sec- 2309–2314, June 2013.
onds real time in a simulation with over 18.8M compu- [4]
J. Garcia-Luna-Aceves. Name-based content rout-
tational complexity and 221,880 packets. That comes ing in information centric networks using distance
out to an average execution time of 2.1 usec per routing information. In Proceedings of the 1st International
protocol event on a MacBook Pro laptop with a 2.6 GHz Conference on Information-centric Networking, ICN ’14,
core i7 CPU. The simulations use under 285 MB of RAM pages 7–16, New York, NY, USA, 2014. ACM.
(just under 1.8 MB per node). Most of the memory is [5]
E. Hemmati and J. Garcia-Luna-Aceves. A new
going to the content repositories. approach to name-based link-state routing for
information-centric networks. In Proceedings of the
6. Conclusions 2nd International Conference on Information-Centric Net-
working, pages 29–38. ACM, 2015.
The ccns3Sim module for NS3 implements the CCNx
[6]
1.0 protocols. It is a native NS3 implementation in C++98 S. Mastorakis, A. Afanasyev, I. Moiseenko, and
that uses the NS3 coding style, memory and object man- L. Zhang. ndnsim 2.0: A new version of the ndn
agement functions, and application style. Using mod- simulator for ns-3. Technical report, Technical Report
ular NS3 helpers, a user can substitute or configure all NDN-0028, NDN, 2015.
the major CCNx components: the Layer 3 implementa- [7]
M. Mosko, I. Solis, and C. Wood. Ccnx messages
tion, the forwarder, the routing protocol, the PIT, FIB, in tlv format. Internet-Draft draft-irtf-icnrg-
and Content Store with in the forwarder, and the layer ccnxmessages-02, IETF Secretariat, April 2016.
4 Portal. Each of these pieces includes a layer delay http://www.ietf.org/internet-drafts/
model to allow simulation of data structure and pro- draft-irtf-icnrg-ccnxmessages-02.txt.
cessing delays. We also provide an example routing [8]
M. Mosko, I. Solis, and C. Wood. Ccnx
protocol, Name Flooding Protocol (NFP) to illustrate
semantics. Internet-Draft draft-irtf-icnrg-
how a dynamic routing protocol operates in ccns3Sim.
ccnxsemantics-02, IETF Secretariat, April 2016.
There is still more work to be done. Future work will
http://www.ietf.org/internet-drafts/
expand the cryptographic side of the implementation
draft-irtf-icnrg-ccnxsemantics-02.txt.
to allow modeling the use of pubic key cryptography.
The packet encoding currently does not support vir-
tual payloads, which are a common simulation tool to
reduce processing time. ccns3Sim is also missing In-
terest NACKs, organizational unit TLVs, and nameless
objects. We also plan on incorporating the CCNx model
within NS3’s LTE model to simulate its use in mobile
networks.
In terms of protocol implementation, future work
will include several important features. The consumer-
producer applications will support Zipf request distribu-
tions and the content store will support different place-
ment (where to cache) and replacement strategies. There
are also many optimizations to make content caching

View publication stats