Overriding Implementations

Overriding Implementations

ccns3Sim uses the NS3 run time type identification (RTTI) system and allows the user to specify which implementation of a base class to use for several components in the system. This means that a user can switch implementations from the configuration file without editing any code and a developer can implement a replacement for a part without changing anything else in the system.

For example, if a developer wants to experiment with a different style Forwarding Information Base (FIB) for route selections, the developer creates new implementations of CCNxForwarder and CCNxForwarderHelper and then sets their new helper in CCNxStackHelper before installing on any nodes.

These components can be swapped out per node:

• CCNxPit (default CCNxStandardPit)
• CCNxFib (default CCNxStandardFib)
• CCNxContentStore (default none yet)
• CCNxForwarder (default CCNxStandardForwarder)
• CCNxL3Protocol (default CCNxStandardLayer3)
• CCNxRoutingProtocol (default none)

The CCNxPortal (layer 4) design follows a factory pattern (just like the NS3 socket), so one can instantiate many different portals of different types wherever necessary. See the CCNxPortal page.

If you use CCNxStackHelper without setting anything, it will use the defaults noted above.

Configuration

The above figure shows that everything is set via the CCNxStackHelper. The default behavior is to use the CCNxStandardLayer3Helper for the layer 3 protocol, no routing helper, and CCNxStandardForwarderHelper for the forwarder. Within the forwarder, it will use the CCNxStandardPit, CCNxStandardFib, and CCNxStandardCs implementations, which are set by their TypeId string not via a helper.

Examples

In these examples, we will assume that you have a directory src/acme/model with your source code. You will not need to change any code in the src/ccns3Sim directory.

If you want to use different configurations on different nodes, you can create multiple CCNxStackHelpers with different configurations and call CCNxStackHelper::Install() on particular groups of nodes.

Using the defaults

CCNxStackHelper ccnx;
ccnx.Install (nodes);

Overriding the PIT implementation

Suppose you have AcmePit that implements the CCNxPit interface (it inherits from CCNxPit and implements the pure virtual functions). In the class' GetTypeId() static method, the TypeId name is defined as ns3::acme::AcmePit. Here is an excerpt from the configuration file:

CCNxStandardForwarderHelper forwarder;
forwarder.SetPitType("ns3::acme::AcmePit");
  
CCNxStackHelper ccnx;
ccnx.SetForwarderHelper(forwarder);
ccnx.Install (nodes);

Overriding the Forwarder implementation

Let's assume you have a different forwarder algorithm, such as label switching instead of named routing and per-packet state. It uses AcmeForwarder with the TypeId ns3::acme::AcmeForwarder. If the Acme forwarder does not, for example, use a Pit table, it would have a no-op for the SetPitType() method, or possibly assert, to indicate to the user that this table is not relevant to the new forwarder.

AcmeForwarderHelper forwarder;
// You could set your own parameters on the helper here

CCNxStackHelper ccnx;
ccnx.SetForwarderHelper(forwarder);
ccnx.Install (nodes);

Setting the Routing Protocol

NfpRoutingHelper nfpHelper;
nfpHelper.Set ("HelloInterval", TimeValue(Seconds(1)));
nfpHelper.PrintNeighborTableAllEvery(Time(Seconds(5)), trace);
nfpHelper.PrintRoutingTableAllEvery(Time(Seconds(5)), trace);

// Setup a CCNxL3Protocol on all the nodes
CCNxStackHelper ccnxStack;
ccnxStack.SetRoutingHelper (nfpHelper);
ccnxStack.Install (nodes);