One way to get involved with ns-3 is to work with a mentor on a suggested project. These are typically project suggestions that would be valued contributions but the proposer does not have enough time to do it himself or herself, but is willing to mentor someone else to do it.
Another possibility for students is to get involved in the Google Summer of Code program. This program is administered by Google and acceptance is competitive.
How does a mentored project work? You contact the mentor and describe your interests and availability to work on the module. You and the mentor will work out a plan to regularly review and discuss the development of your module, following the guidelines for developing new models for ns-3. You will set up a public repository somewhere such as a site listed here or your own mercurial server.
Not all projects are mentored, nor do they all need to be. Please suggest new project ideas on this page and whether you would mentor them.
- 1 Google Summer of Code
- 2 Introductory projects
- 3 Projects needing completion
- 4 Mentored projects
- 5 Feature requests
Google Summer of Code
2012 Google Summer of Code Project Ideas
ns-3 plans to apply to 2012 Google Summer of Code. Our 2012 ideas page: 2012 GSOC project ideas
This project category is for smaller, simpler projects for new developers to get started. If you would like to work on one of these, please coordinate with the named mentor.
Sockets should support the setting of QoS
Mentor: Tommaso Pecorella
Projects needing completion
Some projects were started in the past and never brought to completion.
Bug 187 has a patch that needs further review, updating to ns-3-dev, and finishing off. The enhancement is described as follows:
We need an implementation of ARP which avoids the generation of ARP request/reply packets and assumes a 'perfect' ARP table is always available and up-to-date.
Mentor: Tom Henderson
There is little support for global (i.e. god) routing or dynamic routing for IPv6. This was started in a 2011 ns-3 summer of code project.
This section lists project ideas for which there is interest by an ns-3 developer or maintainer to serve as a mentor in the development of a new feature for ns-3.
Please do not apply for mentoring help on a class project unless you have approval from the instructor to receive mentoring.
Decouple traffic generation from sockets
Mentor: Tom Henderson
All ns-3 simulations are IP based but there is no template for how to do this for non-IP-based stacks. One issue that should be addressed in the long term is that applications that generate traffic are strongly coupled to the sockets interface. It would be nice to decouple the traffic generation aspects of these applications from the sockets-related code.
- summary: Proposed decoupling to generalize applications
- ns-developers post: http://mailman.isi.edu/pipermail/ns-developers/2007-July/003136.html
- code location: http://code.nsnam.org/laprisee/ns-3-mp/
- status: Was under discussion in the summer.
SCTP (Stream Control Transmission Protocol)
Mentor: Tommaso Pecorella
SCTP is a message-based L4 protocol with features similar to both TCP and UDP. It was originally developed as a reliable protocol to transport PSTN control streams, and it's currently used to carry 3G and 4G signaling over IP networks. The use of SCTP, however, is not limited to signaling transport, as its features makes it very interesting for a lot of other applications where UDP or TCP fails. Currently there is no SCTP implementation for ns-3. An SCTP implementation would have to comply with the IPv4 and IPv6 layers and have programming APIs toward the application layer similar to the ones defined in the available SCTP implementations for Linux.
- Required Experience: C++
- Bonus Experience: L4 protocols understanding
- Interests: L4 protocols modeling and simulation
- Difficulty: medium
- Recommended reading:
The following projects have been suggested in the past. If you are working on them, please let us know on the developers or users list so that we can coordinate activities. If you want to add a project, please describe it below.
Path MTU discovery for IPv4 stacks
Status: Being worked on by Vedran Miletic
There is no path MTU discovery implemented for IPv4. This makes guessing the end-to-end MTU imperative for ns-3 simulations. We would welcome a contribution that introduced path MTU discovery to ns-3.
Vedran expressed interest in working on PMTU discovery.
Update: This section has been updated in order to reflect the IPv4 fragmentation availability.
Path MTU discovery for IPv6 stacks
There is no path MTU discovery implemented for IPv6. This makes guessing the end-to-end MTU imperative for ns-3 simulations. While the PMTU Discovery technique is described in RFC 1981 and IPv6 ns-3 stack currently supports the needed ICMPv6 types, the implementation lacks of the following features:
- routers shall not do fragmentation and send ICMP Packet Too Big.
- PMTU tables (with aging) shall be stored in IPv6 layer.
- MTU shall be considered and passed to L4 layers on a per-path basis.
We would welcome a contribution that introduced path MTU discovery to ns-3.