Comfortably Geek

We’re organising the fourth annual Workshop on NS-3, to be held in conjunction with SIMUTools 2012. The workshop will be held on March 23rd, 2012, in Sirmione, Italy. Details regarding the important dates, submission guidelines, and the scope of the workshop is available on the WNS3 2012 site.

The workshop serves as an annual gathering of ns-3 users and developers to share ideas, and brainstorm over future directions for the project. We’re inviting conference style full paper submissions, which will be made available in the ACM and EU digital proceedings. Furthermore, we’re also hosting an interactive session comprising of demos and posters. So start working on your papers and proposals as soon as possible! If you have any queries, feel free to contact the workshop chairs.

Like previous editions of the workshop, we also plan to conduct a day long ns-3 developers’ meeting around the same time. More details will be out soon. Keep an eye on our mailing lists and website to not miss any announcements.

Important dates

Papers submission deadline : December 2, 2011
Notification of acceptance : January 20, 2012
Camera-ready deadline : February 10, 2012
Demos and posters proposal deadline : February 24, 2012
Workshop in Sirmione : March 23, 2012
Developers’ meeting : TBA

Having been busy with coursework lately, I hadn’t gone through our users’ list in a while. Wading through a week’s worth of posts today, it seems to me like a good deal of questions are from users who are trying to get started with extending ns-3. This is indeed quite expected; as a research tool, ns-3 is most useful only when built upon. These extensions usually take one of the following forms:

1. a tweak to an existing protocol to make it simulate some specific scenario (try searching for “attacks” on our users list),
2. adding some functionality X to an existing module, (for instance, RRC messages support for LTE)
3. or writing an entirely new module from scratch.

Before you do *anything* with ns-3, go through the tutorials first.

Now, for cases 1 and 2 mentioned above, the *only* way to proceed is:

1. Go through the literature about what you’re trying to implement — “What do I want to achieve?”
2. Understand the scope and limitations of the ns-3 module you’re trying to deal with (go through the model documentation at least) — “Does ns-3 have the necessary base for me to build on top of?”
3. If the answer to the above is “yes”, then start reading through the respective module’s code to figure out where you’ll need to insert your modifications. — “Where does my extension/tweak fit within the existing source code?”
4. Implement.
5. Profit.

Case 3, on the other hand, requires a lot more work:

