From Nsnam
Jump to: navigation, search

Main Page - Current Development - Developer FAQ - Tools - Related Projects - Project Ideas - Summer Projects

Installation - Troubleshooting - User FAQ - HOWTOs - Samples - Models - Education - Contributed Code - Papers

This is the webpage for planning Google Summer of Code 2009 projects and mentors. ns-3 plans to apply for a spot in the Google Summer of Code again this year. Please list project ideas and identify possible mentors below.

The ns-3 project presented at a GSoC Infosession at the University of Washington on March 5th, 2009. Slides for the short talk we gave may be found here.

Disclaimer: There is no guarantee that ns-3 will be accepted again in GSoC 2009. We have to re-apply.

Note: These ideas are not limited to Google Summer of Code; anyone is welcome to work on them (please email the ns-developers list if one interests you).

Virtual NetDevices for ns-3

  • Mentor or proposer: Tom Henderson
  • Description: A virtual device is a device that is treated like a physical device by the operating system but does not correspond to any hardware. Virtual devices are very important in modern networking research to implement tunneling overlays (e.g. virtual private networks, tunnels to get Ipv6 connectivity from a purely Ipv4 network) and things like 802.1q VLAN tagging. For instance, the IRTF Routing Research Group seems likely to suggest a so-called map-and-encaps architecture for helping the global core routing scalability problem. A proposed project in this area is to help define an architecture for inserting such virtual devices, and to develop a few concrete instances of these devices, such as Ipv6-over-IPv4, VLANs, providing multiple addresses per physical interface for routers to leverage, etc.

Fragmentation and MTU discovery for ns-3

  • Mentor or proposer: Tom Henderson
  • Description: IPv4 packets may need to be fragmented if they encounter device MTUs that are smaller than the datagram. Presently, we have no support for fragmentation for ns-3. An initial project in this space will be to port the fragmentation code from the yans simulator to ns-3. However, there is much more to do here in the area of supporting typical and research-oriented Path MTU discovery techniques as well. In IPv6, there is no in-network fragmentation, so Internet systems need to deal with this at the endpoints. However, the ICMP messaging on which Path MTU discovery relies upon may not be available (since many firewalls block these packets). MTU issues also become more prominent when using IP-in-IP tunnels over virtual devices (see above). Therefore, supporting proper fragmentation handling code and implementing path MTU discovery will open up new research areas for ns-3.

Network Address Translation (NAT) for ns-3

  • Mentor or proposer: Tom Henderson
  • Description: NATs are an essential part of the networking landscape, and are also central to current research since they are being proposed even for IPv6. We have no NAT model for ns-3. Another interesting area of research is the art of traversing NATs, including inbound connections. A proposed project is to develop a typical IPv4 NAT for ns-3, perhaps by leveraging Linux NAT code, and to provide some typical example configurations and test code (home or small office connectivity through a NAT). Then, take the project in some interesting research direction, such as the above suggested areas (IPv6 NATs, NAT traversal) or another one of the student's choosing.

Network Simulation Cradle for IPv4

  • Mentor or proposer: Tom Henderson, Florian Westphal
  • Description: As part of last year's Google Summer of Code, Florian Westphal ported Sam Jansen's Network Simulation Cradle to ns-3. This provides the ability to run Linux TCP code over ns-3's IPv4 stack. However, the port could be made more complete by extending it to totally cover the Linux TCP/IPv4 stack. A good summer project would be to add IPv4 support to NSC, and we have the benefit of a few mentors in this area for any such work. The two main areas here are:
  • enable nsc to create multiple interfaces, assign addresses, set up routing table, etc.
  • extend/rework ns-3 to use these features.

Protolib and Agent-J for ns-3

  • Mentor or proposer: Tom Henderson
  • Description: Protolib is a application support library that enables application code to be run on real systems and also within simulators such as ns-2 and OPNET. Agent-J is an extension to this that allows Java applications to run in ns-2. We seek a student interested in porting over this framework to ns-3. This will enable the use of a wide range of new routing protocols and applications in ns-3.

SNS for ns-3 Wifi

  • Mentor or proposer: Tom Henderson (the SNS author Kevin Walsh will help if needed)
  • Description: Several years ago, staged network simulations (SNS) were introduced to ns-2, via a patch of the wireless models. This yielded a dramatic improvement in ns-2 wireless simulations. This project suggests to try to incorporate these techniques into the Wifi model. The student doing this will probably learn a lot about Wifi and about profiling code performance.

Realtime Distributed simulation

  • Mentor or proposer: Mathieu Lacage
  • Description: run multiple instances of ns-3 on multiple physical machines interconnected by an ip network, each instance is running a realtime simulation, and they can all send and receive packets to each other through UDP-based tunnels over the physical interconnection between each machine. This project requires the implementation of a UDP-based (a TCP option would be nice) tunneling mechanism implemented in a RtTunnelNetDevice which performs UDP encapsulation of outgoing packets and UDP decapsulation of incoming packets. Each simulator instance will require a map from simulated IP addresses to physical IP+port numbers. Simulation setup, initialization, and configuration should be done with RPYC ( The initial implementation should be able to run on a single physical host with multiple instances of the RPYC daemon to control the multiple instances of the simulator on this single host. The student will be given access to a cluster to test and implement deployment on multiple physical hosts.

Router model for ns-3

  • Mentor or proposer: Tom Henderson
  • Description: Many simulators including ns-3 fail to provide high fidelity models of Internet routers. For instance, intra-device latencies and input queuing behavior are not modeled. This project would work to adapt some results on empirical router testing into a new Router node type for ns-3. For more details of the basic idea, see [1].

Click modular router for ns-3

  • Mentor or proposer: Tom Henderson
  • Description: The Click modular router is a popular router implementation for routing research. This project would port and enable ns-3 simulations to use the Click modular router [2]. There is previous experience in doing this for ns-2.

Large scale topology for ns-3

  • Mentor or proposer: Tom Henderson
  • Description: ns-2 has previously incorporated support for various topology generators (see, but these are not supported in ns-3 yet. The basic idea is to write scripts that turn the output of these generators into simulation scripts. In addition, this project could look at the problem of assigning IP addresses coherently to such topologies. Recent work by the Emulab project may be portable.

Emulab/ns-3 integration

  • Mentor or proposer: Tom Henderson
  • Description: Emulab is a leading testbed for Internet research. Emulab experiments are described in tcl like ns-2 scripts. Emulab also uses ns-2 emulation. This project would attempt to integrate Emulab with ns-3. There would be two main goals. 1) Test and document how ns-3 emulation mode could be used in emulab instead of ns-2. Compare its features and performance. 2) Investigate whether Emulab scripting could be cut over to Python/ns-3 or whether ns-3 needs to generate Tcl for Emulab; attempt to do this integration.
  • Mentor or proposer: Tom Henderson
  • Description:

Advanced queues for ns-3

  • Mentor or proposer: Tom Henderson
  • Description: Presently, ns-3 implements only a basic FIFO queue. We would like a student interested in different queuing disciplines and implementations to add support for more sophisticated queues, such as fair queuing, RED, RIO, etc. The first step may be to port the ns-2 implementations, or possibly the implementations from the Linux routing and traffic control project.