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

Back to GSoC 2022 projects

Project Overview

  • Project Name: Perfect ARP and NDP
  • Student: Zhiheng Dong
  • Mentors: Tommaso Pecorella, Ameya Deshpande, Manoj Kumar Rana

The project aims to implement a “Perfect” version of ARP and NDP which produce caches that contain all needed IP address–MAC address mapping. ARP and NDP are sometimes intrusive in high-level testing, it will introduce unexpected noise to the simulation (unwanted delays, packet drops, etc.). The new method generates all needed ARP/NDP caches before simulation start to avoid the delay and message overhead of address resolution so that they can focus on other performance aspects. With the help of the example provided, ns-3 users can enable auto-generated neighbor cache in different scopes. Documentation was added to help users to understand and unit test cases were added to verify the fundamental behavior. The project was divided into 2 phases, and the phase-wise work is available below.

Project Wiki Page: GSOC2022PerfectArp

Project Plan: link

Merge Requests and Commits

Merge Requests
No. Name Status Commit
[1] Internet: GSoC-22 generate ARP/NDISC cache automatically Merged link
[2] internet: GSoC-22 dynamic neighbor cache Merged link

Project Details

Community Bonding Period

During the community bonding period, we did some preparation work:

  • Create a wiki page that will be maintained as the GSoC project evolves.
  • Set a weekly meeting with my mentors for reports and discussions.
  • Discuss the details about how to implement the ideas mentioned in the proposal and some other new ideas.
  • Layout a project plan.

Phase 1

During phase 1, I did parallel jobs for the two methods we discussed during the community bonding period.

The first method is to create a locally shared neighbor cache per network. In this approach, we create a new data structure for the locally shared neighbor cache, which is a map of map: std::unordered_map<Ipv4Address, Cache *, Ipv4AddressHash> PerfectCache, the key is the network address and the value is the pointer to normal neighbor caches in that network, (the new data structure for perfect cache is necessary to deal with the scenario that one interface has multiple IP addresses which are from different network address). We created child classes PerfectArpL3Protocol and PerfectArpCache from ArpL3Protocol and ArpCache , override functions CreateCache , Flush , CreateCache , Lookup , Add to deal with the new data structure of neighbor cache, make it shared among devices in same networks and update dynamically with IP address added/removed. We made this method work but finally didn't choose it, the prototype can be found in my GSoC branch: link.

The second method, which is also the final chosen one, is adding a helper to automatically generate neighbor caches. Users could use the helper after IP addresses are assigned, and the helper will iterate devices in the scope chosen by users to fill up neighbor caches properly by auto-generated entries. We choose this method because it's can achieve the same effect with much neater modification. It doesn't need the new data structure for shared neighbor cache and new child class. We completed a static neighbor cache generating helper and corresponding example and test during phase 1, which is included in this MR: link.

Phase 2

During Phase 2, we worked on a dynamic neighbor cache, which makes the auto-generated neighbor cache update by IP addresses added/removed, and an example is along with this feature. I also worked on documentation and all the comments and suggestions provided by my mentors and the reviewers.

MR submitted during this phase: link

Build Project

Steps to build the code for Phase 1

  • Clone ns-3-dev from above provided link
  • Configure ns-3-dev: ./ns3 configure --enable-tests --enable-examples -d optimized
  • Build ns-3-dev: ./ns3 build
  • To run the example: ./ns3 run src/internet/examples/
  • To run the test: ./ -s neighbor-cache

Steps to build the code for Phase 2

  • Clone ns-3-dev from above provided link
  • Configure ns-3-dev: ./ns3 configure --enable-tests --enable-examples -d optimized
  • Build ns-3-dev: ./ns3 build
  • To run the example: ./ns3 run src/internet/examples/
  • To run the test: ./ -s neighbor-cache

Other Works

Apart from the deliverable code above, I also did the following jobs on the side during the program:

  • Fixed a couple of issues I found when I dug into ns-3 source code.
  • Test the influence of link state changes and series of ip neigh flush cmd on permanent entries in Linux.
  • Test the DAD behavior when on/off in Linux by Wireshark.

Proposal vs. Actual Work

We completed the proposed work with a method different from the proposal. That method was raised during the community bonding period and was discussed and decided during phase 1. The method we chose functionally achieves our goals with neater modification.

Future Work

During phase 2, when modifying neighbor cache NUD_STATE, I found the related code in ReceiveLLA and HandleNA has an improper structure and have multiple logical mistakes, I planned to refactor the code. For this task, I already opened up an MR.


I would like to thank my mentors, and the whole ns-3 community for every suggestion, discussion, and comment which helps me to deal with all the difficulties and problems I meet through the GSoC period. It was a great experience working with ns-3 community, I learned not only about technology and knowledge but also cooperation and communication, which will definitely help me in the future. I would also like to thank Google for providing this opportunity.