1. Go through the literature about what you’re trying to implement — “What do I want to achieve?”
2. Understand how your module would fit within ns-3. This is usually the tricky part. To this end, it’s very important to understand how packets flow through a node within ns-3. This figure from our manual is usually the only thing you’ll need to know to get started.
3. At this point, I’ll make things easier for myself and assume that you’re going to implement something that fits into the above mentioned architecture (rather than trying to modify the architecture itself). The first step is as simple as deriving from the right class. This gives you the virtual methods you need to implement in order to maintain a particular component’s semantics. So if you’re trying to write a new application, derive from ns3::Application. If it’s a new routing protocol, derive from ns3::Ipv4RoutingProtocol or ns3::Ipv6RoutingProtocol. If it’s a new NetDevice, derive from ns3::NetDevice. The easiest thing to do is to find another example of the component type you’re trying to develop and reflect its basic structure.
4. Now to get started writing your new module, have a look at Gustavo Carnerio’s create-module.py script (inside src/)  which generates a skeleton for your new module. This includes the necessary sub-folders for the module, and also the all important wscript file. For most use cases, it would suffice to peek into some other module’s wscript file to get an idea of what to do. If you’re going to need some fancy external libraries, you’ll need to go through the waf documentation a bit. Look into src/click/wscript to get an idea of how to do external linking.
5. Now once you start developing your new simulation model, you’ll need to attach this object to a node to get it to do something. This mode of attachment varies from component to component. Some objects are ‘aggregated’ to the node, some are added to a list of similar components (like applications being added to a node’s ‘ApplicationList’) and so forth. The best places to look in order to understand this are the helpers for each module. So for instance, if you want to figure out how to add your routing protocol to a node, look at src/olsr/helper/ to get an idea.
6. Lastly, you’ll need to write simulation scripts to see your module in action. Copying off and editing existing example scripts from the examples/ folder or the src/*/examples/ folders should suffice for most cases.
7. If you’re going to propose this new module for merge, look at our contributing code page. Keep in mind that we won’t merge code which doesn’t have any documentation, or tests (validation or unit tests, as is applicable).
8. Merge.

We now move into part II of the ns-3-click tutorial series wherein I’ll walk you through an ns-3 script and explain how to load your Click scripts onto ns-3 nodes. This tutorial goes through the following steps:

1. Walkthrough of an example Click graph from ns-3-click.
2. Using the Click graph in an ns-3 simulation.

Walkthrough of an example Click graph from ns-3-click

The Click script I’ll be explaining below is available in current ns-3-dev and stable releases from ns-3.11 onwards. You can find it in src/click/examples/nsclick-lan-single-interface.click.

When working with ns-3-click, you will need to handle all layer 3 functionalities expected of a networked node from Click. The Click script that we’ll be talking about here provides exactly this. It handles ARP, and forwards packets up and down the stack as required. It has a single network interface (eth0) to send and receive packets, and has a kernel interface (tap0) to send/receive packets from the kernel (in ns-3, this corresponds to communicating with layer 4).

We first describe the interface to tap0 with the following functionalities:

1. All packets received from tap0 should be forwarded down to the stack.
2. All packets received from below the stack, destined to us, should be sent up the stack via tap0.

elementclass TapSimHost {
$dev |

// Packets go to tap0, which sends them to the kernel
input[0]
-> ToDump(tokernel.pcap,2000,IP,PER_NODE 1)
-> ToSimDevice($dev,IP);

// Packets sent out by the kernel get pushed outside
FromSimDevice($dev,4096)
-> CheckIPHeader2
-> ToDump(fromkernel.pcap,2000,IP,PER_NODE 1)
-> GetIPAddress(16)
-> [0]output;
}

kernel::TapSimHost(tap0);

The above snippet does exactly what we’ve described so far. We create an element class which has a single input and output. Packets received on the input are plumbed to tap0 (because $dev is now tap0, as per the instantiation in the last line). Packets received from tap0 are pushed outside. We now describe a LAN host, which will handle ARP, and check the destination IP to see if we should receive the packet.

elementclass LanSimHost {
$ipaddr, $hwaddr |

cl::Classifier(12/0806 20/0001,12/0806 20/0002, -);
forhost::IPClassifier(dst host $ipaddr,-);
arpquerier::ARPQuerier(eth0);
arpresponder::ARPResponder(eth0);

ethout::Queue
-> ToDump(out_eth0.pcap,PER_NODE 1)
-> ToSimDevice(eth0);

// All packets received on eth0 are silently
// dropped if they are destined for another location
FromSimDevice(eth0,4096)
-> ToDump(in_eth0.pcap,PER_NODE 1,ENCAP ETHER)
-> cl;

// ARP queries from other nodes go to the ARP responder element
cl[0] -> arpresponder;

// ARP responses go to our ARP query element
cl[1] -> [1]arpquerier;

// All other packets get checked whether they are meant for us
cl[2]
-> Strip(14)
-> CheckIPHeader2
-> MarkIPHeader
-> GetIPAddress(16) // Sets destination IP address annotation
-> forhost;

// Packets for us are pushed outside
forhost[0]
-> [0]output;

// Packets for other folks or broadcast
// packets get sent to output 1
forhost[1]
-> ToDump(discard.pcap,2000,PER_NODE 1,ENCAP IP)
-> [1]output;

// Incoming packets get pushed into the ARP query module
input[0]
-> arpquerier;

// Both the ARP query and response modules send data out to
// the simulated network device, eth0.
arpquerier
-> ToDump(out_arpquery.pcap,PER_NODE 1)
-> ethout;

arpresponder
-> ToDump(out_arprespond.pcap,PER_NODE 1)
-> ethout;

}

lan::LanSimHost(eth0:ip,eth0:eth);

Now that we have a LanSimHost type ready, and instantiated (in the last line indicated above), we perform the final plumbing required to connect our LanSimHost to our kernel tap device:

// Users can do some processing between the two elements
lan[0] -> kernel;
kernel -> lan;
// Packets for others or broadcasts are discarded
lan[1] -> Discard;

This concludes our description of the nsclick-lan-single-interface.click file. Let’s now describe an ns-3 simulation script for our scenario.

Using the Click graph in an ns-3 script

I’ll now describe a simple ns-3 script which makes use of the above described Click graph. Not surprisingly, the script is named nsclick-simple-lan.cc and can be found within src/click/examples/. The simulation scenario is a simple one: two nodes A and B connected via a CSMA channel, with A sending B a stream of packets using a TCP connection. A is Click based, whereas B is a normal ns-3 node.

The first step would be to create the nodes.

NodeContainer csmaNodes;
csmaNodes.Create (2);

Next, we create a CSMA channel.

CsmaHelper csma;
csma.SetChannelAttribute ("DataRate", DataRateValue (DataRate (5000000)));
csma.SetChannelAttribute ("Delay", TimeValue (MilliSeconds (2)));
NetDeviceContainer csmaDevices = csma.Install (csmaNodes);

We then install a normal internet stack on node B.

InternetStackHelper internet;
internet.Install (csmaNodes.Get (1));

And then setup a Click based internet stack on node A. We need to specify the Click script that the particular node is supposed to use, and in the event that we require a Click based node to run a traffic generator on top, we need to specify a routing table element for the node to use. This can be seen by the name “rt” at the end of the nsclick-lan-single-interface.click file.

ClickInternetStackHelper clickinternet;
clickinternet.SetClickFile (csmaNodes.Get (0), "src/click/examples/nsclick-lan-single-interface.click");
clickinternet.SetRoutingTableElement (csmaNodes.Get (0), "rt");
clickinternet.Install (csmaNodes.Get (0));

Now that all the nodes have an internet stack, we assign IPv4 addresses to all the network interfaces.

Ipv4AddressHelper ipv4;
ipv4.SetBase ("172.16.1.0", "255.255.255.0");
ipv4.Assign (csmaDevices);

And then, we setup the traffic generators for talking between node A and node B.

Address LocalAddress (InetSocketAddress (Ipv4Address::GetAny (), 50000));
PacketSinkHelper packetSinkHelper ("ns3::TcpSocketFactory", LocalAddress);
ApplicationContainer recvapp = packetSinkHelper.Install (csmaNodes.Get (1));
recvapp.Start (Seconds (5.0));
recvapp.Stop (Seconds (10.0));
OnOffHelper onOffHelper ("ns3::TcpSocketFactory", Address ());
onOffHelper.SetAttribute ("OnTime", RandomVariableValue (ConstantVariable (1)));
onOffHelper.SetAttribute ("OffTime", RandomVariableValue (ConstantVariable (0)));

ApplicationContainer appcont;
addressValue remoteAddress (InetSocketAddress (Ipv4Address ("172.16.1.2"), 50000));
onOffHelper.SetAttribute ("Remote", remoteAddress);
appcont.Add (onOffHelper.Install (csmaNodes.Get (0)));
appcont.Start (Seconds (5.0));
appcont.Stop (Seconds (10.0));

Lastly, we enable PCAP tracing on all the CSMA NetDevices in the scenario.

csma.EnablePcap ("nsclick-simple-lan", csmaDevices, false);

And to conclude the script, we specify the running time for the simulation to be 20 seconds, and call Simulator::Run(). Don’t forget to call Simulator::Destroy() lest tools like Valgrind start screaming about memory leaks.

Simulator::Stop (Seconds (20.0));
Simulator::Run ();
Simulator::Destroy ();
return 0;

To see the results of running our simulation, execute the below in your terminal from the ns-3-dev top level directory once you’ve built Click as described in the previous article.


$: ./waf --run nsclick-simple-lan


Have a look at the resulting pcap traces (nsclick-simple-lan-0-[0,1].pcap) using wireshark or tcpdump to see what happened through the simulation.

Hope you found this little walkthrough helpful. If you find any bugs with ns-3-click, please don’t hesitate to file a bug report on our bugzilla.

Since its development, I’ve been seeing a lot of requests for an ns-3-click 101. So with no further ado, here’s the first in a series of tutorials to help you get an idea of how to go about using ns-3-click. In this article, I’ll provide an idea of what ns-3-click is and how to install it .

1. What is ns-3-click?

ns-3-click, or the NS-3 Click Integration, is a feature of the ns-3 tool which allows a user to use a Click Modular Router instance to handle an ns-3 node’s layer 3 functionality. Click is an architecture for designing highly flexible router configurations. Basically, it offers a large number of fine grained packet processing units called “elements”, which can be put connected in various combinations into a Click graph. A Click graph defines a particular configuration for a router. The motivation for bringing Click into ns-3 is simple. Click users get to test their Click graphs in a powerful simulation environment which ns-3 offers, and ns-3 benefits from the large feature set that Click brings with it in the form of elements. In ns-3-click, the design choice was to entirely delegate ns-3′s layer 3 functionality to Click. This means that an ns-3 node running a Click router will now have to use Click’s implementations of ARP, routing tables and so forth.

So before you get started with ns-3-click, I suggest going through [0] and [1]. The first paper should tell you everything you need to know about what Click is, and the second one will inform you about where Click fits into ns-3. The latter will help you understand what ns-3-click can or cannot do for you.

2. Installation

By now, you know what ns-3-click is, and its time to get your hands dirty. The first step is to download and build Click.

$: git clone http://read.cs.ucla.edu/git/click DIR
$: cd DIR
$: ./configure --enable-nsclick --enable-userlevel


Note: If you require additional modules, enable them as required using the –enable-<module> flag.

Now build Click:

$: make


Once this is complete, we need to build ns-3 and point it to the Click source we’ve just compiled. So let’s proceed to fetch and build ns-3. Note that ns-3-click was merged post ns-3.10, and will be released with ns-3.11. It is currently available in ns-3-dev.

$: hg clone http://code.nsnam.org/ns-3-dev
$: cd ns-3-dev
$: ./waf configure --with-nsclick=<path-to-click-source> --enable-examples

Once the last command has finished executing, you should see a list of features/modules that have been enabled. At this point, you should see the following line:

NS-3 Click Integration        : enabled

Now, let’s build ns-3:

$: ./waf build


If all goes well, ns-3 should now be built successfully. To test whether things went well, try running one of the example scripts.

$: ./waf --run nsclick-simple-lan

This should generate some PCAP traces (nsclick-simple-lan-*.pcap). If you see packets being exchanged in there, then you’re good to go!

This concludes part I of the ns-3-click tutorial. In the next part, I’ll provide a code walk through of a simple example script that uses ns-3-click. If you find any bugs with ns-3-click, please don’t hesitate to file a bug report on our bugzilla.

References

[0] Eddie Kohler, Robert Morris, Benjie Chen, John Jannotti, and M. Frans Kaashoek, “The Click Modular Router”. ACM Transactions on Computer Systems 18(3), August 2000, pages 263-297. (Paper from the MIT-PDOS page)

[1] Lalith Suresh P., Ruben Merz, ”NS-3-Click: Click Modular Router Integration for NS-3”. In Proc. of 3rd International ICST Workshop on NS-3 (WNS3), Barcelona, Spain. March, 2011. paper

The wait is over, and we hereby announce the students selected for the NS-3 Summer of Code 2011 programme!

• Ashwin Narayan with “Click-MAC extensions for ns-3-click”. Mentored by Ruben Merz and myself.
• Pankaj Gupta with “LTE-RRC extensions”. Mentored by Giuseppe Piro and Francesco Capozzi.
• Atishay Jain with “IPv6 Global Routing”. Mentored by Tom Henderson and Mitch Watrous.

Congratulations to all the students. Hoping to see a lot of good code come out of this effort and most importantly, some long term contributors to the ns-3 project itself.