From Nsnam
Revision as of 18:21, 12 July 2021 by Ameyanrd (Talk | contribs)

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 2021 projects

Project Overview

  • Project Name: IPv6 Nix-Vector Routing
  • Student: Ameya Deshpande
  • Mentors: Manoj Kumar Rama, Tommaso Pecorella
  • Project Goals: The project aims to implement IPv6 Nix-Vector Routing with minimal code duplication from IPv4 Nix-Vector Routing. ns-3 has an implementation of Nix-Vector routing for IPv4. Routing protocols like Global Routing and Nix-Vector Routing help the user a lot when dealing with complex topologies. Unlike any dynamic routing protocol, these protocols simply fill the routing tables and prevent any overhead involved. Currently, there is no such implementation for IPv6 available in ns-3. For IPv6 Nix-Vector Routing, the implementation should handle link-local and global unicast addresses.
  • Repository:
  • About Me: I am currently a pre-final undergraduate student at the National Institute of Technology Karnataka, Surathkal (NITK). I like to play with open-source softwares, browse through their code, make changes and contribute back, if suitable. My areas of interest include Computer Networking, Operating Systems, and Cloud Computing. I have around three years of experience working with C and C++ and around a year working with Python. I have worked before in the development of Linux Kernel (IPv6) and Wireshark (libwireshark).
  • Project Proposal: link
  • Design Document: link

Milestones and Deliverables

The GSoC period is divided into three phases. Following are the deliverables according to the proposal:

Phase 1

Duration: Week 1 to Week 4

  • Prepare tests for the existing IPv4 NixRouting implementation.
  • Port the existing IPv4 Nix code to generic Nix code.
  • Convert the routing and helper classes into template classes.
  • Introduce aliases for IPv*-related classes and make the changes at all their occurrences.

Phase 2

Duration: Week 5 to Week 8

  • Prepare simple examples and tests for IPv6 NixRouting.
  • Handle different member functions for similar IPv*-related classes, virtual functions, and callback functions.
  • Handle link-local and global unicast addresses.

Phase 3

Duration: Week 9 and 10

  • Work on additional tests and a large IPv6 networking topology example (similar to
  • Update the Nix-Vector Routing documentation.

Weekly Reports

Community Bonding Period

Duration: May 17 - June 6

  • Prepare the initial tests for IPv4 Nix-Vector routing (MR link).
  • Discussed the proposal ideas and any potential issues.
  • Since the proposal uses C++ templates, aliases, etc., it is a concern if Python Bindings will be generated for some of the constructs.
  • Complete the Python Bindings setup for rescanning the nix-vector-routing module.
  • Start the Design Documentation for discussing and developing the best possible way for implementation.

Week 1

Duration: June 7 - June 13

  • Start working on the refactoring of IPv4 Nix-Vector routing.
  • Introduce templates in IPv4 Nix-Vector Routing and Helper classes with template parameter as the parent class for inheritance.
  • Replace all the IPv4-related identifiers to IP for generically representing IPv[4, 6].
  • For the IPv[4, 6] equivalent classes, define aliases based on the template parameter.
  • Rescan Python Bindings and verified that there are no issues present.
  • A draft MR is created.

Week 2

Duration: June 14 - June 20

  • Starting working towards IPv6 Nix-Vector Routing.
  • Resolved all the possible errors popping up after instantiation with respective IPv6 template parameters. (In NixVectorRouting, it's Ipv6RoutingProtocol and in NixVectorHelper, it's Ipv6NixVectorHelper.)
  • Some IPv4 and IPv6 related corresponding classes have similar functions but different names. This was causing difficulty in handling different cases. We decided to propose the change in the respective classes themselves to deprecate the current function name and make both the functions (in IPv4 and IPv6 classes) the same.
  • As of now, PrintRoutingPath () is working great! This ensures that Nix-Vector Routing is working fine. Some issues are occurring during IPv6 routing and PrintRoutingTable ().
  • IPv4 Nix-Vector Routing functionality is still intact and working as it was before.
  • Some of the identified reasons for routing issues could be because link-local and multicast addresses are not handled separately for the IP-to-node mappings. Apart from this, the callback logic needs to be checked properly.
  • MR for proposing deprecation of functions: link

Week 3

Duration: June 21 - June 27

  • Completed the basic IPv6 Nix-Vector Routing code.
  • The routing issues in the case of IPv6, encountered last week, are solved now.
  • While adding the IPv6 code, the RouteOutput () and RouteInput () functions have to handle different cases. So, I have used C++ template specialization to handle it.
  • Nix did not have the logic for forwarding (usage of SetForwarding () and IsForwarding ()) functions. This was added for IPv4 and IPv6.
  • A simple IPv6 Nix-Vector routing example is also created, similar to
  • MR updated: link

Week 4

Duration: June 28 - July 4

  • Worked on the nms-p2p example and tests for IPv6 NixRouting.
  • There are a couple of issues I am facing with the above implementations. We have noticed a crash when we set an IPv6 interface down. I am digging to why it is happening.
  • There a few issues with the nms-p2p example as well but I am working on them.
  • Apart from that, we noticed that Doxygen is generating warnings for the template specialized functions.
  • Please find the latest code at the gsoc-21 branch.

Week 5

Duration: July 5 - July 11

  • Completed with the NMS-P2P example and tests.
  • Resolved an issue in the BFS logic. There was no check for the incoming interfaces in the logic. And this resulted in packet routing, even if it was not intended.
  • We detected that Clang requires explicit declaration of public functions in the .cc file; otherwise, it leads to a linking error. On the other hand, GCC can detect the declarations in the .h file easily.
  • Introduced a flag in the example to distinguish IPv4 and IPv6 examples instead of having redundant files.
  • Another thing (as mentioned before), we found that Doxygen shows a warning for C++ template specialized functions and does not take documentation for the generic one.
  • Worked on the comments and suggestions on the Merge Requests.
  • There are 3 open merge requests at this point 1, 2 and 3.
  • Please find the latest code on the project at the gsoc-21 branch.